Conference PaperPDF Available

Tutorial: open source enterprise application integration - introducing the event processing capabilities of apache camel


Abstract and Figures

"Interesting applications rarely live in isolation." ([1], xxix) With this sentence G. Hohpe and B. Woolf start the introduction to their book Enterprise Integration Pattern: Designing, Building, and Deploying Messaging Solutions. While the statement is valid now for more than ten years, Gartner estimates today the cost increase targeting integration aspects for midsize to large companies at about 33% within the next three years (cf. [2]). The expected increase will be mainly driven by the integration of cloud services and mobile devices. Since event processing addresses clearly problems arising with the growth of computational distribution, particularly with the increasing number of mobile devices or cloud services, integration is a topic that needs to be addressed by event processing functionalities. One of the frameworks within the integration domain is Apache Camel. Since it's initial release in 2007, the framework has gained quite some attention - not only within the open-source arena. Apache Camel has a strong focus on enterprise application integration since it implements well known Enterprise Integration Patterns (EIP's) (cf. [1]). This work reveals the event processing capabilities of Apache Camel alongside a logistics parcel delivery process. The delivery process facilitates the scenario descriptions to exemplify the event processing functionalities within a real-world context. All coding examples, supporting the functionality demonstration, are setup around the shipment of parcels.
Content may be subject to copyright.
Tutorial: Open Source Enterprise Application Integration
Introducing the Event Processing Capabilities of Apache Camel
Christoph Emmersberger
Universität Regensburg
Universitätsstraße 31
93053 Regensburg
Florian Springer
Senacor Technologies AG
Wieseneckstr. 26
90571 Schwaig b. Nürnberg
“Interesting applications rarely live in isolation.” ([1], xxix)
With this sentence G. Hohpe and B. Woolf start the intro-
duction to their book Enterprise Integration Pattern: De-
signing, Building, and Deploying Messaging Solutions.
While the statement is valid now for more than ten years,
Gartner estimates today the cost increase targeting integra-
tion aspects for midsize to large companies at about 33%
within the next three years (cf. [2]). The expected increase
will be mainly driven by the integration of cloud services
and mobile devices. Since event processing addresses clearly
problems arising with the growth of computational distri-
bution, particularly with the increasing number of mobile
devices or cloud services, integration is a topic that needs to
be addressed by event processing functionalities.
One of the frameworks within the integration domain is
Apache Camel. Since it’s initial release in 2007, the frame-
work has gained quite some attention - not only within the
open-source arena. Apache Camel has a strong focus on
enterprise application integration since it implements well
known Enterprise Integration Patterns (EIP’s) (cf. [1]).
This work reveals the event processing capabilities of Apache
Camel alongside a logistics parcel delivery process. The de-
livery process facilitates the scenario descriptions to exem-
plify the event processing functionalities within a real-world
context. All coding examples, supporting the functionality
demonstration, are setup around the shipment of parcels.
General Terms
Software Engineering
Integration Framework, Event Processing
“Enterprise Application Integration is the creation of busi-
ness solutions by combining applications using common mid-
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
DEBS’13, June 29–July 3, 2013, Arlington, Texas, USA.
Copyright 2013 ACM 978-1-4503-1758-0/13/06 ...$15.00.
dleware.” ([3], 2) Middleware specifies a technology stack
which is capable to mediate between applications with the
overall goal of improving the supply-chain relationships in a
distributed application environment. One of the frameworks
supporting the mediation between applications coming from
the open-source domain is the integration framework Apache
Camel. The first version of Camel has been released in ver-
sion 1.0 the 2nd July 2007 - just three and a half month
after the development had started (cf. [4]).
Regardless of the short development period, the first re-
lease covered already two domain specific languages (DSL’s)
based on Java and XML, the core routing functionality, an
initial set of components, examples and a proper project
setup [5]). Since than, Camel has become an Apache top
level project in January 2009. Beside those organizational
changes, the project has faced continuous growth which can
be exemplified by
the growing number of committers (starting at seven
being a group of more than 30 today),
an increasing code base which is today more than ten
times the size of the first release and
the growing number of components from an initial set
of 18 to todays 140 components (including external
components) listed at the Camel website (cf. [6]).
In August 2009, Camel has experienced a major release (cf.
[7]). Since that time, it is available in version two which is
still actively maintained. Having said that Camel is a mid-
dleware technology and “(...) middleware can be regarded
as containing the roots of a hierarchical approach to events
and event processing (...)” ([8], 37), we can also identify a
clear relationship between enterprise application integration
and event processing.
Within this tutorial paper we introduce Apache Camel’s
event processing capabilities. The first section gives a brief
introduction into the context of a parcel delivery process.
The process description does not claim to be generally valid;
it’s aim is furthermore to serve as consistent basis for all use
case descriptions when characterizing the individual event
processing functions and their corresponding Camel imple-
After having a rough overview about the supply-chain in-
teractions, the second section brings event processing and
it’s functionalities into the focus of this work. In this con-
nection we’ll cover the the topic’s: “Event type and event
object”,“event producer, consumer and channel”, the “event
processing network” and “event processing agents, context
and state”.
The subsections event processing network,event producer,
consumer and channel and event type provide an introduc-
tion into the concepts of Apache Camel while creating cross
references to event processing building blocks ([9], 59). The
section on event processing agents, context and state will be
covered in a software pattern like structure (cf. [1], xli and
[10], 7). Since it is unquestionable a topic of it’s own, set-
ting a well defined structure for a pattern, we do not intend
to impose any standardization along that line. Instead the
pattern like descriptions collates the commonalities of both
structures to describe event processing agent functionalities
in a consistent manner.
Name identifies the event processing function. The inten-
tion of the name is also to provide a brief summary of
the described functionality.
Context provides background information on requirements
the event processing function aims to resolve. The con-
text information is grouped around the parcel delivery
process (cf. chapter 2)
Problem summarizes the problem that is being addressed
by the event processing function in general without
any contextual description.
Solution describes how Camel addresses the problem con-
ceptually. The solution is based upon a graphical rep-
resentation and a textual description that explaining
the solution design.
Example demonstrates the implementation of the solution
design with the Apache Camel framework. The de-
scription contains listings and descriptive elements that
explain the implementation approach.
Finally this paper concludes in chapter 4 with a summary
of Camel’s event processing capabilities and discusses pos-
sible extensions supporting today’s event processing needs.
A common parcel logistics delivery process (cf. [11], 171),
starting with a customer order and ending with reconcili-
ation and invoicing activities, serves as industrial context
on which we will discover different event processing func-
tionalities and their corresponding implementation within
Camel. The generalized process consists of Order Manage-
ment,Delivery Disposition,Delivery Execution and Order
Reconciliation (see figure 1).
Figure 1: Parcel Delivery Process
Order Management enables the placement of transporta-
tion orders across multiple distribution channels. The
distribution channel is e.g. an internet portal, an appli-
cation installed at the customer location, a call center
or even a mobile application. An electronic order trig-
gers the physical pickup of an item before the delivery
execution can start.
Delivery Disposition is the scheduling component within
the parcel delivery process. Amongst others, it defines
the size of the delivery area and schedules transporta-
tion routes. For distributing the scheduling informa-
tion, the disposition step needs to integrate with the
delivery execution, i.e. sorting sites, navigation sys-
tems and scan facilities.
Delivery Execution realizes the actual transport process
encompassing Pickup,Sortation,Transportation and
Delivery. At all stages, multiple devices with different
hard and software configurations provide status infor-
mation about an individual order, e.g. mobile scan de-
vices during Pickup and Delivery, fixed installed scan
systems during the Sortation process and position-
ing information while the Transportation is being con-
Order Reconciliation covers the invoicing and customer
care activities. In case of any failures within the de-
livery process, customers may receive a refund and
an insurance claim needs to be opened. Otherwise a
monthly bill is created and the incoming payments will
be monitored against payment transactions.
Middleware is, beside other technologies, one of the estab-
lished technology stacks which has clearly adopted the event
processing paradigm ([8], 27-29 and 36-38). This section dis-
covers Camel’s implementation of the main event processing
concepts ([9], 40-47) starting with event types and objects,
highlighting the event producer, consumer and channel con-
cept, integrating the components into an event processing
network and finally discussing the interaction of event pro-
cessing agents, context and state.
Event types and event objects Events are a represen-
tation for something which has happened. As a com-
putational element for the technical representation, an
event object is a concrete instance of an event type. All
event objects, which belong to an event type, carry the
same semantics within their object structure. Event
types, objects and their implementation within Camel
are covered in section 3.1.
Event producer, consumer and channel Producer and
consumer are both event processing elements that com-
municate with each other. While an event producer
obtains the role for generating events, the event con-
sumer receives the results. An event channel fulfills the
mediation role between producer and consumer. It’s
main task is to route events from the producer to the
appropriate consumer. All three elements and their
technical interaction are described in section 3.2.
Event processing networks An event processing network
combines all processing elements, notably event pro-
ducer and consumer,event channel,event processing
agent including context and state elements into an ex-
ecutable application unit. This does not necessarily
imply that all elements need to be executed within a
single execution node. In section 3.3 you’ll find an
in depth explanation on how the combination can be
achieved within Camel.
Event processing agents, context and state An agent
is a software component with the purpose of process-
ing events. The main functionalities of an agent can be
summarized as filtering,matching and derivation with
support of context and state information. While filter-
ing,matching and derivation are core functions within
event processing, the processing of context and state is
required for event reasoning which means the detection
of any conditions that lead to the event generation (cf.
section 3.4)
3.1 Event Types and Event Objects
An event is a representation for something which has hap-
pened in reality (cf. [12], 151 and [8], 255-256 and [9], 4).
Considering the parcel delivery process of figure 1, the cen-
tral event which triggers all subsequent activities is a cus-
tomer order for the transportation service, also known as
Shipment. While the actual instance of an event is called
event object, the structural definition is captured within an
event type.
Listing 1 and 2 disclose the relationship between event type
and event object. The event type in listing 1 defines, that
a shipment order consists of ShipmentDetails,Sender and
Receiver.ShipmentDetails describes the nature of the Ship-
ment, particularly the size and weight of the item; Sender
and Receiver specify the geographical nodes and the distance
that needs to be covered by the Shipment.
Listing 1: Event Type - Shipment Order
1<?xm l v e r s i o n=” 1 . 0 ?>
2<xsd : sc he ma v e r s i o n=” 1 . 0 . . . >
3<xs d : el e me n t name=”Shipment
4type=” t ns : S hip men tT ype ”/>
5<xs d : com plexT ype name=”ShipmentType”>
6<xs d : se q u en c e >
7<xs d : el e me n t name=”ShipmentDetails
8type=” tn s : S hi pm en tDe tai lsT ype ”/>
9<xs d : el e me n t name=Sen der ”
10 type=” t ns : S end er Typ e ”/>
11 <xs d : el e me n t name=” R e c e i v e r
12 type=” tn s : R ec ei ve rT yp e ”/>
13 </x sd : s e que n c e >
14 </x sd : com plexT ype>
15 . . .
16</ xsd : schem a>
In contrast to the event type, which describes the seman-
tical structure of an event, the event object captures what
is actual happening or has happened - in our example the
concrete request of an order. The event object is therefore
an instance of an event type which contains actual values
within the structure of the event type. Listing 2 shows an in-
stance of the Shipment with concrete values. While Weight,
Length,Width and Height define the physical consistency
of the Shipment, the ParcelType provides a classification in-
formation, in our case “Small Parcel”. This classification
information is not necessarily required, since it could be de-
rived by some context information, e.g. when conducting a
lookup against a context store. For the purpose of simplicity
we decided to retain the attribute and discuss the topic of
context in section 3.4.
Adding one more comment to the given XML listing: It
is of course not an imperative need to specify an event body
as XML structure. Camel supports any Java object type in
its message body since the body is of type “java.lang.object”
(cf. [13], 14). It is therefore possible to process any event
that can be serialized into a Java object.
Listing 2: Event Object - Shipment Order
1<?xm l v e r s i o n=” 1 . 0 en c o d in g=”UTF8 ?>
2<tn s : S hipm ent . . . >
3<tns : ShipmentDetails>
4<tn s : P arce lTyp e>
5S ma l l P ar c e l
6</t ns : P a r c e l T y pe>
7<t n s : We ig ht >1.87</ t n s : We igh t>
8<t n s : Len g th >55</t n s : Leng th>
9<t ns : Wi dth>25</t ns : Wi dth>
10 <tn s : H eigh t >12.5</ t ns : H ei g ht >
11 </tns : ShipmentDetails>
12 <tn s : S en d e r . . . />
13 <t n s : R e c e i v e r . . . />
14</ tn s : Shipm ent>
Having introduced the abstract relationship between event
type and event object, we need to investigate the logical
structure of an event and it’s attributes. Since the XML-
based example above represents only the payload, which is
usually wrapped in the event body within the context of
event processing, we need to discover what other attributes
are required to create an event. In addition we need to find
out, if these elements find an implementation representation
within the Camel framework.
According to ([9], 62-64), the abstract, logical structure
of an event is split into three sections: An event header, a
payload and an open content section. The following enu-
meration describes each element and it’s role within event
Header: Covers system defined event attributes e.g. a type
identifier, a property that flags if it is an event com-
position, the temporal granularity and additional event
indicators such as the occurrence and detection time,
event source,identity and certainty. Header attributes
support an efficient processing of the events since they
reduce the need to lookup frequently used information.
Payload: Contains data attributes that are specified by the
event type. The payload data is the actual, computa-
tional representation of what has happened (cf. listing
1 and 2).
Open content: Defines additional data that may be in-
cluded in the even instance. This encompasses any bi-
nary attachment such as any document, audio or video
file. However, it is also possible to attach structure or
un structured text.
The logical event structure has its representation within
Camel as message object, consisting of headers, a body and
an attachment (cf. [13], 13). When taking a look at the
headers object, we can identify a unique messageId. In spite
of the messageId there exist no other predefined message
headers and it is necessary to extend the research also to
the surroundings of the message object to find additional in-
formation like the ones defined by the event indicators, e.g
the event source.
In figure 2 we find an abstract illustration that explains how
the message object is embedded within the broader context
of an exchange object. An exchange may contain two mes-
sage objects, an in and an out object. The reason for that
implementation can be found within the concept of message
exchange pattern (MEP).Camel knows basically two styles
of exchanging messages: InOnly and InOut ([13], 14-15) .
While some interaction scenarios manage the processing of
a “fire and forget” style (i.e. InOnly pattern), others require
still the information about the original request message (i.e.
InOut pattern). To implement this behavior, the exchange
contains the information about the pattern style and the op-
tion to store two messages.
In addition of the processing behavior, the exchange has
also an attribute indicating the endpoint where the message
camel from respectively the event source (cf. section 3.2).
Beyond that, the concept involves also the knowledge about
it’s creation time (i.e. properties.CamelCreatedTimestamp),
the execution context (i.e. fromRouteId) as well as the infor-
mation if any processing failure. The advantage of carrying
exception information outside of the actual message is, that
the the exception handling needs only to look at this infor-
mation rather than parsing the entire message body.
If it is required to add any additional event indicators, this
can be handled by setting custom properties within the mes-
sage header or the exchange properties.
0..1 0..1
-out -in
Figure 2: Camel Exchange and Message Model
Reviewing the overall Camel implementation it is fair say,
that the message and exchange concept provides everything
which required by an event type and object perspective to
fulfill the needs required for event processing.
The next section introduces now the concepts of event
producer,consumer,event channel and tries to discover their
implementation within the Camel framework.
3.2 Event Producer, Consumer and Channel
Event producer and consumer are entities that interact
with each other in an event processing network (cf. sec-
tion 3.3) by sending and receiving events (cf. [9], 42). Taking
an example from the parcel delivery process (cf. figure 1), a
customer may submit a shipment order in a customer por-
tal. The order is being sent to the order system which keeps
track about the fulfillment degree of all customer orders (cf.
figure 3). Before the order system is in capable to confirm
that the order can be processed, it requires additional in-
formation about the feasibility from the scheduling system
since the order system does not know anything about capac-
ities and their utilization. The scheduling system responds
upon the scheduling request and enables the order system
to send out an order confirmation to the customer’s inbox
in the portal application.
<< sendOrder() >> << requestScheduling() >>
<< replySchedule() >><< confirmOrder() >>
1 2
Figure 3: Order Submission
Under the condition of each participant acting either as
producer or consumer, the example (cf. figure 3) demon-
strates that each participant can obtain multiple roles de-
pending upon the communication direction. At first, when
sending the order request, the customer portal holds the
event producer role before it turns into an event consumer
when finally receiving the order confirmation. Since the role
change does not affect any internal semantics or structure
of data within the customer portal, it is possible to combine
both roles into a single element, called participant (cf. [9],
33 and [14], 298). The Camel implementation of a partici-
pant element is realized via the so called Component ob ject
(cf. [13], 188-236).
“Components are the primary extension point in Camel”
([13], 189) and implement basically an endpoint factory.
Since any endpoint is capable to send and receive events,
acomponent exposing an endpoint is suitable to realize an
event producer as well as a consumer. What might become
a surprise is, that the generic Component concept is also
capable to realize the concept of an event channel. First of
all, an event channel is capable to receive events, similar to
the behavior of an event consumer. Secondly, it acts like an
event producer when sending events to one or more destina-
tions. Finally, an event channel may also modify an input
event or make routing decisions (cf. [9], 189).
Since a Camel Component provides basically a configurable
endpoint to which someone can send events or may retrieve
events, it is possible to cover the first and second state-
ment. In addition the endpoint configuration may also con-
tain information on how to modify (e.g. change header in-
formation) or apply routing decisions. Figure 4 provides an
overview about the object dependencies in Camel between,
producer,consumer,component and endpoint.
Component is a factory for endpoint objects. Components
can be added to an EPN via configuration and inclu-
sion to the Camel Context (cf. section 3.3).
Endpoint realizes an addressable element that can send
and receive event objects. The endpoint address is
specified as Unified Resource Identifier (URI) (cf. [15]).
Producer provides a channel on which clients can send
event objects in an endpoint. The endpoint needs to
be individually configured.
Consumer consumes events from an endpoint. Consuming
events requires an individual configuration, including
the appropriate endpoint addressing.
Producer Consumer
0..1 0..1
- component
- endpoint- endpoint
Figure 4: Abstract Comp onent Model
Having gained a first insight into the component concept
and its adoption to realize event producer,consumer and
channel we’d like to give you an example that should pro-
vide some clarification. As example, we have selected two
implementations within Camel that act like event channels,
since a channel realizes both communication directions.
The first component is called SEDA-component and realizes
the concept of a staged event-driven architecture endpoint
(cf. [16]). This endpoint implements in our example (cf.
listing 3) an endpoint that can receive events. Nevertheless,
a SEDA endpoint may be also used to send events; it can
therefore act in both consumer and producer role. In ad-
dition, the component has also the capability to configure
basic routing rules such as the enablement of multiple con-
sumers, similar to a topic based communication, as well as
some blocking and sizing parameters.
The second component we have decided to use as an event
channel is the JMS-component, since the Java Message Sys-
tem (JMS) ([17]). is a well known implementation of the
event channel concept.
Listing 3 shows the mediation between two systems. The
first system, in our case the order system, is capable to call
a SEDA queue directly while the second system, responsi-
ble for scheduling and routing, can only understand JMS
messages (cf. figure 3). The communication direction, re-
spectively the indication of which component acts as event
producer or consumer, is described by the Camel DSL, a
processing language with simple routing expressions. In our
example it is a simple “from().to()” clause based upon the
fluent builder concept (cf. [13], 30, 132).
Listing 3: Endpoint URI Examples
1fr om ( ” s e da : / / s hi p me n tO r de r ” +
2”? m ul ti p le Co ns um e rs= f a l s e ” ) ( ”j ms : t o p i c : s c h e d u l e ? t r a n s a c t e d=t r u e ) ;
As already stated, a component can be addressed via an
URI scheme. In contrast to the URI specification (cf. [15],
16-25), Camel implements a simplified URI structure (cf.
[13], 19, 25) to configure and address an endpoint individu-
ally (cf. listing 3). A Camel endpoint URI is based upon a
scheme, a context path and options.
Scheme: The scheme references the component that needs
to be instantiated. The component identifier needs to
be uniquely.
Context path: Identifies the resources within the process-
ing context unique. This is required to address the
individual component instance when calling an end-
Options: Options configure the endpoint behavior. The
set of options is different for each component since
the behavior depends upon the underlying component
provider (e.g. the scheduling system)
Having seen now, how Camel realizes event types and
event objects (3.1), and knowing how event producer,con-
sumer and channel (3.2) are implemented and interact within
the framework, it is time to discover the complete interac-
tion of all elements within the event processing network.
3.3 Event Processing Networks
“An event processing network (EPN) is a collection of
event processing agents, producers, consumers, and global
state elements (...)” (cf. [9], 43). As we have seen in 3.2,
most of the elements can be express via components. To
combine these components, Camel provides two essential el-
ements called context and route.
Context: The Camel Context is a container at runtime
level, providing Camel’s core services, particularly the
elements Registry,Type converter,Components,End-
points,Routes,Data formats and Languages (cf. [13],
Route: ACamel Route realizes a concrete implementation
of a message flow that can be executed on Camel’s
routing engine. It is possible to define multiple routes
within a context, where each contains a unique identi-
fier (cf. [13], 17).
To get an impression on how a Camel Context and Camel
Routes are structured, we have created a simple listing 4
that provides some clarification. The listing is based upon
the Spring DSL (cf. [13], 18) and is embedded in a Spring
application context (cf. [18], 27). A context element, named
“camelContext” contains a single route with a unique iden-
tifier “camelRoute”; in addition to that single route it would
be possible to add more routes within that context where
all can access the same set of core services provided by the
context. Two core services that must to be registered in our
example are the SEDA and JMS component, since they are
directly referenced from the route and will be instantiated.
Another one is of course the registry that administers all
context paths for all endpoints to enable a proper endpint
resolution when processing the messages.
Listing 4: Context and Route - Application Context
1<?xm l v e r s i o n=” 1 . 0 en c o d in g=”UTF8 ?>
2<beans xmln s : camel=
3” ht t p : / / c am e l . a p ac h e . o r g / sc he ma / s p r i n g
4x s i : s ch e ma L oc a ti on =
5” ht t p : / / c am e l . a p ac h e . o r g / sc he ma / s p r i n g
6h tt p : / / c a me l . ap a ch e . or g / s ch ema / s p r i n g /
ca m els p r i n g . x s d ” . . . >
7<ca m el : c a me l C on t e xt i d=”camelContext >
8<ca m e l : ro u t e i d =”c am el Rou te ”>
9<ca m el : fr om u r i =”s e d a : / / s hi p me n tO r de r />
10 <ca m el : t o u r i=
11 ”j ms : t o p i c : s c h e d u l e ? tr a n s a c t e d =t r u e />
12</c a mel : r o u te >
13 . . .
14 </c a mel : camelC ontex t>
15</ bean s >
As we have seen in the example of listing 4, Camel Context
and Camel Routes enable the collection of components (e.g.
event producer,consumer and channel). We might want to
anticipate the result of section 3.4 to conclude that it is also
possible to collect agents,context and state elements within
the concept.
The following section explains the concept of agents,con-
text and state in detail and points out concrete implemen-
tation strategies for each agent functionality.
3.4 Agents, Context and State
An event processing agent is a piece of software that im-
plements the processing logic between an event producer and
aconsumer (cf. [9], 42, 51). Each agent provides a specific
set of event processing functionality that can be assembled
within an event processing network. The main tasks of an
agent are therefore the mediation between producer and con-
sumer, particularly the grouping of events according to their
processing context. This can be achieved e.g. by filter,split,
translate,aggregate and enrich functionalities.
In addition to these functions, agents are also responsible
to process context and state information which enables also
the correct routing from the event producing to the event
consuming component (cf. [9], 51, 145). The context of an
event may have multiple dimensions, e.g. temporal-,spatial-
, or state-oriented, where each context dimension can occur
in combination with each other one. Identifying the right
context for an event can only be conducted, if there is a
global state element available acting as reference data.
Agent functionality can be reused in different application
scenarios. To support the reuse, we have proposed a simpli-
fied pattern schema (cf. section 1) containing name,context,
problem,solution and example descriptions.
Even if our intention is not to set a standard, the proposed
structure may contribute to the ongoing discussion about
standardization within the event processing community (cf.
[19]). One of the positive effects a pattern based approach
might have is that“[c]learly-defined and commonly-accepted
levels of abstraction enable the development of standardized
tasks and interfaces.” ([20], 48).
The subsequent paragraphs focus on the agent functional-
ity description for filtering,splitting,translation,aggregation
and enrichment based on the logistics parcel delivery pro-
cess (cf. figure 1). Even if the industrial background is taken
from logistics, we have kept the examples general to enable
the adoption towards other industry domains.
3.4.1 Filter Agent Pattern
“A [f]ilter agent (...) performs filtering only and has no
matching or derivation steps (...)” ([9], 317). To eliminate
uninteresting events it utilizes a filter expression. The agent
processes events in a stateless manner (cf. [9], 51)
Name: Filter Agent
Context: The logistics of parcel delivery is characterized
by automated sorting processes. Sorting machines pickup
the labeling information required for routing parcels phys-
ically to their corresponding gates . While the parcels are
being processed on conveyor belts, the capturing of the la-
bel information is being conducted based on barcode scans
or image recognition. It extracts a huge amount of address
data that needs to be distributed to the subsequent delivery
Problem: Since subsequent processing nodes are only
interested in events for their delivery area, it is required to
select the particular parcel information and distribute it to
the corresponding node. However each node needs the flex-
ibility to change the size of the delivery area, since it must
be capable to take over the operation of a nearby delivery
area, in case of e.g. low volumes or operational issues in a
processing node.
Solution: Providing the flexibility to dynamically change
the area, all address events will be published on a single
topic. Each node within the delivery network is responsible
to create a filter expression matching the predefined delivery
area. This way it can be assured that each node receives only
events for it’s field of activity.
Figure 5: Filter Agent
Example: In the example we are sending address events
captured by the sorting machine that contain name,street,
city and zipCode information. For the purpose of simplicity,
we assume that a zipCode identifies a section of a deliv-
ery area and can not be split into the responsibility of two
processing nodes. An active delivery node can serve one to
many zipCode areas at once while an inactive node main-
tains zero. As an additional restriction we have defined that
a processing node can only serve a coherent, ascending se-
quence of zipCodes. All these restrictions have certainly not
a direct, representation in the real parcel delivery process.
However they help us to realize a simple filter expression as
you can see in the in listing 5 by a predicate.
The predicate evaluates all incoming events for a minZip-
Code and a maxZipCode and routes all events within that
range to the responsible processing node. Camel executes
the filtering request within the route by calling the filter()
expression with a predicate parameter.
Listing 5: Filter Agent
1p u b l i c c l a s s FilterRoute extends
2SpringRouteBuilder {
3@O v e r r i d e
4p u b l i c v oi d c o n f i g u r e ( ) throws Exception {
5P r e d i c a t e d e l i v e r y A r e a =
6or (
7bo dy ( ) . is G r ea t e rT h a n ( m in Zip Co de ) ,
8bo dy ( ) . is L e ss T h an ( ma xZi pCod e ) ) ;
9fr om ( ” d i r e c t : // s t a r t bodyf i l t e r )
10 . f i l t e r ( d e l i v e r y A r e a )
11 . t o ( ”l o g : / / a f t e r bod yf i l t e r ? l e v el=INFO” )
12 . e nd ( ) ;
13 }
14 }
3.4.2 Split Agent Pattern
A split agent“(...) takes a single incoming event and emits
a stream of multiple event objects ()”([9], 52). It can be used
to partition an incoming event and distribute the individual
parts to different consumers (cf. [9], 126).
Name: Split Agent
Context: Several customers are having distributed pro-
duction facilities while maintaining a single administration
office that sends out the collected order requests for the en-
tire customer organization. The centralized, batch oriented
order processing provides the customer the opportunity to
centralize the purchase and accounting department at a sin-
gle location rather than having multiple employees sitting in
each production facility.
Problem: Distributing the bulk of orders is difficult,
since the pickup of parcels at the customer’s production fa-
cilities needs to be executed by different logistics processing
nodes. Assigning the individual responsibility for the pro-
cessing nodes is not possible based on the entire set of order
SplitterMessage Messages
Figure 6: Split Agent
Solution: To enable the responsibility assignment across
the logistics network it is required to partition the order
collection into single orders where each order contains only
the address information of the parcel’s sender and recipient.
This can be achieved by conducting a split operation on the
incoming collection.
Example: The solution can be achieved by splitting the
incoming order collection into it’s individual parts. Camel
provides the split() expression for conducting those opera-
tions. One of the requirements to implement the split ex-
pression successfully is to have either a Collection, an Array
or a NodeList (cf. [21], 23-24).
Listing 6: Split Agent
1p u bl i c c l a s s SplitRoute
2extends SpringRouteBuilder {
3@O v e r r i d e
4p u b l i c v oi d c o n f i g u r e ( ) {
5fr om ( ” d i r e c t : // s t a r t s p l i t )
6. s p l i t ( bod y () )
7. t o ( ”l o g : / / s p l i t r o ut e ? l e v e l=INFO” ) ;
3.4.3 Translate Agent Pattern
A translate agent is stateless and“(...) takes a single event
as its input, and generates a single derived event which is
a function of the input event, using a derivation formula”
([9], 125). Its usage ranges from simple type conversions to
complex event transformations modifying event attributes.
Name: Translate Agent
Context: The marketing and sales department has fig-
ured a way, to extract product data as XML documents from
their master spreadsheet where they maintain all product in-
formation. They have also found a documentation section
from the customer portal provider stateing that there is a
Java interface where product data can be updated.
Problem: Unfortunately the Java interface can not seri-
alize XML documents directly and it provides only a remote
method invocation interface. The interface is therefore only
capable to directly process Java objects. What makes the
situation even more complicated is, that some of the ex-
tracted attributes do not match to the data structure spec-
ified within the interface documentation.
Solution: The only way to support the marketing and
sales department in their goal to update the companies por-
tal automatically based on the extracted XML data is to
translate the XML product data into the format required
by the portal software. It is therefore required to translate,
the XML InputStream into an object of Product.class.
Figure 7: Translate Agent
Example: The XML document that can be extracted
from the spreadsheet has a product container with the at-
tributes name,size,weight and a price (cf. listing 7). Since
the specified Product.class object has only a description el-
ement and no size and weight attributes, it is required to
translate these attributes into a single element.
Listing 7: Extracted XML-based Product
1<?xm l v e r s i o n=” 1 . 0 en c o d in g=”UTF8 ?>
2<Pr o d u ct>
3<Name>P ar ce l </Name>
4<S iz e >max. 6 0 x3 0x 15 cm</ S i z e >
5<Weight>up t o 2 kg</Weight>
6<Pr i c e >4.90</ P ri c e >
7</Produ c t>
The proposed implementation for that translation is a
TypeConverter (cf. [13], 88-91). Since the default set of
TypeConverter does not cover the specific translation be-
tween the XML-based product document and the Java-based
Product.class, it is necessary to extend the existing set by a
custom converter (cf. listing 8).
Listing 8: Translate Agent - Type Converter
2p u b l i c c l a s s T r a n s l a t e C o n v e r t e r {
4p u b l i c Product convertInputStreamToProduct(
5InputStream i np ut St ream ) {
6final XPath xPa th = XP athF act ory .
7n ew I n st a n ce ( ) . newXP ath ( ) ;
8final Docume nt doc um ent =
9cr eat eXM LDo cum ent ( in p u tS t re a m ) ;
10 return c r e a t e P r o d u c t ( do cu me nt ) ;
11 }
12 private Product
13 c r e a t e P r o d u c t ( Doc umen t doc um en t ) {/. . . /
14 return pro d u c t ;
15 }
16 private Doc umen t c rea teX MLD ocu men t (
17InputStream i np ut St ream ) {/.. . /
18 r e t u r n n u l l ;
19 }
20 }
To trigger the translation, it is necessary to add a convert-
BodyTo(Product.class) expression to your route. At execu-
tion time, the route identifies the object type that reaches
at the conversion point and searches for a matching type
converter in the Camel Context registry.
When the type conversion succeeds, the translate agent sends
out the Product.class object by executing a remote method
invocation (cf. listing 9)
Listing 9: Translate Agent - Route
1p u bl i c c l a s s TranslateRoute
2extends SpringRouteBuilder {
3@O v e r r i d e
4p u b l i c v oi d c o n f i g u r e ( ) {
5fr om ( ” d i r e c t : // s t a r t translate)
6. c on ve rtB od yT o ( Pr od uc t . class )
7. t o ( ”r mi : / / p o r t a l : 1 0 9 9 / p r o du c t s ” ) ;
3.4.4 Aggregate Agent Pattern
An aggregate agent “(...) takes as input a collection of
events and creates a single derived event (...)” ([9], 126).
Even if this definition describes the input as collection of
events it is not within the meaning of a Javacollection type
where a collection represents a container object that em-
braces multiple objects. We want to emphasize that the
aggregate agent operates on multiple input events and gen-
erates a single output event.
When aggregating events, it is sometimes required to exe-
cute an aggregation function such as calculating e.g. a sum,
an average or the maximum and minimum of a certain event
Name: Aggregate Agent
Context: Since the competition within the parcel de-
livery market has increased and the prices became more
volatile, the marketing and sales department wants to gain
an insight into the average price for products and services
offered by their competitors.
Problem: Calculating the average market price requires
the aggregation of all competitors prices. As soon as one of
the competitors changes the price, it is necessary to recal-
culate the average value.
Solution: To enable the reaction upon any price change,
the proposed solution is to aggregate a new average price as
soon as one of the competitors updates it’s price table. The
aggregation will be implemented via an aggregation strategy
hiding the complexity of calculating the average value.
MessageMessages Aggregator
Figure 8: Aggregate Agent
Example: Listing 10 shows the implementation of a Camel
aggregation strategy. The strategy has as a public aggre-
gate() function which takes an old and a new exchange ob-
ject as parameter values. While the old exchange contains
all events that have been collected until the completion cri-
teria is met, the new exchange involves the latest event ob-
ject. Based on these event objects, it is possible to calculate
an average product price and return the calculated value as
exchange object.
Listing 10: Aggregate Agent - Aggregation Strategy
1p u b l i c c l a s s A g g re g a t o r
2implements A g g r e g a t i o n S t r a t e g y {
3p r i v a t e f i n a l s t a t i c L i s t <Pr o duct >PRODUCTS =
4new ArrayList<P rodu ct >() ;
5p u b l i c E xc h an ge a g g r e g a t e (
6Ex cha n ge oldExch a n g e ,
7Ex ch an ge ne wEx cha ng e ) {
8final Pr o d u c t ol d P r od u c t =
9ge tP rod uc tF rom Ex cha ng e ( ol dE xc hange ) ;
10 final Pr o d u c t newPr o duc t =
11 ge tP ro du ct Fr om Ex ch an ge ( ne wEx ch ang e ) ;
12 i f (null != newAggregateProduct ) {
13 i f ( ! PRODUCTS . c o n t a i n s (
14 newAggregateProduct ) ) {
15 PRODUCTS. ad d( n ew Ag gr egateProdu ct ) ;
16 }
17 }
18 ne wE xc han ge . g e t I n ( ) . s e tB o dy (
19 c al c A v gP r o d uc t P r ic e ( ) ) ;
20 return newExchange ;
21 }
22 private Pro du ct ge tPro du ctFr om Ex cha ng e (
23 Ex cha nge ex ch an ge ) {/. . . /
24 return pro d u c t ;
25 }
26 p r i v a t e d ou b le c a l cA v g Pr o d u ct P r i ce ( ) {
27 /. . . /
28 return ProductPrice ;
29 }
30 }
Beside the actual calculation logic and the call of the ag-
gregation strategy (aggregate()), the definition of the com-
pletion criteria is the most important element that needs
to be defined. The criteria defines either the size (com-
pletionSize()) or the time frame (completionInterval() and
completionTimeout()) that triggers the execution of the ag-
gregation strategy. To assure that the average price is being
calculated for every new product event, we have decided set
the completionSize to one (cf. listing 11).
Listing 11: Aggregate - Agent Route
1p u b l i c c l a s s AggregateRoute
2extends SpringRouteBuilder {
3@Ov e r r i d e
4p u b l i c v oi d c o n f i g u r e ( ) {
5final A gg r e g a to r a g g r e g a t o r =
6new A g gr e g at o r ( ) ;
7fr om ( ” d i r e c t : // s t a r t aggregate)
8. a g g r e g a t e ( bo dy ( ) , a g g r e g a t or )
9. c o m p l e t i o n S i z e ( 1 )
10 . t o ( ”l o g : / / a g g r eg a t e r o ut e ? l e v e l =INFO” ) ;
11 }
12 }
3.4.5 Enrich Agent Pattern
An enrich agent“(...) takes a single input event, uses it to
query data from a global state element, and creates a derived
event which includes the attributes from the original event,
possibly with modified values, and can include additional
attributes.” ([9], 126).
Name: Enrich Agent
Context: A customer places an order by providing with
the physical characteristics and the distance information de-
rived by the points of transfer (e.g. sender and receiver). In
contrast to the described order event of section 3.1, he does
not offer any product classification that can be consulted for
Problem: To create an accurate bill, it is required to
classify the order into the appropriate product category, e.g
small parcel,parcel or oversized parcel, each having an indi-
vidual price tag.
Solution: To conduct the mapping of the provided in-
formation, it is required to lookup the event context in the
global state element. This can be achieved by implementing
the enrichment pattern that implies in the concrete instance
the querying of the product database based on the assigned
order event to return the corresponding product category.
Figure 9: Enrich Agent
Example: The implementation is realized by adopting
the aggregation strategy since an aggregation strategy is ca-
pable calculating a new output event based on two input
exchanges (cf. listing 12).
Listing 12: Enrich Agent - Aggregation Strategy
1p u bl i c c l a s s E n r i c h e r implements
2A g g r e g a t i o n S t r a t e g y {
3p u b l i c E xc ha n ge a g g r e g a t e (
4Ex cha n ge o ldExch a n g e ,
5Ex ch an ge ne wEx cha ng e ) {
6f i n a l C on te x t o r i g i n a l C o n t e x t =
7ol d E xc h an g e . g e t I n ( ) . g et Bo dy (
8Co ntext . class ) ;
9f i n a l L i s t <C o ntex t >c o n t e x t =
10 ne wE xc han ge . g e t I n ( ) . g et B od y ( L i s t . class ) ;
11 /. . . /
12 ol d E xc h an g e . g e t I n ( ) .
13 se t Bo d y ( o r i g i n a l C o n t e x t ) ;
14 return ol dExchange ;
15 }
16 }
What makes the difference compared to a regular aggrega-
tion agent is, that one of the exchanges processed within the
aggregation strategy is being retrieved by a sub-route that
queries the global state. The query is conducted based on a
copy of the original incoming event. Listing 13 demonstrates
this behavior where the main route calls the sub route when
executing the enrich() expression.
Listing 13: Enrich Agent - Route
1p u b l i c c l a s s EnrichRoute
2extends SpringRouteBuilder {
3@Ov e r r i d e
4p u b l i c v oi d c o n f i g u r e ( ) {
5c on f i gu r eM a i nR o u te ( ) ;
6c o n f i g u r e E n r i c h R o u t e ( ) ;
8p r i v a t e v oi d c on f i gu r e Ma i nR o u te ( ) {
9fr om ( ” d i r e c t : // s t a r t e n r i c h )
10 . e n r i c h ( ” d i r e c t : // s t a r t en ri chm en t ” ,
11 new E n r i c h e r ( ) )
12 . t o ( ”l o g : / / e n r i c h r ou t e ? l e v e l =INFO” ) ;
13 }
14 p r i v a t e v oi d c o n f i g u r e E n r i c h R o u t e ( ) {
15 fr om ( ” d i r e c t : // s t a r t en ric hm en t ”)
16 . p r o c e s s (
17 new Processor () {
18 p u b l i c v oi d p r o c e s s (
19 Ex cha nge ex ch an ge ) {/. . . /
20 e xc h a ng e . g e t I n ( ) . se t Bo d y ( c o n t e x t ) ;
21 }
22 }
23 )
24 . t o ( ”l o g : / / e nr i c hm e nt r o ut e ? l e v e l =INFO” ) ;
25 }
26 }
Within this work we have demonstrated, that Camel as an
integration framework clearly realizes event processing con-
cepts. It provides all the basic requirements needed for event
types and objects while maintaining an extension mechanism
to add additional, upcoming features targeting their struc-
tural semantics (cf. section 3.1).
What might be a surprise is, that Camel’s generic compo-
nent concept can serve as an abstraction for event producer,
consumer and channel (cf. section 3.2). Nevertheless, it has
been proven that the concept is sound since its adoption can
be exemplified with the number of 140 realizing components,
all acting either as event producer,consumer or implement-
ing a channel. The introduction to the interaction of event
processing networks by realizing Camel context and Camel
route completes the frameworks support for the event pro-
cessing building blocks.
Finally the paper contributes towards the ongoing standard-
ization effort by introducing the agent functionalities for
filtering, splitting, translation, aggregation and enrichment
(cf. section 3.4).
Since we have seen, that Camel provides such a variety of
functions and knowing that it is a lightweight framework, it
might be a good candidate to be used for assembling services
within a data cloud. An indication supporting this observa-
tion is, that Camel provides already many components that
support the integration of modern technologies and services.
[1] G. Hohpe and B. Woolf. Enterprise Integration
Patterns: Designing, Building, and Deploying
Messaging Solutions. Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, USA, 2003.
[2] D. Chandrasekhar. Gartner predictions 2013 for
application integration: My take. Technical report,
Reality Check, 2013.
[3] W. A. Ruh, F. X. Maginnis, and W. J. Brown.
Enterprise Application Integration: A Wiley Tech
Brief. John Wiley & Sons, 2002.
[4] J. Strachan. Initial checkin of camel routing library, 03
[5] C. Ibsen. Apache camel was awesome from v1.0
onward. Technical report, DZone, 2013.
[6] The Apache Software Foundation. Apache camel.
Technical report, Apache Software Foundation, 2013.
[7] The Apache Software Foundation. Happy 5 years
birthday apache camel. Technical report, Apache
Software Foundation, 2013.
[8] D. C. Luckham. Event Processing for Business:
Organizing the Real-Time Enterprise. John Wiley &
Sons, 2011.
[9] O. Etzion and P. Niblett. Event Processing in Action.
Manning Publications Co., 2011.
[10] R. v. Ammon, C. Silberbauer, and C. Wolff. Domain
specific reference models for event patterns - for faster
developing of business activity monitoring
applications. In VIPSI 2007, October 2007.
[11] C. Emmersberger, F. Springer, and C. Wolff. Location
based logistics services and event driven business
process management. In D. Tavangarian, T. Kirste,
D. Timmermann, U. Lucke, and D. Versick, editors,
Intelligent Interactive Assistance and Mobile
Multimedia Computing, number 53 in
Communications in Computer and Information
Science, pages 167–177. Springer, 2009.
[12] D. C. Luckham. The Power of Events: An
Introduction to Complex Event Processing in
Distributed Enterprise Systems. Addison-Wesley,
November 2001.
[13] C. Ibsen and J. Anstey. Camel in Action. Manning
Publications Co., 2011.
[14] N. M. Josuttis. SOA in Practice - The Art of
Distributed System Design. O’Reilly Media, Inc., first
edition edition, 2007.
[15] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform
resource identifier (uri): Generic syntax. Request for
Comments 3986, The Internet Engineering Task Force
(IETF), Network Working Group,, January 2005.
[16] M. Welsh. Seda: An architecture for highly concurrent
server applications. Project report, Harvard
University, mdw/proj/seda/, May
[17] M Hapner, R. Burridge, R. Sharma, J. Fialli, and
Stout K. Java message service - the jms api is an api
for accessing enterprise messaging systems for java
programms. Specification Version 1.1, Sun
microsystems, April 2002.
[18] Spring. Spring java application framework. Reference
Documentation 3.0, Spring Source,
[19] R. v. Ammon, C. Emmersberger, T. Ertlmaier,
O. Etzion, T. Paulus, and F. Springer. Existing and
future standards for event-driven business process
management. In Proceedings of the Third ACM
International Conference on Distributed Event-Based
Systems, DEBS 2009. ACM, July 2009.
[20] F. Buschmann. Pattern oriented software architecture:
a system of patters. John Wiley & Sons, 1st edition,
July 1996.
[21] P. Kolb. Realization of eai patterns with apache camel.
Studienarbeit 2127, Institut f¨
ur Architektur von
Anwendungssystemen, Universit¨
at Stuttgart, 04 2008.

Supplementary resource (1)

November 2013
Christoph Emmersberger · Florian Springer
... However, Enterprise Application Integration (EAI), which can be described as middleware of technologies and services, is argued by the authors in [29] as an approach to system or application integration. Middleware, providing enhanced support for EAI [30], is described as a technology stack that provides a platform for information exchange between applications in a distributed application environment [31]. Thus, EAI is found relevant as a technology to integrate different EMIS. ...
Full-text available
In this work detailed research and analysis of the challenges of integration and interoperability in education information systems is presented. The integration methods and techniques are examined, as well as interoperability frameworks and challenges in the last 15 years. The work is also driven by sharing of assessment data for the purpose of efficient personalization of learning environments.
... With the EIPs as business process building blocks, integration semantics can be expressed as implementation independent BPMN syntax. From this formal model, we show the realization of the sample integration scenario in Figure 1 to Apache Camel [1], which is a widely used, open-source system for message-based integration and event processing [5] (cf. REQs-4-5 ). ...
Conference Paper
Full-text available
Enterprise Integration Patterns (EIP) are a collection of widely used best practices for integrating enterprise applications. However, a formal integration model is missing, such as Business Process Model and Notation (BPMN) from the workflow domain. There, BPMN is a “de-facto” standard for modeling business process semantics and their runtime behavior. In this work we present the mapping of integration semantics represented by EIPs to the BPMN syntax and execution semantics. We show that the resulting runtime independent, BPMN-based integration model can be applied to a real-world integration scenario through compilation to an open source middleware system. Based on that system, we report on our practical experiences with BPMN applied to the integration domain.
Full-text available
Companies are taking advantage of cloud computing to upgrade their business processes. Cloud computing requires interaction with many kinds of applications, so it is necessary to improve the performance of software tools that allow keeping information on all these applications consistent and synchronised. Integration platforms are specialised software tools that provide support to design, implement, run, and monitor integration solutions, which aim to orchestrate a set of applications so as to promote compatibility among their data or to develop new functionality on top of the current ones. The run‐time system is the part of the integration platform responsible for running the integration solutions, which makes its performance the uttermost important issue. The contribution of this article is two‐fold: a framework and an evaluation of integration platforms. The former is a framework composed of ten properties grouped into two dimensions to evaluate the run‐time systems focusing on performance. Using this framework as reference, the second contribution is an evaluation of nine open‐source integration platforms, which represent the state‐of‐the‐art, provide support to the integration patterns, and follow the pipes‐and‐filters architectural style. In addition, as a result of this work, we suggest open research directions that can be explored to improve the performance of the run‐time systems and at the same time may be useful to adapt them to the context of cloud computing.
Conference Paper
Full-text available
So far, asynchronous messaging has proven to be the best strategy for enterprise application integration (EAI) success. However, building and deploying messaging solutions causes several problems for developers and new technologies and computing paradigms as cloud computing demand for new solutions. There are more than sixty enterprise integration patterns that are designed to effectively develop messaging solutions for enterprises. The tutorial introduces the visual notation framework to describe large-scale integration solutions across different systems and technologies. This includes examples covering a variety of different integration styles and techniques. In a case study we illustrate the application of the patterns in practice and review existing and emerging standards. Also we try to shed light into the future of EAI. In particular cloud integration is an upcoming trend which is discussed in the tutorial, addressing advantages and limitations of this and other modern EAI strategies and architectures. Looking at open-source solutions for enterprise service buses and messaging systems, we also provide practical advice on designing code that connects an application to a messaging system. This provides information to help the practitioner to design EAI or cloud integration solutions by applying the introduced knowledge.
Full-text available
Business Process Management (BPM) and real-time Business Activity Monitoring (BAM) are newly discussed as the preconditions for a so-called predictive business and the competitiveness of enterprises in the future. Com-plex event processing (CEP) is an emerging technology that shall be the basis in order to achieve actionable, situational knowledge from distributed message-based systems, databases and applications in real-time or near real-time. Detecting event patterns in an event cloud or in one or more event streams [30] is a basic idea of the CEP technology. If low level events without any semantics oc-cur in specific combinations, a complex event on a higher business level can be derived of them as well as of "his-torical" events stored in databases. First attempts of set-ting up CEP applications have shown that the potential adopters have major problems to define the needed event patterns. This is a reason why future CEP applications will delay to be set up. Therefore the availability of do-main specific reference models for event patterns is needed. In the project DoReMoPat, a catalogue of refer-ence models for selected domains like automotive, fi-nance, logistics, telco are developed and implemented as customizable prototypes. A meta model is defined for faster developing reference models for other domains. Reference models for event patterns can dramatically reduce time and costs as well as improve the quality of BPM/BAM projects.
Conference Paper
Full-text available
The development and operation of modern IT infrastructures requires generally accepted standards. Many standardization efforts are currently ongoing within the service oriented and event processing community. Recently a new discipline entitled "Event-Driven Business Process Management (ED-BPM)" has emerged which takes a synergetic approach within this larger area. Consecutively, topics being discussed in this paper relate to the role of standards in the ED-BPM context, the need for a standard per se and the benefits and shortcomings of standardization in early phases vs. late phases. Within this activities, the most interesting proposal for a reference architecture is the Networked European Software and Services Initiative (NESSI) approach called NESSI Open Serivce Framework - Reference Architecture (NEXOF-RA) which has to be enhanced in order to support ED-BPM applications. Thereupon a proposal for describing the context and structure of occurring events on a descriptive and non-complex level of events is discussed. Related industry standards like "Notification Event Architecture for Retail (NEAR)" and the possibility to extend that approach to other domains are surveyed. Two possible extensions are exemplified, for the logistics domain (NEAL), and for the finance domain (NEAF). Use cases for the retail, logistics, and finance domains are demonstrated. In the final analysis conclusions are drawn and proposed action items for advancing the ED-BPM standardization are made.
Conference Paper
Complex Event Processing (CEP) is a defined set of tools and techniques for analyzing and controlling the complex series of interrelated events that drive modern distributed information systems. This emerging technology helps IS and IT professionals understand what is happening within the system, quickly identify and solve problems, and more effectively utilize events for enhanced operation, performance, and security. CEP can be applied to a broad spectrum of information system challenges, including business process automation, schedule and control processes, network monitoring and performance prediction, and intrusion detection. This talk is about the rise of CEP as we know it today, its historical roots and its current position in commercial markets. Some possible long-term future roles of CEP in the Information Society are discussed along with the need to develop rule-based event hierarchies on a commercial basis to make those applications possible. The talk gives empahsis to the point that “Rules are everywhere” and that mathematical formalisms cannot express all the forms that are in use in various event processing systems.