The OrbixTalk product presents a different programming model. It provides a reliable multicast messaging system whereby a message can be delivered to a number of recipients who register their interest in a particular type of message. The recipient of a message is an Orbix object contained within an application that is running on the same or a different host from the application that is sending the message. The same message may be received by objects in applications running on several different hosts within a subnet.
The sender of a message is termed a talker, the receiver is termed a listener. Talkers generate messages and listeners receive them. Any particular message stream is uni-directional, from one or more talkers to one or more listeners. The communication between the talker who sends the message and the listener who receives the message is decoupled because the sender has no way of finding out who are the recipients of its messages.
OrbixTalk MessageStore extends the OrbixTalk product by adding persistence. Using OrbixTalk MessageStore, a talkers's messages are stored on disk so that new listeners may request playback of messages of interest that had arrived prior to the launch of the listener or that arrived while the listener was temporarily unavailable.
OrbixTalk also supports the CORBA Event Service, one of the CORBAservices specified by OMG to extend the core CORBA standard. The Event Service is CORBA's specification of how applications that require decoupled communication semantics may be built. In the terminology of the Event Service, the sender of a mesage is a supplier and the receiver is a consumer. The Event Service defines two models of communication between suppliers and consumers: in the push model, suppliers supply events to consumers; in the pull model, consumers request events from suppliers. IONA's implementation of the Event Service extends the CORBA standard by offering multicast of messages and a MessageStore to provide persistence and playback of events.
Most applications will find it easier to use OrbixNames than the Orbix
_bind() function call in order to locate the objects they need to use. An advantage of OrbixNames is that the name associated with an object is independent of any properties of the object it refers to; in particular, a name is independent of an object's interface, server or host name. This is not the case with _bind() which provides a more primitive mechanism for obtaining an object reference.
OrbixWeb introduces full Orbix functionality to the Java environment, with a complete mapping from CORBA IDL to Java. This allows Java programmers to exploit the advantages of CORBA standard connectivity to objects distributed across networks.
This integration extends the flexibility of Java, allowing Java applications to easily communicate with CORBA objects located on remote hosts, across heterogeneous platforms, and implemented in a wide range of programming languages.