Internet Communications Engine
From Wikipedia, the free encyclopedia
This article needs additional citations for verification. Please help improve this article by adding reliable references (ideally, using inline citations). Unsourced material may be challenged and removed. (February 2009) |
The Internet Communications Engine, or Ice, is an object-oriented middleware that provides object-oriented Remote Procedure Call, grid computing, and Publish/subscribe functionality developed by ZeroC and dual-licensed under the GNU GPL and a proprietary license. It supports C++, Java, .NET, Visual Basic, Python, Ruby and PHP on most major operating systems such as Linux, Solaris, Windows and Mac OS X. A light variant of ICE runtime, called Ice-e, may run inside mobile phones and iPhones. As its name indicates, the middleware may be used for internet applications without the need to use the HTTP protocol and is capable of traversing firewalls unlike most other middleware.
Contents |
[edit] ICE and CORBA
ICE was influenced by CORBA in its design, and indeed was created by several influential CORBA developers, including Michi Henning. However, it is much smaller and less complex than CORBA. According to ZeroC's webpages[citation needed], this is partly a result of being designed by a small group of experienced developers, instead of suffering from design by committee.
[edit] ICE Components
ICE is a set of CORBA like components that include object-oriented remote-object-invocation, replication, grid-computing, failover, load-balancing, firewall-traversals, and publish-subscribe services. To gain access to those services, applications are linked to a stub library or assembly, which is generated from a language-independent IDL-like syntax called slice.
[edit] IceStorm
is an object-oriented publish-and-subscribe framework that also supports federation and quality-of-service. Unlike other publish-subscribe frameworks such as TIBCOs’ Rendezvous or SmartSockets, message content consist of objects of well defined classes rather than of structured text.
[edit] IceGrid
is a suite of frameworks that provide object-oriented load-balancing, failover, object-discovery and registry services.
[edit] IcePatch
facilitates the deployment of ICE based software. For example, a user who wish to deploy new functionality and/or patches to several servers may use IcePatch.
[edit] Glacier
is a proxy-based service to enable communication through firewalls, thus making ICE an internet communication engine.
[edit] IceBox
is a SOA-like container of executable services implemented in .dll or .so libraries. This is a lighter alternative to building entire executable for every service.
[edit] Slice
Slice is a Zeroc-proprietary file format that programmers follow to edit computer-language independent declarations and definitions of classes, interfaces, structures and enumerations. Slice definition files are used as input to the stub generating process. The stub in turn is linked to applications and servers that should communicate with one another based on interfaces and classes as declared/defined by the slice definitions.
Apart from CORBA, classes and interfaces support inheritance and abstract classes. In addition, slice provides configuration options in form of macros and attributes to direct the code generation process. An example is the directive to generate a certain STL list<double>
template instead of the default, which is to generate a STL vector<double>
template.
[edit] Comparisons to other major middleware
[edit] SOAP
Ice also compares favorably to SOAP, the main advantages being that it's more object oriented, and offers vastly superior performance in terms of both bandwidth and processor load, because SOAP is based on HTTP and XML, which needs to be parsed, while Ice uses a binary protocol designed for high performance and low verbosity. However, Ice might not offer similar performance or compactness advantages when SOAP messages are exchanged using a more efficient transport and message encoding such as SOAP/TCP and Fast Infoset.
[edit] CORBA
[edit] TIBCO Rendezvous/EMS
Rendezvious is a asynchornous publish/subscribe only middleware from TIBCO that provides text based messaging as well as its own proprietary name value pair format. A deamon runs at the client side and communicates with subscribing client processes through IPC pipes or TCP/IP. The deamon mediates between client processes and deamons that handle publishing servers. Those deamons support multicast as well as broadcast communication. EMS stands for Enterprise Messaging Services and is bascially only an interface on top of Rendezvous and Java style messaging. EMS is thus a superset of Rendezvous with the addition of message queues.
[edit] Talarian Smartsockets
The differences to Rendezvous/EMS above are the lack of a payload format and a daemon running on the client side. Instead, a number of publish/subscribe daemons run somewhere on the network collectively called a cloud. This provides better performance and failover since the communication is split between several daemons and once a daemon run into an unavailable state, clients may automatically switch to another daemon. The cloud also catches published data and provides an interface for clients to retrieve the data. Any clients may therefore request for last published data anytime without having to wait for sources to republish the data. The latter mechanism is currently missing in ICE.