SOA中的数据之将数据转换成信息(二)

当前位置:数据服务 > 数据服务文档   发表日期:2010年8月9日

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

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

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

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

2)确定依赖关系矩阵

一旦您已经开始创建资源目录,第二步就是确定依赖关系矩阵。依赖关系矩阵也是资源元信息的一部分,它获取关于资源的使用者、使用时间、使用频率、使用目的(例如,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数据和/或信息访问系统中的表转换或者映射到一组满足构建块服务定义准则的服务上。

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

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

6)逻辑建模

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

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

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

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

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

7)信息规则

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

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

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

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

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

8)应用程序专门化

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

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

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

结束语

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

SOA中的数据之将数据转换成信息(一)

IT168 技术文章

站点新闻
数据服务文档
互联网资讯