Web Presentation
Want the puppet show instead? If you missed it, here's the web version of Group G's in-class presentation.

Abstract
OMG's CORBA and Microsoft's DCOM are two different middleware solutions for managing distributed objects. The reason for the competing technologies is that Microsoft is hoping to steer distributed object computing in a direction that will favor the proprietary technologies in which the Redmond, WA giant has invested so heavily.

CORBA, a more mature and widely supported ORB, was created by an industry coalition to provide an open standard for a heterogenous environment. The question is, which will become a standard? CORBA has widespread support and looks like the better solution. DCOM has Microsoft's marketing, money, and huge customer base in it's favor. But Sun's decision to put a CORBA mechanism into Java could put CORBA over the top.

Intro to ORB's
Object-oriented and component technology breaks large, complex software applications into pre-built and easily developed and reuseable software modules. Component technology allows for faster development time, lowers integration costs, improves deployment flexibility and lowers ongoing maintenance costs.

An important benefit of component technology is that it separates the execution logic from the business logic. The Object Request Broker (ORB) extends this benefit even further by allowing the components to communicate with each other across processes in a single machine, on a LAN or across the Internet.

The ORB is the middleware that establishes the client-server relationships between objects. Using an ORB, a client can transparently invoke a method on a server object, which can be on the same machine or across a network. The ORB intercepts the call and is responsible for finding an object that can implement the request, pass it the parameters, invoke its method, and return the results. The client does not have to be aware of where the object is located, its programming language, its operating system, or any other system aspects that are not part of an object's interface. In so doing, the ORB provides interoperability between applications on different machines in different distributed environments.

In fielding typical client/server applications, developers use their own design or a recognized standard to define the protocol to be used between the devices. Protocol definition depends on the implementation language, network transport and a dozen other factors.

ORBs simplify this process: with an ORB, the protocol is defined through the application interfaces via a single implementation language-independent specification, the IDL. And ORBs provide flexibility: they let programmers choose the most appropriate operating system, execution environment and even programming language to use for each component of a system under construction. Additionally, they allow the integration of existing components. In an ORB-based solution, developers simply model the legacy component using the same IDL they use for creating new objects, then write "wrapper" code that translates between the standardized bus and the legacy interfaces.

A key feature of object technology is the ability to reuse objects. By simply plugging in object components from many different sources, large, distributed applications can be rapidly and cheaply built or extended. In order to accomplish this, a middleware layer is neccessary to support communication between objects. The most important part of this communication is the object interface that the object presents to the middleware.

Each object's interface serves to specify its methods and the parameters used when invoking these methods. The way that the interface is defined is key to the Interoperability between the objects. It is important to understand that if the interface and the IDL (Interface Definition Language) are the same, then all objects regardless of the where they come from will be able to communicate with other objects via any ORB (Object Request Broker). The ORB with the widest support today is CORBA.

CORBA (Common Object Request Broker Architecture)
CORBA is a specification for distributed objects from the OMG (Object Management Group.) The specification defines a language and platform-independent object bus called an ORB (Object Request Broker), which lets objects transparently make requests to, and receive responses from, other objects located locally or remotely. It takes care of locating and activating servers, marshaling requests and responses, handling concurrency, and handling exception conditions.

Recently, the word IIOP has become synonymous with CORBA. IIOP (Internet Inter ORB Protocol) is an ORB transport protocol, defined as part of the CORBA 2.0 specification, which enables network objects from multiple CORBA- compliant ORBs to interoperate transparently over TCP/IP.

CORBA's Advantages
CORBA has several strong advantages. CORBA's standards have been specified by OMG, a coalition containing over 750 industry members. The open industry standards in CORBA create a level playing field for all vendors. This is beneficial for consumers, as they are not locked into a single vendor proprietary world. Microsoft is in the process of standardizing DCOM, but it continues to lack widespread industry support. Another advantage is CORBA's platform independence and ubiquity.

CORBA claims platform independence and ubiquity because it presumes a heterogeneous environment. Using IIOP, different CORBA implementations interoperate with each other to produce a world-wide object bus. IIOP is fast becoming the TCP/IP of objects. It will be ubiquitous, and will come bundled for free with all non-Windows platforms and browsers.

DCOM is currently available only on Microsoft Windows NT and Microsoft Windows 95. While Microsoft is working with Software AG to port DCOM to UNIX platforms, DCOM is unlikely to become as omnipresent as CORBA, since most platform vendors are investing in CORBA. Even if DCOM is available on other platforms, it is almost a given that its "center of gravity" will continue to be the Microsoft Windows platform.

The maturity of it's specification and implementations are another strong point in CORBA's favor. CORBA has existed since 1990. Commercial implementations have been available since 1992. DCOM was only made available in beta form in 1996. CORBA has had much more time to mature, and there are a large number of companies developing CORBA ORBs. Competition between these companies ensures the robustness and richness of the CORBA solution.

CORBA also leverages advantages of the Java technology. Several CORBA-compliant Java ORBs exist today. These Java ORBs make it possible to write 100% pure Java clients and servers that run on any platform where a Java VM is available. In contrast, ActiveX controls written in the Java language need to be wrapped by platform-specific binary code. Application developers using ActiveX, therefore, need to maintain multiple copies of each ActiveX control -- at least one for each client platform they must support.

CORBA provides a strong security model. Java's applet sandbox security model and bytecode verification totally shields clients from malicious code. ActiveX, on the other hand, has no way of controlling the actions of malicious code. It is important to note that digitally signed ActiveX controls only mitigate this problem; they do not solve it. If you determined that some digitally signed code had acted maliciously, you might be able to take legal action against the author(s) of the software, but the damage will be done.

OMG specifies a rich set of CORBA object services like Naming, Events, Life Cycle, Transactions, Security, Properties, and Persistence. Microsoft will have to port its entire Active Platform to provide developers with this level of functionality on non-Windows platforms.

DCOM, due to its heritage in compound document technology, has an unnecessarily complex API. In addition, DCOM applications are too fat to run on anything but the desktop. CORBA, on the other hand, was designed from scratch without any such restrictions. Java implementations of CORBA, due to their small footprint, can run on thin network computers, on low end Java consumer devices, and on embedded systems.

These advantages will enable CORBA/IIOP, coupled with Java technology, to assume a central role in shaping the Internet during the next phase of its evolution. Unless Microsoft can supplant CORBA with DCOM...

DCOM (Distributed Component Object Model)
DCOM is a Microsoft product and is currently packaged with Window NT, so the increase in NT sales will automatically mean increase DCOM sales.

This strategy, very similar to the marketing strategy for Microsoft's Internet Explorer (which made them so popular with Ralph Nader and the Justice Department), will make DCOM attractive to developers who are more likely to adopt what they already have rather than buy something else.

Like CORBA, DCOM is the object bus, specifying the interface between objects, separating the interface from the implementation and providing APIs for dynamically discovering the interfaces an object exports and how to load and invoke them. DCOM also requires that all shared code be declared using object interfaces. But DCOM isn't CORBA in Microsoft clothing.

Unlike CORBA, DCOM does not support multiple inheritance, rather it supports multiple interfaces. Through aggregation it provides reuse by using multiple interfaces capability. DCOM version of inheritance "is achieved through a web of pointers that link or aggregate different interfaces."

DCOM Advantages
Microsoft believes that DCOM has three main strengths: First, it is based on what Microsoft claims is the most widely used component technology today, ActiveX components. Some of the vendors that sell software development tools that that produce Active X components are: Microsoft, Borland, Powersoft/Sybase, Symantic, Oracle, IBM and Micro Focus.

Secondly, DCOM works natively with Internet technologies like TCP/IP, Java languages and the HTTP network protocols. DCOM provides the "object glue" that allows business applications to work across the Web.

Finally, Microsoft claims that DCOM is based on an open technology that runs on multiple platforms. Microsoft is openly licensing DCOM technology. Additionally, Microsoft is currently working with Internet standards body to promote DCOM as a public Internet technology. It's important to remember that DCOM is versionless, each component gets a new and unique ID.

Some of the services offered by DCOM are: Distributed transaction support (it supports XA, but is more geared toward it own OLE TX protocol), messaging (using MSMQ/Falcon), security (via Windows NT), multi-threading and fail-over (via Wolfpack). All of these services are integrated using a common Directory, interface and IDL, administration routines and underlying communication infrastructure.

Benefits of ActiveX, which of course naturally extend to DCOM are that it is language neutral (developers can build ActiveX components from any language), it has board tools support, that is as stated above, most major software development tools vendors support it, it has board industry support and finally it is an accessible technology due to the fact that a large pool of professional developers currently work in Active X.

DCOM is being touted as ideal for an environment where there are many different applications because it enables Active X components to work across networks thus allowing developers to build systems that span machine boundaries. This can lower integration costs and reduce integration complexity; not only across different platforms, but with legacy operating systems also.

The Bad News About DCOM
However, DCOM is basically two years behind CORBA and for this reason it still needs some polishing up. According to a recent Ovum report, overall DCOM looks promising, but is highly unstable as a middleware foundation.

For example, no load balancing, or automatic multi-threading, no automatic fault handling and no automated memory management services. Also, interoperability is another issue. Software AG is providing ports of DCOM to other platforms, but due to the fact that some DCOM services rely on the Windows Registry and Windows NT, the ports may not provide end-to-end common services.

OMG vs. Microsoft
What these two titans are fighting over is who will control the standard for object technology, a hot prospect since the advent of the Internet and the World-Wide-Web has increased the imperative for deploying distributed object systems.

Sun's decision to put a CORBA mechanism into Java could tip the scales to favor OMG. Current Java beans is a single-language packaging format that is capable of running of either DCOM or CORBA so why is Sun's move so important?

Sun announced that Java RMI (remote method invocation) would be expanded to include OMG's IIOP (internet Inter-ORB protocol), this specifies how Java will communicate with non-Java programs. This major move means that Java will no longer simply be an architecture-neutral language, but will now be a part of OMG thrust.

The clincher is that since Microsoft is the holder of a Java "all-or-nothing" license, according to the terms of the license if Microsoft wishes to ship Java tools to developers, then it must ship them the entire JDK-RMI, IIOP and all.

Sun has also just won ISO approval to be a Publicly Available Specifications (PAS) Submitter for the Java language, which will give it even more power to determine Java standards.

Who will win? No one really knows. But it's sure to be an interesting struggle. If you'd like to learn more, check out OMG's CORBA for Beginners or A CORBA Tutorial by Doug Schmidt (warning: .gz files).

DCOM fans will want to look at the DCOM tutorial and other documents about DCOM and ActiveX technology.