2.4　Middleware for mobile systems: examples

After giving the general framework for describing the middleware for mobile systems in last section, we will illustrate the framework with some existing middleware examples, to see whether the framework is complete and abstract enough to depict the middleware. At the same time, we will compare the different middleware, conclude the important elements that decide or influence the design of the middleware. We will also conclude commonalities for a class of related middleware, which will be used to construct the architectural style for the middleware in the following chapters. This is the main objective of the book as outlined in Section 1.3.

In order to get more abstraction, we will not review individual middleware, but a class of middleware. We will classify the middleware according to the major adopted design strategy, which can be in most case identified through the component interaction model. We identify three classes of middleware here:event-based (or publish/subscribe) middleware, tuple space-based middleware and object component middleware. This classification is also often adopted by other researchers [29, 60, 55].

2.4.1　Event-based (or publish / subscribe) middleware

Event-based (or publish/subscribe) middleware belongs to message-oriented middleware that supports the communication between distributed system components by facilitating message exchange. Event-based [53, 157, 76, 95] or publish/subscribe model is often used for supporting message exchange between components in the mobile environment. Many event-based middleware for distributed systems have been adapted to support mobility. JEDI [43],REBECA [157], Siena [28], JECho [33], STEAM [95] are the examples of this kind of middleware.

A1 Component interoperability　Client components use the middleware to send a message to a server component across the network. The message can be a notification about an event, or a request for a service execution from a server component. The content of such a message includes the service parameters. The server responds to a client request with a reply-message containing the result of the service execution.

We can distinguish two categories of the models according to how to support mobility: nomadic roaming and ad-hoc roaming. Nomadic roaming means that the components can roam inside the nomadic network with the infrastructure support, while ad-hoc roaming means the components do not need the infrastructure support, and they come into contact when in proximity. Generally, the main functionality of the model supporting nomadic roaming is to provide continuous notification service when components are moving between points of connectivity. The main functionality of the model supporting ad-hoc roaming is to provide access to other components during a dynamic change of topology. REBECA [157], JEDI [43], Siena [28] and JECho [33] are the examples that support nomadic roaming. STEAM [95] supports ad-hoc roaming.

A2 Component interaction　Components interact through pub/sub communication. Components can act both as producers and consumers, they are clients of the underlying event notification service, which brokers notifications between producers of information and subscribers of information. Consumers subscribe the events they are interested in and are informed by the notification service when the event occurs. The notification service is responsible for checking the event against all current subscriptions and delivering it to all users whose subscriptions match the event. This model supports undirected communication where the producers do not need to explicitly define the receiver. The loose coupling of producers and consumers is the prime advantage of this model.

The component interaction models are quite different depending the supported mobility models. The model for nomadic roaming often introduces centralized or intermediate components in order to handle disconnection and provide continuous notification service while the application components move from one access point to another. These additional components are responsible for buffering notifications when disconnected, or rerouting and delivering the notifications to different locations where the roaming client currently locates. Therefore, the component interaction behavior is tied to these components. For example, JEDI [43] includes a dynamic tree of dispatchers (the client can reconnect to any) for ensuring publish-subscribe information is retained as members connect and reconnect. The dispatching servers manage temporary storage for notifications. They coordinate that no duplicates are received and that the notifications are causally ordered. They are also responsible for routing the notifications to a new server, with whom the client is currently connecting. Another example is the REBECA [157] mobility model. It uses intermediate components as brokers that relocate and redirect the notifications to the roaming clients.

In contrast, STEAM [95] contains neither centralized components nor intermediate components, since the very dynamic change of topology in ad-hoc networks makes such service not suitable anymore. The components maybe distributed over a potentially large geographical area. Thus they are unlikely to be able to maintain a permanent communication link to the servers. STEAM is based upon the concepts of group communication with publishers and subscribers belonging to the same group. Notably, STEAM exploits a proximity-based group communication, where a group is identified by both geographical and functional aspects. To apply for group membership, a component must firstly be located in the geographical area corresponding to the group and secondly be interested in the group in order to join. Therefore, the interaction is scaled by the proximity of publisher to subscriber, and events are only need to be forwarded within the scope of their proximity.

A3 Wireless network communication　Event-based model has an asynchronous communication⁽²⁾ style, which allows persistent communication between components that are not executing at the same time. That means, a message is stored even when its sender and its receiver are not executing after the message has been sent. It will be stored as long as necessary. This fits naturally to the intermittent and opportunistic wireless network connection. The message or event is buffered when the component disconnects, and it will be delivered when the component reconnects.

Especially, the proximity-based group communication of STEAM [95] limits the interaction between components to a certain geographical area. Subsequently, the behavior of communication connections between components becomes more predictable, and it allows the middleware to support reliable event delivery in a dynamic mobile environment.

A4 Context-awareness　On one side, the middleware supporting nomadic mobility generally fosters a strategy that enables the seamless integration of the legacy distributed applications without rewriting them. Thus, hiding the mobility to the applications is one requirement of such middleware. In this case, the middleware still holds the network and location transparency. On another side, the middleware provides location-awareness to the application, in order to support the location-based applications.

At the same time, the middleware supporting ad-hoc mobility does not focus on providing location transparency. For example, STEAM includes a location service that uses sensor data to compute the current geographical location of its host machine and subsequently providing this location information to the middleware and to the local event producers and consumers. The sensors are generally equipped on some fixed points locating in specific geographical areas. To suit outdoor applications, STEAM also exploits a version of the location service that uses a GPS satellite receiver to provide latitude and longitude coordinates.

A5 Space definition　The middleware supporting nomadic mobility has a relative structured space where devices are allowed to move inside the scope of areas covered by access points. While the middleware supporting ad-hoc mobility does not have a structured space. For example, STEAM has been designed for IEEE 802.11-based, wireless local area networks (WLAN). The application components are allowed to move within the scope of a specific proximity and between proximities. Additionally, STEAM allows entities to define geographical scopes independently of the physical transmission range of the wireless transmitters. It supports a multi-hop event dissemination in which nodes residing within the boundaries of a proximity forward event messages. Members of the corresponding multicast group recognize the identifiers of these event messages and subsequently deliver them.

A6 Dynamic change　The interaction and configuration between components is rather dynamic in a nomadic roaming model. The configuration changes dynamically when components move in or move out of area covered by access points, or when the wireless connection disconnects or connects. Especially, an interaction involves generally the central server or the intermediate components, as they provide continuous notification service. A client component can dynamically establish connections to the intermediate component within its current vicinity. The connection is not valid anymore when the client moves to other area. The configuration of the coordinating intermediate components changes too when the client component moves to other area. A new configuration of the coordinating intermediate components will be thus built.

The interaction and configuration in an ad-hoc network is much more dynamic, and it's direct interaction between the moving components. For example, STEAM supports dynamic interaction and configuration between components with the change of proximity. The configuration changes dynamically when components move in or move out of the proximity, or when the wireless connection disconnects or connects. The interaction is accordingly dynamically too since the interacting components are not fixed. A component can dynamically establish connections to other components within its current vicinity. An already established connection between two components can easily expire.

2.4.2　Tuple space-based middleware

Tuple space is an asynchronous communication model, which is effectively a shared distributed memory spread across all participating hosts that processes can concurrently access. As having decoupled nature that provides useful facilities for communication in wireless settings, tuple space has been explored for the coordination of mobile components. The middleware for mobile systems based on tuple space is created. L2imbo [45], Lime [102], TSpaces [156] and JavaSpace [141] are examples.

A1 Component interoperability Tuple space is a globally shared associatively addressed memory space used by distributed processes to communicate. If two processes need to communicate, a sender writes the data (a tuple) into the shared data space (the tuple space), while the receiver retrieves it from the same place. The tuple space acts as a virtual space between service providers (servers) and requesters (clients) through which they can exchange tasks, requests and data that they may use for future computation. We can roughly distinguish two categories of the models regarding how to support mobility: nomadic roaming and ad-hoc roaming. L2imbo [45], Lime [102] are designed for ad-hoc roaming. They focus on how to provide a dynamically changing context for computation in the presence of mobility. TSpaces [156] and JavaSpace [141] are mainly suitable for nomadic roaming with a distinct client-server style. The client is supposed to be running on a resource-limited device, while the server side is a resource-rich device.

A2 Component interaction　The tuple space based middleware belongs to coordination based model, which is specialized in describing concurrent processes interactions, abstracting away the details of computation and formally defining constrains and conditions on the interactions, i.e., offering facilities for controlling synchronization, communication, creation and termination of computational activities. The tuple space model is data-oriented model that essentially concerns what happens to the data. The model analyzes how data are shared among agents and the state of the computation is defined in terms of both the values of the data and the actual configuration of the coordinated components. Linda [58] is a famous tuple space based coordination language designed for distributed systems. In Linda, the context for computation, i, e, the tuple space is permanent and fixed. In order to support ad-hoc mobility in the tuple-space based model, the people mainly focus on how to provide a dynamically changing context for computation. For example, LIME [102] breaks up the Linda central global tuple space into many separate tuple spaces, each of it is permanently associated to a mobile unit. It introduces rules for transient sharing of the individual tuple space based on connectivity, i, e, the co-located mobile units share the transient data, which changes dynamically according to connectivity and migration. Accordingly, the context for computation changes dynamically too. The interaction between components is called location-dependent transient interaction, which is conditional on the relative positions of components. More precisely, interaction is limited to the situations in which the components are in the communication range of each other. L2imbo [45] is similar to Lime in this aspect. Multiple tuple spaces can be created and used for the mobile unit. They are shared transiently between the co-located mobile units.

The nomadic roaming support in tuple-space based models follow normally a client-server coordination. There exist centralized tuple spaces, accessible through remote operations by multiple processes. The interaction behavior is tied to the server. For example, the TSpaces [156] from IBM allows the creation of multi tuple spaces, each of which exists only on a TSpaces server. When a client issues an operation, information is sent to the server, which uses a lookup operation to find out the tuple space on which the operation needs to be performed and passes the operation and tuple operand to process. JavaSpaces [141] also implements a client-server coordination.

A3 Wireless network communication　In the tuple space paradigm, the sender does not need to know who the receiver is or where it is working. Hence the communication is decoupled in time and space, i.e., senders and receivers do not need to be available at the same time, and mutual knowledge of their location is not necessary for data exchange. This fits to the decoupled and opportunistic style of wireless network communication. Decoupled in the sense that computation proceeds even in presence of disconnections, and opportunistic as it exploits connectivity whenever it becomes available.

A4 Context-awareness　Lime provides both location-transparent and location-aware styles of data access, in order to support applications requiring different styles of programming. Lime fosters a style of coordination that reduces the details of mobility and distribution to changes to what is perceived as the local tuple space. This view simplifies application design in many scenarios. It relieves the designer from explicitly maintaining a view of the context consistent with changes in the configuration of the system.

At the same time, LIME also provides location-awareness through defining tuple location parameters. It supports getting location data from a GPS device. Besides, it also supports the awareness of the system configuration through a read-only, system-maintained tuple space, which contains information about the mobile units present in the community and their relationship.

A5 Space definition The middleware supporting nomadic mobility has a relative structured space where devices are allowed to move inside the scope of areas covered by access points. While the middleware supporting ad-hoc mobility does not have a structured space. For example, STEAM has been designed for IEEE 802.11-based, wireless local area networks (WLAN). The application components are allowed to move within the scope of a specific proximity and between proximities. In addition, STEAM allows entities to define geographical scopes independently of the physical transmission range of the wireless transmitters. It supports a multi-hop event dissemination in which nodes residing within the boundaries of a proximity forward event messages. Members of the corresponding multicast group recognize the identifiers of these event messages and subsequently deliver them.

A6 Dynamic change　The context for computation, represented in Linda by the central permanent tuple space, is represented in LIME [102] by transient sharing of the tuple spaces carried by each individual mobile unit. Through this way, the global context for computation is defined by the transient community of mobile units that are currently present. Since these communities are dynamically changing according to connectivity and migration, the context changes as well. Therefore, the computation is dynamically associated to the connectivity and migration of the components.

2.4.3　Object and component middleware

Object middleware evolved from RPC, which is a classical paradigm that supports remote procedural calling in distributed system. The object and component middleware for distributed systems has been adapted to support mobility too. The synchronous communication paradigm of the object-oriented middleware assumes a permanent connectivity that cannot be guaranteed in the ad-hoc network. Therefore, adaptations of traditional object middleware to mobile scenarios are usually targeted to nomadic roaming. Wireless CORBA [111], ALICE [66], RAPP [132] and DOLMEN [149] are examples of this kind of middleware.

A1 Component interoperability　The object middleware supports the definition of object (component) services. The service provided by a component is encapsulated as an object and the interface of an object describes the provided service, which is a set of method calls defined through an IDL. The interfaces defined in an IDL file serve as a contract between a server and its clients. Clients interact with a server by invoking methods described in the IDL. Marshalling operation parameters and results is again by stubs that are generated from an interface definition.

The main functionality of the model supporting nomadic roaming is providing continuous invocation service when objects are moving between points of connectivity.

A2 Component interaction　Object middleware [49] supports distributed object interaction, that is, a client object requests the execution of an operation from a server object that may reside on another host. This interaction evolved from Remote Procedure Call (RPC). The basic form of interaction is synchronous, that means the client object issuing a request is blocked until the server object has returned the response.

The object middleware supporting nomadic roaming often introduce centralized or intermediate objects in order to provide continuous invocation service while the application objects move from one access point to another. These additional objects are responsible for redirecting and delivering the invocations to different locations where the roaming object currently locates. Therefore, the interaction behavior is tied to these objects. For example,Wireless CORBA [111] and DOLMEN [149] introduce access bridges as intermediate objects that provide continuous invocation service. Handover protocol is used between access bridges for redirecting the invocations.

A3 Wireless network communication　The synchronous communication paradigm of the object middleware does not fit to the unstable wireless connection naturally, unlike other asynchronous communication paradigms. The middleware supporting mobility has to deal with the unstable wireless connections.

There are two main solutions in the current available object middleware. One solution is to emulate the server object as much as possible in order to permit continued execution of application client objects. When disconnection happens, operations originally performed on server objects are performed on replicated or migrated objects in the cache. For example, ALICE [66] provides disconnected operation that lets clients replicate the server data and cache the replica locally. While the client and server are disconnected, client requests to the server are redirected to the replica stored on the client side. This allows the client to operate in spite of not having access to the server. Support for conflict detection and resolution is also provided.

Another solution is to provide reliable transmission over the wireless connection. For example, Dolmen [149] and Wireless CORBA redefine the inter-ORB protocol to enhance reliability and performance of object communication in the mobile environment. Messages over the wireless link are transferred by the adaptation layer that guarantees reliability and ordered delivery of messages. Dolmen [149] and Wireless CORBA maintain the state and forward messages for a disconnected terminal. There is a parameter in the message to indicate if the message should be redirected and handover should be pursued.

A4 Context-awareness　The object middleware supporting nomadic roaming focuses on seamless integration of the legacy distributed applications without modifying them. Therefore, hiding mobility to the applications is one of the design goal of the middleware. The network and location information are hidden to the application. The application objects will not notify that they are doing invocation with the mobile objects. On another side, the middleware also provides location-awareness to the application, in order to support the location-based applications.

A5 Space definition　The object middleware supporting nomadic mobility has a relative structured space where devices are allowed to move inside the scope of areas covered by access points.

A6 Dynamic change　The interaction and configuration between objects is rather dynamic. The configuration changes dynamically when application objects move in or move out of area covered by access points, or when the wireless connection disconnects or connects. Especially, an interaction between application objects involves the intermediate objects, which provide continuous invocation connection service. An object can dynamically establish connections to the intermediate object within its current vicinity. The connection is not valid anymore when the client moves to other area. The configuration of the coordinating intermediate objects changes too when the application objects move to other area. A new configuration of the coordinating intermediate objects will be thus built.

2.4.4　Generalization of commonalities

We have described three important types of existing middleware for mobile systems using the given framework that includes: A1 component interoperability, A2 component interaction, A3 wireless network communication, A4 context awareness correspondingly in the mobile system, A5 space definition and A6 dynamic change. The framework allows us to abstract from specific implementation details and focus on the important and general aspects presented by the middleware.

Additionally, the generalization enables us to compare different approaches from a same point of view, and explore commonalities from the great diversities of the middleware. This builds a basis for constructing the architectural style for the middleware that should represent a common form of design for a class of related middleware.

For instance, we can see that space and wireless connection are the two most important aspects for the middleware to deal with mobility. Space decides allowed roaming style of components, influences the interaction and communication models of components, and hence deciding the preferable design strategy. Different treatment and consideration of wireless connection leads to various communication paradigms. At the same time, the component interaction and configuration are associated to space and wireless connection. They are not static anymore as in traditional distributed systems. The change of space and wireless connection causes dynamic change of the interaction and configuration. Computation is also related to such dynamic change.

In addition, we also observe some commonalities of the reviewed middleware regarding space definition, main functionality and component interaction/ design pattern if we consider the supported wireless network of the middleware (Table 2.2). Accordingly, we can roughly separate the middleware into two classes: the middleware for nomadic networks, and the middleware for ad-hoc networks.

Space　The targeted wireless network of the middleware generally decides the definition of space. Different wireless networks can have different definition of space that greatly influences the design and functionality of the middleware. The nomadic network has a structured space where components are allowed to move inside the scope of areas covered by access points. In contrast, an ad-hoc network does not have a structured space. The distance metric is important because communication can take place only when components are within range.

Main functionality　Generally speaking, the middleware for nomadic network focuses on how to provide continuous connectivity and other services when components move across the structured spaces where handover protocols are often used. In an ad hoc network, the main functionality of the middleware is to provide access to other components during a dynamic change of topology.

Component interaction / design pattern　The component interaction behavior and the design strategy of the middleware share some similarities too for the same kind of network. The middleware for nomadic networks allows the existence of central servers to provide service to other components. Such servers can be fixed and other moving components can always communicate with them. Communication behavior is tied to central servers here. In contrast, the very dynamic change of topology in ad-hoc networks makes such servers not suitable anymore, since the components maybe distributed over a potentially large geographical area. Thus they are unlikely to be able to maintain a permanent communication link to the servers. The favorable component interaction model is also influenced by the network. Synchronous communication paradigms like RPC still can be adapted for nomadic networks, but they do not fit to the ad-hoc network anymore. Ad-hoc networks prefer asynchronous (non-blocking), proximity (geographical space) groups communication, and components most likely interact once they are in close proximity.

Inside these three aspects, we can also observe that space definition and functionality are more general than component interaction. That means, several different middleware platforms use different component interaction design patterns but supports the same space definition and functionality. This is quite natural, since different middleware can be designed for the same class of mobile application, which is normally used in a typical wireless network. Thus, space definition and main functionality are decided by the targeted application and wireless network. At the same time, different middleware platforms can adopt specific component interaction design patterns to deal with the mobility model and realize the functionality.