An Approach to Event Driven Services and Composite Services Massimo Maresca Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) [email_address]
The Service Model
Service Creation & Deployment
Service Activation & Execution
Example: the Truck Tracker Service
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 (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)
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.
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