【SOA】 mySOA：敏捷的、治理的并且可持续的 （ZZ）

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

我们称之为mySOA方法。

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

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

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

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

mySOA方法应该是敏捷的

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

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

敏捷

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

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

mySOA方法应该是可持续的

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

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

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

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

1. 整改的SOA.

2. 大检修的SOA

3. 扩展的SOA

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

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

mySOA依赖于卓越中心

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

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

图 2：ICC的两个组成部分

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

业务层

IT层

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

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

图 3：ICC组织提供的服务

寻找“我的”服务

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

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

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

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

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

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

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

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

改建式开发

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

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

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

一些最佳实践

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

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

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

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

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

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

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

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

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

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

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

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

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

服务分类

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

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

图 4: ICC的高层服务分类

技术或基础域服务

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

我们来看一个例子：

业务域服务

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

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

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

应用域服务

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

服务的生命周期

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

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

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

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

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

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

图 5: mySOA治理过程

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

图 6：改造SOA的RUP过程

业务服务接口

一个业务服务的接口

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

图 7: ICC高层服务分类

mySOA，我们如何做到？

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

mySOA的平台需求

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

mySOA参考平台

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

图 8: mySOA 服务平台

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

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

mySOA平台服务

工具成熟度

知识体系

是否有开源

工具实例

企业消息服务

高

高

是

IBM, , , , Sun, Tibco等

主数据管理服务

中

高

是

IBM, , , SAP, , Sun, 等

服务配置主数据服务

低

低

是

需要自建

语义集成服务

中

低

是

SI, ,

数据分发服务

高

高

是

, Tibco, 2 , IBM

集成与编排服务

中

低

是

, Tibco, , ,

设计时治理

低

中

是

通常需与存储库绑定，同时我们使用企业服务测试工具做质量测试。

企业服务管理

低

低

是

SMS， MSE， , SOA 等

企业服务监控

中

低

是

， SMS，CA wily, WSO2等

企业业务规则和事件服务

低

低

是

Esker，， Tibco业务事件，IBM Ilog，sci-flex

企业注册与/或存储服务

低

低

是

AG , WSO2, Mule , IBM WSRR, , SOA

安全及策略管理服务

中

中

是

, Sun, IBM, CA, , , layer 7, F5

外服网关服务

高

高

是

XML设备（, layer 7, F5, IBM）或

企业服务测试

高

高

是

， ， ，ITKO Lisa， 与SOA .

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

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

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

缺少互操作标准

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

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

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

缺乏工具的互操作

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

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

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

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

投资语义数据的映射

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

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

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

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

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

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

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

图 9: ICC数据服务

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

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

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

不要混淆SOA与整合

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

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

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

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

创建mySOA治理工作流

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

设计时治理

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

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

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

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

图 11： WSDL策略执行器

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

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

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

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

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

设计时治理—— AG 与

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

图 12：服务分类

图 13： 有提供的插件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

运行时治理——SOA虚拟化

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

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

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

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

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

运行时治理——仲裁服务

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

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

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

结论

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

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

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

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

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

致谢

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

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

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

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