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?