6）信息规则
规则和规则的处理决定了数据是怎样变成信息的。它们在数据服务层提供了关系、语义和行为。如图2所示，规则分为几类：
管理规则给出利用物理数据层的系统和数据资源的各种要求和/或限制。这可能包括安全性、访问窗口（日期/时间）、缓存，元数据、事务和各种副作用或需要执行的辅助操作（例如，登录和审计）。
数据规则提供验证、一致性、反复确认和其它与数据准确性和一致性相关的规则。它们也能在物理模型或逻辑模型中提供缓存管理和其它的副作用。数据规则可作用于表级别、行级别、列级别或字段级别。
集成规则提供跨逻辑数据层和物理数据层的映射和一致性。集成映射更高一级的抽象到对应的逻辑层或物理层。例如，一个位于更高一级的抽象的用户ID是新的规范的数据模型的一部分，这个模型转换自/被转换到几个底层的来自若干用户数据库和/或后端系统的本地格式。集成规则位于系统和/或数据库层。
第五步和第六步可以颠倒次序。关键是确保逻辑模型不受当前物理资源的过度约束。换句话说，在逻辑模型将要利用物理数据服务的时候，不要让当前那些物理资源的局限性限制它们，或者对您的整个数据服务层设计施加过度的影响。物理资源是起点，接着是建立更丰富的更多表示形式的模型。
业务规则提供有意义的业务关系和一些业务逻辑，即行为。面向对象编程考虑的是封装在模型对象中的状态和行为。在数据服务中，业务规则扮演一个类似行为的角色。业务规则在数据模型层捕捉业务处理逻辑。这个逻辑是业务实体的恰当定义的基础，也是这个业务实体与其他业务实体的关系的基础，这些实体的关系是跨所有应用的业务实体固有的，例如，在一个企业级的或至少一个部门级的范围里。在这些规则中，有些是在规范的模型中定义的，而另外一些是在应用程序规范模型中定义的。
7）应用程序专门化
一旦完成了逻辑模型，您就有效地定义了一个规范的信息模型。这个模型的定义将完成您的信息模型的初始设计，就意味着您已经有效地开始将数据变成信息。还有最后一步，就是进一步改进您的信息模型：应用程序规范。
不是所有的消费应用程序将会直接使用规范的信息模型。应用程序规范为消费应用程序提供一个抽象层来定义它们自己的特定于其自身需求的逻辑模型。
应用程序规范封装了消费应用程序需要的额外的信息模型状态和行为，简化了消费应用程序对规范的信息模型资源的使用。由于每个消费应用程序或者一组关联的业务应用程序的应用程序规范都是惟一的，所以不需要在规范的信息模型中包括它们。如果应用程序规范包含更大范围（例如，跨部门或者跨企业），那么它应该成为规范的信息模型的一部分。
结束语
为SOA参考架构创建数据服务层和为组织定义规范的信息模型是困难的，这些任务实现起来都非常困难，而具有挑战性的任务又很少能赢得什么荣誉：实现起来非常困难，很少能够做到最好。本文所述的方法应该能给您足够的信息去规划、评估和开始设计数据层的SOA转换，并将组织的数据变成信息。在实际当中，SOA参考架构的数据服务层的规划、设计和开发依赖于许多特殊的因素，这些因素特定于您的组织或状况，它们已经超出了本文所讨论的范围。
既然我们已经开始在SOA系统中把我们的数据变成信息，那么我们可以考虑把这些信息变成知识。本系列的第二篇也是最后一篇文章“SOA中的数据，第二部分：将信息转换成知识”将介绍这一过程。
参考资料
相关博客和文章，请访问Dev2Dev的 AquaLogic Data Services 产品中心(中文网址：http://dev2dev.bea.com.cn/products/aqudtpt/index1.html)。
Information Integration Using the AquaLogic Data Services Platform——Manu Madhusudhanan R编著（Dev2Dev，2005年），关于数据服务层引入的一个极好的介绍。
作者简介
Richard Scott Manning 是美国南部地区BEA专业服务部的企业级架构负责人。主要关注的领域有：企业级架构，SOA，BPM，组织与管理，信息与知识建模，Web 2.0，语义网与人工智能 。
文章来源于领测软件测试网 https://www.ltesting.net/
