- From: Wilfredo Sanchez <wsanchez@KnowNow.com>
- Date: Mon, 1 Apr 2002 14:22:28 -0500 (EST)
- To: "Naresh Agarwal" <nagarwal@in.firstrain.com>
- Cc: <www-ws@w3.org>
FYI- KnowNow uses HTTP as a asynchronous transport. Our event router uses async publish/subscribe semantics and speaks HTTP (natively, not as a bolt-on feature). We recently wrote an RPC services-oriented layer on top of the pub/sub layer which can be both synchronous or async (using a callback). It doesn't do SOAP encodings, though SOAP support is a natural next step which we're working on. The lightweight service works in Java and JavaScript (yes, you can implement your server side in a browser if you are so inclined): http://cvs.developer.knownow.com/index.cgi/Libraries/Java/JavaService/ http://cvs.developer.knownow.com/index.cgi/Libraries/JavaScript/JSService/ The JavaScript version doesn't support writing synchronous clients, because JavaScript doesn't let you block on the reply. Here's the sample client code in Java: http://cvs.developer.knownow.com/index.cgi/Libraries/Java/JavaService/sampleClient. java?rev=HEAD&content-type=text/vnd.viewcvs-markup -wsv On Friday, March 8, 2002, at 03:19 AM, Naresh Agarwal wrote: > Hi > > Today, most of the Soap implementations use HTTP for transport > protocol..However, in the near future, we expect more support for > "Asynchronous" transport protocol like SMTP, JMS, BEEP etc. > > I have following concern in this regard: > > 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*? > > 3) What exactly do we want to achieve by using SMTP, JMS, BEEP etc., as > transport mechanism for SOAP? > > I would appreciate any comments on the above. > > thanks, > > regards, > Naresh Agarwal
Received on Monday, 1 April 2002 17:27:42 UTC