In recent days, CORBA has fast become a standard for the development of distributed applications. A CORBA application may consist of one or more CORBA server objects and many clients who connect to these servers. A CORBA server object makes itself available to the client by registering with the CORBA Naming Service or a CORBA Trader Service. A client locates the desired server object on the network by using this Naming or Trader service. Once the server object is located, the client receives a reference to it. Using this reference, the client can invoke methods on the server object and carry out its desired work. Thus it's the client that usually makes use of server facilities; the server simply returns the results of method invocations to the client. However, in some situations, it may be necessary for the server to invoke a method on the client object. For example, the server may like to notify the client of the occurrence of a certain event on the server or the completion of a processing job requested by the client. This method of invocation on the client is called Callback. CORBA specifications allow Callbacks on clients. This article discusses the implementation of CORBA callbacks using Java.

CORBA specification is language-neutral and thus both client and server programs can be implemented in different languages as selected by the programmer. To implement Callbacks, a client must pass a reference of itself to the server. The server is responsible for storing such references to different client objects and calling methods on the appropriate client as and when required. The server must store these references in a language-neutral format. Thus a proper CORBA data type should be used for storing such references. This article uses the example of a traffic light controller to discuss the implementation of CORBA Callbacks using Java. Java has been used as the implementation language for both client and server applications; however, any other language of choice may be used for the implementation.

Each traffic light object, when created, registers itself with the controller. The controller stores the reference to each registered object. The controller object acts as a CORBA server that registers itself with the CORBA Naming Service. A traffic cop object that wishes to control the lights at a particular junction locates the controller object by looking up the CORBA Naming Service for the desired name. Once the controller is located, it'll retrieve the number of lights that the controller is currently managing. The user interface of the cop application shown in Figure 2 displays the panel for each registered traffic light.Using these panels, the cop sets the states (colors) of the various lights and requests appropriate changes to the controller. The controller, in turn, scans through the list of registered lights and requests the lights to set the desired state (color) by calling a method on each of the light objects.

CORBA IDL
The development of a CORBA application begins by writing Interface Definition Language (IDL) code. The CORBA IDL for the traffic lights application is shown in Listing 1.

The module traffic defines two interfaces - TrafficLight and TrafficCoordinator. The TrafficLight interface defines CORBA traffic light objects while the TrafficCoordinator interface defines the CORBA coordinator interface.

The TrafficLight interface contains a short data type that stores the light number. It also provides a method called SetColor(), which is called by the coordinator to set the state of the traffic light. This is a Callback method, which is invoked by a CORBA server object.

The coordinator interface declares a CORBA sequence variable to hold references to registered TrafficLight objects. The sequence is implemented in Java using a Java array or a Java Vector class. The coordinator declares a method called Register(), which is called by the TrafficLight object to register itself with the coordinator. The coordinator declares another method called SetColor(), which is called by the traffic cop application. The SetColor() method receives two parameters - the traffic light number and the color for the light. The coordinator uses this traffic light number to locate the desired traffic light object and sets the color to the desired one by calling SetColor() method on the object.

Mapping IDL to Java
I used Visigenic VBroker for Java for the development of the application. The first step in developing the application is to map the IDL code to Java. The following command line will do the mapping. Note that Visigenic provides the idl2java utility.

idl2java -no_tie -no_comments traffic.idl

The -no_tie option tells the compiler not to generate the tie classes and the -no_comments option disables the comments generation. The compiler creates a Java package with the same name as the CORBA module - traffic. The two CORBA interfaces are mapped to two Java interfaces - TrafficLight and TrafficCoordinator. The idl2java compiler also creates the implementation classes and the example classes for the two interfaces. The files _example_TrafficLight.java and _example_TrafficCoordinator.java can be used to provide the implementation of the two CORBA interfaces. Maintain a backup of the original files to ensure that your implementation code isn't overwritten the next time you run idl2java compiler. Copy the _example_TrafficLight.java to TrafficLightImpl.java and _example_TrafficCoordinator.java to the TrafficCoordinator.java file. You'll write your implementation code in the newly copied files.

Developing the Application
The source code for TrafficLightImpl.java is given in Listing 2. The class declares a variable number of short data types for holding the light number. It declares one more variable of Java class type as TrafficLightServer. The source for the TrafficLightServer class is given in Listing 3 and is discussed later. The class TrafficLightServer creates the object of TrafficLightImpl class. The SetColor() method of the implementation class (TrafficLightImpl) uses this reference to call the SetColor() method on the TrafficLightServer object. The constructor for the TrafficLightImpl class receives two parameters - the reference to TrafficLightServer object, which called this constructor, and the light number. The two parameters are saved into the two class variables discussed above. The constructor prints an appropriate message to the user upon successful creation of the object. The accessor and modifier methods for the LightNumber attribute, respectively, retrieve and save the value to the local class variable - Number. The SetColor() method of TrafficLightImpl class simply calls the SetColor() method of the TrafficLightServer class.

Now look at the implementation of the TrafficLightServer class given in Listing 3. This class is derived from the Frame class and is a Java command line program. The program receives one command line argument that specifies the number for the traffic light to be created. The init() method sets the location of the frame, depending on the light number. For simplicity, only four traffic light objects are considered. The init() method then builds the user interface for the traffic light object by creating three objects of the TLightPanel class. The object hierarchy for the user interface of TrafficLightServer is shown in Figure 3.

The TLightPanel class is derived from Panel class and creates a traffic light in the panel painted in a given color.

After creating the three TLightPanel objects and adding them to the container, the init() method of the TrafficLightServer class sets the listener for window events, and sets the default light color to red by calling the SetRedLight() method. Once the user interface is constructed, the main() method of the TrafficLightServer class resolves the reference to the CORBA Naming Service and locates the coordinator object. It registers the newly created traffic light object with the coordinator by calling its Register() method. The program then waits for invocations to be made by the controller.

The TrafficCoordinatorImpl class provides the implementation for the CORBA TrafficCoordinator interface. The source for the TrafficCoordinatorImpl class is given in Listing 4. The class declares a variable called LightsList from the Java Vector class. This Vector variable is used for implementing the CORBA sequence declared in IDL. The class constructor prints an appropriate message to the user upon successful creation of the object. The accessor method for the lights attribute copies each element of the vector into an array of TrafficLight objects and returns the array to the caller. The modifier method for the lights attribute isn't implemented as this isn't required for the current application. The Register() method receives the reference to the traffic light object and copies it into the vector. The method then prints an appropriate message to the user upon successful registration of the light. The SetColor() method is called by the traffic cop application. The method receives two parameters - the light number and the color to be set. Note that the color parameter is passed as a Java String rather than as an object of the Java Color class. CORBA doesn't provide a Color data type. Thus, if you use the Color class in Java, you'll need to implement both the traffic cop application and the coordinator application. The method SetColor() iterates through the list of registered light objects, and for each object the internal light number is verified against the number received as a parameter. If the match is found, the SetColor() method on the matched light object is called. The TrafficCoordinatorImpl class is instantiated by the TrafficCoordinatorServer class.

The TrafficCoordinatorServer class source is given in Listing 5. The main() method of the class initializes the ORB, creates the coordinator object and exports it to ORB. The method then obtains a reference to the Naming Service and binds the newly created object to the Naming Service with the name Coordinator. The TrafficLight and TrafficCop objects locate the coordinator object using this name. The coordinator then simply waits for invocations to occur.

Finally, the TrafficCop class creates a traffic cop application. The cop application locates the desired controller object and receives a list of registered objects from the controller. The user interface then shows all the lights with the initial color for each light set to red. The object hierarchy for the user interface is shown in Figure 4.

The user interface allows the user to click on each of the traffic light objects to select the desired color. After the selection of state for each light object, the user presses the Set button to set the various traffic lights to the desired states.

The main() method of the TrafficCop class initializes the ORB and obtains a reference to the Naming Service. It then locates the Coordinator object and obtains a reference to it. The program retrieves the array of light objects from the coordinator by calling the accessor method - lights() - on the coordinator object. The main() method then creates an instance of the TrafficCop class. The constructor of TrafficCop calls the init() method, of the class to construct the user interface of the application. The class constructor calls the init() method, which constructs the object of the TrafficBasePanel class and a button object and adds the two components to the container using BorderLayout manager. The program then sets the window event listener and displays the frame window to the user.

The TrafficBasePanel class is derived from the Panel class. The class constructor looks up the number of light objects received by the cop object and constructs the number of TrafficLightsPanel objects that's equal to this number.

MAXPANELS = Cop.Lights.length;
LightsPanel = new TrafficLightsPanel[MAXPANELS];

Each TrafficLightsPanel object displays a traffic light consisting of three light objects. The class constructor calls the init() method, which sets up a layout manager to display the four light panels and add them to the base panel. Once again, for simplicity, only four lights are considered.

The Update() method of the TrafficBasePanel class is called by the TrafficCop object whenever the user presses the Set button. This causes a refresh of all the panels displayed on the Cop user interface to reflect the changes made by the user. The Update() method iterates through all the displayed light panels, retrieves the color setting for each panel and calls the SetColor() method on each of the light objects.

for (int i=0; i {
Cop.Lights[i].SetColor (LightsPanel[i].clr);
}

The TrafficBasePanel class may hold up to four TrafficLightsPanel objects. The TrafficLightsPanel class constructor calls the init() method to do the user interface. The init() method creates three LightPanel objects for red, amber and green lights and adds them to the container. It then calls the SetRedLight() method of the class to set the default light selection to Red. The SetRedLight() method sets the color of the red light to red and the colors for the other two lights to gray. Similarly, the other two methods - SetAmberLight() and SetGreenLight() - set amber and green lights, respectively, and set the rest of the lights to gray. The TrafficBasePanel class implements the MouseListener interface. In the mousePressed() event, the clr string variable of the class is set to the appropriate color value, depending on the LightPanel object being clicked. The event handler also calls the appropriate set() method for setting the color of the traffic light to the desired one. For example, a click on the red light highlights the red light and the other two lights are turned gray.

Last, the LightPanel class is used for drawing individual lights - red, amber and green. The class constructor receives a reference to the TrafficLightsPanel object so the mouse events can be passed on to it. The second parameter specifies the color of the light. Depending on this parameter, the appropriate color string - red, amber or green - is printed on the light. The paint() method constructs the visual appearance of the traffic light. The SetColor() method of the class is called whenever the user updates the display of the cop application by pressing the Set button. The method copies the received color into the local class variable and repaints itself to show the changes.

Compiling the Application
As mentioned earlier, Visigenic VBroker for Java was used for developing and testing the application. The first step in building the application is mapping the IDL code to Java using the idl2java utility supplied by Visigenic. The following command line is used for mapping IDL code to Java:

idl2java -no_tie -no_comments traffic.idl

To compile the several Java classes discussed above and shown in Listings 2 through 6, use the make.bat file shown in Listing 7. This creates all relevant files for the application. The next step is to run the application. Running the Application
To run the application, start the osagent service and the CORBA Naming Service. The following two command lines start these services:

start osagent –C

vbj -DORBservices=CosNaming -DSVCnameroot=TRAFFIC -DJDKrenameBug com.visigenic.vbroker.services.CosNaming.ExtFactory TRAFFIC namingLog

Next, start the coordinator service using the following command line:

start vbj -DORBservices=CosNaming -DSVCnameroot=TRAFFIC -DOAid=TSession TrafficCoordinatorServer

Once the coordinator is started, create the traffic lights using the following command:

vbj -DORBservices=CosNaming -DSVCnameroot=TRAFFIC -DOAid=TSession TrafficLightServer 1

This creates Traffic Light #1 and registers itself with the coordinator. The appropriate message is printed in the coordinator window. Likewise, create three more traffic lights, replacing the command line parameter with the appropriate number for each light.

At this stage, the screen displays four traffic lights (see Figure 2). Next, start the traffic cop application by using the following command line:

vbj -DORBservices=CosNaming -DSVCnameroot=TRAFFIC -DOAid=TSession TrafficCop

The user interface for the traffic cop is shown in Figure 2. Click on the individual lights to set the desired colors and press the Set button. The corresponding lights will be set on the four light objects.

I didn't provide an unregister method for the traffic light. Thus, if you close a traffic light and re-create it, two copies will be registered with the coordinator. If you restart the cop application, both copies will be shown on the cop panel. To avoid this situation, close the coordinator and the cop and rerun the application if any of the lights need to be closed.

Conclusion
Callbacks in CORBA allow the CORBA server to call a method on the client. The callbacks are achieved by saving the reference to the client in the server class. The server object is responsible for tracking such references and invoking any of the public methods on the desired client by using these references. Callbacks are very useful in real-life situations to notify the client of the occurrence of a certain event or of the completion of processing on the server end. This article has discussed one such real-life example and explained how CORBA callbacks are implemented using Java.