The document discusses the design of a scalable platform for orchestrating telco/IT mashups. It proposes using a sessionless, asynchronous, parallel orchestration approach with lightweight orchestrators to achieve low latency and high throughput. The architecture includes service components that wrap external resources and an orchestrator that manages mashup execution through asynchronous invocations. Performance tests showed that an unbounded thread pool outperformed a bounded pool in throughput.

1. Session B3 Web 2.0, Cloud and Telco Scalable Orchestration of Telco/IT Mashups Massimo Maresca Computer Platform Research Center (CIPI) [email_address]

2. Agenda Introduction Platform Requirements Design Solutions Architecture of the execution platform Discussion Performance Evaluation Conclusion

3. 1 Introduction (1/3) 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 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.

4. 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”

5. 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

6. 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.

7. 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 ).

8. 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

9. 3 Design Solutions (2/5) B. Asynchronous use of Web Services The proposed solution decouples the Web Service invocation from the actual service logic.

10. 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

11. 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

12. 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

13. 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

14. 4 Architecture of the execution platform(2/2) The Architecture

15. 5 Discussion Platform Requirements vs Design Solutions  Management  AAA  Fast Deployment    Low Latency   Fault Tolerance    Scalability   Automatic load adaptation E D C B A

16. 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 SCs platform

17. 6 Performance Evaluation (2/2) Test results Config_1: ThreadPoolExecutor Config_2: CachedThreadPool 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)

18. 7 Conclusions Conclusions 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.

19. Thank you for your attention