• E-mail
• Print
• Comment
• Font Size
• Digg
• del.icio.us
• Discuss article

Is There A Place For Voice And Video In Service Oriented Architectures?

Posted on: Thursday, 16 February 2006, 09:00 CST

By Silver, Brian

Get ready for a fresh way of thinking about voice and video-as services rather than systems.

Service oriented architectures (SOAs) are all the rage-at least conceptually. Enterprises are attracted to the idea that SOAs can improve business process and workflow control, as well as the flexibility and cost efficiencies that SOAs promise. While most enterprises have some distributed systems that could become part of an SOA in the future, few have the high-level mandate or the experience to develop and deploy an enterprise-wide SOA at scale.

Moreover, SOAs to date have been considered almost exclusively in the realm of data applications and data networks. This seems ironic in an era that is otherwise so focused on application and transport "convergence" of voice, data and video.

This article argues that voice and video communications ought to be integrated into the enterprise's plans for its emerging SOA. Voice and video calls are relatively simple services, and if they are part of the SOA they can be readily leveraged by other applications. Making the telecommunication system itself a user and provider of services-that is, both a subscriber and a publisher, in the SOA parlance-is a better way to achieve this integration than simply interfacing the voice and video systems to the data SOA via application program interfaces (APIs).

SOA Basics

In a service-oriented architecture, the information systems are designed such that their elements can offer assistance to other elements. The efficiencies, flexible deployment options and cost reductions enabled by using a services paradigm are the goals of all SOAs, be they based on the Simple Object Access Protocol (SOAP), a Representational State Transfer (REST) architecture, Enterprise Service Bus technology (ESB) or any combination of these.

Credit card processing is a commonly cited SOA example: An application that needs to process credit cards in an SOA simply asks a credit card processing service to do the work on its behalf. Rather than agreeing to the details of the operation beforehand (known as "tight coupling"), the two applications (as part of a "distributed system") exchange the necessary information at the time of the request. In this case, the one application knows the other is a credit card processing service, and learns how to make the processing request as part of the transaction. In SOA-speak, they are "loosely coupled."

The efficiency and flexibility of SOAs comes from the fact that operations are implemented at the service level-e.g., "I need a credit card processed." The static, hard-to-change parts of the application-the detailed levels of semantics and syntax-are abstracted by the architecture and the protocols used to implement it. This makes it easier to change providers of the service, since the detailed aspects of the requested transaction are communicated as part of the transaction itself.

Telephone calls are services we use every day. Placing a "call" is the same as asking the telephone system to do work on our behalf. We enter the phone number and expect the system to handle the rest of the process. If we need to be connected to voice mail, or if we are joining a conference call, or if we hear music played to us while we are on hold, we are subject to the operations of the service that is the telephone system.

Most importantly, the interface to the service is the same regardless of the provider of the service: You dial the phone the same way at home and at work. Your cell phone allows you to place calls, check your voice mail and forward your calls just like your desk phone, although the underlying technologies that implement the service can be vastly different.

If we want to include telephony as a service in a larger SOA, the question becomes, "How can I enable the telephone system to offer assistance to other applications in the SOA?" Approached in this way, it seems like an obvious question-yet this is not how traditional PBX systems integrate with other applications in the enterprise.

From Phone-Centric To Service-Centric

Historically, each PBX has had its own APIs, and any applications that wanted to integrate had to be written for these particular interfaces and system. They often had to have knowledge of the interworkings of call-control and signaling systems. This integration model was closed, proprietary and often complex and expensive. It was not application-centric, but phone-centric.

While this model was arguably sufficient in the early days of computer telephony integration (CTI) 15-20 years ago, it certainly is not appropriate today, when the enterprise focus clearly is on the desktop, the datacenter and IP applications.

A better model would not require so much detailed integration. Instead, it would follow the service model, which is the way in which we commonly use phone services today: Dial the number and the service does whatever is needed to accomplish the request, whether that is placing the call, accessing voice mail or joining a conference call. In other words, the service is operationally opaque from the point of view of the application requesting the service. (If the application cares, such as for the time and charges information on a call, it can request the appropriate level of detail.)

We are starting to see the emergence of service-oriented APIs from a small, but growing number of vendors, including Microsoft and Avaya. Examples include Avaya's PBX API, which wraps the PBX in SOAP technology, as well as Microsoft's systems-oriented approach with Live Communication Server and the .NET environment. Such technologies promise service-oriented (specifically Web Services) interfaces for communication-intensive workflows, such as training applications, customer support and relationship management, as well as enterprise resource and planning applications (ERP).

While this is necessary, it is not sufficient. To truly leverage next-generation voice and video and create more efficient and productive telecommunications networks, external services also need to be incorporated into the enterprise SOA.

This is what service-oriented architectures are all about: building complex solutions by leveraging external services to create something that would not be economical without the external service. The public switched telephone network (PSTN), with its reliance on multiple directory and operator services, database, call routing and wholesale services, is itself a perfect example of why and how this works (see "The PSTN Is An SOA").

Creating An SOA With Interactive Services

Although the PSTN is an SOA, traditional carriers do not yet think in terms of making PSTN services available so that they can be leveraged as part of an enterprise SOA. In contrast, services from some of the emerging IP-based services providers (such as those offered by Verisign, NeuStar and NetGeo) are much more interesting.

For example, NetGeo's IP service could be used to create an application that enables least-cost PSTN and IP call routing plans based on geographical information. Likewise, Internet-based local weather forecasting information (e.g., from nws.noaa.gov, weather.com, etc.) could be incorporated into telephone call policy control to reroute calls away from call centers which might not be fully staffed due to inclement weather. In both of these examples, the SOA architecture controls the telecommunications infrastructure and the IT application writer has full control of the underlying infrastructure and services.

Conceptually, there is no difference between leveraging these Internet and IP-based services and leveraging a long-distance carrier. That means the enterprise "phone person," with his/her PSTN- carrier-interconnect experience, is the natural choice to manage the evolution of these services as both the enterprise and the carriers develop more flexible and complete instantiations of SOAs, including their ability to flexibly switch among multiple service providers.

As this unfolds, however, several sets of issues will arise. First, of course will be the overall consideration of how applications will make use of the voice and video services. This will, in turn, drive requirements for services that the voice and video services themselves may leverage.

Considering which applications will want voice and video service means adopting a new viewpoint: That talking, listening and seeing are features of the applications themselves. Presence and directory policies also must be considered, since applications can have access to these as well. Once these issues are settled, the desired voice and video services can be "published" into the SOA-that is, made available via a service-oriented interface from either internal or external system and service resources.

For example, applications could use dialing information (in the form of the phone number) to ask for the service of placing a call. The service itself-whether it is ultimately provided by the internal PBX or leveraged from a PSTN-based Centrex-type offering-would handle all the details from that point on.

Applications like voice-response-units (VRUs) and automatic-call- distribution systems (ACDs) that need deeper knowledge and interoperability with the telephony system or service would mak\e these needs part of their requests for service. There is no technical reason why these functions cannot be offered in a service- oriented manner.

Voice And Video Underscore Basic SOA Requirements

As is the case with other services in the SOA, IT must deal with identity management, service provisioning and monitoring of voice and video services, as well as with the specific, real-time network needs of voice and video traffic.

Identity management means that service requests must be authorized and authenticated at each corporate (or other security domain) boundary. Some SOA architectures account for identity management; for example, Web Services has WS-Federation, WS- Security and WS-Trust. There is no explicit statement in these standards that they apply to telecommunications-nor need there be, because telecommunications is no different from other applications or services in the enterprise, other than having a requirement for real-time network services.

Identity management issues were never faced in the PSTN, because identities are maintained in the network: A real or virtual circuit connects the endpoints on a leased line and the calling and called parties on a call. When these functions are delivered as VOIP or are reachable from other IP applications, however, the user's identity must be repeatedly confirmed throughout the ad hoc combination of services that are encountered in satisfying the user's request.

Service provisioning and management also can present problems to an enterprise that tries to incorporate voice and video in their SOA. By definition, SOA architectures are loosely coupled, and that means service provisioning takes place in a loosely coupled manner. Since peered (or federated) service environments do not have a central authority to broker the set-up and resource allocation of leveraged services, the interconnecting enterprises themselves must commit resources during the provisioning process and manage those resources. Today this is a manual and static process, which can be expensive and inefficient.

Consider an enterprise extranet. There's no conceptual reason why voice and video between partners can't be carried over that same extranet, eliminating some of the costs and complexity associated with separate voice and data nets.

Without a carrier as the middleman, enterprise partners could form a team to use SOA standards such as the Service Provisioning Markup Language (SPML) and the WS-Provisioning standard to provision the service, handle alarms, verify connectivity and troubleshoot complaints, without exposing security holes or imposing architectural constraints on one another. The SOA's higher-level representations would allow the integrated provisioning process to rely less on the physical make-up of the network and focus on the services.

Focusing on services rather than the physical infrastructure doesn't mean that physical attributes lose their importance, only that they are abstracted-for example, with respect to their transport mechanisms (IP or TDM) and the enterprise's geography (Centrex or PBX, branch-office or datacenter). Such abstraction keeps the service definition intact within the overall architecture and solution set, while letting the enterprise flexibly choose service providers, transport mechanisms, long-distance providers, naming and numbering solutions and directory infrastructures. Having more choices, and not having to change the SOA to accommodate changes in the enterprise operation, reduces cost and dependencies, and increases productivity.

Although SOA's characteristic abstractions can greatly simplify application development, they also can hide important details, and enterprises need to be on the lookout for visibility problems that can result. For example, when enterprises first started deploying applications that use XML as a replacement for legacy protocols they were surprised to find their network utilization substantially increased.

As the IT manager creates network and application topologies, the real-time needs of services like voice and video must be balanced against the generic data abstractions of an SOA. Adding application- specific elements like voice codec manipulation and call admission control services can improve the ability to manage the network, as well as the user's experience when placing calls using applications in the SOA.

Conclusion

Making the PBX reachable by SOAP applications is only a step, albeit an important one, in the direction of making the telecommunications system both a publisher of and subscriber to services in the larger enterprise infrastructure. While challenges remain, and the architecture chosen by the enterprise must take into account issues that arise because of the addition of real-time applications into the SOA, enterprises that leverage services stand to gain economic and deployment advantages that are simply not available from traditional PBX/mainframe architectures

The PSTN Is An SOA

Enterprises already use the PSTN as they would any external service in a service oriented architecture (SOA). In addition, the PSTN providers themselves leverage external services: Directory assistance and number portability can be outsourced; bandwidth can be wholesaled; long-distance minutes can traverse any number of provider networks.

In fact, the PSTN is perhaps the largest, most complex, and feature-rich SOA ever constructed, and it would seem to be a natural fit with the emerging focus in the enterprise on integrated applications. Yet carriers have been slow to embrace SOA interfaces as a means of revamping their enterprise services.

Rather than thinking in terms of replacing TDM services with VOIP or IP Centrex, the carriers ought to be thinking of offering transportagnostic, simple, callable, API-reachable services-such as provisioning, billing reconciliation, alarm management, call routing, call feature configuration, voice mail retrieval, conference calling and simple call setup and teardown-that enterprises could leverage in their own applications and as part of their own integrated SOAs.

If the carriers were to offer such simple, flexible services, in a way that also enables enterprises to migrate gradually from their installed base of equipment, many enterprises would be hard-pressed to justify the operational and capital costs of their PBXs much longer.

Nor have traditional enterprise software and voice vendors seen the SOA light. Some may ask why voice and video capabilities and systems are absent from the standards discussions surrounding SOAs, but the more appropriate question is "Why should they be singled out for discussion?" The email and print-server communities aren't running around as if standards bodies need to cater to their needs- the real-time communication folks shouldn't need special handling either.

Here's the bottom line: There's nothing inherently special about voice and video that dictates they be treated any differently than other real-time data transmissions. The SOA standards discussions do not explicitly include voice and video, but by not excluding those services, they put them in their true place beside other data applications. And the effect of this is that all SOA standards apply to voice and video as well as to data services

Neither the PSTN providers nor the PBX vendors have seen the SOA light

Identity management wasn't an issue in the PSTN, but it must be confronted throughout the ad hoc combination of services that satisfy user requests in SOAs

Companies Mentioned In This Article

Avaya (www.avaya.com)

Microsoft (www.microsoft.com)

NetGeo (www.netgeo.com)

NeuStar (www.neustar.biz)

Verisign (www.verisign.com)

Data extranets could support voice and video, if the business partners would cooperate and use SOA and WS standards

Brian Silver is chief technology officer with BlueNote Networks, specializing in enterprise voice and multimedia software platforms, applications, tools and Web service interfaces. He can be reached at bsilver@bluenotenetworks.com.

Copyright Business Communications Review Feb 2006

Source: Business Communications Review

More News in this Category