Mule Overview

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

Application we’re integrating with. It can be anything — an old legacy Cobol system, a .NET application, a J2EE application, or even another Mule instance.

Channel

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

Message receiver

As 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.

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 router

This 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 dispatcher

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

15 July 2009

9

Developing a Mule Interface package org.mule.example.tryout;

Service to Process Message

hello.java

public class hello { public String hello (String aName) { return "Hello " + aName + "!"; } }

Input Terminal

stdio IN

Router Transformer

stdio OUT

Output Terminal

hello-config.xml <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 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"> <stdio:inbound-endpoint system="IN" /> <pass-through-router> <stdio:outbound-endpoint system="OUT" /> 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: Configuration XML

Source Code: Properties

mulecasestudy1-co nfig.xml

mulecasestudy1_pr operties

15 July 2009

Thank You

[email protected] [email protected]

Repository: M:\TEG\COE\8. Open Source\Mule

15 July 2009