Using software components has become a widely used development technique for building large enterprise systems. However in practice, component applications are still primarily built using simple component models and advanced component models offering valuable features like component nesting, multiple communication styles, behavior validation, etc. are omitted (bV industry in particular). Based on our experience, such an omitting is mainly caused due to usually unbalanced semantics of these advanced features. In this paper, we present a "nextgeneration" component model SOFA 2.0, which in particular aims at a proper support of such advanced features.
Cornponent-based development (CBD) [
There are tnany views and definitions of what a software colnpolteltt is br-rta general agreement is that a cornponent is a black-box software entity with well defined interf'acesand behavior. 'I'he set of all componenL f'eatures and rules fbr component lifecycle, cornposition etc. is usually called cornponent 'model.Frorn the compositiorr point of vierv, cornponent rnodels can be divided irrto two categories - flat coltrponerrtnrodels and hierarclrical conrponerrt nrodels. In corrtrary to the flat ones, the hierarchicai cornponent uroclels allow fbr conrposite componelrts (in addition to prirnitive conlponents), which means cornponents hierarchically composed of other courponents. Thus, an application can be seerr as a tree of nested components.
Currently, there are a number of cornponent modeis each of thern trying to provide an ideal solution for building applications. Componerrt models developed and driven mainly by industry (e.g. EJB, CCN,I. and Koala) offer to developers a stable and mature environment but they use just a flat component model (Koala uses a trierarchical one) and they do not provide advanced features like rrrultiple cornrnunication styles, conrposition verification, searnlessdistribution, dynarnic architectures etc. On contrary, corrlponent models developed mainly in the acadernic environtnent use irr airnost all caseshierarchical cornponent models artd provide above mentioned advanced features. However academic cornponent rnodels focus very often just on component design and they provide rro or very Iirrrited runtirne environment, which is a major factor that hinders a cornmon (and especially industrial) usage of hierarchical component rnodels. The rnain reason for the lirrrited runtime support in the area of component models with advanced features is in our view that it is quite hard to properly balance a senrantics of all these advanced features.
The goal of the paper is to show strong and weak points of contemporary used component models and therr to present the SOFA 2.0 14)component model that supports hierarchical componerlts and a number of advanced features. while it also provides a stable runtime environrnent, which serves for executine of component applications.
Irr this section, we discuss and compare representatives of common contemporary componellt models with respect to their supported features and implementations. In particular, we focus on support for describing architectures, possibilitv of dynamic architectures, support of advlancedfeatures like behavior description, multiple cornmunication styies via connectors, etc. (see [a] for detailed explanation of these particular features and the problerns related to them), and arr existence of runtime support for cornponents. We discuss Darwin, Wright, and ACIVIE component modeis, which although already rather olcl had a strong influcncc on cornportcnt utodels developcd later. Furthcr, we prescnt CC\I, EJB. and Koala as the representatives of the industrial models, and we also devote attention to several representatives of academic component models, namely Flactal, Arch.Iava, and SOF]\. At t.he end ol'the section, we briefly rel'er t,oseveral non-standard component rnodels
As it has been mentioned above, Darwin [
Another classical ADL without a runtime environment is Wright [
ACIVIE [7] is an ADL intended to serve as a common represenrarion for architecture descriptions. It uses a hierarchical component model with connectors. Both components and connectors can have associated properties (for describing auxiliary information) and design constraints, which mainly serve for describing dynamic changes of an architecture. The language for the design constraints is based on first order predicate logic.
Enterprise Java Beans (EJB) component model [
OMG CORBA Component Model (CCM) is quite similar to EJB but it allows for explicit description of component requirements. FYom communication styles, it supports synchronous and asynchronous method invocation. Compared to EJB, it is multiplatform and independent of a particular programming language.
Koala [
Fractal [
Julia is a Java-based reference implementation of Flactal, which allows component programming in Java. Components can be created either directly via Julia API or using Flactal ADL. In addition to design time, components also exist and can be referenced at runtime. For implementation of control parts of components, Julia uses so called m'irins, which are Java classesthat are woven with the original components' classesusing bytecode manipulation. The experience however shows that Julia's approach the component control parts is poorly manageable and hard to extend and debug.
AOkell [
The SOFA component model [
Both SOFA and all implementations of Flactal create a component platform
over the Java platform; in fact they are Java libraries. At runtime, instances
of components exist but they are mapped to a set of Java classes,The
ArchJava [
In addition to the component rnodels presented so far, there also exist component models, which try to capture and describe architectures in a rather formal way. For example CHAM [tL] or system based on graph rewriting [f9], both targeting description of dynamic architectures. But these systems are very corlplicated (even for simple architectures) and they do not provide any runtime environment.
S O F A 2 . 0 As described above, currently there are either component systems with strong support for describing architecture and no or almost no runtime support or
Advanced Features of Hierarchical Component Models systems with a stable and functional runtime environment but rather poor possibilities for designing components. In the middle, there are system like SOFA and the Flactal implementations, which provide both but still they have obstacles that hinder from common usage. SOFA 2.0 which is a next generation of tire original SOFA tries address these obstacles and issues.
SOFA 2.0 has inherited a hierarchical component modei with connectors and most of other features fiom its ancestor. The main differencesagainst the original SOFA version are meta-model-based design of components, support of dynamic architeclure reconfigurations, support of any communication style, and clearly separated and extensible control parts of components.
SOFA 2.0 is defined using a meta-model. In contrast to ADl-based
definition used in the original SOFA, such an approach has many advantages like
automated generation of a repository with standardized interface, standardized
XN{L-based interchange format, support for automated generation of models'
editors, etc. (see [
Components are described using fram,e and archi,tect'ureconstructs. The frarne defines a set of interfaces (services) provided and/or required by a component. The architecture then defines an implementation of the fiame; for primitive components the architecture is empty and for composite components it defines subcomponents (again using frames or other architectures) and connections among them.
The support of dynamic architecture reconfigurations is realized via
welldefined reconfiguration patterns [
For speci$'ing component behavior formally, SOFA 2.0 uses
behaui,orprotocols [
Tlre SOFA 2.0 runtime environment is called SOFAnode. It consists of the repository and a set of deployment docks, each of thern can be located on a different computer. A deployment dock is a container for launching components. A single application can spread over several docks; connectors among components assure transparent distribution.
As it has been said above, the repository is generated from the meta-model and stores both component descriptions and implementations. At development tiute, developers store into it the component information and also reuse the information already stored there. The repository and in fact whole SOFA 2.0 allow
P. Hndnnka and T. Burei versioning of courponents.The versioning model used irr SOFA 2.0 is the sarrre as in lhe original SOFIA. 1b gr.raranteeintegrity of rhe development of different versions and the converrient developrnent, the repository sr-rpports clon'i:ng.At the beginning of the developrnent, developers create a new clone of the repository, which mirrors its content. Then they work with this cione and finally, they nerge the clone with the original repository. In the clorred working copy, developers can create temporary inconsistenciesbut the cloning and merging perrnits to rnerge just fully consistent repository. The repository also allows export and irnport of already developed componerrts(e.g. developed by third parties).
From the implementation point of view, a component is set of Java classes. For primitive componerrts, developers have to provide implementation classes. There are not any requirements on these classes,i.e. they do not have to implemcnt/extend any SOM-specific interfaces/classcs.Instead, we use an annotationbased approach where components' provisions, requirements, initializing methods, etc. are marked using annot,ations. Benefits of this approach are no dependencies ori the underlying platform (a single irnplementation can be resused in different component platfbrms) and implementation classescan be easily [ested by tools like JUnit without starting the whole SOFAnode. As composite cornponents are composed of other components, they do not have any direct impiernentation and developers do not create any code for them.
Due to versioning, Java class nanre clashes can occur at runtime, i.e. a situation. when bwo different classeshaving the same name are to be loaded into the virtual machine. To address this, SOFA 2.0 uses bytecode rnanipulation; after compiling componen[ classes,the bytecode of the classesis modified and the classesare renamed to have unique names. Irr detail, the approach is described I N I 1 U I .
All bindings among components in SOFA 2.0 are realized via connectors, which are first-ciass entities in charge of addressing the communica[ion logic. Their use brings the transparent distribution, different cornmunication styles (e.g. synchronous rnethod invocation, asynchronous message delivery, shared mernory, streaming, etc.) and the possibility of non-functionai aspects (e.g. logging, benchmarking, runtirne bchavior verification. security, etc.). A connector is specificd at design time as a binding (i.e. an hypcr-edge connccting severaicomponent interfaces) and as a conrmunication style and a set of properties associa,tedwith each component interface participating in the binding. In our approach, rve use connectors not onl1,in design but also at runtime as well-defined code artif'acts. 'Ihe transibion from the high-level design [ime specification to connector code is realized by a connector generator, which can automatically generate the connector irnplernentation based on design-time and deployment requirements. We perform the generation of connectors only at deployment tirne, which is when we have the cornplete information of the application to be launched (including the distribution of particular components to deployment docks); thus, we can choose the most appropriate middleware for addressing the distribution and perforrn other potential optirnizations.
In SOFA 2.0, we have striven to bring out the control part of components and make it easily extensible. The control part (or component controliers) deals with the rnanagernertt logic of a component, whicir includes management of bindings, iifecycle, some sort of introspection, controiling the update, etc. In the existing colnponent systems (excepb Fractal), this iogic is typically strictly defined by the respective system and cannot be easily changed or extended. Inspired by the Fractal component nrodel, we have introduced to SOFA 2.0 the concept of explicit component controllers. There is a dedicated nricro-component model, which allows defining an architecturc of thc control part, and the concept of a control aspect, rvhich encapstrlateda set of micro-components and defines a consistentexteusiorrof the control part. Thus) we are able to easilymodel, extend or even replace the control part of a cornponent.
In this paper, we have presented a short overview of contemporary component models and pointed out their main limitations with respect to advanced component features (such as component nesting and rnodeling, possibility of dynarnic architectures, description of component behavior, connectors, multiple communication styles, extensible component corrtrol functionality) and the existence and maturitl' of a runtime environment. Then, we have described a new component model SOFA 2.0 which aims at addressing these limitations. It allows for all the mentioned advanced features and provides a balanced support for them at design-time as weil as at development-, deployment- and run-time. At present, SOFA 2.0 has been formalized using meta-models and also an implementation of its runtirne is available. Tire development toois are work in progress. This work was partially supported by the Grant Agenc'y of the Czech Republic 'project 201/06/0770. The support of the Info'rrnat'ics Commerci,al'isat'ion i,ntt'iat'i'ueof Enterprise lreland i,sgratefully acknowledged.