Service-Oriented Online Architecture with Mule A different approach to building a SOA Feroz khan
Service-Oriented Online Architecture with MuleA different approach to building a SOA
Feroz khan
Agenda 1.Business context and problems faced
2. The idea of a service-oriented online architecture
3. How and why we selected Mule4. Overview and examples of Mule use cases5. Best practices and learnings
2
Business context and problems faced
Existing online infrastructure was complex, expensive
to maintain and could not be used by other portals
3
Corporate Network (Head Quarter)
Portal
DistributionDMZPartner LAN
(*) as Reverse Proxy
Business logic and backend access in the portal needs to available to other portals
Server applications only run on specialized hardware and application platform
Everyone is talking to everyone, point-to-point communication is difficult to manage
Web-Server (*)
Web- Server (*)
Browser Oracle
DB2
BackendBackend
BackendBackend
Client-Application
Client-Application
DataPlatform
ComponentApplication
Platform
Online-ServerServer-
ApplicationServer-
Application- Spare Parts- Technical
Info- …
An ESB-centric service-oriented online architecture is
easier to manage and more extensible
4
Business context and problems faced
Online Client
Corporate Network (Head Quarter)
DMZ
PrimaryESB Backend
Portal
Online- Server
(*) as Reverse Proxy
Local Area Network
Web- Server (*)
Web- Server (*)
Browser
■ The migration of the server applications to standardized hardware proved to be rather difficult due to close coupling to platform
■ To get rid of the application platform components we had toidentify the all required services for the online scenario
■ Then a light-weight surrogate based on Mule was implemented to provide these services to the applications instead
■ The portal independent services had to be identified andextracted from the portal
■ Access to all backend systems is now provided by one central Mule ESB instance, implementing logging and security
■ The maintenance costs for the simplified architecture havealready decreased significantly
■ New server application instances can be deploy transparently within hours instead of days now
Business context and problems faced
The goal was to simplify the architecture, unify the
waybackend systems are
accessed and cut operation costs
5
Agenda 1. Business context and problems faced 2.The idea of a service-oriented online
architecture3. How and why we selected Mule4. Overview and examples of Mule use cases5. Best practices and learnings
6
The improved service-oriented online
architecture can becomposed using different
building blocks
7
The idea of a service-oriented online architecture
Online Client
Corporate Network (Head Quarter)
DMZ
PrimaryESB Backend
Portal
Online- Server
(*) as Reverse Proxy
Local Area Network
Web- Server (*)
Web- Server (*)
Web- Server (*)
LocalESB
Browser
A secondary ESB building block enables the
deploymentof dedicated online servers
in national networks
8
The idea of a service-oriented online architecture
LocalESB
Corporate Network(Head Quarter)
Primary ESB Backend
Portal
Online- Server
National Corporate Network (USA)
Secondary ESB
DMZ
Backend‘
Local Area Network
(*) as Reverse Proxy
Web-Server (*)
Web- Server (*)
Web-Server (*)
Browser
Online-Client
Multiple portal and online server blocks can be
combinedto support different user
groups and network locations
9
The idea of a service-oriented online architecture
Corporate Network
PrimaryESB Backend
Portal
Online- Server
National CorporateNetwork (USA)
SecondaryESB
DMZ
Backend‘
Local AreaNetwork
Web- Server (*)
Web- Server (*) (*) as Reverse Proxy
LocalESB
Browser
Online- Client
Web-Server (*)
Portal
Online- Server
Agenda1. Business context and problems faced2. The idea of a service-oriented online
architecture 3.How and why we selected Mule
4. Overview and examples of Mule use cases5. Best practices and learnings
10
■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-weight deployment
■ Good code quality, in spite of found violations and partially low documentation
■ Test coverage is reasonably high to ensure correct function in case of changes
How and why we selected Mule
Based on the proposed architecture scenarios we
couldidentify the requirements
on the ESB product
11
■ Chosen products: Mule ESB, WSO2 and Fuse ESB
■ Are all 3 uses cases supported?
■ Development model: used frameworks,supported IDEs, build tools?
■ Learning curve: How good is the documentation? Clear API?
■ Development effort: How long does ittake to implement the uses cases?
■ Mule ESB scored best in comparison, closely followed by WSO2
How and why we selected MuleImplementation of a small PoC prototype to get a firstimpression of the chosen
products
121 2 3WS-Call POJO Provider External WS-Call (Asnyc) WS-Proxy with
Transform
■ 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 solveall the found issues:
■ MuleSoft supplied a working patch for the Registry synchronization issue within 2 days
■ 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
How and why we selected MuleIntensive performance tests uncovered several
findings(with Mule 3.1.1) …
13
Agenda1. Business context and problems faced2. The idea of a service-oriented online
architecture3. How and why we selected Mule 4.Overview and examples of Mule use cases 5. Best practices and learnings
14
Clustered deployment of Mule ESB as a web
applicationfor scalability and high
availability■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
■Each Glassfish v2.1 app server instance runs with 512mb heap space on SuSe linux
■The reverse proxies are Apache 2.2 instances using mod_proxy with stickyness
■The final WAR is simply assembled from the Maven artifacts of the individual Mule apps
■Hot-deployment of individual apps not required
15
Overview and examples of Mule use cases
Overview and examples of Mule use cases
Unified web service interface to access details
userfrom heterogeneous data
sources
16
■ Access to the endpoint is controlledusing a Spring security filter
■ Each data source has specific POJO implementation or private flow
■ Choice is based on payload using a Groovy evaluator
■ Only minor Java code required
■ Web service interface and types
■ Custom transformers
■ Choice uses CXF operation header
■ XSLT to transform XML/RPC to JAXB XML structure
Overview and examples of Mule use cases
Web service to XML/RPC service adapter to access
theBZST service for simple and
qualified VAT checks
17
■ Web service interface and types defined asPOJI and POJOs with JAX-WS annotations
■ The service component only performs validation and preprocessing of request
Overview and examples of Mule use cases
Web service to email service adapter to send
supportrequests to a ticketing
backend system
18
■ The actual sending using an SMTPconnector is performed asynchronous
■ Custom transformer uses Velocity to convert request object to email body
Agenda1. Business context and problems faced2. The idea of a service-oriented online
architecture3. How and why we selected Mule4. Overview and examples of Mule use cases 5.Best practices and learnings
19
■ Mule provides several built-in components to test Mule XML and flow definitions
■ 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 to use
■ Smart combination of SoapUI test cases together with mock services allowed 100% local and off-site development
■ Learning: develop as much as possible asPOJOs and use „traditional“ unit testing
■ Learning: take the time to write a good mock for the service you are integrating
Best practices and learningsTest driven development using MuleFunctionalTests,
SoapUI tests and mock services
20
■ „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 Mule community 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
Best practices and learnings
Building a custom Mule distribution for 100%
control ofall dependencies and optimal performance
21
96 MB
30 MB
37 MB
■ 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 infrastructurecomponents and applications has been used:
■ Phase 1: Migration of all online servers, application by application, introduction of the primary ESB with first required services
■ Phase 2: Integration of a new online portal, operated inparallel to the old portal infrastructure
■ Phase 3: Migration of all „legacy“ portals to access the new online infrastructure components
■ 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)
Best practices and learningsNo big bang: start small and migrate in several
phases
22
Questions & Answers