Wrapper Style - the root element of the message (wrapper element) is the operation name, which is not part of the payload. The children of the root element must map directly to parameters of the operation's signature.
Non-Wrapper Style (bare) - the entire message is passed to the service operation. The reply message is handled in a similar way.
Wrapper or Non-Wrapper can only be used in conjunction with the document/literal style defined in WSDL. It defines how web service request or reply messages are interpreted.
public String helloworld(
@WebParam(name = "firstName")String firstName,
@WebParam(name = "lastName") String lastName );
The request looks like:
<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>
<helloworld xmlns="http://personservice">
<firstName>John</firstName>
<lastName>Doe</lastName>
</helloworld>
</soap:Body>
</soap:Envelope>
public String helloworld(
@WebParam(name = "name", targetNamespace="http://www.myname.com")
Name name );
The request looks like:
<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>
<ns0:name xmlns:ns0="http://www.myname.com">
<firstName>John</firstName>
<lastName>Doe</lastName>
</ns0:name>
</soap:Body>
</soap:Envelope>
In JAX-WS, "SOAPBinding" annotation can be used to specify the style.
@SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.BARE)
Note
The parameter style "WRAPPED" is the default. In JAX-RPC the "WRAPPED" style is specified in the web service mapping xml file by adding "wrapped-element" element to the service endpoint mapping.
The wsdl2java will automatically assume " WRAPPED" if operation name matches the wrapper element name.
Wrapper or Non-Wrapper are a data binding style and not part of the contract of a web service, also it is not mentioned in the WSDL file.The web service client can be implemented with "non-wrapper" style for and should interoperate with a "wrapper" service without a hitch in theory at least.
The wrapper style is supported widely event it is not universally. The wrapper style is really an RPC-style binding over "document/literal" WSDL style. The method name is explicitly provided in the message.
Advantages of wrapper style.
- Wrapper service can only have one message part in WSDL, which guarantees that the message (consisting of the method element that contains parameters) will be represented by one XML document with a single schema.
- RPC style message definitions in WSDL have to use schema types, whereas with the document style we can refer directly to element names. This makes XML message representation more "precise", it is also easier to validate.
The wrapper style has one interesting drawback as it may not be immediately obvious. If a service signature changed, for example, a new parameter was added, clients will have to change as well. With wrapper style, all parameters have to be present in the XML message although they can be defined as null using "xsd:nil" attribute. This is despite the fact that the element corresponding to the parameter can be defined as optional in the schema. The non-wrapper style does not have this problem and adding a new optional element does not affect clients as binding is always name-based. This creates somewhat tighter coupling between wrapper style consumers and providers.
JAX-WS does impose some additional restrictions on the wrapper style. The most important one is the wrapper element's content type must be "sequence". By this, a method's signature always represented as an ordered list of arguments.
For non-wrapper style, the most obscure thing is how a SOAP engine decides which operation to invoke based on the message type when a web service has multiple operations as operation name is not explicitly provided by the message. The "SOAPAction" header can be used for that purpose, however this header is HTTP-only and also optional in JAX-WS. For "non-wrapper", each operation must accept a message that corresponds to a unique XML element name. Note that it is not enough to define different WSDL messages using "wsdl:message" element, each message must be represented by a different element in the schema. Web service engines use unique element names to determine Java method names that correspond to WSDL operations. This also means that with non-wrapper you CANNOT have different operation names processing the same message.
The wrapper does not support overloaded methods.
The non-wrapper does not support methods with the same signature.
