Deliverable D8.1.B Proof of Concept Release Moma, THA, SIE, TIE, UPM

NEXOF-RA NESSI Open Framework – Reference Architecture IST-FP7-216446

Deliverable D8.1.b Proof of Concept release MoMA, THA, SIE, TIE, UPM

Due date of deliverable: 30/11/2009 Actual submission date: 30/11/2009

This work is licensed under the Creative Commons Attribution-Share Alike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. This work is partially funded by EU under the grant of IST-FP6-034763.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 1 of 122

Change History Version Date Status Author (Partner) Description 0.1 01/09/2009 draft Angelo Gaeta Reworked structure (MoMA) based on the reviewer‟s recommendations and comments

0.2 14/10/2009 Draft MoMA with First Draft contributions of all PoC owners

0.3 27/10/2009 Draft MoMA with Fixed PoC summaries, contributions of all templates and other PoC owners comments

0.4 06/11/2009 Draft MoMA with First draft. contributions of all PoC owners

0.5 13/11/2009 Draft MoMA with Review of all the doc contributions of all before Internal Peer PoC owners Review

0.6 13/11/2009 Draft UPM PoC 2 and 4 have changed their name

1.1 29/11/2009 Final MoMA with Full review contributions of all PoC owners

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 2 of 122

EXECUTIVE SUMMARY This document reports information on the first set of Proof-of-Concepts (PoCs) set up to validate the architectural choices and patterns of the NEXOF-RA. A limited number of (9) patterns were available when the PoC team started its activities. These patterns have been produced by the horizontal workpackages and now are in the process of harmonisation and integration in the first release of the reference architecture specifications. A first group of patterns (5 out of 9) aims mainly to solve the problems of designing a scalable and high-available infrastructure for replicated data- sources, covering several aspects from data replication to data extraction and holistic replication. A second group of patterns (2 out of 9) covers the security concerns of trust/confidence and non repudiation in enterprise SOA supporting integrity, authenticity and accountability with the cost of decreasing the overall performance of the system. The other two patterns aim respectively to solve the problem of extending service containers to support interoperability, and to facilitate a design of Web 2.0 style user interfaces for service oriented systems. Following the recommendations provided by the NEXOF-RA Reference Architecture Team, the first phase PoC has mainly validated the non-functional (quality) attributes associated with an architectural choice/pattern. There has not been a generic procedure for identification and definition of the PoCs and the PoC team has decided case by case by taking into consideration the impact of the specific patterns. For instance, when added value (also in terms of overall impact of the combination) has been foreseen in a combination of patterns a single PoC has been proposed while in other cases two PoCs have been proposed to validate a single pattern since different aspects of the validation require different contexts. Besides validating particular quality attributes of patterns, it is worth mentioning that in most of the cases the first phase PoCs also provide feedbacks with respect to identification of sensitivity (e.g. properties of a component that are critical to success of a system) and trade-off points (e.g. properties that affect more than one attribute).

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 3 of 122

Document Information

IST Project FP7 – 216446 Acronym NEXOF-RA Number Full title NESSI Open Framework – Reference Architecture Project URL http://www.nexof-ra.eu EU Project officer Arian Zwegers

Deliverable Number 1 Title Proof of Concept release Work package Number 8 Title Proof of concept

Date of delivery Contractual 30/11/2009 Actual 30/11/2009 Status final  Nature Report  Demonstrator  Other  Abstract This document reports information on the first set of Proof-of-Concepts (for dissemination) (PoCs) set up to validate the architectural choices and patterns of the NEXOF-RA. It also provides information on the expected impact of the validation of this first phase PoC. Keywords Proof of Concept, Validation, Architectural Choice, Patterns

Authors (Partner) Angelo Gaeta (Mo.M.A.), Phong CAO (Thales), Vadim Igorevich Chepegin (TIE), Ricardo Jiménez-Peris (UPM), Evelyn Pfeuffer (SIE) Responsible Angelo Gaeta Email [email protected] Author Partner Mo.M.A. Phone +39 89 964364

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 4 of 122

TABLE OF CONTENTS EXECUTIVE SUMMARY ...... 3 TABLE OF CONTENTS ...... 5 0 ACRONYMS ...... 8 1 INTRODUCTION ...... 9 2 ANALYSIS OF THE FIRST PHASE POC ...... 10 2.1 The Architectural choices and patterns involved ...... 10 2.2 The Candidate PoCs...... 13 2.2.1 PoC 1: Database Replication Interfaces for Highly Available Stateful Services ...... 14 2.2.2 PoC 2: Gray-Box Database Replication Architectural Pattern For Highly Available Stateful Services ...... 17 2.2.3 PoC 3: Vertical Replication Architectural Pattern for Scalable and Highly Available Stateful Services ...... 20 2.2.4 PoC 4: Gray-Box Database Replication Architectural Pattern in WANs ...... 22 2.2.5 PoC 5: Security ...... 24 2.2.6 PoC 6: SCA Example Motion Tracker ...... 26 2.2.7 .PoC 7: Front End in E-SOA ...... 28 2.2.8 Summary table of the candidate PoC ...... 30 2.3 The Selection process ...... 33 2.4 The Selected PoCs ...... 34 2.5 The Ranking ...... 34 3 ADDITIONAL REMARK FOR THE FIRST PHASE POC ...... 36 3.1 On the architectural choices and patterns to be validated ...... 36 3.2 On the identification of the candidate PoC ...... 36 3.3 On the selection of the PoC ...... 36 3.4 On the expected impact of the validation ...... 37 4 CONCLUSION AND LESSONS LEARNT ...... 39 5 REFERENCES ...... 40 6 ANNEX A: DETAILED DESCRIPTION OF THE CANDIDATE/SELECTED POC ...... 41 6.1 Database Replication Interfaces for Highly Available Stateful Services .. 41 6.1.1 Detailed description of the software artefacts ...... 46 6.1.2 How to install ...... 47 6.1.3 How to use ...... 47 6.1.4 Details to access to the PoC instance you have implemented ...... 49

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 5 of 122

6.1.5 Packaging ...... 49 6.2 Gray-Box Database Replication Architectural Pattern For Highly Available Stateful Services ...... 49 6.2.1 Detailed description of the software artefacts ...... 55 6.2.2 How to install ...... 55 6.2.3 How to use ...... 56 6.2.4 Details to access to the PoC instance you have implemented ...... 57 6.2.5 Packaging ...... 58 6.3 Vertical Replication Architectural Pattern For Scalable and Highly Available Stateful Services ...... 58 6.3.1 Detailed description of the software artefacts – Vertical Replication 63 6.3.2 Installation Guide - Vertical Replication ...... 64 6.3.3 User Guide ...... 67 6.3.4 Details to access to the PoC instance you have implemented ...... 68 6.3.5 Packaging ...... 68 6.3.6 Detailed description of the software artefacts – Session Replication 68 6.3.7 Description of the involved tools/components and description of their integration ...... 68 6.3.8 How to install ...... 68 6.3.9 How to use ...... 72 6.3.10 Details to access to the PoC instance you have implemented ...... 73 6.3.11 Package of the developed software ...... 73 6.4 Gray-Box Database Replication Architectural Pattern in WANs ...... 73 6.4.1 Detailed description of the software artefacts ...... 79 6.4.2 How to install ...... 79 6.4.3 How to use ...... 80 6.4.4 Details to access to the PoC instance you have implemented ...... 81 6.4.5 Package of the developed software ...... 81 6.5 Security PoC ...... 81 6.5.1 Detailed description of the software artefacts ...... 90 6.5.2 How to install ...... 92 6.5.3 How to use ...... 93 6.5.4 Details to access to the PoC instance ...... 97 6.5.5 Packaging ...... 97 6.6 SCA Example Motion Tracker ...... 101 6.6.1 Detailed description of the software artefacts ...... 105 6.6.2 How to install ...... 107 6.6.3 How to use ...... 107 6.6.4 Details to access to the PoC instance ...... 108

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 6 of 122

6.6.5 Packaging ...... 108 6.7 Front End in E-SOA ...... 108 6.7.1 Detailed description of the software artefacts ...... 113 6.7.2 How to install ...... 113 6.7.3 How to use ...... 113 6.7.4 Details to access to the PoC instance ...... 122 6.7.5 Packaging ...... 122

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 7 of 122

0 ACRONYMS ACP Architectural Choice and Pattern CA Chief Architect NSP NESSI Strategic Project OCC Open Construction Cycle OSP Open Specification Process PoC Proof of Concept PM Project Manager RA Reference Architecture SOI Service Oriented Infrastructure WP Workpackage

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 8 of 122

1 INTRODUCTION The main goal of this document is to explain the processes behind each PoC identification, definition and selection. It also contains remarks on the expected impact of the validation. In particular, section 2 and related subsections are devoted to the description of how the PoC process defined in [1] has been applied. The subsections give the basic information on the architectural choices and patterns validated, and motivate how the PoCs have been identified and selected. Section 3 provides additional remarks on the first phase PoC and information on the expected impact of the validation. Finally, section 4 draws conclusions and argues about the lessons learnt. A presentation of the validation results is out of the scope of this document and will be reported in the D8.2 series. Lastly, the Annex A gives detailed information for each PoC, including information about produced software artefacts, installation instructions, and access points to the running instances of the software.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 9 of 122

2 ANALYSIS OF THE FIRST PHASE POC The objective of this section is to give an overview of the first phase PoC and of its potential impact on the NEXOF-RA. Firstly, architectural choices and patterns proposed for validation are presented and classified according to the key concerns and quality attributes they claim to address, followed by PoCs descriptions that have been identified and defined in order to validate those patterns. Secondly, the PoC selection process is described. It was executed in cooperation with CA, Reference Architecture Team representative and contributors of architectural patterns. The PoCs have been evaluated against the selection criteria identified in [1] to assess if a PoC fits the NEXOF-RA validation needs. Lastly, detailed information for each selected PoC is provided in Annex A including descriptions of software artefacts, instruction on how to install, use and access PoC instances.

2.1 The Architectural choices and patterns involved The architectural choices and patterns that have been selected for the first phase are the following: P1: Trigger Writeset Extraction Pattern P2: Log Mining Writeset Extraction Pattern P3: Writeset Extraction Based on Extended DB Interfaces Pattern P4: Gray-Box Database Replication Pattern P5: Vertical Replication Pattern P6: Non Repudiation Pattern P7: Trusted TimeStamping Pattern P8: OSGi-based SCA-Container Pattern P9: Front End in E-SOA Pattern For more information on these patterns readers can refer to [2] while for additional remarks on their selection refer to section 3.1. To the purposes of this deliverable, it is necessary to mention that at this stage: Selected patterns are abstract design patterns (i.e. refining top level architectural ones) claiming to support some quality attributes often in a price of negatively affecting some other attributes Selected patterns cover 6 out of the 9 key concerns presented in [3] Selected patterns refines the top level Enterprise-SOA (E-SOA) architectural pattern.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 10 of 122

The following table graphically maps the above patterns with respect to the concerns and quality attributes1. For each pattern, it is shown the key concern it belongs to (gray box) and the quality attributes affected positively (green box) or negatively (red box). This table is based on the information provided by [2] and has been reviewed by patterns producer. As the table shows, there is a first group of patterns (highlighted in yellow) aiming to solve the problem of designing scalable and high-available infrastructures for replicated data-sources. They cover several aspects from data replication including specific patterns for data extraction and holistic replication. Key to this group, are the patterns related to database replication [2], aiming to solve the problem of scaling the data tier in multi-tier Service Oriented Infrastructures (SOI). Overall, the patterns of this first group essentially claim to positively support scalability and availability and negatively affect other quality attributes. A second group of patterns covers the security concern (highlighted in blue). These aim to solve the recurring issues of trust/confidence and non repudiation in an enterprise SOA. These patterns claim to sufficiently support integrity, authenticity and accountability with the cost of decreasing the overall performance of the system. The two patterns of this group are related to the Security in E-SOA one [2]. The OSGi-based SCA-Container aims to solve the problem of extending Service Container to support interoperability and portability of different components. Last but not least, the Front End in E-SOA facilitates a design of Rich User Interfaces for service oriented systems.

1 In the table we only show a subset of quality attributes and, in particular, the ones involved in the validation. For more information on the quality attributes and on how the specific patterns support them, interested readers can refer to [2] NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 11 of 122

Key Concerns Quality Attributes

es Servic ging Messa ery Discov sition Compo s Analysi tation Presen y Securit ement Manag ces Resour c Generi ability Applic bility Availa ilit Scalab nability Maintai y Integrit y ntabilit Accou ticity Authen mance Perfor y erabilit Interop ty Usabili

Trigger Writeset Extraction

Log Mining Writeset

Writeset Extraction

Gray Box Database Replication

Vertical Replication

Non Repudiation

Trusted timestamping

OSGi-based SCA- Container

Front end in E-SOA

Table 1: Classification of the patterns to be validated in the first phase

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 12 of 122

For the first phase of proof-of-concepts WP8 was asked with full agreement of CA to focus mainly on the validation of quality attributes of the selected patterns. The results of the validation (reported in D8.2) will be taken into account for refinement of the reference architecture during the next iteration, as well as in the second phase of PoC activities.

2.2 The Candidate PoCs On the basis of the classification presented in Table 1 and on the information obtained from the Reference Architecture team and patterns producers, the PoC team has started the identification of the candidate PoCs. With the exception of the Front End in SOA, all the involved partners have proposed one or more PoCs to validate their patterns. Different strategies have been followed to identify and define a PoC. To validate the first group of patterns (marked with yellow in the Table 1), for instance, the patterns producer has decided to define: One PoC for the validation of the three writeset extraction patterns. The motivation is the fact that these patterns jointly have a dramatic impact on the scalability of database replication patterns (See Black-Box, Gray-Box and White-Box DB Replication patterns in [2]) and this impact has to be properly measured and validated by combining them instead of validating separately One PoC for the validation of the Vertical Replication pattern, since this pattern allows to ease the replication of multi-tier applications that are currently deployed in enterprises and enhance their scalability and availability Two PoCs to validate the Gray-Box DB Replication pattern in two different contexts, namely a LAN and a WAN. The motivation is that current applications are deployed in both Intranet and Internet environments and must satisfy different non–functional requirements for the different contexts. For the second group of patterns (marked with blue in the Table 1) a single PoC has been identified. This PoC has been set up with the purpose of proving the architectural tradeoffs of the two patterns through the non-functional requirements. Other two patterns have been validated through their own dedicated PoCs. The PoCs2 are presented in Annex A while the next subsections summarise the key information for each PoC such as objective, architectural diagram, alternatives to the proposed PoC and the method proposed for validation.

2 In this first phase the candidate PoCs have all been selected. Thus there is no need to differentiate between candidate and selected PoCs and the document presents only one Annex (and not separate Annexes respectively for candidate and selected PoC). NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 13 of 122

2.2.1 PoC 1: Database Replication Interfaces for Highly Available Stateful Services Patterns validated This PoC validates the patterns Trigger Writeset Extraction (P1 of the section 2.1), Log Mining Writeset Extraction (P2 of section 2.1) and the Writeset Extraction Based on Extended DB Interfaces (P3 of section 2.1). Objective of the PoC This PoC aims to demonstrate the validity of the Trigger Writeset Extraction pattern, Log Mining Writeset Extraction pattern and the Writeset Extraction Based on Extended DB Interfaces pattern with regard to data extraction/injection from data sources. In particular, the main objective of this PoC is to evaluate the tradeoffs in terms of non-functional aspects of the different writeset extraction/injection interfaces for databases. The aim is to compare DB replication patterns (See the White- Box, Gray-Box and Black-Box DB Replication patterns [2]) indirectly by means of microbenchmarking their main difference, that lies in the writeset extraction pattern used. With the results obtained, it will be possible to decide the most appropriate pattern to extract/inject writesets with a DB replication pattern. Architectural diagram In this PoC, the main architectural components affected are databases. They are the architectural components that must provide these writeset extraction/injection interfaces to implement replication facilities at the database level.

Figure 1: Architectural Diagram of PoC 1 NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 14 of 122

Alternatives The different alternatives of extracting data from a database are described in depth in the patterns related to database interfaces for writeset extraction and evaluated in this PoC. There are two main approaches: Standard DB Interfaces (Triggers and Log Mining) – They are general purpose interfaces provided by current databases that can be exploited to extract/inject the required writesets. These interfaces allow implementing portable solutions due to the fact that the information provided by the interfaces can be analyzed. Extended DB Interfaces – They are ad-hoc interfaces exhibited specifically to extract/inject writesets from outside the database. The writesets can either be extracted in binary or textual (SQL form). Method proposed for validation As this PoC aims at evaluating a very technical set of patterns and therefore is far from any business scenario from which extract business requirements, we depart from the technical requirements of quality attributes addressed by the architectural patterns. The assessment criteria are partially based on the ATAM methodology [9], that has been adapted to our specific needs that is to evaluate, quantify and compare the tradeoffs between architectural choices. The ATAM methodology was originally developed to assist architectural decisions by taking into account early in the design process the quality attributes and as such was assessed as relevant in the context of the work performed by WP8 and reported here and in D8.2. We use the ATAM utility tree for matching the technical quality attributes (performance, applicability and maintainability) with metrics to be used in the evaluation. The utility tree for each pattern is presented in the following figure:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 15 of 122

Figure 2: Utility tree to support validation in PoC1

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 16 of 122

For evaluating the quality attributes we will use specific microbenchmarks to evaluate the throughput and the response time of the different writeset extraction methods. Since each pattern can only be applied to one or more databases (due to their different assumptions) and there is no single database supporting the implementation of all the patterns, we need to use different databases (described above). We compare the relative performance of transaction execution with a particular writeset extraction pattern with the performance of the same database without writeset extraction. This enables us to quantify the overhead of the different patterns and compare them despite having been exercised on different databases. The applicability is measured as the number and strength of assumptions and the maintainability as the number of components we require to modify and maintain. 2.2.2 PoC 2: Gray-Box Database Replication Architectural Pattern For Highly Available Stateful Services Patterns validated This PoC validates the pattern Gray Box Database Replication (P4 of the section 2.1). Objective of the PoC The goal of this PoC is to evaluate the scalability of the Gray-Box Database Replication pattern. The aim is to quantify the scalability in terms of how many times the peak throughput of non-replicated database can be multiplied by using a replicated database with an increasing number of nodes and in this way determine the limits of the approach in terms of throughput scale-out. Architectural diagram The main architectural components affected by this PoC are databases and their replication support. They are the architectural components that contain the critical data that must be replicated in order to provide high availability and scalability to the applications that use these data. Database replication is controlled by a replication middleware in charge of communicating the changes among the different replicas deployed in a LAN and extracting/injecting the required data from the database through the extended database replication interfaces. The middleware is accessed by an application server.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 17 of 122

Figure 3: Architectural diagram of PoC 2 Alternatives The different alternatives to replicate database systems are described in depth in the White-Box and Black-Box Database Replication patterns [2]. Moreover, in addition to the solution used in this PoC to extract/inject writesets from a database (See Writeset Extraction based on Extended DB Interfaces pattern), there are other different alternatives described in depth in the patterns Trigger Writeset Extraction and Log Mining Writeset Extraction. Method proposed for validation As for the previous PoC, the assessment criteria are partially based on the ATAM methodology adapted to our specific needs (mainly the adoption of utility trees). However, in this case the business requirements have been derived from a particular scenario related to an online bookstore application included in a benchmark. The utility tree for the Gray-Box DB Replication pattern applied in this PoC is depicted in the following picture:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 18 of 122

Figure 4: Utility tree to support validation in PoC2 In the figure are shown the business requirements and metrics identified (on the right side of the figure), technical requirements and quality attributes (on the left side). So, apart from ATAM, we will use an evaluation methodology based on industrial practice. We will use a standard benchmark (TCP-W, [6]) that allows to evaluate the performance of databases in terms of throughput and response times. We will inject increasing loads to the system till reaching saturation for each configuration. We extend the evaluation to quantify the scale-out by running the benchmark with different configurations. The scale out shows how many times a particular number of replicas multiply the peak throughput of a non-replicated setup. Also as part of the scalability evaluation the average response time for client requests will be obtained. Since the benchmark itself does not express the requirements of availability, applicability and maintainability, they have been evaluated with regard to the requirements of the architectural pattern. Availability is measured as the number of single points of failure of the solution. The applicability is measured as the number and strength of assumptions and finally, the maintainability is measured as the number of components we require to modify and maintain. NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 19 of 122

2.2.3 PoC 3: Vertical Replication Architectural Pattern for Scalable and Highly Available Stateful Services Patterns validated This PoC validates the pattern Vertical Replication (P5 of section 2.1). Objective of the PoC The main objective of this PoC is to evaluate the trade-offs in non-functional attributes between the vertical replication approach (See Vertical Replication pattern [2]) and other architectural choices such as non-replicated solutions and single-tier replication. Architectural diagram The main architectural component affected is the service runtime, more specifically its multi-tier specialization that consists of an application server and a database component (See Multi-Tier Transactional Service Runtime pattern [2]).

Figure 5: Architectural diagram of PoC 3 Alternatives Other alternatives to the Vertical Replication pattern perform the replication of a single tier, either the middle-tier (See the Session Replication pattern) or the data-tier (see White-Box, Gray-Box and Black-Box Database Replication patterns). However, these solutions have single points of failure and bottlenecks in the non-replicated tier. An alternative pattern addressing the replication of both tiers is the Horizontal Replication pattern. Method proposed for validation

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 20 of 122

The method is the same as the one used in PoC 2. An utility tree is generated for the quality attributes of the PoC and benchmark is used to measure the most important features. In this PoC the business requirements have been derived from a scenario related to a supply-chain management application included in the benchmark. The utility tree for the Vertical Replication pattern applied in this PoC is depicted in the following picture:

Figure 6: Utility Tree to support validation in PoC3 For evaluating the quality attributes, we will use the following evaluation methodology. By means of a standard benchmark (SPECjAppServer 2004, [7]) we will evaluate the throughput and response time metrics identified in the utility tree. We will inject increasing loads to the system till reaching saturation for each replicated configuration (varying the number of replicas). The metrics are provided by the load injectors of the benchmark. The scale-out will be determined by comparing the peak throughput attained with the architectural pattern without replication (one replica) and with an increasing number of replicas. We will also compare the Vertical Replication pattern results with the Session Replication pattern. The quality attributes availability, applicability and maintainability are evaluated based on the requirements of the architectural pattern related to the number of single points of failure allowed, to have access to the source code of one or more components and the extension of the code that needs to be modified and/or extended. This is done in this way since the benchmark itself does not express this kind of requirements.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 21 of 122

2.2.4 PoC 4: Gray-Box Database Replication Architectural Pattern in WANs Patterns validated This PoC validates the pattern Gray-Box Database Replication (P4 of section 2.1). Objective of the PoC The main objective of this PoC is to evaluate the application of the Gray-Box Database Replication pattern [2] to edge computing to avoid a central sever for static and dynamic contents of applications. That is, storing static and dynamic contents of applications at edge servers and using the database replication pattern over a WAN to keep all edge servers up-to-date and consistent. So, the emphasis of this PoC is on evaluating an additional quality attribute of the Gray- Box Database Replication pattern: the latency experienced by the clients in a WAN. Architectural diagram The main architectural components affected are the database component and its replication support. The pattern is instantiated in the context of edge computing within edge servers using a multi-tier service run-time (See Multi-Tier Transactional Service Runtime pattern [2]), in which they used a WAN replicated database.

Figure 7: Architectural diagram of PoC 4

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 22 of 122

Alternatives The other alternatives for offering replicas of the services in WANs consist of accessing a centralized database to access dynamic contents. This alternative has as shortcoming the high latency observed by clients in the accesses to dynamic contents. Method proposed for validation As in the previous PoCs (2 and 3), an utility tree is generated for the quality attributes of the PoC and a benchmark is used to measure the most important features. The utility tree for the Gray-Box DB Replication pattern applied in WANs is depicted in the following picture:

Figure 8: Utility tree to support validation in PoC4 In this PoC we aim to determine the latency in a WAN of the Gray DB Replication pattern. So, apart from ATAM, we will use an evaluation methodology based on the same standard benchmark (TCP-W) used in the PoC 2. We will inject increasing loads to a system with a replicated database deployed in a WAN with different configurations for dynamic contents till reaching saturation. We will obtain the average latency perceived by clients when performing requests. The latency is indicative of the QoS perceived by the clients. So, the latency of the edge-based approach for the dynamic contents of applications will be compared to the latency obtained in infrastructures that

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 23 of 122

have centralized those contents. Since the benchmark itself does not express the requirements of availability, applicability and maintainability, they have been evaluated with regard to the requirements of the architectural pattern. Availability is measured as the number of single points of failure of the solution. The applicability is measured as the number and strength of assumptions and finally, the maintainability is measured as the number of components we require to modify and maintain. 2.2.5 PoC 5: Security Patterns validated This PoC validates the patterns Non repudiation (P6 of section 2.1) and Trusted Timestamping (P7 of section 2.1) Objective of the PoC The PoC has the main objective to demonstrate the architectural tradeoffs of two patterns: Non-Repudiation and Trusted Timestamping. These tradeoffs are evaluated through the non-functional requirements characterized under quality attributes (integrity, authenticity and accountability). Architectural diagram The following architectural design of the PoC combines the two patterns and as such demonstrate the conjoint use of “Trusted Timestaping” and “Non- Repudiation” patterns. The PoC also promotes architectural choices consisting in relying on the following web services (WS*) standards: WS-Security, WS- Policy.

Digital Consumer Document TS Server Signature

Timestamp CRL TS Hash Authority OCSP CRL or OSCP Server (Document + Timestamp) Certificate Encryption Signed with secrete key PKI Store

Abstract Design Patterns

Figure 9: Architectural diagram of PoC5 Trusted Timestamping pattern is composed with Encryption, Hash, TS Authority, TS Server, Digital Signature, Timestamp components in order to achieve “Document + Timestamp signed with secrete key” requested by the Consumer. Non-Repudiation pattern is composed with Digital Signature, Certificate Store, PKI, OCSP Server, CRL in order to verify the signature of “Document + Timestamp signed with secrete key”.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 24 of 122

The composition of the two patterns make use of the two sets of components while eliminating redundant ones. Alternatives There are several alternatives to preserve the integrity, for example by using the Authorization Component specified in the Security in E-SOA pattern [2]. This component defines the access control to data: only authorized access can modify data. Concerning the authenticity, another manner to deliver it is to use the authentication, but the authentication is not sufficient to have confidence in the authenticity (e.g. for a Tax Declaration). To trust in the authenticity, a trusted third party is needed (e.g. TSA). Accountability (traceability) can be achieved by logging all security information, but to trust in the traceability, it is recommended the use of a certificate. In this way, the certificate guarantees the non-repudiation of the traces. Method proposed for validation This PoC aims at evaluating quality attributes addressed by the architectural patterns. The evaluation criteria are partially based on the ATAM methodology [9] which has been adapted to our specific need that is to evaluate either objectively or subjectively the quality attributes. We use the ATAM utility tree to show clearly the quality attributes which are achieved to support the specification of two patterns (Trusted Timestamping and Non-Repudiation). The utility tree for each pattern is presented in the following figures:

Digital Signature, Integrity Protocol (H,L) X509, 1024 bits Data or Certificate with secrete key, Service (H,M) X509, 1024 bits Authenticity Authenticity Data or Guarantee of proof of timestamp, Service (H,M) thanks to use of the Digital Signature Non-Repudiation Privacy

Components Pattern is used as a component Maintainability (H,M) Services service in the SOA environment

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 25 of 122

Integrity Protocol (H,L) Digital Signature

Timestamping Authority (TSA) Server Creation (H,M) Trusted third party Accountability

Timestamping Authority (TSA) Server Modification (H,M) Trusted Trusted third party Timestamping

Components Pattern is used as a component Maintainability (H,M) Services service in the SOA environment

The Hash uses computing resource, (H,L) increases volume of the origin data Performance Protocol The Signature uses computing (H,M) resource, increases volume one time that the data signed Pattern Quality Attibutes Figure 10: Utility tree to support validation in PoC5 Metrics cannot be easily identified in the security domain to measure the quality attributes (e.g. how can we measure the trust of a certificate?). Quantitative indicators are not usable in the field. We can have more or less confidence. This perception is subjective, proven or not proven by facts, but there is no unit of measurement to evaluate it. We can just position it on a scale of values that we ourselves graduated according to the idea that we do trust. For example, to evaluate the trust in the certificate delivered by a Certification Authority (CA), which is a (trusted) third party, is very subjective. It is the same for an encryption algorithm (used to sign the document); it is very difficult to found metric on it. Thus in this case, the quality attributes are evaluated subjectively with the implementations of specific test cases in the PoC. 2.2.6 PoC 6: SCA Example Motion Tracker Patterns validated This PoC validates the pattern OSGi based SCA Container (P8 of section 2.1). Objective of the PoC This PoC aims at portability and interoperability. In the context of this PoC 6 we restrict the scope of the term “interoperability” to exchange primitive data types and messages using secure communication aspects that encompass Authentication, Signing and Encryption in the context of SCA. Both SCA and OSGi are the evolving standards for building service-oriented enterprise systems. Architectural diagram The following diagram depicts the architecture of the SCA example, containing 3 legacy applications (denoted as rounded rectangles) 3 SCA services (denoted as nested rectangles) NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 26 of 122

4 different communications rsp. service invocations

Motion-Sensor Video-Monitoring ControllerComponent Component (Java Standalone App) (C++ Standalone App)

WS* 1 CamController CamController JMS Service Component Video- Monitoring Service 3 MotionReactor WS* CamController MotionReactor Component Native SCA Runtime / SCA Node Service Service (BPEL)

ZoneInfo WS* Service CamController Component (.Net / WCF)

Java SCA Runtime / SCA Node 2

Optimized Binding / Dynamic Wiring

ZoneInfo ZoneInfo Service Component

Java SCA Runtime / SCA Node Figure 11: Architectural Diagram of PoC6 Alternatives The scope of this PoC is to assess by which extent interoperability and portability can be realized with specifications such as SCA and OSGi. This PoC uses Apache Tuscany (see Apache Tuscany Incubator project http://tuscany.apache.org/home.html) which provides an OSGi-based implementation of the SCA standard. As the objectives of this PoC are closely coupled to the interoperability mechanisms and concepts of the SCA specification itself, no alternative specifications are considered. The PoC focuses on a freely available, open source implementation of the Service Component Architecture that provides a simple way to implement SOA solutions. The free availability of open source products ensures broad applicability. There are several open source implementations available from which we chose Apache Tuscany (AT) for the following reasons: - Commercial product (IBM WebSphere SCA extension) is based on AT - AT is supported by large community - AT is currently (2009) best fit for our objectives As no other open source implementation meets the requirements as defined by our objectives, there do not exist any alternatives that can be assessed.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 27 of 122

Method proposed for validation The essential goal is to demonstrate the feasibility of the objective by means of a running and working implementation. It is important to note that these objectives are all qualitative by nature (in contrast to quantitative objectives such as data throughput, response times, etc.). This important fact is thus reflected in the assessment criteria. For this reason, the selected method is feasibility prototyping. In particular, the PoC realizes several integration scenarios which are implemented by means of feasibility prototypes. In terms of assessment criteria, this PoC will consider availability of installable and working prototype, dynamic extensibility by implementation types and bindings, clear separation of business and infrastructure logic, legacy application integration based on SCA programming model, JMS support for BPEL, optimized binding for Java and C++ within the same domain, BPEL implementation type, C++ implementation type, Java implementation type, as well as the ease of applicability and deployment of Apache Tuscany runtime. It should be noted that these estimations are of subjective nature. However, they are based on former experiences with different service runtimes such as JBoss for example. 2.2.7 .PoC 7: Front End in E-SOA Patterns validated This PoC validates the pattern Front End in E-SOA (P9 of section 2.1). Objective of the PoC SOA increase asset reuse, reduce integration expenses and improve businesses agility in responding to new demands. Nonetheless, until now, the mainstream development and research around SOA has been focused mainly on middleware and scalability, service engineering and automating service composition. Little or no attention has been put on common service front-ends which are, in our vision, necessary to complete a stack of SOA technologies and bring them to the end-users. As a consequence end-users do not really benefit from the advantages promoted by service orientation in terms of modularity, flexibility and composition. In addition service front-ends are constructed in an ad-hoc manner and with the absence of formal engineering methods and tools that could accelerate the time to market. To resolve these shortcomings of current SOA approaches NEXOF-RA advocates a Service Front-End layer that will allow flexible creation of applications by the end users themselves. This PoC is aiming at demonstration of how NEXOF-RA approach deals with the following non-functional requirements from the Presentation concern: usability and availability. Architectural diagram

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 28 of 122

The PoC will be based on the platform developed by the ezWebproject (http://ezweb.morfeo-project.org/). This project has been the source of contributions for the service front-end layer in the NEXOF-RA architecture. It is provided as open source software and already implements part of the target architecture. As part of this specific scenario used to validate the concepts, the following service front-end resources have to be developed SFER 1 List of existing partners. A secured component that shows the list of existing partners for user SFER 2 Partner data. A secured component that shows detailed information of a partner SFER 3 Map. A generic SFER map that shows a location on a map “ala Google Maps” These SFER resources will be published by means of the ezWeb catalogue and they will be used to build new composite resources through the workspace and wiring functionalities provided by the ezWeb platform.

SFE Component Description <> UI Component 0..* 1

1 0..* <> <> SFE Component SFE Catalogue interacts 1..*

1..*

<> <> SFE Resource SFE Mashup 1..* 0..*

+containerOf

User SFE Workspace 1 owns 0..* 0..*

1..* <> SFE Mashup Platform

0..*

Figure 12: High level architecture of front-end for ESOA Alternatives The concept of service interaction with the end users is very new. Due to this fact all the current alternatives would be limited to the ad hoc solutions without clear or elaborated architectures.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 29 of 122

The approach chosen for this PoC is based on a coherent architecture and open XML based service front ends description format. The other alternatives are only allow machine-to-machine communications via machine specific APIs such as SOAP or RESTFul. Method proposed for validation Since this PoC addresses user requirements concerning usability and human- system interaction aspects of a system, the proposed method of evaluation should be based on existing techniques originated from usability studies. These methods will include expert evaluation, questionnaires and interviews, recording of user-system interaction with following analysis. Assessment criteria are the following: Speed of user‟s work: how much time, mouse clicks etc. it is required to reach a desired state of a system Complexity of user‟s work: could be measured via user interface and user tasks complexity metrics developed in human-system interaction field and also via Quantity of user‟s mistakes: could be directly observed and logged Speed of studying: how easy/hard to master provided interface, creating a learning curve based on observations of the users Subjective user‟s satisfaction: could be deduced from questionnaires and interviews About availability, the most interesting aspect in relation to the Presentation concern is the one related to the ability of access of services by users challenged in some way through a software implemented based on NEXOF-RA principles, e.g. problems with vision or limited network access. To prove the correctness of choices in respect of this type of availability the main method is prototyping with following user studies. Some of the availability aspects could be predicted based on expert estimations. For instance, this solution will not be available on the system without JavaScript support (or in general without support of an engine that can run client side logic) because this pattern implies that mash-up engine runs on a client device. To validate that the choices behind proven service front–end platform (ezWeb) are valid the flash interviews will be conducted with two groups of questions. First one about satisfability with the results from an end-user point of view and the second group addressed an achievement of system requirements. 2.2.8 Summary table of the candidate PoC The following table summarises for each PoC the objective and the selected method for validation.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 30 of 122

PoC Objective Method

PoC1 This PoC aims to demonstrate the validity of the Trigger Writeset The method proposed combines some steps of the ATAM methodology Extraction pattern, Log Mining Writeset Extraction pattern and the Writeset [9] (step 5 about generation of Utility Tree and adoption of scenarios to Extraction Based on Extended DB Interfaces pattern with regard to data understand quality attributes requirements) with the adoption of extraction/injection from data sources. industrial benchmark application and metrics such as the scale-out, response time and throughput to demonstrate the support to scalability In particular, the main objective of this PoC is to evaluate the tradeoffs in and availability of a system implementing this architectural decision. terms of non-functional aspects of the different writeset extraction/injection interfaces for databases. The Utility Tree is used in order to identify, prioritize, and refine the most important quality attribute goals, and scenarios are used to understand PoC2 The goal of this PoC is to evaluate the scalability of the Gray-Box quality attribute requirements. The Utility Tree is extended on the right 3 Database Replication pattern. side with the assessment criteria and measurable metrics . So the Utility Tree servers as basis for the evaluation and to reason PoC3 The main objective of this PoC is to evaluate the trade-offs in non- about identification of sensitivity and/or trade-off points. functional attributes between the vertical replication approach (See Vertical Replication pattern) and other architectural choices such as non-replicated solutions and single-tier replication.

PoC4 The main objective of this PoC is to evaluate the application of the Gray- Box Database Replication pattern to edge computing. The emphasis of this PoC is on evaluating an additional quality attribute of the Gray-Box Database Replication pattern: the latency experienced by the clients in a WAN.

PoC5 The PoC has the main objective to demonstrate the architectural tradeoffs The method proposed combines some steps of the ATAM methodology of two patterns: Non-Repudiation and Trusted Timestamping. These [9] (step 5 about generation of Utility Tree and adoption of scenarios to tradeoffs are evaluated through the non-functional requirements understand quality attributes requirements) with the concrete characterized also under quality attributes (integrity, authenticity and implementation of test cases aiming to prove the architectural decision. accountability). In this case the Utility Tree is extended on the right side with the architectural choices made to support the quality attributes (e.g. use of

3 See Figure 2, Figure 4, Figure 6 and Figure 8

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 31 of 122

digital signature to support Integrity). Also in this case, the Utility Tree servers as basis for the evaluation and to reason about identification of trade-off points. This PoC aims at portability and interoperability. In the context of this PoC The method proposed to validate architectural choices was prototyping PoC6 6 we restrict the scope of the term “interoperability” to exchange primitive with parallel expert estimations of the given statements. Interoperability data types and messages using secure communication aspects that and portability were validated by building and executing the according encompass Authentication, Signing and Encryption in the context of SCA. integration scenarios. The assessment metric is qualitative by nature, The focus is on applicability and benefits of SCA and OSGi as well as of i.e. whether the selected features are fully available in the TUSCANY concepts for addressing common integration scenarios (including SCA container. integration of legacy applications)

PoC7 The objective of this PoC is to evaluate the Front End in E-SOA patterns The proposed method of evaluation and assessment criteria will be with respect to availability and usability based on existing techniques originated from usability studies.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 32 of 122

2.3 The Selection process The Candidate PoCs have been selected against the following criteria: Presence and effectiveness of methods for validation Presence and effectiveness of assessment criteria Presence of metrics A way to document the validation results (part of D8.2). and all the criteria have been assessed by a team composed by CA, reference architecture team representative, pattern producers and the PoC team. All the candidates PoCs present a method for the validation of the patterns and, its effectiveness has been evaluated case by case. In general, we can observe that there are 5 out of 7 PoCs aiming to validate patterns claiming a trade-off among quality attributes. These are the PoCs from 1 to 4 related to scalable and available infrastructure for data replication, and the PoC 5 related to the security, e.g. signature and non-repudiation in enterprise SOA. The above PoCs aims also to identify sensitivity and/or trade-off points and, to this purpose, the method selected for these PoCs is supported by some steps of the ATAM methodology [9]. The Utility Tree of the ATAM methodology is used in order to identify, prioritize, and refine the most important quality attribute goals, and scenarios (in most cases coming from [8]) are used to understand quality attribute requirements. In the case of the PoC 1, PoC 2, PoC 3 and PoC 4 the Utility Tree is extended on the right side with the assessment criteria and measurable metrics, and industrial benchmarking application (such as for example [6] and [7]) are adopted to measure the critical parameters, and then compare measurements achieved with other state of the art approach to the same problem. The results of the validation will include the identification of trade-off points, and a series of tables and graphs showing the comparison. In the case of PoC 5 the Utility Tree is extended on the right side with the architectural choices made to support the quality attributes (e.g. use of digital signature to support Integrity). The assessment of the architectural choices will be done via implementation of test cases. The different decision of the “right side” extensions of the Utility Tree is due to the fact that for the Security domain generic quantitative metrics are difficult to find and it is more reasonable and feasible to evaluate “how good” the architectural choices are in supporting quality attributes. The approach adopted by the above PoCs appears to be reasonable and effective either with respect to their objectives (that is evaluating patterns‟ claim about quality attributed and identifying sensitivity and trade-off points) and with respect to the overall goal of first phase PoC (that is giving early feedbacks to RA team on the validation of the patterns to improve the overall quality). In the

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 33 of 122

proposed approach ATAM is partially exploited to do this and, in particular, the Utility Tree is generated with the purpose of guiding the overall evaluation. The adoption of ATAM‟s step 5 allows i) to refine quality attributes goals and requirements into assessment criteria and metrics measured via bechmarking applications (case of PoC1 to 4), ii) to identify the architectural decision to support a quality attributes and implement them via test cases (case of PoC5) and, at the same time, iii) to support reasoning and analysis to identify sensitivity and/or trade-off points (e.g. step 6 of the methodology). The PoCs 6 and 7 have a reduced scope compared with the above ones. In fact they primarily do not aim to identify sensitivity or trade-off points, and restrict the objectives mainly to the evaluation of some quality attributes. PoC 6 uses prototyping as main validation method and PoC 7 combines prototyping with existing techniques originated from usability studies. In both the cases, the proposed validation method appears to be suitable given the reduced scope of the PoCs but, in a first analysis, their assessment criteria appears to be tight to a particular container implementation (in the case of PoC 6) and to subjective user evaluations (in the case of PoC 7). The two PoCs above mentioned are representative of relevant key areas in E- SOA such as Messaging, Composition, and Presentation. Given the delay in the reference architecture activities early feedbacks to the reference architecture team may be useful in the above mentioned key areas of NEXOF-RA and, thus, during the evaluation process the above two PoCs have been kept.

2.4 The Selected PoCs All the candidate PoCs have been selected.

2.5 The Ranking As stated in [1], the ranking against criteria such as number of requirements addressed, innovation and business value is done only in case of very large number of selected PoCs and, thus, it does not apply to this set of first phase PoC. However in this section, we present some considerations on the three criteria. Most of the PoCs derive evaluation scenarios, also to identify quality attributes requirements, from the set of project‟s scenarios presented in [8]. The e- Commerce information sharing scenario, for instance, is the main scenario on which basis the PoC from 1 to 4 and PoC 6 base their validations scenarios. The e-government online fee visualization and payment service scenario is the main reference for PoC 5. Thus, the PoC in a indirect way are related to the requirements described in [8]. As a set of software artefacts, parts of the PoC could be also re-used or exploited to the purpose of requirements validation (mainly the ones cannot be assessed from a pure design stance).

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 34 of 122

Innovation and business value criteria are about evaluating if there are innovative aspects of a PoC of interest beyond the validation, from a technical and /or business points of view. With respect to these criteria, all the first phase PoCs are based on state of the art solutions, with the exception of the PoC 7 where user mash-up services area is quite new solution. In perspective, however, there are cases that are worth mentioning. The first case is the one of PoC 4 aiming at evaluation of the application of the Gray-Box Database Replication pattern to edge computing to avoid a central sever. Interesting enough is a possible evolution of this pattern where it can be applicable to some types of distributed internet based computing such as, for instance, Grid and Cloud ones, where edge servers may communicate over the internet. The second case is the one of PoC 5 that presents the possibility of a development of a Trusted Time Stamping Authority that can be delivered as a Software as a Service (SaaS) solution. In perspective, they can evolve and become building block of solutions representing challenging and relevant domains for ICT players.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 35 of 122

3 ADDITIONAL REMARK FOR THE FIRST PHASE POC This section presents some additional remarks on the first phase PoC.

3.1 On the architectural choices and patterns to be validated As described in section 2.1 the current set of PoCs has been identified to validate 9 patterns that, indeed, is a limited number of patterns. It is worth mentioning that the 9 patterns validated were the only available and released at the time of starting the PoC activities. They originates from the research horizontal workpackages and currently are being harmonised by the reference architecture team to be part of the first release of the NEXOF-RA specifications. Thus, the PoC team has selected all the patterns available but, of course, in the second phase PoC the criteria mentioned in [1] in order to ensure a proper and well balanced coverage of the patterns will be applied (considering also the results and lessons learnt from this first phase PoC). Moreover, the PoC team is aware that software architecting is an iterative process, and there is a possibility that these patterns will change in next releases. To face with this situation the PoC team is considering a kind of regression evaluation: every time we evaluate a new set of choices / patterns, we have to verify if other choices / patterns have been modified and perform a re-evaluation if needed. Lastly, in the second phase the PoC team is going to identify and select also a wide number of patterns refining the new top level architectural pattern on Internet Of Services currently under investigation in the project. As written in [1] PoC team expects some indications on the criticality of the pattern by the domain experts.

3.2 On the identification of the candidate PoC Out of the 9 patterns, 7 PoCs have been identified. There has not been a general rule for identification of the PoCs and the PoC team has decided case by case. For instance, when added value has been foreseen by a combination of the patterns (e.g. the case of the patterns for writeset in PoC1 or the case of non- repudiation and timestamping patterns in PoC5) a single PoC has been proposed, while in other cases two PoCs have been proposed to validate the same pattern since different aspects of the validation require different contexts (e.g. it is the case of the Grey box replication pattern validated in PoC2 and PoC4).

3.3 On the selection of the PoC PoCs from 1 to 5 have been positively assessed against the selection criteria that we have set up for the selection process.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 36 of 122

PoCs 6 and 7 present a reduced scope compared with the previous ones and have been selected for completeness of key concerns reason. It is worth mentioning that this does not a priori mean the validation results for these two PoCs will be useless for the reference architecture team. We decided in this first phase PoC also due to the reduced number of patterns to be validate to do not loose the above two PoCs since they are representative of important key concerns and, as said, we can not exclude that their validation can be useful in the perspective of giving early feedbacks to reference architecture team in these key areas.

3.4 On the expected impact of the validation This section tries to present the expected impact of the overall first phase PoC even if, of course, information on the real impact will be reported in the evaluation report D8.2. Before arguing on the expected impact, we recall the actual situation with the following picture.

Figure 13: Overview of the expected impact The above table must be read only and exclusively in the intersections. For example, this means that at this stage we have only one pattern claiming to positively support Interoperability in the Messaging area of the NEXOF-RA. As other example, we have currently 3 patterns claiming to support Maintainability in the Service area, two of them claiming a positive impact (green ones), one of them claiming a negative one (red one). Other ways of reading the table (i.e. by row or by column) can be misleading. For instance in this first phase PoC, it is wrong that the Service area is covered

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 37 of 122

by 15 different patterns4 as it is wrong to assume that there are 3 patterns claiming to positively support the Interoperability non functional requirement5. The rationale behind the Figure 13 in combination with the information of Table 1 of section 2.1 is support reasoning on the potential impact of the overall first phase validation for a system supporting these architectural choices and patterns. We start from two evident considerations on the overall first phase validation: it can say nothing on the area not covered such as for example discovery, management, resources, etc. it can give only preliminary information of how a system implementing the first phase architectural choices and patterns can impact in key areas such as messaging, composition and presentation since o only one pattern covers messaging, composition and only one pattern cover presentation o validation has been done without the main objective of evidencing trade-off, bottlenecks or risks for the same reason, given the current situation, nothing of substantial can be said about the usability and interoperability of systems implementing all the first phase architectural choices and patterns. The PoC team will take into account the above lacks for the second phase of activities and, of course, will properly react on this. Always reasoning on Table 1 and Figure 13, we can state that: on the whole, 4 out of the 9 patterns of this first phase claim a negative impact on the performance attribute. This is the most negatively impacted quality attribute besides validating the specific patterns‟ claims about the quality attributes, the first phase validation can give useful feedbacks with respect to identification of sensitivity points (e.g. properties of a component that are critical to success of system) or trade-off points (properties that affect more than one attribute) for: o a system designing a scalable and high-available infrastructure for replicated data-sources services implementing the architectural choices of this first phase PoC, o a system supporting non repudiation and trusted time stamping signature. It is worth mentioning that the above are only preliminary considerations on the expected impact and, obliviously, the concrete validation results will be presented in the D8.2.

4 In fact actually they are only 6 5 In fact, there is only one pattern claiming this but it covers more key concerns. NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 38 of 122

4 CONCLUSION AND LESSONS LEARNT This document has presented and described the PoCs set up to validate the first set of patterns released by the horizontal workpackages and now in the process of harmonisation and integration inside the reference architecture. The PoC team has applied the process to identify and select the PoC presented in former deliverables (see [1]) in the respect of the overall recommendation of validating patterns‟ claim about quality attributes. Thus appropriate strategies to identify the PoC including suitable methods for validation and assessment criteria have been took in place. As general conclusion, the PoC team emphasises that even with a limited number of patterns some interesting feedbacks resulting from the POCs execution can be provided (in some area more than others) that can help the reference architecture team in improving the overall quality of the NEXOF-RA specifications. This is mainly true for PoCs aiming also to identify sensitivity or trade-off points. In terms of lessons learnt, the most important one to report is that, as already written also in [1], the different granularity and level of maturity of results from horizontal workpackages resulted in an unbalanced coverage of aspects to validate (most of them relating to WP4 concerns). This will be properly considered and will impact in the process of selection of the architectural choices and patterns to be validated in the second phase of PoC. In the second phase of PoC, in fact, particular attention has to be paid in selecting architectural choices and patterns in order: i) to cover the (currently wide) gaps identified in some key areas / concerns of the reference architecture that are not properly (or at all) addressed by this first phase of PoC, ii) to properly cover the new domain of Internet Of Services (IoS) selecting a wide number of patterns refining the top level IoS architectural one.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 39 of 122

5 REFERENCES [1] D8.0. b Proof-of-Concept Overall Process, NEXOF-RA project Deliverable [2] D7.5 NEXOF-RA V1.0, NEXOF-RA project deliverable [3] D6.2 RA Model V2.0, NEXOF-RA project deliverable [4] Apache Tuscany Project, http://tuscany.apache.org/ [5] Service Component Model specification, http://www.osoa.org/display/Main/Service+Component+Architecture+Specifi cations [6] TPC-W (a transactional web e-Commerce benchmark), http://www.tpc.org/tpcw/default.asp [7] SPECJAppServce (industrial benchmark) of the Standard Performance Evaluation Corporation, http://spec.unipv.it/ [8] D10.1 Requirement Report, NEXOF-RA project deliverable [9] Architecture Tradeoff Analysis Method, http://www.sei.cmu.edu/architecture/ata_method.html and Evaluating Software Architectures, Methods and Case Studies [Clements, Kazman, Klein, Addison-Wesley ISBN 0-201-70482-X]

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 40 of 122

6 ANNEX A: DETAILED DESCRIPTION OF THE CANDIDATE/SELECTED POC For each PoC, in this section we detail the table (including What is the objective of the PoC, Why the objective of the PoC is relevant, and How the validation should be proven, including methods, criteria, metric, way to document) and provide detailed instruction on how to install and use the software artefact. It is worth mentioning that the key aspects of each PoC have been summarised in the previous sections of this document.

6.1 Database Replication Interfaces for Highly Available Stateful Services POC Name Database Replication Interfaces for Highly Available Stateful Services What Owners Universidad Politécnica de Madrid (UPM) Description of In order to provide highly available stateful services, it is necessary to provide the PoC high availability at the service infrastructure level for persistent data stored in databases. Data replication is the main technique for providing highly available and scalable data services. Different architectural patterns have been proposed for replicating databases (See the White-Box, Gray-Box and Black-Box Database Replication patterns). Two of them are generic due to they implement database replication as a middleware component, outside the database, and therefore are amenable to be used with any database. In order to replicate transactions across nodes, after executing an update transaction locally at a node, the updates produced by it needs to be obtained in order to propagate them to the other replicas and therefore have a consistent state across replicas. The main difference across the architectural choices for replicating databases lie precisely on how transaction updates are obtained from the database. Black-box database replication implies to use the standard interfaces of the database since the database is considered as a black box. On the other hand, gray-box replication, can extend minimally the database interface to provide this functionality more efficiently. This PoC evaluates the different tradeoffs involved between the different patterns to acquire transaction updates to enable indirectly infer which are the tradeoffs between the middleware-based database replication patterns. ACPs The main architectural patterns validated in this PoC are Trigger Writeset involved Extraction, Log Mining Writeset Extraction and Writeset Extraction based on Extended Interfaces Objective of The main objective of this PoC is to evaluate the tradeoffs in terms of non- the PoC functional aspects of the different writeset extraction/injection interfaces for databases. We will evaluate the following quality attributes: performance, applicability and maintainability. The aim is to compare DB replication patterns (See the White-Box, Gray-Box and Black-Box DB Replication patterns) indirectly by means of microbenchmarking their main difference, that lies in the writeset extraction pattern used. With the results obtained, it will be possible to decide the most appropriate pattern to extract/inject writesets with a DB replication pattern . Functionalities The PoC focus on the functionalities that must provide databases in order to extract/inject writesets from/into them. In particular, it examines the differences in using approaches based on Standard Interfaces/Mechanisms provided by current databases (mainly Triggers and Log Mining) with regard to the use of ad- hoc Extended Interfaces that allow the extraction of writesets directly from the

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 41 of 122

database either in binary or textual form. Dependencies The architectural patterns used In this PoC are strongly related to the black-box, white-box and gray-box database replication approaches described in the corresponding patterns. The interfaces described in the patterns evaluated in this PoC allow the solutions described in the different database replication patterns to extract/inject the required writesets from the database, either in binary or textual form. Why Rationale As aforementioned in order to decide which database replication pattern should be used, one has to take into consideration which are the different tradeoffs among them in terms of quality attributes. It turns out that most of the quality attributes derived from the way transaction updates are extracted from the database since this strongly affects the resulting quality attributes. Architecture The main architectural components affected are databases. They are the Component(s) architectural components that must provide these writeset extraction/injection affected interfaces.

Alternatives The different alternatives of extracting data from a database are described in depth in the patterns related to database interfaces for writeset extraction and evaluated in this PoC. There are two main approaches: . Standard DB Interfaces (Triggers and Log Mining) – They are general purpose interfaces provided by current databases that can be exploited to extract/inject the required writesets. These interfaces allow implementing portable solutions due to the fact that the information provided by the interfaces can be analyzed. . Extended DB Interfaces – They are ad-hoc interfaces exhibited specifically to extract/inject writesets from outside the database. The writesets can either be extracted in binary or textual (SQL form). Relationship High availability and scalability are two requirements of today‟s SOI. Databases with the are a key component of service-oriented infrastructures and replicating them NEXOF-RA necessary for attaining high available and scalable NEXOF-RA compliant architectures. The service runtime component is many times architected using the Multi-Tier Transactional Service Runtime pattern. A database component is used to provide persistency and data coherence guarantees so called ACID properties. The database replication patterns are used to provide high availability and scalability to service runtimes architected via the multi-tier pattern. The writeset extraction patterns are used by the database replication patterns to extract NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 42 of 122

transaction updates that need to be propagated across replicas.

How Scenarios for This PoC addresses the evaluation of different architectural alternatives for a validation specific component of database replication patterns. As such it is not directly linked to any scenario and the evaluation performs specific microbenchmarks. However, it is indirectly linked with any scenario with high availability and/or scalability requirements that might rely on a replicated database such as the e- commerce scenario in D10.1 (S12). So, the evaluation of the different injection/extraction mechanisms is going to be done directly by means of microbenchmarks on different database management systems, both commercial and open-source: Microsoft SQLServer, PostgreSQL and MySQL. The microbenchmarks will inject an increasing number of transactions in configured databases. Suggested A set of clients will inject transactional load on the different database systems Architecture compared. So, a client machine will inject the load to a database running in a separate machine. The environment for the tests is a LAN.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 43 of 122

Environment The hardware used for the POC consists of computers with AMD Athlon dual CPUs (2GHz), with 1 GB of RAM and two 320 GB hard disks. The running operating system is a Fedora Linux distribution. The writeset extraction/injection interfaces will be evaluated in three database management systems: Microsoft SQLServer, PostgreSQL and MySQL. The binary writeset capture is implemented in Postgres. The textual writeset capture is implemented in MySQL. Triggers and Log Mining are implemented in MS SQL Server. Estimated 12 persons-months. Main efforts: setup the systems (install all server software Effort and configure them), run the evaluations and finally assess them.

Methods The method used to measure the effects of data extraction/injection of the different methods proposed consists in comparing the results obtained in a baseline of a particular configuration (without using any writeset extraction/injection method) against the same database system configured with a particular extraction/injection method for an increasing number of transactions.

Assessment As this PoC aims at evaluating a very technical set of patterns and therefore is criteria & far from any business scenario from which extract business requirements, we metrics & way depart from the technical requirements of quality attributes addressed by the to document architectural patterns. We use the ATAM utility tree for matching the technical quality attributes (performance, applicability and maintainability) with metrics to be used in the evaluation. The utility tree for the patterns applied in this PoC is presented in the following figure:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 44 of 122

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 45 of 122

For evaluating the quality attributes we have used the following evaluation methodology. We will use specific microbenchmarks to evaluate the throughput and the response time of the different writeset extraction methods. Since each pattern can only be applied to one or more databases (due to their different assumptions) and there is no single database supporting the implementation of all the patterns, we need to use different databases (described above). We compare the relative performance of transaction execution with a particular writeset extraction pattern with the performance of the same database without writeset extraction. This enables us to quantify the overhead of the different patterns and compare them despite having been exercised on different databases. The applicability is measured as the number and strength of assumptions and the maintainability as the number of components we require to modify and maintain. The generic quality attributes identified for each pattern are (See the documents for each pattern description): Trigger Writeset Extraction . Performance  - . Applicability  + . Maintainability  + Log Mining Writeset Extraction . Performance  - . Applicability  0 . Maintainability  + Writeset Extraction Based on Extended Interfaces . Performance  + . Applicability  - . Maintainability  0

Further Information

6.1.1 Detailed description of the software artefacts 6.1.1.1 System requirements Linux (kernel > 2.6) Java Ensemble 1.42 6.1.1.2 Description of the involved tools/components and description of their integration Middle-r: Middleware system that is put between applications and database management systems and performs replication. PostgreSQL enhanced with binary writeset extraction/injection: Database Management System that provides the gray box approach to database replication. JDBC: Database access interface that provides interaction between applications and middle-r.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 46 of 122

TPC-W: Web e-commerce application used to benchmark the writeset extraction. Used the implementation from U. Winsconsin. See http://www.ece.wisc.edu/~pharm/tpcw.shtml and http://www.tpc.org for further information. Apache Tomcat 5.5 Servlet/JSP Container: Used to deploy the e-commerce application. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. Ensemble: group communication system used by Middle-r. 6.1.2 How to install Middle-r: Untar and copy in the desired location. PostgreSQL enhanced with binary writeset extraction/injection: Untar and copy in the desired location. JDBC: Put the jar files in the common lib directory of tomcat to be accessible to the applications. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. TPC-W: Install the compiled servers in tomcat. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. Apache Tomcat 5.5 Servlet/JSP Container: Copy and untar tomcat.tgz in the desired location. This file also contains jdbc and tpcw installed on tomcat. Ensemble: See http://dsl.cs.technion.ac.il/projects/Ensemble/ to install ensemble 1.42 6.1.3 How to use 1) COMPILING Before compiling middle-r, functions schema_create and schema_get_tableid in file schema.c should be implemented. Makefile is provided. Some environment variables should be defined in file config.h or the valued passed when compiling middle-r NUM_CLIENT_MNG: client manager pool size NUM_EDGES: number of cluster edges (1 if only one LAN is considered) MAX_REPLICAS: total number of nodes MAX_LOCAL_TXN: maximum number of local transactions that can be executed by each node DATABASENAME: name of the database in the DB backend 2) EXECUTING MIDDLE-R PRE: postgresql should be running and listening in port 6551 as described in http://www.postgresql.org/docs/7.2/static/index.html.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 47 of 122

Ensemble 1.42 should be installed on the machine as described in http://dsl.cs.technion.ac.il/projects/Ensemble To execute middle-r use the following command depending on the role of the middle-r instance $./middlersip-globalseg EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) $./middlersip-localseg EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) $./middlersip-simplerep EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) The config file should have the following format: my_eid=int my_gid=int num_db_connections=int num_threads=int mp_level=int global_seq_addr=string | local_seq_addr=string monitoring_time=int wan_latency=int The meaning of each entry is the following: my_eid: the identifier of the edge cluster. It should be 0 if only one LAN is considered my_gid: the identifier of the data group inside the cluster. It should be 0 if only FULL REPLICATION is considered num_db_connections: number of db connections between middle-r and the db backend num_threads: number of threads serving db requests mp_level: number of concurrent threads allowed to execute in the db backend global_seq_addr: name of the global sequencer node global_seq_addr: name of the local sequencer node monitoring_time: statistics collection time period wan_latency: average latency between this node and the main cluster Environment variables that should be defined and available during middle-r execution DBUSER: database user used to connect to postgresql MIDDLEWARE_DIR: working dir of middle-r NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 48 of 122

ENS_OUTBOARD_TYPE: ensemble 1.42 configuration parameter PARTITION_MATRIX_FILE: path to the file containing the initial replication schema use file FULL-matrix-file for FULL REPLICATION or put in the file one line r[eid][pid] per partition with identifier (type int) pid not replicated in edge eide (type int) and end the file with an 'e' in the last line. See examples in files *-matrix-file 3) EXECUTING THE TESTS Just follow the instructions on http://www.ece.wisc.edu/~pharm/tpcw.shtml to configure and run the TPC-W client (RBE) 6.1.4 Details to access to the PoC instance you have implemented - 6.1.5 Packaging DVD location: D8.1a-SoftwarePackages\DB and WAN

6.2 Gray-Box Database Replication Architectural Pattern For Highly Available Stateful Services POC Name Gray-Box Database Replication Architectural Pattern For Highly Available Stateful Services What Owners Universidad Politécnica de Madrid (UPM) Description of In current service oriented infrastructures, high availability and scalability are the PoC common requirements. When considered for stateful services based on databases, they imply to implement some form of database replication. High availability provides 24/7 access to data using clusters of nodes that contain replicas of the data. In this way, if one of the nodes fails, the data is not lost remains available to other requests. Scalability is another key feature required by many service infrastructures. Scalability enables to cope with increasing loads by using a higher number of nodes. Several architectural patterns are available for attaining highly available data: white, gray and black box data replication (See White-Box, Gray-Box and Black-Box Database Replication patterns for further information). The White-Box DB Replication pattern addresses availability by implementing data replication within the database kernel. Black-Box DB Replication pattern takes the database as a black box and using only its standard interface implement replication outside the database. The White-Box approach might be more performant and scalable but requires access to the database code what in many cases is not possible, and when possible too complex. The Black- Box approach can be applied to any database without access to its code however it might be more costly. The Gray-Box DB Replication pattern has been proposed to have the best of black and white architectural patterns. The core idea of the Gray-Box approach is to identify some minimal functionality to be exposed by the database that can enable to provide a solution as performant and scalable as the White-Box architectural pattern but without access to the database code and using a standard database except for the new identified interface. This PoC aims to demonstrate the validity of architectural choices and architectural patterns described in NEXOF-RA with regard to data replication of data sources, in particular databases.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 49 of 122

ACPs Gray-Box Database Replication architectural pattern. involved Objective of The goal of this PoC is to evaluate the scalability of the Gray-Box database the PoC replication pattern. The aim is to quantify the scalability in terms of how many times the peak throughput of non-replicated database can be multiplied by using a replicated database with an increasing number of nodes and in this way determine the limits of the approach in terms of throughput scale out. The other quality attributes evaluated for this pattern are applicability and maintainability. Functionalities The PoC focus on the functionality of replicated databases in order to provide high availability and scalability in the data tier. Dependencies The architectural pattern used In this PoC depend on the writeset extraction interfaces described in the Writeset Extraction based on Extended DB Interfaces pattern. More concretely on the extended DB interface writeset extraction patterns. Moreover, for failover purposes, this pattern uses the Transparent Replication Proxy in order to provide replication transparency to the clients. Finally, in order to discover the different replicas the Multicast-Based Replica Discovery pattern is used.

Why Rationale For an architectural pattern promising scalability is crucial to quantify this scalability. The scalability should measure how many times the peak throughput of the original, non-replicated system is multiplied by the throughput of the replicated system with a particular number of replicas. This quantification is crucial to understand whether the scalability requirements of a particular application can be met by the chosen database replication pattern. Architecture The main architectural components affected by this PoC are databases. They are Component(s) the architectural components that contain the critical data that must be replicated affected in order to provide high availability and scalability to the applications that use these data. Database replication is controlled by a replication middleware in charge of communicating the changes among the different replicas deployed in a LAN and extracting/injecting the required data from the database through the extended database replication interfaces. The middleware is accessed by an application server.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 50 of 122

Alternatives The different alternatives to replicate database systems are described in depth in the White-Box and Black-Box Database Replication patterns. In addition to the solution used in this PoC to extract/inject data from a database, there are other different alternatives described in depth in the patterns Trigger Writeset Extraction and Log Mining Writeset Extraction. Relationship High availability and scalability are two requirements of today‟s SOI.NEXOF-RA with the addresses them at different levels. In particular, one of the most common forms NEXOF-RA of the service runtime component is the Multi-Tier Transactional Service Runtime pattern. In this pattern, a database component is used to provide persistency and data coherence guarantees so called ACID properties. The database replication patterns are used to provide high availability and scalability to service runtimes architected via the multi-tier pattern.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 51 of 122

How Scenarios for The scenario for validation is an e-commerce scenario which provides the validation services of an online bookstore. This scenario is similar to the one that is described in D10.1 (e-Commerce information sharing, S12). Suggested In order to evaluate the Gray-Box database replication a cluster is required. The Architecture online bookstore application is a web application based on a three-tier architecture. So, each node/replica of the cluster includes a web/application server that includes the presentation and the business logic of the application and a replicated database system containing a full replica of the persistent data used by the application. A client node runs emulated clients that inject request in the replicated infrastructure. The components are interconnected through a LAN.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 52 of 122

Environment The employed hardware environment consists of nodes with AMD Athlon dual CPUs (2GHz), with 1 GB of RAM and two 320 GB hard disks. The running operating system is a Fedora Linux distribution. The validation is going to be performed using the industrial benchmark TPC-W for web-based applications that provides an e-commerce application for selling books through the web. The particular choice of software components is the following: Tomcat web server/sevlet container/application server. Contains the TPC-W application services. PostgreSQL database server enhanced with binary writeset extraction/injection. Contains the data of the TPC-W application. Middle-R replication middleware for replicating PostgreSQL data. Ensemble group communication system in order to communicate the Middle-R replicas. Estimated 1-2 persons-month. Main efforts: setup the cluster (install all server software, Effort TPC-W application, configure it at all sites), running the evaluation and assessing it.

Methods The method used to evaluate the scalability of the Gray-Box DB Replication pattern lies in comparing the results obtained in the performance evaluation of a non-replicated system with the performance results obtained in a cluster

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 53 of 122

configured with gray-box data replication approach, for an increasing number of replicas (nodes).

Assessment The assessment criteria are partially based on the ATAM methodology that has criteria & been adapted to our specific needs that is to evaluate, quantify and compare the metrics & way tradeoffs between architectural choices by means of ATAM‟s utility trees. The to document ATAM methodology was originally developed to assist architectural decisions by taking into account early in the design process the quality attributes. Moreover, in this PoC, the business requirements of the utility tree have been obtained from the online bookstore application provided by a benchmark. The utility tree for the Gray-Box DB Replication pattern applied in this PoC is depicted in the following picture:

So, in here, we use the ATAM utility trees to derive from the scenario, business requirements and metrics (on the right side of the figure), technical requirements and quality attributes (on the left side). Then, we use an evaluation methodology based on industrial practice. We will use a standard benchmark (TCP-W) that allows to evaluate the performance of databases in terms of throughput and response times. We extend the evaluation to quantify the scale-out by running the benchmark with different configurations. We will inject increasing loads to the system till reaching saturation for each configuration. The scale-out shows how many times a particular number of replicas multiply the peak throughput of a non-replicated setup. Also as part of

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 54 of 122

the scalability evaluation the average response time for client requests will be obtained. Availability is measured as the number of single points of failure of the solution. The applicability is measured as the number and strength of assumptions and the maintainability as the number of components we require to modify and maintain. The generic quality attributes for the Gray-Box DB Replication pattern are (See the document for the pattern): . Scalability  + . Applicability  + . Applicability  - . Maintainability  - Further Information

6.2.1 Detailed description of the software artefacts 6.2.1.1 System requirements Linux (kernel > 2.6) Java Ensemble 1.42 6.2.1.2 Description of the involved tools/components and description of their integration Middle-r: Middleware system that is put between applications and database management systems and performs replication. PostgreSQL enhanced with binary writeset extraction/injection: Database Management System that provides the gray box approach to database replication. JDBC: Database access interface that provides interaction between applications and Middle-r. TPC-W: Web e-commerce application used to benchmark the replication system. Used the implementation from U. Winsconsin. See http://www.ece.wisc.edu/~pharm/tpcw.shtml and http://www.tpc.org for further information. Apache Tomcat 5.5 Servlet/JSP Container: Used to deploy the e-commerce application. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. Ensemble: group communication system used by Middle-r. 6.2.2 How to install Middle-r: Untar and copy in the desired location. PostgreSQL: Untar and copy in the desired location.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 55 of 122

JDBC: Put the jar files in the common lib directory of tomcat to be accessible to the applications. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. TPC-W: Install the compiled servers in tomcat. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. Apache Tomcat 5.5 Servlet/JSP Container: Copy and untar tomcat.tgz in the desired location. This file also contains jdbc and tpcw installed on tomcat. Ensemble: See http://dsl.cs.technion.ac.il/projects/Ensemble/ to install ensemble 1.42 6.2.3 How to use 1) COMPILING Before compiling middle-r, functions schema_create and schema_get_tableid in file schema.c shuould be implemented. Makefile is provided. Some environtment variables should be defined in file config.h or the valued passed when compiling middle-r NUM_CLIENT_MNG: client manager pool size NUM_EDGES: number of cluster edges (1 if only one LAN is considered) MAX_REPLICAS: total number of nodes MAX_LOCAL_TXN: maximum number of local transactions that can be executed by each node DATABASENAME: name of the database in the DB backend 2) EXECUTING MIDDLE-R PRE: postgresql should be running and listening in port 6551 as described in http://www.postgresql.org/docs/7.2/static/index.html. Ensemble 1.42 should be installed on the machine as described in http://dsl.cs.technion.ac.il/projects/Ensemble To execute middle-r use the following command depending on the role of the middle-r instance $./middlersip-globalseg EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) $./middlersip-localseg EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) $./middlersip-simplerep EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) The config file should have the following format: my_eid=int my_gid=int

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 56 of 122

num_db_connections=int num_threads=int mp_level=int global_seq_addr=string | local_seq_addr=string monitoring_time=int wan_latency=int The meaning of each entry is the following: my_eid: the identifier of the edge cluster. It should be 0 if only one LAN is considered my_gid: the identifier of the data group inside the cluster. It should be 0 if only FULL REPLICATION is considered num_db_connections: number of db connections between middle-r and the db backend num_threads: number of threads serving db requests mp_level: number of concurrent threads allowed to execute in the db backend global_seq_addr: name of the global sequencer node global_seq_addr: name of the local sequencer node monitoring_time: statistics collection time period wan_latency: average latency between this node and the main cluster Environment variables that should be defined and available during middle-r execution DBUSER: database user used to connect to postgresql MIDDLEWARE_DIR: working dir of middle-r ENS_OUTBOARD_TYPE: ensemble 1.42 configuration parameter PARTITION_MATRIX_FILE: path to the file containing the initial replication schema use file FULL-matrix-file for FULL REPLICATION or put in the file one line r[eid][pid] per partition with identifier (type int) pid not replicated in edge eide (type int) and end the file with an 'e' in the last line. See examples in files *-matrix-file 3) EXECUTING THE TESTS Just follow the instructions on http://www.ece.wisc.edu/~pharm/tpcw.shtml to configure and run the TPC-W client (RBE) 6.2.4 Details to access to the PoC instance you have implemented -

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 57 of 122

6.2.5 Packaging DVD location: D8.1a-SoftwarePackages\DB and WAN

6.3 Vertical Replication Architectural Pattern For Scalable and Highly Available Stateful Services POC Name Vertical Replication Architectural Pattern For Scalable and Highly Available Stateful Services What Owners Universidad Politécnica de Madrid (UPM) Description of Current state-of-the-art for availability and scalability of services architected in the PoC multiple tiers only addresses the replication of session state at the application server tier (e.g. using the Session Replication pattern) or replication at the data tier (e.g. White-Box, Gray-Box and Black-Box Database Replication patterns), but not of both tiers at the same time. Thus, the non-replicated tier may become a single point of failure and a scalability bottleneck for the infrastructure. The Vertical Replication pattern evaluated in this PoC goes beyond current state-of- the-art by enabling to provide scalability and availability of services architected in multiple tiers whilst guaranteeing full consistency of the solution. This PoC aims to demonstrate the validity of architectural choices and architectural patterns described in NEXOF-RA with regard to vertical data replication in multi-tier architectures. ACPs The Vertical Replication pattern. involved Objective of The main objective of this PoC is to evaluate the trade-offs in non-functional the PoC attributes (scalability, availability, applicability and maintainability) between the vertical replication approach and other architectural choices such as non- replicated solutions and single-tier replication. Functionalities The PoC focus on functionalities to attain a holistic replication of multi-tier architectures. Dependencies The pattern used in this PoC is the Vertical Replication pattern. Other architectural patterns such as Multicast-Based Replica Discovery, Session Replication and Transparent Replication Proxy are also used by the Vertical Replication pattern for discovery of replicas and transparent failover and session state replication.

Why Rationale High availability and scalability are two key features for applications and current SOI that is typically multi-tiered. The Vertical Replication pattern provides a holistic solution to satisfy these requirements. However, it is necessary to quantify the degree of scalability to understand in which scenarios it can be used. This POC aims at performing this quantification to identify the scalability limits of the pattern and therefore, its applicability. Architecture The main architectural components affected by this PoC is the service runtime, Component(s) more specifically its multi-tier specialization that consists of an application server affected and a database components (See Multi-Tier Transactional Service Runtime pattern).

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 58 of 122

Alternatives Other alternatives to the Vertical Replication pattern perform the replication of a single tier, either the middle-tier (See the Session Replication pattern) or the data-tier (see White-Box, Gray-Box and Black-Box Database Replication patterns). However, these solutions have single points of failure and bottlenecks in the non-replicated tier. An alternative pattern addressing the replication of both tiers is the Horizontal Replication pattern. Relationship High availability and scalability are two key requirements of current SOI and with the addressed by NEXOF-RA. The service run-time is typically architected in a multi- NEXOF-RA tier manner (See Multi-Tier Transactional Service Runtime pattern). The vertical replication pattern addresses precisely these requirements for this architectural pattern of the service run-time.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 59 of 122

How Scenarios for The scenario is a supply-chain management application architected with a multi- validation tier service run-time (See Multi-Tier Transactional Service Runtime pattern). This application allows to maintain an inventory of products by retailer and to sell/order manufactured goods when necessary. This scenario is related to the one that is described in D10.1 (e-Commerce information sharing, S12). Suggested The architecture includes application implemented in a three-tier architecture, Architecture with the web server, application server, and database tiers. The vertical replication pattern is used to replicate the whole system. Each node of the cluster includes a web server that includes the UI (presentation tier), an application server that runs the business logic of the application (middle-tier) and a database system containing the data used by the application (data-tier). A client node runs the emulated clients of the benchmark that inject requests in the system at a given rate.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 60 of 122

Environment The available hardware consists of computers with AMD Athlon dual CPUs (2GHz), with 1 GB of RAM and with 320 GB in the hard disk. The running operating system is a Fedora Linux distribution. The validation is going to be performed using an industrial benchmark for J(2)EE application servers called SPECjAppServer which includes the supply-chain management application that provides services to car dealers for selling cars through an intranet (LAN) environment. The particular choice of software components is the following: Apache web server to distribute the load to the different replicas of the cluster. Tomcat application server. Runs the presentation part of the application. JOnAS J(2)EE application server. Contains the business logic of the application. Spread group communication system to communicate the application server replicas. PostgreSQL database server. Contains the data of the SPECjAppServer application. Estimated 1-2 PMs. Main efforts: setting up the system (install all server software, SPEC- NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 61 of 122

Effort AppServ, connect all components, configure them), setup the cluster (install the nodes, set up the software to run the nodes such as network booting, private network, NIS/NFS), running the evaluation and assessing it.

Methods The method used to measure the advantages of the Vertical Replication pattern in multi-tier consists in comparing the results obtained in the performance evaluation of the vertical replication approach against a non-replicated approach and some of the standard replication solutions currently available for multi-tier applications.

Assessment The assessment criteria are partially based on the ATAM methodology that has criteria & been adapted to our specific needs that is to evaluate, quantify and compare the metrics & way tradeoffs between architectural choices by means of utility trees. Moreover, in this to document case, the business requirements of the utility tree have been derived from a particular scenario related to an online bookstore application included in a benchmark. The utility tree for the Vertical Replication pattern applied in this PoC is depicted in the following picture:

In the figure are shown the business requirements and metrics identified (on the right side of the figure), technical requirements and quality attributes (on the left side). Apart from ATAM, we will use an evaluation methodology based on industrial practice. We use a standard benchmark (TCP-W) that allows to evaluate the performance of databases in terms of throughput and response times. We will NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 62 of 122

inject increasing loads to the system till reaching saturation for each configuration. We extend the evaluation to quantify the scale-out by running the benchmark with different configurations. The scale out shows how many times a particular number of replicas multiply the peak throughput of a non-replicated setup. Also as part of the scalability evaluation the average response time for client requests will be obtained. Since the benchmark itself does not express the requirements of availability, applicability and maintainability, they have been evaluated with regard to the requirements of the architectural pattern. Availability is measured as the number of single points of failure of the solution. The applicability is measured as the number and strength of assumptions and finally, the maintainability is measured as the number of components we require to modify and maintain. The generic quality attributes for the Vertical Replication pattern are (See the document for the pattern): . Scalability  + . Applicability  + . Applicability  + . Maintainability  0 Further Information

6.3.1 Detailed description of the software artefacts – Vertical Replication The vertical replication protocol for stateful components has been introduced as a service in the JOnAS open-source application server. The following are the instructions for installing JOnAS and test vertical replication. In order to test the vertical replication, the installation of a cluster with two nodes will be described. Each node includes a JOnAS instance associated to its own Postgres database instance. The configuration has been tested using the SpecJAppServer 2004 benchmark. 6.3.1.1 System requirements JOnAS requires the following software in order to be executed. Please, refer to the URLs in order to find information about the installation procedure: JDK 1.4: http://java.sun.com/j2se/1.4/download.html Apache Ant 1.6: http://ant.apache.org/bindownload.cgi Spread 4.0: http://www.spread.org/download.html Apache Tomcat 5.5.15: http://tomcat.apache.org/ Apache HTTP Server 2.2.2: http://httpd.apache.org/ Apache Mod JK 1.2.20: http://tomcat.apache.org/connectors-doc/ Postgresql 8.2.0: http://www.postgresql.org/ SpecJAppServer Benchmark: http://www.spec.org/jAppServer2004/ NOTE: SpecJAppServer is not open-source and a license must be acquired

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 63 of 122

6.3.1.2 Description of the involved tools/components and description of their integration - 6.3.2 Installation Guide - Vertical Replication 6.3.2.1 Installing JOnAS (JOnAS version 4.7.1 with replication) NOTE: This process must be repeated for each node. Before start with the JOnAS installation, JDK, Ant and Spread must be installed. 1) Spread must be configured statically with the addresses of the two nodes. Edit the spread.conf file and add the following configuration: Spread_segment :16666 { node1 node2 } 2) Choose/create a destination directory for JOnAS and uncompress the JOnAS file that is included in this package: $ tar xvfz VerticalReplication.tgz - Two directories appear after uncompressing the file: jonas/ and jonasbase/. NOTE: The JOnAS version used as a base is 4.7.1 3) Export the environment variables required by JOnAS and add the bin directory of the concrete operating system to the PATH variable: $ export JONAS_ROOT= $ export JONAS_BASE= - NOTE: JONAS_BASE contains the JOnAS configuration ready to be used with the SpecjAppServer application $ export PATH=$JONAS_ROOT/bin/unix:$PATH 4) Check the JOnAS installation: NOTE: Before checking the JOnAS installation, please comment temporarily the "spec" datasource from $JONAS_BASE/conf/jonas.properties file #jonas.service.dbm.datasources spec a) Start Spread: $ spread -c b) Start JOnAS: $ jonas start c) Use a browser to go to: http://localhost:9000/

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 64 of 122

d) Finally, if JOnAS works properly, stop JOnAS in order to prepare the installation of the test application: $ jonas stop Once JOnAS is installed, the environment for the SpecjAppServer application must be installed as well. The application will be installed in two different nodes, placing in every one an instance of the JOnAS application server. 6.3.2.2 Preparing the environment for the test application (SpecjAppServer) In order to test the example application 2 JOnAS instances will be used. Below the process of installing every JOnAS instance in a different node. 1) Fist of all, Postgresql must be installed in the each node. 2) Then, follow the previous instructions to install JOnAS in every node. NOTE: Remember to uncomment the "spec" datasource from jonas.properties file 3) Configure the SpecJAppServer application for the JOnAS application server adapting the deployment descriptors. Information on how to configure an application for running in JOnAS can be found in http://jonas.objectweb.org/JOnAS_4_7/doc/. When specifying the lock policy for the Entity Beans use the "si" (Snapshot isolation) policy. E.g.: si 4) Configure the database schemas of SpecJAppServer in order to be used with Postgresql. 5) Then, we have to install and configure Apache and mod_jk in one of the nodes (e.g. in node 1) in order to distribute the load among the two nodes: a) Create a file tomcat_jk.conf and workers.properties in $APACHE_HOME/conf/jk/ b) Contents of the tomcat_jk.conf file: # Location of the worker file JkWorkersFile "conf/jk/workers.properties" # Location of the log file JkLogFile "conf/jk/mod_jk.log" # Log level : debug, info, error or emerg JkLogLevel emerg # Shared Memory Filename ( Only for Unix platform ) # required by loadbalancer JkShmFile conf/jk/jk.shm

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 65 of 122

# Assign specific URL to Tomcat workers # A mount point from a context to a Tomcat worker JkMount /SPECjAppServer loadbalancer JkMount /SPECjAppServer/* loadbalancer # A mount point to the status worker JkMount /jkmanager jkstatus JkMount /jkmanager/* jkstatus # Enable the Jk manager access only from localhost JkMount jkstatus Order deny,allow Deny from all Allow from 127.0.0.1 c) Contents of the worker.properties file: # List the workers' names worker.list=loadbalancer,jkstatus # ------# First worker # ------worker.worker1.port=8009 worker.worker1.host= worker.worker1.type=ajp13 # Load balance factor worker.worker1.lbfactor=1 # ------# Second worker # ------worker.worker2.port=8009 worker.worker2.host= worker.worker2.type=ajp13 worker.worker2.lbfactor=1 # ------# Load Balancer worker NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 66 of 122

# ------worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=worker1,worker2 #Specifies whether requests with session's id should be routed to the #same worker worker.loadbalancer.sticky_session=true worker.loadbalancer.method=Session

# ------# jkstatus worker # ------worker.jkstatus.type=status 6) Edit the $APACHE_HOME/httpd.conf file and add the reference to the mod_jk configuration created above: # Include the user configurations: Include conf/jk/tomcat_jk.conf 7) Then in every JOnAS instance go to the $JONAS_BASE/conf directory and edit the server.xml file. This is necessary in order to link Apache with Tomcat. a) Replace the line with: where X is 1 or 2 depending on the JOnAS instance we are configuring. 6.3.3 User Guide In order to execute the example application, the following instructions must be followed: 1) Execute apache in node 1: $ apachectl restart 2) Execute the Postgres instances in every node: $ postmaster -i -D 3) Create and fill a database for SpecJAppServer following the instructions 4) Inject the database in the Postgres instance of every node: 5) Execute spread in every node: $ spread -c 6) Execute the JOnAS instances in every node:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 67 of 122

$ jonas start 7) Go to: http://ip-address-of-apache-node:80/SPECjAppServer A web page should appear saying that the SpecAppServer application is ready 6.3.4 Details to access to the PoC instance you have implemented - 6.3.5 Packaging DVD location: D8.1a-SoftwarePackages\Vertical Replication. 6.3.6 Detailed description of the software artefacts – Session Replication The session replication protocol for session components is embedded in the JOnAS open-source application server. The following are the instructions for installing JOnAS and test horizontal replication. In order to test the session replication, we are going to describe the installation of an example application deployed in two instances of JOnAS running in two different nodes and sharing the same application database. 6.3.6.1 System requirements JOnAS requires the following software in order to be executed. Please, refer to the URLs in order to find information about the installation procedure. JDK 1.4: http://java.sun.com/j2se/1.4/download.html Apache Ant 1.6: http://ant.apache.org/bindownload.cgi Apache HTTP Server 2.2.2: http://httpd.apache.org/ Apache Mod JK 1.2.20: http://tomcat.apache.org/connectors-doc/ 6.3.7 Description of the involved tools/components and description of their integration - 6.3.8 How to install 6.3.8.1 Installing JOnAS (JOnAS version 4.10.3 with Tomcat 5.5.26) Before start with the JOnAS installation, JDK and Ant must be installed. 1) Choose/create a destination directory for JOnAS and uncompress the JOnAS file that is included in this package: $ tar xvfz jonas4.10.3-tomcat5.5.26.tgz 2) Export the environment variable to locate JOnAS and add the bin directory of the concrete operating system to the PATH variable: $ export JONAS_ROOT= $ export PATH=$JONAS_ROOT/bin/unix:$PATH 3) Check the installation: a) Start JOnAS:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 68 of 122

b) $ jonas start c) Use a browser to go to: d) http://localhost:9000/ If you find problems for installing JOnAS, please refer to: http://jonas.objectweb.org/current/doc/doc- en/integrated/howto/install_j2ee.html e) Finally, if JOnAS works properly, stop JOnAS in order to prepare the installation of the test application: $ jonas stop Once JOnAS is installed, we are going to install an example application. We are going to install the application in two different nodes, placing in every one an instance of the JOnAS application server. 6.3.8.2 Configuring the Example application (Samplecluster2) In order to test the example application we are going to use 2 JOnAS instances. Here, we describe the process of installing every JOnAS instance in a different node. 1) Follow the previous instructions to install JOnAS in every node. After JOnAS is installed in the two nodes, we need to edit several JOnAS configuration files in order to run the application. 2) In every JOnAS instance, go to the $JONAS_ROOT/conf directory and: a) Edit the jonas.properties file and add to the jonas.services list the "ha" service (high availability service). b) Edit the carol.properties file and change the carol.protocols property to use the "cmi" protocol instead of "jrmp" c) The two JOnAS instances are going to share the same application database. So, for example, we have to edit the HSQL1.properties file of one of them to point to the database of the instance running in the first node: 3) Change the datasource.url to jdbc:hsqldb:hsql://ip-address- of_node1:9001/db_jonas 4) The application to install is in the sampleCluster2 directory: $ cd $JONAS_ROOT/examples/sampleCluster2 5) Edit the build.xml file and in the "jonasejbjar" target change the "enableLbMode" antcall target by "enableHaMode". 6) Compile the application: $ ant ear

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 69 of 122

7) This will generate a file called output/apps/sampleCluster2.ear. This file must be added to the $JONAS_ROOT/apps/autoload directory of every JOnAS instance. $ cp $JONAS_ROOT/examples/sampleCluster2/output/apps/sampleCluster2.ear $JONAS_ROOT/apps/autoload 8) Then, we have to install Apache+mod_jk in one of the nodes in order to distribute the workload among the two nodes. Let's assume that it is going to be installed in node 1. The installation instructions can be found in http://www.apache.org/. 9) Then, we have to configure Apache and mod_jk: a) Create a file tomcat_jk.conf and workers.properties in $APACHE_HOME/conf/jk/ b) Contents of the tomcat_jk.conf file: # Location of the worker file JkWorkersFile "conf/jk/workers.properties" # Location of the log file JkLogFile "conf/jk/mod_jk.log" # Log level : debug, info, error or emerg JkLogLevel emerg # Shared Memory Filename ( Only for Unix platform ) # required by loadbalancer JkShmFile conf/jk/jk.shm # Assign specific URL to Tomcat workers # A mount point from a context to a Tomcat worker JkMount /sampleCluster2 loadbalancer JkMount /sampleCluster2/* loadbalancer # A mount point to the status worker JkMount /jkmanager jkstatus JkMount /jkmanager/* jkstatus # Enable the Jk manager access only from localhost > JkMount jkstatus Order deny,allow Deny from all Allow from 127.0.0.1

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 70 of 122

c) Contents of the worker.properties file: # List the workers' names worker.list=loadbalancer,jkstatus # ------# First worker # ------worker.worker1.port=8009 worker.worker1.host= worker.worker1.type=ajp13 # Load balance factor worker.worker1.lbfactor=1 # ------# Second worker # ------worker.worker2.port=8009 worker.worker2.host= worker.worker2.type=ajp13 worker.worker2.lbfactor=1 # ------# Load Balancer worker # ------worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=worker1,worker2 #Specifies whether requests with session's id should be routed to the #same worker worker.loadbalancer.sticky_session=true worker.loadbalancer.method=Request # ------# jkstatus worker # ------worker.jkstatus.type=status 10) Edit the $APACHE_HOME/httpd.conf file and add the reference to the mod_jk configuration created above:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 71 of 122

# Include the user configurations: Include conf/jk/tomcat_jk.conf 11) Then in every JOnAS instance go to the $JONAS_ROOT/conf directory and edit the server.xml file. This is necessary in order to link Apache with Tomcat. a) Configure Tomcat for the connector AJP13 uncommenting: b) Replace the line with: where X is 1 or 2 depending on the JOnAS instance we are configuring. c) Uncomment the tag for session replication 6.3.8.3 Executing the Example application (Samplecluster2) 1) Execute apache in node 1: $ apachectl restart 2) Execute the JOnAS instances in every node: $ jonas start -n nodeX (where X is 1 or 2 depending on the node) 3) Go to: http://ip-address-of-apache-node:80/sampleCluster2 A simple web page should appear saying that the sample is OK 6.3.9 How to use A useful practice can be considered the testing of the Horizontal Replication (Samplecluster2). The application consists of a front end stateless component (EJB) that calls an inner stateful component. The application allows the users to start/end sessions and perform calls inside the session boundaries. The inner stateful component is replicated and maintains a counter of the number of requests performed inside the session. Apache has been configured in order to redirect every client request to any node. As the application has been configured to replicate session state, there is no problem in redirecting each request to a different node. 1) Click "Open a session" in the initial Samplecluster2 web page. 2) The web page received informs about the results of the request. More specifically, it informs about the node where the request has been redirected. There is a stateless component in every node that calls the replicated stateful component. The application informs about the number of

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 72 of 122

calls to the stateless component in every node and the total number of calls to the replicated stateful component (Inner count) 3) We can perform several requests to the application inside the same session clicking "Ask again" in order to see the effects of every request on the different nodes. It is important to note that, for the same session, the state of the "Inner count" is increased and is the same either if the client request is redirected to the node 1 or 2. 4) In order to check the high availability features for sessions provided by the horizontal replication protocol, we can stop the JOnAS instance that does not keep the database (Remember that we have been considering that the database is running in node 1): $ jonas stop -n node2 From that point on, every request is redirected to the node 1. We can observe that the state of the "Inner count" kept by the replicated stateful component remains consistent, counting the session requests to the inner component. 5) If we start again the node 2 and continue executing requests in the same session, every request is again redirected to any node and the state of the "Inner count" is still consistent and replicated in both nodes. 6) When we click on "release the session", the state of the "Inner count" is reset. If another session is started, the "Inner count" contains the value 1. 6.3.10 Details to access to the PoC instance you have implemented - 6.3.11 Package of the developed software DVD location: D8.1a-SoftwarePackages\Vertical Replication

6.4 Gray-Box Database Replication Architectural Pattern in WANs POC Name Gray-Box Database Replication Architectural Pattern in WANs What Owners Universidad Politécnica de Madrid (UPM) Description of High availability is a crucial requirement in current service oriented the PoC infrastructures. The services provided by the companies must be accessible despite node failures, disconnections from the Internet of full data centres or even catastrophic failures destroying a full data centre. Scalability is another important requirement to cope increasing loads due to an increase in the request volume. Another requirement for applications, typically web applications, with a combination of users from different and distant geographical areas is low latency. Centralized servers result in large latencies for distant clients. Edge computing allows diminishing the latency of the access to static contents, but access to dynamic contents is still centralized, with high latencies. An edge server basically is a server placed close to the clients of a particular region that holds a replica of the data used by the applications (e.g. an edge server can serve the client requests of a particular country). Data replication in Wide Area Networks (WANs) enables to provide low latency to both static and dynamic contents to all clients of NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 73 of 122

such services. This PoC aims at quantifying the improved latency that this pattern can obtained in comparison with current approaches to edge computing based on central servers for dynamic contents. ACPs This PoC applies the Gray-Box Database Replication pattern. involved Objective of The main objective of this PoC is to evaluate the application of the Gray-Box the PoC Database Replication pattern to edge computing to avoid a central sever for static and dynamic contents of applications. That is, storing static and dynamic contents of applications at edge servers and using the database replication pattern over a WAN to keep all edge servers up-to-date and consistent. The emphasis of this PoC is on evaluating an additional quality attribute of the Gray- Box Database Replication pattern: the latency experienced by the clients in a WAN. Functionalities The PoC focuses on the data replication functionality across WANs and its integration with a multi-tier system. Dependencies The solution described in this PoC is an instantiation of the Gray-Box Database Replication pattern in the context of WANs. The architectural pattern used in this PoC depends also on the writeset extraction interfaces described in the Writeset Extraction based on Extended DB Interfaces pattern. Moreover, for failover purposes, this pattern may use the Transparent Replication Proxy in order to provide replication transparency to the clients. Finally, in order to discover the different replicas the Multicast-Based Replica Discovery pattern is used.

Why Rationale The Gray-Box Database Replication pattern can be used to attain low latency for dynamic contents in edge computing. This PoC aims at quantifying the real latency that can be obtained by this pattern to determine its range of applicability. Architecture The main architectural components affected by this PoC are the database Component(s) component and its replication support. The pattern is instantiated in the context of affected edge computing within edge servers using a multi-tier service run-time (See Multi-Tier Transactional Service Runtime pattern), in which they used a WAN replicated database.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 74 of 122

Alternatives The other alternatives for offering replicas of the services in WANs consist of accessing a centralized database to access dynamic contents. This alternative has as shortcoming the high latency observed by clients in the accesses to dynamic contents. Relationship High availability and scalability are two key requirements of current SOI and with the addressed by NEXOF-RA. In some application scenarios clients are NEXOF-RA geographically distributed. In these scenarios latency becomes the main non- functional aspect The service run-time is typically architected in a multi-tier manner (See Multi-Tier Transactional Service Runtime pattern). This PoC applies the Gray-Box Database Replication pattern to address all these requirements with emphasis in minimizing the latency.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 75 of 122

How Scenarios for The scenario chosen for this PoC is and edge computing environment for an e- validation commerce application in which clients are naturally geographically distributed: an online bookstore. This scenario is similar to the one that is described in D10.1 (e- Commerce information sharing, S12). Suggested The online bookstore application is a web application based on a three-tier Architecture architecture that is deployed over a WAN. In this case, each node (replica) of the cluster includes a web server (acting as an application server) that contains the presentation and the business logic of the application and a database system containing the full data used by the application in order to provide high availability. A client node runs emulated clients that inject request in each location of the replicated infrastructure.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 76 of 122

Environment The validation is going to be performed using the industrial benchmark for web applications, TPC-W that provides an online bookstore application for selling books through the Internet. The particular choice of software components is the following: Tomcat web server/servlet container/application server. Contains the TPC-W application services. PostgreSQL database server. Contains the data of the TPC-W application. Middle-R replication middleware for replicating data across the WAN to provide low latency access to dynamic web contents. Ensemble group communication system in order to communicate the Middle-R replicas. The operating system is an Ubuntu Linux distribution with kernel 2.6.24. The instances of the middleware for replication + Postgres will run in Intel Xeon 1.8 GHz servers with 3.5 GB of RAM. The Tomcat instances and the emulated clients will run in an Intel Pentium Core Duo 2.8 GHz with 2 GB of RAM. The WAN is emulated by software by introducing a delay equivalent to one for the distance among nodes. Estimated 1-2 PMs. Main efforts: running the evaluation and assessing it, setup the cluster Effort and the software (install all server software, TPC-W application, configure it at all sites, infrastructure for running the experiments, scripting, etc.).

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 77 of 122

Methods The PoC compares the observed latency of edge computing approach based on WAN database replication consists in comparing the results obtained with existing architectural choices for edge computing, namely, a central database server for the dynamic contents.

Assessment The assessment criteria for this PoC are also partially based on the use of the criteria & utility trees of the ATAM methodology. Moreover, in this PoC, the business metrics & way requirements of the utility tree have been obtained from the online bookstore to document application provided by the TPC-W benchmark. So, an utility tree is generated for the quality attributes of the PoC and a benchmark is used to measure the most important features. The utility tree for the Gray-Box DB Replication pattern applied in WANs implemented in this PoC is depicted in the following picture:

In this PoC we mainly aim to quantify the latency in a WAN of the Gray DB Replication pattern. So, apart from ATAM, we will use an evaluation methodology based on the same standard benchmark (TCP-W) used in the Database Replication Architectural Patterns For Highly Available Stateful Services PoC . We will inject increasing loads to a system with a replicated database deployed in a WAN with different configurations for dynamic contents till reaching saturation. We will obtain the average latency perceived by clients when performing requests. The latency is indicative of the QoS perceived by the clients. So, the latency of the edge-based approach for the dynamic contents of applications will be compared to the latency obtained in infrastructure that have centralized those contents. Since the benchmark itself does not express the requirements of availability, applicability and maintainability, they have been evaluated with regard to the requirements of the architectural pattern. Availability is measured as the number of single points of failure of the solution. The applicability is measured as the number and strength of assumptions and finally, the maintainability is NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 78 of 122

measured as the number of components we require to modify and maintain. The generic quality attributes for the Gray-Box DB Replication pattern applied to WANs are the same as the ones described in the Gray-Box DB Replication pattern (See the document for the pattern). Further Information

6.4.1 Detailed description of the software artefacts 6.4.1.1 System requirements Linux (kernel > 2.6) Java Ensemble 1.42 6.4.1.2 Description of the involved tools/components and description of their integration Middle-r: Middleware system that is put between applications and database management systems and performs replication. PostgreSQL enhanced with binary writeset extraction/injection: Database Management System that provides the gray box approach to database replication. JDBC: Database access interface that provides interaction between applications and middle-r. TPC-W: Web e-commerce application used to benchmark the replication system. Used the implementation from U. Winsconsin. See http://www.ece.wisc.edu/~pharm/tpcw.shtml and http://www.tpc.org for further information. Apache Tomcat 5.5 Servlet/JSP Container: Used to deploy the e-commerce application. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. Ensemble: group communication system used by Middle-r. 6.4.2 How to install Middle-r: Untar and copy in the desired location. PostgreSQL: Untar and copy in the desired location. jdbc: Put the jar files in the common lib directory of tomcat to be accessible to the applications. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. tpcw: Install the compiled servers in tomcat. See http://tomcat.apache.org/tomcat-5.5-doc/index.html for further information. Apache Tomcat 5.5 Servlet/JSP Container: Copy and untar tomcat.tgz in the desired location. This file also contains jdbc and tpcw installed on tomcat.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 79 of 122

Ensemble: See http://dsl.cs.technion.ac.il/projects/Ensemble/ to install ensemble 1.42 6.4.3 How to use 1) COMPILING Before compiling middle-r, functions schema_create and schema_get_tableid in file schema.c should be implemented. Makefile is provided. Some environment variables should be defined in file config.h or the valued passed when compiling middle-r NUM_CLIENT_MNG: client manager pool size NUM_EDGES: number of cluster edges (1 if only one LAN is considered) MAX_REPLICAS: total number of nodes MAX_LOCAL_TXN: maximum number of local transactions that can be executed by each node DATABASENAME: name of the database in the DB backend 2) EXECUTING MIDDLE-R PRE: postgresql should be running and listening in port 6551 as described in http://www.postgresql.org/docs/7.2/static/index.html. Ensemble 1.42 should be installed on the machine as described in http://dsl.cs.technion.ac.il/projects/Ensemble To execute middle-r use the following command depending on the role of the middle-r instance $./middlersip-globalseg EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) $./middlersip-localseg EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) $./middlersip-simplerep EXPERIMENT_ID(long int) CONFIG_FILE_PATH(string) The config file should have the following format: my_eid=int my_gid=int num_db_connections=int num_threads=int mp_level=int global_seq_addr=string | local_seq_addr=string monitoring_time=int wan_latency=int

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 80 of 122

The meaning of each entry is the following: my_eid: the identifier of the edge cluster. It should be 0 if only one LAN is considered my_gid: the identifier of the data group inside the cluster. It should be 0 if only FULL REPLICATION is considered num_db_connections: number of db connections between middle-r and the db backend num_threads: number of threads serving db requests mp_level: number of concurrent threads allowed to execute in the db backend global_seq_addr: name of the global sequencer node global_seq_addr: name of the local sequencer node monitoring_time: statistics collection time period wan_latency: average latency between this node and the main cluster Environment variables that should be defined and available during middle-r execution DBUSER: database user used to connect to postgresql MIDDLEWARE_DIR: working dir of middle-r ENS_OUTBOARD_TYPE: ensemble 1.42 configuration parameter PARTITION_MATRIX_FILE: path to the file containing the initial replication schema use file FULL-matrix-file for FULL REPLICATION or put in the file one line r[eid][pid] per partition with identifier (type int) pid not replicated in edge eide (type int) and end the file with an 'e' in the last line. See examples in files *-matrix-file 3) EXECUTING THE TESTS Just follow the instructions on http://www.ece.wisc.edu/~pharm/tpcw.shtml to configure and run the TPC-W client (RBE) 6.4.4 Details to access to the PoC instance you have implemented - 6.4.5 Package of the developed software DVD location: D8.1a-SoftwarePackages\DB and WAN

6.5 Security PoC POC Name Security PoC What Owners Thales Description of The security PoC demonstrates the validity of promoted architectural choices

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 81 of 122

the PoC (WS-Security and WS-Policy) and architectural patterns: Non-repudiation architectural pattern Trusted Time stamping architectural pattern ACPs Architectural choices are used the following standard requirements of the involved web services (WS*): WS-Security (Web Services Security) is a communications protocol providing a means for applying security to Web services. WS-Policy is a specification that allows web services to use XML to advertise their policies (on security, Quality of Service, etc.) and for web service consumers to specify their policy requirements. Two architectural patterns involved in the security PoC are described hereafter: (these descriptions serve to understand the security application context) Non-repudiation is the concept of ensuring that a party in a dispute cannot repudiate, or refute the validity of a statement or contract. Although this concept can be applied to any transmission, including television and radio, by far the most common application is in the verification and trust of signatures. According to traditional legal practice, a signature on a paper contract or memorandum may always be repudiated by the signatory. Such repudiation may take one of two forms: The signatory may claim fraud or forgery, such as "I did not sign that." Alternately, he/she may accept the signature as authentic but dispute its validity due to coercion, as in the scenario of blackmail or confessions given under torture. The legal burden of proof differs depending upon the repudiation reason. In the former scenario the burden of proof typically rests on the party claiming validity, while in the latter it shifts to the signatory claiming lack thereof. Trusted timestamping is the process of securely keeping track of the creation and modification time of a document. Security here means that no one, not even the owner of the document, should be able to change it once it has been recorded provided that the timestamper's integrity is never compromised. By consequence, this pattern trusts the timestamp of a document. The administrative aspect involves setting up a publicly available, trusted timestamp management infrastructure to collect process and renew timestamps. Objective of Firstly, the objective of the PoC serves to demonstrate the results the PoC coming from WP4 (Non-Functional research package where Thales leads in security domain) based on work performed and achieved by WP4 in close cooperation with WP7. Secondly, Thales extracted two patterns from the set of security patterns in order to prove the feasibility of the research work package. This work is based on the solid business requirements defined by the WP10 (especially the D10.1). This PoC has come from with two patterns. These patterns have already contributed to the WP7 (Specification Reference Architecture). By this way, they aims to prove the following quality attributes: For Non-Repudiation Pattern: Integrity

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 82 of 122

Authenticity For the Trusted Timestamping Pattern: Integrity Accountability The implementation of these patterns will improve the: Integrity: the document is digitally signed. Only the owner can modify the document. Authenticity: the document is signed with a certificate. This certificate is based on the trusted third party. And the certificate contains the information concerning the owner. When a document is used with a certificate, we know who is the author of this document. Accountability: to make a track on a document. The trusted third party as TSA (Trusted Timestamping Authority) stamp a time on the document. This authority signs also the document + timestamp. The timestamp put in the document is a formal prove. This timestamp cannot be modified by others thanks to the signature. Functionalities The PoC focus on a business scenario which helps the citizens to declare their tax securely and on the corresponding choice of the patterns. These patterns provide the functionalities in order to fulfil the objective of the requirements of the scenario: Integrity/ Non-Repudiation/ Traceability. It means that we have some security requirements. How can use the security components to obtain these functionalities. By consequence, we define requirements from business process. Coming up with this work, the security requirements help to find the functionalities needed. These functionalities will be translated to the choice of the patterns. Dependencies Anticipated functional dependencies on architectural patterns related to (at least) : Public Key Infrastructure Secure IP Networking Services Composition Services Runtime The dependencies of Non-Repudiation pattern and Trusted Timestamping with other security patterns:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 83 of 122

isPartOf[Security Tool]

Enterprise SOA Security In ESOA

isPartOf[Trusted Timestamping] isPartOf[Non-Repudiation]

Trusted Timestamping Non-Repudiation

Figure 14: dependencies of Non-Repudiation and Trusted Timestamping with Security In ESOA pattern For more details about the relation [isPartOf], it is defined in the template pattern which is specified by WP7. Why Rationale To come up with trustworthy service composition and runtime platform. To first demonstrate the potential of security architectural patterns to cope with security requirements and second to pave the way towards effective usage of these security patterns in conjunction with other patterns from other areas or concerns to solve additional security needs. The essential rationale is to build the PoC in the way to help us to understand each block of the Reference Architecture Structure described in the DoW. And at the end, we tried to map our work to this RA structure. Architecture The components are affected by this PoC: Component(s) affected Timestamping Authority

Hash Digital Signature Timestamping

Key Management

Figure 15: components of Trusted Timestamping pattern

Digital Signature

Hash Certificate Store Key Management

Online Certificate Status Protocol Certificate Revocation List

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 84 of 122

Figure 16: components of Non-Repudiation pattern These components were described in the Trusted Timestamping and Non- Repudiation patterns which are part of Security In ESOA pattern.. They have already described and contributed in the ESOA pattern (Top-Level Pattern) specified by the WP7. Forecasting the next step, these components could also participate to the Internet of Services. Alternatives There are some alternatives to guarantee the integrity by using the Authorization Pattern. This pattern define the access control to the data. Only the authorized access can modify the data. We can also encrypt the data. Only the owner can decrypt the data and modify it. Concerning the authenticity, other manner to achieve it is to use the authentication. But the authentication is more difficult to achieve and is not practical to put in place in the context of Tax Declaration. And the Accountability can be achieved by logging all security information. But the traceability used by this scenario impose us to use only the Trusted Timestamping Pattern Relationship The two patterns extracted from the set of the security patterns defined on with the WP4 and specified in two documents for WP7 can be used as a service. It NEXOF-RA means that these patterns are compliance with SaaS6. Moreover, these patterns can be used in the IoS7. And the scenario used for the Tax Declaration described in the PoC is the use case on the Internet. Our work is driven in the direction prescribed by the Nexof-RA (the future of internet). How Scenarios for Firstly, one of the main scenarios (among the ones described in D10.1) we validation selected to validate those architectural choices and patterns is the e- government online fee visualization and payment service (S16) of D10.1 and more specifically in the context of this Security PoC, a fiscal portal where citizens declare their income tax. Through it, we demonstrate the validity of two architectural choices and two patterns w.r.t. to important requirements for Secured and trustworthy SOA environments which are Non-repudiation and Trusted Timestamping. These requirements are also stated in D10.1 (e.g. Non- repudiation is R39 (non-repudiability of data transfer) and the Trusted Timestamping is R33 (trust and confidence)). The choice of these patterns in the e-government context takes place in the real need of modernization of the interface between the citizen and the government by making it more efficient and cost-saving. These patterns permit not only to validate the reference architecture of Nexof but also to be useful for the million of citizens. To come up with trustworthy service composition and runtime platform, we‟d like first demonstrating the potential of security architectural patterns to cope with security requirements and second to pave the way towards effective usage of these security patterns in conjunction with other patterns from other areas or concerns to solve additional security needs (e.g. secure service composition

6 SaaS : Software as a Service 7 IoS : Internet of Service NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 85 of 122

and/or secure service discovery). We describe hereafter a functional scenario for validation. This scenario is the architecture of the Security PoC we set-up. This architecture choice was designed and shared to demonstrate and validate the two architectural patterns of the Security PoC (i.e. Trusted Timestamping and Non-Repudiation architectural patterns)

Figure 17: Functional architectural choice SBs = SignatureBroker service TTSs =Trusted Timestamping service TDs =Tax Declaration service 0. The user makes available user‟s tax declaration as a XML Form to the SBs. 1. The SBs requests the TTSs to provide a time-stamp. 2. The TTSs generates a trusted timestamp, signs and encrypts it and sends back to the SBs. 3. The SBs decrypts the message received from the TTSs, verifies the signature, concatenates the XML Form and the received time-stamp and finally signs and encrypts the resulting content and submits the message to the TDs. The TDs decrypts the message received from the SBs, verifies the signature and de-concatenates the XML Form and the time-stamp. Then, it verifies that the time-stamp is within the range accepted for a valid tax declaration. It creates a signed and encrypted response for the SBs. Suggested After achieving the security PoC, defining a scenario for the Tax Declaration, Architecture we firstly defined the phase of design pattern and secondly the implementation pattern. The following report contains these two phases: The design of the PoC combines two designs already quoted in two patterns. For this reason, the following abstract design patterns picture is a composition of “Trusted Timestaping” and “Non-Repudiation” patterns.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 86 of 122

Digital Consumer Document TS Server Signature

Timestamp CRL TS Hash Authority OCSP CRL or OSCP Server (Document + Timestamp) Certificate Encryption Signed with secrete key PKI Store

Abstract Design Patterns

Figure 18: Abstract design patterns of the PoC The abstract design patterns should help an architect to design a solution. This abstract design pattern is implementable. Because these patterns are distilled from the experiences of experts. They enable you to repeat a successful design done by someone else. By doing so you can stand on the shoulders of the experts and do not have to re-invent the wheel. However, since patterns enable many implementation variations you still have to keep the brain turned on. Finally, since patterns provide you with names for design building blocks they provide you with a vocabulary to describe and discuss a particular design. Description of each element Each element will be described in the D8.2a (Report on the proof of concept) and will be also depicted hereafter: The input is “document + hash”. This hashed document is timestamped by the TSA. The “hashed document + timestamp” is signed by TSA and then returned to the consumer. In this way, the original document if hashed obtains the same result with “document + hash”. As the hashed document is signed, it proves the signature. And the timestamp is signed; it proves the document is stamped with the indicated time. Only the TSA can encode the timestamp! Only the TSA has the secrete key. In this design pattern, the role played by the TSA is very important. The weakness could be TSA. If the key is stolen, the timestamp could be modified. The input is a “signed document”. This signed document is received by the consumer. He checks in the certificates list found in the Certificate Store. The certificate can be revoked by the CRL (Certificate Revocation List) or OCSP server (Online Certificate Status Protocol). He reads the document with the public key found in the certificate. One difference with respect to the previous session is that it is now possible to verify the signature of the (Document + Timestamp) thanks to “Certificate Store”. The following implementation is one of the possible solutions. The implementation needs the concrete components. Although these components are exposed by open source software. It is possible to use other concrete

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 87 of 122

components. In this case, another list of concrete components would be obtained. The unchanged thing remains the concept viewed in this PoC.

AXIS 2 XML PKI TS Server PKI SOAP Service Document CRL

OCSP RAMPART CRL or OSCP Hash Server TSA Service

Certificate PKI Store RAMPART (Document + Timestamp) Encryption Signed with secrete key

Implementation Design Patterns

Figure 19: Implementation design patterns of the PoC Environment The particular choice of components will be: Axis2 Web Services Engine Rampart (WS-Security and Ws-Policy) PKI (simulated in the context of this PoC phase1) Estimated 3 person-month (developing patterns, running the evaluation and assessing it, Effort setup the first draft of the demonstrator: install servers, install software, develop web services; configuration). Methods The two patterns described in the PoC provide the following quality attributes: integrity, authenticity, accountability. To guarantee the quality of the patterns is met. It should use a method to measure this quality. By measuring the quality attributes of an architecture, the ATAM8 is the adequate choice. In software engineering, ATAM is a risk-mitigation process used early in the software development life cycle. ATAM is most beneficial when done early in the software development life-cycle, when the cost of changing architectures is minimal. The ATAM process consists of gathering stakeholders together to analyze business drivers and from these drivers extract quality attributes that are used to create scenarios. These scenarios are then used in conjunction with architectural approaches and architectural decisions to create an analysis of trade-offs, sensitivity points, and risks (or non-risks). This analysis can be converted to risk themes and their impacts whereupon the process can be repeated. In this case, the quality attributes will be measured with the architectural choices. These measures will lighten if the identified quality attributes will be met with the technical solutions. Assessment To build a system or an architectural pattern, we need to define three fields: criteria & Non-Functional Requirements, Functional Requirements and the Constraints metrics & way (report to the Rationale section of template pattern specified by WP7). to document For the complete way to assess the PoC, the assessment will be done in these

8 ATAM : Architecture Trade-offs Analysis Method. ATAM was developed by the Software Engineering Institute at the Carnegie Mellon University. Its purpose is to help choose a suitable architecture for a software system by discovering trade-offs and sensitivity points. NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 88 of 122

three fields. Firstly, the functional requirements are to be reported with the business requirements of WP10 (especially the D10.1) Secondly, the Non-functional Requirements (quality attributes) will be measured with the ATAM method. Thirdly, the Rationale will be assessed with a technical evaluation criteria (these evaluation criteria will be reported in the annexe 3 of D8.2) Further After implementing these patterns, WP8 understand more the relationship with Information the Reference Architecture Structure described in the DoW. For this reason, the mapping to this structure can be done and schematised in these following pictures. Each element of the RA structure can be mapped with this PoC Concrete components: Rampart Abstract component: thanks to Abstract Design Pattern Abstract Design Pattern: see suggested architecture Implementation Design Pattern: see suggested architecture Reference model: reference to the WP4 Guidelines and principles: best practices of XML signature prescribed by W3C Standard catalogue: XML Signature The mapping can be used in the return of experiences. Of course, this mapping is still imperfect, but there are the feedbacks of the implementation of the PoC in order to go further in the building of the RA structure.

XML Signature XML Signature SOA for systems of systems Best Practices suggested by W3C

Standards Catalogue Top-Level Patterns Guidelines and Principles

Rampart Secure SOA

XML Signature Digital INon-Repudiation Signature Non Repudiation Keys Manager SOA

Query Contextual Identification of Delivery Select the Best Send Data Get Resource Data Server Data Security Policy Information Context Evidence Resource To Channel Description Binding Binding configuration Obtain Contextual Identification of User Manage Recommend a Interaction Knowledge Setup Monitoring Rules Property Parameters Persistence Resource Management Extractor PKI Security Implementation Workspace Describe a Publish a Form Obtain DCCI Tree Design Resource Resource Fulfilment presentation IService Security Abstract Design Patterns Perform Monitoring analysis IAuthentication Message Process Design Process Execution Monitoring PKI Evaluate Monitoring Transformation Results Process Transaction Data Mapping INon-Repudiation Orchestration

Process Test Perform Adaptation IMessage Security composition

Provides a service Provides a service return ranked results Organizes service Browse catalogue Manage Catalogue IPrivacy 1. Document is signed with Discovery UI Discovery Engine to consumers Descriptions content Federations Provides a service provides API interfaces for Manage Manage User Manage Service Discovery Engine Manages the creation service querying, storage Content replication schemas Subscriptions descriptions At Runtime Of search queries and retrieval between catalogues IEncryption Modify, delete, move, Manage Publication manage versions, AXIS 2 Search based on Provides searching retrieve, etc service events authoring Requirements Ranking and selection descriptions algorithms Manage Content Assists for the IStamping secrete key Search based on Access policies Specification of search Behavioral Constraints criteria Manage User Accounts Search based on Roles Groups select best candidates Structural Constraints 2. With the public key found in discovery ISignature IProcess Security

Service Invocation Manage Message Route Message Enhance Message Validate Message exchange Metadata Monitor Security Configure Service Transform Message Select Endpoint the certificate, the receiver read Mapping messaging Standard IDE functions Legacy wrapping Service interface Execute service Communication Service Testing Deploy/Undeploy (edit,compile) tools specification Component instance Support ISecurity Monitoring

Code analysis ( style, Legacy Migration Management and Manage computational QoS specification Service Packaging Publishing Metrics, performance) Tools Monitoring resources ISecurity Monitoring Specification to Management Stateful service Message pattern the document Policy specification Notification Code generation Information Support support

Code to specification Management Transactional Service policy generation specification support support Collect data Service versioning MDA tools support 3. He can verify the signature services

Provision Virtual Add resource to Suspend Resource Delete Resource Resource Set Reserve Monitor Pay per Use Capacity Resource set Set Set

Release reserved Remove resource Resume resource management Capacity resources security Concrete Component abstract Component From resource set Set Catalogue Catalogue Implementation Design Patterns Reference Model

Figure 20: Non-Repudiation Pattern mapped to RA of D7.4

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 89 of 122

SOA for systems of systems WS-Security RFC 3161

Standards Catalogue Top-Level Patterns Guidelines and Principles

Rampart Hash Secure SOA

XML Signature TSA IStamping Timestamp Trusted Timestaming XML Encryption Authority Service

Binding between Source Transform a Create Search a Data model Server Validation Render Workspace And Contextual framework Resource Channel Resource Management Manager Manage Security Render & Service Front Subscribe to Contextual Subscribe to Data Server Data Setup Mgmt. Rules List Resources Timestamp End Resource Contextual props Adaptation Channel Validation Manager Query Contextual Identification of Delivery Select the Best Send Data Get Resource Data Server Data Security Policy Keys Manager Information Context Evidence Resource To Channel Description Binding Binding configuration Obtain Contextual Identification of User Manage Recommend a Interaction Knowledge Setup Monitoring Rules Property Parameters Persistence Resource Management Extractor Security Implementation Workspace Describe a Publish a Form Obtain DCCI Tree Server Design Resource Resource Fulfilment presentation IService Security Abstract Design Patterns Perform Monitoring analysis IAuthentication Message Process Design Process Execution Monitoring Evaluate Monitoring Transformation WS-Security Results Process Transaction Data Mapping INon-Repudiation Orchestration Digital Process Test Perform Adaptation IMessage Security composition

Provides a service Provides a service return ranked results Organizes service Browse catalogue Manage Catalogue IPrivacy Discovery UI Discovery Engine to consumers Descriptions content Federations Provides a service provides API interfaces for Manage Manage User Manage Service Discovery Engine Manages the creation service querying, storage Content replication schemas Signature Subscriptions descriptions At Runtime Of search queries and retrieval between catalogues IEncryption Modify, delete, move, Manage Publication manage versions, PKI retrieve, etc service Search based on Provides searching events authoring Requirements Ranking and selection descriptions algorithms Manage Content Assists for the IStamping Search based on Access policies Specification of search Behavioral Constraints 1. Hash of document criteria Manage User Accounts Search based on Roles Groups select best candidates Structural Constraints SOA discovery ISignature 2. TSA added the Timestamp IProcess Security Service Invocation Manage Message Route Message Enhance Message Validate Message exchange Metadata Monitor Security Framework Configure Service Transform Message Select Endpoint Mapping messaging Standard IDE functions Legacy wrapping Service interface Execute service Communication Service Testing Deploy/Undeploy 3. TSA signed the document with (edit,compile) tools specification Component instance Support ISecurity Monitoring

Code analysis ( style, Legacy Migration Management and Manage computational AXIS 2 QoS specification Service Packaging Publishing Metrics, performance) Tools Monitoring resources ISecurity Monitoring Specification to Management Stateful service Message pattern Policy specification Notification the secrete key. Code generation Information Support support Code to specification Management Transactional Service policy PKI generation specification support support Collect data Service versioning MDA tools support services

Provision Virtual Add resource to Suspend Resource Delete Resource Resource Set Reserve Monitor Pay per Use Capacity Resource set Set Set

Figure 21: Trusted Timestamping Pattern mapped to RA of D7.4

6.5.1 Detailed description of the software artefacts 6.5.1.1 System requirements Operating System: Windows is the only OS supported. Memory/CPU: same as required for JDK 1.5/1.6 and Axis2 1.4 for Windows. Disk space: required for client and services install (ant, Axis2, TCPMon) : 63MB required for JDK : 270MB (additional space required only if JDK is not already installed on your machine) Network connection: no Internet connection required.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 90 of 122

6.5.1.2 Description of the involved tools/components and description of their integration

6.5.1.3 Client Side On the client side the SignatureBroker Web Service client (based on the Axis 2 [AXIS2] 1.4 client side runtime libraries) is used to invoke SignatureBroker Web Service functionalities. Two configurations are provided for this client using an ant [ANT] script. The first version sends a SOAP message to SignatureBroker Web Service that configures it to directly communicate through WS-Security [WS-Security] with Taxdeclaration and Timestamp Web Services running on port 8080 on Axis2. The second version configures SignatureBroker in order to send the WS-Security messages to port 8282 and 8383 where TCPMon [TCPMon] is running. TCPMon will catch, store and forward the messages to port 8080 where the actual Taxdeclaration and Timestamp Web Services are running.

6.5.1.4 Server Side On the server side the Axis2 1.4 Web Services Engine embeds the Rampart libraries and modules that implement the Web Services security standards (WS- Security and WS-Policy [WS-Policy]). Implementing the security algorithms requires some libraries updated also for the Java Virtual Machine (Policy.jar and Bouncecastle.jar [BOUNCYCASTLE]). Axis2 provides the Three Web Services SignatureBroker, Taxdeclaration and Timestamp.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 91 of 122

6.5.2 How to install In this section we describe the installation procedure. We will refer to the root folder of the packaged distribution of the NEXOF Security PoC as %NEXOF_RELEASE% and we will refer to the folder on your machine where you will install the software from the packaging as %NEXOFDIR%. If JDK 1.5 or 1.6 is already installed on your machine, please move to the next step. If it is not installed yet, install JDK 1.6 from %NEXOF_RELEASE%\runtime_environment\jdk\jdk-6u12-windows-i586-p.exe. You can install in the default folder C:\Program Files\Java\jdk1.6.0_12. We will refer to the installation folder of jdk as %JAVA_HOME%.

In %JAVA_HOME%\jre\lib\security, replace the files US_export_policy.jar and local_policy.jar with new files provided that implement an Unlimited Strength Java(TM) Cryptography Extension (JCE) Policy:

cd %JAVA_HOME%\jre\lib\security ren local_policy.jar local_policy.jar.backup ren US_export_policy.jar US_export_policy.jar.backup copy %NEXOF_RELEASE%\runtime_environment\jdk\jce\US_export_policy.jar . copy %NEXOF_RELEASE%\runtime_environment\jdk\jce\local_policy.jar . Then, copy the BouncyCastle library that provides the Cryptography algorithms: For jdk1.6: copy %NEXOF_RELEASE%\runtime_environment\jdk\bcprov-jdk16-141.jar %JAVA_HOME%\jre\lib\ext For jdk1.5: copy %NEXOF_RELEASE%\runtime_environment\jdk\bcprov-jdk15-141.jar %JAVA_HOME%\jre\lib\ext

Then edit the file %JAVA_HOME%\jre\lib\security\java.security: For jdk1.6, add the line security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider For jdk1.5, add the line security.provider.7=org.bouncycastle.jce.provider.BouncyCastleProvider Unzip %NEXOF_RELEASE%\runtime_environment\software\axis2-1.4.1-bin.zip to %NEXOFDIR%\axis2-1.4.1. Copy the content of %NEXOF_RELEASE%\runtime_environment\services to %NEXOFDIR%\ axis2-1.4.1. Unzip %NEXOF_RELEASE%\runtime_environment\software\apache-ant-1.7.1- bin.zip to %NEXOFDIR%\apache-ant-1.7.1. Unzip %NEXOF_RELEASE%\runtime_environment\software\tcpmon-1.0-bin.zip to %NEXOFDIR%\tcpmon-1.0-bin. Copy the content of %NEXOF_RELEASE%\runtime_environment\client to %NEXOFDIR%\client.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 92 of 122

Set environment variables for Java, Axis2, ant: set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_12 set ANT_HOME=%NEXOFDIR%\apache-ant-1.7.1 set PATH=%PATH%;%ANT_HOME%\bin set AXIS2_HOME=%NEXOFDIR%\axis2-1.4.1 6.5.3 How to use Start Axis2: cd %NEXOFDIR%\axis2-1.4.1 bin\axis2server.bat Run client cd %NEXOFDIR%\client ant -f nexof-build.xml client_run on the client screen you will see the following output:

client_run: [java] http://localhost:8080/axis2/services/signaturebroker http://localhost:8080/axis2/services/timestamp http://localhost:8080/axis2/services/taxdeclaration [java] log4j:WARN No appenders could be found for logger (org.apache.axis2.description.AxisService). [java] log4j:WARN Please initialize the log4j system properly. [java] [SignatureBrokerClient] Submitting Tax declaration ... [java] [SignatureBrokerClient] Tax declaration accepted On the axis2 server screen you will see the following output:

[SignatureBrokerService] Entering SignatureBrokerServiceImpl::controller user-2 A B 1 2 3 4 5

[INFO] Verification successful for URI "#Id-23447542" [INFO] Verification successful for URI "#Timestamp-27271771"

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 93 of 122

[TimeStampService] Entering TimeStampServiceImpl::getTimeStamp

[INFO] Verification successful for URI "#Id-29525730" [INFO] Verification successful for URI "#Timestamp-3325285" TS ret=1235028449533 user-2 A B 1 2 3 4 5 1235028449533

[INFO] Verification successful for URI "#Id-15462504" [INFO] Verification successful for URI "#Timestamp-24489446" [TaxDeclarationService] Entering TaxDeclarationServiceImpl::sendTaxForm [TaxDeclarationServiceImpl::sendTaxForm] Tax declaration submitted by: user-2 [TaxDeclarationServiceImpl::sendTaxForm] Tax declaration submitted with timest [TaxDeclarationServiceImpl::sendTaxForm] Tax declaration submission deadline:

[INFO] Verification successful for URI "#Id-4176892" [INFO] Verification successful for URI "#Timestamp-22552192" [SignatureBrokerServiceImpl::controller] Tax declaration accepted This execution of the [SignatureBrokerClient] will invoke the [SignatureBrokerService] with the content of the tax declation form stored in %NEXOFDIR%\axis2-1.4.1\axis2-1.4.1\conf\signaturebroker\TaxForm.xml that corresponds to the tax declaration of user-2:

user-2 A B 1 2

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 94 of 122

3 4 5 For a second execution of the system we will apply a few changes to obtain useful debugging and monitoring information on the security support during the execution of the web services. TCPMon will show the content of the WS-Security messages exchanges between web services:

cd %NEXOFDIR%\tcpmon-1.0-bin\build tcpmon.bat On the Admin tag, add a listener on port 8282 that forwards messages to localhost:8080 and click Add button:

Then, add a listener on port 8383 that forwards messages to localhost:8080 and click Add button:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 95 of 122

Stop the Axis2 server. In file %NEXOFDIR%\axis2-1.4.1\log4j.properties add the following line:

log4j.category.org.apache.rampart=DEBUG Then restart again the Axis2 server (see step 1). Modify the content of %NEXOFDIR%\axis2- 1.4.1\conf\signaturebroker\TaxForm.xml by replacing the value of user-2 with user-1:

user-1 A B 1 2 3 4 5 Then you can execute the client with the commands: cd %NEXOFDIR%\client ant -f nexof-build.xml client_run_with_tcpmon on the client screen you will see the following output:

client_run: NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 96 of 122

[java] http://localhost:8080/axis2/services/signaturebroker http://localhost:8282/axis2/services/timestamp http://localhost:8383/axis2/services/taxdeclaration [java] log4j:WARN No appenders could be found for logger (org.apache.axis2.description.AxisService). [java] log4j:WARN Please initialize the log4j system properly. [java] [SignatureBrokerClient] Submitting Tax declaration ... [java] [SignatureBrokerClient] Tax declaration accepted In this case, the client has been executed in order to send WS-Security messages to port 8282 for web service timestamp and to port 8383 for web service taxdeclaration instead of port 8080 on the Axis2 server. TCPMon that is listening on these two ports will display the WS-security messages exchanged between the web service servicebroker and timestamp and taxdeclaration services:

On the server side console, Rampart will provide all the details on WS-Security and WS-Policy execution: signature validation, encryption and decryption, and certificate validation. 6.5.4 Details to access to the PoC instance Not applicable since no remote access is required to install and get running this PoC 6.5.5 Packaging DVD location: D8.1a-SoftwarePackages\SECURITY POC The following image describes the structure of the software package provided. Further details are included in the following textual description.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 97 of 122

runtime_environment - Contains the software to be installed and the configuration files to setup the environment (both client and server sides) to execute the NEXOF Security PoC. Runtime_environment/jdk - Contains the installer of JDK1.6 and the libraries that implement the Unlimited Strength Java(TM) Cryptography Extension (JCE) required by the JDK for the execution of the web services. Runtime_environment/software - Contains the software to be installed to setup the environment: ant, Axis2, TCPMon. Runtime_environment/client - Contains the software to be installed to execute the client side of the NEXOF Security PoC. NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 98 of 122

Runtime_environment/services - Contains the web services (ServiceBroker, Timestamp and TaxDeclaration) packaged for the runtime environment (Axis2), the configuration files required for the execution of the web services and the Rampart libraries for the support of WS-Security and WS-Policy standards. runtime_environment/services/conf/signaturebroker Taxform.xml

user-2 A B 1 2 3 4 5 signaturebroker_service_users.jks. The signaturebroker_service Java KeyStore contains: certificate of the certification authority NEXOFCA certificate of taxdeclaration _service with public key of taxdeclaration _service certificate of timestamp _service with public key of timestamp _service certificate of each user with user public key private key of each user private key of signaturebroker _service certificate of signaturebroker _service with public key of signaturebroker _service policy_sig_enc_signaturebroker2taxdeclaration_client.xml - Defines the WS-Policy contract for secure communication (signature and encryption) based on WS-Security between SignatureBroker Web Service (client side) and TaxDeclaration Web Service (server side).

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 99 of 122

policy_sig_enc_signaturebroker2timestamp_client.xml - Defines the WS-Policy contract for secure communication (signature and encryption) based on WS-Security between SignatureBroker Web Service (client side) and TimeStamp Web Service (server side). Runtime_environment/services/conf/taxdeclaration taxdeclaration _service_users.jks. The taxdeclaration _service Java KeyStore contains: certificate of the certification authority NEXOFCA certificate of signaturebroker _service with public key of signaturebroker _service private key of taxdeclaration _service certificate of taxdeclaration _service with public key of taxdeclaration _service certificate of each user with user public key policy_sig_enc_signaturebroker2taxdeclaration_service.xml - Defines the WS-Policy contract for secure communication (signature and encryption) based on WS-Security between SignatureBroker Web Service (client side) and TaxDeclaration Web Service (server side). Runtime_environment/services/conf/timestamp timestamp_service.jks. The timestamp _service Java KeyStore contains : certificate of the certification authority NEXOFCA certificate of signaturebroker _service with public key of signaturebroker _service private key of timestamp _service certificate of timestamp _service with public key of timestamp _service policy_sig_enc_signaturebroker2timestamp_service.xml - Defines the WS-Policy contract for secure communication (signature and encryption) based on WS-Security between SignatureBroker Web Service (client side) and TimeStamp Web Service (server side). sources sources/conf - Contains the scripts to generate the public/private keys and the signed certificates for Web Services ServiceBroker, Timestamp and Taxdeclatation and for the users supported by the system.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 100 of 122

sources/src - Contains the java source code for the Web Services.

6.6 SCA Example Motion Tracker PoC Name SCA Example Motion Tracker What Owner Siemens (SIE) This PoC which has been selected and setup is based on a proposal coming from WP2 (Siemens) based on work performed and achieved by WP2 in close cooperation with WP7. Description of the PoC This example demonstrates three best practice architectural patterns: Separation of business logic from infrastructure logic: here, business logic can either be coded in declarative workflow languages (e.g. using BPEL) or in plain code (e.g. Java) without defining the communication and binding to the services used. The binding is defined separately or handled by the container. Automatic choice of communication and binding: it is possible to leave the binding open and the container will choose the most optimal one. Automatic choice among preselected services: instead of referencing a concrete service in a composition, a list of services can be provided and a suitable service (having the required interface, comm. protocol, QoS) will be selected by SCA Container at runtime and injected to the service consumer. The example uses an SCA runtime container that implements these patterns. Thus, this example is a feasibility study. ACPs involved The scope of this PoC is to assess by which extent interoperability and portability can be realized with specifications such as SCA and OSGi. The main architectural pattern validated in this PoC is Tuscany Interoperability Pattern. Objective of the PoC The main objective of this PoC is to evaluate existing interoperability standards, and existing standards and techniques that improve portability of individual components as well as the integration with existing (monolithic) legacy applications. In particular, this PoC addresses the following requirements as defined in deliverable D10.1: Interoperability and flexible communication standards (R8) Integration with legacy application (R14) Technical interoperability (R19) Orchestration(R32) Functionalities The PoC focuses on interoperability and portability. In particular, it demonstrates how to design of distributed environment that is easily and dynamically extensible for supporting new implementation types and communication protocols. This technique is discussed and presented in the pattern OSGi-based SCA-Container. Furthermore, the PoC demonstrates the feasibility of several integration scenarios (incorporating C++, C# and Java based components and communication standards such as WS-* or JMS) as discussed and presented in the Tuscany-Interoperability Pattern.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 101 of 122

Dependencies A subsequently planned PoC will aim at extending the capabilities of the SCA runtime. The dependencies to related patterns will be analysed when the first version of the Reference Architecture is finalized (D7.5.1)

Why Rationale SCA is an important state of the art technology and standard. Hence, its concept should be included as state of the art in the reference architecture and SCA can serve as a component for the implementation of a NEXOF RA compliant platform instance. The reasons for its importance are the above listed key concepts: separation of business logic from communication middleware and improvement of interoperability. Also the optimized and dynamic binding mechanisms are important concepts. The steps beyond state of the art are: the interoperability between applications that are based on different platforms the automatic run time service selection and the dynamic binding during runtime Architecture The finalized information has not yet been provided by WP7. Component(s) affected However, the prototype relates to the following parts of the conceptual architecture defined by WP7: “Service” (creation, deployment, execution): the example contains service creation from POJOs and a container that supports deployment and execution of services. “Message” (service invocation, mediation): the container handles service invocation but mediation is not an issue here. “Process” (programmatic service composition, BPEL-like-orchestration): the example uses BPEL and also dependency injection The example also relates to the interoperability defined by WP7, since SCA achieves: technical interoperability between platforms interoperability between applications running on the platform Notably, also legacy integration is supported. Alternatives There are no alternatives considered to the question by which extent interoperability and portability can be realized with specifications such as SCA and OSGi. Both are the evolving standard for ESoA. The PoC focuses on a freely available, open source implementation of the Service Component Architecture that provides a simple way to implement SOA solutions (see Apache Tuscany Incubator project http://tuscany.apache.org/home.html). The PoC assesses the expectations and promises of the combination of OSGi and SCA for interoperability and portability. In this technological context there is no alternative other than to assess the important architectural pattern, which is the Tuscany Interoperability Pattern. The PoC implements a feasibility prototype. Relationship with the Interoperability by means of flexible communication standards and portability by NEXOF-RA means of coherent and consistent component models are two desirable requirements of service-based systems. According architectural and technological solutions and concepts are crucial for NEXOF-RA in order to get widely-adapted by industry and academia.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 102 of 122

How Scenarios for The evaluation of interoperability and portability in service-based systems is validation going to be done by means of integrating a legacy online portal with existing applications related to e-commerce that implements the services required by an online bookstore. Suggested The following diagram depicts the architecture of the PoC “SCA Example Motion Architecture Tracker”, containing 3 legacy applications (denoted as rounded rectangles) 3 SCA services (denoted as nested rectangles) 4 different communications rsp. service invocations

Motion-Sensor Video-Monitoring ControllerComponent Component (Java Standalone App) (C++ Standalone App)

WS* 1 CamController CamController JMS Service Component Video- Monitoring Service 3 MotionReactor WS* CamController MotionReactor Component Native SCA Runtime / SCA Node Service Service (BPEL)

ZoneInfo WS* Service CamController Component (.Net / WCF)

Java SCA Runtime / SCA Node 2

Optimized Binding / Dynamic Wiring

ZoneInfo ZoneInfo Service Component

Java SCA Runtime / SCA Node The following diagram depicts the control flow between the above components in the PoC:

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 103 of 122

MotionSensor MotionReactor ZoneInfo CamController MotionReactor VideoMonitoring Controller Component Component Component WorkflowComponent Component Component 1 OnNewMotion 2 onMotionDetected(motionSensor) zone:=getZone(motionSensor)

3 moveCamera(zone)

ShowNewView

ShowNewView(Zone) 4

Environment JDK Apache Ant Apache ActiveMQ Apache Axis2/C Tuscany SCA Native Tuscany SDO for C++ WCF Libraries: Libxml2, Iconv, Zlib, Libxslt Estimated Effort The motion example was originally conceived by Siemens. There exists already an implementation, but it has not yet achieved its goals. This is partly due to lack of efforts and partly due to some pre-mature versions of the Tuscany SCA platform. Since the Tuscany SCA platform is constantly evolving, we are now confident, that the goals are now technically achievable.

Completion and documentation of the example will consume 1 person month. Efforts are completely on behalf of Siemens.

Methods There was no special method other than prototyping. Interoperability and portability was proofed by executing of several integration scenarios (incorporating C++, C# and Java based components and communication standards such as WS-* or JMS) as discussed and presented in the Tuscany- Interoperability Pattern.

In particular, the PoC demonstrates three best practice architectural patterns: Separation of business logic from infrastructure logic Automatic choice of communication and binding

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 104 of 122

Automatic choice among preselected services and legacy integration have been evaluated by implementing and functional testing. Functionality was tested by defining and executing unit tests (JUnit).

Assessment criteria & Since this is a feasibility study, a useful metric is feature completeness, metrics & way to i.e. which features really work in the TUSCANY SCA container. The document feature list is available at http://incubator.apache.org/tuscany/home.html. Performance could be interesting as well but we don‟t have a framework for this in the proof of concept work package yet. Some performance measurements have been done for the C++-Service. Further Information ---

6.6.1 Detailed description of the software artefacts Siemens provides the installable version of the PoC to the workpackage members. At the moment it is not yet available for download. The download location is under clarification. Nevertheless, the functionality can be presented any time by Siemens on a computer / laptop. The functionality and the possibility to demonstrate the prototype have been considered with higher priority compared to the installation procedure for external use of the prototype. A small setup function and a short, but complete description how to install is provided as part of the package. 6.6.1.1 System requirements Java SE Development Kit (http://java.sun.com/javase/downloads/index.jsp ) Apache Ant 1.7.0 (http://mirror.olnevhost.net/pub/apache/ant/binaries/apache-ant-1.7.0-bin.zip). Apache ActiveMQ 4.1.1 (http://activemq.apache.org) Apache Axis2/C 0.96 (http://ws.apache.org/axis2/c/download.cgi) Following libraries need to be on the PATH: Libxml2 v2.6.20 Iconv Zlib Libxslt v1.1.22.win32.zip Tuscany SCA Native (http://incubator.apache.org/tuscany/sca-native.html) Requirements: Tuscany SDO for C++ Apache Axis2/C Tuscany SDO (http://incubator.apache.org/tuscany/sdo-downloads.html) NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 105 of 122

Following libraries need to be on the PATH: Libxml2 v2.6.20 Iconv Zlib Libxslt v1.1.22.win32.zip Windows Communication Foundation (WCF) is part of the .Net framework (3.0 and 3.5) Other libraries Libxml2, a XML C parser (http://www.xmlsoft.org/) Iconv, a text encoding converter (http://www.gnu.org/software/libiconv/) Zlib, a library for (de-)compressing (http://www.zlib.net/) Libxslt, extends libxml2 by XSLT processing capabilities (http://www.xmlsoft.org/) 6.6.1.2 Description of the involved tools/components and description of their integration The PoC consists of the following components (see diagram above showing the architecture of the PoC “SCA Example Motion Tracker”): MotionSensorControllerComponent: A Java-based standalone application which manages a set of motion sensors and which notifies a client application about each detected motion. Interface: JMS-Queue “MotionEvents”: On every new motion which is detected in a zone (area, building) a JMS-Message is placed in this queue. The JMS-Message contains data of the motion sensor. JMS-Queue “MotionEventAck”: JMS-Messages in this queue indicate motion sensors whose alarm has been viewed and acknowledged by an admin. i.e. the message in the previous queue(MotionEvents) has been consumed. MotionReactorComponent: A Java-based SCA-Service which knows security- relevant areas and for those reasons monitors all motion-sensor activations. If motion in such an area is detected, the sensor location is translated to area coordinates by the ZoneInfoService of the ZoneInfoComponent and is forwarded to VideoMonitoring and Cam-Controller service. onMotionDetected(MotionSensor): implements the reaction to detected motions. acknowledgeMotionDetection(Zone): acknowledges any registered motions in an area. ZoneInfoComponent: An OSGi-based SCA-Service which knows the equipment of each zone e.g. which motion sensors are installed there etc..

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 106 of 122

getZone(MotionSensor): returns the building zone the given motion sensor is located in. CamControllerComponent: A .Net Service which controls all video-cams and areas which they have to monitor. moveCamera(Zone): Chooses the appropriate cam to monitor the given zone and makes it move as required. MotionReactorWorkflowComponent: A BPEL Service which orchestrates a workflow involving the Video Monitoring service. showNewView(Zone): A BPEL Workflow service which provides a valid zone information to call the videomonitoring service. VideoMonitoringComponent: A C++ Standalone application showing cam pictures to security staff. showNewView (Zone, Camera[]): Tells the application to display a new view of the given cams to the operator since some action was detected in that zone. These components are integrated via 4 different communications (based on JMS and WS*9 rsp. service invocations. 6.6.2 How to install Installing the prototype is a two step process. - Step 1: Double click on setup.exe to install the prototype If you do not have the JRE 1.6 running on your machine it will prompt you to install it. (JRE 1.6 can be downloaded from http://java.sun.com/javase/downloads/index.jsp) - Step 2 : Run "runPrototype.vbs" in the target folder to see the prototype running If the .vbs files do not run automatically when double-clicked then open them with "C:\WINDOWS\system32\wscript.exe" Alternatively you can run the prototype by running the "runjavascaservice.vbs", " runjavastandalone.vbs", "runaxis.vbs" scripts found in the target folder. This will open four consoles. Wait for a while to let the application start up. When two GUI windows pop-up then the application is ready to be used. 6.6.3 How to use Start with the GUI window which says "MotionSensor Management". In this window use the drop-down box to select a Motion Sensor and activate it. 1. When the Motion sensor is activated then it triggers a Motion Event in Building surveillance orchestration control. 2. Click on the button marked "Acquire Zoneinformation". This calls the OSGi service to get Zone info.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 107 of 122

3. Click on the same button now marked as "Move relevant cameras to determined zones". This calls the SCA native service (Camera Controller service) to execute the command. 4. Finally click on the same button now marked "Show camera clippings on monitors". This calls the standalone C++ service (Video Monitoring service) to execute the command. Each console will also display messages that they obtained. 6.6.4 Details to access to the PoC instance - 6.6.5 Packaging The PoC is provided as a package, which consists of one folder and four files: ReadMe.txt – this file contains the installation and user guide HIPrototype.msi – this file contains all necessary components. setup.exe – it executes the installation vcredist_x86 – this is a folder, which contains the file vcredist_x86.exe vcredist_x86.exe – this file is the C++ Runtime.

6.7 Front End in E-SOA POC Name Develop a next generation service front-end (SFE) application for Business systems What Owners TIE/TID This PoC has been selected and setup based on a proposal coming from WP1 (TID) and took over by TIE based on work performed and achieved by WP1 in close cooperation with WP7. Description of This PoC will be used to experiment with the main guiding principles and the PoC architectural concepts for user-service interaction, as proposed by NEXOF-RA. ACPs Essentially in order to fulfill declared principles this abstract pattern introduces the involved following components and relationships among them: SFER Authoring Tool SFE Mashup Platform SFER Access Platform ContextOfUse Manager On the communication level ezWeb abstract pattern makes use of several possible alternatives for enforcing dynamic communication between humans and services on the web: Generation of (X)HTML fragments that could be incorporated into a master page Generation of data that should be interpreted by client application (browser), e.g. JSON and YAML

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 108 of 122

Objective of Service Oriented Architecture (SOA) has attracted a great deal of interest during the PoC the last years. In fact SOA increase asset reuse, reduce integration expenses and improve businesses agility in responding to new demands. Nonetheless, until now, the mainstream development and research around SOA has been focused mainly on middleware and scalability, service engineering and automating service composition using Business Process Management (BPM) technologies. Little or no attention has been put on common/standardized service front-ends which are, in our vision, necessary to provide a complete SOA and services framework. As a consequence SOA remain on a technical layer hidden to the end-user. The evolution of web-based interfaces is a testimony of the progress achieved to improve service usability. However, existing, web-based service front-ends are far from completely meeting end-user expectations. Applications and information portals still are based on monolithic, inflexible, non-context-aware, and non- customizable. As a consequence end-users do not really benefit from the advantages promoted by service orientation in terms of modularity, flexibility and composition. In addition service front-ends are constructed in an ad-hoc manner and with the absence of formal engineering methods and tools that could accelerate the time to market. To resolve these shortcomings of current SOA approaches NEXOF-RA advocates a new generation Service Front layer that will allow flexible creation of applications by the end users themselves. The basic requirements that are addressed by the NEXOF-RA approach, and that will be put to test in this PoC, are: UI_ACC: How SOA-based systems can be accessed by users? UI_COMP: How users can compose their own, personalized interface? UI_COMP_DES: How users can design their own operating environments? UI_COMP_FIND: How users can find service front end resources? UI_COMP_CON: How users can connect service front end resources? Functionalities The PoC focus on the functionalities located at the “Presentation” key concern. The Front-End in E-SOA pattern is part of the Designer and Runtime Tools for E- SOA pattern. This pattern provides the architecture of the UI Runtime and the UI Desginer Tool. More specifically the UIRuntime has been refined into three main components: the SFER Access Platform, the SFE Mashup Platform and the Context of Use Manager. At the present level of abstraction the UI Designer Tool has only been refined into the SFE Authoring Tool. Dependencies The PoC is related to the following concepts in the Service Front-End (SFE) layer architecture:

Service Front-End Resources and Workspaces SFE Resources Catalogues Service-Front Resources integration with back-end services and systems End User empowerment The following diagram shows the relationship of the “Front-End in E-SOA” Pattern with other patterns.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 109 of 122

Dependencies with other ESOA patterns

SFER Access Platform SFE Mashup Platform

ContextOfUse Manager SFER Authoring Tool

Components of the SOA Front-End pattern and their dependencies

The Front-End in E-SOA pattern is part of the Designer and Runtime Tools for E- SOA pattern. This pattern provides the architecture of the UI Runtime and the UI Desginer Tool. More specifically the UIRuntime has been refined into three main components: the SFER Access Platform, the SFE Mashup Platform and the Context of Use Manager. At the present level of abstraction the UI Designer Tool has only been refined into the SFE Authoring Tool. An specific pattern will give more details about such component.

Why Rationale Proposed as a phase I PoC, it will focus on the main architectural components and prepare the way for more complex, joint PoCs and, where applicable, validation of specifications. It illustrates how different Service Front-end resources can be combined by the end users to address a particular problem and proves the benefits of this approach versus the traditional static applications. By doing so it also demonstrates the suitability of some of the main elements of the proposed architecture (workspaces, catalogues, loose integration between front-end and back-end resources based on web services and REST approaches etc.). Architecture The concept of Service Front End Resource implementing the user-service Component(s) interaction affected The concept of "Workspace Editing Tool" in which users edit their own workspace by composing and connecting different Service Front End NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 110 of 122

Resources The concept of Workspace Access Layer which it is the runtime support that allows users to access their previously composed workspaces The concept of Resource Catalogue and how users can upload new Service Front End Resources to their workspaces Alternatives The alternatives in this case are limited to machine specific APIs such as SOAP or RESTFul. Relationship Proposed abstract pattern relies on the following required functionalities from with the NEXOF-RA key concerns: messaging, security, virtualization and monitoring. NEXOF-RA How Scenarios for The PoC involves developing and deploying of several gadgets. Some of them are validation related to the existing services from real-world applications. Two of them taken from a TIE‟s pool of services. They are developed with .NET, they are a part of large scale industrial application of TIE. Another one is from an external party, namely Google Maps. They are exposed to ezWeb as gadgets and then an end user is able to create a mash-up or composition of these gadgets via GUI, saves his workspace with services and share new composite service with other users. Suggested The PoC will be based on the platform developed by the ezWebproject. This Architecture project has been the source of contributions for the service front-end layer in the NEXOF-RA architecture. It is provided as an open source software and already implements part of the target architecture.

E-SOA Front-End IP_UIRuntime

IR_Security SFER Access Platform IP_UIDesignerTool IP_SFER_AccessPlatform

+accessSFER() IP_Monitoring

IP_FrontEnd IP_Messaging IP_SFER_Management +accessSFER() +undeploySFER(sfer: SFE Resource) +accessSFEMashup() +startAgentForSFER(sfer: SFE Resource): Agent +createSFER() +stopAgentSFER(a: Agent) IR_Messaging IR_Notify +createSFEMashup() IR_Resource +deploySFER(sfer: SFE Resource) +deploySFER() +undeploySFER() ContextOfUse Manager +startAgentForSFER() +stopAgentSFER() +unpusblishSFEC() +publishSFEC() IP_SFE_ContextOfUse +sendMessage() +getContextOfUse() +getLoggedData() +subscribeEvent() IP_Monitoring +configureMonitoringPolicy() IP_Management +getLoggedData() IR_UIDesignerTool IR_Security +subscribeEvent(et: EventType) IR_Resource +configureMonitoringPolicy() +isAuthorized() +assignCR()

SFE Mashup Platform IP_Messaging IP_UIDesignerTool +sendMessage(a: UI Agent, m: Message) IR_FrontEnd

+sendMessage() +notifyEvent() +isAuthorized() +assignCR() IR_Security IP_SFEC_Publication +isAuthorized() +publishSFEC() +unpublishSFEC()

IR_UIRuntime

IR_Messaging IP_SFE_MashupPlatform IP_SFER_AuthoringTool +sendMessage(a: Agent, m: Message) +createSFEMashup(): SFE Mashup IR_Notify SFER Authoring Tool +accessSFEMashup(sfem: SFE Mashup) +createSFER(): SFE Resource +createWorkspace(): SFE Workspace +notifyEvent(e: Event) +selectWorkspace(sfew: SFE Workspace) +composeSFERs() +wireSFERs()

An architecture of front-end for SOA pattern As part of this specific scenario used to validate the concepts, the following service front-end resources have to be developed SFER 1 List of existing partners. A secured component that shows the list of existing partners for user SFER 2 Partner data. A secured component that shows detailed information of NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 111 of 122

a partner SFER 3 Map. A generic SFER map that shows a location on a map “ala Google Maps” These SFER resources will be published by means of the ezWeb catalogue and they will be used to build new composite resources through the workspace and wiring functionalities provided by the ezWeb platform. Environment Please, follow the installation instructions specific for the software listed below. EzWeb platform [http://demo.ezweb.morfeo-project.org/] OS: Windows Apache 2.2 [apache_2.2.11-win32-x86-no_ssl.msi] PostgreSQL 8.3 [postgresql-8.3.1-1.zip] Python 2.5 [python-2.5.4.msi] Django 1.0 [Django-1.0.2-final.tar.gz] libxml2dom-0.4.7 [libxml2dom-0.4.7.tar.gz] libxml2-python-2.7.3 [libxml2-python-2.7.3.win32-py2.5.exe] mod_python-3.3.1 [mod_python-3.3.1.win32-py2.5-Apache2.2.exe] PIL-1.1.6 [PIL-1.1.6.win32-py2.5.exe] psycopg2-2.0.6 [psycopg2-2.0.6.win32-py2.5-pg8.2.4-release.exe] PyXML-0.8.4 [PyXML-0.8.4.win32-py2.5.exe] Google maps [http://maps.google.com] TIE authentication service [proprietary implementation in .Net] Estimated Identified tasks: Effort Installation of ezWeb (0,25 m/m) Development of example services implementations (0,25 m/m) services taken from TIE's pool of services only web front ends have to be developed) Development of gadget integration based on provided templates (~0,5 m/m) Total estimated completion time is ~ 1 m/m

Methods The method used to validate architectural choices was prototyping with parallel expert estimations of the given statements.

More specifically methods for usability, availability and inerrability are elaborated separately in the following section.

Assessment To validate the stated a pattern qualities (non-functional properties) the following criteria, assessment criteria and metrics should be used. metrics, and a There are a number of usability evaluation methods (UEMs) to assess and improve way to usability of systems, which defines assessment criteria and metrics for them. It is document still an ongoing discussion in academic circles concerning the comparison and effectiveness of these methods. Since usability study is out of the scope of NEXOF-RA so just several informal interview were conducted in order to evaluate how a produced prototype meets listed user requirements and address architectural needs for SOA presentation concern.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 112 of 122

For availability assessment criterion a metric formulates as a ratio of the expected value of the uptime of a system to the aggregate of the expected values of up and down time.

Another dimension of availability for front-end systems is the possibility to access them by challenged people, people with limited connectivity or from old software/hardware systems. This can be evaluated against specific metrics for each case, e.g.

Is it enough contrast? (type I) Is font big enough? (type I) Does browser support JavaScript for running client side logic? (type II) Type I questions should be also classified as a sort of usability properties. As such they should be developed and investigated further with the methods listed above. In general, those questions will be answered using prototyping and user studies.

Type II falls into a category of an expert-based assessments. In other words, experienced software architect, designer, developer or groups of those creates a list of possible options and then gives answers on them based on a provided architecture. Further A demo shows applicability of architectural and design principals proposed by WP1 Information on a base of previously isolated services (web applications).

6.7.1 Detailed description of the software artefacts 6.7.1.1 System requirements The preferred browser would be FireFox The Flash plug-in (http://get.adobe.com/flashplayer/) is needed From server side, the system requirements derive from EzWeb constraints 6.7.1.2 Description of the involved tools/components and description of their integration - 6.7.2 How to install Please, follow the instructions for installing ezWeb first http://forge.morfeo- project.org/wiki/index.php/Guides_and_Manuals?lng=en Then unzip the file with gadgets provided by TIE into /media/stuff/gadgets directory. Run your web server and access an appropriate URL that leads you to your ezWeb installation. 6.7.3 How to use 1. Access to the EzWeb installation devoted to the PoC. In case of proof of concept developed by TIE, the address is the follow http://87.213.46.7:8080. After loading you should be presented with an empty workspace.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 113 of 122

2. To access the catalogue of available widgets that wraps up different services and web applications, click on the first icon on the left of the top toolbar.

3. To add a new component to the catalog type the following URL in the template URL field: http://87.213.46.7:8080/ezweb/gadgets/pocPartnerList.xml

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 114 of 122

After adding it a new icon should be shown in the catalog working area

4. The new component that represents TIE authentication service will appear in the workspace

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 115 of 122

5. Please use the following user name (appadmin) in order to get an access to the underlying service

After you successfully logged in you will be presented with the similar screen

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 116 of 122

6. To add new templates please feed more links to the “template URL” field http://87.213.46.7:8080/ezweb/gadgets/pocPartnerDetail.xml and http://87.213.46.7:8080/ezweb/gadgets/pocGeolocator.xml

7. After that, e.g. you would be able to see “Partner detail gadget” and “Geolocator”

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 117 of 122

8. Now you can search for example for detailed information about company partners. E.g., click “Advanced Search/Simple Search”, then” Search by Slot” and fill in „address‟ in field and click “search” button.

9. Now the screen should have 3 different isolated gadgets. Clicking at any of them does not cause any effect on the other gadgets.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 118 of 122

10. In order to compose several gadgets in a certain workflow we need to wire them. By clicking on the wiring option (plug icon) the wiring edition screen appears.

Create a new channel clicking on the Icon allows to connect an event into a slot.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 119 of 122

Select event partner id and slot with the same name. This will stablish a connection between them so the event in the first gadget will send its information to the slot in the second.

Repeat the procedure with a second channel and the address.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 120 of 122

11. Now the components are wired together providing enhanced functionality. Gadgets collaborate between them. Selecting a partner show his details in the details gadget. Selecting an address in the partner details gadget will detail the location in the geolocator.

12. After publishing a created workspace (application) it becomes available as a connected set of service (service composition) for the end user.

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 121 of 122

After that step you can save a workspace if you want to access it lately or share with other persons. 6.7.4 Details to access to the PoC instance To access the NEXOF-RA proof of concept developed by TIE based on EzWeb platform please follow this link http://87.213.46.7:8080 6.7.5 Packaging DVD location: D8.1a-SoftwarePackages\NEXT GENERATION SERVICE FRONT-ENDS FOR SOA-BASED BUSINESS APPLICATIONS

NEXOF-RA • FP7-216446 • D8.1.b • Version 1.1, dated 30/11/2009 • Page 122 of 122