Why use an ESB

´Ø Integration Styles

´– Batch

´– File Transfer

´– Shared Database

´– Request/Reply

´– Messaging

´l Synchronous

´l Asynchronous

´Ø ESB Advantages

´– Supports all styles

´– Bridges legacy systems

´– Modular architecture

´– Simple and flexible

´– Easy to test and maintain

´– Scalable

´– Can be a step towards

Mule Special Features

ge and ca

üMule components can be any type you want. You can easily integrate anything from a "plain old Java object" (POJO) to a component from another framework.

üMule and the ESB model enable significant component reuse. Unlike other frameworks, Mule allows you to use your existing components without any changes. Components do not require any Mule-specific code to run in Mule, and there is no programmatic API required. The business logic is kept completely separate from the messaging logic.

üMessages can be in any format from SOAP to binary image files. Mule does not force any design constraints on the architect, such as XML messaging or WSDL service contracts.

üYou can deploy Mule in a variety of topologies, not just ESB. Because it is lightweight and embeddable, Mule can dramatically decrease time to market and increases productivity for projects to provide secure, scalable applications that are adaptive to change and can scale up or down as needed.

Mule Messaging Framework

üThe advantage of networking your applications is that one application can send data to another application. However, many applications don't have the ability to read or process data coming from another application. Mule solves this problem by providing a messaging framework that reads, transforms, and sends data as messages between applications. A message is simply a packet of data that can be handled and sent between applications on a specific channel (also called a queue).

üAt the simplest level, when you connect applications to Mule, it reads data from one application, transforms it as needed so it can be read by the target application, and sends it to that application. This allows you to integrate all types of applications, even those that were not built to be integrated.

üMule is a messaging framework based on ideas from Enterprise Service Bus (ESB) architectures. The key advantage of an ESB is that it allows different applications to communicate with each other by acting as a transit system for carrying data between applications within your intranet or across the Internet. The heart of the system is the message bus, which routes messages between applications.

üOne difference between Mule and a traditional ESB is that Mule only converts data as needed. With a typical ESB, you have to create an adapter for every application you connect to the bus and convert the application’s data into a single common messaging format. The development of these adapters and the time required to process every message requires a lot of time and effort. Mule eliminates the need for a single message format. The information is sent on any communication channel, such as HTTP or JMS, and is translated only as needed along the way. Therefore, Mule increases performance and reduces development time over a traditional ESB.

Mule Architecture

üMule is based on the concept of a service-oriented architecture (SOA). The SOA approach to development allows IT organizations to create applications by bringing together components of application functionality, or services. Services are discrete sets of functionality that are completely separate from each other but can work together on the same objects. For example, if you need to process invoices, you might have one service that merges customer data from a database into the invoice and another service that checks the inventory database to see if the items on the invoice are in stock.

üBecause each service stands alone, services can be used as building blocks for multiple processes and do not have to be recreated for each type of process or message. For example, the service that merges customer data onto the invoice could also be used to merge customer data onto statements, letters, or other documents. This modular approach allows you to create functionality once and re-use it as many times as needed, streamlining development.

üUsing SOA, businesses can realize dramatic savings on development costs and can rapidly adapt to changing business conditions by reusing and reconfiguring existing services in developing new applications. SOA also enables better integration of enterprise IT resources, including previously isolated application silos and legacy systems. Mule fully supports the SOA approach and orchestrates communication among the services, allowing you to easily tie all these applications together.

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

Mule Logical Data Flow Part2

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.

Mule Logical Data Flow Part 2

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.