IMS General Web Services Addressing 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 Addressing Profile
Revision: 19 December 2005

Executive Summary

The IMS General Web Service (GWS) 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 IMS GWS Base Profile addresses the most common problems experienced when 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 Base Profile promotes interoperability across web specifications implementations on different software and vendor platforms. The IMS GWS 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 IMS GWS Base Profile to create a plug-and-play architecture for web services or to guarantee complete interoperability. The IMS GWS Base Profile addresses interoperability in the application layer, in particular, the description of behaviors exposed via Web Services.

The IMS GWS Addressing Profile extends the IMS GWS Base Profile to enable transport-independent end system addressing. IMS GWS Addressing is based upon the WS-Addressing recommendations from the World Wide Web Consortium. WS-Addressing describes two techniques for transport-independent addressing, namely, Endpoint References (EPR) and Message Addressing Properties (MAP). Both techniques are compatible with Web Services Description Language (WSDL). The MAP approach has been selected for the IMS GWS Addressing Profile as this is based upon extending the WSDL v1.1 files as opposed to EPR that defines another external object structure.

Table of Contents

1. Introduction

1.1 Scope and Context

The IMS General Web Services (GWS) Base Profile [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 Addressing Profile extends the IMS GWS Base Profile to enable transport-independent end system addressing. IMS GWS Addressing is based upon the WS-Addressing recommendations from the World Wide Web Consortium (W3C) [WSA, 05a], [WSA, 05b], [WSA, 05c]. WS-Addressing describes two techniques for transport-independent addressing, namely, Endpoint References (EPR) and Message Addressing Properties (MAP). Both techniques are compatible with the Web Services Description Language (WSDL) v1.1 [WSDL, 01]. The MAP approach has been selected for the IMS GWS Addressing Profile as this is based upon extending the WSDL v1.1 files as opposed to EPR that defines another external object structure.

1.2 Structure of the Primer

The structure of the rest of this document is:

1.3 Nomenclature

1.4 References

2. Addressing Framework

2.1 WS-Addressing

The W3C WS-Addressing recommendation defines a standard for incorporating message addressing information into Web Services messages. WS-Addressing provides a uniform addressing method for SOAP messages traveling over synchronous and/or asynchronous transports. Additionally, it provides addressing features to help web service developers build applications around a variety of messaging patterns beyond the typical exchange of requests and responses. WS-Addressing is independent of the other WS-* specifications but can be used in conjunction with them. WS-Addressing extends and incorporates some concepts from WSDL [WSDL, 01], but there is no explicit dependency between the two. Web services developers can use either or both, depending on their needs. WS-Addressing is currently published as three separate specifications:

• WS-Addressing Core [WSA, 05a] - defines the abstract properties;
• WS-Addressing SOAP binding [WSA, 05b] - defines the SOAP binding for WS-Addressing;
• WS-Addressing WSDL binding [WSA, 05c] - defines the WSDL binding for WS-Addressing;

SOAP does not provide a standard way to specify where a message is going, how to return a response, or where to report an error. Those details have, historically, been left to the transport layer. Addressing at the transport level is sufficient for many existing services, but it is a limiting factor in the development of others. WS-Addressing defines standard ways to route a message over multiple transports or direct a response to a third party. WS-Addressing is achieved by extending the SOAP header i.e.

<soap11:Envelope xmlns:soap11="http://www.w3.org/2003/05/soap-envelope" 
 xmlns:wsa="http://www.w3.org/2005/03/addressing">
 <soap11:Header>
 <wsa:MessageID>AVSGEHUWEJIOLIUOMNGG1245</wsa:MessageID>
 <wsa:ReplyTo>
 <wsa:Address>http://www.imsglobal.org/myaddress</wsa:Address>
 </wsa:ReplyTo>
 <wsa:FaultTo>
 <wsa:Address>http://www.imsglobal.org/faultaddress</wsa:Address>
 </wsa:FaultTo>
 <wsa:To>http://www.imsglobal.org/serveraddress</wsa:To>
 <wsa:Action>http://www.imsglobal.org/serviceoperationrequest</wsa:Action>
 </soap11:Header>
 <soap11:Body>
 ...
 <!-- The message body of the SOAP request appears here -->
 ...
 </soap11:Body>
</soap11:Envelope>

WS-Addressing introduces two new Web Services constructs: Endpoint References (EPRs) and Message Addressing Properties (MAPs). "Endpoint" is an established term for a destination at which a Web Service can be accessed. EPRs are a new model for describing these destinations. MAPs, which may include one or more endpoint references, provide a context for that destination information.

2.1.1 Endpoint References (EPRs)

The WS-Addressing specification introduces a new description element type, the EPR, with the intent of supporting a set of dynamic usage patterns not currently appropriately covered by WSDL 1.1. EPRs are defined as a complex type in the WS-Addressing schema that contains an address (a URI), reference properties, reference parameters, a port type, a service name, and policy elements (defined by the WS-Policy specification). The only required element of an endpoint reference is the address, so the simplest EPR is:

 <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/03/addressing">
 <wsa:Address>http://www.imsglobal.org/services/myservice</wsa:Address>
 </wsa:EndpointReference>

The other elements of an EPR are optional. The port type and service name elements are very similar to their WSDL counterparts [GWS, 05a]. WSDL defines a port type as an identifying name attached to an abstract set of operations. The port type and service name in a WS-Addressing EPR provide compatibility with WSDL.

A significant aspect of an EPR is the ability to attach data from other XML namespaces using reference properties or reference parameters. Both of these elements are collections of properties and values that can be used to incorporate elements from any XML namespace into the EPR. A reference property is used to identify the endpoint at which a service is deployed. Two EPRs that share a URI but specify different reference property values represent two different services. Reference properties are used to dispatch a request to the appropriate service. For example, one might deploy two different versions of a service and have requests specify a target version in their reference parameters. When a service receives a request and fulfills it, its behavior should not vary in response to the reference properties. Reference parameters are meant to identify resources managed by a particular service. Reference parameters tell a service which resources to handle. They do not identify the service. Two EPRs with different reference parameters do refer to the same service.

EPRs complement and do not replace the WSDL 1.1 <wsdl:service> element. The EPR is linked to the associated WSDL 1.1 description using one of two methods:

• External meta-data reference

<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/03/addressing">
 <wsa:Address>http://www.imsglobal.org/services/myservice</wsa:Address>
 <wsa:Metadata xmlns:wsdli="http://www.w3/org/2005/08/wsdl-instance"
 wsdli:wsdlLocation="http://www.imsglobal.org/services/myservice.wsdl">
 </wsa:Metadata>
</wsa:EndpointReference>

• Embedded meta-data

<wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/03/addressing">
 <wsa:Address>http://www.imsglobal.org/services/myservice</wsa:Address>
 <wsa:Metadata>
 <wsdl11:definitions targetNamespace=""
 ...
 xmlns:wsdl11="http://schemas.xmlsopa.org/wsdl/">
 ...
 ...
 <wsdl11:service name="myservicename">
 ...
 ...
 </wsdl11:service>
 </wsdl11:definitions>
 </wsa:Metadata>
</wsa:EndpointReference>

Each EPR must be individually defined and linked to the associated service and port/interface. At the current time IMS/GLC will not supply the EPRs as part of the service specification development.

2.1.2 Message Addressing Properties (MAPs)

MAPs define the full set of addressing information that can be attached to a SOAP message. The MAP objects are:

• [destination] : URI (mandatory) - the address of the intended receiver of this message;
• [recipient] : EPR (optional) - the intended receiver of this message;
• [source endpoint] : EPR (optional) - from where the message originated;
• [reply endpoint] : EPR (optional) - this identifies the intended receiver for replies to this message. When formulating a reply message, the sender SHOULD use the contents of the [reply endpoint] of the message being replied to formulate the reply message. If the [reply endpoint] is absent, the sender MAY use the contents of the [source endpoint] to formulate the reply message. This property may be absent if the message has no meaningful reply, e.g., is a one-way application message, or when the reply endpoint has already been communicated to the target by other means. If the [reply endpoint] contains embedded policy, that policy must be the complete policy for that endpoint;
• [fault endpoint] : EPR (optional) - identifies the intended receiver for faults related to this message. When formulating a fault message, the sender SHOULD use the contents of the [fault endpoint] of the message being replied to formulate the fault message. If the [fault endpoint] is absent, the sender MAY use the contents of the [reply endpoint] to formulate the fault message. If both the [fault endpoint] and [reply endpoint] is absent, the sender MAY use the contents of the [source endpoint] to formulate the fault message. This property may be absent if the sender cannot receive fault messages (e.g., is a one-way application message). If the [fault endpoint] contains embedded policy, that policy must be the complete policy for that endpoint.
• [action] : URI (mandatory) - an identifier that uniquely (and opaquely) identifies the semantics implied by this message. It is RECOMMENDED that the value of the [action] property is a URI corresponding to an abstract WSDL construct, e.g., message, operation, port type available at the destination endpoint. In this case, the "relates to" property determines if the action is a request or response (the "direction" of the message). It is expected that at least one interoperable URI encoding scheme for computing an action element from WSDL will be defined. An action may be associated with the WSDL definition of an operation using a Policy element. The algorithm used for computing the action element URI from the WSDL definition of the endpoint may also be identified using an attached Policy element. Finally, it is possible to explicitly associate an arbitrary URI with an operation, superceding all declared encoding algorithms. This provides support to bottom-up development models;
• [message id] : URI (optional) - a URI that uniquely identifies this message in time and space. No two messages may share a [message id] property. The value of this property is an opaque URI whose interpretation beyond equivalence is not defined in this specification;
• [relationship] : (Qname, URI) (0..unbounded) - a pair of values that indicate how this message relates to another message. The type of the relationship is identified by a Qname. The related message is identified by a URI that corresponds to the related message's [message id] property.
• [reference parameters] : xs:any (0..unbounded) - corresponds to the value of the reference parameters property of the EPR to which the message is addressed.

These properties are inserted into the SOAP header. Different combinations of properties are used depending on the message exchange pattern. The IMS GWS Message Exchange patterns (MEPs) are Synchronous, Asynchronous and Polled. The Synchronous MEP is equivalent to the Request/Response MEP in the WS-Addressing WSDL Binding [WSA, 05c].

The MAP approach has been selected for the IMS GWS Addressing Profile as this is based upon extending the WSDL v1.1 files.

2.2 Addressing Processing Workflow

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

Note that INITIATOR and RESPONDENT as used in 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).

The following is a step-by-step breakdown of a typical workflow for exchanging IMS MESSAGES that use the GWS Addressing Profile. 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 an IMS MESSAGE according to the relevant IMS specification and the WSDL binding guidelines [GWS, 05b];
2. The Web Services Messaging Adapter within the INITIATOR:-
   • Constructs the SOAP message request header according to the service WSDL. The action value specified in the WSDL is used to construct the <wsa:Action> header. The <wsa:To> and <wsa:ReplyTo> endpoint addresses are taken from the 'soap:address/@location' attribute values for the service. The <wsa:MessageID> value is allocated as per the local algorithm
   • Encapsulates the IMS MESSAGE in the body of the SOAP message
   • Passes the IMS MESSAGE and any ATTACHMENT to SOURCE;
3. SOURCE transmits the IMS MESSAGE through the transport;
4. IMS MESSAGE is transferred to the DESTINATION;
5. DESTINATION gets the IMS MESSAGE from the transport;
6. The Web Services Messaging Adapter within the RESPONDENT:-
   • Decodes and detaches all ATTACHMENTs attached to the message
   • Constructs the SOAP message response header according to the service WSDL. The action value specified in the WSDL is used to construct the <wsa:Action> header. The <wsa:To> and <wsa:ReplyTo> endpoint addresses are taken from the 'soap:address/@location' attribute values for the service. The <wsa:MessageID> value is allocated as per the local algorithm
   • Passes the receipt/response message to the INITIATOR
   • RESPONDENT extracts, validates and processes the IMS MESSAGE and any ATTACHMENT.

3. Addressing Profile Rules

Table 3.1 summarizes the set of rules used for the Addressing 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 [RFC2119, 97];
• Normative statements in the Profile are presented in the following manner: RADPnnnnStatement 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".

Note that in the rules the namespace prefix "wsa" is used. Any consistent prefix may be used.

4. WSDL Binding Implications

The usage of IMS GWS Addressing Profile requires the following information to supplied as part of the specification process:

• Identification that the Addressing Profile is to be used.

From the perspective of the WSDL 1.1 the attachment information is presented in the WSDL definition part of the file. The transformation files in the IMS Binding 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.

<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:wsa = "http://www.w3.org/2005/03/addressing" 
 xmlns:xs = "http://www.w3.org/2001/XMLSchema" 
 xmlns:xsi = "http://www.w3.org/2000/10/XMLSchema-instance">

<wsdl11:service name = "EgServiceNameSyncService">
 <wsdl11:port name = "CoreOperationsNameSyncSoapPort" binding = "...">
 <soap11:address 
 location="http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap/"/>
 </wsdl11:port>
</wsdl11:service>

<wsdl11:portType name = "coreOpsNamePortType">
 <wsdl11:operation name = "createObject">
 <wsdl11:input message = "tns:createObjectRequest" wsa:Action =
 "http://www.example.soap/serviceuri/coreOpsNamePortType/createObjectRequest"/>
 <wsdl11:input message = "tns:createObjectResponse" wsa:Action =
 "http://www.example.soap/serviceuri/coreOpsNamePortType/createObjectResponse"/>
</wsdl11:operation>
</wsdl11:portType
<wsdl11:binding name = "CoreOpsNameSyncSoapBinding" type="tns:CoreOpsNameSyncPortType">
<soap11:binding transport="http://schema.xmlsoap.org/soap/http" style="document"/>
 <wsa:UsingAddressing wsdl:required = "true"/>
<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 = "CoreOpsNameSyncSoapPort" binding = "tns:CoreOpsNameSyncSoapBinding">
<soap11:address location="http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap/"/>
</wsdl11:port>
</wsdl11:service>

<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:schema>
</wsdl11:types>

The corresponding IMS GWS SOAP request message produced is (the text shown in bold is specific to the usage of WS-Addressing):

<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:wsa="http://www.w3.org/2005/03/addressing">
<SOAP-ENV:Header>
 <wsa:To>http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap</wsa:To>
 <wsa:Action>http://www.example.soap/serviceuri/coreOpsNamePortType/createObjectRequest
 </wsa:Action>
 <wsa:ReplyTo>
 <wsa:Address>http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap
 </wsa:Address>
 </wsa:ReplyTo>
 <wsa:MessageID>MessageIDSTRINGinitiator</wsa:MessageID>
<imsx_syncRequestHeaderInfo xmlns="http://www.imsglobal.org/services/ti/wsdl/sync/sync/wsdlfilev1p0">
<imsx_version>1.0</imsx_version>
<imsx_messageIdentifier>MessageIDSTRINGinitiator</imsx_messageIdentifier>
</imsx_syncRequestHeaderInfo>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<createObjectRequest xmlns="http://www.example/services/wsdl/sync/wsdlfilev1p0">
...
</ceateObjectRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The corresponding IMS GWS SOAP response message produced is (the text shown in bold is specific to the usage of WS-Addressing):

<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:wsa="http://www.w3.org/2005/03/addressing">
<SOAP-ENV:Header>
 <wsa:To>http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap</wsa:To>
 
<wsa:Action>http://www.example.soap/serviceuri/coreOpsNamePortType/createObjectResponse 
 </wsa:Action>
 <wsa:MessageID>MessageIDSTRINGrespondent</wsa:MessageID>
 <wsa:RelatesTo wsa:RelationshipType = 
"http://www.w3.org/2005/08/adddressing/reply">

 MessageIDSTRINGinitiator
 </wsa:RelatesTo>
<imsx_syncResponseHeaderInfo xmlns="http://www.imsglobal.org/services/ti/wsdl/sync/sync/wsdlfilev1p0">
<imsx_version>1.0</imsx_version>
<imsx_messageIdentifier>MessageIDSTRINGrespondent</imsx_messageIdentifier>
<imsx_statusInfo>
...
<imsx_statusInfo>
</imsx_syncResponseHeaderInfo>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<createObjectResponse xmlns="http://www.example/services/wsdl/sync/wsdlfilev1p0">
...
</ceateObjectResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

5. Relationship to the Other GWS Profiles

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

The Addressing Profile assumes that the Base Profile is already being used [GWS, 05a]. WS-Security assumes the usage of WS-Addressing and so the IMS GWS Addressing Profile must be used with the IMS GWS Base Profile is WS-Security is to be adopted as part of the IMS GWS Security Profile.

6. Extending the Addressing Profile

6.1 Proprietary Extensions

Extensions to the Addressing Profile are restricted to using the reference parameters element within the MAP. The <wsa:ReferenceParameters> element should be used to pass service-specific extension data between the communications web service entities. The <wsa:ReferenceParameters> element is a SOAP header extension which can occur any number of times and which can contain any name-spaced element or attribute.

Any extensions must be agreed using external mechanisms and services that do not recognize the extension features should ignore them.

6.2 Further Work in V2.0

In IMS GWS v2.0 further work will focus on three areas:

1. The usage of the Addressing Profile with SOAP v1.2 and WSDL v2.0;
2. Definition of what to do when SOAP faults occur. The current Addressing Profile does not provide specific instructions for handling SOAP fault messages;
3. Investigation of the provision of separate EPR files. This would be an alternative method to using the current WSDL files to contain all of the WS-Addressing information. In this approach the WSDL files are either embedded or referenced using the EPR meta-data element.

7. Conformance to the Addressing Profile

Any claim of conformance for an implementation against the Addressing 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].

About This Document

List of Contributors

The following individuals contributed to the development of this document:

Revision History

Index

A
Abstract Framework 1, 2, 3
Asynchronous 1, 2

B
Base Profile 1, 2, 3

C
Conformance 1, 2
Context 1

E
Endpoint Reference 1, 2, 3, 4, 5, 6, 7, 8, 9

I
IMS Auto-generation Binding Tool 1, 2, 3, 4
IMS General Web Services 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Addressing Profile 1, 2, 3, 4, 5, 6, 7, 8
Base Profile 1, 2, 3, 4, 5, 6
Security Profile 1

M
Message Addressing Properties 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11
Messaging
Asynchronous 1, 2
Polled 1, 2
Synchronous 1, 2, 3, 4, 5

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

S
SOAP 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
Synchronous 1, 2, 3, 4, 5

U
Unified Modelling Language 1, 2, 3, 4
UML 1, 2, 3, 4

W
W3C 1, 2, 3, 4
Web Services 1, 2, 3, 4, 5, 6
SOAP 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
WS-Addressing 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
WSDL 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
WS-Security 1
Web Services Interoperability Organization 1, 2
WSA 1, 2, 3, 4
WS-Addressing 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
Endpoint Reference 1, 2, 3, 4, 5
EPR 1, 2, 3, 4, 5, 6, 7, 8, 9
MAP 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Message Addressing Properties 1, 2, 3, 4, 5, 6
WSDL 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
WSDL Versions
1.1 1, 2, 3
WS-Security 1

X
XML 1, 2, 3
XML Schema 1
XML Schema Definition 1
XSD 1
XSLT 1