mule overview
TRANSCRIPT
15 July 2009
Mule – Open Source ESB
A Case Study
Mukesh Kanchan
M&IS ISU TEG
Agenda
� What is Mule
� ESB – Why we need it
� Commercial & Open Source ESB
� Mule Architecture
� Logical Data Flow
15 July 2009 2
� Logical Data Flow
� Developing a Mule Interface
� A Case Study
� Demo
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)
15 July 2009 3
o Mule Galaxy (SOA Governance)
o Mule IDE (eclipse plug-in)
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
15 July 2009 4
� 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
ESB – Logical Diagram
15 July 2009 5
ESB – Product Landscape
VendorVendor SolutionSolution
IBM WebSphere (WESB & WPS)
IONA Technologies IONA Artix
JBoss (Red Hat) JBoss ESB
Microsoft BizTalk Component
MuleSource Mule Enterprise
Oracle Oracle Service Bus (Fusion)
15 July 2009 6
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
Mule Functionality Overview
15 July 2009 7
Mule Architecture
15 July 2009 8
Mule Architecture - Components
NameName DescriptionDescription
ApplicationApplication we’re integrating with. It can be anything — an old legacy Cobol system, a .NET
application, a J2EE application, or even another Mule instance.
ChannelA channel provides a way for external applications to communicate with Mule. Channels can
also be used inside Mule to wire services together.
Message receiverAs the name implies, this component can receive information from a certain channel. Mule
provides receivers for a lot of common standards and technologies.
Connector
A connector understands how to send and receive data from certain channels. It is present
both at the receiving and the sending ends. The message receiver and message dispatcher
are part of the connector.
15 July 2009 9
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.
Component
The component is the logical place within the Mule architecture to implement integration logic
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.
Outbound routerThis is much the same as the inbound router, but this component determines where a
message is sent to after it’s processed by the component.
Message dispatcherThis is the opposite of the message receiver. This component knows how to send information
over a specific channel.
Developing a Mule Interface
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
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
hello-config.xml
package org.mule.example.tryout;
public class hello {
public String hello (String aName) {
return "Hello " + aName + "!";
}
}
hello.java
Input
TerminalOutput
Terminal
Service to
Process
Message
RouterRouter
TransformerTransformer
stdio
IN
stdio
OUT
15 July 2009 10
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>
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
15 July 2009 11
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.
A Case Study
A basic A basic “real“real--time”time” content publishing systemcontent 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
15 July 2009
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.
A Case Study
15 July 2009
A Case Study
15 July 2009
Source Code: Configuration XML
Source Code: Properties
mulecasestudy1-config.xml
mulecasestudy1_properties
Thank YouThank You
15 July 2009
Thank YouThank You
Repository:
M:\TEG\COE\8. Open Source\Mule