Webx 2010
Upcoming SlideShare
Loading in...5
×
 

Webx 2010

on

  • 296 views

 

Statistics

Views

Total Views
296
Views on SlideShare
296
Embed Views
0

Actions

Likes
0
Downloads
0
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

    Webx 2010 Webx 2010 Presentation Transcript

    • An Approach to Event Driven Services and Composite Services Massimo Maresca Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) [email_address]
    • Agenda
      • Introduction
      • The Service Model
      • Service Creation & Deployment
      • Service Activation & Execution
      • Example: the Truck Tracker Service
      • Conclusions
    • 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 (e.g., phone calls, SMS messages, conference calls, etc) mainly due to Telecom Operators service exposure.
      • 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)
      • A reference model for the definition of Event Driven Mashups is proposed in this paper.
    • 1. Introduction (2/3)
      • Example of a graphical Mashup Creation Tool
      • List of “composable” services on the left
      • Create your own Composite Service on the right
    • 1. Introduction (3/3)
      • Applications
      • Web 2.0 Mashups: combination of data and services provided by means of technologies like RSS Feed, Atom, Web Services, etc. (for a complete list see the Programmable Web repository). Examples:
        • E-government info (e.g., closed roads, concerts, etc.) + Google Maps
        • Monitor RSS Feed + New Tweet on Twitter
        • Monitor Google Calendar + Send SMS
      • Enterprise Mashups: addressing the “Long Tail” 1 through combination of data and services belonging both to the private sphere of an Enterprise (e.g., the CRM system) and to the public Internet (e.g., the APIs listed in Programmable Web).
      • 1 V. Hoyer, K. Stanoesvka-Slabeva, T. Janner, and C. Schroth. “Enterprise Mashups: Design Principles towards the Long Tail of User Needs.” In SCC '08: Proceedings of the 2008 IEEE International Conference on Services Computing, pages 601-602, Washington DC, USA.
    • 2. The Service Model (1/2)
      • The model includes three entities, namely Events, Base Services and Composite Services.
      • 2.1 Events
      • An Event is a notification associated to a Name and to a Property Set. A property is a <Name, Value> pair.
      • 2.2 Base Services (BS)
      • Each BS wraps an external service / resource.
      • External Services are highly reusable
      • functionalities of common use like messaging,
      • localization, social networks, etc.
      • A BS may be synchronous or asynchronous
      • depending on the external service features.
    • 2. The Service Model (2/2)
      • 2.3 Composite Service (CS)
      • A Composite Service is a service implemented through the coordinate action of a set of BSs.
      • Horizontal arrows  communications among BSs
      • Vertical arrows  communications between a BS and the correspondent External Resource
    • 3. Service Creation and Deployment (1/2)
      • BS creation and deployment
      • The creation of each BS needs:
        • The creation of a set of files called Facets that describes the new Service.
        • The development of a software program that interacts with the specific External Service through different technologies (e.g., RSS Feed, WS, etc.).
        • The creation of a new BS requires programming skills but it can be considered as an upgrade of the system since it happens rarely.
      • The deployment of each BS:
        • is needed to make the new BS available in the Service Creation Environment
        • needs the deployment of its facets and programming code in the Service Execution Platform (i.e., the software module in charge of executing Composite Services)
    • 3. Service Creation and Deployment (2/2)
      • CS creation and deployment
      • The creation of each CS needs:
        • The creation of a set of files called Facets that describes the new CSs.
        • The definition of the Composite Service logic by means of a graphical tool like the one showed in slide 4.
        • A CS is defined through a directed graph in which the blocks correspond to BS and the arrows to Event passing. This graph is saved in a repository when the creator presses the “save” button in the tool.
        • It is possible to define some assignments for each arrow.
      • The deployment of each CS:
        • is needed to make the new CS executable
        • needs the deployment of its facets and the parsing of the
        • XML file representing the CS logic to extract
        • the information used at run-time
    • 4. Service Activation & Execution (1/5)
      • The path from Service Creation to Service Execution
      • Deployment of the CS (already discussed in previous slide) performed by the System Administrator.
      • Activation of a deployed SC performed by an end-user:
        • Creation of a new Activation ID to be associated to a set of input properties;
        • Invocation of the Configure_Session_Launch method in the Session Controller component.
      • Launch of a Session of an Active CS, performed as a consequence of an external condition:
        • Invocation of the Session_Launch method in the Orchestration Management System component;
        • Creation of a new Session ID to be associated to that particular CS execution.
      • Execution of the CS:
        • The Orchestrator component interacts with Service Proxies to execute the application logic;
        • When a Session finishes, a new Final Event is generated and the resources related to that Session are de-allocated.
    • 4. Service Activation & Execution (2/5)
      • Service Activation versus Service Execution
      • Activation  Triggered by users + Set of Configuration info (Initial Properties)
      • Execution  Triggered by external events + Session generation
              • = Event
      Activation_ID=A Config_Props_A Activation_ID=B Config_Props_B Activation_ID=C Config_Props_C Session_ID=A.3 Session_ID=A.2 Session_ID=A.1 Session_ID=B.1 Session_ID=C.1 Session_ID=C.2
    • 4. Service Activation & Execution (3/5)
      • The components of the SEP
    • 4. Service Activation & Execution (4/5)
      • Support for Nested Composite Services
      • It is possible to compose an already existing CS together with other BSs to create new CSs
      • A new BS acts like an adaptor to the already existing CS
        • It invokes an Activate service in the Activator, attaching its endpoint as a Session Controller reference;
        • It receives and processes the Configure Session Launch invocation;
        • It invokes the Launch Session service call in the OMS.
    • 4. Service Activation & Execution (5/5)
      • Design Issues for Service Execution Platform Design
      • Service Orchestration as Event Routing
        • 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 SCs
      • Centralized vs. Distributed Orchestration
        • We chose the Orchestration approach because it assures more control on what happens within the platform at execution time (e.g., AAA)
      • Session-less behavior
        • Each SC execution 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
    • 5. Example: the Truck Tracker CS
      • Graphical specification of the Composite Service
      • Activation:
      • Performed by a Terminal
      • Operator who interacts with the SEP
      • through a Web interface;
      • It configures the Session Controller
      • (in this case a Truck Entrance Detector
      • located at the port gate).
      • Session Launch:
      • When a new truck enters the port gate
      • the Truck Entrance Detector
      • launches a new Session (Initial Event).
    • 6. Conclusions
      • We proposed a model for the definition and the execution of Event Driven Composite Services
      • We described some design solutions (e.g., Sessionless Orchestration)
      • We analyzed in details a real world example
      • Future works:
        • Refine the model
        • Refine the prototype of the platform that we already implemented on the basis of this model
    • Thank you for your attention