内容


体系结构实践,第 5 部分

场景 2:实际 SOA 场景中的服务连接性选项

使用不同 ESB 实现灵活的服务连接性选项

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 体系结构实践,第 5 部分

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

此内容是该系列的一部分:体系结构实践,第 5 部分

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

引言

体系结构实践 系列文章的第 1 部分 理解面向服务的体系结构 讨论了 IBM 的面向服务的体系结构 (SOA) 基础生命周期(或 SOA 生命周期),以及其如何允许 IBM 客户从软件开发生命周期的角度来考虑 SOA。其中详细讨论了 IBM SOA 生命周期的四个阶段——建模、组装、部署和管理。

本文将重点讨论八个 SOA 解决方案场景中的第二个:服务连接性场景。第 4 部分 讨论了用于创建服务的技术,以及重用现有功能并将其作为服务来公开的动机。服务连接性场景进一步发展了该思想,并基于“重用资产比从头构建资产更好”这一中心主题。在本文中,了解能够连接企业范围内外的服务以实现面向服务的生态系统的各种机制。了解四种不同的 SOA 连接性实现,以及如何将这些实现映射到 SOA 生命周期的各个阶段。

对于每个示例,IBM 推荐了支持其实现的工具和产品。支持服务连接性的主要体系结构构造是企业服务总线(Enterprise Service Bus,ESB)。本文还将研究一些经常遇到的 ESB 拓扑,以及如何使用这些拓扑来定义端到端服务连接性解决方案。

虽然文中提到了许多工具和产品,但是阐述所有这些工具和产品已超出了本文的范围。请参见参考资料以进一步探索相关主题。

处理业务挑战

为了成为面向服务的业务和 SOA 生态系统的参与者,当今的企业必须了解如何将现有的和新的服务集成到编排良好的业务流程中。现代 IT 环境中的多平台、多传输协议和多样化数据格式的异构性使得在任何时候使用任何设备从任何地方 处理无缝的信息流变得势在必行。

构建超越传统企业边界的业务流程以及构建与业务合作伙伴之间的信任关系的能力正在成为主流需求。挑战在于:

  • 同质化资产和服务的连接性以支持业务流程,以及
  • 简化服务和 SOA 基础设施之间的连接性以构建无缝连接的平台,这样的平台可在联合环境中促进安全、可靠和可伸缩的信息流。

服务连接性场景

服务连接性场景演示了服务提供者和使用者之间的连接性,并促进新的和现有的服务跨多个交付通道重用。对于本文,我们假设在业务问题的上下文中对 SOA 解决方案场景进行了评估,并选择服务连接性场景来进行实现。简而言之,该决策过程依赖于:

  • 本系列的第 2 部分,其中提供了使用 SOA 场景的过程。该过程的关键部分是用于作出选择的标准。在 第 2 部分 的表 1 中,存在四个可归入服务连接性场景的通用用例。第一步是将给定问题域的功能需求映射到这四个通用用例之一。
  • 所开发的实现,这些实现说明了如何使用选定的产品来实现该场景。实现将客户场景与其解决方案组合在一起。提供了帮助客户快速开始其 SOA 实现的典型实现。

下一部分将介绍通用用例的实现。

四种常见实现

服务连接性场景的核心是 ESB 的概念、应用和实现。根据给定问题的需求对 ESB 的功能进行映射,从而产生一个或多个实现该解决方案所必需的 ESB 产品。四种常见实现如下:

安全连接到外部的第三方和业务合作伙伴

通过集成第三方供应商或业务合作伙伴提供的服务,从而将企业业务流程扩展到企业边界之外,这个需求能够保证获得一个可由任何客户使用的公共解决方案。通常建议使用 ESB 网关(无论独立使用还是与企业内 ESB 结合使用),以提供内部和外部域边界之间的安全服务交互。

当唯一的需求是对资源的安全访问时,可以独立使用 ESB 网关。基于中间件和集成需求,ESB 网关还可以提供一些基本的中介和路由功能,从而发挥双重作用。在这样的情况下,建议使用的产品是 IBM Datapower XML Security Gateway XS40(以下称为 Datapower 设备)。Datapower 设备是一个硬件设备,旨在提供以下功能:XML 转换、用于调用企业服务的安全访问通道和基本的中介流功能。这些功能主要是为用于 Web 服务流量的支持消息的网络代理而设计的。这些设备在处理 XML 消息方面具有极高的性能。它们还是应用程序安全体系结构中的消息控制点。

将网关 ESB 用于这种通用连接性用例也应该遵循 SOA 生命周期。生命周期的各个阶段本质上是模块化的;每个阶段的执行可以提供自己的好处,并且不依赖其他阶段的执行即可实现这些好处。图 1 将此用例的高级实现步骤映射到 SOA 生命周期。

图 1. 基于第三方合作伙伴集成的服务连接性的 SOA 生命周期步骤
第三方合作伙伴集成的 SOA 生命周期
第三方合作伙伴集成的 SOA 生命周期

表 1 解释了此用例在每个 SOA 生命周期阶段中的活动。

表 1. 基于第三方合作伙伴集成的服务连接性
阶段活动
建模此阶段中的高级活动并没有什么特殊之处;这些活动主要集中于了解和记录第三方服务对企业策略、角色和性能指标的影响。
组装使用 IBM Datapower Toolkit 来为 Datapower 设备配置一个简单的 XML 防火墙。在配置当中,重要的是请求和响应消息的加密和解密配置,以及定义与这些配置相关联的规则。
部署在 Datapower Toolkit 中定义配置并将其部署到 Datapower 设备上。该设备充当 ESB 网关,并支持将外部服务无缝和安全地集成到企业业务流程中。
管理监视流经企业边界的服务对安全性、性能和可用性需求的遵从性。在此情况下,建议使用的产品是 IBM Tivoli® Composite Application Manager (ITCAM) for SOA。Datapower 设备与 ITCAM 无缝集成,并且可用于监视跨越范围边界的服务调用和信息流。

如果需要超出 Datapower 设备所提供的服务消息级别安全性的增强安全性,可以使用 IBM Tivoli Access Manager (ITAM)。ITAM 与 Datapower 设备无缝集成以增添额外的安全性。如果基础设施已经具有某种安全机制(例如 ITAM)的实现,则不能配置 Datapower 设备来实现消息级别安全性,而是只能将其用于加速 XML 处理。

基于开放标准连接内部业务系统

有时,某企业具有一种业务和 IT 优势,可以使用基于标准的技术来实现各种服务之间的连接,这些服务使用一个基于 WebSphere® Application Server 的中间件基础设施来对业务流程进行编排。当该企业希望与支持许多基于标准的服务调用机制的客户接触时,建议使用的 ESB 为 IBM WebSphere ESB。

WebSphere ESB 为基于标准的 ESB 实现提供了一个功能齐全的部门解决方案。该 ESB 支持发布/订阅和一对多的流、关键业务功能的完全事务化和确切的一次性交付,以及在任何必要情况下的任意集成逻辑。其中介功能可以为支持服务提供者所必需的消息格式和传输协议提供透明支持。

图 2 将高级实现步骤映射到 SOA 生命周期。

图 2. 基于开放标准的服务连接性的 SOA 生命周期步骤
基于标准的内部连接性的 SOA 生命周期
基于标准的内部连接性的 SOA 生命周期

在服务连接性场景中,重点放在服务和业务流程的组装和部署上,随后可能是对这些服务和业务流程进行管理和监视的标准实践模式。

表 2 解释了此用例在每个 SOA 生命周期阶段中的活动。

表 2. 用于基于开放标准连接内部业务系统的活动
阶段活动
建模重点在于确定和记录服务提供者用于访问流程的业务通道。对业务流程进行模拟;从模拟中收集的指标将帮助开发业务用例,以便使用实现流程的服务之间基于标准的连接性来自动化和现代化业务流程。
组装设计和实现提供消息路由和和转换的中介流。IBM WebSphere Integration Developer 是建议用于构建 WebSphere ESB 中介和流的工具。中介流帮助处理传入的消息、记录内容以用于审核目的,或在将消息路由到其最终目的地之前根据需要对消息进行分解。有关此主题的更多信息,请参见参考资料
部署将在 WebSphere Integration Developer 中组装和构建的中介流部署到 WebSphere ESB 运行时平台。WebSphere ESB 是基于 WebSphere Application Server 构建的,并继承了其所有标准和高级安全性、性能、集群能力和容错功能。WebSphere ESB 提供了:
  • 基于开放标准的所需传输协议,以支持各种用于客户请求的业务通道。
  • 中间件运行时平台,以运行智能消息转换和路由所需的中介。
建议将 WebSphere ESB 用作部门或内部网 ESB。消息和服务安全性通常不是支持应用程序和系统间连接性的优势。
管理必须对部署在 WebSphere ESB 上的中介进行管理和监视,以满足指定的服务水平协议(service level agreement,SLA)。能够管理和监视 WebSphere ESB 中介的建议基础设施是 ITCAM for SOA。

ITCAM for SOA 为部署基于 Web 服务的 SOA 应用程序的企业提供一套全面的管理解决方案。ITCAM for SOA 能够发现、监视、诊断和控制使用诸如 SOAP/HTTP 或 SOAP/JMS 等开放标准实现的 Web 服务。它可以帮助确定和解决围绕已部署的服务发生的问题。

通过新的业务通道交付现有的业务流程

SOA 生态系统的一个重要原则是促进服务使用者和服务提供者之间无缝和透明连接。典型业务和 IT 环境的异构性导致了一组集成服务使用者和提供者的不同挑战。服务使用者发送的消息格式:

  • 可能未标准化。
  • 可能随不同的使用者而异。
  • 可能粒度太大而需要分解。

消息分解、路由和中介是主要需求。

即使解决了消息格式,并且实现了基于消息信息的路由,服务使用者用来发起服务请求的协议也可能与服务提供者预期的协议不同。例如,某个服务使用者可能发起一个基于 HTTP 的服务请求,而实际的服务可能预期基于 JMS 的请求调用。

围绕服务调用的安全性也是一个很难解决的问题。在从企业范围之外调用时,服务可能需要适当的安全上下文,但是在由公司防火墙内部的应用程序和系统调用时,服务可能不需要任何安全性。

服务请求者可以请求某个可能由一个或多个服务所支持的业务功能,这些服务组合在一起以实现该功能。这样的组合需要在某个中间件层上进行设计、实现和部署,以促进无缝连接。

在遗留系统和应用程序中实现核心业务功能的企业可能需要释放其业务潜力并保持开放。外部客户和企业都可以得益于跨 IT 组合中的多个应用程序的重用。通过特定的技术适配器连接到标准和非标准后端系统的能力成了迫切需求。

在这种场景中,至少执行以下功能的高级 ESB 是理想的选择:

  • 在通信协议之间进行转换
  • 使用中介功能从异类数据格式转换到规范的消息模型
  • 将服务请求路由到适当的服务提供者
  • 组合服务以满足某个服务请求
  • 事务管理
  • 消息中枢

IBM WebSphere Message Broker (Message Broker) 适合于需要高级 ESB 功能的场合。当 Web 服务支持不是非常关键,并且服务质量需求要求使用成熟的中间件时,可以选择使用 Message Broker。Message Broker 可以支持上述所有 ESB 功能,并且不仅限于基于开放标准的互操作性。

图 3. 将业务流程扩展到多个通道的 SOA 生命周期步骤
将业务流程扩展到多个通道的 SOA 生命周期
将业务流程扩展到多个通道的 SOA 生命周期

表 3 解释了此用例在每个 SOA 生命周期阶段中的活动。

表 3. 用于通过新业务通道交付现有业务流程的活动
阶段活动
建模对跨越组织边界的业务流程进行深入分析。根据上下文,多个业务流程中使用的服务可能需要支持不同的业务通道来与服务使用者交互。必须支持服务使用者所使用的每种协议和消息格式。此阶段中的需求和发现可帮助更周密地判断 ESB 可能需要执行的高级功能。
组装对服务的编排和关联的消息流进行设计和组装。建议使用的工具是 WebSphere Message Broker Toolkit,这是一个基于 IBM Rational Application Developer 的 Eclipse 插件。此工具可以帮助消息流和消息集的开发,并管理消息代理及其运行时组件(执行组和运行于其中的已部署消息流)。此工具可以加速和简化消息流的开发。改进的 Web 服务支持(包括 WSDL 生成和使用)提供了基于关键标准的服务编排。
部署使用至少三个产品的组合。Message Broker 用作 ESB,并提供可靠的中介支持以及其他功能;WebSphere MQ 作为持久性消息中枢提供了完美的辅助。对于多个不同的遗留系统,WebSphere Adapter 技术提供了从 Message Broker 到各种各样基于遗留技术的不同应用程序的连接。

WebSphere Adapter 框架具有一百多个技术适配器,从而提供了与可想象的几乎任何供应商和打包产品的连接和集成。

管理 ITAM 提供了一个集中、灵活和可伸缩的访问控制解决方案,以控制用户对受保护的信息和资源的访问。Tivoli Federated Identity Manager (TFIM) 用于管理安全凭据跨安全域的传播。

有了 Message Broker 和 WebSphere MQ 作为 ESB 基础设施,建议使用 IBM Tivoli OMEGAMON XE for WebSphere Business Integration 来管理和监视该 ESB 基础设施。Omegamon 改进了 Message Broker 和 WebSphere MQ 可用性,主动预防问题,并通过单个工具简化管理。Omegamon 还提供了一个支持 Web 的工具,用于报告所管理的资源的实时可用性和性能。

从第三方系统调整为 Web 服务

对诸如 SOAP/HTTP 和 JMS 等开放标准的遵守正在日益成为公司的强制要求,但是大多数企业还具有基于遗留应用程序和系统的中到大型 IT 组合。SOA 的一个基本原则是通过将旧的、现有的和基于第三方的应用程序、系统和技术调整为基于 Web 服务技术的开放标准,从而释放其中的业务价值。

通过某种能够实现多个业务流程并到达不同业务通道的机制,从而重用现有系统和应用程序中的关键功能,这是 SOA 的一个基本价值主张。通过重用经由现代 Web 服务技术调整过的现有功能,您可以减少新应用程序开发的成本和整个开发生命周期中的成本。使用 Web 服务技术来调整第三方和遗留系统,这在任何应用程序现代化活动过程中都是一个非常恰当和重要的选项。

使用该适配器框架,您可以使用 ESB 来提供到企业信息系统(enterprise information system,EIS)和遗留系统的连接。存在两个要考虑的主要适配器类别:

  • WebSphere Business Integration (WBI) 适配器允许异构业务应用程序通过协调的信息传输来使用业务对象在 ERP、HR、CRM 和供应链系统之间交换数据。
  • WebSphere JCA 适配器提供了一种在 J2EE™ 中存储和检索企业数据的机制。WebSphere JCA 支持到 JDBC、平面文件和诸如 SAP、PeopleSoft 或 Siebel 等系统的连接。

WBI 和 WebSphere JCA 适配器的使用假设:

  • 客户拥有或正在考虑拥有 WebSphere Application Server 基础设施。
  • 不存在 WS-Security 或其他复杂的安全性考虑。
  • 客户机与 EIS 系统之间不存在太多的数据同步需求。
  • 请求的数量适中。

使用 WBI 适配器还是使用 WebSphere JCA 适配器是一个体系结构决策,需要根据客户的需求和现有的第三方系统而定。一些 WebSphere 适配器包括:

  • IBM WebSphere Adapter For Flat Files, Version 6.0
  • IBM WebSphere Adapter for JDBC, Version 6.0
  • IBM WebSphere Adapter for PeopleSoft Enterprise, Version 6.0
  • IBM WebSphere Adapter for Siebel Business Applications, Version 6.0
  • IBM WebSphere Adapter for SAP Applications, Version 6.0

表 4 解释了用于从第三方系统调整为 Web 服务的相对于 SOA 生命周期阶段的活动。

表 4. 用于从第三方系统调整为 Web 服务的 SOA 生命周期和活动
阶段活动
建模在此服务连接性选项中映射活动时,不需要任何独特的东西。
组装WebSphere Integration Developer 是用于构建运行在 WebSphere ESB 上的中介功能的开发和组装工具。此实现中的中介功能包括将 WebSphere BI 或 JCA 适配器整合到中介应用程序中所需要的企业发现功能。
部署 WebSphere ESB 和 WebSphere Adapters 都要派上用场。WebSphere Adapters 提供了到后端和第三方系统的连接所必需的 EIS 适配器。WebSphere ESB 提供了中介功能以对数据执行 XSLT 转换,并包括一个在消息流经中介时对消息进行日志记录的功能。
管理ITCAM for SOA 是建议用于监视和管理 Web 服务调用之间的流量的基础设施组件。需要一个联合标识管理解决方案来管理安全凭据跨体系结构中多个层的传播——特别是业务逻辑层和 EIS 系统之间。IBM TFIM 是建议用于管理标识和跨多个安全域的资源访问的解决方案。

中介概述

在 SOA 中服务间连接的上下文中,中介 指的是:

  • 在传入的服务请求消息到达服务提供者之前对请求消息进行转换、路由和扩充的方式。
  • 在将来自提供者的响应最终发送回原始请求者之前对响应应用相同技术的方式。

WebSphere ESB 是一个能够运行消息中介的运行时环境。用于定义消息中介的技术基于服务组件体系结构(Service Component Architecture,SCA)。中介模块 是消息中介的基本部署单元。其中包含操作消息请求和响应的中介流组件。在中介模块的最终打包中,至少存在一个导出(定义服务使用者用于调用该中介的接口)和一个导入(定义到某个服务提供者的连接)。中介流和模块全都使用 WebSphere Integration Developer 中的中介流编辑器来进行设计和打包。

中介是遵循四个常用模式来开发的:

消息协议转换
中介模块将服务请求者使用的任何基于标准的协议(HTTPS、HTTP、SOAP/JMS)转换为任何其他基于标准的协议格式,从而允许服务提供者支持服务使用者所使用的任何基于标准的协议。
基于内容的消息路由
中介模块封装了动态地选择多个服务提供者之一来满足服务请求的逻辑和智能。该逻辑主要基于筛选规则,可以将这些筛选规则应用于消息内容、消息头、服务请求者等等,以在运行时决定最恰当的服务提供者。这是一种服务虚拟化形式,这种虚拟化使请求者完全不知道是哪个提供者在实际为请求提供服务。

资金转帐服务就是这种基于业务规则和非功能需求的虚拟化形式的一个例子。高级客户可能随时都有资金可用,但是典型的客户需要等两天才有资金可用。

消息格式转换
当服务使用者使用的消息结构与服务提供者预期其传入的请求消息所具有的结构不兼容时,此方法就特别有用。在这种情况下,中介模块中转传入的请求,检测差异,并在将消息转发到服务提供者之前将请求消息格式转换为响应消息格式。中介模块还执行从服务响应消息格式到原始请求格式的逆向转换。

此类中介模块的一个示例实现是从请求者消息模式到提供者消息模式的 XSLT 转换。

消息扩充
此模式用于在将传入的请求发送给服务之前向请求添加新的参数。有时传入的消息没有提供所有的必需信息。中介模块截获传入的请求消息,执行诸如数据库查找等功能,然后在将消息发送到服务提供者之前用所需的参数来扩充消息。当添加可选参数能够加速服务请求的处理时,也可以使用这种模式。

消息协议转换和消息格式转换模式用于解决服务使用者和服务提供者之间的差异。基于内容的路由和消息扩充模式用于实现某种形式的服务虚拟化,以及封装附加的智能逻辑以促进更加无缝的连接和通信。

选择正确的 ESB

到目前为止,我们已讨论了三个不同的 ESB 产品:WebSphere DataPower Appliances、WebSphere ESB 和 WebSphere Message Broker。本部分将提供一些有关选择正确的产品来满足 ESB 需求的指导。

WebSphere DataPower Appliances 是三个不同硬件设备的集合,在 SOA 解决方案中用于重新定义中间件的边界。WebSphere DataPower Appliances 用组合了 SOA 实现的优良性能和安全性的专门的、易使用的、专用的 SOA 设备扩展了 SOA Foundation。此设备可在企业周边使用,从而提供加速的(以线速)XML 和增强的 SOA 安全性处理,并带有 XML 级别的保护和结构化的数据处理。此设备还提供了非常基本的中介功能,并与基于 IBM TFIM、Access Manager 等的安全基础设施无缝地集成。如果您正在寻找一种还能执行一些基本消息中介的 ESB 网关,那么建议您使用 WebSphere DataPower Appliances。

WebSphere ESB 将连接具有基于标准的接口的应用程序,以便为您的 SOA 提供支持。当 Web 服务支持非常关键,并且服务使用者和提供者仅使用开放标准进行通信时,可以选择构建完全基于 WebSphere ESB 的 ESB。由于 WebSphere ESB 是在 WebSphere Application Server 基础上构建的,因此它利用了后者所支持的所有传输协议。通过提供智能服务连接性选项的中介功能,WebSphere ESB 对 Application Server 进行了补充。

WebSphere Message Broker 是 WebSphere 产品套件中最高级的 ESB 解决方案。它为基于标准和非标准的技术和应用程序提供了任意到任意的连接。Message Broker 还促进了任意到任意的消息和数据转换框架,从而在最复杂和异构的环境中实现 SOA 解决方案。此产品还提供了事务处理、通过多种传输(包括 WebSphere MQ、JMS 和 HTTP)的几乎通用的连接,以及市场上的任何其他产品所无法匹敌的可靠性和性能。它支持一组更广泛的转换和中介功能,并支持可能启用也可能未启用 Web 服务的集成资产。当快速的吞吐量和服务质量需求变得非常关键时,Message Broker 是远优于 WebSphere ESB 的选择。

多个 ESB 产品的共存

WebSphere DataPower 设备是对 WebSphere ESB 或 Message Broker 的补充。图 4 显示了如何结合使用不同的 ESB。

图 4. 一起工作的 ESB 产品
一起工作的 ESB 产品
一起工作的 ESB 产品

DataPower 和 WebSphere ESB 可以在 ESB 基础设施中共存,因为它们提供相互补充的 ESB 功能。在 WebSphere ESB 在企业防火墙内提供消息中介和转换功能的同时,可以在企业周边部署一个 DataPower 设备,并对其进行配置以提供消息安全性(拒绝服务、身份验证和授权)。DataPower 还可以提供基本的消息路由功能。在由多个部门级 WebSphere ESB 提供特定于各个业务部门的服务的配置中,DataPower 设备可以将消息路由到正确的 WebSphere ESB 运行时,从而充当多个 WebSphere ESB 运行时的联合集线器。

在仅有 WebSphere ESB 的运行时中,在需要更高吞吐量的情况下,可以通过将 XML 处理开销从 WebSphere ESB 卸载到 DataPower 设备来利用该设备的强大功能,从而释放 WebSphere ESB 平台以提供更高的服务吞吐量。WebSphere ESB 还可以支持仅有 DataPower 的基础设施。WebSphere ESB 可以添加完整的事务支持、复杂的消息流实现、持久性 JMS 消息服务器、发布/订阅支持,以及广泛的应用程序和技术适配器,包括对 IBM 事务处理环境的可靠支持。

DataPower 能够以支持 WebSphere ESB 的相同方式支持 Message Broker 解决方案。由于 Message Broker 是 WebSphere 套件中最高级的 ESB,因此向仅有 DataPower 的解决方案添加了比 WebSphere ESB 更多的功能。Message Broker 提供了下列以及其他功能:更广泛的协议支持(任何第三方 JMS 1.1 支持、遥测、设备集成)、与诸如 CICS 和 IMS 等 IBM 事务处理系统的紧密集成、高级的消息和复杂的事件处理、完善的调度程序和计时器服务,以及一个用于定义任意编程逻辑的通用编程环境(Java、ESQL、C 等等)。

三个 ESB 产品中的每个产品都可以提供有针对性的中间件解决放案。它们还可以协同工作以创建更高级和基于端到端 ESB 的服务连接性解决方案。所选择的配置由给定问题域的需求决定。

结束语

IBM 确定了八个在基于 SOA 的典型 IT 项目中出现的最普遍的不同 SOA 场景。为了帮助客户开始采用 SOA,IBM 提供了以业务为中心和以 IT 为中心的 SOA 入口点和场景,并提供了有关应该如何使用 IBM 工具、产品和方法来对每个场景进行建模、设计和实现的全面指导。

在本文中,我们讨论了第二个 SOA 场景,即服务连接性。服务连接性场景是连接性入口点的一种实现。连接性入口点允许有效地连接您的基础设施,从而集成公司中的所有人员、流程和信息。通过服务之间和整个环境中的灵活 SOA 连接,无需太多的工作即可利用现有业务流程并通过不同的业务通道交付该流程。甚至还能以安全的方式连接到防火墙外的外部合作伙伴。还可以使用 Web 服务技术来调整遗留和第三方应用程序,以释放这些应用程序的价值并促进它们重用。

本文还解释了如何将 SOA 生命周期应用于实现,以及 IBM 产品套件如何解决服务实现的特定设计、开发和运行时需求。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services, WebSphere
ArticleID=302309
ArticleTitle=体系结构实践,第 5 部分: 场景 2:实际 SOA 场景中的服务连接性选项
publish-date=04212008