Here today, COM tomorrow -- ADTmag

Here today, COM tomorrow

By Sally J Cusack
June 26, 2001

I recently had the opportunity to meet with an I/S director at a large insurance and financial services firm. We had spoken several times in the past, and I knew he was struggling with some architectural decisions as the company was moving forward into its next phase of software development. I also knew of a particular area where the company was dependent on Unix boxes, Sybase databases and PowerBuilder front ends -- a legacy from the firm's early commitment to two-tier client/server computing. Imagine my surprise when he told me that he was seriously considering going with a Microsoft NT/COM solution.

"Do you have VB [Microsoft's Visual Basic] in-house?" I asked. "Not in any significant way," he said. "What about C++ programmers?" I continued. "No, none of those," he replied. Why then, I asked, was he considering a move to a Microsoft solution?

"Because they have most of the pieces," he said. "Not that they have all of them, by any means, but they certainly have more in place and actually working than anyone else I've looked at."

To say I was surprised was putting it mildly. I mean, here is an I/S director at a major-league organization -- that has little or no Microsoft experience in-house -- that is willing to go with Bill's Bunch simply because he feels that Microsoft has more on the table for him than anyone else at this time.

When Microsoft starts getting ahead of the rest of the world in terms of deliverables, it says something -- doesn't it?

At this point, I think everyone would agree that the key to distributing applications across an enterprise and outward into the Internet galaxy is object-oriented, component-based development. The promise of object-oriented components -- reuse, plug-and-play applications and increased developer productivity -- is now starting to be leveraged in order to better meet the business goals of the overall organization. By freeing developers from mundane, repetitive tasks, I/S professionals can now envision how they can create products that directly impact the business enterprise.

I think we would also agree that component technology, in and of itself, is not enough. There is also a requirement for a standardized packaging and communication infrastructure on which to build and link components and services across the organization in an orderly fashion. This would provide a solid yet adaptable platform for linking future development efforts.

The two primary players in this area, Microsoft's Component Object Model/Distributed Component Object Model (COM/ DCOM) and the Object Management Group's Common Object Request Broker Architecture (Corba), are the ones users primarily look to for achieving these results. How-ever, this is where an important distinction must be made: Microsoft's COM/DCOM is an established yet evolving set of services provided by a single vendor. Corba is the goal of the Object Management Group, a standards consortium based in Framingham, Mass.

COM is a single-vendor effort that evolved directly from the desktop. With the delivery of DCOM, extending software functionality from the desktop across the network became a reality. Many COM users are not even aware that they rely on COM, which is an integral part of the MS Windows operating system environment that has also been extended to NT. With truth, Microsoft can assert that there are 150 million COM installations to date. As users look to leverage object-oriented linking frameworks and technologies within an Internet environment, SPG Analyst Services believes that most Windows/NT users will eventually embrace COM/DCOM as the most straightforward and natural infrastructure solution in this environment.

To clear up any lingering confusion in the user community, it is easy to think of DCOM as simply the distributed form of COM. DCOM allows software components to communicate directly over multiple network transports and Internet protocols, such as HTTP. Like its counterparts in the Microsoft component family, DCOM has a heavy desktop-/Windows-oriented heritage, and uses the identical Dynamic Link Libraries (DLLs) and binary structure. It is, in fact, this binary interoperability structure that allows DCOM to link COM components together easily in a plug-and-play fashion. At its core, DCOM is based on the Open Group's DCE RPC specification, and will work with both Java applets and ActiveX components.

Tying the entire picture together for corporate development initiatives is the Windows Distributed interNet Applications Architecture (DNA), designed to provide multitier, architecture-enabling distributed systems development. Using a variety of familiar tools, developers can build tightly integrated applications via a comprehensive set of application services in the Windows platform. Windows DNA also defines a common set of services that are exposed in a unified way through COM. These services include components, dynamic HTML, Web browser and server, scripting, transactions, message queuing, security, directory, database and data access, systems management and user interfaces.

COM today

COM defines a binary standard for component interoperability. Running solely in the Microsoft Windows, NT and now the Apple Macintosh environment, COM nonetheless is a language-independent infrastructure. This lets users write in the language of their choice -- be it Java, C++ or Visual Basic, for example -- while giving them the ability to link components over a common infrastructure. COM objects can be implemented in DLLs or in their own executables as a separate process. And COM's fundamental architecture provides several important functions to developers writing component-based software for distributed applications. These include the aforementioned binary standard for function calling between components; a provision for strongly typed groupings of functions into interfaces; and a mechanism that allows components to dynamically discover the interfaces implemented by other components.

COM services can be accessed in three primary ways:
In the same process: facilitating fast, direct function calls
On the same machine: creating fast, secure InterProcess Communication
Across machines: via the DCOM protocol (DCE RPC)

There are two primary interfaces in COM today, the vtable interface found in C++ environments, and automation (formerly called dispinterface) in the Visual Basic world. While C++ is definitely the more complex of the two, C++ developers would have a difficult time giving up the control and robustness the language offers them in an object-oriented environment. Relying on constructs such as pointers, and without "garbage collection" facilities such as those found in Java, C++ is also perhaps more prone to errors for any but the most meticulous of programmers. However, Microsoft is working to make the C++ programming environment a more pleasurable experience via its next iteration of the COM environment -- COM+.

COM tomorrow: COM+

Throughout the remainder of 1998 and stretching into 1999, COM and the Microsoft Transaction Server (MTS) will evolve into a more homogeneous entity called COM+. The goal of this language-neutral component model is to make COM development easier.

COM+ will give COM development some of the advantages found in a language-specific component development environment. The goal: No matter what language or tool a developer uses, they will only have to write a class -- no class factory or type library creation will be necessary. The rest will be provided in the COM+ runtime. The idea here is to off-load the entire infrastructure concerns onto the system and out of the application. COM+ is designed to preserve all existing investments in COM while providing an environment that requires less coding, therefore increasing productivity. Users must define and provide the meta data and the methods, but COM+ is designed to provide all of the "housekeeping" chores.

The COM+ philosophy is this: write your logic; add annotations (set attributes); the run-time handles all the "grungy stuff"; and interceptors can add value later on.

A key concept in COM+ is interception, which is found in the runtime. Interceptors -- actually a form of attribute-based programming -- allow for automatic behavior via runtime extensions. Different interceptors are required for different services, such as transactional objects, for example. Extensible services provided in the COM+ environment include support for transactions, server infrastructure, administration and security. COM+, in effect, is designed to build on the core COM environment while providing a backbone to Microsoft's DNA and extending the Component Services Model. However, developers should be aware that interception interfaces will not be exposed until the 1999 timeframe. The first iteration of COM+ is scheduled to be released very shortly.

Dave Reed, general manager, COM technologies at Microsoft, recently gave a conference audience a preview of things to come. Over the next several months the COM platform will provide queued request services, loosely coupled event services and load balancing -- all critical features for Microsoft to play successfully in the mission-critical world. The event services, for example, will use a dynamic publish/ subscribe methodology that will look syntactically like calling a method on COM.

In answer to users' concerns about vendor lock-in, Reed pointed out that Microsoft will directly license and support COM on non-Microsoft systems. He was also happy to provide a list of systems integrators that will support COM on Unix. Included on the list were Andersen Consulting, KPMG, EDS and Vanstar. SGI currently licenses COM across its systems, as does Digital (recently purchased by Compaq), Hewlett-Packard and Siemens-Nixdorf. But will these kinds of overtures help convince users that Microsoft is not the Evil Proprietary Empire? Time will tell.