IMPLEMENTING A HIGH LEVEL PUB/SUB LAYER

FOR ENTERPRISE INFORMATION SYSTEMS

Mario Antollini

Faculty of Sciences, UNICEN, Tandil, Argentina

Mariano Cilia

∗

Databases and Distributed Systems Group, Technische Universit

at Darmstadt, Darmstadt, Germany

Alejandro Buchmann

Databases and Distributed Systems Group, Technische Universit

at Darmstadt, Darmstadt, Germany

Keywords:

data heterogeneity, data integration, semantic metadata, data dissemination, publish/subscribe, notiﬁcation

services.

Abstract:

Enterprise application interactions based on events has been receiving increasing attention. It is based on

the exchange of small pieces of data (called events) typically using the publish/subscribe interaction para-

digm. Most pub/sub notiﬁcation services assume a homogeneous namespace and do not support the interaction

among heterogeneous event producers and consumers.

In this paper we brieﬂy describe the concept-based approach as a high-level dissemination mechanism for

distributed and heterogeneous event-based applications. We focus on the design and implementation issues of

such a mechanism and show how it can be integrated on research prototypes or products and platforms.

1 INTRODUCTION

The global economy is causing drastic changes in the

way business is conducted. On the organizational

level, company mergers and acquisitions are leading

to a consolidation of manufacturers and producers. At

the same time goods are being offered across tradi-

tional borders regardless of economic, cultural or lin-

guistic differences. To function properly, global elec-

tronic commerce requires the correct interpretation of

exchanged data regardless of its origin and place of

consumption.

Notice that the exchanged data encapsulate infor-

mation about a given happening of interest, which

can only be properly interpreted and used when suf-

ﬁcient context information is known. In traditional

centralized systems, this context information is typi-

cally known by the users/developers and left implicit.

When data and events are exchanged across compo-

nent or institutional boundaries contextual informa-

tion is usually lost. To process this data in a semanti-

cally meaningful way, explicit information about the

semantics of events and data is required.

Event-based systems need an event dissemination

∗

Also Faculty of Sciences, UNICEN, Tandil, Argentina.

mechanism to deliver relevant events to interested

consumers. The publish/subscribe interaction para-

digm has been gaining relevance for this purpose. It

basically consists of a set of clients that asynchro-

nously exchange events

decoupled by a notiﬁcation

service

(NS for short) that is interposed between

them. Clients can be characterized as producers or

consumers. Producers publish notiﬁcations, and con-

sumers subscribe to notiﬁcations of interest by issuing

subscriptions, which are essentially stateless message

ﬁlters. After a client has issued a subscription, the no-

tiﬁcation service is responsible for delivering all fu-

ture matching notiﬁcations that are published by any

producer until the client cancels the respective sub-

scription.

To the best of our knowledge (see Section 2 for

details), almost all publish/subscribe mechanisms are

restricted to expose the data structure of events to

participants. This reﬂects a low level support for

event consumers that based on this scarce informa-

tion must express their interest without having neither

In the context of this work the terms notiﬁcation, mes-

sage and event are used interchangeable to mean basically

the same thing.

Throughout this work the terms notiﬁcation service and

messaging service will be interchangeably used.

Antollini M., Cilia M. and Buchmann A. (2006).

IMPLEMENTING A HIGH LEVEL PUB/SUB LAYER FOR ENTERPRISE INFORMATION SYSTEMS.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - DISI, pages 54-62

DOI: 10.5220/0002448900540062

 SciTePress

a concrete deﬁnition of meaning nor explicit assump-

tions made by event/data producers. Without this

kind of information event producers and consumers

are expected to fully comply with implicit assump-

tions made by participating software components or

applications. Even in the cases of a very small set

of applications within an enterprise this approach is

questionable.

Since publish/subscribe mechanisms decouple pro-

ducers and consumers, they should share a common

understanding in order to express their mutual in-

terests. In other words, events must be understand-

able beyond the closed conﬁnes of a single compo-

nent or application. That includes applications that

interact across traditional borders regardless of eco-

nomic, cultural or linguistic differences (in its sim-

plest form, i.e., system of units, currency or date/time

format). Since the source of an event (in other words

a publisher) cannot anticipate who is interested in a

given event and when and where it must be deliv-

ered, a higher-level publish/subscribe infrastructure is

needed. This basically adds to the current pub/sub

mechanisms the following two requirements: a) the

usage of a common vocabulary for deﬁning interests,

and b) the correct interpretation of information inde-

pendently of its origin and place of consumption.

The Concept-based addressing was initially pro-

posed as a part of a data dissemination mechanism

in the context of Internet auctions (Bornh

ovd et al.,

2000) and later in the context of reactive systems in

distributed environments (Cilia et al., 2001). Based

on this experience a higher level of abstraction to de-

scribe the interests of heterogeneous event producers

and consumers was proposed. This is achieved by

supporting from the ground up ontologies which pro-

vide the base for correct data and event interpretation.

Rather than requiring every producer or consumer

to use the same homogeneous namespace (as is com-

mon in other publish/subscribe systems) we provide

metadata and (extensible) conversion functions to

map from one context to another. This last feature

allows event consumers to simply specify the context

to which events need to be converted before they are

delivered for client processing.

In this paper we focus on the design and implemen-

tation issues of such an abstract layer and show how it

can be integrated on research prototypes (such as Re-

beca) and (commercial) products and platforms (like,

JMS and J2EE). We do not aim to analyze its perfor-

mance since its goal is to show the implementation of

a novel approach that provides heterogeneous appli-

cations with a seamless way to interact and correctly

interpret their exchanged data.

The rest of this paper is organized as follows. In

section 2, background and related work is presented.

Then, we describe our proposed approach in section

3. The main design decisions are described in sec-

tion 4 while details about the implementation are pre-

sented in section 5. Finally, conclusions and future

work are presented.

2 BACKGROUND AND RELATED

WORK

Since this work deals with various issues, like event

dissemination, the publish/subscribe paradigm, dis-

tributed systems, this section serves as a review of

these topics including related research.

2.1 Data Dissemination

Notiﬁcation services are widely used to deliver

events/data of interest to the corresponding con-

sumers. A notiﬁcation service is an application-

independent infrastructure that supports the construc-

tion of collaborating systems (event-based systems),

whereby producers of events publish event notiﬁca-

tions to the infrastructure and consumers of events

subscribe with the infrastructure to receive notiﬁca-

tions of interest.

There are several research projects (e.g. SIENA

(Carzaniga, 1998), REBECA (M

uhl, 2001), CEA

(Bacon et al., 1998), JEDI (Cugola et al., 1998),

READY (Gruber et al., 1999), standard speciﬁca-

tions (i.e., CORBA event service (Object Manage-

ment Group, 1997), Java Message Service (Hapner

et al., 1999)) and products (TIBCO Inc., 1996; IBM,

; Fiorano, ; Talarian, ; SonicSoftware, ; SpiritSoft, )

that focus on different aspects of data dissemination.

The pub/sub model is a very general communi-

cation model to exchange data among participating

applications commonly used in distributed environ-

ments. Its main features can be characterized by:

• Natural Multicast Functionality. Within the pub-

lish/subscribe model one application can send a

message once and multiple participating applica-

tions receive it. This model contains basically two

main players: data producers and consumers.

• Event Filtering. Some notiﬁcation services also of-

fer ﬁltering facilities, which are based on clients’

subscriptions (i.e., server-side ﬁltering), avoiding

irrelevant events to be forwarded to uninterested

consumers.

• Decoupling Producers and Consumers. Producers

and consumers of messages are anonymous to each

other, so the number of publishers and subscribers

may dynamically change. Individual publishers

and subscribers may evolve without disrupting the

existing system, facilitating extensibility and ﬂexi-

bility.

IMPLEMENTING A HIGH LEVEL PUB/SUB LAYER FOR ENTERPRISE INFORMATION SYSTEMS

• Mediator. A NS responsible for ﬁnding and deli-

vering matching notiﬁcations among publishers

and subscribers.

A fundamental aspect of publish/subscribe systems

is the expressiveness of the notiﬁcation selection,

i.e, how consumers specify subscriptions. The pub-

lish/subscribe interaction offers four generic alterna-

tives (or models) in order to address messages.

Channel-based addressing: The ﬁrst generation of

publish/subscribe systems (Harrison et al., 1997;

Object Management Group, 2000; Sun Microsys-

tems, Inc., 1998) used channels. Here, the producer

publishes notiﬁcations into speciﬁc channels. Con-

sumers subscribe to channels and get all notiﬁca-

tions published on them.

Subject-based addressing: In subject-based

pub/sub systems (Oki et al., 1993; TIBCO Inc.,

1996) producers publish notiﬁcations attaching

to them certain additional information, called

subject, that usually synthesizes notiﬁcations’

content. Subjects are arranged in a subject tree

by using a dot notation, and clients can either

subscribe to a single subject (e.g., finance.-

quotes.NASDAQ.FooInc) or use wildcards

(e.g., finance.quotes.NASDAQ.

Topic-based addressing: This is similar to the idea

of channels (here called topics) (Haase, 2002; Hap-

ner et al., 1999). Messages can carry additional

properties that could represent the content of the

message in question. Consumers express their in-

terest by subscribing to a topic but they can addi-

tionally include a predicate (called message selec-

tors) that refer to message properties.

Content-based addressing: It allows subscriptions

to express interest based on the content of noti-

ﬁcations, providing a more powerful and ﬂexible

notiﬁcation selection (Aguilera et al., 1999; M

uhl,

2001) than the others.

2.2 Dealing with Heterogeneity

The need for additional semantic metadata for the ex-

change of data or messages among independent enti-

ties or services has been clearly identiﬁed, not only in

the context of B2B frameworks like ebXML (Eisen-

berg and Nickull, 2001), BizTalk (Microsoft Corp.,

2000), or RosettaNet (RosettaNet, 2002) but also by

the W3C in efforts like Semantic Web (Berners-Lee

et al., 2001), or DAML+OIL (D. Conolly et al., 2001).

XML (Bray et al., 1998) and XML Schema (Fall-

side, 2001) are used to deﬁne common vocabularies

to describe data and business processes. Other data

models similar to XML include OEM (Papakonstanti-

nou et al., 1995) and the models described in (Abite-

boul et al., 1997; Deutsch et al., 1999).

For the representation of content of messages we

use MIX (Metadata based Integration model for

data X-change) (Bornh

ovd and Buchmann, 1999;

Bornh

ovd and Buchmann, 2000; Bornh

ovd, 2000),

a data model that combines the use of tags or at-

tribute names from a common vocabulary with addi-

tional meta information that describes the correspond-

ing data. MIX can be understood as a self-describing

data model for data exchange since information about

the structure and semantics of the data is given as part

of the exchanged data itself.

The MIX model is based on the concept of a

SemanticObject, together with its underlying

SemanticContext which consists of a ﬂexible set

of meta-attributes that explicitly describe the assump-

tions about the meaning of the data item. Each se-

mantic object has a concept label associated with it

that speciﬁes the relationship between the object and

the real world aspects it describes. These labels have

to be taken from a commonly known vocabulary, or

ontology (Bornh

ovd, 1999).

In the MIX representation, simple attributes are

represented as triplets of the form <C; v; S>, with C

referring to a concept from the underlying ontology, v

standing for the actual data value, and S representing

the semantic context of v. The association of context

information with a given data value serves as an ex-

plicit speciﬁcation of the meaning of the data.

3 PROPOSED APPROACH

Originally introduced in (Bornh

ovd et al., 2000) for

a speciﬁc application and with an initial implemen-

tation on top of a commercial pub/sub product (Cilia

et al., 2001), the concept-based approach was pro-

posed to tackle the problem of event-based interac-

tion among heterogeneous cooperating applications.

On one hand, it concentrates on resolving data inter-

pretation problems. On the other hand, it provides a

pub/sub abstraction that can run on top of (various)

notiﬁcation services independently of the addressing

model used underneath.

The concept-based approach provides an abstrac-

tion where participating applications do not need to

care about details of the underlying delivery mech-

anism. In this sense, applications involved in such

interaction can replace this mechanism by relying on

the concept-based layer causing minimal changes on

collaborating applications if any.

3.1 High-Level Architecture

The concept-based approach is not intended to be a

whole new notiﬁcation service by itself, but a layer

ICEIS 2006 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

of software capable of running on top of different ex-

isting notiﬁcation services, even supporting different

addressing models. From an abstract point of view,

it mediates in every subscription or publication that

clients issue and it delivers messages to the underly-

ing notiﬁcation service. As a matter of fact, clients

do not directly communicate with the underlying no-

tiﬁcation service anymore, moreover they don’t even

know which or what kind of NS is running below the

concept-based layer.

Figure 1: Concept-based high-level architecture.

Figure 1 sketches this approach. The underlying

NS is used as a data delivery mechanism where the

concept-based layer is responsible for providing a

higher-level interaction among heterogeneous appli-

cations (Cilia et al., 2004). A vocabulary/ontology

manager is associated with this layer with the pur-

pose of handling domain-speciﬁc vocabularies used

by the participant applications. Adapters are the in-

termediaries between pub/sub clients and the concept-

based layer. At the publisher side, they are responsi-

ble for resolving vocabulary issues and for enriching

message content, i.e. with contextual information. At

the subscriber, side they are in charge of transform-

ing/converting message content according to the sub-

scriber context. Additionally, this layer is responsible

for mapping concept-based data into the data struc-

tures and addressing models of the delivery mecha-

nism underneath.

3.2 Handling Heterogeneity of

Exchanged Data

In order to propose a solution to the problem of

data heterogeneity (or data integration) in the context

of cooperating applications (particularly relying on

pub/sub systems), several crucial issues are needed:

• the management of a shared vocabulary used by

participating applications,

• a matching vocabulary which is a subset of the

shared one used internally by the pub/sub system

for matching purposes,

• a vocabulary agreement module that maps from the

shared to the matching vocabulary,

• explicit deﬁnition of contextual information of all

participants within the pub/sub system, and

• conversion functions to map from and to different

contexts.

Making the vocabulary and the contextual assump-

tions explicit, events produced at source applications

can be correctly interpreted and converted to the re-

quired target context by diverse consumers.

3.3 Context Transformation

Adapters are the contact of applications with the noti-

ﬁcation service. They are responsible for the mapping

operations from local context to the matching one and

vice versa.

Adapters are responsible for converting messages’

context to the context used inside NSs boundaries

(known as default context). This is done based on

the explicit speciﬁcation of clients about their con-

textual information. As soon as a message arrives to

the concept-based layer, it is automatically converted

to the matching context and then delivered to the un-

derlying NS. In this way, NSs’ internal matching op-

erations are always carried out over expressions and

messages expressed in the same context.

Before events arrive at the subscriber side, adapters

automatically convert message’s context to the one

speciﬁed by subscribers at subscription time. In this

way, consumers receive data converted according to

their contextual preferences and no further conversion

is needed at the client application.

4 DESIGN OF THE

CONCEPT-BASED PUB/SUB

LAYER

This section explains how the concept-based layer

was designed, exposing in detail the way subscrip-

tions and publications are represented through the

concept-based layer.

4.1 Integrating MIX with

Participating Applications

The MIX model plays the role of a common vocabu-

lary into the concept-based architecture, as the basis

for the correct interpretation of events coming from

different sources. This important component is the

shared mean between publishers and subscribers in

our concept-based implementation. Relying on it,

heterogeneous applications can interact seamlessly.

IMPLEMENTING A HIGH LEVEL PUB/SUB LAYER FOR ENTERPRISE INFORMATION SYSTEMS

Figure 2: The role of MIX among concept-based clients.

As can be seen in Figure 2, MIX is basically com-

posed of four sub-components (i.e., conversion and

matching operations, events, expressions and seman-

tic context). Participating applications take advantage

of the functionality provided by MIX using the appro-

priate sub-components. Publishers create events and

enhance them with the available semantic informa-

tion. On the other hand, subscribers use MIX to create

expressions indicating the kind of events they are in-

terested in and add contextual information to them as

well. In this way, participating applications can inter-

communicate with each other by sharing a common

component (i.e., MIX) which provides all the func-

tionality required to handle data heterogeneity.

In the context of concept-based, the conversion and

matching operations are used in order to achieve in-

teroperation between the contextually different ap-

plications. This sub-component is only used by the

adapters and no participating application is supposed

to deal with it.

4.1.1 Event and Subscription Representation

Events, or to be more precise event content, are rep-

resented using the MIX model. When a producer ap-

plication publishes an event/notiﬁcation through the

concept-based layer, it sends a SemanticObject

representing the desired event. This so-called seman-

tic event is created using the MIX data model, which

deﬁnes the set of concepts that are available to de-

scribe data and metadata from a given domain. This

event is composed by a tree-shape object structure.

Regarding the representation of subscriptions, sub-

scribers express their interests (or subscription pat-

terns) using boolean expressions that include predi-

cates on the context of the events in question (Cilia

et al., 2005). These expressions include contextual in-

formation for the correct interpretation and matching

of incoming events.

4.2 Notiﬁcation Service

Independence

An important issue of this work was to ﬁnd a way

to achieve loosely coupling interaction between the

concept-based layer and different underlying notiﬁca-

tion services.

The idea was to encapsulate common functionality

(needed by every NS) to be used by the core of the

concept-based layer, but letting speciﬁc functional-

ity to be implemented by NS-dependent components.

Thus, the main concept-based layer functionality (i.e.,

its core) obtains enough independence to allow easy

integrability with existing NSs.

Figure 3: Publisher and subscriber components.

Figure 3 (a) illustrates the collaboration among

components needed to achieve the publication of mes-

sages. As can be seen, the concept-based layer is

(logically) split into two “parts”: the NS-independent

functionality remains unaware of speciﬁc notiﬁcation

service details, while the NS-dependent part explic-

itly interacts with the notiﬁcation service in question.

As a consequence cooperating applications (or client

code) is freed of speciﬁc notiﬁcation service details. It

only needs to communicate with the NS-independent

part. This allows the migration from one NS to an-

other without modifying clients’ code.

In the same way, Figure 3 (b) shows the compo-

nents involved with consumers. It can be noticed here

again, that the concept-based layer is also split into

two parts: NS-independent components (upper layer)

and NS-dependent components (lower layer). As a

consequence clients only interact with the upper layer.

Both ﬁgures include the MIX repository in order

to allow publishers and subscribers to interact. The

shared vocabulary is used by all participating clients.

Using MIX, possible differences among participants

at the vocabulary level and at the information context

level are solved by a vocabulary agreement module.

Achieving NS independence concentrated on iden-

tifying those components that were commonly needed

in every NS. We arrived to the following three entities:

a) Message,b)Listener, and c) Subscription.

ICEIS 2006 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

In addition to these, a factory component was

needed. It is in charge of creating these entities.

That’s the reason why a component that plays the role

of a factory (named CBFactory) appears in both

ﬁgures. Let’s brieﬂy explain the entities involved.

4.2.1 Message (CBMsg)

This component is a message representative within

concept-based boundaries. It is automatically created

by the concept-based layer to store and manipulate

the original event sent by the publisher application.

It provides a common interface to access most needed

message properties, hiding the real NS message to the

concept-based layer. It presents an abstract interface,

helping the core functionality to ignore the concrete

message representation it is currently being used.

4.2.2 Listener (CBListener)

This component is used by consumer applications to

be notiﬁed when an event of interest arrives. It acts as

an intermediary between the underlying NS-listener

and client’s listener. Right before a notiﬁcation is de-

livered to the subscriber it is ﬁrst automatically con-

verted to the context speciﬁed at subscription time.

This conversion function is needed to deliver ready-

to-process data to consumers so that no further data

conversions are needed.

4.2.3 Subscription (CBSubscription)

When a subscriber issues a new subscription, it re-

ceives a subscription ID as a response. This subscrip-

tion ID will be later needed to issue the correspond-

ing unsubscription. This component hides the way an

unsubscription must be notiﬁed to the underlying NS

mechanism. Subscriber applications just need to in-

voke its unsubscribe method.

4.2.4 Factory (CBFactory)

This component is in charge of creating previously

mentioned entities. It is aware of the underlying de-

livery mechanism (i.e., NS). For each underlying NS

there is a corresponding factory. It presents an ab-

stract interface to the concept-based layer, which re-

mains unaware of the concrete factory it is interacting

with. It provides an interface to:

• create a CBMsg wrapping a NS-dependent mes-

sage,

• publish a CBMsg into the NS this factory is able to

communicate with, and

• subscribe to events/notiﬁcations of interest, return-

ing a CBSubscription to consumer applica-

tions.

5 IMPLEMENTATION

This section describes implementation issues, detail-

ing the integration with different implementations of

the JMS speciﬁcation, as well as the J2EE platform

and Rebeca.

5.1 Notiﬁcation Service

Independence

As previously stated, we proposed NS-independence,

which led us to use the Abstract Factory design pat-

tern (Gamma et al., 1995). This pattern allows to cre-

ate families of related or dependent objects without

specifying their concrete classes.

Figure 4: Concept-based’s abstract factory.

As can be seen in Figure 4, the Con-

ceptBasedFactory provides an inter-

face to create concept-based entities (e.g.,

ConceptBasedMessage or ConceptBased-

Listener). This factory is created at startup and is

NS-dependent, so it “knows” what kind (subclasses)

of entities will be needed to interact with the under-

lying notiﬁcation service. It must be noticed that

factory creation is made at system startup and cannot

be changed at runtime. Thus, once the concept-based

layer is up and running it remains fully attached to

the underlying NS until it is restarted.

Participant applications interact with either the

ConceptBasedSubscriber or Concept-

BasedPublisher (consumer applications

communicate with the former, while publisher

applications interact with the latter). These two com-

ponents (together with the abstract entities) contain

the core functionality of the concept-based layer

and remain unaware of the NS-dependant entities

required to achieve interaction with the underlying

NS.

IMPLEMENTING A HIGH LEVEL PUB/SUB LAYER FOR ENTERPRISE INFORMATION SYSTEMS

5.2 Integrating JMS

Before a semantic event can be delivered to a JMS

notiﬁcation service, ﬁrst it must be mapped to a JMS

message as deﬁned in the JMS speciﬁcation.

When a semantic event arrives to the concept-based

layer, it is converted to the default semantic con-

text and then traversed

to gather every relevant in-

formation. This acquired data is inserted one by

one into a CBMsg which in turn is mapped to an

ObjectMessage

. The properties extracted from

the traversed message need to be mapped to the NS-

dependent message format. This data is inserted as

properties of the JMS-dependent message. This map-

ping operations are NS-dependent and they greatly

vary from the kind of JMS message type.

Now, this ObjectMessage is ready to be de-

livered to the underlying NS since it is an accurate

copy (in another representation/format) of the seman-

tic event in question. This JMS message not only

contains the data/properties required by the underly-

ing NS to perform matching and delivery operations,

but also the (serialized) semantic event it stands for.

Later on, when the JMS message (i.e.,

ObjectMessage) is delivered to the concept-

based layer at the subscriber-side (as a result of a

matching subscription), the originally dispatched

semantic event can be extracted from the JMS

message, converted to the subscriber’s context and

ﬁnally delivered.

5.3 Integrating J2EE

This integration was accomplished using message-

driven beans (MDBs) that according to the EJB spec-

iﬁcation (Sun Microsystems, 2001) are responsible

for dealing with asynchronous communications. An

schematic view of our approach is sketched in Fig. 5.

Figure 5: High-level architecture of concept-based on J2EE.

Remember that a semantic event is a tree-shape object

structure.

An ObjectMessage is one of the ﬁve kinds of mes-

sages supported by JMS. This particular message provides

the capability to store and transport serialized objects.

J2EE subscribers are notiﬁed about events of inter-

est through a CBSubscriber that acts as a MDB

within the J2EE platform, whereas publishers issue

events through a CBPublisher as usual. Interac-

tion among participating applications is achieved by

relying on a JMS delivery mechanism

MDB’s native functionality comprises the sub-

scription to JMS messages and their later announce-

ment. In this way, when concept-based publishers

send notiﬁcations to a JMS NS, every MDB with a

matching subscription will be notiﬁed.

Achieving this interaction between different par-

ticipating applications is not a complex task. Every

subscriber client at the J2EE-side has to extend the

ConceptBasedMDB class. As usual in MDB, this

class provides a hook that has to be implemented

since it is invoked when corresponding notiﬁcations

arrive.

It is worth mentioning that during deploy-time the

MDB gets data regarding contextual information uti-

lized by the consumer application. This information

is available in its XML deployment descriptor ﬁle and

every time a new message arrives to the MDB, it is

used to convert the message to the desired context.

Subsequently, this event can be effectively given to

its consumer application.

5.4 Integrating Rebeca

Rebeca

is an open source event notiﬁcation service

framework. Its data model is an essential part of it

and it is composed by two closely interrelated com-

ponents: Notiﬁcations and Subscriptions. The former

are messages that reify and describe Event occur-

rences emitted by publishers, while the latter are mes-

sage Filters that express subscribers interests. The

Event class is the base class of all notiﬁcations and

encapsulates message data. The Filter class is the

base class of all ﬁlters. Its most important functional-

ity is to determine if a given event matches a ﬁlter.

Originally, Rebeca only supported content-based

addressing model but, it was extended to support

the concept-based addressing model (Antollini et al.,

2004). That’s why, before coding Rebeca’s dependent

components into the concept-based layer we ﬁrstly

enhanced its own data model to support the mentioned

addressing model seamlessly. We only coded two new

classes:

MDBs were restricted to JMS until the latest EJB spec-

iﬁcation

Rebeca is a pub/sub research framework that relies on

its own content-based addressing model. Nevertheless, it

also provides a JMS-compliant interface that allows it to

provide services resembling a JMS NS. In this section we do

not take into account its JMS functionality; we just consider

its pure and basic operational mode.

ICEIS 2006 - DATABASES AND INFORMATION SYSTEMS INTEGRATION

• SemanticEvent. This Event subclass rep-

resents a concept-based message into the Rebeca

NS. It not only contains the SemanticObject

it represents, but also the ConceptBasedEvent

that holds additional information required by the

concept-based layer.

• SemanticFilter. It represents an expression

which is used to check if a subscription matches a

given event. It is a Filter specialization.

With such additions the Rebeca NS is ready to

support the concept-based addressing model directly.

Thus, concept-based layer’s modiﬁcations to support

Rebeca were quite straightforward (i.e., just coding

required Rebeca-dependent classes).

6 CONCLUSIONS AND FUTURE

WORK

This work was motivated by cooperating information-

driven applications, particularly on open distributed

heterogeneous environments. These applications re-

quire the dissemination of vast amounts of data, and

the reaction to notiﬁcations concerning events of in-

terest. Usually, these applications rely on pub/sub

mechanisms. Interaction among such applications

faces up the problem that these notiﬁcations must be

understandable beyond the closed conﬁnes of a single

application/module/component or enterprise. Within

the context of pub/sub the source of a notiﬁcation can-

not anticipate who is interested in a given notiﬁcation.

We proposed the extension of notiﬁcation services

by adding a higher-level layer that provides an ab-

straction to data producers and consumers that sup-

port the interaction among heterogeneous partici-

pants. This layer is responsible for mapping sub-

scriptions and publications to the underlying notiﬁca-

tion delivery mechanism. These enhancements were

designed to be incorporated on top of existing noti-

ﬁcation services. Basically, we abstract participat-

ing clients about different messaging service inter-

faces while providing notiﬁcation service indepen-

dence. We showed how to free participating appli-

cations from any data conversion responsibility and

provided such a functionality as a de facto context,

allowing heterogeneous applications to seamlessly in-

teract among each other.

A variety of tests were successfully performed over

different NS implementations. In the case of JMS, we

discovered that the JMS speciﬁcation lacks some im-

portant issues to enable full compatibility among dis-

tinct JMS vendors. On the other hand, no major dif-

ﬁculties arose while performing these practical eval-

uations on the open-source notiﬁcation service called

Rebeca.

In this work we do concentrate on the problem of

interpretation of exchanged data among autonomous,

distributed and heterogeneous information systems.

We proposed a layer that resolves the problem of data

conversion with the aim of reducing/avoiding mis-

interpretations when exchanging data. Performance

measurements are needed to see the overhead induced

by this layer on the different setups. Preliminary per-

formance experiments show a “penalty” ranging from

20-40%. It must be bore in mind that bare compar-

isons here are not fair since producing and consuming

applications do need to compute (ad-hoc) data conver-

sions scattered among many applications. Therefore,

the impact of development and maintenance needs to

be taken into consideration.

As a ﬁnal remark, we can add that the integral use

of ontologies to support the correct interpretation of

data coming from heterogeneous sources was of par-

ticular interest. The data representation of the MIX

implementation used in this prototype is based on se-

rializable java objects. An OWL-based implementa-

tion was built (Kabus, 2003) and is being integrated

in the next generation of our prototype.

Additionally, a centralized administration user in-

terface for the concept-based layer is under develop-

ment. Through this interface a common vocabulary

can be deﬁned, the ontology can be edited, new con-

version functions can be described, the matching con-

text can be speciﬁed, and the mapping strategies into

the underlying addressing model can be conﬁgured.

Our current efforts also include different performance

experiments.

REFERENCES

Abiteboul, S., Cluet, S., and Milo, T. (1997). Correspon-

dence and Translation for Heterogeneous Data. In Intl.

Conf. on Database Theory. Delphi, Greece.

Aguilera, M., Strom, R., Struman, D., Astley, M., and

Chandra, T. (1999). Matching Events in a Content-

based Subscription System. In Procs of ACM

SIGACT-SIGOPS Symposium on Principles of Dis-

tributed Computing, pages 53–61.

Antollini, J., Antollini, M., Guerrero, P., and Cilia, M.

(2004). Extending Rebeca to Support Concept-based

Addressing. In Proceedings of the Argentinean Sym-

posium on Information Systems (ASIS’04), Cordoba,

Argentina.

Bacon, J., Moody, K., and Bates, J. (1998). Opera: Active

systems. Technical Report GR/K77068, University of

Cambridge - Computer Laboratory.

Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The

Semantic Web. Scientiﬁc American, 284(5):35–43.

Bornh

ovd, C. (1999). Semantic Metadata for the Integra-

tion of Web-based Data for Electronic Commerce. In

Procs of WECWIS’99, pages 137–145. IEEE Press.

IMPLEMENTING A HIGH LEVEL PUB/SUB LAYER FOR ENTERPRISE INFORMATION SYSTEMS

Bornh

ovd, C. (2000). Semantic Metadata for the Integra-

tion of Heterogeneous Internet Data. PhD thesis, De-

partment of Computer Science, Darmstadt University

of Technology, Darmstadt, Germany.

Bornh

ovd, C. and Buchmann, A. (1999). A Prototype for

Metadata-based Integration of Internet Sources. In

Procs of CAiSE, volume 1626 of LNCS, pages 439–

445.

Bornh

ovd, C., Cilia, M., Liebig, C., and Buchmann, A.

(2000). An infrastructure for meta-auctions. In Proc.

of (WECWIS’00).

Bornh

ovd, C. and Buchmann, A. P. (2000). Semantically

meaningful data exchange in loosely coupled environ-

ments. In Procs of Intl Conf on Information Systems

Analysis and Synthesis (ISAS’00), Orlando, FL, USA.

Bray, T., Paoli, J., and Sperberg-McQueen, C. (1998). Ex-

tensible Markup Language (XML) 1.0. W3C Rec-

ommendation, W3C, http://www.w3.org/TR/

REC-xml.

Carzaniga, A. (1998). Architectures for an Event Notiﬁ-

cation Service Scalable to Wide-area Networks. PhD

thesis, Politecnico di Milano, Milano, Italy.

Cilia, M., Antollini, M., Bornh

ovd, C., and Buchmann, A.

(2004). Dealing with heterogeneous data in pub/sub

systems: The Concept-Based approach. In Procs of

DEBS’04, Edinburgh, Scotland.

Cilia, M., Bornh

ovd, C., and Buchmann, A. (2001). Moving

Active Functionality from Centralized to Open Dis-

tributed Heterogeneous Environments. In Proceed-

ings of CoopIS, pages 195–210, Trento, Italy.

Cilia, M., Bornh

ovd, C., and Buchmann, A. (2005). Event

handling for the universal enterprise. Information

Technology and Management – Special Issue on Uni-

versal Enterprise Integration, 5(1):123,148.

Cugola, G., Nitto, E. D., and Fuggetta, A. (1998). Exploit-

ing an Event-based Infrastructure to Develop Com-

plex Distributed Systems. In Proc. of ICSE’98.

D. Conolly et al. (2001). DAML+OIL (March 2001) Refer-

ence Description. W3C Note, W3C, http://www.

w3.org/TR/daml+oil-reference.

Deutsch, A., Fernandez, M., and Suciu, D. (1999). Stor-

ing semistructured data in relations. In Workshop on

Query Processing for Semistructured Data and Non-

standard Data Formats. Jerusalem, Israel.

Eisenberg, B. and Nickull, D. (2001). ebXML Technical

Architecture Speciﬁcation v1.04. Technical report,

http://www.ebxml.org.

Fallside, D. (2001). XML Schema Part 0: Primer. W3C

Recommendation, W3C, http://www.w3.org/

TR/xmlschema-0/.

Fiorano. FioranoMQ. www.fiorano.com.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design Patterns, Elements of Reusable

Object-Oriented Software. Addison-Wesley.

Gruber, R., Krishnamurthy, B., and Panagos, E. (1999).

The Architecture of the READY Event Notiﬁcation

Service. In Proceedings of th 19th IEEE Intl. Conf.

on Distributed Computing Systems Middleware Work-

shop.

Haase, K. (2002). Java Message Service API Tutorial. Sun

Microsystems.

Hapner, M., Burridge, R., and Sharma, R. (1999). Java Mes-

sage Service. Speciﬁcation Version 1.0.2, Sun Mi-

crosystems, Inc., Java Software.

Harrison, T. H., Levine, D. L., and Schmidt, D. C. (1997).

The Design and Performance of Real-time CORBA

Event Service. In Proc. of OOPSLA’97, pages 184–

200.

IBM. MQ-Series. www-4.ibm.com/sotware/ts/

mqseries.

Kabus, P. (2003). Implementing Semantic Data Integration

for the Internet (in german). Master’s thesis, Depart-

ment of Computer Science, Darmstadt University of

Technology, Germany.

Microsoft Corp. (2000). Biztalk Framework 2.0: Docu-

ment and Message Speciﬁcation. Microsoft Technical

Speciﬁcation.

uhl, G. (2001). Generic Constraints for Content-based

Publish/Subscribe Systems. In Proc. of CoopIS’01,

volume 2172 of LNCS, pages 211–225. Springer.

Object Management Group (1997). Event Service Spec-

iﬁcation. Technical Report formal/97-12-11, Object

Management Group (OMG), Famingham, MA.

Object Management Group (2000). CORBA Event Ser-

vice Speciﬁcation, version 1.0. OMG Document

formal/2000-06-15.

Oki, B., Pﬂuegl, M., Siegel, A., and Skeen, D. (1993). The

Information Bus - An Architecture for Extensible Dis-

tributed Systems. In Proceedings of the 14th Sympo-

sium on Operating Systems Principles.

Papakonstantinou, Y., Garcia-Molina, H., and Widom, J.

(1995). Object Exchange Across Heterogeneous In-

formation Sources. In Prof. of ICDE ’95.

RosettaNet (2002). RosettaNet Implementation Frame-

work: Core speciﬁcation v2.00.01. RosettaNet Tech-

nical Speciﬁcation, http://www.rosettanet.

org/rnif.

SonicSoftware. SonicMQ. www.sonicsoftware.

com/products.

SpiritSoft. Spirit Lite. www.spirit-soft.com/

products/lite/overview.html.

Sun Microsystems, I. (2001). Java 2 Enterprise Edition Plat-

form Speciﬁcation. Technical Report Version 1.3, Sun

Microsystems, Inc.

Sun Microsystems, Inc. (1998). Distributed Event

Speciﬁcation. Mountain View, CA, USA.

http://www.javasoft.com/products/

javaspaces/specs.

Talarian. SmartSockets for JMS. www.talarian.com/

products/jms/index.shtml.

TIBCO Inc. (1996). TIB/Rendezvous. White

Paper, http://www.rv.tibco.com/

rvwhitepaper.html.

ICEIS 2006 - DATABASES AND INFORMATION SYSTEMS INTEGRATION