Hiding the interaction with CORBA behind the interfaceBroker allowed my team to implement the demo system on schedule.
CORBA or. Com? How about both
Has this ever happened to you? You are building a solution on a tight timeline, and key infrastructure decisions – like choosing between Microsoft’s COM/COM+ and OMG’s CORBA – have not been made.
You must get started now, but what can you do? Consider hiding the indecision behind a generic interface, like my team did.
Recently, my research team was working on a demonstration system to show off some fancy new technologies, but we could not decide whether to implement the demo over CORBA or COM. Since the object request broker (ORB) was not the focus of the demonstration, I kept on deferring the decision. (Actually I kept on saying, “We have to do both.”)
To overcome my indecision, instead of programming to CORBA or COM, my team created a generic interface to target. From a developer’s point of view, CORBA and COM have similar steps for attaching (binding) to a remote component. A requesting component has to locate the remote component, establish addressibility, and cast a reference to the desired interface supported by the remote component. Then the requesting component can invoke the methods of the remote component as if it were local. Of course, the code to do this differs completely between CORBA to COM. The important point here is that by using the generic interface, the requesting component does not know or care what the underlying ORB is.
First, the team created an interface definition named interfaceBroker containing a list of the generic methods required to attach to or advertise any remote component, regardless of the underlying ORB. Methods included things like “locate” and “bind” and miscellaneous housekeeping logic. After that, classes that encapsulate all the actual logic for doing these operations within CORBA were created and programmed to implement the generic interface. The generic methods were used for all requests to remote components within the demonstration application.
An interesting side effect was a reduction in the amount of repetitive code across the application. For example, consider the code needed to bind to a bank account in standard CORBA:
try { // Initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
// Bind to the Account Object
iAccount iAcc = BankHelper.bind(orb, “Account”);
Catch (org.omg.CORBA.SystemException e) {
System.err.println(e);
}
As opposed to the following example, using the generic interface named interfaceBroker:
iAccount iAcc = (iAccount) interfaceBroker.getInterface(“Account”);
With the demonstration system up and running over CORBA, my team demanded my final decision, CORBA or COM. Of course, I chose COM, because I still wanted both. Despite the fact there were over 20 shared components, with each being called from several dozen requesting components, no application code changes were required. Instead, the team simply created a new set of classes that used the COM API to implement the interfaceBroker methods, recompiled the application and presto, the entire thing ran over COM. Total time for conversion (over 200 classes in all) was three days. Considering how many places remote invocation was used, this was quite an accomplishment.
Hiding the interaction with CORBA behind the interfaceBroker allowed my team to implement the demo system on schedule and protected them against the inevitable change to COM. When we did a post implementation review, we concluded that writing a generic interface, which at first glance appeared to be an overhead, actually hid a lot of complexity from the majority of the developers, and resulted in a net overall savings of lines of code and programming time. Lesson learned? When there is a chance of fundamental technology changes occurring in your solution, building a generic interface to that technology is a viable strategy.
Nelson is chief scientist and managing director of the Applied Technology Research Group of EDS Systemhouse. He can be reached at [email protected]
