ESB zone

架构的支撑框架与运营

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

【图示说明：】

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. 自我提升指导–理论体系

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

Posted in 技术思考 | 1 Comment »

Mule是啥玩意

Mule基于Java平台，是一个轻量级的消息框架，可让您快速，轻松地连接您的应用程序（外部系统、内部组件、甚至一段脚本），使他们能够交换数据。

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堆栈，协议比较灵活，在分布式计算领域，性能也还是可以接受的。

Posted in ESB思考 | 2 Comments »

ESB产品Mule+Spring实现最简领域驱动框架

先发一个消息，开源ESB产品Mule又发布了新的LDAP组件，很是让人佩服，首先赞一个先。

架构风格的基本组成体：计算组件、连接组件、信息、数据、配置。下图中，又抽象了一个领域组件，这也是为了让这个风格表示法能够同样适用于业务层面。

MULE+Spring完全支撑上图所示的架构风格，我们可以很容易的用它们实现最简领域驱动框架，以支持领域驱动设计。MULE大量提供连接组件（通信，协调，仲裁等）和信息链路拦截机制（可使用格式转换，加密，压缩之类的），也提供一些通用的计算组件，但更多的通用计算组件还是依赖自己开发；Spring提供了配置能力，把组件之间的关系记录下来；唯独留下新引入的领域组件（领域组件的计算能力可以很容易通过连接组件实现与其它组件的交互），需要我们自己来开发。

在《领域驱动设计在SOA架构中的实践》一文中提到技术架构师解决如下问题：“解决缓存、事务管理（包括分布式事务）、分布式接口规范、通信机制、共性系统服务的注入和应用契约、领域驱动设计风格与编程模式的确定、测试方案的确定、工具的提供、搭建可运行的环境、跨环境（分布式环境）的服务依赖策略、模型转换策略和工具的提供、集成策略”。下面用Mule+Spring的组合来对应一下：

1. 缓存：是一个计算组件，需要单独开发。
2. 事务管理：是一个计算组件，利用Spring事务，分布式事务需要单独定制一个计算组件。
3. 分布式接口规范：需要单独定义。
4. 通信机制：MULE提供。
5. 共性系统服务的注入和应用契约：Spring提供。
6. 领域驱动设计风格与编程模式的确定：见实践一文。
7. 测试方案的确定：Spring提供单元测试，Mule提供分布式测试，可以定制一些测试辅助组件，例如：数据生成组件，该组件配合MULE的定时组件，很容易实现简单的自动测试。
8. 工具的提供：MULE，Spring都提供了工具，DAO生成组件依据存储框架的不同寻找合适的。
9. 搭建可运行的环境：再搞一个JBOSS，整个环境OK。
10. 跨环境（分布式环境）的服务依赖策略：见实践一文，Spring + Mule提供技术支持。
11. 模型转换策略和工具的提供：用Dozer 解决Bean-Bean，JAXB解决Bean-XML，或者Hessian解决Bean-Hessian；开发这些计算工具，配置在Mule的链路中，即可使用。
12. 集成策略：Mule提供了各种连接组件，轻易集成外部系统或服务。
13. 额外的：Mule提供了分布式计算环境，可以作为SOA技术平台来使用。
14. 额外的：Mule提供了服务模型，可以作为服务平台来用。
15. 额外的：Mule提供了Galaxy，解决服务治理。

通过上面的匹配，就会发现，以MULE+Spring为基础，实现一个更强大的领域驱动框架将会非常容易。

Posted in ESB思考, SOA、服务化 | No Comments »

领域驱动设计在SOA架构中的实践

本着实践–阅读–思考–再实践的原则，总结一下领域驱动设计在SOA架构中的实践，关于领域模型设计自身，我建议大家阅读《领域驱动设计》一书，关于领域驱动实践的入门教程，我强烈建议阅读《领域驱动设计和开发实战》；关于领域驱动实践的再一个实践入门，我建议阅读《Domain-Driven Design in an Evolving Architecture》。2篇文章中，作者还提供了架构图，它们已经能够满足大部分应用的架构需求。

1.为什么要在SOA架构中使用领域驱动设计？之所以采用SOA，不是因为好玩，而是业务复杂性导致的，迫不得已而为之呀（可参考《SOA、服务化》栏目内的一些文章）。使用了SOA架构，不代表业务复杂性自动消失，还是从业务入手分析之，从目前广泛流行的方法学中，领域驱动设计完全符合符合这个需求，它就是为解决业务复杂性而生的。

2.职责分离。有时候，由于资源的情况，会让一个人同时承担技术架构和业务系统分析的角色，这种情况下，往往会搞的这个领域驱动设计乖乖的，简单玩玩也是无所谓了，对于较大的互联网公司，就是比较头疼的事情了，应用系统的开发者不同，这架构风格绝对会千奇百怪。因而还是要把这职责分清楚，搞一个技术架构师，再搞一个业务系统分析师。

• 技术架构师：关注与领域驱动设计在SOA架构中的技术部分，重点在“解决缓存、事务管理（包括分布式事务）、分布式接口规范、通信机制、共性系统服务的注入和应用契约、领域驱动设计风格与编程模式的确定、测试方案的确定、工具的提供、搭建可运行的环境、跨环境（分布式环境）的服务依赖策略、模型转换策略和工具的提供、集成策略”。这些东西确定下来之后，技术架构风格就完全定型，下面的工作就是把架构风格“固化”，此时有2中策略，固化为框架、固化为产品，建议在头2个项目迭代中，以框架形式提供，之后就可以考虑以产品方式提供（可参考通用技术系列文章）。有了“领域驱动”在SOA架构中的支撑框架（产品），将大大的简化业务系统分析师的工作，但距离成功还有70%的距离（只有业务成功了，才是成功），可这30%将占据80%的质量属性，严重影响全局SOA架构体系的成功。
• 业务系统分析师：关于业务，关注领域驱动设计，请千万忘记技术，相信我们的战友会解决这些问题的。

3. 领域驱动设计概念架构风格图A，该风格比较保守一下，在具体cache的使用上，有2中选择，或者领域中使用，或者仓储中使用，具体那种方式适合，要看领域模型和缓存需求，不是啥都适合通过仓储缓存。

4. 领域驱动设计概念架构风格图B，该模型的变化之处在增加了一个事件层。好处：领域模型与仓储模型、cache模型等隔离，同时提供了扩展机制；缺点：不如风格图A那么直接，容易理解，且事件层放在这儿有点不伦不类。在使用中注意几点：事件对象可以业务域统一一个，或者技术框架层统一一个；建立事件标识契约，例如领域对象的类型；保证事务，避免跨线程。

5.注意以下几点：

• 领域切分不要太小，切不可变成简单的分布式方法的调用。
• SOA重用的是服务，不是功能。
• 服务应该与需求用例对应；服务提供的方法与设计用例对应（设计用例是对需求用例的实现）。
• 领域内部的复杂度与业务能力体系相关，领域不是平面的、是树状的、是有层次的，可以用层模式来切分领域对象。
• 领域内部既有用户看见的东西，也有用户看不见的业务内能力，对外暴露的值对象信息，往往来自最上层的领域对象。
• 即使一人身兼2职，也要把自己切分开，搞技术架构时，忘记具体业务，把架构风格固化下来，请开发程序员按照这个编程模型来开发；搞领域驱动设计时，完全忘掉技术。
• 如果作为公司的架构师角色进入项目团队，那么请：走入程序员中间，走入项目中间，但不要走入业务编码中间；到这儿是获取需求，验证框架（验证架构风格），发现问题的；目标是整个SOA架构的成功，不仅仅是项目的成功。
• 服务对象层，请参考《SOA实践之：Java服务接口设计的一些实践准则》，务必形成严格的编程规范，强制遵守。

Posted in SOA、服务化, 技术思考 | 3 Comments »

11种开源的Twitter客户端（转）

Twitter的用户群越来越多，如何与已有应用集成(例如，该文《Social mashups with Groovy》)，也逐步为大家所关心，该文《10 Open Source Twitter Clients - And Counting》提供了现存的一些开源方案。

Posted in 互联网资讯 | 1 Comment »