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
|
| News: Cover Stories |  |  |
| WS-Addressing Specification Presented to W3C as a Member Submission. |
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."
Contents
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.
An earlier version of the Web Services Addressing (WS-Addressing) specification from BEA, IBM, and Microsoft was published on March 13, 2003 and was re-issued with modifications in May 2003, though carrying the same "13 March 2003" publication date. An update was issued in March 2004. These versions of WS-Addressing, as well as the recent August 10, 2004 version, represent proprietary design specifications intended for review and evaluation only. SAP AG and Sun Microsystems are now also named as joint authors and copyright holders on the W3C Submission document.
The Web Services Addressing (WS-Addressing) specification defines technology that overlaps in part with Web Services Description Language (WSDL) Version 2.0, SOAP, and the WS-MessageDelivery Specification.
Web Services Addressing (WS-Addressing). W3C Member Submission. 10-August-2004. Edited by Don Box (Microsoft) and Francisco Curbera (IBM). Version URL: http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/. 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), and Eduardo Gutentag (Sun Microsystems, Inc.)
Acknowledgements: Keith Ballinger (Microsoft); Michael Coulson (Microsoft); Giovanni Della-Libera (Microsoft); Christopher Ferris (IBM); Tom Freund (IBM); Steve Graham (IBM); Christoph Hofmann (SAP); Maryann Hondo (IBM); Efim Hudis (Microsoft); John Ibbotson (IBM); Gopal Kakivaya (Microsoft); Al Lee (Microsoft); Anthony Nadalin (IBM); Bill Nagy (IBM); Martin Nally (IBM); Henrik Frystyk Nielsen (Microsoft); Jeffrey Schlimmer (Microsoft); Vladimir Savchenko (SAP); Chris Sharp (IBM); Keith Stobie (Microsoft); Vladimir Videlov (SAP); Volker Wiechers (SAP); Hervey Wilson (Microsoft).
Earlier versions of WS-Addressing:
The W3C's Team Comment on the WS-Addressing Submission compares WS-Addressing to other work being done under the W3C Web Services Activity and to the WS-MessageDelivery specification presented to W3C as a Member Submission by Arjuna Technologies Ltd., Enigmatec Corporation Ltd., Hitachi, IONA Technologies, Inc., Nokia Corporation, Oracle, SeeBeyond, Sonic Software, and Sun Microsystems, Inc. W3C notes that the WS-Addressing [policy] property specifically uses the WS-Policy specification (another proposal by BEA, IBM, Microsoft, and SAP AG). Excerpts from the Team Comment:
Relationship to Web Services Description Language (WSDL) Version 2.0:
"... the endpoint reference description and the [action] property defined by WS-Addressing are related to the description of a Web service that may be expressed in a WSDL 2.0 document...
In WS-Addressing, an endpoint reference is presented as a complement to the concept of a WSDL service. The [selected port type] and [selected port] properties correspond to those of the WSDL 1.1 Member Submission description of a service, and the [action] property is derived from this description.
However, WS-Addressing does not specify its relationship to WSDL 2.0. We note that the mechanisms used by WS-Addressing to reference WSDL components differ from the mechanisms introduced by WSDL 2.0 to reference WSDL constructs.
WS-Addressing may be used in a message exchange described by a WSDL document. It would be useful to document the relationship between the values of the message information headers and the WSDL components of the description, in particular when WS-Addressing is used in the context of the WSDL 2.0 predefined message exchange patterns..." Relationship to SOAP:
A binding of message information headers to SOAP is provided, both to the SOAP 1.2 Recommendation and to the SOAP 1.1 submission.
However, the binding to SOAP 1.2 does not define WS-Addressing as a SOAP 1.2 module as it does not define a URI in order for WS-Addressing to be referenced in description languages (such as WSDL 2.0) or during negotiation. Also, WS-Addressing's [action] property can be directly mapped to SOAP 1.2's SOAP Action Feature's action property.
It is also worth noting that WS-Addressing does not define how the message information headers' abstract properties could be serialized out of the SOAP envelope when the SOAP message is bound to the HTTP underlying protocol. Considering the SOAP 1.2 HTTP binding which supports the SOAP Action Feature, the [action] property can be carried in the action parameter. For HTTP requests, the [destination] property may be carried by the HTTP/1.1 Request URI..." Relationship to the WS-MessageDelivery Specification:
"It is interesting to compare this submission to the WS-MessageDelivery Submission. For example, WS-Addressing defines a [policy] endpoint reference property to carry policy statements, while WS-MessageDelivery does not. Also, while WS-MessageDelivery takes an approach which is derived from WSDL for referencing Web services, WS-Addressing is providing a SOAP extension using a more lightweight description..."
WS-Addressing is an important specification because the functionality it defines is relevant to a growing number of Web Services specifications, including many from the Microsoft/IBM/* WS-* suite. The WS-Addressing specification makes normative use of WS-Policy. As of August 2004, we read that several other (WS-*) specifications make (normative) reference to WS-Addressing. Examples:
"WS-Addressing helps enable organizations to build reliable and interoperable Web services applications by defining a standard mechanism for identifying and exchanging Web services messages between multiple end points. With a standard way to express where a message should be delivered in a Web services network, developers are able to simplify Web services communication and development and avoid the need to develop costly, ad hoc solutions that are often difficult to interoperate across platforms.
With today's acknowledgement by the W3C, the joint submission of WS-Addressing represents a milestone in the collaboration among BEA, IBM, Microsoft, SAP and Sun to further advance Web services technology. Backed by significant industry support, the submission of WS-Addressing is also a part of a longer term effort to provide a standards-based foundation for the development of secure, transacted, asynchronous and reliable Web services.
WS-Addressing is a key part of the core Web services architecture. In particular, the specification is designed to underlie other specifications, such as WS-ReliableMessaging, WS-Federation and WS-AtomicTransaction, providing a consistent, interoperable and standards-based mechanism for Web services addressing.
The submission also further demonstrates all the co-authors' commitment to the development of open industry standards to drive widespread adoption of Web services. With the intent of easing adoption, the co-authors will not charge royalties in conjunction with WS-Addressing. The co-authors of this specification look forward to future collaboration in bringing together a cohesive Web services architecture..." [source]
"Web Services Addressing (WS-Addressing) defines two interoperable constructs that convey information that is typically provided by transport protocols and messaging systems. 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 (referenceable) 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 convey 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..." [from the Introduction]
Endpoint References: The WS-Addressing 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 complement 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..." [from Section 2]
Message Information Headers: WS-Addressing Section 3 defines the model and syntax of a message information header. The message information headers collectively augment a message with the following abstract properties. These properties enable the identification and location of the endpoints involved in an interaction. The basic interaction pattern from which all others are composed is 'one way'. In this pattern a source sends a message to a destination without any further definition of the interaction.
Request Reply is a common interaction pattern that consists of an initial message sent by a source endpoint (the request) and a subsequent message sent from the destination of the request back to the source (the reply). A reply can be either an application message, a fault, or any other message. The properties [defined] support one way, request reply, and any other interaction pattern...[Section 3]
: 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...' [See the complete text of Newcomer's commentary online. Dave Chappell: "The WS-Addressing specification has been submitted to the W3C by the joint authors. While this marks a significant step forward in the 'standardization' of the WS-* stack of specs, this is only the first step in the development/ratification of the spec within the W3C process. The submission in its current state is referred to as a 'Member Submission'. This means that WS-Addressing has now become more 'standard-y' than it was before, but not much more... One of the next steps that would logically follow is the formation of a Working Group. Sometime after that it eventually comes out the other side as a W3C Recommendation (with many steps in between).
The concept of addressing is something that most of the other Web services specs rely on. WS-Addressing specifies an interoperable EndPoint Reference (EPR) in the form of SOAP header information. The EPR contains information about where messages come from, where they should go, and where to send them when they are bad :) More specifically, the spec defines headers such as MessageID, From, To, ReplyTo, and FaultTo.
I'm feeling very positive about this. Because WS-Addressing has been considered proprietary, it has been a bone of contention within other standards efforts such as WS-BPEL and WS-Notification within OASIS. WS-BPEL decided to abstract the concept so they didn't have the direct dependency. In the WS-Notification Technical Committee (TC), we have been faced with possibly making the same decision..."
Reference: "WS-Addressing Submitted to W3C." By Dave Chappell (Sonic Software). From O'Reilly Developer Weblogs (August 10, 2004). Marc Andrue Goodner: "This specification defines a transport neutral way to address Web services and messages, which facilitates sending messages through networks that include monitors, firewalls or other potential intermediaries. From a developer's point of view what is more relevant to understand is that this specification enables other higher-order Web services specifications that provide capabilities like transactions, reliable messaging and security. Many of the WS-* set of specifications have in fact already committed to using WS-Addressing, so it's submission to the W3C for standardization is an important milestone. The W3C is the most logical place for this work to take place as that organization deals with many of the related specifications (HTTP, URI, SOAP), particularly at the foundational level where this spec can clearly be seen as residing.
There is a competing specification called WS-MessageDelivery (WS-MD) that was submitted to the W3C earlier this year. WS-A was first published in March of 2003 and did not make use of this or any other specification. Seeing similar specs published or submitted is a pretty normal part of the standardization process so it's common to see things like this happen. Now that both specs are at the W3C, when a work group gets chartered hopefully you will see all of the companies come together around a single specification in the open process there.
Now I also mentioned reliable messaging above as utilizing WS-A, that is true for the WS-ReliableMessaging specification that has been published as part of the WS-* set of specs. There is another specification called WS-Reliability underway at OASIS that does not use WS-A. To understand why, it is best to review the materials of the TC that produced the specification, particularly their mail archives. Hopefully the submission to the W3C of WS-A will increase adoption of it elsewhere...
... Many of the WS-* specs I mentioned make use of WS-A; until WS-A is standardized, it makes sense that they can't be either. Now many of these specs are still being worked on and are not yet ready to be submitted for standardization and you should not read too much into just one spec being submitted. Still, this is an important core specification for most of the second generation Web services specifications and its submission to the W3C is an important milestone..."
Reference: "WS-Addressing Submitted to the W3C." By Marc Andrue Goodner (SAP). SAP Developer Network. August 10, 2004.
- WS-Addressing Submission Request to W3C
- Web Services Addressing (WS-Addressing). W3C Member Submission 10 August 2004.
- Team Comment on the WS-Addressing Submission. Prepared by Hugo Haas, W3C Web Services Activity Lead.
- "BEA, IBM, Microsoft, SAP and Sun Microsystems Submit WS-Addressing Specification to W3C for Standardization. It is a Milestone in Enabling Customers to Build Interoperable Web Services Applications." Joint announcement August 10, 2004. [source, Microsoft]
- W3C Royalty-Free (RF) Licensing Requirements. The five companies submitting the WS-Addressing specification agree "to offer licenses according to the W3C Royalty-Free licensing requirements described in section 5 of the 5 February 2004 W3C Patent Policy for any portion of the Submission that is subsequently incorporated in a W3C Recommendation."
- Acknowledged Member Submissions to W3C
- WS-* specifications make (normative) reference to WS-Addressing. See the provisional listing of WS-* specifications that depend upon WS-Addressing.
- W3C contact for the WS-Addressing Member Submission: Hugo Haas, W3C Web Services Activity Lead.
- Contacts for the WS-Addressing submission (inquiries from the public or press about the submission): Susan Siegel (BEA Systems), Ron Favali (IBM), Dave Mendlen (Microsoft), Andrew Kisslo (SAP), and Jacquelyn Decoster (Sun Microsystems, Inc.)
- Mail Archives for W3C public list 'www-ws@w3.org' "This forum is for general discussion of Web services."
- Web Services Architecture. W3C Working Group Note 11 February 2004.
- Addressing/Referencing for Web Services Charter Discussions. Posting from Jeff Mischkinsky (Oracle) 2004-08-09.
- Proposed Draft Charter for W3C Web Services Addressing and Referencing Framework Working Group. June 02, 2004. Presented as an Open Letter by Steve Caughey, Arjuna Technologies Ltd; Dale Moberg, CycloneCommerce, Inc; Duncan Johnston-Watt Enigmatec Corporation, Ltd; Masahiko Narita, Fujitsu Limited; Tadashi Yamagishi, Hitachi, Ltd; Eric Newcomer, Iona Technologies, Inc; Fumio Onimaru, NEC Corporation; Art Barstow, Nokia Corporation; Jeff Mischkinsky, Oracle Corporation; Ugo Corda, SeeBeyond Technology Corporation; Eduardo Gutentag, Sun Microsystems, Inc.
- WS-Addressing specification/announcement company URLs:
- Press and Commentary:
- Submission of WS-Addressing to W3C. Technical Commentary by Eric Newcomer (IONA). August 27, 2004.
- "Vendors' Choice of W3C Raises WS-Addressing's Profile." By Charles Abrams. Gartner Research Technical Report. Reference ID Number: FT-23-6913. August 17, 2004. [PDF, cache]
- "Competitors Join to Submit WS-Addressing Specification." By John K. Waters. In Application Development Trends (August 16, 2004).
- "WS-Addressing Submitted to W3C." By Dave Chappell (Sonic Software). From O'Reilly Developer Weblogs (August 10, 2004). See excerpt above.
- "WS-Addressing Submitted to the W3C." By Marc Andrue Goodner (SAP). SAP Developer Network. August 10, 2004. See excerpt above. [blog link, registration required]
- "Sun, Microsoft Join on Web App Standard." By David Becker. From CNET News.com (August 10, 2004).
- "Update: WS-Addressing Specification Submitted to W3C. Potential Standard Helps Exchange Data Between Applications." By Joris Evers. In InfoWorld (August 10, 2004).
- "IBM, MS, Sun Promote Web Services Specifications." By Jay Lyman. From TechNewsWorld (August 11, 2004).
- "WS-Addressing Specification Submitted to W3C For Standardization." Web Services Pipeline from CRN (August 11, 2004).
- "Web Services: IT Leaders Collaborate on Web-Services Specification." By Jay Wrolstad. In CIO Today (August 11, 2004).
- "WS-Addressing and WS-MessageDelivery." By Dave Orchard (BEA). From Dave Orchard's Blog (July 29, 2004).
- Key Reference Documents:
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
