PARLAY API: BUSINESS BENEFITS AND TECHNICAL OVERVIEW

Transcription

1 PARLAY API: BUINE BENEFIT AND TECHNICAL OVERVIEW Key Theme: T2, What s Your Network IQ? Authors: Dr Ivan Boyd pp B54 Rm 133 B54 Adastral Park Martlesham Heath IPWICH uffolk IP5 3RE United Kingdom Mike Carr pp RT4/M2 B63 Adastral Park Martlesham Heath IPWICH uffolk IP5 3RE United Kingdom Tel: Tel: Fax: Fax: ivan.boyd@bt.com mike.d.carr@bt.com

2 TITLE: Parlay API: Business Benefits and Technical Overview ABTRACT The evolution of intelligent capabilities in conventional switched networks and data networks has generated opportunities to expose control of network capabilities to enterprises outside of the network operator s domain. Control can be exposed via an API, such that service providers can generate a new range of applications that execute in their domain but benefit from, and add value to, functionality in the network. This paper discusses the work of the Parlay Group who have generated an API specification providing access to network information and control of a range of network capabilities. The Parlay API specification is open and technology-independent to encourage the widest possible range of market players to develop and offer advanced telecommunication services. The published paper provides an overview of the business benefits and the technical architecture of the Parlay API. The most recent version of the published API is 1.2 but by the time of the presentation, version 2 will be complete and the phase 3 programme will have commenced. The presentation will overview the most recent Parlay API functionality and also provide an outline of the goals of phase 3. An overview of available Parlay oftware Developers Kits and reference models will also be provided. Abstract Page

3 1 Introduction The evolution of intelligent capabilities in conventional switched networks and data networks has generated opportunities to expose control of many telecommunications network capabilities to enterprises outside of the network operator s domain. Historically, these capabilities have been exclusively under the control and exploitation of the network operators themselves. This has partially been as a result of incompatible standards but also to ensure network security and integrity. This has resulted in: 1. Network centric communications service delivery mechanisms (e.g. AIN and IN) which run "in" the network domain but generally cannot access data in the enterprise domain for critical decision making. 2. "Edge of network" service delivery mechanisms (e.g. enterprise CTI) which run outside the network domain but generally cannot access critical information and capabilities within the network. The network centric approach is excellent for simple mass-market applications. The services are relatively easy to manage, and they can be built in a very robust fashion. A greatly simplified layered representation of a typical network operator s architecture is shown in Figure 1. The top layer represents applications, the middle layer service components, that are reused by many applications, and the lower layer different network technologies. Illustrated in this figure are example applications such as; freephone (800) services and personal numbering; service components such as routing, billing and authentication; and network technologies such as IDN, PTN, and IP. Currently all three tiers of this architecture are owned and operated exclusively by network operators. The disadvantages of this architecture in the modern market place are significant. For example, because the network operator is responsible for the creation and operation of all applications, it is difficult to achieve the necessary flexibility to deploy many customised versions of services to different customer groups. Also the time-to-market for new applications is long because both application development and integration testing take significant time and effort. The edge of network approach is good for providing customised services to meet the specific needs of a customer. However, often the ability to use information or resources within the network domain would provide a more efficient solution than an edge of network approach, e.g. calls are often unnecessarily tromboned to and from edge of network devices. What is needed is a solution that combines the benefits of the network centric approach of economies of scale and reliability, with the flexibility of the edge of network approach. To achieve flexibility the applications may be built, tested and operated by enterprises outside of the network domain. To take advantage of the network centric approach, access to network information and control of network Page 1 of 6

4 capabilities must be available to the enterprise domain. This can be achieved by creating an Application Programming Interface (API) that resides between the application layer and the service component layer as illustrated in Figure 2. Enterprise Domain $OLFDWLRQVÃHJÃÃ3HUVRQDOÃ 1XPEHULQJÃ9RLFHÃPHVVDJLQJ 6HUYLFHÃ&RPRQHQWVÃHJÃ5RXWLQJ Ã$XWKHQWLFDWLRQÃ%LOOLQJ&RQILJXUDWLRQ 1HWZRUNVÃHJÃ,6'1Ã3671Ã,3 Network Operator s Business Domain $3, Ã $ Ã $ Ã $ 6HUYLFHÃ&RPRQHQWV 3K\VLFDOÃ1HWZRUNV ÃQ $ Network Operator s Domain Figure 1 Network Operator s Business Domain Today Figure 2 Network API By enabling access to network capabilities via an API, service providers, independent software vendors (IVs) and other developers in the IT and telecommunication industries are empowered to generate a new range of applications that benefit from, and add value to, functionality resident in public and/or private communications networks. These enhanced services are then either used within the enterprise or they are sold to other enterprises. The API does not directly open up the networks signaling for public usage. Rather, network capabilities can be encapsulated and made visible in a manner that maintains the integrity, performance, and security of networks. Network integrity protection must be an integral part of the API design and implementation. Only by achieving high integrity with deployed APIs will the operation of applications in the enterprise domain be effectively prevented from impacting existing network hosted applications. New applications can be developed to meet the needs of a particular customer group and tested in isolation from existing network applications, thus enabling both rapid development and flexibility. 2 The Parlay Group and API pecification The Parlay working group was formed in March 1998 to produce an API specification that would provide enterprises access to network information and allow them to control a range of network capabilities [1]. The Parlay group that generated the first version specification consisted of BT, Ulticom [formerly DGM& Telecom], Microsoft, Nortel Networks and iemens. The plans of the group were outlined in May 1998 [2] and in November 1998 the completion of the phase 1 specification work was announced [3]. The group published the first version of the specification in December 1998 and provided public demonstrations of a hypothetical Guaranteed Call Delivery application [4]. This application illustrated how an Page 2 of 6

5 enterprise, operating and trading outside of the network operator s domain, could offer a service to end customers by employing some of the key capabilities available from the Parlay API specification, version 1. The Parlay Group was expanded during the early part of 1999 by the addition of 6 new members: AT&T, Cegetel, Cisco, Ericsson, IBM and Lucent. The expanded group was announced in June 1999 along with the agreed work programme for phase 2 [5]. The phase 1 programme primarily addressed call control, messaging, and security. The Phase 2 programme is focused on the expansion of the API functionality particularly in the areas of wireless and IP services. One of the major goals of the second version of the specification is to facilitate the convergence of Wireless, PTN and IP networks. 2.1 The Parlay API pecification The Parlay API specification is open and technologyindependent, so that the widest possible range of market players (e.g. Independent oftware Vendors (IVs)) may develop and offer advanced telecommunication services. The API is intended to be simple to use and extensible. To achieve these goals, an object-oriented approach to specifying the API has been adopted. The main specification is defined in the technology independent Unified Modeling Language (UML) [6]. However, while keeping the Network API technology independent, implementation issues that could impact the realisation of the API must be taken into account. Deployment of the API can be via technologies such as COM, CORBA or JAVA. To date the Parlay group has also generated, from the main UML specification, technology dependent IDL specifications in Microsoft IDL and Corba IDL. The complete set of documents that define the Parlay Version 1.2 specification can be found on the Parlay Web site ( To further assist with the realisation of the API, the Parlay group also intends to publish for key technologies: 1. A reference implementation of the API, i.e. a software simulation of the API that provides the expected behavior of a real implementation as viewed from the application. Network functionality will be stubbed out so that the reference implementations can be used to test an application up to the point where the application is dependent upon real functionality. 2. A oftware Developer Kit (DK), consisting of example code and supporting documentation, to aid developers produce applications that exploit the capabilities of the API. 2.2 Parlay API Characteristics The Parlay API can be characterised as follows: Object Oriented (adopted as it is an efficient and proven approach to specifying APIs) Multi-media (the API will support services with different media types, not just telephony) Manageable (essential characteristic if network operators are going to deploy the API) Page 3 of 6

6 ecure (unless both service providers and network operators are convinced that the security of their respective domains is maintained the API will never be adopted by the industry) imple (essential that the API is easy to use or applications developers will not employ it) Extensible (the aim of the Parlay Group is to expand the API in a series of phases and hence extensibility of both the service and management support functionality is essential) upports Discovery (a capability that enables the application developer to request a logical capability leaving the API to locate a particular interface to perform the requested operation) Network Independent (enterprise applications can operate across multiple network technologies) 2.3 Architecture of the Parlay API The Parlay API consists of two categories of interface: ervice Interfaces. These offer applications access to a range of network capabilities and information. Framework Interfaces. These provide the supporting capabilities necessary for the service interfaces to be secure, resilient, located and managed. Examples of the supporting functionality provided via the framework interfaces are listed below. These examples are taken from the version 1.2 Parlay framework interface: Authentication Event Notification Discovery Integrity Management For a comprehensive explanation of all framework capabilities see [1]. Examples of service interfaces are listed below. These have been selected from the version 1.2 Parlay API specification: Generic Call Control ervice Generic Messaging ervice INAP1 Call Control ervice Generic User Interaction ervice For a comprehensive explanation of all service capabilities see [1]. Page 4 of 6

7 The architecture of the Parlay API is illustrated in Figure 3. This figure illustrates the relationship between applications, the framework and service interfaces, resource interfaces and networked equipment. Clearly an implementation of the API will need to interface to network-based resources, through Resource APIs as illustrated in Figure 3. cope of Parlay pecification Resources )UDPHZRUN 5HVRXUFH $OLFDWLRQ $OLFDWLRQ $OLFDWLRQ 6HUYLFH 5HVRXUFH... 6HUYLFH 5HVRXUFH Figure 3 API Architecture The Resource APIs provide a structured means to integrate network resources into the API implementation. pecific interfaces or APIs that may already exist (such as H323 or INAP) can be plugged in to this interface. This allows the Parlay API to be used in a wide variety of network situations, and avoids the Parlay Group re-inventing functionality that already exists. 2.4 Benefits of the Parlay API The success of the Parlay API will be determined to a very significant extent by the perceived benefits that it provides. This sub-section summarises the benefits from the perspective of network operators, service providers, application developers and end users. Network Operator Traffic growth as service provider applications drive demand Ability to address niche markets through service providers Improved time to market by partnership with service providers tep towards convergence of IT and telecommunications ervice Provider Market opportunity for new services by exploiting the API. Can address niche market requirements cost-effectively Improved time to market for new applications as network operator integration testing is avoided Applications portability as API hides implementation detail Application Developer Provides new business opportunities previously not technically feasible (because functionality was not available from network operator) Applications development opened to the majority of IVs DKs make application development simple and cost-effective Page 5 of 6

8 End User Vastly reduced time from idea to application deployment Ability to integrate new communications application solutions with other business software Retains control of business critical databases and functions Application solutions available from a wide range of developers at highly competitive prices 3 Conclusions The focus of the Parlay group is to produce an API specification that enables enterprises outside of the network operators domain to access network information and control a range of network capabilities. The Parlay group believes that there is a tremendous growth opportunity for network operators, service providers and application developers by the adoption of the Parlay API. Customers will benefit as business needs are met more cost-effectively and quickly using the capabilities offered via the Parlay API. In summary the major goals of the Parlay group are to: define an API specification that provides application developers a consistent, network independent view of functionality they can employ ensure that the API specification provides the necessary support for the maintenance of security and integrity of both the network and enterprise domains encourage both the IT and Telecommunications industries to implement and deploy the Parlay API globally work with the IT industry to encourage the production of DKs that make the process of developing applications exploiting the Parlay API straightforward and efficient. encourage application developers to do what they do best, i.e. creating new and innovative applications using the Parlay API to solve customers business needs. Call control and messaging functionality is provided by the service interfaces in version 1.2 of the API. Version 2 of the API, will add significantly more functionality including IP connectivity management and mobility functions. An overview of this functionality will be provided in the presentation. 4 References 1. Parlay API specification Core pecification document, 2. Parlay Group Press Release, May 1998, 3. Parlay Group Press Release, November 1998, 4. Guaranteed Call Delivery Demonstration, 1998, 5. Parlay Group Press Release, June 1999, 6. UML version 1.1, November 19, 1997 (OMG standard) Page 6 of 6