Objects on Ice
Ice or Internet Communications Engine, is an alternative to using CORBA for distributed language-neutral objects. I’ll let them put their own words out (from the documentation) about why Ice exists as a competitor to SOAP, CORBA, DCOM, etc.:
You can either choose a platform that won’t run on anything but Microsoft architectures, or you can choose a platform that is complex and suffering from gradual abandonment, or you can choose a platform that is inefficient and, due to the lack of standardization, proprietary.
That pretty much sums it up. They ship it with complete (or nearly complete) bindings for C++, C#, Java, Python and VisualBasic. That pretty much covers everything, and having looked at the protocol specs, I think implementing a Smalltalk or Lisp binding (either through FFI or native recreation) would be pretty simple. They argue that they have the following goals:
- Provide an object-oriented middleware platform suitable for use in heterogeneous environments.
- Provide a full set of features that support development of realistic distributed applications for a wide variety of domains.
- Avoid unnecessary complexity, making the platform easy to learn and to use.
- Provide an implementation that is efficient in network bandwidth, memory use, and CPU overhead.
- Provide an implementation that has built-in security, making it suitable for use over insecure public networks.
or, put more cleanly:
Let’s build a middleware platform that is as powerful as CORBA, without making all of CORBA’s mistakes.
Not a bad goal, and they’ve hired some of the best people who have worked on all the major CORBA projects, and thereby know the insides of CORBA, and what’s intensely wrong with it in places. Having said that, everything that is wrong with CORBA are mistakes that the SOAP people are making all over again.
I’ve spent the last couple days in my spare time (no comments, please) reading the 1400 page documentation, and trying to grok what they are doing. I have a pretty solid understanding of CORBA (and more simplistic approaches like RPC), so the concepts weren’t hard, and their explanations are excellent—far exceeding anything I’ve seen in the CORBA world.
So far, I’ve been able to migrate all my IDL to Slice, which is their version of IDL. Very close, but missing a lot of excess baggage. It took about 30 minutes to migrate it all (about 100 interfaces), most of which was spent diagnosing typos. One thing that tripped me up was they don’t allow the ’_’ (underline) character in identifiers, so I had to move things to camelCase. That was done using a simple script in Xemacs. Poof, done, and it fixed up all my code as well. After that, I just had to retrofit their binding approach, which wasn’t that hard.
All in all, I was able to move enough bits to test from CORBA (OmniORB) to ICE to show that not only does it work, it’s a lot easier to work with. Having said that, I think I’ve found a minor bug in the Slice compiler, and I’ll have to find out. I plan to add some more observations moving forward. Some early observations about things that I’m liking so far:
- Batching of invocations. This can potentially increase the performance level of part of my application enormously. Nobody does this in CORBA, it’s not allowed.
- Very powerful, and simple, generic servant support. You can easily write a delegate to instantiate new objects to handle requests on the fly. This was very complicated in CORBA, and trivial in Ice.
- Context. This is parallel information that is passed along in the channel with each invocation. Rather than making some things part of your call syntax, you can pass it optionally in a parallel channel—sort of out-of-band. This could be used for additional security measures, tweaking knobs on transaction management, etc. I’m planning to use it to help control role-based access control. By passing role information along with every request, and tying it to the proxies themselves, I can make sure that both sides know who is making the request.
- Asynchronous programming. CORBA had this, but not on both sides. You can make both the client and the server asynchronous, which can be useful when you have a potentially long-running request, like an OLAP DB query.
- Facets. This is a way to get multiple views of an object. Specifically, it looks to be ideally suited for dealing with version migration. Dealing with upgrading a 24×7 distributed object system is always hard, this seems to make it at least solvable without slipping into the tar pit of infinite interface inheritance.
- IceBox. This lets you dynamically move servers around, activate as necessary, and basically lets you treat things as services, rather than applications, making much of it transparent to everyone else writing applications.
- Documentation. I can’t stress this enough. It’s outstanding. Not only does it contain reference and tutorial information, it also contains a substantial amount of advice and rationale for decisions in the system.
Their license is similar to MySQL, in that it’s free for non-commercial use, and costs a tidy sum for commercial use. This is a very fair balance, especially since you don’t owe them any money for commercial use until you ship a product. That’s a position that should be adopted by all of the dual-license vendors. It’s in your best interest to make someone successful and help them ship the product.
One area of specific concern, which seems solvable, is the use of bidirectional channels (similar to bidirectional GIOP in CORBA) to make traversing a firewall outward easier. They have a great solution for inward traversal. Also, throughput from box-to-box using the C++ bindings is around 76Mbps, or close to the limits of the 100Mbps pipe/switch that’s between the boxes. The boxes were not saturated, just the pipe. Strangely, the Python bindings, which seem to be using the underlying C++ code, seem to be running 4-5x slower. For the specific tests, I don’t understand why. Latency is nearly identical (0.14ms).
More as I discover it.
Update: Looks like v2.1.0 is out as of yesterday, and it seems to resolve the bidirectional concern! Yay!
This entry was posted at 4:09 pm on 10 March 2005 and is filed under Technology. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
Responses are currently closed, but you can trackback from your own site.
[...] No, this isn’t some horrid nightmare of an ice-skating competition involving coked-up super-models, it’s some spiffy new technology. Today, I got in my email, an announcement that ZeroC has released a beta version of their Internet Communication Engine with bindings for Ruby. I have written about Ice before, and I’ve used it to build some prototype applications using Python and some C++ (ick). [...]