本文描述了如何使用交互与协作服务 SOA 场景的实现和解决方案模式来解决与该案例研究相关的业务和 IT 挑战。

　　案例研究简介

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

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

　　我们在本红皮书中介绍的案例研究包括以下人员和角色：

　　Sandy Osbourne-Archer，首席技术架构师
　　Edmund Smythe-Barrett，企业架构师
　　Ming Chow，门户开发人员
　　Peggy Smith，财务部帐户经理
　　Andy Brunner，IT 主管

　　帐户开立项目的挑战

　　我们在本红皮书中定义的帐户开立项目挑战与“交互与协作服务”相关。

　　如“案例研究：SOA 帐户开立项目概述，REDP-4376”中所述，挑战包括各销售渠道间的用户界面和体验的不一致性。与许多不同的后端系统的交互是随机的，需要多种用户界面和登录。在有些情况下，JKHLE 仍然依赖基于纸张的业务流程。这些问题增加了处理新帐户的时间和成本，进而可能会对客户满意度和回头率带来负面影响。

　　帐户开立项目体系结构团队已决定对用户界面给予特别关注，这样做的目的是改善客户服务体验，以及减少客户访问各种后端系统时所用的处理时间和资源。执行管理团队还要求能够直观地显示资源和流程是如何帮助实现公司目标的。

　　企业架构师 Edmund Smythe-Barrett 已认识到只有让人员与流程之间实现更好的协作才能促成更全面、更及时的决策。协作方面的改进将带来更好的客户体验和更高的客户满意度。

　　帐户开立业务流程有许多接入点，这些接入点要求用户或工作流中的业务部门 (LOB) 用户进行人工交互操作。在图 1 的业务流程层中定义的各框图中表示了支持帐户开立流程的业务流程，这些流程中许多都需要进行人工交互操作。

　　图 1 帐户开立流程的人工接入点
 
　　帐户开立项目的要求

　　此部分描述了业务分析人员和体系结构团队为应对与交互和协作服务相关的挑战而制定的需求。

　　REQ-01：可从多个渠道和客户端进行访问

　　帐户开立流程需要能通过各种销售渠道供每个市场领域和办公地点的客户访问，并且可供在富客户端和移动客户端操作的联机或脱机模式下访问。

　　REQ-02：通用用户界面和体验

　　为各种销售渠道提供通用用户界面和体验。

　　REQ-03：到不同后端系统的单点登录门户

　　通过提供可访问多个不同后端系统的单点登录 (SSO) 门户，使用户不需要登录到多个系统。这一需求包括身份验证、授权和标识管理。

　　REQ-04：提高门户页面刷新性能

　　提高用于需要刷新的门户页面的 Web 应用程序性能。

　　REQ-05：使用流程门户提供增强的流程

　　支持增强的以人为中心的交互，这些交互需要进行数据输入、法规遵循情况的监管，以及为实现一致的业务结果而进行的流程审批。

　　REQ-06：使用电子表格进行数据输入

　　支持使用电子表格 (e-form) 简化数据输入，并减少数据输入错误。

　　REQ-07：可重用内部和外部服务的门户应用程序

　　支持重用内部和外部服务

　　REQ-08：从动态 Web 仪表板（ dashboard ）中监视流程状态

　　开发一个动态且基于富 Web 的仪表板，通过该仪表板，执行人员将能够查看客户帐户在帐户开立流程中的状态。

　　REQ-09：提供增强的协作

　　在个人与流程之间提供增强的协作能力，以促进更全面、更及时的决策和支持。

　　REQ-10：采用标准和通用中间件

　　采用行业中标准的技术，包括选择一组通用的部署基础结构中间件和工具。

　　将此场景模式应用于案例研究

　　本部分描述如何使用 SOA 中的交互与协助服务场景实现模式来解决与帐户开立项目案例研究相关的业务和 IT 挑战。

　　为了使 JKHLE 采用 SOA 做好准备，企业架构师 Edmund Smythe-Barrett 参加了许多 SOA 培训活动，包括深入学习在 IBM? SOA 基础和 SOA 场景中获得的知识。

　　Edmund 确定团队可以将交互与协作服务 SOA 场景用于帐户开立项目。对于帐户开立流程来说，理想的情况是将与服务和流程进行交互的 Portlet 聚合到统一的门户页面中。门户还可以基于用户角色来识别服务和流程交互的上下文。

　　一次在接受首席技术架构师 Sandy 的检查中，Edmund 介绍了主要功能（请参见图 2）。Sandy 很快就能看到，通过提供可在各销售渠道中使用的通用用户界面，门户基础结构将极大地简化现有环境中各种各样的接口和系统。

　　图 2 交互与协作服务 SOA 场景的主要功能
 
　　Sandy 就对现有组件和系统的支持、与后端系统的交互以及安全性这三个方面提出了一些问题。Edmund 解释说建议的解决方案体系结构将利用经验证的 IBM SOA 参考体系结构和 SOA 场景来解决提到的这些问题。

　　图 3 概要介绍了交互与协作服务 SOA 场景中所用的 SOA 参考体系结构中的关键服务（黑色文本）。Sandy 了解到建议的解决方案主张重用现有组件和系统，而不是一个“拆除和替换”解决方案后终于松了一口气。

　　图 3 交互与协作服务 SOA 场景中所用的 IBM SOA 基础服务
 
　　在下面几个部分中，我们将详细介绍案例研究解决方案元素。这些元素与以下交互与协作服务 SOA 场景实现模式相对应：

　　使用简单的 Portlet 聚合和调用服务
　　使用 AJAX Portlet 的基于富 Web 的应用程序
　　将后端服务与门户集成
　　流程门户
　　托管客户端
　　使用 Web 2.0 实现组织协作

　　安全门户

　　注意：“安全门户”是可在 SOA 安全管理场景中找到的一种解决方案模式。将安全门户基础结构与交互与协作服务 SOA 场景一起使用是极为常见的。

　　使用简单的 Portlet 聚合和调用服务

　　由于各种系统和用户界面并未充分集成，因此不同销售渠道中的客户在帐户开立流程中可能会获得不一致的体验。需要为各销售渠道提供通用用户界面和体验。此外，还需要在 Web 仪表板中查看新帐户在帐户开立流程中的状态。

　　建议的解决方案

　　建议的解决方案包括针对以下 Web 应用程序的基于门户的用户界面增强功能：

　　公共门户

　　公共门户是一种 Web 应用程序接口，可供客户链接到帐户开立流程。

　　帐户开立仪表板

　　帐户开立仪表板可供客户服务代表和管理层监视帐户在帐户开立流程中的状态。

　　Edmund 已确定，更新公共门户以使用 SOA 原则添加 Account History 和 Chat Portlet 将是快速实现投资回报 (ROI) 的一种方式。Account History Portlet 将允许客户更快地获取关于其帐户的信息。Chat Portlet 为客户提供了方便快捷的协作能力，使客户能够快速从客户服务代表 (CSR) 那里获得帮助。Chat Portlet 即时消息 (IM) 协作能力是通过使用 IBM Lotus? Sametime?提供的。

　　Sandy 已决定获得定义帐户开立仪表板需求的权利。Sandy 确定仪表板将包括以下简单的 Portlet：

　　帐户状态 (Account Status)

　　此 Portlet 将列出新开立的帐户在帐户开立流程的每个阶段的存在时间和状态。

　　帐户历史记录 (Account History)

　　此 Portlet 将显示详细的帐户信息。

　　信用报告 (Credit Report)

　　此 Portlet 将显示客户信用信息。

　　热门列表 (Hot List)

　　此 Portlet 将用于标记需要注意的帐户。

　　注意：仪表板指的是类似于汽车仪表板的一种用户界面，旨在以易于读阅、直观的格式显示信息。

　　Sandy 记录了对仪表板的要求，并将设计和组装仪表板的任务分配给门户开发人员 Ming Chow。完成仪表板设计之后，Ming 在设计阶段以方框图的形式向 Sandy 提供了 Portlet 的仪表板布局（请参见图 4）。

　　图 4 使用简单 Portlet 的帐户开立仪表板
 
　　Ming 解释了每个 Portlet 的高级设计。帐户状态 Portlet 可与服务进行交互以从数据库中检索帐户状态，并将相关信息显示到一个可滚动的窗格中。当用户在帐户状态 Portlet 中选择一个帐户时，此信息会显示在信用报告内，然后通过使用 WebSphere Portal Property Broker 功能检索此帐户信息，可立即更新帐户历史记录 Portlet。WebSphere Portal Click to Action 功能用于从帐户状态 Portlet 中的过时列表中选择帐户，然后将所选的帐户添加到热门列表 Portlet 中。

　　开发组织已决定标准化用于在 IBM Rational Application Developer 上组装 Portlet 的工具，并将 IBM WebSphere Portal 和 Lotus Sametime 用于部署基础结构。

　　在后续的版本中，Ming 将使用 IBM WebSphere Portal Dashboard Framework 评估更复杂仪表板的使用，IBM WebSphere Portal Dashboard Framework 添加了特定于仪表板的功能，如强大的警报模块和图表。

　　使用 AJAX Portlet 的基于富 Web 的应用程序

　　在 Ming 开发了基于门户的帐户开立流程的原型之后，他认识到需要为频繁刷新的门户页面提高 Web 应用程序性能。当用户在页面上单击链接或进行一些其他操作时，门户会处理页面上目标 Portlet 的 actionPerformed() 方法和每个 Portlet 的 doView() 方法。门户页面是聚合的，并且结果页面将以 HTML 文档的形式呈现在用户的 Web 浏览器中。本地处理和缓存减少了整页刷新的开销。

　　建议的解决方案

　　Edmund 和 Ming 研究了异步 JavaScript? 和 XML (AJAX) Portlet 的使用对提高门户页面刷新性能的影响。他们确定，团队可以使用 AJAX 在后台处理许多用户交互事件，然后更新门户页面的各个部分，而无需完整的门户刷新周期。此技术将通过增加对单个操作的响应大大改进用户体验，同时显著提高应用程序的总体性能。JavaScript 是一种脚本语言，可用于从 Web 浏览器所用的 XMLHttpRequest 对象中检索数据。

　　使用二级 AJAX 控制器（如 Servlet 或 Web 服务）可以进行更强大的应用程序代码分离。可以使用多种技术来实现 AJAX 服务器目标，包括 Portlet、Portlet WAR 或独立 Servlet WAR中的 Servlet，或者 Web 服务。

　　Edmund 决定将整个 AJAX 控制器设计用于帐户开立流程应用程序，并且让 AJAX 控制器来处理所有基本用户输入操作和分段显示更新。门户 actionPerformed() 方法仅用于页面级转换或处理主要状态更改。Edmund 确认他们将用于部署基础结构的 IBM WebSphere Portal 是支持 AJAX 的。

　　将后端服务与门户集成

　　当前环境中有许多全异的后端系统和部门门户。各个销售渠道在用户界面和体验方面存在许多不一致性。帐户开立流程需要与多个后端系统进行交互，如 SAP?、Siebel? 和 CICS?。当前用于访问这些后端系统的方法要求使用专有技术，这使得更改或重用都很麻烦。

　　Sandy 已将设计基于 SOA 的解决方案的任务分配给了 Edmund，此解决方案将提供通用门户用户界面，允许使用内部和外部服务访问许多全异的后端系统。

　　建议的解决方案

　　建议的用于将全异的后端系统与通用门户用户界面集成的解决方案要求使用多种解决方案模式来创建联合门户。

　　Edmund 对可用于访问 SAP 和类似系统的集成方法进行了分析。Edmund 确定主门户可以通过使用 Web Services for Remote Portlet (WSRP) 访问 SAP 企业门户。WSRP 允许远程 SAP Portlet 并入主门户。

　　注意：WSRP 定义了一组经 OASIS 批准的用户界面和网络协议。WSRP 使门户能够显示远程承载的 Portlet 以及内部门户页面，而无需进行额外的编程。

　　为了在门户中提供 SSO 功能，WSRP 解决方案要求每个门户都知道用户 ID。可以通过使用通用用户存储库满足这一要求，具体做法是，使用 IBM Tivoli? Identity Manager 和 Tivoli Directory Integrator 这样的产品在两个存储库中创建相同的用户 ID，或通过使用 IBM Tivoli Federated Identity Manager 在整个企业中映射标识。

　　Edmund 与 Ming 紧密协作来应用图 5 中所示的虚拟提供者模式。

　　图 5 用于将后端服务与门户集成的虚拟提供者模式
 
　　此解决方案模式包括以下元素：

　　使用代理与虚拟服务提供者后端系统进行通信。

　　使用适配器将服务提供者协议转换为门户服务使用者所需的协议。

　　将代理和适配器封装在 Facade 中。

　　使用适配器将所用的协议转换为门户希望、需要，或者已经在服务描述或契约中指定的协议。

　　将代理和适配器封装到 Facade 中。经过封装的适配器将使用现有的 API 重用通信方法。

　　将 facade 用作服务使用者与后端系统进行通信。

　　注意：还可以使用其他方法来访问 SAP 后端系统，如直接使用 SAP Web 服务、使用 SAP 适配器，以及使用 WebSphere Portal Factory Builder for SAP use of BAPI? 远程函数。

　　Edmund 考虑利用服务集成器模式和远程服务策略模式来进一步增强带有门户的后端集成服务所使用的体系结构。服务集成器模式通过使用服务集成器组件引入了集成和管理层。服务集成器为访问其他冗余服务提供了单一访问点。服务集成器为构建耦合程度更松散、可重新配置的体系结构提供了良好开端。

　　远程服务策略模式创建了一个可重新配置的服务层，不需要进行硬编码更改。这一模式的变体包括能够通过部署服务注册中心动态更改服务提供者。发现和协商流程是在不受门户控制、但可以通过外部服务代理程序访问的注册中心中发生的。

　　Edmund 决定 JKHLE 将实现远程服务策略模式以提供可重新配置的服务层。此模式将通过部署 IBM WebSphere Service Registry and Repository 来实现。

　　最后，Edmund 和 Ming 一致认同 JKHLE 可以利用 ESB 模式在门户和后端服务之间提供中介支持。此模式将通过部署 IBM WebSphere? Enterprise Service Bus 来实现。

　　流程门户

　　Sandy 确定基于门户的帐户开立流程与仪表板应用程序之间需要更紧密的集成。虽然帐户开立仪表板的最初实现可以解决现存的许多难题，但是，若要实现让登录到门户的用户能以个性化的方式与基于后端 BPEL 的帐户开立业务流程进行直接交互，还需要一个门户表示层。

　　注意：流程门户旨在通过业务流程的一致且易于使用的个性化用户界面，在适当的时间将适当的任务呈现给适当的人员。

　　建议的解决方案

　　Edmund 最近知道了如何让流程门户允许来自不同客户端类型（Web 浏览器、富客户端、移动客户端等）的用户以其惯用的方式访问帐户开立流程，而无需为每种访问渠道制定不同的机制。在 JKHLE 环境中，需要支持以下用户的 Web 浏览器客户端：Internet 和内部网用户、与语音响应系统进行交互的仅使用语音服务的用户，以及与客户服务代表协作的用户。

　　Edmund 注意到，需要尽可能少或根本没有人工交互使业务流程尽快向前发展，然而他也知道可能需要一些人工交互。

　　Edmund 使用以下标准来评估帐户开立业务流程对人工交互的需要：

　　法律法规：是否有一些政府规定和法规？

　　缺少规则：是否存在灰色区域，其中没有基于模式的决策流程来生成一致的业务结果？

　　数据输入：以电子方式输入信息时是否需要指导？

　　Edmund 确定帐户开立流程需要人工交互。

　　使用带有电子表格的流程门户可满足定义的需求。Edmund 准备了一份设计文档，用于捕获流程门户的关键需求和高级解决方案体系结构。接下来，Edmund 与 Ming 讨论如何提出设计需求，以及促进低级设计和流程门户组装的开发。

　　Ming 设想使用一种安全门户，客户需要先注册才能使用。

　　注册客户然后登录并在流程门户中使用电子表格 (eForms) 完成帐户应用程序。此功能是通过使用 IBM Lotus Forms 以及 IBM WebSphere Portal，并将这两者与 IBM WebSphere Process Server 集成在一起实现的。在填写了 eForm 并提交之后，业务流程将启动。基于 BPEL 的业务流程根据某些业务规则确定是否需要信用管理器来对应用程序进行评估，如果需要，系统会在信用管理器仪表板中显示审批请求。

　　Ming 决定在低级流程门户设计和组装中使用流程 Portlet。最终得到的设计提供了流程 Portlet 与业务流程的人工任务之间的紧密集成。Task 页面上的其他 Portlet 通过属性代理程序从流程 Portlet 中接收其业务上下文。因此，Task 页面将呈现与手头任务相关的内容。系统将向客户通报关于帐户在整个帐户开立流程中的状态。如果帐户成功经过审核和处理，系统会通过电子邮件向客户通报帐户条款和条件。

　　图 6 显示了流程门户高级解决方案体系结构
 
　　开发组织决定对用于组装以下产品的 Portlet、业务流程和 eForm 的工具进行标准化：IBM Rational Application Developer、IBM Lotus Forms Designer、IBM WebSphere Business Modeler 和 IBM WebSphere Integration Developer。在部署基础结构时，将使用 IBM WebSphere Portal、IBM WebSphere Process Server 和 IBM Lotus Forms。

　　托管客户端

　　销售团队和客户均已报告了现有的帐户开立流程在用户界面和体验方面存在不一致性，这给客户满意度带来了负面影响，并且对发展新客户造成了影响。

　　此外，销售团队已请求获得在连接和断开连接模式下从富客户端访问帐户开立流程应用程序的能力。

　　销售团队希望，在断开连接模式下，可以在企业客户处采用电子方式现场捕获客户信息。当销售团队处于连接模式时，他们可以将客户帐户信息公布到帐户开立流程门户来启动工作流。

　　建议的解决方案

　　Edmund 确定，需要基于定义的需求采用标准和分布式 SOA 组合应用程序体系结构。

　　采用标准

　　Edmund 与开发组织讨论，就采用标准事宜达成一致。JKHLE 团队同意通过以下三项关键计划采用标准：

　　JSR 168 Portlet
　　基于 Eclipse 的 IBM Rational Application Developer 工具
　　IBM WebSphere Portal 和 IBM Lotus Expeditor 中间件基础结构

　　使用 Rational Application Developer 工具组装 JSR 168 Portlet 不仅能获得在通用编程模型上实现标准化所带来的好处，还能减少编写大量代码的需要。这样就可以进行更快速的实现，集中精力进行技能开发。

　　SOA 组合应用程序

　　Edmund 研究并掌握了如何使用 SOA 组合应用程序来满足这些需求。通过实现分布式组合应用程序，用户及相应的富客户端和移动客户端可以获得一个通用的基于门户的用户界面，这样他们就能基于用户角色与相关的服务和内容进行交互，从而提高工作效率。

　　此解决方案是使用 IBM Lotus Expeditor 和 IBM WebSphere Portal 实现的。

　　Lotus Expeditor 包括客户端和服务器，它们用于部署和管理组合应用程序。Expediter 包括基于 Eclipse 的工具包，此工具包可与 IBM Rational Application Developer 结合使用来组装组合应用程序。客户端组合应用程序用户界面可以使用 AWT、Swing、Web 实现，也可以基于门户实现。Expeditor 能够通过使用 OSGI 来远程分发和管理客户端代码。

　　在 Lotus Expeditor 组合应用程序中部署的组件能够与 WebSphere Portal Server 紧密集成。Lotus Expeditor 组件还可以与其他组件进行通信，使用 WSRP，以及在联机连接和断开连接模式下无缝地运行。Lotus Expeditor 桌面客户端为在断开连接模式下在本地运行的组合应用程序提供了 SSO 功能。组合应用程序还可以在连接模式下向远程门户主机发出凭据以实现 SSO。

　　Lotus Expeditor 客户端与服务器之间的通信是使用不同的协议执行的，具体取决于连接模式：

　　在联机连接模式下，客户端可以针对查询和事务使用 Web 服务通过 SOAP over HTTP 与服务器进行通信。

　　在断开连接模式下，应用程序查询存储在本地数据库中，然后使用 DB2?
　　Everyplace? (DB2e) 同步功能与服务器应用程序进行同步。

　　在处于断开连接模式下，将使用 MQ 和 MQ Everyplace (MQe) 将事务以 JMS 消息的形式从客户端发送到服务器。JMS 消息将保存在客户端中，并在客户端下次连接时发送给服务器。

　　在完成事务更新之后，由此产生的更改将同步发送回客户端。

　　Lotus Expeditor 客户端应用程序利用了 Lotus Expeditor 桌面客户端提供的许多 OSGi 服务，如针对本地服务提供者的 Web 服务代理、MQe 和 DB2e。JKHLE 开发人员可以利用 Lotus Expeditor 工具包及相关的组件提供的功能来对现有的门户应用程序进行转换，以构建能够在联机连接模式和断开连接模式下运行门户应用程序的分布式组合应用程序。

　　图 7 中所示的组合应用程序使用了 Lotus Expeditor 提供的几种主要解决方案模式和技术。带有 eForm 的基于通用门户的用户界面在 Expeditor 客户端上运行。客户端组合应用程序代码从远程 Expeditor 服务器分发到 Expeditor 客户端。

　　图 7 使用 Lotus Expeditor 和 WebSphere Portal 的 SOA 组合应用程序
 
　　销售人员可以在企业客户处于断开连接模式下时现场在基于门户的 eForm 中输入帐户信息。帐户数据将存储在本地 JMS 队列中。当销售人员处于连接模式下时，将使用 JMS 将帐户信息发布到流程门户，以启动帐户开立工作流。由于内容呈现是在 Expeditor 客户端上本地执行的，因此销售团队将会非常欣喜地看到门户页面性能方面的改进。当处于连接模式时，组合应用程序可以与指向后端系统的服务进行交互。

　　使用 Web 2.0 实现组织协作

　　Peggy Smith 是财务部帐户经理，主要负责监视帐户开立流程的业务成果。Peggy 是一位明智的业务用户，她正在寻找可在当前业务区中立即可用的自定义门户页面或企业 Mashup 解决方案。

　　Peggy 定义了用于监视帐户状态和业务成果的门户页面所需的信息。接下来，她与 IT 主管 Andy Brunner 联系，请求 Andy 为她开发访问她定义的信息所需的接口。

　　Andy 的团队之前已开发了一些服务，并且已将这些服务公开为可用作接口的代表性状态传输 (REST) 服务。Andy 与他的团队协作，对将访问这些 REST 服务的相应 Portlet 的开发任务进行分配。这样，Peggy 需要做的是搜索企业门户来找出各种预构建的 Portlet、创建页面、使用门户自定义功能组装和连接 Portlet，然后显示这些 Portlet 以创建自定义、个性化用户界面或门户页面。

　　建议的解决方案

　　Andy 将为帐户开立流程服务设计和实现 REST 接口这一任务分配给了 Ming（帐户开立项目的开发负责人）。Ming 确定此解决方案将提供 ATOM Feed，其中包含过时的帐户开立活动的列表，以及用于提供帐户清单和帐户历史记录详细信息的 REST 服务。

　　在创建和维护帐户的热门列表时需要用到使用 REST 和 Portlet 接口的新服务。热门列表可供帐户经理和客户服务代表用于监视帐户流程和业务成果，以获得很高的客户满意度。热门列表是使用 IBM WebSphere Application Server Feature Pack for Web 2.0 作为 ATOM Feed 提供的。

　　Ming 使用 IBM WebSphere Portlet Factory 来开发 Portlet，该 Portlet 可连接到帐户开立流程所使用的现有 SOAP 服务。Ming 向企业门户发布了新服务和 Portlet。

　　Ming 告诉 Andy 和 Peggy，Peggy 将使用的企业门户上已经提供了请求的 REST 接口和相应的 Portlet。

　　Peggy 值得兴奋的是，她现在可以利用门户自定义功能快速构建自定义门户页面来满足她的需求。既然所需的 Portlet 可用，那么她可以使用以下工具自定义门户页面：编辑布局、连接 Portlet 以及其他所见即所得工具。既然 Portlet 在整个 Portlet 调色板中可用，Peggy 就可以创建她的门户页面并将 Portlet 添加到此页面。

　　接下来，她将各个 Portlet 连接在一起，以创建具有以下四个主要区域的自定义门户页面：

　　新开立帐户的过时清单，显示每个帐户在流程中某一阶段的状态。

　　帐户历史记录，使用新创建的帐户历史记录服务的 ATOM Feed 服务接口提供关于帐户的详细信息。

　　对于每个帐户，Peggy 现在可以使用文档 Feed 访问她在 IBM Lotus Quickr(TM) 服务器上为其客户端维护的所有的合法文档。

　　Peggy 可以单击 Feed 直接跳转到文档，而无需查找相关库并搜索文档。

　　信用报告，显示从 JKHLE 和外部信用机构收集的关于帐户持有者的当前和过去的信用信息。

　　热门列表区域，用于标记需要注意的帐户。在最近部署了 IBM Lotus Connections 之后，Peggy 和她的团队可以为他们当前正在处理的每个帐户维护活动，并快速查看需要注意的地方。

　　图 8 概要介绍了以下关键解决方案元素和任务：开发服务和 Portlet、发布到企业门户、部署到基础结构，以及通过 Portlet 使用服务。

　　图 8 使用 Web 2.0 技术的自定义门户
 
　　相关的 SOA 场景实现和解决方案模式

　　这一部分包括的关键 SOA 场景实现和解决方案模式与本红皮书的帐户开立项目要求上下文中的交互与协作服务 SOA 场景相关。

　　安全门户

　　体系结构团队希望确保部署基础结构在保护客户和 JKHLE 业务流程的机密信息方面是安全的。

　　建议的解决方案

　　为实现从流程门户中进行单点登录来与服务和后端系统进行交互，IBM WebSphere Portal 基础结构配置为使用 IBM Tivoli Access Manager 和 IBM Tivoli Directory Server。SSO 解决方案不再需要用户在从门户中访问不同的系统时执行多次登录。Tivoli Access Manager WebSeal 可以验证用户的标识和凭据。当用户与 Portlet（使用服务与后端服务进行通信）进行交互时，凭据将被传递到后端系统。

　　对资源的访问控制是通过在 WebSphere Portal 管理控制台中保护门户页面和 Portal 的安全来实现的。对特定页面和 Portlet 的访问控制可以按用户或组进行配置。可以将门户资源外部化为由 Tivoli Access Manager 集中管理。

　　用户标识管理和预置是通过使用 IBM Tivoli Identity Manager 和 Tivoli Federated Identity Manager 实现的。Tivoli Identity Manager 提供了用于创建新用户帐户的安全、自动化、基于策略的用户管理解决方案。Tivoli Federated Identity Manager 用于映射和管理整个安全域中的标识。

　　注意：“安全门户”是一种解决方案模式，可以在“SOA 安全管理场景”中找到。有关 SOA 安全性的详细信息，请参阅“案例研究：SOA 安全性和管理场景 SOA 场景，REDP-4378”。

　　总结

　　IT 组织已成功实现了帐户开立项目的用户交互和协作增强，可以应对既定的业务挑战和要求。

　　此解决方案允许每个销售渠道中的客户都有一个统一的基于门户的用户界面，通过此界面，他们可以在连接和断开连接模式下，从富客户端和移动客户端中与帐户开立流程中全异的后端系统进行交互。此新的流程门户包括人工任务交互、电子表格、基于角色的门户视图、SSO 以及增强的协作能力。管理团队和客户服务代表能够在帐户开立流程中监视帐户的状态。

　　IT 组织在简化环境方面取得了大的进步。

　　JKHLE 采用了多种应用程序标准，如 JSR 168 Portlet、Web 服务、BPEL 以及其他关键 SOA 技术和原则。JKHLE 已对以下工具和中间件基础结构软件实现了标准化：

　　建模和组装：

　　IBM Rational Application Developer
　　IBM Lotus Expeditor Toolkit
　　IBM WebSphere Portlet Factory
　　IBM WebSphere Portal Dashboard Framework
　　IBM WebSphere Application Server Feature Pack for Web 2.0 – Dojo

　　开发工具包

　　IBM Lotus Forms Designer

　　部署：

　　IBM WebSphere Portal
　　IBM Lotus Expeditor
　　IBM Lotus Forms
　　IBM WebSphere Process Server
　　IBM WebSphere Application Server
　　IBM WebSphere Application Server Feature Pack for Web 2.0
　　IBM Lotus Sametime
　　IBM Lotus Quickr
　　IBM Lotus Connections

　　管理：

　　IBM Tivoli Access Manager
　　IBM Tivoli Identity Manager
　　IBM Tivoli Federated Identity Manager