【日志归档】 03月, 2009
向出色的测试分析师致敬
最近参与一个范围很大的项目，已经进行开发阶段，测试分析也在并行中，这一段时间来，她们每天都有多个问题向项目组的关键同事咨询，确认，从中发现了近百个问题点，这些问题：或者领域边界没有足够的清晰，或者概念没有明确的定义，或者业务规则不完整，或者方案存在矛盾，或者操作链路存在断层，或者某些属性的限制有冲突，或者某个格式、数字不明确，或者…….！！！想来很惭愧，居然有这么多问题点没有能够细化，系统分析师、设计程序员也没有完全发现，我由衷的为与这么出色的测试分析师工作而深感荣幸，她们是这场战斗中坚强的后盾，向她们致敬！！！
她们的武器很简单：测试用例；她们的思想很简单：尽职、尽责、尽心。
Mule技术架构（摘译）
更多明细，请阅读原文 《 Mule 1.x Architecture Guide 》，2.0版本缺少相应的文章，但技术架构没有发生更本的变化。
一.需求
- 简化不同数据源之间的数据交互
- 简化不同应用之间的服务交互
- 可扩展、轻量级、可嵌入、可定制、简单易用
二.架构风格选择
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组件发送和接收消息的部件。
- Connectors：对Connector的实现。
- Endpoints Address：资源标识的一种方法。例如，pop3://user:password@mail.mycompany.com ，file:///tmp/data/in，vm://MyUMO，axis:http://mycompany.com/mule/services/MyUMO等
- Endpoint Resolution：对附加在Endpoint的配置进行解析，例如，jms://topic:myTopic?durable=true。
- Message Receivers：消息接收者或监听者，不同类型的协议实现方式不同。例如TCP协议，只需要监听端口即可，File协议，需要定制一个线程去扫描文件系统，VM协议，可以不做任何事。
- Message Adapters：负责消息的转换。
- Transactions：提供事务支持。（没敢用，实际中，都是通过其它方式实现事务）
- Container Contexts：嵌入式的时候使用，能够把Mule容器和外部容器打通。与Spring整合的已经非常完美。
- UMO Components：mule的核心抽象之一，主要用来包装应用组件（POJO等）。
- Component Lifecycle：组件的生命周期。
- Events：Mule框架采用事件（SEDA,强烈推荐阅读Using SEDA to Ensure Service Availability ）架构来实现。
- Inbound Routers、Outbound Routers：对应于消息架构中的2个部件。
- Event Processing：Mule提供三种事件处理方式，（1）Asynchronously，（2）Synchronously ，（3）Request-Response相当于用异步实现的同步。 （具体使用模式，请参考原文）
- Interceptors：Mule框架提供拦截器模式，以方便用户扩展组件整体行为。
- Exception Management：提供异常管理的机制，默认的异常粗略很糟糕，最好自己定制。
- Agents：为运维人员提供的管理接口。
- Thread Pool：线程池管理，Mule的线程池和池策略需要仔细配置，否则很容易出现错误。Mule提供共用线程池和独立线程池模式，建议使用共用线程池模式。
SOA模式短文推荐
强烈推荐SOA爱好者下载收藏《SOA Pattern》一文，又有精品全文《SOA Design Pattern》推荐下载
作者将模式分为三类：（1）基本服务模式，是最小粒度的服务模式，已经无法再次拆分，可以认为是模式原语，多用在服务层面使用。（2）架构模式，通用的SOA系统设计要素，多用在系统设计时，做为架构风格的一个元素。（3）复合模式，基本服务模式的组合，用来定义系统的衔接特征，多用在应用系统整合场景。下面按照自己的理解和使用经验，简单说明一下，具体的介绍还请研究原文。
基本模式说明：
- Aggregator：将多个独立的消息体通过该计算组件组合为一个消息体。
- Service Bus：将多个独立的系统（已有系统、新系统）通过统一机制整合起来。
- Dynamic Routing：与规则库配合，实现一个消息体的路由，实现上常采用基于消息头路由、基于内容路由2中情况。
- Event-Driven Consumer：常用在资源有限的场景，解决资源竞争的问题，例如，网络接入时，系统所能接收到socket有受限的，此时即可通过该模式解决。
- Filter：消息内容的过滤，例如，关键字过滤，也可用在信息补全场景。
- Router：将消息发送到不同的应用，与Dynamic Routing的区别在于，此时规则是固定的，常常有2中使用方式，单播、多播。
- Translator or Transformer：用在消息格式的转换场景。
架构模式说明：
- Asynchronous Processing：异步事件风格解决服务之间的交互，例如，ATM到银行账务系统，多用该模式。在实践中，也鼓励使用这种风格，实现SOA，以弱化一致性、事务性，缓解资源受限等场景，该模式需要业务配合才能完全发挥。
- Bridge：常用在2中体系之间的交互，把一种协议转换为另一种协议。它与Translator的区别在，Translator是针对消息的，它针对链路。
- Cross-Service Operation：把多个服务封装为一个服务来使用，以确保一致性、事务性，可以把该风格弱化为分布式事务风格。
- Event-Driven Dispatching：基于事件的派发，常用在pub/sub场景。
- Process Aggregation：把多个过程聚合在一起，按照一定顺序进行消息处理，此时不要求一致性，每个过程都是独立的，用BPM技术更容易理解该场景。
- Routing and Filtering：实现一个消息的多种渠道应用，例如，一个业务通知，通过Mail，IM、SMS、语言、甚至特殊应用传达给用户的场景，一个产品为多个渠道提到内容的场景。
- Replicator：实现一份消息，服务处理的时候，同时往数据库复制一份，例如，数据备份容灾、数据采集、数据审计等。
复合模式说明：
- Centralized Schema：解决跨应用边界的数据共享问题。
- Concurrent Contracts：解决一个服务多个消费者时，每个消费者接口不同的问题。
- Decomponse Capability：？？
- Enterprise Service Bus：通过一个消息总线，解决应用整合的问题，化解复杂的网状链接。
- Fault-Tolerant Service Provider：通过负责均衡解决服务高可靠性的问题。
- Wrapper：解决传统应用服务化的问题。
StarMx,Jopr,Galaxy介绍
StarMx是一款利用Jmx实现资源自我管理的框架（下图是一张自动系统的架构），业务目的是：自我配置、自我优化、自我恢复、自我保护。
- 自我配置：系统能够自己动态完成组件的安装和卸载；自己实现条件的改变和校正。
- 自我优化：系统能够监控自己的容量和状态，通过优化一些行为来改善性能。
- 自我恢复：系统能够自己发现、诊断、恢复问题；也能够从故障中自我恢复。
- 自我保护：系统能够自我低于风险。
Galaxy是一款SOA治理平台，主要提供了服务的注册和仓储，业务目的：服务描述和组织、服务静态生命周期管理、依赖管理、服务搜索、网络部署（依赖Netboot）。
Jopr 是一款可插入的框架，提供管理、监控、报警、操作控制、配置的能力。
三款产品，选择的核心业务目标有所不同，但业务域还是一致的，就是服务与IT治理。下图展示了把3款产品的核心概念整合起来使用的一个示意图：
要实现SOA治理，关键的一点还是为每个服务注入一个探测器，从而实现服务数据采集、治理中心指令传达的目的；对于这三款产品，由于其架构的差异，整合起来还是有点挑战的。
产品领域探讨(互联网领域)
该文主要探讨了如下一些问题：产品与业务的关系是什么；用事物本质来理解互联网产品；产品风格与产品品质是啥关系；产品服务质量和产品品质是啥关系；产品风格与用户需求；产品品质转换为产品需求；业务分析师的价值；产品风格与架构风格；产品分类和产品标识；产品与产品模型；产品与商品。该文也是希望抛个砖头，和大家一起探讨这些产品领域。详细请进。
