Best Practices for SOA SDPs

Best Practices for Implementing SOA-based Service Delivery Platforms November 2007 A Whitepaper by OSS Observer and IONA Technologies Table Of Contents Analysis of the Service Delivery Platform Market OSS Observer The New CSP Competitive Landscape ______________________ 3 The Role of an SDP _________________________________ 3 What does an SDP look like? ____________________________ 4 What is the role of middleware in SDP? ______________________ 4 What are the challenges in implementing an SDP? ________________ 5 Critical success factors for SDP middleware ___________________ 5 Carrier-Grade SOA Infrastructure for Service Delivery IONA Technologies SOA Trends in Telecom _______________________________ 8 Typical SDP Architecture ______________________________ 8 Dealing with Heterogeneous Systems _______________________ 9 SDP Integration Requirements with OSS _____________________ 10 Solutions for Carrier-grade SOA _________________________ 12 Reliable, High Performance Messaging ____________________ 12 Single View of Customer ____________________________ 13 SOA Lifecycle Management __________________________ 13 Distributed SOA Infrastructure __________________________ 14 OSS Observer Analysis of the Service Delivery Platform Market October 2007 The New CSP Competitive Landscape The balance of power between Communications Services Providers (CSPs) and adjacent industries has evolved rapidly over the last 10 years. The entry of media and internet companies into telecom services such as Google, MSN, Yahoo and eBay (Skype) is putting increasing competitive pressure on CSPs to deliver new innovative services at reasonable cost. At the same time, CSPs have the new opportunity to offer customers a rich communications and entertainment experience that delivers far greater value than traditional telecom services. We are seeing this in the consumer broadband market with the rollout of Internet Protocol TV (IPTV) services and in mobile with the combination of content, messaging, presence, community, location and many other services. However, a CSP can maximize the value of its core service enablers by opening them to internal developers, strategic partners and potentially the open market. Figure 2: Service enablers from CSPs and Internet companies Rich Communications & Entertainment Internet Value Browsing Customer profile Portal e-mail Instant messaging Billing Presence Voice Advertising Gaming Search Video Entertainment Web 2.0 Content Communities Bandwidth SMS Mobility MMS Customer profile IPTV Call termination Quality of Service Billing Presence Mobile TV Figure 1: The New CSP Competitive Landscape Location CSP Network Value Media & Entertainment Internet Players Source: OSS Observer Smart Pipe Rich entertainment & communications experience For CSPs to be successful, they must be able to respond quickly to competitive threats and partnering opportunities. This competitive landscape is the main business driver for CSPs implementing service delivery platforms (SDPs). Mobile Operators Source: OSS Observer Fixed Operators Cable Operators The Role of an SDP Service delivery platforms enable communication services providers to efficiently create and deliver new and innovative services. They also provide a platform for CSPs to open their service and network infrastructure to third parties. Having the flexibility to choose where to cooperate and where to compete is critical to success. SDPs deliver a range of new and existing services that combine communications, entertainment and electronic commerce. Multimedia content, messaging, presence, location, games and real-time charging are key enablers. Figure 2 shows the increasing value of service enablers from internet companies and CSPs. It has become clear that Internet companies are dominating in areas such as e-mail, search and social networking. CSPs will dominate in providing an infrastructure that provides wide area mobility, supports the quality of service requirements to deliver IPTV and mobile TV. Many of the other areas are still in dispute. PO Box 1319, Sugar Grove, IL 60554-1319 | Phone: +1.630.466.9223 | Fax: +1.630.566.3863 Email: info@ossobserver.com | Website: www.ossobserver.com © 2007 OSS Observer LLC. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any other means - electronic, mechanical, photocopying, or recording or by any otherwise - without the prior written permission of OSS Observer LLC. OSS Observer LLC maintains that all reasonable care and skill has been used in the compilation of this document. However, OSS Observer LLC shall not be under any liability for loss or damage (including consequential loss) whatsoever or howsoever arising as a result of the use of this document by the customer, his employees, contractors, agents or any third party. CSPs in mature markets must increase revenue per subscriber by offering new innovative services that combine voice and messaging with content and entertainment. Mobile device manufacturers are facilitating the new services with multimedia devices that combine high-resolution video cameras, color screens, stereo music, mobile TV, GPS and 3G data speeds into attractive portable packages. Service delivery platforms provide CSPs with the IT infrastructure to combine these multimedia capabilities into new services at reasonable cost. Mobile SDP investment is the main area of focus in emerging markets. The low penetration of PSTN lines and the resulting shortage of DSL access are making mobile content and messaging particularly attractive. A growing percentage of the population will have the means to pay for the more sophisticated services that an SDP enables. CSPs, in fast growing markets are less encumbered by legacy. They will move more aggressively with SDP implementations than their counterparts in mature markets. Supporting third-party interfaces with service-level agreements and policy control are critical capabilities for enabling content provider and service provider partners to participate in providing services. Providing southbound interfaces to the many service enablers available within the CSP infrastructure is an essential feature. This requires support of a wide variety of proprietary, legacy and new generation protocols. Parlay gateways are an effective approach for telecom services. Many application servers also support a wide variety of southbound interfaces. Many services must be available on a wide variety of devices, particularly in the mobile area. The SDP must hide the complexity of this issue from developers. The SDP is part of the CSP's network and service infrastructure and must provide the interfaces to integrate with the operational support systems for business, service and network management. In many current deployments, the integration with OSS and BSS is a significant part of the project. What does an SDP look like? In most SDP projects, the CSP builds a business case around a portfolio of known services, with some upside for the flexibility and support for rapid delivery of new services. The details of the SDP architecture depend on the type of services at which it is targeted. SDPs can be focused on mobile content, fixed VoIP, fixed mobile convergence, IPTV enhancement and many other opportunities. The figure below shows the main characteristics regardless of the specific telecom services focus. Figure 3: SDP environment Content Providers Service Providers Marketing What is the role of middleware in SDP? The role of IT middleware in the Telecom environment has grown steadily over the last two decades. Telecom products and solutions were originally vertically integrated with the application, middleware, operating system and hardware provided by a single organization. IT infrastructure has the advantage of greater economies of scale and wider availability of developers than specialized Telecom platforms. However, IT infrastructure has limitations in meeting some telecom’s requirements. Latency, resilience, continuous operation and manageability have been challenges. As these have been over-come, IT infrastructure has increasingly penetrated telecom. It is now wellestablished in operational systems and growing rapidly in the service layer. IT middleware, such as CORBA, EAI and more recently ESB and Web services have played a key role in this growth. Starting in business support systems, they have spread to operational support systems and now with SDP implementations into the service layer. SOA based SDP Devices End Users Telecom Services BSS OSS IT Business Operations Service Enablers - IN, SMSC, MMSC, Presence, Location, HSS, CSCF, PoC, … Network Operations Legacy access network Core Network Radio access network Broadband access network Source: OSS Observer The creation and execution of telecom services are at the core of the service delivery platform. This may be supported by dedicated application servers, content management systems and Web services orchestration. Page 4 © 2007 OSS Observer LLC. Figure 4: The evolution of telecom software Telecom specific solutions Telecom product Application Application Middleware Middleware Operating Operating system system Hardware Hardware Telecom product Application Application Middleware Middleware Operating Operating system system Hardware Hardware Telecom product Application Application Middleware Middleware Operating Operating system system Hardware Hardware The SDP is part of network and must be capable of meeting the CSP requirements for resilience, manageability, scalability, latency and continuous operation. Recent experience shows that these requirements can be met with a well-architected and implemented SDP. Some new services may not require full carrier-class capabilities, but many will and the SDP must have the flexibility to support these where required. Another challenge is that CSPs will deploy multiple SDPs. Right now, an SDP is deployed on a largely tactical business case to support, say, content or messaging or voice 1980s Vertical integration 1990s Stand-alone platforms 2000s Distributed platforms video services, and so we are seeing a IT platforms proliferation of SDPs within any large service provider. In the next few years, CSPs will face Source: OSS Observer the challenge of consolidating these SDPs to control costs and deal with operational issues in the service layer. Current SDPs are developed using SOA principles and an ESB is used to connect the SDP components and surrounding infrastructure. The ESB can also be used as a service execution platform for orchestrating new services. However, telecom services with tight latency requirements and large-scale deployments are best executed within an application server. The challenges of delivering an SDP implementation were covered in the previous section; here we will focus on the success factors most relevant to the use of IT middleware. Simply put, an SDP is part of the network and must be capable of meeting the requirements of carrier-class network services. Critical success factors for SDP middleware What are the challenges in implementing an SDP? A significant challenge for SDP projects are the organizational boundaries that exist in most CSPs. The SDP is part of the service layer and therefore the responsibility of the network organization. However, it is based on IT platforms that are owned and managed by the IT organization. Some CSPs have addressed this by creating a combined team, with skills from both organizations that own the implementation and operation of the service layer. Managing third-party relationships is another challenge. Operational processes and support systems must be adapted to support a potentially large number of third-party partners. Automation is critical for some content-based services where there are hundreds of content partners. Support for rapid service innovation is a fundamental requirement for an SDP. This has implications for not just the SDP but also the operational systems that support it. Where these are legacy systems, there are considerable challenges in delivering operational support for rapidly developing services. • • • • • Resilience: capable of delivering 5x9s up time normally required of networking equipment Manageability: network operations must have the interfaces to deal with failures, upgrades, reconfiguration, and new service introduction Scalability: scale to tens of millions of subscribers and hundreds of services Continuous operation: Telecom systems must be able to operate without interruption indefinitely. This means being able to upgrade any component while still providing service. It must support rollback in case of problems Latency: capable of participating in real-time services Finally, OSS/BSS integration and the operational processes associated with them will be critical to the success of SDP deployments. Middleware can play a key role in enabling this. Page 5 © 2007 OSS Observer LLC. About OSS Observer OSS Observer is a market research firm covering the global telecom software market. Our goal is to provide clear reasoning and practical recommendations to help our clients make informed business decisions. OSS Observer publishes forecasts, market share and analysis of industry trends that drive commercial spending on service assurance, service fulfillment, customer care, billing, network equipment manufacturer's NMS, service delivery platforms, and middleware worldwide. Founded in 2003, OSS Observer has more than 100 clients in North America, Europe, and Asia. OSS Observer's subscription clients include tier-1 service providers, leading software suppliers, network equipment manufacturers, and capital investment firms. Our analysts bring to the company decades of first-hand experience at service providers and vendors in North America and Europe. Page 6 © 2007 OSS Observer LLC. Carrier-Grade SOA Infrastructure for Service Delivery Carrier-Grade SOA Infrastructure for Service Delivery Abstract: The advent of Service Delivery Platforms (SDPs, AKA Service Delivery Frameworks) puts softwarebased systems squarely in the critical path for delivering telecom services to subscribers. A service-oriented architecture (SOA) is the design principle that underlies SDPs, implying the need for carrier-grade SOA infrastructure. As SDPs move from pilot projects to established assets, operators must consider how they should be integrated with mainstream operational support systems (OSS) in order to avoid creating yet another operational silo. This paper discusses functional requirements and specific solutions IONA has delivered in the most recent of almost two decades of service to the telecom industry. Page 7 November 2007 Carrier-Grade SOA Infrastructure for Service Delivery SOA Trends in Telecom Service differentiation is moving north from hardware-based service control points to software-based SOA networks. While hardware networks still play a central role in service connections to terminal equipment, increasingly the services that attract and retain subscribers are closer to those found on the Internet, if not actually Internet-based. Service delivery platforms (SDPs) are built on SOA principles to bring Internet-based services and network services together, making SDPs the intersection between the Internet and carrier networks. To achieve network-grade reliability, SOA design reuses lessons learned from a century of hardware network design: distributed components, redundancy, no single point of failure, etc. This requires a robust SOA network along with consideration of how to manage the SOA network over the long term. Service lifecycle management is a growing concern for all SOA practitioners aiming for carrier-grade service delivery. SOA governance solutions address OSS-like functions like how to deploy services, roll out new versions of services and retire old services while managing and monitoring operations. Typical SDP Architecture An SDP is supposed to make it easier for software developers to create and deploy new telephony-based applications that bring new, revenue-generating services to subscribers. While there is no exact consensus on what an SDP is, there is consistency across the high-level architecture diagrams presented by vendors, system integrators and service providers. Most SDPs are built at a minimum around a SOA platform based on XML data formats and WSDL-defined interfaces. They provide software gateways to network protocols along with capabilities that make it easy for developers to access network capabilities (often through the Parlay-X standard interfaces). There will be some kind of security layer that restricts access to and monitors usage of these software interfaces. Administration is often portal-based (at least for developer-users) and these portals trigger both SDP provisioning and network provisioning workflows. There is usually some real time settlement and billing capability provided for compensating thirdparty service providers – the ones ostensibly Typical SDP Architecture providing cutting edge new services. Page 8 November 2007 Carrier-Grade SOA Infrastructure for Service Delivery Most SDP implementation teams are not putting integration with existing OSS at the top of their list of concerns. One reason for this is they must first prove the viability of the SDP itself. Another reason is that existing OSS infrastructure presents another level of complexity due to its diverse makeup. Dealing with Heterogeneous Systems There are very few greenfield telephony environments. Though SDPs are based on SOA, they are deployed in the context of existing software systems that were built over years and decades. SOA infrastructure such as an enterprise service bus (ESB) creates, connects and mediates service interfaces, service enabling the existing OSS infrastructure with minimal effort and providing greater design flexibility than other approaches such as those based on application servers. The infrastructure for existing OSS often includes middleware from dozens of vendors using a mix of standard and proprietary technologies. New systems may provide HTTP/SOAP interfaces, but older systems based on JMS, Tuxedo, TIBCO, MQ and CORBA are also very common and business critical. Sophisticated ESBs let SOA designers wrap older systems with WSDL-defined interfaces as a virtual upgrade (i.e. an upgrade that does not require reengineering the application or existing middleware) so that they can be brought into the SOA fold with minimal development effort and little disruption to existing operations. The instantiation and execution of a WSDL-defined interface is a service’s manifestation or point of presence; in SOA terms it is a service endpoint. SOA design includes deciding a service endpoint’s location which should be considered separately from service logic execution. In other words, SOA is about distributed computing and a service endpoint is not tightly bound to its implementation. The natural tendency is to associate a service’s endpoint with the implementation of the service, that is collocate the endpoint with the application(s) implementing the service. When using a JEE application server, all service endpoints are hosted in the application server. This works fine for the applications running in the JEE server, but when an application server is used for service enabling older systems, all service calls must go through the application server hub. An application server can be a heavyweight process and is built primarily for service logic execution. Like JEE, a lightweight ESB can be used to collocate endpoints with service implementations, but ESBs also allow SOA designers the flexibility to deploy service endpoints independent of service logic execution. 1 Consumers There are many reasons to separate a service’s endpoint from its implementation. A simple example: if an application is running on an obsolete computing platform there may be no way to host a service interface there. If a customer care application needs to pull subscriber information from multiple sources, complex data integration can be hidden behind a Web service wrapper with the endpoint running on the client machine. That way the processing cost of fetching and manipulating subscriber data is distributed across the client machines rather than concentrated at a single server. Endpoint acts as intermediary between consumers and providers Service Based Applications Business Process Flows Mobile Devices Portals & Dashboard Service Endpoint 2 Endpoint deployed with service providers to accept calls from any consumer Service Endpoint 1 2 Service Endpoint 3 3 Endpoint deployed with service consumers to make calls to any provider Mainframe Transactions CORBA / J2EE Systems Providers MOM Based Systems JAVA / J2EE Systems Loose coupling of service endpoints and service implementations Page 9 November 2007 Carrier-Grade SOA Infrastructure for Service Delivery The point being that a SOA is inherently distributed and ESBs are lightweight enough to host distributed service endpoints deployed where they make the most design sense. Other benefits of distributed SOA infrastructure are performance (not burdened with service logic execution), reliability (minimizing single points of failure as in the example above) and scalability (load balancing across redundant endpoints and service implementations). SDP Integration Requirements with OSS Most service providers have SDPs in pilot or development phases. Most SDP projects provide their own minimal OSS capabilities because they have special requirements and need to be tested without disrupting other parts of the business. At some point SDPs need to be integrated with quotidian OSS operations like fulfillment, assurance and billing or they will be yet another silo in the business. There really is no other alternative. Fulfilment The plan for most SDPs in pilot is for third-party service developers to be self-provisioning through a Web portal. Marketing of new services such as bundling, promotions and pricing are mostly works in progress, but provisioning of services for subscribers is a clear requirement. Workflows for provisioning new SDP-brokered services must drive processes in both the software layer and in the network layer. Presumably network provisioning workflows are already in place and can be reused as is or serviceenabled with an ESB. Service orchestration with BPEL is ideal for driving provisioning workflows because it was designed to support long transactions lasting hours or days across asynchronous services without blocking access to resources. While it is a dramatic oversimplification to say, “simply service enable fulfillment process components and orchestrate them”, that is the idea. Assurance Service assurance for SDPs is a rich area for discussion. There are three parts to service assurance: preventing problems, detecting problems and fixing problems. And there are at least three different management systems that could be involved in service assurance for SDPs: network management systems, enterprise systems management (ESM) and SOA governance solutions. These systems are more complimentary than not; they all can help ensure service availability by supporting the detection, diagnosis and correction of problems. As in other parts of life, prevention is the best cure and early detection and correction is second best. Network Management Services managed by SDPs still depend on the network and should in fact be considered part of the network as they are visible to subscribers. If a network alarm is raised, which service does it affect? How important is that? Is it a small, quiet emergency or a large, embarrassing emergency (think Skype outage)? SDPs and the applications that use them should be able to raise alarms to network management systems (NMS) when they detect problems. At the very least the flurry of alarms raised will help correlate network problems with the services they affect and speed diagnosis and correction. Providing SDPs with the capability to raise alarms in 3GPP, TMF or other formats is a fairly straightforward task for an ESB. It should be part of the SDP functions made available to applications. Page 10 November 2007 Carrier-Grade SOA Infrastructure for Service Delivery Enterprise Systems Management ESM solutions are typically based on the simple network management protocol (SNMP) and monitor the coarse grained health of processes and hardware in an IT environment. Since the processes and hardware we care about are now part of the telephony service delivery path, ESM solutions can contribute to early detection and prevention of problems. As above, if an ESM detects an issue with say temperature in the hosting rack, it should be able to raise an alarm to the NMS describing as much. If it’s part of service delivery then the network operations center (NOC) should know about it, whether responsibility for fixing the problem lies with IT or with network operations. It may be convenient to think of ESM solutions as akin to element management systems (EMS) even though ESM solutions are too general to handle configuration of SOA services. SOA Governance Governing involves setting policies and enforcing policies. Policies are declarations taking the form, “when conditions are thus, it shall (not) be thus.” Often the initial conditions are omitted and a policy is simply a statement of how things should or should not be. That is policy setting. Policy enforcement requires interpretation of policies, monitoring compliance with them and applying rectifying actions when a breach of policy is detected. Policy management has long been a staple of hardware-based telephony networks to manage bandwidth allocation, Quality of Service (QoS) and security according to defined business policies. This is consistent with the SOA goal of creating business abstractions around software systems. Policies help ensure that services are used/deployed properly in the context of an organization’s overall SOA strategy. This means that if it is decreed that all services will be secure, we can detect that all services are indeed secure and fix those that are not. A further refinement allows policies to be set to allocate messaging bandwidth across classes of users, types of applications, time of day and other attributes. Again we see how the SOA network is really an extension of the hardware-based network. And as with the older networks, policy management when applied to SOA networks lets us proactively manage issues before they cause problems. Billing Prepaid voice plans have had to provide real time billing for a while, but that process is driven from CDRs emitted by the hardware-based network and typically involves checking and decrementing an account balance. SDPs must provide real time settlement and payment to third parties, a more complex operation. There is no information shipped around a telephony IT network more precious than usage information that drives the billing process. Data not received can mean lost revenue; data received twice can mean annoyed subscribers. Invalid data created from manual processing can lead to costly downstream errors. Reliable messaging and robust data validation rules are critical factors in a carrier-grade information supply chain. Page 11 November 2007 Carrier-Grade SOA Infrastructure for Service Delivery Solutions for Carrier-grade SOA Above we looked at some the functional requirements around SDPs and the SOA infrastructure that supports them. Now we will look at some specific solutions IONA has provided to telecom customers in the recent past. These are real world solutions that were driven by issues similar to those described above. Reliable, High Performance Messaging Vendors are now shipping solutions that are Web service enabled, usually by providing interfaces based on SOAP over HTTP. While this makes it easier to connect applications together, there are pragmatic issues that can arise when the goal is carrier-grade SOA. Protocol Tunnelling HTTP was designed to be asynchronous and stateless. It can be made synchronous and stateful with much added complexity, but the fundamental nature of the protocol does not support reliable messaging. This is not reassuring for billing information that could either get lost or sent more than once. Protocol tunneling is a technique for reliable messaging between HTTP endpoints on different machines. It involves inserting a store-and-forward messaging bridge (usually JMS) with an instance of the ESB, such as the IONA Artix ESB, just in front of each HTTP endpoint. The sending application POSTs messages to its local instance of the ESB, which persists messages to a JMS queue. The receiving instance of the ESB receives messages and POSTs them to the destination application. Accelerated XML Processing A common objection to the use of SOAP and other XML data representations is that they are quite verbose and inefficient in their representation of data. Parsing an XML document is often the most CPU intensive part interprocess communications. Building on the tunneling concept, more efficient message formats can also be used in the interstices between applications. Just as a reliable protocol can be inserted between endpoints, an ESB can translate messages into a compact data format like IIOP that is much faster to parse on the receiving end. Using this technique can improve messaging performance up to ten times. QoS Management for Messaging Earlier we looked at how network management concepts can be applied to software based systems. Managing QoS in network terms means allocating bandwidth according to the traffic being carried over the network. Simply put, some network traffic is more important than others and this extends to messaging traffic in the SOA network. It follows that SOA infrastructure needs to provide a way to allocate bandwidth preferentially to higher priority messages and manage uneven or bursty traffic flows to prevent overwhelming services. An ESB is the logical solution to provide these capabilities. For example, telephony network standards set by ETSI TiSPAN standards group include a general overload control application protocol (GOCAP) Page 12 November 2007 Carrier-Grade SOA Infrastructure for Service Delivery designed for hardware network elements that an ESB can apply to managing messaging traffic for SOA network elements. A service designer defines what the service’s maximum healthy message capacity is and the ESB ensures that maximum capacity is not exceeded, buffering messages in a persistent store when necessary. In addition, the ESB can allocate messaging capacity across classes of messages (e.g. users, payload type, etc.) giving a higher proportion of the total bandwidth to preferred traffic. With this capability, SOA network traffic can be managed by policies derived from SLAs. Single View of Customer A perpetual challenge in the industry is providing comprehensive customer support across all lines of the business. A major obstacle to this goal is for customer service reps (CSRs) to have a complete view of all the services to which a given customer subscribes. The ideal is one universal definition of a customer, but the reality is that customer data is spread all over the enterprise in all kinds of formats. Rather than physically consolidate customer data into one database, many service providers are realizing that within a SOA is the means to leave customer data where it is and assemble it dynamically into a comprehensive view as needed. An example of a universal customer data definition is the one included in the TMForum’s Shared Information/Data model (SID), an industry standard common information model. Some service providers have adopted the SID while others use data models derived from the applications currently running their OSS/BSS. Regardless of the model source, the challenge is mapping existing customer information to and from a common model. A semantic data mapping solution like IONA Artix Data Services provides the means to graphically define a mapping between two data representations, then generate the Java code that implements that mapping. The beauty of this approach is that existing data definitions can be accurately combined and leveraged to provide a single view of customer behavior without changing applications or databases. SOA Lifecycle Management Much of the activity around SOA is centered on new service creation or service enablement of existing systems. There is much focus on getting services developed and into production, perhaps less focus on how these systems should be managed over time. Rare is the service that will stand unchanged after deployment. At some point, a service deployed today will be superseded by a revised version of the service which may happen many times before the service is decommissioned. Policy management and other infrastructure components support SOA lifecycle management. SOA Lifecycle Components So far we have looked at how ESBs and data services support SOA design and development. Other SOA infrastructure components support these capabilities and play a critical role at runtime and over the entire lifecycle of a service. A name service or locator service provides real time service lookup that is the basis of loose coupling. It is imprudent to embed a service’s location into a client application; there should be the flexibility to move that service, create service pools, redirect the client to a backup implementation, etc. Locator services provide lookup, load balancing, failover and other architectural designs for carrier-grade SOA. LDAP directories, CORBA COS naming and proprietary lookup engines are examples of locator services. Page 13 November 2007 Carrier-Grade SOA Infrastructure for Service Delivery A registry is a catalog of deployed services and descriptions used mostly at service creation (development) time. Application developers need to know what services are available, how to call them and be notified when service definitions change. The most common standard used for a SOA registry is UDDI. A repository as some have observed is simply a fancy name for a database. For SOA, a repository is the master data store for information about a SOA network. Different vendors provide different capabilities with their repository. Roles of a Service Repository Some repository solutions are like document management systems handling meta-information for service descriptions, specifications, versioning schemes, consumers, contact info, categories, taxonomies, tags, etc. Some repositories support SOA network modeling including dependencies on other services. In this regard a repository starts to look a bit like a service catalog that maps telephony services to network resources. Still other repositories play a more active role in SOA governance by supporting policy management and enforcement. Active Repositories and Policy Management As discussed earlier, policy management is a way to both prevent issues before they cause problems and an effective way of managing SOA networks in business terms. SOA policy management and enforcement builds on concepts established for network policy management including terms like policy definition point (PDP) and policy enforcement point (PEP). The functional concepts behind a PDP or PEP are similar whether used in a network or SOA context. In a SOA, an active repository acts as a PDP because it holds all the information needed to determine compliance with policies and enforce them. Instances of an ESB (i.e. service endpoints) act as PEPs where policy compliance can be monitored and remedial action taken when needed. An example of a policy is “all services must be secure”. An active repository centrally captures service endpoint configurations as they are defined and serves as the database of record (the PDP) for the SOA network. Examination of a service endpoint will show whether this policy is being complied with or not, and if not the original (compliant) configuration is recovered from the repository. Distributed SOA Infrastructure IONA has been providing carrier-grade infrastructure solutions to the telecommunications industry for over 15 years. IONA’s Artix and FUSE product lines includes ESB, data integration, orchestration, locator, security, registry, repository, development and management solutions. IONA has built a reputation for solving hard problems in distributed SOA infrastructure and telecommunications companies around the world are implementing their SDP solutions using IONA products. As the SOA software network is now a de facto part of carrier network for service delivery, service providers must consider how they will manage their SOA network elements to provide the same class of performance, reliability and quality for which the industry is known. Page 14 November 2007 Carrier-Grade SOA Infrastructure for Service Delivery ……………………………………………………………………………………………………………………………………………………… IONA Technologies PLC The IONA Building Shelbourne Road Dublin 4 Ireland Phone Fax +353 1 637 2000 +353 1 637 2888 Phone Fax +1 781 902 8000 +1 781 902 8001 IONA Technologies Inc. 200 West Street Waltham MA 02451 USA IONA Technologies Japan Ltd Akasaka Sanchome Building 7/F 3-21-16 Akasaka Minato-ku Tokyo Japan Phone Fax +813 3560 5611 +813 3560 5612 Support: support@iona.com WWW: www.iona.com Training: training@iona.com Sales: sales@iona.com Copyright Artix, Artix Mainframe, Adaptive Runtime Technology are Trademarks of IONA Technologies PLC. Orbix, Orbix 2000 Notification, and Orbix/E are Registered Trademarks of IONA Technologies PLC. While the information in this publication is believed to be accurate, IONA Technologies PLC makes no warranty of any kind to this material including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. IONA shall not be liable for errors contained herein, or for incidental or consequential damages in connection with the furnishing, performance or use of this material. COPYRIGHT NOTICE. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, photo- copying, recording or otherwise, without prior written consent of IONA Technologies PLC. No thirdparty intellectual property right liability is assumed with respect to the use of the information contained herein. IONA Technologies PLC assumes no responsibility for errors or omissions contained in this white paper. This publication and features described herein are subject to change without notice. Copyright © 1999-2007 IONA Technologies PLC. All rights reserved. All products or services mentioned in this white paper are covered by the trademarks, service marks, or product names as designated by the companies that market those products. Page 15 November 2007