mySOA：敏捷的、治理的并且可持续的

SOA是在各种报道中频繁提及的一个话题。在阅读了很多书、文章、软件提供商们的各种白皮书以及博客文章之后，我仍然在探索如何才能使之成为现实。本文的主要目的是邀您一起参与我们的SOA之旅，不过它针对我们的一些限制使用我们自己的“语言”进行描述的。

我们称之为mySOA方法。

• SOA显然指得是我们要构建灵活的， 治理的并可持续的跨企业的业务和技术的服务，甚至可扩展至更广阔范围（云或B2B等）。
• “我的”是因为Web 2.0的变革使得服务越来越多地用于社会交互，而不仅仅是点到点的交互。“我的”还意味着它专注于我们的需求且与我们公司的业务对齐。

我们并不求为该领域提供一个尖端的解决方案，甚至不求提供统一的方法论（我们使用的术语是内部团队合作的结果）。但我们希望它将提供一个基础，能帮助你在此之上构建你的SOA方法，或者能鼓励你在该主题上扩展知识。

最后，为了描述得尽可能具体些，文中将提到我们所使用的工具提供商或者工具平台。我们诚挚地建议你购买任何技术解决方案之前要在你所面对的特定的上下文环境中做概念验证。因为，没有放之四海皆准的法则，特别是mySOA。

mySOA：敏捷的，治理的，可持续的

mySOA方法基于三大主干：敏捷，治理以及可持续性

mySOA方法应该是敏捷的

敏捷意味着我们将不再总是遵循那些文字所提到的“你必须”和“你应该”的法则（如，你必须要有业务战略，你必须要有管理层的支持，你必须采用自顶向 下的方法，你应该预先做好宏大的规划）。

我们将通过迭代的方法，通过小团队管理特定服务集合的方方面面。目标是创建我们所谓的“服务刀片”，它们可以被插入或重用在不同的业务及技术的环境中的。

敏捷

• 因为在快节奏而且扁平互联的世界中，企业要生存，必须要敏捷。
• 因为我们的开发团队使用SCRUM，因此转向敏捷非常自然。
• 也很必要，因为金融危机使得我们无法得到一大笔预算来开展若干年的完全丰满的SOA项目。

mySOA方法要求治理开始于SOA的第一天

我们不仅把治理作为支撑业务和IT的新动力，还将它作为加强合作和对齐的方法。信任是最大的挑战，而且总是这样，因为（出于整体利益的考虑）一些团队要将他们原有的决策权交出去并且要接受一些新规则。敏捷还包含另外一层含义，即对例外管理应该作为治理流程的本身的一部分。

mySOA方法应该是可持续的

SOA要允许对功能和技术竖井进行逐步且可持续性的改造，这样才能设计出可被各种业务流程重用并且灵活的服务。而往往在一段时间内我们致力于寻找充分的资产为业务提供价值而不是重用。如果我们不得不开发一个portlet来为某个特定客户提供业务服务（如CO2计算器），那么我们一定会这么做，它可能被重用也可能不会，但这是最后才考虑的事情。

可持续性还意味着，即便某些人（参与SOA之旅的人）会因为SOA的成熟以及新业务模型或组织的产生而必须变换角色，还是要保证他们参与进来。往往，SOA项目的结局是成本的降低，外包（投资海外可能更为贴切）以及帮助构建SOA的团队的解散。mySOA立足于人，在公司内且把公司的每个人看作功臣并提升其价值。mySOA的重心是为企业带来附加值。

mySOA——选择你的通往成熟之路

SOA支持建立敏捷的企业，但是通往mySOA天堂的路却取决于你自己。对于任何SOA项目或新方案，都要独立定位并让所有股东都能理解其开销、风险以及可能的收益级别，这点非常重要。图1是一个来自可持续的IT社区的某个SOA项目的分类模型，它的优势是能够在整改的、大检修的或扩展的SOA环境中为你的项目进行清晰地定位。

1.  整改的SOA.

• 不侵入现有资产：需要现有系统的辅助暴露服务；
• 它不同于对现有系统的重写；
• 此类SOA依赖于现有系统的质量；
• 此类SOA可能在有限的情况下快速见效。

2.  大检修的SOA

• 利用服务重构现有的应用系统；
• 可以充分利用IT基础设施；
• 业务规则和业务逻辑依然封装在应用程序的代码之中。

3.  扩展的SOA

• 使用能提升系统灵活性的解决方案：业务规则管理系统、主数据管理及业务流程管理等。

图 1：通往成熟SOA之路（来自可持续IT）

扩展的SOA是最“昂贵”（从时间、资源和投资上看）的，但是它能带来的实质性结果也最多。扩展的SOA才是目标。为了遵循通往该目标的敏捷的方式， 最佳的路径是通过某些过渡性的阶段，在这些过渡阶段中把主数据、业务规则和语义映射等从将要被访问的Web服务的应用程序中清晰地分离出来，并在此基础之上建立服务。

mySOA依赖于卓越中心

我们做的第一件事是创建一个整合卓越中心（ ICC，Integration Competency Center）。该中心的命名故意没有使用“SOA”，因为“整合”是业务更容易理解也更喜欢看到的。这并不代表将来不会有所改变（还是可持续性，我们的工作始终建立在过去的基础之上，而且是以敏捷的方式！）。

ICC是一个分布式的组织，它主要由两个团体构成，如图2所示。解决方案中心（Solution Center）的任务是确保对所有项目的不变的可持续的执行，专家中心（Center of Expertise）则为项目提供随需应变的敏捷的分布式的支持（或征求咨询公司）。

图 2：ICC的两个组成部分

ICC图表是我们创建的第一份文档，它定义了以下行动范围：

业务层

• 业务整合及创新：在各业务单元间普及并宣传业务整合能力的价值。
• 业务域治理：通过定义服务提供方的SLA以及关键功能需求来支持业务（列出要提供的业务服务清单，这些服务独立于技术）。

IT层

• 技术治理：创建技术标准并定义验证这些标准的规则，特别是围绕服务设计及接口设计的标准。ICC开发了一个技术标准最小集合作为必须要遵循的关键架构准则，如XML模式标准、WSDL模式标准、服务级定义模板标准等。ICC还专门开放了一个内部网站和wiki，用于讨论并进行答疑。
• 服务开发周期治理：ICC并不负责服务的开发，因此它应与敏捷的验证点联合才能确保所有的工作都是依照治理规则完成的（必要时还要改进治理流程， 治理流程本身也是敏捷的）。
• 服务交付和运行时治理：全局地交付服务，负责安全，SLA，并在需要时创建适配的虚拟“服务”（或端点）。ICC管理所有服务的技术接口。

解决方案中心由一个分布式敏捷的团队组成，该团队的成员都是全职员工，而将其部分工作时间花在SOA之上。这样就可以避免“巴別塔”综合征，并能使这些成员忙活于如何让实际的项目更加成熟，而不仅仅是管理和作报告。必要时该团队还可以雇佣合同工。

图 3 对ICC所提供的服务进行了归纳。

图 3：ICC组织提供的服务

寻找“我的”服务

一直以来的一个关键问题是如何找到服务?如何找到合适的服务粒度？答案依然是很难。我们遵循3种不同的方法：

• 自顶向下——业务服务诱导法
• 敏捷——遵循敏捷开发流程
• 自底向上—— 改建式开发(Brownfield Development)

业务服务诱导法（自顶向下）

详细讨论如何发现业务服务已经超出了本文的范围。不过我们建议你阅读 《可持续IT架构》[1]一书或者在这里免费得到发布在知识共享平台（creative commons）的文档及培训资料。

你可以遵循一些非常通用的步骤：

• 定义产品服务及他们的依赖：特定于有限业务域的业务价值链是什么（用敏捷的方式去做）；
• 定义业务对象，它们的生命周期及关系；
• 定义主数据；
• 创建用于对业务对象或业务交互周期进行映射的业务服务;
• 尽早定义或预见服务的可变性。
• 敏捷——遵循敏捷的开发方法

另一种方法是利用敏捷的开发流程，通过使用“向前版本控制策略”。与整合团队合作，设定优先级，开发并进行测试。

当然在多个迭代中都建立服务接口可能会产生一些问题，因为服务是不断发展的，而且服务用户是不喜欢服务接口如此不断地变化，然而为了快速地实现能够满足需求的服务，这是不得已而付出的代价。

每个团队都要理解一点，如果要避免在未来进行全盘设计（这种全盘设计并非一定能奏效），他们就应遵循一些规则。此外，还可以通过制定一些技术标准并经常进行检测来避免全盘设计的发生。沟通依然是关键所在。

这里不存在灵丹妙药，但是敏捷的确是为“恰当的”业务需求在“恰当的”时间寻找“恰当的”服务的一种令人惊讶的方法（适时比正确更为重要）。

改建式开发

改建式开发是IT工业中常用的一个词语，它通常用于描述需要在现有（或遗留的）应用或系统之间开发新软件系统的问题域。这意味这任何新的软件架构必须要考虑到与现有的正在运行的系统之间的共存性问题。若要了解更多信息，我们推荐阅读《吞下IT大象》 [2]。

在这种情况下，我们建议：

• 对数据进行挖掘。全面了解你的系统所包含的数据并尽力挖掘其最大价值。
• 控制其生命周期。这是一个前提条件，比如，我们使用Convertigo对遗留的后台办公数据进行访问，这样就不会破坏现有的流程，业务规则以及安全限制。
• 保证其质量。这点不能忽视，而忽视它往往是最常见的失误。
• 定义一个权威的数据版本。定义谁是它的管理者，谁使用它的拷贝进行工作。你可以使用MDM工具或构建一个联邦MDM（通常需要在其之上部署一些中间件来管理数据的同步及分发）
• 数据要面向服务，这是数据部分的最新型的工作。这项工作并不简单，因为它将带来DBMS端优化的工作负担和复杂性。

Informatica将计划推出其新平台V9，它将为数据管理，数据集成和数据服务提供统一的方法。为了在构建平台时更好地理解客户的问题，他们与来自不同客户企业的架构师们（包括我）进行了热烈的讨论。我推荐你阅读该对话中提到的一些经验及心得。开源数据集成提供商也纷纷涌向这块肥肉，其中包括Talend和Xaware等。

一些最佳实践

阅读服务标识方面的文献，如 Accenture SIF， BPM携手SOAHandshake，InfoQ关于SOA标识方面的文章，这本关于写作方面的文档，最后当然还少不了Thomas Erl百科.

以下是一组非常有用的最佳实践。

• 避免通用服务，服务必须要有特定的价值。
• 服务效用依赖于服务的多变性以及多版本。
• 服务提供信息的某种特别的视图。
• 服务总是要遵循某个生命周期，而且服务应当被管理起来。

 我的SOA——敏捷治理的必要性

由于要管理的服务数量可能快速增长，所以我们决定关注那些最“重要的”服务（这也是我们团队的决定）。重要性的依据是业务需求（如客户的要求，新 产品功能等）以及技术需求（如安全支持，REST支持，内容交付网络等）确定的。

所以，我们创建了一个治理进阶来实现服务重要性与服务治理力度的对齐：

1.  完全治理的：由ICC管理的服务——该类服务在全局范围内使用，并且对于遵循ICC治理规则的业务是至关重要的。

2.  已知的且委托治理的：本地管理的服务——该类服务由本地资助开发并且遵循本地的治理规则。

3.  已知的，无治理（使用时风险自担）：未管理的服务——任何不遵循适当的治理规则或未被监控的服务。

4.  所有的：监控的——跟踪SLA，条件允许时会生成报告。

5.  快照模式：遵循治理——已经量化技术需求以及SLA需求并且能随时进行验证。

不论如何，服务都应该在统一的存储库中声明并进行分类。

服务提供者是服务的所有者，它可以是企业的内部提供者也可以是外部提供者。不论选择的是那种服务治理级别，服务提供者都应该遵循以下基础规则集。服务提供者要：

• 对服务开发生命周期的方方面面负责。
• 熟知ICC定义的标准；
• 确保服务设计遵循ICC标准；
• 确保服务实现遵循SLA；
• 保证2，3级支持可用；
• 确保在生产环境中同时运行的服务的版本不超过2个。

ICC负责管理服务并进行敏捷的垃圾回收。它检查服务是否依然有用，是否依然在使用中。这对于避免产生无止境的服务目录非常关键。

服务分类

在我们的SOA视野中，所有内部业务部门都应该对交付服务作出贡献。架构蓝图可用于新系统的设计和旧系统的重构。

• 对于业务决策者，理解组件的业务价值及其商品化级别有助于作出创建、购买、或租借（服务）的决定，甚至还可能因为提供服务而发现业务机会。
• 对于架构师而言，对不同分类的深入理解不仅有助于对现有服务以及新服务进行分类，还有助于将恰当的功能定义在特定的服务之中，从而让服务更有利于组合或重用。

ICC使用特定的分类方式对所有服务进行分类，如图4所示，服务调用的方向的描述如下：

• 服务调用总是从上往下，而不是从下往上。
• 在中间层不是必须的情况下，服务调用可能跨过中间层

图 4: ICC的高层服务分类

技术或基础域服务

技术或基础服务包含一些通用的功能，它们不增加明显的商业价值，但却是SOA中任何业务流程的实现所不可或缺的部分。它们通常是通过购买而来的或定制开发的，并且集中进行管理。

我们来看一个例子：

• 交互服务负责系统中消息的传入及传出，而不需要关心消息的内容。
• 工具服务提供了通用的，与应用无关的服务，他们处理传输消息之外的其他方面。
• 安全服务提供所需的安全相关的能力，如身份、隐私、机密及不可抵赖性等。

业务域服务

核心业务流程服务与以数据为中心和以活动为中心的基础元件绑定在一起，从而实现组织的业务流程。他们通常是有状态的服务（管理服务流程状态）。流程服务的一个例子是订单处理服务。一个业务服务可能永远不会消费核心业务流程服务，而核心业务流程服务则会消费业务服务。

业务服务实现企业的业务级能力。它们通常是有状态的并且代表以活动为中心的基础元件（或“原子动词”），企业的业务流程由它们构成。

业务实体服务将业务实体与它们在系统中的不同的生命周期中的状态分离开。他们通常是无状态的服务。业务实体可以被看成是业务流程中以数据为中心的组件（名词），如员工、客户、销售订单等等。业务实体服务提供了对这些数据对象的操作，如下所示：

• CRUD操作：创建、查询、更新以及删除；
• 搜索功能；
• 基于业务实体的生命周期的可持续性操作。

应用域服务

应用域流程实现了特定的业务级能力或这某些以活动为中心的业务逻辑元素，它们是特定业务应用语境所特有的。

• 有状态或无状态服务；
• 非ICC管理的服务。

服务的生命周期

我们的服务生命周期尽可能简单化。它包括图5中所示的几个基本步骤。

1. 定义：判定是否需要某个服务，收集功能需求和服务级别需求。ICC可以参与并支持此步骤。

2. 开发：开发核心业务逻辑和文档（敏捷迭代的方式）或（根据需要）租用服务的访问。无论选择哪种方式，都要把所需的资产注入到注册库中。

3. 验证：ICC负责控制设计时的治理。该工作的重要性取决于服务所关联的治理级别。在该阶段，必要时应回退到定义阶段 。

4. 部署：ICC建立运行时治理（SLA控制、计费控制和业务活动监控）

5. 退役：从生产环境以及SOA注册库中移除服务

图  5: mySOA治理过程

如果你喜欢参照完善的服务声明周期流程，如图6中所示的RUP，这当然也没有问题。你还可以使用某些特定的工具（如软件服务的UML概要以及RSA SOA插件）并寻求咨询的支持。可以敏捷也可以不敏捷，这仍然取决于你。

图 6：改造SOA的RUP过程

业务服务接口

一个业务服务的接口

• 是将所有必须的服务组合起来去支撑业务流程或扩增的功能或技术特性，并带来的关键价值
• 是独立于其他服务的接口创建并配置的（如，尽可能让不同的接口之间无依赖关系）
• 是自包含的并且向客户端隐藏了其在技术平台上的具体的“投射”细节
• 其使用应该能被跟踪且可收费
• 其创建者可能是所有的业务单元、组织或第三方提供者（按需要提供）
• 由ICC管理或不由ICC管理
• 完全支持版本化

业务服务接口的创建用于服务需求方以及服务提供方之间的粒度适配，如图7中所描述的。它是使现有业务服务和应用服务与业务流程中所需要的服务进行对齐的方法之一。

图  7: ICC高层服务分类

mySOA，我们如何做到？

为简单起见，本文直线式地描述了mySOA以及我们要做的工作的方方面面。当然，在实际的工作中，我们经历了成功也品尝过失败，也根据业务及IT的成熟程度修改过我们的方法并且希望把事情做好。然而即将开始的旅程引入了一些关键驱动力而进行了简化。

mySOA的平台需求

为了构建我们的企业服务平台，我们观察过一些最好的工具看看我们能否让他们无缝地整合起来。我们的主要需求是：

• 企业服务平台应该是迭代地构建的，并且要基于热门组件。业务对该项投入非常清晰，我们的任务并非构建一个SOA的平台!
• 一个独特的可管理的、可扩展的容错平台；
• 尽可能利用现有基础设施及许可证；
• 在必要时帮助遗留系统的离退；
• 能够为所有的服务分类及整合流所用；
• 提供端到端的治理；
• 提供业务和技术监控（设计时及运行时）；
• 降低维护和运行成本。

mySOA参考平台

由企业服务平台提供的主要服务如下所列（见图8）：

• 企业消息服务。提供安全的、受管的、可靠的消息服务（比如，在这里你可以查到一组开源的Java JMS服务器，或从Amazon SQS 使用云中的EMS，或 Microsoft的.NET服务）。
• 主数据管理服务。如前文所述，你可以找到记录的流程，最佳实践和商业的/开源的工具。
• 语义数据整合服务。目的是创建并管理企业信息模型（在具有不同结构和语义的应用系统及服务间进行仲裁），进而可以创建并集中管理用于校验以及仲裁数据的规则及操作。语义数据整合可以自动化执行并管理，这些操作是保证数据质量的核心，如转换、聚集、验证、业务规则执行。若要了解更多语义层的内容，请看《可持续的IT架构》文档。
• 数据分发服务。分发并确保数据按质按量地发送到需求端，提供安全的服务，定义标准数据格式并在需要时进行映射，收集并报告KPI信息（如，Tibco BusinessWorks和信息平台）
• 整合与编排服务。实现SOA标准，业务或技术编排层，收集并报告KPI信息（如BPMS工具、基于SCA的工具、BPEL工具以及面向工作流的工具等）
• 企业服务管理（Enterprise Service Management，ESM）。提供监控、策略描述和执行。它控制SOA的动态交互并为其提供方向。市场上已有为数不多的昂贵的商业软件（Amberpoint, Progress, SOA Software）及一款开源工具（Microsoft Managed Service引擎）。
• 企业服务监控。服务监控通常由ESMP提供。然而现在有些工具能够以比ESMP更低廉的价格提供此项功能（如 JaxView），或者是免费的引擎（如开源工具Microsoft受管的服务），或者是即将与支持Google Gadget的仪表盘一起发布的 WS02 注册库未来版 。
• 企业业务规则及事件服务。实现可持续是需要付出代价的。业务规则和事件的关联应该与代码分开管理；业务规则应独立于企业业务实体被定义、存储以及报告等；业务规则应显式地进行定义，而且，规则定义的变更不应牵连到其他的规则；规则应与顺序无关。
• 企业存储和/或注册服务。所有的生产及管理的资产应该在统一存储库存储并管理。一个注册库还可用在运行时，用来发现服务的一些元数据从而达到对服务的动态配置。
• 安全及策略管理和执行服务。为SOA平台启用安全应该尽可能简单化。为了避免把安全封装在服务调用之内，通常建议使用外部的安全策略与动态执行点 。所有的身份及访问管理提供商都提供了这方面的能力。当然也有一些纯粹的供应商专门提供此项能力。
• 外部网关服务。它用于在网络边缘保护公司内部的服务，优化消息传输以及提高与服务提供者的访问性能。最知名的提供商是 layer 7或 IBM Websphere DataPower。

图  8: mySOA 服务平台

在表1中，我们为每个mySOA参考平台服务提供了以下信息：工具的成熟度评价，实施它的知识系统的成熟度，是否开放服务，有无开源解决方案并且给出了我们所知的工具实例。

第一步可以用代码或XML以及XSD完成，从很多企业范围的项目来看人们更倾向于选择后则。而且，对于很多集成和应用开发场景（不仅仅在企业范围内），人们习惯于先商讨出WSDL/XSD的Web服务规范，然后再开始实际的实现服务功能的代码开发。然而，纯粹处理XML和WSDL很容易出错，WSDL更是非常难对付，原因是原始WSDL规范支持非常复杂的结构以及契约的定义。我们需要一些工具辅助我们一致且可靠地完成该级别的工作，而WSCF就是为此而生的。

 

mySOA平台服务	工具成熟度	知识体系	是否有开源	工具实例
企业消息服务	高	高	是	IBM, Microsoft, Mulesoft, Progress, Sun, Tibco等
主数据管理服务	中	高	是	IBM, Kalido, Orchestra Networks, SAP, Siperian, Sun, Talend等
服务配置主数据服务	低	低	是	需要自建
语义集成服务	中	低	是	Progress DataExtend SI, collibra, expressor
数据分发服务	高	高	是	Informatica, Tibco, Pervasive DataCloud 2 , IBM
集成与编排服务	中	低	是	Intallio, Tibco, ActiveBPEL, Oracle, Informatica
设计时治理	低	中	是	通常需与存储库绑定，同时我们使用企业服务测试工具做质量测试。
企业服务管理	低	低	是	Amberpoint SMS， Microsoft MSE， Progress Actional, SOA Software等
企业服务监控	中	低	是	JaxView， Amberpoint SMS，CA wily, WSO2等
企业业务规则和事件服务	低	低	是	Esker，Drools， Tibco业务事件，IBM Ilog，sci-flex
企业注册与/或存储服务	低	低	是	Software AG Centrasite, WSO2, Mule Galaxy, IBM WSRR, Adjoovo, Dragon SOA
安全及策略管理服务	中	中	是	Amberpoint, Sun, IBM, CA, Oracle, Vordel, layer 7, F5
外服网关服务	高	高	是	XML设备（Vordel, layer 7, F5, IBM）或Amberpoint
企业服务测试	高	高	是	SOASta， Parasoft SoaTest，Eviware SoapUI，ITKO Lisa，Actional Diagnostic与SOA Cleaner.

表 1：mySOA参考平台服务分析

实施mySOA参考平台的经验收获

从演示走到在生产环境中运行正式的系统永远是一个挑战。这点非常正确，尤其在SOA的产品市场尚未稳定而且标准如此繁杂、尚无最终定论和互操作标准的情况下。

缺少互操作标准

我们认为SOA采用和实现的最大阻力是缺乏合适的工具以及互操作性。现今，多数软件提供商利用SOA来推动他们整个软件栈甚至有时还包括硬件的销售。

在建模的一端，OMG的SOAML虽然已经在主要的UML工具中的到实现，但尚未得到广泛接受。Michael Poulin在这里说到，“SoaML不是面向服务的也不完全是架构建模语言，因为它并不完全支持架构实体的建模，相反集中于它们之间的关系（它虽然很重要但并不充分）”。而后它被OASIS SOA参考模型标准与OASIS SOA参考架构标准-草案所钟爱，他们定义了什么是SOA，什么是服务以及服务如何适用于面向服务的环境。

然而，我们的确认为SOAML可用于交互用途，这样就不需要整天与整个WS-*标准纠缠在一起了。另一个有趣的方法是使用语义来更好地定义服务及其交互。目前，这方面的研究仍然在其初期（如Semeuse，欧盟资助的项目 soa4all等）。

缺乏工具的互操作

除了SOA Software，Progress和Software AG（包含Centrasite插件的），其他所有的软件提供商首先考虑的都是他们自己的软件栈（IBM，Tibco，Oracle，Sun， Microsoft都是这样）。开源公司更愿意开放，但是他们也越来越喜欢集成他们自己的工具（OW2，SOAPera， WSO2）。

他们都声称支持WS-*以及WS-I，但是这并不够，而且众所周知。WS-I的用例无法快速跟进SOA实际的标准栈的发展，所以用户必须在其自己的环境里测试所有可能的配置选项。

Microsoft与Sun在互操作性上达成一致是个好事但这还是不够。在Sun Metro项目中，WSIT是对 JAX-WS的扩展，它提供了在Java Web服务与微软的Windows交互平台之间的互操作性。它集中在增强Web服务的安全、可靠消息传输和自动事务方面的特性 。

如proxisoft这样的新加入者，提出了一个有趣的，对我来说甚至很有诱惑的方法。你开发你的Java代码，它们能从你的Java Jar文件中创建你所需的服务。那样的话，你的服务就能与最初的代码完全分离地进行管理，因此提供了一个功能的网关。

投资语义数据的映射

如果你可以通过DSL或一些高端建模语言（如UML）创建出所需的能反映业务数据和服务的企业数据模型会怎么样？如何每个业务对象生命周期和关系能够被定义，如果数据服务契约能够自动生成，那又会怎么样呢？

如何你能深入现有数据并且将它们从真实的资源映射到这个新模型会怎么样？如果你可以将业务规则重用到业务逻辑并且将路由逻辑描述成可以存储在数据库中的元数据又会怎么样？你不觉得你的生活变得容易了吗？若干个月之前，市场上并无这样的解决方案，而现在已有好几个了（Progress DataExtend SI，collibra，expressor）。

利用EAI和ETL创建数据分发服务

如前文所述，我们在最开始启动了（从其所在的竖井中）解放数据的项目。我们还需要足够灵活，从而能在每次适配定制逻辑时不至于锁定某个解决方案。

这件事可以通过三个辅助方法完成（如图9）：使用集中主数据管理（MDM）、从应用创建数据服务以及创建标准格式来缓解企业内部与跨企业的数据分发。

如今大多数公司已经拥有EAI和ETL，也拥有了使用他们的知识。这些领域的开源提供者有一大堆（除了MDM，只有两个选择——Sun的Mural项目和 Talend MDM），而且一些甚至以SaaS的方式提供（Duns & Bradstreet Purisma）。

创建对应用中已封装的数据的访问需要定义最少三个接口：CRUD，查询和管理（启动、停止、数据连接器的状态）。我们称这些服务为基本服务。该方法可以受益于服务提供者与服务消费者之间的“规范模式模型”（CSM）。CSM缺省情况下会在任何消息（包括请求和相应）路径中强制两次转换。

图 9: ICC数据服务

模型驱动的MDM与语义集成工具的合并明显是一个双赢的局面。例如，如果你联合使用Progress的软件按DataExtend SI（数据语义集成），Orchestra网络 Ebx.Platform（主数据生命周期管理）以及Informatica Platform（数据质量，传输），你就能很快地创建一个强大的解决方案，它部分基于模型驱动。

不要忽略对服务配置主数据的管理

服务常常不得不基于客户端而进行配置，该配置信息总是要与服务一起维护。例如，行程单可以通过HTML邮件或PDF传送。对于每个客户端，该信息必须要存放在某个地方。在外部服务使用的情况这些信息更为重要（根据其合同某些能力可能都很大差异）。我们推荐将这些信息加入MDM工具或存放在专用的LDAP目录中。

不要混淆SOA与整合

SOA不是集成，虽然它与集成共享着某些技术。SOA关注创建服务，而服务封装了现有系统，所以新的解决方案能够在消费这些服务的基础上进行开发，而不需要重复创建获取这些信息的功能。若信息没有重复，就无需同步和备份。信息管理是一个宽泛的话题，但在SOA中它通常指的是数据聚集、添加语义、应用业务规则和提供富接口。

在面向服务的架构中，服务接口就是那个规范模型（图10）。它将服务消费者与系统信息记录分离开。若服务被很好地设计时，所有的消费者调用一个特定的服务，而这个服务反过来调用所有所需的后台系统。

这就是SOA很难实施的原因。现有的工具无法管理必要的灵活性，这些灵活性在Jean Jacques Dubray的关于SOA的消息类型架构的文章中有很好的定义。我们仍然使用集成工具实现SOA，出于不得已！因此我们尽量创建一个适用于大多数mySOA平台的基础。

图10：服务接口的规范模型

创建mySOA治理工作流

设计时和运行时都应实现SOA的治理工作流程。这是首要的问题，因为大多数工具并不能同时支持二者，不过，所有的SOA软件提供商都在尽力扩展他们的工具以提供对整合的支持。与此同时，你也可以使用BPMS工具实现你的校验工作流，或者使用通常集成在存储库中工具。

设计时治理

我们的设计时治理基于以下静态校验：

• WSDL，在SOATest中我们通过xpath中定义的规则进行校验。
• XML模式，使用xpath中定义的规则进行校验。
• Web服务安全，我们使用标准的SOATest校验规则。
• WS-I合规，我们使用SOATest中标准的WS-I测试工具。
• 新服务对现有服务的影响分析。

因此，我们的设计流程非常简单，它包含对所有我们创建并实现在SOATest中的标准的验证。测试的结果同时与其他资产一起在配置库中进行存储与管理。

例如，有一个规则，它检查WSDL的每个元素是否非空格字符。

• 标准：所有的WSDL操作必须包含一个元素。
• 执行：SOA测试规则，WSDL\CWT.OperationNullDoc。
• 错误消息：文档缺失，存在无文本的操作。

然后，在SOATest中通过使用WSDL策略执行器对规则进行验证（见图11）。

图  11：SOATest WSDL策略执行器

设计时治理——服务目录的圣杯

服务目录是SOA治理的圣杯。多数市场上的SOA软件提供商都在推他们的工具（Software AG， IBM，Oracle，Progress，HP，以及最近的Amberpoint）或者通过OEM集成在他们的产品之中。有些UDDI存储是基于客户端的，也有基于服务端的（但没有人会告诉你同步时会带来的影响），有些实现了WSDL tModel，有些没有。我们做的大多数产品之间互操作性测试都失败了，其原因不仅有软件提供商实现的差异，还因为UDDI标准中的一些死角。

SOA Software，HP Systinet以及Software AG试图在他们的软件之间实现互操作，多多少少有些成效（有些在一个版本中可以但是另一版本却不行，竞争总是存在）。

就像旁注一样，服务目录已成为存储库的一部分。市场上不再有单纯的注册产品了，也许有些开源工具（如Apache jUDDI）例外。UDDI注册已死，而存储库却能永生。你可以创建自己的工件并存储在注册库中，当然，你要为其找一个UDDI接口。

结论：因为过度工程化的标准（UDDI），所以目前市场上几乎不存在真正可互操作的解决方案。所以，提供商锁定的反模式是适用的。SOA没有死，但你应该承认其模型的一个关键部分已经消逝！我始终认为，对于一些能够提供存储/注册插件的公司来说有一个市场供他们销售插件

设计时治理——Software AG Centrasite与Parasoft SOATest

我们与Sofware AG在过去的两年内做了测试并进行了探讨。Centrasite 8.x版本几乎覆盖了所有我们所需的治理需求，特别在与SOATest集成上（见图12，图13及图14）。但我们不得不承认，我们仍然无法说服业务部门在设计时存储库上花钱，最后我们的产品还是到期了。

图  12：服务分类

图  13： 有Centrasit提供的SOSTest插件

图  14：SOATest设计时治理中的测试转换到Centrasite之后的结果。

所以，我们必须只能走穷人路线，感谢开源软件的发展，我们有幸使用MuleSoft Galaxy和Liferay portal来建立至少可以满足服务目录需求的解决方案（见图15，图16与图17）。

图  15： ICC服务目录——使用服务分类学

图  16：ICC服务目录——TravelerProfileSearch.wsdl

图  17：ICC服务目录——有WSDLDoc生成的文档

我们使用WSDLdoc记录WSDL和XSD，我们还测试了使用Intalio创建MuleSoft Galaxy中不支持的治理工作流并且发现它很好用。然而，我们认为开发SOA工具和把时间花在工具的集成上不是我们的工作，这是为什么我们对Centrasit机器“插件”（不过没有Firefox的插件那么易用……）更感兴趣的原因。

所以我们还在等待市场的成熟，等待价格下降以及等待软件提供商真正实现互操作性。开源工具能促使软件提供商作出反应。Mulesoft，Microsoft服务引擎与WS02 SOA等工具已经在很便宜价格上提供了很多特性。我做一点补充，如果这些工具都能以portlet（或widget）的方式提供出来，并能方便地集成到WebTop(netvibes, Google IG)或门户中，那将会非常强大。

运行时治理——服务消费者管理

ICC在企业中职能的一部分是负责策略的管理以及受管服务及业务接口的报表。

服务消费者代表服务的用户。服务消费者不是一个应用的GUI就是另一服务。服务消费者应该信任任何受ICC管理的服务都是遵循标准的。具体的服务消费者的管理职能包括：

• 熟悉技术上的集成标准；
• 当发现某服务不合规或者需要增强时，应遵循ICC治理流程。

为完成这些职能，ICC必须确保所有服务消费者都是已声明的并且要定期报告其使用情况。

在图18中，我们可以看到3个服务将被应用到AmberPoint Proxy上：

• 认证——通过存储在AmberPoint LDAP中的身份信息认证服务消费者；
• 用户凭证映射——使用静态用户名及密码对Accenture的请求进行认证；Accenture认证使用了HTTP基本认证；
• 日志——记录任何请求，响应以及错误信息。

图  18：ICC服务目录——由WSDLDoc生成的文档。

在图19中，我们将看到如何为这些服务定义性能约定。

图  19：ICC运行时治理——SLA的定义

运行时治理——最后一公里，史诗之战，说服IT运维。

当你谈到运行时治理时，一般自然隐含了硬件，网络和负载均衡等。现在来到了IT运维的地盘，ITIL无处不在而SOA并非等同于SMDB。最后一公里始终是你的SOA旅途中最艰难的部分。我们花了一年多的时间去部署运行时治理工具，并且其主要原因是来自人的抵制。因此，不要忽视这最后一公里！

运行时治理——SOA虚拟化

John Michelsen的一篇好文解释了服务虚拟化为什么重要。在SOA中至少有三个独立点可以使用虚拟化的概念：

1. 硬件虚拟化。“这并非专属SOA的工作，当你在一台物理机器上运行很多操作系统的拷贝时，虚拟化帮助你实现这些虚拟机器间互相独立”。

2. 虚拟服务端点。服务虚拟化架构通常伴随着（处在服务客户与服务实现之间的）服务代理的想法。“在某种意义上说，你在为你的服务消费者创建一个虚拟的访问端点，该端点用于服务访问而事实上你完全可以将真实的服务地址保护在后面”

3. 虚拟服务。“他们对于在每个测试步骤上实现敏捷的SOA测试（更简单的、迭代的、需求驱动的测试周期）特别重要，为什么? 因为如果你想提前测试，你要对未完成或开发中的组件进行测试”。

服务虚拟化应该由工具以服务的方式提供。

运行时治理——仲裁服务

仲裁服务实现两个目的（来自使用Jean-Louis Maréchaux的企业服务总线合并SOA与EDA）

首先，仲裁保证集成异构系统所需的协议适配。因为两个不同的服务不一定使用相同的传输协议，仲裁服务负责从一个协议到另一个协议的转换，这样交互才成为可能。对于在一个业务交易中的所有参与服务，协议切换是透明的。

其次，仲裁带来了转换数据内容的可能性，它是业务集成中的关键服务。它保证了通过总线的数据能够被所有流程理解。另外，仲裁还可以为消息扩充任何信息。内容转换由总线负责，并且对所有服务参与者透明。

结论

我希望你享受了这程mySOA之旅。建设SOA是艰辛的，标准和工具都很缺乏，而且其费用对于大多数中小型企业来说仍然是高山仰止。这解释了为什么大多数时候人们做得都是带着面具的SOA，并招致了很多麻烦及失望。

由于越来越多地提供了很多免费或低价的本地方式或者按需购买的功能，开源提供者正在撼动着这个市场。

如果开源产品还不够，你不能等，而且你不希望在互操作性方面进行技术投资，那么为大多数平台服务选择同一提供商也许是短期或中期的最佳之选（IBM，Sun/Oracle，Microsoft，SAP）。

SOA Software，Software AG，Progress，Tibco，Mulesoft与WSO2也能提供最佳的初始模块，如果需要，你还可将他们集成到你的私有解决方案栈中。

当工具能够帮助我们实现敏捷，为受管服务提供设计时及运行时治理时，SOA才能真正让所有人受益，才能为构建可持续的IT服务和系统作出贡献。

致谢

在这里感谢我的同事Bob Donley（圣.路易斯，美国）与Janusz Szyr（华沙，波兰）对这项工作所作出的贡献。若没有他们的想法，没有他们所付出的劳动，没有不同文化的SOA版本，就没有这件事的完成及这篇文章的问世。我还要感谢Patrice Simon，我们的经理，为他不变的信任和持续的支持。

最后，我要感谢Claude Mariaccia（IBM IT软件架构师），Ghyslaine Ferre Morel （Software AG法国的销售工程师），Miko Matsumura（Software AG的代理CTO），Paul Davidian（MuleSoft的客户总监）以及Thomas Been（Tibco解决方案顾问），感谢他们提供的支持与帮助并快速响应我们提出的有关他们的方案及工具的技术问题。

[1]可持续性IT架构，利用SOA进阶地翻修信息系统。BONNET Pierre,  DETAVERNIER Jean-Michel, ；VAUQUIER Dominique, ； BOYER Jér?me, ； STEINHOLTZ Erik, 3月 2009, ISTE-Wiley.

[2] 吞下IT大象：从绿地开发到棕地开发，Richard Hopkins与Kevin Jenkins，2008年5月， IBM出版社。