COCO: COMPOSITION MODEL AND COMPOSITION MODEL

IMPLEMENTATION

Naiyana Tansalarak and Kajal T. Claypool

University of Massachusetts - Lowell

1 University Ave. Lowell, MA 01854

Keywords:

Component model, Component Model Implementation, Composition Model, Composition Model Implemen-

tation, Composition Style, Composition Script, Composition Operator, Unifying Component Model.

Abstract:

The success of component-based development has been impeded by interoperability concerns, including com-

ponent model, semantic, syntactic, design and platform incompatibilities, that often come into play when

composing two or more independently developed components. In this paper we propose a CoCo composition

model that elevates compositions to ﬁrst class citizenship status. The model deﬁnes a standard for describ-

ing the composition of components transparent to any underlying incompatibilities between the collaborating

components. We also present a CoCo composition model implementation that provides the required support

to describe and subsequently execute the composition to produce an executable application. We advocate the

use of XML Schemas as a mechanism to support this composition model. To support the composition model

implementation we provide (1) a taxonomy of primitive composition operators to describe the connection

between components; (2) XML documents as a description language for the compositions; and (3) the de-

velopment of a set of deployment plugins that address any incompatibilities and enable the generation of the

model-speciﬁc and platform-speciﬁc applications.

1 INTRODUCTION

Component-based software engineering attempts to

address the ever increasing demand for new software

applications by enabling a compositional approach to

software construction in which applications are built

from pre-fabricated components, rather than devel-

oped from scratch (Heineman and Councill, 2001).

A number of component models (with correspond-

ing implementations) have been deﬁned to date and

many have been widely adopted in practice. Ex-

amples of component models are CORBA (Siegel,

1996), JavaBeans (Muller and Davidson, 1996), En-

terprise JavaBeans (Roth, 1998), COM (Box, 1998),

and .NET (Chappell, 2002). These different compo-

nent models have stimulated the rapid development

of components by different developers, with the hope

that eventually most components needed for applica-

tion building will be available as off-the-shelf compo-

nents.

However, the success of component-based devel-

opment has been impeded by interoperability con-

cerns that often come into play when composing

two or more independently developed components

(Gschwind et al., 2002; Vallecillo et al., 2000; Yaki-

movich et al., ). These concerns encompass compo-

nent model incompatibilities that occur when the to-

be composed components are developed based on the

requirements of disparate component models; syntac-

tic incompatibilities that arise when there are signa-

ture or interface mismatches between the to-be com-

posed components; semantic incompatibilities that

typically occur when the behavior expected by one

component (the client component) as speciﬁed by the

“design by contract” principle is incompatible with

the behavior provided by the other (server) compo-

nent; design incompatibilities that occur when there

is an architectural or a design level mismatch between

the to-be composed components; and lastly platform

incompatibilities that come into play when a compo-

nent is constructed on one platform but the execu-

tion infrastructure supports a different platform. Inter-

operability and hence composability of two or more

components may be restricted by one or more of these

incompatibilities, requiring in some cases glue code

to enable the collaborative operation of two compo-

nents, while in other cases completely occluding the

inter-operation of the given components.

340

Tansalarak N. and T. Claypool K. (2005).

COCO: COMPOSITION MODEL AND COMPOSITION MODEL IMPLEMENTATION.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 340-345

DOI: 10.5220/0002525503400345

 SciTePress

Prior research (Raje et al., 2001; Oberleitner et al.,

2003; America, 1990; Garlan et al., 2000; Shaw et al.,

1995; Allen and Garlan, 1997) focusing on interoper-

ability of components has investigated possible solu-

tions to these incompatibilities singularly, rather than

as a complete set of concerns that must be addressed

to provide comprehensive support for the composi-

tion of components. We propose a CoCo composi-

tion model that elevates compositions to ﬁrst class cit-

izenship status and deﬁnes the standard for describ-

ing the composition of components transparent to any

underlying incompatibilities between the collaborat-

ing components. Figure 1 shows a high level view

of the composition model that classiﬁes information

into three primary categories: (i) an object model -

that deﬁnes the selection, instantiation, conﬁguration

and initialization of a set of underlying components

in the system; (ii) an interface model - that deﬁnes

the interface of a resultant composite component (or

application) to enable the resultant composite compo-

nent (or application) itself to interact with the other

components (or applications); and (iii) an association

model - that deﬁnes how components are composed

via both connection-oriented and aggregation-based

compositions. Details on the composition model can

be found in (Tansalarak and Claypool, 2004).

Composition Model

Interface ModelObject Model Association Model

Figure 1: The Composition Model

In this paper, we focus on the CoCo composition

model implementation that provides the required sup-

port to describe and subsequently execute the compo-

sition to produce a composed application. To support

the CoCo composition model implementation we pro-

vide (1) a taxonomy of primitive composition opera-

tors to describe the connection between components;

(2) XML documents as a description language for the

compositions; and (3) a set of deployment plugins that

address any incompatibilities and enable the genera-

tion of the composed application (or composite com-

ponent) in different languages and component models

as well as on different platforms. We exploit the in-

herent tight coupling between an XML Schema and

an XML document to provide the same coupling be-

tween the composition model (expressed as an XML

Schema) and the composition model implementation

enabling us to validate and check the conformance

of a composition against the composition model (or

a core subset of it).

Roadmap: The rest of paper is organized as fol-

lows. Based on the GUI composition style, Section 2

presents the set of primitive composition operators,

while Section 3 illustrates the description of compo-

sitions using an example. To complete the CoCo com-

position model implementation we show in Section 4

the generation of deployable applications based on the

described compositions. We conclude in Section 5.

2 PRIMITIVE COMPOSITION

OPERATORS

In literature (Garlan et al., 2000; Allen and Garlan,

1997; Shaw et al., 1995; Achermann, 2002; Acher-

mann et al., 2001) connectors have played an essen-

tial role in mediating interactions between the under-

lying components of the system. Additionally we be-

lieve that to provide comprehensive support for com-

ponent compositions, an order concept that provides

a sequencing of component interactions is essential.

Based on these, we now introduce a set of compo-

sition operators as the core construct of CoCo com-

position model implementation. These composition

operators represent the building blocks that can be

used in the instantiations of the composition model,

and on the basis of which arbitrarily complex compo-

nent compositions can be deﬁned. In this section, we

describe the set of primitive method composition op-

erators as well as the set of primitive event and con-

tainer composition operators that are at the heart of

the CoCo composition model implementation.

2.1 Method Composition Operators

Butler et al. (Butler and Duke, 1998) have deﬁned a

set of operators for combining object interactions at

the granularity of a method. Given that most com-

ponent compositions are also accomplished at the

method level, we now deﬁne a set of method com-

position operators to enable composition of methods

from one or more components. This set of method

composition operators consists of:

• The conjunction operator, represented as m

∧ m

denotes the execution of the two methods m

and m

simultaneously.

• The sequence operator, represented as m

; m

, de-

notes the execution of the two methods m

and m

in sequence.

• The choice operator, represented as m

∨ m

, de-

notes the execution of either the method m

or the

method m

, but not both.

• The pipe operator, represented as m

| m

, denotes

the execution of the two methods m

and m

in se-

quence wherein the output of the method m

is the

input of the method m

COCO: COMPOSITION MODEL AND COMPOSITION MODEL IMPLEMENTATION

341

• The loop event operator, represented as m

∗

, denotes

the repeated consecutive execution of the method

2.2 Event Composition Operators

In GUI composition style, the ﬁring of an event from

an event component may trigger interaction(s) from

one or more listener component(s) at the granularity

of method. We thus deﬁne an event composition oper-

ator, denoted as e m, to represent the relationship

between an event e and a set of method interaction(s)

m. m thus represents either a simply method invoca-

tion of a listener component, m

, or the composition of

method invocations from a set of listener components

as deﬁned in Section 2.1, { m

∧ m

, m

; m

, m

∨ m

| m

, and m

∗

2.3 Container Composition

Operators

We now deﬁne a set of container composition oper-

ators to facilitate the aggregation and display of the

underlying components. This set of container compo-

sition operators consist of:

• The position container operator, represented as c

≪ c

, speciﬁes that the component instance c

positioned within the component instance c

at a

default location chosen by the layout manager of

the component instance c

. For example, the com-

ponent BorderLayout provides the default lo-

cations to position its underlying components from

left to right and then from top to bottom.

• The position-at container operator, represented as

≪ c

@ location, speciﬁes that the compo-

nent instance c

be positioned within the compo-

nent instance c

at the speciﬁed location. The

location must conform to the layout manage-

ment deﬁned in the component instance c

. For ex-

ample, the component BorderLayout provides

ﬁve locations to position its underlying compo-

nents: North, South, West, East, and Center.

3 A COMPOSITION SCRIPT

EXAMPLE

The eventual goal of a CoCo composition model

implementation is to enable component-based con-

struction of a composite component or an application

based on a speciﬁed composition model. While the

composition operators presented in Section 2 provide

the semantics for combining individual methods, they

cannot singularly express complete compositions. We

now introduce composition scripts, that provide the

necessary glue logic to tie these operators together

and to comprehensively describe a composition, us-

ing XML documents.

In this section, we illustrate how an XML-based

composition script can be used to describe the com-

position of an application. Figure 2 pictorially

represents the SpeedLogo application. The Speed-

Logo application is composed from two compo-

nents Logo and SliderFieldPanel. The com-

ponent Logo is a primitive component while the

component SliderFieldPanel is mainly con-

structed from two primitive components JSlider

and JTextField. When the JSlider value

changes, the JTextField value is automatically

updated with the new value. On the other hand,

when a new value is entered in the JTextField

and the user presses the Enter key, the JSlider

is automatically repositioned to the appropriate lo-

cation. Overall in the SpeedLogo application, when

the SliderFieldPanel value changes, the ani-

mation speed of Logo is changed. The two compo-

nents Logo and SliderFieldPanel are aggre-

gated into the component JFrame at Center and

South locations, respectively.

Figure 2: The SpeedLogo Application

The partial composition script depicting the seman-

tics and the layout for the construction of the Speed-

Logo is shown in Figure 3. This script, that conforms

to the GUI composition model (Tansalarak and Clay-

pool, 2004), incorporates the composition operators

deﬁned in Section 2. For example, on line 072 the

<op type = “|”> is used to ensure that the output

returned from the method getCurrentValue of

the component instance sliderField is the input

of the method setAnimationRate of the compo-

nent instance logo.

The overall architecture of the SpeedLogo applica-

tion (Figure 4) can be efﬁciently and effectively ex-

tracted from the composition script shown in Figure 3.

Here, a box denotes a component instance as well as

the component library that instantiates the component

instance, an arrowed line the connection-oriented

ICEIS 2005 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

342

composition, a double-arrowed line the aggregation-

based composition, a dash line the hierarchical struc-

ture, a rectangle the property, and oval the event.

000. <?xml version=”1.0”?>

001. <GUIscript>

002. <application>

003. <name >SpeedLogo</name>

004. <compInstances>

.....

033. <compInstance role=”Client”>

034. <comp>javax.composite.SliderFieldPanel

</comp>

035. <cid>sliderField</cid>

036. <conﬁguration>

037. <conﬁgProperty>

038. <pName>currentValue</pName>

039. <pValue>

040. <const>10</const>

041. </pValue>

042. </conﬁgProperty>

.....

053. <compositions>

054. <eCompositions>

055. <eComposition>

.....

061. <eCompInstances>

062. <eCompInstance>

063. <rid>sliderField</rid>

064. <event>PropertyChange</event>

065. <eAction>propertyChange</eAction>

066. </eCompInstance>

067. </eCompInstances>

068. <lCompositions>

069. <lCompInstance>

070. <rid>sliderField</rid>

071. <callMethod>getCurrentValue

</callMethod>

072. <op type=”|” />

073. </lCompInstance>

074. <lCompInstance>

075. <rid>logo</rid>

076. <callMethod>setAnimationRate

</callMethod>

077. </lCompInstance>

078. </lCompositions>

.....

099. </application>

100. </GUIscript>

Figure 3: The Partial SpeedLogo Composition Script

4 DEPLOYMENT

The last step of the composition step process is the

conversion of the script to a deployable application

or component that conforms to the desired platform,

model, and language. We present a set of manipula-

tion operators that provide an intermediate unifying

frame << sliderField @ South

frame << logo @ Center

sliderField.propertyChange ~>

( sliderField.getCurrentValue |

logo.setAnimationRate )

javax.swing.JFrame

frame

java.composite.SliderFieldPanel

sliderField

java.animation.Logo

logo

currentValue

propertyChange

javax.swing.Jslider

slider

javax.swing.JTextField

field

javax.awt.BoxContainer

box

javax.swing.JPanel

panel

maximumValue

minimumValue

preferredSize

fieldWidth

minimumSize

box << slider

box << field

panel << box

slider.stateChange ~>

( slider.getValue |

(field.setText /\ this.setCurrentValue) )

field.actionPerformed ~>

( field.getText I (slider.setValue /\

this.setCurrentValue) )

Figure 4: The Overall Architecture of the SpeedLogo Ap-

plication

format between the XML-based composition scripts

and the ﬁnal application written in the programming

language of choice. These unifying manipulation op-

erators together with speciﬁc code generation plugins

provide the instrument for managing language, com-

ponent model and platform incompatibilities. Addi-

tional glue logic can be provided to support handling

of syntactic incompatibilities as part of the deploy-

ment process. We do not currently address semantic

and design incompatibilities at deployment time.

Internal

Transformation

Code

Generation

Deployment Process

Component

Models

Programming

Language

constructs

Manipulation

operators

Composition

Script

C++ /

Java

A sequence of

manipulation

operators

Figure 5: The Deployment Process

Figure 5 pictorially depicts the deployment

process, consisting of two essential modules: internal

transformation and language transformation mod-

ules. The internal transformation module provides

the mapping of the composition script to a sequence

of corresponding manipulation operators. We deﬁne

six primitive manipulation operators (Tansalarak and

Claypool, 2004), namely AA - to add an attribute, AM

- to add a method, IM - to invoke a method, IN - to

instantiate an attribute, ET - to extend a composition,

and CC - to create an inner class. Figure 6 gives the

manipulation operator equivalent of the SpeedLogo

composition script given in Figure 3. Consider as an

COCO: COMPOSITION MODEL AND COMPOSITION MODEL IMPLEMENTATION

343

example the composition fragment from lines 033

to 044. This fragment speciﬁes the instantiation of

the SliderFieldPanel and the conﬁguration

of its property currentValue. This is translated

into the following operators: IN ("sliderField",

"java.composite.SliderFieldPanel") and

IM ("sliderField", "setCurrentValue",

"void", <"10">).

ET (”javax.swing.JFrame”);

IM (”this”, ”setTitle”, ”void”, <”SpeedLogo Animation”>);

AA (”container”, ”private”, ”java.awt.Container”, ”1”, ”null”, ”local”);

IM (”this”, ”getContentPane”, ”container”, <>);

AA (”border”, ”private”, ”java.awt.BorderLayout”, ”1”, ”null”, ”local”);

IN (”border”, ”java.awt.BorderLayout”);

IM (”container”, ”setLayout”, ”void”, <”border”>);

AA (”color”, ”private”, ”java.awt.Color”, ”1”, ”null”, ”local”);

IN (”color”. ”java.awt.Color”, <”0xeeeeee”>);

IM (”this”, ”setBackground”, ”void”, <”color”>);

AA (”sliderField”, ”private”, ”java.composite.SliderFieldPanel”, ”1”,

”null”, ”global”);

IN (”sliderField”, ”java.composite.SliderFieldPanel”);

IM (”sliderField”, ”setCurrentValue”, ”void”, <”10”>);

AA (”logo”, ”private”, ”java.animation.Logo”, ”1”, ”null”, ”global”);

IN (”logo”, ”java.animation.Logo”);

IM (”logo”, ”startAnimation”, ”void”, <>);

IM (”sliderField”, ”addPropertyChangeListener”, ”void”,

<”new sliderField

PropertyChange()”>);

CC (”sliderField

PropertyChange”, ”java.beans.PropertyChangeListener”,

<>,

< AM (”propertyChange”, ”public”, ”void”,

<”java.beans.PropertyChangeEvent e”>, ”null”, ”null”,

{ AA (”value”, ”private”, ”int”, ”1”, ”null”, ”local”);

IM (”sliderFieldPanel”, ”getCurrentValue”, ”value”, <>);

IM (”logo”, ”setAnimationRate”, ”void”, <”value”>) ; }

>);

IM (”container”, ”add”, ”void”, <”logo”, ”BorderLayout.CENTER”>);

IM (”container”, ”add”, ”void”, <”sliderField”, ”BorderLayout.SOUTH”>);

Figure 6: The Sequence of Manipulation Operators for the

SpeedLogo Composition Script

Furthermore, the syntactic incompatibilities be-

tween components are handled within the internal

transformation module. Consider, for example, the

connection-based composition between the compo-

nent instances sliderField and logo described

in lines 056 to 080 of Figure 3 wherein the syn-

tactic incompatibility

between these two component

is transparent. This handler can be accomplished by

creaing an inner class that implements the required

interface (Stearns, 2001; Akerley et al., 1999).

As a next step, the manipulation operators are

translated into the desired programming language via

code generation plugins. Figure 7 gives the Java

The component instance sliderField allows

any component instance implemening the interface

PropertyChangeListener to register for the event

PropertyChange while the component instance logo

does not implement such interface.

equivalent of the sequence of manipulation operators

given in Figure 6 and the composition script given in

Figure 3.

public class SpeedLogo extends javax.swing.JFrame {

private java.animation.Logo logo;

private java.composite.SliderFieldPanel sliderField;

public SpeedLogo () {

java.awt.BorderLayout border;

java.awt.Container container;

java.awt.Color color;

border = new java.awt.BorderLayout();

container = getContentPane();

color = new java.awt.Color (0xeeeeee);

setTitle (”SpeedLogo Animation”);

setBackground (color);

container.setLayout (border);

sliderField = new java.composite.SliderFieldPanel();

sliderField.setCurrentValue (10);

logo = new java.animation.Logo();

logo.startAnimation();

container.add (logo, BorderLayout.CENTER);

container.add (sliderField, BorderLayout.SOUTH);

sliderField.addPropertyChangeListener

(new sliderField

PropertyChange());

}

class sliderField

PropertyChange

implements java.beans.PropertyChangeListener{

public void propertyChange

(java.beans.PropertyChangeEvent e) {

int value;

value = sliderField.getCurrentValue();

logo.setAnimationRate(value);

}

Figure 7: The Corresponding Java Code for the Manipula-

tion Operators in Figure 6

5 CONCLUSIONS

Our work makes the following contributions. It pro-

vides, to the best of our knowledge, the ﬁrst at-

tempt at the standardization of component compo-

sitions elevating compositions to ﬁrst class citizen-

ship status. We provide a CoCo composition model

that is both ﬂexible and extensible, allowing develop-

ers to extend the standard to include at a later time

other composition styles of component-based devel-

opment. The composition model is described us-

ing XML schema. At the lowest level, composition

scripts can be described using the composition model

implementation to describe an actual composition of

two or more components. A composition script writ-

ten in XML documents conforms to a speciﬁed com-

ICEIS 2005 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

344

position model speciﬁed by an XML Schema, which

in turn conforms to the general guidelines of the com-

position model.

The composition model is analogous to deﬁning the

grammar of a composition language, while the com-

position script

provides the program that describes

the actual composition of two or more components.

The composition model thus provides an extensible

composition grammar.

REFERENCES

Achermann, F. (2002). Forms, Agents and Channels -

Deﬁning Composition Abstraction with Style. PhD

thesis, University of Bern, Institute of Computer Sci-

ence and Applied Mathematics.

Achermann, F., Lumpe, M., Schneider, J.-G., and Nier-

strasz, O. (2001). Piccola – a Small Composition

Language. In Bowman, H. and Derrick, J., editors,

Formal Methods for Distributed Processing – A Sur-

vey of Object-Oriented Approaches, pages 403–426.

Cambridge University Press.

Akerley, J., Li, N., and Parlavecchia, A. (1999). Program-

ming with VisualAge for Java 2 (2nd Edition). Prentice

Hall PTR.

Allen, R. and Garlan, D. (1997). A formal basis for architec-

tural connection. ACM Transactions on Software En-

gineering and Methodology (TOSEM), 6(3):213–249.

America, P. (1990). Designing an Object-Oriented Pro-

gramming Language with Behavioural Subtyping. In

The REX School/Workshop on Foundations of Object-

Oriented Languages, pages 60–90, London, UK.

Springer-Verlag.

Box, D. (1998). Essential COM. Addison-Wesley Publish-

ing Company.

Butler, S. and Duke, R. (1998). Deﬁning Composition Op-

erators for Object Interaction. Object Oriented Sys-

tems, 5(1):1–16.

Chappell, D. (2002). Understanding .NET: A Tutorial and

Analysis. Addison-Wesley Professional.

Garlan, D., Monroe, R. T., and Wile, D. (2000). Acme:

Architectural Description of Component-Based Sys-

tems. In Leavens, G. T. and Sitaraman, M., editors,

Foundations of Component-Based Systems, pages 47–

67. Cambridge University Press.

Gschwind, T., Oberleitner, J., and Jazayeri, M. (2002).

Dynamic Component Extension to Support Cross-

Platform Development. Technical Report TUV-1841-

2002-19, Technische Universitt Wien.

Heineman, G. T. and Councill, W. T. (2001). Component-

based Software Engineering. Addison-Wesley Pub-

lishing Company, Reading, Massachusetts.

We use composition script to denote the description of

the composition that results in a composite component or

application.

Muller, H. and Davidson, M. (1996). JavaBeans

Speciﬁcation: Getting Listeners from JavaBeans.

http://java.sun.com/products/javabeans.

Oberleitner, J., Gschwind, T., and Jazayeri, M. (2003). The

Vienna Component Framework Enabling Composi-

tion Across Component Models. In The 25th Inter-

national Conference on Software Engineering.

Raje, R. R., Auguston, M., Bryant, B. R., Olson, A. M.,

and Burt, C. (2001). A Uniﬁed Approach for the Inte-

gration of Distributed Heterogeneous Software Com-

ponents. In The Monterey Workshop on Engineering

Automation for Software Intensive System Integration,

pages 109–119.

Roth, B. (1998). An Introduction to Enterprise JavaBeans

Technology. http://java.sun.com/products/ejb.

Shaw, M., DeLine, R., Klein, D. V., Ross, T. L., Young,

D. M., and Zelesnik, G. (1995). Abstractions for Soft-

ware Architecture and Tools to Support Them. Soft-

ware Engineering, 21(4):314–335.

Siegel, J. (1996). CORBA: Fundamentals and Program-

ming for the 21st century. John Wiley, New York.

Stearns, B. (2001). Using Forte for Java to

Develop and Deploy Enterprise Beans.

http://java.sun.com/developer/technicalArticles/

WebServices/ffjweb/.

Tansalarak, N. and Claypool, K. T. (2004). CoCo:

Composition Model and Composition Model

Implementation. Technical Report 2004-006,

Department of Computer Science, Univer-

sity of Massachusetts - Lowell. Available at

http://www.cs.uml.edu/techrpts/reports.jsp.

Vallecillo, A., Hernandez, J., and Troya, J. (2000). Com-

ponent Interoperability. Technical Report ITI-2000-

37, Departmento de Lenguajes y Ciencias de la

Computacion, University of Malaga. Available at

http://www.lcc.uma.es/∼av/Publicaciones/

00/Interoperability.pdf.

Yakimovich, D., Travassos, G. H., and Basili,

V. R. A Classiﬁcation of Software Compo-

nents Incompatibilities for COTS Integration.

http://sel.gsfc.nasa.gov/website/research/tech-

study.htm.

COCO: COMPOSITION MODEL AND COMPOSITION MODEL IMPLEMENTATION

345