1. WS-I BP1.0 Recommendations On WSDL1.1 Kevin Liu October 2003

2.  SAP AG 2002, Title of Presentation, Speaker Name / 2 Objectives Provide background information for Issue 72 What’s value of BP1.0 wrt BP1.0 BP1.0 constraints on use of WSDL1.1 BP1.0 clarifications on use of WSDL1.1 Conformance to BP1.0 Impacts on BPEL - discussion

3.  SAP AG 2002, Title of Presentation, Speaker Name / 3 Background: WSDL1.1 Basics What A portType describes the abstract interface of the Web service Each contained operation can have an input, an output and a number of fault messages message portTypeoperation * input 0..1 * output 0..1 * fault * * binding 1 * serviceport * * 1 * How A binding specifies exactly one protocol for the operations of a portType Where A port defines the Web service endpoint by specifying a single network address part *

4.  SAP AG 2002, Title of Presentation, Speaker Name / 4 Background: WSDL 1.1 – A simplified Example......... What how XML Schema Where

5.  SAP AG 2002, Title of Presentation, Speaker Name / 5 What’s the value of BP1.0 wrt WSDL1.1? BP1.0 aims at interoperability It’s the result of resolving 344 interoperability issues reported by 100+ WS-I members It provides 161 recommendations about using its selected specifications, majority focuses on the use of WSDL1.1 WSDL1.1 contains many errors, ambiguities, and inconsistencies (among the spec text, examples, and schemas) BP1.0 provides clarifications, correction, examples and guidance to improve the usability and interoperability of WSDL1.1 WSDL1.1 allows multiple mechanisms to do same thing while many of the mechanisms are underspecified and causes interoperability problems. BP1.0 recommends the mostly adopted mechanism XML schema as type system + soap over http as binding BP1.0 contains 72 recommendations on WSDL1.1 (details to follow) Constraints Guidance

6.  SAP AG 2002, Title of Presentation, Speaker Name / 6 BP1.0 Constraints on Web services description BP1.0 assigns WSDL1.1 as one of the mandatory mechanisms for describing a Web Service A service must be described using WSDL, UDDI, or both BP1.0 constraints on use of WSDL1.1 XML1.0 is mandated for WSDL definitions XML schema is the only conformant type system SOAP over HTTP is the only conformant binding Disallow operation overloading - operation name must be unique within a portType Disallow out-bound operations Disallows (soap) encoding  No @use=“encoded” in wsdl bindings  No @encodingStyle in soap messages

7.  SAP AG 2002, Title of Presentation, Speaker Name / 7 BP1.0 Clarifications on WSDL1.1 BP1.0 provides clarifications and guidance on the use of the following WSDL1.1 (details to follow) Dedicated schema files Ordering of top WSDL1.1 elements wsdl:import vs. xsd:import wsdl:part@type vs. @element XML namespaces Faults description Use of RPC style

8.  SAP AG 2002, Title of Presentation, Speaker Name / 8 Which WSDL1.1 schema files to use? WSDL1.1 schemas in the appendix of the spec is out of date, and inconsistent with the spec in many cases Earlier experimental projects have provided updates to the schemas. WS- I has made a snapshot of the updated schemas available in the following URIs WSDL schema:  http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd  Note this schema allows extension to portType SOAP Binding schema:  http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd A WSDL1.1 definition must be valid with the above schemas to claim BP1.0 conformant Who is responsible for validating WSDL1.1 definition against the above schemas? It’s the responsibility of the WSDL author to assure it’s schema validated Consumers of the WSDL may be more tolerant if they choose to

9.  SAP AG 2002, Title of Presentation, Speaker Name / 9 Order of WSDL elements WSDL1.1 spec and its appended WSDL1.1 schema are inconsistent about what are the appropriate order of the top WSDL1.1 elements BP1.0 provides the following guidance: If present, the wsdl:import element must precede all other wsdl elements except wsdl:documentation If present, wsdl:type must precede all other elements except wsdl:documentation and wsdl:import The order of all other elements are not important, but in general it should be in the following order  documentation  import  types  message  portType  binding  service

10.  SAP AG 2002, Title of Presentation, Speaker Name / 10 wsdl:import vs. xsd:import WSDL1.1 uses import mechanism to allow flexible authoring Different sections of a WSDL definition can be defined in separate files and then imported into another WSDL file wsdl:import is modeled after xsd:import, but the WSDL1.1 spec doesn’t provide any explanation about how it should be used  It’s interpreted differently by different vendor and causes interoperability problems BP1.0 provides the following guidance: wsdl:import can only be used to import other wsdl files  The imported definition can either in the same namespace, or in a different namespace than the importing definition  Namespace coercion is disallowed. The imported wsdl must be referenced with the same namespace as defined by its targetNamespace  The location attribute is required and so must not be empty, but its value should only be treated as a hint to the wsdl processor xsd:import can only be used to import XML schema definitions  It can only be used in the section  It should follow the same rules as specified in xml schema

11.  SAP AG 2002, Title of Presentation, Speaker Name / 11 Example – wsdl:import vs xsd:import <definitions... xmlns:wsdl =“http://schemas.xmlsoap.org/wsdl/”http://schemas.xmlsoap.org/wsdl/ xmlns:test1 = “http://example.com/stockquote/test1”http://example.com/stockquote/test1 xmlns:test2 = “http://example.com/stockquote/test2”> … <definitions... xmlns:wsdl =“http://schemas.xmlsoap.org/wsdl/”http://schemas.xmlsoap.org/wsdl/ xmlns:test1 = “http://example.com/stockquote/test1”http://example.com/stockquote/test1 xmlns:test2 = “http://example.com/stockquote/test2”> …

12.  SAP AG 2002, Title of Presentation, Speaker Name / 12 wsdl:part@element vs. wsdl:part@type WSDL:part has two exclusive attributes – element or type One can use the “element” attribute to reference an XSD global element. e.g.... Or use “type” to reference an XSD simple or complex type. E.g.... The choice of “type” vs “element” has significant impact on soap binding definition, and in turn on the soap message wsdl:part attribute Allowed XSD Definition Allowed SOAP Binding Style Impact on SOAP Message typeXSD simple or complex types RPCThe xsd type will be used as the type of the child of a part accessor which gets its name from wsdl:part@name elementXSD global element declaration documentthe xsd element defines the child of soap:body

13.  SAP AG 2002, Title of Presentation, Speaker Name / 13 How to handle fault? Do you have to specify all faults in your WSDL? NO A WSDL should, but not required to, include all known faults Soap faults can appear as body fault or header fault What is the “style” of soapbind:fault or soapbind:headerfault? “RPC” is only appliable to soapbind:body Headers, headerfaults, and faults are always “document” style They can only refer to a wsdl:part that has been defined using the “element” attribute What are the right fault code to use? “VersionMismatch”, and “MustUnderstand” should be first checked If the recipient receives a soap message that is inconsistent with its WSDL, it should generate a soap:Fault with a fault code of “Client”

14.  SAP AG 2002, Title of Presentation, Speaker Name / 14 Use of xml namespaces contained in the must have a target namespace attribute with a valid and non-null value One exception: when xsd:import is its only child The targetNamespace of a WSDL definition and the targetNamespace of its contained schema maybe the same – they are in different symbol spaces

15.  SAP AG 2002, Title of Presentation, Speaker Name / 15 When do you need to provide a namespace for soap binding element? Selected soap binding style Does it have to provide a value for soapbind:body@namespace? How does it impact the soap message? Document- Literal No (note soapbind:header/headerfault/fault are always document style) In the wire message, the serialized element child of soap:body gets its namespace from its xsd element definition RPC- Literal Yes1.Operation wrapper element : the wire message use the provided value as its namespace 2.part accessors and return values must be placed under no namespace 3.Children of part accessor must be namespace qualified and get their ns value from its xsd definition

16.  SAP AG 2002, Title of Presentation, Speaker Name / 16 Use of RPC style Many of BP1.0 recommendations are related to the use of RPC style Already covered some in the slides for part@type use and namespace use Example follows

17.  SAP AG 2002, Title of Presentation, Speaker Name / 17 Example - A RPC style WSDL1.1 definition http://example.org/bar/http://example.org/foo/http://example.org/bar/ http://example.org/bar/http://example.org/foo/http://example.org/bar/ In the case of RPC, the resulting soap message is described as a mix of wsdl constructs and xsd constructs. used as the name of the operation wrapper used as the name of the part accessor used as the namespace of the operation wrapper used as the definition of part accessor children

18.  SAP AG 2002, Title of Presentation, Speaker Name / 18 Example – the resulting soap message String 0 String 0 Operation wrapper has the same name of the wsdl:operation, and it takes the ns value from soapbind:body@namespace in its wsdl definition Part accessor has the same name as the wsdl:part@name, and it must not have any namespace Children of part accessor have their namespace from their schema definition

19.  SAP AG 2002, Title of Presentation, Speaker Name / 19 Conformance to BP1.0 BP1.0 has a well-defined scope which is decided by its underlying specifications. Conformance is only relevant within its BP1.0 covers WSDL1.1, SOAP1.1, UDDI 2.0 and a few other related specs BP1.0 conformance is based on three kinds of artifacts MESSAGE – the soap message DESCRIPTION – the wsdl definition REGDATA – the uddi registry elements A conformant artifact has to meet all requirements targeted for that artifact For DESCRIPTION, conformance can be claimed for the following elements of WSDL1.1 Port Binding portType  Operation  Message Conformance is not about the overall WSDL definition. e.g. A WSDL definition may contain a conformant binding and multiple non- conformant bindings

20.  SAP AG 2002, Title of Presentation, Speaker Name / 20 How can I claim conformance to BP1.0? WS-I provides testing tools which can be used to check conformance of a target artifact, such as a SOAP message WS-I defines a schema for wsi:Claim element which can be used to advertise conformance to a profile in different ways WSDL top elements( e.g. wsdl:port, wsdl:binding, etc) SOAP message header UDDI tModel For Example,

21.  SAP AG 2002, Title of Presentation, Speaker Name / 21 Discussion – BP1.0 Impact On WSDL1.1 BP1.0 provides many valuable clarifications on use of WSDL1.1. These clarifications should be reflected in all WSDL examples in BPEL spec The following BP1.0 constraints affect portType definitions and should be considered for BPEL XML1.0 is mandated for WSDL definitions - OK XML schema is the only conformant type system - OK Disallow operation overloading - operation name must be unique within a portType – should be enforced Disallow out-bound operations – OK The following constraints are for bindings, there is no direct conflicts with BPEL SOAP over HTTP is the only conformant binding –OK, we only provide conformant portType definition, bindings are up to the services implementers. Disallows (soap) encoding – OK, same as above

22.  SAP AG 2002, Title of Presentation, Speaker Name / 22 No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation. IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of IBM Corporation in USA and/or other countries. ORACLE® is a registered trademark of ORACLE Corporation. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA® is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One. SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are trademarks of their respective companies. Copyright 2002 SAP AG. All Rights Reserved

23.  SAP AG 2002, Title of Presentation, Speaker Name / 23 Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden. Die von SAP AG oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer Softwarehersteller enthalten. Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® und SQL Server® sind eingetragene Marken der Microsoft Corporation. IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®, AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere®, Netfinity®, Tivoli®, Informix und Informix® Dynamic ServerTM sind Marken der IBM Corporation in den USA und/oder anderen Ländern. ORACLE® ist eine eingetragene Marke der ORACLE Corporation. UNIX®, X/Open®, OSF/1® und Motif® sind eingetragene Marken der Open Group. Citrix®, das Citrix-Logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® und andere hier erwähnte Namen von Citrix-Produkten sind Marken von Citrix Systems, Inc. HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA® ist eine eingetragene Marke der Sun Microsystems, Inc. JAVASCRIPT® ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape entwickelten und implementierten Technologie. MarketSet und Enterprise Buyer sind gemeinsame Marken von SAP AG und Commerce One. SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com und weitere im Text erwähnte SAP-Produkte und -Dienst- leistungen sowie die entsprechenden Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und anderen Ländern weltweit. Alle anderen Namen von Produkten und Dienstleistungen sind Marken der jeweiligen Firmen. Copyright 2002 SAP AG. Alle Rechte vorbehalten