1 / 13

WSRP Description and Transport Issues SC

WSRP Description and Transport Issues SC. wsrp-webservice@lists.oasis-open.org Andre Kramer, Citrix Systems Inc. 6 th WSRP F2F, Grenoble, France 12 th -14 th May, 2003. Proposed Charter. Responsible for mapping WSRP operations and types (new factors?) to WSDL

venus
Download Presentation

WSRP Description and Transport Issues SC

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. WSRP Description and Transport Issues SC wsrp-webservice@lists.oasis-open.org Andre Kramer, Citrix Systems Inc. 6th WSRP F2F, Grenoble, France 12th-14th May, 2003

  2. Proposed Charter • Responsible for mapping WSRP operations and types (new factors?) to WSDL • Determine binding to SOAP (and other transports!) • Evaluate our Web Service description and its impact on common Web Service Stacks • Leverage attachment mechanisms * • Facilitate WS/SOAP (WS Security) and transport security 2.0? • Investigate performance of WSRP? • Others ?

  3. Proposed Deliverables • WSDL service description • WSDL issue resolution recommendations • Standards coordination (WS-I.org) • WSRP WSDL Report (cf. 5th f2f Note) • Attachment mechanisms investigation • Application level security investigation? • My wish list 2.0: • interoperable, standards based WS security • defines consumer / producer trust relationship • communicates user identity and roles • digital sig, multi-hop, non-repudiation? • secure navigational state? • Others?

  4. Attachment Mechanisms • WSRP = XML and Markup = XML right? • So what’s the problem? • Almost all current HTML is not XML • Portlets produce Markup Fragments not Documents • Different character sets (SOAP message v.s. Markup) • Input (and Output) of binary Documents • Perceived performance problems with in-band binary

  5. Current in-band support • Encode markup as an xs:string • Encoded using XML character entities (&lt; etc) • Done automatically by Web Service Stacks • Some producers can use <![CDATA[ … ]]> • Encode “markup” as a xs:base64Binary • About x 1.3 • Done automatically by Web Service Stacks • Natural for binary documents (byte[] not String) • Future? Encode XML Markup as <any namespace="##other" /> • Needs better parsing support in Web Service Stacks • Could leverage HTML TIDY • Could be re-considered for 2.0

  6. Out-of-band • By reference (URLs, c.f. Portlet resources) • Via http (non SOAP binding for getMarkup) • Via multi-media protocol (SMIL, RTP, DIME) • Using various attachment mechanisms • SOAP Messages with Attachments (W3C Note 11 Dec 2000) • SOAP 1.2 Attachment Feature (W3C Working Draft 24 Sept 2002) • WS-Attachments 17 June 2002 (Microsoft, IBM) • “Proposed Infoset Addendum to SOAP Messages with Attachments” BEA/Microsoft/AT&T/SAP/Tibco/Cano/TBD, V 0.6 draft, 24 March 2003 • WS-I.org • has tabled attachments for Basic Profile (1.1) • Disclaimer: Citrix is not directly involved with these efforts

  7. Why have both? • In-band preserves XML Infoset • keeps XML-abilities • One tool set, one charset (UTF-8 ;-) • Canonical representation, digital signing • Multiple transports (WSDL bindings) • Tools and intermediate message processors see data • SOAP header data as well as body • Out-of-band may not buy much performance • Out-of-band builds on common practice • Multi-part MIME • Soap-with-Attachments (SwA) supported by JAXRPC • Natural for posting binary documents • cf. our UploadContext

  8. Claim: DIME today … • DIME (Internet-Draft) is a binary encapsulation protocol • binary packet headers • with len & type or URIs, MB/ME/CF bits • I.e. not XML! • Championed by Microsoft, IBM • Companion WS-Attachments IETF Internet-Draft • Microsoft WSE 1.0 [no streaming, WS-Routing header] • Apache Axis [support not scoped] • WSRP 1.0 • Only one “markup” returned or array of binary inputs • Can use DIME at the sub-WS level • Citrix prototype uses WSE 1.0 • Declares a “DIME” (read-only) registration property • Or can detect DIME Attachment at registration • Fishes for DIME attachments at runtime

  9. Soap-with-Attachments [SwA] • Simple • multipart/related content type (RFC2387) • MUST put the SOAP Envelope as first/root MIME part • MAY send additional MIME parts with root • Use URIs to id parts (receivers SHOULD consult parts) • JAX-RPC • WSDL1.1 has MIME extensions (Section 5) • Only for SOAP (multipart/related) in practice • (<mime:mimeXML part=“”/> is underspecified IMHO) • Not supported by all wsdl tools (or WS stacks) • <mime:context/> optionally types markup MIME format • How to leverage this in WSRP? “*/*” or MIME type specific wsdls? • WSDL 1.2?

  10. WS-Attachments • Specifies Compound SOAP structures • URIs reference parts • E.g. useful if WSRP had header & body markup parts • SOAP message + “attachments” in a DIME message • Does not have to be MIME • Maps to DIME records (application/soap+xml first) • HTTP binding (application/dime) • “WSDL Extensions for SOAP in DIME” • Microsoft DRAFT, 8 May 2002 • Moves base64Binary or hexBinary elements to DIME records • Location (URL) and type (MIME, URI or XML Doc element) • Layouts (closed-content, open-content) • WSDL: • Element app-info annotation <content:mediaType value=“text/html””/> • wsdl:input/output <dime:message layout=“auri” wsdl:required=“true”/> • SOAP • <… ref:location=“uuid:12DA3C9C-74D3-4446-B995-B150362D9413”> • Faults MAY be DIME encapsulated

  11. XML Infoset friendly proposals • Want binary to be directly included in message • XML does this when “in memory” today • Why not allow this on the wire too? [c.f. WAP] • Can convert to base64 as required • E.g. when digitally signing a document • XInclude-like mechanism to merge in data?

  12. New Infoset-friendly Proposal The “Proposed Infoset Addendum to SwA”: • Aligned with XML Infoset • Backwards compatible SwA message syntax • Alternative (in-band) message syntax for non-SwA processors • Converts between base64 in-band and SwA (or other) out-of-band • swa:MediaType attribute • Specifies MIME type of base64 element (when in-band) • xbinc:Include element • References out-of-band opaque data by URI (just a href) • Xbinc:DoInclude header controls processing • FatalIncludeFault SOAP fault • [swa:Representation header block • Allows sending along cached representations] • swa:Accept attribute • Annotates schema declarations (I.e. XML Schema in WSDL) • <xs:element name=“” type=“swa:Binary” swa:Accept=“image/jpeg image/gif”/>

  13. Recommendations? • Experiment with DIME, SwA, … • Wait for WS-I.org (1.1 including Attachments) • Canvas your WS-I.org representation! • Wait for WSDL extensions? • Wait for Infoset friendly SwA? • Support both in-band and out-of-band in 1.1/2.0 • Add negotiation to WSRP? • Keep xs:string & xs:base64Binary for interop

More Related