wsrp description and transport issues sc
DESCRIPTION
WSRP Description and Transport Issues SC. [email protected] 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 - PowerPoint PPT PresentationTRANSCRIPT
WSRP Description and Transport Issues SCWSRP Description and Transport Issues [email protected]
Andre Kramer, Citrix Systems Inc.
6th WSRP F2F, Grenoble, France
12th-14th May, 2003
Proposed CharterProposed 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 ?
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 ?
Proposed DeliverablesProposed 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?
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?
Attachment MechanismsAttachment 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
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
Current in-band supportCurrent in-band support
Encode markup as an xs:string– Encoded using XML character entities (< 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
Encode markup as an xs:string– Encoded using XML character entities (< 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
Out-of-bandOut-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
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
Why have both?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
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
Claim: DIME today …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
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
Soap-with-Attachments [SwA]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?
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?
WS-AttachmentsWS-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
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
XML Infoset friendly proposalsXML 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?
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?
New Infoset-friendly ProposalNew 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”/>
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”/>
Recommendations?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
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