在我看来，可能没有受到足够重视的一项技术是“信息作为服务”或 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 工作情况。
（责任编辑：朱晶）
<<上一页
1
2
