The Fundamentals of Mule Configuration, Page 3
Using the Mule ClientThe Mule client is a simple interface for Java clients to send and receive messages programmatically from a Mule server and other applications. In general, messages are triggered by an external occurrence such as a message being received on a queue or a file being copied to a directory.
The Mule client helps test the message flow by injecting messages for unit or load testing. If you use the Mule client in the same classloader (e.g., a web app or Mule standalone), the client will have access to the server configuration. For example, if you had this endpoint defined in your server configuration file:
<http:endpoint host="192.168.0.1" port="80" path="/services" name="serviceEndpoint"/>Then this endpoint would be accessible by the Mule client:
MuleClient client = new MuleClient(); client.dispatch("serviceEndpoint", dataObject, null);If you are running the Mule client in standalone mode, you configure it with its own Mule XML configuration file and pass in these files when the client is created:
MuleClient client = new MuleClient("http-client-config.xml, shared-client-config.xml"); client.getMuleContext().start();
Putting It All TogetherMule uses the configuration file to determine the data flow, as well as which components, routers, transports, and transformers to use (see Figure 8). An endpoint defines the transport to use. Below is the flow of an event through a Mule application:
- A client initiates the process by invoking a URL (such as http://mycompany/order:8081).
- A declared HTTP Inbound transport picks up the message and checks if any transformation of the input (the URL in this case) is specified in the inbound router.
- If transformation is needed, a transformer such as HttpRequestToNameString is applied to the message.
- The message is dispatched to the service component for business processing.
- The Customer Data Service component retrieves customer information from a database.
- The outbound router routes the result of the service component to determine where the message should be dispatched. For example, an outbound router may specify a JMS endpoint so that the message is put on a queue or a topic.
- The outbound transport picks up the message and checks if any transformation is needed. The inbound router of the receiving service receives the message, and processing continues with the message as in step 2.
Click here for larger image
Figure 8: Data Flow in Mule
Working with mule-config.xmlA Mule configuration file is organized as a tree of XML elements with the following basic tags:
- <model> Defines the services within an application
- <service> Configures a service
- <description> Describes a service for human viewing
- <inbound> Configures the inbound routers, their endpoints, and inbound transformers
- <outbound> Configures one or more outbound routers, their endpoints, and outbound transformers
- <async-reply> Configures an asynchronous reply router, which is used for asynchronous request/response messaging
- <exception-strategy> Configures the error-handling strategy on the connector or model or a service
<mule> <model> <service name="GreeterUMO"> <inbound....> <filtering-router> .... </filtering-router> </inbound> <component..../> <outbound....> ....... </outbound> <default-service-exception-strategy> ..... </default-service-exception-strategy> </service> <service name="GreeterUMO2" initialState="stopped"> ... </service> </model> </mule>
Page 3 of 4