The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
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
Last modified: March 20, 2006
Web Services Addressing (WS-Addressing)

Update 2004-12-08: "W3C Publishes Three Initial Working Drafts for Web Services Addressing." The W3C Web Services Addressing Working Group released three First Working Drafts for the "Web Services Addressing." Chartered in October 2004 as part of the W3C Web Services Activity, the WG is designing transport-neutral addressing mechanisms by defining XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. The first Working Draft contains three documents: a Core, WSDL Binding, and SOAP Binding.

Update 2004-10-07 In October 2004, W3C chartered a new Web Services Addressing Working Group as part of the W3C Web Services Activity. The goal of the Working Group is to produce a W3C Recommendation for Web Services Addressing by refining the WS-Addressing Member Submission. See details in the news story "W3C Announces Formation of New Web Services Addressing Working Group."

Update 2004-08-10: See "WS-Addressing Specification Presented to W3C as a Member Submission."

Introduction

A Web Services Addressing (WS-Addressing) specification from BEA, IBM, and Microsoft was published on March 13, 2003 and was re-issued with modifications (apparently) in May 2003 though carrying the same "13 March 2003" publication date. According to the document's status statement, "WS-Addressing and related specifications are provided as-is and for review and evaluation only. BEA, IBM, and Microsoft hope to solicit your contributions and suggestions in the near future. BEA, IBM, and Microsoft Corporation make no warrantees or representations regarding the specifications in any manner whatsoever."

Specification abstract: "WS-Addressing provides transport-neutral mechanisms to address Web services and messages. Specifically, this specification defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner."

The WS-Addressing specification makes normative use of WS-Policy. As of March 2004, several other (WS-*) specifications made (normative) reference to WS-Addressing. Examples:

Bibliographic Information

Web Services Addressing (WS-Addressing). Released as a W3C Member Submission. August 10, 2004. 21 pages. Edited by Don Box (Microsoft) and Francisco Curbera (IBM). W3C Version URL: http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/. W3C latest version URL: http://www.w3.org/Submission/ws-addressing/. Authors: Don Box (Microsoft, Editor), Erik Christensen (Microsoft), Francisco Curbera (IBM, Editor), Donald Ferguson (IBM), Jeffrey Frey (IBM), Marc Hadley (Sun Microsystems, Inc), Chris Kaler (Microsoft), David Langworthy (Microsoft), Frank Leymann (IBM), Brad Lovering (Microsoft), Steve Lucco (Microsoft), Steve Millet (Microsoft), Nirmal Mukhi (IBM), Mark Nottingham (BEA), David Orchard (BEA), John Shewchuk (Microsoft), Eugène Sindambiwe (SAP), Tony Storey (IBM), Sanjiva Weerawarana (IBM), Steve Winkler (SAP). Copyright (c) 2002-2004 BEA Systems Inc., International Business Machines Corporation, Microsoft Corporation, Inc, SAP AG, and Sun Microsystems, Inc.. Submitted to W3C on August 03, 2004 by David Orchard (BEA Systems), Steve Holbrook (IBM), Jonathan Marsh (Microsoft) Marc Goodner (SAP), Eduardo Gutentag (Sun Microsystems, Inc.) See the news story.

Web Services Addressing (WS-Addressing). March 2004. 19 pages. Authors: Adam Bosworth, BEA; Don Box, Microsoft (Editor); Erik Christensen, Microsoft; Francisco Curbera, IBM (Editor); Donald Ferguson, IBM; Jeffrey Frey, IBM; Chris Kaler, Microsoft; David Langworthy, Microsoft; Frank Leymann, IBM; Brad Lovering, Microsoft; Steve Lucco, Microsof;t Steve Millet, Microsoft; Nirmal Mukhi, IBM; Mark Nottingham, BEA; David Orchard, BEA; John Shewchuk, Microsoft; Tony Storey, IBM; Sanjiva Weerawarana, IBM. Copyright (c) 2002-2004 BEA Systems Inc., International Business Machines Corporation, and Microsoft Corporation, Inc. XML namespace URI: http://schemas.xmlsoap.org/ws/2004/03/addressing.

Web Services Addressing (WS-Addressing). May19, 2003 (19/23, ca) but said to be "13 March 2003". Copyright (c) 2002-2003 by BEA Systems Inc., International Business Machines Corporation, Microsoft Corporation. Authors: Adam Bosworth (BEA), Don Box (Microsoft, Editor), Erik Christensen (Microsoft), Francisco Curbera (IBM, Editor), Donald Ferguson (IBM), Jeffrey Frey (IBM), Chris Kaler (Microsoft), David Langworthy (Microsoft), Frank Leymann (IBM), Steve Lucco (Microsoft), Steve Millet (Microsoft), Nirmal Mukhi (IBM), Mark Nottingham (BEA), David Orchard (BEA), John Shewchuk (Microsoft), Tony Storey (IBM), and Sanjiva Weerawarana (IBM). 14 pages. Compare the copyright statements in the May 19 and March 13 public versions. With XML Schema.

Web Services Addressing (WS-Addressing). Edited by Don Box (Microsoft) and Francisco Curbera (IBM). 13-March-2003. Authors: Adam Bosworth (BEA), Don Box (Microsoft), Erik Christensen (Microsoft), Francisco Curbera (IBM), Donald Ferguson (IBM), Jeffrey Frey (IBM), Chris Kaler (Microsoft), David Langworthy (Microsoft), Frank Leymann (IBM), Steve Lucco (Microsoft), Steve Millet (Microsoft), Nirmal Mukhi (IBM), Mark Nottingham (BEA), David Orchard (BEA), John Shewchuk (Microsoft), Tony Storey (IBM), Sanjiva Weerawarana (IBM). 14 pages. Copyright 2002-2003 by BEA Systems Inc., International Business Machines Corporation, and Microsoft Corporation.

WS-Addressing Overview: 2003 Version

Web Services Addressing (WS-Addressing) defines two constructs that convey information that is typically provided by transport protocols and messaging systems in an interoperable manner. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. The two constructs are endpoint references and message information headers.

A Web service endpoint is a (referencible) entity, processor, or resource where Web service messages can be targeted. Endpoint references convey the information needed to identify/reference a Web service endpoint, and may be used in several different ways: endpoint references are suitable for conveying the information needed to access a Web service endpoint, but are also used to provide addresses for individual messages sent to and from Web services. To deal with this last usage case this specification defines a family of message information headers that allows uniform addressing of messages independent of underlying transport. These message information headers conveys end-to-end message characteristics including addressing for source and destination endpoints as well as message identity.

Both of these constructs are designed to be extensible and re-usable so that other specifications can build on and leverage endpoint references and message information headers.

The WS-Addressing XML Namespace URI is http://schemas.xmlsoap.org/ws/2003/03/addressing. Though the choice of namespace prefix "is arbitrary and not semantically significant," the prefix used with the WS-Addressing namespace 'http://schemas.xmlsoap.org/ws/2003/03/addressing' in the specification is wsa.

The namespace for WS-Policy is also used in the WS-Addressing specification. Specification Section 2.1 'Information Model for Endpoint References' clarifies that abstract properties of an endpoint reference include [policy] : wsp:policy (0..unbounded), viz., "A variable number of XML policy elements as described in WS-Policy describing the behavior, requirements and capabilities of the endpoint. Policies may be included in an endpoint to facilitate easier processing by the consuming application, or because the policy was dynamically generated." For WS-Policy references, see Web Services Policy Framework."

WS-Addressing is defined in terms of the W3C XML Information Set. WS-Addressing is conformant to the SOAP 1.2 processing model; SOAP 1.2 is not a requirement for using the constructs defined in this specification. WS-Addressing is also designed to be able work with WSDL 1.1 described services. The examples in this specification use an XML 1.0 representation but this is not a requirement.

Model and Syntax for Endpoint References: This specification introduces a new description element type, the endpoint reference, with the intent of supporting a set of dynamic usage patterns not currently appropriately covered by WSDL 1.1. In particular, this specification intends to facilitate the following usage scenarios:

  • Dynamic generation and customization of service endpoint descriptions.
  • Identification and description of specific service instances that are created as the result of stateful interactions.
  • Flexible and dynamic exchange of endpoint information in tightly coupled environments where communicating parties share a set of common assumptions about specific policies or protocols that are used during the interaction.

To support these scenarios, we define a lightweight and extensible mechanism to dynamically identify and describe service endpoints and instances. Because of the current limits of the WSDL 1.1 extensibility model, the WSDL 1.1 service and port elements cannot be used to cover the use cases listed above. Endpoint references logically extend the WSDL description model (e.g., portTypes, bindings, etc.), but do not replace it. Endpoint references will be used instead of WSDL <service/> elements in the following cases:

  • Specific instances of a stateful service need to be identified or its instance specific configuration details need to be transmitted.
  • A lightweight, self-contained description of a service endpoint needs to be communicated. In particular, this may be necessary when the details of the endpoint configuration are already shared by the communicating parties, but specific policy information needs to be added or updated, typically as a result of a dynamic configuration process.

Endpoint references compliment and do not replace the WSDL/1.1 <wsdl:service> element. We expect solutions built on WSDL/1.1 to continue to utilize a service element. Moving forward we anticipate that endpoint references and WSDL will evolve coherently. The endpoint references may link to service elements in WSDL/1.1, and support additional scenarios in which the WSDL information is not known by a party processing a message. These scenarios may include dynamic messaging or limited capability message processors..." [adapted from spec Sections 1-2]

WS-Addressing from 'The Basics — Transports and Messaging'

From "Secure, Reliable, Transacted Web Services: Architecture and Composition," by IBM and Microsoft:

"Messages and responses both go somewhere and come from somewhere. WS-Addressing provides an interoperable, transport independent approach to identifying message senders and receivers. WS-Addressing also provides a finer grain approach to identifying specific elements within a service that send or should receive a message.

Today most systems using Web services encode the destination for a Web service message with a URL that is placed in the HTTP transport. The destination for the response is determined by the return transport address. This approach builds on the basic browser-server model of HTTP.

Using today's approach, the source and destination information are not part of the message itself. This can cause several problems. The information can be lost if a transport connection terminates (for example, if the response takes a long time and the connection times out) or if the message is forwarded by an intermediary such as a firewall.

WS-Addressing provides a mechanism to place the target, source and other important address information directly within the Web service message. In short, WS-Addressing decouples address information from any specific transport model.

In many scenarios messages are targeted directly to a service and the addressing information in the message can be described simply using a URL. But in practice, we often find that messages are targeted to specific elements or resources within a service. For example, a coordination service might be coordinating many different tasks. The coordinator needs to associate most incoming messages with a specific task instance that it manages and not the coordination service itself.

WS-Addressing provides a simple yet powerful mechanism called an endpoint reference for addressing entities managed by a service. While such information could be encoded in an ad-hoc manner within the URL of the service, the endpoint references provides a standard XML element that enables a structured approach to encoding this fine-grained addressing.

The combination of fine-grain control over addressing coupled with the transport-neutral encoding of the message source and destination enables Web service messages to be sent across a range of transports, through intermediaries, and it enables both asynchronous and extended duration communication patterns.

WS-Addressing also enables a sender to indicate where a response should go in a transport-independent manner. The response to a message may not necessarily go to the sender. In HTTP for example, without WS-Addressing it is impossible to specify that the response should be sent elsewhere.

These enhancements to the messaging model enable Web services to be used to support many business scenarios. For example, certain banking tasks require human review for approval at certain steps. There are usually many active instances of the task at any point in time. WS-Addressing provides a general mechanism to associate incoming or outgoing messages with specific tasks. The mechanism that the service uses is transparent to those using the service through an endpoint reference..." [excerpted]

Superseded Specifications: WS-Routing, WS-Referral

According to Microsoft's Messaging Specifications Index Page, the Web Services Addressing (WS-Addressing) specification supersedes the WS-Routing and WS-Referral specifications authored by Microsoft.

  • Web Services Routing Protocol (WS-Routing). By Henrik Frystyk Nielsen and Satish Thatte. October 23, 2001. See also the XML Schema for SOAP-RP. "Web Services Routing Protocol (WS-Routing) is a SOAP-based, stateless protocol for exchanging one-way SOAP messages from an initial sender to the ultimate receiver, potentially via a set of intermediaries. In addition, WS-Routing provides an optional reverse message path enabling two-way message exchange patterns like request/response, peer-to-peer conversations, and the return of message acknowledgements and faults. WS-Routing is expressed as a SOAP header entry within a SOAP envelope making it relatively independent of the underlying protocol. This specification defines the use of WS-Routing in combination with TCP, UDP, and HTTP but other underlying protocols are possible."

  • Web Services Referral Protocol (WS-Referral). By Henrik Frystyk Nielsen, Erik Christensen, Steve Lucco, and David Levin (Microsoft). Draft Version. October 23, 2001. See also the XML Schema for WS-Referral. "Web Services Referral Protocol (WS-Referral) is a SOAP-based, stateless protocol for inserting, deleting, and querying routing entries in a SOAP router. A SOAP router is a SOAP node that exposes SOAP message relaying as a Web service, either as a standalone service or in combination with other services. An example of a SOAP router is a SOAP node supporting the Web Services Routing Protocol (WS-Routing). In addition to mechanisms for inserting, deleting, and querying routing entries, WS-Referral defines an XML-based structure called a WS-Referral statement for describing a routing entry along with a set of conditions under which the statement is satisfied."

W3C Web Services Addressing 2004-12: Core, WSDL Binding, SOAP Binding

On December 08, 2004 the W3C Web Services Addressing Working Group released its first three Working Drafts for the Web Services Addressing specification, which provides transport-neutral mechanisms to address Web services and messages. W3C chartered the new Web Services Addressing Working Group in October 2004 as part of the W3C Web Services Activity, under the W3C Architecture Domain. In August 2004 a revised Web Services Addressing (WS-Addressing) specification was presented to W3C as a Member Submission by BEA, IBM, Microsoft, SAP AG, and Sun Microsystems. WS-Addressing "defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. The specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner." In keeping with terms of the WG Charter, the Member Submission document has been separated into three separate specifications: Core, SOAP Binding, and WSDL Binding. The new Web Services Addressing Core "defines a set of abstract properties and an XML Infoset representation thereof to identify Web service endpoints and to secure end-to-end identification of endpoints in messages." In this version the dependency upon on WS-Policy has been removed, along with references to WS-Trust and WS-SecurityPolicy. The Web Services Addressing - WSDL Binding specification "defines how the abstract properties defined in Web Services Addressing Core are described using WSDL." Part 3, the Web Services Addressing SOAP Binding, defines the binding of the abstract properties defined in Web Services Addressing Core to SOAP Messages. "When a message needs to be addressed to the endpoint, the information contained in the endpoint reference is mapped to the message according to a transformation that is dependent on the protocol and data representation used to send the message. Protocol-specific mappings (or bindings) will define how the information in the endpoint reference is copied to message and protocol fields."

References:

WS-Addressing Specification 2004-08-10

The Web Services Addressing (WS-Addressing) specification has been presented to W3C by BEA, IBM, Microsoft, SAP AG, and Sun. WS-Addressing provides transport-neutral mechanisms to address Web services and messages by defining XML elements that identify Web service endpoints and to secure end-to-end endpoint identification in messages. It enables messaging systems to include processing nodes such as endpoint managers, firewalls, and gateways in messages.

August 10, 2004 Version Sources:

WS-Addressing Specification 2004-03-30

Microsoft announced from the Web Services Development Center home page on March 30, 2004: An "updated WS-Addressing specification has been improved based on community feedback and multi-vendor implementation experience. Changes include an improved definition of request-reply and a new WSDL binding and fault codes." This March 30, 2004 version updates the earlier version of WS-Addressing available from the three canonical web sites (BEA, IBM, Microsoft) as of 2004-03-20, from approximately "19 May 2003", or possibly later.

March 30, 2004 Version Sources:

WS-Addressing Specification Principal URLs 2004-03-20

Here are URLs for WS-Addressing from the three canonical web sites (BEA, IBM, Microsoft) as of 2004-03-20. Specification version is approximately "19 May 2003", or possibly later. A separate section references the specification as originally published on March 13, 2003.

WS-Addressing Specification 2003-03-13 through 2003-05

The WS-Addressing specification as published March 13, 2003 and labeled as version "13 March 2003" contained a different IPR declaration than the modified specification which appeared on the authors' web sites about May 23, 2003 (or later), also labeled as version "13 March 2003". [Clarification is lacking as to whether any other substantive changes were made in the revised version.] See below for an sample expression of criticism about silent changes made to documents promoted as (in-draft) standards.

A copy of the original "13 March 2003" version is available in PDF format. HTML copies cached in various NET places are also available.

IPR statement for the WS-Addressing specification as of 2004-03-20

Copyright Notice

Copyright 2002-2003 by BEA Systems Inc., International Business Machines Corporation, Microsoft Corporation. All rights reserved.

Permission to copy and display the WS-Addressing Specification, in any medium without fee or royalty is hereby granted, provided that you include the following on ALL copies of the WS-Addressing Specification, or portions thereof, that you make:

  1. A link or URL to the WS-Addressing Specification at this location
  2. The copyright notice as shown in the WS-Addressing Specification.

BEA Systems, IBM and Microsoft (collectively, the "Authors") each agree to grant you a royalty-free license, under commercially reasonable terms and conditions, to their respective patents that they deem necessary to implement the WS-Addressing Specification.

THE WS-Addressing SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE WS-Addressing SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE WS-Addressing SPECIFICATION.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the WS-Addressing Specification or its contents without specific, written prior permission. Title to copyright in the WS-Addressing Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

IPR statement for WS-Addressing printed in the original "13 March 2003" version

Copyright Notice

Copyright 2002-2003 by BEA Systems Inc., International Business Machines Corporation, Microsoft Corporation. All rights reserved.

BEA, IBM, and Microsoft (collectively, the "Authors") hereby grant you permission to copy and display the WS-Addressing Specification, in any medium without fee or royalty, provided that you include the following on ALL copies of the WS-Addressing Specification, or portions thereof, that you make:

  1. A link or URL to the Specification at this location
  2. The copyright notice as shown in the WS-Addressing Specification.

EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE, THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL.

THE WS-ADDRESSING SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE WS-ADDRESSING SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE WS-ADDRESSING SPECIFICATION.

The WS-Addressing Specification may change before final release and you are cautioned against relying on the content of this specification.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Specification or its contents without specific, written prior permission. Title to copyright in the WS-Addressing Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

Articles, Papers, News

  • [March 17, 2006] "Green Tide." By Jonathan Marsh. MSN Spaces, Design by Committee: Jonathan Marsh keeps an eye out for the sublime and the absurd. "WS-Addressing 1.0 passed the last two predictable hurdles in the last week in its march towards completion. Last Tuesday, the required interop matrix filled up, allowing the WG to declare the spec sufficient to enable interop between vendors. But the push for interop didn't end there! We needed four implementations interoping, and we have 5 at 100%, with a sixth awfully close. Optional features also overacheived. I put together a little rollup in the test results to show our progress and the minimum we'd need to declare victory. I think it shows we blew past our requirements. This is a significant milestone in Web Services, as the energy throughout the stack seems to be shifting dramatically towards proving interop rather than writing specs. And then another milestone yesterday, with the Working Group accepting the test results and the specs as complete, and referring them to the Director, who, with the advice of the Advisory Committee, should move them to final Recommendation in the coming weeks, hopefully without any fuss..." [tinyUrl, longURL]

  • [December 23, 2005] W3C Web Services Addressing Interoperability Event. Posting by Mark Nottingham (BEA). The W3C Web Services Addressing Working Group plans to hold an Interoperability Event to test the Web Services Addressing family of W3C Technical Reports in January 2006, and invites participation from interested parties who have an implementation of one or more of the following specifications; Web Services Addressing 1.0 - Core, 2005-08-17 Candidate Recommendation [1] Web Services Addressing 1.0 - SOAP Binding, 2005-08-17 Candidate Recommendation [2] Web Services Addressing 1.0 - WSDL Binding Editors' Draft. Testing will focus on satisfying the Candidate Recommendation criteria for the Core and SOAP Binding documents, as expressed in the Test Suite. If time permits, additional testing may take place... Interested parties should join the public-ws-addressing-tests@w3.org mailing list, where the test plan and other specifics will be discussed. Note that testing may take place against subsequent revisions to the documents, and that the test suite is not yet final... The event will take place at the Opus Hotel in Vancouver, BC, Canada on January 17th and 18th, 2006 from 9am until 5pm each day... Please register using the [online] form..."

  • [October 28, 2005]   IBM Submits Web Services Polling (WS-Polling) Specification to W3C.    On October 26, 2005, the World Wide Web Consortium published a W3C Member Submission from IBM presenting the Web Services Polling (WS-Polling) specification. WS-Polling defines a mechanism to deliver messages destined to an unreachable endpoint by allowing the destination to poll the source for messages targeted for it. The WS-Polling specification is part of the WS-* "Composable Architecture" which uses the XML, SOAP, and WSDL extensibility models, designed to be composed with other WS-* specification "to provide a rich set of tools to provide security in the Web services environment. The WS-Polling specification specifically relies on other Web service specifications to provide secure, reliable, and/or transacted message delivery and to express Web service and client policy." WS-Polling defines a mechanism through which "an endpoint may initiate a connection to another endpoint for the purposes of allowing messages from the destination/service endpoint to be delivered back to the source/client. When sending SOAP messages in an environment where the two endpoints (source and destination) are not able to freely open connection in both directions, delivery of asynchronous messages becomes problematic. [For example], if the initiator (client) of a Web service call is behind a firewall, any messages initiated from the service back to the client can not be delivered; another common case is where the client does not have a SOAP listener (i.e., server) running to receive asynchronous messages. In order for the service to deliver a message to the "unreachable" client endpoint it becomes necessary for the client to initiate the connection, thus allowing the message to be sent back on the response flow of the connection." The WS-Polling draft is related to three principal W3C specifications: SOAP 1.2 (W3C Recommendation produced by the XML Protocol Working Group), Web Services Addressing 1.0 (developed by the Web Services Addressing Working Group), and WSDL 2.0 (developed by the Web Services Description Working Group).

  • [April 28, 2005] "Toward Integration: Web Services References." By Steve Vinoski (IONA Technologies). In IEEE Internet Computing Volume 9, Number 2 (March/April 2005), pages 94-96. ['Endpoint references, defined in the WS-Adressing spec, would provide a flexible and useful mechanism for Web service references. In this column, Vinoski discusses a few issues that I raised in the WG regarding the features needed to turn the EPR into a flexible and useful Web service reference.'] "As currently defined, the WS-Addressing EPR allows access to a service over only a single port. That's like mandating that a business card specify only one means of reaching a person, thus forcing you to have multiple business cards to allow others to reach you via multiple access means. Imagine attending a business meeting where you had to give business cards to five people, each of whom you wanted to be able to reach you via your desk phone, cell phone, or email. You'd have to hand out 15 cards to do so. There are at least four approaches to dealing with this problem for services: (1) Augment the EPR structure with additional port information, perhaps by adding optional fields to the EPR. (2) Standardize a policy assertion that could convey additional optional port information within an EPR. (3) Create a separate structure that can hold one or more EPRs. (4) Use WS-MetadataExchange (WS-MEX). Here, a consumer would use a service's advertised EPR — containing information for only a single port — to retrieve the service's metadata, which would provide any additional port information. Ultimately, it boils down to whether a service can carry multiple port information in its EPR by value, or whether it must advertise an address that an application can use to indirectly obtain information about alternative ports. WS-MEX promotes the indirect approach, whereas the by-value approach is reminiscent of Corba interoperable object references (IORs). The IOR approach, which has been in use for about a decade, proves the viability and usefulness of having a service reference structure that can carry connectivity details for any number of protocols and transports. The WS-MEX approach would work, but it would require network operations (which can be fairly expensive) to retrieve additional port information, and it would be tough on legacy services, which can't be rebuilt and redeployed to support WS-MEX..." [alt url]

  • [October 07, 2004]   W3C Announces Formation of New Web Services Addressing Working Group.    W3C has chartered a new Web Services Addressing Working Group as part of the W3C Web Services Activity, under the W3C Architecture Domain. The TC Chair is Mark Nottingham (BEA), while Hugo Haas and Philippe Le Hégaret have been designated as W3C Team Contacts. The charter extends through 28-February-2006. The goal of the new Working Group is to produce a W3C Recommendation for Web Services Addressing by "refining the W3C Member Submission WS-Addressing based on consideration of the importance of this component in the Web Services architecture, implementation experience, and interoperability feedback. WS-Addressing defines how message headers direct messages to a service or agent, provides an XML format for exchanging endpoint references, and defines mechanisms to direct replies or faults to a specific location." In particular, the Web Services Addressing Working Group has been chartered to "standardize the mechanisms for referencing and addressing Web services by refining WS-Addressing, which includes four principal components of the W3C's Web Services Architecture specification. These referencing and addressing mechanisms are (1) a means by which message headers are used to direct messages to a Web service or agent; (2) abstract message properties (message identifier; a URI for the destination address; a URI designating the action to be taken at the destination; correlation with other message[s]; the nature of the relationship with those messages) (3) an appropriate XML Infoset definition; (4) abstract properties to identify subsequent destinations in the message exchange, including the reply destination and the fault destination." The XML Infoset required for "communicating the information necessary to generate appropriate headers to direct messages to a service or an agent includes a URI designating the destination address; service specific message headers; interaction specific message headers; WSDL definitions relevant to this service; additional metadata as required." According to the WG Charter, these components "must be extensible to enable other mechanisms such as new kinds of relationships between correlated messages, policies, or service semantics to be built upon Web Services Addressing. The components must also be usable independently of the SOAP or WSDL version in use." Additionally, the WG will define SOAP 1.1 and WSDL 1.1 bindings (defined for backward compatibility only). It will define (1) a binding of all abstract message properties to SOAP 1.1 and SOAP 1.2 headers, (2) the use of these abstract message properties in the context of all WSDL 1.1 or WSDL 2.0 Message Exchange Patterns, including the asynchronous use of these MEPs; in particular, the relationship between message properties and WSDL 1.1 and WSDL 2.0 service descriptions will be provided if applicable, and (3) a security model for using and communicating these abstract properties."

  • [August 27, 2004] Submission of WS-Addressing to W3C." Technical Commentary by Eric Newcomer (IONA). August 27, 2004. "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..." [see the complete text]

  • [August 17, 2004] "Vendors' Choice of W3C Raises WS-Addressing's Profile." By Charles Abrams. Gartner Research, ID Number: FT-23-6913. August 17, 2004. "On 10-August-2004, BEA Systems, IBM, Microsoft, SAP and Sun Microsystems announced that they have jointly submitted the latest version of WS-Addressing to the World Wide Web Consortium (W3C). WS-Addressing will provide transport-neutral mechanisms for asynchronous Web services messages... This very important specification will enable Web services transactions to overcome current transport restrictions. If it is agreed upon, WS-Addressing will become a core Web services standard, along with Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP). WS-Addressing will underpin other specifications, such as WS-Reliable Messaging, WS-Federation and WS-Atomic Transaction, providing a consistent, interoperable and standards-based mechanism for Web services addressing and extending SOAP functionality to a wider range of interaction. WS-Addressing defines XML (Extensible Markup Language) elements to identify Web services endpoints and secure end-to-end endpoint identification in messages. It will enable messaging systems to support message transmission through network components that may include processing nodes such as firewalls, gateways and endpoint managers. The first version of WS-Addressing was a vendor initiative, submitted to W3C by BEA, IBM and Microsoft in March 2003. The decision by five vendors to use the W3C for the latest initiative bodes well for W3C's continued influence on Web services standards. Since developing the SOAP and WSDL specifications, W3C has not led a Web services standards effort backed by such a large number of key vendors. In the past three years, Web services standards efforts have largely been led by the Organization for the Advancement of Structured Information Standards (OASIS). Gartner expects the WS-Addressing specification to be released and tested as an open industry standard by 1H06 [0.8 probability]... Initial implementations will most likely be complex, given the wide range of communication interactions with which WS-Addressing is designed to operate... Businesses and vendors interested in expanding their Web services communications beyond the limitations of existing protocols should monitor the activities of W3C's WS-Addressing technical committee. Those with a high level of interest and with the necessary resources should consider participating in the committee's work..."

  • [August 10, 2004]   WS-Addressing Specification Presented to W3C as a Member Submission.    The Web Services Addressing (WS-Addressing) specification has been presented to W3C as a Member Submission by BEA, IBM, Microsoft, SAP AG, and Sun Microsystems. WS-Addressing provides transport-neutral mechanisms to address Web services and messages. Specifically, the specification defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. The specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner." The endpoint references defined in the specification serve to "identify the message destination; the message information headers allow the specification of endpoint references within messages, along with a way to relate messages to each other." The authors of the submission request that the W3C Consortium "start a Working Group whose mission is to produce a W3C Recommendation for Web Services Addressing by refining WS-Addressing based on consideration of the importance of this component in the Web services architecture, implementation experience, and interoperability feedback." The five companies identified as copyright holders have agreed to "offer licenses according to the W3C Royalty-Free licensing requirements for any portion of the Submission that is subsequently incorporated in a W3C Recommendation." According to the W3C Staff Comment, the new submission on the topic of Web services references and message delivery highlights the community's interest in this area; the W3C is considering creating a Working Group to address this important area of the Web services architecture." W3C invites feedback on this technology contribution.

  • [August 10, 2004] "WS-Addressing and WS-MessageDelivery." From Dave Orchard's Blog (July 29, 2004). "I thought I'd write up and share a fairly quick comparison of WS-Addressing and WS-MessageDelivery. I wrote this up to help some of our folks do a comparison, and it might be useful to other folks... The SOAP Headers are very similar, matching up almost exactly. The WS-Addressing specification relies on the contents of run time messages to implicitly define message exchange patterns when just WS-Addressing is used and WS-Policy for interactions that are WS-Addressing dependent. For example, WS-ReliableMessaging uses WS-Addressing, and WS-RM is attached to a Web service by WS-Policy statements. WS-Addressing uses Endpoint References for refering to service instances. WS-MD provides WSDL extensions and features and properties for a number of it's functions. To a certain extent, WS-Addressing as part of the WS-* stack uses WS-Policy for extensibility and WS-MD uses features and properties for extensibility. WS-MD uses a WS-Ref structure to identify service instances..."

  • [April 26, 2004]   WS-MessageDelivery Specification Integrates with WSDL Message Exchange Patterns.    W3C has acknowledged receipt of a WS-MessageDelivery Version 1.0 specification which defines an abstract set of message delivery properties enabling message delivery for Web services that utilize Message Exchange Patterns associated with WSDL documents. The W3C Member Submission has been prepared by Oracle, Arjuna, Cyclone Commerce, Enigmatec, IONA, Nokia, SeeBeyond, and Sun Microsystems. According to the W3C staff comment, the WS-MessageDelivery proposal is similar to the WS-Addressing proposal from BEA, IBM, and Microsoft: "while addressing the same scope as the WS-Addressing document, WS-MessageDelivery is more fully integrated with WSDL, by defining its relations with the WSDL Message Exchange Patterns or by introducing a WSMD description for WSDL. It also follows the current work of the W3C Web Services Description Working Group, and the service references introduced in WSDL 2.0. WS-Addressing, while relying on the WSDL concepts, does not use the WSDL service element as a service reference. WS-MessageDelivery relies on the implicit open content model of WSDL for extensions, while WS-Addressing uses an explicit 'reference properties' extension mechanism." The WS-MessageDelivery Version 1.0 specification abstract summarizes: "[This] specification defines a mechanism to reference Web services (WSRef), essential abstract message delivery properties (AMDP), a SOAP binding for those properties, and the relationship of those properties to WSDL definitions and message exchange patterns. These properties enable SOAP messages to be transport independent — extending messaging capability to use separate transport protocol sessions or even using different transport protocols within the context of a message exchange pattern (MEP). Message delivery details are surfaced to the application layer, extending SOAP processors to use a wider range of message patterns and transport protocols to accomplish a Web service interaction. The abstract message delivery properties include web service references, message identification and message references. This specification outlines in detail how to build message exchange patterns consistent with WSDL 1.1 or WSDL 2.0 using the definitions in the specification. The semantics and mapping for the Callback Pattern, a commonly used message exchange pattern as a composite pattern, is defined. The Web service References (WSRef), Abstract Message Delivery Properties and a SOAP binding are designed for interoperability and extensibility." The submission request provides royalty-free license terms from the eight sponsor companies for use of the WS-MessageDelivery technology.

  • [April 26, 2004] "Moving from WS-Routing to WS-Addressing Using WSE 2.0." By Aaron Skonnard. In Microsoft MSDN Library (April 26, 2004). Skonnard discusses issues surrounding Web services routing and the need for transport-neutral addressing, specifically focusing on the move away from WS-Routing towards the new WS-Addressing specification. Core WS-Addressing concepts and implementing secure routing with Web Service Enhancements 2.0 are shown. "As an improvement to WS-Routing, WS-Addressing provides a transport-neutral mechanism for addressing Web services. WS-Addressing formalizes the simplification of WS-Routing and adds a few additional features. WS-Addressing officially drops the WS-Routing elements related to message paths and assumes users will rely on the 'next hop' approach for routing needs. Most of the elements defined by WS-Addressing are semantically equivalent to those originally defined in WS-Routing. The article relates to Web Services Enhancements 2.0 for Microsoft .NET, the WS-Routing specification, and the WS-Addressing specification. Microsoft WSE 2.0 provides full support for WS-Addressing and 'next hop' routing..."

  • [April 15, 2004]   Systinet WASP Server for Java Supports WS-Addressing and WS-ReliableMessaging.    Systinet has announced the availability of WASP Server for Java 5.0 Beta, featuring new functionality and standards support. Systinet's WASP Server for Java is a "modular, easy to use, high performance Web services runtime environment for creating, deploying and managing Web services in Java and J2EE applications. WASP implements the latest SOAP, WSDL, UDDI and Java standards such as JAX-RPC, JAXM, and SAAJ. The WASP Server for Java 5.0 Beta provides reliable messaging with WS-ReliableMessaging support, including one-way, synchronous (request/response), and asynchronous messaging. WASP offers message persistence, support for multiple exchange patterns, and API or policy-based configuration. WASP also fully supports the WS-Addressing specification, which defines transport independent addressing and enables the creation of reliable, asynchronous Web services. The WASP administration console has been redesigned and extended to make Web service configuration, management, and testing even easier. New functionality includes an HTML Invocation Console that automatically creates HTML forms from WSDL definitions for testing deployed Web services. WASP now fully integrates with Netegrity SiteMinder so that it can accept security information propogated by Netegrity using a wide range of authentication credentials."

  • [April 14, 2004] "WS-Addressing Additions and Updates." By Omri Gazitt and David Langworthy. From Microsoft MSDN Library. April 2004. 8 pages. "This overview describes additions and changes in the WS-Addressing specification since original publication in 2003, and includes examples and implementation considerations not contained in the specification. The new specification adds fault codes, a WSDL binding, and explicit direction on formulating the request-reply message exchange pattern. WSDL processors require an inbound message be mapped to an input of an operation. WS-Addressing defines two mechanisms to accomplish this: a default pattern and an explicit annotation. The default pattern allows services that use WSDL to adopt WS-Addressing without modification. Explicit annotation allows direct control over the Action to WSDL mapping. This control may be used to promote factoring and reuse in to a greater degree than natively supported in WSDL. It may also be used to allow a new version of a service to continue to accept messages from a prior version. WS-Addressing defines five (5) new fault codes with explicit bindings to SOAP 1.1 and 1.2 fault messages. The fault messages are: Invalid Message Information Header; Message Information Header Required; Action Not Supported; Destination Unreachable; Endpoint Unavailable..."

  • [April 06, 2004] "The Hidden Impact of WS-Addressing on SOAP. Is the SOAP Standard in for a Shake-Up?" By Doug Davis. From IBM developerWorks (April 06, 2004). "About a year ago, IBM, BEA, and Microsoft put out a new specification called WS-Addressing. At only 14 pages, it doesn't claim to do anything more than to help standardize the way people specify the location of a Web service. So the WS-Addressing protocol might not seem like much at first glance. However, WS-Addressing has the potential to radically change the SOAP processing model. WS-Addressing establishes message information headers that will make new Web services message flow patterns possible — and that's something that will have a profound impact on SOAP engines and the future of the SOAP protocol itself. WS-Addressing [provides standardization] through the definition of EPRs and MI headers. This definition provides a single mechanism through which people are able to specify both the location of a Web service and the ways in which services use those EPRs in SOAP messages. But it's the implied changes in the message processing model/flow that have even more important implications for SOAP. WS-Addressing's importance will grow over time — so much so that it will be viewed as one of those specifications that should have been part of the core SOAP specification itself. IBM's Emerging Technologies Toolkit contains several demos that use the WS-Addressing specification. In particular, the Web-based WS-ReliableMessaging demo lets you easily change the WS-Addressing headers to see how the message flow changes..."

  • [March 22, 2004]   The Growing Importance of Web Services Addressing (WS-Addressing).    Apache Addressing is an open source implementation of the Web Services Addressing (WS-Addressing) specification. It is built on top of Apache Axis, 'The Next Generation SOAP'. The announcement for Apache Addressing as an Apache Web Services Project is one evidence among several of the growing recognition that WS-Addressing is a key specification for Web Services messaging. WS-Addressing "defines two constructs that convey information that is typically provided by transport protocols and messaging systems in an interoperable manner. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. The two constructs are endpoint references and message information headers." An endpoint reference contains a Net address and an optional collection of reference properties, functioning as a "generic URI." The goal of the specification is to provide "transport-neutral mechanisms to address Web services and messages, enabling messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner." Produced as a private WS-* specification by BEA, IBM, and Microsoft, WS-Addressing was published in March 2003 and revised in May 2003. It is being implemented in WSE (Web Services Enhancements), a supported add-on to Microsoft Visual Studio .NET and the Microsoft .NET Framework. WS-Addressing normatively references WS-Policy and is referenced by a growing number of WS-* specifications.

  • [March 19, 2004] [IBM BI-ICS and firestorm]. By Anne Thomas Manes and Farrukh Najmi. Postings to OASIS 'regrep' list. Anne: "For the most part I prefer to reference standards works as opposed to private works, but I make exception for some things -- especially when they provide essential functionality AND when they contain an open copyright notice. Such is the case with WS-Addressing. WS-Addressing provides essential functionality — a standard mechanism to reference a Web service endpoint. In my opinion, it's one of the most critical WS specifications published last year. I am not aware of any competitive effort that is currently defining this type of mechanism... I also want to note that the copyright in the WS-A spec grants IPR to implement the WS-A spec — but it does not grant the right to create derivative works. So implementors need to be very cautious to implement it as a pure WS-A library..." See also the earlier posting which started the "firestorm" about proprietary standards. Farrukh Najmi was not impressed with the assertion that WS-Addressing is an open specification: "Instability of 'specifications that masquerade as pseudo-standards' (SMPS — pronouncd SIMPS?) is another good point but not the one I was emphasizing... The main point I was making is that the process is not transparent with these SMPS. Changes are slipped in without notifying the public, based upon decisions made by parties colluding behind closed doors. Such changes, decisions and the motives behind them will typically never be known to the general public... [as to WS-Addressing] there are some disturbing aspects there that should be taken into account. First of all, this same spec, same version, same date (13 March 2003) used to carry a very different notice... I would really like to know what 'commercially reasonable terms and conditions' means and why it replaces the much more common 'reasonable and non-discriminatory terms', and why you consider it so amazingly open. It seems that this language still allows them to reserve the right to impose discriminatory terms... What is most disturbing is that the specification was changed in the middle of the night, as it were, with no notice, no versioning and no date change... This is precisely one of the main problems with these type of specifications that masquerade as pseudo-standards: their authors can change them at a moment's notice and they don't have to tell anybody. There is no accountability. There is no control. Oh, and let's not forget that WS-Addressing has a normative reference to WS-Policy, which last time I checked, still carried that no-grant notice either. But wait, maybe they changed it since I last looked. Let me check... Indeed it still says: 'EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE, THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL.' So the notice is still there, but who knows what else has changed since last time we looked at it? And who knows what might change tonight?"

  • [March 10, 2004] As outlined in documents describing the refactoring of OGSI into new WSRF technical work, WS-Addressing is key to the Web Services Resource Framework: "In January 2004, the WS-Resource framework (WSRF) was proposed as a refactoring and evolution of OGSI aimed at exploiting new Web services standards, specifically WS-Addressing, and at evolving OGSI based on early implementation and application experiences. WSRF retains essentially all of the functional capabilities present in OGSI, while changing some of the syntax (e.g., to exploit WS-Addressing) and also adopting a different terminology in its presentation..." According to the Globus WSRF FAQ, "[WSRF] WS-RenewableReferences defines a conventional decoration of a WS-Addressing endpoint reference with policy information needed to retrieve an updated version of an endpoint reference when it becomes invalid." According to the OGSI-WSRF paper: "... WS-Addressing provides transport-neutral mechanisms to address Web services. Specifically, WS-Addressing specification defines XML elements to identify Web service endpoints and to include endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner. The end point reference information provides not only the address of Web service itself, but can also serve to identify state instances 'behind' the service by using endpoint reference properties. Although less central to the WS-Resource definition, WS-MetaDataExchange provides a collection of mechanisms for obtaining information about a published service, such as its WSDL description, XML Schema definitions and any other policy information necessary to use the service. Since WS-Addressing and WS-MetaDataExchange provide several capabilities that are also defined OGSI, it is beneficial to exploit those Web services specifications rather than maintaining a specification that defines the same functionality redundantly..." See Table 2, "How the Primary OGSI Constructs Map to WSRF and WS-Notification Constructs: [1] OGSI Grid Service Reference (becomes) WS-Addressing Endpoint Reference, uses the endpoint reference properties of WS-Addressing to identify a WSResource associated with the Web service at the designated endpoint. [2] Grid Service Handle (becomes) WS-Addressing Endpoint Reference and WS-RenewableReferences, WS-RenewableReferences introduces policy annotations to the WS-Addressing endpoint reference that allow 'handles' and 'handle Resolvers' to be an integrated part of the endpoint reference; use of the policy annotations provides for additional endpoint reference stability." [excerpted from "From Open Grid Services Infrastructure to WS-Resource Framework: Refactoring and Evolution"]

  • [February 11, 2004] "WS-Addressing Implementation for Apache Axis." By Davanum Srinivas (Chair, Apache Web Services Project Management Committee). "... we now have a WS-Addressing implementation for Apache Axis at http://ws.apache.org/ws-fx/addressing/. In case you did not know, there is a container project for implementing WS-* specification at http://ws.apache.org/ws-fx/..." Web site: "Apache Addressing is an implementation of the Web Services Addressing (WS-Addressing), published by the IBM, Microsoft and BEA as a joint specification, on top of Apache Axis (The Next Generation SOAP)." See the CVS repository.

  • [February 06, 2004] "Spec #1 - WS-Addressing." Steve Eichert. .NET, OO, SOA, Web Services "WS-Addressing helps to define how web services should be invoked, routed, and replied to in a transport neutral way. Rather then relying on HTTP to carry along the information necessary, we explicitly define it in the SOAP Header for our web service calls. This not only allows us to invoke web services using TCP, but it also allows us better control over how the response messages from our web services calls are handled. Rather then always returning to the address of the service/client that invoked the web service we can instead reply to another service or client. We also have the ability to customize how SOAP fault's are handled. What's cool is that using this approach we're able to introduce a lot into our architecture. Instead of limiting ourselves by always having our message response returned to the place that it was invoked from we can introduce all kinds flexibility regarding how the response is handled. We have the ability to chain web services together, and provide a dynamic pipeline for processing our message..."

  • [February 04, 2004] "I think I finally get WS-Addressing." Steve Maine. Brain.Save(), steve maine's blog. "I didn't really understand the motivation for this spec until I started thinking deeply about non-HTTP based mechanisms for moving SOAP envelopes around. I realized that when you take HTTP out of the picture, you find that there was a lot of critical dispatch metadata being carried outside of the SOAP message by the HTTP protocol itself. Without that information, it's really hard to make SOAP dispatch work. WS-Addressing embeds dispatch information that was previously carried by the transport protocol into the message itself..."

  • [February 2004] "Web Services Enhancements 2.0 Support for WS-Policy." By Simon Horrell (DevelopMentor). February 2004. From Microsoft MSDN Library. The article applies to: Microsoft ASP.NET, Web Services Enhancements (WSE) 2.0 for Microsoft .NET Technology Preview, and the WS-Policy specification. With sample code. ['This article describes support for WS-Policy in the WSE 2.0 Technology Preview, outlines the policy options available, and shows examples of their usage.'] "Microsoft recently provided support for WS-Policy in the Web Services Enhancements (WSE) 2.0 for Microsoft .NET. This article describes the policy options available in the WSE 2.0 Technology Preview and shows examples of their usage. The Microsoft Web Services Enhancements (WSE) 2.0 includes a partial implementation of the WS-Policy Framework, as well as providing support for several of the standard assertions detailed in the WS-SecurityPolicy specification, such as those that require a security token to be present in a message, or require a message to be signed and/or encrypted, or specify a message expiration time. It also allows custom assertions to be supported through the implementation of custom policy assertion handlers..." [In the example policyDocument, the MAP's action sub-element "determines which Web method within a single Web service endpoint the policy is for. It states (via its name attribute) that the associated policy applies to messages with that specific 'action' — the action element defined by WS-Addressing (which will map to the SOAPAction HTTP header for SOAP over HTTP)..."

  • [January 08, 2004] "RefProperties, Cookies and Frag-ids." By David B. Orchard (BEA Systems). From Dave Orchard's Blog. January 08, 2004. "I had some interesting thoughts on comparing reference propertes in EndpointReferences to URI fragment identifiers. EndpointReferences (EPRs) are defined in the WS-Addressing specification. Frag-ids identify a secondary resource that is related to a primary resource. In fact, they aren't even sent from the client to the server when the resource is requested, they are strictly for client-side usage. The interpretation of the frag-is governed by the media-type metadata returned wth the representation. Now a lot of web sites use HTTP Cookies for doing secondary resource identification. This can be done through session ids, ip addresses, etc. They are sent as HTTP headers. Of course, there's often some amazingly breaking of orthogonality when the application then does a getCookie to retrieve part of it's state from the header. But that's a separate article. What is interesting is that one of the main reasons that cookies are used is to identify secondary resources on a server, versus frag-ids which are under client control. WS-Addressing gives us an incredibly useful mechanism for doing secondary resource identification. An EndpointReference contains reference properties, which are required to be echoed as SOAP headers by an EPR holder whenever it communicates. Many of us call this 'SOAP cookies'. The neat thing that I was thinking about is that EPRs give us bidirectional secondary resource identification. Now the obvious comparison is with cookies — and I've been working on that — but a comparison can be made with URI frag-ids. Identifiers for secondary resources can either flow with a message (cookies, EPRs) or not (frag-ids). Given that a secondary resource identifier will flow, it's going to be in a message header or a body. I think bi-directional use of SOAP headers is a really elegent solution and enables us to bring both the power of frag-ids and cookies to both sides as well as fully utilizing XML infrastructure. But I'm leaping to the conclusion and I still need to do the a comparison of frag-ids with ref properties. In the same way that a frag-id is opaque to a server, an EPR reference is opaque to a sender. It is meant for consumption by the 'interpreter' of the reference. In an example web context, a web page links to a section of a document using a frag-id. The client invokes a GET operation and the server returns the entire representation. The refering web page also has a pretty good idea of what the media type of the retrieved representation will be. Woe to any server that doesn't ensure that the frag-ids are uniform across the media-types... In an interesting way, we've taken advantage of the decentralized ability to describe languages and protocols, and then provided the ability to specify which types are related to a specific resource and secondary resource. A Web browser doesn't need the ability to combine the frag-id for a given resource with a media-type. But this does't seem to be the case for what we're going to be doing with distributed application design, specifically the movement towards bi-directional asynchrony..."

  • [January 06, 2004] "Web Services Eventing Has Left the Building..." By Omri Gazitt (Microsoft). From Omri Gazitt's Weblog. January 06, 2004. "With WS-Addressing (my favorite WS spec), we effectively moved the message addressing information into the SOAP header, thereby decoupling the message from the transport. That was the first step towards enabling more complex message exchange patterns than HTTP's request-response model. With WS-Addressing, you have a well-defined way to do asynchronous one-way messaging, with the ability to correlate messages. WS-Eventing builds on the Addressing spec and defines how to do solicit-response (aka publish-subscribe) messaging using the Web services architecture. The thing I find most elegant about this spec is the fact that it adds no new protocol mechanism for accomplishing this beyond what's already in WS-Addressing (and the WSDL associated with the subscription management operations — Subscribe, Unsubscribe, Renew, and the SubscriptionEnd message). It does this by relying heavily on what we call the resource model for Web services. This was also defined in WS-Addressing (I told you it's my favorite spec :-)). The idea is that the organization of resources behind a Web service is opaque to the caller. There can be a single resource that 'fronts' for a bunch of other resources — which in turn can be organized hierarchically, scaled out, or employ whatever internal organization is appropriate. The caller does not (in fact should not) need to know about this internal organization. Here's how it's done. The key abstraction is that all resources are identified by a <wsa:EndpointReference> ('EPR'). This is composed of a <wsa:Address> and <wsa:ReferenceProperties>. The Address is the logical address of the service (a URI), that, with an appropriate binding, resolves to a physical address. The ReferenceProperties are pieces of state that the service uses to disambiguate subordinate resources, and are opaque to the caller. A caller obtains an EPR for the resource (for example, from an operation that the service extrudes), and sends the message to the wsa:Address field, placing that Address in the <wsa:To> SOAP header, and sprinkling in the ReferenceProperties. Upon receiving that message, the service can then route the message to the appropriate resource. This is a fairly simple pattern, yet very powerful. It enables the creation of a wide variety of implementations and architectural styles..."

  • [December 02, 2003] "3 Weeks (and a bit) of EndpointReferences." By Hervey Wilson (Microsoft). From herveyw's blog: inside wse. Part of the author's WS-Addressing Archives. "Keith and I have spent the last 3 weeks hammering through the low-level WSE 2.0 programming model: everywhere we find a URI we change it to an EndpointReference. All message sending and receiving is EndpointReference centric. As someone at work remarked 'It's the new URI'. If you haven't read through the WS-Addressing specification, here's a quick summary of what EndpointReferences are and how they are processed. Every EndpointReference contains a single Address and, optionally, ReferenceProperties. When serialized into a message, the Address becomes the <wsa:To> header and every item in the ReferenceProperties becomes a header in the <soap:Header>. The Address is the core and represents a role; it may also be a physical address. The primary WS-Addressing constructs of Destination, From, ReplyTo and FaultTo are all represented as EndpointReferences. When sending a message, the Destination is 'exploded' as above. The receiver is expected to take one of From, ReplyTo or FaultTo from the message and use them as the Destination for the response, subsequent one-way message or fault: (1) From identifies the sender. In the absence of either ReplyTo or FaultTo, this is the default destination for the response. (2) ReplyTo is an override for From. If present, the receiver should use this as the destination for the response. (3) FaultTo is an override for ReplyTo and From if the receiver generates a fault..."

  • [November 30, 2003] "Musings on WS-Addressing." By Benjamin Mitchel (Microsoft). From benjaminm's blog: Indigo, web services and extreme programming. "... The WS-Addressing specification provides a way of placing all of the addressing information inside the SOAP header. Is provides an XML syntax that can be used in the SOAP Header to describe message destinations. It uses the concept of endpoint reference to describe a destination that a message can be targeted at. The endpoint reference contains the address of the endpoint, as well as extra information that can be useful when sending messages such as the message identifier, and any other properties that may be useful when processing a message (such as message correlation, or session information). There is also the concept of a different address for the reply and fault information... The article also highlights the major problem with WS-Addressing: while it's useful to be able to put the address on the enveloped there's still more work to be done to define how to bind the address onto the protocol. In the article [Expanding the Communications Capabilities of Web Services with WS-Addressing on MSDN] they use a simplified version of the SOAP Version 1.2 Email Binding by changing the content type of the message to make it easier for Outlook to read the email and removing the need for email headers that are already contained in the WS-Addressing policy. This is fine, but how interoperable is it, or what is being done to improve the Email Bindings to make the solution interoperable? There's still work to be done to put the Address in WS-Addressing. So, we're not quite there yet with WS-Adressing. For one thing, WS-Addressing it doesn't say anything about the content of the address. It just says it has to be a URI, and that this may be a network or logical address. This has the benefits of flexibility for the specification, but this needs to be defined for the specification to be implemented... The WS-Address specification leaves it up to the protocol bindings to say how the logical address is translated into a physical network address: When a message needs to be addressed to the endpoint, the information contained in the endpoint reference is mapped to the message according to a transformation that is dependent on the protocol and data representation used to send the message. Protocol specific mappings (or bindings) will define how the information in the endpoint reference is copied to message and protocol fields. Marting Gudgin tells me via email that resolving a logical address to a physical network address on a particular protocol isn't specified by the WS-Addressing specification, but might be done via a local configuration file or talking to the equivalent of a DNS server. WSE 2.0 Tech Preview has a mechanism using local referral cache xml files that can translate logical addresses into a physical address. However, the problem still remains — at some point a physical address is needed..."

  • [October 2003] "'Indigo': The Web Services Protocols And Architecture." By Omri Gazitt (Product Unit Manager, Advanced Web Services, Microsoft). Session Code: WSV 404. Presented at Microsoft PDC 2003. Slides 12-17 cover WS-Addressing and the Resource Model. The Messaging (specification layer) includes SOAP, URI, and WS-Addressing. "WS-Addressing: (1) WS-Addressing provides mechanisms for addressing resources: shipping those addresses in messages, addressing messages to those resources; (2) Addressing mechanisms are transport-neutral; (3) Resources are not constrained — can be constructed, partitioned, named, addressed in arbitrary fashion; (4) Internal resource organization is opaque... The Endpoint Reference (EPR) = Address + Reference Properties, and is a 'Generalized URI'..." Session description: "The Web Services Protocols and Architecture Web Services are the foundation for the way developers will build distributed applications going forward. 'Indigo' is Microsoft's programming model and framework for building connected applications and Web services, and is built on top of the WS protocols, a suite of specifications that will power the next phase of the Internet, much like TCP and HTTP powered the Web we have today. Learn about the architecture behind this protocol framework, and drill into the specifications: Security, Transaction, Reliable Messaging, Addressing, and Policy. See how vertical infrastructures can be built on top of this architecture."

  • [October 2003] "Expanding the Communications Capabilities of Web Services with WS-Addressing. Making Web Services Intermediary-Friendly, Asynchronous, and Transport-Neutral." WS-Addressing in Practice: The SoapMail Sample Application. By John Shewchuk, Steve Millet, Hervey Wilson, and Damon Cole (Microsoft). Microsoft MSDN Library. October 2003. 16 pages. ['Explore several scenarios that are difficult to build using today's standard HTTP-based Web services. Then examine how you can use WS-Addressing to construct solutions.'] "Recently BEA, IBM, and Microsoft introduced the WS-Addressing specification that significantly increases the range of scenarios where Web services can be employed. While WS-Addressing has many uses, here we focus on how WS-Addressing enables the following: (1) Web service-based communication that is secure and end-to-end even in the presence of intermediaries such as firewalls or Network Address Translation (NAT)-based routers; (2) Web services that support a much broader range of transport protocols, including SMTP; (3) Fully asynchronous communication; for example, support for intermittent connectivity and long-running communication; (4) Event-based communication. To illustrate these capabilities, we explore several scenarios that are difficult to build using today's standard HTTP-based Web services, and then we examine how WS-Addressing can be used to construct solutions. To further illustrate how WS-Addressing can be used in practice, we provide a sample application called SoapMail. SoapMail shows how to use WS-Addressing to enable SOAP messaging over email protocols. Furthermore, we show how to use SoapMail as an email-to-HTTP protocol translator for SOAP messages that contain WS-Addressing headers. The SoapMail case study is especially interesting because this simple email-to-HTTP protocol translator can be used to provide easily accessed global names for Web services located behind intermediaries and to transform automatically (no code required) existing request/response Web services into fully asynchronous Web services supporting mobile/intermittent connections... WS-Addressing has many uses as we have described in this article: how WS-Addressing enables secure, end-to-end Web services communication, even in the presence of intermediaries such as firewalls or Network Address Translation (NAT)-based routers; how Web services support a broad range of transport protocols, including SMTP; how WS-Addressing enables fully asynchronous communication such as intermittent connectivity and long-running communication; and how it enables event-based communication. These new capabilities significantly expand the scenarios that SOAP can address..."

  • [September 2003] "Secure, Reliable, Transacted Web Services: Architecture and Composition." By Donald F. Ferguson (IBM Fellow and Chairman; IBM Software Group Architecture Board) Tony Storey (IBM Fellow), Brad Lovering (Microsoft Corporation Distinguished Engineer), and John Shewchuk (Microsoft Web Services Architect). With credits to 66 contributors. In Microsoft MSDN Library. See the section on WS-Addressing, excerpted above.

  • [September 25, 2003] "Making Sense of Web Services Standards." By David Orchard. BEA Systems technical report. September 25, 2003 . "Delivery [in the context of Web Services Standards] is about how a message is sent between services... Delivery [includes] asynchrony, addressing, and routing. One of the promising aspects of Web services is asynchrony; that is, the ability to deliver responses and messages without an existing connection, so that a service consumer's and provider's execution is decoupled. WS-Addressing defines basic mechanisms for asynchronous messaging; in particular, the Reply-To header allows a "callback" to be performed. WS-Addressing also specifies how addressing information (typically used for routing) should be conveyed in a SOAP message, by defining common headers such as message identifiers and to and from fields. Finally, WS-Addressing provides an EndpointReference structure that can contain information about Web service endpoints. An endpoint, which is defined in WSDL 1.2 and is renamed from WSDL 1.1 Port, is an access point of a Web service. It can contain information that is required to access or reference the service, such as a conversation ID. It is often necessary to exchange endpoint references, particularly for callbacks and long-running conversations. In the future, there will be a WS-EndpointResolution specification that will enable two parties to negotiate or refine EndpointReferences..." See also the author's article "Achieving Loose Coupling," on the topic of asynchrony: "We've also been articulating a need for asynchrony for Web services for many years, exemplified by Adam Bosworth... Remembering our definition of coupling, asynchrony reduces the dependency between components by allowing a component to not 'wait' for another component. There is a trade-off between space and time with respect to coupling. Asynchrony allows one component be decoupled in time from another, but it does require that additional coupling in space. The coupling in space is that a sender, wanting to receive an asynchronous callback, must open up its address 'space' to the callback sender. In many cases, such as the Web, the sender either doesn't do this - why much of the Web is synchronous - or the sender uses email to provide a space for subsequent callbacks. Much of Web services is about multiple complex servers communicating with each other, and so it is appropriate to move towards opening up the address space instead of being coupled in time. BEA Systems did some early work on defining asynchronous headers for SOAP in SOAP-Conversation and WS-Callback. We're really excited to now see adoption of WS-Addressing. WS-Addressing defines a 'ReplyTo' SOAP header block for asynchronous messaging. We anticipate widespread deployment of WS-Addressing and it's asynchronous features. Asynchrony is one of the final pieces in delivering loosely coupled components, and we are closing in on being able to repeatedly build systems using asynchrony..."

  • [July 15, 2003] "Programming with Web Services Enhancements 2.0." [Cited by] Edwin Khodabakchian. Tuesday, July 15, 2003. Organic BPEL Blog from Collaxa. "One of the changes between WSE 1.0 and WSE 2.0 is the support for WS-Addressing. WS-Addressing largely replaces the capabilities of the WS-Routing specification that was supported in WSE 1.0. Instead of focusing on routing paths, WS-Addressing functionally provides a mechanism for adding To and From headers to a SOAP envelope. There is also support in WS-Addressing for an Action header, a ReplyTo header and a FaultTo header. The Action header is similar to the SOAPAction HTTP header that is often used for SOAP messages send with HTTP. In the case of .asmx Web services, the HTTP SOAPAction header is used to determine which Web method of a service should be invoked for an incoming message. Similarly the Action SOAP header will be used for determining functions to call for messages received over non-HTTP transports..." Collaxa's Take: "With the support of WS-Addressing and TCP messaging, Microsoft is making asynchronous peer-to-peer conversations a first class citizen of the .Net infrastructure. Note: WSE 2.0 support for WS-Addressing dramatically simplifies bi-directional interactions between C# clients and BPEL processes hosted on the Collaxa Orchestration Server."

  • [July 2003] "Programming with Web Services Enhancements 2.0." By Matt Powell (MSDN Web Services). From the Microsoft MSDN Library. This article applies to Web Services Enhancements 2.0 for Microsoft .NET. [Example: a simple distributed version of the old Rock Paper Scissors game, now made secure and distributed with WSE 2.0] "WSE 2.0 Addressing: One of the changes between WSE 1.0 and WSE 2.0 is the support for WS-Addressing. WS-Addressing largely replaces the capabilities of the WS-Routing specification that was supported in WSE 1.0. Instead of focusing on routing paths, WS-Addressing functionally provides a mechanism for adding To and From headers to a SOAP envelope. There is also support in WS-Addressing for an Action header, a ReplyTo header and a FaultTo header. The Action header is similar to the SOAPAction HTTP header that is often used for SOAP messages send with HTTP. In the case of .asmx Web services, the HTTP SOAPAction header is used to determine which Web method of a service should be invoked for an incoming message. Similarly the Action SOAP header will be used for determining functions to call for messages received over non-HTTP transports. We will also be taking advantage of the ReplyTo header in our Rock Paper Scissors application in order to determine where to send the next message. When one of the peer applications sends the one-way RegisterPlayer message to the RPSService, they will specify a ReplyTo endpoint that will indicate where an opposing player should send their messages when peer-to-peer communications start. Similarly when a second peer application sends a FindPlayer message to the RPSServer, the RPSServer returns a message with a ReplyTo header indicating the first peer application's endpoint. This tells the second peer application that it should send its next message to the first peer application's endpoint. We continue specifying the ReplyTo header in the remaining peer-to-peer messages in order to always indicate where the next message should be addressed..."

  • [April 15, 2003] "Making Sure Web Services Get Along. Specs Complete a Framework for Reliable, Interoperable Messaging." By Edward J. Correia. In Software Development Times (April 15, 2003). "BEA Systems Inc., IBM Corp., Microsoft Corp. and TIBCO Software Inc. in mid-March published a pair of new specifications the companies claim will improve the reliability and interoperability of messaging for Web services... WS-Addressing defines the use of message headers to identify and exchange references to Web services end points. The companies claim that both specs interoperate with existing messaging systems through SOAP bindings and other methods. John Kiger, BEA's director of Web services strategy, claimed the specs fill an important gap in enterprise Web services... Steven VanRoekel, Microsoft's director of Web services, called the specs a turning point for the interoperability of Web services... VanRoekel explained how WS-Addressing also removes concerns of transportation from developers. 'We take the transport-dependent infrastructure in addressing — normally SOAP over HTTP — and put it into the message. So as a message traverses the Internet, it can come back to the original sender because the addressing information is in the message. This makes the message transport-independent.' BEA's Kiger said WS-Addressing also fills the critical role of identifying participants in asynchronous Web-service dialogs and of maintaining their connections. 'Each time a Web service is accessed, an instance of that Web service is created. Enterprise Web services with a lot of volume might have 10 or 20 instances handling requests. In a dialog where there are multiple messages and multiple instances, it provides a way of ensuring that each instance can maintain state so that each message is seen in the context of messages that preceded it.' The net result, Kiger said, is a standardized method of more easily implementing stateful interactions. 'WS-Addressing provides a way to get from the WSDL address of the Web service to the specific address of the instance that's providing that service, so that subsequent messages in the asynchronous dialog can be directed to the instance that handled the initial request.' According to Microsoft's VanRoekel, the first likely implementation of the specs will be in Microsoft's Web Services Enhancements for Microsoft .NET (WSE) tool sometime later this year. 'WSE allows developers to get an early look and feel at the specifications and to start using them in their advanced Web services projects,' he said..."

  • [March 13, 2003] "New Web Services Specifications for Reliable Messaging and Addressing." From the Cover Pages. March 13, 2003. "Two new specifications have been published as part of the Global XML Web Services Architecture (GXA) platform being developed by Microsoft, IBM, and others. The Web Services Reliable Messaging Protocol (WS-ReliableMessaging) specification from BEA, IBM, Microsoft, and TIBCO "allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures... The Web Services Addressing (WS-Addressing) specification from BEA, IBM, and Microsoft "provides transport-neutral mechanisms to address Web services and messages. Specifically, this specification defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner."

  • [March 13, 2003] "Microsoft, IBM, BEA and TIBCO Announce Reliable Messaging Specifications. Publication of WS-ReliableMessaging and WS-Addressing Signifies Milestone In Development of Web Services Architecture." - "Microsoft Corp., IBM Corp., BEA Systems Inc., and TIBCO Software Inc. today announced the publication of two new specifications to enable organizations to build reliable and interoperable Web services applications. The new specifications, WS-ReliableMessaging and WS-Addressing, along with a high-level road map authored by IBM and Microsoft titled "Reliable Message Delivery in a Web Services World: A Proposed Architecture and Roadmap," describe a common architecture comprising the necessary protocols, message formats and interfaces to enable reliable message delivery for Web services... The ability to ensure the delivery of a message is a critical component of Web services. By proposing a standard mechanism for exchanging secure, reliable messages in a Web services environment, organizations will no longer be faced with the need to develop costly, ad hoc solutions that are unable to interoperate across platforms to address reliability. The following specifications define protocols that are independent of the underlying transport layer. Each specification defines a SOAP binding for interoperability across platforms... WS-Addressing, published by IBM, Microsoft and BEA, provides mechanisms to identify and exchange references to Web services end points. In addition, it defines a set of commonly used message information headers. Together, these elements enable transport-neutral, bidirectional, synchronous, asynchronous and stateful service interactions across networks that include the likes of end point managers, firewalls and gateways... In addition to the newly published specifications, IBM and Microsoft are publishing a white paper to provide a high-level overview and road map for reliable Web services communications. Titled "Reliable Message Delivery in a Web Services World: A Proposed Architecture and Roadmap," the white paper employs a common scenario with examples of real-world applications to identify key requirements that must be addressed in the advanced Web services architecture. It also introduces the core reliable messaging protocol and positions it with other Web services specifications such as the WS-Policy and WS-Security families that are required to provide a complete solution. In addition, the white paper identifies other messaging requirements to increase the number of customer scenarios supported, such as flow control and metadata exchange..."
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/ws-Addressing.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org