October 2001

 
Jibe With Java: The New-Generation Telecom Service Creation Environments

BY TOM MCGUIRE

Bridging service creation in these parallel universes calls for a new generation of service creation environments (SCEs) that have the goal of providing rapid application-development environments in which developers can pick design methodology, and where reliable and sophisticated applications can be built with minimal effort.

A market consensus is fast emerging that the most versatile development kid on the block, capable of adequately serving these two networking masters, is the Java programming language as the basis for new-gen SCEs. In fact, with its appealing "write once-run anywhere" capability, Java readily meets the basic requirements for such new-gen SCEs for telecommunications services:

• Easy to use and capable of handling a large user base;
   
• Takes advantage of the latest software development concepts;
   
• Object-oriented with a standard methodology for creating software components;
   
• Currently in use to develop Web-based technologies;
   
• Has defined (or is defining) standard APIs to connect to other networks or network protocols, such as SS7, Megaco, or SIP;
   
• Allows developed applications to be ported to a wide variety of systems; and
   
• Provides a graphical-based programming environment to aid in using components and speed service development.

Historical Perspective
Designed by Sun Microsystems in 1991 as an interpreted language for generating applications able to run on all hardware platforms without modification, Java was initially developed for embedded applications such as set-top boxes. It was transitioned to the Web by 1994. Now it also is efficiently filling the bill as the latest tool in a long history of service creation application generators (AppGens) for the telecommunications/telephony field.

Historically, the purpose of telecom AppGens was to reduce programming drudgery by enabling developers to draw applications using common functions (such as playing a voice prompt or collecting DTMF digits) represented as graphical components. This was similar to digital electronics engineers using schematic-capture programs. The developer would connect components in the graphical environment, thus speeding up the development time and providing a visual representation of the program logic.

Earlier AppGens generated a proprietary scripting language which a corresponding run-time engine then interpreted. It worked, but suffered from performance problems. As a result, the output format of these AppGens was changed to produce a jump table. This method stripped out character strings and replaced them with jump-table references, allowing the run-time environment to look up a function call in a function table. While performance improved, the output of the AppGens became unintelligible.

So telecom AppGens developers embraced the then new kid on the block, Visual Basic (VB), a development environment that was used for actual development and generated real code that could then be further modified. Unfortunately, it collared the developer to a specific hardware platform. These environments also found developers hitting "the wall" when they needed more than the library of components could provide, and adding new functionality was so cumbersome that it often was easier to revert to writing code by hand than use the graphical environment.

Telecom Demands
The ever-changing world of telecommunications equipment has spawned a plethora of operating environments, from RTOSs to full-blown operating systems such as Solaris. Any service-creation AppGen, therefore, must allow for rapid application development as well as have the ability to run on a wide variety of hardware and operating systems. Java has become the premier way to provide a needed "write once-run anywhere" environment. Because Java is transportable across multiple platforms and operating systems, a developer can be reasonably assured that changing hardware environments will not compromise their run-time environment.

Using Java as the foundation of a next-generation execution environment means developers can take advantage of what Java affords. Unlike other languages such as its progenitor C/C++, for example, Java eases the burden of developing applications by using tools such as its often-maligned Garbage Collection feature.

C++ developers can spend weeks working an application�s memory-management infrastructure. Even learning the in-house memory management application programming interfaces (APIs) and using them correctly can be time consuming. With Java, developers can let references go out of scope and simply allow the underlying JVM to garbage collect the unused references.

Standard APIs
Standard frameworks and design patterns are essential for developing flexible, portable applications, and Java makes an extensive array of both available as openly defined libraries. The Java Media Framework (JMF), for instance, is an extensible API for dealing with playing and recording sound files. The JMF can be extended to abstract most integrated voice response functions found in telecom applications.

JMF plays a central role, for example, in many of the voice-over-IP scenarios. This is due in part to the ease of programming, but also because Realtime Transport Protocol (RTP) is provided in the reference implementation of JMF. While RTP tools are freely available for C++ users, there are no standard APIs defined, which makes providing a solution far more difficult.

In fact, there are Java APIs defined for almost every conceivable facet of software development. Most are covered under the Java Community Process, an open development site maintained by Sun with a process defined for introducing new APIs into the Java language. This is where the JAIN initiative (Java APIs for Integrated Networks) defines APIs for many of the converged network protocols in use today. The SS7 ISUP and TCAP JAIN specifications, for instance, are available to the public, with others in the early stages of definition.

As the new standards are made public and gain wide usage, they will provide the foundation for creating services that span multiple networks. Again, the goal for the new-generation SCEs is to create a rapid application development in which reliable applications can be built with minimal effort on the part of the developer. Java is the one environment that delivers all the necessary components.

Java Fits
Telecom services are event driven at their core. Java, as an object-oriented language, is predisposed to handling events in an intuitive manner. JavaBeans, the standard component specification for Java, defines a standard way to relate events to method or function calls. JavaBeans help encapsulate the run-time functionality into a set of easily understood components (beans) which naturally enforce code reuse by programming teams. The software engineering principle of "reuse" is the key to expediting the development process, and JavaBeans fully support this principle.

What Should The Service Creation Environment Look Like?
A standard "Commercial Off The Shelf Java Integrated Development Environment" is a big revelation and a big responsibility of the runtime environment provider.

To create a service, a developer uses off-the-shelf Java Integrated Development Environments (IDEs), the same tools Java developers have used to create countless Web-based applications. The model follows a specific pattern: First create the set of applications that work together to provide the service; then deploy the service by packaging it in a jar file; then deliver it to the run-time environment to be executed. "Create, deploy, and execute" is the mantra of service development.

Figure 1. The SCE Architecture	Figure 2. The SRE Container
Click figures to enlarge.

The SCE architecture is centered around a Java IDE (Figure 1). Any SCE must allow Web-application paradigms to be used within a telecom environment. Old telecom paradigms took time to learn and time to develop any application. Because the SCE is based on Java and many of its standard APIs, there is a wealth of books and magazines available to create training materials for new programmers, saving time because the development team need not document the internal process of development.

A complete service creation environment is more than just an IDE. The Service Runtime Environment (SRE), where all the complexity and connectivity are abstracted, turns the IDE into a service creation environment. The APIs exposed by the SRE and made available in the IDE is the simplifying technology necessary to make the service itself easier to develop. At its core, the SRE makes use of a Web application server thus providing access to Web-based technologies such as servlets, JSPs, and EJBs. Added to this infrastructure is a SRE container 
(Figure 2). The SRE container abstracts the underlying protocols used for processing phone calls. It also handles the threading of each of the service instances. Threading is important for the container to manage because it simplifies the structure of the service. By handling the interface to the telecommunications infrastructure, the SRE container allows services to span multiple networks and to take advantage of truly converged networks. This is where instant messaging meets the PSTN.

Futureproof Java
Service creation and service execution go hand-in-hand, and Java enables creation of a holistic environment where developers can use the same language to create both applications and the run-time environment they deploy to. And it is flexible. In the technology outlined above, for instance, XML can be used easily as a distributed protocol. For example, a service developed may need to control a VXML server to control speech-enabled technology on a separate server. With the Java API for XML Processing (JAXP), XML data languages can be generated and/or interpreted.

A next-generation service creation environment needs to be versatile, and the best way to insure that is by choosing an environment that is used for developing a wide variety of applications. Java even provides a native interface where developers can access C/C++ libraries and programs provided on the underlying operating system. All of this technology helps keep applications on the cutting edge. When a new protocol comes along or a new device hits the market, the developer will always have a method of integrating new technology into the development environment.

As applications become ever more complex, a properly designed service creation/service run-time environment using Java will enable developers to build highly reliable new telecommunications services within shorter development cycles. It will also make it possible for service providers to test-market a multitude of new services by minimizing the upfront hurdles to new service creation and deployment.

Tom McGuire is senior director of Service Creation and Systems Integration, Pelago Networks. Pelago Networks is focused on overcoming the challenges facing service providers such as established local exchange carriers (LECs), CLECs and next-generation ICPs, in delivering enhanced communications services to business customers over any wireless or wireline broadband access network.

[ Return To The October 2001 Table Of Contents ]