WS-Addressing

Submission of WS-Addressing to W3C

Technical Commentary by Eric Newcomer (IONA)

August 27, 2004.

The big news in the standards world this month was the highly anticipated submission of WS-Addressing to the W3C by BEA, IBM, Microsoft, SAP, and Sun. Furthermore, the specification was submitted in accordance with the W3C's strict intellectual property (IP) policy, turning over all copyrights to the W3C and explicitly waiving potential patent royalties and licensing fees.

WS-Addressing is a critical specification for the current generation of extended WS-* specifications, since so many of them depend upon an addressing solution. WS-Addressing is also required for all but the simplest message exchange patterns (MEPs), defining a standard format for routing, reply, and error messages. MEPs such as those needed for publish/subscribe, event notification, and long running business processes need a standard for addressing. Even the simple requirement to guarantee a reply to request can't work without information about the address of the reply.

Of course, existing distributed computing infrastructures such as J2EE, .NET Framework, CORBA, WebSphereMQ, JMS, MSMQ and others provide addressing capabilities as part of their solutions, typically as part of the transport layer. Because Web services are transport independent, and can be implemented using any execution environment, an independent addressing mechanism is needed. WS-Addressing appears to provide the basis of the solution, although some work remains to be done.

Basically, WS-Addressing defines information added to SOAP headers necessary to route them to the appropriate destinations, regardless of transport. The information about where a SOAP message request originated and where it can be executed is important to define and maintain in a transport-neutral. Without WS-Addressing, an implementation might be tempted to depend upon transport-specific features, such as is the case with the HTTP Action header in SOAP 1.1. Among other things, WS-Addressing includes a replacement for this feature.

As with most Web services specifications, WS-Addressing represents a kind of "least common denominator" approach. This is important so that a SOAP envelope can be carried over as many transports as possible, but it also inevitably means omitting some of the advanced features of some of the transports. WebSphere MQ, for example, includes many more message header attributes than are represented in WS-Addressing syntax. And CORBA's IIOP (as could DCE before it) can manage multi-reference address profiles for use in load balancing and failover scenarios.

While WS-Addressing reserves a place for extended features such as these in its extensibility definitions, the question arises as to what it really means to be transport independent. Does it mean simply the ability to carry a SOAP message over any given single transport? Or does it mean the ability to carry the same SOAP message over multiple transports in sequence? It's in the latter case of course that the extended features need to be standardized as well, which may be difficult given WS-Addressing is aimed at the interoperable subset of addressing features.

The relevance of WS-Addressing overall, however, is extremely high. Many other specifications depend upon it, including WS-ReliableMessaging, WS-BPEL, WS-AtomicTransactions, WS-Coordination, WS-Eventing, WS-Notification, and WS-Policy, to name a few. It's a critical piece of Web services infrastructure. Without it, an application is completely dependent upon the transport for addressing, which can cause problems. For example, using the HTTP request/response protocol if the HTTP connection fails before the response is completed, there's no way to resend since the addressing information was in the transport and lost with the connection.

Carrying a SOAP message over IIOP, Tibco RV, Tuxedo, JMS, WehSphereMQ, MSMQ, or any other widely used transport is a fairly simple matter since only a single type of address is required. Each of these systems means something different by the concept of an address, but it's a fairly simple problem to map a WS-Addressing format to any one of these. The difficulty arises when a SOAP message is to be carried over multiple transports, and additional addressing qualifiers and extensions have to be carried in the reference properties. The WS-Addressing specification says that the interpretation of the properties is implementation-specific, but it does not offer any guidance as to how the information might be used across multiple transports.

Given this, it seems as if the WS-Addressing specification is written more for the purpose of bridging HTTP to one alternative transport, such as putting a SOAP message on a WebsphereMQ queue once it arrives over the Internet. The division of technology at the edge of the Internet may indeed be the reality of most current IT environments, but the usefulness of a standard or its applicability shouldn't be limited to a single use case. This isn't to criticize WS-Addressing, since it provides a good solution to a real Web services requirement, but the current specification leaves unresolved the broader requirement of how to pass a SOAP message over multiple different transports.

Other items left open by the current WS-Addressing specification include its relationship to WSDL 2.0, SOAP 1.1 (although faults for SOAP 1.1 are defined), and to the SOAP 1.2 intermediary headers. WS-Policy is referenced within the specification (perhaps indicating that policy will be the next submission we can expect to W3C). For example, policy is included among the criteria for deciding whether two or more endpoint references are identical. When endpoint references are found to differ, Web service providers may have to assume a different set of XML Schema, WSDL, and policy metadata apply to the SOAP message processing operations.

WS-Addressing provides mechanisms for specifying and correlating a message reply, and for defining a fault address. The net effect is comparable to using a message queuing system to define a target queue, reply queue, and error queue, and in fact that would be one implementation option. Reply messages can be correlated using the unique message ID, and WS-Addressing syntax includes a relationship attribute to indicate which messages have a reply relationship to which other messages.

About WS-Addressing

"WS-Addressing Specification Presented to W3C as a Member Submission." News story 2004-08-10.

Web Services Addressing (WS-Addressing). W3C Member Submission 10-August-2004.

Web Services Addressing (WS-Addressing). Main reference page.

About Eric Newcomer

Eric Newcomer is Chief Technology Officer at IONA. Eric is responsible for directing and communicating IONA's technology roadmap, as well as IONA's product strategy as it relates to standards adoption, architecture, and product design.

Eric joined IONA in November 1999, after nearly 16 years at Digital/Compaq, where he held a variety of technical and management roles. Eric joined IONA as the company's transaction processing architect, and also served as IONA's Vice President of Engineering, Web Services Integration Products.

Eric leads IONA's participation in the standardization activities around Web services, and was a founding member of the XML Protocols Working Group at W3C, which produced SOAP 1.2. He is currently editor of the Web Services Architecture specification at the W3C and is IONA's primary representative to OASIS and WS-I. Eric is co-author and editor of the recently published Web Services Composite Application Framework (WS-CAF) set of specifications submitted to OASIS.

A frequent speaker at industry and company events and contributor to popular journals and Web sites, Eric is the author of the best-selling Understanding Web Services, (published in May 2002 by Addison-Wesley), and co-author with Phil Bernstein of Principles of Transaction Processing (published in January 1997 by Morgan Kaufman). His new book, Web Services Integration, is from Addison-Wesley.

Prepared by Robin Cover for The XML Cover Pages archive.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	WS-Addressing Submission of WS-Addressing to W3C Technical Commentary by Eric Newcomer (IONA) August 27, 2004. The big news in the standards world this month was the highly anticipated submission of WS-Addressing to the W3C by BEA, IBM, Microsoft, SAP, and Sun. Furthermore, the specification was submitted in accordance with the W3C's strict intellectual property (IP) policy, turning over all copyrights to the W3C and explicitly waiving potential patent royalties and licensing fees. WS-Addressing is a critical specification for the current generation of extended WS-* specifications, since so many of them depend upon an addressing solution. WS-Addressing is also required for all but the simplest message exchange patterns (MEPs), defining a standard format for routing, reply, and error messages. MEPs such as those needed for publish/subscribe, event notification, and long running business processes need a standard for addressing. Even the simple requirement to guarantee a reply to request can't work without information about the address of the reply. Of course, existing distributed computing infrastructures such as J2EE, .NET Framework, CORBA, WebSphereMQ, JMS, MSMQ and others provide addressing capabilities as part of their solutions, typically as part of the transport layer. Because Web services are transport independent, and can be implemented using any execution environment, an independent addressing mechanism is needed. WS-Addressing appears to provide the basis of the solution, although some work remains to be done. Basically, WS-Addressing defines information added to SOAP headers necessary to route them to the appropriate destinations, regardless of transport. The information about where a SOAP message request originated and where it can be executed is important to define and maintain in a transport-neutral. Without WS-Addressing, an implementation might be tempted to depend upon transport-specific features, such as is the case with the HTTP Action header in SOAP 1.1. Among other things, WS-Addressing includes a replacement for this feature. As with most Web services specifications, WS-Addressing represents a kind of "least common denominator" approach. This is important so that a SOAP envelope can be carried over as many transports as possible, but it also inevitably means omitting some of the advanced features of some of the transports. WebSphere MQ, for example, includes many more message header attributes than are represented in WS-Addressing syntax. And CORBA's IIOP (as could DCE before it) can manage multi-reference address profiles for use in load balancing and failover scenarios. While WS-Addressing reserves a place for extended features such as these in its extensibility definitions, the question arises as to what it really means to be transport independent. Does it mean simply the ability to carry a SOAP message over any given single transport? Or does it mean the ability to carry the same SOAP message over multiple transports in sequence? It's in the latter case of course that the extended features need to be standardized as well, which may be difficult given WS-Addressing is aimed at the interoperable subset of addressing features. The relevance of WS-Addressing overall, however, is extremely high. Many other specifications depend upon it, including WS-ReliableMessaging, WS-BPEL, WS-AtomicTransactions, WS-Coordination, WS-Eventing, WS-Notification, and WS-Policy, to name a few. It's a critical piece of Web services infrastructure. Without it, an application is completely dependent upon the transport for addressing, which can cause problems. For example, using the HTTP request/response protocol if the HTTP connection fails before the response is completed, there's no way to resend since the addressing information was in the transport and lost with the connection. Carrying a SOAP message over IIOP, Tibco RV, Tuxedo, JMS, WehSphereMQ, MSMQ, or any other widely used transport is a fairly simple matter since only a single type of address is required. Each of these systems means something different by the concept of an address, but it's a fairly simple problem to map a WS-Addressing format to any one of these. The difficulty arises when a SOAP message is to be carried over multiple transports, and additional addressing qualifiers and extensions have to be carried in the reference properties. The WS-Addressing specification says that the interpretation of the properties is implementation-specific, but it does not offer any guidance as to how the information might be used across multiple transports. Given this, it seems as if the WS-Addressing specification is written more for the purpose of bridging HTTP to one alternative transport, such as putting a SOAP message on a WebsphereMQ queue once it arrives over the Internet. The division of technology at the edge of the Internet may indeed be the reality of most current IT environments, but the usefulness of a standard or its applicability shouldn't be limited to a single use case. This isn't to criticize WS-Addressing, since it provides a good solution to a real Web services requirement, but the current specification leaves unresolved the broader requirement of how to pass a SOAP message over multiple different transports. Other items left open by the current WS-Addressing specification include its relationship to WSDL 2.0, SOAP 1.1 (although faults for SOAP 1.1 are defined), and to the SOAP 1.2 intermediary headers. WS-Policy is referenced within the specification (perhaps indicating that policy will be the next submission we can expect to W3C). For example, policy is included among the criteria for deciding whether two or more endpoint references are identical. When endpoint references are found to differ, Web service providers may have to assume a different set of XML Schema, WSDL, and policy metadata apply to the SOAP message processing operations. WS-Addressing provides mechanisms for specifying and correlating a message reply, and for defining a fault address. The net effect is comparable to using a message queuing system to define a target queue, reply queue, and error queue, and in fact that would be one implementation option. Reply messages can be correlated using the unique message ID, and WS-Addressing syntax includes a relationship attribute to indicate which messages have a reply relationship to which other messages. About WS-Addressing "WS-Addressing Specification Presented to W3C as a Member Submission." News story 2004-08-10. Web Services Addressing (WS-Addressing). W3C Member Submission 10-August-2004. Web Services Addressing (WS-Addressing). Main reference page. About Eric Newcomer Eric Newcomer is Chief Technology Officer at IONA. Eric is responsible for directing and communicating IONA's technology roadmap, as well as IONA's product strategy as it relates to standards adoption, architecture, and product design. Eric joined IONA in November 1999, after nearly 16 years at Digital/Compaq, where he held a variety of technical and management roles. Eric joined IONA as the company's transaction processing architect, and also served as IONA's Vice President of Engineering, Web Services Integration Products. Eric leads IONA's participation in the standardization activities around Web services, and was a founding member of the XML Protocols Working Group at W3C, which produced SOAP 1.2. He is currently editor of the Web Services Architecture specification at the W3C and is IONA's primary representative to OASIS and WS-I. Eric is co-author and editor of the recently published Web Services Composite Application Framework (WS-CAF) set of specifications submitted to OASIS. A frequent speaker at industry and company events and contributor to popular journals and Web sites, Eric is the author of the best-selling Understanding Web Services, (published in May 2002 by Addison-Wesley), and co-author with Phil Bernstein of Principles of Transaction Processing (published in January 1997 by Morgan Kaufman). His new book, Web Services Integration, is from Addison-Wesley. Prepared by Robin Cover for The XML Cover Pages archive.