Service Broker for 3 Party Enabling

Transcription

1 Deutsche Telekom Laboratories An-Institut der Technischen Universität Berlin rd Service Broker for 3 Party Enabling Horst Stein, Niklas Blum (FhG Fokus) White Paper No. 5 August 2009

2 Abstract and Keywords Abstract and Keywords This whitepaper describes our approach to include telecommunications service enablers into WWW mash-ups or other 3 rd party applications by defining a policy-based service broker that mediates between the 3 rd party applications and real-time communication service enablers. Furthermore, defined policies serve besides service access definitions as a flexible expression for user/service-specific capabilities. Index Terms: Enabler, 3 rd Party enabling, mash-up, brokering, authorisation, delegation Status Public Participants Not restricted. Page 2

3 Table of contents Table of contents Abstract and Keywords Introduction Architecture Use Cases Outlook References Table of figures Page 3

4 1 Introduction The emerging Web 2.0 digital marketplace presents an important opportunity for telecommunications operators to offer their own capabilities as services. Besides communication services like short message service (SMS), voice-call or location, further capabilities like billing, identity management, authentication or control of Quality of Service (QoS) are candidates as telecommunications enablers for the development of new applications. Deutsche Telekom AG has launched its open development portal called Developer Garden [1] in November 2008 with some communications related enablers like SMS and voice call. The target of the portal is to expose simple interfaces for developers, who can combine these services to create web applications and new products. Via the open development portal, the 3rd party service developer becomes part of the community and gets access to core network functionalities using Web Services and the open programming interfaces via the software development kit. Comparable activities are performed in British Telecom's Ribbit [2] and in the Orange Partner program [3]. If the telecommunications operator exposes valuable sources of functionality and content to a wider audience, it is necessary to underpin the service delivery platform with certain security and management mechanisms. A set of technologies must be provided in order to control the access of the service, manage the impact of executing the service usage or apportion this payment according to revenue sharing rules if the service is partly or wholly owned by a 3rd party provider. Figure 1 provides an overview of the role of the service broker as part of the emerging web / telco service sphere. Introduction The Service Broker realises technical mechanisms for brokering between telecommunications and 3rd party service (e.g. Web 2.0 mash-ups, enterprise services) environments. Our approach is a policy-based service broker allowing the definition of request- and service-specific policies serving as Service Level Agreements (SLAs) between a service access gateway to service enablers in an operator environment and applications in 3rd party domains. The project is organized by Deutsche Telekom Laboratories in cooperation with the Fraunhofer Institute for Open Communication Systems (FOKUS). Figure 1 Enabler Environment for 3rd Parties Page 4

5 Architecture 2 Architecture The Service Broker is designed as several independent modules which are accessible through Open Mobile Alliance (OMA) Service Environment (OSE) [4] compliant interfaces. OMA defines several application service enablers and specifies general access functions for 3rd party service access in OSE as a common abstraction layer for IP Multimedia Subsystem (IMS)- based NGNs. Central element in OSE is the Policy Evaluation, Enforcement and Management (PEEM) component which intercepts service requests from a foreign domain as well as from any other service requestors and applies certain rules (policies). PEEM may be used for the authorizations of requests or to define enabler capabilities for exposure based on request policies. OMA has specified two interfaces PEM-1 [5] to trigger policy evaluation requests for intercepted service requests and PEM-2 [6] for policy retrieval from the policy repository. Our architecture of the Service Broker (figure 2) comprises Message Interceptor(s), Callable Interface PEM-1, Policy Evaluation Engine, Policy Enforcement Engine, Service Capability Manager, a workflow engine and the Policy Management Engine. Figure 2 Architecture of the Service Broker Page 5

6 In our experimental environment the Service Broker delegates service requests which address enabler services from Developer Garden, FOKUS Open IMS, and SOA Telco Playground based on policy definitions hold in a Policy repository (figure 2). Figure 3 illustrates a flow of service usage, i.e. from a service request to the service enabler using the evaluation mechanisms of the Service Broker. A policy is a formalism to manage resources, to provide controllable access and to reuse the existing resources exposed by an operator or 3rd party provider. Each policy is defined as a rule set and each rule is composed of conditions and actions. Actions may be either identifiers for responses of the Policy Enforcement Engine to allow or deny a certain request or the definition of a target in case of a defined delegation to a different service (e.g. an orchestrated service). Architecture The Policy Management Engine provides the mechanism for policy repository management and implements common operations such as uploading a policy, modifying it or deleting it. The underlying protocol is based on XML Configuration Access Protocol (XCAP) [7]. As an example to incorporate more complex services we make use of a Business Process Execution Language (BPEL)-based work-flow engine [8] which is targeted for delegation as defined within a specific policy. This mechanism allows that the original exposed service interface remains the same from a 3rd party service perspective, while the executed service that will be called through a defined action as part of the policy nevertheless provides a specific business logic, defined by the operator policy for a specific (3rd party) service or user. Service (Consumer) Service request Interceptor Service (Resource) PE request Callable Interface PE response PE responses: allow deny delegated services resp. PEv request PEn decision Policy Repository Policy Evaluation Engine PEv result Policy Enforcement Engine Delegated Delegated Service Delegated Service Delegated Service Service Figure 3 Flow of Service Usage Page 6

7 Use Cases 3 Use Cases One major use case of the Service Broker is authorization and delegation of service requests from a 3rd party service provider towards the operator domain (Figure 4). As the Service Broker is stateless, authorization is performed for every request. For each service enabler, an XSLT file has to be created for the interceptor providing the transformation according to OMA PEM-1 of the service request for policy evaluation [9]. Figure 4 Message flow for request authorisation Authorisation and delegation criteria are described in the policies e.g. related to request originator (e.g. domain, IP address, identity like SIP URI, tel URI, MSISDN) or request target (service identifier, identity like domain range, number scheme). This allows for instance to route an SMS request targeted for a customer from a specific country-provider (e.g. T-Mobile UK) to the related country specific resource (SMS Center of T-Mobile UK) based on a specific policy, without changing the call parameters. A second use case is the delegation to an additional service enabler in dependence of a special service contract (e.g. low budget service with advertisement vs. premium service without advertisement) through policies. The advantage using such a mechanism is that the functional (exposed) interface remains the same from the perspective of the service developer but the executed application logic may include certain business logics as advertisement enriched services. Page 7

8 Use Cases Figure 5 enabler Service Delegation to additional advertisement Further use cases (e.g. handling events - incoming call or messages - from the network based on policies, exposure of allowed enabler) are realised in the experimental setup. Page 8

9 Outlook 4 Outlook This whitepaper desribes the design for a service broker component based on state-of-the art SOA principles that take the latest standards and concepts in telecommunications into account. The work is based on a policy evaluation and enforcement engine that provides the capability to match service requests to operator defined policies. The policies allow a fine-grained service usage as a mapping of service contracts between service enablers, 3rd party services and users. From the presented perspective the unique approach is to provide one single standardized interface and policy expression format to evaluate service access, service usage as well as service capability information defined by the operator. Future work will concentrate on the dynamic service discovery, orchestration, and composition based on semantics, to allow the combination of many (operator-specific) service enablers automatically for more complex services. Page 9

10 References 5 References [1] [2] [3] [4] Open Mobile Alliance (OMA). OMA Service Environment. Approved Version Feb [5] Open Mobile Alliance (OMA).Policy Evaluation, Enforcement and Management Callable Interface (PEM1) [6] J. Rosenberg. RFC4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). May 2007 [7] IPsphere Framework Technical Specification (Release1) IPsphere 1.0. June IPsphere Forum [8] ActiveBPEL. [9] N. Blum, I. Boldea, T. Magedanz, U. Staiger, H. Stein, "A Service Broker providing Real-time Telecommunications Services for 3r d Party Services", Proc. of 33rd Annual IEEE International Computer Software and Applications Conference (COMPSAC), Seattle, July 2009, ISBN , DOI /COMPSAC Page 10

11 Table of figures 6 Table of figures Figure 1 Enabler Environment for 3rd Parties...4 Figure 2 Architecture of the Service Broker...5 Figure 3 Flow of Service Usage...6 Figure 4 Message flow for request authorisation...7 Figure 5 Service Delegation to additional advertisement enabler...8 Page 11

12 Table of figures Publisher: Deutsche Telekom AG Laboratories Ernst-Reuter -Platz 7 D Berlin Telefon: Authors: Dr. Horst Stein (Deutsche Telekom Laboratories) Niklas Blum (Fraunhofer Institut für Offene Kommunikationssystem FOKUS) 2009 Deutsche Telekom Laboratories The information contained in this document represents the current view of the authors on the issues discussed as of the date of publication. This document should not be interpreted to be a commitment on the part of Deutsche Telekom Laboratories, and Deutsche Telekom Laboratories cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. Deutsche Telekom Laboratories makes no warranties - express, implied, or statutory - as to the information in this document. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording or otherwise), or for any purpose, without the express written permission of Deutsche Telekom Laboratories. Deutsche Telekom Laboratories may have patents, patent applications, trademarks, copyrights or other intellectual property rights covering the subject matter in this document. Except as expressly provided in any written license agreement from Deutsche Telekom Laboratories, the furnishing of this document does not give you any license to these patents, trademarks, copyrights or other intellectual property. Page 12