Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.2)
  3. Essentials of Using Mule ESB 3
  4. Choosing Between Flows Patterns or Services
  5. Using Mule Services

  6. Configuring the Service

Configuring the Service

You configure services using a <service> element within a <model> element. Each <service> element represents and configures a Mule ESB service, providing a unique name that identifies it and optionally an initial state that determines whether the service and its endpoints are started when Mule starts (supported values are started, stopped, or paused).

<mule>
  <model>
    <service name="GreeterUMO">
      ...
    </service>

    <service name="GreeterUMO2" initialState="stopped" >
      ...
    </service>
  </model>
</mule>

Each service can be configured with the following optional elements:

  • <description>: Describes the service

  • <inbound>: Configures the inbound routers, their endpoints, and inbound transformers

  • component: Configures the service component

  • <outbound>: Configures the outbound routers, their endpoints, and outbound transformers

  • <async-reply>: Configures an async reply router, which is used for asynchronous request-response messaging

  • <exception-strategy>: Configures the exception strategy for the service

If you configure more than one of these elements, note that you must configure them in the order shown above. For detailed information on the <service> elements and attributes, see Service Configuration Reference.

Following is a sample service configuration showing these elements:

<service name="GreeterUMO">
  <description>Adds some text to the string before passing it on</description>
  <inbound>
    <stdio:inbound-endpoint system="IN">
        <transformer ref="StdinToNameString"/>
    </stdio:inbound-endpoint>
  </inbound>
  <component class="org.mule.example.hello.Greeter" />
  <outbound>
    <filtering-router>
      <vm:outbound-endpoint path="chitchatter" />
      <payload-type-filter expectedType="org.mule.example.hello.NameString" />
    </filtering-router>
  </outbound>
  <default-service-exception-strategy>
    <vm:outbound-endpoint path="systemErrorHandler" />
  </default-service-exception-strategy>
</service>

The following sections describe these elements in more detail.

Inbound

This element is used to configure inbound endpoints and inbound routers. Endpoints are used to receive incoming messages, and inbound routers determine how these messages are routed. Inbound endpoints and routers are configured separately within the <inbound> element.

Inbound Endpoints

Inbound endpoints are used to receive incoming messages. An endpoint is simply a set of instructions indicating which transport and path/address to receive messages from, as well as any transformers, filters, or security that should be applied when receiving the messages. You can configure multiple inbound endpoints, each receiving message from different transports. For more information, see Configuring Endpoints and Transports Reference.

Inbound Routers

The <inbound> element configure inbound routers. Inbound routers control and manipulate messages received by a service before passing them to the service component. Typically, an inbound router is used to filter incoming messages, aggregate a set of incoming messages, or re-sequence messages when they are received. Inbound routers are also used to register multiple inbound endpoints for a service. You can chain inbound routers together, so that each router must be matched before the message can be passed to the component. You can also configure a catch-all strategy that is invoked if none of the routers accept the current message.

For more information, see Inbound Routers.

Component

The <component> element configures the service component that will be invoked after the inbound message is processed by the inbound routers. If no component is configured, the service acts as a bridge and simply passes messages through to the outbound router.

There are several standard components you can use, such as <log-component>, which logs component invocations, outputting the received message as a string, and <echo-component>, which extends the log component to log and echo the incoming message. Typically, you will create your own component as a plain old Java object (POJO) and configure it using the <component> element.

For more information about component types and their configuration, see Configuring Components. You can also implement new component types in your Mule modules and use them within your configuration. In Mule 2.0, it is now easier to implement and use new non-Java component types and configure them with their own custom component element.

Outbound

The <outbound> element configures outbound routers and their endpoints. Because outbound routers are used to determine which endpoints to use for dispatching messages after the component has finished processing them, outbound endpoints are configured on the outbound routers, not directly on the <outbound> element. Outbound routers allow the developer to define multiple routing constraints for any given message. You can specify a catch-all strategy to invoke if none of the routers accept the current message. For more information, see Outbound Routers.

Asynchronous Reply Router

The <async-reply> element is used to configure the endpoints and routers that will be used to receive the response in asynchronous request-response scenarios where you must consolidate responses from a remote endpoint before the current service responds via its inbound endpoint. The classic example of this approach is where a request is made and then multiple tasks are executed in parallel. Each task must finish executing and the results processed before a response can be sent back to the requester. For an illustration of asynchronous request-response, click here. For more information, see Asynchronous Reply Routers and Configuring Endpoints.

Exception Strategy

Exception strategies are used to handle exception conditions when an error occurs during the processing of a message. You can configure exception strategies on services. If no exception strategy is configured, DefaultServiceExceptionStrategy is used.

For more information on exception strategies, see Error Handling.

Service Bridge

Service component configuration is optional in Mule 2.x. The default and implicit component used is PassThroughComponent. This component automatically bridges inbound messages to the outbound phase and simply passes messages to the outbound routers. This approach is useful for bridging endpoints if you want to pass a message from one transport to another.

As of Mule 2.0, you no longer need to configure an explicit BridgeComponent.

The following example demonstrates reading a file and send its contents onto a JMS topic.

<service name="FileToJmsBridge">
  <inbound>
    <file:inbound-endpoint path="/data/in">
      <file:filename-wildcard-filter pattern="*.txt"/>
    </inbound-endpoint>
  </inbound>

    <!-- No need to configure a component here -->

  <outbound>
    <pass-through-router">
      <jms:outbound-endpoint topic="receivedFiles"/>
    </pass-through-router>
  </outbound>
</service>

If you want to send a response back to the inbound endpoint, use the chaining router instead of the pass-through router in the outbound endpoint. The inbound endpoint must be synchronous.

<service name="HttpProxyService">
  <inbound>
    <inbound-endpoint address="http://localhost:8888" synchronous="true"/>
  </inbound>
  <outbound>
    <chaining-router>
      <outbound-endpoint address="http://www.webservicex.net#[header:http.request]" synchronous="true"/>
    </chaining-router>
  </outbound>
</service>

Service Model

By default, Mule uses the staged event-driven architecture (SEDA) model. SEDA is an architecture model where applications consist of a network of event-driven stages connected by explicit queues. This architecture allows services to be well-conditioned to load, preventing resources from being overcommitted when demand exceeds service capacity. As a result, SEDA provides an efficient event-based queuing model that maximizes performance and throughput.

See Models for more information about alternative models and information about how you can implement your own.

Service Messaging Style

The messaging style determines the message exchange pattern that is to to be used on inbound and outbound endpoints and allows endpoints to be configured as synchronous request/response or asynchronous in-only as well as other patterns.

The messaging style is configured on endpoints, allowing multiple styles to be used with the same service. For more information, see Service Messaging Styles.