SOA案例研究:将信息作为服务

日期: 2008-06-22 来源:TechTarget中国

  本文中的案例研究重点说明与具有 SOA 服务接口的 JKHLE 中的公开信息相关的挑战和解决方案。


  案例研究简介


  JKHL Enterprises (JKHLE) 正在进行一系列的基本业务变更,期望最终能够获得最大收益。JKHLE 已决定采用 SOA 原则来解决其面临的业务和 IT 挑战。


  JKHLE 团队的工作重点是在各个销售渠道中以一致的方式解决因创建新客户帐户而带来的难题。此 SOA 采用计划被称为帐户开立项目 (Account Open Project)。使用 SOA 方法有利于在未来业务发生变化时进行更快的实现和提供更大的灵活性。


  我们在本文中介绍的案例研究包括以下关键人员和角色:


  Ursula DeBarry,认证数据库分析师兼企业架构师


  Sandy Osbourne-Archer,首席技术架构师


  帐户开立项目的挑战


  我们在本文中定义的帐户开立项目挑战与“将信息作为服务的 SOA 场景”相关。


  帐户开立项目体系结构团队的工作重点是解决由于客户在开立 JKHLE 帐户时使用多种机制而带来的相关问题。他们希望从业务和 IT 这两个角度制定一种经过改进、单一的开立帐户机制。


  帐户开立项目的要求


  首席技术架构师 Sandy Osbourne-Archer 向她的团队简要介绍了此项目的目标。我们希望使我们的 IT 基础结构与业务目标更好地保持一致,从而扭转我们当前所处的不利局面。


  由于这一不利局面会影响客户满意度,因此我们首先选择修复帐户开立流程。然而,我们不希望构建一个新基础结构之后仅能解决这一个问题,我们还需要解决其他一些问题。我们必须解决帐户开立问题,同时还必须降低解决其他问题的成本。”


  认证数据库分析师兼企业架构师 Ursula DeBarry 从独特的数据管理角度看到了 JKHLE 在帐户开立流程方面的问题。她所拥有的经验让她能够轻松地识别碎片数据、数据不一致,以及多个不同的数据访问路径所造成的影响。丰富的经验还使她能够形象地阐述在数据中进行整合、清理和解决不一致现象,以及标准化和改进数据访问路径所带来的成效。


  Sandy 希望将信息服务引入到帐户开立项目中。


  Sandy 就此项目对 Ursula 提出了一些明确的要求,希望她能帮助满足这些要求。


  REQ-01:为决策者提供更完善的信息


  JKHLE 的主要决策者抱怨说,他们接收到的关于 JKHLE 客户的数据有许多质量都很差,通常不能返回决策者所需的信息。决策者需要更高质量的信息服务。


  REQ-02:允许服务使用者使用 SOA 访问数据


  帐户开立流程,以及 JKHLE 环境中的其他业务流程和门户都需要访问 DB2? 和 IMS? 中存储的数据。Sandy 希望使用信息服务将这些数据作为服务公开。


  REQ-03:允许使用者实时访问一组多样化的数据


  帐户开立流程需要访问存储在一组多样化数据源中的帐户信息。帐户开立流程需要实时访问各客户、业务合作伙伴和组织的此类帐户信息。并且必须在 5 秒内完成查询的处理。


  REQ-04:允许使用者访问大量的多样化数据,而不会影响其他数据库操作的响应时间


  帐户开立流程需要访问帐户历史记录信息。这些信息表现为驻留在一组多样化数据源中的大量数据。帐户历史记录信息不需要始终保持最新,但是必须在 5 秒内处理查询,并且不会影响其他数据库操作的响应时间。


  REQ-05:清理、标准化和验证客户数据


  JKHLE 有许多因不准确和不一致数据而带来的问题。需要实现的解决方案应支持帐户验证流程和持续数据完整性。


  REQ-06:为非结构化数据提供内容管理


  帐户开立流程要利用大量非结构化数据。这些非结构化数据需要进行存储和管理,并且需要与结构化数据进行连接。


  REQ-07:提供主数据管理的实现服务


  JKHLE 希望制定并执行严格的数据控制,从帐户开立流程使用的客户数据实体开始。


  REQ 08:提高信息服务在远程办公室中的性能和可用性


  JKHLE 的许多远程办公室都使用了信息服务。有时候,这些远程办公室会遇到信息服务响应时间过长的问题,而且在某些情况下,这些服务不可用。解决这一问题需要采取一些措施。


  将 SOA 实现模式应用于此案例研究


  Ursula 说明了将“将信息作为服务 SOA 场景”引入 JKHLE 的好处。她指出,信息服务可以将信息使用者和信息提供者分离开来。信息服务规定面向服务的接口可以利用各种信息管理模式和技术访问信息。将信息作为服务意味着服务的定义和使用具有以下一组重要特征:


  在检索信息时并且跨多个存储库潜在地更新信息时,提供的信息质量是已知的,信息的完整性也是有保证的。


  信息的来源是已知的。例如,服务使用者可以通过访问元数据来确定信息的来源。


  信息的异构是透明的。例如,服务使用者不需要知道数据源的多样性及这些数据源的不同信息格式。


  信息的流通性是已知的,并且可达到服务质量要求期望值。


  信息的结构和语义是已知的,通常在不同的体系结构层上表示。


  对服务和基础信息所做的更改是以整体、统一且一致的方式管理的。


  JKHLE 将使用“将信息作为服务 SOA 场景”中的以下实现模式:


  生命周期建模
  基本信息服务支持
  数据联合
  数据整合
  数据清理
  内容集成
  主数据管理
  管理生命周期
  生命周期建模


  Sandy 告诉 Ursula,JKHLE 的主要决策者一直在抱怨与 JKHLE 客户相关的服务质量太差。Sandy 概述了以下三个特定问题:


  getCustomer 服务不返回业务需要的数据。


  由于没有对客户的特定定义达成一致意见,因此并非所有合适的客户都包括在其中。


  getCustomer 服务也会返回质量很差的数据。决策者接收到的数据通常包括重复的条目或缺失的值。这在很大程度上意味着最终得到的客户数据来自多个系统。


  与客户相关的多项服务具有不同的消息传递格式,这给转换带来了挑战。


  Ursula 告诉 Sandy,她知道问题所在并且重点介绍了导致这一情况的主要 IT 问题:


  术语不明确


  业务与 IT 之间存在不一致的术语概念。例如,在 JKHLE 中,术语“客户”在不同的部门中被赋予不同的内涵。在一些领域中,客户是指订阅帐户持有者,而在另外一些领域中,术语“客户”用于描述订阅帐户持有者以及表示对开立帐户感兴趣的潜在帐户持有者。不同类型的客户没有明确的定义导致了这些不一致性。


  数据质量不明确


  为实现某一服务需要集成在一起的各种信息源之间存在许多数据不一致性。Ursula 指出了帐户数据示例。帐户数据中的地址元素是以多种不一致的格式表示的。


  模型不一致


  消息模型(描述服务的输入和输出)在多个服务中不一致。这是消息模型与概念数据模型之间一致性方面的基本缺陷。


  建议的解决方案


  Ursula 建议使用“生命周期建模”实现模式来解决这些问题(请参见图 1)。



  图 1 生命周期建模
 
  Ursula 告诉 Sandy,业务术语表能够帮助解决术语不明确的问题。业务术语表定义了与流程、服务和数据相关的术语。例如,它可以提供“客户”的一般定义。业务术语表建立了一个通用词汇表,用于控制术语的定义。每个术语的定义中都包括描述和其他元数据,并对其进行了分类。指派术语管理员管理这些术语。这些术语管理员帮助定义术语并负责管理这些术语。


  通过在服务分析和设计过程中执行数据质量评估(有时候称为数据概要分析),可以首先解决由数据质量不明确所带来的问题。在执行了评估之后,Ursula 可以开始研究数据源的数据质量问题。Ursula 可以验证是否存在数据重复,以及这一重复问题是否能在数据匹配和聚合过程中得以解决。在进行了这些类型的分析之后,Ursula 可以采取适当的措施来确保服务实现选择满足潜在服务使用者上下文中要求的数据准确性和含义级别。


  Ursula 建议使用规范的数据模型来解决帐户开立流程所使用的数据模型与消息模型之间的不一致性。规范的数据模型为各种系统(其用于保存与 SOA 项目相关的数据)中的关键实体、这些实体的属性和关系提供了一致的定义。规范的数据模型在数据层上建立了一种通用格式,而规范的消息模型在服务层上定义了这一统一的格式。


  Ursula 建议 JKHLE 使用以下 IBM? 产品:


  IBM WebSphere? Business Glossary 和 IBM WebSphere Metadata Server,用于实现业务术语表以及存储业务术语表定义的底层元数据数据库。


  IBM Rational? Data Architect,用于数据建模。


  IBM WebSphere Information Analyzer,用于执行数据质量分析。


  Ursula 还建议使用 IBM Industry Models 来帮助定义数据和流程模型,如 IBM Information Framework。


  基本信息服务支持


  Sandy 提出了如何通过 SOA 访问 JKHLE 环境中存储在 DB2 和 IMS 中的数据这一问题。Ursula 解释说信息服务可用于 SOA 解决方案中,用法类似于任何其他服务,并且能够从流程(如帐户开立流程)或门户应用程序中进行调用。


  Sandy 解释了她为何想要转而使用 SOA 方法。传统上,JKHLE 应用程序代码依赖于对数据存储方式和位置及这一数据访问逻辑的嵌入式详细信息的直接了解,例如,在访问应用程序时,需要知道如何利用 JDBC? 适配器进行 SQL 调用,使用什么数据源,采用何种业务规则(如果有)进一步清理数据,等等。此方法导致应用程序与数据源和数据模型直接耦合在一起。


  面向服务的信息访问提供了应用程序到数据源的松散耦合,从而可以获得 SOA 在实现业务灵活性方面的好处。


  建议的解决方案


  Ursula 一股脑地列出了多个为“将信息处理任务作为信息服务公开”选择项目的方法:


  第一种选择是使用一个战略性平台,该平台使用单一产品公开各种访问多种不同类型数据源的信息服务。此方法提供了一些增强功能,例如,元数据管理、监视、管理、安全映射、可伸缩性和负载平衡,以及集成的开发环境(请参见图 2)。



  图 2 基本信息服务支持
 
  Ursula 建议使用 IBM Information Server 系列产品,特别是 IBM WebSphere Information Services Director,通过对所有数据(无论是结构化数据、非结构化数据、应用程序数据还是大型机数据)执行标准的验证服务,提供关键业务信息在整个企业范围内的可见性。IBM Information Server 还包含其他可选择的产品组件,这些组件可用于其他信息服务模式,如联合、整合、清理和信息概要分析。


  第二种选择是从使用本机服务支持功能开始,无需额外的投资。本机功能往往最小,因此有一定的局限性。此外,由于存在多个堆栈,致使维护成本增加。


  Ursula 重点介绍了 DB2 和 IMS 都提供入门级的“将存储的过程和事务作为服务公开”功能。Ursula 指出,此方法确实是为现有数据提供服务支持的低成本方法,但是,此方法未必是最适合 JKHLE 的,因为 JKHLE 寻求的是一种可伸缩性更强、允许访问多种不同类型数据源的解决方案。


  第三种选择采用自行构建的服务从基本应用程序服务器开始。在深入分析此选择后,Ursula 认识到,此选择在开发和测试方面可能需要相当长的时间和精力,并且还缺乏标准的方法和控制。


  Sandy 及其团队现在确信,选择使用 IBM Information Server 对 JKHLE 来说是最可行的,因为此选择可以满足 JKHLE 在管理、集成管理和集成开发环境方面的要求,从而有助于快速启动开发。它还具有以下优点:


  作为企业信息体系结构的全面、统一的基础,可以进行扩展,以便满足任何数量和处理要求。


  通过元数据驱动的集成来集成和丰富信息,从而提供更高的工作效率和灵活性。


  可以最广泛和最深入地连接来自各种数据源(包含结构化、非结构化、大型机和应用程序数据)的信息。


  数据联合


  为了改进帐户开立流程,Sandy 指出要创建的服务可以完整而实时地查看与特定客户关联的所有帐户的状态。访问此信息的响应时间应符合小于 5 秒的标准,该标准是用于与客户服务关联的其他复杂查询的标准。


  Ursula 与数据管理团队讨论了获取完整和当前帐户状态的问题。她指出,JKHLE 帐户信息的最大问题之一是其分散在整个组织中。此外,对各个客户、业务合作伙伴和组织而言,JKHLE 存储帐户信息的方式也不相同。


  Sandy 不希望 JKHLE 帐户管理人员花费时间手动搜索、聚合、关联和更正帐户状态信息。


  不过,JKHLE 当前的许多应用程序和工具都要求数据位于其所在的位置。Sandy 在寻找既能用于帐户开立流程又能用于未来项目的解决方案。


  建议的解决方案


  Ursula 建议,数据联合模式非常符合这些要求。Ursula 解释说,在此情况下,通过将数据复制到一个位置来集成数据并不可行。保持数据最新的需求将导致大量的复制开销,特别是在更新频率取决于 JKHLE 订单量时更是如此。因此,最佳的解决方案是使用数据联合服务器(请参见图 3)。


  注意:数据联合服务器负责接收定向到各种源的集成视图的查询。它将该查询转换为针对适当源的子操作,从每个源中收集结果,然后进行组装并返回集成的结果。


  此处理顺序是同步实时执行的,有效地向查询发布者隐藏了实际操作的复杂性。



  图 3 数据联合服务器
 
  Ursula 解释了数据联合服务器如何满足 JKHLE 的需求:


  上市时间是 Ursula 考虑的首要开发优先级之一,数据联合可以提供对信息源的快速访问,而不需要更改冗长的信息管理基础结构。


  数据联合通过支持对位于数据源中的数据的访问,不需要复制和重复数据,因此可以满足 Ursula 的需求。


  Ursula 需要像从单一数据源那样对分布式信息(包括结构化数据和非结构化数据)进行实时访问。


  JKHLE 是一个动态变化的环境,要求使用灵活的和可扩展的信息集成方法,特别是模式发展。


  由于数据联合减少了数据冗余,因此在联合模式中的更改减少了更改对集成系统的影响。


  Ursula 的环境特征可以用适当的请求数来描述,该请求数是根据有限结果大小从多个类似的补充数据源接收的。在此类环境中,Ursula 可以充分利用数据联合的好处。


  Ursula 告诉 Sandy,IBM Information Server 产品系列可以满足建议的解决方案的所有需求。可以使用 IBM WebSphere Information Services Director 将信息管理功能作为服务公开。它将信息集成逻辑、清理规则和信息访问等打包为服务,将开发人员与该功能的基本提供者有效地隔离开来。
  其中与 JKHLE 环境最相关的是其通过面向服务的接口(如 EJB、JMS 或 Web 服务)公开联合访问的能力。该产品为信息服务提供了基础结构(包括负载平衡和故障转移)。


  Ursula 建议使用其他两个产品。IBM WebSphere Federation Server 充当分布式平台上数据联合服务器的角色。


  JKHLE 通过 SQL 接口可以访问来自所有现有数据源的联合信息。JKHLE 还需要访问有关大型机的一些信息,因此 Ursula 推荐了 IBM WebSphere Classic Federation Server for z/OS?。


  数据整合


  为改进帐户开立流程,Sandy 指定要创建的服务应提供 JKHLE 客户的统一帐户历史记录。访问此信息的响应时间应符合小于 5 秒的标准,该标准是用于与客户服务关联的其他复杂查询的标准。


  Ursula 描述了组合统一帐户历史记录的独特问题。


  她告诉 Sandy,由于存在许多帐户信息,因此,如果 JKHLE 尝试实时访问所有这些数据,将会影响许多其他数据库操作的响应时间。Ursula 补充说,还可能很难实时处理这些信息,并且难以满足 Sandy 的 5 秒钟的要求。


  Sandy 回答说不需要实时检索信息。数据刷新间隔为 24 小时就可以满足要求。


  建议的解决方案


  通过数据整合实现模式可以很好地满足解决方案检索帐户历史信息的需求。数据联合模式对多个数据源执行实时查询,而数据整合模式可以通过在非高峰时段将数据复制到一个位置来集成数据,因此数据量的大小不会影响其他数据库操作的性能。这一数据整合过程通过数据整合服务器完成(请参阅图 4)。



  图 4 数据整合服务器
 
  Ursula 解释了数据整合服务器如何满足 JKHLE 的需求:


  Ursula 必须集成来自具有高度异构性的各种源中的数据。对于此类环境,数据整合服务器具有强大的功能,可以消除数据之间的不一致性并将其合并在一起。


  Ursula 的数据使用者要求具有高数据可用性、高度并发访问、高可伸缩性和高性能的集成信息。数据整合服务器在新的目标副本中对集成信息具体化,她的使用者可以独立于转换和集成过程而访问该副本。


  Ursula 还可以将数据整合模式与数据清理模式合并在一起来解决整合过程中数据的质量问题。


  为实现此解决方案模式,Ursula 推荐了 IBM WebSphere DataStage?。这是一个用于进行数据清理、转换和重新定位的高容量数据集成平台。JKHLE 将使用 WebSphere DataStage 来充当数据整合服务器的角色。WebSphere DataStage 提供并行处理功能,如支持动态重新分区、并行数据库和网格配置,使得在较短的时间范围内能够处理大量的数据。源和目标支持所有 JKHLE 源,包括关系数据库管理系统、ERP 系统、大型机现有系统、XML 和专用数据格式。


  为了将这些信息管理功能作为服务公开,Ursula 建议使用 WebSphere Information Services Director。


  数据清理


  帐户管理人员需要有关于客户的一致而有效的数据。目前在 JKHLE,客户数据库有时会无效或者不同数据库之间出现不一致情况。因此,客户不能正确地收到通知,有时还会创建重复的客户记录。


  Ursula 通过 JKHLE CIO 最近转发的一封客户抱怨信提醒信息管理团队。


  “一位名叫 David Brown 的客户由于地址字段键入错误给我们的行政人员写了一封信。他从 JKHLE 收到了帐户通知,但比预期的接收时间晚了一周,而且发现信封上的地址写错了。他多次给客服打电话要求纠正此问题。客服曾两次告诉他,在系统中找不到他的信息。下次他打电话时,他被告知系统中有他的信息并且地址是正确的。后来他又收到一封延迟的信,并且地址仍然不正确。


  就在他向我们的行政人员写完这封信之后,我们就发现了这个问题。与我们的所有其他客户一样,他的数据存储在多个位置。他的地址在某些位置中是正确的。但在有些数据库中,他的地址被输错了”。


  建议的解决方案


  Ursula 告诉信息管理团队,JKHLE 可以使用数据清理模式来解决此类问题。


  当客户(例如 Curt Company Inc.)或者帐户经理(例如 Peggy Smith)提交新的帐户申请时,该申请将提交到帐户验证业务流程。此业务流程中的第一步是清理数据。使用针对美国的规则清理名称和地址,然后将更新的数据作为服务的输出返回。


  Ursula 解释说,使用数据清理服务器允许 JKHLE 使用针对地址和其他客户数据的预定义检查和规范为客户数据构建数据清理规则。可以将清理规则用于在数据传入时改正数据,或者改正当前许多数据库中存储的该数据。甚至可以在数据整合流程中应用这些规则,如 “数据整合”中所述。



  图 5 显示了数据清理服务器拓扑
 
  为实现此解决方案模式,Ursula 推荐了 IBM WebSphere QualityStage。此产品是提供数据清理服务器的 IBM Information Server 的核心组件。


  WebSphere QualityStage 支持自由格式文本数据的标准化、充实和匹配。它提供了以下功能:


  可通过应用成熟的解析规则和统计匹配功能来支持在数据源内或数据源间进行记录关联和重复项消除。


  通过自动交叉填充空白、缺失或不完整的实体值来支持跨多个源选择一个最佳记录。这提供了跨多个系统的单一而全面的数据视图。


  为了将这些信息管理功能作为服务公开,Ursula 建议使用 WebSphere Information Services Director。


  内容集成


  帐户开立流程需要访问大量的非结构化内容。非结构化内容是没有使用传统数据库标准(如 SQL)构建的数据。非结构化内容的示例包括手工填充的申请和支持文档。


  在 JKHLE 的许多业务流程中,使用的非结构化内容多于结构化内容。客户通过将重要的文档传真给帐户经理来提供重要信息是特别常见的事情。事情往往是将原始文档存储在档案柜中,而没有与帐户开立流程联系起来。


  Sandy 特别关注 JKHLE 中非结构化内容的管理。她告诉 Ursula,在一个实例中,客户必须在一周内将保密的财务信息向 JKHLE 传真三次。此事故以及许多类似事故会导致丧失客户满意度,让人担心保密财务信息会被漫不经心地丢弃。


  Ursula 发现在帐户开立流程中有两个地方使用了非结构化数据:


  获得新内容


  在需要时检索内容


  建议的解决方案


  Ursula 告诉 Sandy,内容集成实现模式可通过使用内容集成服务器来帮助管理 JKHLE 中的非结构化数据。此模式将指导 JKHLE 采用严格的内容管理策略。


  Ursula 解释了内容集成策略如何用于帐户开立流程:


  当客户申请一个新帐户时,将要求客户提供验证其薪水的文档。使用内容集成模式,这些文档(传真或支付存根的副本)将作为内容对象获取。


  这些对象与元数据一起存储在内容存储库中,其中元数据用于将这些对象与客户和新帐户申请连接在一起。将创建一个服务,使 JKHLE 客户帐户代表能够通过门户存储这些内容对象。


  在帐户开立的稍后步骤中,JKHLE 帐户主管通过另一服务操作来检索和检查支持文档。内容集成解决方案中的 SOA 接口允许此操作与门户桌面完美集成。



  图 6 内容集成服务器
 
  Ursula 大致查看了 JKHLE 环境中的数据库服务器,发现没有理想的位置存储其非结构化内容。使用现有的数据库将需要大量的重新调整工作,而且还需要重新设计一些模式。她确定,为非结构化内容添加新存储库比较简单而且风险也小,如 FileNet? Content Manager 或 IBM DB2 Content Manager。


  如果在 JKHLE 环境中已经存在一些内容存储库,Ursula 可能需要考虑为其内容应用内容联合模式,如 WebSphere Information Integrator Content Edition 或 FileNet P8 Content Federation Services 提供的内容联合模式。


  在经过一番考虑之后,Ursula 计划使用 FileNet Content Manager 管理内容,原因是 JKHLE 计划将来使用其他 FileNet P8 产品来支持业务流程管理和记录管理。


  主数据管理


  作为一个长期目标,Ursula 希望使用一个强健的数据管理系统来统一管理 JKHLE 中与客户相关的许多后端数据源。


  此系统可以提高客户数据的一致性和质量,使客户在将来更容易地维护和更灵活地使用数据。


  目前,关于核心业务实体的可信信息(如 JKHLE 客户数据)分散在后端系统,并且通常不完整也不准确。


  建议的解决方案


  Ursula 解释说主数据管理实现模式可以帮助实现此目的。


  主数据是特定的描述核心业务实体(如客户、产品和提供商)的高价值数据,这些数据在多个业务流程中被重复使用。可以将主数据管理视为数据整合和数据清理实现模式以及扩展规则、事件控制和用于企业主数据的工具的混合体。


  使用主数据管理系统可以为与客户相关的数据建立和执行标准数据模型。这允许 JKHLE 永久删除同一数据过去使用的不同模型并仅对不同之处进行部分解析。



  图 7 显示了主数据管理参考体系结构。


  主数据管理可以确保关键业务数据始终完整和准确。主数据管理还便于管理跨异构系统的关键数据。主数据管理可以:


  为访问和管理关键业务数据提供一组集中化服务。


  在与其他源同步数据时充当权威记录。


  管理业务数据的复杂层次结构。


  提供管理主数据所需的全面功能。


  主数据管理比管理单个主数据实体要宽泛得多。管理主数据实体(如不同类型的客户以及将某个客户一般化为参与方)的层次结构非常重要。它还管理主数据实体之间的关系,如组织本身和外部组织(例如提供商和业务合作伙伴)之间的关系。深入分析可以确定新的参与方的身份与系统已知的参与方相同的可能性。


  对于帐户开立流程,主数据管理提供客户信息记录系统的存储库,其中包括关系、成员关系和联系。具体的任务包括:


  1. 查看客户信息以验证该客户对于 JKHLE 是否是已知的。


  2. 进行深入分析,以根据 JKHLE 客户列表中潜在不需要的候选者检查客户信息。


  3. 根据需要,使用调用内部或外部服务的管理规则标准化和清理客户提供的更新地址信息。


  4. 扩充主数据管理模型以合并 JKHLE 客户的其他外部信用记录。添加新服务以调用第三方服务提供者并收集信用信息。


  5. 使用前一步骤中的已标准化和清理的地址更新主客户信息。


  Ursula 建议使用 IBM WebSphere Customer Center 实现此解决方案。JKHLE 可以使用 WebSphere Customer Center 建立对参与方数据实体的控制,其中包括 JKHLE 客户数据以及与 JKHLE 客户相关的数据,如合同、帐户和相关参与方。Ursula 将使用 IBM Entity Analytics Solutions 来执行实体分析。


  管理生命周期


  在组装和部署每个“将信息作为服务”SOA 实现模式后,Ursula 发现了一个问题。事实证明信息服务很受欢迎,并在 JKHLE 组织中被广泛使用,特别适用于远程办公室。但是,远程办公室遇到了一些问题。信息服务的响应通常非常缓慢,并且有时甚至不可用。


  Ursula 认识到,整个团队将所有精力都集中在了组装和部署信息服务上,而忽视了一个重要步骤。就是没有很好地管理信息服务。没有良好的管理,JKHLE 将无法快速确定服务执行情况,也不知道何时会出现问题。


  建议的解决方案


  Ursula 为 JKHLE 环境中的信息服务和其他 SOA 服务推荐了一个全面管理解决方案。她推荐的解决方案可以提供 IT 环境的历史视图,并能够通过 IT 堆栈跟踪服务请求。此解决方案将提供业务监视仪表板和系统管理控制台,以管理帐户开立业务流程和此业务流程使用的信息服务。


  此解决方案可以带来以下好处:


  快速隔离问题区域。


  积极主动(而不是被动响应)地确定、隔离和解决问题。


  了解服务对特定资源的依赖关系。


  维护和跟踪水平级别协议。


  监视业务流程,了解业务执行的方式。


  此解决方案将会大量增加收入和提高客户满意度,这是因为 JKHLE 可以在业务受到影响之前解决潜在的问题。


  Ursula 列出了最适合对每个实现模式实现管理的 IBM 产品:


  基本信息服务支持


  对于 DB2 数据库:IBM Tivoli? Monitoring for Databases 和 OMEGAMON? XE for DB2 on z/OS


  对于 IMS 数据库:OMEGAMON XE for IMS on z/OS


  数据联合


  IBM Tivoli Monitoring for Databases


  数据整合


  IBM WebSphere DataStage 的 Director 工具中提供的本机监视功能


  数据清理


  IBM WebSphere QualityStage 的 Director 工具中提供的本机监视功能


  主数据管理


  IBM Tivoli Composite Manager for WebSphere Application Server 和 IBM Tivoli Composite Manager for Response Time Tracking
IBM Entity Analytics Solutions


  总结


  通过使用“将信息作为服务”实现模式,Ursula 能够满足既定的需求。可以通过服务接口访问帐户开立流程(和 JKHLE 体系结构中的其他 SOA 组件)所使用的数据。另外,还可以根据需要联合、整合和清理此数据。Ursula 还能够为非结构化数据提供管理解决方案,并为主数据管理建议了解决方案。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 谁知道阿里云河南服务中心是干什么的?

    一直接到阿里云服务中心的电话,说是阿里云的授权中心,主要提供阿里云的区域服务的?请问其他地方也有阿里云的服务中 […]

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • 揭秘New Relic APM技术细节

    New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响

  • 仅凭SOA和云无法解决业务数据管理风险问题

    SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。