Issue 47: Feature Changes in WSDL1.2

1
Issue 47Feature 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
• Its 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 todays 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 editors
  drafts are available from http//www.w3.org/2002/w
  s/desc/

5
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/faultfeatureproperty
• 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 ltmessagegt
• Let ltinputgt/ltoutputgt/ltinfaultgt/ltoutfaultgt(depends
  on the MEP in use) point to a single
  ltxsdelementgt
• Provide support for RPC use case and other rules

7
Removing Message Construct - New Syntax

• ltinterface namencnamegt
• ltoperation namencname encodingStyleuri
  gt
• ltinput bodyqname
• headerslist-of-qnames/gt
• ltoutput bodyqname
• headerslist-of-qnames/gt
• lt/operationgt
• lt/interfacegt
• 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
ltsoapEnvelopegt
ltsoapHeadergt
ltinterface namencnamegt ltoperation
namencnamegt ltinput bodyqname
headerslist-of-qnames/gt
lt/operationgt lt/interfacegt
lt/soapHeadergt
ltsoapBodygt
lt/soapBodygt
lt/soapEnvelopegt
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
• ltfeature uri"xsQName" required"xsboolean"?gt
  ltdocumentation /gt? lt/featuregt
• Properties
• Features have properties, e.g urnencryption
  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
• ltproperty uri"xsQName" required"xsboolean"?gt
  ltdocumentation /gt? ltvalue /gt ltconstraint /gt
  lt/propertygt
• 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

• ltinterface name gt
• ltfeature urihttp//schemas.xmlsoa
  p.org/ws/2002/12/secext required"true"/gt
• ltoperation name"operatation1"gt
• ltfeature uri"http//schemas.xml
  soap.org/ws/2002/08/wstx" required"true"/gt
• ltproperty uri http//schemas.xmlsoap.org/ws/2
  002/08/wstx/trans requiredtruegt
• ltvaluegtrequest-newlt/valuegt
• lt/propertygt
• ltinput message"inputMessage"/gt
• ltoutput message"outputMessage"/
  gt
• lt/operationgt
• ltoperation name"operatation2"gt
• ltinput message"inputMessage"/gt
• ltoutput message"outputMessage"/
  gt
• lt/operationgt
• lt/interfacegt

11
Interface Aggregation

• WSDL1.2 allows an interface to be derived from
  one or more other interfaces
• Syntax
• ltinterface name"xsNCName"
• extends"list of xsQName"?
  encodingStyleDefault"xsanyURI"? gt
• ltdocumentation /gt?
• ltoperation /gt ltfeature /gt ltproperty /gt
  
• lt/interfacegt

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/_at__at__at__at_/_at__at_/wsdl/in-out
• It contains two message references
• Message A with direction in
• Message B with direction out
• An operation may use the patterns
• ltoperation namemyOp patternhttp//www.w3.org/_at_
  _at__at__at_/_at__at_/wsdl/in-outgt
• ltinput messageReferenceA" body headers"
  /gt
• ltoutput messageReferenceB" body headers"
  /gt
• lt/operationgt

14
Interface Syntax 1.1 vs. 1.2

• WSDL1.2 interface
• ltinterface name"xsNCName extends"list of
  xsQName"? encodingStyleDefault"xsanyURI"? gt
• ltfeature uri"xsQName" required"xsboolean"? gt?
• ltproperty uri"xsQName" required"xsboolean"? gt
• ltvalue /gt ltconstraint /gt
• lt/propertygt?
• ltoperation name"xsNCName"
  pattern"xsanyURI" encodingStyle"xsanyU
  RI"? gt
• ltfeature /gt?
• ltproperty /gt?
• ltinput messageReference"xsNCName"?
  body"xsQName"?
• headers"list of xsQName"? gt?
• ltoutput gt ?
• ltinfault name"xsNCName"
• detailsqname
• headerslist-of-qnames/gt?
• ltoutfault /gt?
• lt/operationgt

• WSDL1.1 portType
• ltmessage name"nmtoken"gt
• ltpart name"nmtoken" element"qname"?
  type"qname"?/gt
• lt/messagegt
• ltportType name"nmtoken"gt
  
• ltoperation name"nmtoken"gt
• ltinput name"nmtoken"? message"qname/gt?
• ltoutput name"nmtoken"? message"qname"gt?
• ltwsdlfault name"nmtoken" message"qname"gt
• lt/wsdloperationgt
• lt/wsdlportTypegt

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 soapbody 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 wsdlinclude
• 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_at_interface optional
• Allow a binding defintion reusable by multiple
  interfaces
• Adds service_at_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 soapbinding

20
Discussions
21
Impact on BPEL4WS? I

• Removing message
• BPEL4WS 1.1 relies on wsdlmessage for property
  and variable definition
• Needs significant update?
• Message Exchange Patterns
• WSDL 1.2 defines a number of MEPs and allows more
  defined elsewhere
• Whats the impact on bpwsinvoke, bpwsreply and
  bpwsreceive? 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?