她们的武器很简单：测试用例；她们的思想很简单：尽职、尽责、尽心。

一.需求

• 简化不同数据源之间的数据交互
• 简化不同应用之间的服务交互
• 可扩展、轻量级、可嵌入、可定制、简单易用

二.架构风格选择

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、拆分、路由等。

三. 技术框架和领域对象介绍

1. The Model：提供框架的运行时环境，管理配置、组件实例，提供运行模式；用户甚至可以定制自己的运行模式（很强大）。Model模型包含如下内容 Descriptors、UMO components、 An endpoint resolver、A lifecycle-adapter factory、A component resolver、A pool factory、An exception strategy。
2. Entry Point Resolver：与应用组件（POJO等）的交互。
3. Lifecycle Adapter：将MULE实例的生命周期映射到应用组件，间接接管应用组件。
4. Component Pool Factory：应用组件管理，提供pool能力。
5. Transport Providers：使Mule组件发送和接收消息的部件。



6. Connectors：对Connector的实现。
7. Endpoints Address：资源标识的一种方法。例如，pop3://user:password@mail.mycompany.com ，file:///tmp/data/in，vm://MyUMO，axis:http://mycompany.com/mule/services/MyUMO等
8. Endpoint Resolution：对附加在Endpoint的配置进行解析，例如，jms://topic:myTopic?durable=true。
9. Message Receivers：消息接收者或监听者，不同类型的协议实现方式不同。例如TCP协议，只需要监听端口即可，File协议，需要定制一个线程去扫描文件系统，VM协议，可以不做任何事。
10. Message Adapters：负责消息的转换。
11. Transactions：提供事务支持。（没敢用，实际中，都是通过其它方式实现事务）
12. Container Contexts：嵌入式的时候使用，能够把Mule容器和外部容器打通。与Spring整合的已经非常完美。
13. UMO Components：mule的核心抽象之一，主要用来包装应用组件（POJO等）。
14. Component Lifecycle：组件的生命周期。



15. Events：Mule框架采用事件（SEDA,强烈推荐阅读Using SEDA to Ensure Service Availability ）架构来实现。



16. Inbound Routers、Outbound Routers：对应于消息架构中的2个部件。
17. Event Processing：Mule提供三种事件处理方式，（1）Asynchronously，（2）Synchronously ，（3）Request-Response相当于用异步实现的同步。 （具体使用模式，请参考原文）
18. Interceptors：Mule框架提供拦截器模式，以方便用户扩展组件整体行为。



19. Exception Management：提供异常管理的机制，默认的异常粗略很糟糕，最好自己定制。
20. Agents：为运维人员提供的管理接口。
21. Thread Pool：线程池管理，Mule的线程池和池策略需要仔细配置，否则很容易出现错误。Mule提供共用线程池和独立线程池模式，建议使用共用线程池模式。

作者将模式分为三类：（1）基本服务模式，是最小粒度的服务模式，已经无法再次拆分，可以认为是模式原语，多用在服务层面使用。（2）架构模式，通用的SOA系统设计要素，多用在系统设计时，做为架构风格的一个元素。（3）复合模式，基本服务模式的组合，用来定义系统的衔接特征，多用在应用系统整合场景。下面按照自己的理解和使用经验，简单说明一下，具体的介绍还请研究原文。

基本模式说明：

1. Aggregator：将多个独立的消息体通过该计算组件组合为一个消息体。
2. Service Bus：将多个独立的系统（已有系统、新系统）通过统一机制整合起来。
3. Dynamic Routing：与规则库配合，实现一个消息体的路由，实现上常采用基于消息头路由、基于内容路由2中情况。
4. Event-Driven Consumer：常用在资源有限的场景，解决资源竞争的问题，例如，网络接入时，系统所能接收到socket有受限的，此时即可通过该模式解决。
5. Filter：消息内容的过滤，例如，关键字过滤，也可用在信息补全场景。
6. Router：将消息发送到不同的应用，与Dynamic Routing的区别在于，此时规则是固定的，常常有2中使用方式，单播、多播。
7. Translator or Transformer：用在消息格式的转换场景。

架构模式说明：

1. Asynchronous Processing：异步事件风格解决服务之间的交互，例如，ATM到银行账务系统，多用该模式。在实践中，也鼓励使用这种风格，实现SOA，以弱化一致性、事务性，缓解资源受限等场景，该模式需要业务配合才能完全发挥。
2. Bridge：常用在2中体系之间的交互，把一种协议转换为另一种协议。它与Translator的区别在，Translator是针对消息的，它针对链路。
3. Cross-Service Operation：把多个服务封装为一个服务来使用，以确保一致性、事务性，可以把该风格弱化为分布式事务风格。
4. Event-Driven Dispatching：基于事件的派发，常用在pub/sub场景。
5. Process Aggregation：把多个过程聚合在一起，按照一定顺序进行消息处理，此时不要求一致性，每个过程都是独立的，用BPM技术更容易理解该场景。
6. Routing and Filtering：实现一个消息的多种渠道应用，例如，一个业务通知，通过Mail，IM、SMS、语言、甚至特殊应用传达给用户的场景，一个产品为多个渠道提到内容的场景。
7. Replicator：实现一份消息，服务处理的时候，同时往数据库复制一份，例如，数据备份容灾、数据采集、数据审计等。

复合模式说明：

1. Centralized Schema：解决跨应用边界的数据共享问题。
2. Concurrent Contracts：解决一个服务多个消费者时，每个消费者接口不同的问题。
3. Decomponse Capability：？？
4. Enterprise Service Bus：通过一个消息总线，解决应用整合的问题，化解复杂的网状链接。
5. Fault-Tolerant Service Provider：通过负责均衡解决服务高可靠性的问题。
6. Wrapper：解决传统应用服务化的问题。

1. 自我配置：系统能够自己动态完成组件的安装和卸载；自己实现条件的改变和校正。
2. 自我优化：系统能够监控自己的容量和状态，通过优化一些行为来改善性能。
3. 自我恢复：系统能够自己发现、诊断、恢复问题；也能够从故障中自我恢复。
4. 自我保护：系统能够自我低于风险。

Galaxy是一款SOA治理平台，主要提供了服务的注册和仓储，业务目的：服务描述和组织、服务静态生命周期管理、依赖管理、服务搜索、网络部署（依赖Netboot）。

Jopr 是一款可插入的框架，提供管理、监控、报警、操作控制、配置的能力。

三款产品，选择的核心业务目标有所不同，但业务域还是一致的，就是服务与IT治理。下图展示了把3款产品的核心概念整合起来使用的一个示意图：

要实现SOA治理，关键的一点还是为每个服务注入一个探测器，从而实现服务数据采集、治理中心指令传达的目的；对于这三款产品，由于其架构的差异，整合起来还是有点挑战的。

探讨1：建平台，那么啥是平台？以前看到一篇文章《用平台的思想观察互联网》写的非常好。平台是一个供多方参与者获取价值诉求的环境。从这个定义中，可以分析到平台的几大要素：参与者，价值链，环境。

1. 参与者：只有一个参与者，肯定没戏，原始社会不就这样吗？因而参与者必须是多个，所扮演的角色各相同，但基本上有这几类，利益输入者（换取另外一种价值），利益获得者（提供价值，换取利益），环境搭建者（维护、运营环境），游戏规则制定者（如何均衡的分配利益，满足利益获得者；如何客观的评估价值，满足利益输入者）。
2. 价值链：“天下熙熙皆为利来，天下攘攘皆为利往。夫千乘之王，万家之侯，百室之君，尚犹患贫，而况匹夫“。这是平台存在的根本，也是商业性所要求的，是驱动参与者进入平台的“原力”，共产主义形式的平台目前还没看到。需要几条价值链？一般以某一核心价值链为中心，想多条也可以。
3. 环境：参与者玩游戏、交换价值的地方。也是技术人员最关心的东西。

探讨2：产品平台与平台是啥关系？产品平台是平台的环境部分。在互联网领域，它首先提供容纳的能力，标识参与者的能力，支持利益获得者运行服务，支持利益输入者体验服务，支持游戏规则制定者有一只强力的手来调控价值链。对于技术人员来说，要搭建平台不是简单的一个技术平台，先得请我们的业务人员把平台的第一，第二要素搞清楚，否则失败的概念会挺高。

探讨3：开放平台与产品平台是啥关系？对于不同的平台，其开放的意义是不同的，但有一点是相同的：容许价值链的某一个点（或多个点）让第三方群体参与。例如，移动通过审批机制，允许SP参与到短信平台；Amazon开放商品供应点，允许第三方参与；淘宝开放平台的API，允许第三方提供网店的功能扩展。开放API只是开放的一种表现形式，而不是开放的本质，Amazon和移动就是很好的例证，开放的本质是价值链的开放，特别是利益获得者价值的开放，无利，开放了也没有价值。

探讨4：产品线与产品平台是啥关系？产品平台是平台的环境部分，与公司的价值链相对应；产品线是业务的实体部分，与公司的业务域相对应。一个或多个产品线可以运行在产品平台上；产品平台也可能是一个产品线。

探讨5：产品线是啥？围绕某一核心价值展开的系列产品，产品线中的产品承担的角色依据策略而各不相同，有的是核心价值的附加，有的是核心价值的放大器等等。比较典型的有:Google搜索产品线，支付宝的支付产品线。

探讨5：产品线架构与产品线是啥关系？产品线架构与平台、产品平台不具有直接关系。产品线架构是针对产品线的，为产品线里的产品提供共同的支撑，例如，共同的业务架构、共同的技术架构。产品线架构首先提供可重用的基础业务，支持产品的多样性、系列化、或形成“价值附加族”（以某一产品的核心价值为中心，研发的依赖核心价值而存在的其它产品，具有增强、放大核心价值的能力）；从技术上提供相同的基础环境、规范、工具等，简化产品的研发和缩短周期。

探讨6:如何构建产品线架构？以《架构的支撑框架和运营》一文为指导，实践之。

从前有个小男孩儿，他的父亲是个收入微薄的驯马师，只能勉强维持全家的生计和
送儿子去上学。有一天，老师在课堂上要求学生们把自己的理想写下来。
晚上，小男孩儿写了一篇长达7页的作文，详细描述了自己的理想，还画了一幅画来表
现自己的整个计划:有庄园，有牲畜，有土地，还有他想住什么样的房子……总之，他全
身心地投入到对未来的憧憬中。

第二天，他将作文交给了老师。老师却将作文评为不及格，并留了一句话：“放学
后，来找我。”小男孩儿去找老师，问他：“为什么给我不及格?”老师说：“对于一个像
你这样的孩子来说，这是一个不切实际的梦想。要想得到你想要的，需要很多条件，更需要很
多钱。你无论如何也做不到。”老师接着说:“如果你回去写一个更实际一些的目标，我
会重新给你打分。”小男孩儿回家后想了很久，他问父亲该怎么办。父亲回答说:“儿子，这要你
自己做决定。”在认真考虑了一星期之后，小男孩儿将原来的作文原封不动地交了上
去。他对老师说:“您可以给我不及格，但我要保留我的梦想。”

故事讲完后，男子对小朋友们说:“这个故事里的小男孩儿就是我。现在我们就住在我
梦想中的庄园和房子里。当年的作文我仍然保留着。”

我们不要让别人剥夺我们的梦想，我们也不要去剥夺别人的梦想。

]]> http://www.esbzone.net/2009/03/02/dream/feed/ http://www.esbzone.net/2009/02/28/arch_framework/ http://www.esbzone.net/2009/02/28/arch_framework/#comments Sat, 28 Feb 2009 15:08:09 +0000 邓芝 http://www.esbzone.net/?p=74 P2->P3-P4是基本过程；P5表示一个反馈和改进行为。这一部分与架构定义流派的决策派是有些映射的，只是具体基本里程碑的出发点是不一样的，例如，对于产品架构来说，本体过程包含了设计-研发-测试几个行为。 路径P6是一个特殊，它的行为是“比较”，通过对当前架构和目标架构的比较，找出差距，从而定制计划。 内容框架包括需求、概念、设计、本体、环境、运行体这6个子域，每个子域都有其特殊的内容项、内容格式。这一部分与架构定义流派的组成派是有些映射的，但也不是完全匹配，但目标是一致的：描述清楚架构的构成。 实践指导框架，本质上是把现有的各类方法论分门别类的放到对应的列上，再提供详细的过程指导。 角色层，定义清晰的角色，根本目标是定义视点，架构绝对不是一个视点的产物，它是多种视点汇聚而成的综合体。每个角色也可能有多个视点，不同角色之间，可能共享视点，但偏角不同（侧重点不同）。角色是整个框架的中枢，它纵向串起了一个价值链路，形成如下场景：经过某个认知过程，角色A具有了需求能力，该能力依赖于某些领域知识A1和某些技能A2，具有该能力的角色以实践过程A为指导，产出了需求内容。横向串起了领域，领域的顺序代表了认识事物的深入，由模糊到抽象，由抽象到具体，由静态到动态。 能力框架表示某个角色要达到某个业务目标，需要掌握的知识和技能。能力是做事的充分条件，但不代表没有这种能力的人不能做这件事。通常，对于不具备能力的人来说，首先按照能力体系的要求学习知识，掌握一定的技能；对于组织来说，就要培养这样的人具有该角色所要求的能力；对于项目经理来说，安排人干活时，首先要评估其能力，否则就要把这一点列入风险管理。 项目框架，把整个支撑作为项目来运作，而不是简单的一个活动或者学习，才能够确保：高效、高质、合适成本的得到目标框架。 【作用】通过该支撑框架，能够获得如下作用： 定义了清晰的工作目的–解决方案、目标域、目标架构 完整的工作指导–过程体系 完整的内容指导–内容框架 可操作的工作内容–执行P6过程的结果 树立客户意识–角色层，前一阶段的结果是后一阶段的输入 清晰的职责划分–角色层 员工培养–能力框架、角色层 交货意识–项目框架 风险意识–项目框架 成本意识–项目框架 质量意识–项目框架 改进意识–执行P5过程的结果 里程碑意识–过程框架 单项目标的可操作性–纵向价值链路 自我提升指导–理论体系 好的架构，是企业的核心资产之一，如何运营好这部分资产？（没有想太明白，但它依然非常重要） ]]> 更多内容在：

架构专栏

在《对架构的另类定义》一文中对架构进行了定义，虽然利用了事物本质来阐述，依然比较抽象，理解起来比较困难，因而再定义一个支撑框架。这种做法与事务研究方法是对应的：“架构定义”是概念，“支撑框架”是本体，“运营中的架构”是运动体。下图展示了这个理念：

【图示说明：】

1. 第一个领域是需求域，包括R1，R2，R3。R1代表当前实际的需求；R2代表了目标，例如，企业战略指标，系统容量指标等；R3代表了当前架构，如果还没有系统，那么R3为空。R1，R2来自于受益人，此处的受益人可以是具体的业务部门，也可以是抽象的系统（此时简介受益人是组织）；R3来自于客观存在。
2. 某人，这个角色在实际中有很多职能部门的人来担任，例如CTO，CIO，产品经理，用户体验师，咨询公司，外部公司等，它的职责是提出解决方案。
3. 目标架构，是解决方案的一部分（重合度可以是100%），目标架构是架构理论的具象，也即架构本体。
4. 传道者，负责把架构理论，架构支撑框架，架构运营策略传递到公司。
5. 下面的大方框内部是支撑框架的主体。在实际运作时，这个框架最好以项目的形式运营，这样是为什么有项目经理角色存在的原因。
6. 支撑框架，横向包括5层：过程框架层、内容框架层、实践指导框架层（即过程A — 过程F），角色层，能力框架层；遵循包含3大类，6个子类，列与过程框架的交叉点上最终业务目标，列于内容框架的交叉点上子业务目标列的下面节点都是对业务目标的纵向支撑。
7. 过程框架包括定义了过程路径和基本里程碑，P1->P2->P3-P4是基本过程；P5表示一个反馈和改进行为。这一部分与架构定义流派的决策派是有些映射的，只是具体基本里程碑的出发点是不一样的，例如，对于产品架构来说，本体过程包含了设计-研发-测试几个行为。
8. 路径P6是一个特殊，它的行为是“比较”，通过对当前架构和目标架构的比较，找出差距，从而定制计划。
9. 内容框架包括需求、概念、设计、本体、环境、运行体这6个子域，每个子域都有其特殊的内容项、内容格式。这一部分与架构定义流派的组成派是有些映射的，但也不是完全匹配，但目标是一致的：描述清楚架构的构成。
10. 实践指导框架，本质上是把现有的各类方法论分门别类的放到对应的列上，再提供详细的过程指导。
11. 角色层，定义清晰的角色，根本目标是定义视点，架构绝对不是一个视点的产物，它是多种视点汇聚而成的综合体。每个角色也可能有多个视点，不同角色之间，可能共享视点，但偏角不同（侧重点不同）。角色是整个框架的中枢，它纵向串起了一个价值链路，形成如下场景：经过某个认知过程，角色A具有了需求能力，该能力依赖于某些领域知识A1和某些技能A2，具有该能力的角色以实践过程A为指导，产出了需求内容。横向串起了领域，领域的顺序代表了认识事物的深入，由模糊到抽象，由抽象到具体，由静态到动态。
12. 能力框架表示某个角色要达到某个业务目标，需要掌握的知识和技能。能力是做事的充分条件，但不代表没有这种能力的人不能做这件事。通常，对于不具备能力的人来说，首先按照能力体系的要求学习知识，掌握一定的技能；对于组织来说，就要培养这样的人具有该角色所要求的能力；对于项目经理来说，安排人干活时，首先要评估其能力，否则就要把这一点列入风险管理。
13. 项目框架，把整个支撑作为项目来运作，而不是简单的一个活动或者学习，才能够确保：高效、高质、合适成本的得到目标框架。

【作用】通过该支撑框架，能够获得如下作用：

1. 定义了清晰的工作目的–解决方案、目标域、目标架构
2. 完整的工作指导–过程体系
3. 完整的内容指导–内容框架
4. 可操作的工作内容–执行P6过程的结果
5. 树立客户意识–角色层，前一阶段的结果是后一阶段的输入
6. 清晰的职责划分–角色层
7. 员工培养–能力框架、角色层
8. 交货意识–项目框架
9. 风险意识–项目框架
10. 成本意识–项目框架
11. 质量意识–项目框架
12. 改进意识–执行P5过程的结果
13. 里程碑意识–过程框架
14. 单项目标的可操作性–纵向价值链路
15. 自我提升指导–理论体系

好的架构，是企业的核心资产之一，如何运营好这部分资产？（没有想太明白，但它依然非常重要）

Mule的架构风格是 Enterprise Service Bus (ESB) 架构，它也属于ESB产品一组，就如下图所示，具有如下品质特征：

• 互联互通。
• 低的耦合性。
• 高扩展性。
• 高可重用性。
• 易维护性。

Mule框架的一些说明：

• Mule框架具有高可扩展性，用户可以自己定制连接器（说实在的，Mule提供的一些东西，只能算是参考品，例如TCP连接器质量一般，必须定制Mina、Grizzly等强壮点的通信框架，自己实现一个连接器；老的那个XFire连接器，也很不好用，换成Jetty也得Fix一些BUG。要不是看它的框架还算巧妙，早丢弃了），拦截器，转换器等连接组件，同时能够把自己业务领域的计算组件或领域组件部署在Mule容器中；
• Mule框架支持面向服务的架构（ SOA ），能够通过JMS ， Web服务，数据库， HTTP等等连接器，无缝地整合应用系统；
• Mule框架可以独立部署，也可以嵌入；
• Mule已经与Spring实现了无缝整合；
• Mule框架有企业版和社区版，社区版是免费的，BUG多一些；其中企业版需要付出点费用；
• Mule有一个很长的授权文件，可惜E文不是很好，没有完全看明白，倒是记得了一句：“The Original Code is MuleSource Mule The Initial Developer of the Original Code is MuleSource Inc. All portions of the code are Copyright (c) 2003-2007 MuleSource Inc. All Rights Reserved。”，所以上市公司，请再仔细读读该文件。
• Mule不是对JBI的实现，但提供了JBI扩展。Mule使用起来比JBI要简单，也不像JBI强制要求SOAP堆栈，协议比较灵活，在分布式计算领域，性能也还是可以接受的。