Welcome to the next installment of "As the Interop World Turns," in which Ted Neward looks at commercial tools that provide a binary RPC-based interop approach. With such tools you follow a development process that's (deliberately) similar to what's done when working with the native ORPC stack (CORBA or RMI for Java, .NET Remoting for .NET). TheServerSide Interoperability Blog invites the developer and architect communities - across platforms - to take part in the discussion. The goal is to create a compelling dialog on the best practices and architectures that relate to this sometimes heated topic.
- Posted by: Regina Lynch
- Posted on: November 16 2006 11:58 EST
- AMQP & Artix by John Davies on November 16 2006 22:38 EST
- Ted forgot to mention ICE by Mileta Cekovic on November 17 2006 10:08 EST
- Voyager by Thomas Wheeler on November 17 2006 16:41 EST
- Do we really need another.... by Guido Anzuoni on November 20 2006 10:56 EST
- Re: Interoperability Blog: Interop Across the Wire by Nati Shalom on November 20 2006 17:39 EST
Ted, Interesting read and some interesting ideas for those stuck with more than one language/OS which of course includes a large proportion of the industry. Two other technologies in this area I'd like to bring into the conversation are:- Firstly the open wire-level protocol AMQP, designed to commoditise the messaging playing field currently held very strongly by MQ and RV and IONA's Artix a "distributed SOA" integration and services enabling framework designed to improve WS capabilities and performance while still maintaining the WS specs. AMQP will hopefully play a very strong role in providing an asynchronous messaging platform to use with web services. Whether the payload is SOAP or something more efficient like binary (IIOP, JRMP, ASN1 etc.), AMQP should provide wire-level interoperability. I can see AMQP fitting nicely into much of what you suggest, perhaps replacing the [usually] synchronous CORBA integration. Having said that CORBA seems to be doing very nicely these days. IONA adds a nice little twist by allowing the programmer to retain the Schema+WSDL description but chose the payload implementation and transport at run-time. This allows the user to move from SOAP/HTTP to IIOP or JRMP etc. over JMS or AMQP (TBA) etc. without code changes. AMQP is actually in production at JPMorgan Chase and one of the several open implementation (Apache Qpid) can be found here: http://incubator.apache.org/qpid/ -John- CTO, C24
Ted forgot to mention ICE. ICE is the fastest RPC stack I have ever tried. Recently I compared WebServices stacks for Java & .NET as well as RMI, CORBA (Sun ORB and JacORB) and ICE. The results are that WebServices stack, although faster then in previous releases, are still almost order of magnitude slower then binary RPC stacks. While Java (JAS WS 2.0.1) were faster then .NET (.NET 2.0) on server, .NET was compensating that providing faster client side WS stack part. The same story again, Java focus is on server side, .NET on client side... From the binary RPC stacks ICE was the fastest. It even outperforms RMI (about 10-15%) although it is multi-platform!
If you've been around the Java middleware world a while you may remember ObjectSpace's Voyager. We (Recursion Software) now own and are developing Voyager, and support it under both Java and .NET. If you're interested in another solution to the Java-.NET integration problem please check us out at http://www.recursionsw.com. Regards, Thomas Wheeler
Interoperability Alliance ? With that membership ? I fear that it will mean only new buzzwords for those (too much) hugely paid consultants able to decide technologies before analysis. Shortly $$ for vendors and pain for the others. Guido.
Majority of the interoperability approaches such as SOAP and IIOP is RPC based. RPC based interoperability normally involves network call, in addition to that it enforce some sort of least-common-denominator such as XML as the mean for portability. All that makes the interoperability task very complex and and insufficient in terms of performance. The other limitation with the RPC based approach is that the it can't address well stateful environment. Another alternative approach is Data based interoperability i.e. instead of passing network calls we simply share data between the two services written in two different languages. This model has been used successfully in the past few years via data base technology. The Reliance on Data-bases made this approach relatively costly in terms of performance and therefore less popular. The emergence of IMDG (In Memory Data Grid) based on JavaSpaces provides a third approach which combines the RPC and Data base approaches under a single technology - the Space. With this approach interoperability could be done in-process over the network and with minimal overhead in terms of performance. Such approach has been successfully implemented by GigaSpaces. The following example illustrates how a pure .net application can write C# objects into a JavaSpace: http://www.gigaspaces.com/wiki/display/GS/.NET+Example Nati Shalom CTO Write Once Scale Anywhere