The Credo Methodology - Formal Methods for Components and Objects - page 52

less (or even single) input and output ports and structured data types, such as
disjoint unions. For the usage of structured data types we refer to the Ve r eo fy
user manual [11]. Fig. 7 depicts the CARML code for the client facade of a peer.
The interface of the client side facade has three input ports ( openCS , closeCS ,
and myAns ) and one output port ( myReq ). The variable status stores the current
state of the peer (initially idle ), while the variable trans stores an element from
the global data domain Data when the peer receives one (initially undefined ). The
server side facade of the peer is modeled analogously.

The network manager. We model the network manager in the scripting
language RSL which is inspired by the exogenous, channel-based coordination
language Reo [3]. Both Reo and RSL yield elegant declarative frameworks for the
specification of circuits, i.e., for the compositional construction of (dynamically
changing) component connectors by creating channels and gluing their channels
ends, the I/O-ports of components, or sub-connectors together. RSL's core lan-
guage features are (1) instantiation of modules and sub-circuits (via the RSL
command new ); (2) gluing instances together (explicitly via the RSL command
join , or implicitly by reusing port names); (3) forming a new prototype for en-
tities for a higher modeling level (via the arrays source and sink ); (4) defining
networks with dynamically changing topologies (via the RSL keyword TOPO ); (5)
and scripting features such as variables, loops, and conditional branching.

Client
myReq

Server
register

Server
openSS

registrationTable

Server
closeSS

A

R

request
buffer

release
buffer I J

B

C

RI[0]
RI[1]
RI[2]

AI[0]
AI[1]
AI[2]

Server
exAns

EXROUTER

P2PConnection

AO[0]
AO[1]
AO[2]

RO[0]
RO[1]
RO[2]

Client
myAns

Server
exReq

NetworkManager

Fig. 8. The network manager