Information Technology Reference
In-Depth Information
facade
Peer
inherits
ClientSide , ServerSide
begin
1
update
<>
(
in
keyList : List [Data ])
// async event
2
end
3
The network manager does not keep a centralized account of all port bindings;
these are locally stored at each component. A component cannot directly change
its port bindings. Before using ports, the component must request a connection
by raising an open session event. An event for closing the session implies that
the ports are ready to be disconnected. When requesting to open a session or
reporting the end of a session the ports used in that session are send as param-
eters. In addition to the ports, events can have extra parameters, e.g., the 'open
client session' event (written as
openCS
) provides the key to the data it is looking
for as additional information to steer the connection process. Based on the data
key the network manager can set up a connection to a server that holds the
requested data.
Events are by default asynchronous. However, when expecting return values
(e.g., opening or closing a session), we declare events to be synchronous (using
the keyword
sync event
). All events raised by the components are handled by the
network. This is reflected in the structural interface description of the network.
Network.
We give the structural interface description of a particular network
manager called
Broker
.Thekeyword
networkmanager
is used to identify such
interfaces (and distinguish them from those characterizing component facades).
The
Credo
methodology distinguishes between the concept of a network manager
and the network itself because a network in general consists of a network manager
and additional coordination artifacts like
channels
, as described later in this
section.
The description of the
Broker
declares the event handlers that it provides. For
each event handler, it specifies the facade (representing a component) from which
the handled event originated using the keyword
with
.
networkmanager
Broker
begin
1
with
ServerSide
2
register
<>
(
in
keyList : List [Data ])
3
sync event
openSS
<
in
req : inport , ans : outport
>
()
4
sync event
closeSS
<
in
req : inport , ans : outport
>
()
5
with
ClientSide
6
sync event
openCS
<
in
req : outport , ans : inport
>
(
in
k:Data;
out
f : Bool )
7
sync event
closeCS
<
in
req : outport , ans : inport
>
()
8
with
Peer
9
update
<>
(
in
keyList : List [Data ])
10
end
11
2.2 Behavioral Interface Description
The behavioral description for a component facade specifies the order of raising
events and the port operations. This is modeled using constraint automata [4].
In these automata, we denote port operations by port names. The corresponding
