Comparing ActiveX And CORBA/IIOP
Introduction
Because of the explosion of the Internet and the World Wide Web in the last couple of years most organizations are now using or planning to implement Distributed Object Computing to take advantage of this new computing paradigm. It is now clear to everyone that object technology offers the answer to proprietary systems and the limitations they place on businesses. As the need for information systems that can scale to the size of the Internet has grown so has the need for standards that will allow the literally millions of users coming online to talk to each other and get the information they need as well as conduct business over the Internet.
Since 1989, the Object Management Group has been working to create standards for object-based component software within the framework of its Object Management Architecture. The key component is the Common Object Request Broker Architecture (CORBA), whose specification was adopted in 1991. In 1994 CORBA 2.0 defined interoperability between objects in heterogeneous systems. Since then the world has seen a growing list of CORBA implementations come to market. Dozens of vendors have recently announced support for the CORBA Internet Inter ORB Protocol (IIOP) which guarantees CORBA interoperability over the Internet. Specifications of several generally-useful support services now populate the Object Services segment of the architecture, and work is proceeding rapidly in specifying domain specific technologies in many areas, including finance, healthcare and telecommunications.
Recently, Microsoft Corporation announced that it would hand control of its object technology over to the a newly-formed public body called the "Active Group," formed in association with the Open Group. ActiveX, formerly known as OLE (Object Linking and Embedding), is Microsoftís proprietary model for component software within Microsoft Windows, and is being extended to support other platforms. Microsoftís stated purpose in forming the Active Group is to create object based standards that would also promote use of Microsoft products.
This document is a summary comparison of ActiveX and the OMG technologies (of which CORBA is just one). They are compared with respect to both their current state and future potential, and in particular on their usability across the global Internet. For a detailed look at the relative complexities of programming for CORBA and DCOM, see "DCOM and CORBA Side by Side, Step by Step, and Layer by Layer" by Chung et al; even a cursory glance at the side-by-side programming example shows how straightforward it is to write a sample application using CORBA.
Comparison # 1: Architecture, definition and specification
Microsoft's Object Linking and Embedding (OLE) technology came into being in 1990 to provide a cut-and-paste capability for Windows. It was subsequently extended to produce OLE2, for more general communication between Windows applications, permitting the embedding of one document type (such as an Excel spreadsheet) inside another (such as a Microsoft Word document). To do this, OLE2 included a simple, single-machine communication model used by OLE2-aware applications to coordinate their use of screen real-estate. In addition to linking and embedding, OLE2 also enabled Drag and Drop, to allow document components to be picked up from one window and positioned in another, and OLE automation, allowing programs to script OLE-aware applications for "batch jobs," or to coordinate applications to perform complex tasks.
When OLE became OLE2 its new communication model was given a separate name: COM, which was variously said to stand for Component Object Model or Common Object Model. Components in C++, Visual Basic and other languages that drove applications via OLE automation came to be called OLE Controls (or OCXs, after their three-letter MS-DOS file extension), and COM began to be promoted as a general-purpose infrastructure for building component-based software applications. However, COM's application-linked, scripting ancestry is still apparent, for instance in its inclusion of a complete file-naming system (called Monikers), supporting COM clients that instruct applications to load their state from a file, manipulate it, then save it back again. For some two years Microsoft has been discussing plans for a set of code libraries which provide the same interfaces as COM, but enable communication between components on networked machines as well as on a single platform. This Distributed COM (DCOM) DLL is now shipping with Windows NT 4.0, and is also available for Windows 95.
When Microsoft made a change of strategic direction in late 1995 to encompass the Internet, a new name began to be heard -- ActiveX. ActiveX is a general name for the COM/DCOM/OLE/OCX technology. ActiveX controls are the new name for OLE Controls, and with Internet Explorer 3.0 Microsoft is also promoting them as a way of supporting mobile code, for example for downloading application components into Web browsers.
Partly because it's the result of continuous re-naming and re-positioning of a changing technology, it's hard to get a firm grasp on exactly what constitutes ActiveX. Initially it looked as though the new name was intended to mean anything related to COM/DCOM, but a recent Microsoft White Paper says that the OLE name has been redefined as "an umbrella term to refer to the set of interfaces that are built on the Component Object Model (COM)." Meanwhile, "ActiveX represents a language neutral interface based on the ActiveX component technology." More practically, it's also hard to know what specifications form part of ActiveX. For instance, since writing any useful ActiveX control entails using the Windows 32-bit API, it's arguable that this too forms part of the ActiveX specification. However, it is a matter of public record that Microsoft does not publish the entire Windows API, and has energetically opposed efforts by the European Computer Manufacturers Association (ECMA) to produce a public Windows API specification. This being the case, do OCXs that use undocumented Windows interfaces qualify as ActiveX controls?
In contrast to ActiveX's lack of overall architecture and past history of continuous re-targeting and redefinition, the member companies of the Object Management Group (OMG) have shared one consistent vision of an architecture for distributed, component-based object computing since OMG's inception in 1989. The architecture is described in the Object Management Architecture Guide, first published in 1990, and has been incrementally populated with the specifications of the core inter-object communication component (CORBA), and with common services for handling transactions, security, concurrency control and other vital support functions for object-based applications. Both the architecture and the individual specifications are vendor-neutral, and control of their technical direction and definition is via a public process that ensures broad cross-industry consensus. The specifications are available to all (OMG members or not), and free rights to implement software using the specifications are guaranteed by the terms of the OMG's constitution. All OMG specifications are available on-line via OMG's web page at http://www.omg.org/library/specindx.htm.
Comparison # 2: Cross-platform support
At present the only ActiveX/DCOM implementations are for Microsoft operating systems -- Windows 95 and Windows NT. Microsoft has contracted third parties to implement DCOM on other platforms such as Unix and MVS, but shipment dates for these ports have yet to be announced.
The other implementations notwithstanding, the Windows version of DCOM will in practice always be the reference implementation -- although there is a published DCOM specification, Microsoft representatives have in the past been very emphatic that where the specification and the Microsoft implementation differ, the Microsoft implementation is to be considered definitive, and the specification will be adjusted to match. It's clear that the non-Windows versions will always have second-class status; to quote Bob Muglia, VP of Microsoft's Developer Tools Division:
"Microsoft unapologetically will make sure ActiveX works best on Windows"
-Bob Muglia, Microsoft (Source: Client Server News and Red Herring Magazine)
In contrast, multiple platform support has always been OMG's highest priority; the engineers from across the industry who created and maintain OMG specifications (including CORBA) have consciously avoided dependencies on the peculiarities of any one platform. Ironically, the more than 100 CORBA related products available today not only support a wider range of platforms than DCOM/ActiveX, they even support a wider range of Microsoft platforms; at present DCOM is only available for Windows 95 and Windows NT 4.0, while CORBA-compliant products are available on MS-DOS and 16-bit Windows 3.x in addition to the 32-bit Microsoft platforms, almost every Unix, OS/2, OS/400, MacOS, VME, MVS, VMS, and a number of real-time operating systems.
Comparison # 3: Cross-language support
While C and C++ are now used for a significant volume of software development, COBOL is still reckoned to be the most-used programming language (as the primary language of an estimated 3 million programmers, compared to 1.6 million using Visual Basic and 1.1 million using C and C++). The variety of languages used in business and technical applications makes cross language support in general, and COBOL support in particular, critical considerations in real business settings.
The programming model behind COM and DCOM is closely wedded to C++, making support for other programming languages problematic. In particular, DCOM requires the passing of C-style memory pointers between applications, while programming languages such as COBOL and Java do not support pointers. In contrast, CORBA's language-neutral approach was designed from the first to accommodate a wide range of languages. At the time of writing, OMG has adopted (and vendors have implemented) specifications for using CORBA's facilities from C, C++, Ada and Smalltalk. Mappings for COBOL and Java are widely used and undergoing standardization by OMG, while individual vendors' products also include mappings for further languages such as Visual Basic and FORTRAN.
Comparison # 4: Maturity and deployment
Although COM and OLE have been around for some time, the specifications and code have been continuously changing, while at the time of writing (4Q96) DCOM has been available to end users for only three months. Key documents such as the COM & DCOM specifications are only available in draft form, while other, published documentation, such as Microsoft's training CD on ActiveX technology and the description of the ActiveX support in Microsoft's Visual C++ 4.2, contain placeholders for information that's not yet available.
By contrast, the CORBA specification was first published in early 1991 with broad industry consensus and support, and implementations began appearing in March of that year. In December 1994 CORBA 2.0 defined ORB interoperability between heterogeneous systems, again with widespread industry support and rapidly-available implementations. While DCOM is only just becoming available to end-users, there are now a slew of mature, debugged mission-critical systems based on CORBA that have been helping run large enterprises (including banks, major manufacturers and government agencies) around the world for over five years.
Comparison # 5: Support for the World Wide Web
The World Wide Web has been the catalyst for explosive growth in the Internet over the last two years (there are an estimated 250,000 public Web servers on the Internet today). However, although Web technology is well suited to its intended task of browsing remotely-held information, the growth and popularity of the Web is in turn spawning demand for distributed computing capabilities which the Web itself cannot provide. Extending Web browsers with mobile code technology allows programs to be dynamically downloaded from any server into the browser, which thus becomes a general-purpose user interface tool for the downloaded client applications.
The power and flexibility of the mobile code approach brings with it stringent design requirements. A major strength of Web technology is its platform independence -- users can run Web clients on almost any platform in use today, including all flavors of Windows, OS/2, MacOS and Unix. Web browsers are also starting to appear in television sets, low-cost Web-centred Network Computers, and even mobile telephones. Because of cost, power consumption and code size, many of these novel Web platforms do not use the same processor or OS as desktop machines. To be viable, a mobile code technology must be usable across this spectrum of browser architectures.
The most appealing mobile code techology available today is based on the Java programming language. Because it's implemented with interpreted bytecodes, Java easily handles cross-platform support; browsers simply implement the Java Virtual Machine, already ported to dozens of platforms up to and including IBM mainframes. The JVM doesn't directly support easy communication between downloaded applets and other distributed computing resources, but interfacing Java to CORBA is the ideal solution to this, allowing Java applets running in Web browsers to communicate with other CORBA objects (possibly written in other programming languages), including both other applications and OMG object services providing security, transaction support, naming, event management and more. This CORBA access can be provided via an "ORBlet," itself written in Java, and downloadable into the browser. Such ORBlets are already available from many vendors including Sun, Iona, HP, Oracle, APM, IBM and Visigenic, and can be downloaded into any Java-enabled Web browser, including Microsoft Internet Explorer and Netscape Navigator, turning them into full CORBA platforms capable of supporting both client and server objects. Furthermore, starting with Netscape Navigator 4.0, Java-enabled Web browsers will soon be available with CORBA support built-in, thus removing even the need to download the ORB into the browser.
Microsoft promotes ActiveX controls and DCOM as an alternative to Java mobile code and CORBA, but ActiveX is fundamentally unsuited to this role because it's based on native machine code, requiring a separate version of every ActiveX control for every browser platform. While any browser implementing the JVM can use a Java-based Web page, Active X pages can only be used by a browser if the page's author has specifically compiled the control for that platform's CPU.
At present the only browser using ActiveX controls is Microsoft's own Internet Explorer 3.0, which is only available for Microsoft 32-bit operating sys tems; Windows 95 and Windows NT 4.0. Although Microsoft is promising IE 3.0 for Unix and the Macintosh by the end of 1996, there's as yet no word how ActiveX will be supported. Microsoft may simply dictate that all ActiveX Controls should be recompiled, possibly into some sort of "fat binary" format with a separate code segment for each supported CPU. Alternatively, Microsoft might incorporate an x86 code interpreter into non-Intel versions of Internet Explorer to allow them to run existing ActiveX controls. However, Mike Pryke-Smith, Microsoft's Internet tools product manager quoted in Online Reporter has said that, although it's too early to know, "my hunch is it will need a recompile," and that cross-platform interpreters for ActiveX controls are "a long way off." Meanwhile, Java support and CORBA ORBlets are available on a wider range of platforms, including a wider range of Microsoft operating systems, than Microsoft's proposed alternative.
Comparison # 6: Security
All distributed computing necessarily involves communication. If this takes place over public computing networks then the authenticity of the data and its integrity while being transferred may be at risk.
There are two communication mechanisms within ActiveX. The first is the copying of ActiveX controls into a remote machine to execute there. The second is DCOM, which uses Remote Procedure Calls (RPC) to communicate between objects that are already remote from each other. Neither mechanism provides enough security safeguards to be usable in the real world of public data networks, such as the Internet.
ActiveX controls are native x86 code, compiled from C++ without any restrictions on what they may do. This is amply illustrated by the "Exploder" ActiveX control written by Fred McLain and available from his Web page at http://www.halcyon.com/mclain/ActiveX/. When downloaded into Internet Explorer 3.0, Exploder initiates a ten second countdown, then shuts down Windows 95 and turns off the machine. Such a control could be placed on any "ActiveX-enabled" web page. More disturbingly, a maliciously-written control "virus" (more properly called a trojan horse) could just as easily reformat the computer's disk drive or steal confidential information stored on the machine.
ActiveX controls are promoted by Microsoft as an alternative to Java mobile code technology, which by contrast provides effective defenses against this form of attack -- Exploder's anti-social behavior has not been, and could not be, achieved in Java. This is because all Java applets run on a virtual machine which insulates them from direct contact with the host system. This so-called "sandbox" around the applet enforces restrictions that prevent it interfering with the host.
A complementary approach to sandboxing mobile code is to certify the integrity and authorship of the code using public key cryptography. Microsoft, Netscape and Sun are all working on technology to do this; Microsoft's version is called Authenticode, while Sun is working on signing Java applets bundled into JAR archives. By verifying the public key signature on downloaded mobile code, a browser can be sure that the code really was written by the ostensible author, and that it hasn't been tampered with since. However, this verification does not guarantee that the author has no malign intent, nor that the code doesn't contain honest but disruptive coding errors. For example, Fred McLain has now signed his Exploder control; it still shuts down Windows and turns off the machine just as effectively as it did before. As Microsoft admits:
It is important to note that in many cases the sandbox approach is the right approach for security and that Authenticode is a complementary technology to sandboxing.
-"What Is the Exploder Control and How Does It Relate to Authenticode?"
What is left unsaid here is that ActiveX has no capability for sandboxing and it's hard to see how it ever could, whereas Java is entirely compatible with both approaches.
The second aspect to distributed object security is securing the communication between remote objects. Different distributed applications have a diversity of security requirements; in some contexts confidentiality is needed, and this can be provided by encrypting data being sent over the network. In other applications authentication of the communicating objects is more important -- for instance, it isn't usually necessary to keep system administration commands (like "shutdown") secret, but it should be possible to confirm that they really came from an object entitled to issue them. Although DCOM uses a variant of the DCE RPC mechanism for communication between remote objects, Microsoft did not use the accompanying DCE security mechanism originally developed at MIT. DCOM seems at this point to have no support at all for confidentiality or authentication of inter-object communication.
By contrast, OMG has specified a wide-ranging security service for CORBA-based systems which not only provides confidentiality and authentication, but also implements non-repudiation (making it usable for financial transactions, to ensure that the participants cannot later deny their commitments), and accommodates international legal requirements for security auditing. Hence the OMG security service specifications address the real-world security issues necessary for the use of distributed objects in building systems for electronic commerce, in addition to the confidentiality needed in other applications such as keeping medical records.
The OMG Security Service is available for download directly at http://www.omg.org/corba/sectrans.htm#sec
Comparison # 7: Scalability
CORBA was designed from the start with Internet-scale applications in mind. DCOM/ActiveX was clearly never designed to work across large-scale networks. Two tell-take signs of this are its use of reference counts and keepalive messages for resource control.
Reference counts are a way of detecting when the number of clients of a DCOM object has fallen to zero, so that the object can be deleted. Unfortunately for the DCOM programmer, he's expected to manipulate the reference counts by hand, calling an Addref routine every time a reference to an object is duplicated, and a Release routine every time one is deleted. Forgetting to call one or other of these routines at the appropriate time will either lead to objects that live forever (because of phantom references), or worse, objects that spontaneously disappear while being used because the reference count has mistakenly been decremented to zero. These mistakes will be insidiously easy to make; for instance, passing an object reference as a parameter to an invocation on another object (something that OO programmers do all the time) implicitly duplicates the object reference, so to be used correctly in DCOM, every such call must be preceeded by an Addref call, and the called routine must end with a Release.
However, error-free use of reference count calls does not guarantee error-free programs; problems can also arise in the network. Since the counters are maintained at the host object, creation or deletion of remote references must be communicated back to that object. Loss of these network messages, or their arrival out of order (both of which commonly occur on congested networks) will lead to random program errors caused by disappearing objects, or objects that persist indefinitely. Nor is congestion unlikely; merely passing around object references without actually using the object will trigger calls to Addref and Delete, creating network traffic and load on the server. An object with ten thousand clients and the network carrying the reference count messages could both be fully loaded just keeping track of the object's reference count.
Since reference counts are so fragile, DCOM implements a backup resource management mechanism which is unfortunately even less scalable; keepalive messages, called "pinging" in the DCOM literature. Holders of references to an object are expected periodically to send it a keepalive message to reassure it that they're still actively interested in invoking operations on it at some point in the future. Keepalives are sent every two minutes; if the object hears no keepalives for three times the pinging period then it considers all references to have expired, and is free to delete itself regardless of its reference count. Thus network congestion or partitioning that separates a server from its clients for more than six minutes results in the server's disappearance. This is clearly not a distributed computing solution that is going to scale up to the size of the world-wide Internet.
These shortcomings in DCOM are actually symptoms of a deeper cause -- DCOM was never designed to provide Internet-scale inter-object communication, but is instead an adaption of the COM architecture originally designed for the single-machine, non-distributed task of managing screen real-estate and the communication between applications. While MS's statements that DCOM is simply "COM with a longer wire" (Microsoft press release, 9/18/96) are very alluring, design assumptions that were appropriate for the local case in COM aren't appropriate for a distributed platform. Simply adding a DLL for DCE RPC to COM does not create an architecture for distributed applications. Distribution cannot be retrofitted onto an existing product in this way.
In contrast, CORBA was originally designed to supply applications built on the Object Management Architecture with a robust backbone for interoperability in local- and wide-area network environments. Though it works just as well as an inter-language unification technology within process and machine boundaries, support for interoperability across network boundaries was the primary design center from the very start.
Endnote: Interworking
Because ActiveX and COM/DCOM are being promoted by Microsoft as competing with the Object Management Architecture specifications (produced through cooperation amongst OMG's 700-strong membership), it's easy to get the impression that ActiveX is incompatible with the OMA, and that using one in a system design precludes any use of the other. This is not the case.
COM was originally designed as one of the components of Microsoft's OLE2 desktop windowing technology. As such it is widely available within Microsoft Windows, and used in the design of many Graphical User Interfaces for large systems. A key focus of the OMA is to enable integration of multiple technologies in support of building enterprise-wide information systems, as witness CORBA's availability across a wide range of operating systems and languages. Although COM uses a different underlying model to the OMA and different APIs to CORBA, enabling its use within the OMA is just a matter of providing the right tools and technology. OMG's membership specified a COM/CORBA interworking technology in 1995, which is now published as part of the CORBA specification. At least three COM/CORBA implementations are available with CORBA products today, and as many as a dozen more will come on to the market in the next few months. If DCOM is indeed "COM with a longer wire" (to quote Microsoft's press releases) then of course these products will work just as effectively with DCOM without any change in the developer's API. However, to be on the safe side, OMG is running a separate technology adoption process for DCOM/CORBA interworking, the results of which will be available in 3Q97. Meanwhile, many organizations are already using OLE/COM components within systems built with using OMA technology from a variety of vendors.
Conclusions
Microsoftís desktop architecture is one of the worldís most popular and widely used. From a business perspective it is understandable that Microsoft would try and scale its architecture to the enterprise and the internet. The companyís intentions are worthwhile, but the facts are that ActiveX is still in a sense ìnewî and still several years from becoming widely deployed. Active Group members who are working on this technology are only now seeing for the first time what constitutes ActiveX.
Meanwhile OMG is embarking on its eighth year of work creating standards for object based component software. During those eight years the OMG has adopted and seen implemented a major portion of its architecture. Not only has OMG already created interoperability, but interoperability that is being used now over enterprise networks and more significantly over the Internet.
Additionally, CORBAís Interface Definition Language (IDL) is on track to become an ISO Standard in early 1997. As an international standard, OMG IDL may be cited in procurements and used to define service and domain-specific interface standards by organizations and enterprises which may not be able to cite consortium specifications directly.
Continued cooperation between Microsoft and the Object Management Group is critical as the ActiveX technology moves forward. The driving principle behind OMG is making disparate systems work together. It is clear that OMG has succeeded beyond most observersí expectations at creating an open, distributed computing architecture. To ensure that this architecture is used as widely as possible, OMG will continue to work with any and all vendors to ensure that a user can access the information he or she needs from any environment.
摘自 Internet
