Assad Moini

Software Productivity Consortium

2214 Rock Hill Road

Herndon, VA 20170

It is estimated that among the computers connected to the Internet today, over 80% are PCs running one the several versions of the Windows operating system [1]. Most PC software applications today barely begin to capitalize on the computing resources of the internal corporate networks, let alone the enormous potential of the global network. The internet and web software, on the other hand, constrained by the portability requirements, provide limited functionality and are completely detached from the desktop and rest of the enterprise computing resources.

To circumvent this architectural mismatch and to cope with the heterogeneity problem, standard application programming interfaces (API) and interoperability protocols, called middleware, have been developed. Long term, the complexity of current middleware is untenable [2]. To bridge the gap between the traditional LAN-based client/server and n-tier web architectures, a new unifying model of computing is required to fully exploit the vast capabilities of intranets and global network and at the same time effectively harness the power and benefit of desktop computing. The new model must provide a single common consistent view, a higher-level abstraction that is readily accessible and compatible with the fundamental notions of the distributed object computing.

Structuring an application as a collection of cooperating but independently built components that can be distributed across networks is not a new concept. Distributed object technologies such as OMG CORBA and Microsoft DCOM provide distributed infrastructure and object services for transparent activation and accessing of remote objects and therefore freeing the application developers from the drudgeries of low-level network programming. Conceptually, they provide a kind of a plug-and-play object bus or back plane into which component objects can be plugged in. In this more complex environment, the component developers manufacture reusable binary components while the application engineers build business applications by tailoring, configuring and integrating prefabricated components. Under this division of labor, both groups rely on the infrastructure providers to provide connectivity and other computational resources required to ensure quality of service.

Unfortunately, building scalable reliable and extensible distributed applications from reusable components requires sophisticated infrastructures and higher-level object services that do not fully exist today.

This section provides a brief comparison of DCOM and CORBA. For a detailed discussion, see [5]. The Microsoft Component Object Model (COM) is arguably the most ubiquitous and mature binary component technology. The third party COM component market is estimated to be over $450 million dollars today and is projected to grow to a $3 billion-dollar market by the next millennium [3].

COM provides a language independent standard for creating and interfacing binary component [4]. Integrated into the NT 4.0 operating system, the Distributed Component Object Model (DCOM), transparently extends COM services over the network by layering an object remote procedure call (ORPC) on the top of DCE RPC; it also brings security and multithreading support to COM.

Location transparency is one of the key features of COM. COM services (server objects) can be accessed within the same process address space, or from different processes on the same machine, or across the network. In all cases, the COM run-time system takes care of all the interfacing issues. The COM's inproc model of component interaction is the key enabler of application assembly from independently built binary components. The CORBA specification does not address the in-process model of object interaction and therefore CORBA-compliant binary server objects cannot participate in the component-based application assembly marketplace.

Both DCOM and CORBA are language neutral. All the object interfaces are described in and Interface Definition Language (IDL). CORBA supports multiple inheritance at the IDL level, but DCOM does not. Instead, DCOM objects can have multiple interfaces. In both cases, the interaction between the client and server object is implemented using RPC style call.

Unlike CORBA that is an implementation-neutral specification, developed by an industry Consortium, the DCOM specification is written and copyrighted by Microsoft. Users of CORBA must rely on individual ORB vendors to implement the standard and provide the necessary tooling for software development. Microsoft, on the other hand, has provided a single reference implementation of COM that has been or is being ported to several platforms including Macintosh, Digital Unix, HP-UX, Solaris and even IBM MVS to enable interoperability among heterogeneous environments. Furthermore, to simplify COM programming, Microsoft and other tool vendors have provided a number of application frameworks (architectural templates + reusable components) and development environments where wizards setup most of the skeleton code and generate required scaffolding for creating COM component objects.

COM objects are implemented either as standalone executables or as dynamically linked libraries and are identified using a 128-bit globally unique identifier called CLSID (similar to interface name in CORBA). Each COM object supports multiple interfaces (a group of semantically related methods); a 128-bit identifier called IID uniquely identifies each interface. Every COM interface inherits from IUnknown interface, the virtual base class for all interfaces (similar to CORBA::object).

Every COM object must provide reference counting and QueryInterface services. Reference counting is used to manage an object’s lifetime. To use the services of a server object, a client uses the QueryInterface service to navigate the interface virtual table and acquire an interface pointer (similar to object reference in CORBA) to the server object desired service. Every COM object must implement a class factory that knows how to instantiate objects of certain type along with all the packaging code required by the run-tine system to properly initialize the object (Bind method call in CORBA) as well as the code for identifying and registering it (repository interface in CORBA). To support dynamic invocation and late binding, a component must also implement the IDispatch interface. There is a number of other standard COM interfaces that a component may need to implement. All other custom interfaces must be defined through the IDL.

While COM offers a simple object model, developing components and component-based applications in COM is not easy. Software developers must learn and cope with the nuances of COM API, MFC classes and security, understand COM threading models and have a good command of C/C++.

Today, much of the code required for implementing a COM component has really nothing to do with the functionality of the component being implemented. For example, much of the code for reference counting, object registration, type information, class factory, dynamic invocation interface, and memory management is nearly identical for all components. Another related problem is the use of IDL for defining custom interfaces. In addition to mastering a programming language, as a developer one must master the art of IDL and maintain yet another header file.

Object-oriented programming languages provide constructs for implementing classes, and interfaces. They mainly focus on single-threaded, single-process monolithic application development and are not sufficient for implementing large scale, multi-threaded, multi-process distributed applications. Building large-scale distributed application involves using multiple tools and languages to implement communicating and cooperating multithreaded applications, running of different platforms.

Another source of incompatibility noti is the conceptual gap between the DCOM system-level objects and what object-programming languages consider to be an object.

Learning from the successes of COM and recognizing its shortcomings, Microsoft has been working on COM+, the next step in the evolution of COM. Presently in alpha, COM+ is planned for release with NT 5.0 in mid 1998.

COM+ combines the services of COM, DCOM and Object Transaction services into a single runtime environment, all integrated into the NT 5.0 operating system. It provides a set of extensible basic services including transactions, data binding, persistence security (authentication, authorization encryption, kerberos), near-real time, load balancing, events, queuing, automatic memory management and last but not least interception, a new mechanism for defining new extensible services.

Using the interception mechanism, developers can dynamically create new or enhanced services simply by setting a set of attributes (metdata) on the objects. Different interceptors will provide different extensible services at runtime. Interceptors provide built-in support for instrumentation, monitoring, and testing. They can also receive and process events associated with instance creation, calls and returns, exceptions, and instance deletion. Using the interception mechanism, third party vendors and developers can build out the runtime infrastructure by adding extensible services, instead of replacing the infrastructure

The interceptors interpret the attributes and enable the appropriate service on the fly. There are no more API calls or complex obscure C++ code to be written; only a few attributes to be set, through a visual interface or some scripting language [6]. The COM+ runtime will do all grunt work by providing the necessary housekeeping code required by the object infrastructure - no more reference counting, type information, component registration, memory management, class factory code needs to be written. The developer will simply write the business logic, add annotations, i.e., specify attributes (for example, declare an object as transactional or persistent); the COM+ runtime does the rest. The interceptors, later, add behavior by extending the default services.

Large enterprises are relying on middleware to provide approximated interoperability. Development teams spend too much of their time coping with middleware complexity and diversity. Two trends will continue: (1) new application domains will necessitate creation of new middleware services and frameworks, (2) many existing middleware services will migrate into OS layers, as OS developers aggressively raise the level of abstraction. The operating systems for the next millenium will raise the level of abstraction by providing a set of high-level extensible services with rich object semantics including:

• active global directory services,
• just-in-time binding for data and computational resources,
• fail-safe operation,
• automatic self-managed storage-independent location-transparent persistence,
• role-based security, and
• adaptive visualization for GUI, data and computational entities.