Gateway architecture integrates telecom, data center

Voice and data are now sharing high-bandwidth pipes into an enterprise with frame relay protocols, voice over IP, firewalls for communications systems, and telephony programming interfaces that automate call center traffic. All of these factors are increasing the demand for the convergence of voice and data traffic. The mixing of traffic represents only the surface of an increasingly growing integration of technologies with separate and very different development and deployment histories.

Full convergence will not be achieved until data center servers are tightly integrated with the telecommunications infrastructure. Tight integration means that computers, networking devices, and telephony gear can seamlessly communicate, exchange information, and provide a means of sharing resources between the platforms when required. They should be able to coordinate services to optimize the use of bandwidth, maintain overall quality of service levels, and enable new types of applications.

What is preventing this level of integration? The systems that control application and file services are significantly different from those driving data and voice communications. Traditional data center servers and software are designed to be highly flexible, able to perform many functions simultaneously with a moderate degree of reliability. They are designed to handle a number of different and often conflicting tasks adequately.

On the other hand, data and telecommunications devices are designed to be highly specific, optimizing a single set of specialized functions with very high reliability. Software running on these devices is dedicated to high performance of a limited number of tasks, and it does so with fault recovery.

Joining these two types of computing together in software means reconciling these contradictory goals and subsequent technical advantages and limitations of each. The level of integration required to realize the potential of voice and data convergence presents a number of technical challenges, not the least of which is enabling reliable interprocess interactions between computer servers, routers, and switches comprising the infrastructure.

There are a number of potential integration areas between data center servers and telecommunications gear. These include building call center applications, monitoring and control of network and telecommunications devices, tracking and allocating bandwidth, and optimizing the use of alternative data and storage channels. Each of these requires, in effect, a heterogeneous distributed system.

Building applications that support such uses requires that processes on application and web servers communicate directly with processes on the telecommunications and network devices in that distributed system. The need for tight interprocess communication is driven by the potential for large amounts of time-sensitive information to be shared between the two types of systems.

Run-time communications between processes running on different processors, and possibly using different programming languages, is difficult to implement from scratch. There is the need not only to share data, but also to invoke and possibly control processes independent of their location on the network, providing supervision throughout the distributed heterogeneous system. Processor, language, and network independence requires a significant amount of software infrastructure to meet these demands.

Today, the interface between the communications device and application or web servers is typically implemented through software mechanisms from the enterprise world such as TCP Sockets or the Common Object Request Broker Architecture (CORBA), or for the embedded world through software systems which provide direct asynchronous message passing. While either one can address the need to some extent, both of these Enterprise approaches have issues and limitations that may not make them the correct approach for mainstream solutions.

TCP Sockets involve the use of a software library that enables connections between an application to a network protocol. With a sockets library, a program can send and receive TCP/IP messages by opening a network socket and reading and writing data to and from the socket. This approach enables the programmer to concentrate on data transfers and lets the operating system transport messages across the network correctly.

However, enterprise application-level integration using sockets tends to be highly complex to code, requiring specialized programming skills, and must be implemented separately for every application using the system. But there can be subtle nuances in the sockets semantics and in the configuration of network connections that make it less portable between different platforms. Also, using the low-level Sockets API to connect at the network protocol level requires detailed knowledge of the underlying network, including network addresses and packet structure. For these reasons, a direct message passing operating system with a simple API layered above the sockets API for application integration, and with a transparent abstraction of the underlying network is important to overcome these obstacles.

CORBA is an architecture that enables pieces of programs to communicate with one another regardless of what programming language they were written in or what operating system they're running on. The CORBA specification defines the Interface Definition Language (IDL) and the Application Programming Interfaces (API) that enable client/server object interaction within a specific implementation of an Object Request Broker (ORB).

CORBA is a highly complex set of technologies. The API is complex and can be difficult to use correctly, and an ORB is required to broker objects between software components. Overall, the TCP/IP and CORBA alternatives lack the tight integration of operating system components, can be technically difficult to implement, and do not inherently provide fault tolerance to individual software components. The result is a complex mixture of software technologies that may not provide the required level of performance and reliability.

A more feasible solution depends on the ability to provide an embedded library that can be linked to application code on the application or web server. This library provides a wrapper through which a client application running on an application or web server communicates transparently with other nodes in a distributed system, bringing the power of direct asynchronous message passing traditionally only found in some real-time embedded operating systems to the enterprise.

The wrapper code interfaces with a daemon running on the enterprise server operating system. This daemon enables the client process to behave as an embedded operating system process to the distributed system, providing for a gateway between the enterprise server and the embedded device. The result is that processes on the server can appear identical to those running on the embedded operating system.

With this type of architecture, developers of applications that integrate the functions of servers and telecommunications and networking devices, can write code that calls facilities defined in the library file. The daemon takes care of guaranteeing the runtime transfer of data and calls to a companion process running on the embedded operating system. With appropriate application process supervision software on the embedded operating system, it should even be possible to monitor of the health of the process on the enterprise server, and to restart it automatically if necessary.

This alternative approach offers some significant advantages over traditional approaches. Because it provides for a process running on the enterprise server that communicates directly with routers and switches using the direct asynchronous message-passing features available in some embedded operating systems, it reduces complexity and provides for a unique method of monitoring the health of the integrated system. The result is an architecture that enables developers to easily build and integrate applications that cross the chasm between voice and data.

Enterprise application developers can also gain the efficiency and reliability of the embedded operating system, which should have a proven record of high reliability in telecommunications networking embedded systems. This reliability extends from the embedded system itself all the way to the processes running on the PC or Unix server. Rather than having to depend on a process with less reliability than the embedded system it monitors, this alternative can extend the advantages of the embedded operating system to the entire combined enterprise and embedded application.

This gateway approach addresses the limitations of existing technologies by providing a transparent mechanism for communication among processes across operating systems. The implementation is independent of network addressing schemes or application programming interfaces on client operating systems, and enables developers to build complex systems at a higher conceptual level, improving reliability and time to market. In effect, it enables heterogeneous distributed systems to have the same level of efficiency, reliability, and high availability as the real-time embedded operating system itself.