Corba's distributed-object architecture, the dominant object technology, is being challenged by COM and Enterprise Javabeans. Can Microsoft's and Sun's offerings finally overtake the complex model or will its popularity help Corba 3.0 prevail?

The most elegant component model in the world is useless without products to support it. By the same token, the most well-designed architecture is hamstrung without powerful, yet flexible and usable tools with which to implement real-world solutions.

These conundrums are influencing the future of the three models for using and managing distributed objects in a network: Corba, DCOM, and Enterprise JavaBeans. Although the Object Management Group's Corba (Common Object Request Broker Architecture) has existed since 1990, and many products support it on some level, it has long been criticized as requiring too much additional programming knowledge for anyone but highly specialized engineers to use. Microsoft's model, which includes COM (Component Object Model), DCOM (Distributed COM), and the upcoming COM+, has a huge installed base and is more mature than Sun Microsystems' nascent Enterprise JavaBeans. But while COM and DCOM have a fairly healthy third-party market for tools, they still restrict users to running Microsoft tools on Microsoft platforms.

Meanwhile, despite the fact that only a few development tools are available for Sun's EJB, it has generated strong interest from both vendors and the market. If that interest turns into robust toolsets and truly interoperable, cross-platform products from multiple vendors, it will become a major force.

"Customers understand the message of object orientation and its benefits, as well as the need for a distributed-object technology," says Roseanna Marchetti, senior product marketing manager at Netscape, "so vendors don't need to sell the benefits of components." Rather, they must sell complete products and development tools that are easy to implement, use, and reuse across whatever network architecture, infrastructure, and operating system their clients use.

Here, Corba faces its biggest hurdle. The technology has proved too difficult to use in many instances, and too complex and expensive to implement and maintain. Although parts of its core technologies will undoubtedly remain vital to many distributed-object deployments, and many products will continue to support Corba in some form, it has likely hit its high-water mark as a separate, integrated model.

By comparison, Microsoft provided a relatively easy-to-use alternative with DCOM and Microsoft Transaction Server, and has quickly gained a large share of the market, if not of the revenue; after all, Microsoft delivers the service free, as a part of the Windows NT operating system. It remains to be seen if EJB, or a merger of EJB and Corba, can overcome Microsoft's head start.

Corba: Merge Ahead?

Corba is in an interesting, but not necessarily good, place right now. On the one hand, it has a large, committed installed base and a huge spectrum of vendors that participate in the Object Management Group. Corba has been available for much longer than DCOM or EJB (its original specification was released in 1990 and commercial products began appearing in 1992), and many products on the market support it. Corba objects can be written in multiple languages, including Java, C, C++, SmallTalk, Cobol, and Ada. The OMG has just announced version 3.0 of the Corba specification, which it will release in final form by midyear. This version will include some important additions, such as a new, expanded distributed component model, a scripting language, and the ability to pass Corba/Internet Inter-ORB Protocol through a firewall. If a client supports IIOP connections directly, new interfaces will allow a Corba 3.0-compliant firewall proxy to be used on the provider's firewall proxy host, with bidirectional filtering and proxy services. If the client doesn't support IIOP, the fallback is tunneling the IIOP requests through HTTP.

On the other hand, it's often been impossible to create connectivity between different vendors' products. Implementing anything substantial has required a great deal of specialized coding by highly skilled staff. It is possible to create large-scale distributed systems using Corba across heterogeneous hosts and operating systems, but the investment in time and talent is huge. Many of the Corba 3.0 specification's services are already functionally part of the DCOM or EJB specs, and while many vendors support Corba, enthusiasm for it has been largely eclipsed by EJB. There's no guarantee that the full 3.0 spec will be widely implemented; it's likely a case of too little, too late.

We believe that at least for new system development, EJB (with essential elements of Corba) and DCOM will soon be the two major distributed-object standards in widespread use. Iona Corp., one of the biggest Corba boosters, recently purchased an EJB development company, and Netscape, though it supports Corba clients, does not offer a Corba server, per se. Rather, according to Komal Parikh, a group project manager at Netscape, the company is looking to Sun to help solidify the relationship between Corba and EJB. Sun is unlikely to offer pure Corba services; rather, it's pushing for greater integration between EJB and Corba.

That's a refrain being heard throughout the industry--that Corba and EJB are headed for a de facto merger, with elements of Corba absorbed into the EJB specification. This will be a very fruitful marriage, if Sun and the OMG can avoid a bifurcation. The Corba 3.0 specification includes some features designed to enhance Corba-Java interoperability, especially support for Objects-by-Value. The extension of Corba support to value objects is essential to enable developers to generate Corba Interface Definition Language files from Java class files, and therefore to allow access to Java applications remotely under Corba via Remote Method Invocation, using IIOP as the wire protocol (as Java is extended to make use of IIOP).

The Corba specification's vagueness has always been its major problem, as it allowed vendors to come up with widely varying, incompatible products with limited or no service-level interoperability. Microsoft makes much of this weakness in its marketing, saying DCOM presents a more consistent specification and environment than Corba. Sun is trying to keep a close eye on EJB's cross-vendor interoperability; while EJB is portable, it remains to be seen whether Sun will be able to avoid some of Corba's intervendor confusion and difficulties.

Most enterprise deployments of Corba are designed primarily to tie together diverse data sources, and most can fairly easily standardize on one vendor. However, that's likely to change as components become commoditized and "plug and play" becomes a larger issue for IT shops. To do a better job than OMG at cross-vendor compatibility, Sun will need a tight spec, a complete reference implementation, and a strong certification process.

Corba's future as a technology distinct from Java will further dim as many vendors merely assure interoperability with existing "legacy" Corba assets. However, Corba/ IIOP will almost certainly remain a popular wire protocol for accessing Java components using RMI, and Corba ORBs will be an essential part of that service; meanwhile, Corba's IDL and Object Transaction Service may well continue to be used, especially in conjunction with Java.

Corba has a loyal base of users in the enterprise, a fair number of success stories, and some level of participation from a large number of vendors. Until the advent of EJB, it has been the only standardized cross-platform object model that has had any significant support. However, in the future, even shops with a large Corba investment will probably start to wrap their existing Corba code and do new development with either DCOM or EJB. As for much of the remainder of the new Corba specification, it's doubtful many companies will continue to use Corba.

Microsoft: Poised For COMbat

Microsoft's DCOM has both the advantages and disadvantages of being pushed by a single vendor. There's no "design by consortium," as there is with Corba, nor even the process of working with "friends and family" that Sun has with EJB. Microsoft can consult with customers, and then implement whatever features and changes it wants. Because DCOM is a part of Windows, Microsoft instantly has hundreds of millions of potential users.

Microsoft has virtually complete control over its specification and implementations, in contrast with both Sun and the OMG. This tends to make DCOM a fairly coherent model in actual use, but also one that's limited to running in Microsoft environments. For instance, one of the most critical pieces of a distributed object model for enterprise use is robust transaction processing. In the DCOM world, that's accomplished via MTS, which runs on Windows NT--period.

On the other hand, eliminating interoperability avoids a host of problems. Microsoft's control of the operating system means that, at least on Windows NT servers, operating-system integration with DCOM is excellent. In Windows 2000, COM+ (the evolutionary successor to the COM model) will both add some new services and subsume what had previously been discrete (though bundled) products, such as MTS. Furthermore, the DCOM infrastructure and MTS-COM+ services are distributed at no additional cost over the base operating system, unlike products that use Corba or EJB.

David Chappell, an industry analyst and principal at Chappell and Associates, puts it bluntly: "The decision about which component model to use is based on which operating system you want to build your server-side business logic. If a Microsoft operating system is your choice across the board, use DCOM and MTS. If you don't want to use NT, you can't use MTS and DCOM."

Some NT shops won't find the choice so clear. There will always be reasons to purchase or develop enterprise-level products that use Corba and/or EJB, such as the need for extremely robust failover and dynamic load-balancing services across LANs and WANs--services that NT by itself either lacks or provides in only a limited capacity.

The point about operating-system choice, however, is an excellent one: DCOM is based upon the assumption that all of a business' new development and business logic will be on NT, probably using MTS. And while Microsoft may be hoping for a future where that's true, most shops still support multiple operating systems and platforms, not only for "legacy" data and applications, but for new applications as well, and will continue to do so for the foreseeable future. Microsoft has made a good effort to port COM to various other platforms-namely, Digital Equipment's OpenVMS, IBM's MVS, and Unix for Hewlett-Packard, Digital, SGI, and Sun boxes. But this is primarily to ensure access to COM-wrapped "legacy" data sources; there are no plans to port the critical MTS piece to anything but NT, and COM+ is also intended to be a Windows-only offering.

The tradeoffs to using DCOM and MTS are familiar ones: You gain a solid, consistent environment, mature development tools, and a distributed component model supported by a huge installed base. On the downside, you lock yourself into a relationship with a single vendor. Despite Microsoft's recent support for "COM on Unix," you can rest assured that support for Unix will always be minimal in order to induce companies to migrate to Windows-based servers. Microsoft representatives have repeatedly stated that they have no interest in making Unix a stronger platform.

The subject of development tools is laced with pros and cons. Microsoft has spent considerable effort integrating its tool offerings (Visual Studio 6, for example) to make easy use of the COM/DCOM model, and to make it a straightforward proposition to create COM objects in several languages (primarily C++, Java, Cobol, and Visual Basic). But that still assumes you're using Microsoft's development tools; you're unlikely to see a Visual Basic integrated development environment from another vendor, for instance, so you definitely hitch your wagon firmly to Microsoft by using its object model.

Another double-edged sword is the ease with which COM objects are created. When a developer checks a box to create an object or make it transactional, it's easy to lose sight of what's going on inside--and what effect that may have on network traffic--and create swiftly written but poorly designed, inefficient systems.

What does the future hold for DCOM? Like Sun and the OMG, Microsoft doesn't want to make radical changes to anything in its object model. Microsoft says COM objects built when the specification was released in 1993 will work today. The emphasis, according to Microsoft, will be on stability and performance ("The Scalability Factor," April 19, p. 69; www.informationweek.com/730/ com.htm). Going from COM to COM+ involves folding formerly separate products, such as MTS, into the base operating system, and adding some new services, such as dynamic load balancing, an in-memory database, a publish-and-subscribe events service, and a queued components service. Unless Microsoft changes its mind, however, COM+ will be a reality for Windows 2000 only.

EJB: The Challenger

EJB was released as a formal specification in March 1998. Though vendors claimed to support elements of EJB almost immediately, products supporting the full spec are first appearing now. Given the usual development cycle for tools and new products, the next six to 18 months will be crucial to determining EJB's long-term viability. Sun says six major EJB products are shipping, with many large business deployments of EJB systems expected between fall 1999 and mid-2000. For a 10-month-old technology, that's not bad. However, enterprise systems tend to be built with proven technologies, so we anticipate a fairly slow rollout of EJB.

Sun's plans for EJB's future are similar in one sense to Microsoft's plans for DCOM and COM+: They are evolutionary, not revolutionary. Every vendor wants its technology to be viewed as stable, and Sun is no exception. EJB 1.1 is expected at the JavaOne conference in June, but will probably be a tightened spec with some extensions, not a major rewrite. Sun wants to add the Extensible Markup Language to the way EJB is built to help any server understand EJB. It also plans to enhance connectivity to legacy systems, such as IBM's CICS and IMS, without losing portability. Finally, Sun is developing a long-overdue reference implementation of EJB. The beta version of the reference implementation is slated for next quarter, with the final version due in the fourth quarter of this year.

The relationship between EJB and Sun's upcoming Java2 Enterprise Edition has been uncertain, especially whether Java2 would pull resources away from EJB. "Just as the Java Virtual Machine is core to Java2, EJB is core to Java2 Enterprise Edition," says Bill Roth, product-line manager at Sun for the Java2 Enterprise Edition platform. The Java2 Enterprise Edition will include and require many of the other core Java technologies: Java Naming and Directory Interface, Java Database Connectivity, servlets, and Java Server Pages. In addition, Corba/IIOP is a required part of Java2 (which includes a reference implementation Corba 2.3-compliant ORB, Java IDL) and forms much of the transport infrastructure for Java2 Enterprise. "The Corba technologies represent the plumbing for us, and the real hope for interproduct interoperability," Roth says.

Sun's stated goal is to make the underlying Corba "plumbing" invisible to the Java2 programmer. In fact, while Sun says it is still paying attention to DCOM interoperability via a bridging strategy, Java2 Enterprise is not wire-transport neutral; Sun will use Corba/IIOP as the communications infrastructure. Interoperability and inter-object communication will be through RMI over IIOP, making Corba essential, but invisible. Sun is planning to take a more visible, public role in the OMG, a further indication of a gradual merging of elements of Corba and EJB over the coming year.

Because EJB is fundamentally built on the Java language, some of the issues particular to Java have a direct impact on EJB. Primary among these is performance, long Java's Achilles' heel. Sun has released a beta version of the HotSpot compiler, and promises a final version with greatly improved performance. In the meantime, IBM's new version of Visual Age for Java produces native binaries, but that's a short-term solution that contradicts Java's "write once, run anywhere" model.

Some heavy-duty, 100% Pure Java production applications are starting to appear, so clearly the performance problems can be addressed with enough care, and Java has proved itself to have perfectly acceptable performance on the server side for most uses. Also, Sun plans to introduce a new revision to servlets soon, with improved architecture and performance features.

Finally, Java's future direction will come into question if Microsoft loses its ongoing court battle with Sun and cuts off its support for Java. That action, while not necessarily fatal, would slow Java's, and thus EJB's, widespread acceptance in the enterprise market. On the other hand, it would also provide a rich market for third-party products like Sun's Java Plug-In, which lets enterprise developers configure Microsoft Internet Explorer or Netscape browsers to use a specific version of Sun's Java Runtime Environment instead of the one included with the browser.

Sun is trying to position EJB as "the industry's best hope to deliver true interoperability," Roth says. But the OMG has shown what a difficult challenge that can be. Sun also suggests that EJB can be a simplifying layer on top of Corba and DCOM. For EJB to succeed, however, it needs to accelerate the availability of third-party development tools, and avoid the pitfalls of specification ambiguity that plagued Corba, while at the same time not be so dictatorial as to discourage vendors.

Sun says it doesn't see EJB as a direct competitor to Microsoft, and this is true. EJB by itself is just a piece of paper; it's the supporting products the vendors develop using EJB that will provide competition for Microsoft and DCOM/COM+ products.

Object Management Group

Framingham, Mass. 508-820-4300 www.omg.com

Strengths

• Cross-platform

• Multiple vendor support

• Can develop in multiple languages

• Longevity

Weaknesses

• Highly complex

• Continued cross-vendor interoperability concerns

DATA: NETWORK COMPUTING

Microsoft

Redmond, Wash. 800-426-9400 www.microsoft.com

Strengths

• Easy-to-use development tools

• Can develop in multiple languages

• Components are free with Windows

• Large installed base

Weaknesses

• Still largely Windows-only (with limited cross-platform support)

DATA: NETWORK COMPUTING

Sun Microsystems

Mountain View, Calif. 800-786-7638 www.java.sun.com

Strengths

• Cross-platform

• Relatively easy to use

• Strong third-party vendor interest

Weakness

• Sparse third-party tools and products so far

DATA: NETWORK COMPUTING

~~~~~~~~

By Richard Hoffman, Network Computing

Richard Hoffman is technology editor at InformationWeek's sister publication, Network Computing. He can be reached at rhoffman@ nwc.com.