Differences between Ice and CORBA
First of all, we neither wish to start a "CORBA vs. Ice" flame war nor do we want to discredit CORBA. On the contrary, we believe that CORBA was a great achievement for its time, and Ice certainly borrows many good ideas from CORBA.
We decided to write this comparison because we expect that many people will rightfully ask us why they should use Ice instead of CORBA. Our general answer is, why not try out Ice for yourself? We are certain that once you've used Ice for some time, you won't ever want to go back to CORBA. Believe us, it's easy to fall in love with Ice, because of its beauty and simplicity, its architectural consistency, and last but not least its vast array of features and tools.
For those of you who do not have the time to really try Ice to form your own opinion, here are some reasons why we believe Ice is superior to CORBA:
When we say completeness, we mean completeness of real-world products, not completeness of specifications that were never implemented. We believe that Ice is more complete than any single CORBA product on the market. Check it out for yourself: which CORBA product really offers a set of features comparable to Ice?
Due to architectural advantages that CORBA cannot match, Ice has outstanding performance. Ice's highly efficient protocol, request batching, and efficient event forwarding (among other features) mean that it runs faster and consumes less bandwidth on the wire than a CORBA ORB.
No "Design by Committee"
Ice was designed by a small group of dedicated and highly experienced people. Ice doesn't try to be everything for everybody. CORBA specifications, on the other hand, are full of "fantasy material", pushed into specs by vested interests, without really making sure that the specifications can actually be implemented.
Often, the only way to reach agreement during the submission process for a CORBA specification is to take the grand union of the feature sets of all the pre-existing proprietary implementations and to somehow shoe-horn them into a standard. This results in specifications that are far larger and far more complex than necessary. This means that the platform is larger and slower, and that it gets much harder to use the resulting complex APIs. Ice provides APIs that are far smaller, more efficient, and easier to learn than the equivalent CORBA APIs, without compromising functionality.
Slice, the Specification Language for Ice, is smaller, cleaner, and more powerful than CORBA IDL. Slice has fewer language constructs but more flexibility overall. For example, a built-in dictionary type provides direct support for fast-access data structures, and exception inheritance allows cleaner mappings to languages with built-in exception handling. At the same time, Slice does away with many of the unnecessary complexities of CORBA IDL, such as attributes, inout parameters, contexts, and the complexities of Objects-by-Value (OBV).
Ice supports C++, Java, Python, Ruby, PHP, and .NET. We are not aware of any CORBA company that offers so much choice. In fact, most CORBA vendors only offer C++ and Java. If you want to use other languages, you have switch to different vendors, or consider using unsupported experimental CORBA implementations.
Slice is not just an interface definition language. It can also be used to describe the state of persistent Ice objects, making it easy to write servers that automatically store object state in a database.
Slice supports an extensible metadata facility, which allows markup of Slice constructs for application-specific purposes. For example, metadata can be used to customize the Java language mapping to suit the needs of a particular application.
No "Any" Type
Ice does not have an equivalent to the CORBA any type. This may come as a surprise to CORBA users because type Any is used extensively in CORBA specifications. However, an any type is redundant: programming languages such as Java and C++ do not need an any type, and neither does a well-designed distributed system. An any type is typically used in two cases: either there is a need for an opaque type that an intermediate party can receive and pass on without knowledge of the details of the type (such as with the CORBA Event Service), or any is used as the moral equivalent of a union.
Ice can send and receive requests as "blobs" to address the first case, and Slice class inheritance addresses the second case. Either way, the resulting applications are more efficient, more type safe, easier to design and implement, and do not suffer from the complexity associated with the CORBA any type.
The CORBA core has become extremely complicated over time. A prime example is the Portable Object Adapter which requires expert knowledge to use correctly, even though there are only a handful of recurring implementation techniques that need to be supported. The Ice object adapter, on the other hand, is simple and straightforward, and just as powerful as the POA: a few well-designed APIs make short work of what, with the POA, can turn into an extended programming project.
IIOP is one of CORBA's weakest points, with too many design flaws to mention them all. To name a few: missing request encapsulation prevents forwarding services, such as the Event Service, from working without having intimate knowledge of all types involved; inefficient alignment rules force unnecessary data copying; data encoding rules are complex without any concomitant gain in performance; the object reference encoding is very complex, preventing efficient marshaling and memory sharing implementations; codeset negotiation is under-specified and suffers from race conditions; all this complexity means that IIOP is difficult to implement, resulting in interoperability and performance problems. The Ice protocol is simple and more efficient, and it offers features such as data compression and batched requests (which IIOP cannot support).
Security has always been one of CORBA's biggest problems. The OMG has gone through several iterations of on-paper specifications that still do not have widely-available implementations and CORBA customers are still without workable and secure ORBs. When designing Ice, on the other hand, security was always considered essential. That's why Ice offers SSL out of the box and provides a flexible and non-intrusive firewall solution that really works.
Working with CORBA and C++ is very difficult, even for experienced C++ developers. There are countless traps and pitfalls with respect to memory management and exception safety. In contrast, the Ice C++ mapping is very simple and straightforward. It's virtually impossible to have memory leaks because of mistakes. The number of rules to remember is infinitely smaller than the rules of the CORBA C++ mapping, and the Ice C++ mapping is based on the C++ Standard Library.
CORBA is a very scalable technology - provided that you are an expert. With Ice, anyone can write highly-scalable applications. For example, Ice implements a persistent "evictor" pattern for you, which allows you to easily handle millions of objects. All you have to do is to specify the persistent object data in Slice, and let Ice do the rest: the Ice run time automatically loads and saves objects using a high-speed database.
CORBA doesn't have any mechanism to support versioning of object state. Freeze, the persistence service for Ice, allows easy migration of databases when the Slice description of persistent data changes.
IcePatch is a tool that allows you to keep client software up-to-date, using compression for efficient data transmission, and checksums to ensure consistency. CORBA provides no mechanism for distributing software updates around a distributed system.
Typed Event Service
CORBA has a specification for a typed event service, but there are few (if any) implementations. The typed event service also has many known problems, making it virtually unused in real-world deployments. Ice was designed to support typed event services from day one. IceStorm is an efficient typed event service implementation that also supports federation.
CORBA supports inheritance, DCOM supports aggregation. In the past, there was a lot of debate about which is the better approach. Ice supports both: interface inheritance plus aggregation in the form of facets. Facets allow you to extend types at run-time using dynamic aggregation instead of static inheritance.
CORBA supports Asynchronous Message Invocation (AMI), but very few CORBA products implement AMI. Ice supports AMI from day one, in a simple and efficient manner. Ice also supports Asynchronous Message Dispatch (AMD), which doesn't have any equivalent in the CORBA standard. AMD is the server-side equivalent of AMI for clients. With AMI, you can send a request, and later get a callback when the result returns from the server. With AMD, you can return the dispatch thread to Ice, and call back when the result is ready to be delivered to the client. AMI and AMD can be chained, which allows you to build very efficient routers with minimal resource consumption.
AMI and AMD are transparent to both clients and servers. That is, a server does not know whether a request arrived via AMI or was sent synchronously, and a client does not know whether an operation invocation was processed via AMD or synchronously. No Slice changes are required to support AMI and AMD.
We hope the above comments have sparked your interest in Ice. If you have any questions or comments, we invite you to join our mailing list. Our aim is to further improve Ice, and therefore we value your feedback.