Introduction to the basic concepts of open source ESB platform Mule

Original reproduced from: http://blog.csdn.net/neareast/article/details/11111279

Mule Basic Concepts

In the simplest case, the Mule application processes messages through a number of message processors like Lego bricks, which are grouped together as a process we call flow . Understanding the basic message structure and flow system is the key to understanding mule. Essentially, each mule flow contains a series of artifacts that receive, transmit, and process messages (building block).

This article will first introduce the flow concept of mule and then decompose the Mule message component that flows through flow. Mule Flow

In a flow, you connect several separate components together to receive, process, and ultimately route the message. Flow supports synchronous and asynchronous sub-flow, one-way and request-response switching modes, and other architecture-compliant options. You can connect a lot of flow together to create a complete application, deployed on premise. ) Mule or other application servers, or the cloud. using flow to develop

There are two ways you can build a muleflow:

Typing a few lines of code directly into an XML-based application configuration file use Mule Studio's graphical interface to organize component icons into visual sequences

Next, you use the graphics tools attached to the studio to configure these ordered artifacts, but you can also edit the XML code in the configuration file directly to configure it, or both. Anatomy of Flow

In the simplest sense, flow is the sequence of message processing events. A message entering the flow may flow through a variety of processors. In the following illustration, mule receives a message through a request-response inbound endpoint (Request-response inbound endpoint), transforms the content into a new format, and processes the business logic before returning the response through the message source.

These basic units that make up flow are often referred to as artifacts (in Mule Studio) or elements (in the XML configuration of click or Studio). In general, a widget that corresponds to an icon in Mule Studio-the icon represents a message source, processor, or component. A component is a visual representation of an XML element in an Mule application configuration file.

The following illustration shows a simple flow and its corresponding XML code in the Mule Studio Visual editor, respectively.

[HTML]  View plain copy print? <?xml version= "1.0"  encoding= "UTF-8"?>       <mule xmlns: tracking= "http://www.mulesoft.org/schema/mule/ee/tracking"  xmlns:http= "http://www.mulesoft.org/schema/ Mule/http " xmlns=" Http://www.mulesoft.org/schema/mule/core " xmlns:doc=" http://www.mulesoft.org/ Schema/mule/documentation " xmlns:spring=" Http://www.springframework.org/schema/beans " version=" EE-3.4.0 " xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " xsi:schemalocation="/HTTP/ www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd        Http://www.springframework.org/schema/beans http://www.springframework.org/schema /beans/spring-beans-current.xsd       http://www.mulesoft.org/schema/mule/core  http://www.mulesoft.org/schema/mule/core/current/mule.xsd       http://www.mulesoft.org /scheMa/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd ">    ...   </mule>   <flow name= "Simple_example_flow1"  doc:name= " Simple_example_flow1 ">       

Mule handles messages that are initialized by external resources, such as events. For example, a message can be initialized by a request from a user on a mobile device, or by an event such as a data change in the database, the creation of a new user ID in the SaaS app, and so on.

The first component in most flow is a sink that is responsible for receiving new messages and putting them into the processing queue. Mule uses a message source element-The inbound HTTP endpoint (Inboundhttp endpoint) in the previous example-to receive messages from one or more external sources, triggering the execution of a flow. A transport plane (transport) carries messages in the integration and application layer so that it gets processed.

Mule Converters (transformer) are the key to data exchange between nodes, allowing Mule to convert message payload data (PAYLOADDATA) into a format that other applications can understand. Mule is also able to enhance the content of the message, allowing you to receive additional data to be attached to the message during processing.

Mule uses components (component) for end-processing of specific business logic, such as checking customers and inventory databases. Therefore, the component routes the message to the correct application (for example, an order execution system). Mule uses a schema called the phased event-driven architecture (staged Event-driven Architecture,seda) to perform asynchronous message processing in flow as a core feature. It is worth mentioning that components do not need to use any specific mule-related code; they can be simple pojo, spring Bean,java bean,groovy scripts, or a business logic Web service that contains data processing. Components can even be developed in other languages, such as Python, JavaScript, Ruby, and PHP. The types of mule components include the most commonly used enterprise integration models.

Flow can also include filters, scopes, flow controls, error handling policies, and many kinds of cloud connectors. For more information about these kinds of flow artifacts, and details on how they can be connected to provide the exact functionality you need for your app, see Mule Application Architecture.

When you configure individual elements that are connected together to form your flow, you can use the Mule expression language to extract information about the message or its environment, and instruct mule to make processing decisions based on that information. For more information about the Mule expression language and how expressions are used in mule, see Introduction to Mule expressions.

For more details on how messages flow in flow, see Understanding the Mule system. Mule Message

Mule messages are data that flows through one or more flow through your app. It consists of two important parts:

The message header that contains the metadata for the message. Message Payload (payload), which consists of your business-specific data.

Some mule messages may contain the third part: an attachment. However, since the attachments are not commonly used, we will not repeat them here. message Header

The Mule message header contains meta data about this message. Metadata includes attributes and variables that provide useful information about the message to help it reach its destination. Properties and variables use a uniform format: Each property and variable has a name and a value. Name is used to refer to this property or variable in mule, where value is the information stored. So, name is like the key to a door, and value is anything behind the door.

The header of a message contains properties and variables that have a specific domain, define and organize how they work throughout the lifetime of the message.

The property has two primary domains: inbound and outbound.

Inbound Properties (inbound properties) is generated automatically by the message source and cannot be set or manipulated by the user. Outbound Properties (Outbound properties) can be configured by the user. The outbound attribute is set during a flow, and the outbound attribute can become an inbound property when the message passes through the transport plane from one flow's outbound endpoint to another flow's stop endpoint. (Note that if this message is passed to another flow through flow-ref instead of a transport, the outbound property is still an outbound property and will not be converted to an inbound property.) ）

The property information that is carried by the message is sent by scope to send the metadata to facilitate processing and to avoid errors when the message crosses the transport boundary-whether it is entering a new flow or being transferred to another application. The inbound attribute holds the message source-specific metadata in case the data format is confusing or other processing incidents occur after the message life cycle. The outbound attribute holds similar metadata, but the metadata is valid when the message enters flow. Outbound properties can be set automatically by mule, or manually by a developer inserting one or more converters in flow.

variables are user-defined metadata about the message. A variable has two effects on:

The flow variable exists only in the current flow. The session variable is valid in all flow in the same app.

A variable is a temporary piece of information about a message that is intended for an application to process it, rather than being sent to the destination along with the message. As a result, variables are more likely to be triggered by a person, whereas properties are more likely to be set and triggered by the system. However, there are no strict rules on how to use attributes and variables. In short, with these attributes and variables that are divided into their respective scopes, mule supports 4 of metadata that share the same key/value pair structure. These four types have different applications based on their scopes.

You can set, trigger, and manipulate outbound properties, flow variables, and session variables using the Mule expression language (Mule expressions Language,mel). Message Payload

The message payload is the most important part of the mule message because it is the content of the data that you send through the Mule app. You can use metadata in the message header to communicate information about your message, or to protect it from interference, but the core of the message-the data you want to transfer-is the reason why the message first existed.

However, there is no need for the load to remain constant as it flows through flow. Various message processors in the Muleflow can affect the load along the way, set, enrich, or convert to a new format. You can also use Mel to extract information from the payload in flow.