CSSA(ID:1314/css001)

Application language for INCAS 


for Computing System for Societies of Agents

Applications development language for INCAS, sibling language to Lady, but developed from an earlier serial version of the language


Structures:
Related languages
*MOD => CSSA   Influence
Act1 => CSSA   Influence
AMPL => CSSA   Influence
Argus => CSSA   Influence
CSSA => CSSA   Evolution of
LADY => CSSA   Co-development
NIL => CSSA   Influence
PLITS => CSSA   Influence
SR => CSSA   Influence

References:
  • Fischer, H. L. and Raulefs, P. "Design rationale for the interactive programming language CSSA for asynchronous multiprocessor systems," Institut fur Informatik III, Univ. Bonn, Memo. Seki-BN-7909, 1979. view details
  • Fischer, Hans Ludwig; Raulefs,Peter "Design Rationale for the Interactive Programming Language CSSA" pp111-124 view details
          in 6th GI-Workshop: Programming Languages and Program Development, Informatik Fachberichte, Vol. 25, Springer-Verlag, 1980 view details
  • Beilken, C. and Mattern, F. "The distributed programming language CSSA -- A very short introduction," Dep. Comput. Sci., Univ. Kaiserslautem, Internal Rep. 123/85, 1985. view details
          in 6th GI-Workshop: Programming Languages and Program Development, Informatik Fachberichte, Vol. 25, Springer-Verlag, 1980 view details
  • Nehmer, J. et al Key Concepts in the INCAS Multicomputer Project, IEEE Trans Soft Eng SE-13(8):913-923 (Aug 1987). view details Abstract: This paper gives an overview of the INCAS (INCremental Architecture for distributed Systems) multicomputer project, which aims at the development of a comprehensive methodology for the design and implementation of locally distributed systems. A structuring concept for distributed operating systems has been developed and integrated into the system implementation language LADY. The concurrent high-level programming language CSSA, based on the actor model, has been designed for the implementation of distributed applications. A substantial effort in the INCAS project is directed towards the development of a distributed test methodology. An experimental system has been implemented on a network of ten MC68000 microcomputers. Preliminary experience with the methodology has been gained from a small number of prototype applications. Extract: Two distributed languages
    Two distributed languages have been developed in the course of this project: the language LADY for the design and implementation of distributed operating systems and the high-level application language CSSA. The underlying philosophies of both languages date back to earlier research projects and take different approaches to structuring distributed software. Since any distributed operating system should be able to support different distributed application languages efficiently, we considered the implementation of a CSSA run-time environment in LADY as a challenge for the applicability of our design methodology. Extract: The LADY Language and Its Underlying Structural Concepts
    The LADY Language and Its Underlying Structural Concepts
    The LADY language reflects our view of an adequate structuring model for distributed operating systems. Experiences with early versions of LADY induced several iterations of the early concepts until the present design has been reached. The development of LADY has been motivated by the lack of expressive power with respect to higher level structures in present system implantation languages.
    The structuring concepts of LADY are expressed in terms of three language levels as illustrated in Fig. 3.
    Process and monitor modules constitute a team. Several teams and systems form a system. This system definition is recursive and allows nested system structures of any depth.
    LADY is a strongly typed language. Each description of a module, team and system type, is divided into a specification part and an implementation part, called the body of the respective type. The specification part describes the interface a type exports to its environment.
    These features promote the decomposition of programs into well-structured building blocks. Due to narrow interface specifications, these building blocks can be easily exchanged between different environments. This greatly supports the customizing of distributed operating systems using predefined building blocks.
    The fundamental structuring unit of LADY is the team. A team consists of a collection of tightly coupled processes which cooperatively perform a specific function. Processes within a team solely communicate via shared memory. Synchronization is achieved by using monitor modules or lower level primitives such as semaphores. Teams are distribution units, i.e., they have to be placed as a whole at one node. Different teams may be placed at the same node or at distinct nodes.
    Teams interact with other teams solely via message passing. The internal structure of teams is hidden by the encapsulation of teams by a port interface. The port concept in INCAS is symmetric: input ports define the message interface exported by a team, while output ports de
    ~ine the message interface imported by a team from-its environment. A process can send a message through an output port to a destination input port, only if a connection between the output and the input port has been established beforehand. A similar approach has been taken in the language NIL.
    Two types of connections between input and output ports can be defined:
    1) logical channels, which provide for a one-to-one link between an output and an input port;
    2) logical buses, which provide for a many-to-many link between output and input ports, thereby offering a multicast communication capability.
    Teams and systems as well as their interconnections can be dynamically generated and deleted. Teams are mobile; communication between teams does not depend on their location. The internal structure of a team is fixed at compile time and cannot be changed at run time.
    Extract: The Distributed Application Language CSSA
    The Distributed Application Language CSSA
    CSSA (Computing System for Societies of Agents) is an experimental high-level programming language for expressing distributed application algorithms which involve many loosely coupled cooperating tasks. In contrast to LADY, CSSA is a more abstract language where most details of synchronization and communication tasks are hidden from the programmer. Its underlying model of distributed computation is based on the notion of actors originally developed by Hewitt [16]. The object-oriented message-passing philosophy of the actor-model provides clean mechanisms for exploiting parallelism and is especially well suited to distributed computing at a higher level of abstraction.
    In CSSA, computations are performed by agents, which are active objects that communicate with other agents solely by message passing. There is no sharing of data among agents. An agent is an autonomous entity consisting of a cluster of operations that can be activated by sending messages to the agent. Each agent processes only one message at a time without interruption. Messages arriving at an agent while it is executing an operation are collected in a mailbox. Execution of an operation may result in any number of messages being concurrently transmitted to other agents with which the agent is acquainted.
    Agents can be created dynamically, and acquaintances with other agents may be transmitted via messages. Therefore, the agent-net, which illustrates the potential flow of information, may change dynamically during a computation. Many agents may be sending or receiving messages at the same time.
    The behavior of an agent is determined by its programmed script, which is an agent-schema containing operations. An agent may provide several clusters of operations. Such a cluster together with local variable declarations is called a facet. At any instance of time the behavior of an agent is uniquely determined by exactly one facet, the current facet. Facetting is accomplished by replacing the current facet by another facet. The new facet may provide some other operations or the same operations with different semantics. Therefore, facets allow the dynamic behavior of an agent to be structured.
    CSSA provides a powerful set of language features for expressing communication and parallelism. Its sequential structures and data types are similar to those of Pascal. Concepts of modularization and data-abstraction have been combined in a homogeneous way to allow a structured implementation of distributed applications.
    The programmer is only aware of the logical structure of the distributed system, and has no influence on the assignment of agents to processors. The physical network is made completely transparent by the underlying distributed operating system written in LADY.
    During a computation the user is part of the agent-net: he resides with a multi-window terminal or other I/O devices on a designated processor which is conceptually a specific agent, the so-called interface agent. It consists of a CSSA interpreter and is "programmed" dynamically by the user during the computation. In common with all other agents, the interface agent can send and receive messages from acquainted agents and create new agents. Beyond that, it comprises various features for debugging and testing distributed application programs.
    Extract: An Example of CSSA
    An Example of CSSA
    The following small program demonstrates how a distributed algorithm, the so-called echo algorithm [6], can be programmed in CSSA. The purpose of the program is to construct a graph and then to visit and mark each node.
    1.....script NODE is
    2.....defines KNOW, MARK, ECHO;
    3.....uses MARK, ECHO;
    4.....type AGENT_LIST is set of agent;
    5.....var AGENT_LIST: NEIGHBORS;
    6.....var agent: ACTIVATOR;
    7.....facet NOT_MARKED is
    8.....operation KNOW (int:I; array [1 . . I]
    9.....of agent: N) assert I > = 1 is
    10.....loop for J in 1 . . I do
    11.....put N[J] into NEIGHBORS;
    12.....endloop;
    13.....endoperation;
    14.....operation MARK(-- > ACTIVATOR)
    15.....assert not empty(NEIGHBORS) is
    16.....send MARK(self) to NEIGHBORS;
    17.....replace by MARKED;
    18.....endoperation;
    19.....operation MARK(agent: SENDER)
    20.....assert empty(NEIGHBORS) is
    21.....send ECHO(self) to SENDER;
    22.....replace by MARKED;
    23.....endoperation;
    24.....endfacet;
    25.....facet MARKED is
    26.....operation MARK(agent: SENDER) is
    27.....send ECHO(self) to SENDER;
    28.....endoperation;
    29.....operation ECHO(agent: A) is
    30.....remove A from NEIGHBORS;
    31.....if empty(NEIGHBORS)
    32.....then send ECHO(self) to ACTIVATOR;
    33.....endif;
    34.....endoperation;
    35.....endfacet;
    36.....initial NOT_MARKED;
    37 endscript

    When starting a CSSA computation, a single agent, the interface agent, already exists. All other agents must be created dynamically. At the terminal connected to the interface agent, the user interactively writes the following CSSA statements:
    var agent: ROOT: = new NODE; var agent: N2, N3, N4, N5, N6, N7; N2 := new NODE; . . .; N7 := new NODE;
    Now seven nodes have been declared and created. To build a graph, the user'sends every node a list of its neighbors:
    uses KNOW, MARK; send KNOW (2, N2, N3) to ROOT; send KNOW (1, N4) to N2; send KNOW (2, N4, N5) to N3; send KNOW (1, N6) to N5; send KNOW (3, N3, N5, N7) to N6; send KNOW (2, N2, ROOT) to N7;
    Because the node-agents are initially in the facet NOT_ MARKED (line 36 and lines 7 to 24) they will eventually receive the KNOW-messages and put their acquaintances with their neighbors in the set NEIGHBORS (line 11).
    The user'starts computation of the echo algorithm by writing "send MARK ( self ) to ROOT; " where "self" holds as a value an acquaintance with the issuing agent. The facet NOT_MARKED contains two definitions of the operation MARK, i.e., it is overloaded. The selection is made by the assertion. If the node has no neighbors, it immediately sends an ECHO (line 21) to the sender of the MARK-message, otherwise the MARK-message is propagated to all neighbors (linel6) and an acquaintance with the invocator is stored in the global variable ACTIVATOR (lines 6, 14). In either case the agent replaces the current facet by the facet MARKED (lines 17, 22). In this facet the operation acts differently: further MARK- messages are acknowledged immediately by an echo (line 27), whereas the echo to the activator is only sent after all neighboring agents have sent their echoes (line 32). Extract: Implementation of CSSA
    Implementation of CSSA
    The first ideas of a sequential version of CSSA originated in 1977; a concurrent version was first implemented for a multicomputer simulation system which served as a testbed for some small programs. Early experiments and careful examination of other high-level distributed programming languages such as SR, Starmod, PLITS, AMPL, Argus, NIL, and Actl resulted in some revisions of the CSSA language. As part of the INCAS project, a compiler running under UNIX and generating code for a virtual stack machine was realized. The run-time environment which consists of the virtual machine and an elaborated set of specific operating system functions is realized in LADY. These functions are provided by encapsulating each single agent in a separate team object of type agent server.
    Fig. 7 sketches the principal structure of such a team. One process is responsible for providing the virtual machine (realizing the run-time environment) and executing the compiled code of the agent. Buffering of incoming and outgoing messages is performed by dedicated processes and two monitors. A CSSA message is packed into fixed-length LADY messages and the agent server processes take care of synchronization and flow control to guarantee reliable communication of CSSA messages. Other processes and monitors not shown in the figure are responsible for local I/O, memory management, debugging capabilities, pattern- matching, and administration of the mailbox.
    The port interfaces are used to connect the agent server team to other agent servers, the interface agent, and various LADY teams realizing other functions of the distributed operating system (e.g., window management, configuration management, and file administration). Corresponding to the creation and deletion of CSSA agents, agent servers can be created or deleted. Depending on the operating system's management strategy, unused agent servers can also be preserved for subsequent agent creations. A comparison to a recently completed implementation of CSSA on a network of UNIX systems shows that our scheme of agent creation is several times more efficient than process creation under UNIX.


          in 6th GI-Workshop: Programming Languages and Program Development, Informatik Fachberichte, Vol. 25, Springer-Verlag, 1980 view details