bringing instruments to a service-oriented interactive grid · universita ca’ foscari di venezia`...

Universita Ca’ Foscari di Venezia

Dipartimento di InformaticaDottorato di Ricerca in Informatica

Ph.D. Thesis: TD-2007-2

Bringing Instruments to a Service-OrientedInteractive Grid

Francesco Lelli

Supervisor

Prof. Salvatore Orlando

Supervisor

Dr. Gaetano Maron

PhD Coordinator

Prof. Simonetta Balsamo

January, 2007

Author’s Web Page: http://www.dsi.unive.it/˜lelli/

Author’s e-mail: [email protected] or [email protected] or [email protected]

Author’s address:

Dipartimento di InformaticaUniversita Ca’ Foscari di VeneziaVia Torino, 15530172 Venezia Mestre – Italiatel. +39 041 2348411fax. +39 041 2348419web: http://www.dsi.unive.it

To the people that was believing in me. 1

1Dedicato a chi a creduto in me.

Abstract

Current Grid technologies offer unlimited computational power and storage capacityfor scientific research and business activities in heterogeneous areas over the world.

Thanks to the Grid, different Virtual Organizations can operate together in or-der to achieve common goals. However, concrete use cases demand a more closeinteraction between various types of instruments accessible from the Grid, and theclassical Grid infrastructure, typically composed of Computing and Storage Ele-ments. We cope with this open problem by proposing and realizing the first releaseof the Instrument Element (IE), i.e., a new Grid component that provides the Com-putational/Data Grid with an abstraction of real instruments, and the Grid userswith a more interactive interface to control these instruments.

In this thesis we describe in detail the proposed software architecture of theIE, also by discussing the functional and non-functional requirements on which itsdesign is based. The non-functional requirements demands not only deep interac-tion between users and devices to control instruments, but also the adoption of highinteroperable solutions, which only Service Oriented Architecture (SOA) based tech-nologies, like Web/Grid Services, can offer. Therefore, in order to solve the trade-offbetween the necessity of universality/interoperability and performance, we proposea set of solution that improves the performances of a SOA System, in terms ofboth throughput and latency of service invocations. Moreover, in order to fulfill theQuality of Service (QoS) nonfunctional requirement, we also devise a methodologythat allows remote method execution times to be predicted. This makes it possible,for example, to select an alternative service that better guarantees the fulfilment ofexecution deadlines.

Still according to our analysis of non-functional requirements, we also addressthe problem of determining fast communication methods to permit instruments toproperly inter-operate. In this regard, we investigate different publish/subscribearchitectures, and we show that RMM-JMS is the best candidate solution for ac-complishing this task.

It is worth noting that even though all these solutions and results have beenmotivated, devised and exploited during the design of our IE, any application basedon Web and Grid Services can benefit from them.

Finally, all our proposals are validated using suitable benchmarks and extensivetests and comparison with alternative solutions.

Acknowledgments

Desidero ringraziare:

Il Dr. Gaetano Maron, per avermi insegnato che semplici risultati pratici sonopiu utili e difficili da raggiungere di brillanti teorie.

Il Prof. Salvatore Orlando, per avermi insegnato come solo con brillanti teoriesi possano raggiungere semplici risultati pratici.

Tutte le persone che hanno creduto in me, in loro ho trovato il conforto per finirequesto lavoro.

Tutte le persone che non hanno creduto in me, in loro ho trovato la forza perfinire questo lavoro.

Infine la mia famiglia, mia madre e mio padre in particolare: senza di loro nonsarei mai arrivato a scrivere queste note di ringraziamento.

2

2 I would like to thank:

Dr. Gaetano Maron for having taught me that simple practical results are more useful anddifficult to achieve than brilliant theories.

Prof. Salvatore Orlando for having taught me how only through brilliant theories one canachieve simple practical results.

All the people who have trusted me, in them I found the support to draw this work to a close.

All the people who haven’t trusted me, in them I found the strength to draw this work to a close.

Finally my family, especially my mother and father: without them I would never have made itto these acknowledgments.

Contents

Preface xi

1 Introduction 11.1 Instrument Element Functional and Nonfunctional Requirements . . . 31.2 Thesis Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Thesis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Instrument Element Architecture 72.1 Instrument Classification . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 A Uniform Instrument Model . . . . . . . . . . . . . . . . . . 82.2 Instrument Aggregation Model . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Instrument Aggregation Building Block . . . . . . . . . . . . . 122.2.2 The Instrument Manager (IM) Abstraction . . . . . . . . . . . 132.2.3 Resource Service (RS) . . . . . . . . . . . . . . . . . . . . . . 152.2.4 Information and Monitor Service (IMS) . . . . . . . . . . . . . 172.2.5 Static vs Dynamic Aggregation Models . . . . . . . . . . . . . 172.2.6 Embedded Devices . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 On Improving the Web Service Interactivity 233.1 Problem Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 Understanding the XML limit . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1 3-tier Test bed . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.2 Service Request Time . . . . . . . . . . . . . . . . . . . . . . . 283.3.3 Handled Request per Second . . . . . . . . . . . . . . . . . . . 30

3.4 The Cache Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4.1 Hashing a Document . . . . . . . . . . . . . . . . . . . . . . . 353.4.2 Cache Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.3 Cache Insertion/Replacement Strategy . . . . . . . . . . . . . 37

3.5 Lower Bound of a Parser Algorithm and Parser Benchmark . . . . . . 383.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 On Enabling the Web/Grid Service Quality of Service 414.1 Problem Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.2 Critical Times in a Remote Procedure Call . . . . . . . . . . . 44

ii Contents

4.1.3 Factors that Influence a Remote Method Invocation . . . . . . 454.1.4 Implementation of a Homogeneous and Consistent Data Repos-

itory for Web Services QoS Case of Study . . . . . . . . . . . 464.1.5 Profiling WS Invocation to Build a Dataset . . . . . . . . . . 464.1.6 Data Sets Assessments . . . . . . . . . . . . . . . . . . . . . . 474.1.7 Data Set Candidates Description . . . . . . . . . . . . . . . . 48

4.2 Some Features of the Collected Data Set . . . . . . . . . . . . . . . . 504.2.1 WS Invocation Time with Large Input and Output Size . . . . 504.2.2 Server De-Serialization Time for Different Input Size . . . . . 504.2.3 One Way WS Invocation with Different Input Size . . . . . . . 534.2.4 Final Remarks on the Data Set . . . . . . . . . . . . . . . . . 59

4.3 Deadline Estimation Methodology . . . . . . . . . . . . . . . . . . . 594.3.1 Empiric Function Estimation . . . . . . . . . . . . . . . . . . 614.3.2 2k Factorial Analysis Design on the Dataset . . . . . . . . . . 624.3.3 Gaussian Upper Bound of a Sample Distribution . . . . . . . . 664.3.4 Total Execution Time Estimation . . . . . . . . . . . . . . . . 664.3.5 A Special Case: Server Deserialization . . . . . . . . . . . . . 664.3.6 Different f(x) Estimations . . . . . . . . . . . . . . . . . . . 694.3.7 Different g(x) Estimations . . . . . . . . . . . . . . . . . . . . 714.3.8 Deadline Function Estimation . . . . . . . . . . . . . . . . . . 71

4.4 On Validating the Methodology . . . . . . . . . . . . . . . . . . . . . 714.4.1 Methodology Validation with One Client . . . . . . . . . . . . 744.4.2 Methodology Validation with Multiple Clients . . . . . . . . . 76

4.5 Web Service Profile Algorithm . . . . . . . . . . . . . . . . . . . . . . 814.6 Possible Web Service QoS Enabled Architectures . . . . . . . . . . . 87

4.6.1 Full Client Side Logic . . . . . . . . . . . . . . . . . . . . . . . 874.6.2 Server and Clients Factors Break Down . . . . . . . . . . . . . 894.6.3 Third Party QoS Enabler . . . . . . . . . . . . . . . . . . . . 90

4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5 Information Dissemination 935.1 Problem Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . 935.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.3 RMM-JMS: a JMS Multicast P2P Architecture Overview . . . . . . . 95

5.3.1 RMM-JMS Architecture . . . . . . . . . . . . . . . . . . . . . 965.3.2 RMM-JMS Broker . . . . . . . . . . . . . . . . . . . . . . . . 985.3.3 Topic Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.4 Experimental Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 1005.4.1 Existing Benchmarks . . . . . . . . . . . . . . . . . . . . . . . 1005.4.2 Test-bed Hardware and Software . . . . . . . . . . . . . . . . 1005.4.3 Messages Rate Tests . . . . . . . . . . . . . . . . . . . . . . . 1015.4.4 Round Trip Time (RTT) Tests . . . . . . . . . . . . . . . . . 103

5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Contents iii

Conclusions 109

C.1 Open Research Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

A Application that Are Using the Current Release of the IE 111

A.1 The Intrusion Detection System . . . . . . . . . . . . . . . . . . . . . 111

A.2 The Power Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

A.3 The Compact Muon Solenoid Experiment . . . . . . . . . . . . . . . 111

A.4 The Synchrotron Radiation Storage Ring . . . . . . . . . . . . . . . . 112

A.5 The IMAA Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . 112

A.6 The Advanced Gamma-Tracking Array Experiment . . . . . . . . . . 112

A.7 The Device Farm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

A.8 Meteorology Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

B A Benchmark on the Current Instrument Element Implementation115

B.1 Command Reception Performances . . . . . . . . . . . . . . . . . . . 115

B.2 Command Distribution Performances . . . . . . . . . . . . . . . . . . 115

C Rleated Work on Complex On-Line Controls Systems 121

C.1 Overview of Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 121

C.2 Expert Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

C.2.1 Expert Systems Advantages . . . . . . . . . . . . . . . . . . . 125

C.2.2 Expert Systems Disadvantages . . . . . . . . . . . . . . . . . . 125

C.3 Fuzzy Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

C.3.1 Fuzzy Logic Advantages . . . . . . . . . . . . . . . . . . . . . 128

C.3.2 Fuzzy Logic Disadvantages . . . . . . . . . . . . . . . . . . . . 129

C.4 Neural Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

C.4.1 Neural Networks Advantages . . . . . . . . . . . . . . . . . . . 132

C.4.2 Neural Networks Disadvantages . . . . . . . . . . . . . . . . . 132

C.5 Intelligent Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

C.5.1 Events-Conditions-Actions . . . . . . . . . . . . . . . . . . . . 133

C.5.2 Taxonomies of Agents . . . . . . . . . . . . . . . . . . . . . . 134

C.5.3 Agency, Intelligence, and Mobility . . . . . . . . . . . . . . . . 134

C.5.4 Processing Strategies . . . . . . . . . . . . . . . . . . . . . . . 135

C.5.5 Multi-agent Systems (MAS) . . . . . . . . . . . . . . . . . . . 135

C.5.6 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 137

C.5.7 Blackboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

C.5.8 KQML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

C.5.9 Cooperating Agents . . . . . . . . . . . . . . . . . . . . . . . . 138

C.5.10 Stream Filtering Agents . . . . . . . . . . . . . . . . . . . . . 138

C.5.11 Intelligent Agents Advantages . . . . . . . . . . . . . . . . . . 138

C.5.12 Intelligent Agents Disadvantages . . . . . . . . . . . . . . . . 140

iv Contents

D QoS Test Bed Architecture: Implementation Details 143D.1 QoS Test Bed Architecture . . . . . . . . . . . . . . . . . . . . . . . . 143D.2 Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . 145D.3 Experimental Error on the Sample Measures . . . . . . . . . . . . . . 146

Bibliography 147

List of Figures

1.1 Interaction between the Instrument Element and others Grid Com-ponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Instrument Element Use Cases . . . . . . . . . . . . . . . . . . . . . . 4

2.1 abstraction model of a generic instrument . . . . . . . . . . . . . . . 9

2.2 The Instrument Element Abstraction . . . . . . . . . . . . . . . . . . 11

2.3 The Instrument Element Architecture . . . . . . . . . . . . . . . . . . 12

2.4 VCR-IE Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Classification of the Information Contained in the Resource Service . 16

2.6 Publish Subscribe Architecture . . . . . . . . . . . . . . . . . . . . . 17

2.7 IMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.8 Instrument Discovery Interaction Diagram . . . . . . . . . . . . . . . 19

2.9 Embedded Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 3-tier Architecture and Sequence diagram . . . . . . . . . . . . . . . . 26

3.2 Service request time for servlet and WS . . . . . . . . . . . . . . . . 29

3.3 Handled request per second using a storage tier and varying the queryresult size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31



3.6 Handled request per sec varying the input size . . . . . . . . . . . . . 33



3.9 XML parsed document with pointer to the nodes . . . . . . . . . . . 36

4.1 Critical Intervals in a Web Service invocation . . . . . . . . . . . . . 44

4.2 Sample distribution S-CPU 0% C-CPU 0% . . . . . . . . . . . . . . . 51

4.3 Sample distribution S-CPU 0% C-CPU 80% . . . . . . . . . . . . . . 51

4.4 Sample distribution S-CPU 80% C-CPU 0% . . . . . . . . . . . . . . 52

4.5 Sample distribution S-CPU 80% C-CPU 80% . . . . . . . . . . . . . 52

4.6 Sample distribution of the Server Deserialization Time (empty method) 53

4.7 Sample distribution of the Server Deserialization Time (Input 100Double) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.8 Sample distribution of the Server Deserialization Time (Input 100Double) whit server CPU occupancy of 80% . . . . . . . . . . . . . . 54

vi List of Figures

4.9 Sample distribution of the Server Deserialization Time (Input 1000Double) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.10 Sample distribution of the Server Deserialization Time (Input 10000Double ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.11 Sample distribution of a one way invocation of an empty method . . 564.12 Sample distribution of a one way invocation (Input 100 String) . . . 564.13 Sample distribution of a one way invocation (Input 100 String) whit

server CPU occupancy of 80% . . . . . . . . . . . . . . . . . . . . . 574.14 Sample distribution of a one way invocation (Input 1000 String) . . . 574.15 Sample distribution of a one way invocation (Input 10000 String) . . 584.16 Sample distribution of a one way invocation (Input and output 10000

String) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.17 coefficients for the linear regression estimation of different g(x) . . . . 724.18 % of deadlines misses varying the number of clients (95 percentile) . . 734.19 % of deadlines misses varying the number of clients (975 percentile) . 744.20 One Way Estimation CPU server 0% CPU Client 80% . . . . . . . . 754.21 End To End Estimation CPU server 0% CPU Client 80% . . . . . . . 754.22 One Way Estimation CPU server 80% CPU Client 80% . . . . . . . . 764.23 End To End Estimation CPU server 80% CPU Client 80% . . . . . . 774.24 End To End Estimation CPU server 80% CPU Client 80% . . . . . . 774.25 One Way Estimation with 2 clients connected . . . . . . . . . . . . . 784.26 End To End Estimation with 2 clients connected . . . . . . . . . . . . 784.27 End To End Estimation with 2 clients connected . . . . . . . . . . . 794.28 One Way Estimation with 3 clients connected . . . . . . . . . . . . . 794.29 End to End Estimation with 3 clients connected . . . . . . . . . . . 804.30 End to End Estimation with 3 clients connected . . . . . . . . . . . 804.31 One Way Estimation with 4 clients connected (Server Overloaded) . . 814.32 End to End Estimation with 4 clients connected (Server Overloaded) 824.33 End to End Estimation with 4 clients connected (Server Overloaded) 824.34 One Way Estimation with 6 clients connected (Server Overloaded) . . 834.35 End to End Estimation with 6 clients connected (Server Overloaded) 834.36 End to End Estimation with 6 clients connected (Server Overloaded) 844.37 One Way Estimation with 10 clients connected (Server Overloaded) . 844.38 End to End Estimation with 10 clients connected (Server Overloaded) 854.39 End to End Estimation with 10 clients connected (Server Overloaded) 854.40 Full client Side logic Architecture description . . . . . . . . . . . . . . 884.41 Server and clients factors break down Architecture description . . . . 894.42 Third party QoS Enabler Architecture description . . . . . . . . . . . 91

5.1 typical environment for grid of instruments. . . . . . . . . . . . . . . 945.2 RMM-JMS broker/bridge in a LAN-WAN-LAN setup . . . . . . . . . 985.3 Message Rate Tests Scenarios . . . . . . . . . . . . . . . . . . . . . . 1015.4 messages rate for varying number of publishers. Msg size 100 Bytes . 102

List of Figures vii

5.5 messages rate for varying number of publishers. Msg size 1000 Bytes 1025.6 messages rate for varying number of publishers. Msg size 10000 Bytes 1035.7 messages rate for varying number of Subscribers. Msg size 100 Byte . 1045.8 messages rate for varying number of Subscribers. Msg size 1000 Bytes 1045.9 messages rate for varying number of Subscribers. Msg size 10000 Bytes1055.10 RTT test description . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.11 Round Trip Time tests, experimental result. . . . . . . . . . . . . . . 1065.12 percentage of RMM RTT anomalies in a sample of 100000 measures . 1075.13 percentage of Sun MQ 3.6 RTT anomalies in a sample of 100000

measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.14 percentage of Mantaray RTT anomalies in a sample of 100000 measures108

B.1 Instrument Element invocation benchmark test description . . . . . . 116B.2 Test 1 Results: VCR invocation capability . . . . . . . . . . . . . . . 116B.3 Test 2 Results: IE messages handling capability . . . . . . . . . . . . 117B.4 Instrument Manager hierarchy performance tests: 1 IM . . . . . . . . 117B.5 Instrument Manager hierarchy performance tests: 3 IM . . . . . . . . 118B.6 Instrument Manager hierarchy performance tests: 3 IM in 3 machines 118B.7 Instrument Element command distribution benchmark test results . . 119

C.1 Expert-based System . . . . . . . . . . . . . . . . . . . . . . . . . . . 123C.2 ComparisonTraditionalFuzzySets . . . . . . . . . . . . . . . . . . . . 126C.3 Example of Neural Network . . . . . . . . . . . . . . . . . . . . . . . 131C.4 Basic structure of neuron . . . . . . . . . . . . . . . . . . . . . . . . . 132C.5 Interaction between agent and environment . . . . . . . . . . . . . . . 134C.6 Agent action flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . 139

D.1 Testbed software architecture . . . . . . . . . . . . . . . . . . . . . . 144D.2 QoS Testbed component interaction diagram . . . . . . . . . . . . . 145

viii List of Figures

List of Tables

1.1 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Parser Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2 Parser Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3 Document Preparation Additional Cost . . . . . . . . . . . . . . . . . 39

4.1 factors that influence a remote method call . . . . . . . . . . . . . . . 464.2 Functions break down description descriptions . . . . . . . . . . . . . 624.3 Full factorial analysis first part . . . . . . . . . . . . . . . . . . . . . 634.4 Full factorial analysis second part . . . . . . . . . . . . . . . . . . . . 644.5 Descriptions of the linear regression coefficients . . . . . . . . . . . . 654.6 Contrast and Sum of Square analysis for the linear regression of the

total execution time (first part) . . . . . . . . . . . . . . . . . . . . . 674.7 Contrast and Sum of Square analysis for the linear regression of the

total execution time (second part) . . . . . . . . . . . . . . . . . . . . 684.8 total execution time linear regression coefficients . . . . . . . . . . . . 684.9 Residual analysis for the linear regression of the total execution time 694.10 Linear regression coefficient with the key factors analysis . . . . . . . 704.11 Linear regression coefficient with the standard linear regression model 704.12 coefficients for the linear regression estimation of different f(x) . . . . 714.13 coefficients for the linear regression for the dead line estimation func-

tions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

x List of Tables

Preface

This PhD Thesis has been realized and developed in close interaction with thefollowing research and deployment projects:

• Grid Enalbed Remote Instrumentation with Distributed Control and Compu-tation (GridCC - EU FP6 contract 511382 )

• Compact Muon Solenoid Trigger and Data Acquisition System (CMS TriDAS)

• Advanced Gamma Tracking Array (AGaTA)

I wish to thank the Italian National Institute of Nuclear Physic (INFN) and theEuropean Community for the opportunity to participate in these challenging andfascinating activities.

xii Preface

1Introduction

Grid computing refers to the coordinated and secured sharing of computing resourcesamong dynamic collections of individuals, institutions and resources [13], [10], [32].It involves the distribution of computing resources among geographically separatedsites (creating a ”grid” of resources), all of which are configured with specializedsoftware for routing jobs, authenticating users, monitoring resources, and so on.

The operative core of the standard computational Grid is mainly composed oftwo important elements: the Computing Element (CE) and the Storage Element(SE). The first one provides the final user with an abstraction of the backend of thecomputational system. In other words it is where the execution of an application isperformed. This is a very general element that allows different computational nodes,like a single processor or a complex computing cluster, to be seen as a homogeneousset of interfaces. The second one, the Storage Element, provides storage facility forthe input and output of the application that are executed on a CE. The storage canbe as simple as a standard file-system, or a set of databases organized in a morecomplex structure. While remote control and data collection was part of the initialGrid concept most recent Grid developments have been concentrated on the sharingof distributed computational and storage resources.

In this scenario applications that need computational power only have to usethese Grid elements in order to access an unlimited amount of computational powerand disk storage. Unfortunately, as explained in Section 1.1, concrete use casesrequire a strong interaction between the instrumentation and the computationalGrid, in addition they need to be accessed directly from a remote site in the world.For instance, in the Compact Muon Solenoid (CMS) Data Acquisition (DAQ) [10]system , where the data taking phase of an experiment occurs, physicists need asingle entry point to operate the experiment and to monitor detector status anddata quality. In Electrical Utility Networks (or power grids [32]), the introductionof very large numbers of ’embedded’ power generators often using renewable energysources, creates a severe challenge for utility companies. In Geo-Hazards Systems aset of heterogeneous geographically distributed sensor need to be remotely accessedand monitored, while the combined instruments outputs should be automaticallyanalyzed using the computational Grid.

The Grid Enalbed Remote Instrumentation with Distributed Control and Com-

2 1. Introduction

Figure 1.1: Interaction between the Instrument Element and others Grid Component

putation (GridCC) project [77], [83], [48], launched in September 2004 by the Eu-ropean Union, addresses these issues. The goal of GridCC is to exploit Grid oppor-tunities for secure and collaborative work of distributed teams to remotely operateand monitor scientific equipment using the Grid’s massive memory and comput-ing resources for storing and processing data generated by this kind of equipment.This thesis has been developed in close interaction with the GridCC project and,as we will point out in Section 1.2, a significant part of this work contributes to theoutcome of the entire project.

Our idea is to implement a software component that can satisfy all the abovementioned requirements as a new Grid component: the Instrument Element (IE).It consists of a coherent collection of services that provide all the functionality toconfigure and control the physical instrument behind the IE and the interactionswith the rest of the Grid. Figure 1.1 gives an idea of the relationship between theIE and its users and between the IE and others Grid components.

In order to achieve a fast and high level interaction with the instrument elementcomponent, users can directly access the controlled instrument using a Virtual Con-trol Room (VCR) [60]. Or, as a second possibility, an instrument operation canbe part of a complex workflow managed by a Grid execution service that allowsthe IE to access and converse with the computational Grid. These ways to controlthe instruments are not mutually exclusive and can be performed in parallel whereneeded.

Inside the IE a set of Web Service interfaces called VIGS (Virtual InstrumentGrid Service) allows the user to remotely access the real instrument, thus pluggingthe system itself in to the Grid. The Instrument Element can provide facilities for

1.1. Instrument Element Functional and Nonfunctional Requirements 3

interactive co-operation between computing Grid resources and applications thathave real-time requirements or need fast interaction with CEs and SEs. Finally theIE can be also linked to existing instrumentation in order to provide Grid interactionand remote control to standalone resources.

Next section (1.1) details the presented intuitive view.

1.1 Instrument Element Functional and Nonfunc-

tional Requirements

The term ’instrument’ describes a very heterogeneous category of devices. A setof use cases [13], [10], [32], [63], [130], [67], [51], [132], [123], [77], [73],[79], [128]have been deeply analyzed in order to collect the functional and non functionalrequirements of this new Grid component. From an intuitive point of view the IEshould:

• Provide a uniform access to the physical device

• Allow a standard Grid access to the instruments

• Allow the cooperation between different instruments that belong to differentVOs

We need to point out that IE users do not need to be a human. Other softwarecomponents must be able to control the Instruments.

Figure 1.2 shows a use case diagram of the system. A user of the InstrumentElement can have one of three roles:

• an observer: i.e. someone that has the rights to monitor the operation of theInstrument.

• an operator that can instantiate an Instrument configuration, control andmonitor the Instrument.

• an administrator: i.e. someone that can create Instrument configurationthat can be accessed by the observer user and/or the operator user.

Monitoring operation is intended as the possibility to retrieve all informationthat can be used to determine the operational status and to track the operation ofan Instrument System.

Control Operation is intended as the possibility to act on one or more Instru-ments and moving acquired data to and from the computational Grid.

Configure Operation is intended as the possibility to create Instruments or-chestration (i.e. configuration or partition) that can be used by other actors.

4 1. Introduction

Figure 1.2: Instrument Element Use Cases

Instantiation Operation (that it is considered as a Control extension) is in-tended as the possibility to create Instruments, if the physical Instruments providesthis functionality, or to link to them otherwise.

At any moment there can be multiple observers, multiple administrators, butat most one operator that utilizes a particular Instrument. A second Operatoruser that tries to control an instrument already controlled by another Operatorshould be treated by the system as an Observer user. If the real Instrument canbe partitioned in subsystems, multiple operators should be able to access differentInstrument partitions via the same IE.

Close to these functional requirements a Grid of instruments introduces a set ofnonfunctional requirements as summarized in table 1.1. For example the possibilityto control about 104 instruments simultaneously in a interactive way. This intro-duces the need to provide a scalable system (marked as Scalability requirement)equipped with certain Quality of Service (QoS) guarantee as will be explained infuture sections.

In a Grid of instruments, like the computational one, interoperability (markedas Standardization in table 1.1) is a mandatory requirements. Therefore the onlypossible communication between grid subcomponents is via Web Services (WS).

In addition, for complex systems, on-line diagnostics, error recovery and deviceorganization robustness (marked as Autonomic) should be provided. Finally weneed to consider that different instruments use different technologies and protocolsin order to be accessed.

The above mentioned functional and nonfunctional requirements represent thebasic building block of this thesis. We claim that the control of instruments demandsboth deep interaction between users and devices, and the need of the adoption of highinteroperable solutions that only SOA based Web/Grid Services can offer. Therefore,

1.2. Thesis Contributions 5

Table 1.1: Non Functional Requirements

as pointed out in Section 1.2 and 1.3, in order to solve the trade-off between thenecessity of universality and performance, we propose a set of solution that improvesthe capability of SOA Systems in term of throughput and service delay, allowing theprediction of a remote method execution time.

1.2 Thesis Contributions

In this Thesis we firstly introduce a classification of instruments and a uniform modelfor the control of each type of instruments. Then we show the IE Architecture andwe present this system as a solution for integrating instruments with the ’classical’Grid.

In order to fulfill the nonfunctional requirement of high interactivity of our IE, weevaluate the limit of XML-based protocols (SOAP) for high-performance and high-interactive distributed computing. One of the main results is a detailed analysisof the influence of XML parsers in the overheads associated with such communica-tions. We thus propose a new XML parser, the Cache Parser, which uses a cache toreduce the parsing time at sender and receiver side, by reusing information relatedto previously parsed documents/messages similar to the one under examination.

Furthermore, in order to address the QoS nonfunctional requirements of ourIE, whose first release is based on Grid/Web Service technologies, we identify theprediction of a remote method execution time as one of the main challenges. Wethus propose a methodology and an algorithm, based on 2k factorial analysis andon a Gaussian approximation of the collected data, that enables the estimationof a remote method execution time. Finally, we define three different softwarearchitectures in which the developed methodology and prediction algorithm can beexploited and integrated.

Still according to our analysis of non-functional requirements of our IE, wealso address the problem of determining fast communication methods to permitinstruments to properly inter-operate. In this regard, we investigate different pub-lish/subscribe architectures, and we show that RMM-JMS is the best candidatesolution for accomplishing this task.

Finally, all our proposals are validated using suitable benchmarks and extensivetests and comparison with alternative solutions.

6 1. Introduction

It is worth pointing out that the majority of the proposed solutions can beapplied not only to the Instrument Element, but every application based on Weband Grid Services can benefit of these results.

Several parts of this thesis work are currently part of the outcome of the GridCCProject [77],[83], and the thesis has been developed in close interaction with theGridCC community. In particular, we have contributed to the entire software archi-tecture [48] presented in Section 2.2.1 and the related development presented in 2.3.The rest of the scientific contribution of this thesis is currently under adoption (seeChapter 2, 4, 5 and Appendix C) or under evaluation by the project community(Chapter 3)[48], [41],[37],[40],[20],[21],[19],[22],[35],[42],[28], [49]. In addition part ofthe results of this thesis have been pubblicated in conferences and journals [36], [44],[43], [45], [18], [15], [39], [16] or are under pubblication.

1.3 Thesis Overview

The rest of this PhD Thesis is organized as follows:In Chapter 2 we show the Instrument Element system as a solution for inte-

grating instruments with the ’classical’ Grid.In Chapter 3 we evaluate the limit of XML for high-performance and high-

interactive distributed computing and we also present the Cache Parser.In Chapter 4 we address the QoS issues in a Web Service scenario. Then we

present the methodology and the algorithm that enable the estimation of a remotemethod execution time. Finally, we suggest three different software architectures inwhich the developed algorithm can be integrated. In addition, in Appendix D wedescribe how the used datasets, exploited to train our predictive model and validateits estimations, have been created and we verify the data consistence.

In Chapter 5 we address the problem of determining a proper inter instrumentfast communication channel. We investigate different publish/subscribe architec-tures. We thus present RMM-JMS as our candidate solution for accomplish thistask. 5.4.

In addition, Appendix A provides an overview of the current applications thatare using the proposed IE architecture and the related implementation, while Ap-pendix B shows some performance tests on the current implementation. Finally, asintroduced and motivated in Sections 2.2.1 and 2.2.2, in Appendix C, we outlinea set of techniques that can be plugged into the IE in order to control and organizecomplex grid of instruments.

2Instrument Element Architecture

The Grid is a hardware and software infrastructure for sharing computer powerand data storage capacity over the Internet. The operative core of the standardcomputational Grid is mainly composed of two important elements: the ComputingElement (CE) and the Storage Element (SE). The Grid aim to provide reliable andsecure access to widely scattered resources for authorized users located virtuallyanywhere in the world. As anticipate in Chapter 1, we believe that the creation ofa coherent collection of services can allow the remote configuration and control ofphysical instruments and a better integration with the computational Grid. Thesenew collection of services that virtualize a set of physical instruments and permit aeasy integration of them in the Grid is called are called Instrument Element (IE).

The rest of this chapter is organized as follows. In Section 2.1 we present aclassification of instruments and a uniform model for the control of each type ofinstruments. In Section 2.2 we present the IE system as the way for integratinginstruments and Grid. In Section 2.3 the technological choices for the implemen-tation of the first release of the proposed IE model are discussed. In addition inAppendix A we give an overview of the applications that already use the currentimplementation, while Appendix B shows some performance tests on the currentimplementation. Finally, in Appendix C we point out a set of techniques that canbe plugged into the IE (see 2.2.2) in order to control complex Grid of instruments.

2.1 Instrument Classification

In Grid terminology the words ”instrument”, ”sensor” and ”device” are used to de-fine a piece of equipment that needs to be initialized, configured, operated (start,stop, standby, resume, application specific commands), monitored or reset. Re-motely accessed resources play a key role in the Grid paradigm. Our classificationincludes only those devices that can be plugged into a network. In addition, theinstruments must be controlled and monitored remotely in order to enable coop-eration with other grid components, such as the CE, SE, and other instruments.Normally, such functionalities are not part of simple devices, simply because theyrequest too many resources in term of computational and/or electrical power.

8 2. Instrument Element Architecture

To summarize, from a Grid perspective, a device can belong to one of the fol-lowing categories:

• Dummy Instrument

• Smart Instrument

• Smart Instrument in an ad hoc network

The first type comprises very simple hardware. The instrument in this categoryuse data acquisition (DAQ) for remote operation; the data is collected with a set ofdevices that are physically linked together. The devices enable remote network or-ganization and provide higher-level functionalities. These instruments are typicallydeployed in remote sites far from the base station. In addition, only the remote (lo-cal from a sensor point of view) DAQ collector can be accessed in a remote way, thusacting as a proxy for the sensors that are physically connected to. Non-polarizablePetiau electrodes [79] used in the IMAA network, are examples of dummy sensors.

’Smart Instrument’ make up a large category comprising devices that provideall the functionality needed to be remotely accessed and controlled. High-energyphysics and particle physics experiments use these kinds of sensors [130], [10], [128].For instance, a Smart Instrument can be an electronic card that acquires data fromthe concrete detector and dispatches it to one or more machines that perform dataaggregation. Typically, these devices are close together and physically connectedvia a fast communication channel, like a 1 Gb Ethernet or an optic fiber. Perfor-mances and scalability are an issue and key requirements of these instruments aspart of a distributed system. An additional requirement imposed on these devices isautonomicity. The electronic front end and the information collector (event builderor EVB) of a high-energy experiment is composed by thousand of nodes (usuallypowerful PCs), thus, basic fault tolerance and dynamic instrument reconfigurationmust be part of the device’s functionalities.

Smart Instrument in an ad hoc network can be seen as a specialization of theprevious category. Such devices need not be in close physical proximity, but ratherthey can remotely communicate through specialized wireless connections. In gen-eral, batteries fuel these devices and mobile sensors are part of this category. Thechallenge is to minimize the energy consumption of the communication channel.Finally, we should keep battery consumption uniform between different devices tominimize human interaction with them.

2.1.1 A Uniform Instrument Model

Since the instruments are heterogeneous in nature, one current shortcoming is thatthe applications that use them (e.g., data acquisition codes) must have a completeoperational model of the instruments and sensors they work with. This makesmaintaining investments in these codes difficult and expensive when the underlying

2.1. Instrument Classification 9

Figure 2.1: abstraction model of a generic instrument

instrument hardware is changed and/or improved. A primary design goal for thischapter is to externalize the instrument description so that applications can buildan operational model ”on the fly”. This approach makes it possible to preserveinvestments in data acquisition codes as instrument hardware evolves and to allowthe same code to be used with several similar types of instruments.

The presented instrumentation model is used in order to meet the functionalrequirements, it can be used for each device independently from the category thatit belongs. In the following Sections, we will better understand why the implemen-tation of this model is really dependent on the instrument types.

Figure 2.1 show our instrument model abstraction.We can consider a generic device as a collection of Parameters, Attributes, a

Control Model, plus an optional description language. More detailed Parametersare variables on which the instrument depends, like range or precision values of ameasure, while Attributes refer to the effective object that the instrument is mea-suring.

The main difference between Parameters and Attributes is that typically thefirst one are accessed in a polling mode wile for certain type of attribute, like acam streaming for instance, a publish/subscribe or a stream access method is moreappropriate. Therefore, both push and pull access ways must be supported forattributes.

The control model represents the list of command that the instrument can sup-port. This list can be expressed using a state machine model, a Petri Net etc. Wehave to note that in this abstraction, we refer to the term ”command” to both theactions that either change the instrument status or not. Parameters, Attributes andthe control model can give the possibility to control every possible instrument orsensor, but what is still lacking is the possibility to allow the device to describe itself,giving to the user the possibility to understand what exactly it can they do with thisinstrument. In order to achieve this goal an XML based description language is alsopart of our instrument abstraction. Language like the SensorML [13] or OWL-DL


[87] can be use to describe the semantic of the particular instrument.The presented abstraction provides a uniform layer across different device and

can be used as building block for the control of complex system like the CMS ex-periment [10] that is composed by about 2 ∗ 107 piece of hardware and about 104

machines dedicate to the on-line elaboration phase. In order to simplify the controlof these systems, instruments can be logically (or physically) grouped into hierar-chies, from which data can be aggregated or for which control commands affectmultiple sensors or actuators. What is needed in this case is an instrument aggre-gation model, like the one that we will present in the next Section, which is capableto control all these devices in a congruent way.

2.2 Instrument Aggregation Model

The integration of one single instrument into the grid is a relatively simple task.Problems come when million of different instruments need to interoperate each otherin order to achieve common goals, giving to the external users a well defined entrypoint. In order to simplify this task, some services could be created around theinstrument that allow a uniform interaction , by giving the illusion of controlling asingle device.

We define the term Instrument Element (IE) as a set of services that provide theneeded interface and implementation that enables the remote control and monitoringof physical instruments. The IE need to be really flexible; in the simplest scenariothis abstraction can represent a simple geospatial sensor or an FPGA card thatperforms a specific function, while in a more complex sensor network it can be usedas a bridge between sensors and computational Grid. Finally, the IE can be partof the device instrumentation, permitting the organization of the instrument in anetwork allowing Grid interaction.

Unlike the CE and the SE, this Grid component is not accessed using non inter-active computational job execution, but requires a close interaction with the userssit in the Virtual Control Room (VCR) [60].

If we see the IE as a black box that allows the interaction of instruments in auniform way, we can identify 3 different communication channels. Firstly a uniforminterface that allows the control of the different system devices in a uniform andcoherent way. Secondly an output channel that allow a fast instrument coopera-tion that permits the reception of asynchronous data and monitor information thatcame from the instrument attributes. And finally a set of services that allow theinteraction between the instrument and the standard Grid system.

A lot of similarity can be seen with the black box model presented in Figure2.2 and in the one discussed in Section 2.1.1. The main difference is that the IErepresents a collection of instruments that can work together or simply belong to thesame organization, so an index service that addresses them is mandatory. Finally,we can note that the IE itself is consistent with the model presented in Section 2.1.1

2.2. Instrument Aggregation Model 11

Figure 2.2: The Instrument Element Abstraction

therefore an IE can be part of other IEs. In addition, the IE acts also as a protocoladapter providing a uniform way to control heterogeneous devices. We believe thatWeb Services are an excellent choice when there is a need to provide a commonlanguage to the cross domain collaboration and to hide the internal implementationdetails of accessing specific instruments. Standards like SWE [13], JMX [50], or IVI[123] and P2P Systems like JINI [107] and Freenet [117], [11] have been analyzed inorder to ensure that the front end (called Virtual Instrument Grid Services or VIGS)final methods are really capable to provide a generic instrument virtualization.

As final remark as already introduced in 1.1, the control of instruments demandsdeep interaction between users and devices. Consider that when the access is per-formed via internet using Web Services calls, the remote invocation time becomingcritical in order to understand if a service can be controlled properly or the delaysintroduced by the wire are unacceptable.

To summarize the mentioned requirements, we can define two different types ofaccess with different Quality of Service:

• Strict (hard) guarantees: The response to a requested service is reliable; inthis case the availability of an Agreement Service [48] that perform advancedreservation is necessary and can negotiate ”interaction times” with a compo-nent.

• Loose (soft) guarantees: The response to a requested service is unreliable.Therefore QoS is provided on top on a best-effort infrastructure. In this casea prediction method based on statistical approach must be provided.

Techniques, allowing interactive web service improvement, prediction of a re-


Figure 2.3: The Instrument Element Architecture

mote method execution time and can be used in this particular context, have beenpresented in Chapter 3, [44] and in Chapter 4, [43].

What follows is a description of the main building block and a detailed descrip-tion of the most important ones.

2.2.1 Instrument Aggregation Building Block

This Section describes the main IE building blocks presenting the set of additionalservices that can simplify the access and the control of instruments. We presentthe mentioned services as centralized components and in the next sections (2.2.5)wediscuss on where these services should be implemented in a centralized or in adistributed way is underlined.

Figure 2.3 represents the detailed Instrument Element architecture and whatfollows is a short description of each subsystem component.

Instrument Managers (IM): The instrument managers are the parts of theinstrument element that perform the actual communication with the instruments.They act as protocol adapters that implement the instrument specific protocols foraccessing its functions. One IM can control more than one single device and it iscoherent with the model presented in section 2.1.1. In other words it can be seen byother IMs as an instrument, allowing a hierarchic partition of the controlled devicewhere the complexity of the system requires such control structure.

Resource Service (RS): This service organizes all the resources that belong to


the system in groups, in order to facilitate the access. In this context a resource canbe any hardware or software component that can be managed directly or indirectlythrough the network.

Information and Monitor Service (IMS): This service disseminates moni-toring data to the interested partners, giving a single access point to all the infor-mation produced by the instruments.

Problem Solver (PS): It has the main task of collecting alarms, errors, warn-ings and messages, which in our models are instrument attributes and parameters,in order to identify error conditions [36]. We have to note that an error recoverycan be part of the IM control logic but while this component mainly is involved inthe on-line recovery the PS can act off-line trying to discover unknown rules.

Access Control Manager (ACM): It is responsible for checking user creden-tials and deciding whether an external request should be processed by the InstrumentElement [48].

Data Mover (DM): since we can not assume that instruments are complexdevices, they need an external service in order to deal with the classical computa-tional Grid. This component provides this functionality in a centralized way. In afully distributed scenario like Sensor Network a decentralized approach could moreappropriate, therefore part of this functionality could be part of the IM component.This service provides the SRM [80], [81] interface to any external storage (SE) orprocessing elements (CE). It finds the ’best’ mechanism, such as GridFTP [74], [86]or others transport protocols, to move a file from one storage resource to another.For more demanding application grid standards could be inappropriate due to thehigh bandwidth requested and might be needed a streaming output and/or an MPIinterface that allows push subscription capability of the instrument attributes.

2.2.2 The Instrument Manager (IM) Abstraction

As already mentioned the IM is the component that deals with the instrument orthe instrumentation of the physical device. Each IM is responsible for performingthe actual communication with the controlled set of instruments. It acts as protocoladapter that implements the instrument-specific protocols for accessing their func-tions. Considering that instruments are heterogeneous in nature, this component isalso equipped with a plug-in/driver based system, that allows an easy reuse of code, by changing just the communication library that implement the device dependentcommunication protocols. For simple devices that requires a minimal control struc-ture, no additional code must be written; in the same time in multiple and complexcontrol devices this component provide all the basic building block that allows thecustomization control system. Finally the IM is conform to the model presented insection 2.1.1 therefore it can be seen by other device as an instrument itself allow-ing instruments aggregation and hierarchic organization, thus achieving the goal ofbreaking down the complexity of the system or organizing the instrument in groups.

In addition the IM can allow the cooperation with other devices and this it is a


key feature when working in a Grid of instruments. Instruments in the ’smart sensor’category need to exchange data without loss, as fast as they are being generated.The data collectors devices, or some other dedicated set of instrument, process thedata (filter and aggregate) and move it to a final location. Afterwords the data, viathe data mover, is stored in a repository or in a storage element for future off-lineanalysis.

The main components of each Instrument Manager are:The Communication Tools can be used by every single sub-component in

order to publish/receive information like logs, errors, states, configuration, etc andto receive messages coming from others component. This service acts also as a proxyfor the higher-level Data Mover service. If data produced by the set of controlledinstruments arrive at large rate, this low-level service makes the movement of suchdata more manageable. Finally, these tools represent the instrument front end ofthe Information and Monitoring System.

The Control Manager is the component that actually controls the instrumentand/or the instrumentation. The typical use case of this sub-system is to receiveinputs from the users that are controlling the devices. It can also receive inputs likestates or errors that come from the physical controlled instrument. So it can react inan autonomous way to unexpected behavior of the controlled resources by allowingautomatic recovering procedures to be started. This autonomic action becomescritical, if the IM controls a large set of instruments while for simpler devices suchfunctionality becomes less important compared to the need to have a plug-in systemthat integrates the device drivers.

Input Manager: waits for an external input and present it to the Event Proces-sor. Input can come from users, other instrument managers, or from the devicesthemselves in case of smart instruments. In this last case, considering that each in-strument have a different way to communicate, a driver component must be providedand loaded inside the particular IM. Resource Proxy: this component represents theinstrument manager instrument front end. The control library used in order to ex-change messages with the physical device must be plugged inside; this is the minimalcustomization action that must be performed in order to plug a generic device intothe Grid.

Event Processor: in this component the command will be elaborated in order tocontrol the instrument properly. By default, events just trigger the proper action inthe proper resource proxy. In the same time, using the plug-in system, this compo-nent can be used in order to provide an aggregate and more complex control allowingthe possibility to plug inside every possible algorithm: Expert systems, fuzzy logic,custom if-then-else, Neural Networks, etc.. Appendix C provides an overview oftechniques that can be adopted in complex control systems. As final remark, thiscomponent represents the basic infrastructure of the Problem Solver allowing recov-ery action and or fault-tolerant procedure, in case of sub-system failure.

Finite State Machine Engine: is specifically designed in order to simplify theevent processor algorithms providing simple call backs mechanism where writing


Figure 2.4: VCR-IE Interactions

the action that must be performed according to a particular triggered transition. Italso provides the possibility to perform introspection by external users that want tocontrol the particular IM.

Figure 2.4 shows in details the interactions occurring in the IM Sub-component.The dotted lines are optional actions that can be performed or not on the basis of theparticular received input, while the others lines are mandatory. In addition, the firsttwo lines are actions triggered by the users in the VCR. From the temporal point ofview, events coming from users command or instrument messages are received fromthe input manager and the information is processed in the Event Processor sub-module. Such sub-module, on the basis of the received input, can decide to performa state transition according to its finite state machine (FSM), and/or control thereal instruments via the Resource Proxy module. Once the action is successfully orunsuccessfully accomplished, a notification is sent back to the users.

2.2.3 Resource Service (RS)

The complexity of the information managed by the RS is really instrument depen-dent and ranges from practically fix configuration to a configuration and orchestra-tion of thousands of nodes [13], [10],[32],[128]. In any case, it provides a uniformway and a single entry point of access to the information related to a particularinstrument from external users.

If a system, like a sensor network, allows the possible use of a subset of devicesmanage also this partitioning. In addition, this service can act as a super peerin dynamic instrument network, where simple devices can appear and disappear.Finally this service can permit a reservation of the system, allowing the possibility


Figure 2.5: Classification of the Information Contained in the Resource Service

to bookmark resources by authorized users.The Figure 2.5 classify the information that have to be retrieved from the Re-

source Service for every instrument.From a semantic point of view we can divide the information in three different

categories. (1) Information, like physical locations of configuration file or driver typeetc, which is only internal to the Instrument Element and is needed in order to ensurethe correct instrument instantiation. (2) Information that can be modified at runtime by the users that could change the global behavior. The numbers and types ofinstruments that should be used to perform particular aggregate actions are typicalinformation that belongs to this category. The last category (3) of informationidentifies the instrument topology, i.e., both potential and actually performed intra-instrument connections.

The same information could be categorized from the dynamicity point of view.(a) Static information refer to data that will be defined at deployment time andthey will never change in the future. As opposite, (b) Dynamic information consistsof data that can change in an automatic way, without users intervention. In themiddle, we have (c) Low Dynamic information, which corresponds, for example,toadjustments performed by the users at run time.

We can note that, most of information is close to the instrument, and belong to aparticular instance. In addition, considering a set of instrument as one single device,static information introduces rigidity to the system while low dynamic informationintroduces complexity in the global system usage. As we will point out later inSection 2.2.5 complex static systems configuration, that typically are simpler toimplement, could be the solution in use cases where all instrument need to be in aconsistent state in order to produce a coherent output [10], [128]. Unfortunately, thissolution remarkably increases the configuration problem providing a fix structurethat, in case of subsystems fault, must be manually reconfigured by the users. Inhigh dynamic system like the one described in [32] and in [13] this solution is simplyunusable because the introduction of a new node in the system triggers a totalreconfiguration.


Figure 2.6: Publish Subscribe Architecture

2.2.4 Information and Monitor Service (IMS)

Instruments and Instrument Managers dispatch data and monitorable informationvia this service. We have to point out that more demanding applications like [10]request that this service can handle about 105 messages per second. Therefore thissystem cannot be implemented in a centralized way. In addition, as explained inchapter 3 standard messages format like SOAP cannot be used in these componentdue to the overhead that this serialization introduces [44]. Finally, taking intoaccount that instruments are independent and low coupled with each others, aninformation and monitor system should preserve the mentioned properties.

As a result, architectures like the one presented in [91], [6] and [4] appear to bethe most appropriate for this task. In these systems peers publish information in agiven topic to subscribers that previously notifies their interest (see figure 2.6 ).

Using this particular approach we allow peers in the network to the dynamicallyappear and disappear, preserving a certain robustness with respect to system faults[14].

Once the connection to the particular information channel has been established,publishers can start sending data. Considering that high throughput is a must inthis cases a bridged/relay [4],[109] solution appears to be the only way to preservethis characteristic.

Figure 2.7 tries to explain what was mentioned before in a simplified scenario,where one publisher, which belongs to a particular private network, tries to sendinformation to peers disseminated throughout the world. Using a smart protocol,the publisher can reach peers locate in the same LAN and/or communicate to thebridge component that is connected with others bridges via standard communicationprotocols, like TCP and HTTP. Bridges, once received the messages, firstly convertthem into more suitable format, and secondly send them to peers that are in thesame LAN domain. Multicast protocols can be used in order to reduce the numberof messages that publishers need to continuously improving the performance of thesystem [8].

2.2.5 Static vs Dynamic Aggregation Models

The term Instrument describes a very heterogeneous category of devices. Refer to[13], [10], [32], [63], [130], [67], [51], [132], [123], [77], [73],[79] and [128] as a large


Figure 2.7: IMS Architecture

set of examples. Even if we believe that a uniform and coherent set of services canfacilitate their aggregation and the interoperability across different organization, theapproach to the implementation could be really different. In [10] for instance, theCMS data acquisition phase can start only if all the instruments of the system arein a consistent status, while, in [13], [32], [51], instruments can dynamically jointhe system. In these cases we can not assume information like an index of all in-struments, that is the base abstraction of the Resource Service, is static. The IMbehavior needs to dynamically adapt itself to the dynamic existing instrument struc-ture. This particular functionality is typical of P2P [66] systems where the networkcan dynamically adapt to peer changes. By the way, a single and relayable entrypoint of this information is mandatory if we want to provide a set of instruments asa service for the computational Grid.

Considering the information categorization that we defined in Section 2.2.3, wecan note that static information and some of the low dynamics, belong to a partic-ular instrument instance while instruments topology information must be a sheerattribute between devices in order to avoid collisions organizing the instruments inthe proper way. In typical discovery based on P2P, a peer announces itself to thenetwork giving other peers the possibility to perform query and exchange data.

In this scenario, instruments can dynamically engage other existing instruments,performing a system lookup and allowing the dynamic determination of the peers’topology.

This approach distribute the information to the instruments therefore break theglobal configuration in several parts that in principle could dynamically changeduring the system usage.


Figure 2.8: Instrument Discovery Interaction Diagram

Figure 2.8 explains the dynamic join of an instrument into the System. After abootstrap, the instrument sends a discovery request to other peers and relays even-tually forward this request to unreachable devices. Instruments reply to this requestby announcing their presence into the network and then the new born instrumentenquirers the others in order to discover what type of device they are. Once theinstrument finds the needed resources it engages and uses them.

If an instrument disappears from the system, other devices can repeat the dis-covery/Information Enquiry phases in order to try and find the needed resources.In addition this operation can also be repeated in case of failure in order to detectthe recovery of the needed subcomponent allowing an autonomic behavior.

In this P2P scenario, the information are no more centralized but distributedin the system. Therefore this approach complicated monitor functionalities thatneed a discovery system too in order to detect the actual instruments topology. Inother words, the Resource Service end point must periodically repeat the instrumentdiscovery and information enquiry phase, as all the system devices, in order todetect the status of the entire system. Alternately (or in parallel), instruments canperiodically send an advertise messages in order to inform interested peers to theirstatus.


Figure 2.9: Embedded Devices

2.2.6 Embedded Devices

In this context we refer to an embedded device as one with limited computational andnetwork capacity. In order to reduce the system requirements, IM with very limitedfunctionality can be directly installed into the electronic front end. This enablesothers IMs to remotely contact this device using a low level communication channel,allowing a bridged communication that can enable a more elaborate interaction.

For complex system like [10], [128], Embedded applications that run in ad hocelectronic cards can also use the communication tools to dispatch the data justacquired to the thousands of nodes that constitute the event builder layer. EachEvent Builder (EVB) machine, which can be seen as an instrument, operates as asubscriber on the messages (data) sent by the publishers - the devices on the cards.The selection of the required devices is enabled by associating a topic with a device.The incoming data messages are then sampled using the publish/subscribe selectorcapabilities [4], [91]. The data is further processed and an event is generated and sentto a subset of machines that perform an additional intermediate step of ”collectionand aggregation”. Finally, this data is sent to the last layer of machines that savethe data via instrument managers directly connected to the data mover.

2.3 Conclusion

Several technologies have been used in order to implement the first Java based IErelease, such as tomcat + axis as web service engine, that provide a WS-I compliant[99] software end point. The usage of quite mature open source software was drivingour choices in this field.

The Resource Service use JDBC [93] connections to MySQL and Oracle DB in

2.3. Conclusion 21

order to retrieve the instruments configuration information and the IE embeddedGUI is based on JSP [92] and AJAX [47] technologies.

Finally the standard Apache Logging System [102], such as log4j, has beenadopted in order to acquire run time information of each single software sub-component.

In order to ensure the high throughput needed by the IMS component (see 1.12.2.4 ) we have also used a JMS [91] implementation on top of a high performanceReliable Multicast Messaging (RMM) layer [8]. As we will better understand inChapter 5, RMM allows hosts to reliably exchange data messages over the standardIP multicast network. It exploits the IP multicast infrastructure to ensure scal-able resource conservation and timely information distribution with reliability andtraffic control added on top of the standard multicast networking. The RMM-JMSextension is a very efficient Java implementation of the JMS standard using RMMservices.

RMM-JMS supports:

• Multicast transport for pub/sub messaging: Supporting the JMS topic-basedmessaging and API, with matching done at the IP multicast level. The trans-port is a Nack-based reliable multicast protocol.

• Direct (broker- less) unicast for point-to-point messaging: Supporting the JMSQueue based messaging and API. The transport is the TCP protocol.

• Bridged/Brokered unicast transport for pub/sub messaging.

In order to fulfill the Scalability requirement mention in Section 1.1, Chapter3 evaluate the limit of XML for high-performance and high-interactive distributedcomputing like the presented IE. It also proposes a new parser, the Cache Parser,which uses a cache to reduce the parsing time sender and receiver side, by reusinginformation related to previously parsed documents/messages similar to the oneunder examination.

Otherwise, in order to solve the Quality of Service (QoS) requirements (see Sec-tion 1.1 and 2.2 ), Chapter 4 addresses the QoS issues in a Web/Grid Service sce-nario identifying the prediction of a remote method execution time as the biggestchallenge. Then this chapter proposes a methodology and an algorithm based on 2k

factorial analysis and on a Gaussian approximation of the collected data that enablethe estimation of a remote method execution time. And Finally, it suggests threedifferent software architectures where the developed algorithm could be integrated.

In addition, Appendix A provide an overview of the current applications thatare using the proposed architecture and the related implementation while AppendixB and [18] show some performance tests on the current implementation. FinallyAppendix C provide an overview of existing techniques for complex control systemsin order to fulfil the autonomic requirements as discussed in Sections 1.1 and 2.2.2.

3On Improving the Web Service

Interactivity

This chapter addresses the problem of performance degradation due to the use ofWeb Service (WS) communication in a distribute architecture like the InstrumentElement Architecture proposed in chapter 2. As stressed in Section 1.1 and 2.3 Scal-ability and high Interactivity between users and instruments is a challenge activity.Therefore we believe that, reducing the overhead introduce by the adoption a highlevels standards like WS, we can increase the effective system performances.

In Section 3.1 we formalize the above mentioned problem while in Section 3.2we present the present status of art.

In Section 3.3 we investigate the limitations of XML for high-performance andhigh-interactive distributed computing. Experimental results clearly show that fo-cusing on parsers, which are routinely used for deserialize XML messages exchangedin these system, we can improve the performance of a generic end-to-end solutionbased on web services.

In Section 3.4 we present a new parser, the Cache Parser, which uses a cache toreduce the parsing time sender and receiver side, by reusing information related topreviously parsed documents/messages similar to the one under examination.

Finally, in section 3.5 we will show how our fast parser can improve the globalthroughput of any application based on Web or Grid Services, or also JAXP-RPC.Experimental results demonstrate that our algorithm is 25 times faster than thefastest algorithm in the market and, if used in a WS scenario, can dramaticallyincrease the number of requests per second handled by a server (up to 150% ofimprovement) bringing it close to a system that does not use xml at all.

3.1 Problem Formalization

XML [90] is a mark-up language used for describing structured data. An XMLdocument consists of elements and their attributes, where each element has a nameand is characterized by start and end tags. The content of the Element is includedbetween the tags, and may consist of other elements, data or may be empty. Eachelement may have attributes that consist of pairs (name=value). XML enables

24 3. On Improving the Web Service Interactivity

users to introduce elements and attributes, their names and their relations in thedocument, by specifying a particular XML syntax (DTD/Xschema). The purposeof this syntax is to define the legal building blocks, the structure and the list of legalelements of an XML document.

An XML-based set of technologies are those at the basis of Web Services (WSs)[38], [76],[82],[66], by which existing legacy systems can be wrapped as WSs, andmade available for integration with other systems. Applications exposed as Webservices are accessible by other applications running on different hardware plat-forms and written in different programming languages. Using this approach, thecomplexity of these systems can be encapsulated behind XML/SOAP protocols.

A common trade-off in computing is between the need of universality and perfor-mance, and this is particularly true when WSs must be exploited to design a systemin which both high performance and QoS requirements are mandatory. Fulfillingboth such requirement is really necessary in a limit case such as scientific com-puting. It demands the full range of capabilities that industrial computing does:reliable transfer in distributed heterogeneous environments, parallel programs of-ten exchanging data, self-contained modules sending events to steer other modules,and complex run-time systems designed for heterogeneous environments with dy-namically varying loads, multiple communication protocols, and different Qualityof Service (QoS) requirements. Unfortunately, the qualities of SOAP that makesit universally usable tend to lower the communication performance. In particular,the features that make XML communication inefficient regard the primarily ASCIIformat of XML, and the verbosity of XML, due to the need of expressing tags andattributes besides the true information content.

As we will see in Section 3.3, in a WS environment a lot of runtime activityis however spent in parsing XML documents: every client or server process needsto exploit an XML parser to send/receive messages. So speeding up the parsingalgorithm should have a big impact on the total communication time, by largelyreducing overheads. In particular, we are interested in reducing the overheads onthe receiver side, where the task of a parser is to deserialize the message by checkingwhether it conforms to the DTD/Xschema syntax, and extracting data from thetextual XML representation.

We noted that in high performance computing systems based on WSs, like con-temporary Grids currently programmed through Grid Services,( i.e. a technologybuild on top of WSs), each subsystem routinely exchanges information by usingvery similar XML-formatted messages. The exchanged XML information often hasthe same ”structure”, i.e not only the same DTD/Xschema syntax, but also thesame particular syntactic tree. ”Standard” parsers do not use this information toimprove unmarshaling algorithm performance, so we develop a cache-based systemthat takes advantage of this behavior. When the system parses a new XML docu-ment, it first tries whether his structure matches an already know structure. Thisis quickly carried out by testing a document checksum. In case of a cache hit, thedocument will be parsed with a fast algorithm that exploits the stored knowledge

3.2. Related Work 25

on the document syntactic tree. Otherwise, the document will be analyzed by usinga standard parser, and a new cache entry will be created to store the syntactic treeof the new document.

Like all the WS, the VIGS, i.e. the user interface of our IE, has a static structure.In addition the XML documents/messages that are exchanged between the IE’s pro-cesses and the specific instruments, are usually characterized by a ”persistent” struc-ture. Note that in our WS implementation such messages are XML-formatted ones,which are inserted in SOAP envelopes and then passed on via HTTP to a receiverthat parses it to extract valuable data. Even if all the remarks about the persistenceof the structures of the message are motivated by our specific Grid use-case, wherea multitude of senders have to send multiple times messages characterized by thesame structure to a small set of receivers, a similar persistence in XML messagesexchanged can also be observed in several other distributed applications based onWeb/Grid Service technologies.

3.2 Related Work

Parsers break documents into pieces such as start tags, end tags, attribute, valuepairs, chunks of text content, processing instructions, comments, and so on. Thesepieces are fed to the application using a well-defined API, implementing a particularparsing model. Four parsing models are commonly in use [98], [131], [124], [56], [27]:

One-step parsing (DOM): the parser reads the whole XML document, andgenerates a data structure (a parse tree) describing its entire contents.

Push parsing (SAX): the parser sends notifications to the application aboutthe types of XML document pieces it encounters during the parsing process.

Pull Parsing: the application always asks the parser for the next piece ofinformation appearing in the document associated with a given element. It is as ifthe application has to ”pull” the information out of the parser, and hence the nameof the model.

Hybrid Parsing: this approach tries to combine different characteristics of theother parsing models to create efficient parsers for special scenarios.

Several optimization techniques are developed in order to improve the WS per-formances. In [1] the idea of avoid complete serialization of SOAP messages bystoring and reusing message templates is exploited while in [9] and [62] focus theirattention on arrays that are data structure largely used in Scientific Computing.Finally in [31],[31],[95] ,[78] and [122] other binary XML protocols was proposed forenhancing WS performance. Our approach, like [1], still involves a cache system butthe stored information is totally different since our goal is to help the deserializationprocess of ”fresh” different documents that share the same syntactic tree. We decideto adopt the pull-parsing approach, though the principle of our technique can beused in conjunction with any other parser. As previously mentioned, we maintaininformation about already parsed syntactic tree XML document to fast parse new


Figure 3.1: 3-tier Architecture and Sequence diagram

document sharing the same XML tree but with different tag value.

3.3 Understanding the XML limit

This Section describes a high level and general architecture, used to build a genericmodern web-based application like our IE. The general architecture reviewed isapplicable across technologies [53], [3] so that we use it to understand the limitsthat an XML solution can introduce in terms of interactivity and handling requestsper second. A modern web-based enterprise application has 3 layers (see figure 3.1):

A client layer, which is responsible for interacting with the user, e.g., forrendering Web Page;

A middle tier that includes:

1. A Presentation Layer, which interprets user inputs (e.g., her/his submittedHTML forms), and generates the outputs to be presented to her/him (e.g., aWebPage, including their dynamic content).

2. A Business Logic Layer, which enforces validations, and handles the interactionwith the data layer.

A data layer, which stores and manages data, and offers the handling interfaceto the upper layers.

This structure allows changes in legacy host access and development of new busi-ness logic to be kept separated from the user interface, dramatically reducing the

3.3. Understanding the XML limit 27

cost of maintenance. Three-tier architectures also enable large-scale deployments,in which hundreds or thousands of end users are enabled to use applications thataccess business information. Our motivating application, the IE, follows this ab-stract architecture: it is just a 3-tier application, with a strong separation betweenthe Business Layer and the Presentation layer, and which uses a very simple datalayer. Talking about business to consumer applications, the client layer of a webapplication is implemented as a web browser running on the user’s client machine.Its job in a web-based application is to display data and let the user enter/updatedata. In a business to business scenario the client layer can be a generic application,compliant to the web-service standard. The presentation sub-layer generates (ordisplays) WebPages, or produces (or interprets) XML-based SOAP messages in aWeb Service scenario. If necessary, it may include dynamic content in them. Thedynamic content can originate from a database, and it is typically retrieved by theBusiness logic that:

• performs all required calculations and validations;

• manages a workflow (including keeping track of session data);

• handles all the needed data access.

For smaller web applications, it may be unnecessarily complex to have two sepa-rate sub-layers in the middle tier. In addition the sub-layer communications typicallydo not use XML.

From a temporal point of view (showed in figure 3.1) a client (Web Services, webbrowser, java, c++, etc) performs a request to the business logic, which dynamicallyretrieves the requested information. During the elaboration phase, the server caneither perform one or more queries to a persistent storage, or interact with othersub-business unit. Once the information is retrieved, the server formats the retrievedinformation in a way that the client is able to understand, and sends it back to theclient.

In a Web Service scenario, the clients need to exploit a further SOAP protocollayer over HTTP communications, while in human client scenario they the commu-nication can be made just via HTTP. The purpose of the next Section is understoodthe real costs of the validation and reply formatting phases, by also varying the usedtechnology. We setup a set of tests, using a synthetic application that follows thementioned 3 layer architecture. Other benchmarks were already published on SOAPperformance, but our approach differs from the ones discussed in [26] and [62]. Whatwe would like to evaluate, is the WS behaviour in a real scenario, understandingWS limits and clarify when a WS approach fails. In particular, unlike [26], we focusour attention on WSs exchanging short messages that are most common in businessand instrumentation applications.


3.3.1 3-tier Test bed

In order to reproduce the architecture presented at the beginning of this paragraph,in the same local LAN we set up two different server machines, the former hosting anOracle DB Server as a storage system, and the latter hosting a Tomcat ApplicationServer as a Middle Tier. Then we run a set of clients on other different machines inthe same cluster.

The hardware used in this test is:

• Database Server: Dual Xeon 1.8 GHz, with 2 GB RAM, Ethernet 1 Gbps,OS Red Hat Linux Advanced Server 2.1.

• Application Server: Dual Xeon1.8 GHz, with 1.5 GB RAM, Ethernet 1Gbps, OS Red Hat Linux Advanced Server 2.1.

• Clients: 25 Pentium III 600 MHz, with 256 MB RAM, Ethernet 1 Gbps, OSLinux Red Hat 9.0.

As Client/Server communications we used:

• Simple HTTP

• SOAP/XML over HTTP

Within the same Tomcat server, we also set up an Axis engine, in order toevaluate the performance of a WS communication (i.e., SOAP/XML+HTTP withautomatic generated stubs) between client and server.

The DB table structure and the complexity of the queries are really simple (i.e..,1 table, with 5 attribute, as a DB structure).

Our benchmark is thus the following: the clients (Java applications) perform arequest to a Tomcat Servlet or to Web Service. The business logic layer, in orderto present the result to the client, performs a query using a pre-generated JDBCconnection, to the DB server. Then the same layer formats the result and sends itto the client.

In this scenario we evaluate both the response time of a single client connec-tion, and the global application server throughput in terms of satisfied requests persecond. The results are shown in next paragraph.

3.3.2 Service Request Time

We measured the service request time, just using one client. Therefore we canassume that both the application server and the data base server are not busy, asthey have to serve one request at a time.

Figure 3.2 shows the average times when using either servlet or Web Servicetechnology.


Figure 3.2: Service request time for servlet and WS


As we can see, the total delay time of the WS (100 ms) is greater than the servletone (16 ms). We can also note that the most of the request time is spent during theSOAP/XML serialization / de-serialization of the objects exchanged between theclient and the server.

We have to note that the marshalling and un-marshalling process only dependson the exchanged data, and not on the complexity of the elaboration phase. Thismeans that the WS cost, in terms of service delay, is important and non negligible forreal time or interactive applications, where the final user/program typically needs areply in a short amount of time. For non interactive service, this delay is acceptable.Considering that the motivation of this work is to increase the performance of a sys-tem in term of handled requests per second, we can focus our attention on reducingthe average service time. By the way, if we need to analyze such systems and ex-ploit the results of profiling in order to guarantee QoS, an analysis and an eventualreduction of the standard deviation of the service request time is mandatory. Theadoption of our Cache Parser reduces the de-serialization overhead, and thus is ableto increase the overall throughput of the server. By the way, it is well known thatthe adoption of a cache system can increase the standard deviation, and thereforethis approach cannot increase the QoS in case of not negligible cache misses.

3.3.3 Handled Request per Second

According to the scenario described in Section 3.3.1, we also performed a test aimedto understand the number of requests handled per second in two different scenarios.In the first one, a servlet or a Web Service, once invoked, it performs a query on thestorage system and sends back the result. In the second scenario, we remove theData Layer in order to exactly measure the service invocation time.

The plots in Figure 3.3, 3.4, 3.5 are related to the first set of measure.The ”ServletRPCXML” curve refers to a servlet that does exactly the same

as the WS actions: in particular, it is only at the preparation that the result issent to the client. The ”ServletRPC” refers to a servlet that does exactly thesame job as the previous one, but the exchanged information is serialized in simpleHTTP. The ”Servlet” curve differs from the first because, instead of buffering theresult and sending it at the end of the preparation phase, it immediately startssending it in a streaming way using an HTTP custom serialization. We can alsonote that the performance of WS is similar to ”ServletRPCXML”. This means thatits large performance decrease is due to both, buffering of the results and XMLserialization, since the clients and the server have additional computational andsynchronization overhead. As we can see, WS infrastructure introduces a remarkableperformance overhead due to the XML serialization, and cannot allow simple, buteffective, code optimizations, like the one previous mentioned for the ”Servlet” curve,to be exploited.

The plots in Figure 3.6, 3.7, 3.8 refer to the invocation of an empty service thatimmediately returns the results with a constant size (10 tags) to the client. While in


Figure 3.3: Handled request per second using a storage tier and varying the queryresult size




the previous set of tests the input service request was fixed and the reply was varied,in this second set we are varying the size of the input messages keeping constant thereply one.

As we can see, once again, the cost of WS in terms of number of handled requestsper second is not negligible, and limits scalability since the number of invocationsper second does not increase when we raise the number of clients.

Finally, as one can expect, when messages are short and less complex (in termsof XML tags) the throughput is better than when messages are large and morecomplex.

As pointed out in the introduction of this chapter, we are interested in increasingthe WS performance in a scenario where the exchanged messages between compo-nents are short. So we decided to focus our attention on parsing algorithms, inorder to reduce the un-marshalling computational time. Next paragraph presentsour solution: the Cache Parser, which strongly reduces the overhead due to theXML use.

3.4 The Cache Parser

In this section we present a view at higher level of our parsing algorithm, while inthe next sections we will discuss in more detail each step of the algorithm.

3.4. The Cache Parser 33

Figure 3.6: Handled request per sec varying the input size




As already mentioned in the Introduction, the goal is to cache a set of informa-tion, related to XML Document syntactic trees, for fast parsing similar documentsreceived by a given WS through distinct SOAP messages. In particular, we proposethe adoption of a checksum to be associated with each XML document. This check-sum must be sent by the Sender of each SOAP message, and is used by the Receiverto detect whether a received document is ”well formatted”, and whether it sharesthe syntactic tree with an already parsed one. In addition, the Sender includesalso a set of pointer to quickly retrieve information between XML tags. In otherwords we introduce cooperation between Sender and Receiver. Since in a WS-basedmiddleware, XML data are encapsulated in XML/SOAP messages, the Sender caninclude this checksum and the other information in the header of the message, inorder to allow the receiver to distinguish fast between XML messages with differ-ent structures. Since in a WS-invocation 2 SOAP messages are exchanged (SOAPRequest and SOAP Reply) between the service requestor and service provider thisapproach can be used on client and server side in order to reduce the deserializationprocess time.

Like DOM [27], also our Cache-Parser exploits the syntactic tree of an XMLdocument. However, in case another document with the parsing tree has alreadybeen encountered, we do not need to build a new syntactic tree from scratch, be-cause we can just navigate an already built one to know where to take the relevantinformation in the new document. In other words, we just need a visit of a tree


structure of the document, instead of a tree construction. The two parts that aresaved during this process are: the object instantiation and document scan processsince a syntactic tree was already created parsing previous received document andthe cached information gives the possibility to skip parse of the tree structure ofthe received XML. Unlike Deltarser [65], in the server-side cache we memorize allinformation about this tree, plus a set of pointers that allow us to have a ”quickjump” to the information needed, without parsing the tag.

In the next paragraphs we will see in detail the 3 main part of the algorithm:

• The hashing of a received Document;

• The algorithm core that uses the cached information;

• The cache insertion/replacement strategy.

3.4.1 Hashing a Document

This subroutine in the receiver side must accomplish the following two tasks:

• To recognize if the new document syntactic tree is already known;

• To find the right entry in the cache data structure.

Achieving the second task is simple, if we can ”well recognize” a document treestructure. All what we need is just an associative memory, where to store informa-tion using as a key a checksum computed over the syntactic tree of documents.

Whereas, to accomplish the first task, the Sender of an XML document has tocreate the associated checksum, which is a hash key obtained from a syntactic treerepresentation of the XML document. This representation simply is a parenthesizedstring, summarizing the nesting of XML elements/attributes and the associatedtags. Note that, since we are interested in characterizing the specific syntactictree of a document, the representation used to compute the checksum does notinclude the information contained between tags. The Sender stores the computedchecksum value in the SOAP Header, and sends it to the Receiver along with theXML document.

3.4.2 Cache Algorithm

As mention in section 3.2 our caching technique has been exploited using the sameAPI of a Pull parser, even if we can adapt it in any possible parser scenarios. Usingsuch parsers, the user asks for the information referring to a given tag, and provides ahandler to elaborate the information between the tags. The main difference betweenour cache-based algorithm and a standard Pull parser is that the Receiver can takeadvantage of the XML-Document tree structure knowledge, by quickly retrievingthe information that must be passed on to the specific handler.


Figure 3.9: XML parsed document with pointer to the nodes

If we receive a NewXMLdocument, and using the associated checksum we havea cache hit, we can assume that:

• NewXMLdocument shares a previous analyzed document syntactic tree;

• There exists a cache entry that stores ”all the interesting information” aboutthe syntactic tree of the NewXMLdocument ;

Since we adopt the Pull parser approach, the handler (user API) notifies thatit wants to know the information associated with a particular tag (e.g.., ¡login¿ seeFigure 3.9). The Cache Parser algorithm ”core” thus exploits the data structurestored in the cache entry to know where the information is memorized in the XMLdocument. The positions where the needed information can be found in the XMLdocument is thus returned. Finally we can obtain such information to be returnedto the handler by just copying a string. By using this algorithm, if the syntactic treeof NewXMLdocument is already known, we achieve a ”well and fast” informationretrieval of relevant information from the XML document itself. Figure 3.9 gives anidea of what we need to memorize inside a cache entry.

It is well known that typical XML documents are more complex than the onewe took as an example. In particular:

• Information contained between Tags normally does not have the same length.

• Tags have also attributes, and the length of their values may not be the same.

• Documents that share the same syntactic tree can have different tag startposition.


• An XML document may use namespaces [75] to avoid collision among tagnames or attribute names, so an XML parser must handle namespaces fordocuments that use them.

Therefore, in order to quickly retrieve relevant information from a document, inthe general case, as we decide to handle, a Receiver needs to know the tag valuestart and end position. Our idea is that the Sender adds this information in a taggedelement that we call ”Map”. We have to point out that this new element can bepart of the SOAP Header, so as not modify the original document.

Adding the ”Map”, we can know when the information associated with a Tagstarts and finishes, just interpreting this attribute, without parsing the entire Taginformation.

Note that the Map information refers to the associated (tree structured) Tagsof the document. So it must be parsed to extract the right start/end positions of agiven XML element.

In common use, typical data structure appearing in SOAP messages exchangedbetween Sender and Receiver are vectors. In out test case we noted situations wherethe numbers of vector elements are different, even if the structure of the message isthe same. This raises serious problems to our cache parser, since the syntactic treesof two XML documents appear to be different when each vector element is storedas a distinct XML element. Our cache parse treats the two documents completelydifferent, thus storing their parsing information in different cache entries. In orderto reduce the memory usage and increase the cache hit rate without slowing downthe algorithm, we can take into account how many sequential repetitions of the sameTag are present in the received XML-document. With this additional information,that it is stored in the SOAP header, two XML documents that only differ for avector size, can be memorized in only one cache entry, just changing the way inwhich the document checksum is computed.

3.4.3 Cache Insertion/Replacement Strategy

As regards to the cache insertion and replacement policy, which in our case is asimple Least Recently Used (LRU), we have to note that:

• Adding a new cache entry costs time and this could be a good investment onlyif the document is frequently exchanged between sender and receiver.

• Each cache entry has not a fixed memory size, and in this case the exchangedXML-Documents are big, this could rapidly increase the cache size.

Since in our use case the number of different XML messages exchanged is small,a little quantity of memory suffices to store all the information associated with allthe different messages received, and the specific replacement policy chosen becomesless important.


Table 3.1: Parser Comparison

3.5 Lower Bound of a Parser Algorithm and Parser

Benchmark

For better understanding the parsers behavior, and to know ”how good” the cacheparser is, we tried to estimate the intrinsic limit of an XML un-marshaling processelaboration phase. For computing this upper bound, we suppose that the parseralready knows whether a document is well formatted (so it does not need a validationphase) and where the requested information is exactly stored in the document.Under such hypothesis, a parser process is just a string transfer from the XML-document to a memory location. As we will see in the following, this limit is verydistant from the actuall parsers performance, but using our Cache Parser we canbring it close to this limit.

We performed two different tests to compare different parsing algorithms andthe new Cache Parser. First we tested the fastest Java parsers available by parsingfor 100,000 times a set of XML documents, and we compared them with our CacheParser. We performed these tests in both UNIX (Dual Xeon 1.8 GHz, with 2 GBRAM) and Windows Systems (P3 1GHz with 1GB RAM). We noted that the testoutcomes are OS independent. Below we report only the values for a Unix System.The absolute time obviously depends on the hardware equipment of the server, butthe relative time with respect to the Pull Parser time (see Column 3 in Table 3.1)is a value that is independent of the specific hardware.

To complete the tests, we evaluated the Cache Parser in a typical client-serverscenario, where clients (PIII 600 MHz, with 256 MB RAM, Ethernet 1 Gbps) sendan XML document to a servlet container (that is the base for any WS and GridServices).The server (Dual Xeon 1.8 GHz, with 2 GB RAM) receives the document,parses it and sends back to the clients a ”done” message. The test results are showin the Table 3.2.

As we can see, if we use the Cache Parser, we can really improve the receiverpart of a generic sender/receiver system. We have to point out that the CacheParser requests more operations on the sender side, like the additional tags and thehash key preparation. In the Table 3.3 we quantify this overhead, by measuringthis additional cost of the serialization process. In a Dual Xeon 1.8 GHz, with 2GB RAM we performed this measure by sending for 100,000 times a set of small

3.6. Conclusion 39

Table 3.2: Parser Comparison

Table 3.3: Document Preparation Additional Cost

XML documents (from 10 to 15 tags), first using the standard WS serialization, andthen adding in the SOAP header the additional information that the Cache Parserneeds. As we can see, since the sender can prepare the additional information whenis building the XML document to send, this does not impact on the informationXML serialization.

3.6 Conclusion

The Web Services fully solve the ”global enterprise integration” problem, but theproposed solution seems to exhibit a poor performance, and we believe that thiscould raise serious limitations to their actual applicability, as the number of com-mercial users will increase.

As shown in Section 3.3, we also believe that one of the limitations in using afull WS approach for implementing complex and highly interactive systems comesfrom the large de-marshalling costs incurred on the receiver sides. To solve thisproblem, we have designed a new parser: the Cache Parser. It is able to ”welland quickly” retrieve information from XML documents, using previous knowledgeabout the document syntactic tree. In particular, our Cache Parser, which is usedto de-marshal XML, messages on the Receiver side:

• Uses a checksum to detect if a new document is ”well formatted”, and to knowwhether it shares the syntactic tree with an already parsed one.

• Takes advantage of this XML-Document syntactic tree stored in a cache.

• It is based on a strict collaboration between sender and receiver.

• Consistently reduces the receiver parse time, without increasing the senderdocument creation time.


This algorithm is 25 times faster than a pull parser and, if used in a WS scenario,can dramatically increase the number of requests per second handled by a server(up to 150% of improvement) bringing it close to a system that does not use xmlat all. Finally, our parser can be applied in any scenario where the client and theserver decide to cooperate.

4On Enabling the Web/Grid Service

Quality of Service

This Chapter addresses the Quality of Service (QoS) issues in a Web/Grid Servicescenario enabling a remote service invocation with a given QoS in the IE context,even if our results can also be applied in a general scenario. As presented in Section1.1 and 2.2, the control of instruments demands deep interaction between users anddevices. Consider that when the access is performed via internet using Web Servicescalls, the remote invocation time becomes critical in order to understand if a servicecan be controlled properly or the delays introduced by the wire are unacceptable.Noting that no real time Web Service engine has been so far produced, a ServiceRequesters can not negotiate a particular QoS but still can try to estimate theexecution time of a remote method invocation building an estimation on top ofunreliable system.

This chapter is organized as follow:

Section 4.1 introduces the QoS in a distribute environment identifying the remoteexecution time estimation as the main QoS issue in a WS environment. It alsopresents the status of art and analyzes the critical parameters that influence theQoS. Finally, it proposes a dataset that enable QoS studies.

Section 4.2 describes a subset of the collected raw data.

Section 4.3 describes a methodology based on 2k factorial analysis and on a Gaus-sian approximation of the collected data, that enables the estimation of a remotemethod execution time.

Section 4.4 validates the proposed methodology in concrete scenarios.

Section 4.5 proposes two variant of an algorithm that automatize the developedmethodology.

Section 4.6 suggests three different software architectures, where the developedalgorithms and methodology could be integrated in order to automatically profilethe end to end service.

Finally in section 4.7 we draw some conclusions while in Appendix D we describehow the used dataset has been created and we verify the data consistence.

The main contributions of this chapter include (1) the creation of a uniformand coherent dataset that enable QoS studies. (2) A methodology that allows the

42 4. On Enabling the Web/Grid Service Quality of Service

clients to estimate a remote method execution time. (3) Experimental results comingout from concrete environments that validate the proposed algorithms to estimatethe deadlines of a method invocation. Finally, (4) the proposal of three differentQoS enabled architecture solutions, which adopt the proposed methodology andalgorithms.


The Quality of service (QoS) is a combination of several qualities or properties of aservice [54]:

• Availability is the percentage of time that a service is operating.

• Security properties include the existence and type of authentication mech-anisms the service offers, confidentiality and data integrity of messages ex-changed, non repudiation of request or messages, and resilience to denial-ofservice attacks.

• Response Time is the time a service takes to respond to various types ofrequests. Response time is a function of load intensity, which can be measuredin terms of arrival rates (such as requests per second) or number of concurrentrequests. QoS takes into account not only the average response time, but alsothe percentile (95th percentile, for example) of the response time.

• Throughput is the rate at which a service can process requests. QoS mea-sures can include the maximum throughput or a function that describes howthroughput varies with load intensity.

• Application Dependent Parameters are values that belong to the partic-ulars service semantic such as the money cost, recall in a Google query and soon.

Considering a set of service request (Transaction) additional properties mustbe considered. A Service Transaction is an inseparable list of operations which mustbe executed either in its entirety or not at all. In database terminology, it is asequence of actions that must be executed as a unit. For example, when a Website sells a travel package to a customer, the site must confirm all components ofthe package (flights, hotels, and car rental reservations). It is common to requiredistributed transactions to have the ACID property in the presence of any type ofsite or network failures:

• Atomicity: A transaction is an atomic unit of processing; it is either per-formed in its entirety or not at all

4.1. Problem Formalization 43

• Consistency: A correct execution of the transaction must take the systemfrom one consistent state to another

• Isolation: A transaction should not make its updates visible to other trans-actions until it is committed. That is, it should run as if no other transactionis running.

• Durability: Once a transaction commits, the committed changes must neverbe lost in the event of any failure

As final remark we need to observe that the QoS properties are observed byusers. These users are not only humans, but also programs that send requests forservices to service providers. As better showed in 4.1.2, the most crucial propertiesin remote procedure calls is the Response Time, in particular the remote methodexecution time. The estimation of this factor, unlike many of the previously men-tioned, is not trivial and quite more important in real time, near real time andinteractive distributes applications like the IE (see Section 1.1 and 2.2). Thereforein this chapter we will focus our attention on the execution time estimation of aremote method.

This problem is quite new and some preliminary results were presented in [24],[61], [12], [46], [72], [71], [33], [64], [7] as we will point out in the next section (4.1.1).

4.1.1 Related Work

In [61] Ran proposes a new Web services discovery model based on UDDI, in whichthe functional and non-functional requirements (e.g. quality of services) are takeninto account for the service discovery. In [46] the authors propose a fault toler-ance solution and in [7] a performance prediction for distributed systems basedon Web service technology by extending the UDDI. In [12] the authors addressservice selection coupled with a QoS ontology proposing architecture based on anagent framework. In [72] authors present a QoS-assured composed service deliveryframework, called QUEST, and design efficient approximate optimal algorithms tocompose service paths under multiple QoS constraints. In [71] Chia et al propose aservice composition architecture that optimizes the aggregate bandwidth utilizationwithin a operator’s network, while in [33] Cardoso et al, present a predictive QoSmodel that makes it possible to compute the QoS for workflows based on atomictask. Finally in [64] the authors study the Web Service end-to-end QoS proposing acentralized broker that is responsible for coordinating individual service componentsto meet the quality constraint for the client.

We need to note that researches are focusing their attentions on techniquesand/or architectures that assume the response times as well known and they leavethe parameter estimation to future investigation. In addition, some works assumeinstantaneous and costless the propagation of the QoS information between thesystems peers [72], [61], [33], [64].


Figure 4.1: Critical Intervals in a Web Service invocation

4.1.2 Critical Times in a Remote Procedure Call

The majority of the web service requests are performed across a LAN or internet.So the network channels have an important role during a remote procedure call andit can deeply influence the Responce Time parameters. Several projects [106], [85],[114], [113], are trying to estimate the end to end network QoS between two remotelydevices. Unfortunately, as we demonstrated in Section 3.3, it is not only the wirethat influences the performance of a WS invocation, but also the serialization anddeserialization process on both the server and client side [44], [9]. By the way Weneed a good estimation of the network quality is an important piece of the puzzle ifwe are invoking a service using a channel with limited bandwidth or high latency. Inaddition, we need to point out that the remote method algorithms have a importantrole too. From a generic point of view a remote method invocation can be split into7 crucial parts [25], as explained in figure 4.1:

During the interval t1 − t0 the client serializes the invocation input in SOAPformat and sends it during the interval t2−t1. The remote peer receives the serializedmessage at time t2 and starts the deserialization process that finishes at time t3.During the interval t4−t3 the remote method is executed and the output is produced.As its last operation, the remote services serialize the output in SOAP format duringthe interval t5− t4 and starts sending it. The invoker receives the serialized messageat time t6 and during the interval t7− t6 starts deserializing the output message inthe proper data structure.

According to this time division, from the client QoS point of view, we can identify3 critical times intervals, that are:


• t7− t0 Remote Method Execution Time (tex)

• t4− t0 Remote Method Processing Time (tpt)

• t3− t0 Remote Method Invocation Time (One Way) (tow)

The t7− t0 interval represents the total execution time of a remote invocation.In other words, in a synchronous method invocation, the time that the invoker waitsbefore starting to process the output of the remote invocation.

The t3− t0 represents the remote procedure execution delay that is introducedby the serialization-deserialization process. This is particular important in One Way[14] invocation method.

Finally t4−t0 is the time needed to finish the remote elaboration process. In No-tification base systems [14], it represents the minimum time before the first receptionof a notification.

Noting that no real time Web Service engine has been so far produced, a ServiceRequestors cannot negotiate a particular service, but still can try to estimate theexecution time of a remote method invocation. In order to give an intuitive idea ofthe problems difficulty, we can note that all critical intervals (t3 − t0, t4 − t0, andt7− t0) depend on both server and client parameters. In addition, due to the clocksynchronization problems [94], some intervals (t3− t0, t4− t0) can not be estimatewithout allowing cooperation between these 2 peers.

An additional remark is related to t4 − t3: this interval represents the remotealgorithm execution time and the method programmer must provide a proper char-acterization in term of complexity and execution time [5].

4.1.3 Factors that Influence a Remote Method Invocation

Generally speaking the method execution time depends on several factors. Firstof all, the algorithm complexity, particular input parameters that could modify itsbehavior and the hardware/software of the machine where both the service and theinvoker are running. In addition, other important factors are the machines load, thesoftware layers used, network bandwidth and delay.

Finally, other method parameters like the data, input and output, size and type,could have a crucial impact on the effective execution time of a method. The table4.1 summarizes the mentioned factors.

Parameters like A, B, C and D can be considered static, since they dependon hardware and software change. Parameters G and H depend on the particularmethod semantic and a characterization must be provided by the user of a WS-framework. Factors like I, L, M and N can be considered well known before startingthe method execution even if, from a general point of view, M could be known onlybefore the time t4. Finally parameters like E, F, O and P can be considered fullydynamic and, in general, out of the program control.


Table 4.1: factors that influence a remote method call

4.1.4 Implementation of a Homogeneous and Consistent DataRepository for Web Services QoS Case of Study

The main motivation of this preliminary work it that QoS over a Web service systemis a relatively new topic. Some results were presented in [72] and [64], but theproblem has never been approached in a homogeneous way. As result, it is impossibleto evaluate the effective performance of different techniques. We believe that, inanalogy with the Data Mining discipline, the creation of Data Set Repositoriescan allow researchers to run comparison tests between different QoS methodologiesdeveloped by the research community.

In the following, the profiling information stored in this first proposed data set.

4.1.5 Profiling WS Invocation to Build a Dataset

A generic data set that must be used in conjunction with different techniques shouldcontain all the possible information that different methodologies can use in order toestimate the execution of remote invocations. Considering a single remote methodinvocation as a single test sample and, according to the model described in theprevious Section (see 4.1.2), we decided to store all possible WS crucial intervals:

• t1-t0 Client Serialization

• t2-t1 Client Network Transmission

• t3-t2 Server Deserialization

• t4-t3 Effective Remote Method


• t5-t4 Server Serialization

• t6-t5 Server Network Transmission

• t7-t6 Client Deserialization

In addition, it will be useful to compute the mentioned QoS crucial intervals inan independent way:

• t7-t0 Remote Method Execution Time (tex)

• t4-t0 Remote Method Processing Time (tpt)

• t3-t0 Remote Method Invocation Time (tow)

4.1.6 Data Sets Assessments

The factors that influence a remote method invocation time were described in Sec-tion 4.1.3. Therefore each single factor must be considered choosing the candidateprofiling information to be included in the data sets.

Parameters that depend on the hardware and software layers (A, B, C, D) (see4.1) can be considered fixed, but the test software code must be portable in order toallow repeating the tests in different configurations. Parameters like G and H (see4.1) belong to the semantic of the method and a characterization of these factorscannot be performed without knowing the method meaning. Therefore we decidedto leave these parameters out of the first test sets.

I, L, M, N factors (see 4.1) must be included in the data set because the ex-changed message sizes have a big impact on the system performance, consequentlyin the method execution time, as demonstrate in several benchmarks [44], [9], andin Chapter 3.3.

Dynamic and unpredictable parameters like E, F, O, and P (see 4.1) must behandled in two different ways. First of all in a concurrent scenario, where differentclients try to access to the same service and where concurrent processes are runningin a random way in both the client and the server machine. Secondly in a scenario,where all the dynamic parameters are under control.

To summarize we produced two different datasets can divide the test sets in 2different categories:

• Training Dataset

• Validation Dataset

In the first one all the test factors are under the control of the test and will beused to train/extract a model used for predicting execution times of remote methods.


In the second set, dynamic parameters are left out of the test control and it will beused as dataset to prove the developed techniques.

We can conclude this section noting that, due to the number of software layersand the lack of real time operative systems, even if we are able to fix all the factorsmentioned, we will still experience a fluctuation on the estimated time interval. Soevery single test must be repeated a sufficient number of times to build the dataset.

4.1.7 Data Set Candidates Description

As with the previous section 4.1.7 we build two distinct datasets: ’Training’ and’Validation’. The variables that we consider in the training test are:

• Input Type= [none, String, double, String and Double]

• Output Type= [none, String, double, String and Double]

• Input Size (number of elements) = [0, 100, 1000, 10000]

• Output Size (number of elements) = [0, 100, 1000, 10000]

• CPU usage Server= [0%, 70%,80%]

• CPU usage Client= [0%, 70%,80%]

The first four above parameters characterize a generic method input and output,while the last two correspond to percentage of CPU usage by processes that are notserving the remote invocation.

In all tests conducted to produce both dataset, client and server were running ona Dual Xeon 2.40GHz, 1.5GB RAM machines running the CERN Scientific Linux3.0.4 Operating System, with Kernel 2.4.21-27.0.2.EL.cernsmp and Java 1.4.2-08-b03. The machines were interconnected to each other by a 100 MB switched Ethernet. Finally on top of this hardware and software layers we installed Tomcat 5.0.28 andAxis 1.4 as Web Service provider.

For every single test (i.e for each combination of parameters), 1000 samples(i.e, remote single method invocation) were taken and a full test set consists ofall possible combinations of the above mentioned parameters. In other words thedataset consists of 2304000 samples (of 9 significant values each) organized in 2304different tests.

Still some variables are not covered from the training dataset and are:

• Long, float, integer in the input of a method

• Long, float, integer in the output of a method

• String size, different from 10 characters, in both input and output size


In addition, the network connection, the hardware and the software were alwaysconsidered fixed:

• Concurrent Bandwidth Network occupancy different from 0%

• Network latency more than 1 ms.

• Hardware and Software on the Server side

• Hardware and Software on the Client side

• Remote method execution time

The above mentioned variables will be included in future improvement. We willshow that the analysis of this preliminary set of samples can be sufficient for thedeveloping of a prediction methodology that can allow service invoker to predict theexecution time of the remote method.

We also believe that an analysis of the Web Service performance varying thenetwork load channel is the most important missing thing in this dataset. But, aspointed out in section 4.1.2, different projects [106], [85], [114], [113] are currentlystudying this problem and are trying to provide a service oriented system for esti-mating the effective performance of a link connection across internet. So, consideringthat a web service call consists of exchanging 1 or 2 messages with a given size, theresult coming out from these projects could help in the network delay estimation.

As ’Validation Dataset’ we consider a scenario where a heterogeneous set ofclients is performing a web service invocation with random input and output sizeand types:

• Input Type= random between [none, String, double, String and Double]

• Output Type= random between [none, String, double, String and Double]

• Input Size, = random between [0, 10000]

• Output Size, = random between [0, 10000]

• Number of connected clients [1, 2, 3, 4, 6, 10]

• Constant Remote method execution time

Clients continuously and randomly choose the input and the output of the remotemethod and then request the service. The CPUs of all the nodes are totally dedicatedto the tests and we were collect and memorize 5000 samples for each single test.

We believe that this second independent set of tests can help the validationof developed estimation techniques with the Training Dataset without the need ofusing part of the same dataset for the validation/test phase.


We also need to point out that the Training Dataset can be see as part of theValidation Dataset. In other words, if we consider the scenario where just one clientis invoking the remote service we will obtain a situation quite similar to the TrainingDataset.

4.2 Some Features of the Collected Data Set

This section presents the experimental results obtained. As mentioned in Section4.1.7 the data set consists in 2304000 samples (of 9 significant values each) organizedin 2304 different tests. We believe that providing 20736 plots relative to the samplesdistribution of each significant value of the entire data set, is mining less. We thusprefer to show and discuss a subset of the collected raw data, in order to let thereader understand which are the effective potential of the produced dataset. Forthe same reason, in this chapter we will present and comment just the raw datadistribution, without any additional analysis that could be performed on top. NextSection ( 4.3 ) will present an analysis of these data. It is worth pointing that, asexplained in Appendix D, these data have been collected using a Tomcat+Axis asWS provider. Therefore, this section is related to a particular WS implementation.By the way, the methodology developed in Section 4.3 can be used within everyWS-engine implementation.

4.2.1 WS Invocation Time with Large Input and OutputSize

In this first set of plots we consider a remote method invocation with 10000 String(of 10 characters) and Doubles in input and output. Figures 4.2, 4.3, 4.4 and 4.5show the samples distributions of the total invocation time (tex = t7− t0) when theCPU occupancy on both client and server side was varying between 0% and 80%.The remote method algorithm is empty; in other words the server immediately startthe serialization of a pre-generated output, once the deserialization of the input isaccomplished.

As intuition suggests, we can note that both the mentioned factors (CPU Clientand Server side) influence the raw data distributions: the average and standarddeviation increase along with the CPU occupancy. We can also note that the CPUoccupancy Client side is more important than the CPU occupancy on the Serverside. Finally the remote method execution time increases remarkably when boththe machines are busy.

4.2.2 Server De-Serialization Time for Different Input Size

In this example we consider only the server de-serialization (t3−t2) time, varying themethod input. In this particular set of plots the server machine was totally dedicated

4.2. Some Features of the Collected Data Set 51

Figure 4.2: Sample distribution S-CPU 0% C-CPU 0%



Figure 4.6: Sample distribution of the Server Deserialization Time (empty method)

to remote method handling, except for the plot 4.8 where we replicate the experimentshown in fig:9ServerDeserializationTime100Input with a server occupancy fixed tothe 80%.

As expected the deserialization server side of the SOAP message has a large im-pact on the remote method execution time. The time needed for the deserializationprocess increases with the input size. For inputs of a small size we can also notea consistent number of coherent anomalies typical of cache miss phenomena or tothe process rescheduling in a different CPU. We can also note that for input mes-sages of large size these phenomena disappear. Finally, as proved by comparing theplots of Figure 4.7 and 4.8, the CPU occupancy server side has a key role in thedeserialization process.

4.2.3 One Way WS Invocation with Different Input Size

This set of plots shows a set of one way invocation, keeping empty the CPU oc-cupancy of the Client and Server sides, varying the number of strings in input. Inaddition plot 4.13 repeats the condition of the test 4.12 with 80% CPU usage serverand client side. Finally, Figure 4.16 considers a one way invocation with 10000strings in input and output.

As expected the number of string in input deeply influence the one way executiontime of a remote method. Like the serialization plots presented in 4.2.2 also theseplots present a phenomenon typical of cache miss or process rescheduling in differentCPU. By comparing Figure 4.12 and 4.13, we can also note that the CPU usageserver and client sides influences the one way service time. Finally, comparingFigure 4.15 and 4.16, the output size does not influence the method execution time


Figure 4.7: Sample distribution of the Server Deserialization Time (Input 100 Dou-ble)

Figure 4.8: Sample distribution of the Server Deserialization Time (Input 100 Dou-ble) whit server CPU occupancy of 80%


Figure 4.9: Sample distribution of the Server Deserialization Time (Input 1000Double)

Figure 4.10: Sample distribution of the Server Deserialization Time (Input 10000Double )


Figure 4.11: Sample distribution of a one way invocation of an empty method

Figure 4.12: Sample distribution of a one way invocation (Input 100 String)


Figure 4.13: Sample distribution of a one way invocation (Input 100 String) whitserver CPU occupancy of 80%




Figure 4.16: Sample distribution of a one way invocation (Input and output 10000String)

4.3. Deadline Estimation Methodology 59

while, in a less approximated analysis this sentence is not correct.

4.2.4 Final Remarks on the Data Set

The main contributions of this first part of the chapter include: (1) an analysis ofthe key factors that influence the QoS in a WS scenario. (2) Secondly the outlineof the status of art and the on going activity in this research area and thirdly theidentification of the method execution time prediction as one of the most criticaland difficult part of the WS QoS.

(3) Finally, in order to try to estimate the service execution time, we analyzethe WS behavior in different scenarios , thus producing a database that contains2304000 samples (of 9 significant values each) organized in 2304 different tests. Inaddition (4) the raw data of a really small subset of tests has been presented anddiscussed.

What follows is a deadline estimation methodology that allow to predict a remoteexecution time.

4.3 Deadline Estimation Methodology

In this section we propose a method that predicts the execution time of a remoteservice invocation. From a mathematical point of view, a remote method invocationrepresents a time interval during witch the method will be executed with a givenpercentile (95th percentile, for example). In other words if

h(x) (4.1)

represent the probability distribution of the statistic variable x that describesthe service invocation execution time,

Y = P (x < X) =∫ X

0h(x)dx (4.2)

represents the minimum time interval [0, Y ] that can ensure the execution timewith a given probability X. Considering that we are trying to estimate a possibledead line an upper bound estimation Y is still an acceptable value while a lowerbound cannot be considered. In other words, we can accept to try to predict a 95thpercentile, when de facto the real number of deadline miss is 99th percentile. Wecannot accept the opposite behavior.

An additional remark is that the probability function must take into account allthe factors that are represented in table 4.1 of section 4.1.3 like client and serverload, the input and output type and size etc.

Finally we need to point out that the exact probability distribution h(x) dependson many factors and it is quite difficult to estimate, so we could try to give an upperbound like the following:


Y = P (x < X) ≤ P (k < X) (4.3)

Where the probability distribution of k is described by a Gaussian ( N(µ, σ) )distribution larger (see Section 4.3.2) than the x distribution with a given average(Avg or µ) and standard deviation (sDev or σ)

N(µ, σ) µ = f(x) σ = g(x) (4.4)

We can note that µ and σ are deterministic function of the key factors ( markedas x) presented in Section 4.1.3. If we succeed in the estimation of the average andthe standard deviation of the presented Gaussian we will be able to provide an upperbound of the remote method execution time, noting that:

Y = P (x < X) ≤ qX = g(x)ΦX + f(x) (4.5)

Where ΦX represent the percentile of order X of a Gaussian distribution withAvg=0 and sDev=1. Considering that both f(x) and g(x) must be determinate inan empiric way we can not ignore the experimental error due to this estimation, inparticular.

µ = fe(x)± εµ (4.6)

σ = ge(x)± εσ (4.7)

Again, considering that we want to estimate an upper bound of a time, onlypositive errors must be considered. In addition, the errors εµ , εσ must follow aconservative approach because we want predict worst case functions, as explainedat the beginning of this section.

In conclusion the final dead line estimation will be:

Y = ge(x)ΦX + εσΦX + fe(x) + εµ (4.8)

If the influence of some factors cannot be considered under the client control, weneed to substitute the worst case scenario into the just above equation.

As final remark we need to consider factors like the algorithm of the method(G) and the Key input that change the algorithm behavior (H). They must beprovided by the programmer of the remote method because, as discussed in Section4.1, WS do not take into account the semantic of the remote methods. Assumingthat the remote algorithm execution time is Ra(x) and that it will be provided byprogrammers, the final estimation of the critical intervals (see section 4.1.2) will be:

t7− t0 = tex = gex(x)ΦX + εσexΦX + fe(x) + εµex + Ra(x) (4.9)


t3− t0 = tow = gow(x)ΦX + εσowΦX + fe(x) + εµ0w (4.10)

t4− t0 = tpt = tow + t4− t3 = gow(x)ΦX + εσowΦX + fe(x) + εµ0w + Ra(x) (4.11)

Of course, if Ra(x) will be known with a given error, it will need to be takeninto account too. The following Section will present and discuss a methodology forthe estimation of the functions according to the experimental data of the dataset.

4.3.1 Empiric Function Estimation

We would like to consider two different approaches to the functions estimation prob-lem. First (1) we could directly estimate the needed functions from the QoS timefactor t7− t0, t4− t0 and t3− t0; as second possibility (2) we could derive the samefunctions from each single interval presented in Section 4.1.2 of a web service invo-cation. In other words considering an empty remote method invocation we couldhave:

µ = f(x) = fe(x)± εµ

= fcs(x) + fcn(x) + fsd(x) + fss(x) + fsn(x) + fdc(x)

±εµcs ± εµcn ± εµsd+±εµss +±εµsn +±εµdc

(4.12)

σ = g(x) = ge(x)± εσ

= gcs(x) + gcn(x) + gsd(x) + gss(x) + gsn(x) + gdc(x)

±εσcs ± εσcn ± εσsd+±εσss +±εσsn +±εσdc

(4.13)

Table 4.2 describe the functions meaning.For one way message types (tpt = t4− t0 and tow = t3− t0):

fss(x) = fsn(x) = fdc(x) = gss(x) = gsn(x) = gdc(x) = 0 (4.14)

Because the output transmission do not influence the execution time.Considering that we are estimate deadline the experienced error must follow a con-servative approach.

This second presented approach can allow an interval composition simplifyingthe clock synchronization problems for one way messages type and the possibilitiesto perform independent measures for the clients, servers and networks channels. In


Table 4.2: Functions break down description descriptions

other words, following this approach the estimation of the execution time can becomputed as a linear composition of factors.

We need to remark that we will consider an upper bound of each real functionso the deadline computed in this second way will probably be larger.

4.3.2 2k Factorial Analysis Design on the Dataset

In this section we will design a factorial analysis [55] around the experimental data inorder to derive a linear regression model that gives an approximation of the functiong(x) and f(x) as discuss in the previous Section 4.3.1.

According to the dataset description presented in Section 4.1.7 and 4.1.5, weconsider the following factors:

• A= Number of String in Input of the method [0....10000]

• B= Number of String in Output of the method [0....10000]

• C= Number of Double in Input of the method [0....10000]

• D= Number of Double in Output of the method [0....10000]

• E= CPU Usage Server Side [0....80%]


Table 4.3: Full factorial analysis first part

• F= CPU Usage Client Side [0....80%]

that generates the full 26 factor design composed of 64 tests presented in Tables 4.3and 4.4:

The functions that we would like to estimate are:

• Average Method Invocation

• Standard deviation Method Invocation

• Average One Way Invocation

• Standard deviation One Way Invocation

• Average Computation Remote Site Executed

• Standard deviation Computation Remote Site Executed


Table 4.4: Full factorial analysis second part


Table 4.5: Descriptions of the linear regression coefficients

• all the functions presented in Table 4.2

Consider that the Training Dataset was build considering that all the remotemethod executions were empty. So there are no difference between the intervalst4 − t0 and t3 − t0. In addition the network transmission ( about 1ms ) can beconsidered negligible, compared to others web service invocation process ( about100ms ), like the serialization and the deserialization.

Finally, once the key inplicant will be determinated we would like to understandif the functions to estimate (ys = f(x)) for both µ and σ can fit in the followingregression model:

ys = β0 + β1xA + β2xB + β3xC + β4xD + β5xE + β6xAxB + β7xBxE + β8xCxE

+β9xDxE + β10xF + β11xAxF + β12xBxF + β13xCxF + β14xDxF ± ε

(4.15)

where βi are the constant coefficients to be derived and xi represent a generic valuebetween [−1, +1], where -1 represent the lowest value of the considered intervalfactor and +1 the greatest.

This particular regression model is very useful because the coefficient have theintuitive meaning resumed in Table 4.5.

We now describe the factorial analysis and the regression model fitting based onthe estimated key factors with the contrast analysis [55]. After that a regression


model with the above mentioned function was computed and, if the two functionsshow the same residuals, just this last one, which is more compressible, is presented[55]. We will show the complete analysis just for the Total Execution time (section4.3.4) wile for all other factors we will present only the results leaving intermediatecomputation.

4.3.3 Gaussian Upper Bound of a Sample Distribution

For each of the 64 tests samples, average and standard deviation was computedusing the following standard estimators:

µ =1

n(x1 + x2 + · · ·+ xn) (4.16)

σ =

√√√√ 1

n− 1

n∑i=1

(xi − µ)2 (4.17)

After that we run the following hypothesis test: H0 = N(µ+ ε, σ+ξ) ”is a largerdistribution than the one experience during the test”

where ε and ξ are the minimum non negative numbers that allow the success ofthe hypothesis test. The just determinate values were used as tests values for thecontrast analysis and the regression model estimation.

4.3.4 Total Execution Time Estimation

The hypothesis test was satisfied with ε, ξ = 0 and Table 4.6 and 4.7 report the con-trast and the sums of square of each factor for both average and standard deviation.

The ”Factor” columns list al the design factors while the ”AVG Cont” representsthe experienced contrast factors for the average function. The ”SS” is the relatedSums of Squares [55]. Finally the ”Res SS” represents the most influent factors thatwill be considered in the linear regression. Similar consideration, but applied to thestandard deviation estimation, can be repeated for the last three columns [55].

The regression model with the estimate key factors and the one presented inSection 4.3.2 present the same residual analysis. So we decided to use this secondfor future analysis. As final result the regression model is represent by Table 4.8

While Figure 4.9 shows the residual analysis for the function that characterizethe Average for the Total Execution Time.

As we can see the experimental error is not negligible compared to values takenby the functions, especially for service invocation with short input and output.

4.3.5 A Special Case: Server Deserialization

For this particular formula computation the linear regression of the average sug-gested by the contrast analysis is different from the one presented in Section 4.3.2


Table 4.6: Contrast and Sum of Square analysis for the linear regression of the totalexecution time (first part)


Table 4.7: Contrast and Sum of Square analysis for the linear regression of the totalexecution time (second part)

Table 4.8: total execution time linear regression coefficients


Table 4.9: Residual analysis for the linear regression of the total execution time

therefore two possible regressions are presented (see Tables 4.10 and 4.11). Forfuture analysis we decide to keep the second formula considering that the errorintroduced by this simplification will be negligible compared with the final results.

ys = β0 + β1xA + β2xB + β12xAxB + β3xC + β13xAxC + β23xBxC + β123xAxBxC +

+β4xD + β5xE + β6xAxB + β7xBxE + β8xCxE + β135xAxCxE + β9xDxE +

+β10xF + β11xAxF + β12xBxF + β13xCxF + β14xDxF ± ε

(4.18)

ys = β0 + β1xA + β2xB + β3xC + β4xD + β5xE + β6xAxB + β7xBxE + β8xCxE +

+β9xDxE + β10xF + β11xAxF + β12xBxF + β13xCxF + β14xDxF ± ε

(4.19)

4.3.6 Different f(x) Estimations

The Table 4.12 shows the different functions estimations related to the averagefunction discussed in section 4.3.1. The last 2 columns of Table 4.12 describe theaverage of the total execution time ( t7− t0) and the one way times (t4− t0, t3− t0)by computing the influence of each interval. As anticipate the error is greater thanthe one experienced using a direct computation.


Table 4.10: Linear regression coefficient with the key factors analysis

Table 4.11: Linear regression coefficient with the standard linear regression model

4.4. On Validating the Methodology 71

Table 4.12: coefficients for the linear regression estimation of different f(x)

4.3.7 Different g(x) Estimations

The Table 4.17 shows the different functions estimations, related to the standard de-viation function, as discussed in Section 4.3.1. We can repeat the same observationsof the previous Section 4.3.6

4.3.8 Deadline Function Estimation

The combinations of the linear regressions presented in the previous two sectionsaccording to the last formula of section 4.3, are presented in Table 4.13.

The first and the second column report the total execution time and the one waytime functions with a direct estimation and a 95 percentile, while the third and theforth report the same results estimated with the interval decomposition techniqueof Section 4.3.1.

Finally the last 4 columns report the same results of previous columns with the97.5 percentile. In the next Section (4.4) we will prove that using these functions,we are able to predict the method execution time of a WS in both a synthetic anda concurrent scenario, where the server is not overloaded.

4.4 On Validating the Methodology

In this Section we will show the prediction capability of the techniques discussed inSection 4.3.


Figure 4.17: coefficients for the linear regression estimation of different g(x)

Table 4.13: coefficients for the linear regression for the dead line estimation functions


Figure 4.18: % of deadlines misses varying the number of clients (95 percentile)

In particular we will use the deadline estimation functions showed in Section4.3.8.

We will validate the methodology using the second independent part (ValidationDataset) of the dataset presented in Section 4.1.7. Note that the use of differentsamples from the one used for build the deadline estimators. In these tests, clientscontinuously and randomly choose the input and the output of the remote methodand then request the service. In addition, in order to validate the methodology inthe worst case scenario, by looking the residual [55] of the function [55] , we willassume that the client CPU Load is always larger than 80%.

We first report the number of dead line misses as in the entire test scenario whilein Section 4.4.1 and 4.4.2 we will present the same results in a more detailed way.

According to Section 4.1.3, in a real scenario is impossible to maintain constantthe CPU usage of the server for the entire method execution time. Therefore wewere forced to assume the worst case scenario, where we consider the server usageat the maximum. By the way, we need to point out that, we could remove thisassumption in case of a reservation as described in Section 2.2.

With this assumptions, we performed 5000 remote method invocation with ran-dom input and output, in a scenario where only one client was invoking a loaded andunloaded server ( XE=1, -1). We also repeated the previous tests when a variablenumber of clients (2, 4, 6, 10) were connected to the server. Figures 4.18 and 4.19report the results.

As we can see, we correctly provide an upper bound of a remote method execu-tion time if the number of clients is three or less, i.e if the server is not overloaded.According to Section 3.3 and [44], 3 concurrent clients that try to use the remoteservice as fast as they can bring the server to the maximum request throughputthat it can handle. In other words, if we try to increase the number of remotemethod invocation, we expect a service time increase because the server is over-loaded. Consequently the number of dead line miss will increase in an unpredictable


Figure 4.19: % of deadlines misses varying the number of clients (975 percentile)

way.

Detailed explanation of these tests will be provided in Section 4.4.1 and 4.4.2.

4.4.1 Methodology Validation with One Client

With the developed methodology we are capable to tune the deadline estimationtaking into account the remote CPU usage factor. By the way, in a real scenario itis impossible to maintain the server CPU usage constant during the entire remotemethod invocation. Therefore we decided to test our predictor in the case where theserver is in the worst case scenario. In other words we consider the case where theserver CPU usage from different processes is always 80%. In addition we analyze thebehaviors of predictors in the case where the server is completely empty, in order tounderstand how much this wrong assumption impacts in this limit scenario.

We need to point out that via an agreement between the client and the server(see Section 2.2 and [48]) a client could totally reserve the remote machine in orderto be sure that the server CPU occupancy is always 0% and thus be able to build amore accurate a short dead line.

The test was computed using all 5000 samples of the Validation Dataset withone client counting the number of deadline (DL) misses. As expected, in both casesless than the 5% and 2.5% of dead line misses were experience, due to the upperbound that we was forced to consider in the dead line functions estimations.

Instead of plotting all the 5000 samples, Figures 4.20 and 4.21 represent a samplessubset that show the behaviors of the estimators, in both, one way and end to endmethod invocation, in a scenario where the client CPU load is 80% (XF =1) whilethe server is completely unloaded (XF =-1).

The ”Real” curve represent the experience invocation time while the ”total95”and ”total975” curve represents the dead line estimation using a direct computa-tion of the linear regression with a quantile of 95 and 97.5 respectively . Finally,


Figure 4.20: One Way Estimation CPU server 0% CPU Client 80%

Figure 4.21: End To End Estimation CPU server 0% CPU Client 80%


Figure 4.22: One Way Estimation CPU server 80% CPU Client 80%

”comp95” and ”comp975” curve show the deadline estimations using the intervaldecomposition technique.

Plots in Figures 4.22, 4.23 and 4.24 represent the case where the CPU usageserver side was forced to be constant at 80% (XE=1). As we can note the dead linestart to be more close to the real system behavior, but still the number DL missesare less than the expected 5% and 2.5%.

4.4.2 Methodology Validation with Multiple Clients

As second set of tests chosen to validate the methodology refers to the concurrentscenario, where more than one client uses the remote method. In this test theassumption of the server CPU at 80% (XE=1) is mandatory, considering that thenumber of service requestor is unknown by the clients.

The Plots in Figure 4.25, 4.26 and 4.27 are related to a scenario where two clientsare concurrently requesting the service.

Except for the number of clients connected to the system the meaning of thecurves is exactly the same as explained in previous Section (4.4.2). The methodologyhas been validated with all the 5000 samples of the test set but, in the Figure4.25, 4.26 and 4.27 we just reported a small subset to give an idea of the proposedestimation methodologies behaviors.

The Plots in Figures 4.28, 4.29 and 4.30 are related to a scenario where 3 clientsare concurrently requesting the service:

Again, like in all the previous tests the methodology was validated with 5000


Figure 4.25: One Way Estimation with 2 clients connected

Figure 4.26: End To End Estimation with 2 clients connected


Figure 4.27: End To End Estimation with 2 clients connected

Figure 4.28: One Way Estimation with 3 clients connected


Figure 4.29: End to End Estimation with 3 clients connected

Figure 4.30: End to End Estimation with 3 clients connected

4.5. Web Service Profile Algorithm 81

Figure 4.31: One Way Estimation with 4 clients connected (Server Overloaded)

samples but in the plots we just report a small subset. As we can see, the numberof deadline misses is increasing, due to the extra overhead of the server but it isstill less than 5% and 2.5%. According to [44] and 3.3, three concurrent clients thattry to use the remote service as fast as they can bring the server to the maximumrequest throughput that it can handle. In other words, if we try to increase thenumber of remote method invocation, we expect a service time increase because theserver is overloaded. Consequently the number of dead line miss will increase inan unpredictable way. Figures 4.31, 4.32 and 4.33 are related to a test where fourdifferent clients are trying to access to the remote server.

As expected the number of deadline misses is increased, but still it appears to beunder control due to the upper bound that we apply during the deadline functionestimation.

Plots 4.34, 4.35, 4.36, 4.37, 4.38 and 4.39 are related to two different tests where,six and ten clients are trying to request the service concurrently.

As expected, the number of dead line miss is out of control, due to the fact thatthe server is overloaded.

4.5 Web Service Profile Algorithm

The methodology developed in Section 4.3 and validate in Section 4.4 can allows usto devise an algorithm for estimation of the remote execution time:


Figure 4.32: End to End Estimation with 4 clients connected (Server Overloaded)



1. Run the characterization the tests according to the input and output regionthat you need to characterize

2. For each test find the minimum ε, ξ where

H0 = N(µ + ε, σ + ξ) (4.20)

is a Gaussian distribution with a sample distribution larger than the one ex-perienced in the tests.

3. Using the generated µ + ε and σ + ξ values of each test find the best set of forthe functions:

µ(x) = β0 + β1xA + β2xB + β3xC + β4xD + β5xE + β6xAxB +

+β7xBxE + β8xCxE + β9xDxE + β10xF + β11xAxF +

+β12xBxF + β13xCxF + β14xDxF ± ε

(4.21)

σ(x) = β0 + β1xA + β2xB + β3xC + β4xD + β5xE + β6xAxB +

+β7xBxE + β8xCxE + β9xDxE + β10xF + β11xAxF +

+β12xBxF + β13xCxF + β14xDxF ± ε

(4.22)

Those minimize the error ε by solving the equation:

β = (X′X)−1y (4.23)

4. Compute the error of the estimated functions looking to the residuals:

y = Xβ (4.24)

e = y − y (4.25)

5. (optional)sum the linear regression in the case of the interval decompositiontechnique

4.6. Possible Web Service QoS Enabled Architectures 87

6. Compute the dead line function with the requested percentile of the set ofGaussians generated by N(µ(x), σ(x)) :

t7− t0 = tex = gex(x)ΦX + εσexΦX + fe(x) + εµex + Ra(x) (4.26)

t3− t0 = tow = gow(x)ΦX + εσowΦX + fe(x) + εµ0w (4.27)

t4−t0 = tpt = tow +t4−t3 = gow(x)ΦX +εσowΦX +fe(x)+εµ0w +Ra(x) (4.28)

4.6 Possible Web Service QoS Enabled Architec-

tures

In this section we will discuss three possible high level software architectures thatwill utilize the developed methodology in order to predict the remote method execu-tion time. For each option we would like to provide an intuitive service orchestrationand the advantages and disadvantages of each solution. The main goal of this ar-chitectures is to allow the automatic profile of the services in order to be able todetermine the deadline function, thus being capable of predict a remote method ex-ecution time. Since each proposed solution presents advantages and disadvantages,we believe that the adoption of a particular architecture depends on the particularuse case.

4.6.1 Full Client Side Logic

In this approach each client will utilize the algorithm presented in Section 4.5 inorder to directly compute the dead line functions (see Figure 4.40):

For each client the Tests Executor component reserves the remote service us-ing the Reservation Engine and performs the needed tests. Then it computes thedeadline functions via the Deadline Function Computation component. The remoteservice provides also a method execution characterization via the Method executionprovider.

Note that in this solution:

• The server must provide a description of the remote methods execution time(t4− t3) for each method

• The clock synchronization is not needed during the test procedure

• During the client tests (step 1 of the algorithm), the server need to be totallydedicated to the client.


Figure 4.40: Full client Side logic Architecture description

4.6. Possible Web Service QoS Enabled Architectures 89

Figure 4.41: Server and clients factors break down Architecture description

• Considering that all the tests will be computed on client side the one waycomputation could be not trivial, due to the clock synchronization problem.Probably an upper bound estimation will be the only possibility.

• During the tests procedure the network channel properties must be maintainedconstant or under the clients control. In order to allow the creation of thedeadline functions in the proper way.

4.6.2 Server and Clients Factors Break Down

The key ideas of this approach is to break the dead line function into several piecesand let the server and the client compute each part separately. Then the dead linefunction will be computed aggregating the functions of each factor (see Figure 4.41).

In this case the servers build the characterization related to the intervals

• t3− t2 input deserialization

• t4− t3 remote method execution time

• t5− t4 output serialization


using the tests Builder component and making it public to the client throughthe Method execution provider component.

The client profile itself has to provide a characterization of only the followingintervals:

• t1− t0 input serialization

• t7− t6 output deserialization

using the test builder component. In addition, it has to compute the deadlinefunctions, retrieving the server characterization values via the Dead Line FunctionComputation component.

If a network characterization channel is required, the client can retrieve it froma third party element.


• The server must provide a description of the remote methods execution time(t4− t3) for each method

• The server profile is built just once and does not change using different clients

• The client can build its test without asking the server cooperation

• The testing procedure does not care about the network channel

• The clock synchronization is not needed during the test procedure

• The estimate dead line will be larger than to a direct estimation, due to theexperimental errors introduced in each functions.

• A modification of the source code of the WS provider in both client and serverside is mandatory since time like t1,t2,t5,t6 are internal part of the WS-Engine.

4.6.3 Third Party QoS Enabler

During the test procedure the server and the clients send the experienced times to athird party component, that build the dead line functions and send it to the client(see Figure 4.42).

For each client the Tests Builder component reserves the remote service usingthe Reservation Engine and performs the needed tests. During the tests procedureboth server and client send information related to t3− t2, t4− t3, t5− t4, t1− t0,t7− t6, intervals to the QoS Enabler component that builds the dead line functions.


• The server must provide a description of the remote methods execution time(t4-t3) for each method

4.7. Conclusion 91

Figure 4.42: Third party QoS Enabler Architecture description

• The external component can directly build the functions, without the intervalcomposition technique allowing a more accurate estimation

• The testing procedure does not care about the network channel, since all theintervals are part of the server or of the client.

• The clock synchronization is not needed during the test procedure, since allthe intervals are part of the server or of the client.

• A centralized external component introduces a single point of failure and anadditional software complexity

• A modification of the source code of the WS-Engine in both client and serverside is mandatory since time like t1,t2,t5 and t6 are internal parts of the WS-Engine

4.7 Conclusion

This chapter analyzes the present QoS status of art in a Web Service scenario andproposes a set of solutions that enable a remote service invocation with a given QoSin the IE context. However, our results can also be applied in a general scenario.

The contribution of this chapter can be divided in four different parts:


• Section 4.1 formalizes the problem and recognizes the need of a uniformdataset, where studying and comparing different techniques for the QoS ina WS context. In this section we also show that a general methodology capa-ble of estimating the execution time is not yet developed.

• The description of the information contained in the dataset is showed in section4.1.4 while in Appendix D the test bed architecture and implementation ispresented. Finally Section4.2 describes the obtained raw data stored in thedatasets. In particular, the dataset consists of 2304000 samples (of 9 significantvalues each) organized in 2304 different tests.

• In the third part of this Chapter we analyze the collected dataset in a moreexhaustive way. Two variants of a methodology that utilizes a Gaussian ap-proximation of the dataset distributions, in combination with regression modelof the key factors that influence the average and the standard deviation, havebeen developed in Section 4.3. Then, our estimator are validated with exper-imental results in a real scenario in section 4.4.

• In the last part of this Chapter (Section 4.6), we propose three differentsoftware architectures that can utilize the developed methodologies and al-gorithms.

5Information Dissemination

Instrument inter operations require fast response time and high throughput for con-trolling the equipments and for consuming the results [10], [128] as described inSection 1.1. The WS response time introduced in Chapter 3.3 demonstrates thatthis technology is not appropriate for this particular task. This chapter addressesthe problem of choosing and tuning the proper inter instrument fast communicationchannel.

In Section 5.1 we formalize the problem. In Section 5.2 we investigate differentpublish/subscribe architecture, while in Section 5.3 we present RMM-JMS as ourcandidate solution for accomplish this task. Finally, the experiments and the resultsobtained for different benchmarks and different systems are presented in Section 5.4.


The adoption of Web Service [38], [76],[82],[66] technology as basic building blocksfor the instrumentation part of the IE, and in particular the use of SOAP over HTTP,guarantees the interoperability of the implemented services and enables the lever-aging of related infrastructure like service discovery, security and encryption, andworkflow management [125]. However, the modest performance of a Web service-based communication network, limits its use to those cases where high bandwidthsand fast response are not required. In the case of IE, most of the control operationsrequire response time on the order of a fraction of a second. This is achieved bypresent Web service platforms as discussed in Chapter 2. However, this responsetime, as demonstrate in Chapter 3.3, and in [44] is not adequate for more demand-ing application and for intercommunication between instruments and for transferthe data generated by the equipment; in these cases the bandwidth requirement canbe very high [10], [128], A.3.

Grid tools [80], [81] for moving files can be used in situations where a file isproduced by the IE. By the way During immediate consumption of data or wheninter instrument data is exchanged, a fast end-to-end message and/or streamingbased communication channel must be established with the peers requiring the data[45]. In this case, the use of a SOAP-based protocol is clearly not adequate, while amessage-oriented protocol seems much more appropriate. Additional requirement in

94 5. Information Dissemination

Figure 5.1: typical environment for grid of instruments.

this last case is for one-to-many data delivery, since many peers usually require copiesof the same data [45]. Figure 5.1 provides a detailed description of the mentioneduse cases.

For accomplishing its functionality the instruments need to exchange and filtergenerated data using high performance connection network, while at the same time,users around the world want to control the entire system and monitor the on goingactivity.

To provide a solution for this last use cases and improve performance and usabil-ity, we contribute to the development and to the definition of the requirements ofRMM-JMS, a JMS [50] implementation on top of an high performance Reliable Mul-ticast Messaging (RMM) layer [68], [8]. This enables the IE to have high-throughputlow-latency transport services designed for one-to-many data delivery or many-to-many data exchange in a message-oriented middleware publish/subscribe fashion,which is also JMS compliant. RMM-JMS supports peer-to-peer communication inboth brokered and brokered-less modes and is singled out by its high performancecapabilities. RMM uses information on the network and buffers status to adaptivelyhandle the situation and for achieving high throughput and low latency.

This chapter presents and evaluates RMM and RMM-JMS; we compare perfor-mance of the our current implementation with known JMS releases in the market.Experimental results show that our system outperforms existing message distribu-tion systems; in particular, a single RMM-JMS node can receive or dispatch morethan 900000 messages per second with latency less than half a millisecond whilehandling data at more than 90MBytes/sec. The rest of this chapter is organized asfollows: Section 5.2 presents related work. Section 5.3 describes RMM and RMM-JMS. The experiments and the results obtained for different benchmarks and dif-ferent systems are presented in Section 5.4. Finally, in Section 5.5 we discuss our

5.2. Related Work 95

conclusions.

5.2 Related Work

Several attempts have been made to integrate heterogeneous high-performance dataproducers, like instruments, into complex and distributed framework like the Grid.CIMA [52] proposes a common instrument middleware based on Web Services us-ing SOAP over HTTP as a communication layer. JXTA Project [4], [2] attemptsto provide a common language (both C++ and Java implementation are provided)and platform to be used by all peers. The JXTA environment and language arebuilt around Jxta protocols that are defined via textual representation (i.e., XML)and Jxta pipes. A WS-based standard, WS-Notification [89], describes asynchronouspublish/subscribe notification models that can be used for listening to remote servicedata element updates; WSRF based framework like OGSA [97], [17], Apache-WSRF[103] and WSRF.NET [120] use this standard. In RGMA [6], the information re-sources of a virtual organization (VO) are presented as a single virtual databasethat contains a set of virtual tables and provides access to this information viaa WS interface. The Java Management Extensions (JMX) [50] technology is anopen system for management and monitoring. Via its Instrumentation, Agent, andDistributed Services layers, this standard can be used for adapting legacy systems,implementing new management tools, and providing monitoring solutions. Jini [107]attempts to provide mechanisms to enable adding, removing, and locating devicesand services on the network on top of RMI. The Java Message Service (JMS) de-fine a common set of API [91] that allow different peers of a distribute system tocommunicate in a publish/subscribe message or streaming based way. JMS im-plementation not only exist in Java language but several vendors provide also C,C++, C#, Ruby, Perl, Python, PHP implementation [96], [101], [119] in order toglue the different parts of a distributed system. Other JMS MessageQueue-basedsystems, like Naradabrokering [118], JBossMQ [84], JORAM [108], OpenJMS [112],ActiveMQ [101], Arjuna [104], Sun Message Queue [115] FioranoMQ [105] and others[127],[129],[110],[111],[121],[116], have been developed for providing a message mid-dleware that allows the interoperation between distributed components of a system.The majority of the implementations utilize a centralized, customizable componentthat provide the JMS services like publish/subscription and message filtering capa-bilities. Other implementations like Mantaray [109] utilize a unicast P2P approach.We propose a P2P multicast approach that enables high throughput low latencyrepayable messages and streaming distribution and yet, has no single point of fail-ure. We compare different systems and show that our system outperforms existingknown implementation.


5.3 RMM-JMS: a JMS Multicast P2P Architec-

ture Overview

RMM allows hosts to reliably exchange data messages over the standard IP multicastnetwork. It exploits the IP multicast infrastructure to ensure scalable resourceconservation and timely information distribution with reliability and traffic controladded on top of the standard multicast networking. RMM services are built asadditional network layers on top of UDP/IP and TCP/IP. The RMM-JMS solutionfor the IE is a Java implementation that includes a subset of RMM services. Wenext describe the layers of RMM-JMS

5.3.1 RMM-JMS Architecture

The packet transport layer (PTL) is the first layer on top of the network layer. ThePTL layer has two implementations; one that provides reliable multicast and con-forms to the PGM standard, and another part that is TCP based (reliable unicast).Both implementations can coexist in the same process.

In the PGM implementation the transmitter sequentially numbers the packetsit sends, treating the data flow as a transport stream (equivalent to TSI in PGM).Each transport stream has a number that uniquely identifies it. The packet sequencenumbers of each stream allow receivers to order packets, filter duplicate packets, anddetect missing packets. When a missing packet is detected the receiver request thatthe packet be retransmitted using a negative acknowledgment (Nack) packet.

The reliability support for packets in the PGM based implementation is based onthe negative acknowledgment mechanism, and incorporates Nack suppression, witha sliding repair window. The basic support for reliability means that each clienteither receives all the packets or can detect unrecoverable packet loss. The degreeof delivery assurance depends on the datagram loss rates, the network round triptime, and the transmitter storage capabilities.

The message transport layer (MTL) is built on top of PTL. This service isresponsible for reliable message delivery, as opposed to packet delivery handled bythe PTL. MTL implements publish/subscribe and point-to-point messaging modelsby mapping the message topics and queues onto the packet transport streams. Theservice allows for symmetric data exchange; any host can both transmit and receivemessages. Most of RMM APIs access the MTL publish/subscribe and point-to-point services directly. The message layer functionality incorporates a batchingmechanism for bandwidth-optimal delivery of small and medium messages, and amessage fragmentation/assembly mechanism for delivery of large messages. Thislayer is also responsible for ordered message reception, when such functionality isrequired. The MTL layer provides a number of different functions related to trafficflow control, periodic receiver aliveness checks, session advertisement, acknowledgeddelivery, multicast infrastructure connectivity and interface to JMS services.

5.3. RMM-JMS: a JMS Multicast P2P Architecture Overview 97

RMM was design with performance as the primary goal. The implementationincludes several patented features that enable RMM to support very high through-put with low latencies. RMM also extends conventional reliable multicast withadditional services such as flow and congestion control, acknowledge delivery andsupport for high availability messaging. Some of the features of RMM are outlinedbelow:

• High delivery performance. RMM’s unique method of message-to-packetmapping enables delay-free, high-speed data delivery of hundreds of thousands(up to a few millions) messages per second, at sub-millisecond latencies. Thismethod which works with both multicast and unicast transports performsoptimal message batching based on the load level.

• A number of different policies for congestion and traffic control.RMM allows for orderly delivery from the transmitter to the receivers, takinginto account the current network conditions, and reception capability of eachclient. It also allows for fair competition with other streams in the network,including TCP streams.

• Fast message filtering.nA special-purpose filtering technology, embedded inRMM messaging layer, allows for fine-grained efficient data multiplexing andfiltering in clients.

• A number of degrees of reliability above the standard IP multicast.Reliable, Acknowledged and Guaranteed delivery modes enable the most ef-fective tradeoff of performance for reliability, depending on the needs of theindividual applications.

• Implementation of a message delivery system. Unlike standard IP mul-ticast methods, which are packet-based, RMM implements a message-orientedmiddleware model, similar to JMS. This allows for application development ata higher level. Developers can work with high level concepts such as topic andmessage, rather than having to deal with low level details such as multicastgroup addresses and datagram packets.

The RMM-JMS layer runs on top of the MTL layer. It provides an efficientimplementation of the JMS standard using RMM services. The following messagingmodes are supported:

• Multicast transport for pub/sub messaging: Supporting the JMS Topic-basedmessaging and API, with matching done at the IP multicast level. The trans-port is a Nack-based reliable multicast protocol.

• Direct (broker- less) unicast for point-to-point messaging: Supporting the JMSQueue based messaging and API. The transport is the TCP protocol.


• Brokered unicast transport for pub/sub messaging (see below)

The RMM-JMS implementation is very efficient and provides special technologyfor topic selection. As a result we achieve high throughput and low latency on endto end messaging.

5.3.2 RMM-JMS Broker

Supporting publish/subscribe messaging in a unicast delivery mode is more complexthan in a multicast mode since only point-to-point messaging transport links areused. In the multicast case, the consumer uses the topic name to figure out whichmulticast group it has to join where in unicast mode the producer must know thelistening IP address and port of the consumer.

A messaging broker, which receives all the publications and subscriptions, andsends the appropriate messages to the appropriate consumer is used for supportingthe unicast case. The broker receives messages from the producer in either unicast ormulticast delivery mode, and sends the messages to the subscribers in either mode.

Another important usage of the broker is LAN-WAN-LAN bridging. In suchconfiguration two separate LANs, inside each of which IP multicast is available, areconnected via a WAN, where no IP multicast is available. A broker-pair bridge, orbroker/bridge for short, is responsible for communicating a multicast (or unicast)message sent in one LAN to a customer in the other LAN. The broker to brokerconnection is restricted to simple TCP tunneling but subscriber in each LAN canreceive a multicast message sent from the producer (in the local LAN) or a multicastmessage from the broker (remote LAN).

The message producer uses multicast or unicast for publishing. In the unicastmode, the JMS topics are implemented over RMM queues, all with remote end-point at the preconfigured bridge; the bridge’s IP address and listening port shouldbe given. No configuration has to be done for multicast publishing.

The broker initially listens for both producers and subscribers. If it gets a pub-lication message for which no subscription has been made, it just drops it. If thereare subscribers to this message, it is queued and eventually sent to each of the sub-scribers. No multicast group is joined until subscriptions are done. Once a topicis subscribed to, the broker joins the group on which this topic may be multicast.When a message with such a topic arrives, it is handled as before. Figure 1 presentsour broker/bridge in a LAN-WAN-LAN setup.

The broker/bridge configuration support multicast publication in each LAN,where some of the subscribers listen to multicast in another LAN. In such config-uration, each broker doesn’t know about the remote subscriptions, so it has to beconfigured to listen to a set of multicast groups and push everything to the oppositebroker. In a sense, each broker views the other one as a unicast subscriber, whichsubscribes to a wildcard (catch-all) topic.

5.3. RMM-JMS: a JMS Multicast P2P Architecture Overview 99

Figure 5.2: RMM-JMS broker/bridge in a LAN-WAN-LAN setup

The broker listens on its default unicast address. If so configured, it also joinsa range or multicast groups. It creates an RMM set of packet streams for eachof the unicast and multicast reception. The most important stream is the unicastonly broker subscription queue. A typical message on this queue is sent to the JMSclient upon creating a JMS topic subscriber. The client should than open an RMMreceive queue to receive feedback messages. The two queues are opened on the sameconnection, which is kept as long as the client’s JMS connection is not closed.

When a connection is first created, it is created in a stopped state. This means,that publications on this Topic will not be sent to the subscriber. To enable mes-sage flow, as JMS dictates, the client should send another message on the brokersubscription queue, with the directive ”start”, and no other data. The flow willbe suspended upon sending of a ”stop”; a ”close” (or reset on the connection) willcancel all subscription associated with the connection. The client can also send”unsubscribe” on a specific topic name.

To support subscriptions, the broker holds a list of all the subscriptions withthe queue associated with each one of them. The broker gets all the publications inits stream set receivers, and dispatches the messages to all those subscribers withstarted connections.

To support the LAN-WAN-LAN bridge, we configure each broker with the ad-dress of the peer broker. When the broker starts it sends a wildcard subscription toits peer with the same protocol used by a client to subscribe to a broker. This auto-


matically makes the peer broker forward all the messages it received from publishersto the subscribing broker. Finally, we enable the multicast receivers and transmit-ters of the brokers, and add the rule that message received via multicast are sentonly using unicast (no need to repeat messages which are multicast anyway).

5.3.3 Topic Mapping

The auto calculations of multicast groups from the topics may be replaced by im-plementing a central mapper at the broker. Even for multicast publishing and sub-scribing, the interested parties will get the multicast group from the broker using aone-time unicast handshake. This also may be extended to a multiplex mapping, toallow JMS topics to share RMM streams [68]. This information may also be used forthe LAN-WAN bridge configuration: Only topics which are known to be of interestto the other side should be pushed over. This enhancement may be implemented ina later stage.

5.4 Experimental Evaluation

In this section we present some experimental results that demonstrate the perfor-mances of our message distribution system compared with the fastest implementa-tion existing in the market. We performed two different set of tests; the first setmeasured the number of requests handled per second in different configurations ofdifferent systems, whereas the second set measured the latency introduces by oursystem.

5.4.1 Existing Benchmarks

The JXTA one-to-one messaging system has been exploited in [2]. WS-Notification-based systems, like RGMA, CIMA, and other SOAP based systems built on topof WS technology, were evaluated and the results in [44],3.3 can be considered asupper bounds on their performance. Our Reliable Multicast Messaging (RMM) isan implementation of high-throughput low-latency transport services designed forone-to-many data delivery or many-to-many data exchange in a publish/subscribefashion message-oriented middleware. RMM-JMS provides a JMS implementationon top of RMM that supports both publish/subscribe messaging services and point-to-point services. The authors of [126], [88] compared similar systems and foundthat the centralized Sun Message Queue [115] system and Mantary [109] - a fullydistributed system, are having the best performance; thus, we compared these twosystems with our RMM-JMS.

5.4. Experimental Evaluation 101

Figure 5.3: Message Rate Tests Scenarios

5.4.2 Test-bed Hardware and Software

The hardware and software environment of our experiments comprises 32 Dual Xeon2.40GHz, 1.5GB RAM machines running the CERN Scientific Linux 3.0.4 OperatingSystem, with Kernel 2.4.21− 27.0.2.EL.cernsmp and Java 1.4.2− 08− b03, linkedto each other by a 1 GB Ethernet switch. In this environment we set up a variablenumber of peers, written in Java, that communicate with each other using the JMS-RMM library, SunMessageQueue3.6 and Mantaray.

5.4.3 Messages Rate Tests

The goal of this set of tests is to see the effective number of messages that can beinjected into the system. We first measure the cost of 1 to N communication, where1 publisher publishes the same messages to N clients (N varies from 1 to 30). Next,we evaluate the opposite scenario where N (from 1 to 30) publishers communicatewith one subscriber. Figures 5.3 describe the tests configurations.

The publisher, in the case of 5.3 right, and the subscriber in Test 5.3 left wererunning in a dedicated machine; the subscribers and publishers were uniformly dis-tributed among 30 different machines. Finally in the case of SunMQ3.6 the brokerwas installed on an additional dedicated machine. These tests have been repeatedvarying the payload size of the exchanged messages.

No messages were lost during the tests and the statistics that were collectedon both the publisher’s and subscribers’ sides showed the same results (per run).Figures 5.4, 5.5, and 5.6 present the experimental results, on the subscriber’s side,for the test configuration 5.3 left with messages of size 100, 1000 and 100000 bytes,respectively.

From the figures, we can see that the number of messages handled by the sub-scriber depends on the messages size and it is independent (with high significance)of the number of publishers. Finally, for the RMM-JMS implementation the totalthroughput is 61 MBytes/sec when the system exchange messages of 1000 Bytes andit is 90 MBytes/sec in the case of messages of 100000 Bytes. The lack of a brokerenables a better system performance because messages did not have to be routed toan intermediate machine to reach the subscribers.


Figure 5.4: messages rate for varying number of publishers. Msg size 100 Bytes




The experimental results of the test configuration 5.3 right are presented inFigures 5.7, 5.8, and 5.9. Once again, no messages were lost during the tests andthe statistics that were computed on both the publisher’s and subscribers’ sides,showed the same results (per run). The presented measures have been taken fromthe publisher. As we can see in the plot of RMM the rate is practically constant; thiscan be explained by the multicast functionalities. In contrast, in standard P2P andbroker-less P2P implementations the rate dropped when the number of publishersincreases. We also note that a broker-less implementation allow a better systemperformance because messages do not need to be routed to an intermediate machinein order to reach the subscribers.

We conclude that the multicast system, that is the key feature of the RMM sys-tem, can be used for one-to-many data delivery reaching a transfer rate of more than80 MBytes/sec per subscriber when the hardware can support it. The maximummessages exchanged are on the order of 900000. This number is remarkable highcompared with results achieved for existing systems [126], [88], [2].

5.4.4 Round Trip Time (RTT) Tests

The second set of tests measures the round trip time for a message. Figure 5.10presents the set-up for the tests.

In two different machines a publisher sends a message to a given topic (1) and asubscriber was instructed to receive and send back the same messages to a different


Figure 5.7: messages rate for varying number of Subscribers. Msg size 100 Byte

Figure 5.8: messages rate for varying number of Subscribers. Msg size 1000 Bytes


Figure 5.9: messages rate for varying number of Subscribers. Msg size 10000 Bytes

Figure 5.10: RTT test description


Figure 5.11: Round Trip Time tests, experimental result.

topic (2). The publisher was listening for incoming messages. We computed theaverage round trip time over 1000 samples.

Figure 5.11 presents the results for messages of varying size. The results forRMM-JMS are compared with the time needed for a simple ping between the twomachines. As we can see, for messages shorter than 10000 Bytes the experiencedRTT is the same while for bigger messages the latency grows in proportion to the size.This behavior is explained by the software overhead in both the sender and receiver,side. Finally, note that the ping measure provides an asymptotic lower bound forsuch systems. The Mantaray implementation introduces 30 ms of minimum delayfor aggregating messages and saving time buffering information while the SunMQ3.6introduce an additional delay due to brokered communication. We can also note thatthis overhead increase consistently if we increase the messages size.

During the above tests, we experienced some anomalies when for a single messagethe RTT was larger than the average by 10 ms. This was mainly due to the garbagecollector of the JVM.

This behaviour motivates an additional test for measuring how frequently theseanomalous delays are. We performed a test similar to the previous one but insteadof computing the average RTT, we counted the number of anomalies. The chartin Figure 5.12 shows the experimental result for RMM using a sample of 100000messages for each different messages size. We can see that less than 0.06% of thesamples, were larger by 10 ms from the average RTT. This number decreases to0.025% when the break point is 20ms above the average; however, statistically nodelay can be grater than 50 ms above the average.


Figure 5.12: percentage of RMM RTT anomalies in a sample of 100000 measures

Figure 5.13: percentage of Sun MQ 3.6 RTT anomalies in a sample of 100000 mea-sures


Figure 5.14: percentage of Mantaray RTT anomalies in a sample of 100000 measures

The performances of Sun MQ3.6 are presented in Figure 5.13. As we can see,a remarkable number of anomalies were experienced during the test that increasesthe message size; this is probably due to the broker that introduces additional syn-chronizations points. Finally, Mantaray (figure 5.14) performs quite well in this testshowing a practically negligible number of anomalies due to the forced delay aftereach message delivery.

5.5 Conclusions

In this chapter, we described RMM-JMS, our solution for high throughput low la-tency pub/sub system. A multicast enabled Gigabit Ethernet hardware frameworkhas been set up to explore the limits of our proposed system. RMM-JMS multicastpub/sub supports a few hundred thousand messages per second, bandwidth in theorder of a Giga bit per second and sub millisecond latency. The IE can utilize thistechnology in multicast enabled networks (LAN and/or WAN). RMM-JMS also sup-ports pub/sub messaging in a unicast delivery mode in a brokered or brokered-lessconfigurations. Our broker can also be used as a bridge between different multicastenabled networks

Conclusions

In this thesis we have discussed how concrete use cases require a strong interactionbetween the instrumentation and the computational Grid and how they also needto be accessed directly from a remote site in the world. We have shown how thecreation of a coherent collection of services can allow both the remote configurationand control of a physical instrument, and a better integration with the computationalGrid. We have called this set of services Instrument Element (IE).

We have discussed in detail the proposed software architecture for this new com-ponent focusing on the functional and nonfunctional requirements that it introduce.However, the majority of the proposed solutions not only can be applied to the IE,but any application based on Web and Grid Services can benefit from these results.

In particular, in order to fulfill the scalability requirement we have evaluatedthe limit of XML for high-performance and high-interactive distributed computing,like the presented IE. We have also proposed a new parser, the Cache Parser, whichuses a cache to reduce the parsing time at sender and receiver side, by reusinginformation related to previously parsed documents/messages similar to the oneunder examination. Experimental results demonstrate that our algorithm is 25times faster than the fastest algorithm in the market and, if used in a WS scenario,can dramatically increase the number of requests per second handled by a server(up to 150% of improvement) bringing it close to a system that does not use XMLat all.

Moreover, in order to solve the Quality of Service (QoS) requirements, we haveaddressed the QoS issues in a Web Service scenario, identifying the prediction ofa remote method execution time as the main challenge. we also have created auniform and coherent dataset that enable QoS studies. Than we have proposed amethodology and an algorithm, based on 2k factorial analysis and on a Gaussianapproximation of the collected data, that enable the estimation of a remote methodexecution time. Finally, we have proposed three different software architectureswhere the developed algorithm can be integrated.

Our final issue has regarded the problem of determining a proper inter instru-ment fast communication channel. We have investigated different publish/subscribearchitecture and we have showed that RMM-JMS is the best candidate solution foraccomplishing this task. We have compared performance of our current implemen-tation with known JMS releases in the market. Experimental results show that oursystem outperforms existing message distribution systems. In particular, a singleRMM-JMS node can receive or dispatch more than 900000 messages per second withlatency less than half a millisecond, while handling data at more than 90MBytes/sec.

110 Conclusions

C.1 Open Research Issues

As pointed out in Section 1.2, a lot of ideas of this thesis have been already consideredor are under consideration by the GridCC Project [77],[83],[48], so we need to fillthe gap between research products and production software. According with whatautors presented in [30], for a Grid to be successful, we not only have to tackle thehuge technological problems but also address the social aspects of how to engageresearchers, educators, business and consumers in using the Grid as part of every-day work. Therefore we need to pay particular attention to the details of the IEsoftware. In particular many minor issues, like a ’one click’ installation or an easyconfiguration, are mandatory if we want that many non technical people use thisproduct.

We need to point out that the Grid is more and more becoming a collection ofhuge quantity of heterogeneous software. This software need to be installed config-ured and maintained. Therefore the production of an autonomic [70],[57] IE softwarecould save a lot of man power. In particular the adoption of the self-configuring,and self-healing ’mantra’ [34] could save a lot of deployment and maintaining time.

In addition, according to what Foster presented in [29], the standardization ofthe released components is mandatory for a successful Grid software. Therefore thestandardization of the VIGS, that in our case represents the way to control andmonitor the physical instruments behind the IE, (See 2.2 and 2.1.1) is an additionalmandatory issue.

Regarding the QoS, we believe that the tests showed in Section 4.4 we havedemonstrated the validity of the presented methodologies for estimation of a ser-vice execution time. We have also experienced that in the case of server overload,the number of deadline misses increases. This suggests a possible approach for anautomatic organization of the clients that balances the servers load: ’if the numberof deadline misses is more than the expected ones, probably the server is overload,so one or more connected clients could decide to use a different machine in whichis deployed the same service’. We also experienced a big experimental error in thecomputation of the deadline functions due to the size of the region where we werecomputing the linear regression model [55]. In order to reduce the experimentalerror, thus building more accurate predictors, the region of investigation could besplit in two parts, or a 3K factorial design could be explored [55].

AApplication that Are Using the

Current Release of the IE

The first Instrument Element Release is currently used to manage the following usecases.

A.1 The Intrusion Detection System

One of the main challenges in security management of large high-speed networks, isthe detection of suspicious anomalies in network traffic patterns due to DistributedDenial of Service (DDoS) attacks or worm propagation [63]. In the Intrusion De-tection System [63], anomaly sensors measure various network elements linked toGrid-controlled instrument managers within a real-time domain. The instrumentelement problem solver provides algorithms aimed to fuse the collected knowledgeanalyzing individual domain state reports, originated from heterogeneous sensors,to deduce a global view of security incidents detecting Distributed Denial of Service.

A.2 The Power Grid

In electrical utility networks (or power grids [32]), the introduction of a very largenumber of ’embedded’ power generators, often using renewable energy sources, cre-ates a severe challenge for utility companies. In addition, power systems involvemany geographically distributed participants: generator owners, transmission net-work operators, load managers, energy-market makers, supply companies, and so on.GridCC technology allows the generators to participate in a virtual organization,and consequently to be monitored and scheduled in a cost-effective manner.

A.3 The Compact Muon Solenoid Experiment

In the Compact Muon Solenoid (CMS) [10] Data Acquisition (DAQ), the instrumentelement is the master controller when the experiment is collecting data. Approxi-

112 A. Application that Are Using the Current Release of the IE

mately 2 ∗ 107 electronic devices need to be accessed and controlled by about 104

different machines scattered over a high-bandwidth network. The IE instructs thesub-part of this experiment to act according to the specific needs of a data collectionsession. The main functions of the instrument element in this case are: Controllingand monitoring the entire instrument, ensuring the correct and proper operation ofthe CMS experiment Controlling and monitoring the data acquisition system Pro-viding user interfaces and allow users to access the system from anywhere in theworld.

A.4 The Synchrotron Radiation Storage Ring

In the Elettra [130] Synchrotron Radiation Storage Ring, the IEs control and monitormany instruments (mainly sensors). The rate of incoming control and monitoringdata is different from the previous use-cases; it is smaller than the data rate inthe CMS scenario, yet, since it resides at a critical point of alerting against majorcatastrophe, it imposes high requirements on response times for alerts at the human-machine level interface.

A.5 The IMAA Sensor Networks

Operating since 2003, the Institute of Methodologies for Environmental Analysis(IMAA) installed a network of sensors devoted to providing real-time informationon several meteorology, physical-chemical parameters of soil and sub-soil, useful todescribing landslide dynamics, and possibly to detect warning conditions in a timelyfashion [58], [59]. Monitoring is done with a multi-channel data-logger [73] on themonitored side to collect/aggregate information coming from different sensors, bothpassive and active [79]. Different sensors are wired to a data-logger while this deviceis remotely controlled via a wireless network. The instrument element virtualizesthe access to the sensors controlling multiple data-acquisition devices, allowing gridaccess to the instruments.

A.6 The Advanced Gamma-Tracking Array Ex-

periment

AGATA [128], the Advanced Gamma-Tracking Array, is a 4π array of segmentedcoaxial detectors. The design consists of a geodesic tiling of a sphere with 12 regularpentagons and 180 hexagons. Sensors, which are front-end electronic devices, arelinked to the detector to dispatch the just-read information to the event-buildingfarm that will merge it into physical events. The IE controls every single subcom-ponent such as PSA farms, event builder, tracking farms, and data servers of this

A.7. The Device Farm 113

complex distributed application.

A.7 The Device Farm

A set of telecommunication measurement instruments of various categories (signalgenerators, signal analyzers, channel emulators), interconnected via programmableswitching matrices, are accessed and remotely controlled as web services, and theyare integrated in the IE architectural framework. The concept of ”virtual instru-ment” allows the remote control and visualization of the results of the measurementscarried out by an instrument [69]. In most cases, it also allowed to assembly thefunctions of more instruments found in the laboratory.

A.8 Meteorology Systems

The meteorological application of GridCC architecture consists of the Skiron/Etaweather forecasting system [23] and it is aiming to predict and analyze hazardousweather events. A HELLASGRID cluster at IASA is currently used as a test bedfor the model configuration and execution under the GridCC environment. Furtherdevelopments of the model algorithms and operation scripts have been prepared inorder to optimize the model utilization through the IE components. The system isoperating daily in deterministic mode. The stochastic mode is under development,although a beta version is currently testing.

The normal operation of the computational model runs in a deterministic fashioncovering the entire Mediterranean region. Emergency condition is assumed if ahazardous weather event is detected in the computational domain from the currentoperational cycle. In this case, the system can be switched to the stochastic modeinstead of the normal deterministic execution.

114 A. Application that Are Using the Current Release of the IE

BA Benchmark on the Current

Instrument Element Implementation

In this appendix we present some Instrument Element benchmark tests. The goal isto provide figures for scalability and flexibility of the first release of the InstrumentElement.

B.1 Command Reception Performances

The following section describes tests related to the receiving capability of the IEsControl Manager component.

Figure B.1 shows which components of the Control Manager are involved in thesetests. Two tests are performed:

• Test 1 is stressing the capability of the control manager to answer to the clientsrequests. Typical clients in this case are the VCR and Execution Services, buteven generic clients. Figure B.2 reports the results. Around 50 invocationsper second have been achieved, each invocation triggering a state transition inthe FSM engine.

• Test 2 is stressing the capability of the control manager to react to asyn-chronous messages, as happen when an instrument has to send error, informa-tion messages, but even state changes. Figure B.3 reports the results obtainedby varying the number of instruments sending messages to the Input Mangerand then to the Event Processor.

B.2 Command Distribution Performances

these tests was aimed measuring the distribution capability inside an IE when a treeinstrument manager structure is used to reach the controlled instruments. FiguresB.4, B.5, B.6, depicts the hierarchy that has been used.

116 B. A Benchmark on the Current Instrument Element Implementation

Figure B.1: Instrument Element invocation benchmark test description

Figure B.2: Test 1 Results: VCR invocation capability

B.2. Command Distribution Performances 117

Figure B.3: Test 2 Results: IE messages handling capability

Figure B.4: Instrument Manager hierarchy performance tests: 1 IM


Figure B.5: Instrument Manager hierarchy performance tests: 3 IM

Figure B.6: Instrument Manager hierarchy performance tests: 3 IM in 3 machines

B.2. Command Distribution Performances 119

Figure B.7: Instrument Element command distribution benchmark test results

In the case of Figure B.4 a single Instrument Manager was controlling from 10 to120 instruments exchanging SOAP messages over HTTP. Case B.5 shows a similarcase, but with 3 Instrument Managers running in the same machine and controllingthe same number of resources. Finally the case B.6 instantiates the 3 InstrumentManagers in 3 different machines.

The graphic of Figure B.7 shows the time spent to distribute a command byvarying the number of the controlled instruments for all the 3 above mentionedcases using a parallel and a sequential command distribution.

This shows that a distributed configuration of the Instrument Managers canensure better performance were it is needed.

CRleated Work on Complex On-Line

Controls Systems

The goal of this appendix is to present a small, result-oriented overview of someof the Artificial Intelligence techniques available to solve a specific problem. Thisproblem comes from the needs of high-energy physics computational environments,but it’s the general problem of analyzing on-line distributed sources of informationand trying to give hints about the things that could be happening, like peripheralsystem failures.

From a more architectural point of view, this problem can be formalized asa series of devices which produce information about their state. This informationfeeds into a Subsystem Supervisor, in order to get advice useful to detect and resolvepotential problems about the good functioning of the whole system.

What we want to achieve here is an overview of ’what can be reached’ usingparticular techniques, in order, as a first step, to prune the approaches that areobviously not suitable for the purpose.

C.1 Overview of Techniques

Over the last few decades knowledge-based systems have been investigated very in-tensively, and successfully applied to a large variety of problems and applications.Overall, artificial intelligence techniques have produced superior behavior due totheir ability to successfully handle behavior that was unknown to domain experts.Since in our case the behavior of IE services is unknown in advance, we will con-centrate on a close investigation of problem solving and knowledge-based techniquesthat fall under an artificial intelligence classification.

The goal of this section is to present a broad overview of some of the ArtificialIntelligence techniques that we have considered for real-time problem solving. Suchproblem solving can be focused on two main aspects: (1) solving problems duringthe operation of the general system, or so-called fault detection, and (2) solvingproblems that are directly related to the performance of instrumentation, whereprediction methods are employed to identify and predict the possible behavior of

122 C. Rleated Work on Complex On-Line Controls Systems

specific instruments. The first aspect is basically responsible for the behavior of ser-vices in the IE architecture in general. In this case, the problem solving techniqueswill analyze data obtained by monitoring the logs produced by various services. Inthe second case, the problem solving techniques are used to analyze the behaviorof instrumentation, predict the behavior of measured data and identify the possiblefailures on the instrumentation side. In this case, the problem solving techniquesare focused on the analysis of data measured by the instrumentation. The choiceof problem solving techniques is highly dependent on the requirements produced byparticular instrumentation, in other words by applications used in the architecture.What we want to achieve here is an overview of ’what can be reached’ using partic-ular techniques, in order, as a first step, to prune the approaches that are obviouslynot suitable for the purpose.

After a brief introduction about the technologies that can be used, we will discusssome advantages and disadvantages of each approach.

C.2 Expert Systems

There is no exact definition of an expert system, but it’s generally agreed that expertsystems:

• Represent their knowledge symbolically. In practice, most systems use IF-THEN rules.

• After giving an answer, can justify or explain it by showing which knowledgethey used to come to that conclusion.

• In a similar way can explain why they have asked their user a particularquestion.

• Can imitate the performance of a human expert in a narrow domain of ex-pertise, such as mortgage tax advice, interpreting mass spectra, or planningcomputer systems so long as the performance of the system is known in ad-vance and the existing expert’s knowledge can be used to generate IF-THENrules.

Expert systems, like human experts, are experts only in their field and as suchare highly domain specific. In general, expert systems are not intended as cognitivemodels. It helps (in some cases), if a system reasons in a way that a human canunderstand. However, we’re not usually aiming to produce a detailed model of theexpert, merely a tool which can solve the same problems.

A simple rule-based expert system can easily be programmed to generate auto-matic explanations of how it has reached a conclusion, or why it is asking a ques-tion. However, these explanations leave a lot to be desired, being too detailed and

C.2. Expert Systems 123

Figure C.1: Expert-based System

low-level. These defects stimulated work on systems which give a more structuredoverview of their reasoning, and even ones which tried to adapt to their user’s levelof skill (see Figure C.1).

Often, the term expert systems is reserved for programs whose knowledge basecontains the knowledge used by human experts, in contrast to knowledge gatheredfrom textbooks or non-experts.

The area of human intellectual endeavor to be captured in an expert system iscalled the task domain. Task refers to some goal-oriented, problem-solving activity.Domain refers to the area within which the task is being performed. Typical tasksare diagnosis, planning, scheduling, configuration and design.

Every expert system consists of two principal parts:

• The knowledge base;

• The reasoning, or inference, engine.

The knowledge base of expert systems contains both factual and heuristic knowl-edge.

Factual knowledge is that knowledge of the task domain that is widely shared,typically found in textbooks or journals, and commonly agreed upon by those knowl-edgeable in the particular field.

Heuristic knowledge is the less rigorous, more experiential, more judgmentalknowledge of performance. In contrast to factual knowledge, heuristic knowledgeis rarely discussed, and is largely individualistic. It is the knowledge of good prac-tice, good judgment, and plausible reasoning in the field. It is the knowledge thatunderlies the ”art of good guessing”.

Knowledge representation formalizes and organizes the knowledge. One widelyused representation is the production rule, or simply rule. A rule consists of an IFpart and a THEN part (also called a condition and an action). The IF part lists aset of conditions in some logical combination. The piece of knowledge representedby the production rule is relevant to the line of reasoning being developed if the IFpart of the rule is satisfied; consequently, the THEN part can be concluded, or its


problem-solving action taken. Expert systems whose knowledge is represented inrule form are called rule-based systems.

Another widely used representation, called the unit (also known as frame, schema,or list structure) is based upon a more passive view of knowledge. The unit is anassemblage of associated symbolic knowledge about an entity to be represented.Typically, a unit consists of a list of properties of the entity and associated valuesfor those properties.

Since every task domain consists of many entities that stand in various relations,the properties can also be used to specify relations, and the values of these propertiesare the names of other units that are linked according to the relations. One unitcan also represent knowledge that is a ”special case” of another unit, or some unitscan be ”parts of” another unit.

The problem-solving model, or paradigm, organizes and controls the steps takento solve the problem. One common but powerful paradigm involves chaining of IF-THEN rules to form a line of reasoning. If the chaining starts from a set of conditionsand moves toward some conclusion, the method is called forward chaining. If theconclusion is known (for example, a goal to be achieved) but the path to thatconclusion is not known, then reasoning backwards is called for, and the method isbackward chaining. These problem-solving methods are built into program modulescalled inference engines or inference procedures that manipulate and use knowledgein the knowledge base to form a line of reasoning.

Knowledge is almost always incomplete and uncertain. To deal with uncertainknowledge, a rule may have associated with it a confidence factor or a weight. Theset of methods for using uncertain knowledge in combination with uncertain data inthe reasoning process is called reasoning with uncertainty. An important subclass ofmethods for reasoning with uncertainty is called fuzzy logic, and the systems thatuse them are known as fuzzy systems.

Because an expert system uses uncertain or heuristic knowledge (as we humansdo) its credibility is often in question (as is the case with humans). When an answerto a problem is questionable, we tend to want to know the rationale. If the rationaleseems plausible, we tend to believe the answer. So it is with expert systems. Mostexpert systems have the ability to answer questions of the form: ”Why is the answerX?” Explanations can be generated by tracing the line of reasoning used by theinference engine.

The most important ingredient in any expert system is knowledge. The powerof expert systems resides in the specific, high-quality knowledge they contain abouttask domains. AI researchers will continue to explore and add to the current reper-toire of knowledge representation and reasoning methods. But in knowledge residesthe power. Because of the importance of knowledge in expert systems and becausethe current knowledge acquisition method is slow and tedious, much of the futureof expert systems depends on breaking the knowledge acquisition bottleneck and incodifying and representing a large knowledge infrastructure.

C.2. Expert Systems 125

C.2.1 Expert Systems Advantages

The Expert System approach was the very first attempt, dated around the 1980’s,to define systems giving answers to a set of possible questions. So, for construction,they have the advantage of modeling series of conditional choices, and some formof correlation between available data in the query and the steps needed to get ananswer.

Since the Expert Systems paradigm is based upon the concept of the decisiontree, they can model uncertainty in some way, at least by considering from thequeries the information that they were built upon. This kind of behavior might begood to produce quantitative results, being very near to heuristic criteria applied tothe information used to build them.

Some real-world applications of Expert Systems are related to providing adviceto professionals in information intensive environments, e.g.

• Advice for physicians in analysing symptoms

• Advice for car mechanics in repair.

C.2.2 Expert Systems Disadvantages

In some form Expert Systems can be seen as intelligent, but they are reactive and notproactive and not fully autonomous. In fact they need instructions and intervention,especially in the case of a continuous training coming from their use.

They also do not interact with the environment or with other entities except forthe user and the trainer, hence they are usually not adaptive. There is also theproblem of the size of the database and of using it efficiently. If the system consistsof several million rules, it takes a very powerful control program to produce anyconclusions in a reasonable amount of time. If the system also has a large quantityof information in the working memory, this will further slow things down unless avery good indexing and search system is available. Another problem that comes froma large database is that as the number of rules increases the conflict set also becomeslarge, so a good conflict resolving algorithm is needed if the system is to be usable.One more problem is that of gathering the rules. Human experts are expensive andare not extremely likely to want to sit down and write out a large number of rules asto how they come to their conclusions. More to the point, they may not be able to.Although they will usually follow a logical path to their conclusions, putting theseinto a set of IF ... THEN rules may actually be very difficult or even impossible.

What may be a way round this problem is to enable Expert Systems to learn asthey go, starting off with a smaller number of rules but given the ability to deducenew rules from what they know and what they ’experience’, given some feedbackfrom their activity.


Figure C.2: ComparisonTraditionalFuzzySets

C.3 Fuzzy Logic

Classical logic relies on something being either True or False. A True element isusually assigned a value of 1, while False has a value of 0 (see Figure C.2 (left)).Thus, something either completely belongs to a set or it is completely excluded fromit. Fuzzy logic broadens this definition of membership.

The bases of the logic are fuzzy sets. Unlike in ”crisp” sets, where membership isfull or none, an object is allowed to belong only partly to one set. The membershipof an object to a particular set is described by a real value from the range between0 and 1. Thus, for instance, an element can have a membership value 0.5, whichdescribes a 50% membership in a given set (see Figure C.2 (right)).

Such logic allows a much easier application to many problems that cannot beeasily implemented using the classical approach.

In classical set theory, a subset U of a set S can be defined as a mapping fromthe elements of S to the elements of the set 0, 1,

U : S−→0, 1

Similarly, a fuzzy subset F of a set S can be defined as a set of ordered pairs,each with the first element from S, and the second element from the interval [0, 1],with exactly one ordered pair present for each element of S. This defines a mappingbetween elements of the set S and values in the interval [0, 1]. The value zero is usedto represent complete non-membership, the value one is used to represent completemembership, and values in between are used to represent intermediate degrees ofmembership. The set S is referred to as the universe of discourse for the fuzzy subsetF. Frequently, the mapping is described as a function, the membership function ofF. The degree to which the statement

x is in F

is true is determined by finding the ordered pair whose first element is x. Thedegree of truth of the statement is the second element of the ordered pair.

C.3. Fuzzy Logic 127

Because of the above alterations, some logical operations had to also be modified.In fuzzy logic we could give a meaning to statements like ”X is LOW”. In the sameway, we can interpret a statement like:

X is LOW and Y is HIGH or (not Z is MEDIUM)

using the standard fuzzy logic definitions:

• truth (not x) = 1.0 - truth (x)

• truth (x and y) = minimum (truth(x), truth(y))

• truth (x or y) = maximum (truth(x), truth(y))

Some researchers in fuzzy logic have explored the use of other interpretations ofthe AND and OR operations, but the definition for the NOT operation seems to besafe.

If you plug just the values 0 and 1 into these definitions, you get the sametruth tables as you would expect from conventional Boolean logic. This is knownas the extension principle, which states that the classical results of Boolean logicare recovered from fuzzy logic operations when all fuzzy membership grades arerestricted to the traditional set 0,1. This effectively establishes fuzzy subsets andlogic as a true generalization of classical set theory and logic. In fact, by thisreasoning all crisp (traditional) subsets are fuzzy subsets of this very special type;and there is no conflict between fuzzy and crisp methods.

Generally fuzzy logic is recommended for the implementation of very complexprocesses, where a simple mathematical model cannot be obtained. Fuzzy logic canalso be successfully applied to highly non-linear processes, where it is observed togreatly simplify the modeling. It is not recommended to employ fuzzy logic intosystems where a simple and adequate mathematical model already exists or wherethe conventional control theory yields a satisfying result. Fuzzy logic seems to be ageneral case for the classical logic and as such it does not present any better solutionsfor problems that might be easily solved using the ”crisp” sets.

The most obvious implementation for fuzzy logic is the field of artificial intelli-gence. Although, fuzzy logic not only brings logic closer to natural language, butalso closer to human or ”natural” reasoning. Many times knowledge engineers haveto deal with very vague and common sense descriptions of the reasoning leading to adesired solution. The power of fuzzy logic is to perform reasonable and meaningfuloperations on concepts that cannot be easily codified using a classical approach.

Implementing the logic will not only make the knowledge systems more userfriendly, but it also will allow programs to justify better the obtained results.

In a fuzzy system, a human expert has to define a set of rules like the following:

IF cond(1)=A1 and cond(2)=A2 THEN conclusion(1)=B1...

IF cond(n)=An and cond(m)=Am THEN conclusion(n)=Bn


Given this, the system is able to get the conclusions by evaluating the conditionsusing the standard fuzzy logic definitions.

Fuzzy logic seems to be a general case for the classical logic. It modifies the rulesfor a set membership and defines operations on modified sets. It allows an element tobelong only partly to a given set. Such modification allows for a much more flexibleand widespread use of reliable and consistent logic in a variety of applications. Sofar, the most common use of the fuzzy logic was encountered in the field of controlsystems, although the theory seems to have big potential in the different fields ofartificial intelligence. The logic stirred a lot of controversy since its introduction,but as it is successfully implemented into more and more applications, it becomes amore accepted way of modeling reality.

Such a classification certainly allows a single object to be a member of twomutually exclusive in the ”crisp” sense sets. For example a person 5 feet and 5inches tall can be classified as 0.5 tall and also 0.3 short, thus he could be describedas ”rather tall” and at the same time ”sort of short”. A single element membershipto different sets does not have to add up to any particular value.

Although, a membership to a negative set (ex. a set of not tall people) has toequal to 1 minus membership to the positive set (a set of tall people).

For the union of two sets, it was found, the result is the higher membership valueout of the two.

For example if an element is a person that is 0.6 member of a set of smart peopleand 0.7 member of a set of pretty people, it makes logical sense to state that suchperson has 0.7 membership in a set of smart or pretty people. The intersection ofthe two sets is the minimal element of the operators. Thus, referring to the aboveexample, the person would be only 0.6 member of a set of smart and pretty people.

It is worth noting that such a representation operates on different principles thanprobabilistic theory, which relies on the same set of values, and is often confusedwith the fuzzy set manipulation. Unlike in fuzzy sets, where an element is partlya member of a set, the probability value describes a chance of the whole elementbelonging to a particular set. The union and the intersection are the most obviousdifferences between these two representations. In the case of fuzzy logic addingmemberships for the union of sets or multiplying memberships for the intersectionmakes no logical sense (for example, a person from the example above being 1.3member of a set of smart or pretty people or 0.42 member of a set of smart andpretty people).

C.3.1 Fuzzy Logic Advantages

Fuzzy logic converts complex problems into simpler problems by using approximatereasoning. The system is described by fuzzy rules and membership functions usinghuman type language and linguistic variables. Thus, one of its best advantages isthat one can effectively use his/her knowledge to design the systems behavior.

C.3. Fuzzy Logic 129

A fuzzy logic description can effectively model the uncertainty and non-linearityof a system. It is extremely difficult, if not impossible, to develop a mathematicalmodel of a complex system to reflect non-linearity, uncertainty, and variation overtime. Fuzzy logic avoids the complex mathematical modeling.

Another advantage point in this approach is that all the fuzzy variables of thesystem are uniformly treated. Doing so the model becomes structure free, meaningthat any variable of the model can be accessed with the same flexibility. Fuzzy logicis generally easy to implement using both software on existing microprocessors ordedicated hardware.

C.3.2 Fuzzy Logic Disadvantages

Fuzzy logic has been proven successful in solving problems in which conventional,mathematical model based approaches are either difficult to develop or inefficientand costly. Although easy to design, fuzzy logic brings with it some critical problems.

As the system complexity increases, it becomes more challenging to determinethe correct set of rules and membership functions to describe system behavior.

A significant time investment is needed to correctly tune membership functionsand adjust rules to obtain a good solution. For complex systems, more rules areneeded, and it becomes increasingly difficult to relate these rules. A hierarchical rulebase can be used but even then the problem remains, as relating rules at differenthierarchies is difficult.

Hence, for many systems, it is impossible to find a sufficient working set of rulesand membership functions.

In addition, the use of fixed geometric-shaped membership functions in fuzzylogic limits system knowledge more in the rule base than in the membership functionbase.

Fuzzy logic uses heuristic algorithms for defuzzification, rule evaluation, andantecedent processing. Heuristic algorithms can cause problems mainly becauseheuristics do not guarantee satisfactory solutions that operate under all possibleconditions. Moreover, the generalization capability of fuzzy logic is poor compared toneural nets. The generalization capability is important in order to handle unforeseencircumstances.

Once the rules are determined, they remain fixed in the fuzzy logic controller,which is unable to learn (except in adaptive fuzzy systems, which allow some limitedflexibility).

Conventional fuzzy logic cannot generate rules (users cannot write rules) thatwill meet a predetermined accuracy. Accuracy is improved only by trial and error.

Conventional fuzzy logic does not incorporate previous state information (veryimportant for pattern recognition, like speech) in the rule base.


C.4 Neural Networks

Networks that mimic the way the brain works; computer programs that actuallylearn patterns; forecasting without having to know statistics. These are just some ofthe many claims and attractions of artificial neural networks. Neural networks havebeen successfully used for many different applications including robotics, chemicalprocess control, speech recognition, optical character recognition, credit card frauddetection, interpretation of chemical spectra and vision for autonomous navigationof vehicles.

Neural network methods share a loose inspiration from biology in that they arerepresented as networks of simple neuron like processors. A typical “neuron” takesin a set of inputs, sums them together, takes some function of them, and passes theoutput through a weighted connection to another neuron. At first glance, this isnot very revealing to a statistician. But as we will show, many familiar statisticaltechniques can be represented in this framework.

Each neuron may be viewed simply as a predictor variable, or a function of acombination (linear or non-linear) of predictor variables. The connection weightsare the unknown (or adjustable) parameters which are set by a “training method”.That is, they are estimated.

Artificial neural networks retain only a small amount of this complexity and usesimpler neurons and connections, but keep the idea of local computation. Manydifferent network architectures are used, typically with hundreds or thousands ofadjustable parameters.

Neural networks process information in interconnecting processing elements (of-ten termed neurons, units or nodeswe will use nodes). These nodes are organized intogroups termed layers. There are three distinct types of layers in a back-propagationneural network: the input layer, the hidden layer(s) and the output layer. A net-work consists of one input layer, one or more hidden layers and one output layer.Connections exist between the nodes of adjacent layers to relay the output signalsfrom one layer to the next. Back-propagation related paradigms require supervisedtraining. This means they must be taught using a set of training data where knownsolutions are supplied.

Fully connected networks occur when all nodes in each layer receive connectionsfrom all nodes in each preceding layer. Information enters a network through thenodes of the input layer. The input layer nodes are unique in that their sole purposeis to distribute the input information to the next processing layer (i.e., the firsthidden layer). The hidden and output layer nodes process all incoming signalsby applying factors to them (termed weights). Each layer also has an additionalelement called a bias node. Bias nodes simply output a bias signal to the nodes ofthe current layer. All inputs to a node are weighted, combined and then processedthrough a transfer function that controls the strength of the signal relayed throughthe nodes output connections. A node’s operation is shown in Figure C.3. Thetransfer function serves to normalize a nodes output signal strength between 0 and

C.4. Neural Networks 131

Figure C.3: Example of Neural Network

1.

When a network is used in recall mode, processing ends at the output layer. Dur-ing training, the networks response at the output layer is compared to a suppliedset of known answers (training targets). The errors are determined and back prop-agated though the network in an attempt to improve the networks response. Thenodal weight factors are adjusted by amounts determined by the training algorithm.The iterative procedure of processing inputs through the network, determining theerrors and back propagating the errors through the network to adjust the weightsconstitutes the learning process. One training iteration is complete when all suppliedtraining cases have been processed through the network. The training algorithmsadjust the weights in an attempt to drive the networks response error to a minimum.Two factors are used to control the training algorithms adjustment of the weights.They are the learning rate coefficient, eta, and the momentum factor, alpha. If thelearning rate is too fast (i.e., eta is too large), network training can become unstable.If eta is too small, the network will learn at a very slow pace. The momentum factorhas a smaller influence on learning speeds, but it can influence training stability andpromote faster learning for most networks.

The dot product is computed between the inputs and the weight vector (seeFigure C.4). That result is passed through the transfer function to obtain the nodesoutput signal strength. The output is passed through to the next layer until theoutput layer is reached.


Figure C.4: Basic structure of neuron

C.4.1 Neural Networks Advantages

One advantage of the network representation is that it can be implemented in mas-sively parallel computers with each neuron simultaneously doing its calculations.Several commercial neural network chips and boards are available, but most peoplestill use neural network “simulators” on standard serial machines. This report willnot discuss parallel hardware implementation, but it is important to remember thatparallel processing was one of the motivations behind the development of artificialneural networks.

Neural nets try to mimic the human brains learning mechanism. Like fuzzylogic, neural net based solutions do not use mathematical modeling of the system,but learn system behavior by using system input-output data.

Neural nets have good generalization capabilities. The learning and generaliza-tion capabilities of neural nets enable it to more effectively address non-linear, timevariant problems, even under noisy conditions. Thus, neural nets-can solve manyproblems that are either unsolved or inefficiently solved by existing techniques, in-cluding fuzzy logic.

C.4.2 Neural Networks Disadvantages

A major problem with neural nets is their Black Box nature, or rather, the relation-ships of the weight changes with the input-output behavior during training and useof trained system to generate correct outputs using the weights. Our understanding

C.5. Intelligent Agents 133

of the Black Box is incomplete compared to a fuzzy rule based system description.

From an implementation point of view, neural nets may not provide the mostcost effective solution. Neural net implementation is typically more costly thanother technologies; in particular fuzzy logic (embedded control is a good example).A software solution generally takes a long time to process and a dedicated hardwareimplementation is more common for fuzzy logic than neural nets, due to cost.

It is also difficult, if not impossible, to determine the proper size and structureof a neural net to solve a given problem. Also, neural nets do not scale well. Ma-nipulating learning parameters for learning and convergence becomes increasinglydifficult.

C.5 Intelligent Agents

”Agents” are autonomous, computational entities that can be viewed as perceivingtheir environment through sensors and acting upon their environment through effec-tors (see Figure C.5). To say that agents are computational entities simply meansthat they physically exist in the form of programs that run on computing devices.To say that they are autonomous means that to some extent they have control overtheir behavior and can act without the intervention of humans and other systems.

Agents pursue goals or carry out tasks in order to meet their design objectives,and in general these goals and tasks can be supplementary as well as conflicting.”Intelligent” indicates that the agents pursue their goals and execute their taskssuch that they optimize some given performance measures.

To say that agents are intelligent does not mean that they are omniscient oromnipotent, nor does it mean that they never fail. Rather, it means that theyoperate flexibly and rationally in a variety of environmental circumstances, giventhe information they have and their perceptual and effectual capabilities. A majorfocus of Distributed Artificial Intelligence therefore is on processes such as problemsolving, planning, search, decision making, and learning that make it possible foragents to show flexibility and rationality in their behavior, and on the realization ofsuch processes in multi-agent scenarios.

As is often the case when a technical field provokes commercial interest, therehas been a large movement and change of focus in the AI research community toapply the basic artificial intelligence techniques to distributed computer systems,company-wide intranets, the Internet, and the World Wide Web.

C.5.1 Events-Conditions-Actions

This is where we have to deal with events, recognize conditions, and take actions.

An event is anything that happens to change the environment or anything ofwhich the agent should be aware. Short of having our agent constantly running and


Figure C.5: Interaction between agent and environment

checking or polling all the devices and computer systems we want it to monitor,having events signal important occurrences is the next best thing.

When an event does occur, the agent has to recognize and evaluate what theevent means and then respond to it.

Events-conditions-actions define the workings of an agent. Some authors feelthat an agent must also be proactive. It must not only react to events, but must beable to plan and initiate actions on its own.

An intelligent agent must be able to initiate transactions with other agents onour behalf, using all of the intelligence and domain knowledge they can bring tobear. But this is just an extension of the event-condition-action paradigm.

C.5.2 Taxonomies of Agents

Intelligent agents have been the focus of researchers for years. In that time, manydifferent ways of classifying or categorizing agents have been proposed.

One way is to place the agent in the context of intelligence, agency, and mobility.Another approach is to focus on the primary processing strategy of the agent. Athird is to categorize the agent by the function it performs.

C.5.3 Agency, Intelligence, and Mobility

When we talk about software agents, there are three dimensions or axes which weuse to measure the capabilities: agency, intelligence, and mobility.

Agency deals with the degree of autonomy the software agent has in representingthe user to other agents, applications, and computer systems.

Intelligence refers to the ability of the agent to capture and apply applicationdomain-specific knowledge and processing to solve problems. Thus our agents canbe relatively dumb, using simple coded logic, or they can be relatively sophisticated,using complex AI-based methods such as inferencing and learning.


An agent is mobile if it can move between systems in a network. Mobility intro-duces additional complexity to an intelligent agent, because it raises concerns aboutsecurity (the agents and the target systems) and cost. Intranets are a particularlyripe environment for mobile intelligent agents to roam because they require lesssecurity than in the wide-open Internet.

C.5.4 Processing Strategies

One of the simplest types of agents are reactive or reflex agents, which respond inthe event condition action mode. Reflex agents do not have internal models of theworld. They respond solely to external stimuli and the information available fromtheir sensing of the environment.

Like neural networks, reactive agents exhibit emergent behaviour, which is theresult of the interactions of these simple individual agents. When reactive agentsinteract, they share low level data, not high-level symbolic knowledge. One of thefundamental tenets of reactive agents is that they are grounded in physical sensordata and are not operating in the artificial symbol space.

Deliberative or goal-directed agents have domain knowledge and the planningcapability necessary to take a sequence of actions in the hope of reaching or achievinga specific goal.

Deliberative agents may proactively cooperate with other agents to achieve atask. They may use any and all of the symbolic artificial intelligence reasoningtechniques which have been developed over the past forty years.

Collaborative agents work together to solve problems. Communication betweenagents is an important element, and while each individual agent is autonomous,it is the synergy resulting from their cooperation that makes collaborative agentsinteresting and useful. Collaborative agents can solve large problems which arebeyond the scope of any single agent and they allow a modular approach based onspecialization of agent functions or domain knowledge.

In a collaborative agent system, the agents must be able to exchange informationabout beliefs, desires, and intentions, and possibly even share their knowledge.

As mentioned earlier, a mobile agent is a software process (a running programscode and its state) which can travel across computer systems in a network doingwork for its owner. An advantage of mobile agents is that the communicationsbetween the home system and the remote systems are reduced.

By allowing the agent to go to the remote system and access data locally on thatsystem, we enable a whole new class of applications. For example, mobile agentscould provide an easy way to do load balancing in distributed systems.

C.5.5 Multi-agent Systems (MAS)

There are a number of fundamental aspects that characterise a MAS and distinguishit from a single-agent system: Agent design It is often the case that the various


agents that comprise a MAS are designed in different ways. A typical exampleis software agents, also called softbots, that have been implemented by differentpeople. In general, the design differences may involve the hardware (for examplesoccer robots based on different mechanical platforms), or the software (for examplesoftware agents running different operating systems).

We often say that such agents are heterogeneous in contrast to homogeneousagents that are designed in an identical way and have a priori the same capabilities.However, this distinction is not clear-cut; agents that are based on the same hard-ware/software but implement different behaviors can also be called heterogeneous.

Agent heterogeneity can affect all functional aspects of an agent from perceptionto decision making, while in single-agent systems the issue is simply non-existent.

Environment Agents have to deal with environments that can be either static(time invariant) or dynamic (non-stationary). Most existing AI techniques for singleagents have been developed for static environments because these are easier to handleand allow for a more rigorous mathematical treatment.

In a MAS, the mere presence of multiple agents makes the environment appeardynamic from the point of view of each agent. This can often be problematic, forinstance in the case of concurrently learning agents where non-stable behavior canbe observed. There is also the issue which parts of a dynamic environment an agentshould treat as other agents and which not.

The key characteristics of multi-agent systems are:Perception The collective information that reaches the sensors of the agents in

a MAS is typically distributed: the agents may observe data that differ spatially(appear at different locations), temporally (arrive at different times), or even se-mantically (require different interpretations). This automatically makes the worldstate partially observable to each agent, which has various consequences in the de-cision making of the agents. An additional issue is sensor fusion, that is, how theagents can optimally combine their perceptions in order to increase their collectiveknowledge about the current state.

Control Contrary to single-agent systems, the control in a MAS is typicallydistributed decentralized). This means that there is no central process that collectsinformation from each agent and then decides what action each agent should take.The decision making of each agent lies to a large extent within the agent itself. Ina cooperative or team MAS, distributed decision-making results in asynchronouscomputation and certain speed-ups, but it also has the downside that appropriatecoordination mechanisms need to be additionally developed. Coordination ensuresthat the individual decisions of the agents result in good joint decisions for thegroup.

Knowledge In single-agent systems we typically assume that the agent knowsits own actions but not necessarily how the world is affected by its actions. In aMAS, the levels of knowledge of each agent about the current world state can differsubstantially. For example, in a team MAS involving two homogeneous agents, eachagent may know the available action set of the other agent, both agents may know


(by communication) their current perceptions, or they can infer the intentions ofeach other based on some shared prior knowledge. On the other hand, an agentthat observes an adversarial team of agents will typically be unaware of their actionsets and their current perceptions, and might also be unable to infer their plans. Ingeneral, in a MAS each agent must also consider the knowledge of each other agentin its decision making.

Typically we view communication in a MAS as a two-way process, where allagents can potentially be senders and receivers of messages. Communication can beused in several cases, for instance, for coordination among cooperative agents or fornegotiation among self-interested agents.

C.5.6 Communication

When our agents need to talk to each other, they can do this in a variety of ways.They can talk directly to each other, provided they speak the same language. Orthey can talk through an interpreter or facilitator, providing they know how to talkto the interpreter, and the interpreter can talk to the other agent.

There is a level of basic languagethe syntax and format of the messages, andthere is a deeper level the meaning or semantics. While the syntax is often easilyunderstood, the semantics are not. For example, two English-speaking agents mayget confused if one talks about the boot and bonnet, and the other about the hoodand trunk of an automobile. They need to have a shared vocabulary of words andtheir meaning. This shared vocabulary is called ontology.

C.5.7 Blackboards

The blackboard architecture was first introduced in the Hearsay II speech recognitionproject. It featured a system with multiple knowledge sources or independent agents,each with a specific domain of expertise related to speech analysis. The blackboardis a data structure that is used as the general communication mechanism for themultiple knowledge sources and is managed and arbitrated by a controller.

As each agent works on its part of the problem, it looks to the blackboard to pickup new information posted by other agents, and they, in turn, post their results tothe blackboard. So the blackboard is an information-sharing device, with multiplewriters and multiple readers. Thus, the blackboard architecture allows multipleagents to work independently and cooperate to solve a problem.

C.5.8 KQML

The Knowledge Query and Manipulation Language (KQML) provides a frameworkfor programs and agents to exchange information and knowledge. KQML focuses onmessage formats and message-handling protocols between running agents, but onlythe message protocols are specified. The content or language used to represent the


content is not. KQML defines the operations that agents may attempt on each othersknowledge bases, and provides a basic architecture for agents to share knowledgeand information through special agents called facilitators.

C.5.9 Cooperating Agents

With agents, the advantages of the small, independent knowledge sources must beweighted against the considerable disadvantages of introducing a language barrierbetween them. But in several domains, the benefits have far outweighed the costs.

An important aspect of multi-agent design systems is that each intelligent agenthas its own perspective on what a good or optimal design is, depending on its areaof expertise. This is not very different from cross-functional development teams.Thus, each agent must be willing to compromise in order to achieve a better overallor global design. This also means that somewhere there is an agent that can providesome measure of the quality of the overall design and can arbitrate conflicts betweenthe more specialized agents.

C.5.10 Stream Filtering Agents

One formal approach to coordination was developed by Singh. This approach rep-resents each agent as a small skeleton, which includes only the events or transitionsmade by the agent that are significant for coordination.

Coordination requirements are stated as temporal logic formulas involving theevents. Formulas have been obtained that can capture the coordination requirementsthat arise in the literature.

Figure C.6 shows a skeleton that is suited for agents who filter a stream, monitora database, or perform any activity iteratively.

Its significant events are start (accept an input, if necessary, and begin), error,end of stream, accept (accept an input, if necessary), respond (produce an answer),more (loop back to expecting more input).

Here, too, the application-specific computation takes place in the node labelled”Executing.” The events error, end of stream, and respond are immediate, and allother events are flexible, and start is in addition triggerable.

C.5.11 Intelligent Agents Advantages

The behavior of a system based on Intelligent Agents depends very much on itsarchitecture as well as the methods used. Therefore, the advantages and disadvan-tages of this approach will be considered taking into account how the IntelligentAgents are used in the system.

Between the advantages of using Intelligent Agents, one could argue that thisparadigm might couple well with the needs of a distributed system for log analysis.This is indeed the desirable scenario in which the bulk of the information is processed


Figure C.6: Agent action flowchart

near the remote sources of data, while some form of centralized gathering can bedone on the outputs of the agents’ multitude.

This scenario falls inside the Multiple Agent Systems scheme, in which

• Single agent or groups are designed separately (modular)

• The approach itself is flexible and fault tolerant.

At this point, while the processing structure might be adequate for a distributedtriggering/filtering task, the main question which arises is about the simplicity ofreconfiguring and making the single agents evolve in order to make better their(local) job. If an organization is too much spread across multiple hosts, that ofreaching, modifying and enhancing multiple independent agents can be a seriousissue in the real world.

Hence, an interesting idea is to consider a centrally designed architecture. Themain advantage of such an approach is its relative simplicity and predictability, since

• components are known

• interaction language and protocols are agreed upon

• Agents can be (and usually are) cooperative

• Agents share architecture - software reuse.


One key advantage of the ability for social interaction in an Open Multiple AgentSystem is that the agents can form a domain agent society. Basically, this acts likea user group for programmers - if the agent does not have the answer itself, it willask other members of the domain agent society. Security would have to be factoredinto any society such as this, since a company would not necessarily want its agentsanswering all the queries they get. If our mobile agents had a way to describe theircapabilities to other agents, there would be no need for the potentially costly processof the agent trying to work out which other agents to trust. A convenient way ofdoing this is to use WSDL.

In addition to the above choices about the overall structure of an agent-basedsystem doing distributed data analysis, another design decision to consider is aboutthe internal structure of the agents taking part in the computations. In this per-spective, we may distinguish between reactive and deliberative agents. Reactiveagents act mainly as triggers: upon input from the environment, they react withaction execution. Deliberative agents invoke a reasoning process upon input, andany action is based on the results of the reasoning.

Obviously, agents may populate the whole spectrum between purely reactiveand maximally deliberative. This decision, however, has to meet with the goalswhich have to be reached through the MAS, keeping in mind the main advantagesof the minimalistic reactive behavior of the single agent. In fact, their internalcomplexity is computationally tractable, mechanisms dealing with fault tolerancecan be deployed, and what is more important is that overall complex behavioremerges from component interaction, not from the single unit sophistication.

C.5.12 Intelligent Agents Disadvantages

A centrally designed architecture has a number of drawbacks, such as:

• Costly maintenance (adding new agents may necessitate the single system re-design)

• The system may be less fault tolerant.

• Difficult to inter-operate with others

• Not reflecting real-world requirements (not realistic), especially in the case ofa not centrally represent able environment.

While the idea of an Open Multiple Agent System is somewhat interesting, itsdisadvantages come directly from its points of force, i.e.:

• The overall behavior of the system might be unpredictable


• A stronger effort is needed on the communication protocols side, since lan-guages and ontology may vary across agent types. A truly open and expand-able architecture could be designed only on the top of open and expandableprotocols. The more obvious idea may be that of using XML and SOAP.

• Self-interest and malicious behaviors are in general difficult to avoid

• A more careful agent and interaction protocols design is needed.

In the case of the reactive approach, some drawbacks that can be highlightedare that, without a model of the environment, agents need sufficient information todetermine the actions to be taken, the fact that agents are short-sighted may limitdecision quality, and, although an overall complex behavior can emerge from themultitudes of components, the relationship between components is not clear., i.e.It’s difficult (if not impossible) to formalize.

Perhaps the biggest inhibitor to widespread use of mobile agents is security. Thecommon name for software that comes unbidden onto systems and starts executingis viruses.

DQoS Test Bed Architecture:

Implementation Details

This appendix describes the test bed architecture, providing all the implementationdetails that ensure the validity of the collected information.

From an intuitive point of view when the WS client performs a service invocationit can send also t0, t1, t6, and t7 times to a QoS Metric Collector component. Inthe same time the WS Server reply to the client invocation and send t2, t3, t4, t5to the Collector too.

The Collector receives the information, correlate the times and construct theinterval mentioned in section 4.1.5 and store it.

A mandatory requirement is that both, client and server should minimize theadditional operation in order to let the Collector component compute the intervalswithout introduce unpredictable overhead.

What follows is a short description of the architecture and a discussion on theerror introduced in measures using the developed software.

D.1 QoS Test Bed Architecture

Figure D.1 show the test bed architecture that has been realized as a P2P systemthat runs in parallel with the web service invocation and exchange messages inthe same network using TCPs channels. As mentioned in the introduction of thischapter different software components have been developed:

WS-Server that:

• Reply to remote the client’s remote call

• Sends its time information to the Collector component.

• Synchronize itself with the client in order to let the collector receive coherenttime from both client and server

WS-Client that:

144 D. QoS Test Bed Architecture: Implementation Details

Figure D.1: Testbed software architecture

• Remotely invokes the server

• Sends its time information to the Collector component

• Synchronize itself with the server in order to let the collector receive coherenttime from both client and server

• Notify the QoS Metric Collector when the current test is finishing

QoS Metric Collector that:

• Remotely invokes the server

• Sends its time information to the Collector component

• Synchronize itself with the server in order to let the collector receive coherenttime from both client and server

• Notify the QoS Metric Collector when the current test is finishing

In order to allow the interaction between the system peer 3 communication chan-nel have been set upped. The first one for dispatch time metric to the QoS MetricCollector (QoS Metric), the second for the Client-Server synchronization (CleanBuffer) and the last between the Client and the Collector in order to send notifica-tion related to the current test status (End Test). From a temporal point of viewthe component interactions are described by figure D.2 and are also remarked infigure D.1.

D.2. Implementation Details 145

Figure D.2: QoS Testbed component interaction diagram

Firstly the client initiates a new test sending the test description to the Collector;secondly it send a clean message to the server in order to force a clean up of theeventually buffered times measures, thirdly the real test begin and times informationare collected during the web service invocations. Finally, once all the test neededinvocations are finished, the Client notifies the collector.

D.2 Implementation Details

A critical importance in these tests is the position of the timing probe in both theclient and the server; a wrong position can cause unpredictable behavior in the timeslice. Times like t0 and t7 can be easily collected just after and before the methodexecution while t3 and t4 can be taken just after and before the beginning/end ofthe remote method.

Unfortunately t1,t6 client side and t2,t5 server side are inside the web serviceengine therefore we was force to chose an open source product for our tests. Thesource code of Axis (version 1.4) was modified introducing our probe and then usedin order to create the web service client and server.

To reduce additional code overhead the collector was running in a separate ma-chine and the collected times was buffered on both client and server side and sent ina single messages to the collector using a simple TCP connection. A JMS Library[109] was used in order to create the communication channels and it was instruct

146 D. QoS Test Bed Architecture: Implementation Details

to send messages in background. Before start the constitution of the dataset, inorder to measure the overhead introduced by this modification, a comparison testwas performed. This test was a comparison between a standard web service and thesame remote service equipped with the above presented software and the result wasnegligible.

For control the CPU load a separate work and sleep java program has beencreated and it was running in both the client and the server machine.

As final remark the Collector was realized as a java stand alone application andwas instrumented using a JMX [50] library in order to provide on-line informationabout the tests.

D.3 Experimental Error on the Sample Measures

Is well known that java systems introduce 1ms of uncertain in every measure [100]while the client-server clocks synchronization has a better precision given that themachines are directly linked by an Ethernet switch [94]. Considering that the expe-rienced time intervals are about 100ms or more we can consider this error negligible.

Bibliography

[1] N. Abu-Ghazaleh, M. J. Lewis, and M. Govindaraju. Differential Serializationfor Optimized SOAP Performance. In HPDC ’04: Proceedings of the 13thIEEE International Symposium on High Performance Distributed Computing(HPDC’04), pages 55–64, Washington, DC, USA, 2004. IEEE Computer So-ciety.

[2] G. Antoniu, M. Jan, and D. A. Noblet. Enabling JXTA for High Perfor-mance Grid Computing. Research Report RR-5488, INRIA, IRISA, Rennes,Submitted to HPCC 2005, February 2005.

[3] J. Blommers. HP Professional Books Architecting Enterprise Solutions withUNIX Networking. (Paperback) Prentice Hall PTR; 1st edition, October 1998.

[4] D. Brookshier, D. Govoni, N. Krishnan, and J. C. Soto. published JXTA: JavaP2P Programming. Sams Publishing.

[5] G. Buttazzo, G. Lipari, L. Abeni, and M. Caccamo. Soft Real-Time Systems:Predictability vs. Efficiency. Springer, 2005.

[6] R. Byro, B. Coghlan, A. Cooke, R. Cordenonsi, L. Cornwall, M. Craig,A. Djaoui, S. Fisher, A. Gray, S. Hicks, S. Kenny, J. Leake, O. Lyttleton,J. Magowan, R. Middleton, W. Nutt, D. O’Callaghan, N. Podhorszki, P. Tay-lor, J. Walk, and A. Wilson. R-GMA: Production Services for Informationand Monitoring in the Grid. AHM2004, 2004.

[7] Zhou C., Chia L.-T., and Lee B. QoS-Aware and Federated Enhancement forUDDI. International Journal of Web Services Research,Vol. 1, No. 2.

[8] B. Carmeli, G. Gershinsky, A. Harpaz, N. Naaman, H. Nelken, J. Satran,and P. Vortman. High Throughput Reliable Message Dissemination. In SAC’04: Proceedings of the 2004 ACM symposium on Applied computing, pages322–327, New York, NY, USA, 2004. ACM Press.

[9] K. Chiu, M. Govindaraju, and R. Bramley. Investigating the Limits of SOAPPerformance for Scientific Computing. hpdc, 00:246, 2002.

[10] S. Cittolin, W.S. J. Varella, A. Racz, M. Della Negra, and A. Herve. CMSTDR 6.2 The TriDAS Data Acquisition project and High-Level TriggerCERN/LHCC, December 2002.

148 Bibliography

[11] I. Clarke, S. Miller, T. Hong, O. Sandberg, and B. Wiley. Protecting freeexpression online with Freenet, 2002.

[12] Maximilien E.M. and Singh M.P. A Framework and Ontology for DynamicWeb Services Selection. IEEE Internet Computing,, May 2004.

[13] OGC Sensor Web Enablement:. www.opengeospatial.org/functional/page=swe,last visit 01/01/2007.

[14] P. Th. Eugster, P. A. Felber, R. Guerraoui, and A. Kermarrec. The manyfaces of publish/subscribe. ACM Comput. Surv., 35(2):114–131, 2003.

[15] F.Lelli and G.Maron. the GridCC Project. Chapter of Distributed CooperativeLaboratories Networking Instrumentation and Measurements edit by Springer,September 2005.

[16] F.Lelli and G.Maron. Integrating Instruments into the Grid.GRIDtoday Supercomputing 06 Special Coverage: electronic journal:http://www.gridtoday.com/grid/1086062.html, November 2006.

[17] I. Foster and C. Kesselman. The globus toolkit. In Ian Foster and CarlKesselman, editors, The Grid: Blueprint for a New Computing Infrastructure,pages 259-278, 1999.

[18] E. Frizziero, M. Gulmini, F. Lelli, G. Maron, A. Oh, S. Orlando, A. Petrucci,S. Squizzato, and S. Traldi. Instrument Element: A New Grid componentthat Enables the Control of Remote Instrumentation. in proc of InsternationalSymposium on Cluster Computing and the Grid (CCGrid), volume 2:page 52IEEE Computer Society, 2006.

[19] E. Frizziero, M. Gulmini, F. Lelli, G. Maron, A. Petrucci, S. Squizzato, andS. Traldi. Report on login Grid service prototype. GridCC Project Deliverable3.2 www.gridcc.org, June 2006 (Authors are in no particular order).

[20] E. Frizziero, M. Gulmini, F. Lelli, G. Maron, A. Petrucci, S. Squizzato, andS. Traldi. Report on the Information and Monitoring System prototype.GridCC Project Deliverable 3.4 www.gridcc.org, June 2006 (Authors are inno particular order).

[21] E. Frizziero, M. Gulmini, F. Lelli, G. Maron, A. Petrucci, S. Squizzato, andS. Traldi. Report on the Resource Service prototype. GridCC Project Deliv-erable 3.3 www.gridcc.org, June 2006 (Authors are in no particular order).

[22] E. Frizziero, M. Gulmini, F. Lelli, G. Maron, A. Petrucci, S. Squizzato, andS. Traldi. Report on the VIGS prototype. GridCC Project Deliverable 3.1www.gridcc.org, June 2006 (Authors are in no particular order).

Bibliography 149

[23] Kallos G. The Regional weather forecasting system SKIRON. Proceedings ofthe Symposium on Regional Weather Prediction on Parallel Computer Envi-ronments, October 1997.

[24] X. Gao, R. Jain, Z. Ramzan, and U. Kozat. Resource Optimization for WebService Composition. IEEE International Conference on Services Computing(SCC05), Jul 2005.

[25] S. Graham, S. Simeonov, T. Boubez, G. Daniels, D. Davis, and Y. Nakamura.Building, Web Services with Java: Making Sense of XML, SOAP, WSDL, andUDDI. Sams, December 2001.

[26] M. R. Head, M. Govindaraju, A. Slominski, P. Liu, N. Abu-Ghazaleh, R. vanEngelen, K. Chiu, and M. J. Lewis. A Benchmark Suite for SOAP-basedCommunication in Grid Web Services. in proc. SC—05 (Supercomputing):International Conference for High Performance Computing, Networking, andStorage, Seattle WA, November 2005.

[27] A. L. Hors, P. L. Hegaret, L. Wood, G. Nicol, J. Robie, and M. Cham-pion. Document Object Model (DOM) Level 2 Core Specification Version1.0. W3C Recommendation http://www.w3.org/TR/2000/REC-DOMLevel-2-Core-20001113, November 2000.

[28] C. Huang, P. Kyberd, Z. Har’El, S. Pinter, B. Mandler, A. Harpaz, N. Naa-man, G. Gershinsky, E. Dekel, F. Lelli, and G. Maron. Web Service Com-pliant Monitoring Middleware Prototype. GridCC Project Deliverable 2.5www.gridcc.org, October 2006 (Authors are in no particular order).

[29] Foster I. What is the Grid? A Three Point Checklist. Grid Today, July 2002.

[30] Foster I and Kesselman C. The Grid 2: Bluprint for a New Computing In-frastructure. Morgan-Kaufmann, Second Edition, 2004.

[31] Fast Infoset. ITU-T Rec. X.891 — ISO/IEC 24824-1.

[32] M. Irving, G. Taylor, and P. Hobson. Plug into Grid computing. IEEE Power& Energy Magazine, pages pp 40–44, March/April 2004.

[33] Cardoso J., Sheth A., Miller J., Arnold J., and Kochut K. Quality of Servicefor Workflows and Web Service Processes. Journal of Web Semantics, Vol. 1,No. 3, pp. 281-308, 2004.

[34] B Jacob, R. Lanyon-Hogg, D.K. Nadgir, and A.F. Yassin. A Pratical Guide tothe IBM Autonomic Computing Toolkit. IBM Corp. Redbooks, April 2004.

150 Bibliography

[35] T. Kalganova, F. Lelli, R. Taylor, M. Alsaif, P. S. de Beauregard, S. Sup-pharangsan, S. Surendrakumar, and S. Vidot. Report on investigations intoknowledge-based systems. GridCC Project Deliverable 3.5 www.gridcc.org,October 2006 (Authors are in no particular order).

[36] T. Kalganova, S. Suppharangsan, R. Taylor, M. Alsaif, and F. Lelli. TowardsDevelopment of Problem Solver in the Grid Environment with Monitoringand Control of Instrumentation. In International Conference on IntelligentEngineering Systems (INES), London UK, june 2006.

[37] C. Kotsokalis, T. Ferrari, A. Lenis, A. Moralis, M. Alsaif, A. Petrucci, F. Lelli,A. Afzal, S. McGough, D. McBride, W. Lee, J Martyniak, L. De Marco, A. Sen-erchia, and F. Asnicar. Technological Review. GridCC Project Deliverable 1.1www.gridcc.org, December 2004 (Authors are in no particular order).

[38] Web Services Description language (WSDL) 2.0.http://www.w3.org/tr/wsdl20-primer, 2005.

[39] F. Lelli. Poster reception—Bringing instruments into the grid. In SC ’06: Pro-ceedings of the 2006 ACM/IEEE conference on Supercomputing. Awards:BestPaper Nomination, page 180, New York, NY, USA, 2006. ACM Press.

[40] F. Lelli, P. Hobson, C. Huang, C. Kotsokalis, T. Ferrari, A. Lenis, andG. Maron. A survey of existing middleware for the GRIDCC project. GridCCProject Deliverable 2.1 www.gridcc.org, June 2005 (Authors are in no partic-ular order).

[41] F. Lelli and G. Maron. AGaTA Run Control. AGaTA Project Deliverable,August 2006.

[42] F. Lelli and G. Maron. Report on QoS Implementation. GridCC ProjectDeliverable 2.4 www.gridcc.org, October 2006 (Authors are in no particularorder).

[43] F. Lelli, G. Maron, and S. Orlando. Enabling the Web Service Quality ofService. Istituto Nazionale di Fisica Nucleare Pre-Printing ID:INFN-LNL-212(2006), september 2006.

[44] F. Lelli, G. Maron, and S. Orlando. Improving the Performance of XML BasedTechnologies by Caching and Reusing Information. in proc of InternationalConference of Web Services (ICWS06), IEEE Computer Society volume 1:pag689–700, september 2006.

[45] F. Lelli, G. Maron, S. Orlando, and S. Pinter. Bringing instruments into aGrid: an Empiric Approach. WSEAS Transactions on Computers, Vol. 6, No1,pp. 153-159, 2007 January.

Bibliography 151

[46] Jeckle M. and Zengler B. Active UDDI - an Extension to UDDI for Dynamicand Fault-Tolerant Service Invocation. Web and Database-Related Workshopson Web, Web-Services and Database Systems, LNCS pp. 91-99, 2003.

[47] M. Mahemoff. Ajax Design Patterns. O’Reilly Media; 1 edition, June 1 2006.

[48] G. Maron, A. Lenis, S. Moralis, M. Grammatikou, T. Karounos, S. Papavas-siliou, V. Maglaris, P. Sphicas, S. Papavassiliou, T. Ferrari, C. A. Kotsokalis,A. S. McGough, T.Kalganova, P. Hobson, R. Pugliese, F. Lelli, and D. Colling.GridCC Architecture Design. GridCC project deliverable www.gridcc.org,May 2005 (Authors are in no particular order).

[49] G. Maron, A. Lenis, S. Moralis, M. Grammatikou, T. Karounos, S. Pa-pavassiliou, V. Maglaris, P. Sphicas, S. Papavassiliou, T. Ferrari, C. A. Kot-sokalis, A. S. McGough, T.Kalganova, P. Hobson, R. Pugliese, F. Lelli, andD. Colling. Revised Architecture Description. GridCC Project Deliverable 1.3www.gridcc.org, October 2006 (Authors are in no particular order).

[50] E. McManus and Sun Microsystems. Inc. JSR 160: JavaTM ManagementExtensions (JMX) Remote API 1.0, October 2003.

[51] D.F. McMullen, T. Devadithya, and K. Chiu. Integrating Instruments andSensors into the Grid with CIMA Web Services. Proceedings of the ThirdAPAC Conference on Advanced Computing, Grid Applications and e-Research(APAC05)., September 2005.

[52] D.F. McMullen, T. Devadithya, and K. Chiu. Integrating Instruments andSensors into the Grid with CIMA Web Services. Proceedings of the ThirdAPAC Conference on Advanced Computing, Grid Applications and e-Research(APAC05), September 2005.

[53] D. Menasce and V. A. F. Almeida. Capacity Planning for Web Performance:Metrics, Models, and Methods. (Paperback) Prentice Hall PTR; Bk&CD Romedition, May 1998.

[54] D.A. Menasce. QoS Issues in Web Services. IEEE Internet Computing, vol.6, no. 6, pp. 72-75, 2002.

[55] D. C. Montgomery. Design and Analysis of Experiments 5th edition. JohnWiley & Sons Inc, December 2004.

[56] R. Mordani. JSR 63: Java API for XML processing 1.1. Java CommunityProcess Specification, September 2002.

[57] M. Parashar and S. Hariri. Autonomic Computing: An Overview. SpringerVerlag, Vol. 3566, pp. 247-259, 2005.

152 Bibliography

[58] A. Perrone, A. Iannuzzi, V. Lapenna, P. Lorenzo, S. Piscitelli, E. Rizzo,and F. Sdao. High-resolution electrical imaging of the Varco d’Izzo earth-flow (southern Italy). Journal of Applied Geophysics, pages 56 (1), 17–29,2004.

[59] A. Perrone, G. Zeni, S. Piscitelli, A. Pepe, A. Loperte, V. Lapenna, and R. La-nari. On the joint analysis of SAR interferometry and Electrical ResistivityTomography surveys for investigating ground deformations: the case-study ofSatriano di Lucania (Potenza, Italy). Remote Sensing of Environment. Journalof Applied Geophysics, 2005.

[60] R. Pugliese, F. Asnicar, L. Del Cano, L. Chittaro, R. Ranon, L. De Marco, andA.Senerchia. Collaborative Environments for the GRID: the GRIDCC Mul-tipurpose Collaborative Environment. Tyrrhenian Workshop,Sorrento, July2005.

[61] Ran Sh. A Model for Web Services Discovery With QoS. ACM SIGecomExchanges, Vol. 4, No.1 pp. 1-10, 2003.

[62] S. Shirasuna, H. Nakada, and S. Sekiguchi. Evaluating Web Services BasedImplementations of GridRPC. In HPDC ’02: Proceedings of the 11 th IEEE In-ternational Symposium on High Performance Distributed Computing HPDC-11 20002 (HPDC’02), page 237, Washington, DC, USA, 2002. IEEE ComputerSociety.

[63] C. Siaterlis, A. Lenis, A. Moralis, P. Roris, G. Koutepas, G. Androulidakis,V. Chatzigiannakis, M. Grammatikou, D. Kalogeras, S. Papavassiliou, andV.Maglaris. Distributed Network Monitoring and Anomaly Detection as aGrid Application. HP Openview University Association Plenary Workshop(HP-OVUA) Porto, July 2005.

[64] Yu T. and Lin K.J. Service Selection Algorithms for Web Services with End-toend QoS Constraints. Journal of Information Systems and E-Business Man-agement, Volumn 3, Number 2, July 2005.

[65] T. Takase, H. Miyashita, T. Suzumura, and M. Tatsubori. An adaptive, fast,and safe XML parser based on byte sequences memorization. In WWW ’05:Proceedings of the 14th international conference on World Wide Web, pages692–701, New York, NY, USA, 2005. ACM Press.

[66] I. J. Taylor. from P2P to Web Services and Grids, Peers in a Client/ServerWorld. Springer, October 2004.

[67] C.K. Tham and R. Buyya. SensorGrid: Integrating Sensor Networks andGrid Computing. invited paper in CSI Communications, Special Issue on GridComputing, Computer Society of India, July 2005.

Bibliography 153

[68] Y. Tock, N. Naaman, A. Harpaz, and G. Gershinsky. Hierarchical Clusteringof Message Flows in a Multicast Data Dissemination System. Proceedingsof the International conference on Parallel and Distributed Computing andSystems (PDCS), November 2005.

[69] A. Vollono and A. Zinicola. A New Prospective In Instrumentation Interfacesas Web Services. in proc. of Tyrrhenian Workshop Sorrento, Italy, July 2005.

[70] T. De Wolf and T. Holvoet. Towards Autonomic Computing: agent-basedmodelling, dynamical systems analysis, and decentralised control. Proceedingsof the First International Workshop on Autonomic Computing Principles andArchitectures (Tianfield, H. and Unland, R., eds.), pp. 10, 2003.

[71] Gao X., Jain R., Ramzan Z., and Kozat U. Resource Optimization for WebService Composition. in Proc. of IEEE International Conference on ServiceComputing (SCC2005), 2005.

[72] Gu X. and R Chang. OoS-Assured Service Composition in managed ServiceOverlay Networks. In Proc. of The IEEE 23rd International Conference onDistributed Computing Systems (ICDCS 2003), 2003.

[73] Data acquisition system (keithley instruments model 2701, with plug-inswitching modules model 7702).

[74] W. Allcock, J. Bester, J. Bresnahan, A. Chervenak, L. Liming, and S. Tuecke.GridFTP: Protocol Extensions to FTP for the Grid. also available at:http://www-fp.globus.org/datagrid/gridftp.html, update January 2002.

[75] T. Bray, D. Hollander, and A. Layman. Namespaces in XML. W3C Rec-ommendation http://www.w3.org/TR/1999/REC-xml-names-19990114, Jan-uary 1999.

[76] 3.0. UDDI Specification. Version 2.0. http://www.uddi.org/specification.html.2005., 2005.

[77] Grid Enabled Remote Instrumentation whit Distributed Controland Computation (GridCC) project annex I. Also available at:http://www.gridcc.org/getfile.php?id=1436e, 2005.

[78] XML Binary Information Set (XBIS). http://www.xbis.org/, last visit01/01/2007.

[79] Non-polarizable petiau electrodes (sdec electrodes, pb/pbcl2-nacl) soilprobes made by http://www.campbellsci.com/sensors: Time domain re-flectometer (tdr) and a thermometer. atmospheric probes made byhttp://www.campbellsci.com/sensors: Pluviometer and thermometer.

154 Bibliography

[80] EGEE Middleware Architecture and planning, EGEE Project Deliv-erable, EGEE-DJRA1.1-594698-v1.0, Chapter 9. also available athttps://edms.cern.ch/document/594698/, Jul 2005.

[81] SRM: Storage Management Working Group. http://sdm.lbl.gov/srm-wg/, lastvisit 01/01/2007.

[82] Simple Object Access Protocol (SOAP) 1.1/1.2. http://www.w3.org/tr/soap/,2005.

[83] GridCC Project web site:. http://www.gridcc.org/, last visit 01/01/2007.

[84] JBossMQ web Site. http://www.jboss.org/wiki/wiki.jsp?page=jbossmq, lastvisit 01/01/2007.

[85] MONitoring Agents using a Large Integrated Services Architecture (MonAL-ISA). http://monalisa.caltech.edu/. California Institute of Technology, lastvisit 01/01/2007.

[86] V. Silva. Transferring files with GridFTP. http://www-128.ibm.com/developerworks/grid/library/gr-ftp/?ca=dgr-lnxw03GridFTP,April 2003.

[87] M K. Smith, C Welty, and D L. McGuinness. OWL Web Ontology LanguageGuide,W3C. also available at http://www.w3.org/TR/owl-guide/.

[88] Krisoft Solution. Performance Comparison (white paper) also available at ,http://hosteddocs.ittoolbox.com/krissoft102904.pdf.

[89] WS Notification specification. http://www-128.ibm.com/developerworks/webservices/library/specification/ws-notification/, last visit 01/01/2007.

[90] XML Specification:. http://www.w3.org/tr/rec-xml/, last visit 01/01/2007.

[91] JMS standard API:. http://java.sun.com/products/jms/, last visit01/01/2007.

[92] JSP standard API:. also available at http://java.sun.com/products/jsp/, lastvisit 01/01/2007.

[93] JDBC standard API: also available at. http://java.sun.com/javase/ technolo-gies/ database.jsp, last visit 01/01/2007.

[94] Network Clocks Synchronization. http://zone.ni.com/ devzone/ conceptd.nsf/webmain/ b40cbba4a2b06a0b862570af0055bdba, last visit 01/01/2007.

Bibliography 155

[95] P. Sandoz and et al. Fast Web Services.http://java.sun.com/developer/technicalArticles/Webservices/fastWS/,August 2003.

[96] IBM MQ Series. http://en.wikipedia.org/wiki/mqseries.

[97] Globus Open Grid Services Architecture OGSA.http://www.globus.org/ogsa/, last visit 01/01/2007.

[98] Yuval Oren. Piccolo XML Parser for Java. http://piccolo.sourceforge.net/.,last visit 01/01/2007.

[99] Web Service Interoperability Organization:. http://www.ws-i.org/, last visit01/01/2007.

[100] Java Clock precision. http://www.javaworld.com/javaworld/javaqa/2003-01/01-qa-0110-timing.html, last visit 01/01/2007.

[101] ActiveMQ Project. http://www.activemq.org/, last visit 01/01/2007.

[102] Apache Logging Project:. http://logging.apache.org/, last visit 01/01/2007.

[103] Apache WSRF Project. http://ws.apache.org/wsrf/, last visit 01/01/2007.

[104] Arjuna Project. http://www.arjuna.com/, last visit 01/01/2007.

[105] Fiorano MQ Project. http://www.fiorano.com/products/fmq/overview.htm,last visit 01/01/2007.

[106] INTERMON project. http://www.intermon.org/, last visit 01/01/2007.

[107] Jini project. home page http://www.jini.org/, last visit 01/01/2007.

[108] Joram Project:. http://joram.objectweb.org/, last visit 01/01/2007.

[109] Mantaray Project:. http://www.mantamq.org, last visit 01/01/2007.

[110] MetaQueue.Net Messaging project:. http:// www.metaqueue.net/ products/appmessaging.html, last visit 01/01/2007.

[111] Mom4j Project:. http://mom4j.sourceforge.net/, last visit 01/01/2007.

[112] OpenJMS Project. http://openjms.sourceforge.net/, last visit 01/01/2007.

[113] PerfSonar Project. http://www.perfsonar.net/, last visit 01/01/2007.

[114] PlanetLab project. http://www.planet-lab.org/., last visit 01/01/2007.

[115] Sun Message Queue Project:. http://www.sun.com/ software/ products/ mes-sage queue/ index.xml, last visit 01/01/2007.

156 Bibliography

[116] SwiftMQ project:. http://www.swiftmq.com/, last visit 01/01/2007.

[117] The Freenet Project. http://freenet.sourceforge.net/, last visit 01/01/2007.

[118] The NaradaBrokering Project. http://www.naradabrokering.org/, last visit01/01/2007.

[119] WebSphere MQ Everyplace project:. http://www-306.ibm.com/software/integration/wmqe/, last visit 01/01/2007.

[120] WSRF.NET Project. http://www.cs.virginia.edu/gsw2c/wsrf.net.html, lastvisit 01/01/2007.

[121] jtom project:. http://www.jtom.de/, last visit 01/01/2007.

[122] XML Binary Characterization Working Group.http://www.w3.org/xml/binary, last visit 01/01/2007.

[123] Interchangeable Virtual Instrument Foundation.http://www.ivifoundation.org/, last visit 01/01/2007.

[124] The Apache Software Foundation. Apache Xerces. http://xml.apache.org, lastvisit 01/01/2007.

[125] Business Process Execution Language for Web Services version also availableat. http://www-128.ibm.com/developerworks/library/specification/ws-bpel/,last visit 01/01/2007.

[126] Crimson consulting group. High-Performance JMS Messaging A BenchmarkComparison of Sun Java System Message Queue and IBM WebSphere MQ.www.sun.com/software/products/message queue/wp JMSperformance.pdf,last visit 01/01/2007.

[127] cyJNDI-cyJMS project:. members.aol.com/came2bringdapain/ cy-overview.html, last visit 01/01/2007.

[128] AGATA Advanced Gamma-Tracking Array design specification. Also availableat:. http://agata.pd.infn.it/Agata-proposal.pdf.

[129] elemenope project:. http://www.elemenope.org/, last visit 01/01/2007.

[130] Synchrotron Radiation Sotorage Ring Elettra.http://www.elettra.trieste.it/index.php, last visit 01/01/2007.

[131] C. Fry. JSR 173: Streaming API for XML. . Java Community Process Speci-fication, Final Release March 2004.

[132] GridCC Use Cases. also available at.https://ulisse.elettra.trieste.it/tutos gridcc/php/product show.php?id=1100.

List of PhD Thesis

TD-2004-1 Moreno Marzolla”Simulation-Based Performance Modeling of UML Software Architectures”

TD-2004-2 Paolo Palmerini”On performance of data mining: from algorithms to management systems fordata exploration”

TD-2005-1 Chiara Braghin”Static Analysis of Security Properties in Mobile Ambients”

TD-2006-1 Fabrizio Furano”Large scale data access: architectures and performance”

TD-2006-2 Damiano Macedonio”Logics for Distributed Resources”

TD-2006-3 Matteo Maffei”Dynamic Typing for Security Protocols”

TD-2006-4 Claudio Silvestri”Distributed and Stream Data Mining Algorithms for Frequent Pattern Dis-covery”

TD-2007-1 Marco Giunti”Secure Implementations of Typed Channel Abstractions”

TD-2007-2 Francesco Lelli”Bringing Instruments to a Service-Oriented Interactive Grid”

TD-2007-3 Matteo Mordacchini”Grid and Peer-to-Peer Resource Discovery Systems”