the many faces of publish/subscribe - cs.ru.nlpieter/oss/manyfaces.pdf · the many faces of...

The Many Faces of Publish/Subscribe

PATRICK TH. EUGSTER

Swiss Federal Institute of Technology, Lausanne

PASCAL A. FELBER

Institut Eurecom

RACHID GUERRAOUI

Swiss Federal Institute of Technology, Lausanne

AND

ANNE-MARIE KERMARREC

Microsoft Research

Well adapted to the loosely coupled nature of distributed interaction in large-scaleapplications, the publish/subscribe communication paradigm has recently receivedincreasing attention. With systems based on the publish/subscribe interaction scheme,subscribers register their interest in an event, or a pattern of events, and aresubsequently asynchronously notified of events generated by publishers. Many variantsof the paradigm have recently been proposed, each variant being specifically adapted tosome given application or network model. This paper factors out the commondenominator underlying these variants: full decoupling of the communicating entitiesin time, space, and synchronization. We use these three decoupling dimensions to betteridentify commonalities and divergences with traditional interaction paradigms. Themany variations on the theme of publish/subscribe are classified and synthesized. Inparticular, their respective benefits and shortcomings are discussed both in terms ofinterfaces and implementations.

Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]:Distributed Systems—Distributed applications; D.1.3 [Programming Techniques]:Concurrent Programming—Distributed programming

General Terms: Design

Additional Key Words and Phrases: Distribution, interaction, publish/subscribe

1. INTRODUCTIONThe Internet has considerably changedthe scale of distributed systems. Dis-tributed systems now involve thousands of

Authors’ addresses: P. Th. Eugster and R. Guerraoui, Swiss Federal Institute of Technology, 1015 Lausanne,Switzerland; email: {patrick.eugster, rachid.guerraoui}@epfl.ch; P. A. Felber, Institut Eurecom, 2229 routesdes Cretes, 06904 Sophia Antipolis, France; email: [email protected]; A.-M. Kermarrec, MicrosoftResearch Ltd., 7 J. J. Thomson Ave., Cambridge CB3 0FB, U.K.; email: [email protected] to make digital/hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requiresprior specific permission and/or a fee.c©2003 ACM 0360-0300/03/0600-0114 $5.00

entities—potentially distributed all overthe world—whose location and behaviormay greatly vary throughout the life-time of the system. These constraints

ACM Computing Surveys, Vol. 35, No. 2, June 2003, pp. 114–131.

The Many Faces of Publish/Subscribe 115

Fig. 1 . A simple object-based publish/subscribe system.

visualize the demand for more flexi-ble communication models and systems,reflecting the dynamic and decouplednature of the applications. Individualpoint-to-point and synchronous commu-nications lead to rigid and static appli-cations, and make the development ofdynamic large-scale applications cumber-some. To reduce the burden of applicationdesigners, the glue between the differententities in such large-scale settings shouldrather be provided by a dedicated middle-ware infrastructure, based on an adequatecommunication scheme.

The publish/subscribe interaction sch-eme is receiving increasing attention andis claimed to provide the loosely coupledform of interaction required in such largescale settings. Subscribers have the abil-ity to express their interest in an event, ora pattern of events, and are subsequentlynotified of any event, generated by a pub-lisher, which matches their registered in-terest. An event is asynchronously prop-agated to all subscribers that registeredinterest in that given event. The strengthof this event-based interaction stylelies in the full decoupling in time, space,and synchronization between publishersand subscribers. Many industrial sys-tems and research prototypes support thisstyle of interaction, and there are severalprominent research efforts on novel formsof publish/subscribe interaction schemes.However, because of the multiplicity ofthese systems and prototypes, it is diffi-cult to capture their commonalities anddraw sharp lines between their mainvariations.

The aim of this paper is threefold.First we point out the common denomi-nators of publish/subscribe schemes: time,space, and synchronization decoupling ofsubscribers and publishers. These decou-pling dimensions are illustrated by com-paring the publish/subscribe paradigmwith “traditional” interaction schemes.Second, we compare the many variants ofpublish/subscribe schemes: namely, topic-based, content-based, and type-based.Third, we discuss variations and trade-offs in the design and implementation ofpublish/subscribe-based systems throughspecific examples.

2. THE BASIC INTERACTION SCHEME

The publish/subscribe interaction para-digm provides subscribers with the abilityto express their interest in an event or apattern of events, in order to be notifiedsubsequently of any event, generated bya publisher, that matches their registeredinterest. In other terms, producers publishinformation on a software bus (an eventmanager) and consumers subscribe to theinformation they want to receive fromthat bus. This information is typicallydenoted by the term event and the act ofdelivering it by the term notification.

The basic system model for publish/subscribe interaction (Figure 1) relies onan event notification service providingstorage and management for subscrip-tions and efficient delivery of events. Suchan event service represents a neutral me-diator between publishers, acting as pro-ducers of events, and subscribers, acting

ACM Computing Surveys, Vol. 35, No. 2, June 2003.

116 Eugster et al.

Fig. 2 . Space, time, and synchronization decoupling with the publish/subscribe paradigm.

as consumers of events. Subscribers reg-ister their interest in events by typicallycalling a subscribe() operation on theevent service, without knowing the effec-tive sources of these events. This sub-scription information remains stored inthe event service and is not forwardedto publishers. The symmetric operationunsubscribe() terminates a subscription.

To generate an event, a publisher typ-ically calls a publish() operation. Theevent service propagates the event to allrelevant subscribers; it can thus be viewedas a proxy for the subscribers. Note thatevery subscriber will be notified of everyevent conforming to its interest (obviously,failures might prevent subscribers fromreceiving some events). Publishers also of-ten have the ability to advertise the na-ture of their future events through anadvertise() operation. The provided in-formation can be useful for (1) the eventservice to adjust itself to the expectedflows of events, and (2) the subscribers tolearn when a new type of information be-comes available.

The decoupling that the event serviceprovides between publishers and sub-scribers can be decomposed along the fol-lowing three dimensions (Figure 2):

—Space decoupling: The interacting par-ties do not need to know each other.

The publishers publish events throughan event service and the subscribersget these events indirectly through theevent service. The publishers do not usu-ally hold references to the subscribers,neither do they know how many of thesesubscribers are participating in the in-teraction. Similarly, subscribers do notusually hold references to the publish-ers, neither do they know how many ofthese publishers are participating in theinteraction.

—Time decoupling: The interacting par-ties do not need to be actively parti-cipating in the interaction at the sametime. In particular, the publisher mightpublish some events while the sub-scriber is disconnected, and conver-sely, the subscriber might get notifiedabout the occurrence of some eventwhile the original publisher of the eventis disconnected.

—Synchronization decoupling: Publishersare not blocked while producing events,and subscribers can get asynchronouslynotified (through a callback) of the occur-rence of an event while performing someconcurrent activity. The production andconsumption of events do not happen inthe main flow of control of the publish-ers and subscribers, and do not thereforehappen in a synchronous manner.



Decoupling the production and con-sumption of information increases scala-bility by removing all explicit dependen-cies between the interacting participants.In fact, removing these dependenciesstrongly reduces coordination and thussynchronization between the different en-tities, and makes the resulting commu-nication infrastructure well adapted todistributed environments that are asyn-chronous by nature, such as mobile en-vironments [Huang and Garcia-Molina2001].

Complementary classifications of the in-teraction models of distributed informa-tion systems have been proposed in theliterature. Franklin and Zdonik [1997]classified dissemination-based systemsaccording to their data delivery mecha-nisms: push versus pull, aperiodic ver-sus periodic, and unicast versus 1-to-N.Push-based information systems havebeen studied extensively [Hauswirth andJazayeri 1999; Hauswirth 1999]. Simi-lar characterizations are used in softwareengineering [Sullivan and Notkin 1990;Garlan and Notkin 1991] and coordinationmodels [Papadopoulos and Arbab 1998].

3. THE COUSINS: ALTERNATIVECOMMUNICATION PARADIGMS

Message passing, remote invocations, no-tifications, shared spaces, and messagequeuing do all constitute alternativecommunication paradigms to the pub-lish/subscribe scheme. They stand at dif-ferent abstraction levels and are not easyto compare. Nevertheless, we overviewbelow their commonalities with pub-lish/subscribe systems and emphasizetheir inability to fully decouple communi-cation between participants.

3.1. Message Passing

Message passing can be viewed as the an-cestor of distributed interactions. Messagepassing represents a low-level form of dis-tributed communication, in which partic-ipants communicate by simply sendingand receiving messages. Although com-plex interaction schemes are still builton top of such primitives, message pass-

Fig. 3 . Message passing interaction: the producersends messages asynchronously through a commu-nication channel (previously set up for that purpose).The consumer receives messages by listening syn-chronously on that channel.

ing is nowadays rarely used directly fordeveloping distributed applications, sincephysical addressing and data marshaling,and sometimes even flow control (e.g., re-transmission), become visible to the ap-plication layer. Message passing is asyn-chronous for the producer, while messageconsumption is generally synchronous.The producer and the consumer are cou-pled both in time and space (cf. Figure 3):they must both be active at the same timeand the recipient of a message is known tothe sender.

3.2. RPC

One of the most widely used forms of dis-tributed interaction is the remote invoca-tion, an extension of the notion of “oper-ation invocation” to a distributed context.This type of interaction was first proposedin the form of a remote procedure call(RPC) [Birrell and Nelson 1983; Tay andAnanda 1990] for procedural languages,and has been straightforwardly appliedto object-oriented contexts in the form ofremote method invocations, for example,in Java RMI [Sun 2000], CORBA [OMG2002a], Microsoft DCOM [Horstmann andKirtland 1997; Chung et al. 1998].

By making remote interactions appearthe same way as local interactions, theRPC model and its derivatives make dis-tributed programming very easy. This ex-plains their tremendous popularity in dis-tributed computing. Distribution cannot,however, be made completely transparentto the application, because it gives riseto further types of potential failures (e.g.,communication failures) that have to be


118 Eugster et al.

Fig. 4 . RPC and derivatives: the producer per-forms a synchronous call, which is processed asyn-chronously by the consumer.

dealt with explicitly. As shown in Figure 4,RPC differs from publish/subscribe interms of coupling: the synchronous na-ture of RPC introduces a strong time,synchronization (on the consumer side1),and also space coupling (since an invokingobject holds a remote reference to each ofits invokees).

Several attempts have been made to re-move synchronization coupling in remoteand avoid blocking the caller thread whilewaiting for the reply of a remote invo-cation. A first variant consists in provid-ing a special flavor of asynchronous in-vocation for remote methods that haveno return values, as shown in Figure 5.For instance, CORBA [OMG 2002a] pro-vides a special one-way modifier that canbe used to specify such methods. This ap-proach leads to invocations with weak re-liability guarantees because the senderdoes not receive success or failure noti-fications (this type of interaction is oftencalled fire-and-forget). The second, less re-strictive variant supports return values,but does not make them directly availableto the calling thread. Instead, the result

Fig. 5 . Decoupling synchronization with asyn-chronous remote invocation: the producer does notexpect a reply.

1 The distinction between consumer and producerroles is not straightforward in RPC. We assume herethat an RPC that yields a reply attributes a consumerrole to the invoker, while the invokee acts as pro-ducer. As we will point out, the roles are inverted withasynchronous invocations (which yield no reply).

Fig. 6 . Decoupling synchronization with future re-mote invocation: the producer is not blocked and canaccess the reply later when it becomes available.

of a remote invocation is a handle throughwhich the actual return values will be ac-cessed when needed. With this approach,known as future or future type messagepassing [Yonezawa et al. 1987; Anandaet al. 1992] or wait-by-necessity [Caromel1993], the invoking thread can continueprocessing and request the return valuelater, thanks to the handle (Figure 6).

3.3. Notifications

In order to achieve synchronization decou-pling, a synchronous remote invocation issometimes split into two asynchronous in-vocations: the first one sent by the clientto the server—accompanied by the invo-cation arguments and a callback refer-ence to the client—and the second onesent by the server to the client to returnthe reply. This scheme can be easily ex-tended to return several replies by hav-ing the server make several callbacks tothe client. Such notification-based interac-tion is widely used to ensure consistencyof Web caches [Wessels 1995]: upon down-load of Web contents, Web proxies receive apromise to be notified if any change occursat the Web server. This implements a lim-ited form of publish/subscribe interactionin which Web proxies act as subscribersand the Web server as the publisher.

This type of interaction—where sub-scribers register their interest directlywith publishers, which manage subscrip-tions and send events—corresponds to theso-called observer design pattern [Gammaet al. 1995] (Figure 7). It is gener-ally implemented using asynchronous in-vocations in order to enforce synchro-nization decoupling. Although publishersnotify subscribers asynchronously, they



Fig. 7 . Notifications: producers and consumerscommunicate using asynchronous invocations flow-ing in both directions.

both remain coupled in time and in space.Furthermore the communication manage-ment is left to the publisher and can be-come burdensome as the system grows insize.

3.4. Shared Spaces

The distributed shared memory (DSM)paradigm [Li and Hudak 1989; Tamet al. 1990] provides hosts in a dis-tributed system with the view of a com-mon shared space across disjoint ad-dress spaces, in which synchronizationand communication between participantstake place through operations on shareddata. The notion of tuple space was origi-nally integrated at the language level inLinda [Gelernter 1985], and provides asimple and powerful abstraction for ac-cessing shared memory. A tuple space iscomposed of a collection of ordered tu-ples, equally accessible to all hosts of adistributed system. Communication be-tween hosts takes place through the inser-tion/removal of tuples into/from the tuplespace. Three main operations can be per-formed: out() to export a tuple into a tuplespace, in() to import (and remove) a tuplefrom the tuple space, and read() to read(without removing) a tuple from the tuplespace.

The interaction model provides timeand space decoupling, in that tuple pro-ducers and consumers remain anonymouswith respect to each other. The creator of atuple needs no knowledge about the futureuse of that tuple or its destination. An in-based interaction implements one-of-n se-mantics (only one consumer reads a giventuple) whereas read-based interaction canbe used to implement one-to-n messagedelivery (a given tuple can be read by

all such consumers). Unlike the pub-lish/subscribe paradigm, the DSM modeldoes not provide synchronization decou-pling because consumers pull new tuplesfrom the space in a synchronous style(Figure 8). This limits the scalability of themodel due to the required synchronizationbetween the participants. To compensatethe lack of synchronization decoupling,some modern tuple space systems likeJavaSpaces [Sun 2002], TSpaces [Lehmanet al. 1999], and WCL [Rowstron 1998]extend the Linda tuple space model withasynchronous notifications.

A similar communication abstraction,called rendezvous, has been introducedin the Internet Indirection Infrastructure(I3) [Stoica et al. 2002]. Instead of explic-itly sending a packet to a destination, eachpacket is associated with an identifier; thisidentifier is then used by the receiver to ob-tain delivery of the packet. This level of in-direction decouples the act of sending fromthe act of receiving.

3.5. Message Queuing

Message queuing [Blakeley et al. 1995] isa more recent alternative for distributedinteraction. In fact, the term messagequeuing is often used to refer to a familyof products (e.g., IBM Corporation [1995];Houston [1998]; DEC [1994]; Oracle[2002]) rather than to a specific interac-tion scheme. Message queuing andpublish/subscribe are tightly inter-twined: message queuing systems usuallyintegrate some form of publish/subscribe-like interaction. Such message-centric

Fig. 8 . Shared space: producers insert data asyn-chronously into the shared space, while consumersread data synchronously.


120 Eugster et al.

Fig. 9 . Message queuing: messages are stored ina FIFO queue. Producers append messages asyn-chronously at the end of the queue, while consumersdequeue them synchronously at the front of thequeue.

approaches are often referred to asmessage-oriented middleware (MOM)[Banavar et al. 1999b].

At the interaction level, message queuesrecall much of tuple spaces: queues can beseen as global spaces, which are fed withmessages from producers. From a func-tional point of view, message queuing sys-tems additionally provide transactional,timing, and ordering guarantees not nec-essarily considered by tuple spaces.

In message queuing systems, messagesare concurrently pulled by consumers withone-of-n semantics similar to those offeredby tuple spaces through the in() operation(Figure 9). These interaction model is of-ten also referred to as point-to-point (PTP)queuing. Which element is retrieved by aconsumer is not defined by the element’sstructure, but by the order in which the el-ements are stored in the queue (generallyfirst-in first-out (FIFO) or priority-basedorder).

Similarly to tuple spaces, producers andconsumers are decoupled in both time andspace. As consumers synchronously pullmessages, message queues do not providesynchronization decoupling. Some mes-sage queuing systems offer limited sup-port for asynchronous message delivery,but these asynchronous mechanisms donot scale well to large populations of con-sumers because of the additional inter-actions needed to maintain transactional,timing, and ordering guarantees.

3.6. Summary

Traditional interaction paradigms es-sentially differ from publish/subscribe

Fig. 10 . The publish/subscribe interaction para-digm decouples consumers and producers in termsof space, time, and synchronization.

communication (Figure 10) by their lim-ited support for time, space and synchro-nization decoupling. Table 1 summarizesthe decoupling properties of the aforemen-tioned communication models.

4. THE SIBLINGS: PUBLISH/SUBSCRIBEVARIATIONS

Subscribers are usually interested in par-ticular events or event patterns, and notin all events. The different ways of spec-ifying the events of interest have led toseveral subscription schemes. In this sec-tion we compare the two most widely usedschemes, namely topic-based and content-based publish/subscribe, as well the re-cently proposed type-based subscriptionscheme.4.1. Topic-Based Publish/Subscribe

The earliest publish/subscribe scheme wasbased on the notion of topics or subjects,and has been implemented by many in-dustrial strength solutions (e.g., Altherret al. [1999]; Talarian Corporation [1999];Skeen [1998]; TIBCO [1999]). It extendsthe notion of channels, used to bundle com-municating peers, with methods to charac-terize and classify event content. Partic-ipants can publish events and subscribeto individual topics, which are identifiedby keywords. Topics are strongly simi-lar to the notion of groups, as definedin the context of group communication[Powell 1996] and often used for repli-cation [Birman 1993]. This similarity isnot surprising, since some of the firstsystems to offer publish/subscribe inter-action were based on the Isis [Birmanet al. 1990] group communication toolkitand the subscription scheme was thus



Table 1. Decoupling Abilities of Interaction ParadigmsSpace Time Synchronization

Abstraction decoupling decoupling decouplingMessage passing No No Producer-sideRPC/RMI No No Producer-sideAsynchronous RPC/RMI No No YesFuture RPC/RMI No No YesNotifications (observer pattern) No No YesTuple spaces Yes Yes Producer-sideMessage queuing (Pull) Yes Yes Producer-sidePublish/subscribe Yes Yes Yes

inherently based on groups. Consequently,subscribing to a topic T can be viewedas becoming a member of a group T , andpublishing an event on topic T trans-lates accordingly into broadcasting thatevent among the members of T . Althoughgroups and topics are similar abstractions,they are generally associated with differ-ent application domains: groups are usedfor maintaining strong consistency be-tween the replicas of a critical componentin a local area network (LAN), whereastopics are used to model large-scale dis-tributed interactions.

In practice, topic-based publish/subscribe systems introduce a program-ming abstraction which maps individualtopics to distinct communication chan-nels. They present interfaces similar tothose of the event service discussed inSection 2, and the topic name is usuallyspecified as an initialization argument.Every topic is viewed as an event serviceof its own, identified by a unique name,with an interface offering publish() andsubscribe() operations.

The topic abstraction is easy to under-stand, and enforces platform interoper-ability by relying only on strings as keysto divide the event space. Additions to thetopic-based scheme have been proposed byvarious systems. The most useful improve-ment is the use of hierarchies to orches-trate topics. While group-based systemsoffer flat addressing, where groups repre-sent disconnected event spaces, nearly allmodern topic-based engines offer a formof hierarchical addressing, which permitsprogrammers to organize topics accord-ing to containment relationships. A sub-scription made to some node in the hier-archy implicitly involves subscriptions to

all the subtopics of that node. Topic namesare generally represented with a URL-like notation and introduce a hierarchyvery similar to the USENET news. Mostsystems allow topic names to containwildcards, first introduced in TIBCORendezvous [TIBCO 1999], which offer thepossibility to subscribe and publish to sev-eral topics whose names match a given setof keywords, like an entire subtree or aspecific level in the hierarchy.

Consider the example of stock quotesdisseminated to a large number of inter-ested brokers. In a first step, we are inter-ested in buying stocks, advertised by stockquote events. Such events consist of fiveattributes: a global identifier, the nameof the company, the price, the amount ofstocks, and the identifier of the sellingtrader. Figure 11 shows how to subscribeto all stock quotes, and Figure 12 givesan overview of the resulting distributedinteraction.

4.2. Content-Based Publish/Subscribe

Despite improvements like hierarchicaladdressing facilities and wildcards, thetopic-based publish/subscribe variant rep-resents a static scheme which offers onlylimited expressiveness. The content-based(or property-based [Rosenblum and Wolf1997]) publish/subscribe variant improveson topics by introducing a subscriptionscheme based on the actual content ofthe considered events. In other terms,events are not classified according to somepredefined external criterion (e.g., topicname), but according to the propertiesof the events themselves. Such proper-ties can be internal attributes of datastructures carrying events, as in Gryphon


122 Eugster et al.

Fig. 11 . Sample code for topic-based publish/subscribe.

[Banavar et al. 1999a], Siena [Carzanigaet al. 2000], Elvin [Segall et al. 2000], andJedi [Cugola et al. 2001], or meta-dataassociated to events, as in the Java Mes-sage Service [Hapner et al. 2002].

Consumers subscribe to selective eventsby specifying filters using a subscriptionlanguage. The filters define constraints,usually in the form of name-value pairsof properties and basic comparison op-erators (=, <, ≤, >, ≥), which identifyvalid events. Constraints can be logicallycombined (and, or, etc.) to form complexsubscription patterns. Some systems, likethe Cambridge Event Architecture (CEA)[Bacon et al. 2000], also provide for eventcorrelation: participants can subscribe tological combinations of elementary eventsand are only notified upon occurrence ofthe composite events. Subscription pat-terns are used to identify the eventsof interest for a given subscriber andpropagate events accordingly. For sub-scribing, a variant of the subscribe()operation is provided by the event ser-vice, with an additional argument rep-

Fig. 12 . Topic-based publish/subscribe interactions.

resenting a subscription pattern. Thereare several means of representing suchpatterns:

—String: Subscription patterns are mostfrequently expressed using strings.Filters must conform to a subscrip-tion grammar, such as SQL [Hapneret al. 2002; Oracle 2002; Lewis 1999],OMG’s Default Filter Constraint Lan-guage [OMG 2002b], XPath [Altineland Franklin 2000; Chan et al. 2002a;Diao et al. 2002], or some propri-etary language [Banavar et al. 1999a;Carzaniga et al. 2001; Segall and Arnold1997]. Strings are then parsed by theengine.

—Template object: Inspired by tuple-basedmatching, JavaSpaces [Freeman et al.1999] adopts an approach based on tem-plate objects. When subscribing, a par-ticipant provides an object t, which indi-cates that the participant is interestedin every event that conforms to the typeof t and whose attributes all match thecorresponding attributes of t, except forthe ones carrying a wildcard (null).

—Executable code: Subscribers provide apredicate object able to filter events atruntime. The implementation of thatobject is usually left to the applica-tion developer. An alternative approach,based on a library of filter objects imple-mented using reflection, was describedin Eugster and Guerraoui [2001]. Exe-cutable code is not widely used in prac-tice because the resulting filters are ex-tremely hard to optimize.



Fig. 13 . Sample code for content-based publish/subscribe.

Figures 13 and 14 illustrate the useof string-based filters. The example out-lines how a content-based scheme enforcesa finer granularity than a static schemebased on topics. To achieve the samefunctionality with topics, the subscriberwould either have to filter out irrelevantevents, or topics would need to be splitinto several subtopics—one for each com-pany (and recursively several subtopicsfor different price “categories”). The firstapproach leads to an inefficient use ofbandwidth, while the second approach re-sults in a high number of topics and anincreased risk of redundant events.

4.3. Type-Based Publish/Subscribe

Topics usually regroup events that presentcommonalities not only in content, butalso in structure. This observation has ledto the idea of replacing the name-basedtopic classification model by a schemethat filters events according to their type[Eugster et al. 2001]. In other terms, the

Fig. 14 . Content-based publish/subscribe interac-tions.

Fig. 15 . Sample code for type-based publish/subscribe.

notion of event kind is directly matchedwith that of event type. This enables acloser integration of the language and themiddleware. Moreover, type safety can beensured at compile-time by parameteriz-ing the resulting abstraction interface bythe type of the corresponding events (with-out any type cast in the resulting code).In contrast, the aforementioned template-based approach of JavaSpaces [Freemanet al. 1999] considers the type of eventsas a dynamic property, and the result-ing JavaSpace API forces the applicationto perform explicit type casts. Similarly,the TAO CORBA Event Service [Harrisonet al. 1997] does not view the type of anevent object as an implicit attribute.

The example in Figure 15 illustratestype-based subscription. Stock events canbe split into two distinct types: stock quotes(for sale) and stock requests, as shownin Figure 16. Brokers use stock requeststo express their interest in buying stock.In contrast to quotes, requests have arange of possible prices. Subtyping can beused to subscribe to both stock quotes andrequests.

It is important to notice that type-based publish/subscribe can lead to a nat-ural description of content-based filteringthrough public members of the consideredevent type, while ensuring the encapsu-lation of these events. This is achieved inour example of Figure 15 by declaring only


124 Eugster et al.

Fig. 16 . Type-based publish/subscribe interactions.

private data members and enforcing theiraccess through public methods.

4.4. Summary

There exist several variants for design-ing publish/subscribe systems, which offerdifferent degrees of expressiveness and,as we shall see in Section 5, differentperformance overhead. Topic-based pub-lish/subscribe is rather static and prim-itive, but can be implemented very effi-ciently. On the other hand, content-basedpublish/subscribe is highly expressive, butrequires sophisticated protocols that havehigher runtime overhead. Because of thisadditional overhead, one should generallyprefer a static scheme whenever a pri-mary property ranges over a limited setof possible discrete values, for example,stock quotes/requests. As outlined inEugster and Guerraoui [2001], additionalexpressiveness can be achieved by apply-ing content-based filters in the context ofstatically configured topics, in particulartypes, to express constraints on propertiesthat are not within discrete ranges (e.g.,stock prices).

5. THE INCARNATIONS: IMPLEMENTATIONISSUES

This section discusses some implementa-tion issues underlying publish/subscribeschemes, and how these issues are ad-dressed in current systems and proto-types. We focus on three major aspects ofpublish/subscribe middleware: the events,the media, and qualities of service, in thecontext of the classification introduced inthe previous sections. Furthermore, wediscuss the different tradeoffs that result

from different approaches, in terms of flex-ibility, reliability, scalability, and perfor-mance. Additional details on specific im-plementation issues of publish/subscribesystems can be found in Rosenblum andWolf [1997]; Banavar et al. [1999a]; andTai and Rouvellou [2000].

5.1. Events

Events are found in two forms: messagesor invocations. In the first case, events aredelivered to a subscriber through a singlegeneric operation (e.g., notify()), while inthe second case events trigger the execu-tion of specific operations of the subscriber.

5.1.1. Messages. At the lowest level,any data that goes on the network is amessage. In most systems, event notifica-tions take the form of messages, which areexplicitly created by the application. Mes-sages are generally made of a header thatcontains message-specific information in ageneric format, and payload data that con-tains user-specific information. Typicalheader fields include message identifier,issuer, priority, or expiration time, whichcan be interpreted by the system or purelyserve as information for the consumers.Some systems (e.g., IBM MQSeries [Lewis1999] and Oracle Advanced Queuing[Oracle 2002]) do not make any assump-tion on the type of the payload data andtreat it as an opaque array of bytes. Someother systems (e.g., JMS [Hapner et al.2002], CORBA Notification Service [OMG2002b]) provide a set of message types,such as text or XML messages. Finally,some systems provide self-describing mes-sages. TIBCO Rendezvous [TIBCO 1999],



for instance, defines a message formatthat does not have header information,but allows the programmer to create hisor her own message structure based on aset of basic types that can be structuredhierarchically. The type of messages canbe queried later at runtime. DistributedAsynchronous Collections (DAC) [Eugsteret al. 2000] and Java Message Service(JMS) [Hapner et al. 2002] even supportobject messages, where the event can beany serializable Java object. In most cases,messages are viewed as records with sev-eral fields.

5.1.2. Invocations. At a higher level,we generally differentiate between invo-cations and messages. An invocation isdirected to a specific type of object, andhas well-defined semantics. The systemensures that all consumers have a match-ing interface for processing the invocation.The interface acts as a binding contractbetween the invoker and the invokees.Systems which offer invocation-styleinteraction along with different seman-tics and various addressing schemes areusually termed messaging systems. Theyincorporate additional logic on top of apublish/subscribe or message queuing sys-tem to transform low-level messages intoinvocations to methods of the subscribers,which must all be of the same type. Whilecertain systems take into account returnvalues of invocations, the typed pub-lish/subscribe models of COM+ [Sessions1997] or the CORBA Event Service [OMG2001] typically only consider one-wayinvocations. Producers invoke operationson some intermediary object (e.g., eventchannel) that exhibits the same interfaceas the actual consumers and forwardsevents to all registered consumers. COM+furthermore provides a form of content-based filtering, by offering the possibilityto specify values for invocation argu-ments in order to restrict the potentialinvocations.

5.2. The Media

The transmission of data between pro-ducers and consumers is the task of the

middleware medium. Media can be classi-fied according to characteristics like theirarchitecture or the guarantees they pro-vide for the data, such as persistence orreliability.

5.2.1. Architectures. The role of pub-lish/subscribe systems is to permit the ex-change of events between producers andconsumers in an asynchronous manner.Asynchrony can be implemented by hav-ing producers send messages to a spe-cific entity that stores them, and forwardsthem to consumers on demand. We callthis approach a centralized architecturebecause of the central entity that storesand forwards messages. This approachis adopted by queuing systems like theIBM MQSeries [Lewis 1999] and OracleAdvanced Queuing [Oracle 2002], eachof which is built on top of a centralizeddatabase. Applications based on such sys-tems have strong requirements in termsof reliability, data consistency, or trans-actional support, but do not need a highdata throughput. Examples of such appli-cations are electronic commerce or bank-ing applications.

Asynchrony can also be implementedby using smart communication primitivesthat implement store and forward mech-anisms both in the producer’s and con-sumer’s processes, so that communicationappears asynchronous and anonymous tothe application without the need for an in-termediary entity. We call this approach adistributed architecture because there isno central entity in the system. TIBCORendezvous [TIBCO 1999] uses a decen-tralized approach in which no process actsas a bottleneck or a single point of fail-ure. Such architectures are well suitedfor fast and efficient delivery of tran-sient data, which is required for applica-tions like stock exchange or multimediabroadcasting.

An intermediate approach, adopted forinstance by Gryphon [Banavar et al.1999a], Siena [Carzaniga et al. 2000],and Jedi [Cugola et al. 2001], consists inimplementing the event notification ser-vice as a distributed network of servers.In contrast to completely decentralized


126 Eugster et al.

systems, this approach discharges the par-ticipating processes by using dedicatedservers to execute the complex proto-cols required for persistence, reliability, orhigh-availability, as well as for content-based filtering and routing. There are dif-ferent topologies for these servers. Jedi’sevent dispatchers are organized in a hi-erarchical structure, where clients canconnect to any node. Subscriptions arepropagated upward the tree of servers.Such hierarchical topologies tend, how-ever, to heavily load the root servers,and the failure of a server might dis-connect the entire subtree. In Gryphon,a graph summarizing the common inter-ests of subscribers is superimposed withthe message broker graph, to avoid re-dundant matches. Siena uses subscriptionand advertisement forwarding to set thepaths for notifications. Event servers keeptrack of useful information to efficientlymatch events with subscriptions. Sev-eral server topologies have been consid-ered, each with respective advantages andshortcomings.

5.2.2. Dissemination. The actual trans-mission of data can happen in variousways. In particular, data can be sent usingpoint-to-point communication primitives,or using hardware multicast facilities likeIP multicast [Deering n.d.]. The choice ofthe communication mechanism dependson factors such as the target environmentand the architecture of the system.

Centralized approaches like certainmessage queuing systems are likely to usepoint-to-point communication primitivesbetween producers/consumers and thecentralized broker. As already mentioned,these systems focus more on strong guar-antees than on high throughput and scal-ability. Topic-based publish/subscribe sys-tems can straightforwardly benefit fromthe vast amount of studies on group com-munication [Powell 1996] and the re-sulting protocols to disseminate eventsto subscribers. To ensure high through-put, Internet protocol (IP) multicast ora wide range of reliable multicast proto-cols [Floyd et al. 1997; Holbrook et al.1995; Lin and Paul 1996; Castro et al.

2002; Banerjee et al. 2002; Ratnasamyet al. 2001; Zhuang et al. 2001] are com-monly employed.

Efficient multicast of events in content-based publish/subscribe systems remainsan issue. Gryphon and Siena both use al-gorithms [Aguilera et al. 1999; Carzanigaet al. 2001] that deliver events to a logi-cal network of servers in such a way thatan event is propagated only to the serversthat manage subscribers interested bythat event. The performance of suchdissemination-based systems is stronglyaffected by the cost of event filtering oneach of the servers, which directly dependson the number of subscriptions in the sys-tem. Highly efficient and scalable algo-rithms have been recently proposed for fil-tering data in publish/subscribe systems[Altinel and Franklin 2000; Pereira et al.2000; Fabret et al. 2001; Campailla et al.2001; Chan et al. 2002a; Diao et al. 2002].The problem of aggregating subscriptionsto increase the filtering speed at eachserver, at the price of a small loss in pre-cision, has been studied in Chan et al.[2002a]. Irrespective of the filtering tech-niques, the selective event routing in-herent to content-based publish/subscribemakes the exploitation of network-levelmulticast primitives difficult.

5.3. Qualities of Service

The guarantees provided by the mediumfor every message vary strongly betweenthe different systems. Among the mostcommon qualities of service consideredin publish/subscribe, we have persistence,transactional guarantees, and priorities.

5.3.1. Persistence. In RPC-like systems,a method invocation is by definition a tran-sient event. The lifetime of a remote invo-cation is short and, if the invokee does notget a reply after a given period of time, itmay reissue the request. The situation isdifferent in publish/subscribe or queuingsystems. Messages may be sent withoutgenerating replies, and they may be pro-cessed hours after having been sent. Thecommunicating parties do not control howmessages are transmitted and when they



are processed. Thus, the messaging sys-tem must provide guarantees not only interms of reliability, but also in terms ofdurability of the information. It is not suf-ficient to know that a message has reachedthe messaging system that sits betweenthe producers and consumers; we mustget the guarantee that the message willnot be lost upon failure of that messagingsystem.

Persistence is generally present in pub-lish/subscribe systems that have a central-ized architecture and store messages untilconsumers are able to process them. Queu-ing systems like the IBM MQSeries [Lewis1999] and Oracle Advanced Queuing[Oracle 2002] offer persistence using anunderlying database. Distributed pub-lish/subscribe systems do not generallyoffer persistence since messages are di-rectly sent by the producer to all sub-scribers. Unless the producer keeps a copyof each message, a faulty subscriber maynot be able to get missed messages whenrecovering. TIBCO Rendezvous [TIBCO1999] offers a mixed approach, in whicha process may listen to specific subjects,store messages on persistent storage, andresend missed messages to recovering sub-scribers. The Cambridge Event Architec-ture [Bacon et al. 2000] provides a po-tentially distributed event repository forevent storage and efficient retrieval (withsearching facilities for simple and compos-ite events) that enables the replaying ofstored sequences of events.

5.3.2. Priorities. Like persistence, mes-sage prioritization is a quality of service of-fered by some messaging systems. Indeed,it may be desirable to sort the messageswaiting to be processed by a consumerin order of priority. For instance, a real-time event may require immediate reac-tion (e.g., failure notification) and shouldbe processed before other messages.

Priorities affect messages that are intransit, that is, not being processed. Run-time execution priorities are handled bythe application scheduler and are notmanaged by the messaging system. In par-ticular, this implies that two subscribers

listening to the same topics may processmessages in different orders because theyprocess messages at different speeds, eventhough communication channels are firstin, first out (FIFO). Priorities should beconsidered as a best-effort quality of ser-vice (unlike persistence).

Most publish/subscribe messaging sys-tems (centralized or distributed) providepriorities, although the number of prior-ities and the way they are applied dif-fer. IBM MQSeries [Lewis 1999], OracleAdvanced Queuing [Oracle 2002], TIBCORendezvous [TIBCO 1999], and the JMSspecification [Hapner et al. 2002] all sup-port priorities.

5.3.3. Transactions. Transactions aregenerally used to group multiple opera-tions in atomic blocks that are eithercompletely executed or not executed at all.In messaging systems, transactions areused to group messages into atomic units:either a complete sequence of messagesis sent (received), or none of them is. Forinstance, a producer that publishes sev-eral semantically related messages maynot want consumers to see a partial (in-consistent) sequence of messages if it failsduring emission. Similarly, a mission-critical application may want to consumeone or several messages, process them,and only then commit the transaction. Ifthe consumer fails before committing, allmessages are still available for reprocess-ing after recovery.

Due to their tight integration withdatabases, IBM MQSeries [Lewis 1999]and Oracle Advanced Queuing [Oracle2002] provide a wide range of transac-tional mechanisms. JMS [Hapner et al.2002] and TIBCO Rendezvous [TIBCO1999] also provide transaction supportfor grouping messages in the context of asingle session. JavaSpaces [Freeman et al.1999] provides lightweight transactionalmechanisms to guarantee atomicity ofevent production and consumption. Anevent published in a JavaSpace in thecontext of a transaction is not visibleoutside the transaction until it is com-mitted. Similarly, a consumed event isnot removed from a JavaSpace until the


128 Eugster et al.

enclosing transaction commits. Severalevents can be produced and consumed inthe context of the same transaction.

5.3.4. Reliability. Reliability is an impor-tant feature of distributed informationsystems. It is often necessary to havestrong guarantees about the reliable de-livery of information to one or severaldistributed entities. Because of the loosesynchronization between producers andconsumers of information, implementingreliable event propagation (“guaranteeddelivery”) is challenging.

Centralized publish/subscribe systemsgenerally use reliable point-to-point chan-nels to communicate with publishers andsubscribers, and keep copies of eventson stable storage. Events are thereforereliably delivered to all subscribers, al-though a failure of the centralized eventbroker may delay delivery.

Systems based on an overlay networkof distributed event brokers often use reli-able protocols to propagate events to all ora subset of the brokers. Protocols based ongroup communication [Powell 1996] andreliable application-layer multicast [Floydet al. 1997; Holbrook et al. 1995; Lin andPaul 1996; Castro et al. 2002; Banerjeeet al. 2002; Ratnasamy et al. 2001; Zhuanget al. 2001] are good candidates as theyare resilient to the failure of some of thebrokers. Individual publishers and sub-scribers generally communicate with thenearer broker using point-to-point com-munication channels.

Finally, systems that let publishers andsubscriber communicate directly witheach other, such as TIBCO Rendezvous[TIBCO 1999], also use lightweight reli-able multicast protocols. As events aregenerally not kept in the system forfailed or disconnected (time-decoupled)subscribers, guaranteed delivery must beimplemented by deploying dedicated pro-cesses that store events and replay themto requesting subscribers.

6. CONCLUDING REMARKS

Publish/subscribe is a distributed inter-action paradigm well adapted to the de-

ployment of scalable and loosely cou-pled systems. To survey and comparedistributed event-based abstractions, wehave introduced a classification basedon three dimensions: the decoupling intime, space, and synchronization betweenproducers and consumers of information.Decoupling is a desirable property be-cause it enforces scalability at the ab-straction level, by allowing participantsto operate independently of one another.At the implementation level, however,scalability remains a sensitive issue, be-cause publish/subscribe interaction canbe built on top of various communica-tion substrates and can easily be ham-pered by an inappropriate architecture,in particular when publish/subscribe sys-tems are built on top of infrastructuresthat were not designed with scalability inmind.

Scalability also often conflicts withother desirable properties. For instance,highly expressive and selective subscrip-tions require complex and expensive fil-tering and routing algorithms, and thuslimit scalability. Similarly, strong relia-bility guarantees involve important over-heads, because events must be logged,and missed events must be detected andretransmitted. Even protocols developedespecially for wide-area networks, suchas the sender-reliable Reliable MulticastTransport Protocol (RMTP) [Lin and Paul1996], do not scale well to large numbersof subscribers because of the considerableamount of traffic resulting from messageacknowledgments.

Recently, probabilistic protocols havereceived increasing attention since theymatch the decoupled and peer-based na-ture of publish/subscribe systems. Insteadof providing deterministic (guaranteed) re-liability, probabilistic multicast protocolsensure that a given event will reach allsubscribers with a very high and quantifi-able probability [Birman et al. 1999]. In-tegration of such probabilistic protocols incontent-based publish/subscribe systemsremains a challenging issue.

While programming abstractions forpublish/subscribe are plentiful, designingappropriate algorithms for deploying such



systems on a large scale is still an openissue, and tradeoffs must be dealt with tocope with scalability, expressiveness andquality of service. Significant research ef-forts remain to be invested, in particularas tribute to the unpredictability of theInternet.

REFERENCES

AGUILERA, M. K., STROM, R. E., STURMAN, D. C., ASTLEY,M., AND CHANDRA, T. D. 1999. Matching eventsin a content-based subscription system. In Pro-ceedings of the Eighteenth ACM Symposiumon Principles of Distributed Computing (PODC’99, Atlanta, GA). ACM Press, New York, NY,53–61.

ALTHERR, M., ERZBERGER, M., AND MAFFEIS, S. 1999.iBus—a software bus middleware for the Javaplatform. In Proceedings of the InternationalWorkshop on Reliable Middleware Systems.43–53.

ALTINEL, M. AND FRANKLIN, M. 2000. Efficient Fil-tering of XML documents for selective dissemi-nation of information. In Proceedings of the 26thInternational Conference on Very Large DataBases (VLDB ’00). 53–64.

ANANDA, A., TAY, B., AND KOCH, K. 1992. A surveyof asynchronous remote procedure calls. ACMOperat. Syst. Rev. 26, 2 (July), 92–109.

BACON, J., MOODY, K., BATES, J., R. HAYTON, MA, C.,MCNEIL, A., SEIDEL, O., AND SPITERI, M. 2000.Generic support for distributed applications.IEEE Comput. 33, 3 (Mar.), 68–76.

BANAVAR, G., CHANDRA, T., MUKHERJEE, B.,NAGARAJARAO, J., STROM, R., AND STURMAN, D.1999a. An efficient multicast protocol forcontent-based publish-subscribe systems. InProceedings of the 19th International Conferenceon Distributed Computing Systems (ICDCS’99).

BANAVAR, G., CHANDRA, T., STROM, R., AND STURMAN, D.1999b. A case for message oriented middle-ware. In Proceedings of the 13th InternationalSymposium on Distributed Computing (DISC99). 1–18.

BANERJEE, S., BHATTACHARJEE, B., AND KOMMAREDDY, C.2002. Scalable application layer multicast. InProceedings of ACM SIGCOMM. ACM Press,New York, NY.

BIRMAN, K. 1993. The process group approachto reliable distributed computing. Commun.ACM 36, 12 (Dec.), 36–53.

BIRMAN, K., COOPER, R., JOSEPH, T., MARZULLO, K.,MAKPANGOU, M., KANE, K., SCHMUCK, F., AND WOOD,M. 1990. The Isis System Manual. Dept. ofComputer Science, Cornell University, Ithaca,NY.

BIRMAN, K., HAYDEN, M., O. OZKASAP, XIAO, Z., BUDIU,M., AND MINSKY, Y. 1999. Bimodal multicast.ACM Trans. Comput. Syst. 17, 2 (May), 41–88.

BIRRELL, A. D. AND NELSON, B. J. 1983. Implement-ing remote procedure calls. In Proceedings ofthe ACM Symposium on Operating System Prin-ciples (Bretton Woods, NH). ACM Press, NewYork, NY, 3.

BLAKELEY, B., HARRIS, H., AND LEWIS, J. 1995. Mes-saging and Queuing Using the MQI. McGraw-Hill, New York, NY.

CAMPAILLA, A., CHAKI, S., CLARKE, E., JHA, S., AND

VEITH, H. 2001. Efficient filtering in publish-subscribe systems using binary decision. In Pro-ceedings of the International Conference on Soft-ware Engineering. 443–452.

CAROMEL, D. 1993. Towards a method of object-oriented concurrent programming. Commun.ACM 36, 90–102.

CARZANIGA, A., ROSENBLUM, D., AND WOLF, A. 2000.Achieving scalability and expressiveness in anInternet-scale event notification service. In Pro-ceedings of the Nineteenth ACM Symposium onPrinciples of Distributed Computing (PODC ’00).ACM Press, New York, NY.

CARZANIGA, A., ROSENBLUM, D., AND WOLF, A. 2001.Design and evaluation of a wide-area event noti-fication service. ACM Trans. Comput. Syst. 19, 3(Aug.), 332–383.

CASTRO, M., DRUSCHEL, P., KERMARREC, A.-M., AND

ROWSTRON, A. 2002. SCRIBE: A large-scaleand decentralized application-level multicast in-frastructure. IEEE J. Sel. Areas Commun. 20, 8(Oct.), 1489–1499.

CHAN, C.-Y., FAN, W., FELBER, P., GAROFALAKIS, M., AND

RASTOGI, R. 2002a. Tree pattern aggregationfor scalable XML data dissemination. In Pro-ceedings of the 28th International Conference onVery Large Data Bases (VLDB ’02, Hong Kong,China).

CHAN, C.-Y., FELBER, P., GAROFALAKIS, M., AND RASTOGI,R. 2002b. Efficient filtering of XML docu-ments with XPath expressions. In Proceedings ofthe 18th International Conference on Data Engi-neering (ICDE ’02, San Jose, CA).

CHUNG, P., HUANG, Y., YAJNIK, S., LIANG, D., SHIH, J.,WANG, C.-Y., AND WANG, Y. 1998. DCOM andCORBA side by side, step by step, and layer bylayer. C++ Rep. 10, 1 (Jan.), 18–29.

CUGOLA, G., NITTO, E. D., AND FUGETTA, A. 2001. TheJedi event-based infrastructure and its appli-cation to the development of the opss wfms.IEEE Trans. Softw. Eng. 27, 9 (Sept.), 827–850.

DEC. 1994. DECMessageQ: Introduction to Mes-sage Queuing. Digital Equipment Corporation;now part of Hewlett Packard, Palo Alto, CA.

DEERING, S. N. D. Host extension for ip multicast.IETF RFC 1112. Internet Engineering TaskForce (Web site: www.ietf.org).

DIAO, Y., FISCHER, P., FRANKLIN, M., AND TO, R. 2002.YFilter: Efficient and scalable filtering of XMLdocuments. In Proceedings of the 18th Interna-tional Conference on Data Engineering (ICDE’02, San Jose, CA).


130 Eugster et al.

EUGSTER, P. AND GUERRAOUI, R. 2001. Content-based publish/subscribe with structural reflec-tion. In Proceedings of the 6th Usenix Con-ference on Object-Oriented Technologies andSystems (COOTS’01).

EUGSTER, P., GUERRAOUI, R., AND DAMM, C. 2001.On objects and events. In Proceedings of theOOPSLA ’01 Conference on Object OrientedProgramming Systems Languages and Applica-tions. ACM Press, New York, NY, 254–269.

EUGSTER, P., GUERRAOUI, R., AND SVENTEK, J. 2000.Distributed Asynchronous Collections: Abstrac-tions for publish/subscribe interaction. In Pro-ceedings of the 14th European Conference onObject-Oriented Programming (ECOOP’2000).

FABRET, F., JACOBSEN, H., LLIRBAT, F., PEREIRA, J.,ROSS, K., AND SHASHA, D. 2001. Filtering algo-rithms and implementations for very fast pub-lish/subscribe systems. In Proceedings of ACMSIGMOD (Santa Barbara, CA). 115–126.

FLOYD, S., JACOBSON, V., LIU, C., MCCANNE, S., AND

ZHANG, L. 1997. A reliable multicast frame-work for light-weight sessions and applicationlevel framing. IEEE/ACM Trans. Netw. 5, 6,784–803.

FRANKLIN, M. AND ZDONIK, S. 1997. A framework forscalable dissemination-based systems. In Pro-ceedings of the 12th ACM Conference on Object-Oriented Programming Systems, Languages andApplications (OOPSLA’97). ACM Press, NewYork, NY, 94–105.

FREEMAN, E., HUPFER, S., AND ARNOLD, K. 1999.JavaSpaces Principles, Patterns, and Practice.Addison-Wesley, Reading, MA.

GAMMA, E., HELM, R., JOHNSON, R., AND VLISSIDES, J.1995. Design Patterns, Elements of ReusableObject-Oriented Software. Addison-Wesley,Reading, MA.

GARLAN, D. AND NOTKIN, D. 1991. Formalizing de-sign spaces: Implicit invocation mechanisms.In VDM ’91: Formal Software DevelopmentMethods. Lecture Notes in Computer Science,vol. 551. Springer-Verlag, Berlin, Germany,31–44.

GELERNTER, D. 1985. Generative communicationin Linda. ACM Trans. Program. Lang. Syst. 7,80–112.

HAPNER, M., BURRIDGE, R., SHARMA, R., FIALLI, J., AND

STOUT, K. 2002. Java Message Service. SunMicrosystems Inc., Santa Clara, CA.

HARRISON, T., LEVINE, D., AND SCHMIDT, D. 1997. Thedesign and performance of a real-time CORBAevent service. In Proceedings of the 12th ACMConference on Object-Oriented ProgrammingSystems, Languages and Applications (OOP-SLA ’97). ACM Press, New York, NY, 184–200.

HAUSWIRTH, M. 1999. Internet-scale push systemsfor information distribution—architecture, com-ponents, and communication. Ph.D. disserta-tion. Technical University of Vienna, Vienna,Austria.

HAUSWIRTH, M. AND JAZAYERI, M. 1999. A compo-nent and communication model for push sys-tems. In Proceedings of Software Engineering—ESEC/FSE’99. 20–28.

HOLBROOK, H., SINGHAL, S., AND CHERITON, D. 1995.Log-based receiver-reliable multicast for dis-tributed interactive simulation. In Proceedingsof ACM SIGCOMM’95.

HORSTMANN, M. AND KIRTLAND, M. 1997. DCOM ar-chitecture. Available online at www.microsoft.com/com/tech/DCOM.asp.

HOUSTON, P. 1998. Building distributed applica-tions with message queuing middleware Whitepaper. Available online at http://msdn.microsoft.com/library/en-us/dnmqqc/html/bldappmq.asp.

HUANG, Y. AND GARCIA-MOLINA, H. 2001. Pub-lish/subscribe in a mobile enviroment. In Pro-ceedings of MobiDE. 27–34.

IBM CORPORATION. 1995. MQSeries: An introduc-tion to messaging and queuing. Tech. Rep.GC33-0805-01. IBM Corporation, YorktownHeights, NY.

LEHMAN, T., LAUGHRY, S. M., AND WYCKOFF, P. 1999.Tspaces: The next wave. In Proceedings of theHawaii International Conference on System Sci-ences (HICSS-32).

LEWIS, R. 1999. Advanced Messaging Applicationswith MSMQ and MQSeries. QUE.

LI, K. AND HUDAK, P. 1989. Memory coherence inshared memory systems. ACM Trans. Comput.Syst. 7, 4 (Nov.), 321–359.

LIN, J. AND PAUL, S. 1996. A reliable multicasttransport protocol. In Proceedings of the IEEEINFOCOM’96. IEEE Computer Society Press,Los Alamitos, CA, 1414–1424.

OMG. 2001. CORBA Event Service Specification.Object Management Group, Needham, MA.

OMG. 2002a. The Common Object RequestBroker: Core Specification. Object ManagementGroup, Needham, MA.

OMG. 2002b. CORBA Notification Service Speci-fication. Object Management Group, Needham,MA.

Oracle 2002. Oracle9i Application Developer’sGuide—Advanced Queuing. Oracle, RedwoodShores, CA.

PAPADOPOULOS, G. AND ARBAB, F. 1998. Coordinationmodels and languages. In The Engineering ofLarge Systems. Advances in Computers, vol. 46.Academic Press, New York, NY.

PEREIRA, J., FABRET, F., LLIRBAT, F., AND SHASHA,S. 2000. Efficient matching for Web-basedpublish/subscribe systems. In Proceedings ofCoopIS.

POWELL, D. 1996. Group communication. Com-mun. ACM 39, 4 (Apr.), 50–97.

RATNASAMY, S., HANDLEY, M., KARP, R., AND SHENKER,S. 2001. Application-level multicast usingcontent-addressable networks. In Proceedings ofthe Third International Workshop on NetworkedGroup Communication.



ROSENBLUM, D. AND WOLF, A. 1997. A design frame-work for Internet-scale event observation andnotification. In Proceedings of the 6th EuropeanSoftware Engineering Conference/ACM SIG-SOFT 5th Symposium on the Foundations ofSoftware Engineering. ACM Press, New York,NY, 344–360.

ROWSTRON, A. 1998. Wcl: A co-ordination languagefor geographically distributed agents. WorldWide Web 1, 3, 167–179.

SEGALL, B. AND ARNOLD, D. 1997. Elvin has leftthe building: A publish/subscribe notificationservice with quenching. In Proceedings of theAustralian UNIX and Open Systems UserGroup Conference (AUUG’97). Available onlineat http://www.dtsc.edu.au/.

SEGALL, B., ARNOLD, D., BOOT, J., HENDERSON, M., AND

PHELPS, T. 2000. Content based routing withElvin4. In AUUG2K (Canberra, Australia).

SESSIONS, R. 1997. COM and DCOM: Microsoft’sVision for Distributed Objects. John Wiley &Sons, New York, NY.

SKEEN, D. 1998. Vitria’s Publish-SubscribeArchitecture: Publish-Subscribe Overview.http://www.vitria.com.

STOICA, I., ADKINS, D., ZHUANG, S., SHENKER, S., AND

SURANA, S. 2002. Internet indirection infras-tructure. In Proceedings of ACM SIGCOMM.ACM Press, New York, NY.

SULLIVAN, K. AND NOTKIN, D. 1990. Reconciling en-vironment integration and component inde-pendence. In Proceedings of the Fourth ACMSIGSOFT Symposium on Software Develop-ment environments. ACM Press, New York, NY,22–33.

SUN. 2000. Java Remote Method Invocation Spec-ification. Sun Microsystems, Santa Clara, CA.

SUN. 2002. JavaSpaces Service Specification. SunMicrosystems, Santa Clara, CA.

TAI, S. AND ROUVELLOU, I. 2000. Strategies forintegrating messaging and distributed objecttransactions. In Proceedings of the IFIP/ACMInternational Conference on Distributed Sys-tems Platforms and Open Distributed Process-ing (Middleware ’00). ACM Press, New York, NY,308–330.

TALARIAN CORPORATION. 1999. Everything you needto know about middleware: Mission-criticalinterprocess communication. White paper.Talarian Corporation, Los Altos, CA (now partof TIBCO, Palo Alto, CA). Available online athttp://www.talarian. com/.

TAM, M., SMITH, J., AND FARBER, D. 1990. Ataxonomy-based comparison of several dis-tributed shared memory systems. ACM Operat.Syst. Rev. 24, 3 (July), 40–67.

TAY, B. H. AND ANANDA, A. L. 1990. A surveyof remote procedure calls. ACM Operat. Syst.Rev. 24, 3 (July), 68–79.

TIBCO. 1999. TIB/Rendezvous. White paper.TIBCO, Palo Alto, CA.

WESSELS, D. 1995. Intelligent caching for world-wide-web objects. In Proceedings of INET’95(Honolulu, HI).

YONEZAWA, A., SHIBAYAMA, E., TAKADA, T., AND HONDA,Y. 1987. Modeling and programming in anobject-oriented concurrent language ABCL/1.In Object-Oriented Concurrent Programming,A. Yonezawa, J.-P. Briot, and E. Shiboyama,Eds. MIT Press, Cambridge, MA, Chap. 4,pp. 55–89.

ZHUANG, S., ZHAO, B., JOSEPH, A., KATZ, R., AND

KUBIATOWICZ, J. 2001. Bayeux: An architec-ture for scalable and fault-tolerant wide-areadata dissemination. In Proceedings of theEleventh International Workshop on Networkand Operating System Support for Digital Audioand Video (NOSSDAV ’01).

Received January 2001; revised December 2002; accepted March 2003


the many faces of publish/subscribe - cs.ru.nlpieter/oss/manyfaces.pdf · the many faces of...

Documents