The document discusses the selection and use of Mule ESB as the integration platform. It describes how Mule was chosen over other open source ESBs based on criteria like maintenance, support, licensing, and performance. Intensive tests uncovered some issues with Mule 3.1.1 that were reported and addressed. Examples of how Mule was used include deploying it as a web application, integrating data sources, and building APIs. A custom lightweight Mule distribution was also created for optimal performance. The infrastructure migration involved a staged approach, integrating applications gradually over several phases.

1. MULE-SOA

2. Business context and problems faced
The idea of a service-oriented online architecture
How and why we selected Mule
Overview and examples of Mule usecases
Best practices and learnings

3. ■ We did not Google „open source ESB“ to select Mule …
■ Instead we did a qualitative and quantitative comparison of major open source ESB
products using different criteria:
■ Primary: professional maintenance, commercial support with SLAs, licensing,performance,
operations by IT department possible
■ Secondary: documentation, code quality, activity and size of community, Spring support,sync
and async communication, supported standards, app server integration, development tools
■ Mule quickly emerged as the favored ESB product, followed by Fuse ESB and WSO2
■ Static analysis of the Mule sources (Sonar,
Structure101) showed acceptable quality
■ Modularization and project structure looks well-
thought-out and enables light-weightdeployment
■ Good code quality, in spite of found violations and
partially low documentation
■ Testcoverage is reasonably high to ensurecorrect
function in case ofchanges
Basedontheproposedarchitecturescenarioswecouldidentifytherequirementsonthe
ESB
product

4. ■ Different load scenarios with constant and
increasing parallel requests (Apache JMeter)
■ Measurement of performance relevant
metrics using Software-EKG
■ Live profiling of system behavior (JProfiler)
■ All findings have been reported to MuleSoft
■ Together with MuleSoft we were able to solve
all the found issues:
■ MuleSoft supplied a working patch for the
Registry synchronization issue within 2days
■ Other issues could simply be addressed using
the optimized configuration parameters (thread
pool settings, …) supplied to us
■ This was decisive for the confidence and the
final decision for Mule ESB
Intensiveperformancetestsuncoveredseveral
findings
(with Mule 3.1.1)…

5. Clustereddeployment of Mule ESB
as a web application for scalability
and highavailability
■Requirement: Mule ESB
had to be deployed as a Java
web application to be
operated by the IT
department
■Embedding Mule into a web
app is pretty straight forward
using the a context listener
■Custom listener
implementation required to
customize working directory
and various other system
properties

6. Unified web service interfaceto
access detailsuser
from heterogeneous datasources
■ Access to the endpoint is controlled
using a Spring security filter
■ Each data source has specific POJO
implementation or private flow
■ Choice is based on payload using a
Groovy evaluator

7. ■ Only minor Java code required
■ Web service interface andtypes
■ Customtransformers
■ Choice uses CXF operation header
■ XSLT to transform XML/RPC to
JAXB XMLstructure
adapterto access the
BZST service for simple and
qualifiedVATchecks

8. ■ Web service interface and types defined as
POJI and POJOs with JAX-WS annotations
■ The service component only performs
validation and preprocessing of request
Web service to email service adapter
to sendsupport
requests to a ticketing backend
system
■ The actual sending using an SMTP
connector is performed asynchronous
■ Custom transformer uses Velocity to
convert request object to email body

9. Testdriven development using
MuleFunctionalTests, SoapUItests
and mock services
XML and flowdefinitions
■The MuleFunctionalTest
allowed us to test our flows
within the IDE
■No deployment to a
standalone instance
required, thus reducing turn-
around times
■The MuleClient is not really
intuitive touse
■Smart combination of
SoapUI test cases together
with mock services allowed
100% local and off-site
development
■Learning: develop as much

10. ■ „The Leanest, Meanest ESB: Mule ESB is the world's most efficient Enterprise
Service Bus” (http://www.mulesoft.com/mule-esb-small-footprint)
■ We went well below the mentioned figures by building a custom Mule distribution
tuned and optimized for our specific use cases
■ Based on the default distribution assembly XML found in the Mulecommunity
sources, we
1. got rid of everything not required in production, mainly docs and examples, but also not
required Tanuki EXE wrapper binaries,etc.pp.;
2. selected only the required Mule modules and transports our uses cases really required, this
reduced the amount of 3rd party libs significantly;
3. used Maven dependency management to have full control of all used 3rd party libraries,
used more recent versions where possible (e.g. Spring, CXF, Saxon)
4. added our Mule apps and their dependencies, then repackaged
■ Thorough load tests lead to optimized JVM parameters and high performance:
-Xmx=128m -Xms=128m -XX:MaxPermSize=64m -XX:NewRatio=2 -XX:SurvivorRatio=12 -XX:+UseParallelGC
-XX:+UseParallelOldGC
Buildinga customMule distribution
for 100% control of all dependencies
and optimalperformance
96 MB
30 MB
37 MB

11. ■ A migration of the whole infrastructure in one go would
have been impossible; the system needs to be
available around the clock
■ Instead a staged migration of the infrastructure
components and applications has been used:
■ Phase 1: Migration of all online servers, application by
application, introduction of the primary ESB with first
requiredservices
■ Phase 2: Integration of a new online portal, operated in
parallel to the old portalinfrastructure
■ Phase 3: Migration of all „legacy“ portals to access the new
online infrastructurecomponents
■ After each phase the behavior of the new components
was monitored closely to detect any problems in
production
■ The services and backend systems integrated by the
primary ESB instance constantly grew (I might still be
growing in next phases)
No big bang:startsmall and migrate
in several phases

12. Thank you