Distributed Artificial Intelligence

Problems and Constraints in SOAP, RESTful, and WoT Approaches

SOAP and RESTful are based on the concept of web resources and enable access to a service as an abstraction of a web resource via simple HTTP "GET" requests.

However, there are some problems with object-based and WoT (Web of Things) approaches:

• No event management
• No consideration for autonomous components
• Not very open
• No suitable coordination tools

For WoT RESTful, there is a misconception that there is no state. However, actuators do have a state, such as a window being either open or closed.

In an IoT (Internet of Things) scenario, there are coordination constraints due to:

• Constraints on the relative activities of sensors and actuators
• Safety constraints: conditions that must never occur in the system
• Liveness constraints: conditions that must always be guaranteed

Some services require the coordinated triggering of activities in multiple devices.

IoT middleware is needed to enable devices to interact and coordinate with each other in order to provide composite services.

• services involving multiple devices.
• Ensuring safety and liveness constraints.
• Support interoperability, security and event management.

IoT middleware can be based on different architectural solutions: centralized, decentralized, edge.

Interoperability, security and event management:

The different architectures proposed by companies try to address different problems:

• Interoperability: middleware that enables talking with different communication protocols, and guarantee security.
• Integrate access control policies: mechanisms to check integrity of data.
• Event management: integrate mechanisms to capture events at the device level (no longer a pure RESTful solution), and handlers to react to them. Reaction to events can imply triggering other services.

Centralized architectures are the easiest to handle such issues.

Coordination in IoT Middleware:

The middleware has to either:

• Integrate a discovery service that enables to discover what devices are around and what services they provide.

1. minimize the degree of coupling between components, especially needed in dynamic environments, where processes/agents might not know a priori each other.
2. Distributed Object-based coordination/computation limitations:
• It is based on client-server interactions with clear distinction in roles between processes.
• The process structure determines the program structure. No explicit design of interactions, no explicit design of coordination rules/constraints.
• Processes must know each other and their location and characteristics.
3. Therefore:
• Limited openness.
• Hard to deal with dynamic environments.
• Impossible to deal with autonomous components.
• Conceptually not scalable.
4. Coordination Models and Languages
5. Concurrent/Distributed Programming = Computation + Coordination:
6. To solve the previous limitations, we need to divide computation and coordination (coordination includes communication and synchronization).
7. Model:
• The model is a Triple :: Coordinables, or entities being coordinated.
• : Coordination media,

used to coordinate the entities.- : Coordination laws, that is the semantic framework of the model.

Coordination language:

The coordination language is a language by which it is possible to use a coordination media to program the coordination laws. The coordination system has a middleware to support the model.

Coordination languages must support:

• Encapsulation: separation between computation and coordination.
• No need to know the details of processes.
• They can be autonomous and intelligent, with decision making.
• Distribution and transparency.
• Also decentralization.
• Dynamics and Adaptivity.
• No need to link the activities and the roles of processes before run-time.
• Dynamic adaptation of coordination schemes.
• Interoperability and Openness.

Distributed Artificial Intelligence Pagina 79

Leading Coordination Models and Languages:

• Tuple Space Model: coordination through a Shared Data Space.
• Event-based Models: extension to Tuple Spaces.
• Multiagent Protocol Systems.

The language to interact via Tuple Spaces is Linda. It is a language that defines the primitive operations by which the processes can interact, inserting or retrieving data objects (called Tuples) from the Shared Data Space (called Tuple Space).

The tuple space is a multiset or a "bag of tuples", so an unstructured database in which we put a tuple that does not have any relation.

The processes can put or retrieve tuples in the tuple space.

Tuple Space:

• Any process can store whatever it wants in the tuple space.
• A process can read tuples from the tuple space by searching specific types of tuples.
• A process can extract tuples from the space.

Tuples:

A tuple is a structured series of typed fields. Ex: ("a string", 15.01, 17).

Operations:

• +: insert a tuple into the tuple space (non-blocking).
• -: if there is a tuple from the tuple space matching the template tuple ("antituple"), it finds and removes it (an antituple specifies the characteristics of the tuple to be removed).

The tuple in which the process is interested).

• If a tuple that corresponds to the characteristics of the antituple is found in the tuplespace, that tuple is extracted.
• If no tuple is found, the process blocks until a matching tuple is found.

: like , but the is not removed (also here we have blocking).

- : tests the existence of a tuple without blocking.

Tuple Matching:

denotes the number of fields in the antituple .

A tuple given in a or operation, matches a tuple in the tuple space if:

1. and have the same number of fields.
2. And for each field:
1. If is a value, then
2. Or if is of the form , then is a valid value for the type of variable .
3. Or if is of the form , then is a valid value for the type of variable .

Ex. of Tuple Matching:

The second element of needs to be an integer to have a match. The value becomes the valueof the tuple matched (ex: ).

Programming Distributed and DAI Applications with Linda

With Linda, we can replicate most of

The functionalities of message-oriented and client-server or object-based systems can be achieved using tuple space as a more general means of realizing dynamic and open forms of interaction. In tuple space, processes have the freedom to be/do whatever they want, as long as the rules of coordination are enforced by the tuple space.

Scenarios:

1. Sending and Receiving Messages: Tuple space can be used to simulate communication channels between two processes. Message-passing involves the use of targets (to-from), tag (ID), and communication (data), which can be inserted into a tuple in Linda.

2. Concurrent Processes: Multiple processes can execute the same task by retrieving the tuple representing the task from the tuple space. There is no need to know in advance how many processes are involved.

   Masters and Workers:

   1. A master process divides work into discrete tasks and puts them into the tuple space.
   2. Workers retrieve tasks, execute them, and put the results back into the tuple space.
   3. Workers notify the completion of work.

Adaptivity:

Workers:

• Can autonomously decide to take a task or not.
• No matter if some of the worker crashes or disconnects.
• No need to know who the masters are.

Masters:

• They can autonomously decide to not publish some of the tasks (if they can accomplish the task by themselves).
• They do not need to know who the workers are.

Barrier Synchronization:

Each process within some group must wait as a "barrier" until all processes in the group have reached the barrier; then all can proceed.

Considerations

Linda and Tuple Space Coordination achieve:

• Time uncoupling: enables communication between time-disjoint processes. There is no need for two processes that interact by a tuple space to coexist at the same time.
• Space uncoupling: there is no need to share a process name space, so no need to know

each- other the name while interacting.Processes only need to agree on the structured naming of tuples.

- Adaptivity: good non-determinism (in multiple tuple matching).

-Linda Limitations:Events: we need to capture events also without the need of polling the tuple space.

- The language is intuitive, but minimal: real world implementation adds several features to- make it useful in real-world.

Implementation: we need a tuple space implementation with the absence of shared memory in- distributed systems.

Security: we need to have access rights and confirmations in the access of tuple spaces.

- Programmability of Coordination Laws: we need to have the possibility to change the basic- matching rules to support different schemes (in Tuple Spaces a tuple matches a template only ifit has the same values for the fields).

Handling Events:A problem of Linda is that a process, to get information from a tuple space, should perform a- operation or a operation, so it is forced to poll the tuple space.