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

2. 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

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

4. 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

5. 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”

6. 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

7. 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

8. 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>

9. 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
Presentation

10. Features and Properties – an example
<interface name =“”>
<feature uri=“ required="true"/>
<operation name="operatation1">
<feature uri=" required="true"/>
<property uri = “ 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.

11. 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>

12. 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

13. Message pattern example
One of WSDL1.2 part 2 defined patterns
URI
It contains two message references
Message A with direction “in”
Message B with direction “out”
An operation may use the patterns
<operation name=“myOp“ …
<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

14. 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>

15. Other changes

16. 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

17. 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

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

19. Changes to binding – simpler & more reusable
WSDL1.2 makes optional
Allow a binding defintion reusable by multiple interfaces
Adds
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

20. Discussions

21. 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?

22. 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

23. 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?