News: Internet Communications Engine 2.0 released
The Internet Communications Engine (Ice) is a modern alternative to object middleware such as CORBA™ or COM/DCOM/COM+. Ice is easy to learn, yet provides a powerful network infrastructure for demanding technical applications. Ice shines where technologies such as SOAP or XML-RPC are too slow, or do not provide sufficient scalability or security.
- Posted by: Enrique Ariz?n Benito
- Posted on: November 27 2004 04:47 EST
Ice is free software, available with full source, and released under the terms of the GNU General Public License (GPL). Commercial licenses are available for customers who wish to use Ice for closed-source software.
The most important features and strengths:
- It's easy to learn and use. Nothing to do with the CORBA "nightmare".
- Well documented.
- Language and platform independent.
More info on:
- Ice by Kit Davies on November 29 2004 10:38 EST
- Internet Communications Engine 2.0 released by Paul Danckaert on November 29 2004 10:50 EST
- Standards? Wouldn't it be great if.... by Lillian Andres on November 29 2004 11:40 EST
- Bernard by Bill Burke on November 29 2004 12:03 EST
- benches by Bill Burke on November 29 2004 12:09 EST
- Internet Communications Engine 2.0 released by Anshuman Purohit on November 29 2004 13:01 EST
- I can vouch for this stuff.... by Kurt Westerfeld on November 29 2004 21:12 EST
- Internet Communications Engine 2.0 released by Dorel Vaida on November 30 2004 03:02 EST
The things you can do with an acronym ! :)
From my skimming here.. and this may be wrong.. this seems to be pretty directly competing against a CORBA type of solution. For example, I don't see this doing object/data transport via HTTP, which is a nice part of the SOAP protocol. (Firewall friendly for external clients..) So that would make it more of an internal enterprise solution. If I have pure Java, I don't necessarily see an advantage with this over RMI or RMI-oriented solutions (JINI, etc..).. So we are mainly talking about a heterogeneous network primarily (but not required to be) internal, if we are being realistic about firewalls and other protections from corporate users?
I don't see that as a problem.. ICE seems to have a very nice set of features and components.. I'm just trying to see where I would make use of this in different projects?
One question I have.. is there any comparison on Bandwidth usage between CORBA, RMI, SOAP, and ICE? SOAP is heavy, but does compress quite well using HTTP compression.. in a heavily used network, if ICE was 50% (or 200%) of CORBA, that would be a big deal..
Take a look at Glacier (http://www.zeroc.com/ice.html) to understand how firewall related issues that have plagued DCOM/CORBA have been addressed in ICE. I encourage everyone to have a look at the documentation -- its just amazingly clear and concise!
Ice has taken many ideas from CORBA. Basically, it's CORBA with all the crud removed. Much easier to use than CORBA, with much smaller and simpler APIs. Ice also has a number of features that CORBA does not, such as exception inheritance, asynchronous dispatch, very efficient message forwarding, and others.
If you are in a pure Java environment, you are right, you might as well use RMI instead of CORBA or Ice. Ice (like CORBA) pays off big-time in heterogeneous environments.
In terms of performance, Ice is as as fast (and faster in many cases) as general-purpose ORBs. (With a fast machine, you get 20,000 RPCs per second, which is more than enough for almost all situations.) In terms of bandwidth, the Ice protocol is quite compact (much more compact than IIOP). Of course, that means it is very much more compact than SOAP :-) Incidentally, Ice supports compression as well, using bzip2. It turns out that, for high-speed LANs, compression actually slows you down: it's faster to throw the uncompressed data on the wire than it is to compress, because compression is very CPU intensive. But, for low-speed connections, such as modem links, compression pays off very handsomely.
The IceStorm portion of ICE looks very attractive. From a "sales" perspective to government customers, wrapping the IceStorm api in the industry standard JMS (Java Messaging Service) and OMG standard DDS (Data Distribution Service) would be very wise. In particular, the interoperability with C++ and Java and the transport protocol of UDP are highly desirable for government applications. ZeroC developers, are you listening? Thanks.
From a "sales" perspective to government customers, wrapping the IceStorm api in the industry standard JMS (Java Messaging Service) and OMG standard DDS (Data Distribution Service) would be very wise.
I'm not sure how much this really would add in terms of value. Much of Ice is about simplicity: we were very careful in deciding what features to admit and what features to reject. (The art is in being strong enough to say "no"...) The effects of this on the overall platform are quite dramatic. People are blown away when they see how simple things are with Ice. (As an example, the CORBA POA API takes 211 lines of IDL definitions. The Slice definitions for the Ice object adapter takes 29 lines of definitions, and it can do everything that the POA can do.)
There is no such thing as a simple specification from the OMG, so trying to follow a standard such as DDS is simply a lost cause, IMO.
"There is no such thing as a simple specification from the OMG, so trying to follow a standard such as DDS is simply a lost cause, IMO."
Painfully Agreed! However, there are some of us that don't have the luxury of using the most simple technology! Wrapper it with DDS, sell it, and you'll make the profits from the government sector.
Hey, does Bernard Normier still work for you guys?
Yes, he does. see http://www.zeroc.com/about.html#staff
A couple of questiosn:
* Do you have benchmark comparisons with a variety of different protocols? (soap, xml-rpc, RMI, IIOP, etc..)?
* Can ICE work without a IDL like definition language? Can server-side marshalling code be generated without a precompilation step?
These are the usual questions I ask when determining whether the transport is worthy of being integrated into JBoss's transport stack.
A couple of questiosnBill
Although a discussion here will be fruitful to many in the community, your questions might be answered faster if you post at http://www.zeroc.com/vbulletin
A couple of questiosn:* Do you have benchmark comparisons with a variety of different protocols? (soap, xml-rpc, RMI, IIOP, etc..)?*
Someone did some independent performance measurements on a very early version of Ice against a number of ORBs (http://www.zeroc.com/vbulletin/showthread.php?s=&threadid=27). (We have improved performance considerably since then.) Bill Beckwith from OIS gave a talk at an OMG meeting last year that also published some performance comparisons. (Unfortunately, he was rather selective in his choice of data and carefully picked cases where Ice was slow. It turns out that those cases were slow due to a bug that we fixed long ago...)
Also, be careful about interpreting benchmark results. For example, Philip Merle recently published a paper about Ice performance against a few other ORBs, being blissfully aware that the platforms were using different threading models, making any comparison of the results meaningless.
Anyway, the upshot is that Ice is as fast or faster than an ORB running on the same hardware and OS. In some cases, Ice is considerably faster -- it depends on what data types in what arrangements you use for a benchmark. The simple answer is "Ice is fast enough for just about anything."
Also, the strong focus on performance as a middleware evaluation criterion is misguided, IMO. Performance is about a 5th-order issue for most projects, and other considerations, such as development cost, defect count, supported languages, compilers, and operating systems are far more important. Unfortunately, those are much harder to quantify than performance, so people time and time again fall into the trap of believing that, because platform X is faster than platform Y, X is better than Y.
Can ICE work without a IDL like definition language? Can server-side marshalling code be generated without a precompilation step?
Yes. Ice 2.0 added a streaming interface that allows you serialize Ice data types using the Ice encoding (or any other encoding of your choice), as well as dynamic invocation and dispatch APIs. So, Ice provides the equivalent of CORBA's DII/DSI.
A couple of questiosn:* Do you have benchmark comparisons with a variety of different protocols? (soap, xml-rpc, RMI, IIOP, etc..)?* Can ICE work without a IDL like definition language? Can server-side marshalling code be generated without a precompilation step?These are the usual questions I ask when determining whether the transport is worthy of being integrated into JBoss's transport stack.Bill
You mean 'JBOSS Ice' ? :-))
If and how TxRPC is supported?
Ice currently does not include a distributed transaction service. We may end up doing one, depending on customer demand. (We've done a distributed transaction monitor in the past, so we know how do it...)
And I've never seen it, implemented with it, or otherwise done anything with it.
I open the doc, and two names are there:
These guys wrote much of the OOC CORBA implementations for Java and C++, and they are great. Alas, if you google for where that stuff went, you can can see why they might have moved on to greener pastures.
But, seriously, these guys on their implementation team know distributed computing.
Now, on to read what they actually *did*.
The Internet Communications Engine (Ice) is a modern alternative to object middleware such as CORBA™ or COM/DCOM/COM+. ...
As oposed to RMI/IIOP does RMI/Ice ring a bell to anyone ?