CORBA

The Common Object Request Broker Architecture (CORBA) is intended for creating, distributing and managing distributed objects in a network. CORBA is best known for its Remote Method Invocation (RMI), but many other specifications add to this basic functionality. The specifications are developed by the Object Management Group (OMG, http://www.omg.org).

CORBA integration requires CORBA middleware in both ends of the connection. All applications need at least an Object Request Broker (ORB). This provides an API for basic remote method invocation. Stubs and skeletons hide the actual request and reply processing over the network. The ORBs themselves communicate via an Inter ORB Protocol, which must be implemented for the transport technology used (e.g. IIOP for TCP/IP). The more advanced CORBA Services (e.g. Notification Service) use the ORB and the basic RMI to provide higher-level communication functionality. Applications access these functions through various service specific APIs.

CORBA’s suitability for control systems can be evaluated against our classification of desirable interaction mechanisms (see section 3.4). As CORBA is basically a collection of specifications, we need to find the appropriate ones. A remaining task is to find a suitable CORBA implementation supporting the selected services. The following discusses shortly how various CORBA specifications might contribute to some of our communication scenarios.

As described in section 3.4, the request-reply mechanism is used for accessing a service provided by some other component or for performing a remote read or write action. Remote method invocation, which is at the heart of CORBA, matches well for this purpose. It was the first functionality specified, and many other CORBA services use it as the basic mechanism. It is an object-to-object, two-way synchronous remote method invocation service, which involves getting a reference (stub) to a remote object, calling the stub’s method and waiting until the method returns with related return values. References to remote objects can be retrieved from naming services, if one is needed. Continuous data distribution is a distributed version of the traditional “signal wiring” concept, familiar to the majority of automation designers. CORBA’s basic RMI service has some properties reducing its applicability for continuous data distribution. Continuous data distribution does not require return values, and blocking a call made by a real time control application is seldom acceptable. The ORB’s Dynamic Invocation Interface (DDI) allows one-way method calls, which do not involve any return values. This could be used for sending signal values periodically to a target node. Just like the plain CORBA RMI, DDI uses object references to the target object. In one-to-many

data distribution, this causes major reference and name management issues. Although the CORBA Naming Service may provide some help in locating object references by name, the application still has to manage and communicate with low-level software constructs.

The new CORBA Data Distribution Service (DDS) attempts to standardise a high-level API for a real-time publish subscribe. It includes the Data Centric Publish Subscribe protocol (DCPS), which encapsulates the complexities of distributed naming and reference management and network layers behind a developer-friendly interface. DCPS interfaces provide the developer with methods for naming signals (“topics”), creating communication objects, configuring communication flows (e.g. publish, subscribe) and for the actual data transfer (e.g. send_issue, receive_issue). The links and details of the transmissions are processed behind the scene by the middleware implementation. The full specification version 1.0 is available from OMG (OMG 2005).

Compared to some other CORBA specifications with tens or even hundreds of implementations, the new DDS is implemented by just a small group of companies (RTI 2004, OIS 2005, Thales 2005). The US company Real-Time Innovations (RTI) has been the driving force behind DDS, and its latest NDDS middleware version implements the specification. RTI was also involved in developing the IDA Group’s RTPS protocol. For event-driven communication, the CORBA Messaging Specification includes a model for Asynchronous Messaging Invocation (AMI). The AMI call-back model can be used for event-based applications that use asynchronous calls (OCI 2002). Such calls relieve the client from having to wait for a call to return, which may sometimes take an unpredictable time. The answer is propagated back to a separate reply handler. This has code, which is invoked by the client ORB when the reply is received. The server needs not to be aware that AMI is used; the client ORB will notice asynchronous requests and map them to the appropriate reply handler.

In event-based applications, an event consumer registers at an event source, after which it receives events via a call-back method. The supplier should not need to keep track of consumers and how they are contacted. The CORBA Event Service provides a convenient way of developing event notification systems (Henning & Vinoski 1999). Its flexibility is achieved by using an event channel as shown in Figure 28 (OMG 2002). There can be many suppliers and many consumers, and no direct link is made between them. For example, consumers do not need to know the object references of the suppliers and suppliers do not need to keep track of consumers. This leads to robust code for the client and server applications, since it does not matter if some new object will take the role of a supplier or if new consumers register. The mechanism is similar to the real-time publish-subscribe protocol of IDA (see section 4.3.2).

Figure 28. Event delivery in the CORBA Event Service.

Figure 28 illustrates different models for event delivery. A push supplier actively gives events to the channel, while the channel is responsible for obtaining events from pull suppliers. A pull-consumer will explicitly request events from the channel while the channel delivers events to push-consumers. Consumers and suppliers with different models can be attached to a single event channel.

The event channel does not try to interpret the event data in any way. This means that all events from any supplier to the event channel are delivered to all consumers attached to the same channel. The channel does no event filtering. The CORBA Notification Services, however, provide advanced filtering mechanisms, which can be used to limit the incoming message flow to the ones the consumer is interested in.