RE: WS-I and RPC

> (And in this particular case I assume sendMeInvoiceDetails 
> does not return an invoice but actually sends it 
> asynchronously over SMTP or maybe by fax)
> 
> arkin
> 

Assaf,

One option for implementing your use case would be to decouple the
client and back office logic/process through a Web Queue resource. You
could model your interface to the outside world as a set of queues. In
that specific example, you would have a "RequestInvoiceDetail" queue.

The client would post an XML document to the web queue and receive in
response a URI. It could a later time do a GET on that URI to retrieve
the "status" or post a cancellation request.

You might say/ask: "You have just morphed all the operations into
queues...you have just moved the complexity to another layer". This is
partially through specially is you focus only on development cost. The
benefit of decoupling the system through a queue (with a generic
interface) resides mainly in management and adaptability: A client can
externalize the URI of the queue/services it is linked in. When a new
version of the server service is available, you can publish a new queue
and the client can be updated more easily. In the case you have services
with multiple methods, each time you chance one method, it impacts all
the other methods. If you are familiar with COM versioning you will
realize that this is complex even within the scope of your desktop let
alone a network or the web.

This might look like a very simple/basic design pattern but one that is
important when you have to manage 1,000,000s of requests across 100s of
services/queues.

I believe that where REST is weak (and this is one of the reason why raw
XML over HTTP is not mainstream) is that there are no standards for
defining the schema of the data produced by a web queue resource, no
programming abstraction for manipulating easily the XML messages that
are sent back and forth and coordinating flow and transactions across
asynchronous requests.

Today's WSDL solves part of the problem but it does it by pushing
developers towards RPC and encouraging them to build very fragile
applications.

Edwin

Received on Monday, 6 January 2003 01:58:11 UTC