Service-Oriented Architectures for Telecom

Everyone is talking about Service-Oriented Architectures (SOAs) these days, though many people, 1) don’t know exactly what they are (which is not surprising, since they have a rather generalized nature about them) and 2) might be confused as to how they can be applied to telecom.

The SOA concept is essentially quite simple. Imagine a service consumer and a service provider. The consumer sends a service request message to the provider, which returns a response message to the consumer. Both messages are defined in a standard way so that everybody knows what’s being requested and provided. Fulfilling the request can cause a change in state in the consumer, the provider, or both.

One analogy would be a restaurant, which offers a food-providing service that causes state changes in both the consumer — who’s no longer hungry — and the restaurant, which just pocketed some of the consumer’s money. Using the restaurant’s food service is less expensive and more effective (better tasting food, hopefully) than if you prepared the food yourself (this is, of course, not the case at most college dining halls!). The service is a well-defined, self-contained function, and does not depend on the context or state of other services. The restaurant itself is also a consumer of services, since it doesn’t grow its own vegetables or generate its own electricity.

In the computer and telecom worlds, a service-oriented architecture is a collection of software-based services, some of which may communicate with each other to coordinate work on complicated services. Services tend to be “loosely coupled” unlike the tight binding of data or processing found in object-oriented programming (OOP).

In the case of IP Communications and the Internet, the connections in this SOA are Web Services, most of which employ XML (the eXtended Markup Language) for standard connection purposes. When you buy something off of a website, the owners of the site are using a credit card service to process your order, not totally original code, which would take too long to write and debug. Microsoft’s not-so-successful Passport service is another example. It could be called upon by outside services to provide user authentication when and where that function was needed. All sorts of self-contained functions can be published and invoked across the web by other applications and other web services.

The original, basic Web Services platform is a combination of XML and HTTP. Later such things as XLANG and XAML appeared, which enables complex web transactions among and between multiple web services.

SOAs are now becoming real. Elements (e.g. call setup, presence) of IP Communications are being connected to business applications via a Web Services model. In 2006, Oracle debuted their Oracle Service Delivery Platform (SDP), designed in part to help carriers, network operators and systems integrators move to SOAs.

BlueNote Networks (www.bluenotenetworks.com), a provider of BCPs (Business Communications Platforms) for real-time voice and video communications to perform services in a Service Oriented Architecture (SOA) environment, recently announced that Boston’s deluxe Seaport Hotel and Exhibition Center is using BlueNote’s SessionSuite SOA Edition software for their “Seaportal”, an in-room web portal for guests.

BlueNote’s Mark Ericson, Director of Product Strategy, says, “I’ve spent over six years working with Web Services and service-oriented architecture. I joined BlueNote last year with a great deal of interest in what the company is doing in terms of bringing human, interactive communications into an SOA. Often you hear that SOA is a new way of providing applications integration in a way that is standards-based and open. We also see it as providing a new way of adding human communications and collaboration into applications and business processes. That’s also facilitated by the open common infrastructure that a service-oriented architecture provides.”

Ericson elaborates: “We’re introducing, for example, voice as a service into an SOA. People like to tout the many benefits of an SOA. You’ll hear about business agility, reuse, open standards and interoperability. We find that you can achieve in the voice world with an SOA some of the same benefits that an SOA offers an IT department regarding applications. An SOA can offer those same benefits to voice and interactive communications by, for example, building voice services that can then be reused and shared across multiple applications within an organization. It follows the same ‘standard’ SOA model.”

Ericson alludes to the fact that “SOA” is a huge, sprawling, loose term. It’s not a specific technology; it’s all kinds of things. It reminds me of my programming days, when one called a subprogram or function from a library of reusable code. You “tell it” what you want to do, it does it, and you don’t necessarily know how it does it.

“You’re right in that SOA means different things to different people,” says Ericson. “I think that first and foremost the right way to look at service-oriented architecture is as an architectural or philosophical approach for building applications and not necessarily specific technologies. When you talk to some companies, they’ll tell you that SOA to them means that you purchase an ESB, you have XML firewalls, you have management monitoring appliances, and that’s what it means to have an SOA. They couple it to technology.”

“But SOA is really more of a philosophy,” says Ericson, “a way of building applications and solutions that are built up of multiple cooperating or reusable services to compose new applications. In some sense, the underlying technology is moot, except for the enablement of SOA through the Web Services and XML standards. They actually enable the possibility of interoperability and mixing-and-matching these service components from various vendors.”

Ericson continues: “We don’t have what you could call an SOA infrastructure, if you will, that provides the platform on which to deploy and run services. Instead, what we have is Internet telephony capabilities. Our product, SessionSuite SOA Edition, has fully-functioning Internet telephony capabilities, but it fits within an SOA by exposing Web Service APIs that can be leveraged to add voice capabilities to applications. Essentially, it fits in an SOA as an additional service — both as a producer and consumer of services within that environment. Organizations can now add voice and the ability to handle human interactions to their business processes, and leverage their existing investment in Web Services and SOA tools to do that. For example, right now I’m talking to you through our software. We don’t have a PBX; we use our own software to provide the telephony solution for our company.”

“In the BPM [Business Process Management] world, there’s certainly a move towards using service-oriented architectures,” says Ericson. “When some kind of human interaction is necessary, that process in terms of BPM is suspended and there’s no modeling or automating of the human interaction going on at that point. It would really be a mistake to not also automate that human interaction, and that’s one of the things we wanted enabled through both a BPM and automation.”

“We did a Webinar recently that explained how you can add voice to a business process,” says Ericson, “which in this particular case is a supply chain application. In the scenario, there were multiple points in the process where there was an exception, so that the process had to halt until some humans could interact and resolve that issue. Sometimes when there’s an exception like that, what happens is that it gets logged and then it gets reconciled later, so it blocks the actual business process. It’s a real loss of revenue for a company when these business processes stop or are delayed until humans can resolve the backlog of exceptions. Thus, by incorporating the automation of getting the right people together on the phone at the proper time to interact and make that itself part of the business process and integrate it all though an SOA, those delays are eliminated and the exceptions are dramatically reduced.”

“In the traditional case with BPM,” says Ericson, “an exception occurs and people interact and resolve it in an ‘out-of-band’ manner, and there’s no ‘knowledge’ of that within the process of what occurred, who communicated, and how they resolved it. By bringing in that human interaction aspect and automating everything through the business process, you now have resolved the issue ‘in-band’ and you now know how it got resolved and who was involved in resolving it.”

Yours Truly brought up the matter with Ericson about SOAs generality. After all, when you have a hammer, everything looks like a nail.

“Certainly there was a time when SOA was looked upon as being a lot of hype,” replies Ericson. “But we’re now seeing people building real solutions and realizing some of its benefits. When people build new solutions with an SOA, they can call upon a what’s essentially a library of pre-built services that they can reuse. Rather than implementing something from scratch, they can assemble or orchestrate those services and perhaps build new solutions. For us, adding voice into that library of services is quite doable and people can start to find opportunities to incorporate voice into a solution and solve real business problems right away.”

Service-oriented architectures sound almost too good to be true. Even so, like its predecessor, object-oriented programming, SOAs will mature in the telecom world and will be called upon to quickly and cost-effectively assemble new services in a modular, “erector set” manner. That’s a definite ‘plus’ as the world continues to move toward adopting a multiple-service-friendly communications network based on IMS (IP Multimedia Subsystem).

Richard “Zippy” Grigonis is Executive Editor of TMC’s IP Communications Group.