SOA生命周期的理解与思考

上周五，代表北航参加了由“中国电子技术标准化研究所”牵头的《SOA用户指南》最新版的修订讨论会，会议过程中与田忠博士（IBM首席信息系统架构顾问）就SOA生命周期的问题进行了讨论，收获颇多，同大家共同分享。

介绍一下相关背景吧。《SOA用户指南》是从2007年起开始规划和起草，由“中国电子技术标准化研究所”牵头负责，参与编撰工作的厂商和研究机构包括微软、IBM、SUN、金蝶中间件、中软国际、神州数码、普元软件、东方通、浪潮、锐易特、炎黄盈动、宝信、北航、后勤指挥学院、长风联盟等16家。致力于解决用户在采用SOA架构搭建行业应用系统中遇到的问题。

整个《SOA用户指南》的内容分为三大部分：

• 第一部分简单介绍SOA的概念和价值，以及SOA实施方法和策略，特别值得一提的是SOA项目实施按照实施策略、切入点、实施组织模型、业务关注点、所需解决问题、建设范围和建设层次等的七个不同视角划分。
• 第二部分则对我国金融、电信、制造、烟草、政府、物流、医疗卫生等9大行业或领域的SOA应用状况进行分析，分析范围包括行业背景、现实状况、SOA应用状况和SOA应用风险等几大方面。
• 第三部分则收录来自13个厂商的、30个国内外实际实施SOA用户案例，并对这些案例进行分析和梳理，形成案例特点的汇总。

对《SOA用户指南》有兴趣的朋友可以在 http://www.soa-china.org.cn 上了解更详细的内容和最新进展。

 

在《SOA用户指南》的第一部分中，整个SOA项目的实施，实际上是围绕着SOA生命周期进行的。目前业界对SOA生命周期的看法，基本上认同IBM提出的MADM模型，也就是下面这张有名的蜂窝图。

MADM是四个单词的首字母，分别指的是上图顶层的生命周期四个阶段：Model（建模）、Assemble（组装）、Deploy（部署）和Manage（管理）。初看这几个阶段的划分还算比较清楚，但是问题往往就出在IBM糟糕的命名机制上，每个阶段所包含的内容远远超过了其名称代表的含义，从某种意义上来说，算是误导了用户。至于每个阶段具体涉及的内容，仁者见仁，智者见智，就算是IBM的内部，对这个问题的看法也不尽一致，下面总结了几种观点，读者可以分析对比，根据自己行业以及项目的实际情况，各取所需。

第一种看法来自于文章 “Realizing Service-Oriented Architecture” （中文版），这种看法比较贴近于一般字面理解。另外，这篇文章还给出了IBM软件产品在整个SOA生命周期的布局，对于国内的用户进行产品选型，以及国内的SOA中间件厂商进行自身产品定位，有着非常重要的借鉴意义，强烈推荐。

• 建模：需求收集；业务流程建模、分析、设计和优化。
• 组装：服务实现；服务发现；服务编排；服务组合；业务流程实现；业务流程测试。（注：个人觉得作者这里把服务组合（composition）和服务编制（orchestration）的概念混淆，把“服务组合”换成“服务编制”会更合理）
• 部署：业务流程部署。
• 管理：服务、业务流程监视与分析；安全性、性能和可用性测量。

第二种看法来自于文章 “The Role of SOA Quality Management in SOA Service Lifecycle Management”

• 建模：业务需求的确认；现有服务的发现与访问；服务需求建模。（注：这里将“业务需求”和“服务需求”分开是非常有道理的，“业务需求”的建模不应该包含在SOA生命周期中，而应该放在前期的战略规划中）
• 组装：服务更新计划创建；服务创建和修改；服务访问。（注：这里的“服务访问”是检测服务是否符合“治理规则”（governance rules），有点服务测试的意思，至于“治理”的概念，在本文后面部分中会提到）
• 部署：服务质量保证；功能测试；性能测试；兼容性测试；服务部署验收。（注：这种看法一个很大与众不同之处在于将服务的测试放在了部署阶段，而不是组装（开发）阶段。仔细想想，这种做法可能更符合现实情况，因为开发和运维一般都是两个独立的部门，开发团队很难接触到实际运行环境，比如银行业务，把测试的工作放在部署中，交给运维部门做，更加合理）
• 管理：服务监控和管理；服务追踪；服务质量报告。

第三种看法来自于文章 “SOA governance framework and solution architecture” 

• 建模：服务需求收集；服务建模和模拟；服务设计。
• 组装：服务发现；服务构造和测试；服务组合。
• 部署：人员集成；业务流程集成；信息管理和集成。
• 管理：应用和服务管理；一致性和兼容性管理；业务属性监控。

上面的三种看法，虽然是IBM的一家之言，但是以IBM在行业中唯马首是瞻的地位，还是很有借鉴意义的。个人比较推崇第二种看法，但是也还是觉得有缺陷，比如说，没有哪种看法能够很好的给出从“管理阶段”到“建模阶段”的迭代过程，以至于整个生命周期像是一个开环而不是闭环的过程。

 

上面SOA生命周期图上一个比较容易忽略或者难以理解的地方，就是蜂窝图下层的“Governance & Best Practices”，国内翻译成为“治理和最佳实现”。我对“治理”这个翻译保留很强烈的意见，因为从字面意思很难揣测出实际含义，但好像这个已经成为大家比较认同和接受的翻译，我也就只好忍了。不过，话说回来，我也提不出一个比较合适的翻译来解释这个“Governance ”，实在是因为这个词包含了太多的意义，无语。

“治理”是一组规则，用来指导SOA生命周期中每个阶段的方方面面，类似于SOA中的宪法。就好像国人忽略宪法存在一样，国内的SOA实践也常常忽略“治理”的存在，总之，这是一个很重要，很重要，非常重要，非常重要的东东！关于“治理”，推荐大家阅读 “Introduction to SOA governance” （中文版）。

文章“Realizing Service-Oriented Architecture” （中文版）给出了“治理”所涵盖的具体领域：服务标识、服务定义、服务部署、服务迁移、服务版本控制、服务所有关系、服务监视、服务测试、服务安全、服务策略。当初见到这篇文章，第一感觉就是作者偷懒了，既然“治理”覆盖了SOA生命周期每个阶段，那么它也必然遵循某个生命周期，并且这两个生命周期同时运行，相辅相成。抱着这样的思路，查了一些资料，找到了另外一张很重要的图，如下所示：

 

治理的生命周期也分为四个阶段（PDEM）：Plan（计划）、Define（定义）、Enable（启用）和Measure（度量），但这四个阶段与SOA生命周期的四个阶段并不是一一对应关系。

文章 “SOA governance framework and solution architecture” 同时也给出了在治理生命周期的每个阶段，需要实施的内容。

计划：确认治理需求

• SOA、IT的业务策略制定和确认
• 现有SOA和IT能力的评估
• SOA远景、策略的定义和重定义
• 现有治理能力、安排的回顾
• 治理计划的规划

定义：定义治理方法

• 治理流程的定义或修改
• 策略、执行机制的设计
• 成功因素和准则的标识
• 所有者和资金的标识
• SOA核心优势的契约化及优化
• 治理IT基础架构的设计

启用：增量部署治理模型

• 治理机制的部署
• 治理IT基础架构的部署
• 基于期望行为、实践的培训和部署
• 策略部署

度量：治理流程的监控和管理

• 策略一致性的监控
• 治理安排一致性的监控
• IT有效性准则的监控

 

总结一下，对于SOA生命周期，特别是治理生命周期的理解是一个长期、渐进的过程。根据行业特点，项目环境，人员参与水平的不同，在整个生命周期中所采用的方法和步骤也不同。没有绝对正确的实施过程，只有最适合的实施过程。上文中有许多地方是被引用文章的翻译，在翻译的过程中，为了便于理解，更多的是采用了意译的方式，如果大家有什么迷惑的地方，欢迎一起探讨，有什么错误的地方，也欢迎批评指正。