Adapter Online Help > TDV Web-Based Data Sources > About WSDL Bare and Wrapper Parameter Styles
 
About WSDL Bare and Wrapper Parameter Styles
WSDL bare and wrapped parameter styles control the consumption of data that is returned in a response. Typically if you have a parameter where you expect the response values to be small, you can put the parameter in the WSDL header. If, however, you expect there to be significant volumes of data returned in the response for the parameter, then it is best to place the parameter or set of parameters in the body of the WSDL.
TDV conforms to the open source standard for XML-based web services. Oracle provides useful reference content that describes the standards fully. This section attempt to summarize how TDV interprets those standards for using Bare and Wrapped parameters for your WSDL.
Style
Description
WRAPPED
For multiple parameters that use the BODY location.
The wrapper element is the child of the SOAP BODY and the parameter elements are children of the wrapper element.
BARE
For exactly one parameter with a location of BODY and its element is the only child of the SOAP BODY.
All other parameters of the same direction must be mapped to another location, for example, HEADER.
WRAPPED
A parameter style of wrapped means that all of the input parameters are wrapped into a single element on a request message and that all of the output parameters are wrapped into a single element in the response message. If you set the style to RPC you must use the wrapped parameter style. The wrapped style tells the Web service provider that the root element of the message represents the name of the operation and that children of the root element must map directly to parameters of the operation's signature.
With wrapped all sub-parameters are in the first level, and the client automatically wraps them in another top element.
Wrapped requests contain properties for each in and in/out non-header parameter. The properties for the method return values of each out non-header parameter, and in/out non-header parameter. The order of the properties in the request is the same as the order of parameters in the method signature. The order of the properties in the response is the property corresponding to the return value followed by the properties for the parameters in the same order as the parameters in the method signature.
Most Web services engines use positional parameter binding with wrapper style. If a service signature changes, clients must also change. With the wrapper style, all parameters have to be present in the XML message, even if the element corresponding to the parameter can be defined as optional in the schema.
The wrapped request:
Must be named the same as the method and the wrapper response bean class must be named the same as the method with a “Response” suffix.
Can only have one message part in WSDL, which guarantees that the message (method element with parameters) is represented by one XML document with a single schema.
Must have parameters present in the XML message, even if the element corresponding to the parameter can be defined as optional in the schema.
BARE
A parameter style of BARE means that each parameter is placed into the message body as a child element of the message root. With BARE there is only a top element parameter with sub-parameters inside. This one BARE parameter is sent directly.
Whether a given SOAP message is valid is determined by the WSDL that it conforms to. Web services using the bare style can have multiple parameters. It is only the actual invocation of the web service where a single parameter is passed.
The Java API for XML-based Web Services requires that parameters for bare mapping must meet all the following criteria:
It must have at most one in or in/out non-header parameter.
If it has a return type other than void it must have no in/out or out non-header parameters.
If it has a return type of void it must have at most one in/out or out non-header parameter.
Adding a new optional element does not affect clients, because binding is always name-based. To get around having to have a contract defined by the schema of the web service, you can define all child elements of the wrapper root element as required. Optional elements must be made nillable.