Towards a Service Oriented Architecture (SOA) for Tele-Rehabilitation

Technical Report

Karin Anna Hummel, Zoltan Juhasz

Towards a Service-Oriented Architecture (SOA) forPerformance-Aware Mobile Grid Services

April 2008TR-20080403

Towards a Service-Oriented Architecture (SOA) for Performance-Aware MobileGrid Services: A Survey on Decentralized Performance Monitoring, SOAs, and

Selected Meeting Application Use Cases for Mobile Devices

Technical Report: TR-20080403

Karin Anna HummelDep. of Distributed and Multimedia Systems

University of Vienna, Austria1010 Vienna, Lenaugasse 2/[email protected]

Zoltan JuhaszDep. of Information Systems

University of Pannonia, Hungary8200 Veszprem, Egyetem u. 10.

[email protected]

Abstract

When using grid technologies for scientific and non-scientific applications, ubiquitous access to these ap-plications is useful for many scenarios. Hereby mobiledevices provide a technology supporting this aim. Byaddressing multimedia integration into these services(like video streaming), the Quality of Service (QoS) isa major cause for user experience (QoE) and accep-tance. The aim of this paper is to present a Service-Oriented Architecture (SOA) based on recent decen-tralized performance monitoring approaches and SOAbased approaches able to support mobile grid clients.We first present a survey on decentralized performancemonitoring and SOA and propose a general architec-ture. Additionally, we describe two application usecases including mobile devices which have been se-lected due to their different QoS constraints which re-quire service adaptations due to dynamic changes inperformance. These two use cases dedicated to themeeting application domain are: smart picture shar-ing and seamless video streaming.1

1This work has been funded by the WTZ Program Hun-gary/Austria 2006/2007. The technical report is published onhttp://www.cs.univie.ac.at/.

1 Introduction

By including multimedia services into Grids, theneed for QoS assurance arises. To support these ser-vices, we present a performance-aware Grid architec-ture based on the SOA paradigm. We extend JGrid[7],a Jini based SOA, by introducing distributed perfor-mance monitoring and persistent storage of perfor-mance data in a shared communication space. As itis already included in the Jini technology, we proposethe use of JavaSpaces as an example space. Herebythe approach for distributed performance monitoringcan be centralized or decentralized. The latter avoidsa single point of failure and thus increases robustnesswhile having to solve the problem of gathering a com-mon system-wide status.

The survey presented in this paper provides a sum-mary of the two approaches relevant for our architec-ture: (i) decentralized performance monitoring and (ii)SOAs. Together with a summary of standard perfor-mance metrics applicable, this survey presents an in-troduction into performance-aware SOA Grid infras-tructures.

We further provide the description of two exampleuse case for SOA-based services which need QoS as-surance and adaptation depending to the Grid’s and themobile client’s performance status. The use cases aretargeted to the business and meeting domain, they are:

smart picture sharing and seamless video streaming.The remainder of this document is structured as fol-

lows: In Section 2 a summary of traditional perfor-mance metrics is given and their application to mobileGrids. In Section 3 we survey decentralized perfor-mance approaches and SOAs which leads to the con-cluding performance-aware SOA mobile Grid archi-tecture presented in Section 4. Then we present a de-tailed description of the use cases benefiting from theapproach in Section 5 and conclude our work.

2 Performance Metrics

According to the work of Jain [4], pp. 30 – 43, thetwo steps of performance evaluation are the selectionof the evaluation technique and the metrics to use. Themetrics are derived by distinguishing between threesystem states: (i) correct systems (providing correctanswers and events), (ii) incorrect systems (providingwrong answers or events), and (iii) not responding sys-tems. The corresponding classes of metrics are relatedto Speed, Reliability, andAvailability. Figure 1 showsthe hierarchical classification of the metrics used. Inaddition to the metrics commonly used for availabil-ity, we will further use the ratesnumber of connectingnodesandnumber of disconnecting nodesin order togive a self-descriptive overview of the dynamics in amobile grid system, that is a grid consisting of mobilenodes. In a system where the number of participat-ing nodes is known and the failure isdisconnection,these rates can be estimated by using the MTTF (MeanTime To Failure) and the MTTR (Mean Time To Re-pair). From a mobile distributed system’s perspective,this rate is a major characterization of the dynamicsof the system and thus, we will include them on thesystem level (see also thechurn ratesdescribing con-nection/disconnection rates in peer-to-peer systems).

By using these well-known metrics, we aim to de-rive high quality metrics in terms of low variability,non-redundancy, and completeness. Since we are in-vestigating distributed systems, individual node met-rics will be considered as well as global metrics.

In order to measure the speed of a (mobile) grid sys-tem, metrics related to time, rate, and utilization areused. Related totime, the following metrics definitionsare used:

Response Time.Here, theResponse Timeis defined

as the duration between the completion of a re-quest by the user to the completion of the re-sponse of the system.2 In case of a batch stream,the termTurnaround Timeis used alternatively.

Reaction Time. TheReaction Timeof a system is de-fined as the duration between the completion ofthe user request and the point in time the systemsstarts to execute the request.

Stretch Factor. This factor is used in order to de-scribe the relation of the response time under aspecific workload to the response time under min-imal load.

The commonly used metrics describingratesare asfollows:

Throughput. The Throughput is measured asre-quests per unit of timeand varies depending onthe load. Typically, the throughput increaseswith increasing load up to a certain point. Thenthe increase of the throughput might significantlyslow down until it finally decreases or it de-creases immediately. Depending on the system(and the system level of investigation), through-put is, e.g., measured as requests per unit oftime (interactive systems), jobs per unit of time(batch systems), Millions of Instructions Per Sec-ond (MIPS) or Millions of FLoating Point OPer-ations (MFLOPS) (CPU), packets or bits per sec-ond (pps/bps) or Transactions Per Second (TPS)(transaction processing).

Nominal Capacity. Under ideal load conditions, thisrate defines the maximum achievable throughput.For computer networks, the termBandwidthis of-ten used. In case the response time is too highwhen the nominal capacity is reached, the rateUsable Capacityrefers to the maximum through-put with restricted response time.

Efficiency. The efficiency is defined as

Efficiency =Usable Capacity

Nominal Capacity.

2It is also possible to define theResponse Timeas the durationbetween the completion of the user request to the point in time, thesystems starts to respond [4].

2

Speed

System

Availability

Reliability

Time

Rate

Utilization

Response Time

Reaction Time

Stretch Factor

Throughput

Nominal Capacity

Efficiency

MTBF

Error probability

MTTF

MTTR

Figure 1: Performance metrics after [4].

Additionally, the utilization of a resource describesthe workload processed during operation. This metricis defined as:

Utilization =Timebusy

Timeelapsed

.

The reliability of a system describes the degree ofconfidence about correct operation of a system. Cor-rect operation can be related to the value domain andthe time domain. In particular for hard real-time sys-tems, a late calculation may end in disaster as well as awrong calculation. Thefault-hypothesisdescribes thefailures that are considered in the system. Independentof the type and semantic of a failure, the following twometrics can be used to describe a system’s reliability:

Mean Time Between Failure (MTBF). This metricrepresents a time value which describes the av-erage time between the occurrence of a failure.

Error Probability. This metric describes the proba-bility of an error, that is, an observed system fail-ure.

The availability of a system should be observed incases where system may partially be unable to answer.In contrast to stationary distributed system where theavailability is a measure of dependability of a sys-tem, in mobile systems, mobile devices are expected to

roam in and out of the coverage area of wireless net-works and, thus, to become unavailable from time totime. The availability metric values of a stationary gridsystem using wired lines are expected to differ signif-icantly from their mobile counterparts. The followingtwo metrics are considered:

Mean Time To Failure (MTTF). This time value de-scribes the average time observed between thestart of the observation period or a failure to thenext failure.

Mean Time To Repair (MTTR). The mean time torepair describes the time needed for the systemto become operational and responding again aftera system failure.

Consequently, the availability of a system is de-scribed by the following ratio:

Availability =MTTF

MTTF + MTTR.

3 Related Work

Performance monitoring in distributed systems is animportant issue as stated in [6] by presenting a mar-ket survey of real network management user’s require-ments. As a result, among the common appreciated

3

functions are the ability to monitor the complete sys-tem on a single console and the ability to use historyinformation.

From an adaptive distributed Service-Oriented Ar-chitecture (SOA) point of view, these functions canbe transformed into the desirable system requirementsthat SOA wide current and history performance datashould be available to trigger the adaptation. If thesystem is decentralized, this aim might not be reachedfor 100 percent, but only approximated. In this sec-tion, related work in the area of network and servicemonitoring will be discussed (including decentralizedapproaches) as well as the second technology relatedto our work: SOA.

3.1 Distributed Performance Monitoring

In [6], most importanttiming metricsand quanti-tative metrics(statistics) are defined for system wideperformance monitoring. Timing metrics are mea-sured response times in total (from the time the clientissues an request to the time the result is received bythe client) and response times within the system it-self like a middleware response time describing thetime spent to process the client request in the mid-dleware. Quantitative metrics are defined as the mid-dleware throughput, the number of clients and serversactive, (average) number of different messages ex-changed, most used server (hotspot), and a deadlockcount. An approach termedClearing Housesupportsthese metrics for a data-base centric system consistingof exchange modules, which might be distributed. Thearchitecture makes use of a central register facility formanaging these exchange modules.

For scientific networking experiments, PlanetLab3

is a well known testbed which provides networkedcomputers on a world wide scale. Applications are runin virtual machines and sharesliceswhich can be re-served on selectable machines in the network. The ad-ministrators use slices as well for monitoring the sys-tem’s performance on nodes in terms of workload (re-lation betweenactive– i.e., containing a process – andlive slices – i.e., in the past five minutes the slice hasused at least 1% (300ms) of the CPU), CPU, memory,bandwidth, disk space, and jitter caused by schedulinglatencies. To allow access for many users, PlanetLab

3see http://www.planet-lab.org/

implements a graceful degradation of the node’s per-formance if a resource is becoming over-utilized.

For grid environments, in [5] a tool for testing andmonitoring network performance has been introducedand developed as a part of the Globus toolkit4. Thistool namedGloperf probes the network connectinggrid nodes and calculates the bandwidth estimate ac-cordingly (based on TCP end-to-end measurements).In order to keep the overhead for probing low, the toolsupports a group membership which allows, for exam-ple, that a remote cluster is tested only once per groupand not by all group member nodes. The overhead isfurther limited by allowing only a fraction of the avail-able bandwidth to be used for probing. If this frac-tion is not sufficient for the probing frequency, the fre-quency is decreased. The group membership in thisapproach has been simply based on manual configura-tion.

The ASKALON framework [2] has been introducedto monitor the performance of scientific workflows byinstrumentation of distributed grid management mod-ules (engines). Workflow events can be monitored andreported to a central AKALON performance monitor-ing client. Example events are the initialization, sus-pension, and cancellation of activities.

When addressing decentralized systems, messageoverhead for the exchange of performance data shouldbe minimized. In [3] the trade-off between commu-nication costs and global performance, i.e., faults, interms of false alarms and miss rates are analyzed insensor networks. The approach ofvirtual coordinatesystemsallows to predict the latency in large scale net-worked systems like the Internet. Virtual coordinatesystems allow nodes to map themselves into a coor-dinate systems and to derive distances to other nodes.Actual distance estimates only exist to nodes in aref-erence set. Latencies are calculated based on the dis-tances in the virtual coordinate system which is usu-ally either landmark based or decentralized [10]. Indecentralized coordinate systems, the system can bedescribed in terms of the reference set (e.g., neighborsin the network) the node uses to calculate the latency,the distance prediction mechanisms based on the dis-tance definition (e.g., Euclidean distance), and an errorminimization technique. In [10] attacks in a decen-

4see http://www.globus.org/

4

tralized virtual coordinate system are investigated andmechanisms are proposed to increase the system’s ro-bustness.

To provide mechanisms for effective self-healingin distributed systems, performance problems have tobe first localized. An approach based on Bayesiannetworks is proposed in [11]. Hereby, the inferencemodel and simulation results are described withoutconsidering the problem of decentralization (and, thus,partial knowledge). Based on collected response timeand elapsed time data, the system automatically inferselapsed times if current data is missing and estimatesresponse times. Thus, it is possible to estimate the ser-vice causing the longest delays and apply self-healingmechanisms to these services.

3.2 Service Oriented Architecture

Service-orientation is a new paradigm in distributedsoftware construction, rapidly gaining popularity inbusiness and science applications. It is based on thenotion of services (entities exporting some function-ality through well-defined interfaces) and clients us-ing these services for carrying out tasks. A crucialdifference between client-server and service-orientedsystems is the level of abstraction. In client-server sys-tems, servers are physical resources represented by anIP address and port number. Services, on the otherhand, hide implementation details behind their inter-face; the physical resource, its type and location typi-cally is irrelevant to the user of the service.

A software architecture based on service-orientation is called a Service-Oriented Architecture(SOA). A service-oriented architecture can overcomeseveral problems of classic distributed systems as wewill discuss below. Figure 2 demonstrates a minimalservice-oriented architecture. A service publishes itsinterface description in a directory. The informationstored in the directory enables clients looking for aservice with a particular functionality to connect anduse the selected service. The use of the directoryprovides naming and location transparency, i.e., aservice can be accessed without explicit knowledge ofits address or location.

The use of service interfaces decouples ser-vice functionality definition from its implementation.Clients and services are loosely coupled in the sense

that changes in the service implementation will not af-fect clients.

Figure 2: A minimal service-oriented architecture.

Service-orientation is only a concept. It requires aphysical implementation technology to be usable. Thetwo most well-known such technologies are Web Ser-vices, and Jini Technology. Web Services Technol-ogy [1] is a language-independent SOA environmentdue to its reliance on the XML language. A web ser-vice describes its interface and invocation details in anXML (Web Service Description Language) documentstored in a UDDI directory5. The advantage of thisscheme is that clients written in arbitrary programminglanguages can invoke services implemented in differ-ent languages. Clients can invoke services by sendingSOAP6 messages either by using Remote ProcedureCall or message passing semantics.

Jini Technology [9] provides a service-oriented ar-chitecture for the Java Platform. Jini services are de-scribed by Java interfaces; clients use these interfacesto look for suitable services. Central to Jini is the no-tion of discovery. Participants in a Jini communityuse multicast or unicast messages to locate availableLookup Services (service directories) on the network.Lookup services are used to register and look up theservices of interest. Jini relies on object mobility in itsoperation. Java objects are passed to the Lookup Ser-vice during registration and this object is forwarded tothe client as a lookup result. The downloaded objectis used as a service proxy in the client enabling con-nection and service invocation in - typically - RemoteMethod Invocation fashion.

Jini has been designed for dynamic communities in

5see http://www.oasis-open.org/specs/index.php#uddiv3.0.26see http://www.w3.org/TR/soap/

5

which services and clients join and leave the system inunpredictable ways. Resource management is a prob-lematic issue in such environments. Jini uses the no-tion of leasing to address these problems. Resourceusage (e.g., service registration in the Lookup Service)is normally allowed on a timed basis. Entities must re-new their lease period before it expires if they need tocontinue with that activity. If the lease is not renewed –either deliberately or due to system failure – the corre-sponding resource is released (e.g., registration objectdeleted). This scheme is well suited to systems withunreliable network connection and intermittently op-erating devices.

4 Architecture

The architecture proposed should support the adap-tation of services due to QoS achievable withinthe grid. In the following sections, performance-awareness is introduced to the SOA JGrid [7].

4.1 JGrid

JGrid [7] is an experimental service grid frameworkdeveloped at the University of Pannonia in collabora-tion with MTA SZTAKI and Eotvos University Bu-dapest. Its aim is to create a reliable environment inwhich various services provide capabilities to clientsin a reliable way despite the geographical disparity,presence of failures, and the dynamically changingtopology.

It is built on top of Jini Technology, hence relyingon its discovery, leasing and platform independencefeatures. There are a set of core services that providefundamental functionalities for the system. TheAu-thentication Serviceis responsible for identifying gridusers and allowing access for them to the system. TheRegistration Serviceis used to store access right-userrole pairs for services. This is an extension to the secu-rity architecture of Java.Compute Services are specialentities that enable clients to execute Java objects (sentfrom the client program) on a remote location. TheCompute Service is highly configurable and supportsa number of sequential and parallel execution modes.TheBatch Serviceis used as a wrapper service to ex-port native batch execution environments as services inorder to provide traditional batch execution facilities in

JGrid. Finally, theStorage Serviceprovides access toremote files and directories through a service interface.

The core JGrid services along with the standard Jiniservices, such as Transaction, Event Mailbox, JavaS-paces, etc services form a rich platform for creatingdynamic service-oriented applications. Several casestudies demonstrate the success of this approach in-cluding video stream, Internet radio, weather instru-ment services, and computationally intensive applica-tions using several compute services.

An important feature of JGrid with respect to per-formance monitoring and providing QoS is its abilityto provide static and dynamic information about theservice’s capabilities and performance. Jini attributeobjects are used to describe static properties, e.g., pro-cessor speed, memory size, network bandwidth, screensize, etc., that clients can use in service selection de-cisions. Services can be assigned so called monitorproxies that clients can retrieve via the main serviceproxy to monitor dynamically changing performancemetrics, e.g., latency, processor load, etc.

4.2 Introducing Distributed Performance

Gathering to JGrid

This section presents a performance frameworkwhich defines the metrics used to evaluate three differ-ent levels of a mobile SOA grid: the mobile client’sperspective, the system’s perspective, and the gridnode level’s perspective including connection charac-teristics. The main three questions arising are:

¦ What should be measured?

¦ Where and how should the measurement takeplace?

¦ How can the measurements be stored and dis-tributed in a mobile and decentralized environ-ment?

We propose a generic approach, thus, metrics canbe easily added. However, we will start with a sampleset of the following metrics necessary to trigger adap-tations for multimedia services QoS: available net-work bandwidth, CPU utilization, availability in termsof MTTF and MTTR, and reliability in terms of theMTBF.

6

The approach proposed is based on the space-basedparadigm (which can be supported by JavaSpaces in-cluded in Jini but also implemented on top of Jini andthe communication infrastructure), the measurementresults are stored by means of the space. Dependingon the decomposition level, the following views canbe defined:

Node view. Here, the metrics are applied to each sin-gle grid node. In order to describe network con-nection as point-to-point links, which are neededto describe ad-hoc networking mode, a matrix isused to describe the link performance measuresas depicted by Table 1. This matrix representsalso the topology of the node network.7 Matri-ces are very useful to describe the links betweennodes and, for example, have already been used inperformance oriented grid research, like thenet-work weather servicepresented in [8]. Usually,this matrix will be symmetric due to the symme-try of the link.8

System view.Here, the metrics are used to describethe grid as a whole. The measurements on nodelevel are aggregated in order to provide the sys-tem view metrics for thecollective layer. Forexample, the variance of node utilization mightbe a useful means to determine under-utilized re-sources. Additionally, the overhead caused bybrokering and scheduling can be observed on sys-tem level.

Client view. From the client’s perspective, the appli-cation’s performance characteristics are impor-tant. These metrics are applied accordingly andrepresent theapplication layerpoint of view. Fur-thermore, selected metrics are used to describethe mobile grid client itself, like, for example, thedisconnection frequency.

The measurements take place on different nodesand should be stored persistently. Here, both time se-ries, that are, thehistory of of measurementsand thecurrent statusare considered. We address performance

7Note, that this matrix might be sparse for ad-hoc networks.8In case of, for example, satellite links, up- and down-link ca-

pacity differ.

Node1 Node2 Node3 ... Noden

Node1 x11 x12 x13 x14 x1n

Node2 x21 x22 x23 x24 x2n

Node3 x31 x32 x33 x34 x3n

... ... ... ... ... ...

Noden xn1 xn2 xn3 ... xnn

Table 1: Connectivity performance matrix

evaluation completely on software layer by means ofcode instrumentation and generation of logs.

Each JGrid node is responsible for generating logson node level. The JGrid management which includesbrokering and scheduling is responsible for measure-ment and generation of logs in terms of system met-rics. The system measures will be executed in a cen-tralized or decentralized manner depending on the sys-tem management policy. The client measures will begenerated at the client side. However, these measuresshould be available to the monitoring framework forevaluation purposes.

We propose to use the persistent layer provided bythe space-based paradigm for storing the measures.Both JGrid clients and JGrid nodes may disconnectfrom the grid while the measures which have been gen-erated previously should remain available. Since JGridis based on Jini, we propose to use JavaSpaces for per-sistent storage of performance data. Figure 3 depictsthe principle of using the space for logging purpose.The log information should contain meta-informationabout the measurements, which can easily be achievedby using XML.

5 Use Cases

We will now define two use cases for mobile gridsfor SOA based applications exhibiting different QoSrequirements, they are: smart picture sharing andseamless video streaming.

Smart picture sharing. In business and technicalmeetings, it is generally a problem to easily share pre-sentations and pictures during the meeting. Copyingslides to the computer driving the projector or switch-ing projector cable from one laptop to the other arecumbersome (although, this should in principle work).We envision a service-oriented picture sharing envi-ronment that greatly reduces the above complexity and

7

Figure 3: Logging of performance measures in JGrid extended by space-based technology.

enhances meetings with additional collaborative func-tionalities.

Participants can use PDA or laptop devices withclient programs with which they can discover the pro-jector service as they enter the meeting room. Theprojector service provides presentation and picture dis-play facilities for each user. Access to the projector canbe controlled manually or by a policy component thatgrants the display right to the requesting client base onpre-set rules.

If required, clients can request the currently dis-played picture to be transferred from the projector ser-vice to the client device on which they can place an-notations or add drawings. These can be displayed onthe projector if so wished.

The devices and the projector exchange QoS pa-rameters (most importantly screen resolution and colordepth) in order to perform automatic conversion andtransformation during picture transfer.

The service-oriented nature of the environment al-lows the use of other services; e.g., one can connectto his or her remote file service to load a presentationor picture not available locally on the device. Anotherpossibility is to use a shared white-board service or aprinter to print out pictures or notes.

Communication network parameters can be moni-tored during operation to change, e.g., picture qualityif communication bandwidth is not adequate for thecurrent image format. Similarly, image conversion be-yond what is required for the devices screen size couldbe triggered if, e.g., the memory constraints of a PDAdevice must be met.

In this scenario, important characteristics of the ser-vice quality are:

¦ Latency caused by auto-configuration

¦ Response time for the service (when sharing, pro-jecting, updating pictures, slowing down the slideshow, etc.)

¦ Latency and jitter effects for the slide show.

A first prototypical implementation of the picturesharing scenario on PDAs shows the feasibility of ac-cessing this JGrid service via mobile devices.

Seamless video streaming.The streaming of videoshould be seamlessly supported. The user should beable to watch a video on the device best fitting andchange the output/input devices while watching. Forexample, when moving around, the video might bestreamed to a PDA. When the user enters the workingroom, the video will be displayed on the PC screen.When the user enters his or her own private house-hold’s living room, the video should be displayed ona wall display. Here, the seamless migration of thevideo is demanding.

Important quality characteristics are:

¦ Video quality, that is, degree of absence of thefollowing faults: artifacts, stalls, blurring, addededge energy, “mosquito noise”

¦ Service and network quality: latency and jitter ef-fects, packet loss, and response time.

Figure 4 depicts the architecture of a smart businessenvironment where the applications described shouldbe embedded. Mobile devices of different types worktogether with services provided by smart devices like asmart bookshelf capable of tracking books that are putinto or taken out of the bookshelf enhanced by RFIDtechnology, and beamers. Mobile devices are expected

8

Figure 4: Service architecture.

to act as interfaces to Jini services and the JGrid infras-tructure provides computing services for computingintensive tasks (like video coding). Hereby, the qualityof the services provided should be permanently moni-tored to allow automatic system adaptation. Each com-ponent should be self-descriptive in terms of classicperformance metrics (like utilization, response time,availability, etc.), and thus, the performance measure-ment framework emerges within the distributed sys-tem. The availability of the framework may be in-creased by replicating the performance information orservices.

6 Conclusions

In this paper, we have surveyed decentralizedperformance monitoring approaches and describedthe main aspects of Service-Oriented Architectures(SOAs). We have further proposed a performanceaware architecture which generates a system viewbased on aggregating node performance measure-ments. For persistent performance data storage weproposed to use space based approaches. We appliedthe general concept to JGrid, a Jini based SOA. Wefurther defined and described two use cases for mul-

timedia services:smart picture sharingandseamlessvideo streaming.

References

[1] G. Alonso, F. Casati, H. Kuno, and V. Machiraju.WebServices: Concepts, Architecture and Applications.Springer Verlag, 2004.

[2] P. Brunner, H.-L. Truong, and T. Fahringer. Perfor-mance Monitoring and Visualization of Grid Scien-tific Workflows in ASKALON. In 2nd Int. Confer-ence on High Performance Computing and Commu-nication, 2006.

[3] E. Ermis and V. Saligrama. Adaptive Statistical Sam-pling Methods for Decentralized Estimation and De-tection of Localized Phenomena. In4th Int. Sympo-sium on Information Processing in Sensor Networks,2005.

[4] R. Jain. The Art of Computer Systems PerformanceAnalysis. Wiley, 1992.

[5] C. Lee, R. Wolski, C. Kesselman, and I. Foster. ANetwork Performance Tool for Grid Environments.In 1999 IEEE/ACM Conference on Supercomputing,1999.

[6] J. McCann and K. Manning. Tool to Evaluate Per-formance in Distributed Heterogeneous Processing.In 6th Euromicro Conference on Parallel and Dis-tributed Processing, 1998.

9

[7] S. Pota and Z. Juhasz. High-Level Execution andCommunication Support for Parallel Grid Applica-tions in JGrid. In20th IEEE International Paralleland Distributed Processing Symposium, 2006.

[8] M. Swany and R. Wolski. Building PerformanceTopologies for Computational Grids.InternationalJournal of High Performance Computing Applica-tions, 18(2), 2003.

[9] J. Waldo and K. Arnold. The Jini Specifications.Addison-Wesley, 2000.

[10] D. Zage and C. Nita-Rotaru. On the Accuracy of De-centralized Virtual Coordinate Systems in AdversarialNetworks. In14th ACM Conference on Computer andCommunications Security, 2007.

[11] R. Zhang, S. Moyle, S. McKeever, and A. Bivens.Performance Problem Localization in Self-Healing,Service-Oriented Systems Using Bayesian Networks.In 14th ACM Conference on Computer and Commu-nications Security, 2007.

10