Network Computingwww.networkcomputing.com

On the other hand, it's been nearly impossible to create connectivity among different vendors' products. Implementing anything substantial has required a great deal of low-level coding by highly skilled staff. It is possible to create large-scale distributed systems using CORBA across heterogeneous hosts and OSes, 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 IDL (Interface Definition Language) files from Java-class files, and therefore to allow access to Java applications remotely under CORBA via RMI (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 plays up 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 OTS (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, looking into the future, even shops with a large CORBA investment likely will start to wrapper 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 whether many dancers will remain at the CORBA ball.