Technical Architecture of Mule

I. Requirements

• Simplify data interaction between different data sources
• Simplify service interaction between different applications
• Scalable, lightweight, embedded, customizable, and easy to use

Ii. architecture style selection

Mule uses a message-based architecture style (as shown in). A message has the following features: no language relation, no component dependency, data format flexibility, and no message status, message-based services also have stateless features. In addition, the message style has a very mature application mode that can meet most of the data application requirements and SOA requirements currently encountered. Therefore, it can meet the scalability and customization requirements of the first two and third of the requirements.

• Application: it can be a program segment or an external system.
• Channel: connects to any two application points (computing points) and communicates through messages. For details, refer to EIP-Message Channel (60).

.

• Message Receiver: used to read and write messages from application nodes.
• Inbound Router: controls and processes before entering the computing component (component), such as filtering, aggregation, and sorting.
• Connector: establishes a link layer on the Channel, and the Message Receiver is bound to the connector to listen to and distribute data.
• Transformers: converts the Message format.
• Endpoint: abstracts the channel into a Configuration component of the service. These configured elements include connector, endpoint URI, transformers, filters and transactional.
• Outbound Router: controls and processes a message that flows out of a compute component (component), such as filtering, Pub/Sub, splitting, and routing.

Iii. Introduction of technical frameworks and fields

1. The Model provides The runtime environment of The Framework, manages configuration and component instances, and provides The running mode. You can even customize your own running mode (very powerful ). The Model includes Descriptors, UMO components, An endpoint resolver, A lifecycle-adapter factory, A component resolver, A pool factory, and An exception strategy.
2. Entry Point Resolver: interaction with application components (POJO, etc.
3. Lifecycle Adapter: ing the life cycle of the MULE instance to the application component to take over the application component indirectly.
4. Component Pool Factory: Manages application components and provides pool capabilities.
5. Transport Providers: the part that enables the Mule component to send and receive messages.
6. Connectors: The implementation of Connector.
7. Endpoints Address: A method of resource identification. For example, pop3: // user: password@mail.mycompany.com, file: // tmp/data/in, vm: // MyUMO, axis: http://mycompany.com/mule/services/myumo, etc.
8. Endpoint Resolution: parse the configuration appended to the Endpoint, for example, jms: // topic: myTopic? Durable = true.
9. Message Receivers: Message Receiver or listener. Different types of protocols are implemented in different ways. For example, for TCP protocol, you only need to listen to the port, File protocol, you need to customize a thread to scan the File system, VM protocol, you can do nothing.
10. Message Adapters: Responsible for Message conversion.
11. Transactions: Provides transaction support. (Not dare to use it. In reality, transactions are implemented in other ways)
12. Container Contexts: Used in embedded systems. It can connect a Mule Container with an external Container. The integration with Spring is already perfect.
13. UMO Components: one of the core abstractions of mule, which is mainly used to package application Components (such as POJO ).
14. Component Lifecycle: the life cycle of the Component.
15. Events: The Mule framework is implemented Using the event (SEDA. We strongly recommend that you read the Using SEDA to Ensure Service Availability) architecture.
16. Inbound Routers and Outbound Routers: correspond to two parts in the message architecture.
17. Event Processing: Mule provides three Event Processing methods: (1) Asynchronously, (2) Synchronously, (3) Request-Response is equivalent to asynchronous synchronization. (For specific usage modes, refer to the original article)
18. Interceptors: the Mule framework provides the interceptor mode to help you expand the overall behavior of components.
19. Exception Management: provides an Exception Management mechanism. The default Exception is rough and bad. You are advised to customize it yourself.
20. Agents: a management interface provided by O & M personnel.
21. Thread Pool: Thread Pool management. The Mule Thread Pool and Pool policy must be carefully configured; otherwise, errors may occur. Mule provides the shared thread pool and independent Thread Pool Mode. We recommend that you use the shared Thread Pool Mode.