Mule – Open Source ESB

A Case Study

Mukesh Kanchan
M&IS ISU TEG

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
What is Mule?
 A lightweight Java-based messaging framework

 Uses Service Oriented Architecture (SOA)

 Created by Open Source Community : www.mulesource.org

 Based on ideas from Enterprise Service Bus (ESB) architecture

 Part of MuleSource family of product, includes other products:

o Mule HQ (Deployment management/Administration)

o Mule Galaxy (SOA Governance)

o Mule IDE (eclipse plug-in)

15 July 2009 3
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 .Net

× code-intensive, expensive, coupled to specific systems, programming languages, and protocols.

 Early attempt : Common transport (e.g. MQ Series), 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 - A transit system for carrying data between applications within intranet or across the Internet.

 Transport and Format Translator

 Router, Adapter, Service Orchestrator

15 July 2009 4
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
Mule Architecture - Components
Name Description
Application we’re integrating with. It can be anything — an old legacy Cobol system, a .NET
Application
application, a J2EE application, or even another Mule instance.

A channel provides a way for external applications to communicate with Mule. Channels can
Channel
also be used inside Mule to wire services together.

As the name implies, this component can receive information from a certain channel. Mule
Message receiver
provides receivers for a lot of common standards and technologies.

A connector understands how to send and receive data from certain channels. It is present
Connector both at the receiving and the sending ends. The message receiver and message dispatcher
are part of the connector.

Transformer A transformer transforms data from one format to another.

Inbound router An inbound router determines what to do with a message once it’s received from a channel.

The component is the logical place within the Mule architecture to implement integration logic
Component not provided by other Mule parts. A component can be implemented with a number of
technologies: POJO, Groovy Script, REST service, and BPM, among others.

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.

This is the opposite of the message receiver. This component knows how to send information
Message dispatcher
over a specific channel.

15 July 2009 9
Developing a Mule Interface Service to
Process
package org.mule.example.tryout;
hello.java Message
public class hello {

public String hello (String aName) {

return "Hello " + aName + "!";
} stdio stdio
Input Router Output
Terminal Transformer Terminal
} IN OUT
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.2" hello-config.xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd
http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.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="org.mule.samples.hello" />
<outbound>
<pass-through-router>
<stdio:outbound-endpoint system="OUT" />
</pass-through-router>
</outbound>
</service>
</model>
</mule>

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

15 July 2009
A Case Study

15 July 2009
A Case Study

Source Code: Source Code:

Configuration XML Properties

mulecasestudy1-co mulecasestudy1_pr
nfig.xml operties

15 July 2009
 Thank You

Mukesh.Kanchan@tcs.com Repository:
abhishek18.j@tcs.com M:\TEG\COE\8. Open Source\Mule

15 July 2009