Internet Computing, IEEE - CiteSeerX

Data Dissemination on the Web

Disseminating Information to Mobile Clients Using Publish–Subscribe Providing an up-to-date view on dynamically changing data presents difficulties. While several different data-dissemination platforms address the problem, client mobility is still a major challenge. Volatile wireless connections and resource limitations void the attempt to apply the same mechanisms that work in fixed-wired networks.The Rebeca publish–subscribe middleware implementation introduces several concepts for accommodating client mobility in publish–subscribe systems. The authors present experimental results that show how intelligent filtering mechanisms can save network bandwidth inside the infrastructure and at mobile clients while preserving the accuracy of client notifications.

Gero Mühl, Andreas Ulbrich, Klaus Herrmann, and Torben Weis Berlin University of Technology

46

MAY • JUNE 2004

he Internet is still primarily used for human-to-computer communication: users explicitly request information such as Web pages from specific servers when they need it. This traditional view presents information as a rather static and stationary good. This is appropriate for simple applications such as catalog browsing, but not for new applications such as news services, auction trackers, traffic information systems, and online decision support systems. These information-driven applications rely on an up-todate view of dynamic information that can change rapidly and unpredictably. Disseminating dynamic information to

T

Published by the IEEE Computer Society

consumers who require sufficiently up-todate views of the content requires active research — particularly for mobile clients, which have limited connectivity and scant resources. In this article, we show how the Rebeca publish–subscribe middleware (www.ivs.tu-berlin.de/Projekte/Rebeca/) can help disseminate dynamic information to mobile consumers. Several adaptations enable Rebeca to cope with mobile clients effectively. First we look at current approaches to information dissemination. Then we examine existing push technologies and their shortcomings. Content-based publish–subscribe faces unique challenges,

1089-7801/04/$20.00 © 2004 IEEE

IEEE INTERNET COMPUTING

Using Publish–Subscribe

which our notification service addresses. Rebeca supports the special needs of mobile clients, and experimental results show the potential of its infrastructure’s intelligent notification filtering.

Information Dissemination The objective of information dissemination is to transfer data from producers to interested consumers. Whereas applications impose various requirements, information dissemination has several fundamental objectives that are always present: making new content available, updating existing content, and revoking obsolete content. Information dissemination strategies fall into two broad categories, pull and push.1 In pull, information consumers initiate communication, whereas push leaves the initiative for communication to the information sources. Both approaches can use periodic or aperiodic communication. With periodic communication, the provider and consumer exchange information at regular intervals, similar to teletext — whether fixed (once a minute, for example) or adaptive (corresponding to the observed rate at which the information actually changed). With aperiodic communication, on the other hand, neither the provider nor the consumer predetermines the times at which they transfer information. Instead, they carry out communication when certain events occur. For example, users pull Web pages from Web servers when they press a button, or providers push quotes to interested consumers when stock prices change. Dissemination Infrastructures Architectures in which information producers and consumers communicate directly or via centralized mediators offer only limited scalability when the number of consumers increases. Intermediate nodes between producers and consumers that act as caches and repeaters can greatly enhance scalability. Such dissemination infrastructures transfer information from producers to consumers stepwise. Each transfer step can employ either push or pull, or even both methods simultaneously.2 In any case, the method the dissemination infrastructure uses internally is orthogonal to the method that serves consumers. Disseminating Dynamic Data Push and pull each have advantages and disadvantages, depending on the application requirements. For information-driven applications, aperiodic pull is not feasible because consumers want


continuous updates as soon as the data changes. Periodic pull, which is also called polling, forces individual consumers to periodically ask for new updates. Because a small delay implies a high polling frequency, polling wastes large amounts of resources. The same applies to periodic push because the infrastructure retransmits the information periodically to allow new consumers to catch information they would otherwise have missed. Aperiodic push offers the following advantages: • The sources can initiate communication instantly if and only if the data changes or new data is available. • Each interaction requires only a single message. • The infrastructure can apply multicast instead of point-to-point communication. • The infrastructure can combine aperiodic push with aperiodic pull to allow new clients to gather the current or historical content. For these reasons, we chose aperiodic push for disseminating dynamic data in Rebeca.

Existing Push Approaches Java applets and JavaScript pushlets abound in applications that push content from Web servers directly to Web clients. However, both approaches can exhibit the desired scalability only in combination with a powerful dissemination infrastructure. Java applets can communicate with their originating Web servers in different ways. For example, they can implement a push protocol by using a callback mechanism via Java RMI or Corba. On a small scale, a callback-oriented push protocol works fine. However, the fact that simple callbacks block the caller leads to limited scalability and a lack of robustness. With pushlets, the Web server continuously pushes JavaScript commands to the Web client over the existing HTTP connection. The client executes the received commands, which update the content. If for some reason the connection breaks, which frequently happens with mobile clients, the server can push no further content to the client. Most proposed “push” architectures actually pull at the infrastructure level.1 Broadcast discs2 are one of the few approaches that actually use push. They periodically push content according to a predefined schedule. Usually, broadcast discs broadcast content with a higher access probability more frequently than less popular content. But how long should the infrastructure keep a specific data item

www.computer.org/internet/

MAY • JUNE 2004

47


on the schedule? To allow consumers to access content that is not broadcast, the infrastructure often combines push with consumer-initiated pull. Our previous work introduced a push infrastructure based on the publish–subscribe paradigm. The Rebeca platform uses content-based subscriptions to give subscribers fine-grained control over the content they receive. This enables us to implement intelligent filtering mechanisms for relieving the infrastructure load and mobile clients.

Content-Based Publish–Subscribe In a publish–subscribe system, producers make information available by asynchronously publishing notifications, and consumers place standing requests for information by issuing notification filters called subscriptions. A subscription is a Boolean evaluation function that yields true if the notification matches the consumer’s interest, false otherwise. Additionally, producers can issue advertisements to express their intention to publish certain kinds of notifications. A notification service decouples producers and consumers, delivering published notifications to all consumers who have matching subscriptions. The resulting loosely coupled communication is the most important advantage of publish–subscribe. Publish–subscribe works for both aperiodic and periodic push, but aperiodic push is more common. With aperiodic push, the provider publishes a notification only once. To implement periodic push, the provider (or the middleware) republishes notifications periodically while they are still up-to-date. We can categorize publish–subscribe systems by the filter model they use — that is, by how they specify and evaluate a notification filter. Most newer notification services rely on content-based filtering because it is the most expressive: it lets consumers specify in detail the notifications they wish to receive, thus allowing the provider to customize information on the basis of appropriate content-based filtering. Content-based filters are Boolean expressions built from conditions on the content of the notifications and logical operators, such as stock = “Foo Inc.” and price > 10. Other filter models classify notifications using channels, subjects, or type hierarchies. Today, a few content-based notification service products exist, mainly implementations of the Java Message Service specification (JMS) and the Corba Notification Service specification. In addition to such commercial products, some researchers have built prototypes such as Siena (www.cs.

48

MAY • JUNE 2004


colorado.edu/serl/dot/siena.html) or Rebeca. Scalable implementations of content-based notification services still present a challenge. Many commercial products employ centralized implementations because they are simpler to implement and can reuse existing technology (for example, databases). Because a single centralized service must carry out all communication, however, such implementations exhibit limited scalability. Using a federation of manually configured services improves the situation to some extent. Distributed implementations use overlay networks of cooperating brokers that each manage a mutually exclusive set of local clients. Flooding provides a simple strategy for distributing data among the brokers. Subsequently, each broker delivers the notification to all local clients with a matching subscription. Flooding works well if a majority of brokers needs to receive the notifications. Otherwise, it can perform very badly, swamping brokers with irrelevant notifications. A more advanced approach is content-based routing, which selectively propagates notifications through the broker network. Each broker manages a subscription routing table that holds a set of routing entries. Routing entries are pairs (F,D) of a filter F and a destination D. A broker forwards an incoming notification n to a destination (such as a local client or a neighbor) D if routing entry (F,D) exists such that n matches F. This way, a broker forwards notifications only over those links that form part of a delivery path from a producer to consumers with matching subscriptions. In Figure 1, clients X2 and X3 issue two subscriptions, F and G respectively. The filter F covers G; that is, F matches at least all notifications G matches. When client X1 publishes a notification n matching F and G, the infrastructure forwards n to X2 and X3. Because we assume that all clients can be publishers as well as subscribers, the routing tables of the brokers also contain entries that the infrastructure needs in order to deliver notifications from X2 to X3 and vice versa. If the infrastructure knows which clients act as publishers, it can use advertisements to avoid unnecessary routing entries. When clients issue new subscriptions or cancel existing ones, a routing algorithm updates the routing tables to reflect the changed delivery paths. The simplest routing algorithm floods new and canceled subscriptions into the broker network. Advanced algorithms use identity and covering tests among filters as well as filter-merging to avoid flooding of subscriptions.3,4



The Rebeca Notification Service Rebeca is a research prototype of a notification service that supports a set of content-based routing algorithms and advertisements.4 We have implemented Rebeca on Java and Microsoft .NET; for mobile devices, we ported the .NET version to the .NET Compact Framework (CF), a strippeddown .NET for PDAs running Microsoft’s Pocket PC or Windows CE operating system. Anyone can download Rebeca free of charge at the project’s Web site. In Rebeca’s default data model, a notification consists of a set of name/value pairs, such as

(G, B2) (F, X2) n (F, B3) (G, B4) n

X2

B3

n

sub(F)

n

X1

B1

B2

n

Client

pub(n) (F, B2)

n

Broker (F, B2) (G, X3)

B4

X3 sub(G)

Routing table

{(Type, Quote), (Stock, “Foo Inc.”), (Price, 10)}. A filter is a conjunction of attribute

filters that impose constraints on single name/value pairs, such as {Type=Quote and Stock=”Foo Inc.” and Price>10}. This simple model allows efficient testing for identity, overlapping, and coverage, as well as efficient filter merging.

Figure 1. Content-based routing. Using the routing tables of the individual brokers B, the infrastructure forwards a published notification n step-wise through the broker network so that the notification reaches all consumers with a matching subscription F or G.

Requirements of Mobile Clients Mobile clients have specific requirements due to their scarce resources and temporary connectivity. Usually, mobile clients connect over wireless links, which are especially susceptible to overloading due to their restricted bandwidth. As they move, mobile clients can connect to different access points using various networking technologies (Bluetooth, Wireless LAN, and so on). Therefore, continuous information delivery requires seamless handover. Moreover, both processing and wireless networking consume considerable electric power; available battery capacity probably represents the greatest limiting factor in mobile devices today. Consequently, mobile clients might get overloaded if the infrastructure delivers all occurring updates to them. This is particularly true for aperiodic push, in which the load corresponds to the rate at which the information changes. Therefore, we decided to reduce the load by reducing the number of update messages mobile clients must deal with. In our approach, the infrastructure propagates only those update messages necessary to fulfill consumers’ specific requirements. This includes only pushing data to the consumer if it sufficiently deviates from the data received previously.5 The infrastructure can save a lot of resources by doing so, because consumers usually do not depend on receiving all intermediate updates. For example, consumers should receive a new stock quote only if they received the last update at least 10 seconds

before, or if the price changed by at least two dollars. Using Rebeca’s content-based subscription mechanism, a client has full control over the notifications it will receive. Clients use the same mechanism to specify, for example, constraints on notification frequency. The Rebeca infrastructure uses this information to avoid propagating notifications unnecessarily. Rebeca applies further policies when network congestion occurs. For example, if several updates have queued up at an infrastructure node, it forwards only the most recent update. The mechanisms Rebeca uses to deal with client mobility differ from previous ones6,7 in that the application does not control mobility; instead, the middleware handles it transparently.8


Persistent Connections Mobile clients’ connections frequently and unexpectedly break. Rebeca partially reimplements transport layer functionality at the application level to realize persistent connections, which handle connection losses transparently. Persistent connections use a simplified sliding window protocol to ensure that the connection does not lose or duplicate notifications. Both end points of the connection — the client and the broker to which the client is connected — buffer notifications they have sent temporarily in a queue until the other end point has acknowledged them. When the mobile client reestablishes a connection, both directions exchange the sequence number for the last


MAY • JUNE 2004

49


1. new 2. new

X1

B1

(F, B3) (F, B4) B2

(F, X2) (F, B2)

sub(X2, F) X2

B3 replay of queued notifications

(F, B2)

mobile client

new 3. new

(F, B2) (F, X2)

B4

X2

Figure 2. Supporting mobile clients. When a client X2 loses its connection to broker B3 and reconnects to a different broker B4, the infrastructure updates the delivery paths of the client and replays queued notifications. received notification, and transmission continues from that point using available transport mechanisms such as TCP, UDP, and Bluetooth. So far, we’ve assumed that clients reconnect to the same broker from which they disconnected. When a client reconnects to a different broker, the middleware transfers the persistent connection’s state (such as subscriptions and the notification queue) to the new event broker.9 In Figure 2, client X2, which has a single subscription F, disconnects from broker B3 and reconnects to broker B4. Rebeca changes the routing entries at brokers on the path from B3 to B4 to ensure the delivery of notifications matching F to the new location of X2. Rebeca executes this process step by step to ensure that it doesn’t lose or duplicate any notifications. The infrastructure forwards the notifications buffered at B3 or at intermediary brokers to B4 and subsequently delivers them to X2. Durable Subscriptions and Queuing Policies Persistent connections offer a proper solution for short disconnections that the client shouldn’t notice. Longer interruptions present a different scenario because they cause large numbers of notifications to queue at brokers. When the client finally reconnects, many of these notifications will be outdated. Our solution to this problem is twofold: durable subscriptions and queuing policies. Durable subscriptions stay active for a certain

50

MAY • JUNE 2004


time, after which the broker automatically cancels them. During their active time, matching notifications queue up even if the subscriber is not connected. When the specified time has elapsed, the broker cancels the subscription and discards the queued notifications. Queuing policies, which attach to subscriptions, limit the number of notifications that can queue. They specify when to discard buffered notifications. For example, a client can specify that notifications older than 10 minutes should be discarded or that the infrastructure should deliver only the most current notification regarding a certain data item (a stock, for example). These policies come into play not only in the case of disconnections, but also during congestion. Accessing Past Notifications Traditional publish–subscribe systems provide no ability to access past notifications. They guarantee to deliver a notification to a consumer only when it is published sufficiently after the consumer has issued a matching subscription. For many applications this behavior is inappropriate. For example, consider a client starting a stock watchlist. Without access to past notifications, the watchlist displays the current price of a stock only after the provider has published a new quote for this stock and the infrastructure has delivered this quote to the consumer. This can lead to an unacceptable delay. Our Rebeca system uses histories that provide access to past notifications.4,10 Rebeca can replay the stored notifications if they match a subscription made after their original publication. This way, clients can essentially aperiodically pull past notifications from the histories. When subscribing, the consumer attaches a replay specification to the subscription describing what past notifications they want to see (for example, all notifications not older than five hours). The middleware then propagates the extended subscription to all concerned histories. When a history receives a subscription, it republishes those stored notifications that match the subscription and replay specification. Of course, only newly subscribed consumers receive republished notifications. The challenge is to deliver all desired notifications without duplicates. Currently, we are investigating two scenarios for using histories. In the first, each producer manages its own history, storing the notifications it has published. In this scenario, duplicates are not a problem because each notification lives in only one history. In the second, more complex, scenario,



each event broker manages a history, which replaces the notifications based on their timestamps. Figure 3 illustrates this scenario. Client X2 subscribes to filter G at 8 p.m. and asks for all notifications since 3 p.m. Rebeca propagates the subscription along the delivery paths via the brokers to the producers until the infrastructure has satisfied its replay specification (that is, until the histories have replayed all relevant notifications). In the example, broker B1 replays all notifications since 5 p.m. and broker B2 replays all notifications since 3 p.m. The notifications matching G are in these brokers’ caches because client X1 subscribed at 10 a.m. to a filter F that covers filter G. Notification n, which client X3 published at 4 p.m., matches F. Therefore, B2 has stored n and now sends it to client X2. Limiting Delivery Rates Mobile clients often cannot deal with notifications published at high rates. A limited delivery rate, which drastically decreases resource consumption, suffices for many applications. Thus Rebeca delivers to the mobile device only those notifications necessary to fulfill application requirements. Our approach for realizing limited delivery rates resembles to some extent the one Shah and Ramamritham presented.11 However, they focused on synchronizing a set of replicated repositories to maintain coherency. In their approach, each repository stores a subset of the available data items, which each come from a single source. In contrast, a publish–subscribe system such as ours permits any node in the system to publish new versions of data items. In Rebeca, the consumers specify relaxed requirements as part of the subscription. For example, {Type=Quote and Stock=“Foo Inc.” at Rate 500 msec} denotes that the infrastructure should deliver

a stock quote for a specific company only if the provider published it at least 500 msec after the prior quote. The consumers can also specify relaxed requirements based on the content; a subscription {Type=Quote and Stock=“Foo Inc.” if change(Price)>=1%} means that the infrastructure

should deliver a quote only if the price has changed by at least one percent compared to the previously delivered notification. To illustrate relaxed requirements, let’s use rate delimiters as an example. Implementation. A simple limited-delivery-rate implementation adds a rate delimiter to the broker’s outgoing link for every subscription of a client. Each rate delimiter stores the publication


History since 12 a.m.

...

n B2

X3 pub(n) at 4 p.m. n matches F

History since 5 p.m.

... B1

X1

X2

sub(F) at 10 a.m. sub(G) at 8 p.m. replay > 3 p.m. F covers G

Figure 3. Accessing past notifications.When a client X2 subscribes to past notifications, the infrastructure forwards the replay request to all concerned histories, which replay the requested notifications. time of the most recently delivered notification. If an arriving notification’s timestamp sufficiently surpasses the recorded time, the broker delivers the notification and accordingly adjusts the time the rate delimiter stores. While this implementation relieves the mobile client, it means that many published notifications travel through the infrastructure only to be discarded. To reduce the load on the infrastructure, the system needs to identify notifications that will not reach consumers and drop them as early as possible. We solved this problem by placing rate delimiters at the producers and on brokers at which different producers’ notification streams join. Only notifications necessary to meet the subscribers’ requirements will then pass through the network. To achieve this, we extended contentbased routing algorithms so they could cope with rate delimiters. Having individual delimiters for each subscription requires the routers to keep every subscription’s delimiter state. Therefore, the infrastructure should merge rate delimiters when possible. For example, Figure 4 (next page) depicts a subscription with a rate of 500 msec and another with a 1-sec rate, realized by placing a 500-msec delimiter (shown as triangles in the figure) at the outgoing links of B1 and B2 connected to B3 and a 500-msec and a 1-sec delimiter at the outgoing links of B3 leading to B4 and B5, respectively. Although the order in which notifications arrive at the delimiters can influence


MAY • JUNE 2004

51

Data Dissemination on the Web pub(n) at {201, 504, 601, 710, 920} msec

pub(n) at {128, 384, 745, 798, 1295} msec

X1

X2

B1

B2

F at 500 msec

F at 500 msec 1295 745 128

710 201

Junction broker

B3 F at 500 msec 1295 710 128 B4

In general, merging rates creates a resulting rate that equals the greatest common divider (GCD) of the merged rates. Hence, we express rates as the power of a natural number multiplied by a constant such as 100, 200, 400, 800, or 1,600 msec, or at least as multiples of some sensible quantum like 250 msec. In the former case, the resulting rate equals the minimum of the merged rates, while in the latter case it equals the GCD, which is bounded below by the quantum. Directed diffusion12 uses another alternative — it always propagates the minimum rate among some rates — but it can result in consumers receiving too few or too many notifications. For many applications, this might be acceptable. We are currently investigating another method, which lets clients specify a range (such as 500–700 msec), from which the system picks the most feasible rate.

F at 1 sec 1295 128 B5

X4

X5

sub(F) at rate 500 msec

sub(F) at rate 1 sec

Figure 4. Limiting delivery rates. The infrastructure uses rate delimiters to filter out unnecessary notifications close to producers X1 and X2.The bold numbers represent the time of a notification’s publication.

Infrastructure traffic (messages)

6*106 5*106 4*106 3*106 2*106 k=0 k=1 k=2 k=3 k=4

6

10

0 0

1,000

2,000

3,000 4,000 5,000 Number of clients

6,000

7,000

8,000

Figure 5. Effect of rate delimiters on infrastructure traffic. The infrastructure can save large amounts of network bandwidth when it applies rate delimiters. the set of notifications that the infrastructure delivers to a client, for many applications this might not raise a problem.

52

MAY • JUNE 2004


Experimental Results We conducted experiments to evaluate our approach using a hierarchical broker network with 1, 3, 9, 27, and 81 brokers on the levels, resulting in 121 overall. An equal number of clients connected to each broker at the lowest level, and each client subscribed randomly to 10 out of 200 available stocks. The root broker published stock quotes every 100 msec. We used five different distributions of subscription rates (k ∈ {0,1,2,3,4}). We expressed the probability that a client has the rate 4r · 100 msec by p(r,k) = 2r/(2k+1 – 1), where 0 ≤ r ≤ k. This covered rates of up to approximately 4 minutes. For example, for k = 0, all clients use a rate of 100 msec, which equals the publication rate. This scenario established the equivalent of a system without rate delimiters because a subscribed client would get all published quotes. For k = 1, two rates exist: rate 100 msec (r = 0) has probability 1/3, and rate 400 msec (r = 1) has probability 2/3. We considered these rate distributions justified because a majority of clients will prefer a lower rate for cost and capacity reasons. Under this scenario, it sufficed that a broker propagated those subscriptions toward the source with the smallest rate among the subscriptions regarding a specific stock. Figure 5 shows the results of our experiments. It depicts the traffic in the infrastructure over the number of issued subscriptions. Without rate delimiters (k = 0), the network traffic rises quickly with an increasing number of subscriptions and then slowly converges to a maximum. Applying rate delimiters substantially reduces the number of messages the infrastructure transports. The net-



work traffic rises more slowly at the beginning and converges to the maximum limit only for a very large number of subscribers (which Figure 5 does not show). Thus, rate delimiters increase the system’s scalability, and filtering improves performance even for larger numbers of clients. Furthermore, rate delimiters are still effective even if some of the clients receive the highest notification rate.

Conclusion Mobile clients present many challenges. In particular, building a dissemination infrastructure for mobile clients is a complex task. Our Rebeca implementation is a good starting point for such an infrastructure. However, increasing the efficiency of the applied algorithms requires further efforts. Currently, we are developing a tiny version of Rebeca that runs on small sensor nodes and supports in-network event aggregation. For example, a monitor process might be interested in events that indicate that the daily average temperature in a geographical region fell below a certain threshold, but the individual sensors only sense the temperature periodically. In such a scenario, the infrastructure can save large amounts of network bandwidth and battery capacity when it aggregates the sensed temperatures close to the publishing nodes instead of propagating all of them to the consumer. Acknowledgments We thank Ludger Fiege, Felix Gärtner, Andreas Tanner, and our other colleagues in the Rebeca project.

References 1. M.J. Franklin and S.B. Zdonik, “‘Data In Your Face’: Push Technology in Perspective,” Proc. ACM SIGMOD Int’l Conf. Management of Data, ACM Press, 1998, pp. 516–519. 2. S. Acharya, M. Franklin, and S. Zdonik, “Balancing Push and Pull for Data Broadcast,” Proc. ACM SIGMOD Int’l Conf. Management of Data, ACM Press, 1997, pp. 183–194. 3. A. Carzaniga, D.S. Rosenblum, and A.L. Wolf, “Design and Evaluation of a Wide-Area Event Notification Service,” ACM Trans. Computer Systems, vol. 19, no. 3, 2001, pp. 332–383. 4. G. Mühl, Large-Scale Content-Based Publish/Subscribe Systems, PhD thesis, Darmstadt Univ. of Technology, 2002; http://elib.tu-darmstadt.de/diss/000274/. 5. P. Deolasee et al., “Adaptive Push-Pull: Dissemination of Dynamic Web Data,” IEEE Trans. Computers, vol. 51, no. 6, 2001, pp. 652–668. 6. G. Cugola, E. Di Nitto, and A. Fuggetta, “The JEDI EventBased Infrastructure and Its Application to the Development of the OPSS WFMS,” IEEE Trans. Software Eng., vol.


27, no. 9, 2001, pp. 827–850. 7. M. Caporuscio, A. Carzaniga, and A.L. Wolf, “Design and Evaluation of a Support Service for Mobile, Wireless Publish/Subscribe Applications,” IEEE Trans. Software Eng., vol. 29, no. 12, 2003, pp. 1059–1071. 8. A. Zeidler and L. Fiege, “Mobility Support with Rebeca,” Proc. 23rd Int’l Conf. Distributed Computing Systems Workshops (ICDCSW ‘03), IEEE CS Press, 2003, pp. 354–361. 9. L. Fiege et al., “Supporting Mobility in Content-Based Publish/Subscribe Middleware,” Proc. ACM/IFIP/Usenix Int’l Middleware Conf. (Middleware 2003), LNCS 2672, Springer-Verlag, 2003, pp. 103–122. 10. M. Cilia et al., “Looking into the Past: Enhancing Mobile Publish/Subscribe Middleware,” Proc. 2nd Int’l Workshop on Distributed Event-Based Systems (DEBS ’03), ACM Press, 2003, pp. 1–8. 11. S. Shah and K. Ramamritham, “Maintaining Coherency of Dynamic Data in Cooperating Repositories,” Proc. 28th Int’l Conf. Very Large Databases (VLDB ‘02), Morgan Kaufman, 2002, pp. 526–537. 12. C. Intanagonwiwat et al., “Directed Diffusion for Wireless Sensor Networking,” IEEE/ACM Trans. Networking, vol. 11, no. 1, Feb. 2003, pp. 2–16. Gero Mühl is a postdoctoral researcher at the Berlin University of Technology. His research interests include middleware, event-based systems, self-organization, and mobile computing. Mühl received a PhD in computer science from the Darmstadt University of Technology. Contact him at [email protected]. Andreas Ulbrich is a PhD student at the Berlin University of Technology. His research interests include middleware, adaptation, and event-based systems. Ulbrich holds a master’s degree (Diplom-Informatiker) in computer science from the Chemnitz University of Technology. Contact him at [email protected]. Klaus Herrmann is a PhD student at the Berlin University of Technology. His research interests include self-organization principles in mobile networks, event-based middleware systems, and mobile agents. Herrmann holds a master’s degree (Diplom-Informatiker) in computer science from the Goethe University of Frankfurt. Contact him at [email protected]. Torben Weis is a PhD student at the Berlin University of Technology. His research interests include CASE tools, model-driven development, and embedded systems. Weis holds a master’s degree (Diplom-Informatiker) in computer science from the Goethe University of Frankfurt. Contact him at [email protected].


MAY • JUNE 2004

53