Exploiting CORBA in a Military Tactical Environment

Introduction

Object technology holds the promise of an improvement in the speed of application development by facilitating object recycling from other applications and upgrade for new functionality. By combining individual functional objects, a software application can be produced more quickly. Nevertheless, building and implementing effective distributed applications means taking both the network and the software applications into consideration. Essentially, communications, processing, and storage are three important types of resources supporting distributed applications. These resources are integrated in the distributed object paradigm to constitute the end-to-end quality of service (QoS) requirements of the applications.

In recent years, the Common Object Request Broker Architecture (CORBA) created by the Object Management Group, has been recognised as an important enabling technology for the development of distributed object-oriented applications. The flexibility of CORBA stems from its support for interoperability across heterogeneous hardware and software environments, hiding the complexities of hardware platforms, operating systems, programming languages, and networking technologies. CORBA is based on an object-oriented distributed model and is designed for distributed computing using a client-server model. The implementation of client-server architecture is prevalent in many distributed applications. Typically, a server application stores data that can be accessed by many clients. The clients issue short request messages to the server, which after servicing, sends a response. As middleware, CORBA is a software layer situated between the application and the operating system to facilitate the design and implementation of client-server systems in a heterogeneous environment.

CORBA has been designed for the commercial environment rather than the conditions one would expect in the military tactical environment. This paper identifies those aspects of CORBA, specifically in relation to communications, that would determine its ability to operate in the military tactical environment. We further suggest some possible approaches to overcoming potential limitations.

The tactical military environment

The battlefield of the future will be characterised by higher demands due to mobility. Seamless access to information will need to be available anytime, anywhere. Deployable military units will be dependent on rapid and reliable communication to fulfil their missions, particularly in a hostile tactical environment. There will be a spectrum of mobility requirements. Major headquarters and logistic facilities will continue to operate for periods of time in a static location. This will allow the use of higher capacity communications, such as satellite, fibre and radio relay, which will tend to be denied to truly mobile users. As a consequence, such headquarters will be interconnected by links with capacity in the hundreds of kbps to a few Mbps whereas mobile users (even with the advent of high capacity LEO satellites) will likely be limited to tens of kbps. This bandwidth sparsity to mobile users will likely last for many years to come. The anticipated dispersed mode of operation will mean that much of the communications will be via satellite with corresponding issues of high latency. While the various tactical platforms should have high-capacity local area networks similar to the strategic systems, the tactical wide area networks will have significantly less capacity and higher latency than the strategic networks. In addition, the tactical links, especially those to the highly mobile nodes, will suffer from a poor underlying error performance. Reliable transport layer services will mean that this high-error situation will further degrade link throughput and introduce network latency variations at the application layer.

The CORBA infrastructure

CORBA architecture

The overall architecture of CORBA is illustrated in Figure 1. At the topmost layer, the exact connection mechanism between the client and the server is hidden from the application programmers, as if the client and the server programs reside on the same machine.

The middle layer provides the necessary infrastructure to hide the details of the underlying Object Request Broker (ORB) layer from the applications, making remote object invocation look similar to local invocation. When the client invokes a remote operation it is effectively invoking the operation of that name provided by the client stub. The middle layer involves bundling and unbundling the call parameters, known as marshalling and demarshalling, for transmission across different address spaces.

The bottom layer specifies the wire protocol for transmission between the client and the server running on different machines, with the ORB acting as an object bus. The ORB is a collection of libraries and network resources that is integrated with end-user applications. It is responsible for locating the remote object and preparing it to receive the request. The ORB then passes to the object the request in the form of a buffer so that the appropriate operation can be executed. The CORBA 2.0 specification includes a general inter-ORB protocol (GIOP) for general ORB interoperability, which defines a set of message formats and common data representations. The GIOP on TCP/IP is known as the Internet inter-ORB protocol (IIOP) for interoperability among TCP/IP based ORBs, in which the Internet is effectively used as an ORB communication bus. The wire protocol for inter-ORB communication between ORBs from the same vendor is vendor dependent; typically the User Datagram Protocol (UDP) is used. In fact, some ORBs are able to support IIOP as a native protocol for communication between objects.

Object activation via IIOP

To invoke operations on an object across heterogeneous ORBs, a client must first obtain its interoperable object reference (IOR). The client can use the IOR to obtain a remote reference (like a pointer to an object) or else the client has to explicitly establish a connection to the object by using the CORBA bind operation.

If a proxy (mirror) object already exists in the object table maintained by the client-side ORB (implying a connection to the target object is extant), an IOR to the target object can be immediately returned to the client program. Otherwise, the ORB contacts an agent or possibly a third party directory service (such as a naming or trading service) to locate a reference to an object implementation that offers the requested service.

CORBA distinguishes between transient and persistent IORs. A transient IOR works only for as long as the corresponding server is running. It becomes invalid once the server shuts down. By contrast, a persistent IOR continues to identify the same object regardless of how many times the server is shut down and restarted. A transient IOR contains the address and port number for the server when it was originally activated. A persistent IOR however contains the address and port number of the implementation repository only.

Once an IOR is obtained, the client-side ORB connects to the address and port number specified within the IOR. A transient IOR enables the client to connect directly to the server provided it is still running. In the case of a persistent IOR, the implementation repository first checks to see if the server is running, and returns the details of the current machine and port number in a location-forward reply message to the client-side ORB. Eventually, the client-side ORB attempts to establish a direct TCP/IP connection to the correct server. If the server that implements the requested object is not currently active, the ORB can ensure that the object adaptor on the server side activates the appropriate server, which in turn instantiates all dependent objects, so that it can receive requests from the client program.

When the TCP/IP connection is successfully established between the ORBs, the client-side ORB creates a proxy object and finally returns the IOR to the client program. The client is able to invoke methods on the proxy object, which in turn, interacts with the server object. In effect, the client's method invocations are translated into operation requests that are sent to the server object.

Method invocation

When the client invokes the remote operation on the proxy object, the stub obtains a buffer and marshals the operation name and necessary parameters into the buffer. This buffer is handed to the underlying ORB, together with the object reference (in the case of IIOP this is the IOR). The client-side ORB sends the buffer to the target server through the established connection.

After receiving the buffer, the server-side ORB then demarshals the object reference to determine the requested object. The remainder of the buffer is passed to the object skeleton. The skeleton demarshals the operation name, and the parameters for the operation. It then invokes the operation of the object, passing it these parameters.

Once the operation has been executed, the skeleton obtains a buffer and marshals any results that are returned from the operation into the buffer. The buffer is then passed to the ORB to be sent to the client. The proxy object then demarshals the results, checks for exceptions, and returns them to the client program.

CORBA challenges

Processing overheads

Figure 2 shows the general path that CORBA implementations use to transmit requests from a client to a server for remote operation invocations [1].

The CORBA processing overheads can be attributed to many factors: presentation and session layer conversions and data copying, server demultiplexing, and buffering for network reads and writes.

CORBA is a high-level network-programming interface that offers many advantages of object-oriented programming compared with low-level interfaces such as sockets (A socket is an end point of communication in the Unix mechanism for creating a virtual connection between processes). The cost of these advantages is that CORBA is less efficient than low-level interfaces due to the layers of binding software. Developers may be forced to choose lower-level mechanisms (like sockets) to achieve the necessary transfer rates, thereby increasing development effort and reducing system reliability, flexibility, and reuse.

A fast CORBA environment will be necessary in a real-time system, and the software must be optimised for speed. To reduce processing overheads, the primary areas that should be optimised include reads/writes, presentation layer conversions and data copying. Indeed, a reasonable percentage of the execution time is spent in memory copy operations. Thus, for instance, the number of reads and writes can be reduced by matching the sender buffer size to the maximum transfer unit (MTU) of the underlying network, thereby enhancing the throughput [2]. While some troubles might be anticipated with low-powered workstations in the field, processor advances are overcoming these. In any case, in the tactical situation, with high latency/low bandwidth links, networking issues will overshadow these problems.

Communications aspects

In the process of object activation, a client always binds with an agent or a directory service. This ensures that the request is always routed to an active server, allowing object migration and load balancing. On the other hand, if a client is given a persistent IOR, it needs to contact the implementation repository to ensure that the first request for an object is passed to the correct server. Once the client knows how to contact the object, further requests can bypass the access to the repository. Nevertheless, the location-forward reply from the repository inevitably incurs additional overhead in the retransmission of requests, especially when requests carry large amounts of data. To avoid this redundant transmission of parameters for large requests, the client-side ORB can send a simple locate request to the repository without any parameter values [3]. The number of transits can be reduced if the agent also functions as an implementation repository.

While object activation would seem to comprise up to three logical transactions (with the agent, the implementation repository and finally the server-side ORB) hence indicating six transits of the network; the reality is more complex as some of the transactions require more messages than a simple request/response. We observed in trials of simple applications using the Visigenics ORBs [4] that object activation entailed 6-14 exchanges transiting the network, before initiating the final TCP/IP connection to the server-side ORB. Depending on the network delays between the client, agent, implementation repository and server; significant delay would be entailed in the process of object activation. If the client and server happen to use ORBs from the same vendor, the client can reduce the number of interactions by extracting the object key and the object adaptor name from the object reference and attempting to connect to that address first. This would avoid the additional connection to the implementation repository.

The IIOP consists of simple request-reply interactions. In addition to the TCP and IP headers, IIOP messages typically carry IIOP headers to support ORB interoperability and CORBA transparencies such as presentation layer translation of data into an interoperable format. Our observation of data transfer using the Visigenics ORBs indicated that the IIOP overhead is relatively constant at 100-300 octets, regardless of the size of IIOP messages. This overhead would become a real burden to short IIOP messages for interactive applications especially over low-bandwidth channels.

The mainstream of CORBA-based solutions is targeted at LAN-based applications and relies on fast, reliable connections. Mobile and satellite links tend to display more variation in operational behaviour that CORBA does not adequately support. Mobile end systems often experience changing characteristics of the underlying communications infrastructure: station closures, variation in throughput, and inadequate coverage, leading to a significant number of lost packets. Often distributed applications are not written to deal with performance degradation of the underlying networks. In this environment, objects can fail unexpectedly, and the response time for a method invocation can be unacceptable.

ORBs can be built using a variety of different communications protocols. Usually, the TCP/IP protocol suite is used to implement ORBs, and inter-ORB communication between ORBs from the same vendor is often based on the User Datagram Protocol (UDP) as the proprietary wire protocol. UDP is basically an unreliable service where delivery and duplicate protection are not guaranteed. UDP packets may be lost between the client and server, especially if the link between the client and the server gets congested. Hence, the client-side and server-side ORBs need to deal with any failures that may occur, such as lost or duplicated packets, giving the illusion of reliable communication.

The connection management of CORBA should ensure that resource usage is optimised by minimising the number of client connections to the server. A client may choose to send requests to multiple target objects supported by the same server over a single connection, thus avoiding the overhead associated with establishing additional TCP/IP connections.

Possible remedies

To help simplify the development of wide-area distributed applications, CORBA should be developed to provide application-level quality of service [5]. Current Internet technologies only provide best effort QoS over wide area networks, whereas absolute QoS guarantees can be provided in limited environments with certain assumptions. In order to make best use of the available resources, applications and system services will have to adapt to these changes. Platforms for tactical distributed systems must be able to provide and manage the change information about the environment, thereby supporting more effective applications. An example of the adaptive services is communications protocols capable of operating over a wide range of network types [6].

A real-time CORBA called TAO (The ACE ORB) [7] has been developed at Washington University in St. Louis to identify the key architectural patterns and performance optimisations necessary to build high-performance real-time ORBs. In TAO, resource-scheduling mechanisms are available in the underlying operating system and network to support real-time guarantees. In addition, a real-time CORBA system [8] is being developed at US Navy and at the University of Rhode Island. Clients are able to express timing requirements, such as deadlines, importance, and QoS, on method invocations. These timing constraints are then enforced by the object services within the CORBA system.

One approach to reducing communication requirements for tactical links is the use of proxies to act on behalf of mobile users. The Reactive Adaptive Proxy Placement (RAPP) architecture [9] has been developed for creating and managing proxies in a CORBA environment. Based on user and application preferences as well as host and proxy availability, the RAPP architecture is able to manage the insertion, modification and deletion of proxies to match the services currently available to mobile clients. In response to decreasing QoS, proxy objects can be installed on the edge of a wired network to reduce the required bandwidth, allowing different protocols to be used in the fixed and wireless domains. In particular, proxy objects can be tuned to adapt to the current QoS for best results in a changing tactical environment.

System developers will need to consider the balance between distributing objects (including their associated data) around the battlefield with associated challenges of maintaining data synchrony and the alternative approach of offering over the network the services of objects at the source of data. If the latter approach is taken (the paradigm upon which CORBA is based) consideration will need to be made of the amount of data that will be returned from the server. It has been observed that CORBA is quite inefficient at transporting short messages. A possible approach to running distributed applications from tactical users is perhaps a hybrid by using CORBA to locate and invoke remote objects, and standard TCP/IP for more efficient information transfer.

Conclusions

CORBA provides a framework for flexible and transparent communication between distributed objects in heterogeneous computing environments. Applying this middleware technology eases software development by allowing interaction between reusable components through well-defined interfaces. This greatly increases the value of information spread across various defence applications over different computing platforms, thereby fulfilling the operational requirements of modern battlefield interoperability. This paper has discussed the mechanisms of CORBA and has considered the performance issues of distributed applications in a military tactical environment. Given the differences in the fundamental characteristics of wired and wireless links, this transparency is difficult to realise without performance degradation, especially for those interactive applications with stringent timing constraints. To overcome these problems, real-time applications require a CORBA run-time system that supports enforcement of the timing constraints. The same requirements also apply to the underlying operating systems on both the client and server nodes, as well as the communications network. Although the potential of CORBA is wide and varied, supporting CORBA in a deployed network may become a burden to the tactical communications infrastructure without careful management of access to remote objects. Alternatively, the use of proxies can be used to act on behalf of tactical users to reduce the communication requirements for tactical links. These proxies can be designed to adapt to match the changing capabilities of the tactical links.

References

Authors

Andrew Au is a Research Scientist in Network Architecture Group of the Australian Defence Science and Technology Organisation’s (DSTO) Communications Division. His interests include traffic control and performance guarantees for computer networks.

William Blair is a Section Head in Network Architecture Group. He has been involved in research into the application of ATM to military strategic and tactical communications.

Rittwik Jana is a Professional Officer with the Network Architecture Group. His interests include computer networking and robust receiver architectures for spread spectrum systems.