Issue ?-WSCDL--(WSDL related proposal)

Here is the proposal for resolving CDL issues related to WSDL (location ?).


*Information Type*

The new syntax of the informationType construct will be changed to:

<informationType name="ncname"
   type="qname"? | element="qname"? exceptionType= "true|false"? />


The description would be:

The attributes type, and element describe the document to be a
WSDL 1.1 Message type, XML Schema type, an XML Schema element or a
WSDL 2.0 schema element. Only one of these attributes MUST be used in a
single informationType element.

If WSDL 1.1 is used, type attribute MUST be used to refer to WSDL message
type. When type attribute is defined, it can also refer to a simple or
complex XSD type.

For WSDL 2.0 message types, only the element attribute MUST be used.

When exceptionType attribute is "true", this type is an Exception Type
and could map to WSDL fault type. Since WSDL 2.0 supports unique faultnames, the
element attribute in the informationType refers to a WSDL 2.0 faultname when
exceptionType is "true".
By default, this attribute is "false".


*Fault Support*

WSDL Faults are described using informationType with attribute
exceptionType=true.

An example of the informationType description for a fault type is given below:

<informationType name="OutOfStockExceptionType"
                 element="wsd:OutOfStockFault" exceptionType="true" />

Where element attribute value "wsd:OutOfStockFault" could point to
unique fault name in a WSDL 2.0 based definition.


*Example WSDL 1.1 and fault mapping in CDL*

WSDL operation definition:

Note that in the below WSDL 1.1 definition, the fault badPOFault is of
type POBadAckMsg.

<wsdl:portType>
    <wsdl: operation name="handlePurchaseOrder"/>
        <wsdl:input name="poInput" message="POMsg"/>
        <wsdl:output name="poAckOutput" message="POAckMsg"/>
        <wsdl:fault name="badPOFault" message="POBadAckMsg"/>
    </wsdl:operation>
</wsdl:portType>


WS-CDL mapping of the fault:

WSDL 1.1 does not have unique fault names. In the below CDL snippet, we
create a unique fault type "badPOFault" and
map its type to POBadAckMsg in WSDL file above.

<informationType name="badPOFault"  type="wsd:POBadAckMsg"
      exceptionType="true"/>


*Example WSDL 2.0 and fault mapping in CDL*

WSDL operation definition:
In the below WSDL 2.0 definition, the fault badPOFault is of type
POBadAckMsg.

<wsdl:interface name="pohandling">
   <fault name="badPOFault" element="ghns:POFaultMsg"/>
    <wsdl: operation name="handlePurchaseOrder"/>
        <wsdl:input name="poInput" message="POMsg"/>
        <wsdl:output name="poAckOutput" message="POAckMsg"/>
        <wsdl:outfault ref="badPOFault" messageLabel="out"/>
    </wsdl:operation>
</wsdl:interface>

WS-CDL mapping of the fault:
WSDL 2.0 allows the definition of unique fault names. In the below CDL
snippet, we create a fault type "badPO" and map it to WSDL fault badPOFault

<informationType name="badPO"  type="wsd:POFault" exceptionType="true"/>


*Message Parts*

The following change is to be done to support WSDL 1.1 parts:

The syntax of the tokenLocator construct is:

<tokenLocator  tokenName="qname"
      informationType="qname"
      part="identification"?
      query="XPath-expression"? />

The following needs to be added in the CDL document section 2.4.3

The attribute part defines the document part from which the query has to
be done if this is a WSDL1.1 document. Otherwise this attribute is invalid.


*Changes to the WS-CDL function getVariable()*

The following change is to be done to support WSDL 1.1 parts:

xsd:any* getVariable(xsd:string varName, xsd:string part, xsd:string
documentPath, xsd:string  roleName?)

Returns the information of the Variable with name varName as a node set
containing a single node. The second parameter part specifies the message
part of a WSDL1.1 document. For a WSDL 2.0 document it MUST be empty.
When the third parameter documentPath is empty, then
this function retrieves the entire document from the Variable
information. When it is non-empty, then this function retrieves from the
Variable information, the fragment of the document at the provided absolute
location path. The fourth parameter is optional. When the
fourth parameter is used that the Variable information MUST be available
at the Role specified by roleName. If this parameter is not used then the
Role is inferred from the context that this function is used.


*MEPS*

WS-CDL supports today One-way and Request/response MEPs. This is
sufficient to support BP1.1.

The MEPs supported for WSDL 2.0 (per Charlton's recommendation) are:
·    In Only
·    Robust In Only
·    In-Out


*WSDL 2.0 Interface Inheritance*

An interaction happens on a channel of channelType that has a behavior
which specifies a WSDL 2.0 interface. If this interface is inherited
from another interface, then WS-CDL interactions can use this channel
to call operations of the base interface as well.




Regards,

Nick

Received on Wednesday, 13 October 2004 01:04:42 UTC