What is Mule ?
Mule is a lightweight event-driven enterprise service bus (ESB) and an integration platform. It is a lightweight and modular solution that could scale from an application-level messaging framework to an enterprise-wide highly distributable object broker.
What difficulties Mule does encompass ?
Transport — applications can accept input from a variety of means, from the file system to the network.
Data format — speaking the right protocol is only part of the solution, as applications can use almost any form of representation for the data they exchange.
Invocation styles — synchronous, asynchronous, or batch call semantics entail very different integration strategies.
Lifecycles — applications of different origins that serve varied purposes tend to have disparate development, maintenance, and operational lifecycles.
Why Mule was designed ?
Mule’s core was designed as an event-driven framework combined with a unified representation of messages, expandable with pluggable modules. These modules would provide support for a wide range of transports or add extra features, such as distributed transactions, security, or management. Mule was also designed as a programmatic framework offering programmers the means to graft additional behavior such as specific message processing or custom data transformation.
Why the name Mule ?
There is a lot of infrastructure work to be done before we can really start thinking about implementing any logic. So this infrastructure work is regarded as “donkey work” as it needs doing for every project. A Mule is also commonly referred to as a carrier of load, moving it from one place to another. The load it specializes in moving is our enterprise information.
What are available ESBs apart from Mule ?
All major JEE vendors (BEA, IBM, Oracle, Sun) have an ESB in their catalog. It is unremarkably based on their middleware technologies and is usually at the core of a much broader SOA product suite. There are also some commercial ESBs that have been built by vendors not in the field of JEE application servers, like the ones from Progress Software, IONA Technologies, and Software AG.
What are differences between Mule and other commercial ESBs ?
Prescriptive deployment model, whereas Mule supports a wide variety of deployment strategies.
Prescriptive SOA methodology, whereas Mule can embrace the architectural style and SOA practices in place where it is deployed.
Mainly focused on higher-level concerns, whereas Mule deals extensively with all the details of integration.
Strict full-stack web service orientation, whereas Mule’s capacities as an integration framework open it to all sorts of other protocols.
Comprehensive documentation, a subject on which MuleSource has made huge progress recently.
What is model layer in Mule ?
The first logical layer is the model layer. A Mule model represents the runtime environment that hosts services. It defines the behavior of Mule when processing requests handled by services. The model provides services with supporting features, such as exception strategies. It also provides services with default values that simplify their configuration.
What is service layer in Mule ?
A Mule service is composed of all the Mule entities involved in processing particular requests in predefined manners.A service is defined by a specific configuration. This configuration determines the different elements, from the different layers of responsibility, that will be mobilized to process the requests that it will be open to receive. Depending on the type of input channel it uses, a service may or may not be publicly accessible outside of the ESB.
What is transport layer in Mule ?
The transport layer is in charge of receiving or sending messages. This is why it is involved with both inbound and outbound communications. A transport manifests itself in the configuration by the following elements: connectors, endpoints and transformers.
A transport also defines one message adapter. A message adapter is responsible for extracting all the information available in a particular request (data, meta information, attachments, and so on) and storing them in transport-agnostic fashion in a Mule message.
What is connector in Mule ?
A connector is in charge of controlling the usage of a particular protocol. It is configured with parameters that are specific to this protocol and holds any state that can be shared with the underlying entities in charge of the actual communications.
For example, a JMS connector is configured with a Connection, which is shared by the different entities in charge of the actual communication.
What is endpoint in Mule ?
An endpoint represents the specific usage of a protocol, whether it is for listening/polling, reading from, or writing to a particular target destination. Hence it controls what underlying entities will be used with the connector they depend on. The target destination itself is defined as a URI. Depending on the connector, the URI will bear a different meaning; for example, it can represent a URL or a JMS destination.
What is transformer in Mule ?
A transformer takes care of translating the content of a message from one form to another. It is possible to chain transformers to cumulate their effects. Transformers can kick in at different stages while a message transits through a service.
What is router in Mule ?
Routers play a crucial role in controlling the trajectory a message will follow when it transits in Mule. They are the gatekeepers of the endpoints of a service, taking care of keeping messages on the right succession of tracks so they can reach their intended destinations. Certain routers act like the big classification yards: they can split, sort, or regroup messages based on certain conditions.
What is filter in Mule ?
Filters are a powerful complement to the routers. Filters provide the brains routers need to make smart decisions about what to do with messages in transit. Some filters go as far as deeply analyzing the content of a message for a particular value on which their outcome will be based.
What is component in Mule ?
Components are the centerpiece of Mule’s services. Each service is organized with a component at its core and inbound and outbound routers around it. Components are used to implement a specific behavior in a service. This behavior can be as simple as logging messages or can go as far as invoking other services. Components can also have no behavior at all; in that case they are pass-through and make the service act as a bridge between its inbound and outbound routers.