1 / 20

WSDL and Schemas Discussion

Initial Review of SOAP Artifacts. The 0.5 Schemas and WSDL artifacts are substantial working assets going into the OASIS TC process.From an initial review, various definition aspects were identified that:Require change for broader tooling compatibility,May hit platform implementation limitations,

alyssa
Download Presentation

WSDL and Schemas Discussion

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. WSDL and Schemas Discussion CMIS F2F January 27, 2009 Gary Gershon gary.gershon@imergeconsult.com 203-431-9328

    2. Initial Review of SOAP Artifacts The 0.5 Schemas and WSDL artifacts are substantial working assets going into the OASIS TC process. From an initial review, various definition aspects were identified that: Require change for broader tooling compatibility, May hit platform implementation limitations, Offer opportunities for simplification, and/or Could be made more consistent. 1/27/09 2 CMIS WSDL and Schemas

    3. Tooling Obviously, the WSDL and Schema artifacts have been successfully consumed in multiple SOAP (SOA-Lite) environments for the prototype integration. However, they are not currently consumable by IBM’s WebSphere SOA platform tooling – WebSphere Integration Developer (WID) We need to arrange for tests using other SOA orchestration (BPM/BPEL) and ESB tools 1/27/09 3 CMIS WSDL and Schemas

    4. WebSphere Issues WebSphere’s WID product does holistic cross-schema and cross-WSDL analysis of all the artifacts in a project space. A particular schema element cannot be defined more than once in the same namespace. This behavior is consistent with best practices for SOAP. 1/27/09 4 CMIS WSDL and Schemas

    5. Duplicate-Definitions Solution Commonly solved by: Using a separate namespace per Schema/WSDL file Defining elements that are used in multiple services once and importing their definitions were needed Note that this issue is not restricted to WID. Standard Service Data Objects (SDOs) generate a factory class per artifact file using the namespace to define both the factory package and factory name. Having multiple schema files with the same namespace is a major problem with SDOs. 1/27/09 5 CMIS WSDL and Schemas

    6. Platform Adoption Issues Various vendor stacks absorb standards at different times. While MTOM has been available for several years as a potential replacement for SWA and DIME, it was only adopted for WebSphere Application Server (WAS) last year, and is not yet directly supported by WebSphere Process Server (WPS) or WebSphere ESB (WESB). Thus, MTOM is currently supported within the IBM stack for Point-to-Point services (SOA-Lite), but not for full mediated (ESB) or orchestrated (BPM/BPEL) SOA environments. 1/27/09 6 CMIS WSDL and Schemas

    7. MTOM Solutions One can develop an SOA SCA “Adapter” component for WESB that parses and assembles MTOM streams. CMIS could support multiple mechanisms to transfer the “content stream” via SOAP: xsd:binhex64 – base-64 inline encoding of content within XML Content-stream representation in SOAP message as a URL to a (temporary) persistence store 1/27/09 7 CMIS WSDL and Schemas

    8. Content Stream via binhex64 An Schema definition type of xsd:binhex64 will encode a byte array using base-64 character encoding Not as efficient as MTOM for large files Usually a good choice for small files since the content doesn’t need to be written to a temporary file and accessed later from secondary storage when needed 1/27/09 8 CMIS WSDL and Schemas

    9. Content Steams via URL (within SOAP) Supporting a URL reference within the SOAP message is a powerful option It allows the message to be very small. It provides a crisp transformed-message option when stripping off the MTOM attachments. It is consistent with HTML/XHTML whereby all content files are referenced by URLs within XML. It is consistent with WebDAV where various methods (e.g. PROPFIND) return XML including document URLs URLs within SOAP should be available for both sets and gets of Content Streams. 1/27/09 9 CMIS WSDL and Schemas

    10. A Content Stream Side-Issue The name “Content Stream” is an overload of the C/Java/.Net/Unix concept of a “stream” Most developers expect a stream object to support APIs like read, write, close, mark/reset Could we call the bytes simply “Content” and have CMIS services support “getContent” and “setContent” operations? Then a program could open a stream on the Content to process the document, and we could refer to the ContentSize and the ContentType… 1/27/09 CMIS WSDL and Schemas 10

    11. Other WSDL Issues If other transports beyond HTTP are to be eventually supported, then each WSDL file should be split into two files: Base file with interface Transport binding file for each protocol (e.g. one for HTTP and another for JMS) The binding file references the first file (includes). As new protocols are added, the first file containing the interface definition does not change. 1/27/09 11 CMIS WSDL and Schemas

    12. Schema Issues Too many modeled faults Opportunity to simplify properties Recommend against use of “qualified” Opportunity for collections of objects Naming- and construction-consistency opportunities 1/27/09 12 CMIS WSDL and Schemas

    13. Fault Simplification Modeled WSDL (SOAP) faults were designed to provide a mechanism to return specific structured data elements to the invoker. There is no need to have multiple faults returning the same structure. Major persistence and messaging frameworks have only one primary Exception (Fault) message, such as SQL, MQ, etc. Recommend adopting a single ContentManagement fault to replace the current multiple faults. This new fault would contain a “type code” to indicate the cause. This would substantially simplify consumer programming by reducing the number of “catch” structures for these faults. The 0.5 draft calls these “Exceptions” – but they are actually SOAP or WSDL “Faults” (which perhaps resulted from a .NET or Java Exception). 1/27/09 13 CMIS WSDL and Schemas

    14. Properties Opportunities Properties Simplify duplicate strongly typed elements. Eliminate (apparently) redundant sequencing index attribute. Eliminate confusing multiple-typed Value element. Need to clarify when strong-typing is required or is simply optional. Eliminate duplicate cmisPropertyType attribute when element name is already strongly typed Define additional standard optional properties (MD5) 1/27/09 14 CMIS WSDL and Schemas

    15. Property Definition Example 0.5 <!-- start the prop definitions --> <xs:complexType name="cmisProperty"> <xs:attribute ref="cmis:name" use="required" /> <xs:attribute ref="cmis:index" use="optional" /> <xs:attributeGroup ref="cmis:cmisUndefinedAttribute" /> </xs:complexType> <xs:complexType name="cmisPropertyBoolean"> <xs:complexContent> <xs:extension base="cmis:cmisProperty"> <xs:sequence> <xs:element minOccurs="0" name="value" type="xs:boolean" /> </xs:sequence> <xs:attribute ref="cmis:propertyType" use="optional" default="boolean" /> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="cmisPropertyInteger"> <xs:complexContent> <xs:extension base="cmis:cmisProperty"> <xs:sequence> <xs:element minOccurs="0" name="value" type="xs:integer" /> </xs:sequence> <xs:attribute ref="cmis:propertyType" use="optional" default="integer" /> </xs:extension> </xs:complexContent> </xs:complexType> 1/27/09 CMIS WSDL and Schemas 15

    16. Can we simplify all this? Simplified XSD: <xs:element name=”propertyInteger”> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:integer"> <xs:attribute name=”name" type="xs:string" /> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> Example: <propertyInteger name=“AccountId”>12345</propertyInteger>  <propertyInteger name=“AccountId”>00789</propertyInteger> 1/27/09 CMIS WSDL and Schemas 16

    17. Qualified in XSD Specifying elementFormDefault="qualified” causes all message elements to be prefixed with a namespace id “<bons5:folderid> vs. <folderid> This adds substantial bulk to the messages and reduces readability. There are various academic arguments for prefixing every element, but few practical examples. By observation, the WebSphere integration tools do not use qualified elements by default, nor do they provide an UI option to turn on qualified. 1/27/09 17 CMIS WSDL and Schemas

    18. Collections of Objects Using collections as service arguments avoids repetitious service requests. Generally implementing collections is a simple programming task to perform iterations. Recommend we support more collections of request arguments to support batches of objects being stored or retrieved via capture systems or as parts of compound documents (e.g. setContent operation with multiple independent Content Streams) Enlarged unit-of-work semantics would need to be discussed. 1/27/09 18 CMIS WSDL and Schemas

    19. Consistency Opportunities Files and enumerations do not use upper-, lower-, and upper/lower camel-case and separators (dashes) consistently Schemas do not make consistent (or effective) use of default values (e.g. minOccurs=1 and maxOccurs=1) We should revisit “nillable” to see if usages are appropriate given the added complexity:  <xs:element name="filter" type="xs:string" minOccurs="0" maxOccurs="1" nillable="true" /> Here filter is an optional XML element. Do we actually need to differentiate an empty string value <filer></filter> from filter having a “null” value : </filter xsi:null=“true”> since the entire element can be omitted if not needed. 1/27/09 19 CMIS WSDL and Schemas

    20. Next Steps Have discussions to better understand considerations used in original 0.5 spec. Need small WSDL and Schemas working group to provide recommendations for the larger TC committee. 1/27/09 20 CMIS WSDL and Schemas

More Related