Browse Prior Art Database

An algorithm to deserialize a Web Service SOAP response independently of sending the request using a synchronous Web Services framework

IP.com Disclosure Number: IPCOM000097049D
Original Publication Date: 2005-Mar-07
Included in the Prior Art Database: 2005-Mar-07
Document File: 2 page(s) / 46K

Publishing Venue

IBM

Abstract

This article describes how a pluggable Web Services runtime implementation can be used to deserialize a Web Service SOAP response independently of sending the request.

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

Page 1 of 2

An algorithm to deserialize a Web Service SOAP response independently of sending the request using a synchronous Web Services framework

The problem is that some Web Services runtime implementations do not support deserializing a SOAP response from a Web Service at some later time to when the request was sent (asynchronously, in other words). If they did, a client could send a request to a Web service, receive the response later and process the SOAP response at a later time to extract the response data. Receiving a response later is possible over the JMS protocol, which supports asynchronous messaging.

    The core idea of the invention is to use a pluggable Transport framework provided by a Web Services runtime implementation (WSRI) to simulate a request/response Web Service invocation. The client pretends that it is invoking a Web Service synchronously and provides the response directly (without sending the request anywhere), this response being the SOAP message which is to be deserialized. The client sets up any Faults, etc which are needed to correctly deserialize the SOAP message on the request/response. No request or response messages are flowed across a network, but as far as the Web Services runtime implementation is concerned, it is invoking a Web Service as normal.

    The SOAP response the client provides is then deserialized by the WSRI as desired. This SOAP response is received from the Web Service by client code, external to the WSRI. For example, a response can be read from a JMS Queue in the case of a SOAP over JMS Web Service.

    The WSRI pluggable Transport framework discussed here allows the code which actually sends the SOAP message to the service and receives the response to be replaced by user code, which is called a "Handler". A Handler is instantiated by a WSRI implementation and called to do the request/response transport.

    When this Handler is called by a WSRI, it is passed the "Context" which contains the requested SOAP message. The "Context" is where the response should be placed by the Handler.

    Another user-replaceable module called a "Transport" is given the opportunity to add things to the Context before the Handler is called. This Transport is registe...