[SOA] Getting started with mule ESB 3.x (1) -- message stream

About mule ESB, in short, mule accepts a message and processes the message in a certain order. Such processing can lead to multiple results. Sometimes, mule changes or transforms the message and returns it to the original message source (request-response ). Or, send the form to one or more third parties (router, transfer) based on the original one ). In other cases, if the message does not meet the specific requirements, mule can reject the message validation and throttling ).

From 3.0, mule uses flow as the unit to control the message stream (<service> is used in mule 2.x), and mule ide assembles the flow through visualized flow blocks. Like an MPS queue, messages flow from one end to the other. A flow message is defined as a mulemessage in mule. Its structure is like the following:

It consists of three parts: 1. header (message header): Attributes divided by range; 2. Payload (Message Body); 3. attachments (Attachment ). We can read or set the content programmatically in flow blocks. In mule development, you will encounter a concept: "Transport barrier ). For example, there is no "Transport barrier" in the subprocess, and the "Transport barrier" must be crossed across endpoints ". The range-based attributes of message headers have the following features:

Mule inbound Properties

• Inbound properties cannot be modified.
• Inbound properties is set by the message source (such as the inbound endpoint)
• Inbound properties lost when crossing "Transport barrier"

Mule outbound Properties

• Outbound properties can be set
• The outbound properties is automatically changed to inbound properties when the traffic obstacle is crossed.

Mule invocation Properties

• Invocation properties can be set
• Invocation properties is lost when crossing "Transport barrier"

Mule session Properties

• Session properties can be set
• Session properties will remain valid even when it crosses the "Transport barrier"

Mule flow variable

• They are like instance attributes.

Mule session variable

• They are like session properties.

Based on the above attributes, you can know where the attributes of the request are stored, and how to control the attributes of response.
The following is a common flow -- Request-response in mule development.

A simple example: When the access address is exposed through the HTTP endpoint, the request submitted by the client is processed by testflow1 and the response is returned. Some logs are recorded in the middle.

    <flow name="mule-maven-testFlow1" doc:name="mule-maven-testFlow1">        First, use logger component to record the request header information, and then send it to groovy to construct response to return.
def contentType = message.getInboundProperty("Content-Type");def response = "";if (contentType == "application/xml") {response = "<string>hello world</string>"} else {response = '{"string":"hello world"}'}response
The Groovy script determines that if the Content-Type of the request is application/XML, the XML content is returned. If the request is application/JSON, The JSON content is returned.
Use Fiddler to simulate the client to send a GET request to http: // localhost: 8089/test:
You can view the received message header in the mule ide console:
Info 2013-08-11 23:08:50, 473 [[mule-Maven-test]. connector. HTTP. mule. default. receiver.03] Org. mule. API. processor. loggermessageprocessor: {HTTP. request =/test, host = localhost: 8089, HTTP. method = get,HTTP. headers = {Host = localhost: 8089, User-Agent = Fiddler, keep-alive = false, connection = false, content-type = application/XML}, HTTP. relative. path =, User-Agent = Fiddler, HTTP. request. path =/test, mule_originating_endpoint = endpoint. HTTP. localhost.8089.test, connection = false, HTTP. query. string =, HTTP. context. path =/test, HTTP. context. uri = http: // localhost: 8089/test, HTTP. version = http/1.1, HTTP. query. params = {}, mule_remote_client_address =/0: 0: 0: 0: 0: 0: 0: 1: 24210, keep-alive = false, content-Type = application/XML}: <logger message = "# [headers: Inbound: *]" level = "info" DOC: name = "logger headers"/> output all inbound headers attributes (MAP) <logger message = "# [headers: Inbound: Host]" level = "info" DOC: name = "logger header property"/> output an attribute in the inbound header <logger message = "# [GROOVY: Message. getinboundproperty ('host')] "level =" info "DOC: name = "logger host value"/> directly outputs the value of a property in inbound property <logger message = "# [GROOVY: Message. tostring ()] "level =" info "Doc: Name =" logger message "/> output mule message
(Note: directly # [GROOVY: Message] Or # [message. tostring ()] is not easy to use, it only outputs the reference address of the object.) In most scenarios, direct output of mule message is more tracing valuable. The structure of the printed mule message is as follows, you can clearly observe the changes of message in flow.
org.mule.DefaultMuleMessage{  id=edced872-0297-11e3-ada6-610a86bd1f23  payload=java.lang.String  correlationId=<not set>  correlationGroup=-1  correlationSeq=-1  encoding=UTF-8  exceptionPayload=<not set>Message properties:  INVOCATION scoped properties:  INBOUND scoped properties:    Connection=false    Content-Type=application/xml    Host=localhost:8089    Keep-Alive=false    MULE_ORIGINATING_ENDPOINT=endpoint.http.localhost.8089.test    MULE_REMOTE_CLIENT_ADDRESS=/0:0:0:0:0:0:0:1:24210    User-Agent=Fiddler    http.context.path=/test    http.context.uri=http://localhost:8089/test    http.headers={Host=localhost:8089, User-Agent=Fiddler, Keep-Alive=false, Connection=false, Content-Type=application/xml}    http.method=GET    http.query.params={}    http.query.string=    http.relative.path=    http.request=/test    http.request.path=/test    http.version=HTTP/1.1  OUTBOUND scoped properties:    MULE_ENCODING=UTF-8  SESSION scoped properties:}
Looking back at the results captured by Fiddler, it is easy to understand the relationship between inbound properties, outbound properties, and payload.