CORBA and DCOM: Side by Side

F O C U S : C FOOMC/ UC SO R: BCAO M I N/ C T EORROB PA E R A B I L I T Y

CORBA and DCOM: Side by Side

by Ronald J. Norman usiness computing has experienced a fundamental shift, from a centralized model, where all application logic and data reside on a single mainframe computer, to a distributed model, where data and logic may be spread across several machines. From simple systems with a few PCs connected to a server, to global networks servicing an entire enterprise, the new distributed model offers better usability, flexibility, and new capabilities that were not possible under the centralized model. However, distributed computing in-

B

www.DistributedComputing.com

troduces complexity and requires that the components be compatible and well managed. Complex multitier applications are becoming more and more commonplace as companies endeavor to meet their information processing needs. Distributed computing technology is a key enabler for these applications. It combines object-oriented concepts with client/server technology to produce a framework for building modular, scalable distributed applications at a relatively high level of abstraction.

DISTRIBUTED Computing

41

FOCUS : COM/CORBA INTEROPERABILITY \ Distributed Computing Known also as “networked” or “client/server” computing, distributed computing has been described by Kalman [DBMS Magazine, 12/94, pg 14] as “a logical computing model defined not by a specific technology or set of technologies, but by interoperability based on standards, by the hiding or encapsulation of complexity through documented, predictable interfaces, and a redistribution of processing based on business requirements.” Simply put, parts of an application run on different computers simultaneously. At 30,000 feet, distributed computing is trivial—clients issue requests for services and servers respond to requests. The nightmare is in the implementation. At an abstract level, connectivity is accomplished through a combination of hardware and software. Middleware, the software portion of connectivity, facilitates the interoperability of objects among heterogeneous computing platforms that provides what appears to the user to be that of a single integrated system.

Middleware

portion of executable transaction logic that resides on the client and the portion that runs on the server. The three most common application architectures used today are: ➤ Fat-client model. Most currently deployed client/ server applications were built using this approach. All executable code resides on the desktop except for the DBMS along with any stored procedures and triggers. ➤ Three-tier (or n-tier) model. The application is partitioned into three components: a presentation layer, an application or business rules layer, and a database layer. Each layer may reside on a different hardware platform, providing flexibility and expandability to meet the processing demands. ➤ Thin-client model. A recasting of the mainframe/dumb terminal generation (also includes the network computer, or NC) featuring a “light” GUI on the desktop along with other layers, similar to the three-tier model. It is usually implemented with a Web browser using TCP/IP, HTTP, HTML, Active Server Pages (ASP), etc. • Three-tier and thin-client partitioning use one or more of the following middleware-enabled techniques: ➤ Transaction processing (TP) monitors. Transaction management can be provided by either a DBMS for lower-volume transaction processing or a teleprocessing (TP) monitor for higher-volume transaction processing. ➤ Remote procedure calls (RPCs). A synchronous functionoriented technique via the transparent redirection of subroutine calls across the network. The most common

Middleware

OSI 7-Layer Reference Model

Middleware masks differences among various kinds of platforms. It’s literally the “/” in the term client/server, the “magical” software glue that connects clients to servers. A universal middleware enables software developers to build systems comprising specialized, reusable components using a common language to define interfaces between components and arbitrate the requests between the components. Middleware makes the network communications layer completely transparent to the application software by embedding it within its services, Figure 1. Middleware as depicted in Figure 1. Because building one’s MiddlewareÕs Position within the Distributed System own middleware to support distributed computing is not simple, cheap, Communication Building Block Layers or risk-free, a commercial market niche has develApplication Application Program oped for middleware User Service products. These products Presentation Object Request Broker (ORB) •Message Queuing can generally be classified (CORBA, COM/DCOM, ¥ Data Translation Distributed M essage RMI, SOM/DSOM) ¥ Directory Service Services: Routing: into three categories of ¥ Nameing Service • X.500 • X.400 Messaging System (MOM) services: ¥ Security • DNS • SM TP ¥ Recovery • LDAP • M API • Distributed Services RPC (DCE, Netwise) ¥ Broadcasting • etc... • etc... ¥ Session Management such as directory and TP Monitor (CICS, Tuxedo) security services. Session Communication APIs (socket , APPC) • Message Routing, timedelayed, store-and-forSPX, TCP, LU 6.2 Transport ward transmission of data files, especially eIPX, IP, DLC Network Transport Service mail documents. StanNIC Driver Data Link dards include X.400, and SMTP. 802.3, 802.5 Physical • Application Partitioning, controlling the

42

DISTRIBUTED Computing

May 1998

FOCUS : COM/CORBA INTEROPERABILITY \ tectural model of the CORBA 2.0 Specification is shown in Figure 2, and each component is briefly discussed below. The Interface Repository is a run-time metadata repository of registered IDL-defined interfaces, including their methods/operations and required parameters. The Dynamic Invocation Interface is the CORBA-defined interface or API for looking up the metadata stored in the Interface Repository that can be used dynamically to generate a remote method invocation. The IDL Stubs present access to the OMG IDL-defined operations on an object in a way that is easy for programmers to predict once they are familiar with OMG IDL and the language mapping for the particular programming language. The ORB Interface allows both clients and object implementations to interface directly with the ORB for the few operations that are common across all objects. CORBA Most of the functionality of the ORB is provided through In 1989, a group of vendors and users who believed in the the dynamic invocation, stubs, skeletons, or object adaptors. benefits of object-oriented development formed the Object The Static IDL Skeleton is generally an up-call interface to Management Group (OMG) coalition to bring some order to an object implementation’s methods. The Dynamic Skeleton the rapid and disjointed developments of object technology. The OMG’s objectives are to foster the growth of object tech- Interface provides a runtime binding mechanism for servers that need to handle incoming method calls for components nology and influence its direction by establishing the Object that do not have IDL-based compiled skeletons. The Dynamic Management Architecture (OMA) Reference Model, upon Skeleton looks at parameter values in an incoming message which all OMG specifications are based. Among these speto figure out who it’s for—that is, the target object and method. cifications, CORBA is perhaps OMG’s most important. Dynamic Skeletons are very useful for implementing generic The CORBA 2.0 Architecture and Specification, adopted in December 1994, was designed to provide the specification bridges between ORBs. The Basic Object Adapter is the primary way that an obfor an object-oriented “universal” middleware that would alject implementation accesses services provided by the low software developers to write objects that could interact ORB. There are expected to be a few object adaptors that with other objects without requiring any knowledge of how will be widely available, with interfaces that are approprior where that object was implemented. A major characterisate for specific kinds of objects, such as generating and intic of CORBA is that it supports the construction and inteterpreting object references, method invocation, security of gration of object-oriented software components in heterointeractions, and object and implementation activation geneous distributed environments. As such, an all-Windows and deactivation. The Implementation Repository is the distributed environment may not need CORBA. The archirun-time database storing Figure 2. CORBA 2.0 Architecture all of an ORB’s registered objects, either activated or in args available for activation by operation() Object Implementation Client out args + return value client requests. Finally, for the “universal” way to connect distributed objects across the InImplementation Interface ternet or intranet, CORBA/ Repository Repository Static IDL Dynamic IIOP has been adopted. Basic ORB Skeleton Skeleton Dynamic IDL Object IIOP (Internet Inter-Orb Interface Invocation Stubs Interface Adapter Protocol) specifies how Interface CORBA’s General InterORB Protocol (GIOP) set of message formats and comGIOP/IIOP ORB Core mon data representations for communications be= Dynamic Interface tween ORBs are exchanged = Static Interface over a TCP/IP network. The example of this is the Distributed Computing Environment (DCE) RPC standard. ➤ Message oriented middleware (MOM). An asynchronous or synchronous event-oriented technique where one program sends a message to another program. Examples are BEA’s MessageQ, IBM’s MQSeries, and Microsoft’s MSMQ. ➤ Object Request Broker (ORB). A synchronous objectoriented handling of distributed object interaction. Examples are Visigenic’s Visibroker and Iona’s Orbix. There are at least two competing “universal” ORB middleware products—the OMG’s CORBA standard, implemented by various vendors such as Visigenic, IONA, Expersoft, and BEA; and Microsoft’s implementation of its own DCOM/COM.

www.DistributedComputing.com

DISTRIBUTED Computing

43

FOCUS : COM/CORBA INTEROPERABILITY \ IIOP makes it possible to use the Internet itself as the backbone ORB through which other ORBs can bridge. Simply stated, a request is sent by a client to an object implementation. The client is the entity that wishes to perform an operation on the object, and the object implementation is the code and data that actually implement the object. The ORB is responsible for all the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. Thus, the CORBA specification defines the least common denominator to which all object request brokers must adhere in order to be OMG compliant. CORBA was designed from the start as a distributed object bus built with open standards to support “intergalactic” or “meganet” client/server systems. It is a reference specification only. Software vendors are free to implement CORBA specifications in any way that conforms to the reference specification.

DCOM

tion transparency. DCOM is shipped with Windows NT 4.0; it is available for Windows 95 and is planned to be shipped with all copies of Windows 98. To satisfy the demands of customers with heterogeneous environments, however, DCOM must go beyond its Windowscentric roots. To accomplish this, Microsoft enlisted Software AG as a partner in late 1995 to “port” DCOM to other platforms. Software AG has announced the general availability of DCOM for non-Windows platforms. Refer to Software AG’s Website for platform implementation release schedules. As DCOM continues to become available on non-Windows platforms, companies can build software architectures that take advantage of their existing infrastructure and deploy business objects that access legacy applications and databases. According to Microsoft, DCOM—bolstered by its COM+ announcement in late 1997—is poised to be a key player in the world of multitier distributed object solutions. It provides all of the basic components necessary for designing and deploying sophisticated systems, and it promises numerous scalability and robustness improvements in the years to come.

Microsoft’s Distributed Component Object Model (DCOM) dates back to 1990 when Dynamic Data Exchange (DDE) CORBA–DCOM Integration and Object-Linking-and-Embedding (OLE) were introduced For many organizations a business and technology need exto support the Windows “cut-and-paste” metaphor. OLE2, ists for “internetworking” between CORBA and DCOM. This called OLE Automation, followed in 1993. It allowed the emgenerally means providing a bridge between CORBA and bedding of one document type within another document. COM, CORBA and Automation, and vice versa (four mapMicrosoft renamed its underlying new communication pings). There are only two reasonable strategies for delivermodel Component Object Model (COM), promoting it as ing an integrated mixed-model solution: OMG compliant a general-purpose infrastructure for building componentand object bridge. A home-grown alternative is simply not based software applications for single computers. justified given the large number of competitive commercial Today, Microsoft’s DCOM is an extension of its COM middleware products available. The OMG-compliant alterfor multiple computers. Microsoft now groups the COM/ native is desirable and is illustrated in Figure 4. DCOM/OLE Automation technologies under the name of The object bridge alternative is also desirable. Examples ActiveX. COM is an object-based framework for developing and deploying softFigure3. Microsoft’s COM/DCOM Architecture ware components. COM lets developers Legend capture abstractions as component interClient = COM faces and then provide binary classes that COM Runtime = DCOM implement those interfaces. COM enforces LRPC = Lightweight Remote SCM COM Library encapsulation such that client applications Procedure Call can only invoke functions that are defined ORPC = Object-oriented Remote Security O R P C Object Procedure Call on an object’s interface. Exporter SCM = Service Control Manager Figure 3 illustrates both COM and DCOM DCOM. The DCOM components shown in LRPC Protocol Remote Out-of-Proce Local Out-of-Process the “Local Out-of-Process” section of the Stack COM Runtime COM Runtime figure and the “LRPC” component in the SCM COM Library “Remote Out-of-Process” section are not SCM COM Library needed in the example shown but are inSecurity O R P C Object DCOM Security O R P C Object Local cluded for completeness. Exporter Network Exporter Protocol DCOM is the foundation for Microsoft’s Internet and component strategy and exDCOM DCOM LRPC Protocol LRPC Protocol tends COM to the network with remote Stack Stack method calls, security, scalability, and loca-

44

DISTRIBUTED Computing

May 1998

FOCUS : COM/CORBA INTEROPERABILITY \ are Visual Edge’s Object Bridge, along with similar products being released by various ORB vendors.

CORBA, DCOM, and JAVA You may be wondering where Java fits into all this, as its third birthday approaches. There is widespread expectation that the CORBA middleware vendors and the enterprise application development environments that support Java will create Java APIs allowing Java applets to interact with CORBA ORBs, thus offering a de facto standardized way of building CORBAcompliant objects in Java. As these CORBA-compliant and Java-written objects proliferate on servers, Java applets would call them back using IIOP. In contrast to the CORBA approach, Microsoft’s Internet Explorer JVM implementation relies completely on COM; therefore, the interpreted Java bytecodes are actually presented as just another ActiveX component. This means that there is no difference on Windows platforms between native Java objects and Java methods operating on COM objects. Conversely, ActiveX components can be written, in traditional C++ for instance, to operate seamlessly on native Java objects in the JVM. Java’s native distributed computing technology, called Remote Method Invocation (RMI), is comparable to CORBA and DCOM. RMI provides a naming service for Java programs to look up object references for objects that are executing on remote Java Virtual Machines, and then to invoke methods on these remote objects. In effect, RMI provides ORB functionality that is fully integrated with the Java language and runtime environment. Unlike CORBA, however, the RMI ORB is fully integrated with the Java language and runtime environment. Thus, while CORBA interfaces are described using an architecture-neutral IDL, interfaces of remote Java objects are described using the Java interface construct. Sun has introduced a product called the Java Object Environment (Joe) that integrates Java with its CORBA-compliant NEO product and any other CORBA objects that support the interoperability protocols defined in the CORBA 2.0 specification. NEO and other CORBA-compliant products provide an applet interface to a CORBA object environment. Joe is

Figure 4. The Four Scenarios in the COM/CORBA Interworking Specification Automation Client

Bridge

CORBA Object

COM Client

Bridge

CORBA Object

CORBA Client

Bridge

Automation Object

Bridge

COM Object

the NEO client-side run-time library reimplemented in Java. It also provides the IDL-to-Java mapping required by CORBA implementations. Using CORBA interfaces, Joe will connect a Java client to a server, an RDBMS, or existing applications running remote NEO objects. Java is an ideal CORBA client. It is too early to tell whether the RMI or CORBA solution will emerge as “victor.” Clearly, Sun will drive where the technology goes, and these projects are both works in progress. For now, the important impact of Java is that it adds the application portability to the client that CORBA gives to the server.

Summary Implementing distributed computing presents many challenges with respect to middleware in general and CORBA and DCOM specifically. The correct choice is rarely at either end of the spectrum, but lies somewhere in between. Depending on both the business and technical problems that need to be solved, the greatest probability is a need for both CORBA and DCOM along with some combination of the other types of middleware, namely MOM, RPC, TP, and possibly DSOM and DCE. As businesses deploy commercially available enterprise application packages to replace or augment homegrown applications, they will find these purchased applications have or soon will include CORBA-compliant middleware. For example, both PeopleSoft and Clarify have announced a commitment to BEA’s Tuxedo suite of middleware. The IT community will need to position itself to not only support middleware, but also develop a number of core interoperability services based on middleware to support the purchased applications to legacy applications and/or other purchased applications interaction. It is just a matter of time before most Windows-based desktop applications—including products such as PeopleSoft and Clarify—will have the need for COM and/or Automation clients to interact with CORBA objects on servers. Development managers need to do their homework carefully and plan an evaluation before jumping into the sea of distributed objects. IS departments will need to be positioned not only to support the COM/Automation interoperability with CORBA, but also to develop and deploy homegrown desktop functionality to enhance purchased applications. Enterprises that can master and stay abreast of changes in this technology will succeed more readily than those that cannot. p

Acknowledgements The author wishes to thank Mike Ellison, Cort Klein, Phil Nguyen, Ricka Williams, and Julie Yu, all of Qualcomm, Inc., for their valuable contributions to this article.

Suggested URL CORBA Client

www.DistributedComputing.com

Those interested are referred to www.rohan.sdsu.edu/faculty/rnorman for a comprehensive White Paper on this topic

DISTRIBUTED Computing

45

FOCUS : COM/CORBA INTEROPERABILITY \ including a fully-detailed side-by-side chart comparison of CORBA and DCOM along with an extensive bibliography and glossary of terms. Follow the “research” link on my home page.

6. Montgomery, J., Distributing Components: For CORBA and DCOM it’s time to get practical, Byte Magazine, April 1997. www.byte.com/art/9704/sec8/art1htm

Suggested Readings

7. Orfali, R., Harkey, D., and Edwards, J., The Essential Distributed Objects Survival Guide, New York: Wiley, 1996.

1. Dolgicer, M. and Fischer, P., DCOM, ActiveX, and CORBA Must Live Together, Application Development Trends, April 1997, 38–44. www.adtmag.com/apr97/fe403.htm 2. Dolgicer, M., OLE/COM Fundamentals From a Business Perspective, Application Development Trends, February 1997, 29–36. adtmag.com/feb97/fe202.htm 3. Frankel, D.S., The Ongoing Battle Over Wire Protocols, Distributed Object Computing (DOC), April 1997, 50–52. 4. Foody, M., Let’s Talk: Getting COM and CORBA talking to each other requires more than just lip service, Byte Magazine, April 1997. www.byte.com/art/9704/sec8/art2.htm

8. Pompeii, J., Programming with CORBA and DCOM: It just isn’t as easy as proponents of either side would have you believe, Byte Magazine, April 1997. www.byte.com/art/9704/ sec8/art4.htm 9. Roy, M. and Ewald, A., Inside DCOM, DBMS, April 1997, 27–34. www.dbms.mfi.com/9704d13.html 10.Tash, J.B., Client-Server “Middleware™” Road Map White Paper, Waltham, MA: Database Decisions, 1996.

Ronald J. Norman, Ph.D., CCP is Professor of Information & Decision Systems in the IDS Department at San Diego State University in San Diego, CA. [email protected]

COM/CORBA Side by Side CATEGORY Vendor Support

CORBA

DCOM

CORBA is a “consortium-approved” specification, but not an actual reference implementation

DCOM is a Microsoft (and now the independent ActiveX Consortium) specification AND a reference implementation

Characterized as a shopping mall having several major “anchors,” such as Sun, IBM, HP, Digital, NCR, etc. and hundreds of ISV “boutiques,” such as Versant, IONA, Visigenic, BEA, Expersoft, etc.

Characterized as a shopping mall having one major “anchor” - Microsoft - and thousands of ISV “boutiques” and is viewed as the current “product of choice” on the desktop.

Implementations are based on a written specification standard which is subject to interpretation and could lead to incompatible interpretations of the standard. Validation tests must be performed before OMG certification

Implementations are based on source code provided by either Microsoft or the Open Group. Validation tests must be performed before certification

CORBA represents a robust technical review by DCOM enjoys the luxury of being Microsoft’s sinsoftware industry professionals and, as such, has gle technological model thereby having no need been optimized/satisficed; could be thought of as to consider competing viewpoints being reduced to the least common denominator. Platform Support

Deployment Characteristics

46

Viewed as the object-oriented middleware of Leading contender for Windows 95, 98 and NT choice for enterprises needing to develop/support environments. Implementations across non-Windistributed applications across heterogeneous dows platforms are starting to happen. platforms Was designed from the beginning to be truly object-oriented and distributed. Its roots are in the network and TCP/IP.

Has its origins in the single-user desktop and builds heavily upon the Windows programming model. It could also be said that its roots are derived from compound document technology

An ORB needs to be deployed on each server and each client

COM is included as part of Windows 95 and NT and soon many other operating systems. DCOM is available for Windows 95, included with Windows NT 4.0 and will be included in Windows 98.

Different ORB implementations that adhere to the standard can achieve, at the most, source level compatibility, but not interchangeability of binary components.

A single implementation is accomplished by a defined binary interoperability specification to access its interfaces using pointers and remote proxies; DCOM language bindings available for Visual C++, J++, Visual Basic & Borlandís Delphi (Pascal)

DISTRIBUTED Computing

May 1998