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 following process, Mule uses the Mule configuration file to determine which components, routers, transports, and transformers to use along the way:
-
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.
-
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.
-
The XML to Object transformer converts the XML invoice into a Java object.
-
The flow passes the message with its transformed payload to the Customer Data component.
-
The Customer Data component queries the master customer database to pull additional data about the customer and updates the invoice with the data.
-
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.
-
The HTTP transport uses the configuration of the Inventory Verification flow to receive the message and pass it to the Inventory Verification component.
-
This component updates the invoice with an ID code of the warehouse that has all the items on the invoice in stock.
-
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.