IMS Logo

IMS General Web Services Attachments Profile

Version 1.0 Final Specification

Copyright © 2005 IMS Global Learning Consortium, Inc. All Rights Reserved.
The IMS Logo is a registered trademark of IMS/GLC
Document Name: IMS General Web Services Attachments Profile
Revision: 19 December 2005

IPR and Distribution Notices

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the specification set forth in this document, and to provide supporting documentation.

IMS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on IMS's procedures with respect to rights in IMS specifications can be found at the IMS Intellectual Property Rights web page: http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf.

Copyright ) 2005 IMS Global Learning Consortium. All Rights Reserved.

Permission is granted to all parties to use excerpts from this document as needed in producing requests for proposals.

Use of this specification to develop products or services is governed by the license with IMS found on the IMS website: http://www.imsglobal.org/license.html.

The limited permissions granted above are perpetual and will not be revoked by IMS or its successors or assigns.

THIS SPECIFICATION IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS SPECIFICATION SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE CONSORTIUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS SPECIFICATION.


Executive Summary

The General Web Service Base Profile provides a basic structure for the definition of Web Services used to realize IMS service-oriented specifications. It consists of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications that promote interoperability. The General Web Services Base Profile addresses the most common problems experienced when implementing web service specifications. The General Web Services Base Profile defines the selection of mechanisms within referenced specifications that are well understood, widely implemented and useful.

The General Web Services Base Profile promotes interoperability across web specifications implementations on different software and vendor platforms. The Base Profile focuses on a core set of web service specifications and the most common problems experienced implementing the identified web service specifications. It is not a goal of the General Web Services Base Profile to create a plug-and-play architecture for web services or to guarantee complete interoperability. The General Web Services Base Profile addresses interoperability in the application layer, in particular, the description of behaviors exposed via Web Services.

The IMS GWS Attachments Profile extends the IMS GWS Base Profile to allow the exchange of non-XML information in the SOAP messages. The Attachments Profile defines the usage of the Message Transmission Optimization Mechanism (MTOM) to attach the non-XML content to the SOAP messages. MTOM uses the XML-binary Optimized Packaging (XOP) mechanism to improve the encoding efficiency possible with SOAP with Attachments.

Table of Contents


Executive Summary

1. Introduction
1.1 Scope and Context
1.2 Structure of this Document
1.3 Nomenclature
1.4 References

2. Attachments Framework
2.1 Message Transmission Optimization Mechanism (MTOM)
2.2 Attachment Processing Workflow

3. Attachments Profile Rules

4. WSDL Binding Implications

5. Relationship to the Other GWS Profiles

6. Extending the Attachments Profile
6.1 Proprietary Extensions
6.2 Further Work in V2.0

7. Conformance to the Attachments Profile

Appendix A - Glossary of Terms

About This Document
List of Contributors

Revision History

Index


1. Introduction

1.1 Scope and Context

The IMS General Web Services (GWS) Base Profile (GWSBP) [GWS, 05a] provides a basic structure for the definition of Web Services. It consists of a set of non-proprietary Web Services specifications, along with clarifications and amendments to those specifications that promote interoperability. The IMS GWS Base Profile addresses the most common problems experienced implementing web service specifications. The IMS GWS Base Profile defines the selection of mechanisms within referenced specifications that are well understood, widely implemented and useful.

The IMS GWS Attachments Profile extends the IMS GWS Base Profile to allow the exchange of non-XML information in the SOAP messages. The Attachments Profile defines the usage of the Message Transmission Optimization Mechanism (MTOM) to attach the non-XML content to the SOAP messages. MTOM uses the XML-binary Optimized Packaging (XOP) mechanism to improve the encoding efficiency possible with SOAP with Attachments.

1.2 Structure of this Document

The structure of this document is:

2. Attachments Framework Establishes the framework for the operation of IMS web services that use SOAP message attachments to send non-XML data. This explains the usage of MTOM;
3. Attachment Profile Rules The statement of the profile rules that must be followed to enable the IMS Base Profile to be extended to send non-XML data using the MTOM/XOP approach;
4. WSDL Binding Implications An explanation of the implications of the Attachment Profile rules on the IMS specification development methodology (using the IMS Auto-generation Binding Toolkit) and the WSDL binding that are created;
5. Relationship to the Other IMS GWS Profiles Describes the relationships and dependencies between this profile and the other IMS GWS profiles;
6. Extending the Attachments Profile A brief discussion of the ways in which the Attachments Profile can be extended to support proprietary requirements and an indication of future development for this profile;
7. Conformance to the Attachments Profile An explanation of how conformance for systems that use the Attachments Profile can be demonstrated;
Appendix A Glossary of Terms Definition of the concepts, terms and technologies used within this document. This material complements the Abstract Framework Glossary.

1.3 Nomenclature

GWSBP General Web Services Base Profile
HTTP Hypertext Transport Protocol
IAF IMS Abstract Framework
I-BAT IMS Auto-generation Binding Toolkit
MIME Multipurpose Internet Mail Extensions
MTOM Message Transmission Optimization Mechanism
RRSHB Resource Representation SOAP Header Block
SOAP Simple Object Access Protocol
SWA SOAP with Attachment
TCP Transmission Control Protocol
UML Unified Modelling Language
URI Universal Resource Identifier
URL Universal Resource Locator
W3C World Wide Web Consortium
WSDL Web Services Description Language
WS-I Web Services Interoperability Organization
XML Extensible Mark-up Language
XOP XML-binary Optimized Packaging
XSD XML Schema Definition
XSLT Extensible Stylesheet Language Transformations

1.4 References

[AbsGloss, 03] IMS Abstract Framework: Glossary v1.0, Ed. C.Smythe, IMS/GLC, July 2003.
[GWS, 05a] IMS General Web Services Base Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS/GLC, December 2005.
[GWS, 05b] IMS General Web Services WSDL Binding Guidelines Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS/GLC, December 2005.
[GWS, 05c] IMS Binding Auto-generation Toolkit Manual, C.Smythe, V1.0 IMS/GLC, December 2005.
[MTOM, 05] SOAP Message Transmission Optimization Mechanism, M.Gudgin, N.Mendelsohn, M.Nottingham and H.Ruellan, W3C Recommendation, http://www.w3.org/TR/soap12-mtom/, January 2005.
[RFC2119, 97] RFC 2119: Key words for use in RFC to Indicate Requirement Levels, S.Bradner, IETF, March 1997.
[RRSHB, 05] Resource Representation SOAP header Block, A.Karmarkar, M.Gudgin and Y.Lafon, W3C Recommendation, http://www.w3.org/TR/soap12-rep/, January 2005.
[XOP, 05] XML-binary Optimized Packaging, M.Gudgin, N.Mendelsohn, M.Nottingham and H.Ruellan, W3C Recommendation, http://www.w3.org/TR/xop10/, January 2005.

2. Attachments Framework

2.1 Message Transmission Optimization Mechanism (MTOM)

The IMS GWS Attachments Framework is based upon the MTOM standard under development by W3C [MTOM, 05]. MTOM combines the composition capability of Base 64 encoding with the transport efficiency of SOAP with Attachments (SWA). Non-XML data is processed just as it is with SWA - the data is simply streamed as binary data in one of the MIME message parts. MTOM is composed of three distinct specifications:

  1. SOAP Message Transmission Optimization Mechanism [MTOM, 05] - this describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message by selectively encoding portions of the message, while still presenting an XML Infoset to the SOAP application. Use of the Abstract SOAP Transmission Optimization Feature is a hop-by-hop contract between a SOAP node and the next SOAP node in the SOAP message path, providing no mandatory convention for optimization of SOAP transmission through intermediaries;
  2. XML-binary Optimized Packaging [XOP, 05] - this specifies the method for serializing XML Infosets with non-XML content into MIME packages. XOP provides an alternate serialization that is fully compatible with a MIME package, including an XML document as the root portion of the package. XOP streams the non-XML attachment as one of the MIME message parts. The MIME attachment is processed and temporarily treated as base-64 encoded text immediately prior to serialization of the message. For example, a WS-Security layer creating a digital signature would use the non-XML data to calculate the signature by streaming it through a base-64-encoding layer. The base-64-encoded data is temporary, used only for creating the signature (it is never actually transferred, stored or serialized anywhere). During deserialization the processing layers that access the attachment would do so through the base-64-encoding layer (again, this is a temporary representation that occurs just before serialization);
  3. The Resource Representation SOAP Header Block specification [RRSHB, 05] - this defines a SOAP header block that can carry resource representations within SOAP messages. The Representation Header Block is designed to be used when the receiver has limited ability to retrieve the resource (due to access restrictions or unreasonable overhead processing due to the size of the resource to be retrieved). The RRSHB can also be used when multiple references to the same resource are required but duplication of the resource is undesirable. The example below illustrates a sample application of the RRSHB. The referenced Content Package is attached as a MIME part and the (simulated) base-64 encoded value was generated during Infoset processing (as mentioned above).

MTOM was selected in preference to SWA for two reasons:

  1. SWA defines a way for binding attachments to a SOAP envelope using the multipart/related MIME type - this is the same attachment/encapsulation mechanism used for e-mail. MIME is inefficient because it uses text strings to delineate boundaries between parts. Consumers must scan the entire message to find the string value used to delineate a boundary;
  2. MIME cannot be represented as an XML Infoset - this effectively breaks the Web Services model since attachments cannot be secured using WS-Security.

MTOM provides a compromise between the MIME model and the Web Services model, combining an efficient encoding mechanism (saving 25% over a traditional binary model) and an infoset representation (the overall package can be processed like a regular SOAP message). MTOM messages are valid SWA messages, lowering the effort of implementing MTOM for existing SWA implementations. MTOM attachments are streamed as binary data within a MIME message part, making it simple to interoperate with other SWA implementations.

2.2 Attachment Processing Workflow

The key terms used in the description of the work-flow are defined in Table 2.1.

Table 2.1 Key terms for the workflow description.

Term Definition
ENDPOINT An entity, processor, or resource that can be referenced and where Web Service messages are originated or targeted.
INITIATOR An application that consumes a Web Service by sending SOAP messages and attachments to a RESPONDENT.
RESPONDENT An application that exposes a Web Service and performs processing upon receiving SOAP messages and attachments from an INITIATOR.
MESSAGE An IMS message encapsulated within a SOAP envelope as referenced in the [GWS, 05b]
SOURCE The ENDPOINT that transmits the MESSAGE to the RESPONDENT
DESTINATION The ENDPOINT that receives messages from the INITIATOR.
ATTACHMENT The non-XML resource that is attached to the MESSAGE based upon the guidance provided by this profile.

Note that INITIATOR and RESPONDENT as intended throughout the rest of the document, are at a different level of abstraction compared to SOURCE and DESTINATION, the former belong to the application layer, while the latter belong to the messaging infrastructure layer and provide services to INITIATORS and RESPONDENTS (see Figure 2.1).

Schematic representation of the web service support for an application
Figure 2.1 Schematic representation of the web service support for an application.

The following is a step-by-step breakdown of a typical workflow for exchanging IMS MESSAGES and ATTACHMENTS. This workflow represents a common sequence of tasks. As a result, this workflow is intended to outline the pertinent tasks and is not prescriptive as to the sequence of fine-grained steps:

  1. INITIATOR constructs IMS MESSAGE according to the relevant IMS specification and the WSDL binding guidelines [GWS, 05b];
  2. INITIATOR identifies ATTACHMENT (or ATTACHMENTs) to be sent with the IMS MESSAGE;
  3. The Web Services Messaging Adapter within the INITIATOR:-
    • Encapsulates the IMS MESSAGE in the body of the SOAP message
    • Attaches ATTACHMENT (or ATTACHMENTs) using MTOM
    • Passes the IMS MESSAGE and ATTACHMENT (or ATTACHMENTs) to SOURCE;
  4. SOURCE transmits the IMS MESSAGE through the transport;
  5. IMS MESSAGE is transferred to the DESTINATION;
  6. DESTINATION gets the IMS MESSAGE from the transport;
  7. The Web Services Messaging Adapter within the RESPONDENT:-
    • Decodes and detaches all ATTACHMENTs attached to the message
    • Passes a receipt/response message to the INITIATOR
    • RESPONDENT extracts, validates and processes the IMS MESSAGE and ATTACHMENT (or ATTACHMENTs).

3. Attachments Profile Rules

Table 3.1 summarizes the set of rules used for the Attachments Profile. Within Table 3.1 the following conventions are used:

  • The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119;
  • Normative statements in the Profile are presented in the following manner: RATPnnnnStatement text here, where "nnnn" is replaced by the statement number. Each statement contains exactly one requirement level keyword, e.g., "MUST", and one conformance target keyword, e.g., "MESSAGE".
Table 3.1 Summary of the IMS GWS Attachments Profile rules.

Identifier Description
Basic Attachment
RATP0001

IMS-compliant Web Services SHOULD use MTOM for attaching non-XML data to SOAP messages.

IMS Web Services should avoid using SOAP with Attachments (SWA) because it is incompatible with the Web Services model. For example, SWA does not work with WS-Security, making it difficult to secure attachments or establish trust boundaries that span multiple organizations. Due to this fundamental problem, the W3C has decided to move away from SWA and adopt MTOM as the sole recommendation for attaching non-XML resources to SOAP messages.

RATP0002

IMS-compliant Web Services receiving an MTOM attachment will need to buffer the XML portion of the message.

If the non-XML portions of the message are not in the same order as they are referenced in the XML portion additional buffering may be required.

RATP0003

IMS-compliant Web Services supporting SOAP 1.1 will not use the Resource Representation SOAP Header Block mechanism.

The RRSHB was created for usage with SOAP v1.2. The IMS Base Profile [GWS, 05} stipulates the usage of SOAP v1.1.

XML-binary Optimized Packaging
RATP2001

The XOP namespace attribute (xmlns:xop=http://www.w3.org/2004/08/xop/include) must be used on the SOAP envelop element. The usage of the prefix 'xop' is not mandatory.

This ensures that the attachment can be identified using the XOP <Include> element.

RATP2002

Each data element that is used to identify to an attachment must use the 'contentType' attribute to identify the MIME-type of the attachment.

This enables the XOP/MIME processing to decode the attachment content. An example of this statement is:

<ns1:data xmlmime:contentType="image/jpeg">
   ...
</ns1>

RATP2003

Each data element that is used to identify an attachment must use the empty XOP <Include> element with the filled 'href' attribute to identify the attachment in the attached MIME parts. The 'href' value must be a valid URI per the 'cid:URI' scheme.

The <Include> element is used to allocate a unique identifier to the attached document contained in the MIME encoding. An example of this statement is:

<ns1:data xmlmime:contentType="image/jpeg">
   <xop:Include href=cid:thismessage:/resource1.jpg/>
</ns1>
MIME Encoding
RATP4001

The MIME namespace attribute (xmlns:xmlmime="http://www.w3.org/2004/06/xmlmime) must be used on the SOAP envelop element. The usage of the prefix 'xmlmime' is not mandatory.

This enables the mime type of the attachment to be defined.

RATP4002

When an attachment is present then the 'Content-type' field for the MIME boundary encoding must be set as:
Content-Type: application/xop+xml;charset=UTF-8;type="application/soap+xml"

This is used by the decoders to identify that the SOAP message has an XOP attachment to the SOAP message.

RATP4003

For each attachment the MIME Boundary 'Content-ID' information must be the identifier assigned in the corresponding XOP <Include> element (see RAPT2003).

This is used to enable the attachment to be uniquely identified. An example of this statement is:

Content-ID: <thismessage:/resource1.jpeg>

RATP4004

For each attachment the MIME Boundary 'Content-Type' information must be the MIME-type assigned to the data element (see RATP2002).

This is used to identify the MIME-type of the attached material. An example of this statement is:

Content-Type: image/jpeg

RATP4005

For each attachment the MIME Boundary 'Content-Transfer-Encoding' information must be the set to 'binary'.

This is used to identify the encoding of the attachment in the MIME-part. An example of this statement is:

Content-Transfer-Encoding: binary

Security Encodings
RATP6004

IMS-compliant Web Services MUST use the Base-64 form of the non-XML attachment to calculate digests for security.

MTOM serializes non-XML data as raw octets. Octets are not the same as base-64 and must be converted to a base-64 representation prior to digest computation.

RATP0005

IMS-compliant Web Services MUST use the Base-64 form of the non-XML attachment for encryption.

MTOM serializes non-XML data as raw octets. Octets are not the same as base-64 and must be converted to a base-64 representation prior to encryption. The cipher data produced by the encryption is then serialized into octets for transmission.

RATP0006

IMS-compliant Web Services SHOULD use simple base-64 encoding for IMS Attachments until a production-quality MTOM implementation is available.

Base-64-encoded data is usually more efficient than structured XML. Base-64 encoding is the best way to pass non-XML data until vendors begin shipping full support for MTOM. Base-64 encoding is fully compliant with Advanced Web Services and provides a highly efficient mechanism for XML encoding. Several development platforms (such as .NET) make it relatively easy to serialize byte arrays into base-64-encoded elements - this enables non-XML data to be transferred to a web service as a byte array parameter.

4. WSDL Binding Implications

The usage of MTOM requires the following information to supplied as part of the specification process:

  • Each parameter (input or output) that is used to reference an attached data object must be identified. More than one attachment can be sent or received during each message exchange;
  • The MIME-type of the attachment must be supplied;
  • The URL for where the document that is to be attached can be located;
  • The value for the <Include href="..."> element for the XOP processor is derived as a combination of the parameter name and the MIME-type. This value is a URI for the material in the MIME parts and not an external URL.

From the perspective of the WSDL 1.1 the attachment information is presented in the XSD definition part of the file. The transformation files in the IMS Auto-generation Toolkit (I-BAT) [I-BAT, 05] use the information supplied in the UML description as described in Table 4.1. In Table 4.1 each attribute has an example value and for each set of values there follows the corresponding WSDL file.

Table 4.1 Synchronous single file auto-generation including the Attachments Profile.

Attribute Original Value
ServiceGroupModel Attributes
Service Group Package Name ExampleGroup
WSDLv1.1:NameSpaceRoot http://www.example/services/
WSDLv1.1:TargetNameSpaceLeaf wsdlfilev1p0
WSDLv1.1:TargetNameSpacePrefix tns
WSDLv1.1:AbstractFileNameSpaceLeaf Unused
WSDLv1.1:AbstractFileNameSpacePrefix Unused
WSDLv1.1:XSDLinkNameSpaceLeaf Unused
WSDLv1.1:XSDLinkNameSpacePrefix Unused
WSDLv1.1:MessageHdrNameSpaceLeaf Unused
WSDLv1.1:MessageHdrNameSpacePrefix Unused
<wsdl11:definitions name = "ExampleGroupSyncServices" 
   targetNamespace = "http://www.example/services/wsdl/sync/wsdlfilev1p0" 
   xmlns:tns = "http://ww.example/services/wsdl/sync/wsdlfilev1p0"
   xmlns:soap11 ="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:wsdl11 ="http://schemas.xmlsoap.org/wsdl/" 
   xmlns:xs = "http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi = "http://www.w3.org/2000/10/XMLSchema-instance">
ServiceModel Attributes
Service Package Name EgServiceName
SOAPv1.1:AddressLocationRoot http://www.example.soap/serviceuri/
SOAPv1.1:OperationActionRoot http://www.example/soap/service/
<wsdl11:service name = "EgServiceNameSyncService">
   <wsdl11:port name = "CoreOperationsNameSyncSoapPort" binding = "...">
      <soap11:address 
         location="http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap/"/>
   </wsdl11:port>
</wsdl11:service>
Interface Attributes
Interface Name CoreOperationsName
createObject (myData:AttachmentJpeg)
<wsdl11:binding name="CoreOperationsNameSyncSoapBinding" 
          type="tns: CoreOperationsNameSyncPortType">
   <soap11:binding transport="http://schema.xmlsoap.org/soap/http" style="document"/>
   <wsdl11:operation name="createObject">
      <soap11:operation soapAction="http://www.example/soap/service/createObject" 
         style="document"/>
      ...
   </wsdl11:operation>
</wsdl11:binding>
<wsdl11:service name = "EgServiceNameSyncService">
   <wsdl11:port name = "CoreOperationsNameSyncSoapPort" 
            binding = "tns:CoreOperationsNameSyncSoapBinding">
      <soap11:address 
         location="http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap/"/>
   </wsdl11:port>
</wsdl11:service>
DataModel Attributes
NameSpaceRoot Unused
NameSpaceLeaf Unused
NameSpacePrefix Unused
SchemaVersion IMS 1.0
QualifiedElements Yes
QualifiedAttributes No
<wsdl11:types>
   <xs:schema xmlns="http://www.w3.org/2001/XMLSchema"
      targetNamespace="http://www.example/services/wsdl/sync/wsdlfilev1p0"
      xmlns:xsd=http://www.w3.org/2001/XMLSchema
      xmlns:xsi=http://www.w3.org/2000/10/XMLSchema-instance
      xmlns:xmlmime="http://www.w3.org/2004/06/xmlmime"
      version="IMS 1.0"
      elementFormDefault="qualified"
      attributeFormDefault="unqualified">

      <xs:import namespace='http://www.w3.org/2004/06/xmlmime' />

      <xs:element name='myData' >
         <xs:complexType>
              <xs:simpleContent>
               <xs:extension base='xs:base64Binary' >
                    <xs:attribute ref="xmlmime:contentType" />
               </xs:extension>
              </xs:simpleContent>
         </xs:complexType>
        </xs:element>

   </xs:schema>
</wsdl11:types>

5. Relationship to the Other GWS Profiles

The relationship of the Attachments Profile to the other IMS GWS profiles is shown in Figure 5.1.

Relationship between the Attachments Profile and the other IMS GWS Profiles
Figure 5.1 Relationship between the Attachments Profile and the other IMS GWS Profiles.

The Attachments Profile assumes that the Base Profile is already being used [GWS, 05a]. This is the only dependency with other IMS GWS profiles.

When the Security Profile is being used there are implications for how some of the attachment related information is encoded. These implications are defined in the profiles rules in Section 3.

6. Extending the Attachments Profile

6.1 Proprietary Extensions

Extensions of the Attachments Profile are NOT recommended. This is because the use of MTOM with WSDL v1.1 is unstable in terms of tool support and completion of the W3C standard. The MTOM is a candidate recommendation and not a full standard.

6.2 Further Work in V2.0

In IMS GWS v2.0 limited further work will be undertaken to ensure the compatibility of supporting MTOM with WSDL v1.1. The rest of the work will focus on the usage of MTOM with SOAP v1.2 and WSDL v2.0.

7. Conformance to the Attachments Profile

Any claim of conformance for an implementation against the Attachments Profile must show that the implementation complies with the set of profile rules listed in Section 3.

Apart from the WS-I Conformance Claims mechanism, the W3C is investigating the usage of WS-Policy. Therefore, no definitive recommendation is made on the usage of the WS-I approach. More information on the WS-I Conformance Claim mechanism is given in the IMS GWS WSDL Binding Guidelines document [GWS, 05b]. However, if some form of conformance statement is required then the WS-I approach may be used but no firm commitment is made to supporting this technique in later releases of the IMS GWS specification.

Appendix A - Glossary of Terms

Throughout the General Web Services documents a variety of key terms, concepts and descriptions have been introduced. These terms, concepts and descriptions and defined below but where appropriate the normative definition from the IAF Glossary is referenced [AbsGloss, 03].

Attachment The non-XML resource that is attached to the Message based upon the guidance provided by this profile.
Destination The Endpoint that receives messages from the Initiator.
Endpoint An entity, processor, or resource that can be referenced and where Web Service messages are originated or targeted.
Initiator An application that consumes a Web Service by sending SOAP messages and attachments to a Respondent.
Message An IMS message encapsulated within a SOAP envelope as defined by the corresponding IMS specification and the WSDL binding rules.
Message Transmission Optimization Mechanism (MTOM) MTOM is one of the W3C message attachment approaches to enable SOAP messages to contain non-XML objects. MTOM is a development of SOAP with Attachments and is recommended in this profile as a replacement for the original SWA specification. Apart from the core specification, MTOM is also based upon the XML-binary Optimized Packaging (XOP) and the Resource Representation SOAP Header Block specifications.
Resource Representation SOAP Header Block (RRSHB) The Resource Representation SOAP Header Block specification describes the semantics and serialization of a SOAP header block for carrying resource representations in SOAP messages. The RRSHB is designed to allow applications to carry a representation of a Web resource in a SOAP message. Applications of this header include cases where the receiver has limited ability to get the representation using other means, for example because of access restrictions or because the overhead would be unacceptable. The RRSHB is also useful when multiple references to the same resource are required but duplication of the resource is undesirable.
Respondent An application that exposes a Web Service and performs processing upon receiving SOAP messages and attachments from an Initiator.
SOAP with Attachments (SWA) SOAP With Attachments (SWA) extends SOAPv1.1 by providing a MIME binding to support multiple message payloads, while ignoring the convention by which Remote Procedure Call (RPC) arguments may be marshalled and unmarshalled in XML.
Source The Endpoint that transmits the Message to the Respondent.
XML-binary Optimized Packaging (XOP) The XML-binary Optimized Packaging (XOP) specification defines a means of more efficiently serializing XML Infosets that have certain types of content. An XOP package is created by placing a serialization of the XML Infoset inside of an extensible packaging format (such a MIME Multipart/Relate, see RFC 2387). Then, selected portions of its content that are base64-encoded binary data are extracted and re-encoded i.e., the data is decoded from base64, and placed into the package. The locations of those selected portions are marked in the XML with a special element that links to the packaged data using URIs.

About This Document

Title IMS General Web Services Attachments Profile
Editor Colin Smythe (IMS)
Team Co-Leads Cathy Schroeder (Microsoft Corp.), James Simon (SUN Microsystems Corp.)
Version 1.0
Version Date 19 December 2005
Status Final Specification
Summary This document contains the description of the profiling of the Message Transmission Optimization Mechanism (MTOM) standard from the World Wide Web Consortium to extend the IMS General Web Services Base Profile. MTOM is used to enable non-XML information to be transported in the IMS GWS SOAP messages.
Revision Information 19 December 2005
Purpose This document is circulated for public adoption. This document is to be adopted by IMS and all other organizations that wish to enhance the IMS General Web Services Base Profile to send non-XML data.
Document Location http://www.imsglobal.org/gws/gwsv1p0/imsgws_attachProfrv1p0.html

To register any comments or questions about this specification please visit: http://www.imsglobal.org/developers/ims/imsforum/categories.cfm?catid=20

List of Contributors

The following individuals contributed to the development of this document:

Name Organization
Fred Beshears UC Berkeley
John Evdemon Microsoft Corp.
Ron Kleinman SUN Micrsosystems Corp.
Sherman Mohler Cisco Learning Institute, Inc.
Cathy Schroeder Microsoft Corp.
James Simon SUN Microsystems Corp.
Colin Smythe Dunelm Services Ltd.
Scott Thorne MIT

Revision History

Version No. Release Date Comments
Final v1.0 19 December 2005 This is the first formal version of the Final Release.

Index

A
Abstract Framework 1, 2, 3

B
Base Profile 1, 2, 3, 4

C
Conformance 1, 2
Context 1

G
General Web Services Base Profile 1

I
IMS Auto-generation Binding Tool 1, 2
IMS General Web Services 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Attachments Profile 1, 2, 3, 4, 5
Base Profile 1, 2, 3, 4, 5
 

M
Message Transmission Optimization Mechanism 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Messaging
Synchronous 1
MIME 1, 2, 3, 4, 5, 6
 

P
Protocols
HTTP 1
SOAP 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
TCP 1
 

R
Remote Procedure Call 1
Resource Representation SOAP Header Block 1, 2, 3, 4, 5

S
Security 1, 2
SOAP 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
SOAP message attachments
MTOM 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
SWA 1, 2, 3, 4
SOAP Versions
1.1 1
SOAP with Attachments 1, 2, 3, 4, 5, 6
Synchronous 1
 

T
TCP 1
Transmission Control Protocol 1

U
Unified Modelling Language 1, 2
UML 1, 2
 

W
W3C 1, 2, 3, 4, 5, 6
Web Services 1, 2, 3, 4, 5, 6, 7, 8, 9
SOAP 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
WSDL 1, 2, 3, 4, 5, 6, 7
WS-Security 1, 2
Web Services Interoperability Organization 1, 2
WSDL 1, 2, 3, 4, 5, 6, 7
WSDL Versions
1.1 1
WS-Security 1, 2
 

X
XML 1, 2, 3, 4, 5
XML Schema 1
XML Schema Definition 1
XML-binary Optimized Packaging 1, 2, 3, 4, 5, 6, 7, 8
XSD 1, 2
XSLT 1

 

 

 

IMS Global Learning Consortium, Inc. ("IMS/GLC") is publishing the information contained in this IMS General Web Services Attachments Profile ("Specification") for purposes of scientific, experimental, and scholarly collaboration only.

IMS/GLC makes no warranty or representation regarding the accuracy or completeness of the Specification.
This material is provided on an "As Is" and "As Available" basis.

The Specification is at all times subject to change and revision without notice.

It is your sole responsibility to evaluate the usefulness, accuracy, and completeness of the Specification as it relates to you.

IMS/GLC would appreciate receiving your comments and suggestions.

Please contact IMS/GLC through our website at http://www.imsglobal.org

Please refer to Document Name:
IMS General Web Services Attachments Profile Revision: 19 December 2005