Mule soa
- 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