Selection
5.7 Software Process Communication Protocol
The purpose of the SoftwareProcessCommunicationProtocolsubsystem is to provide tools with
a communication protocol for sending events to the process engine and receiving service re- quests from there. The subsystem will be built on top of a session-oriented message router such as Sun ToolTalk [Sun93], HP SoftBench [Cag90], DEC FUSE. In these systems, several processes can join a session and afterwards communicate with each other by exchanging mes- sages. We aim to use one of these systems, rather than operating system primitives such as sockets or pipes, for inter-process communication because they enable communication to be dened at a much higher level of abstraction. Using operating system primitives we would gain a slight performance benet. The results of benchmarks performed with SoftBench and ToolTalk [Ger94], however, suggest that these systems require between 50-100 milliseconds for a complete communication cycle, which we consider to be fast enough.
The rationale for providing a subsystem on top of one of these basic message routers is the same as for the UserInterface. The message routing is hidden from the rest of the tool
architecture in order to allow for portability and to provide a dedicated, safe and application- specic protocol for communication between tools and process engine. Figure 5.6 displays an overview.
The CommunicationChannelclass provides the channel for all communications between tools
and the process engine. Each tool has a reference to an object of class CommunicationChannel,
which is stored in an instance variable of the Control class. Upon creation of this object the
basic message router interface is initialised and the tool joins a particular session with the process engine. If the message router interface has informed the Control class about a new
Communication Channel
Message
Synchronous
Message AsynchronousMessage
Open
Message CloseMessage RedisplayMessage QuitMessage Create Message Merge Message Freeze Message AddRelationship Message Import Message Export Message Delete Message DeleteRelationship Message DeleteVersion Message Derive Message
Figure 5.6: Architecture of the Software Process Communication Protocol Subsystem channel object. The read operation investigates what kind of request it is and constructs an
instance of one of the subclasses of class Message. Similarly, a writeoperation is provided in
order to enable the tool to inform the process engine about process events.
Service requests, as well as events, are represented as messages. Hence the readoperation of
the communication channel returns an object of classMessageand the parameter of thewrite
operation is an object ofMessageas well. During the construction of a message that represents
a service request, the parameters of the service request are obtained from the communication subsystem and stored in instance variables of the respective message objects. Access operations for each of these service parameters are provided. During construction of a message that represents an event, the event parameters are passed as arguments to the constructor. As most of the services and events have dierent parameter types, dierent message classes are dened. They inherit from classMessage, which is a deferred class. Polymorphism is used for
the argument and result type of thewriteorreadoperation of the communication channel in
order to pass the appropriate kind of message.
In order to implement asynchronous services and asynchronous events, it is sucient to read or write a message from or into the channel. The tool can continue operating as soon as the communication channel has completed execution of the reador writeoperation respectively.
To implement a synchronous service or event, however, additional measures have to be taken in order to inform the process engine of the completion of the service or to obtain the response to an event from the process engine. To write the result of a synchronous service, each subclass of classSynchronousMessageexports an operationwrite result. The parameter of this operation
is message specic. Besides transferring the result, it also implements the notication that the service has been handled. A design problem is then how to obtain the result of an event notication from the process engine. A rst option would be to send the respective message using a synchronous protocol, as oered by the various basic message routers, and return the result of the event as a result of the write message. This option, however, is inappropriate since the tool would then be waiting under the control of the message router for the handling of the message. As a consequence, actions, such as resizing a window of the tool or moving a window to another position while the tool is waiting, are not handled appropriately in the tool. This is because the required updates to the window contents are not performed: the window manager, which handles these actions, is independent of the tool and runs in a separate operating system
process. It requests updates on window contents from the UIMS of the tool in the case of a resize or move operation. If the tool is waiting for a response to a message (which may take a while, depending on the load of the process engine), the UIMS cannot handle the required
updates accordingly. The second and better option is, therefore, to wait under the control of theUIMS. Therefore, the message has to be sent using an asynchronous protocol. In thewrite
operation of the communication channel, we then invoke an operation from the UIMS, which
returns after a xed amount of time (say a tenth of a second). After the UIMS operation has returned, we check whether the result has arrived. If not, the UIMS operation is invoked again. Otherwise, we return from the writeoperation. The result of an event may then be
obtained or determined by the operation read result, which is exported by all subclasses of
class SynchronousMessage.
The software process communication protocol as suggested above can be reused in arbitrary tools. It implements the required communication between process engine and tools for all generic services and events. It even implements some tool-specic services and events. There- fore, message types are parametrised. Rather than having dierent message types for creating dierent kinds of relationships, for instance, the message AddRelationshiphas a parameter
which denotes the relationship type. Nevertheless, a need may arise to add tool-specic mes- sages to the protocol in order to implement tool-specic services or tool-specic events. We have to require several facilities from the underlying message router in order to be able to implement the communication protocol as suggested above. The overall requirement is that the communication protocol must allow us to implement message objects transfer, i.e. instances of the various message classes, between the process engine and tools and vice versa. Therefore, these message objects have to be transformed into low-level messages, i.e. as sequences of atomic message components, which the message router can transfer. With respect to these low-level messages, we have the following requirements:
Message types:
As we have seen above, synchronous services and events cannot be imple- mented using synchronous communication primitives. To implement them we require instead a low-level message type from the communication mechanism that we call re- quest. These requests are a bi-directional means of communication between tool and process engine. The rst direction is used to send a message representing a request. The message router then returns control to the tool or process engine, respectively. As soon as the request is handled, the requested process adds an acknowledgement to the request message and sends it back to the requesting process. The message is then destroyed by the requesting process. To implement asynchronous services and events, we require a low-level message type notication, which implements one-way communication. The sender of this message does not care about whether the service/event has actually been handled. The message is destroyed by the notied process.Parameter types:
The router should allow for composition of atomic message components, which we call message parameters, to complex messages. As types for these parameters,boolean,integer,charand stringare required at the very least.
Message routing:
It may be too complex for the process engine to keep track of which tools have been started and to explicitly route messages to particular tools. Therefore, the messages dened above do not include any routing parameters. For messages that are sent from tools to the process engine, routing is obvious. For these messages, peer-to-peer routing may be used. For messages from process engines to tools, broadcast routing is required.that an addressee of a message is not reachable. In this case the message router may correct the error by starting the tool or process engine. If the mechanism cannot correct errors, tools and process engines must be notied about failures in message delivery.
Eciency:
Message delivery by the router should not result in any signicant decrease in the overall tool performance. We, therefore, require a round trip for a request type message to perform faster than 50 milliseconds.Distribution:
We required tools to run in a distributed environment. Therefore, tools must be able to join sessions from remote workstations. The message router should be fully supportive in this respect and be able to transfer messages between dierent workstations using a local area network.In short, we have dened an architecture that implements a communication protocol between the process engine and tools. We have discussed how this architecture can be used to implement both services and requests. The communication protocol implementation is reusable among arbitrary tools. To implement tool-specic services, additional message classes may have to be added. Of the available message routers, ToolTalk fulls these requirements, but the available versions of the HP BMS and DEC FUSE do not meet the distribution requirement. We, therefore, select Sun ToolTalk for our implementation as a message router.