1 / 23

Issue 47: Feature Changes in WSDL1.2 & Potential Impact on BPEL4WS

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

dolan
Download Presentation

Issue 47: Feature Changes in WSDL1.2 & Potential Impact on BPEL4WS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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 http://www.w3.org/2002/ws/desc/

  5. 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” Cosmetic Syntax Changes

  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

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

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

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

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

  14. 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 <interfacename="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> Interface Syntax 1.1 vs. 1.2

  15. Other changes

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

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

  20. Discussions

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

  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?

More Related