SOFA component model


Table of Contents

SOFA component model
Components
Component Definition Language
Connectors
Behavior protocols
SOFAnode
DCUP
References
A. Syntactic diagrams of CDL

SOFA component model

SOFA (SOFtware Appliances)[sofa] is a project aiming to provide a platform for software components.

Components

In the SOFA component model, applications are viewed as a hierarchy of nested components. Components can be either primitive or composed - a composed component is built of other components, while a primitive component contains no subcomponents. As a result, all functionality is located in the primitive components.

A component is described by its frame and architecture. The frame is a black-box view of the component. It defines provides-interfaces and requires-interfaces of the component. Optionally, it declares properties for parametrizing the component. The frame can be implemented by more than one architecture. The architecture of a composed component describes the structure of the component by instantiating direct subcomponents and specifying the subcomponent's interconnections via interface ties. The architecture reflects a particular grey-box view of the component - it defines first level of nesting in a component hierarchy.

There are four kinds of interface ties: (a) binding of a requires-interface to a provides-interface between two subcomponents, (b) delegating from a provides-interface of component to a subcomponent's provides-interface, (c) subsuming from a subcomponent's requires-interface to a requires-interface of component, (d) exempting an interface of a subcomponent from any ties. A non-exempting tie is realized via a connector (see the section Connectors). For convenience, the simple connectors, expressing procedure (method) calls are implicit so that they do not have to be specified in an architecture specification.

The architecture can also be specified as primitive (i.e. primitive component), which means that there are no subcomponents and its structure/implementation will be provided in an underlying implementation language.

The whole application's hierarchy of components (all levels of nesting) is described by application deployment descriptor.

Component Definition Language

The Component Definition Language (CDL) is used to describe interfaces, frames and architectures of SOFA components. It is based on OMG IDL; the language extends the features of IDL to allow specification of software components.

A sample CDL specification is shown on Figure 1.

Figure 1. A sample declaration in CDL

interface Login {
   CentralPlayerServices login(in string who);
};
frame Client {
   provides:
      Client iClient;
   requires:
      Login iLogin;
      CentralPlayerServices iCPS;
};
architecture CUNI GameGen implements GameGenerator {
   inst GameGeneratorDBServices aGGDBS;
   inst ConfigurationFileParser aConfig;
   inst GameGeneratorFunctionality func;
   bind func:iConfig to aConfig:iConfig;
   bind func:iGGDB to aGGDBS:iGGDB;
   subsume aGGDBS:iDatabase to iDatabase;
};

Descriptions in CDL are compiled and stored in the Type Information Repository (TIR). TIR manages an evolution of component's description and can store several versions of every element defined in CDL. In TIR, each element defined in CDL (interface, frame, architecture,...) is identified by its name specified in CDL and by its specification version. In the CDL descriptions, a developer can specify references to a concrete version of previously compiled types stored in TIR. Type references specified without version are resolved to the currently compiled version of the referenced type (for a single compilation, a developer can specify multiple files of CDL sources; from the CDL compiler view, all definitions come from one source) or to some version stored in TIR. The selected version depends on TIR contents and a profile. A profile is a list of the identifications to be used in the version selection process. Profiles are also stored in TIR; the profile used during the compilation is selected by CDL compiler option. The algorithm for selecting the appropriate version is following: 1. when a version is specified by a version identifier, that version is retrieved, 2. When only the entity name is specified, a profile is active, and the name of the entity exists in the profile, the version identifier stored in the profile is used, 3. otherwise, the most recent version from the main branch is used. Newly defined elements are introduced without version declaration, their version is derrived automatically from TIR contents and selected profile.

If a profile is not selected for a compilation and the currently compiled elements with same name are already in TIR, the compilation fails and the developer must perform it again with suitable profile selected.

The full description of TIR, profiles and version model of the specifications is provided in [TIR].

Connectors

Components are interconnected by connectors. The goal of connectors is to provide a support for software systems where all application components contain application logic only, while the connectors implement the necessary interaction semantics and cover deployment dependent details. Thus, connectors solve the deployment anomaly problem[con][conp].

In SOFA, connectors are first-class entities like components. Each type of connector implements semantics of specific type of interaction. A connector is described in a similar manner as a component - by connector frame and connector architecture.

The connector frame is represented by a set of role instances. A role is a generic interface of the connector intended to be tied to a component interface. The connector architecture describes connector internals. It can be simple (contains only primitive elements, directly implemented by the underlying environment) or compound (contains only instances of other connectors or components).

SOFA provides three types of predefined connectors (CSProcCall, EventDelivery, DataStream) and user-defined connectors.

Behavior protocols

Communication among SOFA components can be captured formally. Every method call or a return from a method call forms an event. In our communication model, events are atomic (e.g. they cannot be divided into several sub-events) and can be denoted by event tokens. For a method name m, event tokens !m^, ?m^, !m$ and ?m$ stand for emitting a method call, accepting a method call, emitting a return and accepting a return.

A sequence of event tokens denoting events occuring on a component form a trace. Thus, the trace <!m^; ?m$> describes activity of a caller (emitting a method call followed by accepting the return), while the trace <?m^; !m$> denotes what the calle does (accepting a call and emitting the return).

Behavior of a SOFA entity (interface, frame or architecture) is the set of all traces, which can be produced by the entity. In the case of interfaces, restricted form of event tokens is used (only m^ and m$ tokens are possible), because the role of emitor or acceptor of events is implicitly determined by the type of interface (provides or requires).

For example, let an interface I contain methods m, n. If the behavior of I is defined as {<m^; m$; n^; n$>, <m^; m$; n^; n$; n^; n$>}, it means that on the interface I, the method m should be called first, and then n should be called once or twice.

Let a frame F contain an instance i1 of the iterface I (instantiated as a provides interface ) and let the behavior of F be defined as {<?i1.m^; !i1.m$; ?i1.n^; !i1.n$>, <?i1.m^; !i1.m$; ?i1.n^; !i1.n$; ?i1.n^; !i1.n$>}. The meaning is the same as in the previous example, however the description is made from the point of view of the frame, not the interface.

Because behavior described as a (possibly infinite) set of traces is not very human-readable, we use the notation called behavior protocols. A behavior protocol is a regular-like expression on the set of all event tokens, generating the set of traces (behavior). A protocol generating behavior of an interface is called interface protocol, a protocol generating behavior of a frame is called frame protocol. Behavior of I and F from previous examples can be described by the following:

Prot-I = m; (n + (n; n))
Prot-F = ?i1.m; (?i1.n + (?i1.n; ?i1.n))

Here, "+" denotes alternative, ";" denotes sequencing and for a method name m, ?m is an abbreviation for ?m^; !m$.

Interface and frame protocols are written by a programmer into cdl. For example:

interface I {
   void m();
   void n();
   
   protocol: m; (n + (n; n))
};

frame F {
   provides:
      I i1;
   protocol:
      ?i1.m; (?i1.n + (?i1.n; ?i1.n));
};

There exists third type of protocols: architecture protocol. Architecture protocols are not written by a programmer, instead they are generated by CDL compiler from frame protocols of an architecture's subcomponents.

Having behavior description of SOFA entities, CDL compiler can check semantic consistency of a source code. More precisely, the compiler checks if a frame protocol conforms to the protocols of all frame's interfaces and if an architecture protocol conforms to the protocol of the architecture's frame.

SOFAnode

A single environment for developing, distributing and running SOFA applications is called a SOFAnode. A SOFAnode consists of several logical parts.

A SOFAnode is divided in five logical parts. The heart of a SOFAnode is a Template repository (TR). TR contains an implementation of components as well as their CDL description. The other parts provide the environment for developing of components (the MADE part - the CDL compiler, TIR, the code generator,...), for automatic distribution of components among SOFAnodes (the IN and OUT parts) and the runtime environment for launching component applications (the RUN part). Not all SOFAnode have to consist of all these parts.

One SOFAnode is not tied with one host - it can be distributed across a network.

The Figure 2 shows a sample scheme of several SOFAnodes connected to form a SOFAnet.

Figure 2. Scheme of sample SOFAnodes interconnected to form a SOFAnet

DCUP

The DCUP architecture is a specific form of SOFA components which enables their safe updating at runtime. It extends the component model with specific implementation objects and by a technique for updating a component at runtime.

A DCUP component can be divided in two parts - permanent and replaceable. The permanent part is not subject of the dynamic update unlike the replaceable part, which is specific for each version of the component (Figure 3).

Figure 3. Permanent and replaceable part of the component

The DCUP architecture introduces two control objects: Component manager (CM) and Component builder (CB). CM is the heart of the permanent part and is responsible for controlling the runtime lifecycle of the component. CB is responsible for building component internals (in the case of composed component - subcomponents, in the case of primitive component - implementation objects). Each version of the component has a specific CB.

References

[sofa] Frantisek Plasil, Dusan Balek, and Radovan Janecek. SOFA/DCUP: Architecture for Component Trading and Dynamic Updating. Proceedings of ICCDS 98, May 4-6, 1998, Annapolis, Maryland, USA. IEEE CS Press. 1998.

[TIR] Vladimir Mencl and Petr Hnetynka. Managing Evolution of Component Specifications using a Federation of Repositories. Tech. Report No. 2001/2. Dep. of SW Engineering, Charles University, Prague. Jun 2001.

[IDLJava] Object Management Group. IDL to Java Language Mapping. document formal/02-08-05. 2002.

[con] Dusan Balek and Frantisek Plasil. Software Connectors and Their Role in Component Deployment. Proceedings of DAIS'01, Krakow. Kluwer. Sep 2001.

[conp] Dusan Balek. Connectors in Software Architectures. Ph.D. Thesis, Charles university, Prague. 2002.

[conb] Lubomir Bulej and Tomas Bures. A Connector Model Suitable for Automatic Generation of Connectors, Charles university, Prague. Tech. Report. Dep. of SW Engineering, Charles University, Prague. Jan 2003.

[fractal] Fractal. http://www.objectweb.org/fractal/index.html.

[EJB] Enterprise JavaBeans Specification. Version 2.0. Sun Microsystems. 2001.

[CORBA] Object Management Group. The Common Object Request Broker: Architecture and Specification. version 3.0. document formal/02-06-33. 2002.

[DCOM] F. E. Redmond III. DCOM: Microsoft Distributed Component Object Model. IDG Books Worldwide, Inc.,Foster City. 1997.

A. Syntactic diagrams of CDL

The syntactic diagrams of CDL.