Information Technology Reference
In-Depth Information
Request queue
Composite component
(Content)
N
primitive
component
Execution Thread
(serving requests)
Itf
[
N
.
itf
,
N
.
itf
]
∈
bindings
Itf'
N'
primitive
component
Internal
Interface
External
Interface
Server
Interface
Client
Interface
(Membrane)
Results
Fig. 1.
component composition
Fig. 2.
component structure
external (resp. internal) interface will be transmitted - unchanged - to the cor-
responding internal (resp. external) client interface.
The GCM model allows for a client interface to be bound to multiple-server
interfaces. For the moment, in our model, we restrict the binding cardinality
such that bindings connect a client to a single server. Note that several bindings
can anyway reach the same server interface.
Figure 1, shows the structure of a composite component. The composite com-
ponent contains two primitive subcomponents
N
N
. The binding (
N.
and
itf
,
N
.
itf
) connects the client interface
itf
of subcomponent
N
to the server inter-
face
itf
of subcomponent
N
.
Communication Model.
Our GCM-like components use a simple communi-
cation model relying on asynchronous request and replies, as presented in [13].
Communication via requests is the only means of interaction between compo-
nents. We avoid shared objects or component references, and use a pass-by-copy
semantics for request parameters. A component receives the requests on its ex-
ternal server interface. The received requests are then enqueued in the
request
queue
, which holds the messages until they can be treated.
Our communication model is asynchronous in the sense that the requests are
not necessarily treated immediately upon arrival. Requests are only enqueued
at the target component, then the component invoking the request can con-
tinue its execution without waiting for the result. Enqueuing a request is done
synchronously but the receiver is always ready to receive a request. To ensure
transparent handling of asynchronous requests with results, we utilise
futures
.
Futures are created automatically upon request invocation and represent the re-
quest result, while the treatment of the request is not finished. Once the result of
the computation is available, the future is replaced by the result value. Futures
are first class objects: they can be transferredaspartofrequestsorresults.
Figure 2 gives the internal structure of a component. Incoming requests are
enqueued in the
request queue
. The requests are dequeued by the execution
threads, when computed; the results are placed in the
results list
.
