COM+ Notation, Interface, and Implementation
Gopalan Suresh Raj

Food for Thought...

import "unknwn.idl";

[uuid(BC4C0AB0-5A45-11d2-99C5-00A02414C655), object]
interface IStockMarket : IDispatch {
 HRESULT getPrice ([in] BSTR ticker, [out, retval] float * stockPrice);

[uuid(7371a240-2e51-11d0-b4c1-444553540000), version(1.0)]
library SimpleStocks {

 coclass StockMarket {
    interface IStockMarket;

- Yours Truly

import simplestocks.*;
public class StockMarketClient  {
 public static void main (String[] args) {
  try {
// use CoCreateInstance to load component and use Query Interface to coerce type
   IStockMarket market = (IStockMarket) new simplestocks.StockMarket ();
   System.out.println ("The price of MY COMPANY is " + market.getPrice ("MY_COMPANY"));
  catch ( e) {
   System.out.println ("COM Exception:" + e.getHResult () + " - "+ e.getMessage ());

- Yours Truly

The COM+ component defines 'what' tasks it can perform in terms of an Interface and 'how' it performs it in terms of an Implementation. So an interface is a contract between the component and a client that a component agrees to satisfy and support. Each functionality that a component provides to its clients will most probably be represented using a distinct Interface.

Since many different types of components can expose the same Interface, a COM interface is an Abstract Data Type (ADT) and cannot be instantiated directly.
A COM Interface is a collection of semantically related operations that express one functionality and focusses on "what" the component can do.

However, a COM Implementation is a concrete instantiable data type of COM. Every COM Implementation may expose one or more interfaces and will have a name that is known to its client. COM Implementations are often called COM Classes or coclasses.
A COM Implementation or COM Class is an implementation of one or more interfaces and focusses on "how" the component does what it does.

COM+ Notation
COM+ represents a component graphically using a floating opaque box with a plug-in jack (also refered to as a 'lollipop') extending to one side as shown in the following figure.

COM+ stresses binary encapsulation. So it is only appropriate that COM+ components are drawn as opaque boxes. In addition to simplifying client-side documentation, this technique allows the component implementors complete flexibility with respect to changing implementation details. While this approach to documentation may be very useful from the client-side perspective, it is however not very useful to document how an object is implemented internally.

Also be aware that by convention, the names of all interfaces in COM+, start with 'I'.


A COM+ Interface consists of a set of method definitions that are usually related in the operations that they perform. Invoking a method results in the execution of the COM+ object code associated with that method. The method is usually invoked using a pointer to the associated Interface.

For example, a "Bank" component can have interfaces called
ICheckingAccount and ITeller. These interfaces generally group like methods. For example, the ICheckingAccount interface may contain methods called create(), credit(), and debit(). The ITeller interface may contain methods called createCheckingAccount(), createSavingsAccount(), and transferFunds().

The COM+ Interface is an Abstraction which contains the syntax of the methods that it contains, and the semantics of how they are to be used. The Interface has a very specific structure in that, it is an array of pointers to the implementations of the methods that it exposes.

Some Interesting Observations

1. Notice that the vtable is actually an array of function pointers. It is called a vtable since it represents the same virtual table structure that C++ compilers produce when generating object code while compiling C++ classes.

2. Notice that the definition of an Interface does not include an implementation of the interface methods. This separation of interface and implementation leads to a more scalable design, where interfaces can be reused in different places, and a component that exposes a particular interface can be replaced with another component that exposes the same interface. If a COM+ client knows the particular interface that it needs, all that it needs to do is to find an object that implements it.

3. The most important aspect of COM+ is not what the component is, but what it can do. Because interfaces are the only way of making a component do anything at all, we can say that the functionality of a component is defined by the interfaces it exposes.

4. The COM specification includes details of a number of standard interfaces that Microsoft has defined. By implementing one of these interfaces, a component states that it supports some kind of functionality, or that it will work in some given situation. For example, a
coclass that implements ISupportErrorInfo is able to return rich error information, while a component implementing IDataObject is capable of allowing data to be pasted or dropped into another application.

Interfaces Are Immutable

COM+ enforces complete encapsulation of the data and implementation of a component. You can only call methods on the interfaces exposed by a component; you never get direct access to its data. This fact is what makes interfaces so fundamental.

In COM+,
1. An interface, once defined, must never change. Published interfaces are immutable.

2. Once a component has said that it exposes an interface, any future version of that component should also support that interface, to avoid existing clients from malfunctioning

The interfaces that a component exposes represent a 'contract' between the component and its clients. A consequence of the second of these points when taken in the context of the first is that changes made to the contract in order to 'update' a component will surely break any existing clients, and so any revisions must be made with care.


click here to go to
My Basic COM+ Tutorial...
click here to go to
My Advanced COM+/DNA Tutorial HomePage...


About the Author...
Gopalan Suresh Raj is a Software Architect, Developer and an active Author. He is contributing author to a couple of books "Enterprise Java Computing-Applications and Architecture" and "The Awesome Power of JavaBeans". His expertise spans enterprise component architectures and distributed object computing. Visit him at his Web Cornucopia site ( or mail him at


Go to the Component Engineering Cornucopia page

This site was developed and is maintained by Gopalan Suresh Raj

This page has been visited times since March 13,1999.

Last Updated : Mar 14,'99

If you have any questions, comments, or problems regarding this site, please write to me I would love to hear from you.

Copyright (c) 1997-2000, Gopalan Suresh Raj - All rights reserved. Terms of use.

All products and companies mentioned at this site are trademarks of their respective owners.