Re: Two uses of SOAP

> Mark,
> 
> I'm somewhat of a lurker on this board, but I could see another use of SOAP
> emerging over time: as a JCL for managing queued resources. Arguably, this
> could fit into other of the other two divisions that you've set up, but the
> RPC mechanism strikes me as being largely a client/server model where the
> transactions are *roughly* synchronous (I'd describe these as moderately
> coupled synchronous transactions), while application protocol frameworks are
> in turn moderately coupled asynchronous transactions. A queue processing
> system, on the other hand, is a weakly coupled aynchronous transaction - the
> bindings on the SOAP objects make it possible to include multiple kinds of
> entities in the same processing queue, while there is little correlation
> between the time that a queued process is entered and the time that it's
> processed (save that one must perforce come after the other).
> 
> As I said, it could very well be thought of as one of the other two, but
> there are just enough differences in treatment and implementation that it
> might be worth examining it as a separate division.

I believe that any problem looking to be solved with software can be implemented
with either of the current two uses I've described.  They are after all,
architectures (RPC being one, REST - representational state transfer, the
architecture behind the Web and HTTP - being the other).  So a JCL could be
constructed both with custom RPC interfaces, and with just an HTTP interface.

It's the quality of what you end up with after implementing both approaches
that determines the winner.

MB

Received on Monday, 30 July 2001 01:40:34 UTC