Icin 2009

475 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Icin 2009

  1. 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. 2. Agenda <ul><li>Introduction </li></ul><ul><li>Platform Requirements </li></ul><ul><li>Design Solutions </li></ul><ul><li>Architecture of the execution platform </li></ul><ul><li>Discussion </li></ul><ul><li>Performance Evaluation </li></ul><ul><li>Conclusion </li></ul>
  3. 3. 1 Introduction (1/3) <ul><li>Scenario </li></ul><ul><li>Availability of contents and services through technologies typical of the Web 2.0 philosophy such as RSS Feed, Atom, REST-WS, SOAP-WS, etc. </li></ul><ul><li>Availability of Telco services such as phone calls, SMS messages, conference call, etc. </li></ul><ul><li>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. </li></ul>
  4. 4. 1 Introduction (2/3) <ul><li>A model for Event Driven Mashup creation and execution </li></ul><ul><li>Service Components (SCs): </li></ul><ul><ul><li>wrap external resources </li></ul></ul><ul><ul><li>are activated through “Mashup Action” invocations </li></ul></ul><ul><ul><li>fire “Mashup Events” at the occurrence of “External Events” </li></ul></ul>
  5. 5. 1 Introduction (3/3) <ul><li>Mashup classification based on the execution platform location </li></ul>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. 6. 2 Platform Requirements (1/2) <ul><li>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. </li></ul><ul><li>2. Automatic Scalability , to support the simultaneous execution of a very large numbers of Mashup instances on variable size hardware systems. </li></ul><ul><li>3. Fault Tolerance , to guarantee the levels of reliability and availability typical of the Telecoms Operators (99.9999%). </li></ul><ul><li>4. Low latency , to effectively support the execution of long sequences short lived Telco services. </li></ul>
  7. 7. 2 Platform Requirements (2/2) <ul><li>5. Fast Deployment , to allow the Mashup creator to easily and quickly deploy his Mashups. </li></ul><ul><li>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. </li></ul><ul><li>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 ). </li></ul>
  8. 8. 3 Design Solutions (1/5) <ul><li>Orchestration vs Choreography </li></ul><ul><li>Orchestration: a central component called Orchestrator manages Mashup execution (i.e., all the events pass through it) </li></ul><ul><li>Choreography: Mashup execution is performed in a distributed way, no central component is needed. </li></ul><ul><li> We choose the Orchestration approach because it assures more control on what happens within the platform at execution time </li></ul>
  9. 9. 3 Design Solutions (2/5) <ul><li>B. Asynchronous use of Web Services </li></ul><ul><li>The proposed solution decouples the Web Service invocation from the actual service logic. </li></ul>
  10. 10. 3 Design Solutions (3/5) <ul><li>C. Ad-hoc Orchestration technology </li></ul><ul><li>Previous performance tests proved that the widely used BPEL (Business Process Execution Language) standard doesn’t assure low latency and high throughput </li></ul><ul><li>We implemented a lightweight Orchestrator for the execution of Event Driven Mashups </li></ul>
  11. 11. 3 Design Solutions (4/5) <ul><li>D. Sessionless Orchestration </li></ul><ul><li>Each Mashup execution activation is called “Session” </li></ul><ul><li>Orchestrator systems like BPEL usually allocate resources to Session State storage </li></ul><ul><li>In proposed solution, the Session State travels along with the Events instead of being stored within the Orchestrator </li></ul>
  12. 12. 3 Design Solutions (5/5) <ul><li>E. Parallel Orchestration </li></ul><ul><li>Many Orchestrators run on different nodes to increase performances </li></ul><ul><li>A Load Balancer is needed to dispatch incoming Mashup execution requests </li></ul><ul><li>The Sessionless feature is useful to easly support Sessions’ migration among Orchestrators </li></ul>
  13. 13. 4 Architecture of the execution platform(1/2) <ul><li>Run time model </li></ul><ul><li>Each edge that links two basic blocks in the graphical service description is implemented as a pair of Web Service invocations: </li></ul><ul><ul><li>a notifyEvent call from the Service Component to the Orchestrator; </li></ul></ul><ul><ul><li>an invokeAction call from the Orchestrator to the next Service Component </li></ul></ul>
  14. 14. 4 Architecture of the execution platform(2/2) <ul><li>The Architecture </li></ul>
  15. 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. 16. 6 Performance Evaluation (1/2) <ul><li>Thread Pool Tuning </li></ul><ul><li>We focused our attention on two different Thread Pool types, namely </li></ul><ul><ul><li>ThreadPoolExecutor (bounded Thread Pool) </li></ul></ul><ul><ul><li>CachedThreadPool (unbounded Thread Pool) </li></ul></ul><ul><li>The test setup is depicted in this figure </li></ul>SCs platform
  17. 17. 6 Performance Evaluation (2/2) <ul><li>Test results </li></ul><ul><li>Config_1: ThreadPoolExecutor </li></ul><ul><li>Config_2: CachedThreadPool </li></ul><ul><li>Config_3: ThreadPoolExecutor bounded to the maximum size of experiment 2 </li></ul>120 4160 Config_3 120 3657 Config_2 150 4790 Config_1 Total Elapsed Time (sec) Throughput (events/sec)
  18. 18. 7 Conclusions <ul><li>Conclusions </li></ul><ul><li>We defined a list of requirements for the execution of Event Driven Mashups and list of Design Solutions </li></ul><ul><ul><li>in particular, SessionLess Orchestration results to be the most interesting proposed solution </li></ul></ul><ul><li>We designed and implemented a Mashup Execution platform based on the proposed solutions </li></ul><ul><li>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. </li></ul>
  19. 19. Thank you for your attention

×