CORBA and DCOM: Side by Side

Transcription

1 FOCUS : COM/ FOCUS : COM/ INTEROPERABILITY and : Side by Side by Ronald J. Norman Business 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 introduces 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. Computing 41

2 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 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, as depicted in Figure 1. Because building one s own middleware to support distributed computing is not simple, cheap, or risk-free, a commercial market niche has developed for middleware products. These products can generally be classified into three categories of services: Distributed Services such as directory and security services. Message Routing, timedelayed, store-and-forward transmission of data files, especially e- mail documents. Standards include X.400, and SMTP. Application Partitioning, controlling the 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 Figure 1. Middleware MiddlewareÕs Position within the Distributed System OSI 7-Layer Reference Model Communication Building Block Layers Application Presentation Distributed Services: X.500 DNS LDAP etc... Session Transport Network Data Link Physical Message Routing: X.400 SM TP M API etc... Application Program Request Broker (ORB) (, COM/, RMI, SOM/DSOM) Messaging System (MOM) RPC (DCE, Netwise) TP Monitor (CICS, Tuxedo) Communication APIs (socket, APPC) SPX, TCP, LU 6.2 IPX, IP, DLC NIC Driver 802.3, Middleware User Service Message Queuing Data Translation Directory Service Nameing Service Security Recovery Broadcasting Session Management Transport Service 42 Computing May 1998

3 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. 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 standard, implemented by various vendors such as Visigenic, IONA, Expersoft, and BEA; and Microsoft s implementation of its own /COM. Repository Dynamic Invocation = Dynamic = Static Figure Architecture IDL Stubs GIOP/IIOP in args operation() out args + return value ORB Static IDL Skeleton In 1989, a group of vendors and users who believed in the benefits of object-oriented development formed the Management Group (OMG) coalition to bring some order to the rapid and disjointed developments of object technology. The OMG s objectives are to foster the growth of object technology and influence its direction by establishing the Management Architecture (OMA) Reference Model, upon which all OMG specifications are based. Among these specifications, is perhaps OMG s most important. The 2.0 Architecture and Specification, adopted in December 1994, was designed to provide the specification for an object-oriented universal middleware that would allow software developers to write objects that could interact with other objects without requiring any knowledge of how or where that object was implemented. A major characteristic of is that it supports the construction and integration of object-oriented software components in heterogeneous distributed environments. As such, an all-windows distributed environment may not need. The architectural model of the 2.0 Specification is shown in Figure 2, and each component is briefly discussed below. The Repository is a run-time metadata repository of registered IDL-defined interfaces, including their methods/operations and required parameters. The Dynamic Invocation is the -defined interface or API for looking up the metadata stored in the 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 allows both clients and object implementations to interface directly with the ORB for the few operations that are common across all objects. Most of the functionality of the ORB is provided through the dynamic invocation, stubs, skeletons, or object adaptors. The Static IDL Skeleton is generally an up-call interface to an object implementation s methods. The Dynamic Skeleton provides a runtime binding mechanism for servers that need to handle incoming method calls for components that do not have IDL-based compiled skeletons. The Dynamic Skeleton looks at parameter values in an incoming message to figure out who it s for that is, the target object and method. Dynamic Skeletons are very useful for implementing generic bridges between ORBs. The Basic Adapter is the primary way that an object implementation accesses services provided by the ORB. There are expected to be a few object adaptors that will be widely available, with interfaces that are appropriate for specific kinds of objects, such as generating and interpreting object references, method invocation, security of interactions, and object and implementation activation and deactivation. The Implementation Repository is the Implementation ORB Core Dynamic Skeleton Basic Adapter Implementation Repository run-time database storing all of an ORB s registered objects, either activated or available for activation by client requests. Finally, for the universal way to connect distributed objects across the Internet or intranet, / IIOP has been adopted. IIOP (Internet Inter-Orb Protocol) specifies how s General Inter- ORB Protocol (GIOP) set of message formats and common data representations for communications between ORBs are exchanged over a TCP/IP network. The Computing 43

4 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 specification defines the least common denominator to which all object request brokers must adhere in order to be OMG compliant. 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 specifications in any way that conforms to the reference specification. Microsoft s Distributed Component Model () dates back to 1990 when Dynamic Data Exchange (DDE) and -Linking-and-Embedding (OLE) were introduced to support the Windows cut-and-paste metaphor. OLE2, called OLE Automation, followed in It allowed the embedding of one document type within another document. Microsoft renamed its underlying new communication model Component Model (COM), promoting it as a general-purpose infrastructure for building componentbased software applications for single computers. Today, Microsoft s is an extension of its COM for multiple computers. Microsoft now groups the COM/ /OLE Automation technologies under the name of ActiveX. COM is an object-based framework for developing and deploying software components. COM lets developers capture abstractions as component interfaces and then provide binary classes that implement those interfaces. COM enforces encapsulation such that client applications can only invoke functions that are defined on an object s interface. Figure 3 illustrates both COM and. The components shown in the Local Out-of-Process section of the figure and the LRPC component in the Remote Out-of-Process section are not needed in the example shown but are included for completeness. is the foundation for Microsoft s Internet and component strategy and extends COM to the network with remote method calls, security, scalability, and location transparency. 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, must go beyond its Windowscentric roots. To accomplish this, Microsoft enlisted Software AG as a partner in late 1995 to port to other platforms. Software AG has announced the general availability of for non-windows platforms. Refer to Software AG s Website for platform implementation release schedules. As 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, 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. Integration For many organizations a business and technology need exists for internetworking between and. This generally means providing a bridge between and COM, and Automation, and vice versa (four mappings). There are only two reasonable strategies for delivering an integrated mixed-model solution: OMG compliant and object bridge. A home-grown alternative is simply not justified given the large number of competitive commercial middleware products available. The OMG-compliant alternative is desirable and is illustrated in Figure 4. The object bridge alternative is also desirable. Examples Figure3. Microsoft s COM/ Architecture Legend = COM = COM Runtime LRPC = Lightweight Remote SCM COM Library Procedure Call ORPC = -oriented Remote Security ORPC Procedure Call Exporter SCM = Service Control Manager Local Out-of-Process LRPC Protocol Remote Out-of-Proce Stack COM Runtime COM Runtime SCM Security ORPC Protocol Stack COM Library Exporter LRPC Local Network Protocol SCM Security ORPC Protocol Stack COM Library Exporter LRPC 44 Computing May 1998

5 are Visual Edge s, along with similar products being released by various ORB vendors.,, and JAVA You may be wondering where Java fits into all this, as its third birthday approaches. There is widespread expectation that the middleware vendors and the enterprise application development environments that support Java will create Java APIs allowing Java applets to interact with ORBs, thus offering a de facto standardized way of building compliant objects in Java. As these -compliant and Java-written objects proliferate on servers, Java applets would call them back using IIOP. In contrast to the 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 and. 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, however, the RMI ORB is fully integrated with the Java language and runtime environment. Thus, while 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 Environment (Joe) that integrates Java with its -compliant NEO product and any other objects that support the interoperability protocols defined in the 2.0 specification. NEO and other -compliant products provide an applet interface to a object environment. Joe is Figure 4. The Four Scenarios in the COM/ Interworking Specification Automation COM Automation COM the NEO client-side run-time library reimplemented in Java. It also provides the IDL-to-Java mapping required by implementations. Using interfaces, Joe will connect a Java client to a server, an RDBMS, or existing applications running remote NEO objects. Java is an ideal client. It is too early to tell whether the RMI or 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 gives to the server. Summary Implementing distributed computing presents many challenges with respect to middleware in general and and 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 and 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 -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 People- Soft and Clarify will have the need for COM and/or Automation clients to interact with 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, 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 Those interested are referred to for a comprehensive White Paper on this topic Computing 45

6 including a fully-detailed side-by-side chart comparison of and along with an extensive bibliography and glossary of terms. Follow the research link on my home page. Suggested Readings 1. Dolgicer, M. and Fischer, P.,, ActiveX, and Must Live Together, Application Development Trends, April 1997, Dolgicer, M., OLE/COM Fundamentals From a Business Perspective, Application Development Trends, February 1997, adtmag.com/feb97/fe202.htm 3. Frankel, D.S., The Ongoing Battle Over Wire Protocols, Distributed Computing (DOC), April 1997, Foody, M., Let s Talk: Getting COM and talking to each other requires more than just lip service, Byte Magazine, April Montgomery, J., Distributing Components: For and it s time to get practical, Byte Magazine, April Orfali, R., Harkey, D., and Edwards, J., The Essential Distributed s Survival Guide, New York: Wiley, Pompeii, J., Programming with and : It just isn t as easy as proponents of either side would have you believe, Byte Magazine, April sec8/art4.htm 9. Roy, M. and Ewald, A., Inside, DBMS, April 1997, Tash, J.B., -Server Middleware Road Map White Paper, Waltham, MA: Database Decisions, 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. ronald.norman@sdsu.edu Vendor Support COM/ Side by Side CATEGORY is a consortium-approved specification, but not an actual 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. is a Microsoft (and now the independent ActiveX Consortium) specification AND a reference implementation 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 represents a robust technical review by software industry professionals and, as such, has been optimized/satisficed; could be thought of as being reduced to the least common denominator. enjoys the luxury of being Microsoft s single technological model thereby having no need to consider competing viewpoints Platform Support Viewed as the object-oriented middleware of choice for enterprises needing to develop/support distributed applications across heterogeneous platforms Leading contender for Windows 95, 98 and NT environments. Implementations across non-windows platforms are starting to happen. Deployment Characteristics Was designed from the beginning to be truly object-oriented and distributed. Its roots are in the network and TCP/IP. An ORB needs to be deployed on each server and each client Different ORB implementations that adhere to the standard can achieve, at the most, source level compatibility, but not interchangeability of binary components. 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 COM is included as part of Windows 95 and NT and soon many other operating systems. is available for Windows 95, included with Windows NT 4.0 and will be included in Windows 98. A single implementation is accomplished by a defined binary interoperability specification to access its interfaces using pointers and remote proxies; language bindings available for Visual C++, J++, Visual Basic & Borlandís Delphi (Pascal) 46 Computing May 1998