Muddied Waters: Distributed APIs
Just when it seemed that big business was ready to tap into distributed computing by choosing between Microsoft's COM (Component Object Model) and the Object Management Group's CORBA (Common Object Request Broker Architecture), Enterprise JavaBeans (EJB) came along to muddy the waters.

To be fair, it isn't just EJB that makes distributed computing look like California in the mud season. While ISVs eagerly eye Microsoft's COM and COM+, most large businesses seem to have concluded that they'll need to write to both COM and CORBA, and now momentum is also mounting for EJB as the API set to which businesses will write their distributed applications.

Ultimately, the long-term role of Java in the enterprise will hinge on its acceptance as a distributed computing framework-- either alone or in conjunction with CORBA. But that role has yet to be assured for Java, COM or CORBA. In fact, some of the most important interfaces could actually arrive as private APIs from companies that are virtually unknown today. That's because just about every major vendor and a slew of innovative startups see a huge market in building combo packages that leverage some or all of these frameworks. And these new middleware combos--commonly packaged as application servers--represent an ever-increasing accordion of disparate APIs, vendor-specific extensions and platforms that intermingle components (see "Some Well-Known Application Servers," page 67).

Middleware now seems to stretch from the simplest application servers to high-end transaction services like BEA Systems Tuxedo. Mudware, in fact, may be a better name.

The traditional wisdom is that 1998 is the year for big businesses to choose between COM and CORBA. Since that choice will reflect a recognition that support must be provided for both, users must now select an integration platform as well. Then they must choose an API set, since, for example, platforms like CORBA may also have their own distinct APIs. Finally, they will have to choose the middleware server product on which to write their applications and provide component services--a choice that increasingly entails committing to a proprietary API.

John Rymer, president of Upstream Consulting, is among those predicting the emergence of a wide variety of standard and proprietary distributed computing interfaces and platforms to unify disparate frameworks. The private APIs are intended to provide a layer of API abstraction in front of existing CORBA, COM or EJB APIs, to simplify the task of writing to multiple frameworks or to add value to those frameworks. Private APIs will also be used to flesh out the limited functionality of EJB.

Rymer says he expects OMG to vote on CORBA 3 this fall, which will position CORBA as a platform to bridge multiple object models. He also points to private application server superAPIs--from Sun's NetDynamics to Novera Software and ObjectSpace--that create their own entry into various distributed computing frameworks.

But how these superAPIs are implemented highlights possibly dramatic differences in the world of application servers. Vendors such as BEA Systems, for example, plan to support both a superAPI and a repository approach providing direct access to APIs for frameworks like EJB. Sun's NetDynamics is moving toward supporting EJB atomically within its BusinessBeans private API set.

In fact, Rymer expects most application server providers to distinguish their products by extending their own APIs or those proffered by OMG and Microsoft. The trade-off for this added functionality is user lock-in. It's a price many businesses are willing to pay to cut development cycles. Some application server platforms, for example, are credited with cutting COM and CORBA development time in more than half--primarily by offering prepackaged components and services that users would otherwise have to build.

An interesting example of yet another type of emerging integration platform with private APIs is ObjectSpace's Voyager product series, with its popular Object Request Broker. Voyager provides CORBA and RMI compatibility, with DCOM compatibility promised in an upcoming version.

But what really impresses software developers is how ObjectSpace lets them create special components, known as agents. These agents can move independently from one device or program to another--a mobile code talent that's particularly suited to tasks like dynamic load-balancing.

Java deployment may be further delayed by the sheer volume of competing products and the lack of uniform feature sets between them. For example, many application servers are ramping up to support EJB exclusively, with others adding CORBA and an even smaller set also adding COM.

What is clear from the emergence of so many APIs is that it makes sense for large users to select platforms that at least blend support for frameworks. Sun and the OMG have taken the first steps toward common ground with OMB's RMI over IIOP specification. David Curtis, formerly OMG's director of platform technology and now with Inprise, says the specification allows RMI to be mapped to CORBA's Interface Definition Language. RMI over the Internet InterORB protocol (IIOP) lets an RMI program talk to a CORBA object without requiring IDL knowledge on the part of the Java programmer. A key advantage of the specification is that applications addressed by CORBA won't have to be rebuilt to become part of a Java infrastructure.

Still, concern remains over the nuances of shipping a JDK that supports not one, but two approaches. Certainly, duplication generally heightens complexity and boosts overall cost--which explains why some enterprises would prefer even tighter EJB-CORBA integration.