45.

  

Migrating a CORBA Client to Jini

Both of the examples in this chapter started life as pure CORBA systems written by other authors, with CORBA objects delivered by servers to a CORBA client. The clients were both migrated in a series of steps to Jini clients of a Jini service acting as a front-end to CORBA objects. For those in a similar situation, it may be worthwhile to spell out the steps I went through in doing this for the room-booking problem:

1. The original client was a single client, mixing GUI elements, CORBA calls, and glue to hold it all together. This had a number of objects playing different roles all together, without a clear distinction about roles in some cases. The first step was to decide on the architectural constraint: one Jini service, or many.
2. A single Jini service was chosen (for no other reason than it looked to offer more complexities). This implied that all CORBA- related calls had to be collected into a single object, the RoomBookingBridgeImpl . At this stage, the RoomBookingBridge interface was not defined ”that came after the implementation was completed (okay, I hang my head in shame, but I was trying to adapt existing code rather than starting from scratch). At this time, the client was still running as a pure CORBA client ”no Jini mechanisms had been introduced.
3. Once all the CORBA related code was isolated into one class, another architectural decision had to be made: whether this was to function as a fat or thin proxy. The decision to make it thin in this case was again based on interest rather than functional reasons.
4. The GUI elements left behind in the client needed to access information from the CORBA objects. In the thin proxy model, this meant that portable Jini objects had to be built to carry information out of the CORBA world. This led to interfaces such as JavaRoom and implementations such as JavaRoomImpl . The GUI code in the client had no need to directly modify fields in these objects, so they ended up as read-only versions of their CORBA sources. (If a fat proxy had been used, this step of creating portable Jini objects would not have been necessary.)
5. The client was modified to use these portable Jini objects, and the RoomBookingBridgeImpl was changed to return these objects from its methods . Again, this was all still done within the CORBA world, and no Jini services were yet involved. This looked like a good time to define the RoomBookingBridge interface, when everything had settled down.
6. Finally, the RoomBookingBridgeImpl was turned into a UnicastRemoteObject and placed into a Jini server. The client was changed to look up a RoomBookingBridge service rather than create a RoomBookingBridgeImpl object.

At the end of this, I had an implementation of a Jini service with a thin RMI proxy. The CORBA objects and servers had not been changed at all. The original CORBA client had been split into two, with the Jini service implementing all of the CORBA lookups. These were exposed to the client through a set of facades that gave it the information it needed.

The client was still responsible for all of the GUI aspects, and so was acting as a "knowledgeable" client. If needed, these GUI elements could be placed into Entry objects, and also could be exported as part of the service.