Our Coordination Model: STL

The coordination model of STL (Figure 2) shares few characteristics with the IWIM [Arbab1996] model of coordination. It comprehends five building blocks (details in [Krone et al. 1998]):

• Blops, as an abstraction and modularization mechanism for processes and ports. It serves as a separate name space as well as an encapsulation mechanism for events. Blops have the same interface as processes, i.e., a name and a set of ports. The creation of blops is handled in the same way as the creation of processes. It includes the initialization of all processes and ports defined for this blop and subordinated blops.
• Processes, as a representation of active entities. A process is a typed object, it has a name and a set of ports. Processes in STL do not know any kind of process identification, instead a black box process model is used. Process termination is implicit.
• Ports, as the interface of processes/blops to the external world. Every communication in STL is handled via a connection which is the result of ports matching. A port has a name and a set of well defined attributes: they are referred to as the port's signature. The combination of port attributes results in a port type. Examples of port attributes are saturation or communication. The former attribute defines the number of ports that may connect to it. The latter attribute relates to the communication paradigms that can be chosen: blackboard, group or stream. Several port types exist: the BB type (which has a tuple space semantics à la Linda), the Group type and P2P type (point to point) [Krone1997]. Variants of these types can be defined by the user. Thus, we introduced several variants of the P2P port type: P2P_i and P2P_o ports are respectively input and output P2P ports with saturation set to 1; P2P_iN and P2P_oN are respectively input and output P2P ports with saturation set to N. To match, pairs of ports must have compatible signatures, thus introducing a sub-typing relation on port signatures [Krone et al. 1998].
• Events, as a mechanism to dynamically react to state changes within a blop. They can be triggered using a condition operation on a port. STL provides some conditions such as unbound, isfull or accessed.
• Connections, as a representation of connected ports. Their semantics depend on the port types.

  
Figure 2: The Coordination Model of STL.

According to the general characteristics of what makes up a coordination model and corresponding coordination language, these elements are classified in the following way:

• The Coordination Entities of STL are the processes of the distributed application, implemented as threads;
• The Coordination Media of STL are the following: events, ports and connections serve as the medium which enables coordination, and a blop is the medium in which coordination takes place;
• The Coordination Laws are defined through the semantics of the Coordination Tools and the semantics of the interactions with the coordination media by means of events.

STL materializes the separation of concern as it uses a separate language exclusively reserved for coordination purposes and provides primitives which are used in the computation language to interact with the entities to be coordinated. As far as the implementation of these primitives is concerned, we use PT-PVM[Krone et al. 1996] a software platform for programming multi-threaded applications on a cluster of workstations as the underlying communication and process management platform.