WebSphere Process Server and RPC/Literal Web Services: Beware Messages defined by ‘type’ instead of ‘element’.

After a ridiculous amount of XML tweaking and bleeding, I realize that RPC/Literal truly is completely broken in WebSphere Process Server v6.0.2.3. On the response message that consists of a Business Object we would constantly get the exception:

Caused by: org.eclipse.emf.ecore.resource.Resource$IOWrappedException:
 Feature 'MyResultBO' not found. (sca:/message.xml, -1, -1)

The XML from the service looks correct:

<soapenv:envelope 
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:body>
      <ns1:getmyresultresponse xmlns:ns1="urn:ResultTest">
         <myresultbo> ...
         </myresultbo>
      </ns1:getmyresultresponse>
</soapenv:body>
</soapenv:envelope>

I thought it was a problem with the XML returned from the system, but tools like SOAPUI created XML documents of the exact same format.

Then, I went and took my Business Objects and created a Document/Literal Wrapped wsdl. Obviously this worked fine. I compared the document literal WSDL to the RPC/Literal wsdl and found the following difference:

Doc/lit wrapped:

<message name="getMyResultRequest">
<part name="AccountNo" element="typens:AccountElement"></part>
 </message>
 <message name="getMyResultFault">
<part name="Fault" element="typens:FaultElement"></part>
 </message>
 <message name="getMyResultResponse">
<part name="Response" element="typens:MyResultBO"></part>
 </message>

RPC/Literal:

<message name="getMyResultRequest">
<part name="AccountNo" type="xsd:unsignedLong">
    </part>
  </message>
  <message name="getMyResultFault">
<part name="Fault" element="typens:FaultElement">
    </part>
  </message>
  <message name="getMyResultResponse">
<part name="Response" type="typens:MyResultBO">
    </part>
  </message>

You’ll notice the difference between the TYPE declaration for the message part in the latter and the ELEMENT declaration in the former. When I converted my working service to use type declarations instead of element, my service stopped working and threw ‘FeatureNotFound’ exceptions (including some very wonky business object behavior that included not being able to retrieve attributes).

I then asked the service provider to generate a WSDL using DOC/Lit wrapped and everything worked fine. So from my empirical evidence, if you see TYPE declarations in your message part, your service will not be consumable from WebSphere Process Server.

RPC/Literal is a WS-I complaint specification for a Web Service and should be a first class supported WSDL style. Alas, it is not. My recommendation is to either use RPC/Encoded (non WS-I compliant) or Doc/lit wrapped. Interestingly enough, WebSphere Integration Developer does not warn you that the WSDL will not work either.

Shame on WebSphere Process Server for not fully supporting the WS-I Basic Profile standard and not documenting the lack of capability.

Author: dan

Leave a Reply

Your email address will not be published. Required fields are marked *