好公司中的SOA

团队协作

SOA 切实地发生着。采用 SOA 时，将影响整个企业，而不仅是 IT 部门。

企业内不同的组织(可能到目前为止都采用相当独立的方式运作)突然被要求重用其他人的服务，并为创建共享服务提供支持。企业内可能会对这个新的"共享"安排有所顾虑。例如，组织 A 创建了关键型服务 X 来支持他们的某个解决方案。他们并不希望将服务向其他组织的应用程序公开，因为他们并不控制其他应用程序，担心这些应用程序可能会使得此服务崩溃。此外，如果组织 B 的应用程序使此服务崩溃，则可能会导致组织 A 的解决方案也停机。可以这样说，就像将所有人都将鸡蛋放入同一篮子一样。

这个顾虑非常有道理，事实上必须对所需的需要与给定共享服务关联的服务质量进行积极评估，从而对其加以处理。不同的组织可能会依赖于相同共享服务的不同服务质量，如果差异足够大，从财务角度(不是管理角度)来看，认为应该部署该服务两次。

现在，在组织开始对共享服务的最优服务质量吹毛求疵前，可能会希望对共享服务接口的情况达成一致。如果组织 A 和组织 B 均在过去创建了类似的服务，无疑将会就 A 的服务和 B 的服务如何进行组合以形成共享服务的接口进行讨论。此类讨论总是会相当激烈，两个组织都会非常在意其一直依赖的服务的接口中采用所需更改而需要进行的工作。通过部署在之前已经存在的服务与新共享服务间进行转换的 facade 服务，可以简化此转换工作。

很可能在服务调用者和提供者之间存在某个业务实体。谁应该定义实体的表示方式?间接来说，"业务部门"应该负责此工作。应该制订业务术语表，以文字的方式描述"供应商"和"项"之类的业务概念。还应该捕获每个概念的动态方面的信息，类似于如何在业务内对其创建和使用之类。将由"业务部门"在数据架构师的帮助下从术语表中派生出逻辑业务信息模型。可以从逻辑业务信息模型派生出持久性模型(可以采用 DDL 表示)和服务信息模型(可以采用 XSD 表示)。

正如您所看到的，不仅不同组织的 IT 人员必须开始彼此交流，而且其对应的业务人员也将进行类似的沟通。和 IT 一样，这些人员很忙，可能需要让他们确信他们在定义服务接口的过程中扮演着一定的角色(虽然是间接的)，但在业务级别达成此一致前，IT 仅仅是对需求进行猜测而已。

耦合和分离处理新关系

好，现在每个人都在彼此进行交流，而且我们都在扮演着自己的角色，那就可以创建该死的共享服务了，对吧?是的，从技术角度而言的确如此，但由于每个组织目前都负责自己的 IT 支出，那谁将为共享服务提供资金投入呢?共享服务是否可以承载于某个依赖组织的 IT 部门，或者是否将创建某个共享服务组织以某种方式为其提供资金投入呢?如果由现有组织承载，其他组织是否要为服务实现的扩展做出一定的贡献，以便此实现能够支持所有依赖组织的需求?如果服务由共享服务组织承载，该组织是否将采用集中方式提供资金支持，或者从依赖于共享服务的各个组织的预算中提供资金支持?谈到资金投入，共享服务的成本模型是什么样的?如果给定服务需要 IBM? WebSphere? Process Server 之类的新技术，且该服务是驱动对此新技术的需求的第一个服务，则此新技术的全部成本(人员、培训、辅助监视、管理、维护成本等)都归于此新服务，还是采用摊销方式分摊到使用此新技术的后续服务?

可以采用很多方式处理这些事实，虽然"正确"解决方案将会根据组织不同而有所不同，但重要的是要认识到解决此方面问题的需求并加以计划。此组织耦合是由于希望重用服务和更好地保持 IT 与业务的一致性而引起的，可能会从组织变更方面的专家的帮助获益，例如通过 IBM 全球业务服务部提供的专业指导等。

我们已经讨论了 SOA 技术增加耦合的领域，接下来我们将注意力转向组织之间耦合减少的领域。在这种情况下，两个组织都是 IT 部门的下属部门。我将以应用程序开发团队和数据(或信息)管理团队为例。

在我看来，可能没有受到足够重视的一项技术是"信息作为服务"或 IaaS。其原理非常简单：从技术和组织的角度将应用程序同信息分离，在应用程序与其使用的信息之间引入代理服务。应用程序领域属于应用程序开发组织，而数据管理(或信息)则属于数据团队。应用程序团队通过从接口规范派生的项访问规范形式(还记得服务信息模型吗?)的信息，对信息如何产生并不关心。数据管理团队决定信息如何存储及其存储位置。

在这二者中进行更改时，并不会对彼此造成影响。例如，在现有企业中一种常见的情况是，信息存在于数据中心中的多个位置。财务与采购部门可能具有自己的半自动数据库，并具有自己的"供应商"定义的变体，所表示的供应商信息大量重复，但并不完全相同。业务部门可能会在某一点就"供应商"的规范定义达成一致。将通过信息服务访问供应商(创建 (Creat)、读取 (Read)、更新 (Update)、删除 (Delete) 和搜索 (Search);简称 CRUDS);此信息服务使用从业务信息模型派生的服务信息模型。所有新应用程序应该使用规范形式，而且在可能的情况下，所有更新的应用程序也应该采用此形式。为了尽可能减小"对象模型阻抗"(对象模型间转换的运行时与维护开销)，应用程序应该将供应商服务信息模型内部化。此工具可通过使用工具来方便地完成，此类工具可方便地生成服务接口中使用的元素的应用程序技术表示形式。例如，如果 IaaS 服务接口以 WSDL 表示，而应用程序技术是 Java?，大量工具都支持从 WSDL 接口定义生成 Java 类。无疑，应用程序可能需要根据其用途通过派生或封装对生成的类进行扩展。

现在让我们回到供应商服务。数据团队具有生成供应商服务的责任，而在 IBM Information Server 之类的产品中提供了支持此工作的工具。服务可能是熟悉的数据访问技术上的 thin Facade，如嵌入式 SQL 或 SQL，或者最好是提供联合、清理和转换功能的现成软件包。后一种方法将更好地促进对整个企业内的供应商不同表示形式的收集，并能帮助采用规范形式将其重新公开。此外，可以切实地通过工具的集成来优化数据治理的某些方面，以捕获业务术语表、派生业务信息模型、管理信息服务和创建清理与转换规则。

顺便提一句，我某天遇到过一个公司，他们的应用程序开发团队非常关心对象到关系映射(Object to Relational Mapping，ORM)技术。让应用程序开发团队关心 ORM 是与封装及分离对立的。ORM 可能(我并不推荐这种方法)在服务实现中会起到作用，而这是我们认为属于数据团队领域内的内容(您也这样认为，对吧?)。我强烈建议使用框架或工具来避免这种有问题的数据管理方式。

业务与 IT 的一致性

让我们把注意力转到 SOA 引入耦合需求的另一个方面，营销材料中将其称为"一致性"。我将其目标视为业务与 IT 中的可变点的一致性。业务领域中的变量不应作为 IT 领域中的变量实现。我之所以在讨论 SOA 时提到这个问题，是因为我们有时候会在讨论服务接口定义(这对 IT 人员而言是变量)时遇到这个问题。

以下是我最近看到的一个例子：某公司希望在整个企业和渠道内进行一致业务决策。他们明智地将业务逻辑提取到业务规则引擎中，并通过 Web 服务提供对业务逻辑的访问。假定该服务为"getEligibleProducts"服务，业务规则使用关于客户的已知事实来向客户提供其可能感兴趣的公司产品列表。第一天，当 IT 部门与业务部门一起决定服务的接口情况时，业务部门表示出了对在业务规则中使用客户体重、身高和邮政编码来计算合适的产品的兴趣。创建、部署服务并至少由一个解决方案使用后，业务团队提出他们希望添加规则，以将客户年龄考虑进来。服务接口接受体重、身高和邮政编码，但不接受年龄。IT 团队估计至少需要一个月(有可能需要两个月)来对服务提供者和使用者进行更改和执行必要的测试。可想而知，业务团队非常失望，因为"这个 SOA 原本应该让 IT 更为灵活，但它却使其变得更糟糕"。

在我看到的这个特定示例中，IT 通过将关于客户的每个已知事实(约 800 个元素)传递给服务，然后服务将使用其中很少的一部分(约 5 个元素)。其基于的想法是，无论业务部门希望在规则中包含任何事实，这些事实都对服务可用。由于 XML 具有非零处理开销，而这增加了元素的复杂性和基数性(具体取决于服务的使用模式)，因而此解决方案可能会带来性能问题。从学术角度而言，它仅仅延迟了迟早需要解决的问题，因为在将来某个时间收集更多的事实时，将需要对接口进行更改。有很多替代解决方案的变体，但都归结为，不要在 IT 领域的不可变概念中实现可变业务概念。一个建议的解决方案是，提高客户机的复杂程度，从而在所需的变量中包含变量。服务接口将公开属性容器，其中可以随意包含与业务设想一致的属性数量。客户机将在服务注册中心查找相关信息来确定服务需要哪些事实，并将其包含在容器中。显然，这种方法缺少在服务接口中准确制定参数所带来的开发类型安全，从而引入了对服务中进行更为安全的错误处理的需求，但您得做必须做的事。

这些仅是众多示例中的一部分而已，说明了 SOA 可能会如何影响组织间的耦合、关系以及交互(这些组织以前没有交互，或者没有很正式地进行此工作)。推出 SOA 可能是个挑战，但其中充满了乐趣，因此可以让我知道您的 SOA 工作情况。(天极网)