Guus Bosman

www.guusbosman.nl

1042114

14-Feb-00

This paper handles about CORBA and COM+; two platforms for distributed component-technology. I choose to write a paper about these standards, because I am very interested in ‘working standards’. I like current technology more than theoretical research.

The paper gives a short introduction to both platforms, and compares them. I feel sorry that I could only write so superficial about these techniques.

I choose to describe COM+, instead of DCOM. Although COM+ still is in beta-phase (actually, NT 5 will be delivered just after I finish this paper), there was enough reason to write about COM+ instead of DCOM. First of all: the differences are not that big. In a sense, COM+ is DCOM + MTS + a few new services + easier use of components. It is not a whole new platform or standard. Also, there is already a lot of information available about COM+, in the form of white papers etc.

However, it should be noted that there was no official document describing the COM+ standard. In fact, there isn’t even an official document describing the DCOM standard. The source I used is still in draft-version (expired January 1998) – this was at Microsoft’s own MSDN website. This is definitely a drawback of the fact that COM+ is designed, maintained and guarded by 1 company – they don’t seems to be interested very much in publishing their standards.

The CORBA design process is complicated – but well structured. Currently, the CORBA 2.3 specification is the most recent on-line version. In my paper I used this official specification, but next to that I used the ‘pre-production’ specification of 3.0.

Since I didn’t know CORBA, I experimented with some different ORB’s. There is nothing about this in my paper though; it didn’t have any academic value, so to speak.

Guus Bosman

14 February 2000

This paper handles about CORBA and COM+; two platforms for distributed component-technology. They both work roughly in the same way. Using one of these systems, a client program can use a component, which possibly resides on a remote machine, the same way as a local component.

CORBA provides a ‘clean’ object-model, which supports true multiple inheritance. It is a well-defined and well-structured framework. CORBA is an industry-wide standard.

The object model COM+ uses is not that clean, and in general COM+ is less well defined then CORBA. COM+ has as an advantage that is created and distributed by the world’s biggest software-seller.

Both CORBA and COM+ provide a lot of default solutions for common problems. First of all of course the fundamental issues as: how can a client find a certain server object, and how does it communicate with it. In the newest versions of both standards there are more services: security, transactionality, etc. There is a trend to make it easier for the developer to use these systems (and thus components).

COM+ will probably swallow the majority of the desktop market for component computing. It is not very likely that Microsoft will ever put in a lot of effort to support COM+ on a lot of other platforms. CORBA on the other hand, supports a large number of different platforms. The OMG defined a standard CORBA/DCOM mapping, and even Microsoft seems to be willing to ‘build bridges’. A lot of vendors are providing bridging software now.

Using these bridges one could combine the two worlds. Together with the movement to make component programming more easy, one can dream of a world where the developer really doesn’t have to know anything about the physical location of his objects, nor about the platform (CORBA or COM+) he is working with.

Over the years business computing systems will be getting more complex. To build and maintain these systems, a well-structured and well-developed architecture is very important. In the past decade, the object-oriented model turned out to be very interesting as a way to create ‘better software’. A recent development is extending this object-oriented model to distributed computing.

Many developers recognize that a system is much more flexible and scalable, when working with an n-tier system. That is: a separation of the client, business, and database logic. Because the coupling between those 3 layers is low, these services can relatively easily stay on different machines. The n-tier system is therefore one of the most used forms of distributed computing.

The advantages of putting the business logic in separate components than the client & server components are clear. An immediate advantage, obviously, is that business objects may be defined according to actual business needs, instead of being dictated by (relational database) technology.

The server just stores the data, and doesn’t have to ‘know’ a lot about this data. All the data-access goes through the business objects. This way multiple clients (say a web-based asp page and a more sophisticated client program) can access the data – without the business logic to be programmed twice. If the business logic would change, only the business logic component will have to change. Both programs will continue to work without problems. It should be pointed out that decoupling business objects from ‘the database’ is easier in theory than in practice [OOP 1].

The different tiers of a system of course don’t have to reside on different machines. However, in practice they often do. In fact, the client and database services usually are implemented on quite different computer platforms (client usually on a desktop, database on a large mainframe). Therefore, interoperatibility between those two ‘worlds’ is important.

Developing a system with distributed objects would be unfeasible without tools and standards. Already in 1991 the Object Management Group (OMG) published a standard for distributed object computing (CORBA). This standard has been adopted by a lot of companies. The big concurrent for CORBA is Microsoft’s COM+, which developed from OLE during the 1990’s.

From a high point of view, CORBA and COM+ work the same, and provide the same services. They both offer an ‘object-bus’ – a way for objects to interact with each other, even if they’re not on the same machine. Also both frameworks come with additional services, such as ways to find each other (naming services).

Clients request services from (object) servers in a standardized way (with the help of a runtime-environment), and servers answer these request in a standardized way. From now on, we will call the program what requires a service from a server object, a client, and this server object the server. The interaction between server and client is implemented in both COM+ and CORBA as object-oriented RPC-style communication.

The interfaces of the objects are defined in an Interface Definition Language (IDL). By using this IDL code-generators can produce code that deals with creating, maintaining and releasing connections in a distributed environment, as well as marshaling and de-marshaling details. So if a server program has to be written in Java, the idl2java code-generator will create all the needed classes for the Java implementation. An idl2cc code-generator would do the same for C++.

In CORBA the IDL serves as a contract between objects. All interfaces for the objects are defined in the IDL, and for every supported programming language there is an exact mapping between this language and the CORBA-IDL. These mapping are defined by the OMG in the CORBA specification.

COM+ also has an IDL, the Microsoft IDL (MIDL). It serves as a support mechanism for defining interfaces in different languages. However, it doesn’t serve as ‘the contract’ between objects -- it’s just a tool. The only contract between objects in COM+ is the binary compatibility.

CORBA is one of the standards defined by the Object Management Group (OMG). It is based on the OMG’s Object Model. There are many implementations of CORBA, by different vendors. They all comply with this standard. Currently, there are more than 800 members of the OMG

The CORBA architecture consist of 4 parts:

The central part of a CORBA implementation is the Object Request Broker. This serves as the ‘object-bus’.

The CORBAservices provide basic functions for using and implementing object. These are dealing with the lifecycle of objects, persistence, naming, event notifications etc. The ORB uses this CORBAservices.

The communication between the object implementation and the ORB is done through an Object Adapter (OA). The CORBA standard defines a standard Object Adapter, the Portable Object Adapter and the Basic Object Adapter, which provides the functionality needed in most cases. Client programs can use other OA’s if this is necessary (for example for performance reasons – an object oriented database might want to register thousands of objects at once, which are expensive operations in the POA).

The OA also takes care of the following services: generation and interpretation of object references, method invocation, security of interactions, object and implementation activation and deactivation, mapping object references to implementations, and registration of implementations.

The Application Objects are the objects the developer (the ‘user’ of CORBA) creates.

COM+ is the latest member of Microsoft’s technologies. It will ship with Windows 2000 (NT 5.0), and possibly also (partly) ported to NT 4.0. It’s a new name, but it is an evolution of existing standards.

In the 1990, OLE 1 was a standard for compound documents (documents consisting of multiple objects, possibly from different vendors). The need to handle difficult and more demanding objects as video and audio clips, led to a rewrite of the underlying technology, the result of this is COM.

COM was defined as a more general component system that allowed communication between processes in a desktop environment. With Windows NT 4.0 it was extended with DCOM, which extended this to network environments. The DCOM standard didn’t contain all the elements needed (such as server-side transaction processing), but in practice developers would always use extra programs such as MTS and MSMQ. The basic feature’s (especially those on the client side), however, are part of every Windows 9x system and NT 4.0.

With COM+, the MTS services were added to the standard, along with several other improvements.

COM adopted the structure of C++ virtual function tables as the binary representation of an interface. COM interfaces are presented to clients as pointers to virtual tables. This is partly an inheritance from the DLL-technology what Microsoft uses for desktop environments. These allowed multiple client programs to link object implementations at execution time (dynamically).

The Object Exporter does the task performed by CORBA’s Object Adapter in COM+. The registry handles the mapping of object name to its implementation. The Service Control Manager takes care of both locating and activating an object implementation.

First of all, we are discussing component technology. Although it isn’t possible to say that components are (just) better objects, there is a strong relationship between objects and components. Therefore, it is interesting to have a look at the underlying object-model of CORBA and COM+.

Second, since we are talking about a distributed environment, the following points should be investigated

• Security
• scalability

Finally, there are some aspects of programming standards in general. I will have a look at both the error handling, the version control mechanisms, and interoperatibility issues.

This will give us an indication about which standard is the ‘best one’.

It definitely should be pointed out that COM+ and CORBA are not the only ‘answers’. What COM+ and CORBA do, is hiding the complexity of distributed object-oriented computing, and giving the programmer an interface to use remote object as if they reside on the local machine. However, as [Guerraoui99] points out, this might not be an ideal system. They argue that because of the very fundamentals of distributed environments, the developer should always be aware that objects are remote.

Inheritance

All objects in CORBA inherit from the base object CORBA::Object and the Basic Object Adapter class. The last one is created by the compiler for each class and completes the mapping between the interface class and the implementation class. Each object can inherent from multiple objects; this is true multiple inheritance.

If a client wants to use an object from a CORBA server, it will hold a reference to this object as a whole. All available methods and properties can be accessed through this single reference. This is conform the usual object model.

Since CORBA object types are defined in terms of interface types, there is no uncertainty regarding the supported interfaces.

COM does not support multiple object inheritance like most object systems. Instead, it relies on inheritance from multiple interfaces for a single object. Each object inherits from IUnknown. The IUnknown interface includes the QueryInterface() method which is used for navigating between the interfaces of an object. In addition the AddRef() and Release() methods are included here. These are used for reference counting and garbage collection. In this way, every server object controls its own lifetime. Each interface has a Globally Unique Identifier (GUID), which must be registered with the Registry. In addition each class also has its own unique class ID (CLSID).

The situation in COM+ is a bit different. According to [Kirtland 97], COM+ will support implementation inheritance, together with object-references (COM doesn’t know object-references, only interface references). However, it is possible to use it, not mandatory. The article says, "it makes versioning a nightmare (see Version control)". In principle, most COM objects will be referred to by interfaces, not with object references.

A big advantage of COM+ over (D)COM is that there are default implementations provided for (for example) QueryInterface(). Also the reference counting is (in the default situation), taken care of by the COM+ runtime system. Here we see that COM+ shifts towards CORBA’s solution. However, it should be pointed out that the COM+ that comes with Windows 2000 will not have this feature.

Garbage collecting

In a distributed environment, garbage collection needs special attention. Objects might be referred to on multiple machines, so reference counting is complicated. Furthermore, computer can go down and connections fail. A distributed object platform should offer solutions to these problems.

DCOM has been criticized for using pinging. When a client first makes a request the server responds with a ping that the client will return as long as it is functioning. If the pinging stops for a certain interval, the server will assume the client ‘went down’ and will do garbage collection. Pinging doesn’t scale well – it creates a lot of overhead. However, COM+ uses several optimizations to reduce this overhead. These are: keep-alive messages on a per-machine basis, piggy-backing ping messages on ordinary request and tracking changes to the set of remote references instead of always transmitting the entire set. Also, pinging can be disabled if needed.

(Abstract) data types

Since COM+ is evoluted from the DCE RPC IDL, which was based on C, COM+ supports all C data types. Unlike CORBA IDL, MIDL does not define a common set of data types accessible by all target languages. Nor does the COM specification. You can define interfaces and data types in MIDL that are accessible to C and C++ but not to Visual Basic or Java. The only common set of data types (called variant-compliant) is defined for OLE Automation, which requires awkward re-mapping of data structures into interfaces, safe arrays, and collections (the latter two being specific OLE Automation, i.e., Visual Basic, data types wizards.

One area of major difference between the two standards is in error handling. COM+ makes use of returned values in a structure called HRESULT. For richer exception handling it uses Error Objects, and the server object has to implement the IsupportErrorInfo interface. Programmers are free to ignore the returned value.

In CORBA the error handling is achieved through the use of exceptions. When an exception occurs, the ORB transparently serializes and marshals it across the ware. This provides a much cleaner way of error handling.

In almost every comparison between (D)COM(+) and CORBA the version control ability (also ‘versioning’) in COM is noted as being a very good thing.

"As COM+ interfaces are immutable, version control is easy with COM programs. A developer can not modify an interface, but has to define a new one if they wish to modify the behavior. This means that once a client is compiled using a particular interface, the developer can be assured that the interface to the server will remain constant.

Traditional service architectures also tend to be limited in their ability to robustly evolve, as services are revised and versioned. The problem with versioning is one of representing capabilities (what a piece of code can do) and identity (what a piece of code is) in an interrelated, fuzzy way.

Interesting to see here is that the fact that COM uses a less clean object model, makes it possible to provide a (extremely practical) feature for developers. Here we can see that COM is evolved (‘quick-&-dirty’) from other technologies, instead of being build from scratch as an object-oriented distributed system. Versioning is something that is not very important in theory – but in practice it happens very often that objects are updated and than versioning becomes very important.

Because of the fact that COM+ is still in beta-phase, it is not possible to tell on what platforms it will be supported.

DCOM is supported (obviously) on Windows 9x, and NT 4. Companies like Software AG provide COM implementations for different UNIX implementations, including LINUX. Digital does the same for the Open VMS platform. However, several sources expect that Microsoft will focus mainly on their Windows platform, and that the other implementations will always be ‘on the second row’. This is, again, a result of the fact that COM+ is defined and maintained by a single company -- who also sells an operating system.

The situation for CORBA is quite different, obviously. Because of the very nature of the OMG, interoperatibility is extremely important for them. "The newest technology of today is the legacy software of tomorrow" (see Bridging).

Both COM+ and CORBA are scalable models. The MTS has an automated thread management system. It provides resource pooling and database connection multiplexing, which allows the user and data load to be distributed more efficiently. CORBA provides the Object Activation Daemon (OAD) and the Implementation Repository, which control the use of resources by only instantiating object when they are needed.

COM+ provides a well-developed security system. Developers define roles and privileges for their components, and system administrators later assign roles and privileges to user. In this way security is abstracted to a level at which developers and administrators can easily work with the security features of the operating system, without having to know all kind of details about it. Of course this means that the operating system has to support these security features (read: Windows). Also the Authenticode technology can be used, to digitally ‘sign’ components.

CORBA has two security levels. The first level allows an application that is not security savvy to relegate itself to a secure domain. User authentication, authorization with ACLs, data encryption and integrity are all part of Level 1. Level 2 requires that applications be security aware, which is a stronger flavor of the above. Some CORBA vendors provide SSL (Secure Socket Layer), but that is not part of the specification.

Obviously, CORBA’s security model work on all the platforms there is a CORBA specification for. COM+ relies on the Windows security model.

An important difference between components and objects is the facts that components do not have a persistent state [OOP 2], but objects do. However, but in both CORBA and COM+ there is a way to implement this persistence.

CORBA defines an object reference that identifies an instance of an object uniquely in a network. An object implementation can take advantage of this to ensure that a given object reference always refers to the same entity, creating an identity that can persist over multiple object activations of the instance from persistent storage. These object references can be externalized into strings that can then be converted back into an object reference.

COM+ does not have the concept of an object reference. The closest analogy is the Moniker, which provides a persistent naming mechanism. Monikers encapsulate implementation-specific schemes based on names that encode an object's location. This can involve activating an implementation of the object class and restoring its state from persistent storage. There are several types of moniker provided, and the developer can implement custom moniker types.

COM+ uniquely identifies an interface using the concept of Interface Ids (IID) and uniquely identifies a named implementation of the server object using the concept of Class Ids (CLSDID) the mapping of which is found the registry.

New services

Both CORBA and COM+ are still under construction.

COM+ integrates the MS Transaction Server and the MS Message Queue into the DCOM standard. The MTS provides is a container for server-side components, which provides transactionality for components. MSMQ provides reliable asynchronous communication.

An important improvement of COM+ over DCOM is that COM+ does a lot of the ‘plumbing’, which in DCOM was in the developers’ responsibility (or of his runtime environment, such as Visual Basic). COM+ for example, provides a default specification for the reference counting. In fact, this way COM+ comes closer to the way CORBA works: in CORBA::Object also a lot of these things are pre-defined (although still customizable if needed). These default functions in COM+ are now part of the ‘system run-time’ – as opposed of the programmers developing environment’s runtime.

The same goes for CORBA. The latest version of CORBA (3.0) also defines a lot of extra functionality. The CORBAcomponents introduced in 3.0 contain a container environment that packages transactionality, security, and persistence and provides interface and event resolution. In the current ‘CORBA Components final submission’ it says that these CORBAcomponents are provided to provide a greater level of abstraction, and greatly simply programming CORBA.

Bridging

Because of the nature of the OMG (a lot of companies working together), interoperatibility is very important very them. Therefore, they make sure that there are 1) well-described standards every member can use and 2) they provide mappings from a lot of existing programming languages to IDL.

OMG specified a COM/CORBA mapping in 1995 (which is part of the CORBA specification now). Since then several object-bridges have been developed. They differ in how transparent they are for the developer, and in their ease of deployment.

The OMG is working on mappings to ActiveX, and COM+. Besides the OMG, Visual Edge brings Object Bridge, a bridge on object-level.

COM+ is a working technology, being backup up by the world’s biggest software-seller. It offers a lot ‘out-of-the-box’ functionality, which is not necessary the best functionality, but it works and most of all, there are no compatibility issues: there are simply no other vendors providing COM+. A disadvantage is the fact that COM+ is dirtier. Its object model isn’t particularly elegant, and the COM+ standard is really not well documented.

CORBA is a better-designed system. It’s underlying object model supports true multiple inheritance. It comes with a much better exception-mechanism than COM+ does, and it is much better defined as a standard.

It is unlikely that companies will be willing to ‘place all their eggs in one bucket’. A lot of companies have invested in CORBA. On the other side: COM+ does (or will) exist on the majority of all desktop systems.

There are CORBA implementations running on a lot of different operating systems, whereas COM+ is currently only supported by Windows machines. Microsoft will probably never put a lot of energy in porting COM+ to other platforms. In fact, according to the OMG [OMG 98], Microsoft is now working with bridge-vendors to make their MTS working with ORB from different vendors (such as Iona and Orbix).

The recent developments turn in the direction of making component programming easier. They lead the developer away from details like reference counting and greatly simplify security and transactionality. So, in an optimistic mood we might dream of a world where the developer really doesn’t have to know anything about the physical location of his objects, or about the platform (CORBA or COM+) he is working on.

[Cameron] COM+ services 1.0 overview

David Cameron

Microsoft Corporation

[Chung] DCOM and CORBA Side by Side, Step by Step, and Layer by Layer

P. E. Chung, Y. Huang, S. Yajnik

Bell Laboratories, Lucent Technologies

http://www.cs.wustl.edu/~schmidt/submit/Paper.html

[DCOM 1.0] Distributed Component Object Model 1.0

[Talman] COM versus CORBA a decision Framework

O. Tallman and J. B. Kain

Distributed Computing, September-December 1998

[Guerraoui99] OO Distributed Programming is Not Distributed OO Programming

R. Guerraoui and M. E. Fayad

Communications of the ACM April 1999/Vol 42, no. 4

[Lewandowski] Frameworks for Component-Based Client/Server Computing

S. M. Lewandowski

ACM Computing Surveys, Vol. 30, No. 1, March 1998

[Kirtland 97] Object-Oriented Software Development made Simple with COM+ runtime service

M. Kirtland

MSJ, November 1997

[Natan95] CORBA, a guide to Common Object Request Broker Architecture

R. Ben-Natan

McGraw-Hill Computing, 1995

[Normal97] White Paper – middleware: CORBA and DCOM – version date 10/27/97

R.J. Norman

IDS Dept San Diego State University

[OMG] The Object Management Group website

[OMG 98] Microsoft Finally Consents to Marriage of Software Models

Object Management Group, June 1998
by Graham Lea

[OOP 1] Principles of Object-Oriented Software Development

A. Eliens

Addison-Wesley Longman, february 2000

[OOP 2] Principles of Object-Oriented Software Development

A. Eliens

Addison-Wesley Longman, february 2000

[Raj 98] DCOM, CORBA, Java-RMI - A step by step comparison

G. S. Raj

September 1998

Introduction *

Summary *

What question does component-computing answer? *

CORBA & COM+, an overview *

CORBA & COM+, a comparison *

So… what’s the answer? *

Conclusion *