General
• What is Mule?
• What is an ESB?
• Is Mule an ESB?
• Why use Mule?
• Is Mule a JBI Container?
• How does Mule compare to JBI?
• Do Mule and JBI compete?
• Can I use Mule with JBI container X?
• Why not just use JMS?
• How does Mule fit in with my webapp?
• Do we need another framework?
• Where do I go to learn more?
• How can I ask questions about Mule?
• I found a bug, what do I do?
• I thought of this really cool feature, how can I get it added?
Mule Framework
• Why is Mule called Mule?
• What do you mean by Lightweight and Event-driven?
• How does Mule provide Scalability?
• How does Mule enforce decoupling?
• What is an UMO component?
• What is zero code intrusion?
• What about Endpoints, Connectors and Transformers?
Implementing mule framework through eclipse
If you want to build mule framework in eclipse and want to deploy the built in examples
provideded by the mule framework follow this link
http://www.customware.net/repository/pages/viewpage.action?pageId=1927
Service provisioning through ESB
A complete business scenario example through which you can understand the ESB in mule
framework follow this link
http://today.java.net/pub/a/today/2005/10/18/service-provisioning-through-esb.html#esb-in-industry
What is Mule?
Mule is an ESB (Enterprise Service Bus) and integration platform. It can be thought of as a lightweight.
Messaging framework and highly distributable object broker that can seamlessly handle interactions with other applications using disparate technologies such as JMS, Http, Email, and Xml-RPC.
The Mule framework provides a highly scalable environment in which you can deploy your business
Components. Mule manages all the interactions between components transparently whether they exist in
the same VM or over the Internet, and regardless of the underlying transport used.
Mule was designed around the ESB (Enterprise Service Bus) enterprise integration pattern, which
Stipulates that different components or applications communicate through a common messaging bus,
Usually implemented using JMS or some other messaging server.
What is an ESB?
ESB or "Enterprise Service Bus," refers to a range of functions designed to offer a more flexible and
manageable way to enable a disparate range of applications to work together. The central element to any
ESB is a message bus that is used as the communication medium or "wire" between different components
or applications on the bus. Java Message Service (JMS) is typically used as the message backbone, but
any other message server implementation could be used, such as MSMQ, IBM MQ Series or Tibco
Rendevouz.
See the Articles page for further reading.
http://mule.mulesource.org/wiki/display/MULE/Articles
For an example see the Loan Broker ESB sample application.
http://mule.mulesource.org/wiki/display/MULE/LoanBroker+ESB.
Is Mule an ESB?
Mule was designed around the concepts of ESB, but evolved the design to provide greater flexibility in the
way in which services can communicate with each other. ESB standardizes on the notion of a message
bus, whereas Mule services can communicate over a whole range of communication channels. Mule allows
service applications to be developed using different deployment topologies such as ESB, pipeline, peer
network, client/server, and more.
Why use Mule?
There are currently several commercial ESB implementations on the market. However, many of these are
Either vapor-ware or built on top of an existing application server or messaging server in a closed way,
which means that inevitably you'll be locked in to that vendor.
The philosophy of the Mule project is to leverage existing standards and be flexible enough to embrace
New standards as they emerge. Another requirement was that the developer should be able to leverage
many disparate standards using mule in a consistent and simple way. So regardless of whether a
Message is received as a JMS, Email or SOAP message the process of receiving and sending information
over these protocols should always be the same.
Mule provides a simple framework for setting up an ESB and leveraging your existing development
investment and reducing new development costs -
1. The ESB construct inherently provides an easy route to streamlining enhancing and automating
processes.
2. Any kind of component can be configured in Mule, that is to say, to run a component in Mule there
is no need to implement any Mule specific code, the object can be anything from a Java Bean, POJO
or a component from another framework.
3. Mule and the ESB model enable significant component reuse and unlike other frameworks it allows
you to use your existing components without any changes.
4. Mule can dramatically decrease time to market and increases productivity for projects to provide
secure, scalable applications that are adaptive to change.
Is Mule a JBI Container?
Mule itself is not a JBI container, but there is Mule JBI http://mule.mulesource.org/wiki/display/MULE/Home which is a JBI container built from the ground up
That adheres to the JSR-208 http://www.jcp.org/en/jsr/detail?id=208 specification.
How does Mule compare to JBI?
Mule and JBI have some overlap in the problems they solve but under the covers they do it in different
ways. JBI is XML and WSDL centric where as Mule makes no assumptions about the message type so that
you can easily use Strings, binaries, MIME, XML or a mixture without any extra development.
JBI uses a notion of Message Exchanges and a Normalized Message to communicate between
components, where as Mule uses a flexible "Bean to Endpoint mapping" architecture that allows you to
develop sophisticated message flows between services.
JBI is targeted specifically at application integration whereas mule is more of a ubiquitous messaging
fabric that goes beyond integration to provide a solutions for translating, monitoring, routing and
orchestrating all type of information around the organization and beyond in a secure, scalable
environment.
Do Mule and JBI compete?
There is crossover between Mule and JBI, but JBI addresses a subset of messaging problems. Mule
addresses the basic need to enable services that deal with all kinds of data (not just Xml) and objects
around an organisation.
Mule also addresses the needs of smaller applications that just need to obtain or send information to
disparate sources. Mule was designed from the outset to scale down as well up.
Can I use Mule with JBI container X?
Mule works with any JBI container so that Mule components, routers, endpoints and transformers can be
executed in a JBI container.
The reason Mule integrates with other JBI engines and provides it own JBI container is that one
integration solution will never satisfy all messaging needs. ? Mule levels the playing field allowing you to
pick and choose which technologies to integrate with.
Why not just use JMS?
JMS is a vital tool in the enterprise toolbox, but on its own it leaves a lot of additional work for the
developer in order to use it. Mule provides a simple, consistent yet fully customisable way to work with
JMS or any other messaging, transport or repository technology. Components in Mule are wired together
using a variety of technologies though this is totally abstracted away from the application.
How does Mule fit in with my webapp?
Mule can easily be embedded in a webapp http://mule.mulesource.org/wiki/display/MULE/Embedding+Mule+in+a+Webapp or any other Java application http://mule.mulesource.org/wiki/display/MULE/Embedding+Mule+in+a+Java+Application and can be used to handle
complex interactions with external sources and applications. Mule also provides powerful routing http://mule.mulesource.org/wiki/display/MULE/Embedding+Mule+in+a+Java+Application
capabilities for request/response processing to allow your webapp to execute actions across the network
concurrently and Mule manage the collating the results before returning a response.
You can invoke Mule components from Jsp pages or servlets using the Mule Client http://mule.mulesource.org/wiki/display/MULE/Mule+Client or you can use the
REST interface by using the Servlet transport providerhttp://mule.mulesource.org/wiki/display/MULE/Servlet+Provider.
Do we need another framework?
We think so. We know there are a lot of other very good frameworks out there, so why do we need
another one? When Mule was conceptualised it was designed to be a lightweight ESB framework. While
there are plenty of other lightweight frameworks, none of them were designed around ESB model. As you
might expect, there is a lot of crossover between existing frameworks, so rather than adding to this
overlapping of concerns Mule set about to leverage the best features of other frameworks by using those
frameworks in it's design. So Mule provides the wiring to use the features of other frameworks together
while adding features of it's own to make a very powerful ESB server. For example, you can use IoC
containers such as Spring, Plexus or PicoContainer or Jndi to construct your Mule application and even the
Mule server itself can be created from an IoC container.
Why is Mule called Mule?
Ross: "After working on a couple of bespoke ESB systems, I found that there was a lot of infrastructure
work to be done before you can really start thinking about implementing any logic. I regard this
infrastructure work as 'donkey work' as it needs doing for every project. I preferred Mule over Donkey
and Ass just didn't seem right . A Mule is also commonly referred to as a carrier of load, moving it
form one place to another. The load we specialise in moving is your enterprise information."
What do you mean by Light-weight and Event-driven?
Light-weight
You don't need a big server to run a mule instance, in fact it's memory and disk footprints are very small.
One example of this was a custom application configured to run over 8 machines that had to process
hundreds of thousands of events. With Mule they could run a respectable demo of the whole system on
an outdated laptop.
Event-driven
This simply means that all data transitions in Mule are treated as events, and that information entering
the system, say from a customer request over the web, are events.
How does Mule provide Scalability?
Scalability is the ease by which the application can be altered in response to higher demands on the
application.
Mule uses the SEDA http://mule.mulesource.org/wiki/display/MULE/Servlet+Provider processing model to increase the performance and throughput of events. Mule allows
pooling of UMO objects and Providers to allow multiple threads to process events concurrently.
How does Mule enforce decoupling?
Decoupling refers to having each component in system totally independent (and oblivious) to other
components in the system. The advantage of decoupled systems is that components can be added
enhanced or removed causing little or no disruption to other components. Decoupled systems built on
messaging are inherently fault tolerant due to the autonomous nature of the components and the fault
tolerance of the underlying message server, such as persistent queues, durable subscribers and
replication using load balancing.
Mule decouples your components from the complex infrastructure details of your application. Your
components can concentrate on core business functionality while Mule handles all the details of
transforming, routing and delivering business data around your application.
What is an UMO component?
Any object can be registered with the mule server as a UMO component such as Beans, EJBs, MBeans,
Servlets, JoesComponents or POJOs. The only 'sort of' requirement that mule needs is a public method on
the object to pass events. This method is dynamically resolved at runtime depending on the type of event
received and any transformers configured for the event.
What is zero code intrusion?
Mule does not impose any restrictions or preconditions on the objects you wish Mule to manage. Mule
uses discovery to determine which method should be executed when an event for the component is
received. The discovery method used can be overridden to change the way the event method is resolved.
What are Endpoints, Connectors and Transformers?
Endpoints enable connections to external systems or other components in Mule. These provide an
instance of a transport channel between external systems into Mule and vice versa. Providers can be
registered for a UMO so that it can send and/or receive information from the external system without
ever knowing about the system, the format of the data it expects or the transport mechanism used to
communicate with it.
Connectors actually do the logic of sending and receiving to an external system. And transformers are
used to convert data to and from formats expected by the different external systems. The conversion is
usually trivial such as creating a javax.mail message from a message payload on properties for from, to
and subject fields.
For more information about Using Mule and Mule components please see the User Guide
http://mule.mulesource.org/wiki/display/MULE/User+Guide.
Where do I go to learn more?
This document provides an overview of some of the aims and features of Mule. To find out more have a
look at -
Introduction - http://mule.mulesource.org/wiki/display/MULE/Introduction.
introduces the core concepts of Mule and how to get started.
User Guide - http://mule.mulesource.org/wiki/display/MULE/User+Guide covers all areas of Mule including usage, configuration and support for other frameworks
and applications.
Architecture Guide - http://mule.mulesource.org/wiki/display/MULE/Architecture+Guide
provides a reference to workings of the Mule Server describing the features of
each element in the system.
Mailing Lists Archives http://archive.mule.codehaus.org/
a good place to find answers to previously asked questions
How can I ask questions about Mule?
You can subscribe to one of the Mailing Lists and post your questions there. The User list http://mule.mulesource.org/wiki/display/MULE/Home is suitable for
most people.
Also, you can catch the Mule developers and users on the Mule IRC Channel http://mule.mulesource.org/wiki/display/MULE/IRC . Pop in and say hello.
I found a bug, what do I do?
If you find a bug you can report it on the Mule issue tracker. You will need to sign in as a new user so
that you can create issues. Please include as much information as possible when creating the issue. If you
fix the bug yourself you can include a cvs patch or zip of the code and include that in the issue.
Once you have created the issue it will get published to the Mule Developer list, so there is no need to
post it directly to the list as well.
I thought of this really cool feature, how can I get it added?
If you want a new feature in Mule you can either -
1. Write the code yourself and submit the code to the Mule Issue Tracker http://mule.mulesource.org/wiki/display/MULE/Home (and I'll buy you a beer next
time I'm in your neck of the woods ).
2. you can post the idea on the Mailing Lists and also log it on the Mule Issue Tracker http://mule.mulesource.org/wiki/display/MULE/Home . This will kick off
a discussion of the idea and some one may pick it up and code it for you, or you can code it
yourself.
0 comments:
Post a Comment