在这个模式中，模式应用程序通过应用了多种处理规则的中介与后端应用程序交互。在 CPP 解决方案中，这些规则涉及过滤规则、安全性验证和请求路由功能的应用，以及将来由业务伙伴和 CWC 达成一致意见的业务协议的验证。尽管试验项目集中在仅将应用程序服务公开给某个伙伴组织，但是基础结构必须是可扩展的，以从长远考虑满足所有 CWC 当前和将来的业务伙伴。

此外，后端应用程序是由公开的 Web 服务通过基于开放标准的不断发展的中间件技术访问的，预计该技术可以提供下一代 Web 服务基础结构。该中间层使公开的业务流程与旧应用程序分开，并帮助保护银行的信息资产。该模型还在依赖于后端应用程序的其它业务流程中提供连续性，同时提供了银行探索做生意的其它渠道所需的灵活性。另请参阅图 1。

图 1. 受管公共流程应用程序模式

帮助选择受管公共流程的主要业务和 IT 驱动因素有：

• 提高组织效率。
• 减少业务事件的等待时间。
• 支持与业务伙伴的结构化交换。
• 支持伙伴与应用程序之间相互实时访问。
• 支持伙伴与业务服务之间相互实时访问。
• 利用现有的技能。
• 利用以前的投资。
• 后端应用程序集成。
• 使应用程序复杂性降到最低。
• 使企业复杂性降到最低。
• 避免伙伴托管的基础结构。
• 减少伙伴对特定应用程序的依赖。
• 减少伙伴对特定业务协议的依赖。

   图 2 说明了在 CWC 的解决方案中实现的三个逻辑层。如果我们考虑到将来的需求，那么将看到流程规则（Processes Rule）层更细粒度地分离成私有（Private）流程和公共（Public）流程。

图 2. 基本体系结构概述

逻辑解决方案体系结构

正如前面所描述的那样，该解决方案的组件已经分布于多种公共流程和后端应用程序，以满足短期业务目标所驱动的试验程序的直接需求。在该模型中，至少有机会在 CWC 自己的 IT 基础结构内部署的私有中间层组件中利用一些在公共的 CWC 对业务伙伴和 CWC 对最终客户流程中使用的 Web 服务技术。

现在，在我们深入研究解决方案体系结构之前，先对在设计中使用的 IBM 产品作一个小小的说明。我们提到这些产品的目的只是为了说明该解决方案实际上是如何构建的。我们将建议如何设计整体解决方案，以允许您决定使用将帮助您产生这一整体解决方案的实际产品。

位于该解决方案的公共层和私有层之间的是同时运行 WebSphere Business Connection 和 WebSphere Web Services Gateway 软件（它充当请求和数据流过的网关）的 IBM WebSphere Application Server。

该设计提供了一个中央控制点，通过将支持消息路由、负载均衡、请求和响应测量、日志记录和安全性措施的代理安插在流程中，来公开业务服务。该网关组件还为实现定制过滤器（具有这一层中其它系统管理行为）提供了一个关键的部署节点，以及为要在调用业务服务（运行在更传统的 J2EE 和 CICS 环境中）前后调用的 Web 服务提供许多操作支持。

代表应用程序的核心实现的 Java 组件位于在 CWC 的防火墙内部署的 WebSphere Application Server 的第二层，并且支持与后端业务应用程序和系统进程进行平台本地交互。将接口作为 Web 服务在内部公开，可以使 CWC 达到资产重用目的，从而使将来能够更容易地用这些服务做新的或其它事情。通过利用和扩展构建到 WebSphere 和 Web 服务网关内部的功能，CWC 在 SOAP 层对消息交换启用了数字签名和加密支持，使得它们的解决方案与传输无关。除了允许内部应用程序的功能作为 Web 服务对外公开以外，Web 服务网关允许内部应用程序访问由外部伙伴提供的 Web 服务，同时仍可利用公共的基础结构服务集。强调 Web 服务调用的这种双向支持对于说明已定义的体系结构如何允许 CWC 满足他们规定的所有要求是很重要的。

对于利用这种 Web 服务基础结构的未来的应用程序，CWC 打算公开业务流程，这些流程是通过在定制应用程序、打包解决方案和基于 CICS 的主机应用程序中使用非 Java 技术构建的。到那时，这种体系结构将更接近于“受管公共和私有流程”应用程序模式的真实实现。私有流程将提供各种内部服务的基本设计，并将当前中间层集成点扩展到全面的企业应用程序集成模型中。然而，目前，中间层主要用作由基于 CICS 的应用程序公开的定制应用程序组件的抽象，通常是点对点集成。这个中心的不断发展将使这些业务流程组件的实现在企业中能够重用并且保持一致，从而达到这一新的战略性 IT 基础结构的主要目标。另请参阅图 3。

图 3. 逻辑应用程序体系结构

Web 服务的适用性

在本系列的第二篇文章中，我们介绍了一条通用规则，该规则是“每当（在业务之间、在应用程序之间以及在解决方案的逻辑组件之间等等）存在必须交换信息的边界时，Web 服务将影响业务集成和应用程序模式的实现。” 我们在 CWC Bank 所提议的体系结构例子中看到，解决方案的公共组件和由内部应用程序公开的接口都利用 Web 服务技术（请参阅参考资料）。

后端应用程序服务主要构建于专利技术和本机协议之上，这些服务在内部作为 Web 服务公开，通过应用了其它 Web 服务构造的中间层网关代理，最后向外提供给业务伙伴和客户。使用本系列的第 1 专栏中展示的术语集（另请参阅图 4 和 5 ），由于 WSDL、SOAP 和 HTTP 分别用作描述、消息传递和传输协议，所以我们将对在外部公开为 XML Web 服务的 Web 服务进行分类。这样做是为了使得外部和内部流程之间具有最佳级别的互操作性。然而，内部服务和网关之间的边界使用各种协议进行通信。这些被作为 EJB 组件开发的公开的 Java 组件利用 MQSeries 进行异步，确保大型机上 CICS 客户机应用程序之间的传递，但在某些情况下，后端平台中的其它打包应用程序变成使用 SOAP/HTTP。通过使用我们建立的术语，这些内部服务将被视为企业 Web 服务。

图 4. 面向服务的应用程序协议

图 5. Web 服务协议域

XML Web 服务主要为了确保不同种类的运行时和开发环境（例如 Microsoft .NET 和 J2EE）之间的互操作性。另一方面，实现企业 Web 服务是为了利用应用程序之间松散耦合的集成点。SOAP 和 HTTP 被人们广泛接受，并且是能在各种环境下都被支持的可互操作的消息传递和传输协议；它们还已经被标准化或者在被标准化。这使它们可以理想地用于互操作性目的。JMS 和 RMI 只被 Java 平台所支持，而且它们也并不是确保互操作性的最佳协议，但它们确实为集成在 J2EE 环境下运行的应用程序形成了一个很好的框架。考虑到这一点以及继续提供可靠的消息传递的需要，Integration Hub 保留了基于 MQSeries 的、与大型机上 CICS 应用程序的通信。

吸取的经验

这个倡议涉及到非常广泛的企业范围内所进行的开发并且是一个十分具有挑战性的新兴技术倡议。IT 需求非常强烈，足以迫使 CWC 朝 IT 基础结构开发方向跳跃式发展，同时复制两个利用这个平台的业务就绪的试验应用程序。这缓解了多重风险和新平台的不确定因素，同时显示了这些技术方向的商业直接利益和适用性。这里要记住的一个关键点是：具有有效的业务驱动因素以保证这样的主要倡议与商业价值重新紧密相关，这是最根本的。

在构建该方案的基础体系结构和试验性实现时，我们获得了几个关于所涉及的技术、标准和业务概念的重要经验：

现有标准提供了一些机制来支持该方案所需的异步操作类型，但异步操作还不是目前标准的主要组成部分。Web 服务的业务流程执行语言（Business Process Execution Language for Web Service，BPEL4WS）是迈向所需支持的一步，但还有许多工作要做。
业界工具对于能够有效地再利用现有应用程序是重要的（例如，从 Java Connector Architecture 资源适配器自动生成 WSDL 描述）。
这里仍然没有给出 Web 服务的互操作性。我们将在本系列未来的专栏文章中解决大量待解决的问题（特别是着重讨论互操作性问题以及一些有关如何解决这些问题的最佳实践建议）。