This document discusses how four technologies - SOA, EDA, BPM, and CEP - can work together in complementary ways. It provides examples using open source software of how these technologies can be combined to create enterprise middleware solutions. Specifically, it shows how Mule ESB can be used with jBPM for service orchestration and business process management, with Drools for business rules and event processing, and with Drools for complex event processing. It also discusses a real-world customer use case that implemented a large event-driven process using Mule ESB and jBPM.

1. SOA, EDA, BPM, and CEP are all Complementary:
Practical Examples in Open Source Software
Travis Carlson
MuleSoft, Inc., San Francisco, CA, U.S.A.
travis.carlson@mulesoft.com
Abstract. As David Luckham writes in his article “SOA, EDA, BPM and CEP
are all Complementary”, there is a great potential for synergy when these
technologies work together to create enterprise middleware solutions. In this
paper we shall see examples of combining these approaches using open source
software as well as a real-world customer use case.
Keywords: SOA, EDA, BPM, Business Process Management, Event-driven
BPM, CEP, Complex Event Processing, Business Rules, ESB
1 Introduction
As David Luckham writes in his article “SOA, EDA, BPM and CEP are all
Complementary” [1], there is a great potential for synergy when these technologies
work together to create enterprise middleware solutions. In this paper we shall see
examples of combining these approaches using open source software as well as a real-
world customer use case.
Open Source Software
Open source is a development method for software that harnesses the power of
distributed peer review and transparency of process. The promise of open source is
better quality, higher reliability, more flexibility, lower cost, and an end to predatory
vendor lock-in. [2]
Mule ESB 1
is a lightweight integration platform and service container, providing
features for web services, message routing, mediation, transformation and transaction
management. It is distributed under the CPAL license.
jBPM 2
is a flexible business process management suite which is distributed under
the LGPL license.
Drools 3
is a platform for business rules, workflow and event processing/temporal
reasoning, distributed under the ASL license.
All of these licenses are of the “business-friendly” type 4
, which makes them viable
from a legal standpoint for enterprise middleware.
1 http://www.mulesoft.org
2 http://www.jboss.org/jbpm
3 http://www.jboss.org/drools
4 http://www.supportforge.biz/content/view/16/33/

2. 2 SOA/EDA and Business Process Management (BPM)
On its own, an Enterprise Service Bus is an ideal platform for service-oriented event-
driven architectures. It does a good job at interfacing between heterogeneous
technologies as well as routing and transforming messages. However, when a
considerable amount of business logic is involved, the amount of custom code
becomes difficult to maintain and the logic governing interaction between services is
not easily visible. This is when a Business Process Management (BPM) engine
becomes a good complement.
Example
Following is a simple example of how an event-driven process application can be
implemented using Mule ESB with jBPM. The example is an application which
receives a customer request for a loan, queries the customer's credit profile from an
external service, selects a bank based on the result of this query, then queries the bank
for their interest rate and returns this quote to the customer. The credit agency request
is via JMS, while the bank request is via SOAP. The orchestration of services and
requests is handled elegantly by the BPM engine.
Mule ESB Configuration Snippet
<cxf:endpoint name="BigBank" address="http://bank1.com/loanquote"
clientClass="org.mule.example.loanbroker.LoanQuote"
operation="GetQuote" wsdlPort="LoanQuoteSoap"
wsdlLocation="classpath:loanquote.wsdl" />
<service name="ProcessEngine">
<inbound>
<jms:inbound-endpoint queue="customer.requests" />
<jms:inbound-endpoint queue="credit.profiles" />
</inbound>
<bpm:component>
<bpm:process name="LoanBroker"
resource="loan-broker-process.jpdl.xml" />
</bpm:component>
</service>
jBPM Process Definition Snippet
<!-- Request received from customer -->
<mule-receive name="incomingCustomerRequest"
endpoint="CustomerRequests" var="customerRequest">
<transition to="sendToCreditAgency" />
</mule-receive>
<!-- Send customer info. to credit agency -->
<mule-send name="sendToCreditAgency"
expr="#{customerRequest.customer}" endpoint="CreditAgency"
synchronous="false">
<transition to="waitForCreditAgency" />
</mule-send>
<!-- Wait for the customer's credit profile to arrive. -->
<mule-receive name="waitForCreditAgency"
endpoint="CreditProfiles" var="creditProfile">
<transition to="prepareLoanQuoteRequest" />
</mule-receive>

3. <!-- Send the request to one of three banks, depending on the loan
amount and customer credit info. -->
<decision name="sendToBanks">
<transition to="sendToBigBank">
<condition expr="#{customerRequest.loanAmount >= 20000}" />
<condition expr="#{creditProfile.creditHistory >= 24}" />
<condition expr="#{creditProfile.creditScore >= 5}" />
</transition>
<transition to="sendToMediumBank">
<condition expr="#{customerRequest.loanAmount >= 10000}" />
<condition expr="#{creditProfile.creditHistory >= 12}" />
<condition expr="#{creditProfile.creditScore >= 3}" />
</transition>
<transition to="sendToSmallBank">
<condition expr="#{creditProfile.creditHistory >= 6}" />
<condition expr="#{creditProfile.creditScore >= 1}" />
</transition>
<!-- If the credit info. doesn't meet minimum requirements based
on the loan amount, the loan is just denied. -->
<transition to="loanDenied" />
</decision>
<mule-send name="sendToBigBank" expr="#{loanRequest}"
endpoint="BigBank" var="loanQuote"
type="org.mule.example.loanbroker.messages.LoanQuote">
<transition to="sendCustomerResponse" />
</mule-send>
3 SOA/EDA and Business Rules
Another way to complement an event-driven service-oriented application is by adding
Business Rules. This might be instead of BPM or in addition to it, as each one is
better suited for certain types of business logic.
Example
Following is a simple example of how business rules could be used to implement an
SLA function for an event-driven SOA application using Mule with Drools. The
example is an application which receives a stream of on-line support tickets via a JMS
topic, processes them (via a human being), and publishes them to a “completed”
topic. A rules engine snoops on the incoming and completed ticket streams and
escalates a ticket's status if its defined SLA is not being met. A ticket escalation
causes a row to be inserted into a reporting database.
Mule ESB Configuration Snippet
<service name="supportQueue">
<inbound>
<jms:inbound-endpoint topic="incoming.tickets" />
</inbound>
<component class="org.mule.example.sla.SupportAgent" />
<outbound>
<pass-through-router>
<jms:outbound-endpoint topic="completed.tickets" />
</pass-through-router>
</outbound>
</service>

4. <service name="rulesEngine">
<inbound>
<jms:inbound-endpoint topic="incoming.tickets" />
<jms:inbound-endpoint topic="completed.tickets" />
</inbound>
<rules:component>
<rules:rules resource="SupportSLA.drl" />
</rules:component>
</service>
<service name="reporting">
<inbound>
<jms:inbound-endpoint topic="escalated.tickets" />
</inbound>
<outbound>
<pass-through-router>
<jdbc:outbound-endpoint queryKey="insertEscalatedTicket" />
</pass-through-router>
</outbound>
</service>
Drools Configuration Snippet
rule "Silver Priority"
duration 5000
when
customer : Customer( subscription == "Silver" )
ticket : Ticket( customerId == customer.id, status == "New" )
then
modify( ticket ) { setStatus( "Escalated" ) };
end
rule "Gold Priority"
duration 3000
when
customer : Customer( subscription == "Gold" )
ticket : Ticket( customerId == customer.id, status == "New" )
then
modify( ticket ) { setStatus( "Escalated" ) };
end
rule "Escalate Ticket"
when
ticket : Ticket( status == "Escalated" )
then
mule.generateMessage("jms://escalated.tickets", ticket);
end
4 SOA/EDA and Complex Event Processing (CEP)
Complex Event Processing can also complement an event-driven service-oriented
application if the business logic calls for temporal reasoning within a stream or cloud
of events. Once again, this could be instead of or in addition to BPM and Business
Rules, as each one is better suited for certain types of business logic.

5. Example
Following is a simple example of how CEP could work within an event-driven
service-oriented application using Mule with Drools. The example is an application
which polls a public web service for real-time stock tick updates via SOAP requests
and posts the updates to a JMS queue. The queue is subscribed to by a CEP engine
which detects large drops in stock value and generates alert messages (meta-events)
which get logged and routed to human analysts via e-mail.
Mule ESB Configuration Snippet
<service name="stockTickFeed">
<inbound>
<cxf:inbound-endpoint
address="http://www.webservicex.net/stockquote.asmx"
clientClass="net.webservicex.StockQuote"
operation="GetQuote" wsdlPort="StockQuoteSoap"
wsdlLocation="stockquote.wsdl" />
</inbound>
<outbound>
<pass-through-router>
<jms:outbound-endpoint queue="stock.tick" />
</pass-through-router>
</outbound>
</service>
<service name="rulesEngine">
<inbound>
<jms:inbound-endpoint queue="stock.tick" />
</inbound>
<rules:component>
<rules:rules resource="StockAnalysis.drl"
entryPoint="StockTick Stream" agendaGroup="evaluation" />
</rules:component>
</service>
<service name="rulesAlerts">
<inbound>
<jms:inbound-endpoint queue="stock.alerts" />
</inbound>
<log-component />
<outbound>
<multicasting-router>
<smtp:outbound-endpoint address="analyst1@acme.com" />
<smtp:outbound-endpoint address="analyst2@acme.com" />
</multicasting-router>
</outbound>
</service>
Drools Configuration Snippet
rule "Update stock price"
when
$cp : Company( $sb : symbol )
$st : StockTick( symbol == $sb, $pr : price )
from entry-point "StockTick Stream"
then
modify( $cp ) { currentPrice = $pr }
modify( $st ) { delta = $cp.delta }
end
rule "Sudden drop"
when

6. $st : StockTick( $sb : symbol, $ts : timestamp,
$pr : price, $dt : delta < -0.05 )
from entry-point "StockTick Stream"
not( StockTick( symbol == $sb, timestamp > $ts )
from entry-point "StockTick Stream" )
then
msg = "***** Drop >5%: "+$sb+" delta: "+StockTick.percent($dt)
+" price: $"+$pr + " *****";
mule.generateMessage("jms://stock.alerts", msg);
end
5 Customer Use Case
As real-world validation of the concepts in this paper, a large event-driven business
process application has been recently implemented using Mule ESB with jBPM for a
high-profile customer. A description of the architecture is as follows.
Web form submissions create incoming events on a JMS queue. These events are
subscribed to by Mule and routed to one of several jBPM processes which model the
business logic. The event-driven processes make synchronous and/or asynchronous
calls to Siebel via SOAP web services. There are 5 complex processes plus 7 basic
processes that ultimately call one of the complex processes. Processes invoke each
other by sending events. Exceptions in message processing cause erroneous messages
to be redirected to error queues. Historical process information is kept in an Oracle
database to act as a data warehouse.
Fig. 1. Graphical process definition from customer use case
References
1. Complex Event Processing, http://complexevents.com/2007/04/30/soa-eda-bpm-and-cep-
are-all-complementary, http://complexevents.com/2007/07/08/soa-eda-bpm-and-cep-are-all-
complementary-part-2
2. Open Source Initiative, http://www.opensource.org