The following glossary helps you understand MuleSoft terminology.
Many of Mule’s terms are the same as those in the popular Enterprise Integration Patterns book. The book describes the problems Mule solves and documents many of the patterns used in the Mule framework.
(See also <[Mule Agent] and [Runtime Manager Agent]) 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 [Runtime Manager] and has the same lifecycle as the Mule instance, so you can initialize and destroy resources when the Mule instance starts or stops.
Complete repository for connectors, templates, examples and RAML APIs. Discover and use proven assets built by the MuleSoft ecosystem. Or, add assets to a private tenant of Anypoint Exchange for collaboration and sharing of internal best practices. For more information, see Anypoint Exchange (site) and Anypoint Exchange documentation.
An integrated development environment with visual and XML editors to design, debug and test Mule applications. Using the visual interface, you can drag and drop connectors, loggers, decision items, data transformers, and much more to the design canvas. Navigate the interface to debug and test. For more information, see Anypoint Studio Essentials or download from Anypoint Studio.
May refer to both the entire suite of products offered by MuleSoft as a cohesive solution to connectivity challenges, and to the Anypoint Platform Portal where a number of solutions are available as web applications.
Renamed to [Anypoint Platform Private Cloud Edition].
A special packaging of the Anypoint Platform is available for running on your own local servers. Formerly known as Anypoint Platform Private Cloud Edition. By using this, you can keep your entire infrastructure within your own private network. This implementation runs on Docker and Kubernetes, and is also compatible with Pivotal Cloud Foundry. The packaging includes versions of Runtime Manager, API Manager and Exchange.
Web-based graphical environment for designing, documenting, and testing APIs (see Design an API in API Designer)
Part of the Anypoint Platform that allows you to design and manage your APIs. It includes the [API Designer], which allows you to write a [RAML] definition of your API. It also includes tools to monitor usage metrics, apply [policies] and to expose interactive documentation through an [API Portal]
An access point where you can present a designed API to attract users. API Portal
A declarative toolkit that facilitates REST or SOAP API development. It handles error conditions and sets status codes, and generates flows for RESTful calls or SOAP API requests. For more information, see APIkit Basic Anatomy.
Any program that sends data through Mule. An application can be a web application, back office system, application server, or another Mule instance.
See Anypoint Runtime Manager.
Introduced in Mule 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.
A self-contained component that allows you to integrate Mule applications with the APIs of other, external applications, such as SalesForce, CMIS, and Twitter.
Integration platform as a service that lets you manage applications in the cloud. When deploying an application to the cloud through the Runtime Manager console, CloudHub is used in the background. For more information, see the CloudHub documentation.
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. You can manage cluster instances from the cloud.
A POJO, Spring bean, Java bean, or a script such as Groovy, Ruby, Python, or JavaScript that contains the business logic for processing messages passing through Mule. These components typically take the whole message - or just the payload - as input. They return an object that becomes the message payload for the next element in the message processor chain.
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. For information about supported connectors, see Anypoint Exchange.
A deprecated component that can map input fields to ouptut fields via an easy drag and drop interface. In the most recent releases this functionality is carried out by DataWeave.
A feature of Anypoint Studio that uses message metadata to facilitate application design. With this functionality, Anypoint Studio proactively acquires information such as data type and structure, in order to prescribe how to accurately map or use this data in your application. See DataSense.
The DataWeave Language is a simple, powerful tool used to query and transform data inside of Mule. It can be implemented to graphically map fields by dragging one attribute to another, just like you were able to with the now deprecated DataMapper, or leverage its powerful object-oriented language that’s specially designed to make writing transformations quick, without compromising maintainability. See DataWeave.
A channel for receiving or sending data. An endpoint has a specific protocol, such as Jetty 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.
A message indicating that something has happened within a flow or transaction. Events map to message processors and endpoints.
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.
A simple yet flexible mechanism that enables you to orchestrate message services through Mule. 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 any number of building blocks into a single, repeatable process.
Deploying a Mule Application via the cloud console of the [Runtime Manager] to an on-premises server that runs a [Mule Runtime]. This modality is hybrid in the sense that the hosting of your application is on-premises, whilst the managing of it is in the cloud. See Deployment Strategies for a better understanding of this and other modalities of deployment.
A building block in service orchestration that determines how a service component receives messages. The inbound router includes an endpoint that indicates from where the messages 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.
The part of the API that defines the data to which end users have access, and specifies the actions against the data you wish to make available through your API (GET, PUT, etc.). In essence, an interface is the mediator between a service exposed to the world, and the internal assets that need to be exposed. An interface designates the resources that either contain or access the data assets.
[Mule Expression Language] (MEL).
[message exchange pattern] (MEP).
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.
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 and the potential responses to the message request.
Mule 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.
message filter
A message processor that is used to control whether a message is processed by a filter. See also Message Filter.
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 ([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.
See [Mule Runtime].
The open-source version of Mule, available for free. 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 to 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.
A lightweight, Mule-specific expression language that you can use to access and evaluate the data in the payload, properties and variables of a Mule message. See Mule Expression Language (MEL), Mule Expression Language Examples, and Mule Expression Language Reference.
(Obsolete) In Mule Enterprise Edition, a tool that managed 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 2.2.2 Enterprise Edition by the management console.
Introduced in the Mule 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.
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.
Data that passes through an application via one or more flows. A Mule message consists of two main parts:
-
The message header, which contains metadata about the message
-
The message payload, which contains your business-specific data.
A Mule message is embedded within a Mule message object. Some Mule message objects may contain variables, attachments, and exception payloads. However, as attachments and exception payloads are not frequently used or manipulated, this overview document does not include details about them. See Mule Message Structure.
A service container that hosts the service components and manages their runtime behavior.
Java-based integration runtime engine of MuleSoft’s Anypoint Platform that uses a staged event-driven architecture (SEDA) to enqueue messages and process them inside of flows in separate stages. Mule is commonly known as Mule runtime or simply Mule. Mule is used to integrate systems and applications, old and new, and is built to scale.
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 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 dispatches 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.
A cloud computing platform as a service (PaaS) provided by a company named Pivotal. The Anypoint Platform integrates with Pivotal Cloud Foundry, allowing you to deploy Mule applications to dynamically created virtual machines on your own private network. See deployment strategies.
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.
Through [API Manager] you can easily apply runtime policies on your APIs. These execute common operations such as rate-throttling or authentication on the requests or the responses of your API. API Manager allows you both to enable one of a set of predefined policies through the UI, or to create your own custom policy. See Applying Runtime Policies for a deeper understanding.
A structure that Mule uses to store objects during asynchronous message processing. By default, Mule uses SEDA queues for services and VM transports. 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.
RESTful API Modeling Language (RAML) provides a specification language that you can use to define an API. For more information, see http://raml.org//
Introduced in Mule 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.
In APIkit, this is the interface part of the API that defines the data to which end users have access, and specifies the actions against the data you wish to make available through your API (GET, PUT, etc.).
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.
The Runtime Manager (also referred to as Anypoint Runtime Manager or "ARM") is one of the main features of the Anypoint Platform. It is the console that allows you to deploy and manage applications built with any Mule runtime, both to servers in the cloud (currently handled by CloudHub) and on premises. This console can be accessed as a web application through anypoint.mulesoft.com or you can download it as a standalone program to run in a local server.
The Runtime Manager Agent is an [Agent] that mediates the communication between the [Runtime Manager] console and the [Mule Runtime] instances running on servers. See Runtime Manager Agent.
The RuntMule agent is a plugin extension for Mule that exposes the Mule API. Using the Mule agent, you can monitor and control your Mule servers by calling APIs from external systems, and/or have Mule publish its own data to external systems. The agent has many features, such as controlling applications, domains, and services, listing, and deploying domains and applications, and publishing Mule metrics. For more information, see Runtime Manager Agent documentation.
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 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 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. All of these transformations can also be carried out by DataWeave.
A construct that handles and carries messages on a specific messaging protocol, such as FTP. Several connectors are built upon a Transport.
See transport.
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 does not prevent messages from being delivered to service components. See also interceptor and see Wire Tap.
YAML is a popular language for creating configuration files, as it’s easy to read and edit. Several Mule products expose files in this format. YAML is also the inspiration for [RAML]. See this wikipedia article about YAML.