1 / 19

On message/part/(@type|@element) and use=document|rpc, style=literal|encoded A personal opinion

On message/part/(@type|@element) and use=document|rpc, style=literal|encoded A personal opinion. Sanjiva Weerawarana IBM Research September 9-11, 2002. WSDL WG F2F. Outline. Understanding WSDL 1.1’s design SOAP 1.2 and XSD realities What can we do for WDL 1.2?. WSDL 1.1 <message>.

kylia
Download Presentation

On message/part/(@type|@element) and use=document|rpc, style=literal|encoded A personal opinion

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. On message/part/(@type|@element) and use=document|rpc, style=literal|encodedA personal opinion Sanjiva Weerawarana IBM Research September 9-11, 2002. WSDL WG F2F

  2. Outline • Understanding WSDL 1.1’s design • SOAP 1.2 and XSD realities • What can we do for WDL 1.2?

  3. WSDL 1.1 <message> • Message is a collection of parts • The message is not a real thing by itself, but just a bag of things • Each part represents one “thing” to be sent or received • Don’t just think of RPC parameters – a medical record being sent to a doctor may consist of some XML document (contained in the SOAP envelope) and lots of other stuff like XRay images etc. as attachments. Each such thing would be modeled as a part. • In other scenarios it may be multiple XML documents or elements from different namespaces (purchase order + vcard)

  4. <message> cont. • Alternate syntax may have made this clearer: • <portType name=“..”> • <operation name=“..”> • <input name=“..” type|element=…>* • <output name=“..” type|element=…>* • </operation> • </portType>

  5. Defining a part • XSD lets you define one of: • Named, complex type • An element, where the element is typed by pointing to a named complex type or by defining an anonymous type just for that • (Consider just global types and elements for now) • (Ignoring attributes and model groups for now) • XSD also provides a set of built-in types • WSDL 1.1 lets you point to named types (type=) or named elements (element=)

  6. WSDL 1.1 SOAP binding • <soap:body> is what defines how the body is built • If a part is described using type=, then one needs a way to generate an XML element out of it • Basically, some mechanism to do the equivalent of an XSD global element declaration needed • In SOAP RPC case, SOAP RPC rules tell you how to make those into elements • Name based based on part name • Content based on encoded or not • In other cases, no mechanism given • If a part is described using element=, then the XML element is given

  7. WSDL 1.1 SOAP binding (cont.) • Works ok for element case • But for use=literal, type=: • Says the type is the type of <soap:Body> and not the part itself for doc style • There can be only one part

  8. Outline • Understanding WSDL 1.1’s design • SOAP 1.2 and XSD realities • What can we do for WDL 1.2?

  9. Block1 Block2 Blockn Header Envelope Element1 Element2 Elementn Body SOAP 1.2 Data Model

  10. Block1 Block2 Blockn Header Envelope Element1 Element2 Elementn Body SOAP 1.2 DM with Attachments “Outer” Package SOAP Envelope Other stuff

  11. SOAP 1.2 Data Model Realities • A SOAP message has more than one thing in it: • 0 or more header blocks • 0 or more elements in the body • 0 or more related stuff in the outer package

  12. XSD Realities • You can define either a • Named, complex type, or • An element, where the element is typed by pointing to a named complex type or by defining an anonymous type just for that • XSD also provides a set of built-in types

  13. Outline • Understanding WSDL 1.1’s design • SOAP 1.2 and XSD realities • What can we do for WDL 1.2?

  14. WSDL 1.2 Possibilities: Message • Even if we only concentrate on SOAP, there’s more than one thing in a “message” • I don’t believe it makes sense to model the collection of things as a complexType or a global element declaration • We can improve the syntax: not use an explicit message declaration, but do the anonymous equivalent (see previous chart on possible alternate syntax)

  15. WSDL 1.2 Possibilities: Parts and XSD • XSD has both named types and named elements • Suppose we only support named elements: • What about the http binding? • What about other non-XML bindings • Suppose we only support named types: • Equivalent of global element declaration would be needed to actually generate XML out of it

  16. Non-XML type systems • MIME, in particular • DIME-like URI identifiers for types • Other more radical ones like java:foo

  17. On style=document/RPC • RPC style is a way to let the WSDL processor generate the contents of <soap:Body> • Two options: • Indicate that SOAP RPC rules are to be used • Say that one should apply the rules first, generate the XSDs and then say that document is to be sent/received • I compare that to describing the stack frame

  18. On use=literal/encoded • If WS-I’s going with literal then let’s forget about use=encoded (yes and drop the use attribute) • As Arthur has mentioned several times, the encodingStyle concept is useful as a way to indicate how the schema was derived • Should be a characteristic of the part definition instead of the SOAP binding only • That will allow the language binding to do the right thing

  19. Conclusions • None really – its up to us to decide on subjective positions to take

More Related