DOC - ECE

tenuousdrunkshipInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

76 εμφανίσεις

ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

Liaisons

Project

Report

Yamuna Krishnamurthy


1

Introduction

The goal of pervasive computing is the seamless integration of computation and
communication. Achieving this goal requires successfully tackling its two main
characteristics of heterogeneity and dy
namicity. Heterogeneity exists both in the
hardware (different kinds of sensors, nodes) and the software (operating systems,
network protocols) realms. This makes a consistent information discovery, processing
and reaction very difficult. Past research has

addressed the issues of heterogeneity at
various levels
[1]
[2]
[3]
. But achieving true homogeneity across all aspects is almost
impossible and more importantly not recomm
ended.


Dynamicity is the other defining characteristic of a pervasive computing environment as
it is a combination of both wired and wireless infrastructure. This implies that the various
sensors and actuators enter and leave the system arbitrarily thereb
y constantly changing
the topology. It is imperative that this entry and exit be as seamless as possible to the
applications executing in the environment. Emerging ad
-
hoc network routing protocols
have tried to address this issue
[4]
[5]
.



Pervasive environments through their heterogeneity and dynamicity create a ubiquitous
information grid that applications can leverage. However, ease and efficiency of locating,
accessing and leveraging this informa
tion to perform some useful task calls for new
programming and infrastructure management paradigms. Technologies like Jini
[6]
,
provide a robust solution to create virtual homogeneous communication environments
b
etween various participants of a pervasive computing environment. But these
technologies are somewhat restrictive in their scope as they allow flexible interfacing to
pre
-
configured services which requires the download of customizable objects onto the
clie
nts in order to communicate with the services. The customization is limited by the
scope of the services offered. Also, since the service addressing and location management
is centralized, it does not lend itself well to dynamically changing pervasive
envi
ronments.


The programming paradigms should allow ad
-
hoc interactions between various elements
of the application and provide a management infrastructure that allows these elements
adapt to the changing environment. They should also be context and content
aware to
aggregate the diverse information available to avoid burdening applications with
redundant information. Models built on content
-
based discovery and routing provide a
solution to this problem. Meteor
[9]

i
s one such model. Meteor defines
associative
rendezvous (AR)
as an abstraction for content
-
based decoupled interactions.
Cascading
local behaviors
then build on associative rendezvous to enable opportunistic application
flows where flows emerge as a result

of context and content based reactive behaviors.
The sensor and actuators communicate their interests and data descriptions
ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

correspondingly to the AR through profiles and the consequent reactive behaviors
specified in the messages. The profiles are a set
of rules that are processed by a rule
engine that is part of the Meteor framework. The rules and actions are predefined and
may be simplistic for some data aggregation algorithms like those used for target tracking
and recognition that process streamed vid
eo data or perform filtering to reduce resolution.



We would thus like to extend the
data processing capability of
Meteor framework by
introducing the concept of
Liaisons
. A
Liaison
, as the name suggests, would be a trusted
agent responsible for establis
hing and maintaining mutual understanding and cooperation
between two entities. These two entities can be any two trusting parties that allow the
other to upload its liaison and allow it to execute in its context. The liaison embodies the
requirements of t
he entity it originates from and gathers and processes that information in
the context it is currently executing in. It then communicates these requirements back to
its parent in a language they mutually understand.


This project’s goal is to architect a L
iaison management framework, in the context of
Meteor, which enables the consumers subscribing to the associative rendezvous points, to
upload their liaisons as part of their subscribing process. The liaisons in turn have the
onus of communicating with th
e consumers (who are their parents) whenever the events
that the parent is interested in occurs. The liaisons would enhance the rule based
subscription mechanism that already exists in Meteor and make the interaction between
the consumers and ARs functiona
lly richer.


The rest of the report is organized as follows: Section
2

enumerates the motivation for a
Liaison Framework;
Section
3

discusses related work;Section
4

provide
s design de
tails of
the Liaison framework;
Section
5

looks at the implemen
tation of the Liaison framework;
and finally we conclude with Section
6
.

2

Motivation

Liaisons work as façades or proxies fo
r the
ir originators.
The following are some
of the
advantages
that motivate

the

need for such

facades:

Process at or close to content



In sensor and ad
-
hoc wireless networks the cost of
transmitting data is higher than local computation costs in terms of energ
y usage. Hence
it is preferable to move processing as close to the content as possible and transmit only
the processed data back to the interested parties.
[12]
provides a similar solution but
unlike the Liaison framework, targe
ts purely sensor networks. Liaisons can be deployed
in any environment that has computational nodes

both wired, wireless and hybrid
.


Rule based processing insufficient



Rule based data aggregation is sufficient when the
aggregation is simple like summat
ion, average etc. But for more involved operations like
signal processing, pattern recognition or data formatting the rule engines are insufficient.
Since implementation of Liaisons is not restricted to a specific language, they can
perform more involved d
ata processing in a suitable language as long as a compatible
Liaison
S
ubstrate
(LS)
, described in Section
4.2

is available.



ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

Processing based on client characteristics



Though aggregation is the more common
in
-
network process
ing there could be other relevant data processing based on the
characteristics of
both data and
the client interested in the data. For e.g. if the client has a
small
display
screen then the data must be formatted before sending to the client.
Liaisons prov
ide the bridge between data and client as they are aware of both the client
and data characteristics.


Mobile Agent

System


The Liaison
framework
provides the infrastructure to realize
a
mobile agent
framework where the migrating liaison

is

a mobile agent
.

The migration
path can be specified as part of the profile, in the absence of which the liaison is migrated
across all existing Liaison Substrates.



Surrogate Computing
/Process Migration



Surrogate computing and process migration
is required under foll
owing conditions:



When
a device has limited
processing
capabilities

like cell phones, PDAs



Limited power
capabilities like sensors



For load balancing

and fault tolerance

in distributed computing

The programs and processes that need to be transferred can be

bundled as a liaison with
all the relevant information
to resum
e execution on a different host that has a compatible
Liaison Substrate.

3

Related Work


This work has been influenced by
other
work
in

mobile agent systems like OMG’s
Mobile Agent Facility
[10]

and JXTA’s Java Mobile Agents
[11]
.
[10]

proposes a mobile
agent framework using the CORBA
[2]

communication model.
[11]

provides the design
for a mobile agent system using the JXTA peer
-
to
-
peer framework.
Liaisons differ
fundamentally from a mobile agent in that while an agent is usually deployed to
autonomously gather information from hosts specified in its migrati
on path and return to
the parent, the liaison is deployed to process information at the host that has
content

its
parent is interested in and communicates interactively with its
parent
.
M
obile agents
require a migration path to be specified which is usuall
y the location of the host in the
network. Liaisons
migrate based on
t
h
e data interests

of its
originator
.


This project is also similar to the work in
active networks
like SensorWare
[12]

and
DFuse
[13]
.

Sensor aware proposes a run
-
time environment on the sensor nodes that
executes the application specific portable control scripts

that are deployed to the sensors
.
The resources on the nodes are abstracted by the run
-
time environment with common
interf
aces to ensure portability of the scripts across different kinds of sensors.

The scripts
however are restri
cted to TCL scripts

and
the run
-
time environment is designed for
sensors.


The Liaison Framework is

very similar to the DFuse
approach where data fun
ctions,

synonymous to

Liaisons
,

are deployed on mobile devices in a given area a
s per the task
graph specified. The motivations for DFuse overlap the motivations for the Liaison
Framework.
However, DFuse assumes that each device is aware of th
e other devic
es in
ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

the area
and is cumbersome as it needs to recompute its task graph every time there is a
change in topology.


4

Liaison Framework


Design


The three main components of the Liaison Framework are
Liaisons, the Liaison Substrate
and the Liaison Loader. T
hey are described in detail in the following subsections.

Their
interactions are illustrated in
Figure
2
.

4.1

Liaison

The liaison is the entity that encapsulates the characteristics of the parent it originates
from and specifies the i
nformation the parent is interested in and the action that needs to
be taken when such information is found. Liaison is an extension of the AR message in
Meteor. It augments the
AR m
essage in two ways. First, while AR messages rely on a
rule
-
based engine a
nd basic prede
fined actions, liaisons can

contain an executable object
that can be executed on the LS
,

if the object is serializable and can be transferred across
the network to the LS. If the object cannot be serialized then the Liaison can contain a
code
base from which the object can be instantiated provided the codebase and
corresponding Liaison are accessible by the LS. This ability to load and execute a set of
more complicated instructions at the LS facilitates more sophisticated in
-
network data
proces
sing. In this report, Liaisons refer to AR messages that contain some object code to
be executed. For
a
simple rule based
AR
message refer to
[9]
.


Second, the liaison can be replicated and migrated to other LS if requested by t
he
Liaison. The liaison can either choose the LS that it wants to migrate or replicate on, or
be migrated and replicated on all the LS that support its requirements. Replication
facilitates in
-
network data processing. For e.g., in sensor networks each sens
or can be a
LS and the Liaison can be replicated on each of these sensors in order to aggregate data at
each of these sensors before propagating the result back to the parent. Each child Liaison
however communicates back to the Liaison that spawned it and
not to the Liaison
originator so it is not burdened by multiple connections from each of the replicas and also
allows for any data aggregation before sending to the original parent.

4.1.1

Liaison Message Layout

A Liaison comprises

a triplet (header, action, data
) much like the AR profile but
additionally is followed by the code for an executable object if the object is serializable.
The header of the liaison includes a semantic profile, sender credentials, characteristics,
TTL(time
-
to
-
live) and details of the exe
cutable object as shown in
Figure
1
. Each object
from a specific sender has a unique objectID. The objectIDs need not be globally unique
IDs. If the object is not serializable, the profile specifies a codebase from which the
objec
t can be obtained. The profile is a set of attribute/value pairs that specifies the
information that the sender is interested in.


ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

(temperature)
(unit = Farenheit)
(degree > 80)
(object)
(name = foo)
(objectId)
(language = java)
(codebase = http://www.objects.com)
(protocol = UDP)
(parameters)
(type int)
(value = temperature)
(temperature)
(unit = Farenheit)
(degree > 80)
(object)
(name = foo)
(objectId)
(language = C++)
(codebase = foo.dll)
(protocol = TCP/IP)
(parameters)
(type int)
(value = temperature)

Figure
1

Profile header with information about the executable object code

4.1.2

Liaison Specific Reactiv
e Behavior

The Liaison supports all the actions supported by the AR. These actions are augmented
with the actions that are specific to the Liaison’s object code. These actions are listed in
Table
1

with the new actions italicized.


Actions

Semantics

store

store data profile and data;

match message profile with existing interest profile;

execute action if match

retrieve

match message profile with existing data profiles;

send data corresponding to each matching data profile to the
sender.

notify_data

n
o
tify_interest

match message profile with existing data/interest profiles;

notify sender if there is at least one match.

delete_data

delete_interest

match message profile with existing data/interest profiles;

remove all matching data

profiles and data from the system in case of
delete data;

remove all matching interest profiles from the system in case of delete
interest.

execute

c
a
ll the execute method on the object code with the parameters that are
specified in the profile

migrate

migrate the Liaison to the specified LS

replicate

replicate the Liaison on

all or specified LS

Table
1

Supported reactive behaviors


The object code contained in a Liaison should implement the reactive behaviors that it
wants the
LS to invoke on the object code instance when a matching interest criteria is
found.

4.2

Liaison Substrate (LS)

The LS is the context in which Liaisons execute. LS is an Associative Rendezvous
Message Substrate (ARMS)
[9]

with the a
dditional responsibility of instantiating,
executing, replicating and migrating the object code specified by the Liaison. LS
advertises its services like communication protocols and languages it supports. The
ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

Liaison Loaders use this information to select
a suitable LS for a particular Liaison. The
LS can replicate or migrate the Liaison to other LS if requested by it. If the executable
object is specified as a codebase then the LS gets the object from the location specified.
Once the LS has the executable
object it creates an instance of that object and initializes it
with the specified parameters.


The LS maintains a repository of the Liaisons it has received as an association between a
profile and the corresponding instance of the object. The objectID spe
cified in the profile
provides the key for the association.


LS
Parent (Liaison Loader)
Satellite
post (<p1,p2>)
Liaison
post (<p1,p2>,Liaison)
notify_parent()
execute()
(1)
(2)
(3)
(4)


Figure
2

Interactions between the Liaison Framework Components

4.3

Liaison Loader (LL)

The Liaison Loader performs the following functions:



Locates the compatible LS for t
he corresponding Liaison. Compatibility between
the Liaison’s requirements and the services advertised by the LS is checked
before the Liaison is shipped to the substrate. Some services offered by the
substrate that essentially need to be checked are commu
nication protocols,
language support etc.



Once a suitable LS is located it ships the Liaison to that LS.



The LL can cache the locations of the most recently used substrates. It can first
check if a compatible LS exists in the cache. If
found it tries to c
onnect to that

LS.
If the connection is successful it propagates the Liaison to the substrate else it
tries to locate a LS for the Liaison.


5

Liaison Framework


Implementation

5.1

Liaison Substrate

The Liaison Substrate will be implemented in the context of t
he Meteor programming
framework and middleware stack. Meteor builds on a self
-
organizing overlay that
interconnects sensor/actuator services, resources, and data on the
ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

information/computational Grid, and implements content
-
based discovery and routing
serv
ices. The LS is the AR abstraction for content
-
based decoupled interactions with the
additional responsibility of instantiating, executing, replicating and migrating the object
code specified by the Liaison.


5.1.1

Meteor Overview

Meteor is a wireless testbed in
tended to provide a flexible platform for the evaluation of
future sensor/actuator
-
based systems, wireless networking protocols, middleware, and
applications. The testbed is an open
-
access multi
-
user experimental research facility
consisting of a two
-
tier
architecture involving a controlled laboratory emulator consisting
of a radio grid of roughly 400 radio nodes arranged in a regular rectangular grid, and an
outdoor field trial network involving an IP
-
based 3G basestation and related mobile
multimedia plat
forms. The sensor network is a self
-
organizing, three tiered (hierarchical)
structure consisting of low
-
power sensor nodes with limited functionality, higher
-
power
radio forwarding nodes that route data, and access points that route data between radio
link
s and other wired/wireless infrastructures. The overlay network connects forwarding
nodes and access points with the wired infrastructure and supports the Meteor
programming framework and content
-
based middleware. These components are
shown in
Figure
1

and d
escribed below.

Overlay Network:
The Meteor overlay network is composed of RP nodes, which may be
access points or message forwarding nodes in ad
-
hoc sensor networks and servers or peer
nodes in wired networks. RP nodes can join

or leave the network at any time. The current
Meteor overlay network uses Chord
[10]

protocol to organize peers in a ring topology.
The overlay network layer of the middleware stack provides a simple abstraction to the
upper l
ayers, consisting of a single operation:
lookup
(
identifier
). Given an identifier, this
operation locates the node that is responsible for it, i.e, the node with an identifier that is
the closest identifier greater than or equal to the queried identifier. A
pplication names can
be mapped to identifiers using hashing mechanisms, and then mapped to nodes in the
overlay network.

ECE 572
Advanced Parallel & Distributed Computing

Spring 2005


Figure
3

Meteor System Architecture

Content
-
based Discovery and Routing (Squid)
:
Content
-
based discovery and routing
services in Meteo
r are provided by Squid
[16]
[17]
. Squid builds on top of the overlay to
enable flexible content
-
based routing. As mentioned above, the
lookup
o
perator provided
by the overlay requires an exact identifer. Squid effectively maps complex queries
consisting of keyword tuples (multiple keywords, partial keywords, wildcards, and
ranges) onto clusters of identifiers, and guarantees that all peers respon
sible for
identifiers in these clusters will be found with bounded costs in terms of number of
messages and the number of intermediate RP nodes involved.

Liaison Messaging Substrate (LMS):
The LMS layer implements the Liaison Substrate.
Each LS can be loca
ted at each RP. Like the Associative Rendezvous Messaging
Substrate (ARMS) it consists of two components: the
profile and object code

manager
and the
matching engine
. The matching engine component is essentially responsible for
matching profiles. An incomi
ng message profile is matched against existing interest
and/or data profiles. If the result of the match is positive, then the action field of the
incoming message is executed first
,

followed by the evaluation of the action field in
matched profiles. The p
rofile manager manages locally stored profiles and their
associated objects, and monitors message credentials and contexts to ensure that related
constraints are satisfied. For example, a client cannot retrieve or delete data that it is not
authorized to.
The profile manager is also responsible for garbage collection. It maintains
a local timer and purges interest and data profiles when their TTL fields have expired.
The object code manager used the ObjectID to associate the profile with the executable
code

which can be quried for its ObjectID
.
Finally, the profile manager executes the
action corresponding to a positive match which would be the execution of a specified
operation on the object instance that the profile is associated with.

5.1.2

Implementation of LM
S with JXTA

The current implementation of Meteor builds on Pr
oject JXTA
[7]
, a general
-
purpose
peer
-
to
-
peer framework that provides a set of open protocols and platforms to build new
Application

Opportunistic Interactions

Liaison Substr
ate (AR)

Content Based Routing
,
D
iscovery

(Squid)

Self
-
organizing Overlay

Wireless/Wired Substrate

e.g. sensors,actuators,internet

Meteor

Middleware

Stack

ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

services and applications. JXTA defines conc
epts, protocols, and a network architecture.
JXTA concepts include peers, peergroups, advertisements, modules, pipes, rendezvous
and security. JXTA defines protocols for (1) discovering peers (Peer Discovery Protocol,
PDP), (2) binding virtual end
-
to
-
end c
ommunication channels between peers (Pipe
Binding Protocol, PBP), (3) resolving queries (Peer Resolver Protocol, PRP), (4)
obtaining information on a particular peer, such as its available memory or CPU load
(Peer Information Protocol, PIP) (5) propagating

messages in a peergroup (Rendezvous
protocol, RVP), (6) determining and routing from a source to a destination using
available transmission protocols (Endpoint Routing Protocol, ERP). The JXTA
architecture builds on three layers, a core layer, for essenti
al common functionalities, a
service layer, for additional pluggable/unpluggable behaviors, and an application layer
for end
-
to
-
end high
-
level control. Note that JXTA is an application level technology and
does not introduce any limitations on the underlyi
ng infrastructure or the routing
protocols. The overlay network, Squid and the LMS layers of the Meteor stack are
implemented as event
-
driven JXTA services. Each layer registers itself as a listener for
specific messages, and gets notified when a correspon
ding event is raised. Since Meteor
is designed as an overlay network of rendezvous peers, it is incrementally deployable. A
joining RP uses the Chord protocol and becomes responsible for an interval in the
identifier space. In this way, the addition of a n
ew rendezvous node is transparent to the
end
-
hosts.


The overall operation of the Meteor overlay consists of two phases: bootstrap and
running. During the bootstrap phase (or join phase) messages are exchanged between a
joining RP and the rest of the grou
p. During this phase, the RP attempts to discover an
already existing RP in the system and construct its routing table. The joining RP sends a
discovery message to the group. If the message remains unanswered after a duration (in
the order of seconds), the

RP assumes that it is the first in the system. If a RP responds to
the message, the joining RP queries this bootstrapping RP according to the Chord join
protocol and updates routing tables to reflect the join.


The running phase consists of a stabilizatio
n and a user mode. In stabilization mode, a RP
responds to queries issued by other RPs in the system. The purpose of the stabilization
mode is to ensure routing tables are up to date, and to verify that other RPs in the system
have not failed or left the s
ystem.


In user mode, RPs participate in interactions as part of the Squid and LMS layers. The
LMS matching engine at each RP is based on MySQL (http://www.mysql.com), a
lightweight SQL database. Since LMS is implemented as a JXTA service it can advertise
its specifications and capabilities, which can be used by the LL to locate and select the
LMS.


5.2

Liaison Loader

The Liaison Loader resides on the peer that is interested in sending a Liaison to the LMS.
The LL is also implemented as a JXTA service. The peer

uses the LL to locate a suitable
LMS for the Liaison by checking the compatibility of the LMS based on its
ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

advertisements. Once a suitable LMS is found the LL sends the Liaison as an event
message to the LMS. As mentioned in Section
5.1.2

the LMS is also implemented as a
JXTA service.

The LMS in turn loads, initializes and executes the Liaison when its
interest criteria is matched.

5.3

Liaison Framework Prototype with JXTA

A prototype
o
f the Liaison Framework was im
plemented using

the Java
JXTA
framework. Squid and Chord were not used to
keep the prototype simple.

The prot
ot
ype
applicatio
n consists of four

components

seen in
Figure
4

and described below.

All
components are

implemented in Jav
a.



A
T
hermometer
M
odule

which publishe
s

its

temperature readings in Farenheit

to the
Liaison Substrate



The
Liaison Loader M
odule

that uploads a temperature conversion liaison interested
in the temperature information published by the thermometer

module
.



The
L
iaison

which converts temperature received from the thermometer in Farenheit
to Celcius while executing on the LS. It then sends this

converted temperature to its
parent
. The liaison is
implemented as
a
serializable Java object so it can be serialized

to the LS.



Liaison S
ubstrate

module to which both the thermometer module and the liaison
loader connect to via its published pipe advertisement.

It invokes the attached liaison
when it receives
temperature
d
ata from the thermometer module passing it the
t
emperature in Farenheit.


text
Upload
Liaison
PEER
Liaison
Temp
Converte
r
Liaison Loader
f()
Liaision
Temperature
Converter
Data
Store
Liaison
Substrate
C
F
Thermometer
Module

Temp
Reading


Figure
4

Temperature Converter Prototype Components

The Liaison Substrate was implemented as a JXTA PipeService which published its pipe
advertisement shown in
Figure
5
. The pipe advertisement has a description of the LS
characteristics like transport protocol and Liaison language support.

This information can
be used by the LL to check compatibility with its Liaison and peer requirements.


ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

<!DOCTYPE jxta:PipeAdvertisement>
<jxta:PipeAdvertisement xmlns:jxta="http://jxta.org">
<Id>
urn:jxta:uuid-59616261646162614A7578746
</Id>
<Type>
JxtaUnicast
</Type>
<Name>
Liaison Substrate
</Name>
<Desc>
<Protocol>
TCP/IP
</Protocol>
<Language>
Java
</Language>
</Desc>
</jxta:PipeAdvertisement>


Figure
5

Liaison Substrate Service Pipe
Advertisement

The Liaison Loader an
d the thermometer module use JXTA’s

Discovery Service to
acquire the
LS’s pipe advertisement.
They then create input pipes to the LS to send the
liaison and temperature data r
espectively.

The liaison connects back to its parent via a
TCP socket connection in order to send the co
nverted temperature information.

The
Appendix

shows execution screen shots of the prototype.


6

Conclusion and Future Work

The p
roject

motivates
and proposes a Liaison Framework based on the Associative
Rendezvous
Framework implemented in the context of
the
Meteor

project
.
The main aim
of the project was to extend the
data aggregation capability of
AR to include more
complex data p
rocessing
algorithms by uploading executable

code as part of the AR
message.
This
ensure
s

a portable solution to
deal with the heterogeneity and dynamicity
of pervasive computing environments.


The project provides the design and implementation detai
ls of
the Liaison Framework
including a prototype implementation of the framework using the JXTA peer
-
to
-
peer
framework.



Future
work includes implementing the framework using Chord and Squid to locate the
LS based on t
he peers interest specification, working o
n migration and replication of the
ECE 572
Advanced Parallel & Distributed Computing

Spring 2005

Liaisons across Liaison Substrates

and

looking into security issues related with execution
of unsolicited liaisons

on Liaison Substrates.

7

Reference


[1]

Java Technology, http://java.sun.com/.

[2]

OMG’s CORBA Model,
http://www.omg.org/technology/documents/corba_spec_catalog.htm
.

[3]

Java RMI Model,
http://java.sun.com/products/jdk/rmi/

[4]

D. B. Johnson and

D. A. Maltz, Dynamic source routing in ad hoc wireless
networks", Mobile Computing, T. Imielinski and H. Korth, Eds. Norwell, MA:
Kluwer, ch. 5, pp. 153
-
181, 1996.

[5]

C. Perkins and E. Royer, Ad hoc on
-
demand distance vector routing, Ad hoc
Networking, Addis
on
-
Wesley Publishers, Editor C. Perkins, 2000.

[6]

Jini Network Technology,
http://www.sun.com/software/jini/
.

[7]

JXTA, http://www.jxta.org

[8]

A. Carzaniga and A. L. Wolf. Content
-
based networking: A new communicati
on
infrastructure.
NSF Workshop on an Infrastructure for Mobile and Wireless
Systems
, October 2001.

[9]

N. Jiang, C. Schmidt, V. Matossian and M. Parashar. Content
-
based Middleware
for Decoupled Interactions in Pervasive Environments,
Technical Report Number
2
52
, Wireless Information Network Laboratory (WINLAB), Rutgers University,
April 2004

[10]

OMG’s Mobile Agent Facility,
http://www.omg.org/docs/formal/00
-
01
-
02.pdf

[11]

Rita Yu Chen and Bill Yeager, Java Mo
bile Agents on Project JXTA Peer
-
to
-
Peer
Platform
,
in
Proceedings of the 36th Hawaii International Conference on System
Sciences (HICSS’03)

[12]

Athanassios Boulis, Chih
-
Chieh Han, and Mani B. Srivastava, Design and
Implementation of a Framework for Efficient a
nd Programmable Sensor Networks,
in the Proceedings of the 1st international conference on Mobile systems,
applications, and services, 2003

[13]

A. Boulis, C.C. Han, and M. B. Srivastava, Design and Implementation of a
Framework for Programmable and Efficient S
ensor Networks, MobiSys 2003

[14]

Rajnish Kumar, Matthew Wolenetz, Bikash Agarwalla, Jun
-
Suk Shin, Phillip Ward
Hutto, Arnab Paul, and Umakishore Ramachandran, DFuse: A Framework for
Distributed Data Fusion, in the Proceedings of the 1st international conferenc
e on
Embedded networked sensor systems, 2003.

[15]

I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan. Chord: A
scalable peer
-
to
-
peer lookup service for internet applications. In
Proceedings of the
ACM
SICOMM’01 Conference
, pages 149

160, San
Diego, California,
August
2001.

[16]

C. Schmidt and M. Parashar. Flexible information discovery in decentralized
distributed systems. In
Proceedings of the 12th High Performance Distributed
Computing (HPDC)
, pages 226

235. IEEE Press, June 2003.

[17]

C. Schmidt and
M. Parashar. Enabling flexible queries with guarantees in p2p
systems.
Internet Computing Journal
, 8(3):19

26, 2004.

ECE 572
Advanced Parallel & Distributed Computing

Spring 2005


8

Appendix




Figure
6

Thermometer Module
Execution
Shell


ECE 572
Advanced Parallel & Distributed Computing

Spring 2005



Figure
7

Liaison Substrate

Execution Shell

ECE 572
Advanced Parallel & Distributed Computing

Spring 2005


Figure
8

Liaison Loader Module Shell