|Did you know . . .|
MuleSoft has released Studio GA, a powerful new interface for Mule ESB that can cut your development time by half or more. You can model, debug, and deploy your applications all within the rich, yet flexible Studio environment.
Studio provides two-way (i.e., graphical and code-based) editing, which means that developers no longer have to trade ease-of-use against fine-grained control over their development projects. Any changes you make in one mode appear instantly in the other.
Mule Enterprise and Mule iON developers can fine-tune their applications in the advanced Studio XML editor, then re-deploy them on whichever version of Mule those applications were originally developed.
Studio installation is almost instantaneous, and a pair of tutorials can get you up and running in less than 40 minutes.
Let’s get Kicking!
Following are the terms you'll see as you work with Mule ESB. Because of the dynamic open-source history of Mule, there are sometimes multiple terms used to describe the same thing. This glossary lists all terms but refers to the preferred term when there are synonyms.
Many of Mule's terms are the same as those in the popular Enterprise Integration Patterns book. The book describes the problems Mule aims to solve and documents many of the patterns used in the Mule framework.
A service, such as the Mule JMX agent, that is used by or associated with Mule but is not a Mule-managed service component. An agent is registered with the Mule Manager and has the same lifecycle as the Mule instance, so you can initialize and destroy resources when the Mule instance starts or stops.
Any program that sends data through Mule. An application can be a web application, back office system, application server, or another Mule instance.
Introduced in Mule ESB 3.2 Enterprise Edition, the Business Event Analyzer provides functionality that gives visibility into business transactions and events on Mule servers. The Business Event Analyzer functions are available through the management console's Business Events tab.
A means to "catch" any messages that are not handled by any of the configured routers. A catch-all strategy is invoked if no routing path can be found for the current message. An inbound or outbound endpoint can be associated with a catch-all strategy so that any orphaned messages can be routed to a common location.
An outbound router that can be used to send a message through multiple endpoints using the result of the first invocation as the input for the next. This can be useful where you want to send the results of a synchronous request-response invocation such as a web service call to a JMS queue. The chaining router sends a synchronous message to the first endpoint and waits for a reply. The reply is then routed to the second endpoint.
A logical pathway in which messages are sent in a messaging framework. Channels connect services together as well as different Mule nodes across a local network or the Internet. A transport sends messages on a specific channel. See also Message Channel at http://www.eaipatterns.com/MessageChannel.html.
See cloud connector
A self-contained component that allows you to integrate Mule applications with the APIs of other, external applications, such as SalesForce, CMIS, and Twitter.
Introduced in Mule ESB 3.2 Enterprise Edition, a cluster is a set of Mule instances that acts as, and can be managed as, a unit. A cluster is a virtual server composed of multiple nodes.
Components can do one of the following:
- implement a Callable interface
- use annotations to express how a component method gets called
- rely on Mule's runtime injection mechanism
These components are managed in the Mule container that is built on top of Spring; this allows Spring users to take advantage of Spring's DI, AOP, DAO, etc.
See also: service component.
A class that knows how to parse a given configuration file. The default configuration builder is the org.mule.config.MuleXmlConfigurationBuilder class that knows how to parse a Mule XML configuration file.
A concrete instance of a Mule transport, whose properties describe how that transport is used. A connector maintains the configuration and state for the transport. All Mule endpoints that use a connector with its same transport inherit the connector's properties.
See management console.
A channel for receiving or sending data. An endpoint has a specific protocol, such as HTTP or JMS, and a set of elements for configuring filters, transactions, transformations, and more. There are two types of endpoints: inbound or outbound. An inbound endpoint receives data and allows a flow to be called by an external client. Conversely, an outbound endpoint is used to publish or send data to a service, application, or resource. The endpoint is configured in an inbound or outbound router. Endpoints can also be defined globally instead of in a specific router. See also Message Endpoint at http://www.eaipatterns.com/MessageEndpoint.html.
An architecture that allows different applications to communicate with each other by acting as a transit system for carrying data between applications within or outside your intranet. An ESB provides transaction management, routing, security, and other functionality for the messages.
See Mule expression.
A building block in service orchestration that determines which messages are routed to a service component. You can set filters on an inbound router to filter which messages that service component can receive, or you can set filters on an outbound router to indicate how you want to route messages after they have been processed by the service component. See also Message Filter.
Introduced in Mule 3.0, a flow is a simple yet flexible mechanism that enables you to orchestrate message services through Mule ESB. In contrast to the use of services, which define a component with explicit inbound and outbound phases that allow a limited amount of flexibility, a flow does not define anything and is completely free-form. A flow enables you to define n number of building blocks into a single, repeatable process.
See Mule Galaxy.
See Mule HQ.
A building block in service orchestration that determines how a service component will receive messages. The inbound router includes an endpoint that indicates from where the messages will come.
A building block in service orchestration that is used to intercept message flow into a service component. An interceptor can be used to trigger or monitor events or interrupt the flow of the message.
Introduced in Mule ESB 2.2.2 Enterprise Edition, the management console is a monitoring and management system that provides information about the hardware, services, and applications in your enterprise, including CPU usage and information about disks and network devices. The management console provides remote management, monitoring, patching, and alerts for all the assets in your infrastructure, including clusters. You can integrate the YourKit profiler with the management console to provide a more detailed level of information, showing memory usage all the way to the object level. The management console and YourKit profiler are included with the enterprise version of Mule ESB.
A packet of data that can be handled and sent between applications on a specific channel. Data is always wrapped in a message before it is transported by Mule. A message has a header, which contains metadata about the message (such as the sender information), and the body, which contains the actual data. See also Message at http://www.eaipatterns.com/Message.html.
A Java class used by a connector to receive the messages and routing instructions from an outbound router and send the message to the next service component. See also Message Dispatcher at http://www.eaipatterns.com/MessageDispatcher.html.
A well-defined interaction pattern that describes how a message request is handled in Mule ESB and the potential responses to the message request. Mule ESB supports various messaging styles such as synchronous or request-response, each of which has one or more corresponding message exchange patterns. For example, in the request-response messaging style the exchange pattern can be "in-out". In this pattern, the flow or service component receives a message from an inbound endpoint, processes or operates on the message payload, and finishes by delivering the message payload to an outbound endpoint. By contrast, the messaging exchange pattern for the one-way messaging style is "in-only", meaning that after the flow or service component receives a message from an inbound endpoint it puts it on a SEDA queue for further processing. However, nothing gets returned in response to the initial request. See also Message Exchange Patterns in Mule.
A basic building block used to construct flows. A message processor controls how messages are sent and received within a flow. Message Processors can be categorized by function, such as those that perform some logic (see service component), those that transform messages (see transformer), and those that filter messages (see filter).
A Java class used by a connector to read the incoming data, package it as a message, and passes it to a service component's inbound router. The message receiver can use a transformer if necessary to convert the data.
The open-source version of Mule, available for [free download]. As its name suggest, the Community Edition is developed, tested, and maintained by the community.
The enterprise version of Mule, available for 30-day trial download. The Enterprise Edition includes full development cycles, testing, technical support, maintenance releases and hot fixes, and management and monitoring tools from MuleSoft. If you are deploying Mule in a mission-critical environment, want to ensure that you always have a stable, high-quality release, and want additional tools for managing and monitoring your deployment, you should purchase a subscription of Mule Enterprise Edition.
A construct in Mule that allows you to extract information from the current message or determine how to handle the message. Expressions are very useful with routers and filters for defining routing logic and for filtering out unwanted messages. Mule expressions are also useful for querying request and response payloads and headers.
In Mule 1.x and Mule 2.x, provides Mule Service registry functionality.
In Mule ESB Enterprise Edition, a tool that manages Mule deployments as well as disparate systems and services in an SOA infrastructure. Mule HQ provides integrated log, configuration, server event tracking, and profiling. Obsoleted in Mule ESB 2.2.2 Enterprise Edition by the management console.
See management console.
The primary component for each instance of a Mule server. The Mule Manager manages Mule objects, including connectors, endpoints, and transformers. The Mule Manager constructs these objects and provides them to the service components in the Mule model. Each Mule instance has one Mule Manager and one or more Mule models.
A service container that hosts the service components and manages their runtime behavior.
A service-oriented architecture governance platform that allows you to control your infrastructure with SOA governance, registry, and repository features including lifecycle, dependency, and artifact management, as well as auto-discovery or services and reporting. The enterprise version of Mule ESB includes a service deployment repository, which allows for easy deployment and migration of services throughout an environment.
A Java class that you configure in the Mule configuration file to determine how a service component will dispatch messages. The outbound router can include an endpoint to indicate where the messages should go next, or if no endpoint is configured, it returns the completed message back to the sender.
An acronym for "plain old Java object," a POJO is a simple Java object, not an enterprise JavaBean. One advantage of Mule is that your service components can be simple POJOs, which Mule then wraps and exposes as services.
A structure that Mule uses to store objects during asynchronous message processing. By default, Mule uses SEDA queues for services and VM transports. In Mule ESB 3.2 Enterprise Edition, SEDA queues are also used for flows configured with the queued-asynchronous processing strategy. SEDA queues enable Mule to decouple the receiver of a message from the other steps in processing the message. These queues enable asynchronous processing in Mule because once a receiver places a message into a SEDA queue, it can immediately return and accept a new incoming message. See also channel.
Introduced in Mule ESB 3.2, a reliability pattern is a design that results in reliable messaging for an application even if the application receives messages from a non-transactional transport such as HTTP. A reliability pattern couples a reliable acquisition flow with an application logic flow. The reliable acquisition flow delivers a message reliably from an inbound endpoint, which uses a non-transactional transport, to an outbound endpoint, which can be any type of transactional endpoint such as VM or JMS. The application logic flow delivers the message from the inbound endpoint (which uses a transactional transport) to the business logic for the application.
A building block in service orchestration that determines where and how messages are transported between applications. See also inbound router, outbound router, and Message Router at http://www.eaipatterns.com/MessageRouter.html.
A POJO, Spring bean, Java bean, or web service that contains the business logic for processing data in a specific way. Mule simply manages the service component, bundles it with configuration settings and exposes it as a service, and ensures that the right information is passed to and from it based on the settings you specified for the service in the Mule configuration file. In early versions of Mule, service components were called Universal Message Objects, and "UMO" is still part of the nomenclature in the Mule APIs today.
The coordination of a message from a message source to its destination. Mule ESB performs service orchestration through flows.
An architecture model where applications consist of a network of event-driven stages connected by explicit queues. This architecture allows services to be well-conditioned to load, preventing resources from being overcommitted when demand exceeds service capacity. As a result, SEDA provides an efficient event-based queuing model that maximizes performance and throughput. SEDA is the default processing model in Mule.
A message exchange that must succeed or fail as a complete unit – it cannot remain in an intermediate state. Mule ESB supports JDBC transactions, XA transactions, and JMS transactions or message acknowledgments. Transactions are configured on endpoints.
A building block in service orchestration that transforms message payloads (data) to and from different types. See also Message Translator at http://www.eaipatterns.com/MessageTranslator.html.
A construct that handles and carries messages on a specific messaging protocol, such as HTTP.
See service component.
A router that makes copies of messages and forwards them to another endpoint. It can either forward a copy of all messages that it receives or it can be configured to use a filter and send a subset of these messages only. This router will not prevent messages from being delivered to service components. See also interceptor and see Wire Tap at http://www.eaipatterns.com/WireTap.html.
A transaction that enlists multiple managed resources and provides guaranteed reliability. Mule also supports multi-resource transactions that are not XA transactions. These transactions do not have guaranteed reliability.
|<< Previous: Basic Usage||Next: Compatible Technologies >>|