一.需求
- 简化不同数据源之间的数据交互
- 简化不同应用之间的服务交互
- 可扩展、轻量级、可嵌入、可定制、简单易用
二.架构风格选择
Mule使用的是基于消息的架构风格(如上图所示),消息具有程序语言无关系、组件无关性、数据格式灵活性、消息无状态等特征,基于消息的服务也同样具有无状态的特征,此外,消息风格有非常成熟的应用模式,能够满足当前遇到的大部分数据应用需求以及SOA的需要。因而能够很好的满足需求中的前2个和第三个的可扩展、可定制的需求。
- Application:可以是程序段、外部系统。
- Channel:连接任何2个应用点(计算点),通过消息进行沟通,可参考《EIP - Message Channel (60)》
。
Message Receiver:用来从应用节点中读取、写入消息。Inbound Router:进入计算组件(component)之前的控制和处理,例如:过滤、聚合、排序等。Connector:在Channel上建立链路层,Message Receiver绑定在connector上监听数据、派发数据。Transformers:转换消息格式。Endpoint:把channel抽象为服务的一种配置组件,这些被配置的元素有connector, endpoint URI, transformers, filters and transactional。Outbound Router:消息从计算组件(component)流出后的控制和处理,例如:过滤、Pub/Sub、拆分、路由等。三. 技术框架和领域对象介绍
- The Model:提供框架的运行时环境,管理配置、组件实例,提供运行模式;用户甚至可以定制自己的运行模式(很强大)。Model模型包含如下内容 Descriptors、UMO components、 An endpoint resolver、A lifecycle-adapter factory、A component resolver、A pool factory、An exception strategy。
- Entry Point Resolver:与应用组件(POJO等)的交互。
- Lifecycle Adapter:将MULE实例的生命周期映射到应用组件,间接接管应用组件。
- Component Pool Factory:应用组件管理,提供pool能力。
- Transport Providers:使Mule组件发送和接收消息的部件。