Information Technology Reference
In-Depth Information
different objects further, because the plan chosen to achieve a given goal is only
important for the object itself, not for the invoking agent.
3.1 State-Filtering in Publish / Subscribe Systems
As mentioned above, publish subscribe systems are used to enable indirect com-
munication between publishers and subscribers of events. That is, the system
sends messages to all registered subscribes on all events triggered by the pub-
lisher. Ex. 1 shows a simple scenario serving as running example.
Example 1. Assume a simple lamp, which can be turned on and off, and whose
dim value can be changed. Those actions result in events of the following form,
distributed via the publish / subscribe system:
(Lamp3 (on true))
or
(Lamp3
(on true) (dimValue 0.5))
Subscribers can register for such events using for
example the following filter:
($on = true) || (dimValue >= 0.5)
with
$
in-
dicating event keys and
||
denoting a logical or.
◦
By assuming a certain format of the event description, we are able to actually
track the state of the producing objects. In our architecture we use events con-
taining key-value pairs as shown in Ex. 1. We furthermore, assume that all keys
represent state properties of the sender and that the corresponding values carry
the value of that property at the time of the event. Finally, we assume that all
events carry the unique ID of the sender (
Lamp3
in the example above). These
assumptions allow to track the state of the published objects.
Based on this state tracking mechanism, we are able to include the state of
other objects into the filters specified in the publish/subscribe system. In our
system, the state of other objects can be access using the following syntax:
$on@Lamp2 = true
stating that the property
on
of the object
Lamp2
must be
true
. Unfortunately, there is no guarantee that the publisher actually is in the
state perceived by some subscriber. This is due to the facts that there might be
no guarantee of message delivery and there usually is a delay between sending
and receiving the message. Nonetheless, the perceived state coincides with the
subscribers belief of the publisher's state.
3.2 Goal-Based Interaction with Objects
In object orient programming, the world is modelled using objects, which are
characterised by their attributes and methods. Interaction with objects usually
means to invoke methods. As argued above, this paradigm is not necessarily
adequate while developing heterogeneous and dynamic ensembles. We apply the
idea of goal-based interaction to objects. Assume that every object knows how
to bring about a certain internal state. Therefore, we should interact with such
objects not by invoking methods, but by asking to achieve a certain goal.
Example 2. To set the dim value of a lamp to 0.5, we would normally invoke the
following methods on it:
(turnOn Lamp3) (dimLight Lamp3 0.5)
The lamp is
