Issue 47: Feature Changes in WSDL1.2 & Potential Impact on BPEL4WS Canyang Kevin Liu, SAP
Jan 15, 2016
Issue 47:Feature Changes in WSDL1.2 & Potential Impact on BPEL4WS
Canyang Kevin Liu, SAP
Objectives
• Goals– 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• Operation
– Input/output/fault» message
– Service• port
•WSDL1.2•definition
– Import + include– Type
– interface• Operation
– Input/output/infault/outFault• Feature• Property
– Binding• Operation
– 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
Removing Message Construct - New Syntax
<interface name=“ncname”> <operation name=“ncname” [encodingStyle=“uri”]>
<input … [body=“qname”] [headers=“list-of-qnames”]/> <output … [body=“qname”] [headers=“list-of-qnames”]/></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
<interface name=“ncname”> <operation name=“ncname”> <input … [body=“qname”]
[headers=“list-of-qnames”]/> …
</operation></interface>
<soap:Envelope>
</soap:Envelope>
<soap:Header>
</soap:Header>
<soap:Body>
</soap:Body>
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– Syntax
<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
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"> <input message="inputMessage"/> <output message="outputMessage"/> </operation> </interface>
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>
Interface Syntax 1.1 vs. 1.2
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>
WSDL1.2 interface
<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>
Other changes
Removed WSDL1.1 Features
•Operation Overloading– 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– 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– 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?