- From: Carl Sjogreen <CarlS@bea.com>
- Date: Sat, 9 Mar 2002 11:19:46 -0800
- To: Naresh Agarwal <nagarwal@in.firstrain.com>, www-ws@w3.org
> 1) Does the "Aynchrony" make sense in "RPC" (encoded) style > of SOAP or > it would be only useful for "messaging" (literal) style of SOAP? > > 2) Are RPC *synchronous* per se, or does it make sense to have RPC > *asynchronous*? Whether a message is sent synchronously or asynchronously is really different from the encoding style. BEA Weblogic Workshop has a complete framework for asynchronous messaging (and bi-directional messaging using a callback paradigm) that can operate over both SOAP-RPC and document-literal encoding styles and over HTTP or JMS. With that said, in talking to customers most people I have spoken with view the SOAP-RPC encoding style and synchronous request/response messages going hand in hand. This is the view of web services as the next generation of RMI/DCOM/CORBA. Others who view web services as a platform for building a service oriented architecture are much more concerned with rich documents, B2B message standards and asynchrony. Asynchrony is key for modeling overall business processes, and interacting with resources in the enterprise that are inherently asynchronous (people, legacy systems, etc.). > 3) What exactly do we want to achieve by using SMTP, JMS, > BEEP etc., as > transport mechanism for SOAP? As I said above, I think its partly about accommodating integration with different kinds of resources, partly just about scalability. There is also interest in using protocols like JMS for reliable messaging, and it just happens to be an asynch protocol. -Carl -- Carl Sjogreen Product Manager, WebLogic Workshop BEA Systems, Inc.
Received on Saturday, 9 March 2002 20:13:22 UTC