Pluggable Java EE-based Architecture for Efficient Coupling ofEvent-based Applications

Samuel Dauwe, Bruno Van Den Bossche, Filip De Turck, Bart Dhoedt, Piet DemeesterDepartment of Information Technology, Ghent University - IBBT, Gent, Belgium

Abstract— In many enterprises, business functions arespreaded across multiple applications. In order to provideefficient, reliable and secure data exchange between appli-cations, these components need to be integrated. In thiscontext, component based technologies have become verypopular. Component architectures such as Java EE facili-tate rapid and flexible application development. Nowadays,messaging system are frequently used to enable high-speed,asynchronous, program-to-program messaging. In spite ofthe many existing asynchronous communication solutions,there is a need for an efficient generic messaging model.

In this article we present the architecture of a pluggablemessaging system targeted at enterprise applications. Thismodel was used to implement a fully functional prototypeusing Java EE specific technologies. To evaluate our mes-saging system, performance tests were done. Results fromthis evaluation show that the system is capable of efficientasynchronous communication.

Keywords: Java EE, event based, software architecture

1. IntroductionThe growth of the internet and the increased attention to

object-oriented programming has resulted in a rapid adoptionof distributed component architectures. These architecturesprovide the foundation and standards for invoking objectswithin one application from another application independentof their location.

Traditional applications use synchronous function calls;for example: one method calling another method, or oneprocedure invoking another remotely through a remote pro-cedure call (such as RMI [1], CORBA [2] and DCOM [3]).Synchronous calls imply that the calling process blockswhile the other process is executing a function and can onlyproceed when control is returned. In this model all systemshave to be online and functioning flawlessly, resulting intight semantic coupling. This point-to-point and synchronouscommunication approach is very suitable in rigid and staticapplications. However, with the increasingly dynamic natureof large-scale complex systems today, there is clearly aneed for a middleware providing asynchronous messaging.We illustrate the importance of the asynchronous messagingprinciple by presenting a message-driven application. Con-sider an Air Traffic Control System, used for monitoring andcontrolling arriving and departing airplanes. First of all there

are various sources of information like airplane transpondersproviding location information, weather stations and trafficupdates from neighboring airports. This large amount of datahas to be processed and presented in real-time. On the basisof this information, decisions can be made, which have to becommunicated to the airplanes. It is clear this kind of systemis difficult to realize using synchronous components. Firstly,there is the dynamic nature of the application. Moreover,communication between the varying number of componentsshould be reliable. When data is packaged in independentmessages or events, a store and forward approach canprovide reliability. A sender can simply send the messageto the system and continue with other processes, resultingin a asynchronous communication style.

These days, distributed multi-tiered application modelslike Java EE [4] and Microsoft.NET [5] are very popularand commonly used in the context of enterprise applications.In the Java Enterprise Edition there is the Java MessageService (JMS) [6] that can act as a communication channel.However, as event model it is not efficient enough, especiallyfor heavily event-driven enterprise applications. First of allJMS is centered around the paradigm that each message isguaranteed to be delivered once and only once. This focus onreliability has consequences on the performance and the in-troduced overhead when creating messages [7]. Furthermore,all message channels must be known before deploymentwhich makes it not very flexible. Although dynamic channelcreating is possible, it is difficult to implement. When weconsider technologies similar to Java EE, we notice similardisadvantages.

This paper focuses on the development and implemen-tation of a framework that acts as a generic, event modelbetween loosely coupled enterprise applications achievingefficient communication. Firstly, we give an overview ofcommonly used Java based application server environmentsusable to create event-oriented applications (Section 3).Next, we present the architecture of our messaging system(Section 4). We used this architecture to implemented a fullyfunctional prototype using Java EE specific technologies asdescribed in Section 5. An evaluation was done, investigationthe most common performance metrics (Section 6). Finally,in Section 7 future work is stated an our conclusions arepresented in Section 8.

2. Related WorkTraditionally asynchronous behavior in Java EE is realized

using JMS. A number of design patterns make actively use ofthis asynchronous behavior to simulate threaded behavior toexecute multiple tasks in parallel. By using the Splitter andAggregator pattern [8] this can be achieved in the context ofJava EE application servers. Using the event based approachproposed in this paper, the implementation of this patterncan be made highly efficient, compared to a the traditionalJMS based implementation. The same can be applied to theService Activator pattern [9] to allow business services tobe invoked asynchronously.

A typical use of the asynchronous invocation of businesservices is in the web-tier of enterprise applications makinguse of AJAX [10]. AJAX or Asynchronous JavaScript andXML, is a group of interrelated web development techniquesused to create rich Internet applications. This allows webapplications to retrieve data from the server asynchronouslyin the background without interfering with the display andbehavior of the existing page. For example a servlet offersan initial version of the web page and the results of longrunning tasks in the back end application server are fetchedusing Asynchronous JavaScript.

An overview of the use and advantages of asynchronouscommunication for complex e-commerce applications isgiven in [11]. This allows to increase the throughput ofthe application significantly as shown in [12]. TraditionallyJMS is used for these optimizations, however, using the lowoverhead event based communication proposed in this paperallows to further increase the performance.

An Enterprise Service Bus (ESB) is an architectural pat-tern which defines a communication infrastructure betweenservices. The main role of an Enterprise Service Bus (ESB)is to serve as a communication bus accepting a variety ofinput message formats and to transform these messages todifferent output formats and thus providing a transparentcommunication interface. A functional overview of com-mercial ESBs is presented in [13] and [14] evaluates theperformance of four both commercial and non commercialESB implementations.

3. Java-Based Application ExecutionFrameworks

The Java Enterprise Edition (Java EE) [4], has emerged asa leading component architecture for applications requiringagility, scalability and interoperability. In this section wegive an overview of existing Java-based application execu-tion frameworks which are usable for the creating of event-oriented applications.

3.1 Java EEThe Java EE platform is essentially a Java application

server environment that provides a set of Java extension APIs

to build applications and a runtime infrastructure for hostingapplications. Business applications are deployed and run in acontainer that manages application components and providestransparently access to Java EE services like transactionmanagement, security checks and resource pooling.

The application container hosts Java EE applicationscomposed of Enterprise Java Beans (EJBs). There are threetype of EJBs: Session Beans which contain the businesslogic, Entity Beans which represent data and Message-Driven Beans which allow for asynchronous communication.Additionally a web-container is provided which enables thehosting of HTTP-based services. Figure 1 gives an overviewof the Java EE logical architecture.

The typical way of communicating with a Java EE Ap-plication server is through synchronous method calls andthe same goes for the inter component communication.Clients can interact directly with application componentsusing a Java EE application client which performs RemoteMethod Invocations. For asynchronous communication, theJava Message Service (JMS) can be used in combinationwith Message-Driven Beans (MDB). JMS allows to con-figure communication channels called queues (one-to-onecommunication) or topics (one-to-many communication),MDBs consume and process the incoming messages on thosechannels. However, the capabilities of the JMS system aresomewhat limited as the queues and topics are staticallyconfigured at deploy-time and no other efficient routingmechanisms are available in the framework.

Apart from this there is also support for deploying Java EEConnector Architecture Resource Adapters (RA) [15] intothe application server. Deployable JCA components arecalled resource adapters. The Java EE Connector Architec-ture (JCA) defines a standard architecture for connecting theJava EE platform to a heterogeneous Enterprise InformationSystem (EIS). An EIS provides the information infrastruc-ture for an enterprise, examples EIS are ERP (EnterpriseResource Planning), database systems and legacy applica-tions. By defining a set of scalable, secure, and transactionalmechanisms, JCA enables the integration of an EIS with anapplication server and enterprise applications. The resourceadapter plugs into an application server and provides con-nectivity between the EIS, the application server, and theenterprise application. The Java EE Connector Architecturewas originally designed for implementing RAs to interfacewith existing (legacy) systems, but it can be used in a moregeneral context to extend the Java EE application server withextra protocol stacks. For example, the JMS stack typicallyis implemented as a RA as well.

3.2 JSLEEThe Java APIs for Intelligent Networks (JAIN) [16] aims

for an enabling set of Java APIs to develop and deployservice-driven network applications. The JAIN Service LogicExecution Environment (JSLEE) specification [17] provides

Java EE Application Server

Application

Component

Resource

AdapterEnterprise

Information

System

Container-Component

Contract

System

Contracts

EIS

specific

interface

Client API

Fig. 1: Presentation of the Java EE logical architecture.

an application server targeted at Java communications ap-plications demanding a high throughput, low latency eventprocessing environment. Applications are composed of Ser-vice Building Blocks (SBBs) which are the equivalent ofthe Java EE EJBs. One of the key features of the JAINSLEE application container is the use of asynchronouscommunication. Internally almost all communication in theSLEE happens by using events. The idea behind the eventbased communication between SBBs is that every SBBperforms its own task and then hands the result off to thenext SBB in line. One could compare this to an assemblyline in a factory

The internal routing is completely taken care of by theapplication server. A key component in the routing of eventsis the Activity Context which manages the links betweenlogically connected SBB entities. When an initial event (forexample the first message in a message flow) enters theSLEE an Activity Context is created. The SBBs processingthis event will be attached to this Activity Context and allfollowing events which logically belong together (e.g. allevents related to the same message flow) will be fired onthe same Activity Context and processed by the same SBBentities. This is important as the SBB entities processingmessages from a single message flow use this ActivityContext to share data. This is comparable to the use ofSessions in the context of Java EE.

Communication with the outside world happens throughResource Adaptors which are similar to RAs in Java EE.An RA is a component which can be pluggind in the JAINSLEE application server. This component then functions asa pass through for external events to the SBBs and theoutside world and vice versa. Typically such an RA isused enable the JAIN SLEE to communicate using a certainprotocol stack. Using this mechanism allows the JAIN SLEEapplication server be protocol agnostic, i.e. it offers allrequired functionality for a generic event based applicationserver and can be extended to support any protocol usingRAs.

4. ArchitectureIn section 3 we gave a brief overview of JSLEE and

Java EE. Although the two technologies are complemen-tary, they are targeted at different types of applications.Because JSLEE is a specialized component model for event

driven applications, it lacks some concepts which are presentin Java EE. First of all, enterprise applications are moredatabase access intensive. As a consequence, Java EE hasbetter support for back-end systems and transactions, whichis also reflected in the EJB specification. When we want tocreate event-driven enterprise applications, there is a needfor a pluggable event model for Java EE application servers.

In this section we present the designed architecture of ourmessaging system aimed at enterprise applications, as shownin Figure 2. This event channel provides an asynchronousmessaging service between the different application compo-nent which can reside in the same container or distributed ondifferent machines. It consists of a set of modules interact-ing together and implementing several functional and non-functional properties like routing, reliability and orderingof message transfers. The requirements of the messagingsystem can be summarized as followed:

4.1 Requirements• Publish/Subscribe Components should be able to reg-

ister themself with the messaging system by stating theevent type there interested in. Received events matchingthis interests will only be forwarded to those subscribedlisteners. Each component should be able to attach anddetach at any moment.

• Asynchronous Communication The sender should nothave to wait for the receiver to receive and processthe message; it should not even have to wait for themessaging system to deliver the message. This allowsto run applications at maximum throughput and avoidunnecessary waiting time.

• Mediation The messaging system acts as a mediatorbetween all of the programs that can send and receivemessages. If an application becomes disconnected fromthe others, it need only reconnect to the messagingsystem. The event channel should also provide accessto shared resources such as a datastore.

In the remainder of this section we give an overview ofeach component in the presented architecture.

4.2 Component DescriptionApplication Component An application component can

be a server-side component, such as a Message-Driven beanwhich allows asynchronous invocation. Application logicis divided into components according to their function.When distributed components want to cooperate they haveto exchange messages. Typically, each component shouldhave the possibility to send or receive messages using themessaging system.

Connection The connection provides connectivity to theresource adapter. Components will first setup a connec-tion with the event channel through which they can asyn-chronously send and receive messages. Beside sending

Datastore

Messaging System

Logical Bus

Remote Listener

Remote Event Endpoint Proxy

Main Buffer

Event Processor

ConnectionStorage

Adapter

Event Handler Event Handler

Logical Bus Logical Bus

Local Event Endpoint Proxy

Logical Bus

Application

Component

Application

Component

Event

Event EventEventEvent

Event Event Event Event

EventEvent

Event Event

Event

Session

Data

Session

Data

Fig. 2: Overview of the designed architecture of the mes-saging system containing modules interacting together andimplementing several functional and non-functional proper-ties

events there will also be the possibility to store sessionrelated data in a datastore.

Event Handler This component acts as an interface to theunderlying network protocol. When messages are receivedfrom components residing in the local or remote containerthey often have to be translated to Java objects which themessaging system can handle.

Event Processor This module contains the actual logic ofthe resource adapter. Events received from the applicationcomponents come together in the central buffer. Next, theevent header of each message is analyzed by the eventprocessor to determine the destination. The event processordrops events silently whenever there is a problem with theheader, like unknown destination or wrong format. Becausethere is loosely coupling between sender and receiver, mes-sage producers are not notified when such a drop occurs.

Logical Bus According to the publish/subscribe paradigm,events are delivered to listeners according to their event type.Messages belonging to the same class should be treated thesame, for example routed to the same subscribers. Therefore,we have chosen to introduce logical buses. These compo-nents will handle the events which have the same event type.Using this approach it is easier to provide a desired qualityof service (QoS), another advantage is the fact that thesebuses operate in parallel increasing the overall performance.A logical bus has the following responsibilities:

• Filtering: Each logical bus is responsible for handlingevents which have the same event type. To providequality of service there should be a filtering phase. Thisprocess will treat events differently according to extrainformation contained in the event header. For example,high priority messages will be handled first and placedin front of the queue in the next phase.

Filter Buffer Dispatcher Endpoint

Logical bus

Event Event Event Event

Fig. 3: Logical bus.

• Buffering: The publish/subscribe principle gives ap-plication components the opportunity to register andderegister themselves dynamically. Events received fora logical bus with no associated listeners should bebuffered to ensure delivery. This buffer also give theopportunity to deal with high loads.

• Routing: The dispatcher is responsible for the deliveryof messages to the appropriate event endpoint. Routingis done by passing the event to the local or remote eventendpoint proxy. The proxy passes the message to theendpoint, hiding, using the underlying communicationprotocol.

Storage Adapter Application components can use theconnection to send session related data to the StorageAdapter. This adapter will generate an unique session iden-tifier and handles data retrieval process.

Datastore Encapsulating large amounts of data in eventsshould be avoided because they will decrease the overallperformance of the event system. Furthermore, real-timecommunication is not always necessary for applications. Inthis case it should be possible for application components tostore session related data and generate an event notifyingthe information is available. Next, other components canretrieved the data from the datastore, and continue theiroperations. With this approach, event sizes are kept smallin size, furthermore when another datastore is required theonly thing that have to be modified is the interface to theevent model.

4.3 Component InteractionTo illustrate how components in the architecture interact

we briefly describe a scenario when an event is exchanged.Figure 4 shows the sequence diagram of this internal com-munication scenario. The application sends an event usingthe resource adapter connection, which will be intercepted bythe event handler. There is a handler for each connection,this component also contains protocol specific logic (e.g.creating Java objects from a bytestream). Next, the event isplaced in a buffer where it remains until the event processoris able to process it. In a first step, the event processoranalyzes the event header to determine if it is registration orderegistration or a normal message. According to the eventtype, logical buses are created and given to the matching bus.Finally, the bus will be responsible for the filtering, bufferingand routing to the event endpoints. The event is deliveredto the receiving application component by asynchronouslyinvoking an interface method.

Application

ComponentConnection

Event

Handler

Event

ProcessorLogical Bus Event Endpoint Proxy

fireEvent(Event)

fireEvent(Event)

queue.put(Event)

AnalyseHeader()

LookupLogicalBus()

handleEvent(Event)

filterEvent(Event)

putOnQueue(Event)

determineListeners()

deliverEvent(Event)

onEvent(Event)

Fig. 4: Sequence diagram giving an overview of the interaction between the messaging system components when sendingan event. The sending and receiving application components reside in the same container

J2EE Applicatie Server

Web Container

Servlet JSP Page

EJB Container

EJB EJB

Client Machine

Application Client

Container

Browser

Application

Client

Database

HTTP/

SSL

HTTP/

SSL

RMI-IIOP

Fig. 5: Overview of the different contracts between thelogical entities in the Java EE Connector Architecture

5. Implementation DetailsThe Java EE Connector Architecture (JCA) defines a

standard architecture for connecting the Java EE platformto a heterogeneous Enterprise Information System (EIS).Deployable JCA components are called resource adaptersand plug into an application server and provides connectivitybetween the EIS, the application server, and the enterpriseapplication. Nowadays, the Java EE Connector Architectureis used in a more general context for example to extend theJava EE application server with protocol stacks. BecauseJCA makes it possible to develop a pluggable communica-tion module, it was chosen as implementation technologyfor our messaging system. To achieve a standard system-level pluggability, the connector architecture defines a set ofsystem-level contracts which are the following:

Connection management contract enables an applica-tion server to pool connections to an underlying EIS, andenables application components to connect to an EIS.

Transaction management contract enables an applica-

tion server to use a transaction manager.Security contract provides support for a secure applica-

tion environment that reduces security threats.Lifecycle management contract provides a mechanism

for the application server to bootstrap a resource adapterinstance during its deployment or application server startupand to notify the resource adapter instance during its unde-ployment or an orderly shutdown of the application server.

Work management contract allows a resource adapterto submit thread instances for execution.

Transaction inflow contract that allows a resourceadapter to propagate an imported transaction to an appli-cation server.

Message inflow contract that allows a resource adapterto asynchronously deliver messages to message endpointsresiding in the application server.

The Common Client Interface (CCI) defines a API foraccessing EISs, used by application components. The con-nector architecture recommends, that a resource adaptersupport CCI as the client API. A client API specific to thetype of a resource adapter and its underlying EIS could alsobe used instead.

A Resource Adapter allows bidirectional connectivity be-tween a J2EE application and an enterprise information sys-tem (EIS). Unfortunately, the Connector Architecture doesnot specify the way of communication between componentsresiding in different containers. With the Java Java 2 Stan-dard Edition 1.4 it is possible to create non-blocking sockets.Previously, a thread had to be started for each connection todeal with multiple socket connections. This approach gaveissues such as operating system limits, deadlocks, or thread

J2EE Application Server

Event Service

Event listener

Event producer

J2EE Application Server

event

event

Event producer/

listenerEvent

Event

Event Service

100 Mbit TCP/IP

Network

100 Mbit TCP/IP Network

Fig. 6: Test setup used to measure the messaging latencywhen both the sender and receiver run on the same machine

safety violations. With Java NIO [18] one can use selectorsto manage multiple simultaneous socket connections on asingle thread, which makes writing scalable, portable socketapplications simpler. We chose to use the Java NIO technol-ogy because it allows to create nonblocking sockets, result-ing asynchronous high-performance communication betweencontainers.

6. Evaluation ResultsIn this section we evaluate the capacity of our developed

messaging system. The first performance metric we investi-gate is the latency, which is defined as the worst-case timetaken to deliver messages from the sender to the receiver.This metric gives an idea of how efficiently the event channelcan route messages. In our test scenario, we measure thelatency for events with changing event size. Determining theintroduced delay in a distributed environment is difficult,because all the systems clocks need to be synchronizedprecisely. Therefore, we run both the sender and receiveron the same machine so that the latency can be measuredusing the same clock. This approach has the disadvantagethat communication components and messaging system allrun on the same machine. Therefore, the CPU demand ofthe test components influence the messaging performance.

Figure 6 shows the used test setup. The sending com-ponent encapsulates the current timestamp (Ts) in an event.When the receiving component gets the message, it retrievesthe current time (Tr). The messaging latency is then calcu-lated using the formula: Latency = Tr − Ts

The performance evaluation of the event channel de-scribed in this section was done on two testmachines withthe following hardware: Athlon XP (Palomino) 1.4 Ghz, with256 Mb memory and connected by a 100 Mbit network.The machines were running the Debian Linux operatingsystem, kernel version 2.6.11.3. We used the JBoss 4.0.5.GAApplication Server and Java Virtuele Machine 1.5.0 10-b03to run the different Java based test components. The latencyand throughput tests were done using a 1 minute warm-upperiod, followed by 5 minutes of measurement.

Figure 7 shows the results for this experiment. The firstthing that we can notice on this figure is that the eventchannel is very scalable and latencies increase as message

0

50

100

150

200

250

300

350

0 20000 40000 60000 80000 100000 120000

Late

ncy (

ms

ec

)

Send Rate (events/sec)

0 KiB

5 KiB

50 KiB

500 KiB

2000 KiB

Fig. 7: Internal communication latency distribution forevents with varying payload sizes

J2EE Application Server

Event Service

Event listener

Event producer

J2EE Application Server

event

event

Event producer/

listenerEvent

Event

Event Service

100 Mbit TCP/IP

Network

100 Mbit TCP/IP Network

Fig. 8: Test setup used to measure the messaging throughputwhen both the sender and messaging system run on differentmachines

sizes go up. The latency remains almost constant at 4 msecuntil a sendrate of 18000 events/sec for all events payloadsizes. When this injection rate is reached latencies increasevery rapidly until the maximum sendrate is reached.

A second experiment focuses on the throughput mea-surement of the external communication. This metric isdefined as the maximum number of messages that can bedelivered in a time period. Figure 8 shows the used test setup.The sending component sends messages to itself using themessaging system, which is located on a different machine.The messages transmitted in a time period increases untilthere is a difference between send rate and receive rate.

Table 1 presents the results for this experiment. Becausethe events are transmitted through a 100 Mbit networkwe did a comparison between the theoretical and practicalachievable sendrates. The theoretical sendrate is calculatedusing the formula: SRT = NC/ES. Where SRT presentsthe theoretical sendrate, NC the network capacity in KiB/secand ES the event size in KiB.

As can be derived from the comparison table, there is asignificant difference when sending events at a high rate.When we measured the time the senders blocks whilesending an event, we notice an increased timeout withhigher event payload sizes. Therefore, we can conclude thecurrent approach of using non-blocking sockets resulted inbehavior which is not truly asynchronous. When sendingevents between containers residing on different machines,the network becomes the bottleneck.

Table 1: Theoretical and practical sendrate comparison whensending events between different containers located at dif-ferent testmachines.

Event Size Theoretical Max connection Max sendrate(KiB) sendrate (events/sec.) call delay (ms) (events/sec.)0,826 15496 0,46 21935,826 2197 0,90 1111

50,826 252 6,34 158500,826 26 173,01 62000,82 6 284,42 4

7. Future WorkThe evaluation results presented in this paper show the

event architecture to be capable of high throughput eventprocessing. Due to the behavior Java Virtual Machine mem-ory management and the use of automatic garbage collectionwe assume the obtained results can be further improved uponusing Garbage Collection tuning [19].

Hosting business applications are typically outsourced tospecialized hosting providers. This reduces the maintenancecosts and investments for the application provider. To ac-commodate the hosting provider, the platform should supportautonomic management and load balancing to make optimaluse of the available resources. We intend to incorporatethe event bus in an event based distributed platform forMassively Online Virtual Environments [20], [21].

8. ConclusionsToday, the Java Enterprise Edition is commonly used as a

component architecture where asynchronous communicationcan be achieved by the Java Message Service in combinationwith Message-Driven Beans. However, as event model it isnot efficient enough. Alternative technologies exist but theyall have similar disadvantages.

In this paper we presented the architecture for an efficient,generic event model. We also provided a working imple-mentation using Java EE specific technologies like the JavaConnector Architecture. JCA makes it possible to extend ap-plication servers with pluggable modules, which can provideconnectivity to legacy information system or can extend thefunctionality of the application server (e.g. additional pro-tocol stack). Because the Java Connector Architecture alsospecifies the communication between components residingin the same container we have chosen to use nonblockingsockets to realize the external communication.

From our evaluation results, we conclude that the pre-defined requirements are met. First of all, events can beeasily exchanged in a asynchronous manner using pub-lish/subscribe. The concept of logical buses, makes themodel very flexible as components can register and unreg-ister themselves at any time even if the specific event typewas not produced yet. Additionally the event delivery is veryperformant. Finally, because the application server managesa pool of instances we can achieve a parallelized executionenvironment with increased performance.

AcknowledgmentFilip De Turck is a postdoctoral Fellow of the Fund for

Scientific Research - Flanders (F.W.O.-Vlaanderen).

References[1] W. Grosso, Java RMI, O’Reilly, Ed. O’Reilly, 2001.[2] Object Management Group, “Common Object Requesting Broker

Architecture (OMG CORBA),” [online], http://www.corba.org/.[3] Microsoft Corporation, “Distributed Component Object Model

(DCOM),” [online], www.microsoft.com/COM/.[4] Sun Microsystems, “Java Platform, Enterprise Edition,” [online],

http://java.sun.com/javaee/.[5] Microsoft Corporation, “.NET Framework,”

www.microsoft.com/NET/.[6] Sun MicroSystems, “Java Message Service (JMS),”

http://java.sun.com/products/jms/, Oktober 2006.[7] S. Chen and P. Greenfield, “Qos evaluation of jms: an empirical

approach,” System Sciences, 2004. Proceedings of the 37th AnnualHawaii International Conference on, pp. 10 pp.–, 5-8 Jan. 2004.

[8] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing,Building, and Deploying Messaging Solutions. Boston, MA, USA:Addison-Wesley Longman Publishing Co., Inc., 2003.

[9] D. Alur, D. Malks, J. Crupi, G. Booch, and M. Fowler, Core J2EEPatterns (Core Design Series): Best Practices and Design Strategies.Mountain View, CA, USA: Sun Microsystems, Inc., 2003.

[10] J. J. Garrett, “Ajax: A new approach to web applications,”http://adaptivepath.com/ideas/essays/archives/000385.php, February2005, [Online; Stand 18.03.2008]. [Online]. Available:http://adaptivepath.com/ideas/essays/archives/000385.php

[11] W. Q. Cao, J. Z. Li, K. H. Wang, and T. Zeng, “Asynchronouscommunication for complicated e-commerce applications,” Nov. 2003,pp. 161–168.

[12] S. Kounev and A. Buchmann, “Improving data access of j2ee appli-cations by exploiting asynchronous messaging and caching services,”in VLDB ’02: Proceedings of the 28th international conference onVery Large Data Bases. VLDB Endowment, 2002, pp. 574–585.

[13] L. Macvittie, “Make way for the ESB,” Network Computing, vol. 17,no. 5, pp. 41–58, March 2006.

[14] S. Desmet, B. Volckaert, S. Van Assche, D. Van Der Weken,B. Dhoedt, and F. De Turck, “Throughput evaluation of differententerprise service bus approaches,” in Proceedings of the 2007 Inter-national Conference on Software Engineering Research in Practice(SERP’07), 2007.

[15] Sun Microsystems, “J2EE Connector Architecture 1.5,” [online],http://www.jcp.org/en/jsr/detail?id=112.

[16] J. de Keijzer, D. Tait, and R. Goedman, “JAIN: A New Approachto Services in Communication Networks,” IEEE CommunicationsMagazine, vol. 38, no. 1, pp. 94–99, January 2000.

[17] Sun Microsystems, “JAIN SLEE API Specification,” [online],http://jcp.org/en/jsr/detail?id=22.

[18] Sun MicroSystems, “The new I/O (NIO) APIs,”http://java.sun.com/j2se/1.4.2/docs/guide/nio/, Oktober 2006.

[19] B. Van Den Bossche, F. De Turck, B. Dhoedt, and P. Demeester,“Enabling Java-based VoIP backend platforms through JVM perfor-mance tuning,” in Proceedings of the 1st IEEE workshop on VoIPManagement and Security: VoIP MaSe co-located with IEEE NOMS2006, S. Niccolini, H. Schulzrinne, and S. R, Eds., Vancouver, Canada,April 2006, pp. 41–46.

[20] B. Van Den Bossche, T. Verdickt, B. De Vleeschauwer, S. Desmet,S. De Mulder, F. De Turck, B. Dhoedt, and P. Demeester, “A Platformfor Dynamic Microcell Redeployment in Massively Multiplayer On-line Games,” in Proceedings of NOSSDAV2006: the 16th InternationalWorkshop on Network and Operating Systems Support for DigitalAudio and Video, Rhode Island, USA, May 2006, pp. 14–19.

[21] B. Van Den Bossche, B. Dhoedt, F. De Turck, and P. Demeester,“Autonomic Service Hosting for Large-Scale Distributed MOVE-services,” in (Awaiting publication) Proceedings of IM2009: The 11thIFIP/IEEE International Symposium on Integrated Network Manage-ment, New York, New York, USA, June 2009.