An Execution Platform for Event Driven Mashups Massimo Maresca Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) [email_address]
Overview of the Platform
The Service Execution Platform
1. Introduction (1/4)
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)
1. Introduction (2/4)
Service Taxonomy and Mashup Patterns: the “Monitor Resource + Notification” pattern
Notification of interesting events Mashup
1. Introduction (3/4)
Service Taxonomy and Mashup Patterns: the “Monitor Resource + Processing + Notification” pattern
Time or Location or Presence dependent Notification Mashup
Non repudiation Mashup
1. Introduction (4/4)
Service Taxonomy and Mashup Patterns: traditional Data Mashup and “something” + Map Mashup
Traffic on Map
Wheather on Map
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”)
Server side Client side SC1 SC2 SCN User Node (Browser) SC1 SC2 SCN Browser (User) Mashup Engine (Server) Request Results
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.
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”
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).
3. The Service Execution Platform (1/7)
Interaction with external world
Orchestrator: it executes the Mashup logic
Service Proxies: they wrap external resources
3. The Service Execution Platform (2/7)
IT public Services Telco Services IT private Services notifyEvent/ invokeAction Interface External Resource Interface (REST, SOAP, SDK, …)
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
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).
3. The Service Execution Platform (5/7)
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)
3. The Service Execution Platform (6/7)
The Scalability mechanism in action
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
4. Performance Tests (1/2)
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
4. Performance Tests (2/2)
Config_1 (Zero Load Config.)
SOAP_UI: 1 req/sec
SOAP_UI: 2600 req/sec
SOAP_UI: 2600 req/sec
SOAP_UI: 2600 req/sec
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
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:
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.