Using Mule Services

More flexible than Configuration Patterns but less versatile than Flows, services are the Mule 2 way of configuring integration.

A service provides a fixed framework for building integration mechanisms around the concept of inbound routers and endpoints, a single service component and outbound routers and endpoints.

To achieve complex routing or processing chains, several services, tied together by VM queues, are often needed. In contrast, a single flow element can achieve such complex integration paths.

A service component is a class, web service, or other application that contains the business logic you want to plug in to the Mule ESB framework. For example, one service component could add information to an invoice from a customer database, and another service component could be the order fulfillment application that processes that invoice. You can use any existing application for a service component, or create a new one.

Your service component does not need to contain any Mule-specific code. Instead, you configure a service, which wraps the service component with the Mule-specific configuration. The service configuration points to the service component, as well as routers, filters, and transformers to use when carrying messages to and from the service component. It also specifies the endpoint on which this service will receive messages and the outbound endpoint where messages will go next.

A service component can be a POJO, spring bean or a script. Typically, you configure your own service components, but you can also use one of the several standard components included with Mule. For more information, see Configuring Components.

Most configuration happens at the service level. Services can be configured using globally defined endpoints, transformers, and filters, or these can be defined inline. For more information, see Configuring the Service.

When a service receives a message on an inbound endpoint, the service model (default is SEDA) determines the service’s threading and queuing behavior, while the messaging pattern defines the inbound and outbound message exchange patterns that will be used.

You can further configure the service with security (configured on endpoints), transactions, and error handling.