Mule Getting Started Guide

(1)

Mule Getting Started Guide

Mule Enterprise Edition Version 2.2.6

August 2010

(2)

Confidential

The ideas contained in this publication are subject to use and disclosure restrictions as set forth in the license agreement.

Copyright

Copyright © 2003-2010, MuleSoft, Inc. All rights reserved. No part of this publication may be copied or distributed, transmitted, transcribed, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, manual, optical, chemical or otherwise; or disclosed to third parties without the express written permission of MuleSoft, Inc.

Disclaimer

Information in this document is subject to change without notice and does not represent a commitment on the part of MuleSoft, Inc. The software described in this document is furnished under a license agreement or nondisclosure

agreement. The software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the software on any medium except as specifically allowed in the agreement.

In addition, MuleSoft, Inc makes no representation or warranties either express or implied, with respect to this manual and accompanying software and specifically disclaim any implied warranties of merchantability or fitness for any particular purpose. This manual and accompanying software are sold “as is” and MuleSoft, Inc will in no event be liable for direct, indirect, incidental or consequential damages resulting from any defect, error or failure to perform except as expressly set forth in the license agreement.

Trademarks

MuleSoft, Mule and MuleForge are among the trademarks of MuleSoft. All other product names are trademarks of their respective companies.

(3)

Preface

The Mule Getting Started Guide introduces Mule and related products from MuleSoft. It provides the conceptual information and context that everyone from decision makers to programmers need to get started with planning and implementing Mule.

Who Should Read This Guide?

This guide is intended for the following audiences:

Decision makers who need to evaluate and understand Mule

Architects who need to plan how they will implement Mule

Business analysts who will design the business processes supported by Mule

Developers who will customize and extend Mule

Integration developers who will integrate Mule with other applications

(7)

Preface What’s the Fastest Way Through This Guide?

What’s the Fastest Way Through This Guide?

This section describes what you should read based on your role.

Getting a Quick Start

If your role is... Read...

Decision maker such as CIO, Director of Software Architecture, or IT manager

Chapter 1, “Introduction to Mule ESB”

Appendix B, “Third-party Software”

Architect responsible for designing the system

Chapter 2, “Installing and Running Mule”

Appendix B, “Third-party Software”

Business analyst responsible for designing the business processes

“Glossary” on page 100 Developer responsible for customizing or

extending Mule

Chapter 3, “Tutorial” Integration developer responsible for

wiring everything together

Chapter 3, “Tutorial” Administrator responsible for maintaining

Mule

(8)

Typographic Conventions Preface

Existing Users

If you are an existing user, go to http://mule.mulesource.org/x/J4H8 to learn about the new features and how to migrate your configuration files to this release. Mule Enterprise customers can use the migration tool and follow the instructions in the Migration Guide, both available from the Downloads page on the MuleSoft customer portal (log in at http://mulesupport.mulesource.com/portal/login.mule.

Typographic Conventions

The following table describes the typographic conventions used in the Mule documentation:

Mule Technical Support

If you have a paid subscription to MuleSoft, you can view the Mule knowledge base and get assistance with Mule products at http://support.mulesoft.com. For information on purchasing a subscription, contact MuleSoft by phone at 1-877-MULE-OSS or by email at [email protected].

Typeface Meaning Example

AaBbCc123 _{Files and directory names, parameters,} command lines, and code examples.

Edit the information in struts-config.xml

AaBbCc123 _{Placeholder text that you change.} http://serverName/mule

AaBbCc123 _{A live link to a web site, email address,} or another section in the document

See page 8

AaBbCc123 _{The names of user interface controls,}

menus, and menu items.

(9)

Chapter 1

Introduction to Mule ESB

This chapter describes Mule ESB, its architecture, and how it is useful to your enterprise. It contains the following sections:

“What is Mule ESB?” on page 10

“Understanding the Messaging Framework” on page 11

“Understanding the Mule ESB Architecture” on page 12

“Understanding the Logical Data Flow” on page 18

“Integrating Mule ESB into Your Environment” on page 21

“Administering Mule” on page 23

“Compatible Technologies” on page 24

(10)

What is Mule ESB? Chapter 1 Introduction to Mule ESB

What is Mule ESB?

Mule ESB is a lightweight Java-based messaging framework that allows you to quickly and easily connect your applications and enable them to exchange data. Mule ESB uses a service-oriented architecture (SOA), enabling easy integration of your existing systems. Regardless of the different technologies the applications use, including JMS, Web Services, JDBC, HTTP, and more, Mule ESB seamlessly handles interactions among them all.

The Mule framework is highly scalable, allowing you to start small and connect more applications over time. Mule ESB manages all the interactions between applications and components transparently, regardless of whether they exist in the same virtual machine or over the Internet, and regardless of the underlying transport protocol used.

Mule ESB is based on ideas from Enterprise Service Bus (ESB) architectures. The key advantage of an ESB is that it allows different applications to communicate with each other by acting as a transit system for carrying data between applications within your intranet or across the Internet. There are currently several commercial ESB implementations on the market. However, many of these provide limited functionality or are built on top of an existing application server or messaging server, locking you into that specific vendor. Mule ESB is vendor-neutral, so different vendor implementations can plug in to it. You are never locked in to a specific vendor when you use Mule ESB.

(11)

Chapter 1 Introduction to Mule ESB Understanding the Messaging Framework

Mule ESB provides many advantages over competitors, including:

Mule ESB components can be any type you want. You can easily integrate anything from a “plain old Java object” (POJO) to a component from another framework.

Mule ESB and the ESB model enable significant component reuse. Unlike other frameworks, Mule ESB allows you to use your existing components without any changes. Components do not require any Mule ESB-specific code to run in Mule ESB, and there is no programmatic API required. The business logic is kept completely separate from the messaging logic.

Messages can be in any format from SOAP to binary image files. Mule ESB does not force any design constraints on the architect, such as XML messaging or WSDL service contracts.

You can deploy Mule ESB in a variety of topologies, not just ESB. Because it is lightweight and embeddable, Mule ESB can dramatically decrease time to market and increases productivity for projects to provide secure, scalable applications that are adaptive to change and can scale up or down as needed.

MuleSoft also provides administration tools that allow you to manage your deployments (Mule Management Console) and control your infrastructure (Mule Galaxy). These tools are described in more detail in “Administering Mule” on page 23.

The next section provides more detail on the messaging framework and how Mule ESB exchanges data among applications.

Understanding the Messaging Framework

The advantage of networking your applications is that one application can send data to another application. However, many applications don't have the ability to read or process data coming from another application. Mule ESB solves this problem by providing a messaging framework that reads, transforms, and sends data as messages between applications. A message is simply a packet of data that can be handled and sent between applications on a specific channel (also called a queue).

Message Data

Application 1 Application 2

(12)

Understanding the Mule ESB Architecture Chapter 1 Introduction to Mule ESB

At the simplest level, when you connect applications to Mule ESB, it reads data from one application, transforms it as needed so it can be read by the target application, and sends it to that application. This allows you to integrate all types of applications, even those that were not built to be integrated.

Mule ESB is a messaging framework based on ideas from Enterprise Service Bus (ESB) architectures. The key advantage of an ESB is that it allows different applications to communicate with each other by acting as a transit system for carrying data between applications within your intranet or across the Internet. The heart of the system is the

message bus, which routes messages between applications.

One difference between Mule ESB and a traditional ESB is that Mule ESB only converts data as needed. With a typical ESB, you have to create an adapter for every application you connect to the bus and convert the application’s data into a single common messaging format. The development of these adapters and the time required to process every message requires a lot of time and effort. Mule ESB eliminates the need for a single message format. The information is sent on any communication channel, such as HTTP or JMS, and is translated only as needed along the way. Therefore, Mule ESB increases performance and reduces development time over a traditional ESB.

The Mule ESB architecture and terminology use the principles described in the book

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe and Bobby Woolf. This book is highly recommended reading for anyone involved in working with enterprise messaging solutions. For more information, see http://www.enterpriseintegrationpatterns.com.

Understanding the Mule ESB 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.

Message Invoice Message Updated Invoice Order Entry Application Order Fulfillment Application Process Invoice

(13)

Chapter 1 Introduction to Mule ESB Understanding the Mule ESB Architecture

About SOA

Mule ESB is based on the concept of a service-oriented architecture (SOA). The SOA approach to development allows IT organizations to create applications by bringing together components of application functionality, or services. Services are discrete sets of functionality that are completely separate from each other but can work together on the same objects. For example, if you need to process 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.

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. This modular approach allows you to create functionality once and re-use it as many times as needed, streamlining development. 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 ESB fully supports the SOA approach and orchestrates communication among the services, allowing you to easily tie all these applications together.

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 ESB contains many individual parts that handle the processing and routing of the message. The key part of the

(14)

service is the service component. The service component executes 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 the service component is that it doesn’t have to have any Mule ESB-specific code; it can simply be a POJO, Spring bean, Java bean, or web service containing the business logic for processing data in a specific way. Mule ESB manages the service component, bundles it with configuration settings and exposes it as a service, and ensures that the right information is passed to and from it based on the settings you specified for the service in the Mule ESB configuration file.

You can have many different service 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.

Routing Messages Between Service Components

As stated previously, the service 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 service component receives the right messages and routes them properly after processing, you specify an inbound router and an outbound router for the component’s wrapping service when you are configuring Mule ESB.

Customer Data Service Component Message Invoice Customer Database Message Updated Invoice Service Configuration Settings Order Entry Application Order Fulfillment Application

(15)

Inbound routers specify which messages the service component will process. They can filter incoming messages, aggregate them, and resequence them before routing them to a service component. For example, if a service component subscribes to an RSS feed, the inbound router could filter which messages it receives from that feed.

After a service component has processed a message, the outbound router specifies where to dispatch the message. For example, it might route invoices for in-state addresses to one shipping department and route all other invoices to another shipping department. You can define multiple inbound and outbound routing constraints and even chain routers together so that a service component receives and routes messages exactly as required.

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 the service 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 service components don’t know how to read the messages, because by default, service 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 service component can read before the router passes the message to the service component. For example, if an XML invoice is sent over HTTP, the HTTP transport carries the message along, routers direct the message to each service

Domestic Order Fulfillment Application Message Updated Invoice Message Updated Invoice Inbound Router Outbound Router

Customer Data Service Component Outbound Router Inbound Router International Order Fulfillment Application Inbound Router

(16)

component that needs to process it, and transformers change the invoice along the way (such as from XML to a Java object) as required by each service component. All the transporting, transforming, and routing of the message are completely transparent to the service

component.

Transformers are the key to exchanging data, as they allow Mule ESB to convert the data to a format that another component or application can understand. Most importantly, data is transformed only as needed. Instead of converting every message to a single common messaging format, messages and their data are transformed only as needed for the target component or application where the message is being sent. Lastly, you can use multiple types of transports to handle different channels, such as sending the message over HTTP and then forwarding it as a JMS message after it has been processed by the Customer Data service component.

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.

HTTP Transport

Inbound Router Outbound Router

Message JMS Transport Service XML to Java Object Transformer Customer Data Service Component Message

(17)

Wiring Everything Together

Endpoints are configuration elements that are the key to wiring together all the services. You specify endpoints in the inbound and outbound routers to tell Mule ESB which transport to use, where to send messages, and which messages a service component should receive. The primary part of an endpoint is the address, expressed as a uniform resource indicator (URI), which indicates the transport to use, the location (a transport-specific resource), and any additional parameters.

For example, if a service’s inbound router specifies the endpoint http://myfirm.com/mule, the HTTP transport will dispatch to that service any messages that have been sent to that URL. If the inbound router specifies file://myserver/files/, the File transport, which is watching that directory, dispatches any new files created in that directory to the service. The endpoint you specify on the outbound router indicates where the message will go next—it goes to the service with the same inbound endpoint as the previous component’s outbound endpoint, as shown in the following illustration.

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

HTTP Transport Outbound Router Message sent to http:// myfirm.com/mule JMS message JMS Transport Inbound Router Endpoint: jms://myqueue Endpoint: jms://myqueue Service Service Customer Data Service Component Order Fulfillment Service Component Inbound Router Endpoint: http:// myfirm.com/mule HTTP message

(18)

Understanding the Logical Data Flow Chapter 1 Introduction to Mule ESB

The router or endpoint can include filters that further specify which messages to send or receive. For example, you can specify that the service component only receives RSS messages by a specific author. Specifying routers and endpoints for your services simply requires editing an XML file. You do not have to write any Java code. As stated previously, your service components code remains completely separate from messaging and routing, which you handle through the Mule ESB configuration.

In summary, Mule ESB provides a simple and lightweight way to write service 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 ESB 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

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 ESB instance. Throughout the process, Mule ESB uses the Mule ESB 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 http://myfirm.com/orders.

2 The HTTP transport receives the XML invoice and wraps it in a Mule message. The Customer Data service’s inbound endpoint is set to http://myfirm.com/orders, and its inbound router specifies that the message must contain a Java object, so the HTTP transport prepares to transform the XML invoice and dispatch the message to the service.

3 The XML to Object transformer converts the XML invoice into a Java object. Note that the next service and the final application also expect Java objects, so no further

transformers are used in this scenario.

4 The transport passes the message with its transformed payload to the Customer Data service.

5 The Customer Data service component queries the master customer database to pull additional data about the customer and updates the invoice with the data.

(19)

Chapter 1 Introduction to Mule ESB Understanding the Logical Data Flow

6 The HTTP transport uses the outbound router configuration to determine that it must now dispatch the message to http://myfirm.com/verify.

7 The HTTP transport uses the inbound router configuration of the Inventory Verification service to receive the message and pass it to the service component.

8 The service 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.

(20)

Understanding the Logical Data Flow Chapter 1 Introduction to Mule ESB

HTTP Transport

Sends messages to http://myfirm.com/orders JMS message http:// myfirm.com/ orders HTTP Transport Outbound Router jms://myqueue http:// myfirm.com/ verify Customer Data Service

Customer Data Service Component Inventory Verification Service Component XML to Java Object Transformer 1 2 3 4 Data 5 XML POJO 6 http:// myfirm.com/ verify Inbound Router Order Entry Order Fulfillment

JMS Transport Inventory Verification Service 7 POJO includes warehouse ID 8 9 Receives messages on jms://myqueue

(21)

Chapter 1 Introduction to Mule ESB Integrating Mule ESB into Your Environment

Integrating Mule ESB into Your Environment

As mentioned at the beginning of this chapter, Mule ESB is based on ideas from the ESB architecture. The messaging backbone of the ESB is usually implemented using JMS, but any other message server implementation could be used, such as MSMQ, IBM WebSphere MQ (and earlier versions know as MQSeries), or TIBCO Rendezvous. Additionally, there are no strict rules on how your integration service layer should behave when using Mule ESB. You can connect Enterprise JavaBean components (EJBs), mainframe applications,

messaging, web services, sockets, and file systems and interact with them all in a simple consistent way.

Mule ESB also supports other topologies beyond ESB, including pipeline, peer network, client/server, hub-and-spoke, and more. These topologies can be mixed and matched in an

enterprise service network to model complex enterprise messaging and service requirements, as shown in the following illustration.

When integrating with Mule ESB, you can start with just a few applications and connect more applications to Mule ESB over time. For example, one Mule ESB customer started by integrating six systems. Three years later, they had a total of 71 systems connected using Mule ESB. Mule ESB allows you to start as small as needed and easily scale over time.

(22)

Integrating Mule ESB into Your Environment Chapter 1 Introduction to Mule ESB

You can have multiple instances of Mule ESB distributed across your network, as shown in the following illustration. This approach is useful for failover (if one Mule ESB instance becomes unavailable because the server stops, another Mule ESB instance can take over its messages) as well as for load-balancing (you can send some messages to one instance and other messages to another instance to balance the load).

You can deploy each instance of Mule ESB as a stand-alone application, in a web container (such as Apache Tomcat), or in an application server. You can use proprietary J2EE

application servers such as BEA WebLogic, IBM WebSphere, Oracle Application Server, and SunOne, as well as in open source products like Geronimo or JBoss.

Designing your system is both an art and a science. It must be done correctly to ensure scalability. MuleSoft Professional Services can help you by reviewing your architecture, designing components, or doing the full implementation for you. For more information, contact your MuleSoft Professional Services representative.

(23)

Chapter 1 Introduction to Mule ESB Administering Mule

Administering Mule

MuleSoft provides additional tools for monitoring and managing your Mule deployment, as shown in the following illustration. This section describes these tools and how they can help you administer Mule.

Managing Your Deployments with the Management Console

The management console for Mule ESB provides a centralized way to manage all of your standalone Mule deployments as well as all of the disparate systems and services in your SOA infrastructure. For example, a typical stack that the management console monitors might include Redhat Enterprise Linux, MySQL, JBoss Application Server, OpenMQ, and Mule. The management console provides integrated log, configuration, and server event tracking. It can detect Mule ESB servers and associated software and hardware, and report real-time and historical details of events.

The management console is available with Mule Enterprise Edition only. It can monitor both Community Edition and Enterprise Edition instances of Mule 2.x servers (to monitor Mule 1.x, download the previous release, Mule HQ 3.5). The management console fully supports standalone Mule ESB deployments and provides some monitoring data for embedded Mule ESB instances.

Controlling the Infrastructure with the Service Registry

The service registry for Mule ESB helps you get control over your infrastructure by providing the following features:

Registry: automatically detects and displays dependencies among services and manages service lifecycles.

Repository: stores and manages artifacts (including Mule configuration files, web services frameworks, and any other artifact), providing version management and collaborative comments, and allows you to publish the artifacts in a web browser using the Atom Publishing Protocol.

Governance: provides a centralized control point for policy management and compliance, ensuring that your SOA adheres to your firm's policies.

(24)

Compatible Technologies Chapter 1 Introduction to Mule ESB

The service registry can be deployed either alongside Mule or as a standalone component in an enterprise's SOA infrastructure. The service registry is available with Mule ESB

Enterprise. It is based on the open-source Mule Galaxy project, which can be used with the community edition of Mule ESB.

Monitoring Mule Instances Using JMX

JMX is a simple and standard way to manage applications, devices, services, and other resources. JMX is dynamic, so you can use it to monitor and manage resources as they are created, installed, and implemented. You can also use JMX to monitor and manage the Java Virtual Machine (JVM). The JMX agent is useful for integrating Tivoli or HP OpenView with Mule.

Compatible Technologies

Following are the technologies that are known to work with Mule.

Operating Systems

Linux Windows Solaris AIX HP-UX Mac OS X

Application Servers

Standalone Tomcat WebLogic WebSphere Geronimo JBoss Jetty

(25)

Chapter 1 Introduction to Mule ESB Compatible Technologies Resin

Containers

EJB 3 jBPM Spring

JMS Servers

ActiveMQ FioranoMQ JBossMQ OpenJMS OpenMQ Oracle AQ SeeBeyond SonicMQ Sun JMS Grid SwiftMQ TIBCO EMS WebLogic JMS

Developer Tools

Ant

Data Mapper (Eclipse IDE, Oakland)

Eclipse

Japex

Maven

Mule IDE

(26)

Compatible Technologies Chapter 1 Introduction to Mule ESB

Transports

Abdera Amazon SQS Axis BPM CICS CTG CXF Email FTP Hibernate HTTP/S IMAP/S JCR JDBC Jersey Jetty/Jetty SSL JMS LDAP Multicast POP3/S Quartz Restlet RMI SalesForce SAP Servlet SMTP/S SOAP STDIO TCP UDP VM XMPP WSDL

(27)

Chapter 1 Introduction to Mule ESB Compatible Technologies

Security

WS-Security Acegi Jaas PGP Spring Security

Databases

Derby MySQL Oracle

Web Service Technologies

Axis

Atom

CXF

.NET Web Servces

REST SOAP WS-Addressing WS-Policy WS-Security WS-I BasicProfile WS-I SecurityProfile WSDL

Languages

Groovy Java JavaScript Jaxen JRuby

(28)

Compatible Technologies Chapter 1 Introduction to Mule ESB JXPath Jython (Python) OGNL RegEx SXC XPath XQuery

Data Formats

Atom Base 64 encoded Byte arrays CSV EDI Encrypted GZIP Hex strings HTML / XHTML Java objects JAXB JSON Streaming Strings XHTML XML XML entity encoded

Deployment Topologies

ESB Client/Server Peer-to-Peer

Enterprise Service Network

Hub and Spoke

(29)

Chapter 1 Introduction to Mule ESB Summary

Event Handling

Asynchronous Routing Patterns SEDA Streaming Synchronous Transactions

Summary

Mule ESB provides a messaging framework that enables exchange of data among

applications. The application functionality is wrapped as a service, which includes a service component (the business logic that processes the data), routers (which use endpoints to specify where to send the message), and other configuration settings. Transports carry the messages on different channels from service to service, and transformers convert the messages and data as needed along the way.

Mule ESB is not a replacement for existing application frameworks. Instead, Mule ESB leverages many open source projects such as Apache CXF, Spring, and ActiveMQ and fills a void in enterprise Java development where an application requires complex interactions with a variety of systems on a variety of platforms. Mule ESB makes light work of wiring systems together in a robust, decoupled environment with little to no code and provides the necessary support to route, transport, and transform data to and from these systems. This chapter provided an introduction to the Mule ESB architecture. Now, read Chapter 2, “Installing and Running Mule,” for more detailed information on how to download, install, and get started using Mule.

(30)

Chapter 2

Installing and Running Mule

This chapter describes how to get started using Mule. For full details, see the Mule User Guide at:

http://mule.mulesource.org/documentation/display/MULE2USER/Home This chapter contains the following sections:

“Installing Mule” on page 30

“Setting Up Eclipse” on page 38

“Installing and Configuring Mule IDE” on page 43

“Running Mule” on page 46

“Basic Usage” on page 47

“Where Do I Go Next?” on page 49

Installing Mule

This section describes how to download and install the three types of Mule distributions. Install the third-party software and set up your environment first, and then follow the installation instructions for the distribution type you are downloading.

Note If you need to upgrade from a previous release of Mule, see “Existing Users” on page 8.

(31)

Chapter 2 Installing and Running Mule Installing Mule

Distribution Types

There are three types of Mule distributions. The distribution you choose depends on your business needs and current phase of development.

MuleSoft supported release (Mule Enterprise): the latest, fully tested release of Mule ESB created by MuleSoft that includes premium features not found in the community release. Mule Enterprise provides access to technical support, maintenance patches, and the MuleSoft knowledge base and is suitable for development, pre-production, and production environments alike.

If you have purchased a license for Mule Enterprise, log in to the customer portal at http://mulesupport.mulesource.com/portal/login.mule, and then click

Downloads. If you are evaluating Mule, you can download the 30-day trial of Mule Enterprise at http://www.mulesoft.com/mule-esb-enterprise-trial-download.

Latest stable community release: the latest stable release of the community release of Mule ESB. This distribution is suitable for people who are evaluating Mule ESB in development or pre-production environments. (Mule Enterprise is the best choice for production environments.) To download the community release, go to

http://www.mulesource.org/display/MULE/Download

Snapshot release: the latest Mule distribution built against the very latest code base (“the bleeding edge”). Snapshot releases may be unstable, so they are intended for development environments only, not for production environments. Additionally, snapshot releases do not include any documentation. To download a snapshot release, go to

http://www.mulesource.org/display/MULE/Download

You can also download the source code and build Mule yourself. For complete information, see “Setting Up the Development Environment”

(http://www.mulesoft.org/documentation/display/MULECDEV/Setting+Up+the+ Development+Environment) and “Building from Source”

(http://www.mulesoft.org/documentation/display/MULECDEV/Building+from+S ource).

Note If you download one of the compressed distributions, you will need a compression tool such as WinZip (Windows) or GZip (Linux/UNIX) to decompress the ZIP or TAR file.

(32)

Installing Mule Chapter 2 Installing and Running Mule

Compatible Platforms

Users run Mule on many different operating systems with a variety of messaging platforms and application servers. The following table lists the platforms that members of the community have reported are compatible with Mule.

Installing Third-Party Software

Before you install and run Mule ESB, you must install Java and Maven.

Note If you are using UNIX, log in as a non-root user before you proceed. This will ensure that your environment and Mule installation can support Mule HQ if you decide to install it later, as Mule HQ requires that you log in as a non-root user before you install it.

Compression Tool: If you will be downloading one of the compressed Mule distributions, make sure you have a compression tool installed such as WinZip (Windows) or GZip (Linux/UNIX) to decompress the ZIP or TAR file.

Java: Install Java Developer Kit (JDK) 1.5. Note that JDK 1.4.x will work if you are not using CXF or building Mule from the source code, but JDK 1.5.x is highly

recommended. Run the installer, following the instructions that appear on the screen. You can download JDK 1.5 from

http://java.sun.com/javase/downloads/index_jdk5.jsp

If you are using the Mule IDE, you must also endorse the JDK with a proper JAXP (Java API for XML Processing) implementation. To do this, download Apache Xerces and Xalan and drop the JARs into your JVM's jre/lib/endorsed directory. If that directory does not yet exist, create it.

Technology Platforms

Operating Systems Windows XP SP2, Windows 2000, Windows 2003 Server (32-bit if using the Java Service Wrapper), Linux, Solaris, AIX, HP-UX, and Mac OSX

Application Servers Tomcat, JBoss, WebSphere, WebLogic, and Jetty

Messaging Any JMS vendor; users have reported integration with Active MQ, Open MQ, TIBCO EMS, TIBCO Rendezvous, Oracle AQ, and IBM WebSphere MQ

(33)

Mule IDE: If you are installing the Mule IDE, install it immediately after installing Mule—see I“Installing Mule” on page 30.

Maven: If you do not want to use the Mule IDE, or if you will be using the Maven archetypes to create a new transport or module, install Maven.

z Download the Maven distribution from the Maven web site

(http://maven.apache.org/) and unpack it to any folder (for example, c:\Apache). Since there were some critical bugs in earlier versions, Maven 2.0.9 is recommended. If you are using a Macintosh, you must use Maven 2.0.9.

z Create a Maven repository directory with no spaces in the path, such as

c:\.m2\repository on Windows. (If Windows Explorer does not allow you to create the .m2 folder name, use the mkdir command in a console window instead.)

z Open the settings.xml file in your Maven conf directory (e.g.,

c:\apache-maven-2.0.9\conf) and specify the repository directory. For example: <localRepository>c:/.m2/repository</localRepository>

Ensure that this entry is not commented out in this file.

Ant: If you want to use Ant to build the examples instead of Maven, download and install it if you have not done so already.

You can download Ant from http://ant.apache.org/bindownload.cgi.

Setting Up Your Environment

Before you can use Mule, you must create environment variables for Java, Maven, Ant (optional), and Mule, and update your path to point to their bin directories. If you intend to run Mule as a Windows service, you must create system environment variables instead of user environment variables.

1 Create an environment variable called JAVA_HOME and set it to the directory where the JDK is installed.

2 Create an environment variable called MAVEN_HOME and set it to the directory where you unpacked Maven.

3 Create an environment variable called MAVEN_OPTS and set it to -Xmx512m -XX:MaxPermSize=256

4 If you will use Ant, create an environment variable called ANT_HOME and set it to your Ant home directory.

(34)

5 Create the MULE_HOME environment variable and set it to the location where you will install Mule. If you are running Windows, the installation path must not contain any spaces (for example, you cannot use C:\Program Files). A good workaround is to create a root directory called Mule (for example, C:\Mule). This step is not required if you will use the Mule IDE.

6 Update the PATH environment variable so that it includes the path to the JDK, Maven, and Mule binaries.

If you are using Windows, you can use the System utility in the Control Panel to add the environment variables and edit your path. Alternatively, you can use the export or set commands (depending on your operating system) at the command prompt, as shown in the following examples:

Linux/UNIX

export JAVA_HOME=/opt/java/jdk

export MAVEN_HOME=/opt/apache/maven-2.0.9

export MAVEN_OPTS='-Xmx512m -XX:MaxPermSize=256m' export MULE_HOME=/opt/mule

export PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin:$MULE_HOME/bin

Windows

set JAVA_HOME=C:\Program Files\Java\jdk set MAVEN_HOME=C:\Apache\maven-2.0.9

set MAVEN_OPTS='-Xmx512m -XX:MaxPermSize=256m' set MULE_HOME=C:\Mule

set PATH=%PATH%;%JAVA_HOME%/bin;%MAVEN_HOME%/bin;MULE_HOME/bin

You are now ready to install Mule. If you are installing Mule Enterprise, read the next section. If you are installing the community or snapshot release, skip ahead to “Installing the Community or Snapshot Release” on page 36.

(35)

Installing Mule Enterprise

This section describes installation of Mule Enterprise on Windows or Linux/UNIX. Follow the instructions for the version of the file you downloaded, and then set up your Maven repository.

To install the TAR.GZ:

1 If you downloaded the TAR.GZ version of Mule Enterprise, simply decompress the files into the Mule home directory you specified above.

You must use a decompression utility like WinZip, not just the built-in Windows extractor.

2 When you have finished, do one of the following:

z If you will use the Mule IDE, see “Installing and Configuring Mule IDE” on page 43.

z If you will use Maven, skip ahead to “Setting Up the Maven Repository” on page 36.

z Otherwise, go to the section on “Running Mule” on page 46.

To install the JAR

1 If you downloaded the JAR version of Mule Enterprise onto Windows, double-click the file to launch the installer. If you do not have Java associated with JAR files by default, open a command prompt, navigate to the directory where you downloaded the JAR file, and then enter the following command:

java -jar mule-enterprise-standalone-installer-version.jar where version is the version number in the file name.

2 Follow the instructions in the installer to install Mule. You will also be given options for installing the Profiler pack, which helps you identify memory leaks in your custom Mule extensions, and the scripting module, which provides facilities for using scripting languages in Mule.

3 When you are prompted to specify the installation directory, be sure to specify the same directory as you specified for the MULE_HOME environment variable.

4 Do one of the following:

z If you will use the Mule IDE, see “Installing and Configuring Mule IDE” on page 43.

Note These instructions are for Mule Enterprise only. For the community or snapshot releases, skip to the next section.

(36)

z If you will use Maven, skip ahead to “Setting Up the Maven Repository” on page 36.

z Otherwise, go to the section on “Running Mule” on page 46.

Setting Up the Maven Repository

You are now ready to set up your Maven repository as follows. These steps are not required if you will use the Mule IDE to configure Mule (see “Installing and Configuring Mule IDE” on page 43), but they are required if you will use the Maven archetypes to create new projects, transports, and modules.

1 Open a command prompt and navigate to the Mule bin directory.

2 Type populate_m2_repo.cmd followed by the location of the Maven repository directory (the same directory you specified in the settings.xml file when you installed Maven). For example:

cd c:\mule\bin

populate_m2_repo.cmd c:\.m2\repository

This step is required to populate the Maven repository with the local Mule Enterprise JAR files from the distribution. Note that when you add Mule Enterprise-only features to your code, you must add the correct dependencies to your POM before building your project with Maven. For more information, see “Dependencies” on the Using Maven page at

http://www.mulesoft.org/documentation/display/MULECDEV/Using+Maven#Us ingMaven-Dependencies.

You have completed the Mule installation and setup. You can now skip the next section and go to “Setting Up Eclipse” on page 38.

Installing the Community or Snapshot Release

This section describes installation of the community or snapshot release on Windows or Linux/UNIX.

1 If you have a previous release already installed, you should delete the directory where it is installed before installing the later release.

2 Go to the Mule download page at:

(37)

3 Click the link next to the release you want to download. Use the .zip links for installing on Windows and the .tar.gz links for installing on Linux/UNIX. The latest releases are at the top of the page.

4 On Linux/UNIX, if you prefer to download through a shell instead of a browser or need to download to a remote computer without X-Windows, you can download the

distribution using your download tool. For example to download the Mule 2.0.1 snapshot using wget, you would enter the following command all on one line: wget http://snapshots.dist.codehaus.org/mule/org/mule/distributions /mule-full/2.0.1-SNAPSHOT/mule-full-2.0.1-SNAPSHOT.tar.gz

5 After the distribution is downloaded, extract its files into the MULE_HOME directory you specified when setting up the environment variables (see page 33). For example, on Linux/UNIX, you would switch to your MULE_HOME directory, and then enter a command like this to extract the files:

tar -xvzf mule-full-2.0.1-SNAPSHOT.tar.gz

Installing Multiple Instances

After installing Mule, you can install multiple secondary instances on the same machine, allowing users to set up their own directories for configuration files, logs, and JAR files that interact with the primary Mule installation. On UNIX machines, you can use the

setup_local_instance.sh script in the Mule bin directory to set up these secondary instances. If you are installing on Windows, or if you want to configure the secondary instances manually, take the following steps:

1 Run Mule from the primary instance so that the license acceptance and third-party libraries will be properly configured and available for secondary instances. If you are running the enterprise version of Mule, also apply the license to the primary instance before setting up the secondary instance.

2 Log in as the user who will use a secondary instance.

3 Create a directory for the secondary instance with the following subdirectories:

z /bin - Startup scripts

z /conf - Local configuration files

z /examples - Examples (optional)

z /lib/user - User JARs

(38)

Setting Up Eclipse Chapter 2 Installing and Running Mule

4 Copy the files from these subdirectories in the primary Mule instance to the

corresponding subdirectories in the secondary instance directory. For example, if your primary Mule instance is in C:\Mule and your secondary instance is in C:\Mule2, you'd copy C:\Mule\bin to C:\Mule2\bin, copy C:\Mule\conf to C:\Mule2\conf, and so on.

5 Create an environment variable called MULE_BASE that points to the secondary instance directory, and create an environment variable called MULE_HOME that points to the location of the primary Mule installation. Using the previous example, you would set MULE_BASE to C:\Mule2 and set MULE_HOME to C:\Mule.

6 Add the MULE_BASE/bin directory to the system path so that the Mule startup script is launched from MULE_BASE instead of MULE_HOME.

7 Repeat these steps for each user who will use a secondary Mule instance. Each secondary instance must be in its own directory, and you must set the MULE_BASE and MULE_HOME environment variables separately for each user.

When users run Mule, the files from their secondary instance (MULE_BASE directory) will be loaded first, allowing users to put updated JARs in their MULE_BASE directory and test different scenarios without affecting the primary instance.

Setting Up Eclipse

When you work with Mule, you can make configuration and development much easier by using an IDE. This section describes how to set up Eclipse, an open-source IDE, to enable easy configuration of Mule and development of new functionality. This section describes using Eclipse 3.4 (Ganymede), which you can download from

http://www.eclipse.org/downloads/packages/ (download the Eclipse IDE for Java EE Developers). It contains the following sections:

“Prerequisites” on page 39

“Build the Hello Application” on page 39

“Generate the Eclipse Project” on page 39

“Configure Eclipse” on page 39

“Import the Eclipse Project” on page 41

“Configure the Eclipse Build Path” on page 41

(39)

Chapter 2 Installing and Running Mule Setting Up Eclipse

Prerequisites

Before you continue, be sure you have installed Mule and the prerequisites as described earlier in this chapter. You must also have Internet access to build the example application and generate the Eclipse project, as each of those steps downloads dependencies.

Build the Hello Application

The first step is to build the application you want to work with in Eclipse. This will download the dependencies in preparation for generating an Eclipse project. For the sake of illustration, we will build and import the Hello example application into Eclipse.

To build the example, navigate to the MULE_HOME\examples\hello directory, and then type mvn at the command prompt.

Generate the Eclipse Project

After building the Hello application, you can generate the Eclipse project by typing the following command:

mvn eclipse:eclipse

You can now configure Eclipse and import the project.

Configure Eclipse

You only need to configure Eclipse once. With subsequent projects, you can skip these steps.

1 Start Eclipse.

2 In the Workspace Launcher, specify the location of the examples directory under your Mule home directory (such as C:\mule\examples), and click OK.

3 Click the Workbench icon on the right to display the workbench.

(40)

5 Expand Java in the navigation tree, click Compiler, and then change the compiler compliance level to 1.5.

6 Click Installed JREs. If the JRE is not version 1.5, click Edit, click Directory and navigate to your JDK1.5 directory, and then change the JRE name to jdk5. Click Finish, and then click OK.

(41)

Chapter 2 Installing and Running Mule Setting Up Eclipse

Import the Eclipse Project

1 In the Workbench window of Eclipse, choose File > Import.

2 Expand General, click Existing Projects into Workspace, and then click Next.

3 In the Import dialog box, click Browse, navigate to the Mule examples directory again, and click OK. The hello project should be listed and selected.

4 Click Finish.

The hello project is now listed in the Project Explorer on the left. You will notice some errors at the bottom of the screen, which are caused by your build path needing to be configured.

Configure the Eclipse Build Path

(42)

1 In the Project Explorer, right-click the hello project and choose Build Path > Configure Build from the popup menu.

2 In the Properties dialog box, click the Libraries tab, and then click Add Library.

3 Click User Library and click Next.

4 Click User Libraries, and then in the Preferences dialog box, click New.

5 In the New User Library dialog box, enter MULE_LIB and click OK.

6 Click Add JARs, navigate to the \lib\mule directory under your Mule home directory, select all the JARs, and click Open.

7 Click OK and then Finish.

8 Click Add Variable, click Configure Variables, and then in the Preferences dialog box, click New.

9 In the New Variable Entry dialog box, create a variable called M2_REPO that points to your Maven repository (such as C:\.m2\repository), which you created when you installed Maven. Click OK.

10In the Preferences dialog box, click OK, and this time when you're prompted to rebuild, click Yes. Click OK in the open dialog boxes to close them and rebuild the project.

Create a Run Configuration and Run the Application

This step defines your configuration settings. You only have to do this once per project, and thereafter your settings are stored and used each time your run the application.

1 Choose Run > Run Configurations.

2 In the left window, double-click Java Application, and then change the name to hello and specify org.mule.MuleServer for the main class.

(43)

Chapter 2 Installing and Running Mule Installing and Configuring Mule IDE

3 Click the Arguments tab, and then enter -config conf\hello-config.xml (for Windows) or -config conf/hello-config.xml (for Linux/UNIX) in the Program Arguments box.

4 Click Apply and then Run.

The Hello application runs in the Console tab at the bottom of the window, prompting you to enter your name. You can type your name and press Enter to see the application continue. Congratulations! You have successfully built and run your first Mule example from within Eclipse. You can now add services to the configuration, write POJOs as needed, debug your code, and compile and run your examples all within the IDE.

If you want to import another example into Eclipse, repeat the instructions to generate an Eclipse project for that example, import the project into the workspace, and then just run the example by choosing Run > Run. You do not have to repeat the steps for configuring Eclipse.

Installing and Configuring Mule IDE

Mule IDE is a development and testing environment based on Eclipse. It allows you to easily create or edit a Mule project or configuration file in Eclipse. If you want to use Mule IDE and Eclipse, follow the instructions in this section.

Prerequisites

Before you install Mule IDE, ensure that you have installed the following software:

Eclipse 3.4 (Ganymede) or later (see “Setting Up Eclipse” on page 38).

Java 5 or later. You can download Java from

http://java.sun.com/javase/downloads/index_jdk5.jsp.

Mule 2.2 or later (see “Installing Mule” on page 30). Note that you do not have to install and configure Maven or Ant if you are using Mule IDE, but you must install Maven if you want to use the Maven archetypes to create transports and other projects. You can ignore the information on that page about running Mule, as you will run Mule from within Eclipse instead of at the command prompt.

(44)

Installing and Configuring Mule IDE Chapter 2 Installing and Running Mule

You must also endorse the JDK with a proper JAXP (Java API for XML Processing) implementation. To do this, download Apache Xerces

(http://xerces.apache.org/xerces2-j/) and Xalan

(http://xml.apache.org/xalan-j/) and drop the JARs into your JVM’s jre/lib/endorsed directory. If that directory does not yet exist, create it.

Installing Mule IDE

You are now ready to install Mule IDE. Use the set of instructions that apply to your version of Eclipse. Before installing, you should first ensure that your existing Eclipse plug-ins are up to date, as Mule IDE depends on specific versions of the Eclipse libraries and the installation will not complete if these are not present.

Installing Mule IDE (Eclipse Galileo)

1 Start Eclipse, and set up a workspace for your installation of Mule if you haven't already. (Make sure your workspace does not have a space in the directory path)

2 In the workbench view, choose Help > Install New Software.

3 Click Add next to the Work with text box, enter

http://dist.muleforge.org/mule-ide/updates/3.4/, and click Enter.

4 Click the Mule IDE check box and click Next, and after Eclipse processes for a moment, click Next again.

5 Review the IDE license, select the option to accept the license, and then click Finish.

6 Click Yes to restart Eclipse.

You are now ready to configure the Mule distribution as described in “Configuring the Mule Distribution” on page 45.

Installing Mule IDE (Eclipse Ganymede)

1 Start Eclipse, and set up a workspace for your installation of Mule if you haven't already. (Make sure your workspace does not have a space in the directory path)

2 In the workbench view, choose Help > Software Updates, and then click the Available Software tab.

3 If you previously installed a preview release of Mule IDE 2.0, click Manage Sites, select the Mule IDE update site, click Remove, and then click OK.

(45)

Chapter 2 Installing and Running Mule Installing and Configuring Mule IDE

5 Specify http://dist.muleforge.org/mule-ide/updates/3.4/ for the location and click OK. It now appears in your list of available software.

6 Expand it in the list until you see Mule IDE. Click Mule IDE and click Install.

7 If you are installing an update of Mule IDE, a screen appears saying that an update will be performed instead. Click Next, read and accept the license agreement terms, and click

Finish. You should restart Eclipse before you continue.

You are now ready to configure the Mule distribution as described in the next section.

Configuring the Mule Distribution

You specify the location of a Mule 2.x distribution in Eclipse so that Mule and third-party libraries will be automatically added to Mule project classpaths. This distribution will also be used when launching a Mule server instance to test and debug your application.

To configure a Mule distribution:

1 In the Eclipse workbench, choose Window > Preferences.

2 Click Mule, and then click Add.

3 Specify the root directory where the Mule distribution is installed, and then click OK.

4 Click the distribution’s check box, and then click Apply. This distribution is now the default Mule distribution. You can configure multiple Mule directories, but only one can be the default.

You are now ready to start Eclipse and start using Mule IDE as described in Chapter 3, “Tutorial” and Chapter 4, “Using Mule IDE.”

Troubleshooting

If you have difficulty installing or using Mule IDE, verify the following:

You have the correct update site and have uninstalled any developer preview releases.

Does your workspace directory or project name have a space in it? Mule runs from the workspace folder, and if it has a space in the name (like Documents and Settings), Mule cannot locate the configuration file to start.

(46)

Running Mule Chapter 2 Installing and Running Mule

If you cannot successfully complete the installation steps, remove and recreate the update site. To remove a site in Eclipse, choose Help > Software Updates, on the Available Software tab click Manage Sites, select Mule IDE, and then click Remove. You can now recreate the Mule IDE site following the steps above.

Have you updated the other libraries in your eclipse installation? Make sure all of your existing standard Eclipse plug-ins are up to date.

Ensure you followed the documented steps to register the endorsed XML libraries and have also previously installed Mule. You will need to configure the location of Mule the first time you create a Mule project.

Running Mule

Now that you have installed and configured Mule, you are ready to get started! This section describes how to run Mule. If you installed Eclipse, see “Create a Run Configuration and Run the Application” on page 42 instead.

Note If you are using the 30-day trial version of Mule Enterprise, you will not be able to run the trial version after the 30 days has expired unless you purchase a license. (This does not affect the community release of Mule.) For information on purchasing Mule Enterprise, go to http://www.mulesource.com/buynow/.

The simplest way to run Mule is to enter the following command at the command prompt: mule [-config your-config.xml]

where your-config.xml is the Mule configuration file you want to use. For a quick start, use one of the configuration files in the Examples subdirectories to see how this works. For more information on examples, see http://mule.mulesource.org/x/wAm7.

To get up and running quickly with developing a Mule application using an example application, see Chapter 3, “Tutorial.”

If you are running the community release of Mule, the MuleSoft Public License is displayed page by page when you first run Mule. To advance a page, press Enter. At the end of the license display, type y to accept the license file and proceed with startup.

For more information on ways you can run Mule, see http://mule.mulesource.org/x/gQi7.

(47)

Chapter 2 Installing and Running Mule Basic Usage

Basic Usage

When you look at how a message flows through Mule, 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 POJOs, services, or beans that contain the business logic and will be used as service components in a Mule deployment.

Integration: developing routers, transformers, and filters, and configuring everything in the Mule configuration file.

Extending Mule: developing new transports, connectors, and other modules used by Mule.

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

HTTP Transport

Message Message JMS Transport Service HTTP Channel JMS Channel XML to Java Object Transformer Customer Data Service

Component Application _Layer

Integration Layer

Transport Layer

(48)

Basic Usage Chapter 2 Installing and Running Mule

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 framework. You can use any existing application, or create a new one. 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 should use an IDE such as Eclipse. For a tutorial on setting up Eclipse and creating a new service, see Chapter 3, “Tutorial.”

For more information on developing service components, see: http://mule.mulesource.org/x/2IDR

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 configure the connectors, transformers, and endpoints you'll use in different services. Lastly, you configure models, which act as containers for services and apply settings such as the queue profile to all the services in that model. For complete information, see http://mule.mulesource.org/x/W4LR.

Configure the Service

You 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: http://mule.mulesource.org/x/XAKV Following is more information on configuring routers, filters, and transformers for the service.

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: http://m

Mule Getting Started Guide