Icin 2009
Upcoming SlideShare
Loading in...5
×
 

Icin 2009

on

  • 377 views

 

Statistics

Views

Total Views
377
Views on SlideShare
377
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Icin 2009 Icin 2009 Presentation Transcript

    • Session B3 Web 2.0, Cloud and Telco Scalable Orchestration of Telco/IT Mashups Massimo Maresca Computer Platform Research Center (CIPI) [email_address]
    • Agenda
      • Introduction
      • Platform Requirements
      • Design Solutions
      • Architecture of the execution platform
      • Discussion
      • Performance Evaluation
      • Conclusion
    • 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.
    • 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)
      • The Architecture
    • 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
      SCs platform
    • 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)
    • 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.
    • Thank you for your attention