The architectures for distributed software components have grown up quite considerably in the last six months. Today we have three competing distributed component models: Sun’s Enterprise JavaBeans (EJBs), Object Management Group’s (OMG) Common Object Request Broker (CORBA), and Microsoft’s Common Object Model (COM). A year ago, EJBs were receiving all the trade press. EJBs weren’t Microsoft-specific, and they provided a rather complete architecture for business programming. Recently, however, Microsoft and OMG have enhanced their component models so that they are extremely competitive with EJBs.

What Are Distributed Components, and Why Do I Need Them?

For years many IT departments have been handling the distribution of data between multiple platforms with a fly-by-the-seat-of-the-pants approach. They have been downloading complete data files to PCs so accountants can massage data with their spreadsheets and business managers can play programmer with their Access and FoxPro applications. It’s not an issue of sending the data down to these applications; the issue is when you have to update your database with the manipulations of these homegrown, uncontrolled applications. The power of SQL with ODBC and, more recently, Java Database Connectivity (JDBC) has allowed Visual Basic and Java developers to have direct access to the database of your AS/400. The architecture of these applications could be construed as an improvement because there is no need to download complete files and then laboriously merge changes back in. But do those applications maintain the same integrity with your database as your core application code?

The architecture of distributed components allows you to build a standard interface for host-based application code. Client applications no longer contain code that directly manipulates host-based data. Instead, a client app receives a handle (a remote reference) to one of the standard interfaces of your host application. That interface consists of a set of functions. Some functions are used to retrieve information, and others are subsequently used to modify the retrieved data. When the client invokes a function of that interface, the code of that function executes on the host. The point is that, with distributed components, all access to your corporate database is through the standard interface. Thus, distributed component models enhance control of your application’s data by providing a consistent interface. No longer do you deliver data files, and no longer do you distribute code. Now you deliver APIs to host-based code.

The Model Walk

The architecture of distributed components is very attractive, but which of the three models do you choose: EJBs, CORBA, or COM? CORBA is a cross-platform and language- neutral model. If the distributed components of your n-tier application are to be accessed on non-Microsoft operating systems and by languages other than Java, CORBA is the answer. Microsoft’s COM, although its architecture could be implemented on any platform, is Microsoft-operating-system-specific. But COM is language-independent. One reason for COM’s success is that its implementation is included with every copy of Microsoft Windows. Internet Information Server (IIS), which is bundled with NT, also has integrated support for COM. If you decide to use CORBA or EJBs, you’ll have to buy a Web application server that supports that model. There are plenty of Web application servers to choose from, but, when you add up the additional costs, COM may look more appealing.

EJBs are language-specific but platform-independent. Until recently, EJBs provided the most complete architecture for business components. The engine behind EJBs (provided by a Web application server) handles such things as the mapping of relational data to business components, database concurrency, and load balancing. EJBs may be language-specific, but because the low-level protocol of EJBs is the same as CORBA’s, non-Java client applications can access EJB components.

COM+ and CORBA Now

Microsoft and OMG have enhanced their component models to be even more competitive with EJBs. The new version of COM, called COM+, integrates the features of Microsoft Transaction Server (MTS), Microsoft Message Queuing (MSMQ), IIS, and In-Memory Database (IMDB) along with other services. The new version of CORBA, CORBA CCM (for CORBA Component Model), is a superset of Sun’s EJB specification.

I believe that Microsoft’s COM+ is an excellent choice because of its high integration with Microsoft Windows, but, if you plan to deploy on any other OS, then you need to look at CORBA CCM or EJBs. CORBA CCM is now a more complete specification than EJBs, and CORBA is language-independent. But there are not as many tools available for CORBA, the tools are more expensive, and CORBA is decidedly more complex than EJBs. Your choice, then, depends on the platforms you intend to deploy on and the programming language(s) you plan to support.