MueE B3C n e t l S o c ps

1. Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Mule ESB 3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 How Mule Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 About Mule Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 Understanding the Mule Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.1 About SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.2 Mediation - Separating Business Logic from Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.3 Orchestration - Routing Messages Between Service Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.4 Components - Processing the Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.5 Endpoints - Wiring Everything Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.6 Understanding the Logical Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3.7 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Understanding Enterprise Integration Patterns Using Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 Understanding Orchestration Using Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.6 Understanding Configuration Patterns Using Mule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.7 Connecting with Transports and Cloud Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.8 Using Mule with Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2 2 4 6 7 7 8 9 10 11 12 14 15 16 17 18

Home
Introducing Mule ESB 3 Concepts
This book explains important concepts necessary for you to understand when developing with Mule effectively. Mule ESB 3 Concepts How Mule Works About Mule Configuration Understanding the Mule Architecture About SOA Mediation - Separating Business Logic from Messaging Orchestration - Routing Messages Between Service Components Components - Processing the Data Endpoints - Wiring Everything Together Understanding the Logical Data Flow Policy Enforcement Understanding Enterprise Integration Patterns Using Mule Understanding Orchestration Using Mule Understanding Configuration Patterns Using Mule Connecting with Transports and Cloud Connectors Using 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 Works About Mule Configuration Understanding the Mule Architecture About SOA Mediation - Separating Business Logic from Messaging Orchestration - Routing Messages Between Service Components Components - Processing the Data Endpoints - Wiring Everything Together Understanding the Logical Data Flow Policy Enforcement Understanding Enterprise Integration Patterns Using Mule Understanding Orchestration Using Mule Understanding Configuration Patterns Using Mule Connecting with Transports and Cloud Connectors Using 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, the integration 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 the business logic and will consume, process, or enrich messages. Service Orchestration: configuring message processors, routers, transformers, and filters that provide the service mediation and orchestration capabilities required to allow composition of loosely coupled services using a Mule Flow. New orchestration elements can also be created and dropped into your deployment. Integration: A key requirement of service mediation is decoupling services from the underlying protocols. Mule provides transports to allow dispatching and receiving messages on different protocol connectors. These connectors are configured in the Mule configuration and then can be referenced from the orchestration layer. Mule supports many existing transports and all the popular communication protocols, 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. You can use any existing Java class, Spring bean, Groovy script, a Cloud Connector, or create a new component. Your service component does not need 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 Mule IDE, which works within Eclipse to provide an integrated development environment for developing Mule 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 <configuration> element to set global configuration options such as the threading profile. You then define the connectors, transformers, and endpoints you'll use in different flows. Lastly, you configure flows or service models, which act as containers for services and orchestration elements and apply settings such as the 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 <flow> element in the Mule configuration file. The flow creates a composition around the service component(s) that allows you to define how messaged are routed, filtered, transformed and enriched before or after processing by one or a series of service components. Flows are more flexible and robust than the traditional service model in Mule, allowing a more natural and compact means of describing 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 <model> element in the Mule configuration file. The service points to the service component, routers, filters, and transformers. It also specifies the endpoint on which this service will receive messages and the outbound endpoint where messages will 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 building block in Mule and in fact, components, routers, filters, and transformers are all message processors. There are also other special message processors that do not fall in one of those categories. These include a number of specialized modules like CXF and Jersey Web Services, BPM, as well as a few specialized integration elements like <poll>, <content-enricher>, and <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 has finished processing them. There are several default routers that come with Mule that you can use, or you can create your own routers. For more information, 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 you can 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 the message, they can also convert the message to a different type as needed by the outbound transport. There are several default transformers you can use, or create your own. For more information, see Using Transformers.

Transports and Connectors

Mule provides default transports for many different channels, including File, FTP, HTTP, JMS, JDBC, Quartz, and many more. Transports communicate 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 Connectors Transports Custom Message Processors Custom Transformers Configuration 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 ESB To 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 transformers and 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 Mule configuration Connectors - Non-default configuration of any transports used Endpoints - Define the channel and address or path where messages are sent or received. You can define them globally and use them in multiple 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 filters specifically 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/core http://www.mulesoft.org/schema/mule/core/3.0/mule.xsd http://www.mulesoft.org/schema/mule/vm http://www.mulesoft.org/schema/mule/vm/3.0/mule-vm.xsd"> <vm:connector name="vmConnector" queueTimeout="5000"/> <vm:endpoint name="CustomerRequests" path="customer.requests"/> <vm:endpoint name="CustomerResponses" path="customer.responses"/> <custom-transformer name="ThisToThat" class="com.acme.transformer.ThisToThat"/> <flow name="myBasicFlow"> <inbound-endpoint ref="CustomerRequests"/> <component class="com.acme.service.BasicService"/> <outbound-endpoint ref="CustomerResponses" transformer-refs="ThisToThat"/> </flow> </mule>

Other, more advanced things you may configure at this level: Security Manager - Authenticates requests based on one or more security providers Agents - Agents are typically used for cross-cutting concerns such as logging or management Notifications - Allow you to be notified upon certain lifecycle events Transaction Management - Mule transactions are configured on inbound endpoints, where an endpoint can be configured to start a new transaction 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: org.mule.api.config.MuleConfiguration . Configurations in a MuleConfiguration are set when a MuleContext is created. The object becomes immutable after it is started and can be accessed using the following:

// implement MuleContextAware to have the reference injected MuleConfiguration 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 then send them to the shipping department for order fulfillment.

This section includes the following topics: About SOA Mediation - Separating Business Logic from Messaging Orchestration - Routing Messages Between Service Components Components - Processing the Data Endpoints - Wiring Everything Together Understanding the Logical Data Flow Policy Enforcement

About SOA
About SOA
Mule ESB is based on the concept of a service-oriented architecture (SOA). The SOA approach to development allows IT organizations to compose applications by building service interfaces around components of applications and exposing those to service consumers. Services are discrete sets of functionality that are completely separate from each other but can work together on a canonical set of objects. For example, if you need to process customer invoices, you might have one service that merges customer data from a database into the invoice and another service that 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 type of process or message. For example, the service that merges customer data onto the invoice could also be used to merge customer data onto statements, letters, or other documents. The logic that determines how the invoice data and customer data are merged is decoupled from the logic that looks up and retrieves the necessary customer data. This modular approach allows you to create functionality once and re-use it as many times as needed, streamlining development. This decoupling is a key element of service mediation. Mediation is a well-known pattern for promoting loose coupling. In SOA, service mediation also describes the capabilities of the ESB to convert between transport protocols (including the ability to bridge between synchronous and asynchronous protocols), changing the representation of messages by transforming data, and enforcing compliance with policies by taking the necessary steps such as auditing, logging, security monitoring, etc. Constructing the building blocks into a logical process is called orchestration. Service orchestration using an ESB allows for automation of common backend processes at the application service layer. These processes can be scheduled or exposed as services that are triggered by external 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 and reconfiguring existing services in developing new applications. SOA also enables better integration of enterprise IT resources, including previously isolated 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 might always be in XML format, but it might arrive over HTTP in one situation and as a JMS message in another depending on which application created 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 the various 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 message format. Instead, a transport carries the message along, and transformers change the message's payload (such as the invoice) as 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) as required, and the flow directs the message to each component that needs to process it. All the transporting, transforming, and routing of the message 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 can understand. Most importantly, data is transformed only as needed. Instead of mandating the conversion of every message to a single common data protocol (like XML) and specific message format, messages and their data are transformed only as needed for the target component or application where the message is being sent. Mule also enables content enrichment of messages through integration patterns that allow you to retrieve 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 and then forwarding it as an asynchronous JMS message after it has been processed by the Customer Data component. This decoupling of the transport layer allow services to be reused across the enterprise regardless of the legacy technology decisions that were made and enable different 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 security monitoring can all be performed without any modification of the existing code. Policy enforcement can even be applied based on who is calling the service 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 your architecture and makes it much simpler to customize the business logic without having to worry about the various formats in which a message might 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 send messages themselves. To ensure that the component receives the right messages and routes them properly after processing, an orchestration flow wraps the component (or components) with additional message processors that filter, transform, enhance or route the message to the appropriate component or endpoint. This allows the invocation sequence to be dynamically varied based on the context of the message or the current load or availability of the system.

Processing data using Mule Flows gives you complete flexibility in where and how messages are transformed, filtered, and routed. Each is just another 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 configuration patterns make it easy to perform common bits of orchestration, for instance, bridging two endpoints. Using configuration patterns where possible simplifies the work required to configure Mule. When business process orchestration is required, Mule provides a BPM module for enabling different BPM engines within Mule. Business process orchestration should be used for longer running stateful business processes, complex human interactions and approvals, or parallel execution of those 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 a service that processes it using some specific business logic (such as checking the customer and inventory databases), and then routes it to the correct application (such as the order fulfillment system). Mule contains many individual parts that handle the processing and routing of the message. One key part is the component. Components execute business logic on messages, such as reading the invoice object, adding information 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, Java beans, Groovy scripts, or web services containing the business logic for processing data in a specific way. Mule even supports a powerful type of component called a Cloud Connector that can connect to any cloud-based service or application and process or enrich the message. Cloud connectors 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 right information 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 flow. Flows allow any number of components to be chained together along with other forms of message processing. Flows allow Mule to orchestrate how and when a message is routed 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 in stock and one that updates a separate customer database with the order history. The invoice, which is encapsulated in a message, can flow from one 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 ESB which transport to use, where to send messages, and which messages a component should receive. The primary part of an endpoint is the address 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 (URI) or as schema-specific XML configuration

For example, if a flow's inbound endpoint's address is http://myfirm.com/mule, the HTTP transport will dispatch to that flow any messages that have been sent to that URL. If the inbound endpoint specifies file://myserver/files/, the File transport, which is watching that directory, dispatches 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 the sender. Mule supports several Message Exchange Patterns and each transport has a default pattern it will follow unless you specify otherwise. Mule will typically return the final result of the message processing back as the result; however response processing can also be specified to control 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 may want 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 more separate endpoints. For example, if you want one of your flows to handle messages coming in on both the HTTP and JMS channels, you would specify at least one inbound HTTP endpoint and at least one inbound JMS endpoint. Mule registers these endpoints with the flow, and the transport 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-slip patterns 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 only receives RSS messages by a specific author. Specifying filters, routers, and endpoints for your services simply requires editing an XML configuration. You do not have to write any Java code. Some routers are also dynamic and can change behavior based on the content of the message or an external data source such as a file or database. As stated previously, your components code remains completely separate from messaging and routing, which you handle through Mule configuration.

In summary, Mule provides a simple and lightweight way to write components that do something to data without needing to worry about the sender or recipient of the data, the format of the data, or the technology being used to send/receive the data. Although many brokering and integration technologies offer the ability to connect to disparate data sources, they often require extra coding to get messages to behave the way you 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 they behave 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 to determine which components, routers, transports, and transformers to use along the way. The diagram that follows illustrates these steps.

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

1. http://myfirm.com/orders. 2. The HTTP transport receives the XML invoice and wraps it in a Mule message. The Customer Data flow's inbound endpoint is set to http://myfirm.com/orders, so the HTTP transport dispatches the message to the service. 3. The XML to Object transformer converts the XML invoice into a Java object. 4. The flow passes the message with its transformed payload to the Customer Data component. 5. The Customer Data component queries the master customer database to pull additional data about the customer and updates the invoice with the data. 6. What follows in the flow is an HTTP outbound endpoint, so the HTTP transport determines that it must now dispatch the message to its address, http://myfirm.com/verify. 7. The HTTP transport uses the configuration of the Inventory Verification flow to receive the message and pass it to the Inventory Verification component. 8. This component updates the invoice with an ID code of the warehouse that has all the items on the invoice in stock. 9. The outbound endpoint specifies a JMS address, so the JMS transport dispatches the message to the order fulfillment application, which picks 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 into the 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 unmodified message to both output channels. To insert the Wire Tap into a channel, create an additional channel and change the destination receiver to consume from the second channel. Because the analysis logic is located inside a second component, a generic Wire Tap can fit into any channel without 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 the server starting or a service being registered. It is is the parent of a host of concrete notifications you can use in your Mule-aware Java applications: ServerNotification ComponentMessageNotification ConnectionNotification CustomNotification EndpointMessageNotification ExceptionNotification FlowConstructNotification ManagementNotification MessageProcessorNotification ModelNotification MuleContextNotification RegistryNotification RemoteDispatcherNotification RoutingNotification SecurityNotification ServiceNotification TransactionNotification

Logging
Examining the Mule log is a way to understand what is happening as messages move through a Mule application. Mule's logging configuration is stored 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="Logger" engine="groovy"> <scripting:text>log.info(message); log.info(payload); message</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 called AbstractEncryptionTransformer that will transform an array of bytes or string into an encrypted array of bytes once implemented. There are two concrete classes called DecryptionTransformer and EncryptionTransformer that will transform an encrypted array of bytes or string into an decrypted 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 Mule application. To implement this abstract class, authenticate inbound and outbound events, ensuring no anonymous or null users gain access, then throw 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 to control method-level authorization on your service components. The Security Manager is responsible for authenticating requests based on one or more security providers. All security is pluggable via the Mule security API , so you can easily plug in custom implementations. For information on the elements you can configure for the Security Manager, see Security Manager Configuration Reference. The following sections 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 (Yale Central Authentication service), and DAO. The following topics will help you get started securing your services using Spring Security: Configuring the Spring Security Manager Component Authorization Using Spring Security Setting 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), and DAO. The following topics will help you get started securing your services using Acegi: Configuring the Acegi Security Manager Component Authorization Using Acegi Setting 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 SOAP message 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 book by Gregor Hohpe and Bobby Woolf. The fact that Mule implements these patterns greatly reduces the effort required when building integrations. You can design your solution using these 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 objects below:

Integration Styles
Pattern File Transfer Shared Database Messaging Mapping to a Mule Object File Transport JDBC Transport Mule is all about Messaging

Messaging Systems
Pattern Message Channel Pipes and Filters Message Router Message Translator Message Endpoint Mapping to a Mule Object Mule provides a message channel that connects the message processors in a flow. A Flow implements a pipe and filter architecture Message Routers Message Transformer Inbound & Outbound Endpoints

Messaging Channels
Pattern Point-to-Point Channel Message Bus Mapping to a Mule Object The default channel within a flow. Mule is a message bus.

Message Routing
Pattern Content-Based Router Message Filter Mapping to a Mule Object Choice Filters

Recipient List Splitter Aggregator Resequencer

Recipient List Collection Splitter, Message Chunk Splitter & Plain Splitter Collection Aggregator, Message Chunk Aggregator & Custom Aggregator Resequencer

Message transformation
Pattern Content Enricher Mapping to a Mule Object Message Enricher

Messaging Endpoints
You can declare endpoints to be transactional as needed. Pattern Idempotent Receiver Mapping to a Mule Object Idempotent Message Filter

System Management
Pattern Wire Tap Mapping to a Mule Object 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 as combining service calls to create higher-level, more useful composite services, and implies implementing business-level processes combining business-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 as systems or business needs change. It involves moving beyond patterns into a service-based framework, where you wrap multiple components with endpoints to decouple them from protocols and routing requirements, enabling multiple services to work as one when implementation requirements 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 mediationfor 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 for orchestration by chaining together multiple services using queues and/or a chaining router. Flow enables you to orchestrate new forms of data movement based on flow-specific routers. Orchestration enables you to create and reuse subflows, chain together multiple components in one flow, and integrate endpoints or cloud connectors anywhere in a flow.

When to Use Orchestration

You use orchestration when existing Enterprise Integration Patterns (EIPs) dont seem to apply to implementing your solution, or when routers seem too confining or clumsy. There are only so many EIPs to use when implementing a solution, and you may find yourself in a position when you need to resort to more flexibility than patterns provide. You may also use orchestration when you wish to contain your flow subsystem to a single 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 files contents into a standard format that contains one or more specific orders. Next, the orders are split out to be processed separately, and any non-book orders are filtered out. Now two 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 the customer 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 be checked, 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 for each order in the xml file --> <expression-filter expression="xpath://order[@type='book']"/> <component class="org.my.BookInventoryChecker"/> <component class="org.my.BookCustomerOrderProcessor"/> <smtp:outbound-endpoint subject="Order Confirmation" to="#{xpath://customer/email]"/> <jdbc:outbound-endpoint queryKey="storeOrder"/> <default-exception-strategy> <jms:outbound-endpoint queue="failedOrders"/> </default-exception-strategy> </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 to implement 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: Inbound Component Outbound and anything that doesn't fit into that mold has to be decomposed into multiple services. For that reason, services, while fully supported, 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 of coding 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 service and 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 worry about. 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 about the 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: POJOs JAX-WS services JAX-RS services JAXB 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 only minimal configuration but separation of concerns: different configuration objects are responsible for Validating the input Defining the positive and negative status messages returned to the caller Declaring 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 the address 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 the service, 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 http:/ /localhost:8090/weather-forecast?wsdl will make the service appaer to be at http:/ /localhost:8090/weather-forecast. To learn more about the capabilities of the web service proxy pattern, see 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 how can 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) platforms out 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 that our 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 S3 connector:

<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/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.mulesoft.org/schema/mule/s3 http://www.mulesoft.org/schema/mule/s3/1.0/mule-s3.xsd http://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 here and in 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 how to 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. The following 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 a message 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 of the 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 the connector. 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 services Building Web services and exposing them to other applications Creating a proxy/gateway to existing Web services (for example, adding security to an existing Web service)

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 main technology on which it relies on is Apache CXF. Apache CXF is an open-source services framework that helps you build and develop services using front-end programming APIs, like JAX-WS and JAX-RS. Mule ESB now bundles the CXF Module that provides Web services integration for consuming 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 will understand 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 the service (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: 1. 2. 3. 4. Generate and use a client from a WSDL Use a client based on the interface of a JAX-WS service Use a client based on the interface of a "simple" frontend web service Use 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: 1. Generate a CXF client using the WSDL to Java tool from CXF or the Maven plugin. 2. Configure the client in the Mule configuration XML file using the <cxf:jaxws-client> component. 3. 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 Consuming Web Services with CXF documentation.

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 client from the WSDL. To consume a web service this way, do the following: 1. Copy your service interface and all your data objects locally. 2. Configure the client in the Mule configuration XML file using the <cxf:jaxws-client> component. 3. 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 Consuming Web Services with CXF documentation.

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 simple enough 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: 1. Copy your service interface and all your data objects locally. 2. Configure the client in the Mule configuration XML file using the cxf:simple-client> component. 3. 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 Consuming Web Services with CXF documentation.

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 invoke services from within your Java classes that can then be used from within Mule ESB.

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 use CXF 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 and expose them. Here are three different ways to do this: 1. Create a JAX-WS Service. 2. Create a WSDL First JAX-WS Service. 3. 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 will need to accomplish the following: 1. Write a Java class that represent Web services (with the @WebService annotation) to expose its methods so that they can be invoked remotely. 2. Configure the endpoint that will be accepting requests to the Web service (usually a HTTP inbound endpoint). 3. Configure the service in the Mule configuration XML file using the <cxf:jaxws-service> component. For more information, read the Creating a JAX-WS Service documentation.

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: 1. 2. 3. 4. Generate your Web service interface from your WSDL using WSDL to Java tool from CXF or the Maven plugin. Write 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 <cxf:jaxws-service> component.

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

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, and though 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 way and configure it in Mule, do the following: 1. Use an existing simple Java class (POJO) or write a new one. 2. Configure the endpoint that will be accepting requests to the Web service (usually a HTTP inbound endpoint). 3. Configure the service in the Mule configuration XML file using the <cxf:jaxws-service> component. For more information, read the Creating a simple front-end Web service documentation.

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-Policy assertions. 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 Proxying Client-side Proxying

Web Service Proxy Pattern

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

References
For more information and complete documentation, please read the following: CXF Module Reference Supported Web Service Standards Web Service Proxy Pattern Examples Echo Example Bookstore Example