COM Before the Java Storm
To win the distributed enterprise, Microsoft is walking an interoperability/portability tightrope between its Windows Everywhere goal and the heterogeneous reality of big business today. And Microsoft is well aware of the altitude.

A Microsoft spokesman goes so far as to call Windows Everywhere "an immature goal." For Microsoft's COM (Component Object Model) to be pervasive, it must work across existing enterprise platforms. That's why Microsoft is licensing COM to companies such as Compaq Computer Corp., Silicon Graphics, Software AG and Visual Edge Software. It's also why Microsoft supports COM on Sun Solaris and plans direct support for other Unix platforms by year's end. "We want to make sure we respect the existing investments of business," says Joe Maloney, Microsoft's group manager for COM and Microsoft Transaction Server.

The importance of distributed computing is one obvious reason for Microsoft's decision to draw a line in the sand when it comes to distributed component interaction. It chose its own Windows-specific invocation methods for COM, Distributed COM and COM+, disdaining Sun's Remote Method Invocation (RMI) and CORBA (Common Object Request Broker Architecture) before that. And while Microsoft maintains that RMI can work with Microsoft's own virtual machine, Microsoft's development tools certainly don't make it easy.

That doesn't mean, however, that Microsoft isn't optimizing COM for its own operating systems, which, in turn, influences just how much functionality can be wrung out of COM applications written for NT and subsequently ported to other platforms. In addition, Gina Centoni, Sun's group manager for the Java platform, cautions that COM developers must still recompile their code for each platform, which is unnecessary if Java purity is maintained.

Inprise's David Curtis is incensed by changes he says Microsoft is making in languages like Java and C++ to tap Windows-specific functionality. It would be bad enough, he says, if Microsoft limited proprietary extensions to libraries and frameworks, like Microsoft Foundation Classes and Active Template Library. But Curtis says Microsoft's own COM+ Web pages show examples of proprietary keywords used in C++ itself (www.microsoft.com/msj/1297/complus2/complus2.htm). Such proprietary extensions, he says, will make it extremely difficult for businesses to port COM applications written on NT to non-Windows platforms.

Chris Hargarten, Microsoft product manager for Visual C++, says that while much of the page referenced by Curtis is obsolete, Microsoft does plan to propose one keyword, "interface," as a Visual C++ extension. Hargarten says, however, that wherever it can, Microsoft plans to use attributes, rather than keywords, to support COM+ because "the portability story is far greater." By limiting COM+ support primarily to attributes, Hargarten says, users are given the option to compile source with pure C++ code, minus any attributes. Hargarten emphasizes that this approach means it will be much easier to write distributed COM+ applications in C++, and users wishing to port their COM+ applications won't face any greater challenge than porting COM today.

Hargarten expects COM+ support eventually to make its way into Visual Basic, Java and all the Microsoft Visual Studio Tools, though C++ is the first place it will appear. That may take some time, however, especially since Microsoft is now saying that COM+ won't ship until NT 5.0 does, but a ship date for NT 5.0 has not been set.

Rymer says new keywords are part of the evolution of any language and mostly reflect customer requirements. "The real question is whether the libraries implementing the functions of the keywords are tied to a particular OS," he says. For his part, Hargarten says Microsoft is working with Mainsoft, Software AG, Bristol and others to ensure its COM-specific libraries are ported to non-Windows platforms-and Mainsoft is supporting the full Win-32 API set.

So, should businesses concerned about eventually porting a distributed application from NT to another platform plan on using Microsoft's Visual C++ or Visual J++ with COM+ support once it becomes available? Rymer says that if businesses want distributed software that "is easily portable between NT, Solaris, HP-UX or even MVS, they are absolutely crazy to tie themselves to Microsoft. Everything Microsoft does is tied to Windows. Period. Everything they do must serve that god. They'll do things to interoperate with other OS platforms, but that's not fundamental to their business."

Yet, Microsoft enjoys distinct distributed computing advantages in the enterprise. For example, the combination of NT, COM and Microsoft Transaction Server has a two-year jump on Enterprise JavaBeans, which was released last spring and still lacks a unified reference implementation (though Distributed COM is seen as following CORBA). Also, COM can tap a wealth of third-party application developers who know there's gold at the end of the Microsoft's rainbow.

Microsoft is on the march and bringing one of its tried and true formulas for COM+ success-namely, popularizing products through simplifying their use. The new approach lets programmers write an application and then check off how a component should be treated at runtime (such as enforcing a two-phase commit). In its labs, Microsoft is also working on the total automation of distributed applications through its Millennium project (see Jini/Millennium article online).

Much of the success of CORBA, on the other hand, may well depend on whether it aligns well with Java or is viewed as an Enterprise JavaBeans competitor. At this point there is at least some integration on the way in the form of RMI over IIOP (Internet InterORB Protocol), which 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 legacy applications addressed by CORBA won't have to be rebuilt to become part of a Java infrastructure. Sun officials say they will implement the specification in its entirety in a Java Development Kit-but that support isn't expected to ship until sometime in the first half of 1999.

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.

For CORBA-Java combinations the advantages primarily lie with user sentiment that CORBA was designed from the ground up with the enterprise and heterogeneity in mind. There's also a prevalent perception that CORBA and Java are more standards-like than COM and, finally, Java presents the opportunity to not only invoke methods in components, but to move and rearrange components across a network.

Many users see their stripped down distributed computing options as either using multiple languages to reach to a single Windows platform; or using a single language, Java, with or without CORBA to reach multiple platforms.