In this section we present our programming model and provide a small, introductory example. We begin by introducing a few terms that are used through the rest of the paper.
A Mobile Stream (MStream) is a mobile communication endpoint in a distributed system. The closest analogy to an MStream is a mobile active mailbox. As in a mailbox, an MStream has a globally unique name. MStreams provide a FIFO ordering guarantee, ensuring that messages are consumed at the MStream in the same order as they are sent to it. Usually mailboxes are stationary. MStreams, on the other hand, have the ability to move from Site to Site dynamically. Usually mailboxes are passive. In contrast, message arrival at an MStream potentially triggers the concurrent execution of message consumption event handlers ( Append Handlers ) registered with the MStream, which can process the message and, in turn, send (append) messages to other MStreams.
An MStream has a globally unique name. We refer to any processor that supports an MStream execution environment as a Site. A distributed system consists of one or more Sites. A collection of Sites participating a distributed application is called a Session. Each Session has a distinguished, trusted, reliable Site called a Session Leader. Each Site is assigned a Location Identifier that uniquely identifies it within a given Session. New Sites may be added and removed from the Session at any time. An MStream may be located on, or moved to any Site in the Session that allows it to reside there. MStreams may be opened like sockets and messages sent (appended) to them. Multiple Event Handlers (Handlers) may be dynamically attached, to and detached from, an MStream. Handlers are invoked on discrete changes in system state such as message delivery (append), MStream relocations, new Handler attachments new Site additions and Site failures. We refer to these discrete changes in system state as Events. Handlers are attached by Agents which provide an execution environment and thread for the Handlers that they attach. (i.e. an Agent specifies a collection of Handlers that that all use the same thread of execution and interpreter.) Logically, the system is structured as shown in Figure 1.
Handlers can communicate with each other by appending messages to MStreams. These messages are delivered asynchronously to the registered Append Handlers in the same order that they were issued 2. A message is delivered at an MStream when the Append Handlers of the MStream has been activated for execution as a result of the message. A message is consumed when all the Append Handlers of the MStream that are activated as a result of its delivery have completed execution. By asynchronous delivery we mean that the sender does not block until the message has been consumed in order to continue its execution.
A distributed application is constructed by first specifying the communication end-points as MStreams and then attaching Agents to those end-points, that in turn attach Handlers for specific Events. A given MStream may have multiple Agents and each Agent may register Handlers for different Events, but each Agent may have only one Handler for a given Event. When an Event occurs, the appropriate Handlers in each Agent are concurrently and independently invoked with appropriate arguments. Handlers are typically registered on Agent initialization and may be dynamically changed during execution.
An application built using our Middleware, may be thought of as consisting of two distinct parts - an active part and a reactive part. The reactive part consists of MStreams and Handlers. The active part or Shell lives outside the Middleware and drives it. A Shell may connect to the Middleware and issue requests and may exit at any time. The reactive part is persistent.
Figure 2 shows an example script that instantiates a simple distributed system that resides at Sites 1 and 2. A message is sent to the MStream called foo by the stream_append command issued via the external Shell (#a in Figure 2) . The MStream called foo receives the message "Hello world" and sends it to the MStream called bar (#b in Figure 2) which outputs the message via its handler and then moves MStream bar to Site 1 (#c in Figure 2). The arrival handlers run when the MStream bar arrives at Site 1, printing the string "I am at 1" to the console at Site 1 (#d in Figure 2).
In Figure 2 the script labelled "External Input" in is the Shell and MStreams and their registered handlers are the reactive parts.