Models summary

Rather than presenting in this chapter a thorough survey on component models, we opted to present here only a summary of that survey. This summary is intended to give readers a grasp of current component models, their main strengths and shortcomings. Interested readers are invited to find further details on each of the surveyed component models in Appendix A.

Table 2.1 summarizes the component models presented in this review. The balanced distribution of models by origin reflects our concern in discussing component models originated by the software industry, academia, and consortia between both. In the columns’ header, we have the surveyed component models. In the rows’ header, we present the several categories identified in our taxonomy. The x matching a category row with a component model column means that that component model fits into the corresponding categories. For most of the criteria, each component model fits into one of the categories in that criteria. The exception concerns the support for contracts. Here, a model may support more than one contract type, and we opted to mark all the supported types, rather than just the most sophisticated one. As we will see, it is not always the case that a model supporting the most sophisticated of Beugnard’s contract types supports all the remaining ones.

With respect to the typical granularity of components, most models support the full range, from fine-grained to coarse-grained components. That said, while some models may be better suited for fine-grained components (e.g. JavaBeans), most models are better suited for medium and coarse-grained components, although they also support fine-grained components. One of the common characteristics for supporting coarse- grained components is the ability to create composite components from finer-grained components (see, for instance, Koala components), and we have classified the models with this ability as hierarchical component models.

Depending on the component model, components may be classes, objects, or archi- tectural units. In our sample of component models, this has a direct mapping on the syntax of the component model. When components are represented through classes, they typically have an object-like specification language syntax. When components are run-time objects, they are usually specified through their interfaces, using an IDL. When they are architectural units, they are specified through an ADL.

When analyzed in the scope of the component life cycle, the form of integration of component models, ranging from design without repository to deployment with repository, varies greatly. In one end of the spectrum, we have ADL-based component models, which usually do not rely on a repository for retrieving their components. The implication that this leads to focusing on designing components and component-based systems from scratch, rather than by reusing existing components, is one of the main shortcomings of these approaches.

JavaBeans Enterprise

JavaBeans

COM+ .Net CCM Fractal OSGI Web

Services

Acme UML KobrA Koala SOF

A PECOS Frequency Origin Industry x x x x x x x 7 Academy x x 2 Both x x x x x 5 Repr es. Classes x x 2 Objects x x x x x x 6 Arch. Units x x x x x x 6 Syntax Object-like x x 2 IDL x x x x x x 6 ADL x x x x x x 6 Integrat. DesNRep x x x 3 DesDORep x x x x x x x 7 DesRep x x x 3 DepRep x 1 Str u. Flat x x x x x 5 Hierarchical x x x x x x x x x 9 Contract Syntactic x x x x x x x x x x x x x x 14 Behavior x x x x x 5 Synch. x x 2 QoS x x x x 4 Cert. Supported 0 Not available x x x x x x x x x x x x x x 14 Reas. Supported x x 2 Not available x x x x x x x x x x x x 12

of design can be stored and retrieved from the component model as units of design. This is an approach common to software product line component models (Koala and KobrA), and to SOFA (the exception, when it comes to academic-based models in this review, for this particular categorization).

Between the previous two categories of integration, we have the most popular com- ponent models within industry, which, in general, allow designing components and storing them in binary form into a repository. A common shortcoming in these ap- proaches is that they don’t allow depositing composite components in the repository, which would make them available for further integration, for instance. Most compo- nent models allow component integration during design. The exception is JavaBeans, which only allows it in deployment.

As noted in [Lau 07], there is an opportunity for improvement of current compo- nent models, as none of the component models (with the possible exception of SOFA 2.0) supports a “Design and deposit category”, which would allow composites created during design to be further composed during deployment.

In [Bures 06], the SOFA proponents dispute this classification. They argue that no composition should happen at deployment time. Their rationale is that rather than a deployment phase, we should consider a runtime phase when systems can be dynam- ically reconfigured. With this adaptation, they claim to meet the “ideal” component life cycle proposed in Lau’s taxonomy [Lau 07]. In turn, Lau’s taxonomy assumes that run- time reconfiguration is achieved by stopping the system’s execution and going back to the deployment phase for reconfiguring the system. It also assumes that the creation of links to services at runtime should not be considered as composition, in terms of semantics (as they are not considered, for example, with respect to web services).

Most component models support, by default, only a basic syntax-type contract. It is no surprise that more sophisticated contract approaches are mostly available for com- ponent models provided by academics, or consortia between academic and industry partners. It should be noted that this state of practice seems to be shifting, in the sense that, increasingly, industry driven solutions (e.g. UML 2.0) are providing more sophis- ticated support to design by contract.

The quest for component certification remains, to all practical aspects, a dream. None of the reviewed component models provides direct support for component cer- tification, as described in section 2.2.2. Initiatives such as Predictable Assembly for Certifiable Components (PACC) [Wallnau 03] are trying to mitigate this problem. In [Chaki 07], the PACC team supports certification of software component binaries from UML state chart specifications, combining Proof-Carrying Code with Certifying Model Checking techniques5.

5_{Proof-carrying code “constructs a proof that machine code respects a desired policy, packages the proof with}

the code so that the validity of the proof and its relation to the code can be independently verified before the code is deployed”, while certifying model checking “is an extension of model checking for generating proof certificates for finite state models against a rich class of temporal logic policies” [Chaki 07].

Most component models provide no support for compositional reasoning. The ex- ceptions come from academic backgrounds, suggesting that, as with the certification of components, the techniques for compositional reasoning are still in a maturing process. The community needs more sophisticated abstractions than those provided by cur- rent component models. Components represented by objects and classes are integrated through message passage. Several of the architectural-based approaches discussed in appendix A provide some level of compositional reasoning support, but are less dis- seminated in the practitioner’s working environments, and typically lack professional development tools, comparable to those of modern integrated development environ- ments.