You are on page 1of 15

Mule – Open Source ESB

A Case Study

Mukesh Kanchan

15 July 2009

Agenda  What is Mule  ESB – Why we need it  Commercial & Open Source ESB  Mule Architecture  Logical Data Flow  Developing a Mule Interface  A Case Study  Demo 15 July 2009 2 .

org  Based on ideas from Enterprise Service Bus (ESB) architecture  Part of MuleSource family of product.What is Mule?  A lightweight Java-based messaging framework  Uses Service Oriented Architecture (SOA)  Created by Open Source Community : www. includes other products: o Mule HQ (Deployment management/Administration) o Mule Galaxy (SOA Governance) o Mule IDE (eclipse plug-in) 15 July 2009 3 .mulesource.

Service Orchestrator 15 July 2009 4 . programming languages. and protocols. Adapter.  Transport and Format Translator  Router. Common message format (positional or XML) × frequent revision of message format due to business needs – increases testing time and expenses  Ross Mason – Java Engineer – identified these issues and started a project in 2001  Codehaus open-source project Mule  Progress Software (Sonic) also started the parallel work and coined the term : Enterprise Service Bus  ESB .Net × code-intensive.  Early attempt : Common transport (e.g. MQ Series).ESB – Why we need it?  Applications need to share data but have significant interface differences  Many Approaches suggested : Protocol wrappers. Porting legacy to Java or .A transit system for carrying data between applications within intranet or across the Internet. coupled to specific systems. expensive.

ESB – Logical Diagram 15 July 2009 5 .

ESB – Product Landscape Vendor Solution IBM WebSphere (WESB & WPS) IONA Technologies IONA Artix JBoss (Red Hat) JBoss ESB Microsoft BizTalk Component MuleSource Mule Enterprise Oracle Oracle Service Bus (Fusion) Progress Software Sonic ESB Software AG webMethods ESB platform Sun Microsystems Sun ESB Suites TIBCO Software ActiveMatrix (Business Woks) Apache ServiceMix **FUSE – IONA’s open source based on SM 15 July 2009 6 .

Mule Functionality Overview 15 July 2009 7 .

Mule Architecture 15 July 2009 8 .

15 July 2009 9 . REST service. a . Channels can Channel also be used inside Mule to wire services together. It can be anything — an old legacy Cobol system. This is the opposite of the message receiver. A channel provides a way for external applications to communicate with Mule. This is much the same as the inbound router. but this component determines where a Outbound router message is sent to after it’s processed by the component. or even another Mule instance. Groovy Script.Components Name Description Application we’re integrating with. This component knows how to send information Message dispatcher over a specific channel. A connector understands how to send and receive data from certain channels. among others. this component can receive information from a certain channel. Mule Message receiver provides receivers for a lot of common standards and technologies. Inbound router An inbound router determines what to do with a message once it’s received from a channel. A component can be implemented with a number of technologies: POJO.Mule Architecture .NET Application application. It is present Connector both at the receiving and the sending ends. and BPM. The component is the logical place within the Mule architecture to implement integration logic Component not provided by other Mule parts. The message receiver and message dispatcher are part of the connector. Transformer A transformer transforms data from one format to another. As the name implies. a J2EE application.

org/schema/beans/ http://www.2" xmlns:vm=" http://www.2" hello-config.Developing a Mule Interface Service to Process package org.hello" /> <outbound> <pass-through-router> <stdio:outbound-endpoint system="OUT" /> </pass-through-router> </outbound> </service> </model> </mule> 15 July 2009 10 .java Message public class hello { public String hello (String aName) { return "Hello " + aName + "!".2/" xmlns:spring="http://www.2 http://www.mulesource.0" encoding="UTF-8"?> <mule xmlns="http://www.2/mule.w3.xsd"> <stdio:connector promptMessage="What is your name?" name="ConsoleConnector" /> <model name="test"> <service name="helloservice"> <inbound> <stdio:inbound-endpoint system="IN" /> </inbound> <component class=" http://www. } stdio stdio Input Router Output Terminal Transformer Terminal } IN OUT <?xml version="" xmlns:stdio="http://www.springframework.2" xsi:schemaLocation=" http://www.springframework.mulesource.xsd http://www. xmlns:xsi="http://www.mulesource.springframework.mule.samples.mulesource.xsd http://www.

com/verify. The customer places an order on the company web 5. 6. 9. 7. The XML to Object transformer converts the XML invoice into a Java object. The transport passes the message with its transformed payload to the Customer Data service. 3. The HTTP transport uses the outbound router configuration to determine that it must now dispatch the message to http://myfirm. 8. and its inbound router specifies that the message must contain a Java object. 15 July 2009 11 . so no further transformers are used in this scenario. so the JMS transport dispatches the message to the order fulfillment application. 4. The HTTP transport receives the XML invoice and wraps it in a Mule message. The Customer Data service component queries the master customer database to pull additional data about the customer and updates the invoice with the data. 2. The HTTP transport uses the inbound router configuration of the Inventory Verification service to receive the message and pass it to the service component. The service component updates the invoice with an ID code of the warehouse that has all the items on the invoice in stock. so the HTTP transport prepares to transform the XML invoice and dispatch the message to the service. The Customer Data service's inbound endpoint is set to http://myfirm. Note that the next service and the final application also expect Java objects. which picks up orders on that address. The outbound endpoint specifies a JMS address. and an invoice is created as an XML form and submitted to Data Flow 1.

A Case Study A basic “real “real--time” content publishing system • Procurement and creative departments acquire or create content on time to time basis. • For effective utilization or sales of contents. earliest availability of these contents at consumer websites is desirable. • A high level metadata can be provided by the creators through file and/or folder properties • Websites can use meta data based filter to release these contents on their websites. These changes should reflect on other sister web-sites in real time. 15 July 2009 . • Meta data are editable by a web-site admin.

A Case Study 15 July 2009 .

xml operties 15 July 2009 .A Case Study Source Code: Source Code: Configuration XML Properties mulecasestudy1-co mulecasestudy1_pr nfig.

Thank You Mukesh. Open Source\Mule 15 July 2009 .com M:\TEG\COE\ Repository: abhishek18.j@tcs.