Introduction to Open-Source ESB-mule

mule is a lightweight ESB message framework. It is an upgradeable, highly distributed object proxy that can seamlessly process interactions between services and applications through asynchronous message transmission technology.
the mule framework provides an upgradeable environment where you can deploy your business components. Mule manages the interaction between all components, regardless of whether they are in the same virtual machine or on the Internet, or the underlying transmission mode.
mule is designed around the Enterprise Service Bus (ESB) architecture to ensure that different components or applications can interact with each other through the public message bus, the public message bus is generally implemented by JMS or other message servers.

its main features include:
1. enterprise message bus (ESB) and Message Broker Based on j2ee1.4 ).
2. pluggable Connectivity: for example, JMS, JDBC, TCP, UDP, multicast, HTTP, Servlet, SMTP, POP3, file, XMPP, etc.
3. supports asynchronous, synchronous, and request RESPONSE event processing mechanisms over any transmission.
4. web service that supports axis or glue.
5. flexible deployment structure [topologies] includes Client/Server, P2P, ESB and enterprise service network.
6. integration with the Spring framework: it can be used as an ESB container and can be easily embedded into spring applications.
7. use highly scalable Enterprise Servers Based on the Seda processing model.
8. powerful Event Routing Mechanism Based on EIP mode.

Bytes ----------------------------------------------------------------------------------------------------------
Several rankings in mule:

1 connectors: a connector that supports different protocols. For example, HTTP, FTP, mail, soap, JMS, and MQ. There are usually three types of connectors: for receiving only, for sending only, and for both.

2 endpoints address: terminal address, something similar to JMS: // topic: mytopic. The previous JMS is the connector type. Each connector can recognize other addresses. This address can be the address recognized by the receiver. For example, JMS: // topic: mytopic indicates listening to the queue of mytopic. It can also be the address identified by the sender. For example, POP3: // User: The password@mail.mycompany.com sends a message to a remote mailbox.

Note that the address here is your own name. Generally, different applications have different addresses. For example, an application is JMS: // topic: mytopic. The other is JMS: // topic: mytopic2.

3 UMO components: As you can imagine, this is a chip and a controller on the ESB bus. In the mule, they are some pojo responsible for receiving messages, processing them, and sending them out. For example, an UMO listens to messages in JMS: // topic: mytopic. If yes, it is sent to POP3: // User: password@mail.mycompany.com after processing.

Obviously, UMO simply calls endpoints address to receive and forward messages. It does not need to know what protocol it uses to receive and send messages. This is the role of the ESB, that is, to provide a unified Bus Interface