CORBA in the age of Java

The CORBA standard for distributed object computing continues to find new adherents, both in the vendor and user communities. More than a few industry observers have asked, however, if CORBA should not have moved forward further and faster. Among these onlookers are some that say the lack of tools has slowed CORBA's growth. This led Application Development Trends to ask the question: "What is the state of tools for CORBA design today?"

The answer: The state of tools for CORBA depends on whom you ask. Yes, there is some assembly required. In this case the analogy for assembly is the CORBA language-neutral IDL. But there are plenty of C++ developers that do not find learning the CORBA IDL too difficult at all. They are completely at home with the barest of bare bones programming environments. On the other end of the spectrum are those developers -- perhaps a surprising number, in fact -- applying a mix of tools that includes front-end object modelers that support high-level design.

Whether working from the top down or from the bottom up, distributed computing experience seems a requisite for success. After all, a developer may not have trouble building a system, but that system might have trouble working in the real world. The tools available as yet do not change this fact.

While users say object-oriented API design is hard, they do not blame CORBA or the tools. A mix of tools, and more than a dash of skill, seems to be the best recipe for success today. Numerous tools are at hand to add to the mix, with more coming everyday.

Clearly intended for use in distributed object environments, Java is a tool that seems to offer help to the distributed object designer -- and it is becoming a common language for servers. The startling appearance of Java caused more than a few CORBA designers to go back to the drawing board a couple of years ago. But time has shown that experience is needed. Java is still relatively immature for the enterprise, and Java advocates are counting on CORBA to fill in the holes in Java services. [See "CORBA and Java: Marriage or just serious dating?," by Max Dolgicer, p. 35, this issue.]

Nothing magical

Ron Zahavi is perhaps as knowledgeable as anyone on CORBA. He actively researched object-based system development for several years at Mitre Corp., Bedford Mass., and co-authored The Essential CORBA with Thomas Mowbray. Today, Zahavi is a principal at Concept Five Technologies, an enterprise application integration services company based in Burlington, Mass., and McLean, Va. Zahavi reminds us that CORBA is a spec -- there is nothing magical about CORBA itself as a technology. He echoes others who state that distributed object design, whether CORBA-based or not, is still a difficult undertaking.

"Some people use CORBA as another RPC mechanism and don't know anything about the services,"said Zahavi. "All they have to learn is what the CORBA [object] types look like. Developers have to learn that with any language or technology they use."

The complexity issue arises when the spec is applied. Asked Zahavi: "How do you deal with fault tolerance, deadlocks or slow performance? That's where the complexity comes in.

"Should you have one big interface or a lot of small ones? Should you have a server-oriented interface or should you expose all the individual objects? For example, if you have a banking application, do you want all the objects instantiated?" queried Zahavi. "Or, if you have a million clients, do you want a million objects instantiated or do you need a server-oriented interface overlaying a database? These are the kind of questions to ask when pursuing CORBA designs. Those are the design issues."

Thus, thoughtful architecture is probably more crucial than the choice of a tool. "A developer that can handle RPCs can use CORBA, but that developer doesn't necessarily have the years of experience required. You need a good architecture for any of these technologies to work. CORBA is as complex as any tech from a design perspective," said Zahavi.

Concept Five uses the Unified Modeling Language (UML) to create object designs, said Zahavi. While the tool can generate objects in CORBA IDL, it does not come embedded with the appropriate knowledge of which objects should in fact be generated. "If you press a button and generate IDL for everything, that's not going to be very helpful. You don't want to generate them all," Zahavi noted.

"Many [elements] should not be service objects; they are internal to the application and should not have exposed IDL interfaces. Remember, if you make everything a distributed object your performance will degrade seriously," he added.

Tools are starting to emerge that help with both the design and management of the runtime environment, said Zahavi. "Some tools generate the IDL and then you have to compile [that] with your favorite ORB. Some will generate both client stubs and server skeleton [code]."

Another take on this issue comes from none other than Java father James Gosling, a Sun Microsystems' Fellow and vice president. "If we think of servers as monolithic entities, and we don't think in terms of specific services, we may be headed for trouble," noted Gosling in a presentation at last year's SD '98/East Conference held in Washington, D.C. While others have noted that misunderstanding distributed computing can be an obstacle to CORBA's success, Gosling has noted that a general misunderstanding of networked computing is an obstacle to Java success. Progress will be made, said Gosling, "when people stop thinking about servers. The word has become [overloaded]." [Naturally the application server has gained tremendous attention of late, based in no small part on Sun's aggressive purchases of NetDynamics and the Netscape Kiva server technology.] "The server has become sort of a New Age mainframe," added Gosling. "The clearer name to use is 'services.'"

Top-down front ends

Another practitioner who sees usefulness in front-end architecture building is Michael Sawczyn, CTO at the Ohio Police and Firemens' Disability and Pension Fund, Columbus, Ohio. CORBA lets the Fund connect varied database data and deal with functions as business objects. Front-end modeling tools let Sawczyn's developers concentrate on designing objects, and not on IDL. "We use [Cupertino, Calif.-based] Rational's Rose and [Cleveland, Ohio-based] Secant Technologies Inc.'s Extreme [tools]," said Sawczyn. "Secant's tool allows us to take the Rose models to IDL." The Secant tool provides persistent mapping of database table data to objects (and back), and compiles standard CORBA. An Inprise VisiBroker IDL compiler is also used for some client stub and service skeleton coding.

For their part, developers at 3M Health Information Systems in Murray, Utah, used a variety of tools, including modelers, in a CORBA effort, said Skeetor Draper, product marketing manager.

Said Draper: "Object [programming] has been an evolution over time. It's not as bullet proof as it needs to be."

Draper led a team that built an integrated delivery network for this large health-care software services vendor. In Draper's world, disparate functions can no longer be handled as stove-piped apps. A key choice was that of the Orbix CORBA ORB from Cambridge, Mass.-based Iona Technologies. Also used, said Draper, were tools and technology from Rational, ObjectStore, Oracle and Microsoft. Application of skill is perhaps more important than the ability of tools, he noted.

"Objects are good. But object technology becomes less well-defined when you move down the scale of distributed en-
vironments,"; Draper said. "As you get to 'pure' object systems, complex issues arise in performance and data integration." He has found it very important for developers to take UML use cases and carefully generalize these into objects. "It takes time to develop those skills," he said.

Make mine Java-CORBA

And what are users doing on the budding Java-and-CORBA front? Today, it is the new companies with new design slates that may be more likely to go with a combination of Java and CORBA. Take Global Mobility Systems (GMS) Inc., Bellevue, Wash. The goal at start-up GMS is to build intelligent network services for wireless telecommunications users, said Mike Pirie, vice president of product development. As the firm does a lot of work with Sun Microsystems, the choice of Java seemed natural.

Meanwhile, looking to turn out apps fairly rapidly, and given that a GMS application would be one of many nodes on a network, GMS decided CORBA was a good architecture, said Pirie. Thus, the company also came to select the Voyager CORBA-compliant ORB development and deployment platform from Dallas-based Object Space.

Of Voyager he said, "A protocol typically will have a lot of overhead. Voyager didn't have that. The attachment is quite nice in terms of managing itself, and it's lightweight." Voyager's broadcasting functionality has also proved valuable, said Pirie.

For Pirie, CORBA as a runtime system "bus" is the real selling point. From a development point of view, the important thing was merely that Voyager was "quite compatible with our Java environment," said Pirie, while noting that CORBA developers will encounter some unique configuration management issues. "We had a lot of stub building requirements that caused version control management problems," he said.

In terms of performance of the end product, GMS has been quite happy, he noted.

The Java-CORBA connection has received a boost in recent months as Sun Microsystems has increasingly appeared to support CORBA (via tool deals with Inprise and the purchase of NetDynamics), and to move further away from exclusively supporting its RMI Java-specific ORB.

"Java and CORBA are working together. The Java 2 platform bundles CORBA," said Richard Soley, chairman and CEO of the
Object Management Group, Framingham, Mass., in the wake of Sun's recent Java 2 (JDK 1.2) announcement. "From now on, whenever you find Java you find CORBA."

That would seem to leave little difference between CORBA and Java. No, that is not quite right, said Soley. "The point is we always tried to support every language as well as possible, and we still do. That is not going away," said the OMG head.

True, Java is easier to support because it has an object model, he said. But is not the first or last language in history. "There is no object model in COBOL, we had to make it," said Soley.

And what is Soley's view on the state of CORBA tools?

"There are some things that are hard because the tools don't help you. And there are some things that are just hard," he said. The latter case, as stated before, is true of distributed computing. "I've seen everything from people doing top-to-bottom models of systems and generating CORBA stubs, and then I've seen people going from the bottom up and starting with C++ or FORTRAN, building CORBA wrappers and working those up to the system level.

"What I haven't seen yet is a 'server IDE,'" added Soley. "It seems you ought to be able to pull together a server from a palette of objects for server processes. What we probably need is an idea for building servers."

It's a wrap!

"I believe that we will see a greater shift to development with Java over C++ because of its increased portability and improved garbage collection," said Concept Five's Zahavi. "A couple of things that need to improve on the Java front are: greater CORBA service availability and improved virtual machine robustness on specialized hardware."

Because Java is so new, and distributed enterprise systems are so multiflavored, CORBA's language-neutrality is a clear advantage. But where "legacy" is a concern, old problems cannot be wished away. Many a distributed system has floundered when it came time to "wrapper" the old COBOL mainframe. In fact, said Zahavi, Concept Five has been spending a lot of time lately on tools that analyze COBOL to find the best place to interface.

"Let's say I generate the IDL," said Zahavi." Let's say I want to wrap a legacy COBOL system. I may have a tool that helps me write the IDL, but the difficult part is actually identifying the places that are proper for integration in the legacy system.

"Is it batch-oriented? Is it a transactional CICS system with various interfaces and buffers, or does it talk directly with a database? There are different interface points available and they all might require different communication mechanisms," he said.

So, between the new middle tier of your CORBA architecture and the old back-tier of your corporate legacy, hard decisions must still be made.