Publish-subscribe is now a well-known paradigm for building robust, large-scale distributed systems. In this architecture, the components interact via publishing messages and subscribing to classes of messages through a centralized component (the server). The set of conditions imposed by a subscriber define the subscriber’s policy. A common characteristic of these architectures is that the server does not maintain any state about the subscribers. The server keeps only the address of the subscriber (usually an IP address) and the associated policy. The policy is usually specified in a language based on first-order predicates and decides whether the message is sent to the particular subscriber only based on the content of the message.
Publish-subscribe promises to be a very good paradigm for developing applications for mobile environments due to the loose coupling of the components that are involved. However, the limited and highly dynamic resources of the mobile devices (such as network connection, energy supply) impose major challenges on the way the subscribers should specify their policies. The proliferation of Wi-Fi wireless LANs makes this situation even worse, since the clients need to be able to make a smooth transition from the hotspots to areas with normal or poor coverage. The main question we address in this paper is: What type of policies do the subscribers need to specify in order to be able to receive the right information in such environments?
There has been a considerable body of research in the last years on supporting publish-subscribe in mobile environments. The main focus was to improve the performance of the overall system in the presence of sporadic connectivity, using different algorithms for finding the best path to the mobile subscriber or support for offline work. In this paper we argue that we need novel mechanisms for the deployment of the policies themselves in order to support publish-subscribe in mobile environments.
A wide range of applications use the publish-subscribe paradigm, from simple stock quotes to civil disaster recovery or customized enterprise applications. To illustrate the generality of the problems that are faced in mobile environments we will give short examples in each category.
Suppose
that in a stock market application, a client wants to receive information about
the companies
Consider now a civil disaster recovery scenario, where agents in the field are equipped with mobile devices and are searching in a specified region. They can receive periodical updates from different data sources about any activity that was discovered in the area. The information can be a complex map or just some simple map indications. It should be possible for the agent to define its policy based on the current state it is in, depending on the network connectivity, remaining power, etc.
Finally, let us consider a large hospital with an Intensive Care Unit. The patients are monitored continuously using specialized devices. Ideally, the doctor would like to receive all of the data for the patients he is responsible for, if he has a good network connection and the battery of his PDA is charged. However, if the network connection deteriorates, he would like to be sure that he receives the most important data (such as the pulse) and maybe compressed versions of the least important data, even with loss of information such as the electrocardiogram. Moreover, if the battery power is very low, he would like only a summary of the state of the patients, at a regular interval of time.
We believe that the main characteristics that make the publish-subscribe paradigm suitable for mobile systems are the following:
The server must maintain a state associated with each subscriber. The state is an abstract concept and can be composed of any number of variables that describe the properties of a particular client.
A first-order predicate-based language which allows only interaction with the content of the message is no longer suitable for mobile systems. The language in which the conditions are written should be able to allow the interaction with the content of the message and with the state of the subscriber. It should also be able to modify the message content that is actually sent to the client according to the policy.
The SUBLIM system supports publish-subscribe for mobile systems and meets the above requirements. Our approach can be used in conjunction with current systems, where the server maintains states only for some of the subscribers facilitating an incremental deployment. In our system, the servers are running on the access points of the wireless environments, ensuring a good scalability by supporting a potentially large number of subscribers with minimal overhead.
The architecture for the SUBLIM system is based on a distributed network of servers in order to support a large number of subscribers. We assume that the subscribers are using wireless devices (such as PDAs). The servers are running on the access points of the wireless network, so that each server will be responsible for the subscribers connected to that access point. In Figure 1 we present the global architecture for our system, where WS stands for Wireless Subscriber. The solid lines represent wired network connection, while the dashed ones represent wireless connections. As we can notice, SUBLIM servers are running on the base stations, with wireless devices as subscribers. Publishers are also connecting to a SUBLIM Publish server that has as subscribers the servers running on the base stations. In the current implementation, the Publish Server is a simple router that forwards all of the messages to the SUBLIM Servers running on the base stations.
We will now present the abstract model used for building stateful publish-subscribe systems. The subscribers compose a community, or more specifically a S-community, where S is the SUBLIM server. To differentiate between specific subscribers, the server maintains some state for each member of the community. More formally, a S-Community is a tuple {S,C, ST, P, M}, where S is the server of the community, C is the set of subscribers, ST is a mutable set {STx, x in C} of subscribers state, (one per each subscriber in C), P is the set of policies, (one for each subscriber in C) and M is the set of messages that can be received by the subscribers. The state is a tuple-space and can be composed of any number of variables, describing the subscriber properties. Each variable is uniquely identified by its name. The variables can be automatic, in the sense that their values are maintained by the SUBLIM system, or manual, maintained by the policy itself.
The SUBLIM client is a component that runs on each subscriber. The SUBLIM client is responsible for maintaining the automatic variables
When a message arrives, the arrived() event is triggered and the policy specifies the operations that have to be performed. In our current implementation the operations are specified in a C++-like syntax. In addition to all the operations supported by C++, the policy can invoke a number of system operations that are implemented by the server. The currently supported grammar is presented in Figure 3. There are three operations associated with the handling of the properties maintained in the subscriber state (getProperty, setProperty and removeProperty). The automatic properties are read only, so the setProperty and removeProperty operations will do nothing. The policy can also specify how to create a message, using the createMessage operation, and how to manipulate the content of a message. A detailed example of such a policy is given in Section 5.
The architecture of the server is presented in Figure 1. The subscriber creates the policy and sends it to the server using a setPolicy() command (Step 1 in Figure 1). The server generates an agent, which will be associated with this subscriber. Each time a message arrives at the server from a publisher, an arrived event is triggered at every connected participant.
The main difference in the design of the SUBLIM server compared with other publish-subscribe servers is the way the policies are written and interpreted by SUBLIM. The policy is translated into C++ and then linked together with the needed SUBLIM libraries in a dynamic link library (DLL). The server attaches the DLL and then uses the function provided by the DLL in order to make the decision. Thus, the server is very flexible and able to handle any number of heterogeneous policies in an efficient manner.
When a message m arrives (Step 2), it is processed by the Message Dispatcher, then the Subscriber Agent checks the message (Step 3) and decides if the message m1 (which can be m or a modified version of m) should be sent to the subscriber or not, according to its policy (Step 4).
|
|
Consider for example a large hospital with an Intensive Care Unit. The patients are monitored continuously using specialized devices. For simplicity, we assume that the monitoring devices generate, for each patient, the following types of data: patient ID, pulse (P) and electrocardiogram (E).
Each doctor is responsible for a certain number of patients, identified by the patient IDs. The doctor wants to receive the messages according to the following policy, denoted by PICU-Stateless:
This policy will work very well in a wired environment, where the issues of low quality network connection, display size or energy supply do not exist. It is the thesis of this paper that, in a wireless environment, the current publish-subscribe paradigm will not be able to handle the dynamic changes in the quality of connection or energy supply. Intuitively, if many packets are sent to a client with a low bandwidth network connection, it might happen that, due to the congestion of the network, the client will not receive the most important information, (the pulse in this case) because the packets are dropped or delayed long enough to make the information irrelevant. The same argument can be made for the battery utilization. Receiving large amounts of data when the battery is low will reduce dramatically the availability of the service in real-life conditions.
Ideally, the doctor would like to receive all of the data for the patients he is responsible for, if he has a good network connection and the battery is charged. However, if the network connection deteriorates, he would like to be sure that he receives the most important data (such as the pulse) and maybe compressed versions of the least important data, even with loss of information such as the E. The same thing applies for the battery utilization. Similarly, the doctor will want to receive as much information as possible when the battery is charged, but only the most important data when the battery is low. Moreover, if the battery is very low, he would like only a summary of the state of the patients, at a regular interval of time. This leads to the following formulation (in an informal manner) of the policy PICU, suitable for mobile systems:
R1: The doctor is interested in receiving all data (P and E) for the patients he is responsible for if the network connection is good and the battery is charged. The electrocardiogram should not be bigger than the display size of the device used by the doctor.
R2: If the battery utilization goes beyond 75%, the doctor is interested in obtaining P and compressed versions of the electrocardiogram (E), with the compression ratio dependent on the battery utilization. When the battery goes beyond 25%, the doctor is only interested in the pulse (P) every five minutes.
R3: If the network connection deteriorates, the doctor is interested in getting the pulse P and compressed versions for the electrocardiogram (E).
R4: If the pulse of the patient goes beyond a certain threshold (let us say 50), the doctor is interested in getting information about that patient according to rules R1-R3.
The
state for this policy has three automatic variables:
An implementation for PICU is presented in Figure 2. Each of the rules is followed by comments (in italic) that, together with the following discussion, should provide enough understanding of the nature of our policies.
The first three lines of the policy deal with getting the current values for the automatic variables. We then create a new message and obtain the data associated with the received messages (Rules 4-5). If the doctor is not responsible for this patient and the pulse is good, the message is just discarded by returning a NULL message (again, details on how the policy determines if the patient is within the responsibility of the doctor are given in Section 6), as shown in Rules 8-9.
If the battery is very low (below 25%), only a part of the message (the pulse) will be send to the subscriber every five minutes. This is done by using a manual variable, Timestamp, as shown in Rules 12-24.
Otherwise, the content of the message is changed based on the current values of the battery, network connection and display size. In the current implementation, the SUBLIM server provides the compress method, but customized methods can also be implemented in the subscribers policies.
 |