DOI 10.1007s00779-005-0037-4 ORIGINAL ARTICLE

发布于:2021-06-13 08:07:52

Pers Ubiquit Comput (2006) 10: 28–36 DOI 10.1007/s00779-005-0037-4


Mirco Musolesi ? Cecilia Mascolo ? Stephen Hailes

EMMA: Epidemic Messaging Middleware for Ad hoc networks

Received: 10 July 2004 / Accepted: 17 November 2004 / Published online: 19 August 2005 ? Springer-Verlag London Limited 2005

Abstract The characteristics of mobile environments, with the possibility of frequent disconnections and ?uctuating bandwidth, have forced a rethink of traditional middleware. In particular, the synchronous communication paradigms often employed in standard middleware do not appear to be particularly suited to ad hoc environments, in which not even the intermittent availability of a backbone network can be assumed. Instead, asynchronous communication seems to be a generally more suitable paradigm for such environments. Message oriented middleware for traditional systems has been developed and used to provide an asynchronous paradigm of communication for distributed systems, and, also for some speci?c mobile computing systems recently. In this paper, we present our experience in designing, implementing, and evaluating Epidemic Messaging Middleware for Ad hoc networks (EMMA), an adaptation of Java Message Service (JMS) for mobile ad hoc environments, discussing in detail the design challenges and the solutions that have been adopted. Keywords Message oriented middleware ? Middleware for mobile computing ? Epidemic protocol ? Mobile ad hoc networks

1 Introduction
With the increasing popularity of mobile devices and their widespread adoption, there is a clear need to allow the development of a broad spectrum of applications that operate e?ectively over such an environment. Unfortunately, this is far from being simple: mobile devices are increasingly heterogeneous in terms of processing capabilities, memory size, battery capacity, and network
M. Musolesi (&) ? C. Mascolo ? S. Hailes Department of Computer Science, University College London, Gower Street, London, WC1E 6BT United Kingdom E-mail:

interfaces. Each such con?guration has substantially di?erent characteristics that are both statically di?erent for example, there is a major di?erence in capability between a Berkeley mote and an 802.11g-equipped laptop and that varies dynamically, as in situations of ?uctuating bandwidth and intermittent connectivity. Mobile ad hoc environments have an additional element of complexity in that they are entirely decentralised. In order to craft applications for such complex environments, an appropriate form of middleware is essential if cost e?ective development is to be achieved. In this paper, we examine one of the foundational aspects of middleware for mobile ad hoc environments—that of the communication primitives. Traditionally, the most frequently used middleware primitives for communication assume the simultaneous presence of both end points on a network, since the stability and pervasiveness of the networking infrastructure is not an unreasonable assumption for most wired environments. In other words, most communication paradigms are synchronous: object oriented middleware such as Java RMI and CORBA are typical examples of middleware based on synchronous communication. In recent years, there has been a growing interest in platforms based on asynchronous communication, such as publish-subscribe systems [6]; these have been exploited very successfully where there is application level asynchronicity. This is an extract from a Gartner Market Report [7]: ‘‘Given message-oriented middleware’s (MOM) popularity, scalability, ?exibility, and a?nity with mobile and wireless architectures, by 2004 MOM will emerge as the dominant form of communication middleware for linking mobile and enterprise applications (0.7 probability)...’’. Moreover, in mobile ad hoc systems, the likelihood of network fragmentation means that synchronous communication may in any case be impracticable, giving situations in which delay tolerant asynchronous tra?c is the only form of tra?c that could be supported. Middleware for mobile ad hoc environments must therefore support semi-synchronous


or completely asynchronous communication primitives if it is to avoid substantial limitations to its utility. Aside from the intellectual challenge in supporting this model, this work is also interesting because there are a number of practical application domains in allowing inter-community communication in undeveloped areas of the globe. Thus, for example, projects that have been carried out to help populations that live in remote places of the globe such as Lapland [3] or in poor areas that lack ?xed connectivity infrastructure [9]. There have been attempts to provide mobile middleware with these properties, including STEAM, LIME, XMIDDLE, Bayou (see [11] for a more complete review of mobile middleware). These models di?er quite considerably from the existing traditional middleware in terms of primitives provided. Furthermore, some of them fail in providing a solution for the true ad hoc scenarios. If the projected success of MOM becomes anything like a reality, there will be many programmers with experience in it. The ideal solution to the problem of middleware for ad hoc systems is, then, to allow programmers to utilise the same paradigms and models presented by common forms of MOM and to ensure that these paradigms are supportable within the mobile environment. This approach has clear advantages in allowing applications developed on standard middleware platforms to be easily deployed on mobile devices. Indeed, some research has already led to the adaptation of traditional middleware platforms to mobile settings, mainly to provide integration between mobile devices and existing ?xed networks in a nomadic (i.e. mixed) environment [4]. With respect to message oriented middleware, the current implementations, however, either assume the existence of a backbone network to which the mobile hosts connect from time to time while roaming [10] or assume that nodes are always somehow reachable through a path [20]. No adaptation to heterogeneous or completely ad hoc scenarios, with frequent disconnection and periodically isolated clouds of hosts, has been attempted. In the remainder of this paper we describe an initial attempt to adapt message oriented middleware to suit mobile and, more speci?cally, mobile ad hoc networks. In our case, we elected to examine JMS, as one of the most widely known MOM systems. In the latter part of this paper, we explore the limitations of our results and describe the plans we have to take the work further.

2 Message oriented middleware and JMS
Message-oriented middleware systems support communication between distributed components via messagepassing—the sender sends a message to identi?ed queues, which usually reside on a server. A receiver retrieves the message from the queue at a di?erent time and may acknowledge the reply using the same asynchronous

mechanism. Message-oriented middleware thus supports asynchronous communication in a very natural way, achieving de-coupling of senders and receivers. A sender is able to continue processing as soon as the middleware has accepted the message; eventually, the receiver will send an acknowledgment message and the sender will be able to collect it at a convenient time. However, given the way they are implemented, these middleware systems usually require resource-rich devices, especially in terms of memory and disk space, where persistent queues of messages that have been received but not yet processed, are stored. Sun JMS [5] and IBM WebSphere MQ [6] are examples of very successful message-oriented middleware for traditional distributed systems. The JMS is a collection of interfaces for asynchronous communication between distributed components. It provides a common way for Java programs to create, send, and receive messages. JMS users are usually referred to as clients. The JMS speci?cation further de?nes providers as the components in charge of implementing the messaging system and providing the administrative and control functionality (i.e. persistence and reliability) required by the system. Clients can send and receive messages, asynchronously, through the JMS provider, which is in charge of the delivery and, possibly, of the persistence of the messages. There are two types of communication supported: point-to-point and publish-subscribe models. In the pointto-point model, hosts send messages to queues. Receivers can be registered with some speci?c queues, and can asynchronously retrieve the messages and then acknowledge them. The publish-subscribe model is based on the use of topics that can be subscribed to by clients. Messages are sent to topics by other clients and are then received in an asynchronous mode by all the subscribed clients. Clients learn about the available topics and queues through Java Naming and Directory Interface (JNDI) [16]. Whilst the JMS speci?cation has been extensively implemented and used in traditional distributed systems, adaptations for mobile environments have been proposed only recently. The challenges of porting JMS to mobile settings are considerable; however, in view of its widespread acceptance and use, there are considerable advantages in allowing the adaptation of existing applications to mobile environments and in allowing the interoperation of applications in the wired and wireless regions of a network. Mobile networks vary very widely in their characteristics from nomadic networks in which modes relocate whilst o?ine through to ad hoc networks in which modes move freely and in which there is no infrastructure. Mobile ad hoc networks are most generally applicable in situations where survivability and instant deployability are the keys—most notably in military applications and disaster relief. In between these two types of mobile networks, there are, however, a number of possible heterogeneous combinations, where nomadic and ad hoc paradigms are used to interconnect totally


unwired areas to more structured networks (such as a LAN or the Internet). In [10], for example, JMS was adapted to a nomadic mobile setting, where mobile hosts can be JMS clients and communicate through the JMS provider that, however, sits on a backbone network, providing reliability and persistence. The client prototype presented in [10] is very lightweight, due to the delegation of all the heavyweight functionality to the provider on the wired network. However, this approach is somewhat limited in terms of widespread applicability and scalability as a consequence of the concentration of functionality in the wired portion of the network. If JMS is to be adapted to completely ad hoc environments, where no ?xed infrastructure is available, and where nodes change location and status very dynamically, more issues must be taken into consideration. In the following section, we will discuss our experience in designing and implementing JMS for mobile ad hoc networks.

3 Design of a message oriented middleware for mobile ad hoc networks
3.1 Adaptation of JMS for mobile ad hoc networks We now describe EMMA, our initial attempt to adapt the JMS speci?cation to target the particular requirements related to ad hoc scenarios. As discussed in Sect. 2, a JMS application can use either the point-to-point or the publish-subscribe styles of messaging. 3.1.1 Point-to-point model The point-to-point model is based on the concept of queues that are used to enable asynchronous communication between the producer of a message and possible di?erent consumers. In our solution, the location of queues is determined by a negotiation process that is application dependent. For example, let us suppose that it is possible to know a priori, or it is possible to determine dynamically, that a certain host is the receiver of the most part of messages sent to a particular queue. In this case, the optimum location of the queue may well be on this particular host. In general, it is worth noting that, according to the JMS speci?cation and suggested design patterns, it is common and preferable for a client to have all of its messages delivered to a single queue. Queues are advertised periodically to the hosts that are within transmission range or that are reachable by means of the underlying synchronous communication protocol, if provided. It is important to note that, at the middleware level, it is logically irrelevant whether or not the network layer implements some form of ad hoc routing (though considerably more e?cient if it does); the middleware only considers information about which nodes are actively reachable at any point in time. The hosts that receive advertisement messages add entries to

their JNDI registry. Each entry is characterized by a lease (a mechanism similar to that present in Jini [17]). A lease represents the time of validity of a particular entry. If a lease is not refreshed (i.e. its life is not extended), it can expire and, consequently the entry is deleted from the registry. In other words, the host assumes that the queue will be unreachable from that point of time. This may be caused, for example, if a host storing the queue becomes unreachable. A host that initiates a discovery process will ?nd the topics and the queues present in its connected portion of the network in a straightforward manner. In order to deliver a message to a host that is not currently in reach1, we use an asynchronous epidemic routing protocol that will be discussed in detail in Sect. 3.2. If two hosts are in the same cloud (i.e. a connected path exists between them), but no synchronous protocol is available, the messages are sent using the epidemic protocol. In this case, the delivery latency will be low as a result of the rapidity of propagation of the infection in the connected cloud (see also the simulation results in Sect. 4). Given the existence of an epidemic protocol, the discovery mechanism consists of advertising the queues to the hosts that are currently unreachable using analogous mechanisms. 3.1.2 Publish-subscribe model In the publish-subscribe model, some of the hosts are similarly designated to hold topics and store subscriptions, as before. Topics are advertised through the registry in the same way as with queues, and a client wishing to subscribe to a topic must register with the client holding the topic. When a client wishes to send a message to the topic list, it sends it to the topic holder (in the same way as it would send a message to a queue). The topic holder then forwards the message to all subscribers, using the synchronous protocol if possible, the epidemic protocol otherwise. It is worth noting that we use a single message with multiple recipients, instead of multiple messages with multiple recipients. When a message is delivered to one of the subscribers, this recipient is deleted from the list. In order to delete the other possible replicas, we employ acknowledgment messages (discussed in Sect. 4), returned in the same way as a normal message. We have also adapted the concepts of durable and non-durable subscriptions for ad hoc settings. In ?xed platforms, durable subscriptions are maintained during the disconnections of the clients, whether these are intentional or are the result of failures. In traditional systems, while a durable subscriber is disconnected from the server, it is responsible for storing messages. When the durable subscriber reconnects, the server sends it all
1 In theory, it is not possible to send a message to a peer that was never reachable in the past, since there is no entry present in the registry. However, to overcome this limitation, we provide a primitive through which information can be added to the registry.


unexpired messages. The problem is that, in our scenario, disconnections are the norm rather than the exception. In other words, we cannot consider disconnections as failures. For these reasons, we adopt a slightly di?erent semantics. With respect to durable subscriptions, if a subscriber becomes disconnected, noti?cations are not stored but are sent using the epidemic protocol rather than the synchronous protocol. In other words, durable noti?cations remain valid during the possible disconnections of the subscriber. On the other hand, if a non-durable subscriber becomes disconnected, its subscription is deleted; in other words, during disconnections, noti?cations are not sent using the epidemic protocol but exploit only the synchronous protocol. If the topic becomes accessible to this host again, it must make another subscription in order to receive the noti?cations. Unsubscription messages are delivered in the same way as with subscription messages. It is important to note that durable subscribers have to explicitly unsubscribe from a topic in order to stop the noti?cation process; however, all durable subscriptions have a prede?ned expiration time in order to cope with the cases of subscribers that do not meet again because of their movements or failures. This feature is clearly provided to limit the number of the unnecessary messages sent around the network. 3.2 Message delivery using epidemic routing In this section, we examine one possible mechanism that will allow the delivery of messages in a partially connected network. The mechanism we discuss is intended for the purposes of demonstrating feasibility; more e?cient communication mechanisms for this environment are themselves complex, and are the subject of another paper [14]. The asynchronous message delivery described above is based on a typical pure epidemic-style routing protocol [18]. A message that needs to be sent is replicated on each host in reach. In this way, copies of the messages are quickly spread through connected networks, like an infection. If a host becomes connected to another cloud of mobile nodes during its movement, the message spreads through this collection of hosts. Epidemic-style replication of data and messages has been exploited in the past in many ?elds starting with the distributed database systems area [2]. Within epidemic routing, each host maintains a bu?er containing the messages that it has created and the replicas of the messages generated by the other hosts. To improve the performance, a hash-table indexes the content of the bu?er. When two hosts connect, the host with the smaller identi?er initiates a so-called anti-entropy session, sending a list containing the unique identi?ers of the messages that it currently stores. The other host evaluates this list and sends back a list containing the identi?ers it is storing that are not present in the

other host, together with the messages that the other does not have. The host that has started the session receives the list and, in the same way, sends the messages that are not present in the other host. Should bu?er over?ow occur, messages are dropped. The reliability o?ered by this protocol is typically the best e?ort, since there is no guarantee that a message will eventually be delivered to its recipient. Clearly, the delivery ratio of the protocol increases proportionally to the maximum allowed delay time and the bu?er size in each host (interesting simulation results may be found in [18]). 3.3 Adaptation of the JMS message model In this section, we will analyse the aspects of our adaptation of the speci?cation related to the so-called JMS message model [5]. According to this, JMS messages are characterised by some properties de?ned using the header ?eld, which contains values that are used by both clients and providers for their delivery. The aspects discussed in the remainder of this section are valid for both models (point-to-point and publish-subscribe). A JMS message can be persistent or non-persistent. According to the JMS speci?cation, persistent messages must be delivered with a higher degree of reliability than the non-persistent ones. However, it is worth noting that it is not possible to ensure once-and-only-once reliability for persistent messages as de?ned in the speci?cation, since, as we discussed in the previous subsection, the underlying epidemic protocol can guarantee only beste?ort delivery. However, clients maintain a list of the identi?ers of the recently received messages to avoid the delivery of message duplicates. In other words, we provide the applications with at-most-once reliability for both types of messages. In order to implement di?erent levels of reliability, EMMA treats persistent and non-persistent messages di?erently, during the execution of the anti-entropy epidemic protocol. Since the message bu?er space is limited, persistent messages are preferentially replicated using the available free space. If this is insu?cient and non-persistent messages are present in the bu?er, these are replaced. Only the successful deliveries of the persistent messages are noti?ed to the senders. According to the JMS speci?cation, it is possible to assign a priority to each message. The messages with higher priorities are delivered in a preferential way. As discussed above, persistent messages are prioritised above the non-persistent ones. Further selection is based on their priorities. Messages with higher priorities are treated in a preferential way. In fact, if there is not enough space to replicate all the persistent messages, a mechanism based on priorities is used to delete and replicate non-persistent messages (and, if necessary, persistent messages). Messages are deleted from the bu?ers using the expiration time values that can be set by senders. This is


a way to free space in the bu?ers (one preferentially deletes older messages in cases of con?ict), to eliminate stale replicas in the system, and to limit the time for which destinations must hold message identi?ers to dispose of duplicates. 3.4 Reliability and acknowledgment mechanisms As already discussed, at-most-once message delivery is the best that can be achieved in terms of delivery semantics in partially connected ad hoc settings. However, it is possible to improve the reliability of the system with e?cient acknowledgment mechanisms. EMMA provides a mechanism for failure noti?cation to applications if the acknowledgment is not received within a given timeout (that can be con?gured by application developers). This mechanism is the one that distinguishes the delivery of persistent and non-persistent messages in our JMS implementation—the deliveries of the former are noti?ed to the senders, whereas the latter are not. We use acknowledgment messages not only to inform senders about the successful delivery of messages but also to delete the replicas of the delivered messages that are still present in the network. Each host maintains a list of the messages successfully delivered that is updated as part of the normal process of information exchange between the hosts. The lists are exchanged during the ?rst steps of the anti-entropic epidemic protocol with a certain prede?ned frequency. In the case of messages with multiple recipients, a list of the actual recipients is also stored. When a host receives the list, it checks its message bu?er and updates it according to the following rules: (1) if a message has a single recipient and it has been delivered, it is deleted from the bu?er; (2) if a message has multiple recipients, the identi?ers of the delivered hosts are deleted from the associated list of recipients. If the resulting length of the list of recipients is zero, the message is deleted from the bu?er. These lists have, clearly, ?nite dimensions and are implemented as circular queues. This simple mechanism, together with the use of expiration timestamps, guarantees that the old acknowledgment noti?cations are deleted from the system after a limited period of time. In order to improve the reliability of EMMA, a design mechanism for intelligent replication of queues and topics based on the context information could be developed. However this is not yet part of the current architecture of EMMA.

The communication infrastructure is based on sockets. We have tested our prototype on HP IPaq PDAs running Linux and interconnected with WaveLan and on a number of laptops with the same network interface. We also evaluated the middleware platform using the OMNeT++ discrete event simulator [19] in order to have some simulation results considering the scenario composed of a realistic number of hosts. This environment o?ers broad functionalities that facilitate the development and the optimisation of the simulation code. 4.1 Description of the simulation We simulated the delivery of messages using the epidemic protocol in the case of one recipient (i.e. topic subscriptions and point-to-point message delivery) and in the case of multiple recipients (i.e. noti?cations to multiple subscribers). We assumed that no synchronous protocol is present in the underlying network layer. We used a group mobility model with movement patterns similar to those described in [13]. We evaluated the performance of the system in terms of the delivery ratios and delays of persistent messages by sending 200 messages (50% persistent and 50% non-persistent, with di?erent priorities). Furthermore, we analysed the impact of the use of priorities in a di?erent simulation scenario, sending 300 persistent messages in three priority classes (100 messages for each class). We performed this simulation in order to understand the in?uence of priorities; moreover, the case of persistent messages only in the system is an interesting limit case. In all the simulations, the priority and the type of persistence of each message are generated using uniform distributions. The intervals between each message are modelled as a Poisson process. All the messages are sent in 20 s. The sender and receiver of each message are chosen randomly. The bu?er for each node is set to 100 messages, unless otherwise speci?ed. In the case of subscriber noti?cations, we set the number of recipients to 80% of the number of hosts; this scenario allows us to evaluate the performance of the delivery mechanisms based on the dissemination of the messages using the epidemic protocol. We consider three mobile scenarios composed of 16, 24, and 32 hosts in a 1 km2 simulation area. We assume an omnidirectional antenna that transmits according to a free space model with a transmission range equal to 200 m. The maximum allowed delay time is set to 4 min. 4.2 Analysis of results

4 Implementation and evaluation
We have implemented a prototype of our platform using the J2ME Personal Pro?le [15]. The size of the executable is about 250 KB including the JMS 1.1 jar ?le; this is a perfectly acceptable ?gure given the available memory of the current mobile devices on the market. In this subsection we analyse the results of our simulations, presenting the performance of our platform and discussing the variation of some performance indicators as functions of the density of hosts (i.e. the number of


the hosts in the simulation area) and the size of the bu?ers used to store messages. 4.2.1 Point-to-point model Figure 1 shows the dependency of the delivery ratio of persistent and non-persistent messages on the bu?er size, in the case of a scenario with 32 hosts. As expected, the bu?er size has a strong impact on the performance of the platform. Therefore, the choice of the correct dimension of the bu?er is a key aspect of the deployment of the platform. However, in general, the maximum size of bu?ers is also constrained by the limited amount of available memory of mobile devices. Figure 2 shows the distribution of the average delay for the point-to-point delivery (32 hosts scenario); a proportion of the messages are delivered more or less immediately, since the recipients are in the same cloud as the sender. Figure 3 shows the delivery ratio of persistent messages with di?erent priorities (300 persistent messages with three uniformly distributed levels of priorities as described above, with a bu?er size equal to 100). 4.2.2 Publish-subscribe model Figure 4 shows the distribution of the delivery ratio of persistent and non-persistent messages in a 32 hosts scenario. In the case of the publish-subscribe model, the term delivery ratio indicates the average percentage of the potential recipients that actually received the message. Figure 5 shows the distributions of the delivery ratio of persistent and non-persistent messages with multiple recipients with respect to bu?er size, respectively (in the case of the scenario with 32 hosts). In Fig. 6, a graphical representation of the variation of the delivery ratio with respect to the population density (considering scenarios with 16, 24, and 32 hosts, with a bu?er size equal to 100) is presented. As expected, the delivery ratio increases as the population density increases.

Fig. 2 point-to-point model (32 hosts scenario): delay time distribution of persistent and non-persistent messages

Fig. 3 point-to-point model (32 hosts scenario): delivery ratio of persistent messages with di?erent priorities versus bu?er size

Fig. 1 point-to-point model (scenario with 32 hosts): delivery ratio of persistent and non-persistent messages versus bu?er size

The simulation results show that the performance provided by the platform in terms of delivery ratio and delay of persistent messages and messages with higher priorities is good. This is a direct consequence of the exploitation of epidemic techniques [18]. However, it is worth noting that, in general, it is quite di?cult to o?er high degree of scalability in peer-to-peer middleware for mobile computing due to the characteristics of the devices (limited memory to store messages temporarily) and the number of possible interconnections in ad hoc settings. Nevertheless, the number of nodes of many potential application scenarios that could be envisaged is quite limited due to the intrinsic communication patterns and organisational boundaries. Moreover, it is worth noting that the dimension of the bu?er may be chosen both in accordance with the application requirements and considering the resources of the devices. For larger application scenarios, where the number of hosts is considerably higher or where the messages exchanged are in high number, we are studying a variation of the delivery mechanism presented that uses probabilistic and statistical techniques to reduce the number of message replicas present at the same time in the system


Fig. 4 Publish-Subscribe model (32 hosts scenario): delivery ratio distribution of persistent and non-persistent messages

Fig. 6 Publish-subscribe model (32 hosts scenario): delivery ratio distribution of persistent messages versus population density

Fig. 5 Publish-subscribe model (32 hosts scenario): delivery ratio distribution of persistent messages versus bu?er size

[14]. The description of the protocol is however outside the scope of this paper.

5 Discussion and related work
The design of middleware platforms for mobile computing requires researchers to answer new and fundamentally di?erent questions; simply assuming the presence of wired portions of the network on which centralised functionality can reside is not generalisable. Thus, it is necessary to investigate novel design principles and to devise architectural patterns that di?er from those traditionally exploited in the design of middleware for ?xed systems. As an example, consider the recent cross-layering trend in ad hoc networking [1]. This is a way of rethinking software systems design, explicitly abandoning the classical forms of layering, since, although this separation of concerns a?ord portability, it does so at the expense of potential e?ciency gains. We believe that it is possible to view our approach as an instance of crosslayering. In fact, we have added the epidemic network protocol at middleware level and, at the same time, we

have used the existing synchronous network protocol if present both in delivering messages (traditional layering) and in informing the middleware about when messages may be delivered by revealing details of the forwarding tables (layer violation). For this reason, we prefer to consider them jointly as the communication layer of our platform together providing more e?cient message delivery. Another interesting aspect is the exploitation of context and system information to improve the performance of mobile middleware platforms. Again, as a result of adopting a cross-layering methodology, we are able to build systems that gather information from the underlying operating system and communication components in order to allow for adaptation of behaviour. We can summarise this conceptual design approach by saying that middleware platforms must be not only context-aware (i.e. they should be able to extract and analyse information from the surrounding context) but also system-aware (i.e., they should be able to gather information from the software and hardware components of the mobile system). A number of middleware systems have been developed to support ad hoc networking with the use of asynchronous communication [11] (such as LIME, XMIDDLE, STEAM). In particular, the STEAM [12] platform is an example of event-based middleware for ad hoc networks, providing location-aware message delivery and an e?ective solution for event ?ltering. In STEAM the communication is limited to the hosts that are in the same radio range sets of interests are also used to reduce the computational complexity of the process of message ?ltering. STEAM o?ers an interesting contentbased model, but its possible applications are limited to speci?c scenarios, where the interaction among hosts belonging to di?erent clouds is not necessary. EMMA, instead, supports communication also among hosts that are intermittently disconnected. A discussion of JMS, and its mobile realisation, has already been conducted in Sect. 2. The Swiss company Softwired has developed the ?rst JMS middleware for mobile computing, called iBus Mobile [10]. The main


components of this typically infrastructure-based architecture are the JMS provider, the so-called mobile JMS gateway, which is deployed on a ?xed host, and a lightweight JMS client library. The gateway is used for the communication between the application server and mobile hosts. The gateway is seen by the JMS provider as a normal JMS client. Pronto [21] is an example of middleware system based on messaging that is speci?cally designed for mobile environments. The platform is composed of three classes of components: mobile clients implementing the JMS speci?cation, gateways that control tra?c, guaranteeing e?ciency and possible user customizations using di?erent plug-ins and JMS servers. Moreover, di?erent con?gurations of these components are possible. Pronto represents a good solution for infrastructure-based mobile networks but it does not adequately target ad hoc settings, since mobile nodes rely on ?xed servers for the exchange of messages. Other MOM implemented for mobile environments exist; however, they are usually straightforward extensions of existing middleware such as [8]. The only implementation of MOM speci?cally designed for mobile ad hoc networks was developed at the University of Newcastle [20]. This work is again a JMS adaptation; the focus of that implementation is on group communication and the use of application level routing algorithms for topic delivery of messages. However, there are a number of di?erences in the focus of our work. The importance that we attribute to disconnections makes persistence a vital requirement for any middleware that needs to be used in mobile ad hoc networks. The authors of [20] signal persistence as possible future work, not considering the fact that routing a message to a nonconnected host will result in delivery failure. This is a remarkable limitation in mobile settings where unpredictable disconnections are the norm rather than the exception.

forming epidemic algorithm in terms of the number of replicas that are spread across the network. An important advance in the practicability of this work requires an algorithm that better balances the needs of e?ciency and message delivery probability. We are currently working on algorithms and protocols that, exploiting probabilistic and statistical techniques on the basis of small amounts of exchanged information, are able to improve considerably the e?ciency in terms of resources (memory, bandwidth, etc) and the reliability of our middleware platform [14].

1. Conti M, Maselli G, Turi G, Giordano S (2004) Cross-layering in mobile ad hoc network design. IEEE Comput 37(2):48–51 2. Demers A, Greene D, Hauser C, Irish W, Larson J, Shenker S, Sturgis H, Swinehart D, Terry D (1987) Epidemic algorithms for replicated database maintenance. In: Sixth symposium on principles of distributed computing, pp 1–12 3. Doria A, Uden M, Pandey DP (2002) Providing connectivity to the Saami nomadic community. In: Proceedings of the second international conference on open collaborative design for sustainable innovation 4. Haahr M, Cunningham R, Cahill V (1999) Supporting CORBA applications in a mobile environment. In: Proceedings of MOBICOM’99), pp 36–47 5. Hapner M, Burridge R, Sharma R, Fialli J, Stout K (2002) Java message service speci?cation version 1.1. Sun Microsystems, Inc., 6. Hart J (2003) Web Sphere MQ: connecting your applications without complex programming.IBM WebSphere Software White Papers 7. Hayward S, Pezzini M (2001) Marrying middleware and mobile computing. Gartner Group Research Report 8. IBM (2002) WebSphere MQ EveryPlace Version 2.0, http:// 9. ITU (2003) Connecting remote communities. Documents of the World Summit on Information Society, spu/wsis-themes 10. Ma?eis S (2002) Introducing wireless JMS. Softwired AG, 11. Mascolo C, Capra L, Emmerich W (2002) Middleware for mobile computing. In: Gregori E, Anastasi G, Basagni S (eds) Advanced lectures on networking, vol 2497. Lecture Notes in Computer Science, Springer, Berlin Heidelberg New York, pp 20–58 12. Meier R, Cahill V (2002) STEAM: event-based middleware for wireless ad hoc networks. In: 22nd international conference on distributed computing systems workshops (ICDCSW ’02), pp 639–644 13. Musolesi M, Hailes S, Mascolo C (2004) An ad hoc mobility model founded on social network theory. In: Proceedings of the 7th ACM international symposium on Modeling, analysis and simulation of wireless and mobile systems. ACM Press, Venice, pp 20–24 14. Musolesi M, Hailes S, Mascolo C (2004) Adaptive routing for intermittently ad hoc networks. Proceedings of the IEEE 6th International Symposium on a World of Wireless Mobile and Multimedia Networks (WOWMOM 2005), Taormina, Italy 15. Sun Microsystems. J2ME Personal pro?le documentation. 16. Sun Microsystems (2003) Java naming and directory interface (JNDI) documentation version 1.2. 17. Sun Microsystems (2003) Jini speci?cation version 2.0, http://

6 Conclusions
Asynchronous communication is a useful paradigm for mobile ad hoc networks, as hosts are allowed to come, go, and pick up messages when convenient, also taking account their resource availability (e.g. power, connectivity levels). We have described EMMA that represents a proof of concept adaptation of JMS to the extreme scenario of partially connected mobile ad hoc networks. We have described and discussed the characteristics and di?erences of our solution with respect to traditional JMS implementations and the existing adaptations for mobile settings. EMMA provides very good performance in terms of delivery ratio and latency. However, trade-o?s between application-level routing and resource usage should also be investigated, as mobile devices are commonly power/resource scarce. In fact, a key limitation of this work is the poorly per-

36 18. Vahdat A, Becker D (2000) Epidemic routing for partially connected ad hoc networks. Technical Report CS-2000-06, Department of Computer Science, Duke University 19. Varga A (2001) The OMNeT++ discrete event simulation system. In: Proceedings of the European simulation multiconference (ESM’2001), Prague 20. Vollset E, Ingham D, Ezhilchelvan P (2003) JMS on mobile adhoc networks. In: Personal wireless communications 2003 (PWC ’03), Venice, pp 40–52 21. Yoneki E (2003) Pronto: mobilegateway with publish-subscribe paradigm over wireless networks. In: Middleware’03—work in progress session, number 4(5), IEEE DistributedSystems Online