p31-kobryn

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

For more than a decade ven-dors have hyped and underdelivered the promises ofobject modeling and com-ponent technologies. As aresult, object modeling

tools are in disrepute in many devel-opment organizations, and thesemantics of the term “component-based” have been diluted to an extentreminiscent of what occurred to theexpression “object-oriented” in theprevious software generation.

However, if we put aside ourskepticism and evaluate recentadvances in these technologies, wefind encouraging signs that they arecatching up with some of theirhyperbole. Many object modelingtools can now generate production-quality skeleton code from structuralmodels, and some of them can alsoderive useful methods from behav-ioral models. While they still fall farshort of the ambitious goals of full“round-trip engineering,” theirimprovements mark significantprogress toward automating the soft-ware development process.

Likewise, the leading componentstandards have evolved from nascentdefinitions of simple architectures tomature specifications of completeruntime environments. For example,

Sun Microsystem’s JavaBeans defini-tion has developed into the Enter-prise JavaBeans (EJB) specification,which supports both transaction andpersistence services for enterpriseapplications [4]. Similarly, Microsoft’sCOM definition has evolved into theDCOM and COM+ specifications,and supports the Microsoft Transac-tion Server (MTS) for enterpriseapplications [3].

While analyzing the evolution ofthese technologies it is important tonote that strong synergies existbetween them. The coarse granularityof components in relation to classespromotes the modularity and reusegoals of object modeling. Conversely,the rigorous specification discipline ofobject modeling supports the inter-face-based design and replaceabilityaims of components. Consequently, itis not surprising that componentIntegrated Development Environ-ments (IDEs) are converging withvisual object modeling tools, a trendthat is likely to continue.

This article explores some of thesynergies between object modelingand components by examining howthe de facto object modeling lan-guage standard, the Unified Model-ing Language (UML), supports theleading enterprise component archi-

Modeling Componentsand Frameworks

with UML

� Cris

kobryn�

As localized

objects evolve

into distributed

components,

developers are

asking that UML

provide better

support for

component-based

development

using EJB and

COM+.

�F

tecture standards—EJB andCOM+/MTS (or COM+ forshort). It is presumed the readeris generally familiar with howUML is used to specify softwaresystems; the central focus here is UML component-modelingcapabilities.

Components in UML 1.3The current UML specification,UML 1.3, defines a componentas follows:

component: A physical,replaceable part of a system thatpackages implementation andprovides the realization of a setof interfaces. A component rep-resents a physical piece ofimplementation of a system,including software code(source, binary or executable)or equivalents such as scripts orcommand files [9].

It is important to note thatthis definition tends to berestrictive and emphasizes theuse of components for imple-mentation modeling (comparethis with analysis and designmodeling). This point will beaddressed later in this article.

The UML notation for com-ponents is summarized in Fig-ure 1. In this diagram aShoppingCart component foran e-business application isshown as a rectangle with twosmaller rectangles protrudingfrom its side. At the top of thediagram the component isshown with attributes, opera-tions, and the interfaces Calcu-late and ChangeOrder, which are drawn usinglonghand interface notation (rectangles that containan operations compartment). At the bottom of thediagram the component is shown in a more compactrepresentation where the attributes and operationsare elided and the interfaces are drawn using short-hand (“lollipop”) interface notation.

Although UML components may be shown inany structural modeling diagram, they are typically

found in implementation model diagrams, such ascomponent diagrams and deployment diagrams. Acomponent diagram shows the organization anddependencies of components, and a deploymentdiagram shows how component and class instancesare deployed on computational nodes. An exampleof a deployment diagram that uses components isshown in Figure 2.

The example shows a simple failover scenario for

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

Figure 1. Component and interface notation.

Calculate

Component and interface notations showing details

Component and interface notations hiding details

Shorthand("lollipop")notation forinterface

ChangeOrder

Longhandnotation forinterface showingoperations

Componentshowingattributes andoperations

Realize relationship

ShoppingCart

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

+calcWeight()+calcShipping()...+addItem(item:OrderItem)+deleteItem()...

«interface»Calculate

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

«interface»ChangeOrder

+Weight+Shipping... +orderItems...

ShoppingCart

Figure 2. Deployment diagram example.

backupServer:appServer

«call»

«copy»«copy» «copy»

«become»

«become»

«call»

«database»

A computationalnode, in this casean applicationserver

In a failoverscenario, the backupBrokerbecomes theprimaryBrokerand vice versa

Indicatesreplication

backupBroker:StockBroker

backupDB:AccountsDB

primaryServer:appServer

«call»«call»

«database»

primaryQuoter:QuoteService

primaryBroker:StockBroker

PrimaryDB:AccountsDB

backupQuoter:QuoteService

an online stockbroker system, where several compo-nents deployed on an instance of the primary appli-cation server node (primaryServer) are replicated onthe backup application server node (backupServer).On the primaryServer the primaryBroker, an instanceof the component StockBroker, calls the interfaces ofthe primaryQuoter (an instance of the QuoteServicecomponent) and the primaryDB (an instance of theAccountsDB component). Component replicationand migration are shown by «copy» and «become»dependency flows, which are part of standard UML.

Semantic Overlap: Components, Classes,and SubsystemsThe fact that UML is a general-purpose modelinglanguage is both a strength and a weakness. Althoughsoftware developers find they can use UML to modelmost software problems in a variety of ways, they arefrequently overwhelmed by their options. The prob-lem is exacerbated by the dearth of pragmatic exam-ples and the lack of tools that support advancedconstructs. Many of the examples in UML modelingbooks tend to be trivial or academic, and frequentlydo not address the practical problems faced by devel-opers. As for modeling tools, the author knows of nonethat fully implements the UML 1.1 semantics andnotation (adopted three years ago), let alone one thatcompletely or correctly implements the current UML1.3 specification (which was adopted a year ago).

Consequently, many modelers find the modelingof components, which is sometimes considered an

advanced UML modeling topic,problematic. One of the mostcommon problems modelersencounter is the semantic overlapbetween components and relatedclassifiers, such as classes and sub-systems, which are defined as fol-lows:

class: A description of a set ofobjects that share the sameattributes, operations, methods,relationships, and semantics. Aclass may use a set of interfacesto specify collections of opera-tions it provides to its environ-ment [9].subsystem: A grouping of modelelements that represents a behav-ioral unit in a physical system. Asubsystem offers interfaces andhas operations. In addition, themodel elements of a subsystem

can be partitioned into specification and realizationelements [9].

The semantics of components, subsystems, andclasses are compared in Table 1. The table shows thatall three classifiers can have operations and inter-faces, may be associated with other classifiers, can benested, and may create instances. Components aresimilar to subsystems and differ from classes in thatthey cannot have threads of control and they repre-sent units in physical systems. Components differfrom subsystems and classes because they are not agrouping construct; they alone can contain theimplementation of model elements, and theirinstances typically reside on computational nodes.Only subsystems can import or access other modelelements.

It is important to note that, while all three classi-fiers may conform to a set of interfaces, interfaces areusually most closely associated with components.Although it is relatively common to see a class with-out an interface during analysis, and subsystems mayuse model elements other than interfaces for specifi-cation (for example, use cases and statecharts), acomponent without an interface may be technicallywell-formed but suspect. This reflects the longstand-ing and intimate relationship between component-based development and interface-based design. For example, both COM+ and the CORBA Com-ponent Model (CCM) are closely associated withInterface Definition Languages (IDLs). In addition,


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?

+

+

–

+

+

+

–

+

–

–

+

+

+

+

+

+

–

–

+

+

–

+

+

+

+

–

+ (optional)

–

+

+

+

+

+

+

+

+

+

–

–

–

+

–

COMPONENT SUBSYSTEM CLASS

Table 1. Semantic comparison of components, subsystem, and classes.

both the Java and EJB specifi-cations emphasize interface-based design.

When choosing among theserelated classifiers modelers mayalso find it useful to considersome usage heuristics. Althoughthe UML is a modeling lan-guage and not a softwaremethod, the specification doesprovide some usage notesregarding how some constructscan be used during variousphases in the software life cycle.Other heuristics may be gleanedfrom component methods, spec-ifications, and applications.With the caveat that these arebasic guidelines and not rules,Table 2 summarizes someheuristics for applying the classi-fiers in question.

In general, components andsubsystems tend to be morecoarse-grained than classes.Indeed, it is common for a com-ponent to implement multipledesign classes. Similarly, it istypical for a subsystem to modelthe specification and realizationof a set of model elements,which may include both specifi-cation types and implementa-tion classes. Components arefurther distinguished from both subsystems andclasses in that they are typically modeled during theimplementation phase (compare analysis and designphases). It is important to note, however, that theclasses and/or subsystems specifying componentsand frameworks may be modeled during an earlierlife-cycle phase, such as analysis or design.

Modeling Component FrameworksComponents are quintessential software buildingblocks that can be recursively composed to build sys-tems of increasing size and complexity. Just as thehardware industry has used integrated circuits torecursively build larger and more complex hardwarecomponents, the software industry now endeavorsto do something similar with software components.Component frameworks are important mechanismsbeing used to accomplish this.

A framework is a generic term for a powerfulobject-oriented reuse technique that typically

emphasizes the reuse of design patterns and archi-tectures. One common definition is that “a frame-work is a reusable design of all or part of a systemrepresented by a set of abstract classes and the waytheir instances interact.” Another frequently useddefinition is that “a framework is the skeleton of anapplication that can be customized by an applica-tion developer” [5]. These definitions are comple-mentary, not conflicting, since the former describesa framework from a design perspective, whereas thelatter describes it from a functional viewpoint.However, the differences between the two defini-tions point out the variety of ways in which theterm is used.

Although the UML definition of a framework ismore restrictive than the preceding definitions, it iscompatible with them:

framework: 1) A stereotyped package consistingmostly of patterns. 2) An architectural pattern that


Tend to be coarse-

grained?

Typically modeled

during analysis?

Typically modeled

during design?

Typical modeled

during implementation?

+

–

–

+

+

+

+

–

–

+

+

+

COMPONENT SUBSYSTEM CLASS

Table 2. Usage heuristics for components, subsystem, and classes.

Figure 3. Enterprise component framework pattern.

Enterprise Component Framework

Client

RemoteProxy

FactoryProxy

Context

PersistenceService

Container

Component

«call» «call»

«call»Remote

original

original

Remote

Factory

Factory

«call»

«call»{xor}

«call»

«call»

client

client

proxy

proxy

Either the Containeror the Componentmanages thePersistenceService

The Proxy pattern used here is defined in [1]. Note that the pattern is usedtwice.

Proxy

Proxy

provides an extensible template for applicationswithin a specific domain.

The first definition is less than illuminating, sinceit explains the concept in terms of the UML con-struct (the «framework» stereotype of Package) withsparse additional semantics. The second definition ismore informative and reinforces the associationsbetween frameworks, patterns, and architectures.

As one might intuit, component frameworks areframeworks typically designed, constructed, andextended using components. Since a comprehen-sive discussion of component frameworks isbeyond the scope of this article, readers are referredto [5] for more information about them. Theremainder of this section focuses on two compo-nent frameworks that are industry standards forbuilding enterprise applications: Enterprise Java-Beans and COM+.

Defining a common pattern. The architecturesof Enterprise JavaBeans and COM+ are based on acommon architectural pattern that we call the Enter-prise Component Framework. The purpose of thispattern is to describe the basic mechanisms for acomponent runtime environment that supports dis-tributed services for interprocess communication,transactions, and persistence.

For the purposes of this article a pattern is definedas a common solution to a recurring problem in aparticular context. UML 1.3 prescribes that thestructure of patterns should be modeled using para-meterized collaborations, but does not prescribe themodeling of non-structural aspects, such as behavior

and heuristics for apply-ing patterns. As was thecase for the frameworkconcept, there are diverseopinions regarding thedefinition and use of pat-terns. In consideration ofthis and the scope of thisarticle, we will restrict ourmodeling of patterns toUML parameterized col-laborations.

The structure of theEnterprise ComponentFramework pattern ismodeled as a parameter-ized collaboration in Figure 3, where the col-laboration is shown as adashed ellipse. This pat-tern contains seven classi-

fier roles that participate in the collaboration, whichare depicted as rectangles: Client, FactoryProxy,RemoteProxy, Context, Component, Container, andPersistenceService. The Client represents an entitythat requests a service from a Component in theframework.

An important aspect of this pattern is that theClient does not call the Component directly. Ratherit communicates indirectly via a pair of proxy roles(FactoryProxy and RemoteProxy) that delegate(relay) calls from the Client to the Component. Thislevel of indirection supports two important functions:

• Location transparency: At a lower level ofabstraction the proxies may be realized by stub-skeleton pairs, such as those used by CORBA,Java RMI, and COM+.

• Message interception: The use of proxies allowsthe component’s runtime environment (the Con-tainer) to intercept method calls and insert ser-vices based on a set of attributes defined atdeployment time.

The roles of FactoryProxy and the RemoteProxyas surrogates are made explicit by the use of twoProxy sub-patterns in the main pattern. These sub-patterns are shown as dashed ellipses, but their clas-sifier roles are elided to reduce distracting detail.Readers interested in details about the structure andbehavior of the Proxy pattern are referred to [1] and[6]. The bindings of the roles of the Proxy patterndescribed in [1] to their counterparts in the main


Figure 4. Application of pattern to EJB.

ArtStoreClient

HomeObject

ShoppingCart

RemoteObject

«EJBContextObject»ContextObject

«EJBEntityClass»ShoppingCartimpl

javax.ejb.EntityContext

«call» «call»

«database»ArtStore«call»

ShoppingCartHome

ShoppingCart

«call»

context

client

remoteProxy

factoryProxy

container

component

persistenceService

«call»

Specification Elements RealizationElements

Indicates aSubsystem

In the case of EJBeither the Bean orContainer canmanage persistence


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

«EJBHomeInterface»ShoppingCartHome

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

«EJBRemoteInterface»ShoppingCart

Collaboration representing thepattern structure

pattern are shown by dashed lines that are labeledwith role names. For example, the roles client, proxy,and original from the Proxy pattern shown in thetop left of the diagram are bound to the classifierroles Client, FactoryProxy, and Component in themain pattern. Likewise, the roles client, proxy, andoriginal from the Proxy, pattern shown in the lowerleft of the diagram are bound to the classifier rolesClient, RemoteProxy, and Component in the mainpattern.

The FactoryProxy and RemoteProxy surrogatesperform distinctive roles in the pattern. The formerproxy handles object factory operations such as cre-ate and find, while the latter proxy handles businessoperations specific to the Component (for example,getItemCount, setTotal). The separation of concernsbetween the proxies is consistent with UML’s classi-fier-instance dichotomy: the FactoryProxy facilitatesclass methods, while the RemoteProxy facilitatesinstance methods.

The Component and both proxy roles are held ina component Container, where the containment isshown by aggregation relationships (lines withunfilled diamonds at the aggregation end) betweenthe Container and its contents. The Container rep-resents the framework’s runtime environment,which supports various distributed processing ser-vices, such as interprocess communication, security,transactions, and persistence. The Container alsoincludes a Context entity for each Component thatmaintains specific context information, such as thestates of transactions, persistence, security, anddeployment.

Persistence services for the Component (for

example, database storage andretrieval) can be coordinateddirectly by the Component orcan be delegated to the Con-tainer. This choice is shown bythe {xor} constraint on the twocalls to the PersistenceService inthe diagram. We will return tothis point in the next section,where we will use it to illustratean important difference betweenthe EJB and COM+ architec-tures.

Applying the pattern. Thecommon solution the EnterpriseComponent Framework patternprovides for distributed compo-nent architectures can bedemonstrated by applying it tomodel EJB and COM+ exam-

ples. We first apply it to an EJB example in Figure 4,which shows a ShoppingCart component for an e-business application modeled as a UML subsystem.The pattern being applied is shown as a dashedellipse in the lower right of the diagram, and theclassifiers to which the pattern roles are beingapplied are shown above the pattern.

It is noteworthy that the names of several of theclassifiers in the collaboration are preceded by UMLkeywords, which are marked by guillemet delimiters(for example, «EJBEntityClass»). The keywords hereindicate that these classifiers are UML stereotypes(that is, user-customized extensions to the language)defined external to the model and not part of stan-dard UML. These stereotypes highlight areas whereUML needs to be customized to meet the specificneeds of particular component architectures, such asEJB or COM+. For example, Java and EJB inter-faces are defined as stereotypes of the UML meta-class Class, since Java and EJB interfaces may declareconstants, whereas UML standard interfaces cannot.

The dashed lines between the pattern and theclassifiers are labeled with the roles that the classi-fiers play in the collaboration: client, context,remoteProxy, factoryProxy, container, component,and persistenceService. These roles are respectivelybound to the following EJB classifiers: ArtStore-Client, «EJBContextObject» ContextObject, RemoteObject, HomeObject, ShoppingCart,«EJBEntityClass» ShoppingCartImpl, and «data-base» ArtStoreDB.

In the EJB example, the subsystem calls the Art-StoreDB directly for persistence services (for exam-ple, database stores and retrievals), indicating that


Figure 5. Application of pattern to COM+.

ArtStoreClient

FactoryWrapper

ShoppingCart

ObjectWrapper

«COMContextObject»ContextObject

«COMClass»ShoppingCartimpl

IObjectContext

«call» «call»

«call» «database»ArtStoreDB

«call»

IClassFactory

IShoppingCart

«call»

context

client

remoteProxy

factoryProxy

containercomponent

persistenceService

«call»

«COMInterface»IClassFactory

«COMInterface»IShoppingCart

Specification Elements RealizationElements

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

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


the container will manage this at runtime.In order to facilitate comparison between the two

component architectures, the Enterprise Compo-nent Framework pattern is also applied to a COM+example in Figure 5. As was the case when applyingthe pattern to the EJB example, the pattern rolesmap to classifiers in a straightforward manner.Although this confirms that there are strong struc-tural similarities between the two component archi-tectures, we note the following differences:

• Stereotypes usage. The different stereotypes usedin the two examples indicate areas where the twoarchitectures are likely to vary. Although an analy-sis of these detailed differences is beyond thescope of this article, readers are encouraged toperform this comparison.

• Persistence services. Whereas in the case of EJB,either the component or the container may coor-dinate persistence services, in the case of COM+only the component can coordinate persistenceservices. This is a significant architectural differ-ence between the two frameworks.

Alert readers will notice the UML componentconstruct was not used to specify either applicationof the framework pattern. This points out the ratherlimited semantics and restricted use of the current

component construct, which is mostly used inimplementation model diagrams. Since the patternapplication examples are design models and notimplementation models, they do not show the use ofthe UML component construct.

However, in both cases it is relatively straightfor-ward to generate implementation models that usethe UML component construct. For example, the«EJBEntityClass» ShoppingCartImpl in Figure 4might be implemented on a «EJBEntity» componentthat executes in an «EJBContainer» component run-

ning on an application server node in a deploymentdiagram. Similarly, the «COMClass» Shopping-CartImpl in Figure 5 might be implemented on a«COMObject» component that executes in an«MTS Executive» component running on an appli-cation server node in a deployment diagram.

Issues and RecommendationsAlthough the preceding examples show that theUML 1.3 specification can effectively model manyaspects of components and frameworks, they havealso identified some significant issues. In addition,users and vendors have identified many other prob-lems as they apply standard UML and custom pro-files to specify large and complex componentapplications. Some of these issues, along with rec-ommendations to resolve them, are discussed here.

Increase clarity and reduce overlap. The currentsemantics for the component construct are vague and,as pointed out previously, overlap the semantics ofrelated classifiers, such as class and subsystem. Inorder to fully support component-based develop-ment, the semantics of components should be refinedand the overlap with related constructs should bereduced.

Support components at an earlier phase of thesoftware life cycle. The semantics for componentare dated and emphasize implementation diagrams,

which typically occur at the tail endof the modeling process. Thesesemantics should be updated so thatmodelers can specify componentsearlier in the software life cycle (forexample, during design).

Define model management con-structs that support large compo-nent systems and frameworks. Ascomponent applications grow andproliferate, so will the need forabstractions to manage their size andcomplexity. Consequently, UMLmodel management constructsshould be refined, extended, or aug-

mented to support large component systems andframeworks. These constructs include, but are notlimited to, containers, frameworks, and subsystems.

Clarify how components and interfaces are“wired.” When combining components with variousentities that realize or implement interfaces (classes,implementation classes, and subsystems) it is notalways clear how to connect them correctly, especiallywhen they are heterogeneously nested. The specifica-tion should include better guidelines and examplesfor mixing and matching these constructs.


Component modeling

issues are being given

a high priority by both

the UML Revision Task

Force and the

UML 2.0 Working Group.

Provide standard UML profiles for specificcomponent technologies. Standard UML profilesshould be defined for specific component technolo-gies, such as EJB, COM+, and CCM.

Component modeling issues are being given ahigh priority by both the UML Revision Task Force(UML RTF) and the UML 2.0 Working Group. TheUML RTF will make clarifications and correctionswithin the scope of a minor revision in their recom-mendations for UML 1.4, which they expect to befinalized and adopted later this year. Larger issuesthat are outside the scope of a minor revision will bedeferred to the UML 2.0 Request for Proposals,which is scheduled to be issued later this year.Improvements to support the modeling of EJB com-ponents and frameworks may be further facilitatedby the informal liaison between the OMG UMLRTF and the Java Community Processes expertgroup for the UML/EJB Mapping Specification [8].

Conclusion and FutureThe current UML 1.3 specification provides basicsupport for modeling components and componentframeworks. Users can specify components in vari-ous ways, including those outlined by softwaremethods that support component-based develop-ment [2, 7]. In addition, tool vendors can customizeUML profiles that support the round-trip engineer-ing of EJB and COM+ components.

However, there are also substantive issues relatedto modeling components with the current UML 1.3specification. These range from restrictive yet over-lapping semantics to the lack of robust model man-agement constructs and component technologyprofiles. We hope the OMG UML Revision TaskForce and the UML 2.0 Working Group will addressthese issues in an effective and timely manner.

As we await these improvements we should keep

in mind that component technology is still at thebeginning of its adoption curve. As it enters moreinto mainstream business computing we can expectit to have a dramatic impact on how we design, con-struct, and deploy software systems. We have everyreason to believe that UML will evolve along withcomponents to meet their special needs, and will notbe surprised if future modelers think of UML as acomponent-based, rather than an object-oriented,modeling language.

References1. Buschmann, F., et al. Pattern-Oriented Software Architecture: A System of

Patterns. Wiley, NY, 1996.2. D’Souza, 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 Microsys-

tems, 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. Addison-

Wesley, 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 Specifi-

cation, v. 1.3, document ad/99-06-08. Object Management Group,June 1999.

Cris Kobryn ([email protected]) is the chief scientist and asenior director at InLine Software (www.inline-software.com). He isthe co-chair of the UML Revision Task Force and the co-chair ofthe Analysis and Design Platform Task Force at the OMG.

Permission to make digital or hard copies of all or part of this work for personal or class-room use is granted without fee provided that copies are not made or distributed forprofit or commercial advantage and that copies bear this notice and the full citation onthe first page. To copy otherwise, to republish, to post on servers or to redistribute tolists, requires prior specific permission and/or a fee.

© 2000 ACM 0002-0782/00/1000 $5.00

c


W E B R E F E R E N C E S

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. Alsoincludes a link to the UML 2.0 Working Group page.

java.sun.com/products/ejb/ is the Enterprise JavaBeans home page. Contains links to diverseresources related to EJB, including specifications, white papers, and tutorials.

java.sun.com/aboutJava/communityprocess/ is the Java Community Process home page. Containsinformation 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 rangeof resources related to COM+, including white papers, presentations, and books.

p31-kobryn

Documents