We now describe our telecommunication case study in JavaTriveni.
Lucent Technologies' 5ESS telephone switching system [MS85] is a concurrent reactive system comprised of millions of lines of C code. In this switch, a wide variety of carrier group types are used to transmit data corresponding to end-to-end telephone connections. These carrier groups are attached to various hardware units on a set of processors, which are responsible for routing telephone calls. Malfunctions on these carrier groups, such as lost framing, lost events, or physical accidents, can result in disturbance or abrupt termination of existing phone calls. The Carrier Group Alarms (CGA) software in the 5ESS switch is responsible for reporting status changes -- malfunctions or recoveries from malfunctions -- on carrier groups, so that other 5ESS software can respectively remove or restore the associated carrier groups from service, and route new telephone calls accordingly [HLRW85].
As a case study, we have re-implemented part of the CGA software in JavaTriveni. The starting point of our implementation and the top level design come from our earlier work [JPVO96]. We repeat here our earlier description and design of the CGA software [JPVO96] in order to keep this paper self-contained. For proprietary reasons, the descriptions of our version given in this paper do not reflect the specific details of the actual 5ESS switch software, and we note that the JavaTriveni code in this paper is not part of the 5ESS switch.
One of the main sources of inputs to the CGA software are summary requests from either human operators or some other parts of the switch. In response, the CGA software must collect data about the status of all the carriers on all the relevant processors, and print this information on various consoles and printers via the Human-Machine Interface (HMI).
One component, called the ``CGA Collection Software,'' requests every relevant processor to send data about the status of all the carrier groups attached to that processor. This software then formats the received data in a manner suitable for printing on various consoles and printers via the HMI. The other components, called the ``CGA Data Software,'' reside on the processors on which the carrier groups are attached. When a request for data arrives from the CGA Collection Software to the CGA Data Software on a given processor, this processor searches the relevant databases for status information on all the carriers that are attached to that processor. The data is then sanity-checked -- namely, that this particular sort of status change can actually occur on the given carriers and is not merely the outgrowth of a database error. The data is collected into a packet and sent to the CGA Collection Software, after which this instance of the CGA Data Software waits for the next request from the CGA Collection Software. After receiving the next request, it resumes searching for more data, from the point it left off in the corresponding databases. When all the relevant data has been gathered, an appropriate termination message is sent to the CGA Collection Software. All communication between the CGA Collection Software and the instances of the CGA Data Software is through asynchronous message passing.
There are a number of issues that we needed to consider in writing our JavaTriveni version (and our earlier version) of the CGA software. For example:
We have dealt with these problems in quite a natural manner, thanks to the expressive power of JavaTriveni. Our case study version is described below. In this case study, we follow closely our earlier design [JPVO96].