Skip to main content

A quick fix of WS-I BP2703 assertion

A few days ago we have got WS-I conformance report from our third party client that says our web service is not compliant with WS-I guidelines. The report summary was failed with the following error:
Assertion: BP2703
Our team member quick check the WS-I compliance in Jdeveloper and can't reproduce the bug, but with soapUI gave the result with the assertion failed. Here is the WSDL of the web service.
<?xml version="1.0" encoding="utf-8" ?>
<wsdl:definitions 
    xmlns:tns="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/RetailerService.wsdl" 
    targetNamespace="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/RetailerService.wsdl" 
    xmlns:retailer="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns="http://schemas.xmlsoap.org/wsdl/" >
 
  <wsdl:import namespace="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl" 
      location="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl"/>


  <wsdl:service name="RetailerService">
    <wsdl:port name="LocalRetailerPort" binding="retailer:RetailerSoapBinding">
      <soap:address location="http://localhost:9080/Retailer/services/Retailer"/>
    </wsdl:port>
  
  </wsdl:service>
<wsp:Policy wsu:Id="UsernameToken" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy/ws-policy.xsd" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
  <wsp:ExactlyOne>
   <wsp:All>
    <sp:TransportBinding/>
    <sp:SupportingTokens>
     <wsp:Policy>
      <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"/>
     </wsp:Policy>
    </sp:SupportingTokens>
   </wsp:All>
  </wsp:ExactlyOne>
 </wsp:Policy>
</wsdl:definitions>
If we carefully check the error, we have to get that wsdl parser encounter wsp:Policy element after service element and throws exception. If we will check the WS policy specification we could found that Policy element can be anywhere in wsdl document.
But basic WS-I profile doesn't allow the Policy element after the service element by the specification of the wsdl schema. If we put the Policy element before the type or import element the assertion error fixes because according to the wsdl schema WSDL definition could take any number of element before type element, and this the simple fix. The valid wsdl document are as follows:
<?xml version="1.0" encoding="utf-8" ?>

<wsdl:definitions 
    xmlns:tns="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/RetailerService.wsdl" 
    targetNamespace="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/RetailerService.wsdl" 
    xmlns:retailer="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl" 
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns="http://schemas.xmlsoap.org/wsdl/" >
  
     <wsp:Policy wsu:Id="UsernameToken" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy/ws-policy.xsd" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
  <wsp:ExactlyOne>
   <wsp:All>
   
    <sp:TransportBinding/>
    <sp:SupportingTokens>
     <wsp:Policy>
      <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"/>
     </wsp:Policy>
    </sp:SupportingTokens>
   </wsp:All>
  </wsp:ExactlyOne>
 </wsp:Policy> 
  <wsdl:import namespace="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl" 
      location="http://www.ws-i.org/SampleApplications/SupplyChainManagement/2002-08/Retailer.wsdl"/>


  <wsdl:service name="RetailerService">
    <wsdl:port name="LocalRetailerPort" binding="retailer:RetailerSoapBinding">
      <soap:address location="http://localhost:9080/Retailer/services/Retailer"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>
Rest of the part of the blog post describes how to configure WS-I testing tools on Mac OS. For some unknown reason SOAPUI doesn't display the conformance report on the window.
First download the Java WS-I testing tool from the following link. Unzip the archive and add the following properties on the .bash_profile
export WSI_HOME=/Users/samim/Development/WS-i/TestTool/wsi-test-tools
export PATH=/opt/subversion/bin:$WSI_HOME/java/bin:$PATH
run the bash_profile . .bash_profile
If we now runs the Analyzer.sh tools we should get the following error
/bin/sh^M: bad interpreter: No such file or directory
Unfortunately all the executable file on the wsi-test-tools/java/bin/ catalog has wrong return endings.
Do the following for the files setenv.sh and Analyzer.sh
cp -p setenv.sh setenv.sh.orig
cat setenv.sh | tr -d '\r' > setenv.sh.new
mv setenv.sh.new setenv.sh
now change the permissions of the files:
chmod +x setenv.sh (also do for the Analyzer.sh)

Now we are ready to execute Analyze tool. From the wsi-test-tools/java/samples/ directory run the following command
./Analyze.sh -config ./analyzerConfig.xml
these will analyze the WSDL and create a report on the current directory. You can examine and edit the analyzerConfig.xml for our purpose. Report.xml can be run on any internet browser and you will see the report.
Labels:

Comments

Post a Comment

Popular posts from this blog

8 things every developer should know about the Apache Ignite caching

Any technology, no matter how advanced it is, will not be able to solve your problems if you implement it improperly. Caching, precisely when it comes to the use of a distributed caching, can only accelerate your application with the proper use and configurations of it. From this point of view, Apache Ignite is no different, and there are a few steps to consider before using it in the production environment. In this article, we describe various technics that can help you to plan and adequately use of Apache Ignite as cutting-edge caching technology. Do proper capacity planning before using Ignite cluster. Do paperwork for understanding the size of the cache, number of CPUs or how many JVMs will be required. Let’s assume that you are using Hibernate as an ORM in 10 application servers and wish to use Ignite as an L2 cache. Calculate the total memory usages and the number of Ignite nodes you have to need for maintaining your SLA. An incorrect number of the Ignite nodes can become a b...
Post a Comment
Read more

Benchmarking high performance java collection framework

I am an ultimate fan of java high performance framework or library. Java native collection framework always works with primitive wrapper class such as Integer, Float e.t.c. Boxing and unboxing of wrapper class to primitive data type always decrease the java execution performance. Most of us, always looking for such a library or framework to works with primitive data type in collections for increasing performance of Java application. Most of the time i uses javolution framework to get better performance, however, this holiday i have read about a few new java collections frameworks and decided to do some homework benchmarking to find out, how much they could better than Java native collection framework. I have examine two new java collection framework, one of them are fastutil and another one are HPPC. For benchmarking i have used java JMH with mode Throughput. For benchmarking i took similar collection for java ArrayList, HashSet and HasMap from two above described frameworks. Col...
Post a Comment
Read more

Apache Ignite Baseline Topology by Examples

Ignite Baseline Topology or BLT represents a set of server nodes in the cluster that persists data on disk. Where, N1-2 and N5 server nodes are the member of the Ignite clusters with native persistence which enable data to persist on disk. N3-4 and N6 server nodes are the member of the Ignite cluster but not a part of the baseline topology. The nodes from the baseline topology are a regular server node, that store's data in memory and on the disk, and also participates in computing tasks. Ignite clusters can have different nodes that are not a part of the baseline topology such as: Server nodes that are not used Ignite native persistence to persist data on disk. Usually, they store data in memory or persists data to a 3rd party database or NoSQL. In the above equitation, node N3 or N4 might be one of them. Client nodes that are not stored shared data. To better understand the baseline topology concept, let’s start at the beginning and try to understand its goal and what ...
Post a Comment
Read more