CORBA in the age of Java
- By Jack Vaughan
- May 30, 2001
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.]
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,"
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
"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
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.