Issue 47: Feature Changes in WSDL1.2 & Potential Impact on BPEL4WS Canyang Kevin Liu, SAP

Objectives Goals Non-goals Caveats Information briefing Facilitate TC discussion Non-goals Not representing the W3C WSD WG Focus on what & how, Not on why Caveats WSDL1.2 is still under heavy construction, even the version number might be changed It’s possible that the WSD WG may revisit/change the resolutions presented here

Agenda Introduction Cosmetic syntax changes Key changes in interface layer Other changes Impact on BPEL4WS - Discussion

Introduction WSDL is currently the subject of a standardization effort at the W3C. WSDL1.1 is a W3C notes, not a “standard”, but implemented by most of today’s web services platforms WSDL1.2 is the deliverable of the W3C Web Services Description working group WSDL1.2 Currently consists of 4 parts Part 1: Core language Part 2: Message Patterns Part 3: Binding extensions Part 0: Primer Public WSDL1.2 working drafts and latest editor’s drafts are available from http://www.w3.org/2002/ws/desc/

Cosmetic Syntax Changes WSDL1.1 definition import Type Message part portType Operation Input/output/fault message Binding Service port WSDL1.2 definition Import + include Type interface Operation Input/output/infault/outFault Feature Property Binding Input/output/fault|feature|property Service endpoint Note: there are other proposals on table, e g. changing “operation” to “messageExchange”

Removing Message Construct Status: WG reached general agreement in July F2F Work in progress to fine tune the resolution Current Thought Drop <message> Let <input>/<output>/<infault>/<outfault>(depends on the MEP in use) point to a single <xsd:element> Provide support for RPC use case and other rules Reference – Sanjiva presentation

Removing Message Construct - New Syntax <interface name=“ncname”> <operation name=“ncname” [encodingStyle=“uri”]> <input … [body=“qname”] [headers=“list-of-qnames”]/> <output … [body=“qname”] </operation> </interface> This syntax is for in-out MEP. Similar syntax for other MEPs The optional encodingStyle attributes can point to any rule specification identified by an URI WSDL1.2 defines rules for RPC support http://www.w3.org/2003/ws/desc/rpc

Removing Message Construct - SOAP Binding <soap:Envelope> <soap:Header> <interface name=“ncname”> <operation name=“ncname”> <input … [body=“qname”] [headers=“list-of-qnames”]/> … </operation> </interface> </soap:Header> <soap:Body> </soap:Body> </soap:Envelope>

Features and Properties Status – under a task force. Here is the current thoughts Features: An abstract piece of functionality Defined in a separate specification + Named with an URI WSDL feature at abstract level can be used to indicate support for soap 1.2 features, requirements, ws-policies, etc Syntax <feature uri="xs:QName" required="xs:boolean"?> <documentation />? </feature> Properties Features have properties, e.g “urn:encryption” feature has a property “cipher” which can take values for different algorithms WSDL property may be used to provide a value or constrain the use of a property <property uri="xs:QName" required="xs:boolean"?> <documentation />? [ <value />| <constraint />] </property> Where they can appear in WSDL1.2? As children of Interface, interface/operation As children of binding, binding/operation WSDL Features vs WS-Policy - Complimentary Ws-policy defines a format for defining features WSDL feature provide a mechanism for referencing features References Original proposal http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/att-0004/SOAP-feature-proposal.htm Presentation http://lists.w3.org/Archives/Public/www-ws-arch/2002Nov/0085.html

Features and Properties – an example <interface name =“”> <feature uri=“http://schemas.xmlsoap.org/ws/2002/12/secext” required="true"/> <operation name="operatation1"> <feature uri="http://schemas.xmlsoap.org/ws/2002/08/wstx" required="true"/> <property uri = “http://schemas.xmlsoap.org/ws/2002/08/wstx/trans” required=‘true”> <value>request-new</value> </property> <input message="inputMessage"/> <output message="outputMessage"/> </operation> <operation name="operatation2"> </interface> a) the "secext" must be used or all inbound and outbound messages b) the "requires-new" feature must be used for the inbound and outbound messages of "operation1". In the case of SOAP, the features may be implemented either via SOAP header blocks or SOAP transport bindings.

Interface Aggregation WSDL1.2 allows an interface to be derived from one or more other interfaces Syntax: <interface name="xs:NCName" extends="list of xs:QName"? encodingStyleDefault="xs:anyURI"? > <documentation />? [ <operation /> | <feature /> | <property /> ]* </interface>

More flexible message exchange pattern support Status Under a Task Force. Here is current thoughts WSDL1.1 only allows 4 “operation primitives” Request-response, one way, solicit-response, notification WSDL1.2 allows any message exchange patterns be defined in their own specification and named with URIs WSDL1.2 part 2 defines a set of 6 message patterns (still under working) In-out, in-only, out-in, out-only, … An operation references a message pattern

Message pattern example One of WSDL1.2 part 2 defined patterns URI http://www.w3.org/@@@@/@@/wsdl/in-out It contains two message references Message A with direction “in” Message B with direction “out” An operation may use the patterns <operation name=“myOp“ pattern=http://www.w3.org/@@@@/@@/wsdl/in-out…> … <input messageReference=“A" body=“…“ headers=“…" /> <output messageReference=“B" body=“…“ headers=“…" /> </operation> In-Out This pattern consists of exactly two messages, in order, as follows: A message: indicated by a Message Reference component whose {messageReference} is 'A' and {direction} is 'in' received from some node N indicated by a Message Reference component whose {messageReference} is 'B' and {direction} is 'out' sent to node N This pattern uses the rule "Fault Replaces Message". An operation using this message pattern has a {pattern} property with the value 'http://www.w3.org/@@@@/@@/wsdl/in-out'.

Interface Syntax 1.1 vs. 1.2 WSDL1.2 interface WSDL1.1 portType <interface name="xs:NCName“ extends="list of xs:QName"? encodingStyleDefault="xs:anyURI"? > <feature uri="xs:QName" required="xs:boolean"? >? <property uri="xs:QName" required="xs:boolean"? > [ <value /> | <constraint /> ] </property>? <operation name="xs:NCName" pattern="xs:anyURI" encodingStyle="xs:anyURI"? > <feature />? <property />? <input messageReference="xs:NCName"? body="xs:QName"? headers="list of xs:QName"? >? <output > ? <infault name="xs:NCName" details=“qname” headers=“list-of-qnames”/>? <outfault />? </operation> </interface> WSDL1.1 portType <message name="nmtoken"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> <portType name="nmtoken">* <operation name="nmtoken">* <input name="nmtoken"? message="qname“/>? <output name="nmtoken"? message="qname">? <wsdl:fault name="nmtoken" message="qname"> * </wsdl:operation> </wsdl:portType>

Other changes

Removed WSDL1.1 Features Operation Overloading ParameterOrder In Wsdl1.1, names of operations can be same within a portType WSDL1.2 requires operations within an interface must have unique names ParameterOrder Related to RPC programming model mapping

Preclude SOAP encoding For SOAP binding, WSDL1.2 removes the “use” attribute from soap:body and other elements any encoding is disallowed, including soap encoding Add encodingStyle attributes to interface/operation can be used to provide a hint about how the schema is constructed Alignment with other activities SOAP1.2 deprecated encoding to “adjuncts” WS-I Basic Profile 1.0 disallows any encoding

Enhanced Features Add wsdl:include Improved Extensibility Model after XSD: import + include Improved Extensibility allow extensions anywhere in wsdl definition: Elements based Attributes based

Changes to binding – simpler & more reusable WSDL1.2 makes binding@interface optional Allow a binding defintion reusable by multiple interfaces Adds service@interface a service can only implement one interface For very simple cases, binding is totally optional allow inlining binding definition in endpoint Defines more defaults for soap:binding

Discussions

Impact on BPEL4WS? I Removing message Message Exchange Patterns BPEL4WS 1.1 relies on wsdl:message for property and variable definition Needs significant update? Message Exchange Patterns WSDL 1.2 defines a number of MEPs and allows more defined elsewhere What’s the impact on bpws:invoke, bpws:reply and bpws:receive? Is reference to operation enough? Interface aggregation BPEL4WS composes portType/operation Is it a concern to aggregate all operations for a interface?

Impact on BPEL4WS? II Features and Properties Some thing we can take advantage with? Cosmetic syntax changes & Other changes Minor impact Code examples need to be updated

What options do we have? Option 1 – continue with WSDL1.1, defer compliance with WSDL1.2 to next release? Option 2- support both WSDL1.1 and WSDL1.2, how? different extensions? Option 3 – switch to WSDL1.2 now? Other options? Do we need an liaison with WSD WG?