Question on Asynchronous web service call using document style.

[Ravi C Kota]

Hello All,

I was going through a blueprinton Webservice design patterns which quoted the differences between Synchronous and Asynchronous WS calls.It says Synchronous WS can be achieved using RPC style and Asynchronous using Document Style.

Based on this document, I have few questions.

1) What are the technical difficulties in implementing Asynchronous WS using RPC style? What would prevent it from being implemented? If none, why RPC is considered to be good for Synchronous call.

2) Similarly why Document style is better for Asynchronous call? Under the hood, both RPC and Document style will have the SOAP request/response which is basically an XML document. The only difference is how are we accessing this XML document, whether we want to handle the SOAP request/response at the XML level or through some kind of Java objects. So how does it matter the synchronous or asynchronous call between RPC and Document style.

3) In an Asynchronous pattern, I read that it makes use of JMS for achieving Asynchornization. So when we design an Asynchronous WS, do we need to explicitly configure the JMS and its components or would that be taken care implicitly by WS run time.


In another article, it is mentioned as below

An RPC (remote procedure call) is essentially a call to a remote method. Web services are XML-based, but you can still interact with the back-end service in an RPC-like fashion. Typically, the interaction is a very simple request/response, where the client sends a SOAP message that contains a call to a method. The application server receiving this request can then translate this request into the back-end object (e.g., a Java object, EJB method, or C# method). There is very little that developers have to do to build an RPC-based Web service because everything is mapped for them. Note that even in this approach XML is used to contain the call.

With document style, XML "business documents" are transmitted across the wire. They do not map directly to back-end method calls; they are actually complete, self-contained business documents. When the service receives the XML document, it might do some pre-processing on the document, perform some work, and construct the response back. There is usually no direct mapping to a back-end object. In fact, a request might invoke multiple components on the back end. The developer has to do much of the work in processing and mapping the XML data received, and there are very few tools on the market that can do this automatically. The document style is typically used in conjunction with asynchronous protocols to provide reliable, loosely coupled architectures.

From this I understand that, in RPC style, operation name is the SOAP Body's first element. For instance, an example would be similar to

    
<soapenv:Body>
    <ns0:calculate>
          <arg0>add</arg0> 
          <arg1>5</arg1> 
          <arg2>3</arg2> 
    </ns0:calculate>

and for Document style

    
<soapenv:Body>
    <q0:calculate>
       <arg0>ADD</arg0> 
       <arg1>5</arg1> 
       <arg2>3</arg2> 
  </q0:calculate>
  </soapenv:Body>

When we compare the above two snippets, there is no difference at all. Neither I have any change in the way I'm handling the request in my SEI, except some annotation change. So what is the difference here?

If some one could provide me a good real time example, justifying their usage, it would be of great help to me.

Another question I have regarding the style to be used, in case If I decide to act on the SOAP request at XML level, using low level API, would there be any difference in my RPC vs Document style WS.

[Ivan Krizsan]

Hi!

Ravi C Kota wrote:I was going through a blueprinton Webservice design patterns which quoted the differences between Synchronous and Asynchronous WS calls.It says Synchronous WS can be achieved using RPC style and Asynchronous using Document Style.

As far as I understand, this sounds unmotivated. After all, the payload of RPC style and document style messaging is an XML fragment.
Both RPC and document style messages using SOAP have a header, in which headers carrying additional information can be added.

Question 3:
There are two types of asynchronous servers, as I have described in earlier posts here.
One in which the client's call is asynchronous, but the web service processes the request synchronously.
The other in which the request is truly asynchronous both on the client and server side. This case often involves placing the request in some sort of a queue on the server side, to be processed at a later point in time. This queue does not have to be a JMS queue, it may for instance be a job queue of a thread pool.

Hope this clarifies!

[Dan Drillich]

Hi Ravi,

Thank you for articulating your questions so eloquently.

I keep pointing to this same article as the article is very clear - Which style of WSDL should I use?.

When comparing RPC/literal, Document/literal and Document/literal wrapped please look at the WSDL document (versus the SOAP message). Then the difference between the styles becomes obvious.

Russell's note at the beginning of the article is helpful as well -

Before I go any further, let me clear up some confusion that many of us have stumbled over. The terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style should be used for RPC programming models and that the document style should be used for document or messaging programming models. That is not the case at all. The style has nothing to do with a programming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothing more. You can use either style with any programming model.

Regards,
Dan

[Ravi C Kota]

Ivan Krizsan wrote:Hi!
One in which the client's call is asynchronous, but the web service processes the request synchronously.
The other in which the request is truly asynchronous both on the client and server side. This case often involves placing the request in some sort of a queue on the server side, to be processed at a later point in time. This queue does not have to be a JMS queue, it may for instance be a job queue of a thread pool.
Hope this clarifies!

Thanks Ivan.

Would you mind elaborating a bit more on the client making asynchronous call, but service handling it synchronously. Is this what is being done using Polling and CallBack mechanism? I doubt though.

[Ravi C Kota]

Dan Drillich wrote:

I keep pointing to this same article as the article is very clear - Which style of WSDL should I use?.

Thank you Dan. I actually went through the article you pointed here, but unfortunately I did not understand that quite well, as internally I always feel that the bottom line is after all an XML. But may be I need to take a look at that link more carefully.

Initially, I did not really care, when people talked about the toughness of SCDJWS preparation and the confusion about various specifications. But I need to admit that this is one of the toughest test I'm preparing for and it requires some practical exposure, which I lack

[Ivan Krizsan]

Hi!

Ravi C Kota wrote:
Would you mind elaborating a bit more on the client making asynchronous call, but service handling it synchronously. Is this what is being done using Polling and CallBack mechanism? I doubt though.

No, this is not polling or callback, which are typically used when the service processes request asynchronously.
Polling:
The client sends a request to the service, which replies with a correlation id (think of it as a job id).
Later, the client invokes another operation on the service asking the service if the request with the supplied correlation id is finished or not.
If the request is finished, the client receives the result, otherwise it receives some indication that the request has not yet been processed.
Callback:
The client sends a request to the service, along with some information of the client's callback service.
The callback service is a service that the client makes available.
When the request from the client to the service has been processed, the service invokes the client's service and delivers the result.

Concerning a web service client developed in Java making asynchronous requests to a web service that processes the requests synchronously:
Please see my SCDJWS study notes, section 4.8 and the subsection Asynchronous Request-Response for detailed description and code examples.
Best wishes!