strategies, architecture and imple- mentation - CHOReOS

ICT IP Project Deliverable D4.2.2 V&V tools and infrastructure – strategies, architecture and implementation

http://www.choreos.eu

LATEX template v. 1.16

Project Number Project Title

: :

FP7-257178 CHOReOS Large Scale Choreographies for the Future Internet

Deliverable Number Title of Deliverable

: :

Nature of Deliverable Dissemination level Licence Version Contractual Delivery Date Actual Delivery Date Contributing WP Editor(s) Author(s)

: : : : : : : : :

Reviewer(s)

:

D4.2.2 V&V tools and infrastructure – strategies, architecture and implementation Report + Prototype Public Creative Commons Attribution 3.0 License A.2 M24 – 30/09/2012 04/01/2013 WP4 Antonia Bertolino, Guglielmo De Angelis, Andrea Polini Midhat Ali (Unicam), Cesare Bartolini (CNR), Amira Ben Hamida (Linagora), Antonia Bertolino (CNR), Felipe Besson (USP), Antonello Calabro` (CNR), Flavio Corradini (Unicam), Francesco De Angelis (Unicam), Guglielmo De Angelis (CNR), Teodoro De Giorgio (CEFRIEL), Felicita Di Giandomenico (CNR), Fabio Kon (USP), Nelson Lago (USP), Julien Lesbegueries (Linagora), Paulo Moura (USP), Gianmarco Panza (CEFRIEL), Emanuela Merelli (Unicam), Andrea Polini (Unicam), Alberto Polzonetti (Unicam), Alberto Ribolini (CNR), Sarah Zribi (Linagora), Maurilio Zuccala` (CEFRIEL) ´ Animesh Pathak, Valerie Issarny (Inria)

Abstract This deliverable presents the results of work within Workpackage 4 (WP4) and provides the supporting technical documentation for the various strategies and components released at Month 24 that are part of the CHOReOS IDRE infrastructure. WP4 focuses on the definition and implementation of tools supporting Governance and V&V activities for ULS FI choreographies. In particular, this document describes what has been designed and implemented with respect to mechanisms and tools for: • supporting development time testing activities of choreographies following a Test-Driven Development paradigm • supporting on-line governance and testing activities for services and choreographies • supporting monitoring activities of services and choreographies This deliverable completes and improves its previous version, Deliverable D4.2.1 released at M18, with more refined versions of the tools thereby introduced and with an emphasis on integration, based on the Resource Life-cycle registry. Scalability aspects to allow governance and V&V approaches to deal with ultra-large scale choreographies are discussed.

Keyword List Choreography, Future Internet, Governance, Monitoring, Policy, Quality of Service, Ranking, Registry, Role, Service Level Agreement, Test Driven Development, Testing, Ultra Large Scale, Verification and Validation

CHOReOS FP7-257178

III

CHOReOS FP7-257178

IV

Document History Version

Changes

1.0

Tentative of the ToC

1.2

Preliminary contents from all the partners Revised TOC and solicited missing contents by all partners

1.3

1.4

Finalization for the internal review

2.0

Draft for internal review

2.1

Revised the document structure

2.2 3.0

Applied changes from internal review Revised Final Version Final EU submitted Version implementing modifications suggested by the PTC

A.0 A.1

Final EU submitted Version implementing modifications suggested by the PTC

A.2

Revised version addressing the comments received form the Review at M24

Author(s) Midhat Ali, Antonia Bertolino, Guglielmo De Angelis, Andrea Polini all all Antonia Bertolino, Francesco De Angelis, Guglielmo De Angelis, Andrea Polini Antonia Bertolino, Guglielmo De Angelis, Andrea Polini Antonia Bertolino, Guglielmo De Angelis, Andrea Polini all all all Antonia Bertolino, Guglielmo De Angelis, Andrea Polini Antonia Bertolino, Guglielmo De Angelis, Andrea Polini

Document Reviews Review Outline

Date 11/06/2012

Ver. 1.0

Reviewers WP4 team

Draft

23/09/2012

2.0

Animesh Pathak

QA

3/10/2012

3.0

´ Valerie Issarny

Comments N.A. the review is uploaded on the internal wiki at https://collab. theresis.org/download/ attachments/25952265/ main-choreos-d4-2-2-AP-1. pdf Comments were communicated via e-mail to : [email protected], and [email protected]

PTC

CHOReOS FP7-257178

26/10/2012

A.1

N.A.

on 17/10/2012 N.A.

V

CHOReOS FP7-257178

VI

Glossary, acronyms & abbreviations Item ACRB API BPMN BSM CEP CRUD DoW EMF FI IDRE LGPL MDE MID OMG PL PMT PTC PMM Q4BPMN QoS REST SLA SOA SOAP TDD UL ULS URI V&V WS WP WPL WSDL XML XSD SL

CHOReOS FP7-257178

Description Adaptive Customer Relationship Booster Application Programming Interface Business Process Model and Notation Business Service Monitor Complex Event Processor Create, Read, Update, Delete Description of Work Eclipse Modeling Framework Future Internet Integrated Development and Run-time Environment GNU Lesser General Public License Model Driven Engineering Mobile Internet Device Object Management Group Project Leader Project Management Committee Project Technical Committee Property Meta Model Quality for BPMN Quality of Service REpresentational State Transfer Service Level Agreement Service Oriented Architecture Simple Object Access Protocol Test-Driven Development Ultra Large Ultra Large Scale Uniform Resource Identifier Verification and Validation Web Service Work Package Work Package Leader Web Services Description Language eXtensible Markup Language eXtensible Service Discovery Scientific Leader

VII

CHOReOS FP7-257178

VIII

Table Of Contents List Of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII List Of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII List of Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX 1

2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1

V&V conceptual architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

WP4 highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

Document structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

Development-Time Analysis and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1

Rehearsal framework for correctness and scalability testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.1

Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.2

Scalability Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.3

Rehearsal Scalability Dimensions, Issues, and Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

Non-functional Annotation and Analysis of Choreographies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2

2.2.1

3

1

Q4BPMN Scalability Dimensions, Issues, and Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Run-Time Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1

General Architecture of the V&V Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1

Choreography Participant Testing Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.2

CHOReOS Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3

Complex Event Processor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.4

Governance Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.5

Mocks Factory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.6

Policy Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.7

Q4BPNM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.8

ReputationRanking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.9

ServicePostboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.10

Test Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.11

Test Reporter Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.12

Test Suite Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.13

TestingRanking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2

Resource Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1

Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.2

Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.3

Core Resource Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.4

Resource Lifecycle Scalability Dimensions, Issues, and Strategies . . . . . . . . . . . . . . . . . . . 24

CHOReOS FP7-257178

IX

3.3

ServicePot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.1 3.4

ParTes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.1 3.5

CRank Scalability Dimensions, Issues, and Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Multi-source Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1

Overall Monitoring Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.1.1

Business Service Monitoring Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.2

CHOReOS Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.3

Complex Event Processor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.4

Infrastructure Monitoring Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.5

Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.6

RulesManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.7

ServiceLocator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2

Infrastructure Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.1 4.3

Infrastructure Monitoring Scalability Dimensions, Issues, and Strategies. . . . . . . . . . . . . . 49

Business Service Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.1

Business Service Monitoring Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.2

Communication Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.3

Data Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.4

Glimpse Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.5

QoS Runtime Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.6

BSM Monitoring Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.7

Business Service Monitor Scalability Dimensions, Issues, and Strategies. . . . . . . . . . . . . 53

4.4

5

ParTes Scalability Dimensions, Issues, and Strategies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

CRank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.5.1

4

ServicePot Scalability Dimensions, Issues, and Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Event Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4.1

Event Monitoring main components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4.2

Event Monitor Scalability Dimensions, Issues, and Strategies . . . . . . . . . . . . . . . . . . . . . . . . 56

Towards Validating the V&V Governance Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.1

The Adaptive Customer Relationship Booster Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.1

Brief Description and Main Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.2

Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.1.3

Scale Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2

Applying V&V to the ACRB Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.1

Development-time Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.2

Run-time Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2.3

Multi-source Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3

Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

CHOReOS FP7-257178

X

6

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 A

B

Exploratory Study on the TDD methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 A.1

Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A.2

Qualitative Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.2.1

Dynamic generation of web service clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.2.2

Web service mocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.2.3

Message interceptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.2.4

Abstraction of choreography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A.2.5

Methodology and Rehearsal acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A.3

Quantitative Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

A.4

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Resource Lyfe-cycle Manager : API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 B.1

Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

B.2

Core Resource Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

C ServicePot: API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 C.1

Choreography storage and retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

C.2

Extensibility in ServicePot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

D ParTes: API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 E CRank: API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 E.1

CRank: Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

E.2

CRankServicePlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

CHOReOS FP7-257178

XI

CHOReOS FP7-257178

XII

List Of Tables

Table 2.1: Rehearsal requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Table 2.2: Requirements covered by the related works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Table 2.3: ULS dimensions and Rehearsal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

Table 2.4: ULS dimensions and Q4BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Table 3.1: ULS dimensions and Resource Life Cycle Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Table 3.2: ULS dimensions and ServicePot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Table 3.3: ULS dimensions and ParTes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Table 3.4: ULS dimensions and CRank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Table 4.1: ULS dimensions and Infrastructure Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Table 4.2: ULS dimensions and BSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Table 4.3: ULS dimensions and Event Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Table 5.1: Scalability Dimensions of the ACRB Use Case (taken from D7.3 [34]). . . . . . . . . . . . . . . . . . 61 Table 6.1: WP4 tool repositories list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Table A.1: Questions to study WSClient feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Table A.2: Questions to study the web service mocking feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Table A.3: Questions to study the message interceptor feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Table A.4: Questions to study the abstraction of choreography feature . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Table A.5: Questions to study the acceptance of the proposed methodology. . . . . . . . . . . . . . . . . . . . . . 79 Table A.6: Experience and time taken with the development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

CHOReOS FP7-257178

XIII

CHOReOS FP7-257178

XIV

List Of Figures

Figure 1.1: Conceptual Overview of CHOReOS Governance and V&V Framework. . . . . . . . . . . . . . . .

2

Figure 2.1: Scalability Explorer Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Figure 2.2: Scalability Test Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Figure 2.3: Execution Flow of ScalabilityTester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

Figure 2.4: General Overview of the Q4BPMN Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Figure 2.5: Analysis and Monitoring Toolchain for Annotated BPMN Models . . . . . . . . . . . . . . . . . . . . . . 11 Figure 3.1: General Architecture of the V&V Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Figure 3.2: Governance Registry Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Figure 3.3: Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figure 3.4: Managers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figure 3.5: CoreManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Figure 3.6: ServicePot: High Level Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figure 3.7: ServicePot: Mapping of BPMN2 concepts to UDDI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figure 3.8: ServicePot: The ChorDDI Component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 3.9: ServicePot: Plugin Interfaces and Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 3.10: ServicePot: Distributed Publishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Figure 3.11: ServicePot: Distributed Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Figure 3.12: ParTes Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Figure 3.13: BPMN2 Basic Choreography Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figure 3.14: ParTes Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figure 3.15: Simple Parallel of ChoreographyTasks without Dependencies . . . . . . . . . . . . . . . . . . . . . . . 37 Figure 3.16: ”receiver-sender” Dependency Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figure 3.17: ”same-receiver” Dependency Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figure 3.18: ”chain” Dependency Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 CHOReOS FP7-257178

XV

Figure 3.19: Example of Complex Dependencies in a Choreography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Figure 3.20: CRank: Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figure 3.21: CRankServicePlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figure 4.1: Monitoring Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figure 4.2: Platform Monitoring Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Figure 4.3: The Notification Daemon Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Figure 4.4: The Business Service Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Figure 4.5: BSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Figure 4.6: Interaction in the Multi-Source Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Figure 4.7: Event Monitoring Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Figure 5.1: High-level ACRB Choreographies and Their Relationships (adapted from D7.1 [36]) . . . 60 Figure 5.2: ACRB Choreography: Shopping List Communication and Shops Identification (taken from D7.2 [22]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Figure 5.3: ACRB Choreography: Enter Shop and In Store Marketing & Sale (taken from D7.2 [22]) 64 Figure 5.4: ACRB Choreography: Enter Shop and In Store Marketing & Sale - Service Architecture (taken from D7.2 [22]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Figure A.1: Exploratory Study Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Figure A.2: WSClient - Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Figure A.3: WSClient - Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Figure A.4: WSMock - Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Figure A.5: WSMock - Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Figure A.6: Message Interceptor - Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Figure A.7: Message Interceptor - Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Figure A.8: Abstract of Choreography - Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Figure A.9: Abstract of Choreography - Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

CHOReOS FP7-257178

XVI

Figure A.10: Answers Obtained for the Questions of Table A.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Figure B.1: Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Figure B.2: CoreManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Figure C.1: ServicePot: Mapping of BPMN2 Concepts to UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figure C.2: ServicePot: The ChorDDI Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figure C.3: ServicePot: Plugin Interfaces and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Figure D.1: ParTes Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Figure E.1: CRank: Class Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Figure E.2: CRankServicePlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

CHOReOS FP7-257178

XVII

CHOReOS FP7-257178

XVIII

List of Listings 3.1 Java code generated for the basic example of a choreography . . . . . . . . . . . . . . . . 30 3.2 Template for the generation of a Java line with a new Choreography object . . . . . . . 33

CHOReOS FP7-257178

XIX

CHOReOS FP7-257178

XX

1 Introduction The CHOReOS project is developing the theory and supporting infrastructure required for the design, implementation, enactment, and management of large-scale choreographies for the FI. The solutions proposed concern the Development Environment, the supporting Middleware and the Governance and V&V framework. The respective approaches and components released in WPs 2-3-4 are then integrated under WP5 into the CHOReOS IDRE. As part of this effort, WP4 develops the strategies and tools required for governance, testing and monitoring. As we described in Deliverable D1.2 [4], there exist various approaches and tools for V&V of serviceoriented applications, which in principle could be applied to the services that compose a choreography. However, when it comes to the development of large-scale FI choreographies, existing approaches appears inadequate because significant challenges arise related to the internet features of scalability, heterogeneity, mobility, awareness & adaptability, and security, privacy & trust addressed in CHOReOS. Such challenges also apply to V&V activities, asking for innovative ways and instruments that are applicable to the FI choreographies. The approach that we propose in CHOReOS extends from development time to run-time, and is based on an agreed governance framework. An overview of the developed components is given in Figure 1.1, which provides a conceptual architecture of the WP4 framework and is further detailed in the next section. With reference to this conceptual architecture, in Deliverable D4.1: Governance V&V policies and rules [15] (released at Month 12) we provided an early high-level design of the V&V framework, and focused more specifically on the governance infrastructure. We presented a classification and initial definition of governance policies and rules that we conceive as an indispensable means to enable the application of V&V strategies in the dynamic FI context. Then, in Deliverable D4.2.1: V&V tools and infrastructure – Strategies, architecture and implementation [16] (released at M18), we refined the design of the CHOReOS governance and V&V architecture, and released a first running version for most of its components. The present deliverable is incremental on D4.2.1, with which it shares the same title. In the past six months we have continued to revise the overall architecture and have refined several of its constituent tools. In order to make this document a self-contained description of the WP4 approaches and tools, we report here all components released so far, both those that are new or have been significantly enhanced in the last reporting period and those that have only undergone minor changes. To clearly identify the progress made, for each chapter the description includes a short report of main changes with respect to the corresponding D4.2.1 version.

1.1. V&V conceptual architecture Figure 1.1 depicts a conceptual overview of the components resulting from research and development activities carried out within WP4. This is an abstract conceptual architecture, because the components here collected refer to different stages of a choreography lifecycle, and are hence addressing different stakeholders. In other words, users of the WP4 components will be probably interested in applying a subset of these components, depending on their role in the choreography development process. In particular, the components belong to three main categories and are packaged accordingly into three CHOReOS FP7-257178

1

main subsystems: 1) the package Development time V&V infrastructure collects those components devoted to support the testing activities in an off-line setting at design time; 2) the package Run-time Governance and V&V infrastructure collects those components supporting the extension of the verification phase along run-time activities. Run-time V&V is pursued both through testing and monitoring, and can concern both functional and non-functional aspects. We remark that we distinguish between on-line testing, that actively launches test cases and observes outcomes, from monitoring, that passively observes how the services spontaneously interact. 3) the package V&V Enabling Components collects those components implementing methods and notations that support the above activities, including test case generation and non-functional requirements specification. For each package we have developed new approaches or adapted existing ones, as described in the rest of this document. It is worth noting that however the above conceptual architecture is completely generic and can be extended by including different approaches and policies. For example, the Run-time testing infrastructure component currently applies a model-based testing strategy, but other different strategies could be used without affecting the framework.

Figure 1.1: Conceptual Overview of CHOReOS Governance and V&V Framework

1.2. WP4 highlights In this section we summarise the main results of WP4 so far, that are further documented in the next chapters. We highlight below the innovative contributions we propose for governance and V&V, specifically conceived to tackle the challenges posed in the CHOReOS context: - Rehearsal, an integrated framework supporting the automated testing of choreographies by the choreography developer. Rehearsal supports choreography testing along the entire choreography development process: the choreography elements can be manipulated as Java Objects and web service operations can be invoked dynamically. The framework also provides mechanisms

CHOReOS FP7-257178

2

for simulating web services or invoking them in their real environments, and the Scalability Explorer component that assists in checking how a choreography can scale up according to defined performance metrics. - Q4BPMN, a UML profile for specifying non-functional constraints by directly annotating the BPMN specification of a choreography; we have also produced some instruments to perform QoS analysis from the Q4BPMN annotations. - A Resource Life Cycle Manager for the publication and discovery of heterogeneous resources such as services, SLAs, and choreographies. This is an extensible registry which is based on event-based loosely coupled links, thus reducing the impact of their interactions, which is valuable in a ULS approach. The registry is synchronized with the run-time middleware which enables to control the resources lifecycle from design to run-time, also thanks to the synchronization with the monitoring framework. - ServicePot, an enhanced registry supporting the on-line testing of choreographies. It expands a traditional service registry by logging the information needed to test whether a service is conforming to play a specified role within a choreography (as done by our ParTes tool). Both ServicePot and the Resource Life Cycle Manager are part of a common whole Governance registry that by means of a plugin mechanism populates the Abstraction Oriented Service Base Management (See Deliverable D3.2.2 [13]). - ParTes, an original test approach for detecting potential mismatches between the actual behaviour of participant services involved in a choreography and their expected role in the choreography specification. - CRank, a mechanism for rating services and choreographies. This information is instrumental to WP4 governance policies. - A Multi-source Monitoring Framework, which combines different levels of run-time information into complex events meaningful at the application level. It can correlate the messages passed at business-service level with lower-level observations relative to the infrastructure resources.

1.3. Document structure This deliverable is organized as follows: Chapter 2 presents Development-time Analysis and Testing approaches, including updates on Rehearsal framework and its Scalability Explorer component, and as a novel contribution that was not included in D4.2.1 the specification of the Q4BPMN profile. Chapter 3 focuses on Run-time testing of choreographies, including enhanced versions of the Resource Life Cycle registry, ServicePot registry, ParTes tool and CRank framework. Chapter 4 reports the refined version of the CHOReOS Multi-source Monitoring Framework. In Chapter 5 we perform a preliminary qualitative assessment of the application of WP4 tools to one of the CHOReOS scenarios, specifically the ACRB use case of WP7. Finally, conclusions and directions of work in the next year are briefly discussed in Chapter 6. The appendix includes as further documentation the results of an empirical evaluation of the presented Rehearsal framework (Appendix A), and the API for the released tools (Appendices B to E).

CHOReOS FP7-257178

3

CHOReOS FP7-257178

4

2 Development-Time Analysis and Testing Although the main emphasis and novelty of WP4 framework relies on the establishment of governance and V&V approaches at run-time that can address dynamic service compositions, it is also important to provide the choreography developer with means to test and validate their specified choreographies all along their development cycle. In particular, this chapter contains: • A brief summary of the Rehearsal framework we have developed for design-time testing of choreography, in particular adapting a Test-Driven approach to the scenario of ULS choreography development. A more detailed description was previously given in Deliverable D4.2.1. We have also performed an empirical assessment of Rehearsal that is reported in Appendix A. • A detailed description of the Scalability Explorer component that implements the scalability testing strategy we previously outlined in D4.2.1. • An original model-driven approach to specification of non-functional requirements for choreographies, that consists of a UML profile defined on top of the standard BPMN2.0 specification. The proposed notation is called Q4BPMN. We plan to integrate such notation into the CHOReOS modelling and development process, as we describe in Deliverable D2.2.

2.1. Rehearsal framework for correctness and scalability testing Rehearsal is a testing framework that supports Test-Driven Development (TDD) of choreographies. It has already been described in Deliverable D4.2.1 [16]. Progress has been made in two fronts: first, we performed an exploratory study around the tool and its application in TDD; second, improvements have been made to the Scalability Explorer component. Except for the Scalability Explorer, Rehearsal is considered finished by its authors in the context of the CHOReOS project. However, an adapter must still be created to allow rehearsal to extract information from the Synthesis Processor, as that component is not finished yet. All software components used by Rehearsal are open-source and the framework is available under the GNU LGPL license. Rehearsal provides features for correctness tests – supporting unit, acceptance and integration tests – as well as scalability tests. Unit and acceptance tests can be applied by using the dynamic web service client generator. Features for mocking web services and intercepting messages are provided to support integration tests. As for scalability tests, Rehearsal includes facilities to build and automate their execution. We present Rehearsal’s key contributions – comparing with other existing tools – and the current status of the Scalability Explorer and the issues concerning with ULS dimensions below. The exploratory study is described in Appendix A.

2.1.1. Contributions Rehearsal’s main goal is to facilitate TDD adoption in choreography development. Keeping this in mind, a prototype [19, 18] has been developed to understand the choreography testing strategies deeply. This

CHOReOS FP7-257178

5

Identifier R1 R2 R3 R4 R5 R6 R7 R8 R9

Requeriment description Create clients to invoke operations of Soap web services Create clients to interact with REST service resources Allow test case writing for services that do not have contracts (interfaces) defined Intercept (at the development environment) messages exchanged among the services of a composition Emulate (mock) web services Configure a timeout when invoking a web service operation Provide objects that represent the choreography elements Validate the contract (roles) of choreography services Provide features that are not coupled to specifics choreography and orchestration technologies, languages, or tools

Table 2.1: Rehearsal requirements prototype consisted on: (a) ad hoc bash scripts to implement a choreography; (b) JUnit1 test cases and (c) a console that allows the user to execute the scripts and the test cases. Based on the experience and results achieved with this prototype, we derived the requirements that Rehearsal should meet. Table 2.1 presents these requirements. Table 2.2 shows which of the requirements are covered by other existing tools. As can be observed, none of the analyzed tools cover all of the defined requirements. In particular, one can notice that SoapUI, an internal Rehearsal dependency, is the tool that covers the most of them. Apart from the compliance testing approach [30], all tools focused on choreography testing are coupled to a specific technology, tool or choreography language. Beyond that, in spite of all tools covering the requirement R4 (message intercepting), only the ValiBPEL-Web and BPELUnit intercept real messages of the choreography. In the other tools, the interception and validation occur in a message exchange simulation. The Rehearsal features cover all the defined requirements. R1

R2

R3

R4

R5

R6

•

•

R7

R8

R9

•

• • • • • • • •

Testing of atomic web services •

SoapUI [27] TTR [20] WS-TAXI [10] wsrbench [33] SOCT [9] BISTWS [25] (role)CAST [14] Mobile-agent framework [43]

• •

•

• • • • • •

• • • • • •

Testing of choreographies PI4SOA [39] CDLChecker [42] Compliance testing approach [30] ValiBPEL-Web [26] BPELUnit [35] Online testing framework [29]

•

• • • • • •

• •

• • • • • •

•

Table 2.2: Requirements covered by the related works

2.1.2. Scalability Explorer Rehearsal provides the Scalability Explorer component to assist the developer in verifying the choreography scalability characteristics for future improvements. Figure 2.1 presents its architecture. The developer must apply the following steps to assess a system scalability: 1

JUnit: http://www.junit.org

CHOReOS FP7-257178

6

Figure 2.1: Scalability Explorer Architecture

Figure 2.2: Scalability Test Chart 1) Choose the variables that define the problem complexity (e.g., number of requests per second), the performance metric (e.g., average response time), and the software architecture (e.g., number of nodes of a role). 2) Define the functions of the complexity size of the problem, performance metric, and the architecture capability. 3) Choose initial values for these variables. 4) Execute the application with these initial values for obtaining the initial value of the performance metric. 5) Execute multiple times with the same process and collect the performance metric for each execution. 6) Analyze the performance metric. In steps 1 to 3, the developer writes the test supported by the Scalability Explorer. In order to automate steps 4 and 5, a ScalabilityTestItem must be implemented, so that a ScalabilityTest can execute CHOReOS FP7-257178

7

Figure 2.3: Execution Flow of ScalabilityTester its test(Number...) method multiple times, increasing the parameter values according to a ScalabilityFunction. The framework also includes facilities such as LoadGenerator and AggregationFunction to support test writing. In step 6, a chart may be generated (Figure 2.2), so that the developer can analyze the test results. The Scalability Explorer contains ScalabilityTester, an abstract class that encapsulates a common scalability test. It implements ScalabilityTestItem and uses a LoadGenerator and an AggregationFunction. It assumes the problem complexity is the number of requests per minute, the relevant architecture dimension is the quantity of instances of some resource and the performance is measured as the response time, in milliseconds. When extending a ScalabilityTester, the programmer may override some methods to define the behavior of the test at specific points. They are: • setup(), called at the beginning of the test; • resourceScaling(), called after each scaling, so that the programmer can adjust the test to the values; • test(), which is the actual code to be measured; • beforeTest(), called before every test() execution; • tearDown(), called at the end of the test. Additionally, ScalabiltyTester can be configured with the initial number of requests per second and resource quantity, a measurement limit to interrupt the tests, the number of tests to be executed and the number of request made in each test. In the default implementation, the tester linearly increases the quantity of resources and requests per minute. The executions also follow a uniform distribution over time, and the value obtained in each battery is the mean of the executions results. But other types CHOReOS FP7-257178

8

of ScalabilityFunction, LoadGenerator and AggregationFunction can be set, too. The execution flow of the run() method is presented in Figure 2.3. The run() method can be called many times (e.g. with different configurations) and its argument is used to identify the results of each specific execution in a chart presented when showChart is called.

2.1.3. Rehearsal Scalability Dimensions, Issues, and Strategies The Rehearsal Framework has two facets: it includes functionalities for correctness tests, as well as scalability tests. The functionalities for correctness test will mostly not be used in a Ultra-Large-Scale (ULS) scenario. Nevertheless, in some cases it may be desired to perform integration tests involving a higher amount of services. On the other hand, the Scalability Explorer can be more commonly used in ULS scenarios, to validate if a choreography can handle a large frequency of messages. Table 2.3 summarizes how Rehearsal relates to these scalability dimensions. ULS Dimension Number of different kinds of services in a single choreography

Frequency of messages (requests, operations or transactions) exchanged by the services in time period

Consideration about Rehearsal It must be possible to generate mocks and message interceptors for the number of different kinds of available services in the choreography. We must assess the maximum number of instances (mocks and interceptors) that Rehearsal can handle in the developer machine. Due to the restriction that Rehearsal can only deploy these services (mock and interceptor) locally, the machine on which these tests are performed must have enough memory to support it. However, they were developed to be light. This aspect may also be constrained by the number of TCP ports the user can open simultaneously. It must be possible to generate ULS frequency of messages in order to support testing this dimension. Currently, the framework includes only the UniformLoadGenerator, which distributes the messages uniformly over time and supports high frequencies as long as the time required to send the message is shorter than the required delay between two consecutive messages. We notice that this component is non-blocking, thus the required time does not add up with the response time.

Table 2.3: ULS dimensions and Rehearsal

2.2. Non-functional Annotation and Analysis of Choreographies Quality requirements are a relevant part in the specification of service choreographies. However, the BPMN specification from the OMG [37] does not provide means of expressing non-functional requirements. For this reason, in CHOReOS we have carried out an effort to let the domain expert introduce quality requirements directly in BPMN service choreographies. The result is Q4BPMN [7]: a natural way of extending the BPMN functionalities to allow the choreography designer to introduce non-functional requirements. Q4BPMN is a generic methodology, which so far has been implemented into MagicDraw as a UML profile, exploiting the current MagicDraw implementation of BPMN service choreographies as a profile of UML activity diagrams. The choice to implement Q4BPMN as a UML profile is a practical one, which avoids the need of creating an actual extension to the BPMN specification, but does not represent a loss of generality against a different implementation. Q4BPMN is not a language for expressing the quality requirements, but rather provides a placeholder CHOReOS FP7-257178

9

within the BPMN diagrams for expressing the specific quality requirement into some specific language. Specifically, Q4BPMN implements the concepts defined by PMM [23] as a UML profile. The main concepts of the Q4BPMN profile are illustrated in Figure 2.4.

Figure 2.4: General Overview of the Q4BPMN Profile Although the non-functional annotations are already useful by themselves (helping the service providers meet the choreography requirements elicited by the choreography designer), their full potential is expressed when they are toolchained in a set of operations. In particular, the Dynamic Development Process of CHOReOS presented in Deliverable D2.2 [3] exploits them in order to perform automated analyses and monitoring of the choreography. Figure 2.5 summarizes the steps envisioned in D2.2 [3] showing the application of a toolchain to the QoS-annotated BPMN model. Summarising, the multi-step process (spanning both design-time and run-time steps) includes: 1) initially, the choreography designer must create the BPMN model of the service coreography introducing annotations of non-functional requirements. This is described in full detail in [8]. The non-functional requirements can be directly transformed into rules for service monitoring; these rules can then be fed to a QoS service monitoring system to watch over the respect of the agreements expressed in the non-functional requirements; 2) the annotated service choreography must undergo a transformation to a pivot model called KLAPER [28]. A tool is capable of transforming the annotated BPMN service choreography to a KLAPER model, and the KLAPER model into a set of other models useful for various types of analyses. The output models can thus be easily fed to the most appropriate tools performing the desired performance analyses; 3) the KLAPER suite, combined with the analysis tools, checks the feasibility of the service choreCHOReOS FP7-257178

10

Figure 2.5: Analysis and Monitoring Toolchain for Annotated BPMN Models ography as a whole with respect to the non-functional requirements. The purpose of this stage of the analysis is to detect incompatibilies between different non-functional requirements, or even between non-functional requirements of the same type annotated on different choreography tasks. Full details on this methodology is described in [7]; 4) the analysis tools can be used not only to check the coherence of the non-functional requirements expressed in service level agreements, but also to derive constraints that were not expressed but can be partly or totally inferred from the others. This technique can be used to generate additional rules to be fed to the service monitor. This methodology is currently under implementation.

2.2.1. Q4BPMN Scalability Dimensions, Issues, and Strategies The Q4BPMN approach fits well into a scaling ULS environment, but additional care and effort is needed. It is assumed that the non-functional requirements are not created in the Q4BPMN approach; rather, the approach only requires converting existing non-functional requirements into a PMM format and annotating them on the model of the service choreography. The main issue is therefore the conversion, but this process can be automated. If the requirements are specified in a formal non-functional requirement language, or an MDE technique, a transformation script or model transformation tool can be applied to automatically introduce the annotations into the service choreography model. In other words, the first step of the Q4BPMN approach could be a major manual effort when the service choreography grows to a ULS environment, but with an automatic transformation no difference should emerge in scaling. The second step again has no difficulty in scaling. There is already a tool for transforming the nonfunctional requirements from the Q4BPMN format into the KLAPER pivot model, and again from the latter to the formats supported by the various analysis tools. This transformation is immediate (the computation time may be a bit longer, but it is only a translation), independently of the size of the service choreography. The third step does not change qualitatively, but it does change quantitatively. Some computations need to be performed to check the compatibility of different non-functional requirements, and in a ULS environment this might be intensive. However, since all the computation is carried out prior to the deployment of the service choreography, it just lengthens the deployment time and does not affect the CHOReOS FP7-257178

11

QoS at run-time. The last step changes significantly. As the choreography scales towards a ULS environment, more non-functional requirements will be expressed, but many others will be omitted as well. So the number of implicit non-functional requirements will tend to grow exponentially as there are more constraints which are not expressed in SLAs. This has several consequences: • the computation can become much more intensive, since an exponentially-growing number of possible combinations of explicit non-functional requirements must be accounted for to compute the implicit ones; • the precision of the implicit non-functional requirements will be more and more approximate. The “gray areas” left by the unexpressed non-functional requirements will increase, thus making the overall run-time execution of the service choreography less predictable; • for the same reason, the number of possible warning rules generated by the tool will increase strongly, probably giving way to a large number of redundant warnings, and it would be hard for the service monitor to separate the useful ones from those that should be omitted. Table 2.4 summarizes the estimated effects of each aspect of scalability on the efficiency of Q4BPMN.

CHOReOS FP7-257178

12

ULS Dimension Number of different kind of available services

Number of different kind of services in a single choreography

Number of service consumer instances in a single choreography (i.e., for a given kind of service consumer, we may have a UL number of instances) Frequency of messages (requests, operations or transactions) exchanged by the services in time period Number of atomic services (actuators and sensors) aggregated in services Change of the above dimensions over time

Consideration about Q4BPMN This dimension represents the amplitude of the scale of the whole ULS system and affects the amount and value of nonfunctional requirements involved. However, it does not involve the processing of those requirements, which would be carried out independently of their values. The increase in the number of services has a major effect on the number of non-functional requirements of different classes expressed in the service choreography. A very large scale along this dimension would make implicit non-functional requirements and service monitoring rules much more complex and approximate. Since the Q4BPMN methodology is not affected by consumers invoking the services choreography, the approach can be applied independently of the growth of consumers.

Q4BPMN does not involve the communication among services (apart from the constraints that can be expressed related to them), so this dimension is not an issue. This dimension is not an issue for the Q4BPMN methodology, since only the non-functional requirements expressed in those services are accounted for. Although the Q4BPMN methodology in itself does not change when the service choreography is reconfigured, still it needs to be run all over again, with possible effects on performance, especially in a ULS environment. Also, during the transition phase, some warnings which are not significant anymore might be issued by the service monitor, and others might be missed because they are in the process of being formulated. An extensive study on the dynamic evolution of the service choreography subject to the Q4BPMN methodology has not been faced as of yet.

Table 2.4: ULS dimensions and Q4BPMN

CHOReOS FP7-257178

13

CHOReOS FP7-257178

14

3 Run-Time Testing The goal of this chapter is to show the various components and subsuming strategies that the CHOReOS project has developed with respect to run-time verification activities. The various components have been already sketched in the previous deliverable D4.2.1 [16], with respect to which workpackage partners have progressed in several directions. In particular this chapter contains: • A clearer and more detailed view on resource lifecycle management • A detailed description of the different elements composing the Run-time infrastructure for verification and testing. • A detailed description of the plug-in infrastructure for the ServicePot component • A new version of the test case derivation algorithm with better performances • For each proposed approach, a description of the strategies to address the scalability dimensions. This is particularly important with respect to the general CHOReOS objectives.

3.1. General Architecture of the V&V Framework

Figure 3.1: General Architecture of the V&V Framework

CHOReOS FP7-257178

15

This component diagram reports the elements composing the run-time V&V infrastructure. Through the interaction of the various components, the CHOReOS infrastructure supports both run-time governance of choreographies and services and the launch of a on-line testing sessions to check the behavior of services with respect to the specification of choreographies in which they can play a role. Here we give a brief overview of each component whereas in the following sections we give details on the various components that have been specifically developed within Workpackage 4.

3.1.1. Choreography Participant Testing Strategy This component provides the implementation of a test derivation strategy permitting to automatically derive test suites from a choreography specification. Derived test suites are specifically targeted to test the behavior of a service with respect to a role defined in the choreography. In Section 3.4 this component is described with an high level of detail.

3.1.2. CHOReOS Middleware This component represents the CHOReOS Middleware which enables the various elements to interact. The CHOReOS middleware is developed within Workpackage 3.

3.1.3. Complex Event Processor The CEP is the rule engine which analyzes the primitive events, generated by the middleware, to infer complex events matching the monitoring requests. Specifically, the CEP would implement a notification mechanism following the publish/subscribe paradigm on a monitoring bus (which is part of the middleware). Also, it orchestrates both the sources of events (i.e. probes), and the consumers of the notifications. Specifically it can both register probes, and fetch monitoring requests coming from consumers, Then, it can analyze complex events, and notifies the proper consumer on a dedicated channel of the monitoring bus. This component is plays an important role with respect to monitoring activities and will be further detailed in the next Chapter.

3.1.4. Governance Registry The governance registry provides functionalities to handle the life-cycle of service and choreography artifacts. In particular this component will permit to store/retrieve/remove/update choreographies and service descriptions. At the same time the governance registry cooperates with the run-time testing infrastructure to apply the V&V policies established in the federation. A reference implementation of this component with respect to lifecycle management is described in Section 3.2 whereas ServicePot, that is described in Section 3.3 and whose architecture is presented in Figure 3.2, provides on-line testing capabilities. The Governance Registry is deployed within the CHOReOS infrastructure as part of the XSD component, as illustrate also in Figure 1.1 of Deliverable 3.2.2

3.1.5. Mocks Factory This component is not yet implemented and is planned for future releases. The Mocks factory should permit to automatically generate proxies for real services to be used for testing purpose. The idea foresees that the registry returns proxies services during testing sessions so to have a better level of observability over the services involved. In fact the proxies services log and report all the invocations made by the service under tests or successive analysis.

CHOReOS FP7-257178

16

Figure 3.2: Governance Registry Implementation

3.1.6. Policy Repository This component stores policies for V&V activities. In particular such policies take into account the evaluation of both the Governance Registry, and the CRank component. This repository will mainly store policies according to the following classification: • V&V Activation Policies; • V&V Rating Policies; • V&V Ranking Policies; • Choreography Enactment Policies; • Test Cases Selection Policies.

3.1.7. Q4BPNM This component models Q4BPMN. For a detailed description of this component we refer to Section 2.2 and to Deliverable D2.2 [3].

3.1.8. ReputationRanking Reputation systems based on feedbacks provide a widely adopted solution in order to share subjective evaluation of a service after the direct experience of its users. This component implements a reputation system for services/choreographies based on user’s feedback. Its features are described both in D4.1 [15] and D4.2.1 [16], and in other documents such as [17]. CHOReOS FP7-257178

17

The component is implemented by means of the class ReputationBasedRanking, for which a detailed description can be found in Section 3.5, and a prototype implementation is released as a service at : http://atlantis.isti.cnr.it:8080/axis2/services/CRankReputationService

3.1.9. ServicePostboard This component collects service feedbacks from their users. The collection of feedbacks stored in this component is used by the component ReputationRanking in order to compute both choreography, and service ranking based on a subjective reputation model. A prototype implementation of this component is implemented by means of the class PostboardReader, for which a detailed description can be found in Section 3.5. In particular, this prototype computes the Reputation cores by reading users’ feedbacks expressed as RSS on a given bulletin board (i.e. the Postboard service available at http://atlantis.isti.cnr.it:8080/virtualNoticeBoard/ postboard).

3.1.10. Test Driver This component permits to start a testing session. A testing session is started as a consequence of specific events such as the registration of a new service. To start a testing session the driver receives the end point to test and the role within a choreography with respect to which it is necessary to test. The test cases are retrieved from the test suite repository specifying the choreography and the role the service would like to play. After the test suite has been executed, the driver reports to the governance registry the result of the test indicating possible positive test results. This component is part of the run-time testing infrastrastructure presented in Section 3.4.

3.1.11. Test Reporter Component The results for each test session are collected by this component. In addition, according with the overall registration procedure supported by ServicePot (as anticipated in D4.2.1 [16]), the results of the on-line testing sessions can be exploited in order to determine what service is trustable according to an objective estimation (i.e. test passed VS. test failed). To this end, this component publishes the results of the test cases that ServicePot runs. This means that the other compoments of the V&V Governance Framework in CHOReOS can be notified of unreliable service behaviours playing in some choreography. This component is part of the run-time testing infrastrastructure presented in Section 3.4

3.1.12. Test Suite Repository This component permits to store and retrieve test suites. Test suites are automatically generated and stored when a new choreography is registered. At the same time they can be generated off-line and manually stored. Test suites are retrieved by a test driver when it needs to test a service. This component is part of the run-time testing infrastrastructure presented in Section 3.4

3.1.13. TestingRanking This component provides a specific implementation of the ranking based on the results of on-line testing session (i.e. based on the number of tests passed VS. the number of tests failed). Its features are described in D4.1 [15], D4.2.1 [16], and in other documents such as [17]. The component is implemented by means of the class TestingBasedRanking, for which a detailed description can be found in Section 3.5, and a prototype implementation is released as a service at : http://atlantis.isti.cnr.it:8080/axis2/services/CRankTestingService CHOReOS FP7-257178

18

This component collects the results of the launched testing session by interacting with the Test Reporter Component.

3.2. Resource Lifecycle In the ULS systems of the FI, we deal with several types of resources that are discovered continuously. These resources can refer to services, but also to processes, choreographies, users, contracts, etc. In D4.2.1 [16], we have classified the resources that interest the CHOReOS system and defined the architecture for their management. To ensure the creation, discovery, publication and retrieval of heterogeneous resources, in CHOReOS we are developing an extensible resource management tool. This work goes in the same direction as the CHOReOS Middleware for discovery developed in WP3 (we refer specifically to the XSD reported in Deliverable D3.2.2 [13]) and also as the tool ServicePot presented in this deliverable. Indeed, ServicePot provides a UDDI-based service discovery that is more focused on the testing capabilities of services to involve within the choreographies. In contrast, the Resource Life cycle management tool hereby described aims at providing an extensible governance registry that enables the integration with the run-time environment, and more precisely, with the CHOReOS Middleware (Extensible Service Access- EasyESB) that runs the services and the choreographies. The integration within the XSD middleware is realized thanks to a plugin mechanism through which a common registry will be populated.

3.2.1. Resources At run-time and within the CHOReOS context, the CHOReOS middleware and specifically the EasyESB (XSA) handle many types of resources. These resources are relevant at both design and run-times for enabling the governance activities. A first classification of these resources is described in D4.2.1, here we refine it and provide a set of resources of different types: Services, Interfaces, Endpoints, Choreographies, SLA, Roles, and Policies. Its noteworthy to mention that within WP3 activities and more precisely the Extensible Service Discovery middleware an abstractions classification is also provided. It considers the abstractions relevant for the discovery of services and adaptation of the choreographies at run-time. Both classifications have in common the modeling of the services and provided interfaces. Therefore, in the Abstraction Oriented Management Base, we go further in this classification and enrich it with additional non functional abstractions useful for the substitution of the services within a choreography. While, in the governance resource registry presented hereafter, we give a high level representation that is meant for modeling middleware and run-time abstractions, such as the EndpointResourceType, which a representation of the address of a service in the ESB. We present in the class diagram of Figure 3.3, the resource type classification that we consider to realize the governance activities at both design and run-time. The AbstractResourceType refers to the abstract type of the resources that are handled within the registry. This abstract class inherits from the ResourceType interface that provides the common functionalities between all resources. The AbstractResourceType can be instantiated into several resources, such as Services, SLA, Choreographies, Endpoints, Interfaces, Roles, etc. The Services, Endpoints and Interfaces resources are already implemented, the remaining resources are scheduled for the next governance framework delivery. In addition to their specific functionality, all resource type classes have the following functions: getInstance() getTypeName() The ResourceType Class is the common parent of all the resources. We model the resources considering the ResourceType Interface and the AbstractResourceType in order to enable and ease extensibility of the resources when needed. According to the different resource types, the AbstractResourceType CHOReOS FP7-257178

19

Figure 3.3: Resources could be refined into: ChoreographyResourceType, EndpointResourceType, InterfaceResourceType, PolicyResourceType, RoleResourceType, ServiceResourceType, and SLAResourceType.

3.2.2. Managers The Managers components are responsible for handling the resources, for each resource type there is a dedicated manager. In the following diagram (Figure 3.4) we only sketch the ServiceResourceTypeManager as well as the components interacting with the managers.

Figure 3.4: Managers

ResourceAnalyzerManagerImpl The ResourceAnalyzerManagerImpl implements the ResourceAnalyzerManager functionality. This component eases the publication and retrieval of resources into the registry thanks to the analyze function that is implemented. The latter parses the resources descriptions and classifies each of the fields such as the names, interfaces, etc. in order to ease the storage and indexation of the resources. CHOReOS FP7-257178

20

ResourceAnalyzerManager The ResourceAnalyzerManager is the interface that exposes functionalities for resources analysis. It is implemented thanks to the ResourceAnalyzerManagerImpl presented above. The functions provided by the ResourcesAnalyzerManager are the following: ResourceAnalyzerManager() addResourceAnalyzerService(AbstractResourceAnalyzerService) analyse ( Document : Map : ) clear() getAllResourceType () get( QName, ResourceType ) : Resource() findResourceType (String) addResourceAnalyzerService (AbstractResourceAnalyzerService) ResourcesManager The ResourcesManager is the interface providing functions for creating, retrieving, or removing resources. It is implemented thanks to the ResourcesManagerImpl. The functions provided by the ResourcesManager are the following: ResourcesManager (Configuration get (Get ) detectSyntaxSimilarity (String : String : ) remove(Remove) () publish (Document : Map : ) getAllByResourceType (ResourceType ) addResourceAnalyzerService (AbstractResourceAnalyzerService) findResourceType (String : ) ResourceType getAllResourceType ( ) : List analyse (Document : Map : ) List remove (QName : ResourceType : ) Resource clear ( ) void store ( Resource : ) getNumberOfResources ()

ResourcesManagerImpl The ResourcesManagerImpl is the class providing the business implementation of the ResourcesManager component. It is a relevant and important component in the governance framework as it ensures the life cycle management of the resources. Managed resources are either services, choreographies, service level agreements, policies, interfaces, endpoints, etc. The framework is modeled to be extensible to support new models. The management functionality is mainly concentrated on the discovery and publication of resources. Consequently, we have implemented the publish, find and remove functions with several parameters, for instance, we can publish a resource given its legacy description. Moreover, a resource can be retrieved or removed thanks to its name. Additional analysis functions are implemented in order to ease the indexing of the resources within the registry. Finally, the resources can be stored into a given storage device. Given a run-time platform, the Resource Manager is able to retrieve all the resources that are running on this platform thanks to the getAllResourceType functionality. The ResourcesManagerImpl component is described in the Resources class diagram that specializes the resources manager according to CHOReOS FP7-257178

21

the concerned resource. ServicesManager The Services Manager is the interface that enables retrieving services, interfaces and endpoints, it exposes the functionality detailed in the ServicesManagerImpl. ServicesManager (ResourcesManager ) findEndpoints (String ) findInterfaces (String) findServices (String ) getEndpoint (QName ) getInterface (QName ) : getService (QName) publishWSDL (PublishWSDL ) ServicesManagerImpl The ServicesManagerImpl is the class that implements the Service Manager and that is responsible for dealing with the services life cycle. Providing the name of a service, the manager ensures retrieving all the corresponding services as well as their interfaces and endpoints. The same functionality is also provided for the Interfaces and the Endpoints of a given run-time context that was initially added thanks to the Connection and Configuration components. It is also able to publish a service legacy respecting the Web Service Description Languague. The ServicesManagerImpl manages services that respect the ServiceResourceType model detailed in the Resources diagram. StorageService The storage service is the interface that provides resource storage functionality, it is implemented thanks to the StorageServiceImpl class. clear() find(String, ResourceType) get(QName, ResourceType) getAllByResourceType(ResourceType) getNumberOfResources() store(Resource) unstore(QName, ResourceType) StorageServiceImpl The StorageServiceImpl is responsible for storing a resource to an indicated storage device. It enables the resources storage as well as the unstorage. The retrieval of a stored resource is also ensured.

3.2.3. Core Resource Registry The Core Resource Registry represents the core of the resource life cycle management framework. It relies on the core manager that is the aggregation of an entity dealing with the configurations concerns (Configuration), a Connection Manager that ensures the bridge with the run-time context; and finally the ResourcesManager that deals with heterogeneous resources.

CHOReOS FP7-257178

22

Figure 3.5: CoreManager Configuration The Configuration component configures the connected nodes and informs about the port that will produce the notifications. getHost ( ) getNotificationPort ( )

ConnectionManager The Connection Manager is the component that is responsible for connecting the governance framework to the CHOReOS middleware and more precisely to the Enterprise Service Bus (EasyESB). The latter is responsible for exposing the services that will be involved in the choreographies and enabling their enactment. Synchronizing the governance registry with the run-time infrastructure enables the registry to have the knowledge of all the resources at both design and run-time. clear ( ): : shutDown ( ): : init ( ): : getInstance ( ): :

CoreManager The CoreManager component represents the aggregation point of the resource life cycle framework. It is composed of the following components:

CHOReOS FP7-257178

23

• a Logger component that stores all information about the run-time context. • a Configuration component that enables the awareness of the surrounding run-time hosts. • a ConnectionManager component that provides capabilities for connecting the framework to the chosen host. • a ResourceManagerImpl that is the class implementing the Resource Manager and provides functionalities for dealing with the life cycle of each resource. CoreManagerImpl(Configuration) getResourcesManager clear () getConfiguration () setConfiguration(Configuration) getConnexionManager ()

Logger The Logger component is responsible for logging all the messages concerning the governed resources.

3.2.4. Resource Lifecycle Scalability Dimensions, Issues, and Strategies Table 4.2 lists the ULS challenges that the resource registry needs to address as well as the envisaged solutions that we implement to achieve this.

3.3. ServicePot This section describes the reference architecture of ServicePot. The framework relies on an increased information model of a classical service registry. In particular, ServicePot enables the storage and the retrieval of choreography specifications. It assumes that a service willing to be indexed in the registry specifies which roles it is able to play within one or more choreographies. Obviously, more advanced techniques can be used to match services with roles (see for instance [5]). In this first implementation we decided to take the simplest path; nevertheless more complex functionality can be implemented as extensions to the basic one. Therefore the implementation we are considering is somehow limited by the following characteristics: • it provides an API that permits to directly associate a role to a service implementation. • indexing of choreographies does not use any grouping technique and lookup mechanisms are mainly based on those provided by the UDDI implementation. Both limitations can be addressed thanks to the ServicePot extension mechanism described in the following sections. In particular it is possible to include mechanisms for dynamic and automatic mapping of services to roles and complex indexing functionality possibly using metadata structures. Figure 3.6 depicts the overall architecture of ServicePot, which is described in detail below. ServicePot ServicePot is a UDDI compliant SOA Registry, enhanced with additional information to store Web Service Choeographies. ServicePot was first introduced in D4.2.1 [16] as a tool to enable run-time Verification and Validation of Web Services and Choreographies. UDDI Registry At its core, ServicePot is based on a UDDIv3 registry CHOReOS FP7-257178

24

ULS Dimension 1. Heterogeneity of resources

2. Number of Resources

3. Number of run-time services

4. Frequency and time response for the resources discovery

Consideration about the Resource Registry This dimension represents the number of governed resources discovered in the ULS System. We classify these resources as Services, Interfaces, Endpoints, Choreographies, SLAs, Roles, and Policies. We rely on an extensible multi level modeling approach including abstract classes and interfaces able to generate instances of each resources when needed. The specificity of each resource is considered while common criteria are gathered into a main ResourceType. The resources need to be stored for publication and discovery; in ULS Systems an important number of resources may be discovered. In order to address possible issues, we implement a storage mechanism that classifies and stores the resources based on their types. Further study needs to be done in order to find ways of exploiting the cloud storage mechanisms for instance. The resource registry is synchronized with the CHOReOS runtime distributed middleware which is an enterprise service bus (EasyESB). The latter is distributed over several nodes and is deployed on top of large cloud infrastructure. The resource registry is able to collect all the resources that are running on top of the middleware and exposes them in the registry. This synchronization is valuable as it enables exploiting the runtime evolution of managed resources. Considering an important amount of governed resources, we adopt an analysis mechanism that parses the resources schemas and eases the retrieval and discovery of services. We believe this is a valuable functionality that faces the large scale challenges, mainly with respect to the lookup functions of resources.

Table 3.1: ULS dimensions and Resource Life Cycle Framework UDDI Proxy ServicePot contains a proxy for that UDDI registry that would actually store the data. This proxy receives standard calls from external callers and forwards it to the UDDI Registry ChorDDI ServicePot provides primitives for publishing a service choreography: store and drop a choreography; attach and drop a specific role to a specific service (i.e. participant of a choreography). Furthermore, it also exposes primitives for inquiring the registry looking for choreographies, roles in a choreography, or participants (i.e. services) that can play a specific role within a choreography. All this functionality is provided by the component ChorDDI. Governance Pool As Service Oriented Architectures are inherently fluid and subject to change, we anticipate that new requirements will emerge in response to those changes. To allow handling all such requirements, we need to make ServicePot extensible. The motivation behind Governance Pool is the need to implement such extensibility. At the core of Governance Pool is an OSGi framework implementation [38]. Governance Pool features the architecture by supporting configurable extensions that can enforce governance activities over the life-cycle of the registered items. For instance, The augmented registration process described in D4.2.1 can be implemented using an extension that intercepts the convenCHOReOS FP7-257178

25

Figure 3.6: ServicePot: High Level Architecture tional service registration procedure. ServicePot uses an event-driven architecture for extensibility. It raises events on both entering and exiting each operation of its exposed API. Extension to the ServicePot functionality can be done by listening and responding to these events. ServicePot provides events for all invocations on the UDDI Proxy and the ChorDDi components. To allow event handling and enumeration of the event listeners, GovernancePool also includes interface definitions for all the events raised by ServicePot. ServicePot events can be handled by importing and implementing the interfaces for event handlers provided by GovernancePool. Later, the extension handling the events can register with the bundled OSGi implementation. To raise an event, ServicePot looks up from the GovernancePool all the extensions registered as event handler of the currently executing method. It then calls all the event handlers sequentially, passing the data received as input, or the processed data about to be returned to the ServicePot caller. This puts a constraint on the ServicePot extensions to provided the PluginInterface required by ServicePot and to register with Governance Pool Using GovernancePool, we have supported a number of plugins that perform important governance functions. for example, the Partes Plugin invokes the ParTes component to perform conformance tests of choreography participants, CRank Plugin uses the CRank component to rank the services. An extensibility plugin provides support for distributed partitioning of the registry. Abstract Plugin Servicepot Plugins import and implement the event handler interfaces exported by GovernancePool . These events are raised during UDDI and ChorDDI operations, GovernancePool maintains a collection of registered plugins, and the registered plugins are retrieved and invoked for each event. Choreography storage and retrieval ChorDDI is the component responsible for Storage and retrieval of Choreographies. UDDIv3 does not natively support the storage of Web Service Choreographies. However it does allow expression of new concepts using an Object called TModel. We use TModels to store information about choreographies CHOReOS FP7-257178

26

Figure 3.7: ServicePot: Mapping of BPMN2 concepts to UDDI and the roles in the choreographies. Figure C.1 shows this mapping between BPMN 2.0 concepts and UDDI concepts The overall structure of ChorDDI is expressed in Figure C.2 and it is explained in Apendix C: Extensibility in ServicePot As discussed above, GovernancePool is the component providing extensibility for servicepot. The various interfaces and events available to ServicePot plugins are expressed in Figure C.3. The datailed description of these APIs are given in Appendix C. Notice that in the figure, most UDDI events are hidden for simplicity. Only one pair of UDDI events is shown as an example. All events raised by ChorDDI are shown.

3.3.1. ServicePot Scalability Dimensions, Issues, and Strategies ServicePot faces the same scalability challenges as any other web applications. We solve the scalability problem by distributing the ServicePot application and data over multiple nodes. UDDI provides data distribution using a replication mechanisn. We believe this approach is not scalable in a ULS SOA, because in a ULS system, we need to store a large amount of data, and replication at this scale will create a lot of overhead. For data distribution in ServicePot, we have devised a partitioning and federation based approach among the ServicePot Nodes. This kind of partitioning introduces new challenges for implementation as the UDDI standard does not allow lookups on a distributed registry. For this, we have taken inspiration from the DNS System to introduce recursive lookups in a distributed ServicePot registry. We use the approach mentioned by [6] to federate the registries at the publication and query level. Similar to what is described by the authors, we use a global distributed data store to index the entities in the UDDI registry. To implement this federation we utilize the extension mechanism provided by ServicePot and described in the previous section. A plugin is developed which approximately implements the approach described in [6]. The flow of the “Publish Choreography” and “Find Choreographies” use cases, when CHOReOS FP7-257178

27

Figure 3.8: ServicePot: The ChorDDI Component

Figure 3.9: ServicePot: Plugin Interfaces and Events the plugin is installed, is described in the sequence diagrams in Figure 3.10 and Figure 3.11. Table 3.2 summarizes the main dimensions of scalability as highlighted in D1.4 (see [31]) expanded in relation to ServicePot. Scalibility Testing Plan For Scalability Testing in ServicePot, we intend to do the following: CHOReOS FP7-257178

28

ULS Dimension 1. Number of different kind of available services 2. Number of different kind of services in a single choreography

3. Number of service consumer instances in a single choreography (i.e., for a given kind of service consumer, we may have a UL number of instances) 4. Frequency of messages (requests, operations or transactions) exchanged by the services in time period 5. Number of atomic services (actuators and sensors) aggregated in services 6. Change of the above dimensions over time

Consideration about ServicePot This dimension represents the amplitude of the scale of the whole ULS system. This is the main motivation of distributing the data storage in ServicePot This dimension affects the use case of listing all possible participants for a role. This can cause a large communication overhead in this usecase if the participants are distributed. We will need to minimize the distribution of the services performing a role whenever possible As this dimension increases, we will see an increase in the number of lookup requests in ServicePot

The message exchange taking place in the execution of the services is irrelevant for ServicePot

ServicePot currently does not distinguish between aggregate and atomic services, so this dimension is irrelevant at the moment Depending on the capabilities of ServicePot nodes, a scaling by 1000 could necessiate introducing new nodes and partitioning existing data.

Table 3.2: ULS dimensions and ServicePot Generate UDDI data that conforms with our notion of ULS. The data would be a mix of Choreographies and Web Services. Then we intend to use measurement tools such as JMeter to observe the trend of scalibility metrics as we increase the distribution of this data into partitions. This experiment will allow us to estimate how much performance gain we will be able to achieve through distribution, and whether the performace improvement diminishes after a certain level of distribution.

3.4. ParTes In this section we describe the status of the implementation of the ParTes tool that provides the strategy already sketched in the deliverable D.4.2.1. The aim of the tool is test derivation and execution of participants involved in a choreography to discover possible mismatches in their behavior with respect to an assigned role. Mismatches can prevent the integration in the choreography bringing to run-time errors. Integration mismatches are also addressed by the synthesis approach. Indeed in case the test suite derived by ParTes is applied using as System Under Test the system composed by the synthesized adapter plus the service the technique will be able to discover possible mistakes with respect to the behaviour declared by the service, and that has been used to drive the synthesis algorithm. As already stated, the tool uses a model checking based technique in order to select those executions that could better highlight integration issues in BPMN2 choreographies. Each execution trace is found from the exploration of a Java choreography model built starting from BPMN2. Traces are converted in SOAPui test suites, and are successively used to assess the behavior of services. The implementation involves different steps implemented in separate components (see Figure 3.12) that carry on different activities: CHOReOS FP7-257178

29

Figure 3.10: ServicePot: Distributed Publishing • BPMN2JPF transforms a BPMN2 model in a Java model of the choreography that we call ”JPFModel”. This artifact is suitable for being processed by the model checker Java Path Finder 1 to derive counter-example traces. The component has been implemented according to the principles of MDE. In particular, the implementation has been developed considering the Eclipse platform in the context of EMF that supports the implementation of model manipulators such as model-tomodel and model-to-code transformation. Indeed, the component takes as input the specification of a BPMN2 choreography and after specific code generation steps produce Java code. As an example, in Figure 3.13 we show a minimal definition of a choreography with two choreography tasks involving two participant. This BPMN2 specification is translated to a Java code that foresees a Choreography object, ChoreographyTasks and SequenceFlows (and other concepts according to the BPMN2 XSD model attached to the OMG specification) as represented in Listing 3.1. This code represents the behavior of the ”main” method of the JPFModel and drives the interaction between mocks implementation of participants (Participant1Impl, Participant2Impl in the sample). The interactions among these objects are tracked by JPF. The Listings 3.2 shows a sample portion of the whole template for the generation of the first line of the template: Choreography choreography = new Choreography();. 2 This step of the ParTes strategy is not yet integrated with the others because at the moment it requires manual intervention to the developer. We are defining the better way to ”code” participant behavior. Moreover, a work about a new algorithm for BPMN exploration is in progress as detailed in the following section. 1

//...

1

http://babelfish.arc.nasa.gov/trac/jpf The keywords in the template code should be identified by guillemets, i.e: readability. 2

CHOReOS FP7-257178

DEFINE. Here we have omitted them for



30

Figure 3.11: ServicePot: Distributed Lookup

CHOReOS FP7-257178

31

Figure 3.12: ParTes Architecture

2

Choreography choreography = new Choreography();

3 4 5 6 7

Participant p1 = new Participant("Participant_1", "Participant 1"); Participant p2 = new Participant("Participant_2", "Participant 2"); choreography.addParticipant(p1); choreography.addParticipant(p2);

8 9 10 11 12

Message Message Message Message

m1 m2 m3 m4

= = = =

new new new new

Message("Message_1", Message("Message_2", Message("Message_3", Message("Message_4",

"MessageRequest1"); "MessageResponse1"); "MessageRequest2"); "MessageResponse2");

13 14 15 16 17 18 19 20

MessageFlow mf1 = new MessageFlow("MessageFlow_1", "Message Flow 1", m1, p1, p2); MessageFlow mf2 = new MessageFlow("MessageFlow_2", "Message Flow 1", m2, p2, p1); MessageFlow mf3 = new MessageFlow("MessageFlow_3", "Message Flow 3", m3, p1, p2); // alternatively you can use the choreography methods MessageFlow mf4 = new MessageFlow("MessageFlow_4", "Message Flow 4", m4, choreography.getParticipant("Participant_2"), choreography.getParticipant("Participant_1"));

21 22 23 24 25

choreography.addMessageFlow(mf1); choreography.addMessageFlow(mf2); choreography.addMessageFlow(mf3); choreography.addMessageFlow(mf4);

26 27 28 29 30 31 32

ChoreographyTask ct1 = new ChoreographyTask("ChoreographyTask_1", "Choreography Task 1"); ct1.setInitiatingParticipantRef(p1); ct1.addParticipantRefs(p1); ct1.addParticipantRefs(p2); ct1.addMessageFlow(mf1); ct1.addMessageFlow(mf2);

33 34 35 36 37 38 39 40

// alternatively you can use the choreography methods ChoreographyTask ct2 = new ChoreographyTask("ChoreographyTask_2", "Choreography Task 2"); ct2.setInitiatingParticipantRef(choreography.getParticipant("Participant_1")); ct2.addParticipantRefs(choreography.getParticipant("Participant_1")); ct2.addParticipantRefs(choreography.getParticipant("Participant_2")); ct2.addMessageFlow(choreography.getMessageFlow("MessageFlow_3")); ct2.addMessageFlow(choreography.getMessageFlow("MessageFlow_4"));

41

CHOReOS FP7-257178

32

Figure 3.13: BPMN2 Basic Choreography Example

42 43

StartEvent start = new StartEvent("StartEvent_1"); choreography.addFlowElement(start);

44 45 46

SequenceFlow sf_start = new SequenceFlow("SequenceFlow_start", "SequenceFlow start", start, ct1); choreography.addFlowElement(sf_start);

47 48 49

SequenceFlow sf1 = new SequenceFlow("SequenceFlow_1", "SequenceFlow name", ct1, ct2); choreography.addFlowElement(sf1);

50 51 52

EndEvent end = new EndEvent("EndEvent_1"); choreography.addFlowElement(end);

53 54 55

SequenceFlow sf_end = new SequenceFlow("SequenceFlow_end", "SequenceFlow end", ct2, end); choreography.addFlowElement(sf12);

56 57 58

ChoreographyEnvironment cEnv = ChoreographyEnvironment.getInstance(); cEnv.setChoreography(choreography);

59 60 61 62 63 64 65 66 67

//these classes mock participant for with JPF API for logging Participant1 p1Impl = new Participant1(); Participant2 p2Impl = new Participant2(); cEnv.getParticipantsMap().put(p1, p1Impl); cEnv.getParticipantsMap().put(p2, p2Impl); cEnv.attachImplementationToChoreography(); cEnv.start(); //...

Listing 3.1: Java code generated for the basic example of a choreography 1 2 3 4 5 6 7 8

DEFINE Definitions FOR emf::EObject IF (this.metaType == bpmn20::TChoreography) Choreography ((bpmn20::TChoreography)this).id = new Choreography(”((bpmn20::TChoreography)this).id”, ” (( bpmn20::TChoreography)this).name”); EXPAND choreographyContent FOREACH this.eContents ENDIF ENDDEFINE

Listing 3.2: Template for the generation of a Java line with a new Choreography object • A model checker component Choreography Interaction Tree Generator that explores the model and build a choreography interaction tree respect to a given property. This is represented in the interface ChoreographyInteractionTreeGenerator that provides the buildInteractionTree(modelDir:String):Tree method. This step is able to explore the JPFModel to provide a tree structure that contains Interaction objects representing SOAP invocations to participants arranged according to the exploration of the choreography. • A projection component Participant Interaction Tree Generator that separates the traces (i.e sequences of Interactions) respect to the service role they belong. Each projection is repreCHOReOS FP7-257178

33

Figure 3.14: ParTes Sequence Diagram sented by a new tree (that we call participant interaction tree) that contains the Invocations for a specific participant role. This is represented in the interface ParticipantInteractionTreeGenerator that provide the method makeProjection(tree:Tree, services:String):Vector. The incapsulation of information is made by the ProjectionInfo object that contains the generated tree with the role name used for the projection. • A test suites generator component Test Builder that generates soapUI projects from the participant interaction tree generated by the projection component. This produces the final output of the tool providing a SOAPui project for each participant role involved in the choreography. SOAPui projects are XML files that can be used during the ServicePot operations (and also with the standalone SOAPui tool). This is represented by the interface ParticipantTestBuilder that provides the method makeSOAPuiProject():WsdlProject. This method, starting from a participant interaction tree, a WSDL portType to test and a WSDL file, builds a SOAPui project that is represented by a WsdlProject object form the SOAPui library3 . • A test generator component Test Generator that use the previous components to implement the strategy. This is represented by the interface PartestTestGenerator • A test execution component Test Execution that is responsible to execute tests using the SOAPui library. This is represented by the interface PartesTestRunner • Two components that represent the Java PathFinder API and the SoapUI API . The components are integrated by an abstract class PartesTestGenerator and a Partes default implementation. The implementation refers to the default implementation of the interfaces presented, and it performs the ParTes strategy. The main sequence diagram is depicted in Figure 3.14 and foresees the presence of the PartesMain command line external interface or the PartesWS web service implementation. The external utiliser use a Partes object and call the generateTestSuite() method that use the components following the steps of the strategy already described. 3

http://www.soapui.org

CHOReOS FP7-257178

34

The ParTes strategy is used in the ServicePot registry to reinforce service registration. The ParTes and ServicePot API are the basis plugin that (i) derive and store the test suites and (ii) execute them. These feature are implemented using specific hook provided by ServicePot. In particular after the choreography registration, the afterSaveChoreography() hook is used to build the test suites and store them in a XML database. The beforeAddChoreographyParticipant() and beforeAddRolesToParticipant() are the hooks responsible to invoke test execution that can performed using also a dedicated web service that use the SOAPui library. The goal of the plugin is to run the tests during registry usage and fail the operation if tests do not succeed. Appendix D offers an overview of the main classes of the tool. Compared to the version described in Deliverable D.4.2.1 [16] there are three new Java interfaces (ParticipantTestBuilder, ChoreographyInteractionTreeGenerator, and ParticipantInteractionTreeGenerator) that replace web services for the single steps of the strategy. These steps are now offered as a Java API and not as separate web services. The web service endpoint interface for the whole implementation of the ParTes strategy is now PartesWSInterface. We also have added a new algorithm for managing data dependencies in ChoreographyTask executed concurrently and an integration with ServicePot. This is described in Section 3.4.1. Moreover, as minor improvement we added a new command line interface.

3.4.1. ParTes Scalability Dimensions, Issues, and Strategies The scalability of the tests generation and execution functionality offered by ParTes is addressed through replication of the service itself (integrated as a ServicePot plugin) in multiple nodes. Moreover, also the execution of the tests will be made scalable via the replication of a testing service (based on the soapUI API, also integrated as a plugin in ServicePot) to meet the needs of the ULS context. It is worth noting that replication is a simple effective approach for ParTes, in particular in order to address scalability issues, given its purely functional behavior with no state-based consequence among different invocations. In this sense the functionality of tests generation offered by ParTes, and the functionality of tests execution built in ServicePot will be replicated in the context of ULS systems ensuring the operational independence of the elements which constitute the run-time testing support of the choreography. This approach of ”division of labor” in the basic components brings advantages in the ULS context. Due to the large number of users, components and requirements in the presence of a ULS system there will be several configuration options to support testing at run-time. Integrating different capabilities of test generation (other than ParTes), different modes of execution or - in the case where users prefer fast response of the registry - disabling the testing support at a cost of having an increased error rate. The Table 3.3 summarizes the main dimensions of scalability already highlighted in the project (deliverable D1.4) in relation to the ParTes tool. The main ULS dimension that affect ParTes is the ”Number of different kind of services in a single choreography”. A service that takes part in a choreography plays a role that should be tested considering all possible scenarios of integration allowed by the choreography considering also the other roles involved. The model checking phase of ParTes is useful and powerful as the expressiveness of JPFModels is guaranteed by the use of the Java language and the exploration capabilities of JPF are rather powerful. Despite this, the implementation of a Java model derived automatically from the choreography is a difficult task and often requires manual intervention for the specification of mock services. Java Path Finder is a software model checker that works at Java bytecode level. This allows a good customization via a powerful API, but at the same time weigh the exploration of parallel events. These events become parallel threads which generate a large number of interleaving (of JAVA byte code instruction). To avoid this overload in the model checking phase of the ParTes strategy we are developing a new ad-hoc algorithm for BPMN2 exploration to improve the generation of the choreography interaction tree without explicitly using a model checker. The new algorithm deals directly with the BPMN2 concepts instead of exploring the JPFModel at java code level. In particular the focus is on managing the parallelism between ChoreographyTasks that can CHOReOS FP7-257178

35

ULS Dimension 1. Number of different kind of available services

2. Number of different kind of services in a single choreography

3. Number of service consumer instances in a single choreography (i.e., for a given kind of service consumer, we may have a UL number of instances) 4. Frequency of messages (requests, operations or transactions) exchanged by the services in time period 5. Number of atomic services (actuators and sensors) aggregated in services 6. Change of the above dimensions over time

Consideration about ParTes This dimension represents the amplitude of the scale of the whole ULS system and affects the need for replication of the services for generation and execution of tests. The derivation strategy itself is not affected by this dimension. This is a sensible dimension for ParTes, with the increase in the number of services the complexity of the generation increases. The bottleneck is given by the use of model checking and the related explosion of states in the presence of interleaving. The work on the algorithm for BPMN exploration was on the elimination of this problem to make exploration scalable with respect to the number of ChoreographyTasks contained in the BPMN specification of the choreography. This dimension is not an issue for the derivation strategy nor for the deployment of services for generation and execution of tests.

This dimension is not an issue for the derivation strategy nor for the deployment of services for generation and execution of tests. This dimension is not an issue for the derivation strategy nor for the deployment of services for generation and execution of tests. This dimension can affect the need for replication of services for test generation and execution. The strategy itself is not affected by this.

Table 3.3: ULS dimensions and ParTes

CHOReOS FP7-257178

36

affect communication between roles. Figure 3.15 shows a simple example of a parallel gateway that generates two branches in the choreography. The ChoreographyTasks within each branch can be executed in parallel and we are potentially in a situation where interactions that take place in a ChoreographyTask may affect other interactions. In such situations it is important to consider these potential interleavings that can represent hazards to a proper execution of the choreography. Conversely, if the ChoreographyTasks performed in parallel do not have hazardous conditions is not necessary to generate all the interleavings as these will produce equivalent final results (i.e. equivalent service status). In Figure 3.15 there are no dangerous conditions. A classic model checker will produce all possible interleavings but not all are useful for the test generation because ChoreographyTasks describe independent interactions. Our algorithm instead select one trace without considering all possible interleavings.

Figure 3.15: Simple Parallel of ChoreographyTasks without Dependencies We must consider interleavings when the dependencies can cause problems in the execution of the choreography. Dependencies between ChoreographyTasks (”CT” for short) can be of various types: • ”receiver-sender” dependency: this is the case in which a participant is the ”receiver” in a CT and the sender in another CT performed in parallel. The execution order is potentially important because the received data could alter the internal state of the service and hence lead to a different interaction in the other CT. This situation is depicted in Figure 3.16. • ”same-receiver” dependency: this is the case in which a participant is the ”receiver” in more CTs performed in parallel. The execution order is potentially important because the received data could alter the internal state of the final service. This situation is depicted in Figure 3.17. • ”chain” dependency (or cyclic dependency): this is the case in which the order of CT execution may be significant because of the fact that some participant are ”sender” and then ”receiver” in other CT executed in parallel (and vice versa) in a cyclic manner. This situation is depicted in Figure 3.18. Clearly, the dependencies can arise in more complex ways than those described so as shown in Figure 3.19. CHOReOS FP7-257178

37

Figure 3.16: ”receiver-sender” Dependency Example

Figure 3.17: ”same-receiver” Dependency Example The new algorithm works building a graph able to describe all the structural constraints (due to sequences of CTs) and dependencies found in the BPMN2 specification of a choreography. The graph nodes represent CTs while edges represent possible parallel executions of CTs. Paths in the graph represent possible executions of CTs which take account of interesting combinations. The algorithm that explore the graph perform a graph traversal that will start each time from a different initial node (the initial CT of each original BPMN2 branch), respects the constraints of the graph, and build interesting sequence of CTs to test. These sequences are arranged in a choreography interaction tree to integrate with the overall ParTes strategy.

CHOReOS FP7-257178

38

Figure 3.18: ”chain” Dependency Example

Figure 3.19: Example of Complex Dependencies in a Choreography

3.5. CRank This component implements mechanism for rating both services and service choreographies. As introduced in Deliverable D4.1 [15], the rating policies are based on both objective indicators (i.e. testing scores from on-line testing session launched from ParTes– see Section 3.4); and rating them based on subjective evaluation (i.e. feedbacks form the users). Rating information is useful to improve the service selection process and to put in place policies concerning service lifecycle activities related to those services made available by the corresponding service provider [17]. Furthermore it can be used in order to deal with properties on the whole choreography (e.g. determining if a choreography is “enactable”). The component can provide several possible strategies for calculating and implementing the service/choreography ranking function. In order to keep a modular design/implementation of the component, each strategy must be implemented in a dedicated package including various subcomponents. A first release ofthis component was given in Deliverable D4.2.1 [16] and Deliverable D5.2 [11] as ”Reputation Center”. Section 3.5.0.1, and Section 3.5.0.2 highligth the main elements implementing CRank, while the detailed description of its API is given in Appendix E

CHOReOS FP7-257178

39

CRank: Imptementation Details

Figure 3.20: CRank: Class Diagram

AbstractDependencyEdges This class models the dependencies among the actors of a service choreography. Actor This class models an Actor of a service choreography. Somewhere an Actor could be also referred with the term “Role”, nevertheless, in this documentation they are synonymous. ActorsRank This class models the ranks scored by a list of actors. ChoreographyRank This class models the ranks scored by a service choreography. It refers to a choreograpy modeled as a dependency matrix CHOReOS FP7-257178

40

DependencyEdges This class provides a specific implementation of a dependency relation. In particular this class implements the relation described in [17], and D4.1 [15]. PostboardReader This class interfaces the ranking function based on the services reputation with a specific subsystem able to collect user’s feedback. In particular, the class computes the Reputation scores by reading feedbacks expressed as RSS on a given bulletin board (i.e. Postboard). RefreshServiceRanks This Class handles the periodical computation of the Service Ranks. Reputation This class models the reputation of an entity (i.e. services) in terms of the numbers of positive and negative feedbacks it collected. ReputationBasedRanking This class provides a specific implementation of the ranking function associated to the services. In particular, it implements the ranking function based on user’s feedback as the Beta expectation function [17], [15]. In other words, the feedbacks that the users reported during past interactions with a service ”s” are interpreted as the probability of collecting a positive feedback with ”s” on average in the future interactions. For example, if ”betaExpectation” for the service ”s” is 0.8 means that is still uncertain if ”s” will collect a positive feedback in the future (i.e. due to a positive interaction), but it is likely that this would happen. Service This class models a Service. ServiceRankFunction This class models the ranking function associated to the services. ServiceRankFunctionFactory A factory for creating ServiceRankFunction objects. ServiceRankFunctionTypes This enumeration defines the types of the ranking functions supported for services. SourceOfRank This class models the actor’s source of rank. The source of rank is used as base-line during the computation of the choreography rank. TestingBasedRanking This class provides a specific implementation of the ranking function associated to the services. In particular, it implements the ranking function based on testing results as described in [17], and D4.1 [15]. CRankServicePlugin CRankPlugin This plugin implements the integration between ServicePot and CRank. Specifically, reffeing to the overall plugin architecture described in Section 3.3, it deals with choreography specifications refferred as input TModel. Specifically, it follows a description of how the features offered by ServicePot and CRank have been integrated. The detailed presentation of the API, is given in Appendix E After a new choreographies has been added to ServicePot, this plugin computes the following steps: • create the Dependency Matrix

CHOReOS FP7-257178

41

Figure 3.21: CRankServicePlugin • allocate resources in CRank for the reputation-based ranking of the choreography • allocate resources in CRank for the testing-based ranking of the choreography After the subscription of a new services in ServicePot, the service is also included it the procedure calculating the reputation/testing-based ranking for all the roles it specify in the category bag of structure ServiceDetail. After the subscription in ServicePot of an existing service with an additional set of roles (in one ore more choreographies), the service is also included it the procedure calculating the reputation/testingbased ranking. Both the new roles and their associated choreographies are specified in the category bag of structure ServiceDetail.

3.5.1. CRank Scalability Dimensions, Issues, and Strategies CRank faces the same scalability challenges as most of the other solutions based on the Web Services technologies. Specifically, CRank tackles some of the ULS dimensions addressed in CHOReOS clustering the implementation over multiple nodes; for example in order to provide both high availability, and scalability of the service. Specifically, high availability refers to the ability to serve client requests by tolerating failures; while scalability is the ability to serve a large number of clients sending a large number of requests without any degradation to the performance. In this sense, it is difficult or in some cases impossible to support massive level of scalability and high availability from a single server, despite how powerful the server hardware or how efficient the server software is. Web services clustering allows to deploy and manage several instances of identical web services across multiple web services servers running on different server machines. Then, client requests are distributed among these machines using a suitable load balancing system. As introduced above, clustering is an asset that is usually provided by any platforms for Web Services. Thus most of the solutions among the several platforms are similar. Nevertheless, as the current prototype is developed for Axis2 4 , CRank relies on the features offered by this specific platform. 4

http://axis.apache.org/axis2/java/core/

CHOReOS FP7-257178

42

Specifically, to achieve scalability, an Axis2 cluster will be managed by a load balancer. This module is configured in order to spread the load across the cluster according to some load balancing algorithm. Usually, the round-robin load balancing algorithm is one such popular and simple algorithm. Nevertheless, the ULS dimensions identified within CRank (see Table 3.4) ask for more specific approaches; for example aiming at allocating and distributing each choreography on a specific instantiation of the service. In such a way, it is possible to allocate the computation of the choreography ranks according to the specific needs that any enactment may dynamically require at run-time. In this way, the number of nodes in the cluster is a function of the number of choreographies currently available (e.g. because they have been registered on registries like ServicePot– see Section 3.3). ULS Dimension 1. Number of different kind of available services for a specific role

2. Size of the Dependency Matrix derived from the choreography specification

3. Number of service consumer instances in a single choreography (i.e., for a given kind of service consumer, we may have a UL number of instances) 4. Frequency of messages (requests, operations or transactions) exchanged by the services enacting the choreography in time period 5. Change of the above dimensions over time

Consideration about CRank Each participant defined in a service choreography represents a specific role that many services may subscribe for implementing it. Thus, if on the one hand we do not necessary refer to choreographies composed by a large number of tasks, on the other hand we see that this dimension is the amplitude of the scale of the whole ULS system. This is the main motivation of clustering and distributing the resources implementing by the CRank service. The Dependency Matrix used by CRank represents the relations among the roles specified in the choreography. Thus, most of the computations calculating the overall rank of such roles are based on matrix multiplications involving the Dependency Matrix. Indeed, a choreography that specifies many roles (i.e. roles not services bind a role) may require appropriate strategies for dealing with scalability issues. The current version of the prototype CRank does not explicitly support this aspect yet. Nevertheless, for further improvements of the approach it could be possible to refer/exploit the scalable solutions (e.g. matrix reduction techniques) provided by the communities specifically working either on Linear Algebra Optimization, or on Scientific Calculations. This dimension concerns the number of services binding a role of choreography. Simplifying, CRank represents a role as an array of the rank of the services. Indeed, at the moment, this dimension is considered irrelevant, as the computational costs associated to the calculation of the rank of a role is linear with respect to the number of services binding it. The message exchange taking place in the execution of the services is irrelevant for CRank

Depending on the capabilities of the nodes available for the instantiation of the cluster of implementing the CRank service, a scaling by 1000 could necessitate introducing additional nodes. As described above, for this specific aspect, the prototype we developed relies on the flexible clustering features offered by the Axis2 5 framework.

Table 3.4: ULS dimensions and CRank

CHOReOS FP7-257178

43

According to its official documentation, Axis2 supports several membership schemata for the node binding a cluster. Specifically, those schemata includes : the static membership only a defined set of members are in the cluster, and they are the only ones that can be dynamically activated/deactivated; the dynamic membership does not define any predefined set of cluster members. Nodes can join or leave a cluster by querying a specifics entity within Axis2 specifying the appropriate group name; the hybrid membership where there are a set of static members (i.e. “well-known members”), but external nodes can join this group by notifying one of the well-known members. This last schema looks the most interesting solutions facing the dimensions of ULS defined by CRank within the context of the CHOReOS project. The Table 3.4 summarizes the main dimensions of scalability in relation to the CRank. Scalability Testing Plan For Scalability Testing in CRank, and especially with respect to item 1, and item 5 in Table 3.4 we intend to use measurement tools such as JMeter to observe the trend of scalability metrics as we increase both the number of node in the cluster implementing the CRank service, the number of requests to CRank.

CHOReOS FP7-257178

44

4 Multi-source Monitoring Interactions among Web-Services at run-time can lead to QoS anomalies that may be difficult to detect and to handle properly. This is even more complex when these interaction are regulated by abstract choreography specifications. Often in those scenarios, the observation of QoS anomalies at run-time can be due to phenomena originated from sources operating at different abstraction layers [12]. In this chapter we present the CHOReOS Multi-source Monitoring Framework, through which the nonfunctional properties of service choreographies can be kept under observation by coordinating monitoring activities occurring at different layers and focusing on different goals. The overall architecture of the monitoring framework, and the first version of its implementation were introduced in D4.2.1 [16]. In the following, for each of the monitoring layers we report the major refinements of the implementation that we developed in the last months.

4.1. Overall Monitoring Architecture The components forming the multi-source monitor and their connections are depicted at a high abstraction level in Figure 4.1. The details of the components are then presented in the following sections.

Figure 4.1: Monitoring Architecture

CHOReOS FP7-257178

45

4.1.1. Business Service Monitoring Node The Business Service Monitoring Node is an EasyESB Node with a specific profile dedicated to monitoring. It involves components that are useful to evaluate the non functional parameters of the governed services. It interacts with the middleware for business services (EasyESB) and with the Complex Event Processor (Glimpse).

4.1.2. CHOReOS Middleware This component represents the CHOReOS Middleware which enables the various elements to interact.

4.1.3. Complex Event Processor The Complex Event Processor (CEP) is the rule engine which analyzes the primitive events, generated by the middleware, to infer complex events matching the monitoring requests. Specifically, the CEP implements a notification mechanism following the publish/subscribe paradigm on a monitoring bus (which is part of the middleware). Also, it orchestrates both the sources of events (i.e. probes), and the consumers of the notifications. Specifically it can both register probes, and fetch monitoring requests coming from consumers, Then, it can analyze complex events and notify the proper consumer on a dedicated channel of the monitoring bus.

4.1.4. Infrastructure Monitoring Node The Infrastructure Monitoring is the component in charge to monitor the status of the machine on which the services are running. Each time the Infrastructure Monitoring notices a violation, e.g. too high CPU/memory usage, it notifies the violation to the Complex Event Processor through a JMS Message on the CHOReOS middleware component by means of the Enterprise Service Bus.

4.1.5. Manager The Manager component is part of the Complex Event Processor component. It is in charge to instantiate and orchestrate the ServiceLocator component, the RulesManager component and the EventListener component. The Manager component is in charge also to deal with several Rule engines, in the current implementation, we adopt the Drools Fusion rule language [1].

4.1.6. RulesManager The RulesManager is the component in charge of analysing events, and to infer complex events. In the CHOReOS scenario the events are represented by SLA Violations or Infrastructure violations detected by the Business Service Monitoring and the Infrastructure Monitoring. There are several rule engines that can be used for this task (like Drools Fusion [1], RuleML [2]). As said, in the current implementation we adopt the Drools Fusion rule language [1] that is open source and can be fully embedded in the realized Java architecture. Note that, the proposed flexible and modular architecture allows for easily replacing this specific rule language with another one.

4.1.7. ServiceLocator Through the ServiceLocator component, the Complex Event Processor is able to fetch from the CHOReOS middleware, through SOAP calls, information about services that are running on the machines connected to the CHOReOS infrastructure. CHOReOS FP7-257178

46

This component contains a daemon that continuously contacts the CHOReOS middleware through SOAP calls to obtain information about the services that are running on each machine. It stores locally a map between service → machine and uses it when a SLA violation occurs to check if there are also violations coming from the infrastructure monitoring related to the same machine.

4.2. Infrastructure Monitoring As described in Deliverable D4.2.1 [16], the resource monitor in CHOReOS leverages previous works by borrowing heavily from Ganglia [40] and has three main components: 1) A set of data collectors that gather local information such as load average, I/O rates, and network utilization. These collectors run on every active node of the cloud. Data for each node is both made available on demand over TCP/IP and, at the same time, periodically pushed over UDP to be replicated in nearby nodes. These data collectors are simply instances of the Ganglia gmond component. 2) A set of aggregators that periodically pull data from the collectors, summarize it, and keep a historical record of the values received. Each aggregator may be responsible for a subset of the nodes in the system and may also be replicated. Finally, aggregators may be organized hierarchically, so that higher-level ones provide a broader view of the system. Data stored in each aggregator is made available on demand over TCP/IP. These aggregators are instances of the Ganglia gmetad component. 3) A notification mechanism that detects potentially relevant events, such as exceptional load average or too little available disk space, and notifies the higher-level event monitor system described in Section 4.4 for further analysis. It is up to this higher layer (according to the parameters defined by the middleware) to assess whether such events indeed warrant special attention or not. The notification daemon is based on simple hard-coded rules that define what constitutes a potentially relevant event. Currently, the gmetad component is deployed to every node, but we have not yet identified a strong use case for the data it provides in CHOReOS, and it is consequently unused. The other components should be deployed in a similar fashion to Figure 4.2. Recent work on the platform monitoring subsystem has culminated in the development of the necessary modifications to the NodePoolManager component so that: 1) gmond and gmetad (the Ganglia components we use) are automatically deployed to every CHOReOS node on the cloud; 2) The configuration for gmond is automatically updated whenever virtual nodes are added or removed from the cloud. Both improvements were made easy by the underlying chef configuration management system, which allows us to create simple “recipes” to manipulate files and applications on managed nodes. In particular, the automatic configuration of gmond is simply implemented in a recipe by means of code similar to: template "/etc/ganglia/gmond.conf" do source "gmond.conf.erb" iplist = search(:node, "*:*").map {|node| node.ipaddress} variables( :iplist => iplist ) notifies :restart, "service[ganglia-monitor]" end CHOReOS FP7-257178

47

Figure 4.2: Platform Monitoring Deployment gmond.conf.erb is the template for the configuration file /etc/ganglia/gmond.conf. chef-client runs periodically on each node and builds a new version of the file with the data gathered from the search command; if this new version is different from the old one, it restarts the gmond daemon. We have also made two significant improvements to the notification daemon: 1) The previous version offered just a proof-of-concept mechanism for the detection of exceptional conditions, with hard-coded rules inside the application code. It now has a configuration file where it is possible to define which parameters to take into account and the threshold values (too high or too low) that should trigger a notification to be sent to the Glimpse CEP. 2) The daemon now is able to collect data from all machines in a cluster and not only the node itself (thanks to the replication feature of gmond). It also detect nodes that have failed to send any information for some time, which indicates a serious problem with that node. This allows us to deploy the daemon to only a subset of nodes if so desired. The configuration file follows the YAML syntax; a simple configuration file example is:

attribute: comparison: CHOReOS FP7-257178

load_one MAX 48

limit_value: attribute: comparison: limit_value:

1 load_one MIN 0.7

This would direct the notification daemon to notify the Glimpse CEP whenever the load one parameter (Unix load average for the last minute) exceeds 1 or goes below 0.7. The class diagram for the current version of the notification daemon is presented in Figure 4.3.

Figure 4.3: The Notification Daemon Class Diagram

4.2.1. Infrastructure Monitoring Scalability Dimensions, Issues, and Strategies As can be seen in Table 4.1, the number of virtual nodes in a cluster1 is the only scale variable that affects the platform monitoring subsystem: for every new virtual node, there is an additional set of monitoring components deployed onto this new virtual node. This means the resource usage of these components (memory for local data, disk space, CPU usage) on each node is always constant. Since the overhead of the gmond data collectors is widely acknowledged to be very low, we may consider it negligible. Memory consumption on each node for the data collected from neighboring nodes grows linearly with the number of nodes in the cluster; and the volume of data exchanged among nodes for repli1

A cluster is a set of (virtual or actual) machines that are grouped together, usually because they belong to a single organization and are close in terms of network topology. CHOReOS FP7-257178

49

cation grows quadratically with the number of nodes in the cluster. However, they are still low and, therefore, it is not uncommon for Ganglia deployments to feature thousands of nodes. Since it would be unwise to deploy any exceptionally large environment without partitioning the network, planning the cloud infrastructure to partition the Ganglia replication cliques accordingly is highly desirable. ULS Dimension Number of virtual nodes in a cluster

Consideration about the Infrastructure Monitoring Subsystem For every new virtual node, there is an additional set of monitoring components deployed onto this new virtual node. Memory consumption and network usage are low but grow, which suggests the need to partition the Ganglia replication cliques according to the network topology.

Table 4.1: ULS dimensions and Infrastructure Monitoring

4.3. Business Service Monitoring The Business Service Monitoring framework was previously presented in Deliverable D4.2.1 [16]. We sketched the architecture of this monitor and studied its integration within the CHOReOS Monitoring Framework and towards the other Middleware and Governance components. In this deliverable, we present the implementation status of each component and bring the new achieved updates. In Figure 4.4, we present the component diagram of the Business Service Monitor.

Figure 4.4: The Business Service Monitor

4.3.1. Business Service Monitoring Node The Business Service Monitoring Node is a EasyESB Node with a specific profile dedicated to monitoring. It involves components that are useful to evaluate the non functional parameters of the governed services. It interacts with the extensible service access middleware for business services, namely the EasyESB and with the Complex Event Processor (Glimpse).

4.3.2. Communication Monitoring The communication monitoring component is responsible for observing the message exchanges between services involved in a choreography. This component will be available in the next version of the CHOReOS FP7-257178

50

governance and V&V Framework.

4.3.3. Data Collector The Data collector aggregates the observed non functional data generated by the exchange between services. It uses data coming from both the QoS Runtime Assessment Component and from the Communication Monitoring.

4.3.4. Glimpse Component The Glimpse Component is an integration element implemented to make the BSM communicate with the Complex Event Processor Glimpse thanks to JMS notifications.

4.3.5. QoS Runtime Assessment The QoS Runtime Assessment is the component that evaluates the respect of the non functional contracts between services. It is composed of an SLA Manager and the Web Service Distributed Management Component. The SLA Manager is responsible for loading the service level agreement contracted between two given services. The WSDM Manager is responsible for creating a non functional endpoint for the observed services. The creation of a non functional endpoint each time a governed service is imported to the platform enables its tracking and the assessment of its contracts.

4.3.6. BSM Monitoring Process The BSM monitor interacts with both the middleware and the Complex Event Processor Glimpse. It enables the assessment of the SLA of services involved in choreographies and generates specific alerts when a violation is observed. In Figure 4.5, a sequence diagram illustrates the process for business service monitoring, in the basic case of two services. Let us consider the case of a Service A as a consumer and the Service B as a provider. The process goes through the following steps : 1) The service provider ServiceB is exposed to service consumers thanks to the ESB Node. 2) The BSM Node connects to the ESB Nodes. 3) The BSM Node creates a non functional endpoint for the Service B. 4) The Glimpse component loads the SLA into the SLA Manager. 5) When ServiceA sends a request to ServiceB, 6) The ESB Node informs of the response time T1-T2 separating the moment the real service sends the request and the moment its proxy endpoint gets the request. 7) The SLA Manager starts checking the SLA objectives. A first potential alert is generated and sent to the GlimpseComponent waiting for confirmation. 8) When ServiceB answers ServiceA, a second period of time T3-T4 separating the moment the ServiceA answers and the moment it is received by ServiceB, is evaluated. 9) In the case the difference (T4-T2) exceeds the response time mentioned in the SLA, the alert is confirmed and sent to the GlimpseComponent. The latter sends this notification as a JMS Message to the CEP Glimpse.

CHOReOS FP7-257178

51

Figure 4.5: BSM

CHOReOS FP7-257178

52

4.3.7. Business Service Monitor Scalability Dimensions, Issues, and Strategies Table 4.2 lists the ULS challenges that the business service monitor needs to address as well as the envisaged solutions. ULS Dimension 1. Heterogeneity of resources

2. Number of Resources

3. Number of SLA

4. Number of exchanges in a choreography

Consideration about the BSM The BSM framework needs to support all the defined resources (choreographies, services, SLA, etc). This implies strategies for controlling each resource as their behaviors are not similar, for instance, controlling a choreography needs to be done at each level of each choreography task. For each monitored resource the BSM node creates a non functional endpoint representing the resource. Considering an important number of resources would generate an important number of non functional endpoints as well. The BSM Node may adopt a deployment strategy relying on a distributed topology to relieve the stress on a unique local node. The QoS run-time assessment is responsible for evaluating the SLA between running services. As the number of services increases, the number of contracts increases as well and requires performance from the QoS Assessment component to compile the SLA objectives with regard to the collected ones. Moreover, the Data collector component that is responsible for gathering all this data needs to cope with a large size of data. Further tests need to be achieved in order to assess the scalability compliance of these specific components. Choreographies are built as an aggregation of choreography tasks, that put into play several services within exchanges. As the choreography is bigger and involves a higher number of choreography tasks, the BSM will need to evaluate for each choreography task who are the involved partners, and their relative contracts for assessment needs. Following a large choreography of services that is deployed on an ultra large scale platform raises challenging issues and implies dedicated monitoring strategies.

Table 4.2: ULS dimensions and BSM

4.4. Event Monitoring The sink of the violation intercepted and raised at business and infrastructure levels is the Event Monitor and its Complex Event Processor. The Event Monitor is in charge to correlate the violations raised by the Business Service Message-Oriented Monitor with the information collected by the Infrastructure Monitor. Ultimately, this is done to assess and improve the quality of the enacted choreography. Figure 4.6 depicts an example of how the CEP interacts with the other elements of the Multi-source Monitoring Framework. Specifically, a daemon running into the Event Monitor is continuously updating the information about the status of the services that are running on a choreography. The status of a service for the Event Monitor consists of information like: ip address of the machine where the service is running, status of the service, instance of the service. This information is mapped into the Event Monitoring and it is used when needed correlating the information generated from both the Business Service Message-Oriented Monitoring, and the Infrastructure Monitoring. CHOReOS FP7-257178

53

Figure 4.6: Interaction in the Multi-Source Monitoring

CHOReOS FP7-257178

54

In the sequence diagram at Figure:4.6, action 3 is a violation of an SLA contract raised by the BSM to the Event Monitoring. When the Event Monitoring receives this kind of violation, it will perform a local check to obtain the ip address/name of the machine on which the service is running. If the check is positive, now the Event Monitoring has the necessary information to make correlation between the service that violated the SLA and the machine on which the service is running; if the local check fails, the Event Monitoring will query the middleware to obtain information about the machine on which service is running. This kind of query is done through SOAP calls to the Middleware. Now, the Event Monitor can check if the machine on which the service is running is in a good shape or not: in a correct scenario, the machine on which the services of the enacted choreography are running, sends an “Alive” message to the Event Monitoring each X seconds. If the Complex Event Monitor does not receive an “Alive” message for more than X*5 seconds, it can means that the machine may be overloaded or stuck and, if the service that violated the SLA is running on the same machine that is no longer answering, the Event Monitor will notify that this service has a bad behavior. All these correlations will raise alert at a higher level. The rest of the section describes the implementation of the CEP in CHOReOS (see Section 4.4.1.1), and presents some scalability dimensions concerning the Event Monitor (see Section 4.4.2).

4.4.1. Event Monitoring main components ComplexEventProcessor The ComplexEventProcessor class is the abstract class that defines those methods to be implemented to use a generic Complex Event Processor engine. The Complex Event Processor is the component in charge to infer complex events and to match the rules loaded on it. ComplexEventProcessorImpl This is the class that implements the ComplexEventProcessor abstract class. We used the Drools Complex Event Processor engine. RulesManager To infer complex events, the complex event processor must be instructed about the simple events to correlate. The rules may be specified using several rules language: RuleML, Drools rules, WR rules. This abstract class specifies a set of generic operations that can be applied to manage rules. DroolsRulesManager This class specifies the RulesManager for the Drools Complex Event Language used in the proposed solution. GlimpseManager The GlimpseManager class is the main class in charge to coordinate all the components of the Event Monitoring. It loads the RulesManager, ServiceLocator, ComplexEventProcessor components and is in charge to manage also the communication between Infrastructure and Business Monitoring.

CHOReOS FP7-257178

55

Figure 4.7: Event Monitoring Overview ServiceLocator The ServiceLocator class keeps track of the status of the services that are running on several machines. Using HashMap techniques it takes trace of which services are running on which machine. This is necessary in order to correlate the events coming from the Infrastructure and the Business Monitors. ServiceLocatorImpl This is a specific implementation of the ServiceLocator class in the proposed solution, that uses SOAP calls to the Middleware in order to gather information about services running on a machine.

4.4.2. Event Monitor Scalability Dimensions, Issues, and Strategies This section discusses how the Event Monitor deals with some of the ULS dimensions and what are the main issues foreseen during the research and the development of the components in the Event Monitoring. In general, the heterogeneity of roles in a choreography does not imply negative effects on event Monitoring. However, the increasing number of services playing some role within a choreography may CHOReOS FP7-257178

56

lead to an increase of the number of SLA offered within the domain of the choreography specification. The more is the number of SLA, the more is the number of violations that should be considered by the monitoring framework. This aspect concerns both the number of rules that should be checked, and the number of matching per each rule. The Event Monitoring deal with this issue by scaling the number of CEP within the architecture. Specifically, each instance of CEP can run on a dedicated host and can communicate with the other components of the Multi Source Monitoring framework by means of the DSB using a publish-subscribe communication paradigm. For each CEP, the subscription rules of the DSB filter only those notifications that result useful for a potential map with a rule it stores. In this sense, each instance of the CEP can narrow the set of the event handled, for example according with the kind of notifications, the source service, the source infrastructure, or the choreography such notification belongs. As described in Section 3.1.6, a proper definition of this configuration depends on both the monitoring, and the enactment policies of the service choreographies. The Multi Source Monitoring architecture proposed in the CHOReOS project aims to correlate information generated at different abstraction layers. For this reason, it is really crucial to keep track of the information relative to the nodes on which the services are deployed and to be able to understand how the messages coming from both Infrastructure and the Business monitoring are correlated. One of the main needs concerning ULS aspects is to optimize the gathering of the information related to the nodes and services that are running on top of it. On top of the Event Monitoring there is a component, called ServiceLocator that is in charge to gather, store and update all the information related to the mapping between the services and the node on which they are running. This issue must be addressed by Event Monitoring in order to be able to correlate information coming from Infrastructure Monitoring and Business Monitoring as described in section 4.4. From a more technical point of view, during a normal execution of an instance of the Event Monitoring, the ServiceLocator contacts the Middleware through a SOAP call requesting the list of all the services that are running on a specific node. These information are stored locally by the ServiceLocator using HashMap techniques. For each role in the choreographies it is reserved a dedicated hashing tables so that trying to achieve optimal indexing performances when the number of services playing a specific role scales. When the Event Monitoring needs information about where is running a service, it will query the local HashMap requesting the ip address of the machine where the service is running, and in the worst case, if this service has not been already scanned by the running ServiceLocator daemon, a query to the middleware will be forwarded. Table 4.3 summarizes how the Event Monitor deals with some of the ULS dimensions and what are their main issues.

CHOReOS FP7-257178

57

ULS Dimension 1. Number of different kind of services in a single choreography

2. Number of different SLA in a single choreography

3. Number of service consumer instances in a single choreography (i.e., for a given kind of service consumer, we may have a UL number of instances) 4. Frequency of notification produced by the Business Services Monitoring in time period 5. Frequency of notification produced by the Business Services Monitoring in time period

Consideration about the Event Monitor This dimension may lead to a congestion in the modules of the Event Monitoring that keep trace on which node a service is located. As described above, the Event Monitoring includes dedicated mechanism optimizing the memorization of this information in HashMap tables. Such operation are running concurrently with the other activities of the CEP. In addition, each role in the choreographies it is allocated a dedicated hashing table trying to achieve an optimal indexing performances when the number of services playing a specific role scales. This dimension may lead to an increase of the number of the monitoring rules in the CEP. A candidate solution is to exploit the distributed nature of the DSB by deploying several instances of CEPs, selecting in the publish/subscribe mode the notifications from the DSB. This dimension may lead to an increase of the SLA violations. See the mitigations proposed at item 2.

This specific concern is addressed in Section 4.3.7.

This specific concern is addressed in Section 4.2.

Table 4.3: ULS dimensions and Event Monitoring

CHOReOS FP7-257178

58

5 Towards Validating the V&V Governance Framework The goal of this chapter is to summarize the main characteristics of the WP7 Adaptive Customer Relationship Booster (ACRB) use case from the standpoint of exploiting it as a means to evaluate the effectiveness of the V&V tools described in the previous sections of this deliverable. Based on the current status of the ACRB scenario, whose prototype implementation is in progress at the time of writing, this analysis mainly takes into account the use case design in terms of choreographies and related services, things and people involved, scale parameters, as described in Deliverables D7.1 [36], D7.2 [22] and D7.3 [34]. The remainder of this chapter is organized as follows. Sect. 5.1 briefly recalls the ACRB use case. Sect. 5.2 summarizes its main characteristics from a V&V viewpoint, and discusses the effectiveness of the WP4 V&V tools and methodologies for testing purposes to the WP7 scenario. Finally, sect. 5.3 draws some conclusions.

5.1. The Adaptive Customer Relationship Booster Use Case 5.1.1. Brief Description and Main Characteristics The ACRB use case addresses marketing at both planning and operative levels, with the objective of dynamically and cooperatively maintaining and implementing a marketing plan. Here follows a list of the main characteristics of this use case (for more details, see Deliverables D7.1 [36] and D7.2 [22]): • Involves a high number of different services, service types and actors. • Deals with many different types of information (e.g., known product demand, estimated demand, actual availability, estimated availability etc.). • Requires carrying out quasi real-time marketing actions such as negotiations with different types of entities (warehouses, suppliers, commercial partners etc.), through different types of channels (smart mobile devices, common cell phones, smart TV, in store displays etc.). • Involves different types of actors (i.e., clients having different purchasing profiles), inherently distributed and independent, and showing some degree of randomness in their needs and behaviors. • Implements a complex decision making process triggered by events, context-awareness and personalization, and is affected by multiple concurrent and distributed activities involving negotiations and cooperation. • Requires quasi real-time response times: its choreographies can select services based on the guaranteed SLA, and they can dynamically adapt to meet the required response times.

5.1.2. Structure From a high-level perspective, the ACRB use case is composed of several choreographies, as depicted in Figure 5.1 (for more details, see Deliverable D7.2 [22] and subsequent updates in WP7 documentation). CHOReOS FP7-257178

59

Figure 5.1: High-level ACRB Choreographies and Their Relationships (adapted from D7.1 [36])

5.1.3. Scale Parameters Table 5.1 provides some figures concerning the expected ULS scale of the ACRB use case in the real life. In some cases a range is given: the lower number corresponds to a relatively small deployment of the use case, while the upper number corresponds to a wide deployment of the use case. More details about the estimated number of actors involved in the use case can be found in Deliverable D7.3 [34].

5.2. Applying V&V to the ACRB Use Case The ACRB use case shows some peculiar characteristics that can directly impact on V&V activities: • The scenario can involve a high number of heterogeneous services, service types, things and people. All of them are nearly independent of one another, and can be geographically distributed. • Some choreographies may last for a long time, also due to the fact that people are involved in performing some tasks. • Some choreographies cannot be fully specified at design time, since they need to adapt at runtime when specific information (i.e., context, user profile, user demands) becomes available. • Use case choreographies also need to adapt in order to react to run-time events, such as faults and unavailability of resources. In some of these cases, quasi real-time responsiveness is needed. These factors require proper V&V activities that should be performed on the ACRB choreographies, which also demonstrate the effectiveness of the V&V tools and methodologies described in this deliverable. The remainder of this section tries to go more into details on these topics, by evaluating how development-time testing, run-time testing and multi-source monitoring relate and can be applied to the ACRB scenario. Some examples in this direction are provided.

5.2.1. Development-time Testing The Rehearsal framework (sect. 2.1) lends itself to supporting functional testing of ACRB choreographies at development-time, in particular as for unit, integration, acceptance and scalability testing. CHOReOS FP7-257178

60

Scalability dimension Number of service consumers

Number of services Number of users (people) Number of service requests made by each user

Number of services invoked in a single choreography Frequency of service requests Number of different device types involved

Definition Service base Number of Coordination Delegates Service base abstractions Actual services — — —

Number of Coordination Delegates per choreography Number of invocations per seconds and per choreography —

Order of magnitude 106 109 106 109 102 – 104 104 – 107 A few hundred per day for clients. In the order of 104 for marketing managers and directors. 106 106 104 – 107

Table 5.1: Scalability Dimensions of the ACRB Use Case (taken from D7.3 [34]) The Rehearsal framework approach consists in abstracting a choreography into Java objects, so that all the choreography elements (partners, services, messages exchanged etc.) can be represented by Java objects. Given a choreography specification, the ACRB testing developer can write unit, integration, scalability and acceptance tests at development-time for each of the internal elements of the ACRB choreographies. In this phase, service endpoint information are not required, infact at run-time the framework will interact directly with the CHOReOS Synthesis Processor through the DelegatesGenerator API to extract such information and then execute the actual test cases. Unit testing • The choreography abstraction approach (see Appendix A for more details) allows for incremental testing before choreographies implementation is complete, and this is in line with the ACRB development plan. In general, the Rehearsal based TDD approach can be adopted in order to implement also the ACRB use case . • The dynamic generation of Web service clients (see Appendix A for more details) can be used to perform unit testing at service level, i.e., requesting service operations and validating the related responses. The SOAP and REST services involved in ACRB choreographies can be incrementally tested without the need of manually creating dedicated stubs, but only relying on their descriptors (e.g., WSDL). This feature is particularly useful in the context of the ACRB scenario because of the high number of service types involved in its realization. Integration testing • The Service Mocking feature (see Appendix A for more details) can be particularly relevant for developing and testing choreographies based on SOAP services that are not available or directly testable on-line during the ACRB development phase. Moreover, this feature can support the test of choreographies by simulating unavailability of services (crash, no response etc.). An incremental service mocking approach should be adopted due to the high number of services potentially involved in the ACRB scenario. Moreover, some kinds of services might not be mocked (e.g., REST services, or services discovered at run-time). CHOReOS FP7-257178

61

Figure 5.2: ACRB Choreography: Shopping List Communication and Shops Identification (taken from D7.2 [22]) • The Message Interceptor feature (see Appendix A for more details) can support validation of simple or complex messages exchanged while invoking SOAP services. This feature can be particularly useful while implementing the ACRB scenario for testing communication between choreographies and services. Scalability testing • The Scalability Explorer component (sect. 2.1.2) can be used to support scalability testing of the ACRB use case. Proper functions for complexity size, performance metric and architecture capability have to be defined for the specific ACRB choreographies (see Deliverable D7.3 [34]). Acceptance testing • Acceptance testing may consist of validating a whole choreography as a unit service, from the end user viewpoint, by iteratively adopting the unit testing features described above. This approach can be feasible in testing the ACRB scenario but the number of different actors potentially involved in the use case should be taken into account. Therefore, this approach cannot be applied extensively, specific actors should instead be selected in order to perform focused acceptance testing on specific choreographies or interaction scenarios. Testing ACRB choreographies: An example. In general, the approach proposed by the Rehearsal framework can be adopted to implement the ACRB choreographies by iteratively applying the phases depicted in D4.2.1 [16], sect. 2.3.3, Figure 2.29, in a test-driven fashion. E.g., the ACRB choreography “Shopping list communication and shops identification”, depicted in Figure 5.2, can be developed by using a TDD approach. This choreography aims to submit the user shopping list to the Marketing Application, and to identify the most suitable shop (or shops). To do so, the system takes into account both the products availability and the client location (see D7.2 [22], Sect. 2 for more details). The choreography is composed of three participants, each playing a specific provider/consumer role (see D7.2 [22], Sect. 2.1.4). Basic test cases can be written for each atomic participant, based on their specification. Information needed to write such test cases include: • Operation name • Operation signature CHOReOS FP7-257178

62

• Service endpoints (WSDL URIs). Let’s consider the first task of the choreography, Get_location. This task describes the identification of the user position. To do so, the Marketing Application invokes the getLocation method provided by the Client MID owned by the client. This means that in order to write the test the following information is needed: • Operation name: getLocation • Operation signature: getLocation():Point • Service endpoints: the URL that identifies the Marketing Application and the Client MID WSDL file. According to the TDD approach, developers will have to code (or possibly adapt) each atomic service to make the tests pass. During this phase, Rehearsal features such as dynamic generation of libraries to create the service mocks of Marketing Application and the Client MID, and the related code to invoke them. This is useful in order to support an incremental approach. When services are ready and tested properly, they can be integrated to compose the choreography. Services can be also published to the ServicePot registry, together with the choreography specification. When all the services involved in the choreography become available, it is possible to test the overall behaviour of the latter. It means that developers have to verify that the expected list of stores is returned to the Client MID according to the client location and the shopping list composed and submitted to the Marketing Application. The Message Interceptor feature can be used to assess correctness of exchanged messages. Test cases can be automatically derived, e.g., by ParTes. To complete the overall process, the choreography can be assessed taking into account acceptance test (by involving end-users) and scalability test (through the Scalability Explorer). In the latter case, variables and functions modelling the problem complexity should be properly identified, e.g., complexity size is strictly related to the number of stores (Get_availability service), and performance can be basically expressed in terms of response time.

5.2.2. Run-time Testing The Rehearsal framework can support functional testing of ACRB choreographies also at run-time, thanks to its integration with CHOReOS components such as Service Registry and Synthesis Processor. In addition, V&V of ACRB use case can take advantage of ServicePot component (sect. 3.3). ServicePot, part of the CHOReOS Governance Registry, is basically a V&V enhanced registry. ServicePot can be used to publish ACRB choreographies and services in order to manage their lifecycle and exploit its different kinds of test based ranking, i.e.: • Rating services and choreographies based on automatic test suites performed on a continuous basis. This feature can provide a basis for service selection. Test cases can be derived by the ParTes component (sect. 3.4) based on the BPMN 2.0 specification of ACRB choreographies, in order to test at run-time the behavior of services with respect to the choreographies in which they play a certain role. Ratings can then be elaborated by CRank (sect. 3.5) also to improve indexing in ServicePot. • Rating service and choreography reputation based on subjective evaluation of selected actors. This feature can be exploited in order to collect user feedback on ACRB services and choreographies, and again can be used for service selection.

5.2.3. Multi-source Monitoring As for run-time monitoring, the enacted ACRB use case may exploit both infrastructure-oriented and business service message-oriented monitoring. CHOReOS FP7-257178

63

Figure 5.3: ACRB Choreography: Enter Shop and In Store Marketing & Sale (taken from D7.2 [22]) Infrastructure-oriented monitoring (sect. 4.2) collects and elaborates information about infrastructural resources (e.g., high load, low disk space), provided that resources share the same execution middleware/infrastructure (e.g., DSB). By exploiting event monitoring (sect. 4.4), ACRB can implement automatic scale up and scale down of the running cloud nodes for facing temporary request bursts, with the aim of optimising the resources allocated on the cloud infrastructure. Business service message-oriented monitoring (sect. 4.3), for message-based SOA monitoring at service and choreography level, could be particularly useful for monitoring and analyzing message exchanges taking place at different levels between services cooperating in a choreography, or between different choreographies that constitute the overall ACRB scenario. I.e., it becomes possible to monitor the behavior of services/choreographies w.r.t. their BPMN 2.0 specification. Monitoring ACRB choreographies: An example. Figure 5.3 shows the results of a test enactment of the ACRB choreography “Enter Shop and In Store Marketing & Sale”, whose service architecture is shown in Figure 5.4. This choreography aims to monitor client activity inside a store in order to propose tailored shopping offers and/or advertisements according to information such as user preferences, current shopping list etc. held by the shopping assistant application service (see D7.2 [22], Sect. 2 for more details). Figures shown in Figure 5.3 report the number of instances of each participant involved in the choreography (that in this test enactment is a set of parameters under control), as well as the overall number of invocations that took place between participants. This test run tried to resemble a real-life scenario in which 250 clients are present in the same store; setup and execution took less than 1 minute. The test enactment of this choreography leads to the following considerations: • A relatively high number of instances may operate and then have to be handled in a relatively small time frame. Infrastructure-oriented monitoring becomes particularly useful to detect possible excessive consumption of resources, expecially in ULS scenarios. A high number of message exchanges can take place between participants (see, e.g., the number of invocations between CHOReOS FP7-257178

64

Figure 5.4: ACRB Choreography: Enter Shop and In Store Marketing & Sale - Service Architecture (taken from D7.2 [22])

CHOReOS FP7-257178

65

Marketing Manager and Marketing Application). Infrastructure-oriented monitoring can help detecting possible load bursts on adopted communication channels. Moreover, message-oriented monitoring can play a key role in supporting proper management of choreography behavior by analyzing message exchanges and service invocations between participants, possibly helping focusing on the most critical ones. • Business service message-oriented monitoring can also support QoS run-time assessment (by collecting and computing QoS metrics) and SLA testing (i.e., check that SLAs are not violated). This feature can be used to regulate the choreography by monitoring selected QoS/SLAs of interactions between specific participants. Also, it can be used to show other relevant aggregated data to business users involved in the ACRB scenario. Real time data as well as business events can be shown in dedicated reports and/or dashboards which can become part of marketing managers’ and marketing directors’ user applications.

5.3. Final Remarks The implementation of the ACRB use case can take advantage of development-time WP4 V&V tools as for unit and integration testing, in an incremental (and possibly TDD based) fashion. Acceptance testing can rely on the proposed unit-testing approach but it should be properly planned because of the high number of end users involved in the ACRB scenario. The ServicePot component (and the Governance Registry in general) may play a key role in managing the lifecycle of services and choreographies involved in the ACRB use case, as well as in continuously executing specific test suites and supporting service/choreography rating. Moreover, the ACRB use case has peculiar characteristics that can help testing and monitoring at run-time some typical ULS scalability dimensions such as: • Number of different instances of available services. • Number of service consumer instances in a single choreography (i.e., for a given kind of service consumer, we may have an UL number of instances) / number of services invoked in a single choreography. • Frequency of service requests in a time period (proportional to the UL number of clients). With respect to WP4 V&V tools, these scalability dimensions can be tested by relying on the Scalability Explorer (provided that proper functions for complexity size, performance metric and architecture capability can be defined for the ACRB scenario) or require more focused test planning involving, e.g., multi-source monitoring features. The enacted ACRB use case may exploit both infrastructure-oriented and business service messageoriented monitoring. Event monitoring will allow for the implementation of automatic scale up and scale down of the running cloud nodes for facing temporary request bursts, so to optimize allocation of resources on the cloud infrastructure. Moreover, through business service message-oriented monitoring, the behavior of ACRB services and choreographies can be monitored w.r.t. their BPMN 2.0 specification, and the supported QoS and SLA testing/assessing features can be leveraged in order to aggregate data to be shown to selected users according to the goals of the use case. Some use case dimensions could require ah hoc efforts in order to be tested, such as: • Seamless testing of both SOAP and REST Web services. • Multichannel interactions. • Full context awareness. • Non-functional properties (accuracy, adaptability, maintainability, security etc.), e.g., expressed by means of Q4BMPN annotations (sect. 2.2). CHOReOS FP7-257178

66

It will be possible to conduct more quantitative analysis in the next stages of the project, in particular as for exploiting WP4 monitoring tools while enacting the overall ACRB scenario.

CHOReOS FP7-257178

67

CHOReOS FP7-257178

68

6 Conclusions This deliverable reports about the status of work done within WP4 at Month 24. We describe the refined architecture and the tools of the CHOReOS Governance and V&V framework, and provide the accompanying documentation to the released software components. The presentation of the developed components is here organized into three main classes. The first one, referred to as Development time, includes the Rehearsal testing framework presented in Chapter 2. In particular the tool supports service and choreography developers in the testing, coding and execution activities in order to support a Test-Driven Development approach for choreography modeling. The framework also provides mechanisms for either mocking up web services, or invoking them in their real environments. Rehearsal includes the Scalability Explorer component (evolved from the Scalability testing approach presented in D4.2.1) that assists developers in checking how a choreography can scale up according to defined performance metrics for future improvements. Chapter 2 also reports the newly proposed Q4BPMN profile, allowing for annotating the choreography specification in BPMN2 with non-functional requirements. A second class of components includes tools supporting the governance and testing activities to be carried out at run-time. The CHOReOS Governance framework is centered around a Governance Registry for the publication and discovery of heterogeneous resources such as services, SLAs, and choreographies. The registry is extensible and is synchronized with the CHOReOS run-time middleware, thus enabling to govern the resources lifecycle from design to run-time. On-line testing of services playing a role within a choreography is based on ServicePot, a framework which enables the testing of services in association to their request for registration within a service registry, and ParTes, a tool for the automatic derivation of test cases from choreography specification. This tool permits to derive test cases useful to assess services at run-time with respect to the role they are called to play, within run-time enacted choreographies. Finally, we also provide the CRank component that uses test cases results to rank services and choreographies. This information is useful to improve the service selection process and to put in place policies concerning service lifecycle activities related to those services made available by the corresponding service provider. Furthermore such rating can be used in order to deal with properties on the whole choreography (e.g. determining if a choreography is “enactable”). The third class of V&V activities that CHOReOS supports refers to monitoring. In this respect, Chapter 4 provides details about the three monitoring components collecting run-time information from different sources. Along with the description of each software component, emphasis has been put on scalability concerns, as expressly requested by the reviewers. Therefore, we have included a discussion in tabular form of concerns about scalability along the different dimensions identified within the CHOReOS project. The deliverable provides also a preview of how the effectiveness of the Governance and V&V tools can be assessed on one of the CHOReOS Use Cases, namely the WP7 Adaptive Customer Relationship Booster (ACRB). The analysis mainly takes into account the use case design in terms of choreographies and related services, things and people involved, scale parameters, as described in Deliverables D7.1 [36] and D7.2 [22] and discusses if and how the tools should be applied to it. ˜ Paulo to In Appendix A, we also report the results from an exploratory study at the University of Sao assess the application of Rehearsal. The APIs for all the tools here described are then also included, whereas the source code is stored and can be retrieved from the CHOReOS repository as detailed in CHOReOS FP7-257178

69

Tool Rehearsal ServicePot ParTes CRank GLIMPSE SLA&LifecycleManagement Business Service Monitoring Platform Monitoring

Source Location governance/tdd/rehearsal governance/servicepot governance/v and v/partes governance/v and v/crank governance/component-glimpse governance/sla and lifecycle manager monitoring/new-bsm-distribution-choreos cloud/Monitoring

Table 6.1: WP4 tool repositories list Table 6.1. In such a table, we report links to the sources hosted in the CHOReOS SVN repository: svn.forge.objectweb.org/svnroot/choreos/trunk/ While the released framework is already in advanced status, the R&D activity in WP4 is continuing. As planned in the DOW, we will release the final versions for all the above tools and the supporting infrastructure at M30 (Deliverable D4.3), and will carry out their evaluation to be completed at M36 (Deliverable D4.4). Therefore, in the next months we will continue the refinement of the tools presented here, especially considering their integration within the CHOReOS development process as described in D2.2 [3] and over the CHOReOS middleware as described in D3.2.2 [13]. In parallel, we have already started to plan for integrated demonstrations and assessment of the developed tools within the project scenarios. Here we have described how the tools can be applied to WP7, and we have also developed demonstrations for some of the released tools on the WP6 use case. This activity has to be expanded and integrated in cooperation with the whole consortium.

CHOReOS FP7-257178

70

Bibliography [1] Drools fusion: Complex drools-fusion.html.

event

processor.

http://www.jboss.org/drools/

[2] Ruleml: The rule markup initiative. http://ruleml.org. [3] Marco Autili and Davide Di Ruscio, editors. Definition of the Dynamic Development Process for Adaptable QoS-aware ULS Choreographies. Number Del. D2.2. The CHOReOS Consortium, 2012. [4] Marco Autili and Davide Di Ruscio, editors. CHOReOS perspective on the Future Internet and initial conceptual model. Number Del. D1.2. The CHOReOS Consortium, 2011. [5] Matteo Baldoni, Cristina Baroglio, Alberto Martelli, Viviana Patti, and Claudio Schifanella. Service selection by choreography-driven matching. In Thomas Gschwind et al., editors, Emerging Web Services Technology, Vol. II, pages 5–22. Birkhuser Basel, 2008. [6] S. Banerjee, S. Basu, S. Garg, S. Garg, S.J. Lee, P. Mullan, and P. Sharma. Scalable grid service discovery based on uddi. In Proceedings of the 3rd international workshop on Middleware for grid computing, pages 1–6. ACM, 2005. [7] Cesare Bartolini, Antonia Bertolino, Andrea Ciancone, Guglielmo De Angelis, and Raffaela Mirandola. Non-functional analysis of service choreographies. In Proceedings of the 4th International Workshop on Principles of Engineering Service-Oriented Systems (PESOS), 34th International Conference on Software Engineering (ICSE), Zurich, Switzerland, June 2012. IEEE-CS. [8] Cesare Bartolini, Antonia Bertolino, Andrea Ciancone, Guglielmo De Angelis, and Raffaela Mirandola. Quality requirements for service choreographies. In Proceedings of the 8th International Conference on Web Information Systems and Technologies (WEBIST), Porto, Portugal, April 2012. [9] Cesare Bartolini, Antonia Bertolino, Sebastian Elbaum, and Eda Marchetti. Whitening SOA testing. In Proceedings of the the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT Symposium on The foundations of software engineering, ESEC/FSE ’09, pages 161–170, New York, NY, USA, 2009. ACM. [10] Cesare Bartolini, Antonia Bertolino, Eda Marchetti, and Andrea Polini. WS-TAXI: A WSDL-based Testing Tool for Web Services. Software Testing, Verification, and Validation, 2008 International Conference on, 0:326–335, 2009. [11] Amira Ben Hamida, editor. D5.2 : Specification of the CHOReOS IDRE. Number Del. D5.2. The CHOReOS Consortium, 2011. ` Guglielmo De Angelis, Nelson Lago, [12] Amira Ben Hamida, Antonia Bertolino, Antonello Calabro, and Julien Lesbegueries. Monitoring service choreographies from multiple sources. In Proc. of SERENE, 2012. – to appear. [13] Amira Ben Hamida and Fabio Kon, editors. D3.2.2 : CHOReOS Middleware Implementation. Number Del. D3.2.2. The CHOReOS Consortium, 2012. CHOReOS FP7-257178

71

[14] Antonia Bertolino, Guglielmo De Angelis, and Andre Polini. (role)CAST: A Framework for On-line Service Testing. In 7th Internation Conference on Web Information Systems and Technologies, WEBIST, Noordwijkerhout, Netherlands, 2011. [15] Antonia Bertolino, Guglielmo De Angelis, and Andrea Polini, editors. Governance V&V policies and rules. Number Del. D4.1. The CHOReOS Consortium, 2011. [16] Antonia Bertolino, Guglielmo De Angelis, and Andrea Polini, editors. “V&V tools and infrastructure” – strategies, architecture and implementation”. Number Del. D4.2.1. The CHOReOS Consortium, 2012. [17] Antonia Bertolino, Guglielmo De Angelis, and Andrea Polini. Validation and verification policies for governance of service choreographies. In Proc. of the 8th International Conference on Web Information Systems and Technologies (WEBIST 2012), Porto, Portugal, Apr. 2012. SciTePress. [18] Felipe M. Besson, Pedro M.B. Leal, Fabio Kon, Alfredo Goldman, and Dejan Milojicic. Supporting Test-Driven Development of Web Service Choreographies. In The 5th International Open Cirrus Summit, Moscow, Russia, 2011. [19] Felipe M. Besson, Pedro M.B. Leal, Fabio Kon, Alfredo Goldman, and Dejan Milojicic. Towards automated testing of web service choreographies. In Proceeding of the 6th international workshop on Automation of software test, AST ’11, pages 109–110, Waikiki, Honolulu, HI, USA, 2011. ACM. [20] Sujit K. Chakrabarti and Prashant Kumar. Test-the-REST: An Approach to Testing RESTful WebServices. In Future Computing, Service Computation, Cognitive, Adaptive, Content, Patterns, 2009. COMPUTATIONWORLD ’09. Computation World, pages 302 –308, nov. 2009. [21] Francesco De Angelis, Andrea Polini, and Guglielmo De Angelis. A counter-example testing approach for orchestrated services. In Proceedings of the 2010 Third International Conference on Software Testing, Verification and Validation, ICST ’10, pages 373–382, Washington, DC, USA, 2010. IEEE Computer Society. [22] Daniele Dell’Aglio and Luigi Lavazza, editors. “Mobile-enabled coordination of people” – service & choreographies design. Number Del. D7.2. The CHOReOS Consortium, 2012. ` Francesca Lonetti, and [23] Antinisca Di Marco, Claudio Pompilio, Antonia Bertolino, Antonello Calabro, Antonino Sabetta. Yet another meta-model to specify non-functional properties. In Proceedings of the International Workshop on Quality Assurance for Service-Based Applications, QASBA ’11, pages 9–16, New York, NY, USA, 2011. ACM. [24] Valerie J. Easton. Statistics glossary v1.1, 1997. [25] Marcelo Medeiros Eler, Marcio Eduardo Delamaro, Jose Carlos Maldonado, and Paulo Cesar Masiero. Built-In Structural Testing of Web Services. In Proceedings of the 2010 Brazilian Symposium on Software Engineering, SBES ’10. IEEE Computer Society, 2010. ˜ Simone do Rocio Senger de Souza, and Paulo [26] Andre´ Takeshi Endo, Adenilso da Silva Simao, Sergio Lopes de Souza. Web Services Composition Testing: A Strategy Based on Structural Testing of Parallel Programs. In Proceedings of the Testing: Academic and Industrial Conference - Practice and Research Techniques, TAIC-PART ’08. IEEE Computer Society, 2008. [27] Eviware. SoapUI, Web Services Functional Testing Tool. Available on: http://http://www. soapui.org/, 2010. [28] Vincenzo Grassi, Raffaela Mirandola, Enrico Randazzo, and Antonino Sabetta. Klaper: An intermediate language for model-driven predictive analysis of performance and reliability. In Andreas Rausch, Ralf Reussner, Raffaela Mirandola, and Frantisek Plasil, editors, CoCoME, volume 5153 of Lecture Notes in Computer Science, pages 327–356. Springer, 2007. CHOReOS FP7-257178

72

[29] Michaela Greiler, Hans-Gerhard Gross, and Arie van Deursen. Evaluation of online testing for services: a case study. In Proceedings of the 2nd International Workshop on Principles of Engineering Service-Oriented Systems, PESOS ’10, pages 36–42. ACM, 2010. [30] San-Yih Hwang, Wen-Fan Hsieh, and Chien-Hsiang Lee. Verifying web services in a choreography environment. In SOCA. IEEE, 2011. [31] Valerie Issarny, editor. Description of the CHOReOS conceptual model and architectural style and their relation with the CHOReOS development process and related method, tools and middleware. Number Del. D1.4. The CHOReOS Consortium, 2012. [32] Barbara Kitchenham. Desmet: A method for evaluating software engineering methods and tools. Technical Report TR96-09, University of Keele - Department of Computer Science, 1996. [33] Nuno Laranjeiro, Marco Vieira, and Henrique Madeira. A Robustness Testing Approach for Soap Web Services. Journal of Internet Services and Applications, 4, 2012. ` [34] Luigi Lavazza, Gianmarco Panza, Riccardo Mazza, Lorenzo Coletti, F. Messina, and G. Rubio, editors. “Validation test plan of the ‘Adaptive Customer Relationship Booster’ use case”. Number Del. D7.3. The CHOReOS Consortium, 2012. [35] Philip Mayer and Daniel Lubke. Towards a BPEL unit testing framework. In Proceedings of the ¨ 2006 workshop on Testing, analysis, and verification of web services and applications, TAV-WEB ’06, pages 33–42, New York, NY, USA, 2006. ACM. [36] Riccardo Mazza, editor. “Mobile-enabled coordination of people” – requirements, specification and use case definition. Number Del. D7.1. The CHOReOS Consortium, 2012. [37] Object Management Group. Business Process Model and Notation (BPMN) Version 2.0, 2010. [38] OSGi Alliance. OSGi Service Platform Release 4. [Online]. Available: http://www.osgi.org/ Main/HomePage. [Accessed: May 19, 2012], 2007. [39] Pi4 Technologies Foundation. Pi4soa - pi calculus for SOA. sourceforge.net/projects/pi4soa/, 2010.

Available on:

http://

[40] Federico D. Sacerdoti, Mason J. Katz, Matthew L. Massie, and David E. Culler. Wide area cluster monitoring with ganglia. In Proceedings of the IEEE International Conference on Cluster Computing, page 289298, 2003. [41] Carolyn B. Seaman. Qualitative Methods in Empirical Studies of Software Engineering. IEEE Trans. Softw. Eng., 25:557–572, July 1999. [42] Zheng Wang, Lei Zhou, Yongxin Zhao, Jing Ping, Hao Xiao, Geguang Pu, and Huibiao Zhu. Web Services Choreography Validation. Service Oriented Computing Applications, 4, 2010. [43] Jia Zhang. A Mobile Agent-Based Tool Supporting Web Services Testing. Wireless Personal Communications, 56:147–172, 2011.

CHOReOS FP7-257178

73

CHOReOS FP7-257178

74

A Exploratory Study on the TDD methodology To assess Rehearsal and the TDD methodology proposal, we have conducted an exploratory study in two phases with students of Computer Science at the Institute of Mathematics and Statistics of the ˜ Paulo. The first phase was conducted with 8 Masters or PhD students. All students University of Sao had good knowledge in web service compositions and Test-Driven Development (TDD). The first phase focused on assessing the efficacy and adequacy of Rehearsal and the proposed methodology in the context of web service choreography development. To achieve this goal, the following research questions have been defined:

RQ1: Does the Rehearsal features aid in the application of the proposed methodology steps? RQ2: Does the proposed methodology provide adequate guidelines for developing a choreography?

After this first validation phase, Rehearsal and the TDD methodology was refined based on the feedback received. Then, in the second phase, a similar exploratory study was conducted. In this second phase, the goal was to assess the Rehearsal and the TDD methodology effectiveness when they are applied by non-specialist developers. To achieve this, the subjects of this phase were 8 undergraduate students, 3 masters and 1 PhD student. All students had basic or no knowledge of SOA. Then, on the second phase, the following research questions have been defined: RQ1: How easy is to use the Rehearsal features to apply the methodology steps? RQ2: How easy is to follow the methodology steps to develop a choreography?

A.1. Organization Both phases have been designed following the guidelines of similar studies [41, 32]. Since Rehearsal and the proposed methodology introduces novel concepts in the our research theme, we decided to apply an exploratory study to identify benefits and problems in the use of both artefacts. Besides, qualitative data is more adequate to identify these benefits and problems from the developer perspective. Before each phase of our study, we developed a systematic protocol that defined the study steps depicted in Figure A.1. This protocol as well as all elements (questionnaires, produced code, interview audio) belonging to the both phases are organized in a study package that is available through the url: http://ccsl.ime.usp.br/baile/VandV#rehearsal-study. In the training part, the participants received a practical course of TDD, web service compositions, Rehearsal and related topics. In the development part, the participants worked in pairs to develop a choreography in 4 development tasks. Each phase corresponded to each TDD methodology step. Finally, we collect the results through questionnaires. These results are presented in the next section.

CHOReOS FP7-257178

75

Figure A.1: Exploratory Study Steps

A.2. Qualitative Results Our qualitative results have been presented in box plots using a percentile function to extract the numbers of the positions representing 25% and 75% of the ordered data set. These charts also contain the Whisker points [24] that represents the minimum and the maximum values presented in the sample (data set). This way, we can easily visualize the highest and lowest answers as well as how dispersed the answers are. As defined in the study protocols, we proposed to analyze groups of similarity in isolation. For each group we present in a table the studied questions and charts related to them.

A.2.1. Dynamic generation of web service clients ID

Question

QR1 QM3 (p1) QM3 (p2) QM13 (p1) QM13 (p2)

It was easy to learn how to use the WSClient feature. The use of the WSClient feature is useful in Task 01. It was easy to use the WSClient feature in Task 01. The use of the WSClient feature is useful in Task 04. It was easy to use the WSClient feature is useful in Task 04. p1 = phase 01 and p2 = phase 02

Table A.1: Questions to study WSClient feature

Figure A.2: WSClient - Phase 1

Figure A.3: WSClient - Phase 2

In the first phase, as can be seen in Figure A.2, all answers were the options 4 or 5. According to the box plot depicted in Figure A.2, all subjects strongly agreed that WSClient is an useful tool for applying the first methodology phase (QM3 question), and almost all of them, strongly agreed it is also efficacy in the acceptance testing which is presented in the fourth phase of our methodology (QM13 question). As can be seen in Figure A.3, in the case of the second phase, we had similar results. Although we have had some answers for the option 3 (“indifferent”), the most part of answers were the options 4 or 5.

CHOReOS FP7-257178

76

ID QR2 QM6 (p1) QM6 (p2)

Question It was easy to learn how to use the WSMock feature. The use of the WSMock feature is useful in Task 02. It was easy to use the WSMock feature in Task 02. p1 = phase 01 and p2 = phase 02

Table A.2: Questions to study the web service mocking feature

Figure A.4: WSMock - Phase 1

Figure A.5: WSMock - Phase 2

A.2.2. Web service mocking In the first phase, even though almost all of the subjects have strongly agreed that this feature is useful for applying the Task 02 (QM6 question), they apparently had problems to learn this feature. As can be seen in Figure A.4, the median for the QR2 question was 4, which means that learning this feature was not so easy for the most part of the subjects. In the second phase, half of students had no problems in learning how to use and applying this feature in the Task 02. According to the students, in the interviews, learning the feature for its own is not a problem but use it in real situations is not trivial.

A.2.3. Message interceptor ID QR3 QM7 (p1) QM7 (p2) QM10 (p1) QM10 (p2)

Question It was easy to learn how to use the Message Interceptor feature. The use of the Message Interceptor feature is useful in Task 02. It was easy to use the Message Interceptor feature in Task 02. The use of the Message Interceptor feature is useful in Task 03. It was easy to use the Message Interceptor feature in Task 03. p1 = phase 01 and p2 = phase 02

Table A.3: Questions to study the message interceptor feature According to the box plot presented in Figure A.6, all of the subjects strongly agreed that the message interceptor is useful for validating messages exchanged between the choreography roles (QM10 question). Almost all of them strongly agreed that this feature is also useful for validating the messages exchanged inside the role, which was applied in the Task 02 of our study (QM7 question). Regarding the QR3 question, we had similar results to those we had for the WSMock feature. In the second phase, we had also good results. Although we had some bad results (answer 2 for all questions), more than 75% of the students strongly agreed or agreed that was easy to use the Message Interceptor.

CHOReOS FP7-257178

77

Figure A.6: Message Interceptor - Phase 1 ID QR4 QR5 QR6

Figure A.7: Message Interceptor - Phase 2

Question It was easy to learn how to use the Abstraction Choreography feature. The Abstraction Choreography feature helped me to use other Rehearsal features. The Abstraction Choreography feature helped me to write the test cases.

Table A.4: Questions to study the abstraction of choreography feature

Figure A.8: Abstract of Choreography - Phase 1 Figure A.9: Abstract of Choreography - Phase 2

A.2.4. Abstraction of choreography In both study phases, for this feature, we had negative results. In the first phase, as can be seen in the Figure A.8, not the most part of, but some subjects had problems to learn how to use this feature (QR4 question). Although this feature has not always helped to use the other Rehearsal features (QR5 question), it has helped the subjects to write the test case in almost all cases (QR6 question). For this last question, the median was 4 in the second phase, and around 4 in the first phase, we had as the lowest value the option 3 (“indifferent”), but we had no negative results. Then, although it can be difficult to learn and use, the abstraction of choreography is useful in the choreography development.

A.2.5. Methodology and Rehearsal acceptance We had good results for questions related to the adequacy and easiness in follow the methodology steps. In addition to these analyses, in the first phase of the study, we investigated the methodology acceptance in terms of how it is suitable in SOA projects that the subjects have participated. The questions related to this topic are presented in Figure A.5. The answers obtained for these questions are presented in Figure A.10. According to the data depicted in Figure A.10, we had only positive results. Even though only one CHOReOS FP7-257178

78

ID QM14 QM15

Question I think the use of the methodology and Rehearsal would be useful for projects I have participated. I would use the methodology and Rehearsal in future projects I may participate.

Table A.5: Questions to study the acceptance of the proposed methodology

Figure A.10: Answers Obtained for the Questions of Table A.5 subject strongly agreed to the QM15 statement, the most part of subjects would use the methodology hereafter. In the case of QM14 question, we had similar results which means that Rehearsal and methodology steps can be adequate to solve problems that the developers have been faced.

A.3. Quantitative Results Besides the qualitative results presented, we calculated the linear correlation between two variables: time spent for each team to complete all development tasks (v2) and the team experience in traditional software development (v1). In the Table A.6, we present the time and experience of the teams selected for this analysis. Team team 1 team 2 team 2 team 3 team 4 team 5

Experience (in years) Class Phase 1 more than 5 3 more than 5 3 Phase 2 3-5 2 1-3 1 1-3 1 1-3 1

Time (in minutes) 140 155 221 274 275 334

Table A.6: Experience and time taken with the development Given the low number of samples, we applied a non-parametric test, which is recommended in these cases. In this kind of test, there are no presumptions about the population distribution. In this linear correlation, we applied the Kendall’s method to the vectors x = c(3, 3, 2, 1, 1, 1), classes of Table A.6, and y = c(140, 155, 221, 274, 275, 334), that represents the user experience. Then, the result was -0.700649 with p-value 0.10. In this case, we can say that exists a strong linear correlation between the studied variables (v1 and v2), and this correlation is inverse. The higher the experience, the less time taken to complete the tasks. This analysis is not complete and its goal consists of supporting the qualitative analysis conducted in the study. As a future work, a more complete quantitative analysis must be conducted. However, this linear correlation introduces evidences that the knowledge in web service compositions may not be CHOReOS FP7-257178

79

determinant to use Rehearsal and the methodology properly.

A.4. Conclusions In both phases, the participants complete all development tasks correctly. In terms of the functional code, all teams developed the choreography correctly. In terms of the test cases, a few errors were detected. In the first phase, only one of the eleven test cases that each team had to developed was implemented incorrectly. In the second phase, only 2 test cases have been implemented incorrectly. Regarding the questionnaire results, apart from abstraction of choreography feature, we had positive results for all Rehearsal features. As a future work, this feature will be improved to let the process of describing a choreography easier. In the case of methodology, we can conclude that we had good results in terms of its efficacy and adequacy.

CHOReOS FP7-257178

80

B Resource Lyfe-cycle Manager : API B.1. Resources Managers The diagram reported in Figure B.1 shows the managers for the resource lyfecycle management and it is taken from Section 3.2 to be used as a reference with respect to the components API presented in the following.

Figure B.1: Managers

ResourceAnalyzerManager The functions provided by the ResourcesAnalyzerManager are the following: ResourceAnalyzerManager() addResourceAnalyzerService(AbstractResourceAnalyzerService) analyse ( Document : Map : ) clear() getAllResourceType () get( QName, ResourceType ) : Resource() findResourceType (String) addResourceAnalyzerService (AbstractResourceAnalyzerService) ResourcesManager The functions provided by the ResourcesManager are the following: ResourcesManager (Configuration get (Get ) detectSyntaxSimilarity (String : String : ) remove(Remove) () publish (Document : Map : ) CHOReOS FP7-257178

81

getAllByResourceType (ResourceType ) addResourceAnalyzerService (AbstractResourceAnalyzerService) findResourceType (String : ) ResourceType getAllResourceType ( ) : List analyse (Document : Map : ) List remove (QName : ResourceType : ) Resource clear ( ) void store ( Resource : ) getNumberOfResources ()

ServicesManager The functions provided by the ServicesManager are the following: ServicesManager (ResourcesManager ) findEndpoints (String ) findInterfaces (String) findServices (String ) getEndpoint (QName ) getInterface (QName ) : getService (QName) publishWSDL (PublishWSDL ) StorageService The functions provided by the StorageService are the following: clear() find(String, ResourceType) get(QName, ResourceType) getAllByResourceType(ResourceType) getNumberOfResources() store(Resource) unstore(QName, ResourceType)

B.2. Core Resource Registry Configuration The functions provided by the Configuration are the following: getHost ( ) getNotificationPort ( )

ConnectionManager The functions provided by the ConnectionManager are the following: clear ( ): : shutDown ( ): : init ( ): : getInstance ( ): :

CoreManager The functions provided by the CoreManager are the following: CoreManagerImpl(Configuration) getResourcesManager clear () getConfiguration () CHOReOS FP7-257178

82

Figure B.2: CoreManager setConfiguration(Configuration) getConnexionManager ()

CHOReOS FP7-257178

83

CHOReOS FP7-257178

84

C ServicePot: API C.1. Choreography storage and retrieval ServicePot uses TModels to store information about choreographies and the roles in the choreographies. Figure C.1 shows this mapping between BPMN 2.0 concepts and UDDI concepts The overall structure of ChorDDI is expressed in Figure C.2 and explained below: AddChoreographyParticipantIn getAuthInfo (): : String: get the UDDI AuthInfo for this object setAuthInfo ( authInfo : String ): set the UDDI AuthInfo for this object

:

void :

getBusinessServiceKey ( ): : String : get Key for existing BusinessService to add as a participant setBusinessServiceKey ( businessServiceKey : set Key for existing BusinessService to add as a participant

String ):

:

void :

getChoreographyKey ( ): : String : get Key for Choreography, for which to add a participant setChoreographyKey ( choreographyKey : String ): set Key for Choreography, for which to add a participant

:

void :

getNewService ( ): : SaveService : get new BusinessService to create as a participant setNewService ( newService : SaveService ): set new BusinessService to create as a participant

:

void :

getRoleKeys ( ): : List : get role key to assign to the participant setRoleKeys ( roleKeys : List ): set role key to assign to the participant

:

void :

FindParticipantsIn getParticipantCriteria ( ): : FindService : get search criteria to find participant services setParticipantCriteria ( participantCriteria : set search criteria to find participant services getRoleKeys ( ): CHOReOS FP7-257178

:

FindService ):

:

void :

List :

85

Figure C.1: ServicePot: Mapping of BPMN2 Concepts to UDDI

Figure C.2: ServicePot: The ChorDDI Component

CHOReOS FP7-257178

86

get roles for which to find participant services setRoleKeys ( roleKeys : List ): set roles for which to find participant services

void :

:

ICHOReOSInquiry FindChoreographies ( findChreographiesIn : Finds choreographies matching the specified criteria

FindTModel ):

TModelList :

:

GetChoreographyDetails ( getChereogaphyDetailsIn : GetTModelDetail): Returns the details for the specified choreography

:

TModelDetail

GetRolesInChoreography ( getRolesInChoreography : GetTModelDetail ): Returns the list of roles int he choreography

:

TModelList :

FindParticipants ( findParticipantsIn : Find participants of a Choreography.

FindParticipantsIn ):

:

:

ServiceList:

ICHOReOSPublish SaveChoreography ( saveChoreographyIn : SaveChoreographyIn ): : TModelDetail: Save a Choreography to the underlying UDDI registry. The input type contains the URI of the choreography specification, and the name of the choreography in case many choreographies are present in the specification AddChoreographyParticipant ( addChoreographyParticipantIn : AddChoreographyParticipantIn ): Adds a new or existing Service as a participant to the choreography. AddRolesToParticipant ( addRoleToParticipantIn : RolesAndParticipantIn ): : Add roles to a Service which is already a participant of a choreography RemoveRolesFromParticipant ( removeRoleFromParticipantIn : Removes roles form the participants

RolesAndParticipantIn ):

RemoveChoreography ( removeChoreographyIn : Removes the choreography from the registry

:

ServiceDetail:

ServiceDetail :

:

DeleteTModel ):

ServiceDetail : :

void :

RolesAndParticipantIn getAuthInfo ( ): : String : get UDDI AuthInfo for this operation setAuthInfo ( authInfo : String ): set UDDI AuthInfo for this operation

:

void :

getRoles ( ): : List : get roles for this operation setRoles ( roles : List ): set roles for this operation getServiceKey ( ): CHOReOS FP7-257178

:

:

void :

String :

87

get ServiceKey for this operation setServiceKey ( serviceKey : set ServiceKey for this operation

String ):

:

void :

SaveChoreographyIn getChoreographyName ( ): : String : get Chreography Name for this operation setChoreographyName ( ChoreographyName : set Choreography Name for this operation

String ):

:

void :

getChoreographyURI ( ): : String : get Choreography URI for this operation setChoreographyURI ( ChoreographyURI : String ): get Choreography URI for this operation

:

void :

getAuthInfo ( ): : String : get AuthInfo for this operation setAuthInfo ( authInfo : set AuthInfo for this operation

String ):

:

void :

C.2. Extensibility in ServicePot Accroding to Section 3.3, GovernancePool is the component providing extensibility for servicepot. The API available within the ServicePot plugins are depicted in Figure C.3, and explained below. CHOReOSInquiryMonitor beforeGetRolesInChoreography ( getRolesInChoreography : GetTModelDetail ): : void : This method is invoked just after a request to Get all roles in a Choreography is received. beforeFindChoreographies ( findChreographiesIn : FindTModel ): This method is invoked just after a request to find choreographies is received

:

void :

afterFindChoreographies ( findChreographiesOut : TModelList ): This method is invoked before returning the list of found choreographies to the user

:

void :

beforeGetChoreographyDetails ( getChereogaphyDetailsIn : GetTModelDetail ):

:

void :

afterGetChoreographyDetails ( getChereogaphyDetailsOut : TModelDetail ): : void : This method is invoked before returning the Choreography Details to the user afterGetRolesInChoreography ( getRolesInChoreography : TModelList ): : This method is invoked before returning the list of Roles ina choreography to the user

:

void

beforeFindParticipants ( findParticipantsIn : FindParticipantsIn ): : void : This method is invoked just after a request to find participants in a choreography or multiple choreographies is received CHOReOS FP7-257178

88

Figure C.3: ServicePot: Plugin Interfaces and Events

CHOReOS FP7-257178

89

afterFindParticipants ( findParticipantsIn : ServiceList ): : void : This method is invoked before returning the list of found participants in a choreography or multiple choreographies to the user CHOReOSPublishMonitor beforeSaveChoreography ( saveChoreographyIn : SaveChoreographyIn ): : This method is invoked immediately after the request for saving a Choreography is received.

:

void

afterProcessChoreography ( choreographiesAndRoles : Map ): : void : This method is invoked after a Choreography has been processed from BPMN2 xml into Choreography and Role TModels. The parameter is a Map with Choreography TModel as Key and List of Role TModels as value afterSaveChoreography ( saveChoreographyOut : TModelDetail ): : void : This method is invoked after the Choreography and Role TModels have been committed to the UDDI registry beforeAddChoreographyParticipant ( addChoreographyParticipantIn : AddChoreographyParticipantIn ): : void : This method is invoked just after a request to register or modify a service as a choreography participant is received afterAddChoreographyParticipant ( addChoreographyParticipantOut : ServiceDetail ): : This method is invoked after a Choreography Participant has been added

void :

beforeAddRolesToParticipant ( addRoleToParticipantIn : RolesAndParticipantIn ): : void : This method is invoked just after a request to add Roles to an existing participant is received afterAddRolesToParticipant ( addRoleToParticipantOut : ServiceDetail ): : void : This method is invoked just after roles have been added to an existing Choreography Participant beforeRemoveRolesFromParticipant ( removeRoleFromParticipantIn : RolesAndParticipantIn ): : void : This method is invoked just after a request to remove Roles from a choreography is received afterRemoveRolesFromParticipant ( removeRoleFromParticipantOut : ServiceDetail ): : void : This method is invoked just after Roles have been removed from the participants. beforeRemoveChoreography ( removeChoreographyIn : DeleteTModel ): This method is invoked just after a request to remove a choreography is received

:

void :

afterRemoveChoreography ( ): : void : This method is invoked just after a choreography has been removed from the UDDI registry ServicePotPluginInterface This is a tagging interface for all ServicePot plugins. UDDIInquryMonitor beforeGetBindingDetail ( body : CHOReOS FP7-257178

GetBindingDetail ):

:

void :

90

this is invoked after a GetBindingDetail request is received afterGetBindingDetail ( output : BindingDetail ): this is invoked before the GetBindingDetail response is returned

void :

:

beforeGetServiceDetail ( body : GetServiceDetail ): this is invoked after a GetServiceDetail request is received afterGetServiceDetail ( body : ServiceDetail ): this is invoked before the GetServiceDetail response is returned

void :

void :

:

afterFindBinding ( body : BindingDetail ): this is invoked before the FindBinding response is returned

:

void :

afterGetTModelDetail ( body : TModelDetail ): : this is invoked before the GetTModelDetail response is returned beforeFindBinding ( body : FindBinding ): this is invoked after a FindBinding request is received

void :

:

beforeGetTModelDetail ( body : GetTModelDetail ): this is invoked after a GetTModelDetail request is received

void :

:

void :

:

beforeFindBusiness ( body : FindBusiness ): this is invoked after a FindBusiness request is received

:

afterFindBusiness ( body : BusinessList ): : this is invoked before the FindBusiness response is returned

void : void :

beforeFindRelatedBusinesses ( body : FindRelatedBusinesses ): this is invoked after a FindRelatedBusinesses request is received afterFindRelatedBusinesses ( body : RelatedBusinessesList ): this is invoked before the FindRelatedBusinesses response is returned beforeGetBusinessDetail ( body : GetBusinessDetail ): this is invoked after a GetBusinessDetail request is received afterGetBusinessDetail ( body : BusinessDetail ): this is invoked before the GetBusinessDetail response is returned beforeFindTModel ( body : FindTModel ): this is invoked after a FindTModel request is received

:

:

void :

: :

void :

void :

:

void :

void :

afterFindTModel ( body : TModelList ): : void : this is invoked before the FindTModel response is returned void :

beforeGetOperationalInfo ( body : GetOperationalInfo ): this is invoked after a GetOperationalInfo request is received

:

afterGetOperationalInfo ( body : OperationalInfos ): this is invoked before the GetOperationalInfo response is returned

void :

beforeFindService ( input : FindService ): this is invoked after a FindService request is received

:

void :

afterFindService ( output : ServiceList ): this is invoked before the FindService response is returned

:

void :

:

UDDIPublicationMonitor afterDeleteBinding ( ): : void : this is invoked before DeleteBinding the response is returned CHOReOS FP7-257178

91

beforeSaveTModel ( body : SaveTModel ): this is invoked after a SaveTModel request is received

void :

:

beforeDeleteBinding ( body : DeleteBinding ): this is invoked after a DeleteBinding request is received

void :

:

void :

afterSaveTModel ( body : TModelDetail ): : this is invoked before the SaveTModel response is returned

afterAddPublisherAssertions ( ): : void : this is invoked before the AddPublisherAssertions response is returned beforeAddPublisherAssertions ( body : AddPublisherAssertions ): this is invoked after a AddPublisherAssertions request is received beforeDeleteBusiness ( body : DeleteBusiness ): this is invoked after a DeleteBusiness request is received

:

void :

void :

:

afterDeleteBusiness ( ): : void : this is invoked before the DeleteBusiness response is returned beforeSaveService ( body : SaveService ): this is invoked after a SaveService request is received

void :

:

void :

afterSaveService ( body : ServiceDetail ): : this is invoked before the SaveService response is returned

beforeDeletePublisherAssertions ( body : DeletePublisherAssertions ): : void : this is invoked after a DeletePublisherAssertions request is received afterDeletePublisherAssertions ( ): : void : this is invoked before the DeletePublisherAssertions response is returned beforeSetPublisherAssertions ( authInfo : String publisherAssertion : Holder ): this is invoked after a SetPublisherAssertions request is received

:

void :

:

void :

afterSetPublisherAssertions ( ): : void : this is invoked before the SetPublisherAssertions response is returned beforeGetPublisherAssertions ( authInfo : String ): this is invoked after a GetPublisherAssertions request is received

afterGetPublisherAssertions ( body : List ): : void : this is invoked before the GetPublisherAssertions response is returned beforeDeleteService ( body : DeleteService ): this is invoked after a DeleteService request is received

void :

:

afterDeleteService ( ): : void : this is invoked before the DeleteService response is returned beforeSaveBinding ( body : SaveBinding ): this is invoked after a SaveBinding request is received

void :

:

void :

afterSaveBinding ( body : BindingDetail ): : this is invoked before the SaveBinding response is returned beforeSaveBusiness ( body : SaveBusiness ): this is invoked after a SaveBusiness request is received afterSaveBusiness ( body :

CHOReOS FP7-257178

BusinessDetail ):

void :

: :

void :

92

this is invoked before the SaveBusiness response is returned beforeGetRegisteredInfo ( body : GetRegisteredInfo ): this is invoked after a GetRegisteredInfo request is received afterGetRegisteredInfo ( body : RegisteredInfo ): this is invoked before the GetRegisteredInfo response is returned

void :

:

void :

:

beforeGetAssertionStatusReport ( authInfo : String completionStatus : CompletionStatus ): this is invoked after a GetAssertionStatusReport request is received

void :

:

afterGetAssertionStatusReport ( body : List ): : void : this is invoked before the GetAssertionStatusReport response is returned beforeDeleteTModel ( body : DeleteTModel ): this is invoked after a DeleteTModel request is received

:

void :

afterDeleteTModel ( ): : void : this is invoked before the DeleteTModel response is returned UDDISecurityMonitor beforeDiscardAuthToken ( body : DiscardAuthToken ): this is invoked after a DiscardAuthToken request is received

void :

:

afterDiscardAuthToken ( ): : void : this is invoked before the DiscardAuthToken response is returned beforeGetAuthToken ( body : GetAuthToken ): this is invoked after a GetAuthToken request is received

:

void :

afterGetAuthToken ( body : AuthToken ): : void : this is invoked before the GetAuthToken response is returned UDDISubscriptionListenerMonitor beforeNotifySubscriptionListener ( body : NotifySubscriptionListener ): : void : this is invoked after a NotifySubscriptionListener request is received afterNotifySubscriptionListener ( body : DispositionReport ): : void : this is invoked before the NotifySubscriptionListener response is returned UDDISubscriptionMonitor beforeGetSubscriptionResults ( body : GetSubscriptionResults ): this is invoked after a GetSubscriptionResults request is received

:

void :

afterGetSubscriptionResults ( body : SubscriptionResultsList ): this is invoked before the GetSubscriptionResults response is returned

:

void :

beforeGetSubscriptions ( parameters : GetSubscriptions ): this is invoked after a GetSubscriptions request is received afterGetSubscriptions ( parameters : Subscriptions ): this is invoked before GetSubscriptions the response is returned CHOReOS FP7-257178

:

:

void :

void :

93

beforeDeleteSubscription ( body : DeleteSubscription ): this is invoked after a DeleteSubscription request is received

void :

:

afterDeleteSubscription ( ): : void : this is invoked before the DeleteSubscription response is returned beforeSaveSubscription ( parameters : SaveSubscription ): this is invoked after a SaveSubscription request is received afterSaveSubscription ( parameters : Subscriptions ): this is invoked before the SaveSubscription response is returned

CHOReOS FP7-257178

:

:

void :

void :

94

D ParTes: API ChoreographyInteractionTreeGenerator The Interface ChoreographyInteractionTreeGenerator. This interface represents the first step of the ParTes strategy as described in [21]. buildInteractionTree(modelDir:String):Tree The buildInteractionTree method. This signature says implementers to build a method that has for input a java model (represented by a path) and returns as output a Tree object representing a tree of interactions made by the choreography. @param modelDir the path of the java code with JPF annotations @return the tree of interaction found in the choreography Interaction The Class Interaction. This class represents a method invocation between participants. A method invocation is characterized by a method name, a set of input parameters identified by a name and a type, and a return value, all represented as strings. The use of strings was made to simplify as much as possible the model checking phase and to be compliant with the Dumont Language used in the STSimulator project. This make possible to model check participants modeled as State Transition System allowing the model checker to interact with them. isAppendInteresting():boolean The method isAppendInteresting. This checks if an Interaction is interesting and attached to another Interaction marked as interesting. @return true, if is interesting setAppendInteresting(appendInteresting:boolean):void The method setAppendInteresting. This sets the ”appendInteresting” boolean to mark an Interaction as interesting inside a path of other ”interesting” Interactions. @param appendInteresting the ”appendInteresting” boolean isInteresting():boolean The method isInteresting. This gets the ”interesting” boolean to show if an Interaction is interesting. @return true, if is interesting setInteresting(interesting:boolean):void The method setInteresting. This sets the ”interesting” boolean to mark an Interaction as interesting. @param interesting the ”interesting” boolean getRetValue():String The method getRetvalue. This gets the return value used inside an Interaction. @return the return value setRetValue(retValue:String):void The method setRetvalue. This sets the return value used inside an Interaction. CHOReOS FP7-257178

95

Figure D.1: ParTes Class Diagram

CHOReOS FP7-257178

96

@param retValue the return value addRetValue(retValue:String):void The method addRetvalue. This adds a value to the vector of possible return values. This is used inside an Interaction to represent distinct return values that can be a result of an method invocation. @param retValue the return value getAllRetValues():String The method getRetvalues. This gets a string representation of the return values that can be found during the exploration. The values are described in the Dumont language to be compatible with participants modeled as STS using the STSimulator tool. @return all the return values getMethodClass():String The method getMethodClass. This is used to get the name of the class that contains the method described in the interaction. @return the method class name setMethodClass(methodClass:String):void The method setMethodClass. This is used to set the name of the class that contains the method described in the interaction. @param methodClass the method class name Interaction(methodClass:String, method:String, params:HashMap) The constructor of the Interaction. It instantiates a new interaction with a specified method name, class name, and a list of parameters. @param methodClass the method class name @param method the method name @param params the parameter names Interaction(methodClass:String, method:String) The constructor of the Interaction. It instantiates a new interaction with a specified method name and class name. @param methodClass the method class name @param method the method name Interaction(method:String) The constructor of the Interaction. It instantiates a new interaction with a specified method name. @param method the method name Interaction() The constructor of the Interaction. It instantiates a new empty interaction. getMethod():String The method getMethod. This is used to get the name of the method described in the interaction. @return the method setMethod(method:String):void The method setMethod. This is used to set the name of the method described in the interaction. @param method the new method setParam(name:String, value:String):void The method setParam. This is used to set the name/value of a parameter involved in the interaction. @param name the parameter name @param value the parameter value getParam(name:String):String The method getParam. This is used to get the value of a parameter involved in the interaction. @param name the name @return the parameter getAllParams():String CHOReOS FP7-257178

97

The method getAllParams. This is used to get all the name/value pair of the parameters involved in the interaction. @return all the parameters showInteraction():String The method showInteraction. This method returns a representation of the Interaction using the Dumont language. @return the Dumont representation showMethodWithParams():String The method showMethodWithParams. This method returns a representation of the method and parameters involved in the Interaction using the Dumont language. @return the Dumont representation showParams():String The method showParams. This method returns a representation of the parameters involved in the Interaction using the Dumont language. @return the Dumont representation getLastMethodFound():int The method getLastMethodFound. This method gets the last method found during the exploration. This is used to do comparisons with the specified property in relation to the history of the interaction where the history represents the path until the Interaction itself. @return the name of the last method found setLastMethodFound(lastMethodFound:int):void The method setLastMethodFound. This method sets the name of the last method found during the exploration in relation to the current Interaction. @param lastMethodFound the last method found isToIgnore():boolean The method isToIgnore. This method check if an Interaction is not interesting and the path as to be ignored by the exploration. This is used to prune the tree when a branch is found and it is not able to satisfy the property. @return true, if is to ignore setToIgnore(toIgnore:boolean):void The method setToIgnore. This method sets if an Interaction is not interesting and the path as to be ignored by the exploration. @param toIgnore the new to ignore getPropertyHistory():String The method getPropertyHistory. This method returns the history of the Interaction. @return the property history setPropertyHistory(propertyHistory:String):void The method setPropertyHistory. This method sets the history of the Interaction, as a path to be compared with the path expected by the property. @param propertyHistory the property history InteractionTreeTour This class extends the InteractionTreeTour class in the JSDL library (from the documentation of JSDL: The EulerTour algorithm is a tree traversal that can be informally described as a walk around tree T, where we start by going from the root towards its left child, viewing the edges of T as being walls that CHOReOS FP7-257178

98

we always keep to our left). setTestPool(p:TestFragmentPool):void The method setTestPool. It sets the test pool. @param p the test pool getTestPool():TestFragmentPool The method getTestPool. This method is used to obtain the populated pool of TestFragments after the exploration. @return the test pool visitBetweenChildren(arg0:Position):void The method visitBetweenChildren. This method is used to implement the Euler tour technique for tree exploration @see jdsl.core.algo.traversals.EulerTour#visitBetweenChildren(jdsl.core.api .Position) visitExternal(arg0:Position):void The method visitExternal. This method is used to implement the Euler tour technique for tree exploration. @see jdsl.core.algo.traversals.EulerTour#visitExternal(jdsl.core.api.Position) visitFirstTime(arg0:Position):void The method visitFirstTime. This method is used to implement the Euler tour technique for tree exploration. This method is called during the exploration the first time a position in the tree is discovered. @see jdsl.core.algo.traversals.EulerTour#visitFirstTime(jdsl.core.api.Position ) recursiveExecute(t:Tree, pool:TestFragmentPool):void The method recursiveExecute. This method is used to recursively execute the exploration of a tree to populate a pool of TestFragments to be used in testing. @param t the tree to traverse @param pool the test fragment pool to use in the traversal visitLastTime(arg0:Position):void The method visitLastTime. This method is used to implement the Euler tour technique for tree exploration. This method is called during the exploration each time a position in the tree is reached. @see jdsl.core.algo.traversals.EulerTour#visitLastTime(jdsl.core.api.Position) JPFRunner The Class JPFRunner. This class is responsible for the exploration of the choreography model to derive a data structure that represents all the interactions that might be performed as result of a Choreography enactment. This class implements the interface ChoreographyInteractionTreeGenerator. buildInteractionTree(modelDir:String):Tree The buildInteractionTree method. This method is implemented to respect the ChoreographyInteractionTreeGenerator interface. @see partes.jpfrunner.ChoreographyInteractionTreeGenerator#buildInteractionTree(java.lang.String) main(args:String):void The main method. This is used to run locally the first step of the ParTes strategy. All the parameters are loaded by command line. @param args the command line arguments

CHOReOS FP7-257178

99

Partes The Class Partes. This class extends the abstract implementation PartesTestGenerator using the default steps of the strategy. Partes(debug:boolean, modelDir:String) The Partes constructor. This instantiates a new Partes object. @param debug the debug boolean value (to print useful information on console) @param modelDir the directory of the java code that should be checked in JPF Partes(debug:boolean, modelDir:String, cTreeGenerator:ChoreographyInteractionTreeGenerator, pProjectionGenerator:ParticipantInteractionTreeGenerator, pTestBuilder:ParticipantTestBuilder) The Partes constructor. This instantiates a new Partes object using a TreeGenerator a ProjectionGenerator, and a TestBuilder explicitly. @param debug the debug boolean value (to print useful information on console) @param modelDir the directory of the java code that should be checked in JPF @param cTreeGenerator a TreeGenerator @param pProjectionGenerator a ProjectionGenerator @param pTestBuilder a TestBuilder generateTestSuite():HashMap The generateTestSuite method. This is where the strategy will be implemented as required from the abstract class PartesTestGenerator @see partes.PartesTestGenerator#generateTestSuite() getPartesParticipantInformation(filename:String):Vector The getPartesParticipantInformation method. This is a private method used in the strategy implementation. It is used to found information about the participants in the java code model of the choreography used by the model checker. @param filename the filename of a YAML configuration file in the java code model used in the model checking step @return a vector of participant information PartesInfo The Class PartesInfo. This class contains all the information about a participant. PartesInfo(portTypeToSearch:String, wsdlLocation:String, modelImplClass:String) Instantiates a new ParteInfo object. @param portTypeToSearch the portType to search for testing @param wsdlLocation the location of the WSDL of the service under test @param modelImplClass the implementation class used in the java model for exploration getPortTypeToSearch():String The getPortTypeToSearch method. It returns the PortType to search. @return the PortType to search setPortTypeToSearch(portTypeToSearch:String):void The setPortTypeToSearch method. It sets the PortType to search. @param portTypeToSearch the PortType to search getWsdlLocation():String The getWsdlLocation method. It gets the location of the WSDL description of the service under test. @return the wsdl location setWsdlLocation(wsdlLocation:String):void The setWsdlLocation method. It sets the location of the WSDL description of the service under test. CHOReOS FP7-257178

100

@param wsdlLocation the WSDL location getModelImplClass():String The getModelImplClass method. It gets the name of the java class used in the choreography model explored by JPF. @return the name of the implementation class setModelImplClass(modelImplClass:String):void The setModelImplClass method. It sets the name of the java class used in the choreography model explored by JPF. @param modelImplClass the name of the implementation class PartesJPFProperty The Class PartesJPFProperty. This class implements a Java PathFinder PropertyListenerAdapter to explore the choreography looking for a property expressed in a subset of CTL. The PartesJPFProperty class generate a NodeTree object of the external library JDSL (http://www.cs.brown.edu/cgc/jdsl/) marking the paths that are compliant with the specified property. The NodeTree structure is used in the projection and test creation features of Partes. choiceGeneratorAdvanced(vm:JVM):void The choiceGeneratorAdvanced method is required for the implementation of a PropertyListenerAdapter. It is executed when a JPF ChoiceGenerator perform a backtracking step inside the JPF exploration. @see gov.nasa.jpf.PropertyListenerAdapter#choiceGeneratorAdvanced(gov.nasa.jpf.jvm.JVM) choiceGeneratorProcessed(vm:JVM):void The choiceGeneratorProcessed method is required for the implementation of a PropertyListenerAdapter. It is executed after ChoiceGenerator has performed a new choice inside the JPF exploration. @see gov.nasa.jpf.PropertyListenerAdapter#choiceGeneratorProcessed(gov.nasa.jpf.jvm.JVM) searchFinished(search:Search):void The searchFinished method is required for the implementation of a PropertyListenerAdapter. It is executed when JPF ends the exploration. @see gov.nasa.jpf.PropertyListenerAdapter#searchFinished(gov.nasa.jpf.search.Search) searchStarted(search:Search):void The searchStarted method is required for the implementation of a PropertyListenerAdapter. It is executed when JPF starts the exploration. @see gov.nasa.jpf.PropertyListenerAdapter#searchStarted(gov.nasa.jpf.search.Search) stateStored(search:Search):void The stateStored method is required for the implementation of a PropertyListenerAdapter. It is executed when JPF need to store a state to perform backtracking. @see gov.nasa.jpf.PropertyListenerAdapter#stateStored(gov.nasa.jpf.search.Search) deleteNotRelevantPath():void The method deleteNotRelevantPath. This is used to delete from the output tree the Interactions that are not marked as interesting for testing purposes. removePositionToIgnoreUp(p:Position):void The method removePositionToIgnoreUp. This is a support method that given a specific Position removes parent Positions (Interactions) from the tree when these are not interesting. @param p the position to start the removal. removePositionToIgnoreDown(p:Position):void The method removePositionToIgnoreDown. This is a support method that given a specific Position CHOReOS FP7-257178

101

removes child Positions (Interactions) from the tree when these are not interesting. @param p the position to start the removal. buildPropertyHistory(methodToFind:int):String The buildPropertyHistory method. This is used to build a path (called history) during the exploration starting from a property. @param methodToFind the method to find @return the property history string representation initializeOnInstruction(vm:JVM):void The initializeOnInstruction method. This is used by JPF to initialize the listeners. @param vm the internal vm representation PartesJPFProperty() The PartesJPFProperty constructor. This instantiates a new trap property. The constructor initialize the PartesJPFProperty reading the property from the command line inside the choreography model given as input. instructionExecuted(vm:JVM):void The instructionExecuted method. This is executed by JPF to log instructions at bytecode level. Instructions are filtered in this method to log only invocation of methods. @see gov.nasa.jpf.PropertyListenerAdapter#instructionExecuted(gov.nasa.jpf.jvm.JVM) generateOutput():void The generateOutput method. This is used to generate output files when the tool is runned locally. stateProcessed(search:Search):void The stateProcessed method is required for the implementation of a PropertyListenerAdapter. It is executed after the exploration of a state. @see gov.nasa.jpf.PropertyListenerAdapter#stateProcessed(gov.nasa.jpf.search.Search) stateAdvanced(search:Search):void The stateAdvanced method is required for the implementation of a PropertyListenerAdapter. It is executed when JPF need to move to another state during exploration. @see gov.nasa.jpf.PropertyListenerAdapter#stateAdvanced(gov.nasa.jpf.search.Search) stateBacktracked(search:Search):void The stateBacktracked method is required for the implementation of a PropertyListenerAdapter. It is executed when JPF need to perform backtracking. @see gov.nasa.jpf.PropertyListenerAdapter#stateBacktracked(gov.nasa.jpf.search.Search) writeTreeToFile(tree:Tree, fileName:String):String The writeTreeToFile method. This method write a tree to file. @param tree the tree to write @param fileName the file name @return a string that represents the content of the file getTreeOfInteractions():Tree The getTreeOfInteraction method. This getter method is used to retrieve the tree of interactions found by the property. @return the tree of interactions writeTreeToDotFile(tree:Tree, fileName:String):String The writeTreeToDotFile method. This write a tree to a dot file. @param tree the tree to write @param fileName the file name @return a string that represents the content of the file generateImage(dotSource:String, imageFile:String):void The generateImage method. This method generates an image of the tree used for debugging purpose. CHOReOS FP7-257178

102

@param dotSource the dot source to use in image generation @param imageFile the image file to use in generation writeTree(tree:Tree, p:Position, sb:StringBuilder):void The writeTree private method. @param tree the tree @param p the p @param sb the sb writeTreeDot(tree:Tree, p:Position, sb:StringBuilder):void The writeTreeDot private method. @param tree the tree @param p the p @param sb the sb printToConsole(treeDescription:String, dotSource:String):void The printToConsole method. This method prints the to console the tree of interaction. This is used for debugging purpose. @param treeDescription the tree description @param dotSource the dot source writeTreeToXMLFile(tree:Tree, fileName:String):void The writeTreeToXMLFile method. This method write a tree to an xml file. @param tree the tree to write @param fileName the file name to use check(search:Search, vm:JVM):boolean The check method. This is used to check the evaluation of the property. @see gov.nasa.jpf.PropertyListenerAdapter#check(gov.nasa.jpf.search.Search, gov.nasa.jpf.jvm.JVM) makeParentPositionsInteresting(p:Position):void The method makeParentPositionInteresting. This is a method that, given a specific Position, marks as interesting its child Positions (Interactions) inside the tree. @param p the position to start the marking PartesMain The Class PartesMain. This class represents an entry point of the tool. main(args:String):void The main method of the Partes tool. This method take command line input to specify the directory that contains the java model to be used in ParTes. The java model, instrumented by the JPF API is equipped with a configuration file that describes the participants and the properties to be checked. @param args the command line arguments PartesTestGenerator The abstract class PartesTestGenerator. This class represents an abstract implementation of the ParTes strategy to use a ChoreographyInteractionTreeGenerator, a ParticipantInteractionTreeGenerator, and a ParticipantTestBuilder. This is for future versions of the ParTes steps that will be used with little impact on the existing code. generateTestSuite():HashMap The generateTestSuite abstract method. This is where the strategy will be implemented in non-abstract classes. @return the hash map with PartesInfo objects. PartesInfo represents test information for participants. PartesTestGenerator(cTreeGenerator:ChoreographyInteractionTreeGenerator, pProjectionGenerator:ParticipantInteractionTreeGenerator, pTestBuilder:ParticipantTestBuilder) The PartesTestGenerator constructor. This instantiates a new PartesTest generator starting from the three steps of the strategy. CHOReOS FP7-257178

103

@param cTreeGenerator a TreeGenerator @param pProjectionGenerator a ProjectionGenerator @param pTestBuilder a TestBuilder PartesTestGenerator() The PartesTestGenerator basic constructor. This instantiates a new PartesTest generator starting from the three default implementations of the strategy getcTreeGenerator():ChoreographyInteractionTreeGenerator The getcTreeGenerator method. This method gets the TreeGenerator used in the implementation. @return the cTreeGenerator setcTreeGenerator(cTreeGenerator:ChoreographyInteractionTreeGenerator):void The setcTreeGenerator method. This method sets the TreeGenerator used in the implementation. @param cTreeGenerator the cTreeGenerator to set getpProjectionGenerator():ParticipantInteractionTreeGenerator The getpProjectionGenerator method. This method gets the ParticipantInteractionTreeGenerator used in the implementation. @return the pProjectionGenerator setpProjectionGenerator( pProjectionGenerator:ParticipantInteractionTreeGenerator):void The setpProjectionGenerator method. This method sets the ProjectionGenerator used in the implementation. @param pProjectionGenerator the pProjectionGenerator to set getpTestBuilder():ParticipantTestBuilder The getpTestBuilder method. This method gets the ParticipantTestBuilder used in the implementation. @return the pTestBuilder setpTestBuilder(pTestBuilder:ParticipantTestBuilder):void The setpTestBuilder method. This method sets the ParticipantTestBuilder used in the implementation. @param pTestBuilder the pTestBuilder to set PartesWS The Class PartesWS. This class provide remote access to the tool using a SOAP web service. generateTestSuite(zipFile:File):Vector The generateTestSuite method. This method accept as input a zip file that contains the java code used for exploration by JPF. The java code must be compiled. The method extracts the file and uses the ParTes API for the generation of test suites. Test suites are contained in a ParticipantTest object. @see partes.ws.PartesWSInterface#generateTestSuite(java.io.File) getFileNameWithoutExtension(fileName:String):String The getFileNameWithoutExtension private method. This gets a file name of a zip file without extension. @param fileName the file name @return the file name without extension PartesWSInterface The Interface PartesWSInterface. This interface define the remote method available for the invocation of ParTes. generateTestSuite(zipFile:File):Vector The generateTestSuite signature. This signature describes a method that accepts as input a zip file that contains the java code that will be used for exploration by JPF. The method should return a vector of tests. Tests are encapsulated in a ParticipantTest object. CHOReOS FP7-257178

104

@param zipFile the zip file that contains the java code @return the vector of ParticipantTest ParticipantInteractionTreeGenerator The Interface ParticipantInteractionTreeGenerator. The Interface ParticipantInteractionTreeGenerator. This interface represents the second step of the ParTes strategy as described in [21]. makeProjection(tree:Tree, services:String):Vector The makeProjection method. This signature says implementers to build a method that has for input a Tree of interactions and a vector of service names and returns as output a Vector of ProjectionInfo objects. A ProjectionInfo represents the information about the behavior of a participant role @param tree the tree @param services the services @return the vector ParticipantTestBuilder The Interface ParticipantTestBuilder. The Interface ParticipantTestBuilder. This interface represents the third step of the ParTes strategy as described in [21]. makeSOAPuiProject(tree:Tree, portTypeToSearch:String, wsdlLocation:String):WsdlProject The makeSOAPuiProject method. This signature says implementers to build a method that has for input a Tree of interactions (a projection of a participant role), a WSDL description and a portType to test. The method has the aim to build a WsdlProject (SOAPui library) to be used with the SOAPui tool, or with other ”runner” (i.e: ServicePot Plugin) @param tree the tree of interactions for a participant role @param portTypeToSearch the portType to tes @param wsdlLocation the WSDL location @return a WSDL project of the SOAPui library @throws XmlException the XML exception @throws IOException Signals that an I/O exception has occurred. @throws SoapUIException the SOAPui exception ProjectionInfo The Class ProjectionInfo. This class relates a tree of Interaction objects to a service endpoint. It is used by the WS implementation logic to return the tree of the expected behavior of a participant in a choreography. @author francesco ProjectionInfo(service:String, projectionTree:Tree) Instantiates a new projection info. @param service the service name @param projectionTree the projection tree ProjectionInfo() Instantiates a new projection info. getProjectionTree():Tree The getProjectionTree method. It gets the projection tree. @return the projection tree setProjectionTree(projectionTree:Tree):void CHOReOS FP7-257178

105

The setProjectionTree method. It sets the projection tree. @param projectionTree the projection tree getService():String The getService method. It gets the service name. @return the service setService(service:String):void The setService method. It sets the service name. @param service the new service TestBuilder The Class TestBuilder. This class is responsible for the derivation of real test cases using soapUI API starting from a data structure containing Interactions. This class performs an exploration of the tree data structure containing the expected behavior of a participant service using the visit procedure implemented in the BPTEulerTour class. The visit algorithm make a partition of the tree to find TestFragment (i.e sequence of interactions that should be performed without interruptions or other constraints) and how these fragments are organized. TestFragment will be represented inside a soapUI project as a reusable asset to be shared among different possible test cases (different paths). TestBuilder() The TestBuilder constructor. This instantiates a new test builder. makeSOAPuiProject(treeWithEndpoint:TreeWithEndpoint):WsdlProject An alternative version of the makeSOAPuiProject method. @param treeWithEndpoint the tree of interactions with endpoint information @throws XmlException the xml exception @throws IOException Signals that an I/O exception has occurred. @throws SoapUIException the SoapUI exception makeSOAPuiProject(tree:Tree, portTypeToSearch:String, wsdlLocation:String):WsdlProject The makeSOAPuiProject method. This method implements the logic to build a WsdlProject object starting from a tree of interaction for a given participant and the related information about the service endpoint. A WsdlProject in the SoapUI library contains all the tests and scripts used to test a service. @see partes.testbuilder.ParticipantTestBuilder#makeSOAPuiProject(jdsl.core.api.Tree, java.lang.String, java.lang.String) @param tree the tree of interactions for the participant @param portTypeToSearch the PortType to test @param wsdlLocation the WSDL location of the service to test @throws XmlException the xml exception @throws IOException Signals that an I/O exception has occurred. @throws SoapUIException the SoapUI exception main(args:String):void The main method. This is used to run locally the third step of the ParTes strategy. All the parameters are loaded by command line. @param args the arguments TestFragment The Class TestFragment. This class represents a sequence of interactions and the data to perform it. Each fragment can be: - an initial fragment meaning that the sequence is at the start of a trace found by the model checker and the projection phases. - a branch fragment meaning that after the branch there is a choice that depends of an interaction inside the fragment and that affects the choice of which CHOReOS FP7-257178

106

fragment to execute next. TestFragments are organized in a tree structure, and each of them has a unique predecessor and a set of successors. getFragmentID():int The getFragmentID method. This is used to get a unique identifier of a fragment. @return the fragment id getPredecessor():TestFragment The getPredecessor method. This is used to get the parent fragment of a given fragment. @return the predecessor setPredecessor(predecessor:TestFragment):void The setPredecessor method. This is used to set the parent fragment of a given fragment. @param predecessor the new predecessor getSuccessors():Vector The getSuccessors method. This is used to get the successors fragments of a given fragment. @return the successors addSuccessor(successor:TestFragment):void The addSuccessors method. This is used to add a TestFragment as a successor fragment of a given fragment. A fragment can have more than one successor. @param successor the successor setSuccessors(successors:Vector):void The setSuccessors method. This is used to set the successors fragments of a given fragment. @param successors the new successors TestFragment(tree:Tree) The constructor of the class. It instantiates a new test fragment using a Tree object. @param tree the tree getTree():Tree The getTree method. This is used to get the Tree contained in the TestFragment object. @return the tree setTree(tree:Tree):void The setTree method. This is used to set the Tree contained in the TestFragment object. @param tree the new tree isInitialFragment():boolean The isInitialFragment method. This is used to check if a Fragment is located in the start of the soapUI TestCase that will be built. @return true, if is initial fragment setInitialFragment(initialFragment:boolean):void The setInitialFragment method. This is used to set a Fragment as located in the start of the soapUI TestCase that will be built. @param initialFragment the new initial fragment isBranchFragment():boolean The isBranchFragment method. This is used to check if a Fragment is a branch fragment. @return true, if is branch fragment setBranchFragment(branchFragment:boolean):void The setBranchFragment method. This is used to set a Fragment as a branch fragment inside the soapUI TestCase that will be built. A branch fragment ends with a script able to choice the following fragment. CHOReOS FP7-257178

107

@param branchFragment the new branch fragment TestFragmentPool The Class TestFragmentPool. This class represent a container for TestFraments. Each TestFragment is stored with an unique identifier and can be retrieved using or the same identifier or searching for an Interaction that belong to it. TestFragmentPool() The constructor of the class. This instantiates a new test fragment pool. addToPool(identifier:int, test:TestFragment):void The addToPool method. This is used to add a TestFragment to the pool. @param identifier the identifier @param test the TestFragment to add getFromPool(identifier:int):TestFragment The getFromPool method. This is used to find a TestFragment in the pool given its identifier. @param identifier the identifier @return the TestFragment found inside the pool getTestFragmentIterator():Iterator The getTestFragmentIterator method. This is used to get an Iterator object over all the TestFragments in the pool. @return the TestFragment iterator findTestFragment(position:Position):TestFragment The findTestFragment method. This is used to find a TestFragment in the pool given a Position that belong to it. @param position the position to find @return the TestFragment that contains the given Position object TreeProjection The Class TreeProjection. This class is responsible for the projection of the behaviors contained in the NodeTree of Interactions to obtain the expected behavior of a participant involved in a choreography with a given role. In this way the NodeTree of Interactions found by the model checker is divided into a tree of Interactions for each participant. Each of these trees contains the Interactions related to a single role. makeProjection(tree:Tree, services:String):Vector The makeProjection method. This implements the logic for projecting a tree of interactions returned by JPFRunner into a set of trees. Each tree is dedicated to represent the expected behavior of a participant in the choreography. This method implements the makeProjection method in the ParticipantInteractionTreeGenerator interface. @see partes.projection.ParticipantInteractionTreeGenerator#makeProjection(jdsl.core.api.Tree, java.lang.String[]) printTests(testTrees:HashMap, treeCounter:int):void The printTests method. This method prints information about the tests to the console. This is used for debugging purpose during the development. @param testTrees the test trees to print @param treeCounter an index to identify the tree to use evaluatePositions(tree:Tree, service:String):Tree The evaluatePositions method. This is an internal method used to implement the projection logic. @param tree the tree to project @param service the service to search for the projection @return the projection CHOReOS FP7-257178

108

evaluateSubTree(tree:Tree, services:String):HashMap The evaluateSubTree method. This is an internal method used to implement the projection logic using recursion inside the input tree. @param tree the tree @return the hash map that contains all the trees found as subtrees evaluatePosition(tree:Tree, p:Position, service:String):Tree The evaluatePosition method. This is an internal method used to implement the projection logic using recursion inside the input tree. @param tree the tree @param p the position (node of the tree) to be evaluated @param service the service to found @return a tree of evaluated positions detachSubTreeFromRoot(aTree:Tree):Vector The detachSubTreeFromRoot method. This is used to split the input tree into a set of trees when needed by the projection logic. @param aTree a tree that contains subtrees @return the vector of trees built by the method main(args:String):void The main method. This is used to run locally the second step of the ParTes strategy. All the parameters are loaded by command line. @param args the arguments TreeWithEndpoint The Class TreeWithEndpoint. This class represent the association between a tree of interaction and WSDL document with at least one portType. This class is used by the TestBuilder to organize the tree exploration in relation of a service endpoint that will be the SUT. TreeWithEndpoint() The constructor of the class. This instantiates a new empty TreeWithEndpoint. TreeWithEndpoint(tree:Tree, wsdlFileName:String, portType:String) The constructor of the class. This instantiates a new TreeWithEndpoint @param tree the tree of interaction for a participant @param wsdlFileName the WSDL file name @param portType the portType to test getTreeFileName():String The getTreeFileName method. This is the getter method for the tree file name. @return the tree file name setTreeFileName(treeFileName:String):void The setTreeFileName method. This is the setter method for the tree file name. @param treeFileName the new tree file name getPortType():String The getPortType method. This is the getter method for the port type name. @return the portType setPortType(portType:String):void The setPortType method. This is the setter method for the port type name. @param portType the new portType getTree():Tree The getTree method. This is the getter method for the Tree structure. @return the tree of interaction setTree(tree:Tree):void The setTree method. This is the setter method for the Tree structure. CHOReOS FP7-257178

109

@param tree the new tree getWsdlFileName():String The getWsdlFileName method. This is the getter method for the WSDL file name. @return the WSDL file name setWsdlFileName(wsdlFileName:String):void The setWsdlFileName method. This is the setter method for the WSDL file name. @param wsdlFileName the new WSDL file name getTestFragments():Vector The getTestFragments method. This is the getter method for the TestFragments related to a tree with a given endpoint. @return the Vector of TestFragment

CHOReOS FP7-257178

110

E CRank: API E.1. CRank: Implementation Details

Figure E.1: CRank: Class Diagram

CHOReOS FP7-257178

111

AbstractDependencyEdges This class models the dependencies among the actors of a service choreography. AbstractDependencyEdges(actorList:List) Instantiates a new abstract dependency edges. @param actorList the actor list AbstractDependencyEdges(size:int) Instantiates a new abstract dependency edges. @param size the size getActors():List Gets the actors. @return the actors get(sourceActor:String, destActor:String):double Gets the dependency factor between two actors. set(sourceActor:String, destActor:String, value:double):void Sets the dependency factor between two actors. getActorsList():List Gets the actors list. @return the actors list populate(filename:String):void Populate the dependency matrix. Actor This class models an Actor of a service choreography. Somewhere an Actor could be also referred with the term “Role”, nevertheless, in this documentation they are synonymous. Actor(name:String) Instantiates a new actor. @param name the name Actor(name:String, ls:List) Instantiates a new actor. @param name the name @param ls the ls getName():String Gets the name. @return the name getServiceIndex(u:URL):int Gets the service index. @param u the u @return the service index addService(s:Service):void Adds the service as playing this Actor. dropService(s:Service):void Drop service. @param s the s getServices():List Gets the services. @return the services

CHOReOS FP7-257178

112

ActorsRank This class models the ranks scored by a list of actors. ActorsRank(e:AbstractDependencyEdges) Instantiates the new vector of ranks for the actors. @param e the e @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception ActorsRank(e:AbstractDependencyEdges, epsilon:double) Instantiates the new vector of ranks for the actors. @param e the e @param epsilon the epsilon @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception ActorsRank(e:AbstractDependencyEdges, sr:SourceOfRank) Instantiates the new vector ranks for the actors. @param e the e @param sr the sr @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception ActorsRank(e:AbstractDependencyEdges, epsilon:double, sr:SourceOfRank) Instantiates a new actors rank. @param e the e @param epsilon the epsilon @param sr the sr @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception configureServiceRank(sr:SourceOfRank):void Configure service rank. @param sr the sr computeRank():void Compute rank from the internal source of rank. @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception computeRank(s:Vector):void Computes the Manhattan norm of the rank vector “v”. get(actorName:String):double Gets the value of the rank for the specified actor. @param actorName the actor name @return the double @throws Exception the exception updateValues(v:Vector):void Update the raking values of all the actors according with the input vector. @param v the v manhattanNorm():double Computes the Manhattan norm of this rank vector. manhattanNorm(v:Vector):double Manhattan norm. @param v the v @return the double ChoreographyRank This class models the ranks scored by a service choreography. ChoreographyRank(e:AbstractDependencyEdges) Instantiates a new choreography rank. The choreograpy is modeled by means of a dependency matrix. @param e the e @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception ChoreographyRank(e:AbstractDependencyEdges, ar:ActorsRank) Instantiates a new choreography rank. The choreograpy is modeled by means of a dependency matrix. CHOReOS FP7-257178

113

In this case, an initial ranks of the actors defined by the choreography is provided. @param e the e @param ar the ar @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception getRank():double Gets the rank. @return the rank getActorsRank():ActorsRank Gets the actors rank. @return the actors rank updateRank():double Update rank. @return the double @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception updateRank(updateActors:boolean):double Update rank. @param updateActors the update actors @return the double @throws VectorException the vector exception @throws MatrixException the matrix exception @throws Exception the exception DependencyEdges This class provides a specific implementation of a dependency relation. In particular this class implements the relation described in [17], and D4.1 [15]. DependencyEdges(actorList:List) Instantiates a new dependency edges. @param actorList the actor list DependencyEdges(size:int) Instantiates a new dependency edges. @param size the size populate(filename:String):void PostboardReader This class interfaces the ranking function based on the services reputation with a specific subsystem able to collect user’s feedback. In particular, the class computes the Reputation scores by reading feedbacks expressed as RSS on a given bulletin board (i.e. Postboard). PostboardReader(url:URL, services:List) Instantiates a new postboard reader. @param url the URL @param services the services getURL():URL Gets the URL of the Postboard. @return the uRL setURL(url:URL):void Sets the URL of the Postboard. @param url the new uRL addService(s:Service):void Adds the service on the Postboard. @param s the s

CHOReOS FP7-257178

114

getServiceReputation(s:Service):Reputation Gets the service reputation. @param s the s @return the service reputation update():void Update. @throws IllegalArgumentException the illegal argument exception @throws FeedException the feed exception @throws IOException Signals that an I/O exception has occurred. @throws URISyntaxException the uRI syntax exception convertFeedbackRate(rate:String):int Convert feedback rate. @param rate the rate @return the int processFeedbacks(feedbacksURI:URI):Reputation Process feedbacks. @param feedbacksURI the feedbacks uri @return the reputation @throws IllegalArgumentException the illegal argument exception @throws MalformedURLException the malformed url exception @throws FeedException the feed exception @throws IOException Signals that an I/O exception has occurred. readFeed(url:URL):SyndFeed Read feed. @param url the url @return the synd feed @throws IllegalArgumentException the illegal argument exception @throws FeedException the feed exception @throws IOException Signals that an I/O exception has occurred. removeService(s:Service):void Removes the service. @param s the s RefreshServiceRanks This Class handles the periodical computation of the Service Ranks. RefreshServiceRanks(srf:ServiceRankFunction, timeout:long) Instantiates a new refresh service ranks. @param srf the srf @param timeout the timeout RefreshServiceRanks(srf:ServiceRankFunction, timeout:long, notifier:Thread) Instantiates a new refresh service ranks. @param srf the srf @param timeout the timeout @param notifier the notifier run():void Reputation This class models the reputation of an entity (i.e. services) in terms of the numbers of positive and negative feedbacks it collected. Reputation() Instantiates a new reputation. getNegativeFeedbacks():int Gets the negative feedbacks. @return the negative feedbacks getPositiveFeedbacks():int Gets the positive feedbacks. @return the positive feedbacks incReputation():void CHOReOS FP7-257178

115

Increases the reputation. decReputation():void Decreases the reputation. raiseReputation(i:int):void Raises the reputation. @param i the i reduceReputation(i:int):void Reduces the reputation. @param i the i reset():void Reset. ReputationBasedRanking This class provides a specific implementation of the ranking function associated to the services. In particular it implements the ranking function based on user’s feedback as described in [17], and D4.1 [15]. ReputationBasedRanking() Instantiates a new reputation based ranking. @throws MalformedURLException the malformed url exception ReputationBasedRanking(services:List) Instantiates a new reputation based ranking. @param services the services @throws MalformedURLException the malformed url exception ReputationBasedRanking(url:URL, services:List) Instantiates a new reputation based ranking. @param url the url @param services the services betaExpectationFunction(positive:double, negative:double):double Beta expectation function. Mathematical Expectation according with the beta-distribution. In other words, the feedbacks that the users reported during past interactions with a service ”s” are interpreted as the probability of collecting a positive feedback with ”s” on average in the future interactions. For example, if ”betaExpectation” for the service ”s” is 0.8 means that is still uncertain if ”s” will collect a positive feedback in the future (i.e. due to a positive interaction), but it is likely that this would happen. @param positive the positive @param negative the negative @return the double getCurrentRank(s:Service):double update():void subscirbe(s:Service):void drop(s:Service):void Service This class models a Service. Service(url:URL) Instantiates a new service. @param url the url getURL():URL Gets the uRL. @return the uRL CHOReOS FP7-257178

116

setURL(url:URL):void Sets the uRL. @param url the new uRL ServiceRankFunction This class models the ranking function associated to the services. getCurrentRank(s:Service):double Gets the current rank. @param s the s @return the current rank update():void Update. subscirbe(s:Service):void Subscirbe. @param s the s drop(s:Service):void Drop. @param s the s ServiceRankFunctionFactory A factory for creating ServiceRankFunction objects. getDefaultServiceRankFunction():ServiceRankFunction Gets the default service rank function. @return the default service rank function getDefaultServiceRankFunction(services:List):ServiceRankFunction Gets the default service rank function. @param services the services @return the default service rank function ServiceRankFunctionTypes This enumeration defines the types of the ranking functions supported for services. SourceOfRank This class models the actor’s source of rank. The source of rank is used as base-line during the computation of the choreography rank. SourceOfRank(e:AbstractDependencyEdges) Instantiates a new source of rank. @param e the e @throws VectorException the vector exception @throws Exception the exception SourceOfRank(actors:List) Instantiates a new source of rank. @param actors the actors @throws VectorException the vector exception @throws Exception the exception SourceOfRank(e:AbstractDependencyEdges, ratingFunction:ServiceRankFunction) Instantiates a new source of rank. @param e the e @param ratingFunction the rating function @throws VectorException the vector exception @throws Exception the exception SourceOfRank(actors:List, ratingFunction:ServiceRankFunction) Instantiates a new source of rank. @param actors the actors @param ratingFunction the rating function @throws VectorException the vector exception @throws Exception the exception CHOReOS FP7-257178

117

computeRank():void Compute rank. @throws VectorException the vector exception @throws Exception the exception compute(actorIndex:int):void Compute. @param actorIndex the actor index @throws VectorException the vector exception computeRank(actorName:String):void Compute rank. @param actorName the actor name @throws VectorException the vector exception @throws Exception the exception computeRank(index:int):void Compute rank. @param index the index @throws VectorException the vector exception @throws Exception the exception getServices(index:int):List Gets the services. @param index the index @return the services getServices(actorName:String):List Gets the services. @param actorName the actor name @return the services @throws Exception the exception get(actorName:String):double Gets the. @param actorName the actor name @return the double @throws Exception the exception getRatingFunction():ServiceRankFunction Gets the rating function. @return the rating function TestingBasedRanking This class provides a specific implementation of the ranking function associated to the services. In particular it implements the ranking function based on testing results as described in [17], and D4.1 [15]. TestingBasedRanking() Instantiates a new testing based ranking. TestingBasedRanking(services:List) Instantiates a new testing based ranking. @param services the services getCurrentRank(s:Service):double logisticFunction(grow rate:double, time:double):double Logistic function. @param grow rate the grow rate @param time the time @return the double collectNewTestingResults():void Collect new testing results. update():void subscirbe(s:Service):void drop(s:Service):void CHOReOS FP7-257178

118

E.2. CRankServicePlugin

Figure E.2: CRankServicePlugin

CRankPlugin CRankPlugin() CRankPlugin(virtualNoticeBoardAddress:String) doGet(req:HttpServletRequest, resp:HttpServletResponse):void doPost(req:HttpServletRequest, resp:HttpServletResponse):void beforeSaveChoreography(sci:SaveChoreographyIn):void afterProcessChoreography(map:Map):void Processes the choreography specification referred by the input TModel. Specifically, the following steps are computed: • create the Dependency Matrix • allocate resources in CRank for the reputation-based ranking of the choreography • allocate resources in CRank for the testing-based ranking of the choreography @param tmd a TModel linking the choreography specification afterSaveChoreography(tmd:TModelDetail):void Processes the choreography specification referred by the input TModel. Specifically, the following steps are computed: • create the Dependency Matrix • allocate resources in CRank for the reputation-based ranking of the choreography • allocate resources in CRank for the testing-based ranking of the choreography

CHOReOS FP7-257178

119

The input parameter tmd represents the TModel linking the choreography specification beforeAddChoreographyParticipant(acpi:AddChoreographyParticipantIn):void afterAddChoreographyParticipant(sd:ServiceDetail):void After the subscription of a new services in ServicePot, the service is also included it the procedure calculating the reputation/testing-based ranking for all the roles it specify in the category bag of structure ServiceDetail. The input parameter sd represents the standard UDDI data structure describing the details of a service. beforeAddRolesToParticipant(rapi:RolesAndParticipantIn):void afterAddRolesToParticipant(sd:ServiceDetail):void After the subscription in ServicePot of an existing service with an additional set of roles (in one ore more choreographies), the service is also included it the procedure calculating the reputation/testing-based ranking. Both the new roles and their associated choreographies are specified in the category bag of structure ServiceDetail. The input parameter sd represents the standard UDDI data structure describing the details of a service. beforeRemoveRolesFromParticipant(rapi:RolesAndParticipantIn):void Release all the ranking resources associated to the a specific service. After this operation the reputation/testingbased ranking would not take into account the contribution in ranking given by this service anymore. @param rapi afterRemoveRolesFromParticipant(sd:ServiceDetail):void beforeRemoveChoreography(dtm:DeleteTModel):void Release all the ranking resources associated to the choreography. The parameter dtm represents the TModel linking the choreography specification that should be removed afterRemoveChoreography():void wrapGetRequest(address:String, args:Map):HttpGet

CHOReOS FP7-257178

120