The document proposes an execution platform for event-driven mashups that: 1) Allows for the creation and deployment of event-driven mashups that combine various web services and resources. 2) Uses a sessionless orchestration model and asynchronous web service calls to provide automatic scalability and fault tolerance. 3) Was tested and shown to reduce latency when replicated across multiple nodes, demonstrating its ability to horizontally scale under load.

1. An Execution Platform for Event Driven Mashups Massimo Maresca Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) [email_address]

2. Agenda Introduction Overview of the Platform The Service Execution Platform Performance Test Conclusions

3. 1. Introduction (1/4) Scenario Availability of contents and services through technologies typical of the Web 2.0 philosophy such as RSS Feed, Atom, REST-WS, SOAP-WS, etc. Availability of Telco services such as phone calls, SMS messages, conference calls, etc. Availability of tools for the rapid development of convergent Composite Services (a.k.a. Mashups) that combine different resources such as Yahoo Pipes!, JackBe Presto, etc. Such tools mainly support Data Mashups (i.e., those Mashups that combine data extracted by different sources), while they do not support Event Driven Mashups (i.e., those Mashups in which the basic components interact through events)

4. 1. Introduction (2/4) Service Taxonomy and Mashup Patterns: the “Monitor Resource + Notification” pattern Examples: Reminder Mashup Alert Mashup Notification of interesting events Mashup

5. 1. Introduction (3/4) Service Taxonomy and Mashup Patterns: the “Monitor Resource + Processing + Notification” pattern Examples: Time or Location or Presence dependent Notification Mashup Non repudiation Mashup

6. 1. Introduction (4/4) Service Taxonomy and Mashup Patterns: traditional Data Mashup and “something” + Map Mashup Examples: Data Fusion Data Migration … Examples: Traffic on Map Wheather on Map …

7. 2. Platform overview (1/4) Mashup classification based on execution platform location The analysis is about Server Side Mashup Execution Platforms Long Running Executions (i.e. user can be also “offline”) Security (e.g. private data, malicious components, etc.) Server side Client side SC1 SC2 SCN User Node (Browser) SC1 SC2 SCN Browser (User) Mashup Engine (Server) Request Results

8. 2. Platform overview (2/4) Server-Side Mashup Lifecycle A Mashup is created by means of a Service Creation Environment (e.g., see next slide) and stored as a XML file in a repository. The new Mashup is deployed into the Service Execution Platform – SEP (i.e., the XML representation is translated into a set of data structures that are loaded in the execution system). The Mashup is now ready to be used by final users. There are two phases to take into account: Activation: the SEP is configured by the user (i.e., he sets the input properties of the service) to be ready to execute the Mashup when a new initial event occurs. Execution: when a Mashup previously activated by the user receives a new initial event, the actual execution of the service logic takes place.

9. 2. Platform overview (3/4) The Service Creation Environment Service Proxies (SPs): wrap only one internal/external resource can fire more than one “Mashup Event”

10. 2. Platform overview (4/4) Requirements for the Service Execution Platform Automatic Scalability, to support the simultaneous execution of a very large numbers of Mashup instances on variable size hardware systems. Fault Tolerance, to guarantee the levels of reliability and availability typical of the Telecoms Operators (99.99999%). Low latency, to effectively support the execution of long sequences short lived Telco services. Authentication, Authorization and Accounting, to support the seamless integration of the Mashup with the AAA modules already existing in the owner’s platform environment. Management, to have the complete control of the platform resources, to control Mashup activation/execution as well as to allow the platform administrator to perform the appropriate management actions (e.g., enforcing SLA rules).

11. 3. The Service Execution Platform (1/7) Interaction with external world Main components: Orchestrator: it executes the Mashup logic Service Proxies: they wrap external resources

12. 3. The Service Execution Platform (2/7) The Architecture IT public Services Telco Services IT private Services notifyEvent/ invokeAction Interface External Resource Interface (REST, SOAP, SDK, …)

13. 3. The Service Execution Platform (3/7) The runtime model Each edge that links two basic blocks in the graphical service description is implemented as a pair of Web Service invocations: a notifyEvent call from the Service Component to the Orchestrator; an invokeAction call from the Orchestrator to the next Service Component

14. 3. The Service Execution Platform (4/7) Asynchronous use of Web Services The proposed solution decouples the Web Service invocation from the actual service logic by means of a Thread Pool structure. For each request a new orchestration task is created and submitted to the Thread Pool (no Thread creation is required at run time).

15. 3. The Service Execution Platform (5/7) Sessionless Orchestration Each Mashup execution is called “Session”. Orchestrator systems like BPEL (Business Process Logic Execution) usually allocate resources to Session State storage. In proposed solution, the Session State travels along with the Events instead of being stored within the Orchestrator. The Sessionless feature + Orchestrator node replication allows to perform an automatic scalability mechanism (see example in next slide)

16. 3. The Service Execution Platform (6/7) The Scalability mechanism in action

17. 3. The Service Execution Platform (7/7) Platform Requirements vs Design Solutions A. Node replication B. Sessionless Orchestration C. Asynchronous use of Web Services D. Centralized Orchestration Where:  Management  AAA    Low Latency    Fault Tolerance    Scalability D C B A

18. 4. Performance Tests (1/2) Test Setup SOAP-UI as Web Service traffic generator Round robin algorithm for the Load Balancer Svc_A is a fake Service (We did so in order to minimize the noise) We measured the latency (i.e. the time needed by the orchestrator(s) to manage one event) Latency = T CPU + T NET

19. 4. Performance Tests (2/2) Test configurations Config_1 (Zero Load Config.) SOAP_UI: 1 req/sec #ONs: 1 Config_2 SOAP_UI: 2600 req/sec #ONs: 1 Config_3 SOAP_UI: 2600 req/sec #ONs: 2 Config_4 SOAP_UI: 2600 req/sec #ONs: 3 Test Results Config_1 (L = 600 µs) T CPU = 100 µs T NET = 500 µs Config_2 (L = 1500 µs) T CPU = 300 µs T NET = 1200 µs Config_3 (L = 690 µs) T CPU = 130 µs T NET = 560 µs Config_4 (L = 610 µs) T CPU = 100 µs T NET = 510 µs BEST CASE

20. 5. Conclusions We defined a model for Event Driven Mashups. a list of requirements for Event Driven Mashup execution. We developed a Server Side - Service Execution Platform that fulfills the requirements. Platform Distinctive Features: Sessionless Orchestration Asynhcronous Use of Web Services We have run performance tests on the platform. The main lesson learned is that “horizontal scalability” is suitable to fulfill the requirements of this kind of platforms.

21. Thank you for your attention