5)数据建模

　　从第一个选定的资源开始(我建议您首先端到端地制作一个资源，也许不是最高优先级的那个，这允许您使用控制度更高并且便于管理的方式实现数据管理和数据服务层的SDLC过程)，对现有的物理方面进行检查。对于数据库或者一组表，考虑来自用户的各种查询、数据库的逻辑存储过程及其触发器、各种具有副作用的操作。这构成了物理数据资源定义和描述。对于信息访问，要使用什么呢?MOM、第三方适配器、专有的集成或者点对点的定制集成?这构成了物理信息资源定义和描述。

　　由于数据服务层是完整的SOA参考架构的一部分，所以应该规定SOA构建块的定义和要求。您的资源的当前状态与SOA RA构建块的目标状态之间很可能存在差距。业务的第一步是引导当前的物理状态尽可能地接近您的SOA构建块目标状态标准。您可能会想起前面讨论的关于SOA参考架构中“服务”的定义和描述。为简单起见，假设您的服务定义要求包含WSDL、SOAP和用XSD定义的文档样式。其它推荐的规范包括 WS-Addressing和XQuery/XPath。有了这个定义，我们需要考虑怎样把关系数据库、XML数据和/或信息访问系统中的表转换或者映射到一组满足构建块服务定义准则的服务上。

　　有许多不同的工具和技术可以映射现有的数据和信息访问资源到图2所示的物理数据层，定义与您的特殊要求和服务定义一致的逻辑服务模型。BEA的 AquaLogic Data Services Platform(ALDSP)是我们的从数据/信息访问资源向SOA构建块(数据服务)转换的实现技术，它为您的SOA参考架构提供了基于标准的、面向服务的数据服务层。

　　一旦您导入了您的物理资源(不考虑它们的接口和实现)，您就有了物理的数据服务层(参见图2)。物理的数据服务层中的服务有着一致的外观和表示——即底层的实现细节和通信协议被抽象化和封装，并且从视图中移除(必要时，您仍然可以访问底层)，只提供了资源定义(服务定义)和操作的信息。 既然您有了自己的“数据”，下面该定义您的逻辑模型。

　　6)逻辑建模

　　逻辑建模的目标是抽象、集成、规范和管理一个或多个物理数据服务的集合，可以将这些操作抽象到两个层上：逻辑数据标准化层和逻辑数据集成层，如图2所示，它们也有一组可用的规则：管理规则、数据规则、集成规则和业务规则。

　　在进一步讨论之前，需要注意： ALDSP允许支持您的逻辑抽象设计要求所需的任何逻辑层。这些逻辑层只是面向设计时的，其作用是允许设计和开发人员有效地分离和分层逻辑模型和内容。这些逻辑层不是运行时部署的一部分——也就是说，即使设计时可以有若干逻辑层，但它们并没有对应于运行时的一组间接层。通过平展和优化，它们成为一个运行时层。开发和操作人员能够察看这些运行时工件和优化，并且在认为必要时进行调整。

　　您可以规定一组不同的准则和因素作为逻辑模型层的基础，而不是我在这里所使用的。例如，可以有单独一个层来包含所有的逻辑抽象，也可以有若干个逻辑层。经证明，逻辑层太少可能有限制作用并可能随时间增加了复杂性。至少，您应该规定一组准则来确定逻辑抽象层和它们所包含的内容。

　　例如，您可以有一个逻辑抽象来执行标准化，如图2所示。逻辑数据标准化层允许您“清除”和简化任何复杂的或混乱的信息。改变那些您不直接拥有或负责的现有数据库或者其他系统的物理结构通常也是困难的，或者任何程度的改变都是不可行的。逻辑数据标准化层让您可以重新构建而不必强制改变物理数据层。(如果您需要关于“数据标准化”的更多信息，我建议您用“数据标准化”进行Web搜索，会了解到更多的相关内容和要求。)这个逻辑层提供一个模型设计，当更新或退出直接使用这些数据资源的系统时，它可以用作未来物理数据和信息的模型。逻辑数据服务的目标是提供一个高级共享服务和消费应用程序更加易于使用的、更加易懂的和更加可重用的服务模型。

　　第五步和第六步可以颠倒次序。关键是确保逻辑模型不受当前物理资源的过度约束。换句话说，在逻辑模型将要利用物理数据服务的时候，不要让当前那些物理资源的局限性限制它们，或者对您的整个数据服务层设计施加过度的影响。物理资源是起点，接着是建立更丰富的更多表示形式的模型。

　　7)信息规则

　　规则和规则的处理决定了数据是怎样变成信息的。它们在数据服务层提供了关系、语义和行为。

　　管理规则给出利用物理数据层的系统和数据资源的各种要求和/或限制。这可能包括安全性、访问窗口(日期/时间)、缓存，元数据、事务和各种副作用或需要执行的辅助操作(例如，登录和审计)。

　　数据规则提供验证、一致性、反复确认和其它与数据准确性和一致性相关的规则。它们也能在物理模型或逻辑模型中提供缓存管理和其它的副作用。数据规则可作用于表级别、行级别、列级别或字段级别。

　　集成规则提供跨逻辑数据层和物理数据层的映射和一致性。集成映射更高一级的抽象到对应的逻辑层或物理层。例如，一个位于更高一级的抽象的用户ID是新的规范的数据模型的一部分，这个模型转换自/被转换到几个底层的来自若干用户数据库和/或后端系统的本地格式。集成规则位于系统和/或数据库层。

　　业务规则提供有意义的业务关系和一些业务逻辑，即行为。面向对象编程考虑的是封装在模型对象中的状态和行为。在数据服务中，业务规则扮演一个类似行为的角色。业务规则在数据模型层捕捉业务处理逻辑。这个逻辑是业务实体的恰当定义的基础，也是这个业务实体与其他业务实体的关系的基础，这些实体的关系是跨所有应用的业务实体固有的，例如，在一个企业级的或至少一个部门级的范围里。在这些规则中，有些是在规范的模型中定义的，而另外一些是在应用程序规范模型中定义的。

　　8)应用程序专门化

　　一旦完成了逻辑模型，您就有效地定义了一个规范的信息模型。这个模型的定义将完成您的信息模型的初始设计，就意味着您已经有效地开始将数据变成信息。还有最后一步，就是进一步改进您的信息模型：应用程序规范。

　　不是所有的消费应用程序将会直接使用规范的信息模型。应用程序规范为消费应用程序提供一个抽象层来定义它们自己的特定于其自身需求的逻辑模型。

　　应用程序规范封装了消费应用程序需要的额外的信息模型状态和行为，简化了消费应用程序对规范的信息模型资源的使用。由于每个消费应用程序或者一组关联的业务应用程序的应用程序规范都是惟一的，所以不需要在规范的信息模型中包括它们。如果应用程序规范包含更大范围(例如，跨部门或者跨企业)，那么它应该成为规范的信息模型的一部分。

　　结束语

　　为SOA参考架构创建数据服务层和为组织定义规范的信息模型是困难的，这些任务实现起来都非常困难，而具有挑战性的任务又很少能赢得什么荣誉：实现起来非常困难，很少能够做到最好。本文所述的方法应该能给您足够的信息去规划、评估和开始设计数据层的SOA转换，并将组织的数据变成信息。在实际当中，SOA参考架构的数据服务层的规划、设计和开发依赖于许多特殊的因素，这些因素特定于您的组织或状况，它们已经超出了本文所讨论的范围。

　　既然我们已经开始在SOA系统中把我们的数据变成信息，那么我们可以考虑把这些信息变成知识。本系列的第二篇也是最后一篇文章“SOA中的数据，第二部分：将信息转换成知识”将介绍这一过程。