Session B3 Web 2.0, Cloud and Telco Scalable Orchestration of Telco/IT Mashups Massimo Maresca Computer Platform Research Center (CIPI) [email_address]
Architecture of the execution platform
1 Introduction (1/3)
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 call, etc.
Availability of tools for the rapid development of convergent Composite Services (a.k.a. Mashups) that combine different resources such as Google Mashup Editor, Yahoo Pipes!, IBM QuedWiki, etc.
1 Introduction (2/3)
A model for Event Driven Mashup creation and execution
Service Components (SCs):
wrap external resources
are activated through “Mashup Action” invocations
fire “Mashup Events” at the occurrence of “External Events”
1 Introduction (3/3)
Mashup classification based on the execution platform location
The analysis is about Server Side Mashup Execution Platforms Server side Client side SC1 SC2 SCN Browser (User) SC1 SC2 SCN Browser (User) Mashup Engine (Server) Request Results
2 Platform Requirements (1/2)
1. Automatic load adaptation , to ensure that the platforms is able to complete the execution of the Service Mashups started and automatically transforms a load growth into a latency increase.
2. Automatic Scalability , to support the simultaneous execution of a very large numbers of Mashup instances on variable size hardware systems.
3. Fault Tolerance , to guarantee the levels of reliability and availability typical of the Telecoms Operators (99.9999%).
4. Low latency , to effectively support the execution of long sequences short lived Telco services.
2 Platform Requirements (2/2)
5. Fast Deployment , to allow the Mashup creator to easily and quickly deploy his Mashups.
6. Authentication, Authorization and Accounting , to support the seamless integration of the Mashup with the AAA modules already existing in the owner’s platform environment.
7. 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 Design Solutions (1/5)
Orchestration vs Choreography
Orchestration: a central component called Orchestrator manages Mashup execution (i.e., all the events pass through it)
Choreography: Mashup execution is performed in a distributed way, no central component is needed.
We choose the Orchestration approach because it assures more control on what happens within the platform at execution time
3 Design Solutions (2/5)
B. Asynchronous use of Web Services
The proposed solution decouples the Web Service invocation from the actual service logic.
3 Design Solutions (3/5)
C. Ad-hoc Orchestration technology
Previous performance tests proved that the widely used BPEL (Business Process Execution Language) standard doesn’t assure low latency and high throughput
We implemented a lightweight Orchestrator for the execution of Event Driven Mashups
3 Design Solutions (4/5)
D. Sessionless Orchestration
Each Mashup execution activation is called “Session”
Orchestrator systems like BPEL 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
3 Design Solutions (5/5)
E. Parallel Orchestration
Many Orchestrators run on different nodes to increase performances
A Load Balancer is needed to dispatch incoming Mashup execution requests
The Sessionless feature is useful to easly support Sessions’ migration among Orchestrators
4 Architecture of the execution platform(1/2)
Run time 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
4 Architecture of the execution platform(2/2)
5 Discussion Platform Requirements vs Design Solutions Management AAA Fast Deployment Low Latency Fault Tolerance Scalability Automatic load adaptation E D C B A
6 Performance Evaluation (1/2)
Thread Pool Tuning
We focused our attention on two different Thread Pool types, namely
ThreadPoolExecutor (bounded Thread Pool)
CachedThreadPool (unbounded Thread Pool)
The test setup is depicted in this figure
6 Performance Evaluation (2/2)
Config_3: ThreadPoolExecutor bounded to the maximum size of experiment 2
120 4160 Config_3 120 3657 Config_2 150 4790 Config_1 Total Elapsed Time (sec) Throughput (events/sec)
We defined a list of requirements for the execution of Event Driven Mashups and list of Design Solutions
in particular, SessionLess Orchestration results to be the most interesting proposed solution
We designed and implemented a Mashup Execution platform based on the proposed solutions
We performed some performance tests for the tuning of the platform. We identified how the Thread Pool size can be selected for throughput and latency optimization.