CORBA Program Development, Part 2

In our last article, we introduced the concept of distributed programming with CORBA from a high-level point of view. In order to further flush out the CORBA infrastructure, we need to detail some of the standard services that the OMG (Object Management Group) has defined that should be supplied at least in part by most ORB vendors. Among these are the Trader Service, the Naming Service, the Event Service, the Interface Repository and the Implementation Repository.

The OMG has defined only the interface to each service while not attempting to provide an implementation. This means an OMG Service is actually nothing more than a CORBA interface written in IDL (Interface Definition Language). If a particular service is not available within a particular ORB or is not well-implemented, the developer always has the option of writing a custom implementation for the interface. In fact, if a vendor is truly CORBA-compliant, one vendor's implementation of a service can be used with another vendor's implementation of the ORB. This ability to mix and match CORBA-compliant implementations allows for flexible approaches to CORBA solutions. In this article, we will describe two of the most commonly provided OMG Services: the Naming Service and the Event Service. Our sample code is written using the feature-rich and GNU-licensed MICO CORBA implementation and demonstrates how to use both the Naming and Event Services in C++.

Last month, we introduced the concept of an IOR (Interoperable Object Reference), which we said was like a phone number or mailing address for the remote object. The client application can use the IOR to locate the remote object and establish communication. In that article, we handed the client application the IOR by writing it to a file and passing the file to the server application at startup. In practice, this is an inconvenient way to design a system. One of the most common approaches to solving the problem of locating objects at runtime is to use the OMG Naming Service. The Naming Service is an interface to a database where an object's name is associated with its IOR.

In order to understand the Naming Service, it is often helpful to think in terms of the UNIX directory structure. The Naming Service is comprised of objects called naming contexts. A naming context can be thought of as a directory within a file system, ultimately deriving from a common root directory (the “root” context). Each name within a naming context must be unique. Since naming contexts are actually objects, a naming context can be registered with another naming context. In effect, this is analogous to creating a subdirectory within another directory in a file system. The hierarchical structure created by this method is called a naming graph. In order to simplify finding objects within a naming graph, the Naming Service allows objects to be referred to by compound names, which are similar to an absolute path name in UNIX.

The name under which an object is registered in the Naming Service is completely discretional and not required to even describe the actual object. In the Naming Service, the object's name is defined by a NameComponent object. These NameComponent objects are then stored in a particular naming context. The NameComponent object actually consists of two parts, an “identifier” and a “kind”. The NameComponent is represented in IDL as:

struct NameComponent {
Istring id;
Istring kind;
};

Returning to the UNIX file system analogy, a UNIX file called Consumer.C would have an identifier of Consumer and a kind of C. In the same manner, an object may be stored in a naming context with an identifier of BusinessObject and a kind of java. The developer can thus use any naming standard he wishes when defining objects using the Naming Service.

In order for a CORBA client object to use the Naming Service to find other objects, it must know where to find the naming service. The preferred method of finding the Naming Service is to use the OMG method resolve_initial_references. Under most ORB solutions, resolve_initial_references will return the IOR of the “root naming context”, or in effect, the root directory node.

In simplest terms, when a server application is launched, it registers or “binds” objects it wishes to expose with the Naming Service using compound names. This is accomplished through the bind and rebind methods. The client application can then look up a particular object's IOR simply by resolving the object's compound name, which the client must know. The client application uses the resolve method to find an IOR from a given compound name. Once the name has been resolved and the IOR obtained, the application can narrow (narrowing an object is CORBA terminology for downcasting) the object reference to resolve the actual object implementation; from that point on, the object can be used as usual. Later, our example demonstrates how you might use the Naming Service to register and locate object implementations.

Another service with an OMG-defined interface is the Event Service. The OMG Event Service specification provides for decoupled message transfer between CORBA objects. The decoupling of communication provided by the Event Service allows for flexibility in terms of communication modes and methods. Specifically, it allows one object (Supplier) the ability to send messages to another object (Consumer) that is interested in receiving those messages without having to know where the receiver is or even whether the receiver is listening. This decoupling provides several important benefits:

Two primary styles of interaction exist between Suppliers and Consumers and the Event Channel: Push and Pull.

In the Push Method, a Supplier will connect to the Event Channel and initiate a push of an event onto the Event Channel whenever it is ready to do so. It is the Event Channel's responsibility to buffer those events until they are delivered to one or more interested Consumers. In the Push Model, it is the Supplier that initiates the flow of events to the Event Channel. When a Supplier wants to connect to an Event Channel, it needs an object within the Event Channel to “pretend” it is a Consumer. This allows the Supplier to simply deliver events to its “Consumer”, when in reality, its Consumer is simply a proxy for the actual Consumer, which is outside the Event Channel. It is to this proxy “Consumer” that the Push Supplier pushes events. Thus, the Proxy object is not a real Consumer, but merely an object within the Event Channel that provides a delivery mechanism through which the Supplier can deliver messages.

A Push Consumer will likewise connect to a “proxy” object, a proxy that represents the Push Supplier. When the Event Channel has a message available, the Push Supplier proxy will deliver (push) the message to the actual Consumer object. The message path is from the actual Push Supplier, through its Proxy Push Consumer, to the Proxy Push Supplier and finally to the Push Consumer itself. There are other variations of this, as our later example will show.

In the Pull Method, the Event Channel will pull data from the Supplier. In the Pull Model, it is the Consumer that drives the delivery of messages. A Pull Supplier will connect to a Proxy Pull Consumer. Again, as far as the Pull Supplier is concerned, it can consider this proxy object as a real Consumer that will request events periodically. An interested Pull Consumer object will then connect on the other end of the Event Channel to a Proxy Pull Supplier. When a Pull Consumer is ready to receive an event, it will initiate either a pull or try_pull call on its Proxy Pull Supplier, which will in turn query the Proxy Pull Consumer connected to the actual Pull Supplier, to request another event be delivered. In this way, the Consumer drives the data, when it is ready to process another message. Some implementations of the Pull Method will allow the Proxy Pull Supplier to periodically pull events from the Supplier at regular intervals in an attempt to keep a buffer full of events for consumers when they request delivery.

The nice thing about the Event Channel abstraction is a communication does not need to be either entirely Push Model or Pull Model. A Push Supplier may indirectly connect to one or more Pull Consumers, and several Pull Suppliers may connect to one or more Push Consumers. It is the Event Channel logic that allows such interrelationships disproportionality among objects. It is the application design that drives the decisions concerning suppliers, consumers and their numbers.

Regardless of the relationship among suppliers and consumers, to establish a connection and deliver events through the Event Channel the following five steps must be taken:

When messages are delivered through the Event Channel, they can be either “typed” or “untyped”. Typed messages are those defined in an IDL which are type-checked at compile time. Untyped events, the most common, adhere to the standard Event Services interfaces and are packaged as type CORBA::Any, which is a wrapper around all known CORBA types. It is this “Any” type that is actually sent from a Supplier Object to a Consumer Object. The Supplier will construct an Any, and the Consumer, upon receipt of the message, will derive the true value from the Any wrapper. This allows for great flexibility in delivering messages, as a Supplier may pass a string first, a long value second and an array third, all through packaging the values into an Any. The example code shows how to create, embed and extract values from Any types.

Our example incorporates both the Naming Service lookup as well as an implementation of a Supplier and a Consumer interacting through the use of the Event Service. The Supplier implements the Push Supplier Model and the Consumer implements the Pull Consumer Model, thus illustrating that the models do not have to be all of one type. Listing 1 shows Consumer.C, and Listing 2 shows Supplier.C. These listings are available by anonymous download in the file ftp://ftp.linuxjournal.com/pub/lj/listings/issue62/3213.tgz.

The first step the Consumer must take is to find the root naming context. This is accomplished by calling resolve_initial_references and then narrowing the returned IOR. The resulting object is the root naming context we can then use to resolve our Event Service.

CORBA::Object_var nsobj =
orb->resolve_initial_references("NameService");
assert(! CORBA::is_nil(nsobj));
CosNaming::NamingContext_var context =
CosNaming::NamingContext::_narrow(nsobj);
assert(! CORBA::is_nil(context));

As we turn to the Event Service sections of the code, we notice that the first thing the Consumer does after obtaining the initial context from the Naming Service is resolve and narrow the EventChannelFactory.

CosNaming::Name name;
name.length(1);
name[0].id =
CORBA::string_dup("EventChannelFactory");
name[0].kind = CORBA::string_dup("factory");
CORBA::Object_var obj;
obj = context->resolve(name);

SimpleEventChannelAdmin::EventChannelFactory_var
        factory;
CosEventChannelAdmin::EventChannel_var event_channel;
factory =
SimpleEventChannelAdmin::EventChannelFactory::_narrow(obj);
event_channel = factory->create_eventchannel();

name.length(1);
name[0].id =
CORBA::string_dup("TestEventChannel");
name[0].kind = CORBA::string_dup("");
context->bind(name,<\n>
CosEventChannelAdmin::EventChannel::
_duplicate(event_channel));

CosEventChannelAdmin::ConsumerAdmin_var
Consumer_admin;
Consumer_admin = event_channel->for_consumers();
...
CosEventChannelAdmin::ProxyPullSupplier_var
proxy_Supplier;
proxy_Supplier =
Consumer_admin->obtain_pull_Supplier();

proxy_Supplier->connect_pull_Consumer
(CosEventComm::PullConsumer::_duplicate(Consumer));

interface PullSupplier
  {
    any pull() raises(Disconnected);
    any try_pull(out boolean has_event)
         raises(Disconnected);
    void disconnect_pull_Supplier();
  };

CORBA::Any* anyval;
CORBA::Boolean has_event = 0;
anyval = proxy_Supplier->try_pull(has_event);

Once the has_event value is true and an Any value is retrieved, the Consumer must decide first what type it is, then extract that value from the Any wrapper in order to use it. The code to do that uses the Any's overloaded >>= operator. This strange-looking beast will attempt to extract the Any into the destination type. If the type contained in the Any is compatible with the destination type, the value is extracted from the Any; if not, null is returned. The usual way to check for the value is to do something like the following:

if( *anyval >>= shortval )
  {
    cerr << "Consumer: thread pulled short:
         " << shortval << endl;
  }
  else if( *anyval >>= doubleval )
  {
    cerr << setiosflags(ios::fixed);
    cerr << "Consumer:
         thread pulled double: " << doubleval << endl;
  }

In our case, when we extract the correct type from the Any, we print it out and immediately begin checking again for events through our try_pull call.

Our Supplier implementation is a bit simpler. After binding to the ORB, it creates an implementation of a class that implements the CORBA PushSupplier IDL:

class PushSupplierImpl :
virtual public CosEventComm::PushSupplier_skel
{
public:
PushSupplierImpl() { }
void disconnect_push_Supplier();
};
...
  PushSupplierImpl * Supplier =
  new PushSupplierImpl();

This class implements the IDL PushSupplier interface, which has only a single function to implement: disconnect_push_Supplier. The implementation object, PushSupplierImpl * Supplier, will be used later to connect to the Event Channel and register our interest in supplying events to the Channel.

Just as the Consumer started by finding the root Naming Context, our Supplier begins by calling resolve_initial_references. Using the IOR returned by resolve_initial_references, the Supplier can then narrow to the naming context object.

CORBA::Object_var nsobj =
orb->resolve_initial_references("NameService");
assert(! CORBA::is_nil(nsobj));
cerr << "Supplier: successful call to \
resolve_initial_references()" << endl;
CosNaming::NamingContext_var context =
CosNaming::NamingContext::_narrow(nsobj);
assert(! CORBA::is_nil(context));

Once the name is resolved and narrowed, the Supplier attempts to retrieve a SupplierAdmin object through a call to the event channel's for_suppliers function.

CosNaming::Name name;
name.length(1);
name[0].id = CORBA::string_dup("TestEventChannel");
name[0].kind = CORBA::string_dup("");
CORBA::Object_var obj;
...
obj = context->resolve(name);
...
CosEventChannelAdmin::EventChannel_var
event_channel;
CosEventChannelAdmin::SupplierAdmin_var
Supplier_admin;
...
event_channel =
CosEventChannelAdmin::EventChannel::_narrow(obj);
Supplier_admin = event_channel->for_suppliers();

CosEventChannelAdmin::ProxyPushConsumer_var
proxy_Consumer;
...
proxy_Consumer =
Supplier_admin->obtain_push_Consumer();

proxy_Consumer->connect_push_Supplier(
CosEventComm::PushSupplier::_duplicate(Supplier));

interface PushConsumer
{
void push(in any data) raises(Disconnected);
void disconnect_push_Consumer();
};

CORBA::Any any;
any <<=(CORBA::ULong) 555555555;
proxy_Consumer->push(any);

Our example was built using the egcs 1.1b C++ compiler and MICO 2.2.1. In order to build and run the example, once you have unpacked the tar file, you simply need to update the variable MICO_BASEDIR in the Makefile to point to your base Mico installation, then type make. This will build both the Supplier and Consumer. To run the application, we've provided a simple script that starts the rather lengthy MICO naming and event services for you automatically, then starts the Consumer (which creates the Event Channel), then the Supplier. To run the script, simply type runit. You will see the progress of the Supplier writing messages to the Event Channel, and the Consumer extracting them from the Event Channel; as it does so, it prints them out. Our Supplier will push, in succession, a long, a short, a double, a string, and finally another long (the number 13), which signals to the Consumer that it is finished. At that point, the Consumer thread exits and the applications are killed by the runit script.

Our next article will discuss an implementation of VisiBroker for Java that can be made available for development of clients and servers completely on Linux using Sun's JDK.

Resources

Home page for the Object Management Group: http://www.omg.org/

Introduction to CORBA: http://www.omg.org/news/begin.htm

The Free CORBA Page: http://adams.patriot.net/~tvalesky/freecorba.html

Java port for Linux: http://java.blackdown.org/

The CORBA FAQ: http://www.cerfnet.com/~mpcline/Corba-FAQ