Issue 87 - Rough draft of proposal to vote

["Yaron Y. Goland" <ygoland@bea.com>]

WSDL 1.1 provides no mechanism to specify optional message parts. This 
means that optional parts of messages, such as optional SOAP headers, 
cannot be described using WSDL. Below is a solution based on the 
approach WSDL 2.0 is taking to solve the same problem.

Proposed Text:

14.9 Application Data

Application data is data transmitted in a message outside of the normal 
message channel, specifically data in a message that is not bound to a 
WSDL message part.

To enable BPEL processes to access application data the from-spec is 
extended to include:

<from appDataForMessage="ncname"/>

The value of the appDataForMessage attribute MUST be the name of a WSDL 
message type variable. The output of this from-spec will always follow 
the schema:

bpws:applicationData
	xs:any *

The application data will be recorded inside of the applicationData XML 
element.

To enable BPEL processes to set application data the to-spec is extended 
to include:

<to appDataForMessage="ncname"/>

The schema of the data assigned using this to-spec MUST follow the 
previously defined schema.

When a message is received by the BPEL process any application data 
associated with the message MUST be made available via the application 
data from-spec. The exact means by which application data is retrieved 
from a message is binding specific and the binding definition has final 
say as to what data will appear as application data but in general any 
parts of the incoming message that do not have bindings to specific WSDL 
message parts are considered application data. Similarly when a message 
is sent if any application data has been associated with the message 
then the application data MUST be sent with the outgoing message using 
the rules defined for the particular binding in use.

In the specific case of a message received via a SOAP based binding the 
applicationData value associated with the received BPEL WSDL message 
type variable MUST contain any SOAP headers that do not have bindings to 
message parts in the WSDL used to receive the message. Each SOAP header 
not otherwise bound to a WSDL message part MUST be copied into the 
application data structure in the relative document order the headers 
appeared in the SOAP message.

Similarly if a message is sent via a SOAP based binding then any values 
in the applicationData MUST be copied into the SOAP message's header 
block in document order. The exact place where the headers will be 
inserted into the header block is application specific but SHOULD 
generally be after the SOAP headers defined via a binding in the 
outgoing message's WSDL message definition.

Any application data associated with a WSDL message type variable is 
replaced with application data from the incoming message, if any, 
whenever that variable is used to receive a new message.