The document proposes a model for defining and executing event-driven composite services. It describes three main entities: events, base services that wrap external resources, and composite services composed of base services. It discusses how services are created, deployed, activated, and executed on a service execution platform. As an example, it describes a truck tracking composite service that is activated when a truck enters a port gate, launching a new session to track the truck.

1. An Approach to Event Driven Services and Composite Services Massimo Maresca Computer Platform Research Center (CIPI) University of Padova & Genova (Italy) [email_address]

2. Agenda Introduction The Service Model Service Creation & Deployment Service Activation & Execution Example: the Truck Tracker Service Conclusions

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

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

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

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

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

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

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

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

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

12. 4. Service Activation & Execution (3/5) The components of the SEP

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

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

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

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

17. Thank you for your attention