Why SOA and VoIP will converge

A dozen years ago, I wrote a Byte cover story on the subject of computer-telephony integration. CTI was “right around the corner” back then. Every time I revisit the subject I conclude that, regrettably, it still is.

Voice and data networking remain two different cultures that have so far failed spectacularly to come together. But I’m stubbornly optimistic that, sooner or later, they will. There are too many opportunities to ignore, and those opportunities multiply as service orientation takes hold.

Consider a business process that’s been automated, SOA-style. A BPEL (Business Process Execution Language) script orchestrates the flow of XML payloads through a sequence of steps, untouched by human hands, until an exception occurs. In all such workflows, people are the exception handlers of last resort.

How does the process that raised the exception kick off a meeting between the requester of a purchase order and its approver? Today the most likely method would be to set up a call in a conference bridge and then e-mail invitations to the two parties. But although computers are supposed to be our intelligent assistants, an intelligent human assistant would set up the conference call between the parties.

According to Mark Ericson, director of SOA product strategy at BlueNote Networks, whom I interviewed for last week’s podcast, setting up that call in response to a BPEL exception is exactly the kind of thing that BlueNote’s SessionSuite SOA Edition is designed to do.

What’s intriguing about this scenario is that, as with Amazon’s Mechanical Turk, it enables a software-based service to call on the services of humans. In the case of MTurk, an application creates a HIT (human intelligence task) that a human worker accepts, performs, and submits. To the application, this just looks like an asynchronous request. It polls for a response or arranges to be notified in an event-driven manner, but in either case the service provided by the human looks no different to the application than would a service provided by another piece of software.

In a world where SOA and VoIP work hand in hand, more natural scenarios become possible. I have, for example, been dealing with a stalled purchase order of my own for several days. The business rule says that I have to contact two parties, who must in turn reach an agreement. But we’ve all been playing voice-mail or e-mail tag, and so far we haven’t managed to close the loop. It’s admittedly creepy to imagine empowering that business rule to detect our common availability, initiate a conference call, and receive a signal from us that tells it to proceed. But the alternative that we constantly endure is arguably worse.

BlueNote’s product can’t do all of this yet. Even if it could, VoIP infrastructure isn’t deployed widely enough and isn’t interoperable enough to make this kind of scenario routine. But the vision of a common framework for process-to-process, process-to-human, and human-to-human communication is compelling.

The genius of REST (Representational State Transfer) is that it’s a mode of communication equally accessible to programs and humans. To software, a URL is a method call. To a person, it’s a bookmark that can be saved, traded, and tagged. VoIP/SOA convergence aims for a similar kind of duality. Programs may not ever understand what we’re saying on the voice channel. But when voice and data share a common application context, our software agents will seem smarter and will be more helpful.