Browse Prior Art Database

Mechanism for Delivery of SOAP Messages to an Unreachable Endpoint

IP.com Disclosure Number: IPCOM000032964D
Original Publication Date: 2004-Nov-19
Included in the Prior Art Database: 2004-Nov-19
Document File: 6 page(s) / 106K

Publishing Venue

IBM

Abstract

This specification defines a mechanism to deliver messages destined to an unreachable endpoint by allowing the destination to 'poll' the source for messages targeted for it.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 1 of 6

Mechanism for Delivery of SOAP Messages to an Unreachable Endpoint

1. Introduction

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. Perhaps the most common scenario being where the initiator (client) of a Web service call is behind a firewall so 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 both of these cases, 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.

This specification 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.

2. XML Namespaces

The XML Namespace URI that MUST be used by implementations of this specification is:

http://ws-polling/ws/2004/08/ws-polling
Table 3 lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Table 3: Prefixes and XML Namespaces used in this specification.

Prefix XML Namespace Specification(s)

s (Either SOAP 1.1 or 1.2) (Either SOAP 1.1 or 1.2)

s11 http://schemas.xmlsoap.org/soap/envelope/ SOAP 1.1 [SOAP 1.1 ]

s12 http://www.w3.org/2003/05/soap-envelope SOAP 1.2 [SOAP 1.2 ]

wsa http://schemas.xmlsoap.org/ws/2004/03/addressing WS-Addressing [WS-Addressing ]

wsdl http://schemas.xmlsoap.org/wsdl/ WSDL [WSDL 1.1 ]

wsp http://ws-polling/ws/2004/08/ws-polling This specification

xs http://www.w3.org/2001/XMLSchema XML Schema [Part 1 , 2 ]

1

Page 2 of 6

3. Requesting Messages
3.1 GetMessage Request

To request a message from an endpoint, a requestor MAY send a GetMessage request message to the endpoint. The normative outline for a GetMessage request is:

<s:Envelope ...>
<s:Header ...>

<wsa:Action>

http://ws-polling/ws/2004/08/ws-polling/GetMessage

</wsa:Action>

<wsa:MessageID>xs:anyURI </wsa:MessageID>

<wsa:ReplyTo>endpoint-reference </wsa:ReplyTo>

<wsa:To>xs:anyURI </wsa:To>

...
</s:Header>
<s:Body ...>

<wsp:GetMessage ...>

[<wsa:MessageID>xs:anyURI </wsa:MessageID>]

[<wsa:To>endpoint-reference </wsa:To>]

</wsp:GetMessage>
</s:Body>
</s:Envelope>

The following describes normative constraints on the outline listed above:

/s:Envelope/s:Header/wsa:Action

If a SOAP Action URI is used in the binding for SOAP, the value indicated herein MUST be used for that URI.

/s:Envelope/s:Header/wsa:ReplyTo

The Endpoint Reference (EPR) of the source endpoint. This SHOULD contain reference properties to help uniquely identify the source endpoint.

/s:Envelope/s:To

The address of the destina...