内容


IBM WebSphere 开发者技术期刊

WebSphere Integration Reference Architecture 简介

基于服务的企业级业务集成基础

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

此内容是该系列的一部分:IBM WebSphere 开发者技术期刊

敬请期待该系列的后续内容。

摘自 IBM WebSphere 开发者技术期刊

引言

面向服务框架的出现是最近 20 年软件开发和实现演变的结果。我们的行业是从单个独立的应用程序和难于管理的客户机-服务器解决方案发展起来的,现在发现通过面向服务的体系结构 (SOA) 支持的增量组件开发,可以提高应用程序的质量,加快新解决方案的开发速度,因而能够更好地满足业务参与者的需求。

SOA 中包含的概念允许企业跨业务线和支持信息系统集成其业务流程。为了便于跨信息、应用程序和人员建模和管理服务,必须具有能够协调企业级集成难题的体系结构。通过基于组件的方法,组织可以构建更灵活的集成解决方案,充分利用通用核心基础设施服务集。此解决方案框架通过更简单的松耦合方法为 IT 解决方案提供增强的灵活性和适应性。基于 SOA 的集成基础由于支持基于标准的设计、开发和实现,从而为技术共存提供了支持。此方法通过提供跨现有和未来技术资产的可扩展基础设施,为企业集成体系结构提供了坚实的基础。

尽管很多集成产品声称支持这一体系结构方法,但多数产品不具备满足企业集成需求的能力。本文重点介绍支持多种集成样式所需的各种功能,这些样式都是使用企业级方法进行集成所必需的;并且讨论如何将基于开放源代码开发和运行时标准构建的面向服务的综合体系结构作为集成的关键组件。通过此体系结构基础,当集成需求出现时,企业可以扩展其解决方案,方法是组合现有组件与新组件,以及实现组合应用程序。

企业集成策略

企业集成策略至少需要消息交换能力作为解决方案体系结构的基础,这样才能支持人员、应用程序/流程和信息的集成。通过这一方法,集成解决方案可以在部门级实现,并且可以方便地跨企业边界扩展。此集成方法可以为企业提供灵活性和将产品推向市场的时间优势,将成为在当今复杂且竞争激烈的商业环境中能否取得成功的关键因素。

目前,企业集成策略正在发生转变。尽管还在继续部署旨在满足部门级需求的战术计划,但是组织正在基于 SOA 方法定义企业集成体系结构计划。此方法要求组织识别核心集成资产/组件,并提倡鼓励重用和细化这些用于集成项目的资产的方法。通过这种方式,跨部门的集成可以按照企业级计划进行处理,从而促进了通过基于标准的方法进行的定义、发现和调用的重用。

企业方法的集成与业务部门/业务线集成解决方案开发的战术方法相兼容。实际上,战术解决方案已经成了整个集成存储库的资产。需要提供一种管理模型来确保战术解决方案的开发是在企业集成体系结构的环境和规则中完成的,这一点至关重要。如果没有合适的管理模型,企业将继续在隔离状态下构建部门集成解决方案,并且无法看出集成的长期好处。在业务和技术改变速度一定的情况下,缺乏对集成方法的管理还将影响有效而主动地支持跨企业集成目标的能力。

面向服务的集成体系结构

由于还需要提供规定的集成方法,因此企业集成体系结构必须借助于面向服务的体系结构的力量。面向服务的体系结构允许通过使用开放和可用标准将新的以及现有的功能打包为可重用服务组件,从而创建模块化组合应用程序。面向服务的体系结构可以提供“组合在一起(通过组合和编排的方式)实现业务目标的联合业务服务集...服务作为一组接口出现,不依赖任何实现机制和位置。”(Endrie,2003 年)松耦合的组件体系结构非常强大,因为在这种体系结构中,可以通过以标准形式跨分布式拓扑公开接口,来将组件作为服务使用者和(或)提供者。组合应用程序可以通过功能隔离改进 IT 系统的灵活性,提高在多种环境中重用组件的能力,同时提供较简单的集成模型和构造集成的过程中的灵活性。

采用面向服务的集成方法的应用程序带来了很多好处:

  • 利用开放标准将集成资产用作服务,促进现有资产的重用并帮助避免受制于供应商。
  • 提供用于表示集成组件(如映射、进程、离散事务/服务或接口)和与之交互的标准方式,从而提供跨多个业务流程解决方案重用资产的灵活性。
  • 将集成重点转移到应用程序集(而非实现细节),从而能够高效实现新的和经过修改的业务解决方案。

面向服务的体系结构提供应用程序和组织资源之间的连接性,方法是将这些资产表示为可以包含在更高级别的订购服务组件中的服务。从技术的角度来看,面向服务的集成框架允许资源通过标准的互换框架来交换信息(消息、文档和业务对象)。通过将新的和现有的应用程序表达为服务,可以将服务组合在一起来满足集成需求。

使用 SOA 方法,体系结构样式可以包括通过熟悉的发布-发现-绑定服务框架枚举的服务提供者、请求者和服务描述。SOA 方法允许并提倡使用包括封装、服务组合、松耦合和重用在内的设计原则和模式。

面向服务的框架需要渗透到集成解决方案的各个方面。某些流行的中间件方法支持通过 SOAP 包装程序定义或调用集成组件的功能,但是集成架构师应该明白,SOA 方法所能提供的远不止基于 SOAP 的集成。该解决方案需要支持自从在标准组织(如 OASIS 和 OAG)中出现就不断发展的接口定义(用户定义的和基于行业的)。体系结构中的基础集成资产必须遵循基于 SOA 的方法:

  • 通过标准接口的服务描述和定义;例如,WSDL。
  • 基于标准的传输/中介层上的服务调用/交互。
  • 用于编排服务交互的服务编排;例如,BPEL4WS。
  • 通过集成注册中心/目录服务的服务发现;例如,UDDI。

组合应用程序允许使用流逻辑创建粗粒度的服务,从而确定服务执行的顺序。这些组合应用程序成为业务域中业务流程的 IT 模拟。SOA 设计利用中间件和操作环境功能将在单个服务中实现的流逻辑从基础业务逻辑中分离出来。服务可以从现有组件(例如,大型机 CICS 应用程序)中启用,也可以是全新的功能。

面向服务的集成方法中关键问题在于定义和实现适当的抽象级别的服务。是否能够在开发企业集成方法中应用合理的体系结构设计,直接依赖于关注点分离 (separation of concerns) 的概念以及模型驱动的设计和体系结构中的合并概念。

关注点分离简化了集成体系结构的实现

信息技术的开发和实现包括多个方面,这些方面需要在企业级集成策略中进行协调。在定义和管理业务应用程序与基础操作环境之间的边界时,IT 所扮演的角色成了实现业务解决方案的关键因素。操作环境为业务应用程序提供基础设施服务,并代表通用服务支持集成解决方案。

定义企业的集成体系结构时,全面考虑集成需求至关重要。这些集成需求可能包括基于人工任务交互的传统工作流处理、不同系统之间的活动编排、结构化和非结构化信息的分布式数据管理,以及用户交互能力。企业必须能够区分和设计适合解决特定集成问题所需的集成样式的服务构件。因此,关注点分离的概念是定义集成服务的基础。

关注点分离建议将业务需求分解为多个服务;合并表示业务流程的现有服务以及新的服务的组合。通过关注点分离,可以将集成需求分解为更细粒度的服务。可以通过识别为支持业务需求而定义的特定功能来实现这种分解,如图 1 所示。

图 1. 关注点分离
图 1. 关注点分离
图 1. 关注点分离

使用定义服务的关注点分离方法,可以设计隔离和特征化独立实现的功能和服务。通过这种方法,构建集成解决方案将变成一个迭代过程,组件通过多个连续的集成项目得到细化。企业向开发团队提供设计管理和集成指导以促进最佳实践和服务及组件的重用。

在基于 SOA 的解决方案框架中,服务组件是隔离定义的。除了支持自顶向下的模型驱动方法之外,此解决方案方法还允许采用自底向上方法来开发新的服务。最后得到的组合应用程序由带有管理单个服务执行顺序的流逻辑的服务调用组成。组合应用程序可以作为一种服务用于其他服务,也可以用来进行其他组合应用程序的开发。

目前流行的构建基于组件的体系结构的方法是通过模型驱动的体系结构 (MDA) 进行的,而 MDA 方法提供了 SOA 开发的基础。在 An MDA Manifesto (MDA 期刊,2004 年 5 月)中,Grady Booch 指出,MDA 是“一种基于使用自动化工具的企业应用程序开发和集成样式,目的在于构建与系统无关的模型并将其转换为高效实现”。MDA 方法通过基于工具生成的构件来提高 IT 开发过程的效率,同时允许业务参与者参与业务流程的开发。可以将 MDA 与面向服务的建模和体系结构 (SOMA) 和面向服务的应用程序开发 (SODA) 结合使用,以便更快地进行面向服务的应用程序开发。

Guide to Enterprise IT Architecture (C Perks/T Beveridge) 中,Perks 说“IT 的技术功能需要改头换面,因为现有功能非当前团队所构建。有时此方法可能很有道理,但在多数情形下,它只能让项目组感到莫明其妙。应用程序开发只与业务功能有关,而与构建技术基础设施无关”。这种意见强调需要将开发集成的企业管理方法与构建企业级集成策略的关注点分离应用程序的观点结合起来。

WebSphere Integration Reference Architecture

业务集成得益于强制关注点分离集成数据和应用程序以满足业务要求。它不只是具有流程解决方案或应用程序服务器基础——它是使用通用组件和服务的多种集成样式的聚合,可以提供长久的支撑力,保护现有 IT 资产中的投资,并避免公开“拼凑”的集成方法。有效的业务集成还要求操作环境支持面向服务的解决方案的实现,可以采用模块化、随意构建的方式实现,并且支持企业级实现所需的全部功能。

WebSphere Integration Reference Architecture 提供了一整套服务来支持业务集成。这些服务可以提供满足集成需求所需的各种功能。更重要的是,这些组件服务是分阶段实现的,允许在企业集成解决方案体系结构中工作的同时以项目为基础进行增量发展。尽管特定项目可能并非都需要这些服务,但是企业级集成必须具备将这些功能添加到集成体系结构中的能力。最后得到的体系结构通过启用业务逻辑、控制逻辑、松耦合的路由和转换逻辑来支持关注点分离,因而具有更多的更改灵活性。在组织级别,此方法有利于更简单的集成解决方案的开发,并可增强解决方案的可维护性和可操作性。

WebSphere Integration Reference Architecture(图 2)展示了综合性、企业级解决方案所需的主要集成功能。这些服务分组可以将关注点分离应用于企业集成需求,并在其应用于集成时促成与面向服务体系结构的原则的聚合。

图 2. WebSphere Integration Reference Architecture
图 2. WebSphere Integration Reference Architecture
图 2. WebSphere Integration Reference Architecture

此高级体系结构描述启用综合方法进行集成所需的集成功能/服务。由于这些服务是通过接口而非实现描述的,因此特定解决方案可能由大型机应用程序、本地或远程服务、由 BPEL(业务流程描述标准)描述的安排过程或使用 J2EE 构建的组件构成。此外,这些集成组件的实现还可以提供对可靠性、安全性、可用性等非功能性需求以及操作环境级和组件/服务级管理的支持。

连接性服务

处于 WebSphere Integration Reference Architecture 的核心位置的是连接性服务。此组件提供支持和实例化企业服务总线(Enterprise Service Bus,ESB)体系结构模式的基础设施。ESB 交付跨分布式组件拓扑的互连接性服务。传输服务、事件服务和中介服务都是通过 ESB 提供的。传输服务提供基本连接层;事件服务使系统能够响应作为业务流程一部分发生的特定事件;中介服务启用系统中交互服务之间的松耦合。ESB 实际上已成为跨企业不同操作环境提供消息传递、通知和调用服务的扩展的企业主干系统。无论现在还是将来,ESB 都将是利用面向服务的 WebSphere Integration Reference Architecture 实现面向服务解决方案的关键因素。

ESB 提供多种连接技术方案来支持多个消息传递拓扑和模式,以及 SOAP/HTTP、RMI/IIOP 等实现。在大多数情况下,为了便于管理服务之间的交互,松耦合连接是必需的。但是,有些事务由于其特性和关键业务功能所限,可能需要紧耦合连接。这两种模式在 WebSphere ESB 体系结构中均受到支持。对异构技术的支持需求表现为在以下方面对多个协议的支持:消息流实例、中间件互操作性、不同服务质量规范(如持久性、可靠性、事务管理、可用性)、支持各种消息分发和路由(包括发布-订阅、基于队列和基于广播)。此外,连接性服务和 ESB 体系结构还支持专门的消息/信息交付,如销售点、SCADA 及其他普及设备解决方案。使用当前具有 WebSphere MQ 的解决方案的客户不但现在可以实现 ESB 样式,而且当新协议出现时,也将能够提供支持。

在 ESB 中,存在三个主要服务方面,分别作为连接性框架的一部分提供:

  • 事件服务提供允许组件(及组织资源)响应刺激的事件驱动服务;例如,业务事件。
  • 事务服务提供跨有线和无线网络进行同步和异步消息传递的通信服务,同时具有可提供位置和协议独立性的不同级别的传递保证。
  • 中介服务允许动态处理消息传输、动态路由和服务绑定解析服务。

离开基本的连接性、路由和传输等功能,SOA 集成方法是不可能存在的。这些功能需要通过 WebSphere Integration Reference Architecture 中的 ESB 启用,形成解决方案体系结构的基础。在多数情况下,ESB 可以通过传统的和新出现的中间件解决方案实现,提供对集成组件的访问。

业务逻辑服务

业务逻辑服务提供以服务端点的形式执行业务逻辑所需的能力。服务端点的实现是综合性集成体系结构的一个关键部分。服务可以通过任何现有应用程序的组合来提供;可以通过新实现的组件,也可以通过到第三方系统的外部连接:

  • 合作伙伴服务允许对商业合作伙伴通过不同传输和使用文档形式提供的服务端点进行集成。这一层的服务可以对具有外部合作伙伴和提供商的传统 B2B 合作伙伴集成解决方案提供支持。它是隔离了跨企业交互的体系结构的组件。这些服务提供高效实现 B2B 处理和交互所需的文档、协议和合作伙伴管理服务:
    • 社区服务允许对交易中心的交易社区进行管理,并且允许合作伙伴进行自我管理。
    • 文档服务支持诸如 RosettaNet、EDI、AS1/AS2 之类的业务协议,以及支持会话过程的相关状态管理。
    • 协议服务提供传输级服务,包括身份验证、文档路由和用于自动化文档互换的边缘服务功能。
  • 业务应用程序服务为集成组件提供 J2EE 运行时环境,这些组件使用 Java 编码作为自定义应用程序组件开发并在应用服务器环境中运行。这一层的服务可以为使用 J2EE、XML 和 Web 服务编程模型开发的自定义应用程序组件的管理提供框架和运行时操作环境。这些组件提供实现能满足当今业务环境需求的全新业务流程所需的新功能。这些组件在 WebSphere Integration Reference Architecture 中作为服务实现,允许通过新解决方案直接重用。业务应用程序服务包括传统编程人员重点用于构建灵活的可维护、可重用业务逻辑组件和运行时集成的功能,允许进行更高级别的自动管理。此层中包含的服务功能有:
    • 组件服务提供运行时容器管理服务,可以自动处理 J2EE 框架中的对象持久性、关系导航、对象查询和事务管理之类的问题。
    • 核心服务作为 J2EE、XML、消息传递和 Web 服务编程模型的一部分提供运行时服务,如内存管理、对象实例化和池管理、性能管理和负载平衡、事件通知、可用性、目录,以及安全性。
    • 接口服务提供与数据库、消息传递系统、管理框架和企业应用程序进行双向集成的服务。
  • 应用程序和信息访问提供与第三方应用程序(如 ERP 和 CRM)、大型机接口(如 CICS 和 iSeries)、自定义应用程序(通过消息传递、应用程序编程接口、数据处理程序之类的技术桥)和异构数据源(像 RDBMS、XML、非 RDBMS 数据源;例如,IMS、文本文件和内容管理系统)进行交互的能力。此功能层提供到现有应用程序和数据的访问接口,同时支持数据库、消息传递系统及其他数据源的事务服务和连接服务。现有的基于主机的应用程序和企业数据都可以通过一组访问服务从 ESB 访问。这些访问服务提供遗留应用程序、预打包应用程序、企业数据存储(包括关系、分层结构和非传统、非结构化源,如 XML、文本和内容管理系统)和 ESB 之间的桥接功能。该层通过多个运行时解决方案模式(如面向 Web、通信级集成、消息传递和启用 Web service)提供大型机系统的集成。随着应用程序和数据实现演变为业务流程中更加灵活的参与者,其基础操作环境的增强功能将进一步得到开发利用。以下是在这一层中隔离和启用的服务:
    • 事件检测服务基于通过特定应用程序/数据源接口启用的事件框架提供事件通知服务。例如,在 CRM 系统创建新客户将生成一个事件,ESB 将该事件分发给这种事件类型的订户。
    • On-ramp 服务允许应用程序集成模式(包括单向入站、请求-应答、恳求-应答消息模式)支持应用程序和数据包装程序功能(包括查询执行计划和数据检索),从而支持数据集成。例如,如果业务流程中的一个步骤需要更新订单,一个带有订单数据的消息将通过 ESB 发送到大型机 CICS 应用程序,然后再从其返回一个确认。

控制服务

控制服务提供在 WebSphere Integration Reference Architecture 中有效集成人员、流程和信息的能力。这些服务控制人员、流程和信息服务中的交互和数据流,使其适合业务流程的开发的运行时实现:

  • 交互服务提供向最终用户交付功能和数据所需的能力,能够满足最终用户的特定使用偏好。交互服务还提供将各种普及设备(例如,传感器和传动器)集成到集成系统的其他组件中所需的能力。这一层的服务为使用(包括浏览器和语音交互)和普及设备集成提供外部交互服务。以下是作为交互服务的部分提供的服务:
    • 交付服务为用户启用运行时交互框架,以便通过 portlet、语音和普及消息传递与交互组件交互;该能力集合包括多设备支持、页面聚合、标记译码和国际化等专门技术,以及为支持移动/远程用户/设备集成与无线通信技术的集成。
    • 体验服务提供以用户为中心的服务,负责交付健壮的用户体验,如个性化、协作、身份验证、授权、自我服务功能(自定义和注册),以及单点登录。
    • 资源服务提供交互组件支持的运行时管理,例如,通过组件(如页面、主题/外观、原则和 portlet)实现的安全性和权利。
  • 流程服务提供管理实现业务流程的服务流和交互所需的控制服务。这一层的服务提供通过聚合集成组件支持粗粒度业务功能从而执行代理过程的能力。在 WebSphere Integration Reference Architecture 中,BPEL4WS 标准用于描述服务的编排。以下是流程服务中提供的服务:
    • 安排服务由其他服务组成,因此安排服务提供以定义的顺序执行其他服务和从错误中恢复的能力。
    • 事务服务为短期运行和长期运行过程提供错误恢复。整个过程可能都是事务性的(短期运行)。在长期运行过程中,通常每个服务都被视为一个事务(如果改变数据)。
    • 人员服务允许将人员集成到流程中。提供基于人员目录中的规则和信息创建工作项。它支持任务分配、委派、管理和交互服务。
  • 信息服务提供联合、复制、查询、分析和转换数据源的能力,这些数据源可能是结构化的(RDBMS 或其他数据源,如 IDMS 或 VSAM),也可能是非结构化的(如电子表格、文本文件、文档格式,如 Adobe PDF)。这一层的服务提供异构数据源的数据集成和聚合,因此允许对使用高级技术进行分布式优化的多个数据上下文进行透明访问。以下是信息服务层的部分服务:
    • 联合服务能够从传统(如 RDBMS)和非传统源(如 XML 数据存储、文本数据和内容存储)聚合数据,同时让其本地存储继续控制这些数据。
    • 复制服务为自动化实时数据同步和结构化数据源的源/目标转换提供支持,允许对数据进行局部性访问,不管源如何实现。
    • 转换服务将数据从源格式转换为批处理和面向记录的访问/转换的目标格式。
    • 搜索服务允许通过约定(数据库和结构化数据源)和非约定(如 PDF、电子表格、字处理文档)数据源进行完整查询和搜索集成。

开发服务

WebSphere Integration Reference Architecture 深刻地认识到需要将综合软件开发平台作为核心竞争力。开发平台包括软件开发的整个生命周期(如需求分析、建模和设计、组件开发、测试,以及代码维护)至关重要。工具必须与 MDA(模型驱动体系结构)的概念相兼容,支持通过 SOMA(面向服务的建模和体系结构)和 SODA(面向服务的应用程序开发)方法演变而形成的最佳实践的使用。这些特征在 IBM 软件开发平台中都可以实现。

在高级级别,WebSphere Integration Reference Architecture 中的开发服务允许人员根据其技能、专业知识和他们在企业中担当的角色来完成特定任务,并创造一定的效益:

  • 业务分析师负责分析业务流程需求,他们需要完成业务流程的设计和模拟的建模工具。
  • 软件架构师需要建模数据、功能流和系统交互的工具,以及开发系统拓扑的工具。
  • 集成专家需要在集成解决方案的开发中配置和编排组件的能力。
  • 编程人员需要开发新业务逻辑(如 J2EE 组件、portlet 及其他自定义服务组件)的工具。

最重要的是,集成工具环境通过资产访问和资产共享推动连接开发、资产管理,以及开发角色之间的深度协作。这里的重点是,组织的工具技术和能力将来自于多个供应商,结果,多供应商框架(如 Eclipse)的出现无疑会使开发过程中各个角色的学习曲线得到简化。此外,标准的工具框架(如 Eclipse)提供通用存储库和跨开发人员各个方面(例如,版本控制功能,如 CVS 和 ClearCase;实用功能,如编辑、文件和打印服务)的基础功能。通过 WebSphere Integration Reference Architecture 提供的开发服务可以充分利用 Eclipse 基础来实现其功能。

不管对于哪一个特定的开发角色而言,在软件开发中最大限度协作都是必需的,只有这样才能让每一个角色多产而高效。开发工具平台通过基于角色的活动和跨多供应商工具环境提供集成的工具集,从而解决了集成开发的作用域问题。通过在开发过程中应用关注点分离,每个角色都可以设计、开发和部署特定于单个技巧和响应性的构件。许多服务功能已作为开发框架的部分公开:

  • 建模服务提供让分析师构建代表业务流程的可视模型的能力。
  • 设计服务允许将模型分级进行设计,包括使用服务组件为流程确定属性的能力。此外,此功能组还允许设计和开发新的集成组件。
  • 实现服务允许将已开发的构件作为组织的配置管理标准的一部分移动到生产中。
  • 测试服务提供支持单元测试的能力和作为总体开发生命周期的一部分的集成测试功能。

业务创新和优化服务

综上所述,业务创新和优化服务提供持续改善和创新的基础设施,允许业务适应变幻不定的市场动态和每天可能出现的运作中断。设计良好的 BPM 解决方案支持对业务管理进行整体分析,启用调整的目标、基于角色的可见性、上下文识别和及时操作。请注意,BPM 需要一组不同的功能来支持和结合业务和 IT 专业人员的需求,这一点至关重要。

通用基础事件 (CBE) 规范为 WebSphere Integration Reference Architecture 提供通用基础事件模型。CBE 最初是 IBM Autonomic 团队为了与合作伙伴协作而编写的,是一个新兴的 OASIS 标准,它定义了通用的基于 XML schema 的事件表示,支持日志记录、跟踪、管理和业务事件的编码。

在 WebSphere Integration Reference Architecture 中,BPM 服务由三个主要的组组成,其中每个组对 IT 和业务事件都提供支持:

  • 通用事件基础设施(Common event infrastructure,CEI)服务提供发出服务,可以过滤本地事件并将其转换为 CBE 形式的事件存储服务(用于存储、查询和管理事件)和事件目录服务(用于存储、查询和管理事件架构)。
  • 相关服务提供策略驱动的过滤和用于检测相关情形的事件关联。
  • 监视服务使用观察模型定义适当的监视上下文,将事件映射到上下文,以及计算和管理相关性能测量和关键性能指标 (KPI)。

规格和 KPI 的表示可以使用交互服务完成。同样地,支持 BPM 解决方案所需的分析和数据交互则通过信息服务提供。

开发平台和业务创新及优化服务之间的联接是 WebSphere Integration Reference Architecture 中的一个关键方面。通过将重要性能指标特征化为建模环境的一部分和作为流程模型的一部分生成特定事件标志,分析师可以在其业务流程中构建管理功能。在实现集成组件后,BPM 层将提供事件数据和统计数据(这些数据还可以被输入到建模环境中)的捕获和交付。此方法允许组织支持通过连续的业务流程改进周期重新设计迭代过程。

IT 服务管理

位于 WebSphere Integration Reference Architecture 的所有功能之下的是安全性、目录、系统管理和资源虚拟化的管理服务。安全性和目录服务包括实现所需的身份验证和授权功能;例如,跨分布式和异构系统的单点登录功能。系统管理和虚拟化服务包括跨服务器、存储、网络及其他资源的管理的操作环境;例如,群集和虚拟化服务允许基于加载模式和其他因素高效使用计算资源。对于 IT 服务管理而言,将网格用作计算平台的一部分的功能是不可或缺的。很多管理服务直接绑定到硬件或系统实现执行功能,而其他一些服务则提供通过 ESB 与体系结构中其他元素提供的集成服务直接交互的功能。这些交互一般涉及与安全性、目录和 IT 操作系统管理相关的服务,作为支持操作环境的一部分。

硬件和软件管理服务提供高效运行和操作企业系统所需的能力。这些服务中的大部分都独立于其他集成服务;而另外一些则为其他集成服务提供功能和数据,以支持高效业务性能管理和系统操作。

正在使用的 WebSphere Integration Reference Architecture

在图 3 中,采购订单处理是一个端到端的组合集成过程。该解决方案表示通过 WebSphere Integration Reference Architecture 中的组件编排的服务顺序。

图 3. WebSphere Integration Reference Architecture 中的服务调用
图 3.  WebSphere Integration Reference Architecture 中的服务调用
图 3. WebSphere Integration Reference Architecture 中的服务调用

开发工具和 IT 服务管理没有显示。开发工具和管理服务分别提供对集成组件开发和对基础操作的运行时框架开发的支持。通过业务集成的基于 SOA 的方法,可以独立开发单个集成构件,然后编排起来提供一个总体解决方案。这是与传统集成解决方案的关键不同点,传统集成解决方案都是紧密绑定的应用程序。更重要的是,任何已开发的组件(如适配器服务或合作伙伴配置文件服务)都可以重用,不会对采购订单的操作过程造成影响。WebSphere Integration Reference Architecture 可以让组织在应用集成技术应对随需应变计算的挑战时更具策略性。

Patterns: Service-oriented Architecture and Web Services (M. Endrei and others, 2004)中所述,“随需应变的操作环境提供允许使用通用标准和开放技术集成应用程序所需的基础设施。”这是通过 WebSphere Integration Reference Architecture 支持的集成框架的重要原则。遵守通用标准和开放技术是 IBM 集成方法的基础。下表给出了在 WebSphere Reference Architecture 中出现的一些主要标准和技术:

表 1. WebSphere Integration Reference Architecture 标准和技术
服务功能相关标准
企业服务总线JMS、J2EE、SOAP、XSLT、WSDL、UDDI
开发工具Eclipse、J2EE、J2SE、J2ME、XML、UML、Java Server Faces、SWT、XMI、WS BPEL、SQLJ、JDBC、XSLT、WSDL、UDDI
业务性能管理工具W3 Common Log Format、WS DM 计划、CEI/CBE
交互服务WSRP、JSR 168、Java Server Faces、VoiceXML、J2EE
流程服务J2EE、BPEL4WS、WSDL、UDDI
信息服务XQuery、SQL、JDBC/ODBC
合作伙伴服务FTP、sFTP、HTTP、HTTP/S、RosettaNet、SMTP、JMS、SOAP/HTTP、WMQ、cXML、EDI(X12、EDIFACT 及其他)
业务应用程序服务J2EE(JNDI、EJB、JSP、JTA、JAAS、JAXP、JAXR、JMX 及其他)
应用程序和信息资产J2C、JMS、IIOP、JDBC、CICS、IMS、3270/5250

此外,在解决方案框架中还应用了多种行业标准,如 ACORD、SWIFT、HIPAA、UCCNET 及其他主要纵向框架和计划。遵循标准表示 IBM 的集成方法在构建灵活和持久的企业集成体系结构中堪当关键引擎。

IBM 的 WebSphere Integration Reference Architecture 提供业界大多数综合性集成框架。除了支持传统编程和开发解决方案外,该体系结构还广泛支持面向服务的集成解决方案的开发。对 SOA 的支持开始于 IBM 软件开发平台中针对 MDA 的行业领先的支持技术,后来在 IBM WebSphere Application Server 和 IBM WebSphere MQ 中的 WebSphere 基础技术中进一步得到了实现。整个 WebSphere Integration Reference Architecture 严格依赖于支持 SOA 开发的现有标准和新兴标准。更重要的是,WebSphere Integration Reference Architecture 对所有集成样式都提供支持,允许在基于标准的基础上将人员、流程和信息联接起来。该解决方案体系结构开发和实现了业务和 IT 度量的监视,并支持将其作为完整开发平台的一部分,从而为生命周期建模提供了强大的支持。

结束语

WebSphere Integration Reference Architecture 允许企业通过面向服务的体系结构基础在业务需求和技术解决方案之间形成紧密的联接。应用这一体系结构并结合“关注点分离”概念,是替换传统集成方法的一种完美选择。

三个主要概念——MDA、SOA 和 BPM——是 WebSphere Integration Reference Architecture 的三大支柱。包含 MDA、基于角色的开发工具通用框架允许设计和开发各种集成构件。可以通过企业服务总线体系结构提供的通信基础设施,来测试这些构件并在运行时环境中进行部署。这些集成组件都可以利用基于 SOA 的通用核心基础设施服务集(以提高性能、可扩展性、安全性,等等)。最后,覆盖此运行时结构的,是包含 BPM 的广泛监视和管理环境。

总之,WebSphere Integration Reference Architecture 提供完整的综合性体系结构,可以满足企业中方方面面的集成需求。明确定义和交付的集成服务以模块化的方式促进跨组织的重用和共享能力。随着新项目的实现,可以方便地添加或扩展服务,从而拓宽企业集成工作的作用域并提高其效率。WebSphere Integration Reference Architecture 允许组织采用面向服务的方法进行集成,这样就避免了与传统集成方法相关的缺陷。

致谢

作者非常感谢 Worldwide WebSphere 技术销售小组在创建和发展 WebSphere Integration Reference Architecture 的过程中所做的工作,其中 Bill Hassell、Bob Liburdi 和 Bob Knaus 三位的贡献尤为突出。此外,作者还感谢 IBM CTO for Business Integration 的 Dan Wolfson 对本文进行了全面审阅。


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文
  • M Endrei(和其他人)撰写的 Patterns: Service-oriented Architecture and Web Services (红皮书),IBM TSO,2004 年。
  • C Perks 和 T Beveridge 撰写的 Guide to Enterprise IT Architecture Springer-Verlag,New York,2003。
  • G Booch 等撰写的 An MDA Manifesto MDA Journal,2004 年 5 月。
  • M Keen 和其他人撰写的 Patterns: Implementing an SOA using an Enterprise Service Bus IBM 红皮书 SG2463,2004 年 7 月。
  • IBM Service-Oriented Modeling and Architecture,IBM Business Consulting Services Overview,2004 年。

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, SOA and web services, Open source
ArticleID=94221
ArticleTitle=IBM WebSphere 开发者技术期刊: WebSphere Integration Reference Architecture 简介
publish-date=08172005