| SubmissionsW3C 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.
This Member Submission is related to the following W3C specifications:
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.
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: such faults are being
generated at
http://www.w3.org/2005/08/ws-polling/HoldResponse.
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:
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.
In addition, it is mentioned that it is expected, in the case where a SOAP mailbox is used, each client of the mailbox will be issued a unique URL or EPR. From the point of view of the architecture of the Web, use of IRIs, i.e. use of the [address] property of an EPR, is preferred for identifying different endpoints.
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.
This Member Submission will be brought to the attention of the Web Services Activity Coordination Group. Due to the current scope of their work, it is expected that the existing groups will not take on such work.
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.
Feedback on this technology is encouraged on the www-ws@w3.org mailing list (public archive).