Proceedings of the Fifth International Workshop on Component-Oriented Programming (WCOP 2000)

Proceedings of the Fifth International Workshop on

Component-Oriented Programming

(WCOP 2000)

Editors:

Jan Bosch, Clemens Szyperski and Wolfgang Weck

Department of Software Engineering and Computer Science Blekinge Institute of Technology

Blekinge Institute of Technology Research Report No 15/00

Component-Oriented Programming (WCOP 2000)

JanBosch

University ofGroningen

Netherlands

Jan.Bosch@cs.rug.nl

Clemens Szyperski

Microsoft Research

USA

cszypers@microsoft.com

Wolfgang Weck

Oberon microsystems

Zurich, Switzerland

weck@oberon.ch

WCOP 2000, held in conjunction with ECOOP 2000 in Sophia Antipo-

lis, France, was the fth workshop in the successful series of workshops

on component-oriented programming. The previous workshops were held

in conjunction with the respective ECOOP conferences in Linz, Austria,

Jyvaskyla,Finland,Brussels,BelgiumandLisbon,Portugal. WCOP96had

focussed on theprincipal idea of software components and worked towards

denitionsof terms. Inparticular,a high-leveldenitionofwhat asoftware

component is was formulated. WCOP97 concentrated on compositional

aspects, architecture and gluing, substitutability, interface evolution, and

non-functionalrequirements. WCOP98 had a closer look at issuesarising

in industrial practice and developed a major focus on the issues of adap-

tation. WCOP'99 moved on to address issues of component frameworks,

structured architecture, and some bigger systems built using components

frameworks. The topics for WCOP 2000 focussedon component composi-

tion,validationand renementand theuseofcomponent technologyinthe

software industry.

WCOP 2000 had beenannouncedasfollows:

WCOP 2000 seeks positionpapers on theimportant eld of

component-oriented programming (COP). WCOP 2000 is the

1

placein conjunctionwithevery ECOOPsince1996.

COP hasbeen described as the naturalextension of object-

orientedprogramming to the realm of independentlyextensible

systems. Several important approaches have emerged over the

recent years, including CORBA, COM, JavaBeans, and more

recently COM+, EJB, and CCM. After WCOP'96 focused on

thefundamentalterminologyofCOP,thesubsequentworkshops

expanded into the many related facets of component software.

WCOP 2000 shall emphasis architectural design and construc-

tion of component-based systems beyond ad-hoc reuse of unre-

lated components.

To enable lively and productive discussions, the workshop

willbe limitedto 25 participants. Dependingon the submitted

positionpapers,theworkshopwillbeorganizedintothreeorfour

subsequentmini-sessions,eachinitiatedbyapresentationoftwo

orthreeselectedpositionsandfollowedbydiscussions. Insteadof

splittingtheworkshopintotaskforces,itis intendedto provoke

livelydiscussionbypreparinglistsofcriticalquestionsandsome,

perhapsprovocative, statements(to be usedon demand).

Position papers will be formally reviewed, each by at least

two independent reviewers. As an incentive for submission of

high quality statements, the best position statements will be

combined withtranscriptsof workshop resultsand published.

Last year's WCOP'99 report observed: \One interesting trend that we

have identiedover theyears is a change infocus. Whereas the rst work-

shops aimedat the individualcomponents, especiallyduringthe lastevent

there wasa clear consensus thatthe focus shouldbeon the component ar-

chitecture, i.e. the cooperation betweencomponents. In particular,notthe

component-'wiring' standards,such asCORBA, COMand JavaBeans, but

ratherthesystemdesignlevelissues,suchassoftwarearchitecturesandcom-

ponent frameworks." Interestingly, this trend was maintained for WCOP

2000. Eventhemore formalworkon validationandrenement focussedon

thecompositionof components, ratherthanindividualcomponents.

25 papersfrom morethan10 countries weresubmittedto theworkshop

and formally reviewed. Thirteen papers were accepted for presentation at

the workshop and publication in the proceedings. About 40 participants

fromaround theworld participatedintheworkshop.

Theworkshopwasorganizedinto three morningsessionswithpresenta-

2

afternoonsessiongatheringreportsformthebreakoutsessionanddiscussing

future direction. The opening and closing sessions were runtogether with

anassociatedworkshopon pervasivecomponent systems,whichallowedfor

interestingcross fertilization.

1 Presentations

Thissectionsummarizesbrie ythecontributionsofthethirteenpresenters,

as presented in three sessions. i.e. validation & renement, component

compositionand industrialapproaches.

1.1 Validation and Renement

Therstsessionconsistedoffourpapers. The rstpaper,byEddyTruyen,

BoNorregaard Jorgensen, Wouter Joosen and Pierre Verbaeten, addressed

the issue of interaction renement in middleware. The authors propose to

use a re ective approach to allow for dynamic reorganization of, among

others,objectrequestbrokerstoreneinteractionatrun-time. Theauthors

applythisapproachtodynamicallyintegratenewservicesthatsupportnon-

functionalaspects,such assecurity,transactionsand real-timebehaviour.

The second paper of Jo~ao Costa Seco and Lu



is Caires presented the

compositionlanguage ComponentJ,to which parametric typingwas added

recently. In ComponentJ, acomponent can state which services itrequires

to be plugged in. In the respective requires clauses component types are

used. Similarly,providesclauses state the typesimplementedby aparticu-

lar component instance. Actual instances can now be connected using the

plug-into clause. Of course, instances plugged together this way have to

adherethetypeconstraintsformulatedbytherequiresandprovidesclauses.

ComponentJalso supports subtypingand boundparametric polymorphism

forcomponent types.

Another approach of separating composition from implementation was

taken bythe authorsof thethird paper,Kris DeVolder, Johan Fabry,and

Roel Wuyts. Their proposal is to deploy logic programming to describe

propertiesobjects musthaveto becomposablewitheachother. Atcompile

timethelogicprogramis ranand matches aremade. Withthehelpof this,

for instance, visitor objects can be implemented much more independent

of the structures to be iterated over by the visitor. Such patterns, cutting

across several classes, can be expressed in isolation rather than smeared

acrossall involved classes.

3

and co-authored by Robert Cherinka, John Ricci and Michael Overstreet.

The authors pointed out that with increasing information hiding within

components integration tests of mission critical systems become more and

more diÆcult. Whereas of-the-shelf components can considerablyspeedup

applicationdevelopmentin thebeginning,extraeort needsto be putinto

testingand validatingthecomposedsystemifitisgoing to bemission crit-

ical. Internalstates of acquiredcomponents cannot easilybe observed and

componentscannoteasilybeprovoked toexhibitbehaviorthatmightbere-

quiredtoputothercomponentsintoastresstest. Theauthorshencepropose

to open up components for these purposes ina controlled way. Additional

testinginterfacescanbeprovided,forinstancetoobserveinternalstate,and

testinginstructionsshouldbemadepartofacomponent'sdescription. Such

requirementsgo beyond today'scomponents.

1.2 Component Composition

The second session consisted of six papers, covering various facets of com-

ponent composition. The rst paper, presented by Oliver Stiemerling and

Pascal Costanza, focused on object identityand dynamic recomposition of

components. TheydescribedtheirprototypesystemEvolve,whichpresents

3D-views of the dynamic congurationof distributedsystems. Comparing

Evolvetoaprecisioninstrumentforopen-heartsurgery,theyexplainedhow

itcan be usedto change systemcongurations at run-time. Evolve models

componentswithexplicitinandoutconnectionsandmanifestsitseectson

a systemin terms oftransitions. Under a congurationtransition, oldand

new components can coexist for a while. This leads to potential overlaps

in state. Evolve has mechanisms to deal with the consistent maintenance

of object identity under such transitions. However, the necessary transfer

of state remains an open issue. They described how the new can act as a

wrapperoftheoldcomponentto handlesuchstatetransferincertaincases.

The second paper introduced an approach to the declarative descrip-

tion of component models in an attempt to support software composition

generically;itwaspresentedbyMarieJose Presso. Theirgoal istodevise a

compositionmodel thatisindependentofparticularbuildertoolsand their

approachistouselogicmeta-programming. Compositionisexpressedusing

facts and validity checking using queries. The resulting descriptions they

foundare a powerfultool for code generation; a result that they validated

witha JavaBeans-based prototype.

The third paper, presented by Sanjiva Weerawarana (co-authors are

4

compositionlanguages. Besides presenting theright compositionoperators

andan opportunityto placerequiredglue code,they claimthat, to besuc-

cessful, composition languages must t into current development realities.

Hence, they do not introduce a new component model. In their present

work they useJavaBeans, butthey wishto extend to other models(COM,

CCM) with an aim to mix and compose across multiple models. Further,

they emphasizedthat theapproachmustnotinterferewithobject-oriented

programming, thus requiring a separate composition structure. They pro-

pose thatsuchan approach leadsto a new marketof composersthatdon't

require OOP training. (`Scripting languages are your friend.') Their ap-

proachrestsontwopillars: BML(BeanMarkupLanguage)andBSC(Bean

Scripting Component). BML is an XML-based composition language that

can be interpreted orcompiled. A BSC is a component encapsulationof a

composition script; when combining BML and BSCs, their approach gets

recursive. Inthe future, they wish to extend their work to supporttesting

and validation. The required component description language is an open

issue.

The fourth paper on abstract plug-in components with behavior was

presented by P.J. 't Hoen (co-author L.P.J. Groenewegen). Focusing on

packages as the basis of their approach, they extend the idea of packaging

classesto that of packaging objects. Such packages of objects help to per-

form instance-level composition. In a recursive step, they view packages

themselves again as classes. They made this approach concrete in their

SOCCAlanguage.

The fth paper discussed an architecture to support dynamic compo-

sition of service components and was presented by Bernard Pagurek (co-

author David Mennie). Their basic scenario are networked services com-

posed usingthe Facade pattern. Where performancematters, such a com-

positioncan beintegrated, creatingastand-aloneinterpretedservice. Their

architectureaimstosupportexistingtechnology(Jini,JavaBeans)anduses

an XML-based compositionlanguage, augmented by a repository of avail-

ablecomponents. Theycreateda Component ManagerserviceforJinithat

oversees all aspects of dynamic composition. An issue is to how to avoid

undesiredfeatureinteraction. TheComponentManagerusesXML-encoded

servicespecications{avoidingunwantedinteractionis hard,sincethecom-

positionisdone on-line.

The sixth paper presented by Dietrich Birngruber (co-author Markus

Hof) outlined interactive decision spots for JavaBeans composition. Their

observation is thatthesame beans aretypicallywired inverysimilarways

5

wiring scenarios, leaving only specic decision spots open. The net eect

wouldbe to deliver acustomizablewizzard withabean.

1.3 Industrial approaches

The thirdsessionconsisted of fourpapers,covering software productlines,

congurationmanagement,non-programmeruseofcomponentsandtheuse

ofagents ascomponents.

The rst paper was presented by Denis Conan (co-authors are Michel

CoriatandNicolas Farcet). The focus ofthepaperwasthe development of

software componentsin thecontext of software product lines. The authors

describea meta-model for softwarecomponent development coveringthree

activities,i.e. design, implemenationand delivery. The meta-model allows

one to expressdesigntransformations,suchascomponent compositionand

splittin,abstractionand renement.

The second paper addressed the conguration management of compo-

nents and was presented by Ivica Crnkovic (co-author Magnus Larsson).

The authorsstart outwith discussingtheproblemof component selection,

i.e. whenconstructingacomponent-basedsystem,howdoesoneselectcom-

ponentsthatprovidetherequiredfunctionalityandqualityattributes. Since

components typically are available as binary units, the prefered approach

wouldbetoassociateinformationwiththebinaryrepresentation. However,

thisisnotfeasibleforexternallydevelopedcomponents, requiringthecom-

ponent user to extensively test these components in order to understand

their properties. The authors propose the use of software conguration

management principlesto address these issues.

Erlend Stav addressed a problem little discussed in the component-

orientedprogramcommunity: theconstruction ofsoftwaresystemsbynon-

programmers using a component-based environment. The approach taken

is to make use of visual means for component composition. This basically

denesavisualprogramminglanguagewitharatherlimitedvocabularyfor

buildingsystems. Thepresentation wasrefreshinginthat mostapproaches

to component instantiation are concerned with providing the component

user,whoisexpectedtobeanexpert,withasmuchcongurabilityaspossi-

ble. TheworkpresentedbyStav,however,wasinterestedinlimitingnumber

of variation pointsas much aspossible, while maintaining freedom for the

user.

ThenalpresentationinthissessionwaspresentedbyJean-GuySchnei-

der (co-authors are Oscar Nierstrasz and Franz Achermann). The authors

6

"agents everywhere, all the time". The authors identify that computing

is movingtowards pervasive, wireless,spontaneously networked computing

devices and their assumption is that these devices and the services that

they provide will be represented as agents. In the paper, three open is-

suesare discussed,related to development,operation andvalidation. First,

whatparadigmsandapproachescan be usedtodeveloptheaforementioned

agents. Second, what identication and interaction models shouldbe used

fortheseagents. Finally,whatvalidationapproachesareavailablethatallow

usto reason aboutthe properties of such emergent networks. Theseissues

arediscussedPiccola,a smallcompositionlanguage.

2 Breakout Session

Thefollowingsixbreakoutgroupswereformed:

1. Componentsand architectures.

2. Embeddedand pervasive systems.

3. Component evolution.

4. Scalabilityandgranularity.

5. Variability.

6. Degreesof encapsulation.

Most of the groups had between ve and twelve members, all with a

designated scribe and a designated moderator. The following subsections

summarizeeachgroupsndings.

2.1 Components and architectures

Thisbreak-out groupidentiedearly that its participants had two distinct

interpretationsofthetitle. Onegroupinterpreteditascomponent architec-

tures andwasinterested intheinteractionbetweencomponents. Theother

group interpreted it as the relation between the software architecture and

thearchitecturalcomponentsthatitspeciedandthesoftwarecomponents

that provide the implementationfor architectural components. The group

decidedtodiscussbothtopics. Forcomponentarchitectures,thediscussion

7

basedsystems. Forinstance, anevent generated byone componentmaybe

interpretedrather dierentlyby thecomponent(s) thatreceived theevent.

Sincecomponentsaredevelopedbydierentparties,onecannotassumethat

these sharesemanticsforsynctactic typesand events.

Thesecondinterpretationwasdiscussedaswell. Themaintopicsduring

thediscussionincluded therelationbetweenqualityattributes and require-

mentsatthearchitectureandthoseattheleveloftheindividualcomponents.

A second topic that was discussedwasvariability. Variation pointscan be

introduced and boundat thelevelof thearchitecture, thecomponentsand

inside components. Preferably, one would prefer freedom in selecting the

optimallevelforintroducingthevariationpoint,whichisa challengewhen

using components. The third topic was concerned with dynamic software

architectures, i.e. systems that can dynamically reorganize themselves in

responseto changes inits context orto incorporate new functionality that

becomes available. When the architecture of a software system changes

dynamically,how do components manage this?

Finally,thedierenceininterpretationofthetitleofthebreakoutgroup

led to a terminological discussion. Interestingly, the participants reported

that, after thediscussion, they were no longer certain aboutthe dierence

betweenconcepts such as architecture, framework, component and compo-

sition!

2.2 Embedded and pervasive systems

The breakout group was primarily interested in the resource constraints

present in embedded and pervasive systems and the eect on component-

based software engineering. The group started with asking among them-

selves why they were interested in using components even in these types

of software systems. The answers that they foundwere: reduced cost, im-

proved reuse, reduced complexity, improved maintainability and improved

customizability. Thus, good arguments exist forwhyto use components in

theembeddeddomain.

Oncethiswasclearedup,thegroupfocussedonthreespecicissuesthat

they considered to be most central. First, the specication of constraints,

suchasqualityofservice,memoryconsumptionand energyconsumption,is

notnecessarilyrelevantforgeneralpurposecomponents,butcrucialforcom-

ponents in an embeddedcontext. A component that provides the required

functionality,butdoesnotsatisfythequalityrequirements,suchastheones

mentioned above, is still useless forthe system at hand. The second issue

8

Due to additional levels of indirection and the availability of functionality

notnecessarily required in all types of systems, component modelsimpose

an overhead that needs to be outweighed by the advantages. Finally, the

break-outgroupparticipantsdiscussedtheimmaturityoftheinfrastructure

inembeddedsystems.

2.3 Component evolution

Component evolution wasrst decomposed into two types, i.e. anticipated

and unanticipatedevolution. When theorganization usingthecomponents

also ownsthem, theevolution is generally anticipated. Otherwise,compo-

nentsaretypicallyblack-boxand evolution isoften unanticipated.

The breakout group continued to identify the driving forces for com-

ponent evolution. Three forces were identied, i.e. environment changes

(whatthecomponentrequires),requirementchanges(whatitprovides)and,

nally,changes to themanagement interface.

Finally,evolution of external, black-box components was discussedand

it was concluded that wrappers, despite their disadvantages, currently are

theprimarymeansforachievingevolution.

2.4 Scalability and granularity

Thecoreissueinthisbreakoutgroupwasthequestionwhetheritispossible

tomentallymanagetherecursivecompositionof'small'interfaces. Ifthisis

thecase, thendisadvantagessuchastherun-timeoverheadremain,butthis

is countered by the better testability of small component interfaces. The

granularityof components isa compromisebetweencon ictingforces.

The breakoutgroupexploredtherelationbetweentheproblemsizeand

the solution size. Assuming that the problem has predened domain in-

stances, the solutiondomaincan be organized in components of the'right'

granularitywhilemaintainingscalability.

Finally,thenotionofacompositionallanguagewasdiscussedthatwould

allow us to compose components as easy as programming languages com-

pose the syntactic elements of thelanguage. The assumption was that the

availabilityofsuchalanguagewouldpositivelyin uenceourabilitytoscale,

butnolanguage proposal waspresented.

9

A topic that received no or minimal attention during earlier years is the

notion of variability, i.e. predened variation points at which available or

newly developed variants can be bound to obtain the required behaviour

from the instantiated component. The breakout group identied three rel-

evant activities, i.e. discovering, facilitating and implementing variability.

Themainissuewithrespecttodiscoveringvariabilityishowoneidentiesre-

quiredvariabilityand,onceidentied,howonedocumentsvariationpoints.

Withrespect to facilitating variability, thebreakout group focussed on de-

sign patterns. Many designpatterns separate stableand variant behaviour

providinggoodmeansforfacilitatingvariability. Finally,fortheimplemen-

tationofvariability,severalcategoriesofmechanismsareavailableincluding

structural exibility,rule-based exibilityand supportive technologies.

2.6 Degrees of encapsulation

Thenal topic addressed bya breakoutgroup was encapsulation. The dis-

cussion start out from the question "how much encapsulation can we af-

ford?". A certain degree of encapsulation {or information hiding{ within

components is needed to abstract from implementation details, to allow

component implementationsto be changed withoutinvalidatingall clients,

and to achieve more context independence. Onthe downside,a totally en-

capsulatedcomponent is pretty much useless fora component user. There

is a need for information about how to use the component, in particular,

what is demanded from the component's deployment context. The more

encapsulated a component is, the more careful it must be described how

the surrounding system must look like. In today's practice, most of these

descriptionsarenotcompleteand lacksome details.

Further, the more a component actually becomes context independent,

the more genericity gets build in, which has drawbacks on performance,

complexity,etc. Finally,systemsbuiltofcomponentsneedto betestedand

components may need to be adapted to application-specic needs. Again,

this may require access to component-internal details. From a component

producer perspective, the above discussion contains relevant questions as

well. For instance, how to express quality attributes of a component and

what aspects ofa componentare relevant fortheusers.

The break out group concluded that there is no nal and general an-

swer yet to theissueof how muchencapsulated a component maybe. The

hard issue is that component designers and producers need to guess what

10