1 / 24

WS - Attachment s

WS - Attachment s. Yavuz Gürcan SRDC. OUTLINE. Why do we need attachments? Limitations Requirements of WS-Attachments DIME Compound SOAP Message The Future of WS-Attachment MTOM Web Services Enhancements (WSE) 2.0 Attachment Approaches. Why do we need attachments? .

KeelyKia
Download Presentation

WS - Attachment s

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. WS-Attachments Yavuz Gürcan SRDC

  2. OUTLINE • Why do we need attachments? • Limitations • Requirements of WS-Attachments • DIME • Compound SOAP Message • The Future of WS-Attachment • MTOM • Web Services Enhancements (WSE) 2.0 • Attachment Approaches

  3. Why do we need attachments? • There are situations where we would not want to include the extra data within the original SOAP message • That might occur when the format of the extra data is unsuitable to conversion to XML, e.g., inefficient or bulky (as in media files, for example) • Advantages: • Smaller message size • Smaller memory requirements • Smaller processing time (no need to convert binary data to base-64) • Streaming

  4. Limitations • Encapsulation of binary data (in the form of image files etc.) cannot be done without additional encoding/decoding of the data. • Encapsulation of other XML documents as well as XML fragments is cumbersome within a SOAP message--especially if the XML parts do not use the same character encoding. • Although SOAP messages inherently are self-delimiting, the message delimiter can only be detected by parsing the complete message. • SOAP with Attachments (SwA) addresses 1 and 2 • DIME is faster than MIME!

  5. Requirements of WS-Attachments • It is important that the packaging system provide a mechanism for passing the different parts over a single stream • A packaging solution must have: • The ability to separate where one part of the package ends and the next part begins • It must have some mechanism for indicating when the package is complete • A definitive mechanism for identifying each part of a package • To be able to identify what kind of information is in each part of the package

  6. DIME - The Direct Internet Message Encapsulation • DIME is a packaging mechanism that allows multiple records of arbitrarily formatted data to be streamed together • Records are serialized into the stream one after the other and are delineated with an efficient binary header • The first record in a DIME message has the MB (Message Begin) flag set in the header and the last record has the ME (Message End) flag set • The header also includes a fixed length-portion that allows for the easy computation of the absolute length of the record

  7. DIME - Chunked records • For large records or records where the size of the data is not initially known, DIME has defined a "record chunk” • Each record chunk has a header and a payload like normal records do, however a record chunk sets the CF (Chunk Flag) in the header • This indicates that the data is part of a chunked record and more data for that record will follow • The data for the chunked record is read serially from the record chunks that follow until the last record chunk is determined when the CF is no longer set

  8. DIME - Chunked records

  9. DIME - Record Header • The DIME record header includes: • The version of DIME that is being used • Type of information about the data in the record's payload • An ID to uniquely identify each record, and • Support for adding any optional information that may be transmitted with a particular record

  10. Using DIME to Send a SOAP Message with Attachments • DIME by itself is simply a mechanism for packaging a collection of arbitrarily formatted records of data • It sets no requirements on the contents of record payloads, what is contained in the ID fields or how a SOAP message might be encapsulated in a DIME message

  11. SOAP and DIME • For SOAP messages with attachments, the main message is referred to as the "Primary SOAP Message Part“ • Any attached articles will be referred to as "Secondary Parts" • WS-Attachments indicates that the Primary SOAP Message Part must be contained in the first record of a DIME message

  12. SOAP and DIME

  13. DIME - Referencing the Attachments • WS-Attachments defines the use of the HREF attribute for making such a reference • The HREF attribute is a URI that can be used to point to an HTTP URL if so desired • But WS-Attachments also defines the ability to refer to a specific DIME record using the ID field of the DIME record header

  14. DIME - Example • If a secondary part of a DIME message had an ID of uuid:6FF57C24-74A1-426f-92D9-98861E105B4F then the primary SOAP message part that referenced such an attachment might be as follows: <?xml version='1.0' ?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mes="http://example.org/message/response"> <s:Body> <mes:responseMesssage> <responseTo href="uuid:6FF57C24-74A1-426f-92D9-98861E105B4F"/> <messageText>Hello World!</messageText> </mes:responseMessage> </s:Body> </s:Envelope>

  15. DIME - Example • The responseTo element in the message body has an HREF attribute that specifies the ID of the DIME record • Presumably the data in the DIME record is another SOAP message that this message responds to • The receiver of this DIME message will not need to track down the message that the primary SOAP Message Part responds to, they simply can find it in the specified secondary part of the DIME message

  16. Compound SOAP Message • WS-Attachments also define the details of how a compound SOAP message can be sent in an HTTP request • For the most part it is similar to simply sending the primary SOAP message part on its own, except that the HTTP Content-Type header must be set to "application/dime" and the body of the HTTP request is the DIME message instead of the SOAP message

  17. The Future of WS-Attachment • DIME is dead! ; ) • SOAP with attachments (multipart-mime, used by JAX-RPC 1.1), and some optimizations known as MTOM (first known as PASWA) won. • PASWA "Proposed Infoset Addendum to SOAP Messages with Attachments", April 2003.http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html • Limitation: There is no support for attachments when starting from Java. This is because for certain Java types to MIME type mapping METADATA support is needed. It will be supported in JAXRPC 2.0

  18. MTOM (Message Transmission Optimization Mechanism) • SOAP with Attachments and MTOM are based on MIME. • MTOM goes a step further by including attachments as part of the Infoset (since SOAP 1.2 is built around Infoset), thus making the SOAP 1.2 processing model applicable to the attachments as well. • MTOM is expected to be supported by JAXRPC 2.0 with SOAP 1.2 support. • W3C Working Draft 8 June 2004 http://www.w3.org/TR/2004/WD-soap12-mtom-20040608/

  19. Attachment Approaches • XML Representation: Replace any non-Xml data with a structured XML representation and include it in your message. • SOAP with Attachments (SwA): Use SOAP with Attachments to send binary data with your SOAP in a MIME Multipart message. • WS-Attachments with DIME: Use DIME and WS-Attachments to send binary data with your SOAP in a DIME message format. • Base 64 Encoding: Use base 64 encoding to include opaque data within your SOAP message • Message Transmission and Optimization Mechanism (MTOM): Use an MTOM approach to take advantage of the SOAP infrastructure, but gain the transport efficiencies provided by a SOAP with Attachments solution.

  20. XML Representation • Interoperability: Perfect • Composability: Excellent • Efficiency: Debatable • When to use: Whenever you can! <picture> <row> <pixel> <color>00FF00</color> </pixel> <pixel> <color>00FF00</color> …

  21. SOAP with Attachments (SwA) • Interoperability: Perfect • Composability: Poor (cannot support WS-Security) • Efficiency: Good • When to use: If you never want to interoperate with Microsoft platforms (.Net does not support SwA)

  22. WS-Attachments using DIME • Interoperability: Modest. Efforts for creating widely interoperable DIME and WS-Attachment implementations have stopped. As with SwA, there is no recommendation for DIME or WS-Attachments at this time. There are also no plans for standardizing DIME and WS-Attachments. Microsoft tools currently only support a DIME approach to attachments, but will be changing to support MTOM in the future. • Composability: Poor • Efficiency: Very Good (has support for efficiencies like chunking and jumping easily between message records) • When to use: Web services are all about interoperability, and if DIME and WS-Attachments does not provide wide interoperability. At this point the only real reason to be using DIME and WS-Attachments would be to interoperate with an existing DIME and WS-Attachment implementation.

  23. Base 64 Encoding • Interoperability: Excellent (Base-64-encoded data is understood on every platform that understands XML) • Composability: Excellent (As data lives within the SOAP envelope) • Efficiency: Modest (bloats the data by about 33%) • When to use: Base 64 encoding is probably the best way to pass opaque data if transport size efficiency is not your first concern

  24. Message Transmission Optimization Mechanism (MTOM) • Interoperability: Potentially great • Composability: Excellent • Efficiency: Excellent (Although the MIME Multipart data transfer isn't quite as efficient at transferring raw data as DIME, it can still transfer data without additional bloating) • When to use: You can probably expect to see MTOM implementations in the third quarter of 2004. Just be aware that you will probably need to rebuild with the latest technology at some point in the future.

More Related