A Scenario of Service-oriented Principles Adaptation ...

Pre-print:

N. Kryvinska, C. Strauss, B. Collini-Nocker, P. Zinterhof, “A Scenario of Service-oriented Principles Adaptation to the Telecom Providers Service Delivery Platform”, The Fifth International Conference on Software Engineering Advances (ICSEA 2010), 22-27 August 2010, Nice, France, IEEE ISBN 978-0-7695-4144-0, pp. 265-271.

A Scenario of Service-oriented Principles Adaptation to the Telecom Providers Service Delivery Platform

Natalia Kryvinska, Christine Strauss

Bernhard Collini-Nocker, Peter Zinterhof

Department of eBusiness, School of Business, Economics and Statistics, University of Vienna Bruenner Strasse 72, A-1210 Vienna, Austria [email protected], [email protected]

Department of Computer Sciences University of Salzburg Jakob-Haringer-Str. 2, 5020 Salzburg, Austria [email protected] [email protected]

Abstract— Telecom service providers face a challenge how to increase average revenue per user by new-generation services. In view of the fact that it is extremely difficult to predict the success of the certain kind of service(s), as a result the providers are in need for a dynamic architecture that has to be capable to deliver new services promptly, add resources for successful services as demand increases, or remove unsuccessful services effortlessly. Such architecture has to be a modular standards-based service platform that supports different protocols and interfaces as well as QoS-based transformations and gateways. The potential candidate for this delivery platform is Service Oriented Architecture (SOA). Thus, the aim of our work is to develop a SOA implementation methodology considering telecom service providers existing enterprise network architecture and potential future growth. Keywords- Enterprise Architecture, Service Delivery Platform (SDP), Service Oriented Architecture (SOA), Telecom Services, Telecom Service Providers, Web Services Management.

I.

INTRODUCTION

The landscape in the telecommunications industry today is much more competitive than 10 years ago. In the 1990s, only traditional Telecom Operators were competing for a share of the market. Today, Telecom Service Providers work in a much more diverse environment that includes cable television operators, Internet/Web-2.0 suppliers, and mobile/wireless services providers. Besides, it is about impossible to predict from where the next competitive challenge will arise [1][2]. Thus, in order to survive in this highly competitive Telco/IT service offering market, Telecom Providers have had to revise and reconfigure their service development and delivery strategy. This strategy has to meet the following requirements: • Open IT (Information Technologies) landscape to the customers, suppliers and distributors; • Guarantee agility in implementing new services, e.g. reduce time-to-market for new services and products; • Provide cost reduction and faster services development, integration and deployment;

•

Remove outdated technologies from the ICT (Information and Communication Technologies) systems; Reduce geographic and organizational constraints; Deploy web-oriented platforms/portals.

• •

Moreover, a “Telephone company” has to be transformed into the “Net company”. And, the following features must define this process: • Future information systems have to be built and current information system have to be ported on a three level architecture using the Internet technologies. • Web-based interfaces to access the information system have to be used systematically. • Business logic on the second level has to be built using standard and robust middleware technology. • Service primitives have to be based on the middleware, to be used by the applications. • Applications componentization and objectorientation. To conclude, the main challenge, and in the same time the main goal for Telecom Service Providers is to implement a technical infrastructure capable of making the information system simpler, more flexible, and open, while providing secure access to enterprise resources [3][4][5]. II.

DEFINING THE REQUIREMENTS TO THE SERVICE PLATFORMS

The term Service Delivery Platform (SDP) usually refers to a set of components that provide services delivery architecture (such as service creation, session control & protocols) for a type of service. There is no standard definition of SDP in the industry although the TM Forum (TMF) is working on defining specifications in this area. The business objective of implementing the SDP is to enable rapid development and deployment of new converged multimedia services (see Figure 1), from basic phone services to complex audio/video conferencing for multiplayer games [6][7][10].

The Service Delivery Platform for Telecom Enterprise is a system that provides one or more services to the user by means of the network and the information system. The same services can be accessible via different access networks and with different types of terminals. The user is recognised whatever the usage context is. The new approach concerning SDP has lead to new architectural rules for these platforms: • High availability of the services; • Real-time visibility for the end user; • Different handling rights depending on the customer; • user data storage and protection; • Direct interfaces with networks and equipments enabling services; • Diverse types of terminals instead of the single web browser; • Incorporation of services and portals with multichannel access and delivery; • Various content providers with requirements for accounting and traceability.

Figure 1. Reference architecture of converged SDP, our vision.

Besides, the SDP model has to go behind the following objectives: • Guarantee the consistency and interoperability of platforms and networks; • Gain greater reactivity and competitiveness with reuse; • Provide fast and manageable transitions between different phases of the service lifecycle and the conformity to the planned service level. The model has to include four planes: • User-installation plane; • Network plane; • Service plane; • Information system or in other words IT plane. This model we discuss in details in the next sections in accordance to the SOA approach [3][8][9][10][11].

III.

THE OBJECTIVES AND THE METHODOLOGY OF SOA IMPLEMENTATION

The objective of this work is to develop an effective methodology/plan of SOA principles adaptation to service platforms in Telecom Enterprises, taking into consideration their existing architecture and the future growth. Thus, the SOA deliberations are related to the following Telecom Enterprise objectives: • Real-time service creation by service composition and reuse; • Release an access to B2B or end-user relations, access to network and IT resources, imply openness at multiple points and levels in the considered architectures; • Maintain the control on services availability; • Services quality monitoring/control. • Investments protection by services revenue insuring and risk lowering. Launching the SOA to Telecom Enterprise enables the existing IT systems to adapt to changes, bring in agility catering for rapid reconfigurations in a phased rollout manner, help define new services and make them available quickly to customers, internal users and partners (other service providers) and help integrate services within the organization leveraging the guidance IT planning. In general, the application of SOA can be used internally and between IT, network equipments, services platforms across functional domains and geographies for the extended enterprise, including B2B (Business-to-Business), with a maximum reuse of existing technologies where it makes sense. Furthermore, the need for a Services Oriented Architecture is to reduce the complexity of the Telecom Enterprise network topologies and security implemented. Also, development of services platforms as well the necessity to expose some of secured services to partners or customers are strong drivers for a new services infrastructure. This infrastructure has to provide functions around those services and core enterprise components. Some of these functions are as follows: routing to distributed services, securing services, fostering their reuse and visibility, defining and enforcing functional and technical Service Level Agreements (SLAs), reporting, managing and monitoring services. The added value of a services infrastructure is in providing these functions close to where they are needed in the distributed environment. Thus, the following steps have to be included into the SOA implementation plan/methodology: • Exposing services to service platforms and B2B gateways; • Endorsing current legacy services using a SOA and enriching them into secured, quality monitored web services; • Sharing and reusing service components, technical constraints and governance/ ownership responsibilities; • Services orchestration, where and how;

• • • • IV.

new services and the volume of traffic they will generate; Leveraging services infrastructure to provide external interfaces to partners and internal interfaces; Arranging services into categories and hierarchies; Managing SLA enforcements [3][12][13][14][15]. ANALYSIS FEATURES AND ARCHITECTURAL DESIGN BASED ON THE CONCEPTS AND COMPONENTS

In this section, we introduce and analyze the key features of a new architectural design based on the concepts and components. A. The Architectural Model The proposed model shows various domains of Telecom Enterprise information systems which communicate using a service backbone coupled with a registry and a Web services management system. The domains may be distributed physically and utilize routes defined in service backbone for the response-requests flow (see Figure 2). In this model, VPN (Virtual Private Network) domains are linked by using network connectivity following SIA (Security Industry Association) rules of controlled access (exchange zone). The service backbone (SBB) is made of interconnected hubs and forms an infrastructure grid, providing a services oriented transport layer between the Network, Services Platform, Information Systems and B2B planes. This interconnection defines routes between services client and providers parties which can be defined dynamically. The purpose of the service backbone is to provide a transport layer to this SOA infrastructure. The backbone is intended to be purely technical and stateless. It is aimed at high throughput, simple routing and flow logic that are resilient to changes, robust and highly available. The model shows how service backbone hubs and registries are working to provide message flow in and over the domains.

Figure 2. Architectural Model of Telecom Enterprise IT systems Communication over SBB.

The registry is also introduced as a core component of a SOA. The registry is in fact an integrated and searchable registry-repository which holds SOA artifacts and the metadata associated with it. In other simplistic terms, the registry holds references to SOA pieces and repository holds the pieces. The registry also facilitates governance as it does bind human organizations, internal communication, standard approval processes and SOA artifacts such as services WSDL (Web Services Description Language), security policies, etc. By intersecting these different aspects of SOA, technical, business or organizational facets, the registry complements simple SOA descriptions with human ownership and control processes over the resources (services, policies, validation workflows, organizational taxonomies). In a large, heterogeneous Services Oriented Architecture with multiple layers of infrastructure the service backbone and repositories need to participate in a management framework that provides end-to-end visibility across services. Historically these services include end-point stacks as well as all intermediaries that may be present (multiple Web Services stacks, intermediaries or integration brokers, adapters, legacy infrastructures and so on). The role of the Web services management, included into the model, is exactly this one. This framework allows for access and control of performance, reliability, throughput and availability of the Web services that are being deployed. Web Services Management provides auto-discovery of new services, service level policy enforcement, exception management, and integration with a registry to attach management data to services. It does also leverage the existing capabilities explained above with the registry and the service backbone. All these aspects combined make the SOA ready to function, own and manage its services [3][16][17]. B. Service Backbone Functionality The main functionality is to receive service calls from service consumers and to forward them to dedicated service providers. An important design principle is that the entire business logic of the SOA is placed in the service domains where clients and providers handle the semantics of their exchange. The state is maintained by them using distributed computing techniques. This introduces some challenges for the parties when using load balancing solutions but it mainly guarantees the scalability of the service backbone. The SBB hubs meshed together constitute the overall backbone (see Figure 3). From the logical point of view the service backbone is made of hubs (or nodes) in a grid. Each SBB node acts as an intelligent routing entity between service consumers (services client, other hubs or brokers) and service providers (final providers or other intermediaries). The SBB hub guarantees interoperability with all other parties that comply with WS Basic Profile, JMS providers and other de-facto standards like .Net INDIGO and Apache AXIS. In terms of scalability and reliability, the proposed network of hubs has multiple

advantages. First it does provide loose coupling between connecting parties and protocols. This capability to mix and match is a great support for a flexible architecture. Different communication modes (such as synchronous and asynchronous) can be accommodated for input and output messages and the same interface is used for different messaging paradigms.

Figure 3. SBB Instances, Hubs and Clusters.

Depending on the situation, the traffic traversing SBB nodes can be very intense. For example, the service requests rate on the SDP gateway can be quite important. A peak of 3000 messages per second can be hitting the Web services and RMI (Remote Method Invocation) gateway. The throughput of an SBB hub depends on a variety of factors such as protocols, messages and their size, processing logic complexity and the number of instances available to process the load [18][19]. C. Processes Management with SOA One of the important questions raised when implementing SOA, is related to the orchestration concept. The orchestration word is understood as part of a general vision, involving a step by step approach for the invocation of several services, combining them in upper level, coarse grained new services. However, this can take place at different levels in the overall architecture, and may represent different scopes. The first understanding of orchestration is related to the Business Process Management (BPM): how can we model and build application logic, for business applications requiring the invocation of several services in their core business functionality? For example, an order processing and provisioning application can be modeled as a business process with a set of steps and complex test cases involving subscriber account checking, subscriber data updating, customer care, billing, etc. Each of these steps can appear as invoked applications exposed as services through the SOA infrastructure. The second meaning of orchestration is understood as related to the service composition, leveraging built-in features of the SBB. In fact, the underlying ESB itself gives

the possibility for intelligent routing of service calls, according to some data included in the routed message. For example, a customer ID or subscriber number can be defined as criteria to route messages to different bases. The ESB (Enterprise Service Base) tool offers the possibility for fast service composition, which can span business scopes, but the aim of the SBB approach is to handle technical aspects as infrastructure features. The service composition at the SBB level should then be considered uniquely in the case of routing and callout of services based on technical criteria [3][16][20]. D. Service Registry in SOA The use of the registry is a pointer of the maturity of SOA within an enterprise. As in multiple enterprises, the first attempts with services were technology driven and saw the creation of Web services providing point-to-point connectivity between applications. The use of Service Registry can allow developers on projects to find and reuse existing services to build new applications and at runtime, the registry can act as the reference point for systems that need to access a service or information about a service (see Figure 4). When a new service is built, the contract and other information required to make the service a reusable IT asset is published to the systems of record. At runtime, it is important to notice that in a typical use case most of the services are already provisioned and they will be invoked directly on the backbone without prior client lookup on the registry. Nevertheless, the consistency and validity of the logical registry over a period of time is key to ensure that this architecture is correct, manageable and functional.

Figure 4. The Service Registry Framework.

The purpose of the Service Registry is to store metadata about available services. And, it has to have the following features:

• • • • • • •

Static or dynamic capabilities to record and discover of services based on UDDI v3 (Universal Description, Discovery and Integration); Support for customized policies, naming rules and taxonomies; Web services, console or script based lookup capabilities and intelligent caching for queries; Services versions support; Administration consoles both business and/or technical; Change and replication mechanisms to other registries, WSM and ESB. Publishing process to support clear workflows to ensure that services are published only if they are compliant with Telecom Enterprise policies.

This is a only a condensed list which outlines the most important aspects of the service registry [3][14]. E. Web Services Management within the Enterprise SDP Service Level Agreement (SLA) is one of the main features as well as functions of Web Services Management (WSM). It can either be technical (service round trip time, service failure ratio or error count) or functional when it deals with service access quotas, requestor characteristics or other business oriented aspects. In theory these service levels are mutually agreed by service consumers and service providers. In practice when a service is provisioned it is deployed with a particular SLA which is more of an objective at that point. The difficulty resides in being able to enforce this SLA across the boundaries of the systems. The control and predictability of the whole depends on those enforcements. The proposed architecture model has to guarantee that both types of SLA are enforced for the totality of the transactions within its scope. Another vital utility of WSM is supervision. In the case where a client application has become a great consumer of service and issues a very large number of requests, it is possible to take action because the supervision has detected an abnormal request rate on the system and has triggered an alert. In case where it is possible to determine the potential excess, apply a temporary quota and ring the different parties to solve the problem. There are multiple ways of defining and enforcing those service agreements at different levels: at the service backbone level, in the registry or other custom developed extensions. In order to separate out the concerns, there should not be any functional rules or logic implemented at the backbone level as it is an infrastructure foundation on which other business and functional components are relying. In order to implement the service agreement, the bus can invoke this rule and make a routing decision. For instance, if according to a user value attribute (like user A is gold and user B is silver) an SLA mentions that gold users are entitled fastest available service, the service backbone can lookup the result of this rule to know where to route the request. Another typical use case: a service contract is a quota per

sliding time window on usage: user A can invoke by contract 100 times a service in a month. WSM allows for a global management of SOA, not only at a local level and each service individually but also helps to provide a consolidated view. Major WSM vendors extend their backbone capabilities leveraging a distributed agents framework which collect runtime data, enforce management policies, and offload policies analysis overhead to servers. This lightweight and modular approaches offer the following service management features: • Highly transparent business data visibility enables information in the SOA environment to be monitored and managed by a broad set of business parameters including customer segment, price level, order size and SLA status; • Interactive dashboards and extensive business-level reporting provide a highly targeted user experience; • Errors management with automated dependency tracking and targeted error analysis provides a robust distributed exception management capability. • Duplex-based integration with enterprise systems management supervision across multiple layers, hardware. With such a global management architecture in place, integrated with local SBB and registry instances, it is possible to define and enforce SLAs across the ITs and Services Platforms domains and global control and predictability of the SOA architecture is enhanced. Using a customizable and lightweight portal approach, control and management can be delegated by roles to different user population (developers, operations, business managers).

Figure 5. WSM framework.

In terms of deployment, the overall infrastructure benefits from the combination between the registry, the SBB and the WSM. Increased management comes with a relative simplicity as all the components leverage the others capabilities; without burdening all applications and services providers.

As shown in the Figure 5, all the SOA components are coming together as the over-arching management system has interfaces with service backbone, the registry and the management system. With the backbone, SLA enforcement typical use cases are made possible by the notifications initiated by the SLM (Service Level Management) system to the SBB hubs for dynamic routing decisions. A context based routing example could be that upon a request attribute (gold customer request) the SBB needs to look up the proper end point destination to respect the SLA for gold customer. An event driven approach where WSM pushes destination endpoint information to the backbone and updates its routing tables, has the merit of being both control efficient with minimum overhead and penalty on the routing bandwidth. For highly dynamic and less intensive services the routing data can be discovered by looking up the SLM server. By leveraging a registry a WSM management platform is able to: • Verify if a given business service is under management; • Catalog the business services managed by a given provider; • Leverage the registry’s change discovery and notification capabilities, so a management platform can be informed of modifications to a management provider as well as new or updated business services requiring management functions; • Find out whether a given management provider supports the base set of WSDM (Web Services Distributed Management) capabilities and interfaces or exposes an extended set of capabilities and interfaces. In general, SOA, by means of its components and tools like SBB, Registry and WSM, reduces IT total cost of ownership, maximizes investments in existing systems by integrating new applications and business processes. It provides global enterprise visibility and reduces the total cost of building, supporting, and maintaining applications, in the new era of convergence of fixed, mobile and Internet worlds using all these advanced techniques [3] [19][21] ÷ [24]. V.

CONCLUSIONS

We have studied in this paper challenges, opportunities and benefits of the SOA concepts implementation to the Telecom Enterprise IT environment. We first analyzed the evolution of the approaches and strategies in the Telco IT landscape. In order to survive in this highly competitive Telco/IT service offering market, Telecom Providers have to revise and reconfigure their service development and delivery strategy. Next, we defined and discussed the requirements to the service platforms. Now, the evolution of the Telco world involving the extension of the IT to the customers and partners, and the convergence of fixed, mobile and Internet

world, have brought new requirements, leading to new architectural approaches. After that, we have been working onto the development of a methodology/plan of SOA principles adaptation to service platforms in Telecom Enterprises, taking into consideration their existing architecture and the future growth. And finally, we analyzed the key features of a new architectural design based on the concepts and components. When bringing SOA promises such as reusability, interoperability and scalability into real life, new questions arise regarding important issues such as service scoping, security and SLA management [3][19] ÷ [24]. REFERENCES [1]

Industry Brief, “IT Management Solutions for Communication Service Providers. How can I deliver innovative new services more rapidly?”, CA, IB05CSPINS01E-MP327580308, 2008. http://www.ca.com 19.03.2010. [2] N. Kryvinska, L. Auer, C. Strauss, and P. Zinterhof, “A Methodology for the Enterprise Information and Communication Infrastructure Design Process”, 2nd Int. Conf. on Network-Based Information Systems (NBiS-2008), September 1-5, 2008, Turin, Italy, pp. 303312. [3] L. Feuillet, M. Anakok, and O. Laplace, “Service Oriented Architecture at Telecom Company”, BEA recommendations, BEA Systems, a subsidiary of Oracle Corporation, 03.03.06. [4] N. Kryvinska, L. Auer, and C. Strauss, “SOI Framework for the Efficient Management of Complex Resource-Intensive Applications on Constrained Devices”, Int. Workshop on Design, Optimization and Management of Heterogeneous Networked Systems (DOMHetNetS’09), in conjunction with ICPP-2009, September 22nd -25th, 2009, Vienna, Austria, pp. 249–255. [5] J. Wilmes and S. Sankar, “Standards-Based OSS for Accelerating Converged Services Delivery - The Integration of IMS and Service Delivery Platforms”, April 2007, Vol. 1, IEC Newsletter. http://www.iec.org/newsletter/april07_1/ 29.03.2010. [6] From Wikipedia: “Service Delivery Platform” http://en.wikipedia.org/wiki/Service_delivery_platform 9.03.2010. [7] N. Kryvinska, L. Auer, and C. Strauss, “Managing an Increased Service Heterogeneity in Converged Enterprise Infrastructure with SOA”, Inderscience, Int. Journ. of Web and Grid Services (IJWGS), Special Issue on Web/Grid Information and Services Discovery, Vol. 4, No. 4, 2008, pp.440 - 460. [8] I. Demydov, N. Kryvinska, C. Strauss, M. Klymash, and I. Ivanochko, “Enterprise Distributed Service Platforms - an Approach to the Architecture and Topology”, Emerging Research and Projects Applications Symposium (ERPAS 2009), in conjunction with MoMM2009, 14-16 December 2009, Kuala Lumpur, Malaysia, ACM, pp. 417-421. [9] T. Pollet, G. Maas, J. Marien, and A.Wambecq, “Telecom Services Delivery in a SOA”, 20th International Conference on Advanced Information Networking and Applications - Volume 2 (AINA'06), 2006, pp.529-533. [10] R. D. Callaway, M. Devetsikiotis, Y. Viniotis, and A. Rodriguez, “An Autonomic Service Delivery Platform for Service-Oriented Network Environments”, IEEE Transactions on Services Computing, Special Issue on Modeling and Implementation of Service-Oriented Enterprise Systems, 2010. [11] Z. Duan, Z.-L. Zhang, and Y. T. Hou, “Service Overlay Networks: SLAs, QoS, and Bandwidth Provisioning”, IEEE/ACM Transactions on Networking, 2003.

[12] M. Papazoglou, P. Traverso, S. Dustdar, and F. Leymann, “ServiceOriented Computing Research Roadmap”, World Scientific Publishing Company, International Journal of Cooperative Information Systems, Vol. 17, No. 2 (2008) 223–255. [13] J. L’opez and D. O’Hallaron, “Evaluation of a resource selection mechanism for complex network services”, 10th IEEE International Symposium on High Performance Distributed Computing (HPDC-10 2001), 7-9 August 2001, San Francisco, CA, USA. [14] J. Spohrer, P. Maglio, J. Bailey, and D. Gruhl, “Steps Toward a Science of Service Systems,” IEEE Computer, pp. 71–77, 2007. [15] C. Ghezzi, “Service-Oriented Computing: Where does it come from? A software engineering perspective”, keynote address at Int. Conf. on Service-Oriented Computing (ICSOC 2005), Amsterdam, The Netherlands, December 12-15, 2005. [16] B. Orriens and J. Yang, “Bridging the Gap between Business and IT in Service Oriented Business Collaboration”, IEEE Int. Conference on Services Computing (SCC05), Orlando, Florida, USA, July 2005. [17] S. Wenhui, L. Feng, Z. Jinyu, and D. Gang, “Develop a telecommunication service system using service-oriented architecture”, IEEE International Conference on e-Business Engineering (ICEBE'06), 24-26 October, Shanghai, China, 2006.

[18] I.-Y. Chen, G.-K. Ni, and C.-Y. Lin, “A runtime-adaptable service bus design for telecom operations support systems”, IBM Systems Journal, vol. 47, no. 3, 2008. [19] J. Yang and M. P. Papazoglou, “Service components for managing the life-cycle of service compositions”, Information Systems vol. 28, no. 1, 2004. [20] P. Harmon, “Second generation business process methodologies”, Business Process Trends vol. 1, no. 5, May 2003. [21] L. John J and B.-N. Ron, Integrating service level agreements with OSS, Wiley Publishing, 2002. [22] H. Kreger et al., “Management Using Web Services: A Proposed Architecture and Roadmap”, IBM, HP and Computer Associates (June 2005), www-128.ibm.com/developerworks/library/ specification/ws-mroadmap 29.03.2010. [23] F. Casati et al., “Business-Oriented Management of Web Services”, Communications of the ACM vol. 46, no. 10, 2003. [24] B. Orriens and J. Yang, “Modeling and Managing Service Oriented Business Collaboration”, Int. Workshop on Middleware for Web Services (EDOC-MWS05), Enschede, Netherlands, September 2005.