Modeling Components

and Frameworks

UML


with

or more than a decade vendors have hyped and under

delivered the promises of
object modeling and component technologies. As a
result, object modeling
tools are in disrepute in many development organizations, and the
semantics of the term componentbased have been diluted to an extent
reminiscent of what occurred to the
expression object-oriented in the
previous software generation.
However, if we put aside our
skepticism and evaluate recent
advances in these technologies, we
find encouraging signs that they are
catching up with some of their
hyperbole. Many object modeling
tools can now generate productionquality skeleton code from structural
models, and some of them can also
derive useful methods from behavioral models. While they still fall far
short of the ambitious goals of full
round-trip engineering, their
improvements mark significant
progress toward automating the software development process.
Likewise, the leading component
standards have evolved from nascent
definitions of simple architectures to
mature specifications of complete
runtime environments. For example,

Sun Microsystems JavaBeans definition has developed into the Enterprise JavaBeans (EJB) specification,
which supports both transaction and
persistence services for enterprise
applications [4]. Similarly, Microsofts
COM definition has evolved into the
DCOM and COM+ specifications,
and supports the Microsoft Transaction Server (MTS) for enterprise
applications [3].
While analyzing the evolution of
these technologies it is important to
note that strong synergies exist
between them. The coarse granularity
of components in relation to classes
promotes the modularity and reuse
goals of object modeling. Conversely,
the rigorous specification discipline of
object modeling supports the interface-based design and replaceability
aims of components. Consequently, it
is not surprising that component
Integrated Development Environments (IDEs) are converging with
visual object modeling tools, a trend
that is likely to continue.
This article explores some of the
synergies between object modeling
and components by examining how
the de facto object modeling language standard, the Unified Modeling Language (UML), supports the
leading enterprise component archi-

As localized
objects evolve
into distributed
components,
developers are
asking that UML
provide better
support for
component-based
development
using EJB and
COM+.


Cris
kobryn


COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10

31

tecture standardsEJB and

COM+/MTS (or COM+ for
short). It is presumed the reader
is generally familiar with how
UML is used to specify software
systems; the central focus here
is UML component-modeling
capabilities.

Figure 1. Component and interface notation.

Realize relationship
Longhand
notation for
interface showing
operations

ShoppingCart
+calcWeight()
+calcShipping()
+calcTotal()
...

Components in UML 1.3

The current UML specification,
UML 1.3, defines a component
as follows:
component: A physical,
replaceable part of a system that
packages implementation and
provides the realization of a set
of interfaces. A component represents a physical piece of
implementation of a system,
including software code
(source, binary or executable)
or equivalents such as scripts or
command files [9].

interface
Calculate

interface
ChangeOrder
+addItem(item:Item)
+deleteItem()
+saveItem()
...

Component
showing
attributes and
operations

+Weight
+Shipping
...
+orderItems
...
+calcWeight()
+calcShipping()
...
+addItem(item:OrderItem)
+deleteItem()
...

Component and interface notations showing details

Calculate
Shorthand
("lollipop")
notation for
interface

ChangeOrder

ShoppingCart

Component and interface notations hiding details

Figure 2. Deployment diagram example.

primaryServer:appServer
database
PrimaryDB:
AccountsDB

A computational
node, in this case
an application
server

It is important to note that

primaryQuoter:
call
QuoteService
this definition tends to be
call
restrictive and emphasizes the
primaryBroker
use of components for imple:StockBroker
mentation modeling (compare
this with analysis and design
modeling). This point will be
copy
copy
copy
addressed later in this article.
become
The UML notation for combecome
ponents is summarized in FigbackupServer:appServer
ure 1. In this diagram a
backupBroker
ShoppingCart component for
:StockBroker
an e-business application is
call
shown as a rectangle with two
call
database
smaller rectangles protruding
backupQuoter:
backupDB:
QuoteService
AccountsDB
from its side. At the top of the
diagram the component is
shown with attributes, operations, and the interfaces Calculate and ChangeOrder, which are drawn using found in implementation model diagrams, such as
longhand interface notation (rectangles that contain component diagrams and deployment diagrams. A
an operations compartment). At the bottom of the component diagram shows the organization and
diagram the component is shown in a more compact dependencies of components, and a deployment
representation where the attributes and operations diagram shows how component and class instances
are elided and the interfaces are drawn using short- are deployed on computational nodes. An example
hand (lollipop) interface notation.
of a deployment diagram that uses components is
Although UML components may be shown in shown in Figure 2.
any structural modeling diagram, they are typically
The example shows a simple failover scenario for
In a failover
scenario, the
backupBroker
becomes the
primaryBroker
and vice versa

Indicates
replication

32

October 2000/Vol. 43, No. 10 COMMUNICATIONS OF THE ACM

Table 1. Semantic comparison of components,

subsystem, and classes.
COMPONENT

Is a classifier?
Can have operations?
Can have methods?
Can have attributes?
Can have interfaces?
Can be associated?
Can have thread of
control?
Can be nested?
Is a grouping construct?
Can import/access?
Represents a unit in a
physical system?
Contains implementation
of model elements?
Can create instances?
Instances typically reside
on nodes?

SUBSYSTEM

+
+

+
+
+

+
+

+
+

+
+
+
+

+
+

+ (optional)

an online stockbroker system, where several components deployed on an instance of the primary application server node (primaryServer) are replicated on
the backup application server node (backupServer).
On the primaryServer the primaryBroker, an instance
of the component StockBroker, calls the interfaces of
the primaryQuoter (an instance of the QuoteService
component) and the primaryDB (an instance of the
AccountsDB component). Component replication
and migration are shown by copy and become
dependency flows, which are part of standard UML.

Semantic Overlap: Components, Classes,

and Subsystems
The fact that UML is a general-purpose modeling
language is both a strength and a weakness. Although
software developers find they can use UML to model
most software problems in a variety of ways, they are
frequently overwhelmed by their options. The problem is exacerbated by the dearth of pragmatic examples and the lack of tools that support advanced
constructs. Many of the examples in UML modeling
books tend to be trivial or academic, and frequently
do not address the practical problems faced by developers. As for modeling tools, the author knows of none
that fully implements the UML 1.1 semantics and
notation (adopted three years ago), let alone one that
completely or correctly implements the current UML
1.3 specification (which was adopted a year ago).
Consequently, many modelers find the modeling
of components, which is sometimes considered an

CLASS

+
+
+
+
+
+
+

advanced UML modeling topic,

problematic. One of the most
common problems modelers
encounter is the semantic overlap
between components and related
classifiers, such as classes and subsystems, which are defined as follows:

class: A description of a set of

objects that share the same
attributes, operations, methods,
+
relationships, and semantics. A
+
class may use a set of interfaces

to specify collections of opera

tions it provides to its environment [9].

subsystem: A grouping of model

elements that represents a behav+
ioral unit in a physical system. A

subsystem offers interfaces and

has operations. In addition, the
model elements of a subsystem
can be partitioned into specification and realization
elements [9].
The semantics of components, subsystems, and
classes are compared in Table 1. The table shows that
all three classifiers can have operations and interfaces, may be associated with other classifiers, can be
nested, and may create instances. Components are
similar to subsystems and differ from classes in that
they cannot have threads of control and they represent units in physical systems. Components differ
from subsystems and classes because they are not a
grouping construct; they alone can contain the
implementation of model elements, and their
instances typically reside on computational nodes.
Only subsystems can import or access other model
elements.
It is important to note that, while all three classifiers may conform to a set of interfaces, interfaces are
usually most closely associated with components.
Although it is relatively common to see a class without an interface during analysis, and subsystems may
use model elements other than interfaces for specification (for example, use cases and statecharts), a
component without an interface may be technically
well-formed but suspect. This reflects the longstanding and intimate relationship between componentbased development and interface-based design.
For example, both COM+ and the CORBA Component Model (CCM) are closely associated with
Interface Definition Languages (IDLs). In addition,
COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10

33

both the Java and EJB specifiTable 2. Usage heuristics for components, subsystem, and classes.
cations emphasize interfacebased design.
COMPONENT
SUBSYSTEM
CLASS
When choosing among these
Tend to be coarse+
+

related classifiers modelers may

grained?
also find it useful to consider
Typically modeled

+
+
some usage heuristics. Although
during analysis?
the UML is a modeling lanTypically modeled

+
+
guage and not a software
during design?
method, the specification does
Typical modeled
+

+
provide some usage notes
during implementation?
regarding how some constructs
can be used during various
phases in the software life cycle.
Figure 3. Enterprise component framework pattern.
Other heuristics may be gleaned
from component methods, specifications, and applications.
With the caveat that these are
Proxy
basic guidelines and not rules,
Enterprise Component Framework
Table 2 summarizes some
heuristics for applying the classifiers in question.
In general, components and
subsystems tend to be more
coarse-grained than classes.
Indeed, it is common for a component to implement multiple
design classes. Similarly, it is
typical for a subsystem to model
the specification and realization
of a set of model elements,
which may include both specifiProxy
cation types and implementation classes. Components are
further distinguished from both subsystems and emphasizes the reuse of design patterns and archiclasses in that they are typically modeled during the tectures. One common definition is that a frameimplementation phase (compare analysis and design work is a reusable design of all or part of a system
phases). It is important to note, however, that the represented by a set of abstract classes and the way
classes and/or subsystems specifying components their instances interact. Another frequently used
and frameworks may be modeled during an earlier definition is that a framework is the skeleton of an
application that can be customized by an applicalife-cycle phase, such as analysis or design.
tion developer [5]. These definitions are compleModeling Component Frameworks
mentary, not conflicting, since the former describes
Components are quintessential software building a framework from a design perspective, whereas the
blocks that can be recursively composed to build sys- latter describes it from a functional viewpoint.
tems of increasing size and complexity. Just as the However, the differences between the two definihardware industry has used integrated circuits to tions point out the variety of ways in which the
recursively build larger and more complex hardware term is used.
components, the software industry now endeavors
Although the UML definition of a framework is
to do something similar with software components. more restrictive than the preceding definitions, it is
Component frameworks are important mechanisms compatible with them:
being used to accomplish this.
A framework is a generic term for a powerful framework: 1) A stereotyped package consisting
object-oriented reuse technique that typically mostly of patterns. 2) An architectural pattern that
The Proxy pattern used here is defined
in [1]. Note that the pattern is used
twice.

original

proxy

client

Factory

call

FactoryProxy

Client

call

call

Factory

original

Component

call

Remote

Remote

RemoteProxy

call

Either the Container

or the Component

Context

call manages the

PersistenceService

Container

proxy

client

34

October 2000/Vol. 43, No. 10 COMMUNICATIONS OF THE ACM

call

{xor}

Persistence
Service

and heuristics for applying patterns. As was the

case for the framework
ShoppingCart
concept, there are diverse
Specification Elements
RealizationElements
opinions regarding the
definition and use of patterns. In consideration of
this and the scope of this
article, we will restrict our
modeling of patterns to
UML parameterized collaborations.
The structure of the
Enterprise Component
Framework pattern is
modeled as a parameterized collaboration in
Enterprise Component Framework
Figure 3, where the collaboration is shown as a
dashed ellipse. This pattern contains seven classiprovides an extensible template for applications
fier roles that participate in the collaboration, which
within a specific domain.
are depicted as rectangles: Client, FactoryProxy,
RemoteProxy, Context, Component, Container, and
The first definition is less than illuminating, since PersistenceService. The Client represents an entity
it explains the concept in terms of the UML con- that requests a service from a Component in the
struct (the framework stereotype of Package) with framework.
sparse additional semantics. The second definition is
An important aspect of this pattern is that the
more informative and reinforces the associations Client does not call the Component directly. Rather
between frameworks, patterns, and architectures.
it communicates indirectly via a pair of proxy roles
As one might intuit, component frameworks are (FactoryProxy and RemoteProxy) that delegate
frameworks typically designed, constructed, and (relay) calls from the Client to the Component. This
extended using components. Since a comprehen- level of indirection supports two important
sive discussion of component frameworks is functions:
beyond the scope of this article, readers are referred
to [5] for more information about them. The Location transparency: At a lower level of
remainder of this section focuses on two compoabstraction the proxies may be realized by stubnent frameworks that are industry standards for
skeleton pairs, such as those used by CORBA,
building enterprise applications: Enterprise JavaJava RMI, and COM+.
Beans and COM+.
Message interception: The use of proxies allows
Defining a common pattern. The architectures
the components runtime environment (the Conof Enterprise JavaBeans and COM+ are based on a
tainer) to intercept method calls and insert sercommon architectural pattern that we call the Entervices based on a set of attributes defined at
prise Component Framework. The purpose of this
deployment time.
pattern is to describe the basic mechanisms for a
component runtime environment that supports disThe roles of FactoryProxy and the RemoteProxy
tributed services for interprocess communication, as surrogates are made explicit by the use of two
transactions, and persistence.
Proxy sub-patterns in the main pattern. These subFor the purposes of this article a pattern is defined patterns are shown as dashed ellipses, but their clasas a common solution to a recurring problem in a sifier roles are elided to reduce distracting detail.
particular context. UML 1.3 prescribes that the Readers interested in details about the structure and
structure of patterns should be modeled using para- behavior of the Proxy pattern are referred to [1] and
meterized collaborations, but does not prescribe the [6]. The bindings of the roles of the Proxy pattern
modeling of non-structural aspects, such as behavior described in [1] to their counterparts in the main
Figure 4. Application of pattern to EJB.

Indicates a
Subsystem

In the case of EJB

either the Bean or
Container can
manage persistence

EJBHomeInterface
ShoppingCartHome

call

ArtStoreClient

HomeObject

create(...)
findByPrimaryKey(...)
...

call

ShoppingCartHome

EJBRemoteInterface
ShoppingCart

call

call

getItemCount()
setItemCount(...)
getTotal()
setTotal(...)
...

EJBEntityClass
ShoppingCartimpl

database
ArtStore

ShoppingCart

RemoteObject

call

javax.ejb.EntityContext

EJBContextObject
ContextObject

remoteProxy

context

client

container

factoryProxy

persistenceService

component

Collaboration
representing the
pattern structure

COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10

35

example, database storage and

retrieval) can be coordinated
directly by the Component or
can be delegated to the Container. This choice is shown by
the {xor} constraint on the two
calls to the PersistenceService in
the diagram. We will return to
this point in the next section,
where we will use it to illustrate
an important difference between
the EJB and COM+ architectures.
Applying the pattern. The
common solution the Enterprise
Component Framework pattern
provides for distributed component architectures can be
demonstrated by applying it to
model EJB and COM+ examples. We first apply it to an EJB example in Figure 4,
which shows a ShoppingCart component for an ebusiness application modeled as a UML subsystem.
The pattern being applied is shown as a dashed
ellipse in the lower right of the diagram, and the
classifiers to which the pattern roles are being
applied are shown above the pattern.
It is noteworthy that the names of several of the
classifiers in the collaboration are preceded by UML
keywords, which are marked by guillemet delimiters
(for example, EJBEntityClass). The keywords here
indicate that these classifiers are UML stereotypes
(that is, user-customized extensions to the language)
defined external to the model and not part of standard UML. These stereotypes highlight areas where
UML needs to be customized to meet the specific
needs of particular component architectures, such as
EJB or COM+. For example, Java and EJB interfaces are defined as stereotypes of the UML metaclass Class, since Java and EJB interfaces may declare
constants, whereas UML standard interfaces cannot.
The dashed lines between the pattern and the
classifiers are labeled with the roles that the classifiers play in the collaboration: client, context,
remoteProxy, factoryProxy, container, component,
and persistenceService. These roles are respectively
bound to the following EJB classifiers: ArtStoreClient, EJBContextObject ContextObject,
RemoteObject, HomeObject, ShoppingCart,
EJBEntityClass ShoppingCartImpl, and database ArtStoreDB.
In the EJB example, the subsystem calls the ArtStoreDB directly for persistence services (for example, database stores and retrievals), indicating that

Figure 5. Application of pattern to COM+.

ShoppingCart
Specification Elements

RealizationElements

COMInterface
IClassFactory
call
ArtStoreClient

call

call

FactoryWrapper

createinstance(...)
lockServer(...)
...

IClassFactory

COMInterface
IShoppingCart

call

getItemCount()
setItemCount(...)
getTotal()
setTotal(...)
...

COMClass
ShoppingCartimpl

IShoppingCart

ObjectWrapper

call
IObjectContext

COMContextObject
ContextObject

remoteProxy
context

client

persistenceService
container
component
factoryProxy

Enterprise Component Framework

pattern are shown by dashed lines that are labeled

with role names. For example, the roles client, proxy,
and original from the Proxy pattern shown in the
top left of the diagram are bound to the classifier
roles Client, FactoryProxy, and Component in the
main pattern. Likewise, the roles client, proxy, and
original from the Proxy, pattern shown in the lower
left of the diagram are bound to the classifier roles
Client, RemoteProxy, and Component in the main
pattern.
The FactoryProxy and RemoteProxy surrogates
perform distinctive roles in the pattern. The former
proxy handles object factory operations such as create and find, while the latter proxy handles business
operations specific to the Component (for example,
getItemCount, setTotal). The separation of concerns
between the proxies is consistent with UMLs classifier-instance dichotomy: the FactoryProxy facilitates
class methods, while the RemoteProxy facilitates
instance methods.
The Component and both proxy roles are held in
a component Container, where the containment is
shown by aggregation relationships (lines with
unfilled diamonds at the aggregation end) between
the Container and its contents. The Container represents the frameworks runtime environment,
which supports various distributed processing services, such as interprocess communication, security,
transactions, and persistence. The Container also
includes a Context entity for each Component that
maintains specific context information, such as the
states of transactions, persistence, security, and
deployment.
Persistence services for the Component (for
36

call

October 2000/Vol. 43, No. 10 COMMUNICATIONS OF THE ACM

database
ArtStoreDB

the container will manage this at runtime.

In order to facilitate comparison between the two
component architectures, the Enterprise Component Framework pattern is also applied to a COM+
example in Figure 5. As was the case when applying
the pattern to the EJB example, the pattern roles
map to classifiers in a straightforward manner.
Although this confirms that there are strong structural similarities between the two component architectures, we note the following differences:

ning on an application server node in a deployment

diagram. Similarly, the COMClass ShoppingCartImpl in Figure 5 might be implemented on a
COMObject component that executes in an
MTS Executive component running on an application server node in a deployment diagram.

Issues and Recommendations

Although the preceding examples show that the
UML 1.3 specification can effectively model many
aspects of components and frameworks, they have
Stereotypes usage. The different stereotypes used also identified some significant issues. In addition,
users and vendors have identified many other probin the two examples indicate areas where the two
architectures are likely to vary. Although an analy- lems as they apply standard UML and custom profiles to specify large and complex component
sis of these detailed differences is beyond the
applications. Some of these issues, along with recscope of this article, readers are encouraged to
ommendations to resolve them, are discussed here.
perform this comparison.
Increase clarity and reduce overlap. The current
Persistence services. Whereas in the case of EJB,
either the component or the container may coor- semantics for the component construct are vague and,
as pointed out previously, overlap the semantics of
dinate persistence services, in the case of COM+
related classifiers, such as class and subsystem. In
only the component can coordinate persistence
order to fully support component-based developservices. This is a significant architectural differment, the semantics of components should be refined
ence between the two frameworks.
and the overlap with related constructs should be
Alert readers will notice the UML component reduced.
Support components at an earlier phase of the
construct was not used to specify either application
of the framework pattern. This points out the rather software life cycle. The semantics for component
limited semantics and restricted use of the current are dated and emphasize implementation diagrams,
which typically occur at the tail end
of the modeling process. These
Component modeling semantics should be updated so that
modelers can specify components
earlier in the software life cycle (for
issues are being given
example, during design).
a high priority by both
Define model management constructs that support large compothe UML Revision Task
nent systems and frameworks. As
component applications grow and
Force and the
proliferate, so will the need for
UML 2.0 Working Group. abstractions to manage their size and
complexity. Consequently, UML
model management constructs
should be refined, extended, or augcomponent construct, which is mostly used in mented to support large component systems and
implementation model diagrams. Since the pattern frameworks. These constructs include, but are not
application examples are design models and not limited to, containers, frameworks, and subsystems.
implementation models, they do not show the use of
Clarify how components and interfaces are
the UML component construct.
wired. When combining components with various
However, in both cases it is relatively straightfor- entities that realize or implement interfaces (classes,
ward to generate implementation models that use implementation classes, and subsystems) it is not
the UML component construct. For example, the always clear how to connect them correctly, especially
EJBEntityClass ShoppingCartImpl in Figure 4 when they are heterogeneously nested. The specificamight be implemented on a EJBEntity component tion should include better guidelines and examples
that executes in an EJBContainer component run- for mixing and matching these constructs.
COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10

37

Provide standard UML profiles for specific

component technologies. Standard UML profiles
should be defined for specific component technologies, such as EJB, COM+, and CCM.
Component modeling issues are being given a
high priority by both the UML Revision Task Force
(UML RTF) and the UML 2.0 Working Group. The
UML RTF will make clarifications and corrections
within the scope of a minor revision in their recommendations for UML 1.4, which they expect to be
finalized and adopted later this year. Larger issues
that are outside the scope of a minor revision will be
deferred to the UML 2.0 Request for Proposals,
which is scheduled to be issued later this year.
Improvements to support the modeling of EJB components and frameworks may be further facilitated
by the informal liaison between the OMG UML
RTF and the Java Community Processes expert
group for the UML/EJB Mapping Specification [8].

in mind that component technology is still at the

beginning of its adoption curve. As it enters more
into mainstream business computing we can expect
it to have a dramatic impact on how we design, construct, and deploy software systems. We have every
reason to believe that UML will evolve along with
components to meet their special needs, and will not
be surprised if future modelers think of UML as a
component-based, rather than an object-oriented,
modeling language. c

References
1. Buschmann, F., et al. Pattern-Oriented Software Architecture: A System of
Patterns. Wiley, NY, 1996.
2. DSouza, D. and Wills, A.C. Objects, Components and Frameworks with
UML: The Catalysis Approach. Addison-Wesley, Reading, MA, 1999.
3. Eddon, G. and Eddon, H. Inside COM+ Base Services. Microsoft Press,
1999.
4. Enterprise Java Beans Specification, v. 2.0. Public draft, Sun Microsystems, May 2000.
5. Fayad, M., et al. Building Application Frameworks. Wiley, NY, 1999.
6. Gamma, E., et al. Design Patterns: Elements of Reusable Object-Oriented
Software. Addison-Wesley, Reading, MA, 1995.
7. Jacobson, I., et al. The Unified Software Development Process. AddisonWesley, Reading, MA, 1999.
8. UML/EJB Mapping Specification, Java Specification Request ID#
000026, Java Community Process, Sun Microsystems, July 1999.
9. UML Revision Task Force, OMG Unified Modeling Language Specification, v. 1.3, document ad/99-06-08. Object Management Group,
June 1999.

Conclusion and Future

The current UML 1.3 specification provides basic
support for modeling components and component
frameworks. Users can specify components in various ways, including those outlined by software
methods that support component-based development [2, 7]. In addition, tool vendors can customize
UML profiles that support the round-trip engineerCris Kobryn (ckobryn@acm.org) is the chief scientist and a
ing of EJB and COM+ components.
senior director at InLine Software (www.inline-software.com). He is
However, there are also substantive issues related the co-chair of the UML Revision Task Force and the co-chair of
to modeling components with the current UML 1.3 the Analysis and Design Platform Task Force at the OMG.
specification. These range from restrictive yet overto make digital or hard copies of all or part of this work for personal or classlapping semantics to the lack of robust model man- Permission
room use is granted without fee provided that copies are not made or distributed for
agement constructs and component technology profit or commercial advantage and that copies bear this notice and the full citation on
first page. To copy otherwise, to republish, to post on servers or to redistribute to
profiles. We hope the OMG UML Revision Task the
lists, requires prior specific permission and/or a fee.
Force and the UML 2.0 Working Group will address
these issues in an effective and timely manner.
As we await these improvements we should keep 2000 ACM 0002-0782/00/1000 $5.00

WEB REFERENCES
www.celigent.com/omg/umlrtf is the OMG UML Revision Task Force home page. Contains UML
specification artifacts, including the latest UML specification and drafts of works-in-progress. Also
includes a link to the UML 2.0 Working Group page.
java.sun.com/products/ejb/ is the Enterprise JavaBeans home page. Contains links to diverse
resources related to EJB, including specifications, white papers, and tutorials.
java.sun.com/aboutJava/communityprocess/ is the Java Community Process home page. Contains
information about the JCP process, specification proposals, calls for experts, and specification drafts.
www.microsoft.com/com/tech/complus.asp is the COM+ home page. Contains links to a wide range
of resources related to COM+, including white papers, presentations, and books.

38

October 2000/Vol. 43, No. 10 COMMUNICATIONS OF THE ACM