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.
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.
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.
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!
Dan Drillich wrote:
I keep pointing to this same article as the article is very clear - Which style of WSDL should I use?.
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.