Xfire and WS in Document Literal Wrapped Style

Developers life has changed a lot . Most of the time you dont need to know whats going behind the scene. We are just following the trails somebody has gone before.When something is not working then we will do a Google search, straight forward: other guys had the same error message, blindly follow the steps given in the answer.I agree some times it will take little bit time to rephrase the search and read through the blogs etc. But what if you dont quite find what you are looking for .. Go back to the basics. Try to understand whats going on in the code esp. the third party open source code. This is what I did for couple of days this week. The problem was related to a web service.I was using Xfire and Jibx combination for the webservice client creation. When it try to send a request to an external webservice , it was creating an extra outer element for the request. like

<?xml version="1.0" encoding="UTF-8"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soap:Body>

<ns1:GetDetails xmlns:ns1="http://services.sample.com/Details">

<yup:GetDetails xmlns:yup="http://services.sample.com/yupment" xmlns:ent="http://services.sample.com/Common/Entities" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<yup:DetailsRequest>

Here  <ns1:GetDetails  is an extra element in the request, due to which it was failing the validation in the server side. I tried to find the root cause of why Xfire/Jibx is adding this extra element. Debugged the Xfire source and find the place where it is adding it and found out if "wrapped" is true it will add ns1 element to the request. I tried to find out where are we defining  this wrapped flag. Mean while I noticed that the client wsdl is created by using microsoft tools. It gave me a wild guess of whether they are using any of so called "non standard" stuff.
 
Kept on reading so many article about WS styles and finally caught the attention of  following snippet. Yeah .. thats right .. there is a 'non standard' microsoft stuff out there,document/literal wrapped pattern.

These are the basic characteristics of the document/literal wrapped pattern:

• The input message has a single part.
• The part is an element.
• The element has the same name as the operation.
• The element's complex type has no attributes.

I started looking at the wsdl and found that it matches the above characteristics. I  made the element name and the operation different.. wow!!!! it started working.

So mastery solved..... By seeing the same element and operation name Xfire was creating  the out going request as a wrapped one.

<wsdl:message name="AService_GetDetailsInfo_InputMessage">
      <wsdl:part name="parameters" element="tns:GetDetailsInfo"/>
   </wsdl:message>
  
   </wsdl:message>

   <wsdl:portType name="AService">

     <!-- Changed from GetAccountInfo to GetDetailsInfoOp to avoid wrapped style;Hence do double request by Xfire!-->
      <wsdl:operation name="GetDetailsInfoOp">
         <wsdl:input wsaw:Action=
         <wsdl:output wsaw:Action=
         <wsdl:fault wsaw:Action=
         <wsdl:fault wsaw:Action=
      </wsdl:operation>
   </wsdl:portType>
  
     <!-- Changed from GetAccountInfo to GetDetailsInfoOp to avoid wrapped style; Hence do double request by Xfire!-->
     <wsdl:operation name="GetDetailsInfoOp">
         <soap:operation soapAction=
         <wsdl:input>
            <soap:body use="literal"/>
         </wsdl:input>
         <wsdl:output>
 
To read more about the pros and cones of  Wrapped style as well as other styles go to:

http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/

Moral : Go back to the basics when ever you can ... Knowledge is power !!!!!