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 |  |  |
| IBM Submits Web Services Polling (WS-Polling) Specification to W3C. |
Contents
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). WS-Polling defines a SOAP 1.2 module, so that when using WS-Polling for holding messages, with HTTP a service can return a 202 Accepted HTTP status code. WS-Polling leverages WS-Addressing capabilities to "specify whether a service should hold the reply until the SOAP sender retrieves it using a GetMessage WS-Polling request. WS-Polling also uses WS-Addressing capabilities to specify an alternate reply address (the address of a SOAP mailbox), as well as to provide search criteria. Using WSDL 2.0, a service can indicate that it supports WS-Polling with wsoap:module once an identifier is defined for the WS-Polling SOAP module as required by SOAP 1.2."
W3C has published a namespace document for WS-Polling, but although publication of an acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership, but it does not indicate that W3C will be allocating any resources to the issues addressed by such a submission. According to the W3C Team Comment on WS-Polling, members of the Consortium "may consider starting an Incubator Group within the new Incubator Activity, in order to build consensus around this specification and prepare for a Working Group to be chartered to work on this area." WS-Polling is being brought to the attention of the W3C Web Services Activity Coordination Group, which provides a forum for coordination for Web services work at W3C, between the Working Groups of the Web Services Activity, the Semantic Web Activity, other parts of W3C, and other organizations."
WS-Polling may become an Incubator project because its requirements do fit into the current scope of the existing W3C Working Groups (Web Services Addressing Working Group; Web Services Choreography Working Group; Web Services Description Working Group; XML Protocol Working Group; XML Schema Patterns for Databinding Working Group). The W3C Incubator is part of the process of developing standards at W3C based upon coordination, consensus and interoperability, with no "rubber stamping" and a requirement to engineer dependencies inside and outside of W3C.
The W3C Incubator Activity is a new, lightweight process at W3C "designed to foster development, on a time scale of a year or less, of innovative ideas for specifications, guidelines, and applications that are not (yet) clear candidates for development and more thorough scrutiny under the current W3C Recommendation Track. The Incubator Activity allows rapid start of pre-standardization work within an Incubator Group (XG), where the XGs operate under a simple, fast-paced, flexible process, with the objective of producing an XG Report."
A WS-Polling background article prepared by Doug Davis of IBM describes how WS-Polling can be used to enable a truly asynchronous messaging delivery model even when firewalls get in the way. It also illustrates how WS-Polling can be used in a wide variety of scenarios.
The IBM reference page for Web Services Polling provides the following summary:
Recently, IBM made a member submission to the W3C of a new specification, Web Services Polling (WS-Polling) that addresses how to handle firewalls for environments that require connections between SOAP endpoints and asynchronous processing without interference.
The WS-Polling specification is aimed at addressing a problem with Web services that appears to be popping up in quite a few places. In environments where connections between SOAP endpoints can be freely created, asynchronous message processing can be done without any problems. However, this isn't always the situation. Firewalls must be in place to protect your company's assets. This is where this new specfication comes in. WS-Polling tries to help address this issue in a non-application, non-domain, non-specific way.
Several specifications and standards bodies, including WS-Notification, WS-Distributed Management, WS-Management and WS-Addressing, are all experimenting with the idea of how to allow an endpoint that cannot receive new asynchronous connections to still get messages delivered to it. While each one of these groups is looking at the issue, each appears to be solving it with a very specific domain in mind. WS-Polling attempts to solve the problem with a broader vision — hoping to allow a single solution that can be reused by all of these other organizations. By doing this, it would allow the functionality proposed in WS-Polling to be pushed into the 'core' SOAP engine, freeing these higher-level specifications to work on their domain and application-specific features..."
Doug Davis (Architect, IBM) has published an article on IBM's developerWorks website to help explain the rationale behind the WS-Polling specification. See "Firewalls: Web services' Achilles' Heel? Asynchronous Message Delivery With Firewalls." Excerpts:
This paper explores how WS-Polling can be used to enable a truly asynchronous messaging delivery model even when firewalls get in the way — and of course how WS-Addressing has made all of this possible. IBM's external WS-RM interop endpoint allows for WS-Polling to be used if you would like to see it in action. It uses a WS-Polling SOAP message host located at http://mailbox.soaphub.org...
In a previous paper, the author talked about how the WS-Addressing specification would have a dramatic impact on SOAP itself. The notion of any SOAP message being routed dynamically based on information inside of the WS-Addressing Headers introduces a new level of freedom to SOAP users. They are no longer limited to simple HTTP request/response message flows. Specifications such as WS-Coordination/Transactions and WS-Reliable Messaging can now assume there's an asynchronous message processing model (and one that is defined in a standard way) simply by using the WS-Addressing headers. However, as with many things, there's a downside to using asynchronous message processing and an obstacle to its adoption: firewalls...
Firewalls themselves aren't bad, but if you think about what asynchronous message processing means, they certainly throw an interesting monkey-wrench into the mix. Suppose you have a Web service client running on your home computer and you try to call out to some service on the Web that will take a while to execute. In that case there's a chance that either the HTTP connection will not stay open long enough for you to receive the response or, even if it did, you might not want it to — why tie up resources while waiting? And besides, you're talking about asynchronous message processing so you're expecting the result to come back to you through a new connection...
WS-Polling, at its simplest level, just defines a single SOAP operation called GetMessage, which the SOAP client can use against the message hosting provider. This operation will either return the desired SOAP message or return nothing at all if there are no messages waiting to be delivered to this SOAP client.
Usage scenarios: WS-Polling can be used in a wide variety of scenarios; here are a few worthy of special mention:
Unsolicited Messages: If a SOAP client has subscribed to a notification system (using, for example, WS-Notification or WS-Eventing) but they are behind a firewall any notification messages wishing to be sent to a subscriber client behind a firewall, can now be delivered. The subscriber (client) simply needs to use WS-Polling to periodically query its SOAP messaging host for any messages waiting to be delivered to it. Of course, when the client subscribed to the notification system it must have specified its SOAP messaging host as the target EPR of its messages, but the notification system is unaware of its use. It is important to note that WS-Polling allows for its GetMessage request to query for any messages destined for the client — not just responses messages. Server-side support: This paper focuses on using a SOAP messaging host as a mailbox, but it's also possible for a service endpoint to directly support WS-Polling itself. WS-Polling defines a way for the client and service to know that the other supports (and will use) WS-Polling when appropriate. This would allow for asynchronous messaging between two endpoints without the need for a third party mailbox. Security: WS-Polling is designed to be composed with the other WS-* specifications, including the security ones (WS-Security and WS-SecureConversation). The WS-Polling specification explains how to use some of its features to ensure that message integrity is not compromised, even when using a third party mailbox. Message delivery control: WS-Polling can be used as a means for an endpoint to control the rate at which messages are delivered and processed by its SOAP engine. Without firewalls, if an endpoint hosted a SOAP server, it could not easily control the rate at which messages would be delivered (or attempt to be delivered). Using WS-Polling, an endpoint has complete control over how often messages are delivered to its engine for processing. 24x7 Web Presence: There can be cases where a service cannot be available on the Web all day every day. If the service provider used a WS-Polling mailbox as the EPR of its services, then incoming messages could be delivered at any time. Then when the service does come on-line, it could retrieve the pending messages from the mailbox and process them. This gives the appearance of the service being available 24x7. Reverse protocol: WS-Polling can be viewed as a reverse protocol. Once the initial WS-Polling GetMessage is sent, request messages can flow on the HTTP response flow. Then responses to those requests can flow on a new HTTP connection — on the request side. This allows WS-Polling to be used as a means to initiate a connection between two endpoints, when the requesting side could not normally do it itself. Optimizations: WS-Polling optimizes the act of polling by defining additional SOAP headers that can be included in non-WS-Polling messages as a means for the two endpoints to communicate the presence of messages needing to be delivered. This could dramatically improve the network overhead normally associated with periodic polling. Implementation: As with other WS-* specifications, such as WS-MetadataExchange, WS-Polling can be used two different ways. Client applications can issue the GetMessage request themselves, and then they would be expected to manually process any possible response. Or, the SOAP stack itself could issue the GetMessage request from its infrastructural code...
There are already several polling solutions popping up various specifications, so clearly there is a need for this type of solution. While those work for the particular problem space of each individual spec, WS-Polling allows for a more generic solution that can be used to address all of these concerns and allows for a single infrastructural implementation to be reused for all of them. Duplication of functionality across WS-* specifications would lead to more confusion for implementers as well as their customers..."
Hugo Haas, W3C Web Services Activity Lead and Team contact for the Web Services Addressing and Description Working Groups, has provided W3C Staff comment on the WS-Polling submission. Excerpts:
W3C is pleased to receive the Web Services Polling (WS-Polling) Submission from IBM. WS-Polling is a SOAP extension which defines a polling mechanism allowing asynchronous retrieval of SOAP messages. Using this mechanism, an agent unable to receive messages may arrange for a SOAP node to store messages, so that the agent can later retrieve the messages from the storage node.
The SOAP node storing messages may be a service asked to hold reply messages until the requester can retrieve them, or a third party acting as a SOAP mailbox.
One use case for WS-Polling could be where agents are behind firewalls, and they do not have the ability to accept incoming connections.
Relationship to SOAP 1.2: WS-Polling defines a SOAP 1.2 module. When using WS-Polling for holding messages, the specification indicates that, when using HTTP, a service can return a 202 Accepted HTTP status code. Additional work would be needed around the SOAP 1.2 HTTP binding in order to support this capability. Such work to enable asynchronous interactions is currently under discussion in the XML Protocol and Web Services Addressing Working Groups. For SOAP 1.1, the WS-I Basic Profile 1.1 allows a 202 HTTP status code to be used in the HTTP binding.
No SOAP fault has been specified for the case when an agent is asked to hold reply messages and is unable to do so, e.g. because it temporarily lacks the resources to do so. It would be useful to have such a fault specified to let the sender of the message know that the reply cannot be stored for later retrieval.
Use of WS-Addressing 1.0: WS-Polling is built on top of the WS-Addressing Member Submission; a standardized version would logically be built on WS-Addressing 1.0, which is the result of the standardization effort around the WS-Addressing Member Submission, and whose Core and SOAP Binding specifications are currently published as Candidate Recommendations, i.e., under implementation testing.
WS-Polling leverages WS-Addressing capabilities to specify whether a service should hold the reply until the SOAP sender retrieves it using a GetMessage WS-Polling request. The special IRI used to identify that a requester cannot receive the reply and that the message should be held is the following URL: http://www.w3.org/2005/08/ws-polling/HoldResponse. In case the received does not support WS-Polling, it will attempt to deliver the reply to this address. When using this address, it may make sense to have a SOAP header block with a mustUnderstand attribute set to 'true' in order to ensure that the receiver understands this IRI. Alternatively, it is useful to have a SOAP processor respond with a SOAP fault to SOAP messages delivered at this address to clearly let the sender of the message that the meaning of this special URL has not been understood...
WS-Polling also uses WS-Addressing capabilities to specify an alternate reply address (the address of a SOAP mailbox), as well as to provide search criteria. Two criteria have been defined for searching for messages: (1) using WS-Addressing message identifiers; (2) using endpoint references (EPRs), as introduced by WS-Addressing. WS-Addressing 1.0, as opposed to the version of WS-Addressing on which WS-Polling is built, does not provide a way to compare EPRs. Use of WS-Addressing 1.0 would require this specification to provide rules for comparing two EPRs...
Relationship to WSDL: A WSDL 1.1 description of the WS-Polling messages is provided in an appendix, and a WSDL description is listed as a way for an agent to be aware that a service supports WS-Polling. Using WSDL 2.0, a service can indicate that it supports WS-Polling with wsoap:module once an identifier is defined for the WS-Polling SOAP module as required by SOAP 1.2, which the WS-Polling specification does not currently provide..."
- WS-Polling Submission:
- IBM resources:
- W3C and Web Services:
- W3C Incubator Activity:
- Tim Berners-Lee: "There are dozens of organizations out there who are interested in developing their own ontologies, just as there continues to be demand for industry-specific XML vocabularies, on an even larger scale. W3C has recently announced the launch of an Incubator Activity, in which groups that have ideas that are good ones, but usually outside of the W3C purview — think of the development of a specific ontology, for example — can have space at W3C to discuss and develop their idea more fully..." [From "The Semantic Web: An Interview With Tim Berners-Lee"]
- Steve Bratt: "... pre-standardization work, such as an Incubator Activity or a Characterization work in particular... An Incubator Activity is a new, lightweight process at W3C designed to foster development, on a time scale of a year or less, of innovative ideas for specifications, guidelines, and applications that are not (or not yet) clear candidates for development and more thorough scrutiny under the current W3C Recommendation Track..." [From "W3C Workshop on Frameworks for Semantics in Web Services Summary Report"]
- Steve Bratt: "New Incubator Activity: a quicker, lighter process for efforts that are innovative and not-yet-ready for standardization..." [From "The W3C and its Patent Policy"]
- List of Acknowledged Member Submissions to W3C. "The W3C Member Submission process allows Members to propose technology or other ideas for consideration by the Team. After review, the Team may publish the material at the W3C Web site. The formal process affords Members a record of their contribution and gives them a mechanism for disclosing the details of the transaction with the Team, including IPR claims. The Team also publishes review comments on the Submitted materials for W3C Members, the public, and the media."
- "Web Services Addressing (WS-Addressing)" - Local references.
|
 | Receive daily news updates from Managing Editor, Robin Cover.
 |
|
