IBM 架构师 Tilak Mitra 为一些 IBM 工具提供实用指导,您可以用这些工具构建一个面向服务的体系结构
(SOA) 解决方案。本文是他的专栏的第一期,您可以简要地了解 IBM SOA Foundation、IBM Rational、WebSphere、Tivoli
软件工具和其他用来实现 SOA 设计的资源。
作为 IBM 的一位实践执行 IT 架构师,Tilak Mitra 为 IBM 的客户提供咨询,帮助他们开发和实现
SOA。在“体系结构实践”专栏中,Tilak 将与您分享他的经验,帮助您将 IT 体系结构的理论(尤其是 SOA)转化为实践。您有什么需要帮助的棘手问题吗?请通过
tmitra@us.ibm.com
联系Tilak,他将来可能会针对您的问题在专栏中专门撰写一期文章。
面向服务的体系结构 (SOA) 对于不同的人有不同的含义。对于一名业务执行人员,它能提供一组业务服务,并提供给客户合作伙伴。对于一名
IT 架构师,SOA 既是一种体系结构样式,也是一个范例,能用来创建模块化和松散耦合的服务,这些服务可以被组合和编排在一起,创建出代表运营企业的业务流程。
一个运行的 SOA 系统的关键在于对系统中的各项业务服务进行适当的概念化和标识。架构师在决定哪些服务需要建模和构建时,必须考查多种因素。这些因素的关键是服务的各种特性,包括:
- 服务在业务协调方面的潜力
- 它的可组合性
- 它的可重用性
- 它在实现方面的技术可行性
根据一些重要的基础性概念,可以为基于 SOA 的企业体系结构的服务建立模型,并设计这些服务。
服务会严格遵循 SOA 系统中的生命周期。SOA 生命周期的每个阶段都需要设计和开发工具,以及中间件软件产品,以使该阶段内的各项活动能顺利进行。本文介绍了
IBM 提供的重要工具和产品,它们是用来实现 SOA 生命周期内的各个阶段的。
服务的生命周期是从建立需求模型开始,然后是服务的设计和开发,接着是服务的组合与编排。此后会将服务部署到一个执行运行时。各种运行时系统不但为服务及其包含的业务流程提供了执行环境,而且还提供了一套用来监视和管理服务的机制。
SOA 基础将简要介绍实现一个 SOA 系统的逻辑步骤。IBM 已经细心地挑选了软件工具和产品,能帮助您用一个更广阔的
IBM 软件投资组合实现 SOA 基础,以支持 SOA 生命周期中的每个阶段,SOA 生命周期由下列四个阶段(常被称为
MADM)组成:
- 建模
- 组装
- 部署
- 管理
治理和最佳实践提供用来监督生命周期中每个阶段的的全部原则。图 1 展示的是 IBM SOA 基础。
图 1. IBM SOA 基础生命周期
大致上,每个阶段发生的一般活动如下:
- 建模。收集需求,对端到端的业务流程进行建模、分析和设计,然后再进一步优化,形成企业的未来状态业务流程。
- 组装。实现服务。已实现的服务将被组装,也就是说,它们将被发现、编排和组合,以实现企业业务流程,这些流程将经过测试,以满足功能性和非功能性需求。
- 部署。组装好的业务流程会被部署到正在操作的运行时环境中。
- 管理。对运行时中执行的服务和业务流程进行监视和分析,以保证它们能正常运行。此外还会测量安全性、性能和可用性等
IT 度量。对服务和业务流程进行进一步监视,以保证它们与应当满足的业务度量及服务级别协议 (SLA) 之间的兼容性。
- 治理和最佳实践。这是用来监督 MADM 生命周期中每个阶段中所有方面的全部原则。由于治理和最佳实践对
SOA 开发有着深远的正面影响,因此被视为强制性原则而加以制度化,使之成为一个正规的 SOA 实现中必需的一部分。
本文剩余部分将重点介绍用来实现 SOA 生命周期中每个阶段的 IBM 工具和产品。您可以从 developerWorks
的试用版下载区下载本文中介绍的某些产品的试用版。(请参见参考资料部分。)
这一部分将介绍可以用来执行 SOA 生命周期各阶段的活动的 IBM 产品。
建模阶段
- WebSphere® Business Modeler
- Rational® RequisitePro®
在建模阶段,将围绕企业运营的关键流程进行业务建模。首先会建立当前业务流程的模型。这个步骤将帮助您记录业务的当前状态,并教育员工和新职员,使他们了解业务是如何运行的。此后会模拟现有的已建模业务流程,以确定现有操作中的可能瓶颈。业务流程优化将帮助您重新设计已确定的瓶颈区域,使业务流程变得更灵活,性能更高,并能消除故障点和消费者抱怨的服务。
这一优化的成果是目标业务流程的模型。它们依次被各种数据点模拟,以评估可能的后果。这些后果可以根据业务需求(功能性和非功能性的)加以验证。利用模拟的流程,可以预测如何在各种不同的场景中执行业务;例如,在不同的季节,会有不同的使用者负载。业务将不再被突然情况弄得措手不及,这有助于业务从被动式的操作模式转换到另一模式中,在该模式中,可以对不同业务事件的后果进行预测。这是为了成为灵活的企业而迈出的关键一步。
企业需要成熟的工具来建立业务流程的模型,而且建模的方式不能过于深奥和困难,以致于只有 IT 人员才能使用。该工具应当使用普通的业务词汇,而不是复杂的
IT 术语。它应当能够将关键性能指标 (KPI) 形式的业务度量、资源、成本和性能度量添加到流程的元素中,以便在
SOA 生命周期中后来的阶段测试它们。WebSphere Business Modeler 提供这一类的功能。它是一个可靠的、完全成熟的、稳定易用的产品,能用来建立业务流程的模型。
WebSphere Business Modeler 可以:
- 供业务分析员使用。
- 捕获业务流程设计。
- 提供业务流程、组织结构、资源和性能度量的可视化表示形式。
- 提供一个用于流程分析和测试的模拟工具。
- 导出 SOA 生命周期中各个阶段的活动所使用的业务模型。
- 生成与节省的成本、时间和资源有关的信息。
- 在对流程或服务进行实际更改之前,查看瓶颈和工作负载的不平衡之处,以便优化业务流程。
这并不是 WebSphere Business Modeler 的完整功能列表,但它说明了该工具是如何在 SOA
生命周期建模阶段中的活动中使用的。图 2 是某个业务流程模型的快照,该模型是用 WebSphere Business
Modeler 创建的。
图 2. WebSphere Business Modeler 中的示例业务流程模型
Rational RequisitePro
收集需求是建模阶段中另一项重要的任务。Rational RequisitePro 解决方案帮助团队利用数据库功能(如需求跟踪和影响分析),以他们熟悉的、基于文档的方式创建和分享需求。其结果是,令需求得到更好的沟通和管理,提高了项目按预期准时在预算内完成的可能性。
Rational RequisitePro 中的关键功能包括:
- 与 Microsoft® Word 的高级集成
- 一个可靠的数据库体系结构
- 可自定义、可筛选的需求属性
- 深入的可跟踪性和覆盖率分析
- 利用审核记录和电子邮件通知进行的详细的更改/影响分析
- 创建和比较项目基准
- 为分布式团队提供的 Web 访问功能
- 灵活的报告选项
- 可配置的导入功能
- 与 Rational Software Development Platform 包的多个工具集成
- 可由用户定义的需求类型
- 可配置的项目和文档模板
图 3 提供了使用 RequisitePro 收集的需求快照。
图 3. 用来收集需求的 RequisitePro 工具
组装阶段
- Rational Software Architect
- Rational Application Developer
- Rational Data Architect
- WebSphere Integration Developer
组装阶段可分为下列三种主要活动:
- 服务设计
- 服务构建
- 服务集成
如果您回顾过去几年的软件开发历程,您可能会想起使用 Visio 进行流程建模的经验并与人分享,而且会发现在建模和设计之间存在着空白。用
Visio 创建的构件与用来设计和开发组件和服务的下游工具不兼容。
WebSphere Business Modeler 是作为一种完美的解决方案出现的。使用这一工具设计的模型可以以至少三种格式导出:业务流程执行语言
(BPEL)、统一建模语言 (UML) 2.0 和 XML 模式定义 (XSD)。BPEL 被用来编排和组合服务,而符合
UML 2.0 的输出则在使用 Java™ 2 Platform, Enterprise Edition
(J2EE) 等技术进行设计和实现时会被用到。在业务的输入和输出步骤中确定的业务实体,其 XSD 定义对于逻辑数据模型和信息模型而言是一个绝佳的起始点。
业务流程的元素,即组成流程的活动,可以作为业务服务或可重用组件实现。无论采用何种实现方法,流程都需要使用 J2EE
等技术进行设计和实现。然后,已实现的服务可以进行组装,以实现业务流程,接下来业务流程将在运行时上执行。
服务设计、规范和构造
Rational Software Architect 和 Rational Data Architect 用来设计服务、数据元素和消息。Rational
Application Developer 则使用 J2EE 技术实现服务。
Rational Software
Architect
Rational Software Architect 是一个集成式的设计和开发工具,它利用了 UML 的模型驱动开发。版本
6.0.1 中新的 SOA 设计资源简化了从业务流程到面向服务的应用程序的转换。WebSphere Business
Modeler 和 Rational Software Architect 之间的无缝集成,使软件架构师可以用
UML 2.0 符号使业务流程模型可视化,而无需手动导入流程模型。这一集成还提供业务模型和设计模型之间的直接映射。WebSphere
Business Modeler 中的流程模型可以导出为 UML 2.0 格式,然后导入 Rational Software
Architect,并在其中成为活动关系图。
UML 2.0 Profile for Software Services(由 Rational Software
Architect 与 WebSphere Business Modeler 的集成提供支持)扩充了 UML,提供了一种用来描述服务的通用语言,使架构师们可以建立模型并生成
Web 服务。这一概要可以应用于任何新模型或现有模型,它还为 SOA 分析和设计添加了一些新概念和新符号。这一概要为架构师们提供了一些新功能,使他们可以使用描述整个企业级服务投资组合的逻辑分区对服务进行规划,开发出服务规范(包括结构和行为的),作为服务的客户与实现者之间的契约。因此,可以用
Rational Software Architect 设计和指定服务。图 4 显示了一个使用 Rational
Software Architect 的 UML 建模示例。
图 4. 使用 Software Architect 的 UML 2.0 中的服务设计和规范
Rational Application
Developer
当设计和指定服务后,需要对它们进行构造和实现。在服务的构造和实现过程中,可以使用 Rational Application
Developer。该工具是一个面向服务的开发环境,使许多通常在 Web 服务的构造和使用过程中执行的任务实现了自动化。从
Web 服务描述语言 (WSDL) 文件和代码的生成,到测试客户机的产生和Web 服务互操作性 (WS-I) 的一致性验证,一切都由
Rational Application Developer 实现了自动化,开发人员可藉此将注意力放在业务逻辑代码的编写上。
您还可以使用 Rational Application Developer 创建、构建、使用、测试、部署和发布
Web 服务,您可以从头做起,也可以使现有的应用程序符合 WS-I。Rational Application Developer
根据需求规范和 UML 模型,采用自顶向下的方法简化 Web 服务的创建流程。它甚至能创建 Enterprise
JavaBeans (EJB) 的框架,该框架能用来实现 Web 服务。Rational Application
Developer 还在 Web 服务的创建中发挥协助作用,它采用自底向上的方法,由现有的 Java 类或 EJB
进行创建,它提供一个向导,根据现有的 Java 类和 EJB 自动生成 WSDL 定义。Rational Application
Developer 还拥有 J2EE Connector Architecture 工具,它们可以使您轻松地将现有的企业信息系统
(EIS),如 IBM CICS® 或 IBM IMS™,集成到您的 SOA 解决方案中。使用这些工具,开发者可以根据某个现有的
EIS 事务,迅速创建一个 Web 服务。
Rational Data
Architect
Rational Data Architect 是一个企业数据建模和集成设计工具,它的设计目的是帮助数据架构师设计关系型和联合数据库,理解数据资产和它们的关系,以及简化数据库项目。Rational
Data Architect 使用 WebSphere Business Modeler 将 XSD 导出到关系型数据库
(RDB) 模式中。RDB 模式能帮助创建 RDB 数据的映射。在 Rational Data Architect
中执行的数据建模还可以在以后导出为 UML。
Rational Data Architect 被用来创建逻辑数据模型和数据映射,它们可以从 Rational
Data Architect 中导出为 UML 格式,并导入 Rational Software Architect。这会对以
UML 2.0 格式从 WebSphere Business Modeler 中导出的业务流程模型进行扩充,然后导入
Rational Software Architect。Rational Software Architect
在其后会使用一个名为 UML 2.0 Profile for Software Services
的 RSA 插件设计和指定服务。之后,已经过设计和指定的服务将在使用 J2EE 技术的 Rational Application
Developer 中进行构造。
服务组合与编排
在服务实现之后,需要用它们组合和编排业务流程。在 WebSphere Business Modeler 中创建的业务流程模型将使用
BPEL 进行优化和实际组装。组装阶段使用现有的和新建的服务,以实现业务流程中的每个活动。
WebSphere Integration Developer
IBM 的 WebSphere Integration Developer 为集成开发人员提供他们需要的可视化软件开发工具,用来指定、测试和部署可执行的业务流程。WebSphere
Integration Developer 帮助确保流程将 Web 服务、企业应用程序、人工任务和其他服务组件有效地集成到基于
SOA 的业务解决方案中。
WebSphere Business Modeler 中的业务流程被导出为 BPEL,然后导入 WebSphere
Integration Developer。之后 WebSphere Integration Developer
将按 WS-BPEL 表示业务流程。BPEL 流中的每个活动通过下列两种方式之一实现:
- 作为一个已经开发的服务(例如,使用 Rational Application Developer 预先构建的服务)或一个外部服务(例如,由企业对企业的合作伙伴提供的服务)
- 作为一个使用服务组件体系结构 (SCA) 的构造和功能的服务组件(WebSphere Integration
Developer 支持 SCA);或作为 IBM 向 BPEL 的扩展
图 5 显示了 WebSphere Integration Developer 的 business integration
透视图,它被用来通过服务编排来细化和实现业务流程。
图 5. WID 的 Business Integration 透视图
WebSphere Integration Developer 还可以帮助团队编排业务流程,方法是将原子连接在一起,并组合服务,以实现业务流程。此后您可以在一个运行时环境中执行这些流程。
部署阶段
- WebSphere Application Server
- WebSphere Process Server
已实现的业务流程现在已经就绪,可以部署到某个支持执行动态业务流程的运行时中去了。该运行时必须提供基于开放标准的执行环境,以使服务能随时调用其他服务。执行运行时至少应支持下列三项基本功能:
- 各种服务调用间的协议转换
- 适当的服务供应商间的路由
- 用来提供安全性、审核、日志记录等功能的中介
服务的实现构件(例如 J2EE 组件、类、EJB)也需要一个可靠的、可伸缩的高性能应用程序服务器,以保证实现预期的服务水平和质量。
WebSphere Application
Server
WebSphere Application Server 在 SOA 基础中充当两种角色。对于基本的 SOA
业务服务(主要是那些用 EJB 实现的服务)而言,它是一个安全的、可伸缩的高性能弹性承载环境。这些服务可以用 WSDL
公开,并通过标准 Web 服务协议和编码进行集成。它们还可以通过远程方法调用/ORB 间协议 ( Remote
Method Invocation/Inter-ORB Protocol,RMI/IIOP) 绑定,用一种更紧密的耦合方法进行集成。WebSphere
Application Server 还可作为 WebSphere Portal、WebSphere Process
Server、WebSphere Enterprise Service Bus 和 IBM 软件组合中各种其他产品的基础执行平台。用来实现服务的已构造服务和
J2EE 组件可以在 WebSphere Application Server(包括版本 6.1,它是最新的版本)上运行。
WebSphere Process
Server
虽然 WebSphere Application Server 提供了用来运行服务的运行时,但它不提供用来运行动态业务流程的中间件功能。它也无法处理服务调用、协议转换、中介,以及请求路由。WebSphere
Process Serve 版本 6.0.1 能安全地、一致地执行业务流程,并能保持事务的完整性。它包含对基于
BPEL 的流程流和业务状态机的支持。WebSphere Process Server 还支持流程和服务选择中的业务规则集成。流程服务器是
IBM 套件中对服务组件体系结构 (SCA) SOA 编程模型提供直接支持的第一款产品。WebSphere Process
Server 还与 WebSphere Portal Server 集成,为业务流程中的人工任务提供支持。
在 WebSphere Integration Developer中组装的业务流程可以部署在 WebSphere
Process Server 执行运行时中。WebSphere Process Server 是根据各种标准构建的,如
BPEL、Web 服务、Java 消息服务 (Java Message Service, JMS)、XML,以及许多其他标准,以保证任何属于
SOA 系统的服务都能获得最高的互操作性和灵活性。WebSphere Process Server 包含 WebSphere
Enterprise Service Bus (ESB),后者处于不同的资源之间,可最大限度地重用您的资产,而不管它们在什么位置,也不管它们的供应商、平台,以及它们是否是自制应用程序或打包应用程序。
WebSphere Application Server 与 WebSphere Process Server
和 WebSphere ESB 联合,提供一个可靠的、可伸缩的高性能部署环境,用来运行任务关键型业务流程和业务应用程序。WebSphere
Application Server provides 为这两者提供一个用来运行 J2EE 组件(对于构建企业应用程序是必需的)的
J2EE 运行时以及若干 WSDL 文档(以便将业务服务作为 Web 服务公开), WebSphere Process
Server 则提供运行时,以编排和组合业务服务,运行业务流程。WebSphere Process Server
包含的 WebSphere ESB 为企业服务总线提供各项功能。WebSphere ESB 和 WebSphere
Process Server 都在 WebSphere Application Server 上运行。
管理阶段
- WebSphere Business Monitor
- Tivoli® Composite Application Manager for SOA
- Tivoli Composite Application Manager for Response Time
Tracking
- Tivoli Federated Identity Manager
在部署阶段,业务流程和业务应用程序被部署到适宜的 SOA 执行运行时环境套件中。在管理阶段,团队需要确保应用程序、服务、业务流程、SOA
体系结构和中间件运行时能平稳有效地运行。必须根据应满足的业务度量和 SLA,对 SOA 系统构造和构件进行监视和度量。另外还需对业务的投资回报
(ROI) 进行度量。因此,管理阶段不但管理着企业 SOA(服务、流程和体系结构),还对它的有效性和效率进行监视和度量。
管理阶段至少可以分为四个主要领域,它们与 SOA 系统有更为密切的关系:
- 管理业务流程
- 管理服务层
- 管理事务性能
- 管理服务安全性
在本文中,会对每项活动和用来进行该活动的工具进行分别处理。这并不是一份记录了在 SOA 管理阶段中执行所有活动时所需的全部产品的完整列表。不过,利用本文所述的产品,您可以完成
SOA 生命周期中一个典型管理阶段的大部分必要任务。
管理业务流程——WebSphere
Business Monitor
WebSphere Business Monitor 运行时产品能对业务流程进行实时监视,提供业务流程状态的可视化显示。WebSphere
Business Monitor 与 WebSphere Business Modeler(在建模阶段中使用)集成,使
WebSphere Business Monitor 可以跟踪业务流程(由WebSphere Business
Modeler 建模)的业务度量(如成本、收入、性能),并检查它们的遵从性。为了帮助管理和度量业务流程,WebSphere
Business Monitor 具有下列功能:
- 对业务流程进行实时监视,并使信息可通过定制的业务仪表板进行访问,可以针对不同用户(业务参与者、业务分析员、IT
系统经理),对业务仪表板做进一步个性化处理。业务仪表板提供了关键性能指标(如成本、收入、时间和资源)的记分卡视图。
- 用标出异常的方法,为那些有助于持续改善业务流程和管理企业的关键用户提供警报,这些异常在此后可被收集起来,以找到解决的办法。
- 提供数据分析工具,检查多种因素,在流程信息中寻找可使流程更有效率的模式。
- 能对关键情况作出快速响应,提高客户的满意度。
- 能持续监视和确认系统,以改善缺陷级别或其他服务度量的遵从性。
- 从正在执行的流程中收集实时数据,这些流程可以用来提高未来流程模型的精确度。
- 将数据反馈到 WebSphere Business Modeler,以模拟流程,帮助优化未来流程的实现过程。
管理服务层:Tivoli
Composite Application Manager for SOA
应用程序的分层体系结构有新增的服务抽象层,因此必须有一种机制用来监视、管理和度量在某个 SOA 中充当第一类构造的服务。IBM
Tivoli Composite Application Manager for SOA (ITCAM for
SOA) 解决方案提供了端到端的 Web 服务跟踪,帮助确定在服务的执行和调用期间暴露的问题,并将其隔离。
ITCAM for SOA 的设计目的是,为部署基于 Web 服务的 SOA 应用程序的企业提供一套全面的管理解决方案。ITCAM
for SOA Version 6.0 能发现、监视、诊断和控制用 SOAP/HTTP 和 SOAP/JMS 实现的
Web 服务。它帮助您标识和解决可能在部署的服务周围发生的问题。它的做法是从服务深入到应用程序组件和 IT 资源,以确定瓶颈或故障的来源。它提供内置的警报、通知,以及可使运行时中的服务管理实现自动化工作流。服务度量和警报还作为
portlet 出现,可以很容易地集成到企业门户中去。
图 6 显示了 ITCAM for SOA 是如何在运行时提供服务运行状况的不同视图的,这些视图在此后会显示在一个门户环境中。(此处使用的是
Tivoli Enterprise Portal。)
图 6. ITCAM for SOA 以 portlet 的形式提供不同的服务运行时信息
管理事务性能:Tivoli
Composite Application Manager for Response Time Tracking
IBM Tivoli Composite Application Manager for Response Time
Tracking (ITCAM for RTT) 提供了端到端的事务跟踪,以快速确认问题并将其隔离。该产品通过合成和真实最终用户度量技术,为分布式事务提供一种度量方法。ITCAM
for RTT 允许遍历用户事件在业务结构中所经历的路径,它将深入事务在跨越多个系统时采取的每个步骤。在每个步骤中,它还会度量事务的各个组件在总响应时间中所占的比例。与
ITCAM for SOA 类似,ITCAM for RTT 以某种可在企业门户中作为 portlet 查看的形式提供事务报告。
管理服务安全性:Tivoli
Federated Identity Manager
对于现在的组织而言,“更好地工作”就意味着“协同工作”,这为 IT 安全提出了新的挑战。在生态系统中,一项业务既可以是服务提供者,也可以是服务使用者,SOA
已经使企业参与生态系统成为可能,可以实现一个面向 SOA 的价值网络。参与生态系统,将打破企业应用程序间的传统边界。业务事务可以调用某个服务序列,序列中的每个服务都可能是由不同的组织提供的。跨越传统企业边界的事务,会在已编排服务的安全性方面带来更多挑战。
面对业界、消费群体、政府和企业本身强制推行的众多遵从性措施,安全性变得越来越重要了。要使 SOA 取得成功,一个可靠的联合安全标识和管理系统是必不可少的,特别是在企业的边界更多地向基于价值网络的边界系统扩展时更是如此。
IBM Tivoli Federated Identity Manager (ITFIM) 支持标识的集中管理,为用户提供一种以可信的方式访问信息和服务的简便方法。ITFIM
为联合 Web 服务提供基于策略的集成安全性管理。共享信任标识和策略,能简化用户在 SOA 生态系统中的联合站点间导航的过程。ITFIM
支持开放标准和规范,包括 Liberty、SAML、WS-Federation、WS-Security 和 WS-Trust,它们简化了合作伙伴服务的集成工作。
治理和最佳实践:WebSphere
Service Registry and Repository
SOA 治理建立在决策权限和管理框架之上,管理框架能提供说明性指南和最佳实践,针对 SOA 生命周期中各个阶段的活动制订有效的治理方法。如果在本文已经介绍的内容的基础上,更仔细地观察一个服务生命周期,会发现它涵盖了下列具体领域:
- 服务标识
- 服务定义
- 服务部署
- 服务迁移
- 服务版本控制
- 服务所有关系
- 服务监视
- 服务测试
- 服务安全
- 服务策略
每个领域内的活动都需要用某个框架谨慎地治理,该框架为企业向 SOA 的转换制订了一套严格的基于流程的方法。由于软件工具不能用来运行治理,SOA
治理中的许多方面都无法由 IBM 或其他任何供应商的产品提供支持。不过,治理中的某些方面和下列最佳实践有望从某些产品支持的自动化中获益。
WebSphere Service Registry and Repository 就是这样的产品。您可以用它将与服务相关的存储、访问和管理信息的元数据存储起来。它存储的是组织或外部系统中已被使用、计划使用或计划告知服务使用者的服务的信息。WebSphere
Service Registry and Repository 能在服务的生命周期内对该服务进行治理。它能保证采用注册中心和存储库的各种服务之间的互操作性,注册中心和存储库是根据开放标准构建的,通过开放标准,可以在由
WebSphere Service Registry and Repository 准备的、采用其他标准注册中心和存储库的服务间实现集成和信息共享。
SOA 治理不仅仅是服务元数据的准备。正如先前所说,它是对服务生命周期内所有方面的治理,能将人员、流程和技术结合在一起,协调一致地工作。因此,用来实现服务生命周期中各个方面的产品,也能通过集成企业中三大要素,即人员、流程以及工具和技术,帮助简化服务治理。其中的一个例子是用来监视和管理服务的工具:WebSphere
Business Monitor and ITCAM for SOA。IBM 的 Tivoli 和 Rational
品牌提供了一整套工具和产品,它们在服务的设计和开发阶段帮助您进行治理。
图 7 提供了帮助实现 SOA 生命周期各个阶段的工具的可视化概述。
图 7. 产品是如何映射到 SOA 生命周期的各个阶段的
下面介绍在整个生命周期中使用各种工具构建 SOA 服务的过程:
- 使用 Rational RequisitePro 收集并存储需求。
- 使用 WebSphere Business Modeler 建立业务流程模型。
- 来自 Modeler 的输出将被作为服务设计和规范输入 Rational Software Architect。
- 输出还被用在 WebSphere Business Monitor 中,以标识需要在运行时度量和监视的业务度量。
- 使用 Rational Software Architect 设计和指定的服务此后会在 Rational
Application Developer 中实现。
- 来自 Modeler 的输出将作为一个 BPEL,在 WebSphere Integration Developer
中表示业务流程。
- 此后,在 WebSphere Integration Developer 中实现业务流程时将使用已开发和公开的服务。
- 已实现的服务和 J2EE 组件构件被部署到 WebSphere Application Server。
- 在 WebSphere Integration Developer 中编排的业务流程被部署到 WebSphere
Process Server。业务流程将 WebSphere ESB 用于中介和服务路由。
- 使用 WebSphere Business Modeler 管理和监视正在运行的业务流程。
- 服务本身是用 ITCAM for SOA 管理和监视的。
- 服务的安全性是由 Tivoli Federated Identity Manager 管理的。
- 使用 ITCAM for Response Time Tracking,通过 IT 堆栈跟踪分布式端到端事务。
步骤 1 和 2 属于管理阶段。步骤 3 至 7 属于组装阶段。步骤 8 和 9 属于部署阶段,而 10 至
13 则属于管理阶段。
之后由 WebSphere Business Monitor 收集的实时数据会被返回到 WebSphere Business
Modeler 中,以模拟和优化流程,用一个新的建模阶段重新开始整个流程。对服务的增强功能进行建模与模拟,新的建模阶段的输出会被反馈到另一个组装阶段,经过优化的服务也会被再次部署和管理。可以对流程监视期间发现的瓶颈做出改进,从而协助进行优化。
在本文中,您已经对 IBM 跨品牌投资组合套装中的关键工具和产品有所了解,它们能使您的 SOA 系统得到成功执行。您还了解了关于
SOA 的更多信息,它是一个体系结构范例,提供了关于如何有效地将可重复的业务任务标识为服务的原则、最佳实践和指导方针。服务经过设计、实现和编排,可以使某项业务通过以流程为中心的方法进行业务转换。
分为四个阶段的生命周期,是 IBM SOA 基础的重要原则之一,它可以用 MADM(建模、组装、部署和管理)蜂窝状视图表示。MADM
的所有阶段都是由一个全盘治理和最佳实践原则控制的,该原则提供的框架会仔细监视每个阶段的活动。
每个阶段都包含一组令人望而生畏的活动,必须执行这些活动,以使您的 SOA 系统取得成功。对 IBM SOA Foundation
提供的工具进行适当选择和推荐,这对成功实现每个阶段中的活动并取得 SOA 的总体成功是十分关键的。
学习
获得产品和技术
讨论