3rd KuVS meeting


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

3rd KuVS meeting

  1. 1. Service Composition Technology for the Internet of Services and for Next Generation Telecom Services P. Baglietto 1 , M. Maresca 1 , M. Stecca 1 , A. Manzalini 2 , R. Minerva 2 , C. Moiso 2 1 CIPI University of Genoa and Padua, 2 Telecom Italia Berlin, 14th October 2010 3rd GI/ITG KuVS Fachgespräch on NG SDPs
  2. 2. Outline <ul><li>Introduction </li></ul><ul><li>Service Composition </li></ul><ul><ul><li>Telco View </li></ul></ul><ul><ul><li>Internet View </li></ul></ul><ul><ul><li>Comparison </li></ul></ul><ul><li>A convergent execution platform </li></ul><ul><li>Conclusions </li></ul>
  3. 3. Introduction <ul><li>The “Service Composition” concept may refer to different models and technologies. </li></ul><ul><li>Technological trends: </li></ul><ul><ul><li>Service Exposure (Orange, Deutsche Telekom , etc. ) </li></ul></ul><ul><ul><li>Mashups (e.g., Yahoo Pipes!, JackBe Presto, etc.). </li></ul></ul><ul><li>In this presentation we identify two classes respect of the boundaries of the Telecom Operators SDP, namely: </li></ul><ul><ul><li>The In-out scheme: services execute on the Application Servers of the Operator SDP and take advantage of services provided on the Internet; </li></ul></ul><ul><ul><li>The Out-in scheme: services execute outside the Operator SDP takes advantage of services provided by the SDP. </li></ul></ul>
  4. 4. Service Composition – Telco View (1/3) <ul><li>The Service Delivery Platform </li></ul><ul><li>The Service Execution Platform: </li></ul><ul><ul><li>A set of Execution Platforms (e.g. SIP AS, JSLEE AS, etc.) + a set of gateways that interact with the Service Enablers </li></ul></ul><ul><li>The Service Exposure Layer: </li></ul><ul><ul><li>Admission Control Module </li></ul></ul><ul><ul><li>Policy Enforcement Module </li></ul></ul>Image Source: Moriana (2004)
  5. 5. Service Composition – Telco View (2/3) <ul><li>Service Exposure </li></ul><ul><li>Some services are already available also outside the telecom operator boundaries, e.g.: </li></ul><ul><ul><li>Voice Call </li></ul></ul><ul><ul><li>SMS / MMS </li></ul></ul><ul><ul><li>Localization </li></ul></ul><ul><li>New services may be available, e.g.: </li></ul><ul><ul><li>Advanced SendSMS (e.g., send an SMS to all the “friends” in a certain geographical area) </li></ul></ul><ul><ul><li>Extract aggregated data from the Operator back-end (e.g., return the number of persons in a given area at a given hour of the day) </li></ul></ul>
  6. 6. Service Composition – Telco View (3/3) <ul><li>Service Composition </li></ul><ul><li>Classic SDP Composition Scheme: compose in the service execution platform the enablers and the services executed on the different platforms in the SDP </li></ul><ul><li>In-out Composition Scheme: compose the enablers and the services already available in the SDP with external services (e.g., Social Network APIs, Calendar APIs, RSS Feeds, etc.). Some issues can be identified: </li></ul><ul><ul><li>Identity management (e.g., the external service’s credential mng  Tokens? See Google Apps, Salesforce, MS Azure) </li></ul></ul><ul><ul><li>Subscription/Payment management (e.g., find a light scheme for telco capabilities usage  new payment API?) </li></ul></ul>
  7. 7. Service Composition – Internet View (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 tools for the rapid development of convergent Composite Services (a.k.a. Mashups) that combine different resources such as Yahoo Pipes!, JackBe Presto, etc. </li></ul>
  8. 8. Service Composition – Internet View (2/3) <ul><li>Client side vs Server Side </li></ul><ul><li>Server Side execution model is often preferable than Client Side </li></ul><ul><ul><li>Long running Mashups (see the CloudPhone Intel Project); </li></ul></ul><ul><ul><li>Service execute even if terminals are disconnected and/or turned off; </li></ul></ul><ul><ul><li>Security; </li></ul></ul><ul><ul><li>Management. </li></ul></ul>Client side Server side SC1 SC2 SCN User Node (Browser, Smart Phone, etc.) SC1 SC2 SCN Browser (User) Mashup Engine (Server) Request Results
  9. 9. Service Composition – Internet View (3/3) <ul><li>Service Composition </li></ul><ul><li>Availability of Telco enablers through the Service Exposure Layer </li></ul><ul><li>Out-in Composition Scheme: the SDP Service Exposure Layer allows to combine Web 2.0 Internet services with Telco services. Some issues can be identified: </li></ul><ul><ul><li>Do the Internet programmers really need the services provided by the Operators? </li></ul></ul><ul><ul><li>Which kind of services should the Operator expose? </li></ul></ul><ul><ul><li>Which are aspects that in-Out and Out-in composition schemes have in common? </li></ul></ul>
  10. 10. Service Composition – Comparison (1/3) <ul><li>1. Telco Service Granularity level: </li></ul><ul><ul><li>In-out: it is possible to directly access the telco enablers thus the developer can decide at which abstraction level he/she wants to work (e.g., at SIP messages level instead of at “make call” level); </li></ul></ul><ul><ul><li>Out-in: the Operator decides which functionalities can be exposed and their abstraction level. In that case the Internet programmer must follow the service provider directives. </li></ul></ul><ul><li>2. Execution Latency: </li></ul><ul><ul><li>In-out: since the service composition takes place inside the SDP, the latency related to the telco enablers combined in a Mashup is lower than in the Out-in case (e.g., for each request the Admission Control module invocation can be skipped); </li></ul></ul><ul><ul><li>Out-in: since the service composition takes place outside the SDP, the latency related to the telco enablers combined in a Mashup is higher than in the In-out case. The performance may also be related to some SLA policies. </li></ul></ul>
  11. 11. Service Composition – Comparison (2/3) <ul><li>3. Programming skills: </li></ul><ul><ul><li>In-out: the direct interaction with the complex telco functionalities requires skilled programmers; </li></ul></ul><ul><ul><li>Out-in: a large number of graphical Mashup creation tools already exist. It means that that also non skilled programmers might create Mashups (e.g., based on the Widget/Gadget technology). </li></ul></ul><ul><li>4. Identity Management: </li></ul><ul><ul><li>In-out: the telecom Operator already manages user’s sensitive data thus it can rely on the fact that users see it as a “Trusted Entity”; </li></ul></ul><ul><ul><li>Out-in: Internet companies like Google and Facebook use and/or sell user’s data for commercial reasons so they might be seen as “less-Trusted Entities”. </li></ul></ul><ul><ul><li>Issues: federation among ID management entities and/or user profile data replication. </li></ul></ul>
  12. 12. Service Composition – Comparison (3/3) <ul><li>5. Service activation: </li></ul><ul><ul><li>In-out: in general activated by events provided by the service enablers (e.g., call events, update on user’s state/location, SMS/MMS sending/receiving, timer triggers,…); </li></ul></ul><ul><ul><li>Out-in: in general, explicitly activated by user’s request (e.g., through the browser), or by events from interfaces of the capabilities accessed through the service exposure. </li></ul></ul>
  13. 13. An convergent execution platform (1/2) <ul><li>Service Proxies (SPs): </li></ul><ul><ul><li>wrap only one internal/external resource </li></ul></ul><ul><ul><li>decouple the Mashup Logic from the specific Enabler implementation (useful in case of modifications in the Enablers) </li></ul></ul><ul><ul><li>can fire more than one “Mashup Event </li></ul></ul>
  14. 14. An convergent execution platform (2/2) <ul><li>The Platform presents the following features: </li></ul><ul><ul><li>It is convergent in the sense that it can support both the in-out and the out-in service composition models </li></ul></ul><ul><ul><li>Thanks to the Service Proxy component, it can interact with all the different telco protocols and / or Internet technologies (RSS Feed, Atom, JSON, etc.) </li></ul></ul><ul><ul><li>It is designed to be scalable and fault tolerant </li></ul></ul><ul><ul><li>It efficiently routes incoming events </li></ul></ul><ul><ul><li>It executes Long Running services (e.g., polling-based) allowing to save the battery energy on the mobile terminals </li></ul></ul><ul><ul><li>It is a Server-Side engine thus it allows to execute services even if the terminals are disconnected and/or turned off </li></ul></ul>
  15. 15. Conclusions <ul><li>We proposed a classification of two service composition schemes, namely the In-out and the Out-in models </li></ul><ul><li>We compared the two service composition schemes </li></ul><ul><ul><li>Some issues are still open </li></ul></ul><ul><li>We proposed a convergent execution platform that allows to efficiently execute the Composite Services both inside and outside of an SDP </li></ul>
  16. 16. Q&A <ul><li>Thank you! </li></ul><ul><li>Questions? </li></ul>