A distributed object is a piece of a program that resides on a server and does some of the processing for one or more of your applications. With objects residing on your servers, programs from all over your network can access them without your developers' reinventing the wheel for each project. A distributed object is not useful by itself; it must have a client application that uses it to do some of the processing. The desktop will have to know how to find the object it needs and how to communicate with the object.
Three distributed-object architectures are in use: Microsoft's DCOM (Distributed Component Object Model), the Object Management Group (OMG)'s CORBA (Common Object Request Broker Architecture) and Sun Microsystems' Enterprise JavaBeans (EJB). Each takes a different approach to object/desktop communication. In essence, DCOM says "the desktop will know about everything." CORBA says "a central server can point any desktop to any object." EJBs say "that's a communication problem, not an EJB problem." Sun defines naming services for EJBs but does not force an EJB development vendor to use a specific standard or technology to implement those services. While interoperability tools are available for all three platforms, they tend to be expensive and problematic. And they slow processing significantly.
>> DCOM and COM+. Microsoft's DCOM was introduced as an Internet draft in January 1998. It is now running in many enterprises. COM+ is the new version of DCOM, encapsulating DCOM, Microsoft Transaction Server (MTS) and network configuration tools.
Under DCOM, you can develop three different models of servers: a DLL (dynamic link library) model, an executable model and a DLL model for MTS. Each model has a separate impact on your server, network and clients. Under COM+, Microsoft has attempted to merge the standard into a single DCOM server type: DLLs loaded into MTS and accessed exclusively through MTS for most applications.
DCOM has some serious configuration issues, particularly if you're running Microsoft Windows 95. Successfully configuring your network and server environments can take weeks. Security configuration is the worst aspect of this. You will need to set security on the client, the server, in DCOM on the server, on your PDC (primary domain controller) and in MTS.
So far, DCOM servers are available only for Windows platforms. There has been talk of a Unix flavor, but it's not yet available. Solutions based on COM+ do not even attempt to address true interoperability. You can pull data from non-Microsoft platforms, but you cannot force-feed data from a non-Microsoft production system into a Windows platform. Microsoft says its .Net initiative addresses this problem. (To find out more about .Net, see "Microsoft Looks To Snag Developers, Dollars in Its .Net.")
>> CORBA. The first CORBA specification was released by the OMG in October 1991, but this standard has been slow to win acceptance. CORBA offers the promise of multiplatform interoperability and scalability. However, you must adopt a single-source solution from a major vendor if you want to build a system that works on many platforms. The OMG is taking steps to ensure that if you have brokers from two different vendors, they will work together.
CORBA servers support Windows NT/2000, most Unix variants and IBM OS/390. Development environment tools -- using C/C++, COBOL, Java, Pascal, PL/I and Smalltalk -- exist for the same platforms. Note that some vendors require that software be installed on each desktop that uses CORBA services. With this kind of broad language support, the right CORBA vendor can take your organization into distributed-object nirvana. Setting up and configuring the server take time, and your developers must be trained in CORBA IDL (Interface Definition Language), but if your main need is interoperability, look to CORBA.
>> Enterprise JavaBeans. Sun's EJBs are an interesting twist in this space. They provide the basic functionality of distributed objects but approach the problem from a language-centric view. EJBs require a Java-enabled application server, and all applications accessing EJBs previously had to be written in Java. However, Sun and the OMG have joined forces to provide an alternate solution. A mapping from OMG IDL into EJB IDL is available, letting your CORBA-compliant languages access an EJB as if it were a CORBA object.
EJBs provide platform interoperability and scalability, but you are limited to a single implementation language: Java. EJB has the fewest usable tool sets on the market, perhaps because EJB is the newest of the three solutions. EJB uses CORBA as a backbone but lets Java programmers develop distributed objects without the knowledge base required for either CORBA or COM+. Of course, network and systems engineers still need CORBA knowledge to set up those services.
RSS
