- From: Krishna Sankar <ksankar@cisco.com>
- Date: Fri, 29 Jun 2001 11:29:49 -0700
- To: <nick@invertica.com>, <www-ws@w3.org>
Nick, I agree with your thought on the lack of multi-cast. Hence my assumption that inside an enterprise, normal apps wouldn't need to do more than 10-25 subscribers and that too not frequently. My impression with Tibco was that they use UDP broadcast, which itself is an issue with the security folks. So multi-cast is an issue to be solved, and again, following your thoughts, we need standards on all layers incl the wire protocol. Re the demo, I also plan to write the JXTA/Sockets using C# (if a BEEP implementation is available on C#, the better) and see if we can (seamlessly) talk between a set of C#, Java peers, proving the interoperability. cheers |-----Original Message----- |From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of |Nick Nadgauda |Sent: Friday, June 29, 2001 10:49 AM |To: Krishna Sankar; www-ws@w3.org |Subject: RE: open transport protocol for aysnc web services? | | |Krishna, | |Sounds like an interesting demo. Web services over BEEP looks like a |definite possiblity for inside the enterprise. The only hitch I can see |with BEEP (and P2P approaches in general) is the lack of |multicast. I'm not |an expert on this topic by any means, but proprietary pub/sub schemes like |Tibco and Talarian scale the way they do because they run over IP |multicast. |I think APEX (or APEX over BEEP) is supposed to address the multicast issue |at some point. | |Regards, |--Nick | |-----Original Message----- |From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of |Krishna Sankar |Sent: Thursday, June 28, 2001 9:03 PM |To: nick@invertica.com; www-ws@w3.org |Subject: RE: open transport protocol for aysnc web services? | | |Nick, | | Good thoughts. | | Inside an enterprise, processes to processes, I would propose a |peer-to-peer model (yep we would also need to overlay a pub-sub over the |basic Peer-to-Peer infrastructure) One of the assumption is that, |even if we |do pub-sub, we would only be doing 1 to (say) 20. | | Just as an example, I am doing is to prototype the RosettaNet PIP3A4 |choreography (involving orchestrator, conversation manager, PO service, |booking service, ...) on a JXTA over BEEP. | | In short, the concept of asymmetric, asynchronous, |multi-channel wire |standard and associated discovery/description mechanisms do have an appeal |over the current proprietary, messaging systems. As one of our engineers |pointed out, even JMS does not have interoperability over the wire :-( | | cheers | ||-----Original Message----- ||From: www-ws-request@w3.org [mailto:www-ws-request@w3.org]On Behalf Of ||Nick Nadgauda ||Sent: Thursday, June 28, 2001 3:54 PM ||To: www-ws@w3.org ||Subject: open transport protocol for aysnc web services? || || ||One of the biggest holes to web service adoption inside the ||enterprise seems ||to be the lack of an open transport protocol for aysnc, reliable message ||delivery. By this I mean an equivalent of HTTP which provides for two-way ||async communication with decent performance. Ideally, this |protocol should ||become a standard over time enabling "out of the box" web service ||interoperability between different vendors, products, systems, etc. What ||I'm envisioning is having different systems be able to communicate ||asynchronously inside the enterprise the way they might |communicate outside ||the enterprise via HTTP. || ||There are a few proprietary alternatives (that I know of) |including Tibco's ||Rendezvous, IBM's MQ APIs, and JMS. But none of these is open and I don't ||think you would see widespread adoption as such. One cannot assume that ||every system is going to be able to talk Rendezvous the way one can assume ||about HTTP. JMS might be the closest thing to what I'm thinking |about, but ||it seems tightly coupled to Java and it really is more of an API ||for driving ||messaging systems rather than a transport protocol. || ||There's also a few open protocol possiblities (again that I know of) ||including the Jabber as Middleware effort (jam.jabber.org) which aims to ||provide a messaging transport over Jabber's XML on IM backbone. ||Anyone know ||of any (other?) efforts going on in this area? || ||Regards, ||--Nick || ||Nick Nadgauda ||:Chief Technology Officer ||:Invertica, Inc. ||:nick@invertica.com ||:[P] 212.571.4103 x6593 ||:[F] 212.571.3588 ||:[C] 917.847.7938 || || | |
Received on Friday, 29 June 2001 14:28:18 UTC