User:Rroycho/sandbox

SOFtware Appliances (SOFA)component framework

The Researchers at Charles University in Prague used their experience in the field of object oriented programming and software systems and started designing a software environment which gives full provider-user relation.

A SOFA application consists of several different software components which are deployed on a common network such that they can be dynamically downloaded and uploaded.

SOFA consists of a lot of different software domains, some of them are: component management, component design, security, communications middleware, etc. Due to the presence of various domains, this leads to various issues like component transmission protocol, dynamic component updating, component versioning, component description and support for component trading, licensing, accounting and billing.

Component descriptions using CDL

In the SOFA component model, an application is considered as a composition of software components. The CDL which is based on CORBA IDL and Java syntax, is used to describe SOFA component's architecture, frame and interfaces.

A software component is an instance of a component template, which consists of template frame and template architecture. Frames specify the the services a component can provide to an environment and the services a component needs from the environment. While an architecture specifies the communication between a component and its subcomponent.

Interfaces are the lowest abstraction and they are used for individual services, which is characterized by a set of operations. CDL interfaces are enhanced with interface behavior protocols, which specify the acceptable order of method invocations for a given interface.

CDL template frames represent a higher level of abstraction. They present a black box view of components. A frame does not show the internal operations of the component. It specifies what services a component makes available provided those services are available. CDL frames define provides-interface and requires-interface of the component. There cannot be more interface instances of the same name in a frame.

Architecures in SOFA are called as gray box views of components. There are two types of architectures in SOFA CDL:

A Primitive Architecture has no internal structure and does not have description.

A compound architecture consists of subcomponents and description of their communication. The communication is described using ties. There are three types of ties:

• Bind- Bind is a tie of type requires-provides and represents an internal cooperation within a component.

• Subsume- Subsume is a tie of type requires-requires and represents relation between interfaces required from the environment and subcomponents.

• Delegate- Delegate is a provides-provides interface which represents the services a component fulfills which it has claimed.

CDL Example

 
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). Each element defined in CDL is stored by its name and specification version. A developer can specify references to a concrete version of previously compiled types stored in TIR. When type references do not have a version specified they are resolved to currently compiled version of referenced type stored in TIR. The version is selected on the basis of TIR contents and a profile. A profile consists of a list of identifications. 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

4. Newly defined elements are introduced without version declaration, their version is derived automatically from TIR contents and selected profile.

Behavior Protocols in SOFA

To keep the complex component system in a manageable and verifiable state, Behavior protocols were introduced to bound possible behavior of the three main abstractions in the CDL. The protocols for the three abstractions must be little different, but if they were based on the same basic conception then it would have been very useful.

The conception is based on conception model and consists of agents. The agents here are computational entities which exhibit actions such as emit or absorb external communication events or perform the internal ones. Each agent can perform bidirectional peer-to-peer communication with a finite number of other agents. Agents can be primitive or composed.

Activity is the finite number of actions that an agent exhibits on a finite number of connections. All possible activities exhibited by an agent on a set of connections are called behaviour of an agent on a set of connections. Trace is a sequence of action tokens.

Regular-like expressions over action tokens  are used to describe the behavior of an agent on a set of its connections. These expressions help to syntactically generate traces. The following operators can be used in such expressions:

• ✻ - repetition
• ; - sequencing
• + - alternative
• | - and-parallel
• || - or-parallel
• ⨅x- composition
• |T| - adjustment
• / - restriction

Particular Protocols in SOFA/DCUP

The general model of behaviour protocols can be applied to frames, interfaces and architectures. There must be a relation between interface, frame and architecture protocols.

Frame Protocols

Frame protocols specify the acceptable interplay of method invocations on the provided interfaces and reactions on required interfaces of the frames. The name of events are denoted by the name of methods prefixed by respective interface instance name and specifications, irrespective of whether the event is a request or a response. The role of the interface in a particular frame determines whether the event is a request or a response.

Interface Protocols

Interface protocols specify the acceptable order of method invocations on an interface. The behaviour of components on single interfaces only are represented by these protocols.The method names are used to denote the name of events.

Architecture Protocols

Architecture Protocols describe the interplay of method invocations on interfaces of the frame and the outmost interfaces of subcomponents in the architecture of a component template. These are inferred from architecture specification and are generated automatically by a CDL compiler by combining frame protocols of ties participants appropriately.

Protocol Conformance

The notion of protocol conformance was established using the notion of compliance. According to the notion of compliance, the way interfaces are utilized in frames must correspond to intentions interfaces were created with . Also, the architecture protocol of a component should follow the intentions described in the frame protocol of that component. The intentions behind three types of protocol conformance, precise definitions are described informally below:

Interface-interface protocol conformance

We can say that an interface protocol conforms with another interface protocol if the other protocol complies with it in an appropriate alphabet.

Interface-frame protocols conformance

Whatever is allowed by the interface protocol, it must be done in such a way that a components should be able to exhibit at least the events specified by the frame protocol on the requires-interfaces. It is vice-versa for the provides-interface. Whatever is allowed by the frame protocol on a provides-interface, it must be done in such a way that a component should be able to exhibit at least the events specified by the interface protocol.

Frame-architecture protocols conformance

An architecture protocol cannot generate traces which are not allowed by the frame protocol, under assumption that the provides-interface from the frame are used in the architecture in a way the frame protocol allows to. The architecture protocol can be less-demanding on the requires-interface.

Implementation and deployment of SOFA components

There are two parts in the development process of a component:

• creating a software specification
• implementing it later which can be done by independent vendors.

The whole component lifecycle has several stages:

• Designing the component’s architecture.
• Recursive binding of all the nested component frames to a concrete architecture. A component assembly infrastructure is used to select concrete subcomponents.
• Dividing the application into distribution units which results into a deployment form.
• Filling the form with exact location for execution resulting into a deployment descriptor.

A SOFAnode is a single deployment environment in SOFA. A SOFAnet is formed by a set of interconnected SOFAnodes. A SOFAnode can contain several parts, which may or may not be present in a single SOFAnode. The role of SOAnode in the SOFAnet determines which part should be present in the SOFAnode. In the following section we will describe the individual parts:

Template Repository (TR)

It contains component implementations together with their descriptions. It is the only mandatory part in all SOFAnodes.

Run-part

This part is supposed to be distributed across multiple hosts and it is responsible for providing environment for running the component instances.

Made-part

This part is used to create new components and insert them into the Template Repository.

Out-part

This part is used to transfer components from the SOFAnode.

In-part

This part is used to transfer components to the SOFAnode.

DCUP

The DCUP architecture is an extension of SOFA component model which allows dynamic updating. DCUP component has a permanent part which does not get dynamically updated and a replaceable part which is different for each version of the component. A CManager (CM) which coordinates updates is the main part of the component's permanent part. A CBuilder (CB) is responsible for building and terminating the replaceable part of the component.

With respect to operation, the component is divided into functional part and control part. The control part is used for managing purposes such as starting an update while the functional interface is the component interface described by SOFA model.