Law-Governed Linda(ID:7806/)


Controls Linda spaces with the Law of Demeter to make a coordination model


Related languages
DEMETER => Law-Governed Linda   Incorporated some features of
Linda => Law-Governed Linda   Enhancement of

References:
  • Naftaly H. Minsky, Jerrold Leichter. Law-Governed Linda as a Coordination Model. Technical Report. view details Abstract: Linda is a very high level communication model which allows processes to communicate without knowing each other's identities and without having to arrange for a definite rendezvous. This high level of abstraction would make Linda particularly suitable for use as a coordination model for open systems, if it were not for the fact that the Linda communication is very unsafe. We propose to remove this deficiency of Linda by means of the concept of law-governed architecture previously applied to centralized and message passing systems.
    We define a model for Law-Governed Linda (LGL) communication, and we demonstrate its efficacy by means of several illustrative examples.
  • Naftaly H. Minsky, Jerrold Leichter Law-Governed Linda as a Coordination Model July 1994 Selected papers from the ECOOP'94 Workshop on Models and Languages for Coordination of Parallelism and Distribution, Object-Based Models and Languages for Concurrent Systems view details
  • Law-Governed Regularities in Object Systems; part 1: Principles. Naftaly Minsky Published in Theory and Practice of Object Systems (TOPAS) (John Wiley) Vol II, No. 4, 1996; view details
  • Naftaly Minsky and Partha Pal "Imposing The Law of Demeter and Its Variations" the TOOLS Conference, Aug 1996, Santa Barbara, CA, USA view details
  • Naftaly Minsky and Partha Pal "Law-Governed Regularities in Object Systems; Part 2: the Eiffel Case" In Theory and Practice of Object Systems (TOPAS) (John Wiley) 1997; view details
  • Barbosa, Fernanda and Cunha, José C. "A coordination language for collective agent based systems: GroupLog" pp189-195 view details Extract: Extensions to GHC
    GroupLog defines extensions to the Extended Horn Clause
    language (EHC) [29], that are supported at two levels: L1,
    defines agents as program units and L2 defines groups of agents.
    A GroupLog system contains concurrently executing
    agents able to: (1) communicate through interface predicates,
    and (2) join groups to coordinate their activities. In
    the following, we first summarize EHC (see [29]), and then
    describe the two mentioned levels. Extract: GroupLog and other work
    Related Work
    Recently, models have been proposed based on coordination concepts aiming at integrating a number of components together such that the collective set forms a single application that can take advantage of distributed systems.

    Many proposals extend a base logic language for concurrency, communication and non-determinism. The base language may be Horn Clause Logic, Temporal Logic, Linear Logic or Situation Calculus. In the first case, we have Rose, DeltaProlog, MultiProlog. In the second, MetaTem. In the third, COOL and IAM and in the last case ConGolog. Specification of concurrency has also been introduced jointly with an objectoriented model such as in DLP, CSO-Prolog, ShaDE, IAM and COOL.
    The motivation to use EHC as the base language for GroupLog is due to its elegant interpretation of a process interaction and its rigorously defined semantics. The dynamic entities of a program can be modeled by: Processes, as April and MultiProlog; Objects, as ShaDe, Law Governed Linda, IAM, ColaS, Electra and Emerald; Agents, as ConGolog, COOL, MetaTem, Agentspeak, 3APL and Placa; Actors, as Concurrent Aggregates and Synchronizers.

    The interation between dynamic entities can be modeled by: Sending messages, as ShaDe, ConGolog, Concurrent Aggregates, IAM, AgentSpeak, COOL, MetaTem, April, Placa and Electra; Shared tuples, as GammaLog, PollS, Law-Governed Linda, MultiProlog and ESP.

    L1 vs others models
    In L1, we structured the concurrency and communication with the agent notion, but this language does not aim to provide a theory to model the mental state of an agent, as in MetaTem, ConGolog, AgentSpeak, 3APL and Placa. The agent behavior is only dependent on the interface predicates and its configuration, i.e. the entities are reactive and act in accordance with the interaction and its configuration, like in the actor model. This behavior is modeled by EHC clauses, with a very similar interpretation to the rule based one in AgentSpeak and 3APL. In L,, one simple form of communication is allowed: the explicit invocation of interface predicates. The notion of agent in L, integrates the logic aspect with the object-oriented model, as in [11]. In this model it is possible to model blackboardbased systems, which is only allowed in GroupLog in L2.

    L2 vs others models
    The definition of groups in GroupLog was the result of an incremental development process which started with our early experimentation with the ISIS system. Groups allow the modeling of a cooperative entity and the dynamic evolution of a system. A group can be created or destroyed, as its members can join or leave the group at any time. The group members are hidden from the outside environment. Because a group is a meta-agent, it is possible to have a group as a member of another group, so this allows the composition of the group notion, as the context notion defined in [7]. In a group we allow two forms of communication: by invocation of interface predicates or through the shared group state. So, L2 is also an experiment towards unifying distributed-memory (remote predicate call) and shared-memory models (shared data). In some of programming languages, like MetaTem, COOL and Concurrent Aggregates, the group notion is used to restrict the communication to a certain group of agents, which may alleviate some of the inefficiencies that occur in full broadcasting.
    In other languages, like Electra, Emerald, Synchronizers and Colas, the group is seen as a logical unit that manipulates and restricts the invocation of the members group interface. In Syneronisers, the notion of coordination is modeled by a special object (synchroniser) that restricts the invocation of the group of objects using constraints. In most of these programming languages, as in GroupLog, the group is a dynamic entity. But in Synchronizers and Colas it is possible to dynamically change the coordination behavior, which is not possible in GroupLog.

    In GroupLog, as in Electra and Emerald, the members of the group perceive a consistent view of: (1) the other agents who are also part of the group and (2) the shared state.

    The main difference between GroupLog and these languages is the group interface predicates, that may be distinct from the group members individual interface. In languages where the communication is modeled by shared-memory, like ESP and PoliS, the communication structuring is done by allowing multi-tuple spaces. In ease of PoliS there are hierarchical tuple spaces. The L2 level of GroupLog supports the structuring of the tuples space into multiple parts, as each is naturally encapsulated within a specific group such that only its members are allowed to access the group state.
    This is a good approach to address both modularity, information-hiding, and scalability concerns in large-scale real applications.

          in Proceedings of the 2000 ACM Symposium on Applied computing SAC'2000 Villa Olmo, Como, Italy view details
  • Naftaly H. Minsky; Yaron M. Minsky; Victoria Ungureanu "Making tuple spaces safe for heterogeneous distributed systems" pp218-226 view details DOI
          in Proceedings of the 2000 ACM Symposium on Applied computing SAC'2000 Villa Olmo, Como, Italy view details