Apr 2, 2000 - a variety of business roles including network operators, solution providers, distributors (e.g. ... easily accommodate small market characteristics either technically or ... solution providers and any independent software vendors. (ISVs) are ... are a large number of accounting and billing options afforded by this ...
The Parlay network API specification M J Yates and I Boyd
New business opportunities have emerged for network operators to offer a new generation of interfaces directly to solution providers that expose information and control in various intelligent networks. The paper describes the commercial rationale and operational benefits of these application level interfaces. The Parlay Group has defined application programming interfaces (APIs) to expose network capabilities including wireline, mobile, IP QoS, and messaging to external enterprises. The Parlay Group and the API specification are described together with an illustration of how the API could be used to create an enterprise workflow solution that integrates capabilities in different networks.
1.
Introduction
S
everal trends in telecommunications and computing have created an environment where there are business benefits from opening new types of interface to telecommunications networks. Historically, telecommunications services have been offered as physical interfaces with terminals that are used to set up and carry voice or data traffic on wireline or wireless networks. With the advent of the Internet, the meaning of communications services has been broadened to Internet service provision, messaging, Web hosting services, etc.
Background and membership information is available at the www.parlay.org Web site.
The telecommunications world has now diversified into a variety of business roles including network operators, solution providers, distributors (e.g. supermarkets) and consumers. Individual companies may be active in combinations of these areas depending on their market presence and branding.
•
This business structure has created the need to open new types of network control and information interface that expose capabilities present in various networks to enterprises other than the network operator. For example, intelligent, real-time control of a call has previously been exclusively in the control of the network operator, but exposing this to solution providers gives them new opportunities to tailor service behaviour to their end users, without the providers having to operate their own network elements. This paper describes the work of the Parlay Group in defining an open application programming interface (API) specification for such inter-enterprise control of network capabilities. The business rationale is covered, followed by a description of the Parlay Group, its specifications and finally an example application using the Parlay API.
2.
Business drivers
H
istorically, intelligent capabilities in conventional switched networks 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:
•
network-centric communications service delivery mechanisms (e.g. AIN and intelligent network (IN)) which run ‘in’ the network domain but generally cannot access data in the enterprise for domain-specific decision making, ‘edge-of-network’ service delivery mechanisms (e.g. enterprise computer/telephony integration (CTI)) which run outside the network domain but generally cannot access critical information and capabilities within the core network.
The network-centric approach is excellent for simple mass-market applications because it is easily managed and robust. A simplified layered representation of a network operator’s typical architecture is shown in Fig 1. The top layer represents applications, the middle layer represents service components that are reused by many applications and the lower layer represents different network technologies. Also annotated are typical applications (e.g. freephone 0800 services, non-geographic numbering and voice messaging), service components (e.g. routeing, billing and authentication), and network technologies (e.g. wireline BT Technol J Vol 18 No 2 April 2000
57
PARLAY NETWORK API SPECIFICATION enterprise
enterprise
networks, e.g. wireline, wireless, IP..
app 2
app 3
app n
Parlay API service components, e.g. routeing, authentication, billing, configuration.. networks, e.g. wireline, wireless, IP..
1 4 7 *
2
3
5 8 0
network operator
service components, e.g. routeing, authentication, billing, configuration..
app 1
network operator’s business domain
applications, e.g. 0800, personal numbering, voice messaging..
6 9 #
1
Fig 1
7 *
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. It is difficult for network operators to gain deep insight into business processes inside specialist markets, and new applications have prolonged time to market — due to the extensive testing necessary to ensure existing services are not compromised. Typically, mass-market IT platforms and business processes do not easily accommodate small market characteristics either technically or commercially. The edge-of-network approach is good for creating services that meet the specific needs of a customer. However, often the ability to use information or resources within the public network domain would provide a more efficient solution than an edge-of-network approach, e.g. calls are often unnecessarily ‘tromboned’ through edge-ofnetwork equipment.
58
2
4
Network operator’s business domain today.
Fig 2
5 8 0
3 6 9 #
Position of a network API for the communications solutions business.
communications networks. The API does not need to open the basic network signalling capability directly. Rather, a high-integrity API implementation is necessary to encapsulate these network capabilities and present them to enterprise applications in a manner that maintains the security of the networks and other API-based applications. New application solutions can be developed and tested in isolation from existing network applications enabling faster and more flexible development. 3.
Value chains
S
ervice delivery, as part of a network operator’s traditional retail business, involves service delivery and billing directly to customers.
What is needed for the solutions business is a combination of the network-centric approach, with its economies of scale and reliability, and the flexibility of the edge-of-network approach. To achieve flexibility the applications should be built, tested and operated by enterprises outside the network domain. To take advantage of the network centric approach, access to network information and control of network capabilities must be available to the enterprise application. This can be achieved by creating an API that resides between the application layer and the service component layer as illustrated in Fig 2.
Network operators will increasingly be delivering wholesale services to roles such as solution providers, service bureaux and distributors, as well as directly to end users — this is illustrated in Fig 3. Each player in this multitier world will both offer services to players further up the value chain and buy services and support from players lower in the value chain. There are several possible models for these relationships. In many examples, both the solution provider and network operator take responsibility for different aspects of the service delivery to customers, such as marketing, order handling, customer care, problem reporting, and billing.
By enabling access to network capabilities via an API, solution providers and any independent software vendors (ISVs) are empowered to manufacture new applications that add value to functionality resident in public or private
The introduction of a network API will enable new service providers to specialise in solutions that add value on top of network operator capabilities. Simple examples are personal numbering and mobility solutions that fit the
BT Technol J Vol 18 No 2 April 2000
PARLAY NETWORK API SPECIFICATION
service billing
value-added service delivery
service billing
solution provider
service delivery
service billing
service delivery
consumer
operator
Fig 3
Service delivery involving the network operator and a third-party provider.
specific needs of different people and organisations. There are a large number of accounting and billing options afforded by this model and the market will determine which of these succeed. eBusiness will have an important role in the realisation of these billing options, as it will offer very attractive and flexible ways of providing and processing both accounting and billing information. It is the aim of the Parlay specification to enable this variety rather than preclude it. 4.
The Parlay Group and API specification
T
he Parlay Group was formed in April 1998 to produce an API specification that would provide solution providers with access to network information and a range of network controls [1]. The Parlay Group that generated the phase one specification comprised BT, Microsoft, Nortel Networks, Siemens, and Ulticom. The plans of the group were outlined in May 1998 [2] and in December 1998 [3] the Group published the first version of the specification, primarily addressing call control, messaging, and security. Public demonstrations were also given of a hypothetical ‘guaranteed call delivery’ application based on the specification [4]. This PC application illustrated how an enterprise, operating and trading outside the network operator’s domain, could offer a solution to end customers by employing some of the key capabilities available from the first Parlay API specification. An expanded Parlay Group and work programme for phase 2 [5] was announced in June 1999 with additional members — AT&T, Cegetel, Cisco Systems, Ericsson, IBM, and Lucent Technologies. The phase 2 programme
was 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 was to facilitate the convergence of wireless, wireline, and IP networks. 4.1
The Parlay API specification
The Parlay API specification is intended to be open and technology-independent, so that the widest possible range of organisations may develop advanced telecommunications solutions. The API is intended to be simple to use and extensible, so that it can be applied across different types of network and service. The main specification is defined in the technology-independent Unified Modelling Language (UML) [6]. However, while keeping the network API technology independent, implementation issues that could have an impact upon the realisation of the API must be taken into account. The API could be deployed using distributed object technologies such as Microsoft DCOM, OMG CORBA or Sun Java. To date the Parlay group has also generated, from the main UML specification, technology-dependent IDL specifications in Microsoft IDL and OMG CORBA IDL. The complete set of documents that defines the Parlay Version 2.0 specification is available from the Parlay Web site [1]. 4.2
Parlay API design goals
The top-level requirements, both functional and nonfunctional, expected of an implementation of the Parlay API have already been outlined. Some of the more important aims are expanded upon here.
•
Programming interface, not wire-protocol For reasons of ensuring interoperability, telecommunications standards bodies have normally focused on protocols rather than APIs. Since it was the main aim of the Parlay Group to encourage application development, the focus was placed on an attractive API. It is expected that the solutions market will ultimately choose which underlying protocol-stack standards should be deployed to support the API and its future extensions.
•
Security Unless both service providers and network operators are convinced that the security of their respective domains is maintained, the API will never be adopted. While end-to-end security is a characteristic of a whole system and not just the API, the design of the API is intended to ensure it is not a weak link in the standard ‘security-in-depth’ approach. BT Technol J Vol 18 No 2 April 2000
59
PARLAY NETWORK API SPECIFICATION
•
Multimedia The API will support services with different media types not just telephony, which is important as the world embraces multimedia networks, service and terminal diversity.
•
Simplicity Programmers must find the API easy to use to lower software vendors’ entry costs for training and development. For this reason the design is object oriented, a well-proven approach to specifying APIs.
•
Extensibility 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. A key part of this is the support of service discovery, a mechanism that enables an application to request an abstract service capability and leave the gateway to locate appropriate interface implementations.
•
Network independence Enterprise applications should operate across multiple network technologies and different network operators to maximise the market available from each application implementation.
4.3
•
Framework interfaces
Manageability Network operators of the API will need the ability to manage the operation and provision of the API implementations with high availability on public-scale networks.
•
set of interfaces which are supported either by the application or the gateway. The service interfaces provide the core functionality useful to enterprise applications.
These provide the supporting capabilities on the application and gateway necessary for the service interfaces to be secure, resilient, located and managed. The framework interfaces have no real value in isolation, their existence is to ensure that the API services can be used in an extensible and robust way. Examples of the functionality provided by the framework and services in the Parlay Specification version 2.0 are shown in Table 1. Table 1
Functionality supported in Parlay Specification 2.0.
Framework interface categories
Enables the application to contact the framework, mutually authenticate and sign for use of services.
Discovery
Supports property qualified searches for services available to the application.
Event notification
Allows asynchronous event passing between application and gateway.
Integrity management — load management — fault management — operation and maintenance
Various basic functions to monitor and control the operations of the gateway and application and assist recovery from faults.
Subscription management
Allows enterprise applications to explicitly subscribe to new services and make them available for use.
Design of the Parlay API Service interface categories
In the Parlay specification the two sides of the API are referred to as the application (which embodies the service logic in the enterprise) and the gateway (which implements the interfaces giving access to the operator’s network capabilities). The bi-directional nature of the interactions obviously means that the API describes interfaces that the application expects to find on the gateway and interfaces the gateway expects to find on the application. The goal of the API is to support an extensible range of independent services that can be used as building blocks for imaginative solutions — this is reflected in the specification that distinguishes between two categories of interface.
•
60
Service interfaces These support the use of a range of network capabilities and information in a way that minimises dependencies or coupling between the services. At a detailed technical level each meaningful service capability, e.g. simple call control, comprises a small
BT Technol J Vol 18 No 2 April 2000
Functionality
Trust and security — authentication — service access
Functionality
Call control service — simple call control — multimedia — conferencing
This has tiered capabilities from very basic call control to multiparty multimedia so that applications use only the appropriate complexity.
User interaction service
Used in conjunction with call control, this enables applications to control interactive voice systems, specify prompts, and collect user input.
Messaging service
Capabilities to send, retrieve, and store messages.
Connectivity Manager
Enables applications to provision QoS-specified pipes across IP networks
Mobility Services
Location information for fixed, mobile and IP networks and terminal status.
For a comprehensive explanation of each of these capabilities see the Parlay Web site [1].
PARLAY NETWORK API SPECIFICATION The architecture of the Parlay API is illustrated in Fig 4, where the relationship between applications, the framework and service interfaces, resource interfaces and network equipment is illustrated.
5.
application implementation framework interfaces
service interfaces
service interfaces
service interfaces
service interfaces
scope of Parlay specification
framework interfaces
network gateway implementation
resource interface
resource interface
resource interface
network resources
Fig 4
•
Parlay network API architecture.
Any implementation of the network gateway interfaces will need to interact with network-based resources, through the resource interfaces illustrated in Fig 4. The resource interfaces provide a structured means to integrate network resources into the API implementation. Specific protocols or APIs that may already exist (such as H.323, INAP or CAMEL) can be ‘plugged in’ to this interface. This allows the Parlay API to be used in a wide variety of network situations, and avoids reinventing functionality that already exists. The choice and specification of the resource interfaces is outside the scope of the Parlay specification.
a reference or a software simulation of the gateway APIs for key technologies (e.g. DCOM, CORBA, and Java) that provides the expected behaviour of a real implementation as viewed from the application — the reference implementations can be used to aid and test application functionality,
Parlay API business benefits
T
he success of the Parlay API specification will be judged by the benefits to all stakeholders in the creation and delivery of value-added solutions. Without the commercial drive from an obvious ‘killer’ application, it is necessary to have a sufficient range of applications to generate the revenue commensurate with the network API investment. Lowering the cost and time needed to build new, secure services will reduce the entry barriers to solution providers. The Parlay API specification aims to offer network capabilities at a level of abstraction that allows application developers to easily add their value to a broad array of solutions. In particular, the approach facilitates independent capabilities (e.g. call control, mobile network functions, and Web services) to be combined creatively by enterprise, e.g. using a corporate personnel database to set up voice communications (e.g. over IP, PSTN, wireless) to mobile workers, based on their location, the staff rota, and the caller. The framework allows the service set to be augmented incrementally by adding new service interfaces or extensions to existing ones, without any impact upon existing functionality. In this way, investment in services is future proofed. The API allows either solution providers or network operators to change and upgrade their components independently, with the end user experiencing the benefits. Successful adoption and wide-scale deployment of the Parlay API will be achieved when the stakeholders can see their business benefits being satisfied in the ways outlined below.
•
Network operators’ perspective Operators should see whole market growth as new application-based solutions create an environment of mass-customisation of communications. Network traffic should increase and new revenue may arise from access charges to the network API capabilities. Good implementations of the API gateway will allow access to network capabilities and still maintain the security and integrity of the gateway and underlying networks, which is an essential requisite to protect existing investment.
The Parlay Group actively encourages the telecommunications and IT industries as a whole to design and implement the API. To assist with this, the Parlay Group Web site [1] supplies an open, licence-free publication of the specification defined in a technology- independent format (UML) and mappings to the technology-specific IDLs mentioned. The Group anticipates industry will generate:
•
a software developers’ kit (SDK), consisting of example code and supporting documentation, to assist applications developers to exploit the full capabilities of the API.
•
Solution providers’ perspective A major market opportunity will be created to offer new communications solutions using the API, without the need for capital expenditure on network equipment. Custom and niche solutions should have improved time BT Technol J Vol 18 No 2 April 2000
61
PARLAY NETWORK API SPECIFICATION to market and lower cost because the development process for traditional core-network applications is avoided. Solutions should be portable across implementations of the API using the same technologies to minimise deployment cost. Enterprises can retain control of dynamic, core business data, and decision making, without the need to disclose these to the network operator. Finally, new communications capabilities can be exploited as they become available through extensions to the network API and ‘solutionsready’ concepts become inherent in new network investments.
•
Application developers’ perspective A whole range of new business opportunities are created that were previously either not technically feasible (because the necessary functionality was not exposed from the network operator) or not financially feasible (because cost of integration by the network operator was a market barrier). Development can exploit a common framework that is ideally positioned to integrate proprietary or organisationally specific technology with functionality offered by Parlay API service interfaces. Other market opportunities follow for SDKs and other necessary tools, documentation, product support, and training to assist software manufacture.
•
End users’ perspective The most notable advantage of API-enabled networks should be choice of communications solutions, available from a wide range of providers with competitive conditions. A rich variety of applications should become affordable bringing mass-customisation to end users, enabling them to find solutions that meet their personal and business needs.
6.
Application example using the Parlay API
T
his section illustrates how the Parlay API specification might be used in a business scenario in a way that integrates the data and decision making within the enterprise with the network capabilities offered by the API. The fictitious company, ZippyRepair, offers a product support service for its customers. The system configuration that ZippyRepair has commissioned from an independent software house is shown in Fig 5 and comprises a workflow engine that integrates a fault-logging system, homebased diagnostic experts, and mobile repair fleet. 6.1
A business scenario A typical workflow for the support service is given here.
A customer phones the 0800 support line and the call control API sends a message to the application identifying
home-based experts
voice/ data
voice/ data
work flow application IP data
diagnostic
home agents
mobile repair
voice network
connectivity
customer
mobility voice mail
messaging
Parlay API
staff rota data
call control
IP data IVR product voice/ data
mobile technician
62
staff skills data
Fig 5
BT Technol J Vol 18 No 2 April 2000
Application example of a product support enterprise using the Parlay API.
customer data
PARLAY NETWORK API SPECIFICATION the calling line identity (CLI). If the CLI is not recognised as belonging to a customer, the application instructs the call control API to route the call to an interactive voice response (IVR) system. The prompts played to the customer and the responses are all passed across the user interaction Parlay API. When the customer and site location are recognised the application uses its customer database to ascertain the product type and the level of service for which the customer has paid. For example, this is used to determine whether a night-time call is handled immediately, by an agent, or simply logged until the following morning. Supposing the service call is to be dealt with immediately, the application would now release the IVR and route the call using the call control API to an available agent qualified for the particular product. The agent takes the customer through a basic diagnosis system and logs the report into ZippyRepair’s work-flow databases. After the completion of the reporting and diagnosis phase, the work-flow engine now identifies an appropriate mobile repair technician to send to the customer site. The application uses the mobile networks API to ascertain the location of its field repair technicians and using Zippy Repair’s technician database identifies the nearest suitably qualified technician and estimates the completion time of the technician’s current job. The estimated arrival time and the technician’s name are screen popped to the home-based agent and is reported to the customer who then waits confidently for the repair to take place. Behind the scenes the work-flow system will then call the mobile technician and download the fault report on to the technician’s mobileenabled portable computer. Additionally, when technicians and home-based experts need to communicate with each other, they will use the company’s internal non-geographic numbers that will trigger through the call control API to the work-flow application. The staff can choose a variety of alternative call-handling procedures that they configure in the staff database using intranet Web servers. Typically, employees want calls they cannot answer to be diverted by the workflow application to their voicemail system. Whenever the caller leaves a message, the messaging API will alert the application that may, for example, instruct the messaging API to send an alerting e-mail to the staff member. Furthermore, because of the distributed nature of the enterprise, ZippyRepair regularly needs to schedule training events and meetings using high-quality IP-based multimedia conferencing. The conferencing and training application uses the connectivity manager API to schedule guaranteed QoS pipes between the distributed offices for the duration of the high-bandwidth, real-time conferences.
6.2
Benefits of the API in the example scenario
Although obviously a fictitious example, the intention is to show how different capabilities of the API can be used to create a solution to an overall business problem. From the enterprise’s perspective, its prosperity comes from making optimal operational decisions about customers, products, staff and resources using dynamic information it should exclusively own. The API has enabled the enterprise solution to govern the way telecommunications services are operated, whereas without the API these services are more likely to restrict the way the enterprise is operated. Use of the API therefore has these key benefits:
•
the breadth of the Parlay API specification allows appropriate network capabilities to be integrated to deliver a complete service — the nature of that integration is determined by the application designer, not by the limitations to network control offered by the network operator,
•
solution logic and the dynamic data upon which it is based, resides exclusively with the enterprise and does not have to be shared with the network operator,
•
the enterprise can change its application work-flow logic at any time without the network operator being involved,
•
the enterprise has minimal investment in the network equipment used to deliver the telecommunications services since this remains under the care of the network operator.
7.
Conclusions
T
he focus of the Parlay Group is to produce an API specification that enables enterprises outside the network operators’ domain to access network information and control a range of network capabilities. It is believed that there is a tremendous growth opportunity for network operators, solution providers and application developers by the adoption of the Parlay API. Customers will benefit because their business needs will be met more cost effectively and more quickly using the Parlay API capabilities. In summary the major goals of the Parlay Group are to:
•
define an API specification that provides application developers with a consistent, network-independent view of functionality they can employ, BT Technol J Vol 18 No 2 April 2000
63
PARLAY NETWORK API SPECIFICATION
• • •
•
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 IT and telecommunications industries to implement and globally deploy the Parlay API specification, work with the IT industry to encourage the production of software development resources to aid the creation of applications that exploit the Parlay API specification, liberate software developers and solution providers to do what they do best — creating new and innovative applications that solve customer needs because the use of telecommunications is simplified through the API.
References 1
Parlay: ‘API specification 2.0 — core specification document’, www.parlay.org
2
Parlay Group Press Release — www.parlay.org (May 1998).
3
Parlay Group Press Release — www.parlay.org (December 1998).
4
Guaranteed Call Delivery Demonstration — www.parlay.org (1998).
5
Parlay Group Press Release — www.parlay.org (June 1999).
6
UML version 1.1 — OMG standard (November 1997).
64 BT Technol J Vol 18 No 2 April 2000
Martin Yates leads a group within BT’s Advanced Communication Research, Adastral Park, researching open interfaces next-generation IP-based service platforms and application service provision. He has been involved in the Parlay Group since its formation in 1998. Previously in BT he has worked on various distributed systems projects to prototype application and servicehosting platforms with open interfaces. This included secondment to lead the servicearchitecture team for the USA-based Telecommunications Information Networking Architecture Consortium (TINA-C), an industry collaboration to create experimental standards for open service architectures. In 1997 he won the Alan Rudge Award for Innovation. He joined BT research 12 years ago working on optical network technology. He holds a Physics BSc and PhD from Birmingham University.
Dr Ivan Boyd is manager of the Programmable Networks Laboratory within BT’s Advanced Communications Research at Adastral Park. He pursues a number of research areas including next generation middleware, application layer active networks, client-based middleware, next generation ASPs, and application programming interfaces (APIs), in particular the Parlay API. He is an elected Board member of the Parlay Group. Prior to joining ACR, he won a BT gold award in 1994 for the development and delivery of the Skyphone speech codec, and worked for Internet and Multimedia Applications where he was responsible for the technical delivery of many of BT’s initial set of Internet applications. He has been with BT for 14 years.
