SOA中的数据，第1部分：将数据转换成信息

　　数据和数据管理是几乎所有企业软件解决方案的关键因素。SOA也不例外。有效的数据建模和管理是成功实现SOA的基础。要将数据提高一个层次，需要把数据转换成信息；要将信息提高一个层次，需要把信息转换成知识。

　　本文是关于“SOA中的数据：将数据转换成知识”的两篇系列文章的第一篇。本文通过SOA参考架构（SOA RA）的定义介绍了在SOA中从数据到信息的转换方法，它构成了完整SOA转换方案的一部分，并且还讲述了一个企业SOA的实现。这个系列的第二部分描述了在SOA中从信息到知识的转换方法，这是对完整SOA转换方案的一个扩展，并且还描述了一个企业SOA RA的很有价值的扩充。

　　为什么使用数据？

　　数据是普遍存在的（data是复数；datum是单数，尽管“data”能够同时使用单数和复数）。大部分 IT工作的核心就是收集、分发和管理数据，并且当需要数据的时候、在需要数据的地方、以要求的方式为需要数据的人（拥有正确的权限）提供数据。有些人可能会想起在IT（“信息技术”）这一术语出现之前，多数的企业把他们的“计算机部门”及其工作称为DP或“数据处理”。

　　在过去、现在和可预见的将来，数据是所有技术浪潮中一个不变的常量。同样的数据，过去由（很可能仍然是）大型机处理，现在也很可能已经由一个或多个的客户机-服务器、CORBA/DCOM、 Java EE、.NET、 Web services、SOA和Web 2.0来完成。随着时间的流逝，数据的存储、格式和传输可能已经改变，数据的处理方式可能已经改变，但是“数据”依然保留（而且还在增加）。其实，所有工业技术浪潮有着一个相同点：它们都是新的或者改良的数据处理方法。数据就是基础。如果您您也认为数据是企业解决方案的基础，则由此得出结论：数据（以及数据建模/管理）也是SOA（与Web 2.0）的企业架构需要优先考虑的事情。

　　数据是什么？

　　让我们先看一下字典中“数据”的定义，然后对其进行补充。就本文而言，数据是基本的、最小的，或者拥有一些结构、关系和状态的“信息”片断的底层集合，但不包括行为。例如，一个包含街道地址、城市等数据列的地址表是数据。就像一个用户表中的地址定义。数据是结构和状态，但没有行为。数据是构成信息的原始的构建材料。数据是信息的前提。

　　信息是什么？

　　让我们再看一下信息的定义，然后对其进行补充。就本文而言，信息是数据的集合，是提供附加的形式、基本关系、语法和语义上下文的基本逻辑——也就是说，它是状态和核心模型行为。例如，确保ZIP码有效并与城市一致。信息是数据的扩展，它向和域（语法和语义）上下文一致的行为模型提供映射或关联数据、定义逻辑的能力。信息基于数据，需要数据。换句话说，信息表示封装了状态（数据）和行为（逻辑）的实体（主体，对象）。可以认为信息类似于面向对象编程中的模型类的实例，这个实例包含用于保持状态的数据成员（实例变量）和提供（模型）行为的方法。

　　SOA中数据的价值

　　各种组织对于定义和细化自身SOA参考架构（SOA RA）有着不同的动机、出发点和优先次序，向SOA转换时可能会发生变化。规划设计SOA RA的完整方法应该包括数据服务（data services）层。本文采用数据服务层这一术语包含数据和信息访问服务。

　　如果在SOA RA中没有企业数据服务层，则其后的业务项目将被迫开发成特定于每一个应用程序的专用“点”或者一次性解决方案。几乎没有通用性，几乎没有共享的服务定义、重用和一致性，规范的数据模型的定义也会变得难懂。如果认识到SOA的优点，则会逐渐认识到它的众多优势。我们很可能都看到过这样的统计信息：企业应用程序软件开发的５０％到８０％的项目资源消耗在数据集成任务上。这一“事实”应该足以确定在任何SOA实现中数据服务层是必不可少的一部分。企业软件解决方案的主要设计目标是数据处理，结合这一概念， SOA 中数据的价值应该非常明显。

　　图１展示了BEA的SOA参考架构较高层次上的概念，它说明了位于上面的几个层。注意，数据服务层位于第一个区域，这表明它在SOA RA中的重要性。

　　图1：SOA参考架构的层次

　　数据、数据模型和数据管理是SOA成功的基础。实际上，BEA对数据服务如此高度地重视，以至于我们不仅提供 AquaLogic Data Services Platform产品，还把数据服务当作许多 BEA Consulting服务产品的基础，其中包括一个Data Services Consulting Service，该服务着重于SOA数据和信息层的规划、设计和开发。

　　关于数据访问和连通性服务的注释

　　访问数据资源的数据访问服务通常被总称为企业信息系统（EIS），也叫数据库和文件系统。它们可以是遗留系统、记录系统，包装好的商业应用程序、用户、伙伴、第三方应用程序和服务，以及Web services。它们的共同之处是向其他应用程序提供数据和/或信息（在本文中的意思是行为）。因此，这些应用程序在通过数据访问层被访问时就是数据的另一种形式或另一个数据源。在一个更高的抽象层上，数据服务与消费应用程序看上去一样，这是SOA RA的数据服务层的主要目标（标准化/一致性）之一。公开的接口与一个或多个数据库、表、后台、遗留系统、快速收缩的系统和/或外部系统交互，这是数据服务层封装的一个实现细节。

　　连通性服务以基于标准的方式将应用程序和数据库公开为应用程序服务。

　　将数据转换成信息

　　假设您的组织正计划向 SOA转换。 SOA RA的所有层和所有方面（见图1）的研究和规划已经开始，您的任务是数据服务层的实现。现在该怎么办？想想下面的几个步骤：

　　盘点现有的数据和系统访问资源

　　确定依赖关系矩阵

　　建立基线度量/SLA

　　设置资源优先级

　　执行数据建模

　　创建逻辑建模

　　设置信息规则

　　建立应用程序规范

　　图2是SOA RA数据服务的一组可能的内部抽象层示例，这里将采用我们的9个步骤来映射这些需求和性能。

　　图2：数据服务层——内部层抽象

　　基于现在和将来的需要，您可以为一组不同的抽象层定义需求。至少，您应该分离物理层和逻辑层，并相应地分配规则类型。

　　现在，让我们更具体地看一下每一个步骤。

　　1）盘点现有的数据和系统访问资源

　　第一步是确定数据内容，即您您当前的数据和信息系统访问资源。您您的组织拥有哪些数据和信息资源（本文后面，简称为“资源”）？例如，数据库、信息资源和应用程序（指遗留系统、记录系统）。对于每一个资源，您需要了解支撑元数据，如文档、历史、技术／工具／产品／平台、版本、所有权／管理部门、位置、安全性和访问机制。根据资源及其元数据的数量，您可能想考虑某些元数据目录或者储存库，也可能是一个或一组标准模板，能够以一致的方式获取元信息并允许进行检索。

　　２）确定依赖关系矩阵

　　一旦您已经开始创建资源目录，第二步就是确定依赖关系矩阵。依赖关系矩阵也是资源元信息的一部分，它获取关于资源的使用者、使用时间、使用频率、使用目的（例如，CRUD）和使用地点（即，访问类型——成批的、在线的、实时的或报告式的）的信息。了解用户为何使用某个特殊的资源也是很重要的，这将有助于任务优化，而且为新的数据模型提出要求。

　　一旦您得到了使用某个资源的每个已知用户的情况——“使用者、使用内容、使用地点、使用时间、如何使用以及为什么使用”，您就可以开始分析和形成所有资源用户的概括。这样做的目的是要找到在现有资源向SOA构建块转换的过程中进行简化和重用的可能。它们包括，但不限于，那些面向服务的、自描述的和可发现的资源，这些资源能够便捷地应用于采用开放的、公共的、行业和／或企业标准的SOA生态系统。

　　在这组SOA构建块中包含的一个定义是您的服务定义。要使用什么样的标准、规格和版本呢？例如，可能会要求 WSDL、SOAP、UDDI、WS-Security、WS-I Basic Profile、WS-Addressing、XML和XSD之中的某一个的特定版本，而其它的则可以是可选项／推荐项。数据和信息访问资源很可能会采用与基本SOA构建块定义（即服务）一致的格式。（使用您喜欢的搜索引擎搜索“Service Identification”和“Service Definition”这两个主题可以找到这方面的内容。）

　　建立基线度量／SLA

　　由于每个编目好的资源已经以某种方式存在，所以应该具有预测的或者实际的产品使用统计信息，包括事务规模、模式、并发用户、可靠性、可用性、可伸缩性和性能（RASP）等方面的信息。

　　使用信息也很好地表明了业务和IT的价值和优先权。这个基线信息用来定义一组度量，这组度量将构成服务级别协议（SLA）并允许目标定义和历史跟踪。为了支持 SOA的数据服务层，要规划软硬件的大小和容量，在这一过程中，度量和当前产品信息的价值是无法估量的。确定您的SLA是双向的，即服务提供者针对每个用户定义SLA术语、条件和处罚；用户应该遵守这个协议。

　　例如，一个协议声明用户A每天（这里指一天24小时，从午夜GMT12:00开始计算）可以在DataServiceXYZ（资源/服务的提供者）上执行最多100个get()请求，而每个请求的响应时间将≤2秒。如果用户A发出了超过协议规定的最大数量的get()请求，那么服务提供者能够根据协议规定对其处罚。对服务提供者也有相应的要求。如果用户A的请求数量不大于规定的最大值，则服务提供者必须提供≤2秒的响应时间，否则就要面对协议规定的相应的处罚。

　　度量和SLA定义约定的要求和规则，这些要求和规则影响每个资源的价值、目标和规模的基础。跟踪并重用您的基线度量、SLA，建立一个成本和效益模型。

　　有了上述的一定程度的一组已获取信息，应该可以在所有其它的编目好的资源上下文中开始评价每个资源——即，指定每个资源的优先权。一个好的策略是拥有最少3个、最多10个优先权级别（过多了）；小于3个不够，多于10个难于管理。

　　优先权分配的目的是帮助识别在应用上最重要的资源和所支持的业务功能的价值。您应该设计一组度量（包括第三步中的那些）和定义来根据经验比较和评价每个资源，以确定其优先级。分配资源优先级将有助于确定项目的合理起点、潜在的∵业务/IT赞助和相关的业务价值。

　　当这些资源向SOA构建块转换时，使用上述的所有信息能够建立、记录和跟踪每个资源的“当前使用”快照。对于剩下的几个步骤，应该在所有编目好的资源中选择那些被指定为最高优先级的资源。实际数量的选择要根据您的风险评估、优先权评价、业务/IT目标、资源以及其它类似的因素来进行。

　　5）数据建模

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

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

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

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

　　6）逻辑建模

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

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

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

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

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

　　7）信息规则

　　规则和规则的处理决定了数据是怎样变成信息的。它们在数据服务层提供了关系、语义和行为。如图2所示，规则分为几类：

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

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

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

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

　　8）应用程序专门化

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

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

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

　　结束语

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

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