For all that is radically new about Internet telecom, it's hard to avoid a sense of dja vu in hearing its proponents talk about services. At one level, the vision of next-gen service creation intentionally calls upon a set of technological and financial models already established by the web. Among other things, this means adopting non-proprietary hardware and software platforms, lowering the technical bar to application development by employing less esoteric programming methods, and cultivating new markets through leverage of a more diverse set of business processes. But if the web can be referenced for the introduction, or at least the consolidation, of these core concepts, their application to telecom services intersects somewhat ironically with another technological vision - good old-fashioned computer telephony.
Long before the focus had shifted to voice-over-IP, it was one of the first principles of CT to separate telephony applications from the call control and signaling necessary to support them. Even the earliest efforts in this direction were based on the idea that voice services could be created faster, cheaper, and easier if programming were moved off of proprietary switch hardware and onto open, standard PC platforms. The open architecture IP softswitch model, therefore, is not the first to call for a division between media processing and call control, or to try to isolate application logic from the domain of call signaling. Likewise, the IP telephony community is not the first to suggest that the barrier to rapid development of voice applications is, in a sense, voice itself. To remove this stumbling block, the prevailing logic went (and goes), one must eliminate, or at least hide from view, aspects of application programming that are "telephony-specific," and expose only that which applies to general computing.
It is not surprising, given these assumptions, to find almost coincident with the first appearances of PC-based telephony systems, the release of the first application generators: script-based or graphical development tools that encapsulated chunks of call control code as objects or simple text commands. The idea was to let non-programmers, or computer programmers with no specific telephony expertise, quickly compose voice applications without worrying about how to drive the underlying hardware or processing software. At first, these products were aimed mainly at the creation or customization of interactive voice response (IVR) applications; but most app gens gradually widened in scope, encompassing everything from call centers to debit cards to the creation of full-scale PC PBXs.
App gens do not consist solely of higher order scripting languages or their associated graphical user interfaces. They also act at a lower level, typically hidden from the user, where they implement a multi-line call processing state engine and facilities for communicating with underlying hardware. As app gens themselves have evolved, along with the systems they were designed to control, this lower level functionality has become arguably more significant than the user interface it supports. Part of the reason for this is the simple proliferation of both proprietary and "standard" APIs at the call control and signaling layers, which makes it difficult for an application to achieve portability across disparate systems and networks without the supplement of an abstraction layer. Another aspect has to do with the rather tepid reaction of many real world developers to very high-level tools, which they often find limiting or inefficient.
Taken together, these concerns prompt the question of where, or at what level, a call itself can be usefully abstracted from the logic of an application designed to manipulate it in some way. This, in fact, could be considered the central question facing app gen vendors today, as well as their prospective customers. Bachir Halimi, co-president and CTO of Elix, a company formed from the merger of Mediasoft (Montreal, QC, Canada - 514-731-3838) and Prima (Nuns' Island, QC, Canada - 514-768-1000), situates the problem specifically in context of changes in the audience app gens are designed to serve.
"As the industry has matured," Halimi says, "the need for hand-holding developers has begun to fade away. When we started, almost ten years ago, CT application developers were very rare. They were not used to working in an environment where you have a call that is live during the whole time an application is running; so we needed to do a lot of hand-holding, and that's why we came up with very high-level, very easy-to-use tools. But today these developers are much more sophisticated. They want to go directly to the API, and integrate it themselves within their application... They don't want to use proprietary scripting languages, they want to use C++ and Java."
In accordance with these demands, Elix now supports both Java and C++, and plans to add VoiceXML as another scripting option, sitting side-by-side with its original, in-house developed scripting languages. At the same time, Halimi's focus seems to have shifted broadly from a concentration on tools to somewhat more abstract concerns. More than easy-to-use tools, Halimi suggests that what today's developers are looking for is a platform that can make sophisticated application logic more versatile and generalizable. The move to standard programming languages is one aspect of this project, but the manipulation and generalization of lower-level functions is just as important.
In this regard, the company's strategy is similar to that of "component frameworks" - object-oriented development environments that combine infrastructure elements with programming templates - being developed for e-commerce applications on the web. In the Elix model (see Figure 1), XML is used as a basis for defining object parameters, as well as for the glue between low-level APIs and the application logic, which itself consists of these variously assembled objects. On the basis of this type of framework, it is possible to conceive of whole generalized applications (a voicemail program, for example) being defined as a set of standard, portable objects, which could then be made available as resources to a more specific application that might need to employ them.
"Obviously, we have not abandoned the idea that you have to keep the interfaces to media resources and call control simple, or that you have to provide an environment for managing applications that call upon those resources. But now our focus is on a different set of needs: we need reusability of application code, we need interoperability of applications within the same environment, and we need portability of applications across environments. That's where we see the component framework idea as a paradigm shift within application development."
