Information Technology Reference
In-Depth Information
and futures. Creol also offers components; the paper [12] presents a framework
for component description and test. A simple specification language over commu-
nication labels is used to enable the expression of the behaviour of a component
as a set of traces at the interfaces. Creol's component model does not support
hierarchical structure of components. In [2], the authors present a formalisation
of the interface behaviour of Creol components. Creol's operational semantics
uses the rewriting logic based system Maude [19] as a logical support tool. The
operational semantics of Creol is expressed in Maude by reduction rules in a
structural operational semantics style enabling testing of model specifications.
However, this kind of logical embedding does not support structural reasoning.
2.2
Component Model Overview
Our intent is to build a mechanised model of the GCM component model [4], but
giving it a runtime semantics so that we can reason on the execution of compo-
nent application and their evolution. Thus we start by describing the concepts
of the GCM which are useful for understanding this paper. We will try in this
paper to distinguish clearly structural concepts that are proper to any hierar-
chical component model and a runtime semantics that relies on asynchronous
requests and replies. Structurally, the model incorporates hierarchical compo-
nents that communicate through well defined interfaces connected by bindings.
Communication is based on a request-reply model, where requests are queued at
the target component while the invoker receives a future. The basic component
model has been presented in [13] and is summarized below.
Component Structure.
Our GCM-like component model allows hierarchical
composition of components. This composition allows us to implement a coarse-
grained component by composition of several fine-grained components. We use
the term
composite component
to refer to a component containing one or more
subcomponents
. On the other hand,
primitive components
do not contain other
components, and are leaf-level components implementing business functionality.
A component, primitive or composite, can be viewed as a container comprising
two parts. A central
content part
that provides the functional characteristics
of the component and a
membrane
providing the non-functional operations.
Similarly, interfaces can be functional or non-functional. In this work and in the
following description, we focus only on the functional content and interfaces.
The only way to access a component is via its interfaces.
Client
interfaces
allow the component to invoke operations on other components. On the other
hand,
Server
interfaces receive invocations. A
binding
connects a client interface
to the server interface that will receive the messages sent by the client.
For composite components, an interface exposed to a subcomponent is referred
to as an
internal
interface. Similarly, an interface exposed to other components
is an
external
interface. All the external interfaces of a component must have
distinct names. For composites, each external functional interface has a corre-
sponding internal one. The implicit semantics is that a call received on a server
