Mule ESB 3 Concepts

1. Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1 Mule ESB 3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 How Mule Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 About Mule Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.3 Understanding the Mule Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1.3.1 About SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.3.2 Mediation - Separating Business Logic from Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.3.3 Orchestration - Routing Messages Between Service Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.3.4 Components - Processing the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1.3.5 Endpoints - Wiring Everything Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1.3.6 Understanding the Logical Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.3.7 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1.4 Understanding Enterprise Integration Patterns Using Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.1.5 Understanding Orchestration Using Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.1.6 Understanding Configuration Patterns Using Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.1.7 Connecting with Transports and Cloud Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.1.8 Using Mule with Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Home

Introducing Mule ESB 3 ConceptsThis book explains important concepts necessary for you to understand when developing with Mule effectively.

Mule ESB 3 ConceptsHow Mule WorksAbout Mule ConfigurationUnderstanding the Mule Architecture

About SOAMediation - Separating Business Logic from MessagingOrchestration - Routing Messages Between Service ComponentsComponents - Processing the DataEndpoints - Wiring Everything TogetherUnderstanding the Logical Data FlowPolicy Enforcement

Understanding Enterprise Integration Patterns Using MuleUnderstanding Orchestration Using MuleUnderstanding Configuration Patterns Using MuleConnecting with Transports and Cloud ConnectorsUsing Mule with Web Services

Mule ESB 3 Concepts

Introducing Mule ESB 3 Concepts

This book explains important concepts necessary for you to understand when developing with Mule effectively.

How Mule WorksAbout Mule ConfigurationUnderstanding the Mule Architecture

About SOAMediation - Separating Business Logic from MessagingOrchestration - Routing Messages Between Service ComponentsComponents - Processing the DataEndpoints - Wiring Everything TogetherUnderstanding the Logical Data FlowPolicy Enforcement

Understanding Enterprise Integration Patterns Using MuleUnderstanding Orchestration Using MuleUnderstanding Configuration Patterns Using MuleConnecting with Transports and Cloud ConnectorsUsing Mule with Web Services

How Mule Works

How Mule Works

When you examine how a message flows through Mule ESB, you can see that there are three layers in the architecture: the application layer, theintegration layer, and the transport layer.

Likewise, there are three general types of tasks you can perform to configure and customize your Mule deployment:

Service Component Development: developing or reuse existing POJOs, services, Cloud Connectors, or Spring beans that contain thebusiness logic and will consume, process, or enrich messages.Service Orchestration: configuring message processors, routers, transformers, and filters that provide the service mediation andorchestration capabilities required to allow composition of loosely coupled services using a Mule Flow. New orchestration elements canalso be created and dropped into your deployment.Integration: A key requirement of service mediation is decoupling services from the underlying protocols. Mule provides transports toallow dispatching and receiving messages on different protocol connectors. These connectors are configured in the Mule configurationand then can be referenced from the orchestration layer. Mule supports many existing transports and all the popular communicationprotocols, but you may also develop a custom transport if you need to extend Mule to support a particular legacy or proprietary system.

This page provides a high-level overview of the steps you take to perform these tasks.

Create a Service Component

A service component is a class, web service, or other application that contains the business logic you want to plug in to the Mule service bus. Youcan use any existing Java class, Spring bean, Groovy script, a Cloud Connector, or . Your service component does notcreate a new componentneed to contain any Mule-specific code. All the Mule-specific instructions will be configured on the service that wraps the service component.

To assist development, you can use the , which works within Eclipse to provide an integrated development environment for developingMule IDEMule applications.

Configure the Mule Instance

The Mule configuration file allows you to configure all the elements you need in your Mule instance. You use the element to<configuration>set global configuration options such as the threading profile. You then define the connectors, transformers, and endpoints you'll use in differentflows. Lastly, you configure flows or service models, which act as containers for services and orchestration elements and apply settings such asthe queue profile and error handling to all the services in that flow or service model. For complete information, see .Configuring a Mule Instance

Configure the Flow

You configure a flow using the element in the Mule configuration file. The flow creates a composition around the service component(s)<flow>that allows you to define how messaged are routed, filtered, transformed and enriched before or after processing by one or a series of servicecomponents. Flows are more flexible and robust than the traditional service model in Mule, allowing a more natural and compact means ofdescribing service orchestration. For more information, see .Flows

Mule provides an even more compact notation for commonly used patterns called .Configuration Patterns

Configure the Service

You may also configure a service within a element in the Mule configuration file. The service points to the service component, routers,<model>filters, and transformers. It also specifies the endpoint on which this service will receive messages and the outbound endpoint where messageswill go next. For more information, see .Configuring the Service

Following is more information on configuring message processors, routers, filters, and transformers for the service.

Message Processors

Message Processors are the basic in Mule and in fact, components, routers, filters, and transformers are all message processors.building blockThere are also other special message processors that do not fall in one of those categories. These include a number of specialized modules likeCXF and Jersey Web Services, BPM, as well as a few specialized integration elements like , , and .<poll> <content-enricher> <logger>You can also easily create your own .custom message processor

Routers

Inbound routers specify how messages are routed to a service, and outbound routers specify how messages are routed after the service hasfinished processing them. There are several default routers that come with Mule that you can use, or you can create your own routers. For moreinformation, see .Using Message Routers

Filters

Filters specify conditions that must be met for a message to be routed to a service. There are several default filters that come with Mule that youcan use, or you can create your own filters. For more information, see .Using Filters

Transformers

Transformers convert incoming payload data to the type required by the service component. After the service has finished processing themessage, they can also convert the message to a different type as needed by the outbound transport. There are several default transformers youcan use, or create your own. For more information, see .Using Transformers

Transports and Connectors

Mule provides for many different channels, including File, FTP, HTTP, JMS, JDBC, Quartz, and many more. Transportsdefault transportscommunicate with the channel using a connector. There are also many community-contributed transports and Cloud Connectors on .MuleForge

Cloud Connectors

Cloud Connectors are actually message processors that are used to speak to application APIs over existing transports - almost always HTTP.Cloud Connectors typically connect SaaS applications, social media, cloud infrastructure services, and cloud-based data services.

Extend Mule

Mule provides a complete set of APIs for extending Mule. Typical custom extensions include:

Cloud ConnectorsTransportsCustom Message ProcessorsCustom TransformersConfiguration Patterns

If you develop an extension to Mule that you think others might reuse or help support or improve, you could decide to share it on .MuleForge

In addition to the Mule IDE, you can also use Maven to create new Mule projects (transports and other types of modules). For more information,see .Using Maven

About Mule Configuration

About Mule Configuration[ ] [ ] [ ]Overview of a Mule Configuration Global Configuration Settings Accessing the Configuration Programmatically

This topic relates to the most recent version of Mule ESBTo see the corresponding topic in a previous version of Mule ESB, click here

Following is an introduction to configuring Mule ESB via the Spring XML file. For details on this file, see .About the XML Configuration File

Overview of a Mule Configuration

A Mule ESB configuration file is a tree, as shown in the following illustration:

Each of these elements provides access to configuration object within Mule:

Custom Message Processors - Observe a message, or modify either a message or the message flow. Examples include transformersand filters.Flows - Use message processors to define message flow between a source and a target.

MULE3USER:Mule Global Configuration - Global settings, such as the default transaction time-out, that apply to the entire MuleconfigurationConnectors - Non-default configuration of any transports usedEndpoints - Define the channel and address or path where messages are sent or received. You can define them globally and use them inmultiple flows.Transformers - Convert data from one format to another. You can define them globally and use them in multiple flows.Filters - Filter out the messages that don't match specific criteria. You can define them globally and use them in multiple flows.Models - One or more models that logically group together your services.Services - One or more services that wrap your components (business logic) and configure routers, endpoints, transformers, and filtersspecifically for that service

Following is an example of a simple Mule configuration file:

Simple Mule Configuration

<mule xmlns="http://www.mulesoft.org/schema/mule/core" =xmlns:xsi "http://www.w3.org/2001/XMLSchema-instance" =xmlns:vm "http://www.mulesoft.org/schema/mule/vm" xsi:schemaLocation=" http://www.mulesoft.org/schema/mule/corehttp://www.mulesoft.org/schema/mule/core/3.0/mule.xsd http://www.mulesoft.org/schema/mule/vmhttp://www.mulesoft.org/schema/mule/vm/3.0/mule-vm.xsd">

<vm:connector name= queueTimeout= />"vmConnector" "5000"

<vm:endpoint name= path= />"CustomerRequests" "customer.requests" <vm:endpoint name= path= />"CustomerResponses" "customer.responses"

<custom-transformer name= class= />"ThisToThat" "com.acme.transformer.ThisToThat"

<flow name= >"myBasicFlow" <inbound-endpoint ref= />"CustomerRequests" <component class= />"com.acme.service.BasicService" <outbound-endpoint ref= transformer-refs= />"CustomerResponses" "ThisToThat" </flow></mule>

Other, more advanced things you may configure at this level:

Security Manager - Authenticates requests based on one or more security providersAgents - Agents are typically used for cross-cutting concerns such as logging or managementNotifications - Allow you to be notified upon certain lifecycle eventsTransaction Management - Mule transactions are configured on inbound endpoints, where an endpoint can be configured to start a newtransaction or join an existing one.Properties - Property placeholders, message properties, and system properties.

Global Configuration Settings

You can configure global configuration settings such as the default transaction timeout and default threading profile in the <configuration>element. For example:

<mule>... <configuration defaultTransactionTimeout= >"31337" <default-threading-profile poolExhaustedAction= />"RUN"... </configuration>

For a list of the available global configuration settings, see .Global Settings Configuration Reference

Accessing the Configuration Programmatically

All Mule configuration is accessible from a single object: . Configurations in a MuleConfiguration are setorg.mule.api.config.MuleConfigurationwhen a is created. The object becomes immutable after it is started and can be accessed using the following:MuleContext

// implement MuleContextAware to have the reference injectedMuleConfiguration configuration = context.getConfiguration();

Understanding the Mule Architecture

Understanding the Mule Architecture

This section describes the different parts of the Mule ESB architecture and how they handle messages and their data. For the sake of illustration,it uses the example of a company that needs to generate invoices for customer orders, perform some processing on those invoices, and thensend them to the shipping department for order fulfillment.

This section includes the following topics:

About SOAMediation - Separating Business Logic from MessagingOrchestration - Routing Messages Between Service ComponentsComponents - Processing the DataEndpoints - Wiring Everything TogetherUnderstanding the Logical Data FlowPolicy Enforcement

About SOA

About SOA

Mule ESB is based on the concept of a (SOA). The SOA approach to development allows IT organizations toservice-oriented architecturecompose applications by building service interfaces around components of applications and exposing those to service consumers. areServicesdiscrete sets of functionality that are completely separate from each other but can work together on a canonical set of objects. For example, if youneed to process customer invoices, you might have one service that merges customer data from a database into the invoice and another servicethat checks the inventory database to see if the items on the invoice are in stock and a third service that fulfills the order.

Because each service stands alone, services can be used as building blocks for multiple processes and do not have to be recreated for each typeof process or message. For example, the service that merges customer data onto the invoice could also be used to merge customer data ontostatements, letters, or other documents. The logic that determines how the invoice data and customer data are merged is decoupled from thelogic that looks up and retrieves the necessary customer data. This modular approach allows you to create functionality once and re-use it asmany times as needed, streamlining development.

This decoupling is a key element of . Mediation is a well-known pattern for promoting loose coupling. In SOA, service mediationservice mediationalso describes the capabilities of the ESB to convert between transport protocols (including the ability to bridge between synchronous andasynchronous protocols), changing the representation of messages by transforming data, and enforcing compliance with policies by taking thenecessary steps such as auditing, logging, security monitoring, etc.

Constructing the building blocks into a logical process is called . Service orchestration using an ESB allows for automation oforchestrationcommon backend processes at the application service layer. These processes can be scheduled or exposed as services that are triggered byexternal events. Service orchestration differs from business process orchestration which may include longer running stateful business processes,complex human interactions and approvals, or parallel execution of those types of processes at the business service layer.

Using SOA, businesses can realize dramatic savings on development costs and can rapidly adapt to changing business conditions by reusing andreconfiguring existing services in developing new applications. SOA also enables better integration of enterprise IT resources, including previouslyisolated 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.

Mediation - Separating Business Logic from Messaging

Mediation - Separating Business Logic from Messaging

One of the many advantages of Mule ESB is that it can handle messages that are sent via a variety of protocols. For example, an invoice mightalways be in XML format, but it might arrive over HTTP in one situation and as a JMS message in another depending on which applicationcreated the invoice. If a component handles only business logic and works with the data, not the message itself, how does it know how to read thevarious formats in which the message might arrive?

The answer is that components don't know how to read the messages, because by default, components are completely shielded from the. Instead, a carries the message along, and change the message's payload (such as the invoice) asmessage format transport transformers

needed to a format the component can read before the flow passes the message to the service component. For example, if an XML invoice is

sent over HTTP, the HTTP transport turns it into a Mule message, transformers change it along the way (such as from XML to a Java object) asrequired, and the flow directs the message to each component that needs to process it. All the transporting, transforming, and routing of themessage are completely transparent to the component. This decoupling is .service mediation

Transformers are the key to exchanging data, as they allow Mule to convert the data to a format that another component or application canunderstand. Most importantly, . Instead of mandating the conversion of every message to a single commondata is transformed only as neededdata protocol (like XML) and specific message format, messages and their data are transformed only as needed for the target component orapplication where the message is being sent. Mule also enables content enrichment of messages through integration patterns that allow you toretrieve additional data during processing and attach it to the message.

Multiple types of transports can be enabled to handle different channels, such as sending the message over a synchronous HTTP endpoint andthen forwarding it as an asynchronous JMS message after it has been processed by the Customer Data component. This decoupling of thetransport layer allow services to be reused across the enterprise regardless of the legacy technology decisions that were made and enabledifferent choices in protocols to be made based on service level agreements or concerns around reliability or performance.

Mediation also means that policy compliance can be layered into the architecture outside of the services. Logging, auditing, and securitymonitoring can all be performed without any modification of the existing code. Policy enforcement can even be applied based on who is calling theservice or what routing has occurred.

The separation of the business logic from the sending and transformation of messages allows for great flexibility in how you set up yourarchitecture and makes it much simpler to customize the business logic without having to worry about the various formats in which a messagemight arrive. Your service component can work with the raw data of the message if desired, but it is not required.

Orchestration - Routing Messages Between Service Components

Orchestration - Routing Messages Between Components

The component contains business logic for processing the data in the message. It does not contain any information about how to receive or sendmessages themselves. To ensure that the component receives the right messages and routes them properly after processing, an orchestrationflow wraps the component (or components) with additional message processors that filter, transform, enhance or route the message to theappropriate component or endpoint. This allows the invocation sequence to be dynamically varied based on the context of the message or thecurrent load or availability of the system.

Processing data using gives you complete flexibility in where and how messages are transformed, filtered, and routed. Each is justMule Flowsanother step in the process. If you want to do any kind of sophisticated routing using Mule, it is recommended that you use the Flow pattern.

Mule make it easy to perform common bits of orchestration, for instance, bridging two endpoints. Using configurationconfiguration patternspatterns where possible simplifies the work required to configure Mule.

When business process orchestration is required, Mule provides a for enabling different BPM engines within Mule. Business processBPM moduleorchestration should be used for longer running stateful business processes, complex human interactions and approvals, or parallel execution ofthose types of processes at the business service layer rather than the application layer.

Components - Processing the Data

Components - Processing the Data

When a message is sent from an application (such as the invoice from an order entry system), Mule ESB picks up the message, sends it to aservice that processes it using some specific business logic (such as checking the customer and inventory databases), and then routes it to thecorrect application (such as the order fulfillment system). Mule contains many individual parts that handle the processing and routing of themessage. One key part is the . Components execute business logic on messages, such as reading the invoice object, addingcomponentinformation to it from the customer database, and then forwarding it to the order fulfillment application.

An important feature of components is that they don't have to have any Mule-specific code; they can simply be POJOs, Spring beans, Javabeans, Groovy scripts, or web services containing the business logic for processing data in a specific way. Mule even supports a powerful type ofcomponent called a that can connect to any cloud-based service or application and process or enrich the message. CloudCloud Connectorconnectors operate on Application APIs, typically exposed over web services.

Mule manages components for you, bundles them with configuration settings, exposes then as message processors, and ensures that the rightinformation is passed to and from them based on the settings you specified for their flows in the Mule configuration file.

Mule supports chaining multiple processing steps together through an orchestration mechanism called . Flows allow any number offlowcomponents to be chained together along with other forms of message processing. Flows allow Mule to orchestrate how and when a message isrouted to a component. Components can also be exposed directly as services using the Simple Service pattern or the Service Model.

You can have many different components that perform different business logic, such as one that verifies whether the items on the invoice are instock and one that updates a separate customer database with the order history. The invoice, which is encapsulated in a message, can flow fromone service component to the next until all the required processing is complete.

Endpoints - Wiring Everything Together

Endpoints - Wiring Everything Together

Endpoints are configuration elements that are the key to wiring together all the services. You specify endpoints in your flows to tell Mule ESBwhich transport to use, where to send messages, and which messages a component should receive. The primary part of an endpoint is theaddress which indicates the transport to use, the location (a transport-specific resource), and any additional parameters.

Addresses may be expressed as a Uniform Resource Identifier ( ) or as schema-specific XML configurationURI

For example, if a flow's inbound endpoint's address is , the HTTP transport will dispatch to that flow any messages thathttp://myfirm.com/mulehave been sent to that URL. If the inbound endpoint specifies , the File transport, which is watching that directory, dispatchesfile://myserver/files/any new files created in that directory to the flow.

Depending on the messaging style you specify, Mule may or may not generate a response to send back through the inbound endpoint to thesender. Mule supports several and each transport has a default pattern it will follow unless you specify otherwise.Message Exchange PatternsMule will typically return the final result of the message processing back as the result; however response processing can also be specified tocontrol what is returned.

An outbound endpoint can also be specified to indicate where the message will go next. For example, after processing an HTTP request, you maywant to place the result on a JMS queue as shown in the following illustration.

A flow can receive messages using many different transports. For each type of transport that a flow will use, you must specify one or moreseparate endpoints. For example, if you want one of your flows to handle messages coming in on both the HTTP and JMS channels, you wouldspecify at least one inbound HTTP endpoint and at least one inbound JMS endpoint. Mule registers these endpoints with the flow, and thetransport uses this registry information at runtime to configure itself and determine where to send and receive messages.

Mule also supports dynamic endpoints, allowing the destination to be constructed from the content of the message. This allows routing-slippatterns where the message instructs Mule where to route it.

The flow can also include filters that further specify which messages to send or receive. For example, you can specify that the component onlyreceives RSS messages by a specific author. Specifying filters, routers, and endpoints for your services simply requires editing an XMLconfiguration. You do not have to write any Java code. Some routers are also dynamic and can change behavior based on the content of themessage or an external data source such as a file or database. As stated previously, your components code remains completely separate frommessaging and routing, which you handle through Mule configuration.

1.

In summary, Mule provides a simple and lightweight way to write components that do something to data without needing to worry about thesender or recipient of the data, the format of the data, or the technology being used to send/receive the data. Although many brokering andintegration technologies offer the ability to connect to disparate data sources, they often require extra coding to get messages to behave the wayyou want and to deliver the data where you want it to go. Mule allows you to quickly develop service components and then change the way theybehave through simple XML configuration instead of writing Java code.

Understanding the Logical Data Flow

Understanding the Logical Data Flow

The previous sections introduced each of the parts of the Mule ESB instance from a conceptual view point. Now, using the invoice example again,let's take a look at how data flows logically through each part of a Mule instance. Throughout the process, Mule uses the Mule configuration file todetermine which components, routers, transports, and transformers to use along the way. The diagram that follows illustrates these steps.

The customer places an order on the company web site, and an invoice is created as an XML form and submitted to

1.

2.

3. 4. 5.

6.

7.

8. 9.

.http://myfirm.com/ordersThe HTTP transport receives the XML invoice and wraps it in a Mule message. The Customer Data flow's inbound endpoint is set to

,  so the HTTP transport dispatches the message to the service.http://myfirm.com/ordersThe XML to Object transformer converts the XML invoice into a Java object.The flow passes the message with its transformed payload to the Customer Data component.The Customer Data component queries the master customer database to pull additional data about the customer and updates the invoicewith the data.What follows in the flow is an HTTP outbound endpoint, so the HTTP transport determines that it must now dispatch the message to itsaddress, .http://myfirm.com/verifyThe HTTP transport uses the configuration of the Inventory Verification flow to receive the message and pass it to the InventoryVerification component.This component updates the invoice with an ID code of the warehouse that has all the items on the invoice in stock.The outbound endpoint specifies a JMS address, so the JMS transport dispatches the message to the order fulfillment application, whichpicks up orders on that address.

Policy Enforcement

Policy Enforcement

Mule provides capabilities to add audit, logging, and security enforcement at the ESB layer.

Examples

The following are examples of how to set and enforce policy in a Mule application.

Event Tracking

You can inspect all messages using a Wire Tap pattern. To inspect messages that travel on a point-to-point channel, insert a Recipient List intothe channel that publishes each incoming message to the main channel and a secondary channel.

The Wire Tap is a fixed Recipient List with two output channels. It consumes messages off the input channel and publishes the unmodifiedmessage to both output channels. To insert the Wire Tap into a channel, create an additional channel and change the destination receiver toconsume from the second channel. Because the analysis logic is located inside a second component, a generic Wire Tap can fit into any channelwithout any danger of modifying the primary channel behavior. This improves reuse and reduces the risk of instrumenting an existing solution.

The Notifications API

Mule's API includes the concept of notifications. ServerNotification is an event triggered by something happening in the server itself such as theserver starting or a service being registered. It is is the parent of a host of concrete notifications you can use in your Mule-aware Javaapplications:

ServerNotificationComponentMessageNotificationConnectionNotificationCustomNotificationEndpointMessageNotificationExceptionNotificationFlowConstructNotificationManagementNotificationMessageProcessorNotificationModelNotificationMuleContextNotificationRegistryNotificationRemoteDispatcherNotificationRoutingNotificationSecurityNotificationServiceNotificationTransactionNotification

Logging

Examining the Mule log is a way to understand what is happening as messages move through a Mule application. Mule's logging configuration isstored in ./conf/log4j.properties. Edit this file to change the verbosity of the log output.

The following code demonstrates how to log messages:

<flow name= >"FlowWithLoggers" <http:inbound-endpoint address= />"http://localhost:8383/flowlog" <log-component /> <base64-encoder-transformer/> <log-component /> <vm:outbound-endpoint path= />"next.in.line"</flow>

For more details, use a scripted logging component like the following:

<scripting:script name= engine= >"Logger" "groovy" log.info(message); log.info(payload); message<scripting:text> </scripting:text></scripting:script>

Security Enforcement

Security is an important part of policy. There are three elements of enforcing security in a Mule application--encryption/decryption transformers,security filters, and Mule's own security manager.

Encryption Transformers

When writing Java code that requires encryption, you use Mule's Java encryption transformers. Mule provides an abstract class calledAbstractEncryptionTransformer that will transform an array of bytes or string into an encrypted array of bytes once implemented. There are twoconcrete classes called DecryptionTransformer and EncryptionTransformer that will transform an encrypted array of bytes or string into andecrypted array of bytes, or will transform an array of bytes or string into an encrypted array of bytes.

Security Filters

Mule incorporates an abstract class for security filters, AbstractEndpointSecurityFilter, that you can implement to increase security of your Muleapplication. To implement this abstract class, authenticate inbound and outbound events, ensuring no anonymous or null users gain access, thenthrow the corresponding UnauthorisedException with a message.

Configuring Security

Mule ESB allows you to authenticate requests via endpoints using transport-specific or generic authentication methods. It also allows you tocontrol method-level authorization on your service components. The Security Manager is responsible for authenticating requests based on one ormore security providers. All security is pluggable via the , so you can easily plug in custom implementations.Mule security API

For information on the elements you can configure for the Security Manager, see . The followingSecurity Manager Configuration Referencesections provide links to information on configuring different types of security managers.

Spring Security

Spring Security is the next version of Acegi and provides a number of authentication and authorization providers such as JAAS, LDAP, CAS (YaleCentral Authentication service), and DAO. The following topics will help you get started securing your services using Spring Security:

Configuring the Spring Security ManagerComponent Authorization Using Spring SecuritySetting up LDAP Provider for Spring Security

Acegi Security (deprecated)

Acegi provides a number of authentication and authorization providers such as JAAS, LDAP, CAS (Yale Central Authentication service), andDAO. The following topics will help you get started securing your services using Acegi:

Configuring the Acegi Security ManagerComponent Authorization Using AcegiSetting up LDAP Provider for Acegi

NOTE: Acegi may not be supported in future versions of Mule.

WS-Security

WS-Security is a standard protocol for applying security to Web services. It contains specifications on how integrity and confidentiality in a SOAPmessage can be enforced via XML signatures and binary security tokens such as X.509 certificates and Kerberos tickets as well as encryption

headers. It ensures end-to-end security by working in the application layer as opposed to the transport layer.

Other Security Technologies

Mule also supports the following security technologies:

Encryption Strategies - Secure your messages by encrypting them.PGP Security - Secure your messages by encrypting them with PGP.Jaas Security

Understanding Enterprise Integration Patterns Using Mule

Understanding Enterprise Integration Patterns Using Mule

The Enterprise Integration Patterns are accepted solutions to recurring problems within a given context and they provide framework for designing,building messaging and integration systems as well as a common language for teams to use when architecting solutions.

Mule supports most of the Enterprise Integration Patterns from the by Gregor Hohpe and Bobby Woolf.book

The fact that Mule implements these patterns greatly reduces the effort required when building integrations. You can design your solution usingthese well-known patterns and then simply configure and use these same patterns in Mule.

Mapping Enterprise Integration Patterns into Mule Objects.

There is a list of patterns that can be mapped directly with Mule objects. Find the list of Enterprise Integration Patterns mapped to Mule objectsbelow:

Integration Styles

Pattern Mapping to a Mule Object

File Transfer File Transport

Shared Database JDBC Transport

Messaging Mule is all about Messaging

Messaging Systems

Pattern Mapping to a Mule Object

Message Channel Mule provides a message channel that connects the message processors in a flow.

Pipes and Filters A implements a pipe and filter architectureFlow

Message Router Message Routers

Message Translator Message Transformer

Message Endpoint Inbound & Outbound Endpoints

Messaging Channels

Pattern Mapping to a Mule Object

Point-to-Point Channel The default channel within a flow.

Message Bus Mule is a message bus.

Message Routing

Pattern Mapping to a Mule Object

Content-Based Router Choice

Message Filter Filters

Recipient List Recipient List

Splitter Collection Splitter, Message Chunk Splitter & Plain Splitter

Aggregator Collection Aggregator, Message Chunk Aggregator & Custom Aggregator

Resequencer Resequencer

Message transformation

Pattern Mapping to a Mule Object

Content Enricher Message Enricher

Messaging Endpoints

You can declare endpoints to be transactional as needed.

Pattern Mapping to a Mule Object

Idempotent Receiver Idempotent Message Filter

System Management

Pattern Mapping to a Mule Object

Wire Tap Wire Tap

Related Topics

Configuring Mule with Patterns

Understanding Orchestration Using Mule

Understanding Orchestration Using Mule

Orchestration is how Mule facilitates the process of moving data through a Mule implementation based on flow. Orchestration can be seen ascombining service calls to create higher-level, more useful composite services, and implies implementing business-level processes combiningbusiness-specific services across applications and information systems.

Orchestration and Flow

Orchestration involves decoupling point-to-point integration in favor of chains of messages sent to endpoints that can be reused or changed assystems or business needs change. It involves moving beyond patterns into a service-based framework, where you wrap multiple componentswith endpoints to decouple them from protocols and routing requirements, enabling multiple services to work as one when implementationrequirements demand it. Some common use cases that flow easily orchestrates include simple integration, scheduled data processing,connecting cloud and on-premise applications, and event processing where multiple services must be composed and operate simultaneously.

How Flow Enables Implementation of Orchestration

Flow enables new ways to orchestrate service mediation—for example, you can combine an arbitrary number of endpoints, routers, transformers,and components that work in concert to achieve implementation requirements. With previous versions of Mule, you accomplished a substitute fororchestration by chaining together multiple services using queues and/or a chaining router. Flow enables you to orchestrate new forms of datamovement based on flow-specific routers. Orchestration enables you to create and reuse subflows, chain together multiple components in oneflow, and integrate endpoints or cloud connectors anywhere in a flow.

When to Use Orchestration

You use orchestration when existing Enterprise Integration Patterns (EIPs) don’t seem to apply to implementing your solution, or when routersseem too confining or clumsy. There are only so many EIPs to use when implementing a solution, and you may find yourself in a position whenyou need to resort to more flexibility than patterns provide. You may also use orchestration when you wish to contain your flow subsystem to asingle location in the configuration file.

An Example of Orchestration

The following example of orchestration uses a flow to accept a book order in an XML file and transform the file’s contents into a standard formatthat contains one or more specific orders. Next, the orders are split out to be processed separately, and any non-book orders are filtered out. Nowtwo services are called: one to check whether the book is in our inventory, and another to create a customer order. This is both e-mailed to thecustomer and stored in a database. If anything in this process fails, the message is placed in a JMS queue of failed orders, where it can bechecked, any error fixed, and finally resubmitted.

<flow> <file:inbound-endpoint path= >"/myDirectory" <file:filename-filter name= />"*.xml" </file:inbound-endpoint> <xml:xslt-transformer xsl-file= />"createBbookOrdersTransformation.xsl" <splitter expression="xpath: />//order"<!-- The following message processors will be invoked each order in the xml file -->for <expression-filter expression="xpath: />//order[@type='book']"<component class= />"org.my.BookInventoryChecker" <component class= />"org.my.BookCustomerOrderProcessor" <smtp:outbound-endpoint subject= to="Order Confirmation" "#{xpath: />//customer/email]"<jdbc:outbound-endpoint queryKey= />"storeOrder" < -exception-strategy>default <jms:outbound-endpoint queue= />"failedOrders" </ -exception-strategy>default</flow>

Understanding Configuration Patterns Using Mule

Understanding Configuration Patterns Using Mule

Flows, Configuration Patterns, and Services

In Mule 3, you have three choices for creating a message-processing flow:

Flows, new in Mule 3, are the most powerful and flexible choice. You can choose from all of the message processors Mule provides,including filters, transformers, routers, components, and others, as well as creating your own, and combine them however you like toimplement exactly the logic you need.Services, which go back much further, are just as powerful, but far less flexible. Services have a structure that cannot be changed:

InboundComponentOutboundand anything that doesn't fit into that mold has to be decomposed into multiple services. For that reason, services, while fullysupported, are not recommended for new development.

Configuration patterns, which are, by design, not as powerful as either of the others. They have instead been designed for ease of use.The four configuration patterns that exist today make things that people do all the time simple, understandable, and fast to create.

In short, if one of the configuration patterns solves your problem, use it. It's like using a library class that solves a programming problem instead ofcoding a new one that duplicates it. If your problem doesn't match one of the configuration patterns, use a flow. If you have an existing serviceand need to modify or update it, consider converting it to a flow or configuration pattern. If you decide to keep it a service, there is nothing to worryabout. Services remain completely supported.

The Configuration Patterns:

There are currently four configuration patterns in Mule. All of them are in the pattern namespace.

Bridge

The bridge pattern is used to bridge an inbound and outbound endpoint. Here's an example that bridges an http and vm endpoint:

<pattern:bridge name="request-response-bridge" inboundAddress="http://localhost:8080/orderService" outboundAddress= />"jms://orderQueue"

This example illustrates the goal of minimal configuration: nothing needs to be configured except what is absolutely required. To learn more aboutthe capabilities of the bridge pattern, see ,Bridge Pattern

Simple Service

The simple service pattern is used to expose a component as a request-response service. Several types of components are supported:

POJOsJAX-WS servicesJAX-RS servicesJAXB and XPath processing components

Here's a simple example that, once again, shows minimal configuration, in this case to expose a POJO as a service:

<pattern:simple-service name="maths-service" address="vm://maths.in" component-class= />"org.mule.tck.services.SimpleMathsComponent"

To learn more about the capabilities of the simple service pattern, see ,Simple Service Pattern

Validator Pattern

The job of the Validator pattern is to ensure that a message is well-formed before sending it to be processed.  This pattern demonstrates not onlyminimal configuration but separation of concerns: different configuration objects are responsible for

Validating the inputDefining the positive and negative status messages returned to the callerDeclaring where well-formed messages are sent.

Here's a simple example that illustrates all of those:

<pattern:validator name="integer-validator" inboundAddress="vm://validator.in" ackExpression="#[string:GOOD:#[message:payload]@#[context:serviceName]]" nackExpression="#[string:BAD:#[message:payload]@#[context:serviceName]]" outboundAddress= >"vm://test-service.in" <payload-type-filter expectedType= />"java.lang.Integer"</pattern:validator>

The filter validates that the message is an Integer, the ack and nack expressions define the positive and negative status messages, and theaddress declares where a valid message is sent. To learn more about the capabilities of the validator pattern, see .Validator Pattern

Web Service Proxy

The Web Service Proxy pattern creates a proxy for a web service at an endpoint serviced by Mule.  This endpoint will advertise WSDL for theservice, with the service's address rewritten to point to the proxy. Here's a simple example:

<pattern:proxy name="weather-forecast-ws-proxy" inboundAddress="http://localhost:8090/weather-forecast" outboundAddress= />"http://ws.acme.com:6090/weather-forecast"

The WSDL which can be fetched from will make the service appaer to be at http:/ /localhost:8090/weather-forecast?wsdl http:/. To learn more about the capabilities of the web service proxy pattern, see /localhost:8090/weather-forecast Web Service Proxy Pattern

Connecting with Transports and Cloud Connectors

Connecting with Transports and Cloud Connectors

This topic provides a brief overview about Cloud Connect and transports in general--what they are, how to use them, and even a hint about howcan you develop one.

Cloud Connectors

The main purpose of cloud connectors is to provide you with an easy way to connect to the thousands of software-as-a-service (SaaS) platformsout there without having to work with transports or dealing with the different protocols that each API uses.

MuleSoft's goal was to facilitate how connectors are created and for that we have developed a web kit. Connectors essentially Java POJOs thatour kit works with and that are converted into fully featured components for Mule ESB.

How to Use Them

To use Cloud Connects with a Mule flow, you can add them directly to your Mule app like this:

<dependency> <groupId>org.mule.modules</groupId> <artifactId>mule-module-s3</artifactId> <version>1.0-SNAPSHOT</version></dependency>

Or you can deploy the JAR produced by our kit into the lib/user folder to share the connector between multiple applications.

Once you have deployed the connector JAR, reference the schema inside your Mule app config. The following is an example for the S3connector:

<mule xmlns="http://www.mulesoft.org/schema/mule/core"xmlns:s3="http: //www.mulesoft.org/schema/mule/s3"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation=" http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-3.0.xsdhttp://www.mulesoft.org/schema/mule/s3 http://www.mulesoft.org/schema/mule/s3/1.0/mule-s3.xsdhttp://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.1/mule.xsd">

How to use each connector depends on the specific connector. You can find a list of available connectors and in .here MuleForge

Developing a Cloud Connector

Developing a connector is as straightforward as using them. MuleSoft provides a topic inside the documentation that explains the process on howto develop cloud connectors. You can find that topic .here

Limitations

While development continues, cloud connectors have not yet reached their full potential, although progress is continually being made. Thefollowing are some tasks that you cannot accomplish with cloud connectors.

Request-Reponse Only: Cloud connectors are designed as request-response message processors. So every operation inside amessage processor must have a request to generate a response. You cannot use endpoints with them.

Non-Dynamic Instancing: While you can have multiple cloud connectors defined inside your Mule app, and even multiple instances ofthe same connector, you cannot create new ones inside a flow.

Global Configuration: Connectors can be configured globally only, and that configuration applies to all operations supported by theconnector. You cannot override configuration inside a flow.

Using Mule with Web Services

Using Mule with Web Services

Mule ESB allows different integration scenarios using Web services:

Consuming existing Web servicesBuilding Web services and exposing them to other applicationsCreating a proxy/gateway to existing Web services (for example, adding security to an existing Web service)

1. 2. 3. 4.

1. 2. 3.

1. 2. 3.

1. 2. 3.

Here we explore in a deeper way what options exist in each of these scenarios and direct you to other documentation sources and examples.

CXF Module Overview

Before explaining the different Web service scenarios that you can accomplish using Mule ESB, it is important to understand that the maintechnology on which it relies on is . Apache CXF is an open-source services framework that helps you build and develop servicesApache CXFusing front-end programming APIs, like JAX-WS and JAX-RS. Mule ESB now bundles the that provides Web services integration forCXF Moduleconsuming existing Web services and building new ones.

As of the latest version of Mule ESB, the CXF Module is the recommended way to work with with Web services.

Consuming Web Services

If you invoke an existing Web service, you usually build a Web service client to perform the call. If you have ever experienced this, you willunderstand it requires some code generation--you can learn about different ways to accomplish this with Apache CXF ).here

With Mule ESB you can simplify the way Web services can be consumed, but mainly you have many features out-of-the-box when invoking theservice (e.g, security) and to handle and process the results, such as transformations and using the results in a complex flow.

Mule ESB provides different alternatives to consume web services:

Generate and use a client from a WSDLUse a client based on the interface of a JAX-WS serviceUse a client based on the interface of a "simple" frontend web serviceUse the JAX-WS Java client API

Generate and use a client from a WSDL

This is a good approach when you need to consume third-party web services or in other cases where you don't have the web service code.

When consuming a web service this way, do the following:

Generate a CXF client using the tool from CXF or the .WSDL to Java Maven pluginConfigure the client in the Mule configuration XML file using the component.<cxf:jaxws-client>Configure an endpoint in the Mule configuration XML file that will be the transport to request the service (usually HTTP).

For more information, you can check the documentation.Consuming Web Services with CXF

Use a Client Based on the Interface of a JAX-WS Service

If you have access to the code used to build the Web service, you can build a client for your JAX-WS services with no need to generate a clientfrom the WSDL.

To consume a web service this way, do the following:

Copy your service interface and all your data objects locally.Configure the client in the Mule configuration XML file using the component.<cxf:jaxws-client>Configure an endpoint in the Mule configuration XML file that will be the transport to request the service (usually HTTP).

For more information, read the documentation.Consuming Web Services with CXF

Use a Client Based on the Interface of a "Simple" Front-End Web Service

If you are not using the JAX-WS service, you have a copy of your service interface and all your data objects locally, and the service is simpleenough you may consider building a client for your simple front end-based services without generating a client from the WSDL.

In order to consume a Web service this way, do the following:

Copy your service interface and all your data objects locally.Configure the client in the Mule configuration XML file using the component.cxf:simple-client>Configure an endpoint in the Mule configuration XML file that will be the transport to request the service (usually HTTP).

For more information, read the documentation.Consuming Web Services with CXF

Use the JAX-WS Java Client API

You can also use a Web service client API to communicate with Web services outside of Mule configurations. This means that you can invokeservices from within your Java classes that can then be used from within Mule ESB.

1. 2. 3.

1.

2. 3.

1. 2. 3. 4.

1. 2. 3.

As before, based on whether you will use the WSDL or whether you've built your service via "code-first" methodologies, there are two ways to useCXF clients:

Use the JAX-WS Client API.Build a Client Proxy.

Exposing Web Services

Mule ESB can be used to host your own Web services. In the same way you can consume Web services from Mule ESB, you can also build andexpose them. Here are three different ways to do this:

Create a JAX-WS Service.Create a WSDL First JAX-WS Service.Create a simple front-end Web service.

Create a JAX-WS Service

The JAX-WS specification is a series of APIs and annotations to help you build web services. To build and expose a Web service this way you willneed to accomplish the following:

Write a Java class that represent Web services (with the annotation) to expose its methods so that they can be invoked@WebServiceremotely.Configure the endpoint that will be accepting requests to the Web service (usually a HTTP inbound endpoint).Configure the service in the Mule configuration XML file using the component.<cxf:jaxws-service>

For more information, read the documentation.Creating a JAX-WS Service

Create a WSDL First JAX-WS Service

This is where you first define the WSDL and then code the web services. To build a Web service this way and configure it in Mule you should:

Generate your Web service interface from your WSDL using tool from CXF or the .WSDL to Java Maven pluginWrite the service implementation class that implements your service interface.Configure the endpoint that will be accepting requests to the Web service, usually a HTTP inbound endpoint.Configure the service in the Mule XML configuration file using the component.<cxf:jaxws-service>

For more information, read the documentation.Creating a WSDL First JAX-WS Service

Create a Simple Front-End Web Service

This is the best approach if you want to create a simple Web service out of an existing POJO. In this way, you need not use annotations, andthough writing an interface is not required, it is recommended as it will make the Web service easy to consume. To build a Web service this wayand configure it in Mule, do the following:

Use an existing simple Java class (POJO) or write a new one.Configure the endpoint that will be accepting requests to the Web service (usually a HTTP inbound endpoint).Configure the service in the Mule configuration XML file using the component.<cxf:jaxws-service>

For more information, read the documentation.Creating a simple front-end Web service

Proxying Web Services

Using Mule ESB as a Web service proxy is a feature that you may want to use when:

You need to add security to an existing 3rd party web service (you don't have the code or own the infrastructure).You need to add or remove HTTP headers.You need to validate or transform input or output of the Web service.You may need to transform the SOAP envelope.You may want to take advantage of the CXF Web service standards support to use WS-Security, WS-Addressing or to enforce WS-Policyassertions.Introduce custom error handling.

There are many other scenarios where you may also need to consider proxying Web services.

You have two types of proxying:

Server-side ProxyingClient-side Proxying

Web Service Proxy Pattern

For simple use cases, you may consider using the , particularly when you don't need to accomplish much messageWeb Service Proxy Patternprocessing. From Mule, you can use to configure (with minor XML configuration) a specific integration feature.Using Mule Configuration Patterns

References

For more information and complete documentation, please read the following:

CXF Module ReferenceSupported Web Service StandardsWeb Service Proxy PatternExamples

Echo ExampleBookstore Example