级别： 初级 Holt Adams (rhadams@us.ibm.com), IT 设计师, IBM jStart
Dan Gisolfi (gisolfi@us.ibm.com), 客户经理兼解决方案设计师, IBM jStart
James Snell (jasnell@us.ibm.com), 设计师兼策略专家, IBM Software Group
Raghu Varadan (rvaradan@us.ibm.com), 顾问 IT 设计师, IBM Global Services
2003 年 6 月 01 日 在本最佳实践系列所涉及的各种方案中，作者们一直都在试图说明客户正如何利用 Web 服务技术来提供对现有 IT 应用程序基础结构的第三方访问。在目前为止所讨论的大多数解决方案中，重点一直是在阐述大粒度的应用程序服务，从而将基于标准的技术和基础结构用于向外部业务伙伴提供服务。这里，他们讨论了由一家全球金融服务机构定义的企业级 IT 策略，它描述了基于新兴 Web 服务技术的应用程序开发和集成平台。
在本系列的头两篇文章中，我们介绍了 IBM 电子商务模式中的语义框架和一些实用技术，
提出了一个关于 Web 服务为什么可能在电子商务应用程序中发挥作用以及在哪里发挥作用的分析方法（请参阅
参考资料）。
我们的方法一直着眼于由实际的 IBM 客户向我们提出的各种业务问题，以及通过使用 IBM 电子商务模式提供给我们的语义和组织框架来探究已开发的解决这些问题的解决方案。在这篇专栏文章中，我们将关注全球金融服务业的客户，
他希望开发一个构建于 Web 服务基础结构之上的框架，以使内部业务流程能够提供给银行客户和第三方业务伙伴。所讨论的试验项目重点是利用这种框架，并作为参考实现，
以允许与伙伴拥有和管理的业务应用程序进行平稳集成，同时使对来自多个系统的应用程序接口的直接用户干预达到最小。
对于许多正在寻求应用 Web 服务的开发人员和应用程序架构设计师来说，主要挑战是：
目前几乎没有提供关于如何在真实的业务方案中最佳地应用诸如 SOAP、WSDL 和 WS-Security 之类新技术的指导。
本文的目的就是举一个实际的业务示例，按照前几篇文章所列出的概念对这个示例进行分析；并在分析过程中得出一些关于这种新技术的承诺如何和使用这种新技术来解决实际问题的现实相一致的经验教训。
具体来说，我们将针对下面一组问题来分析该示例方案：
- 解决方案的业务目标是什么？
- 解决方案实现哪种通用的电子商务模式？
-
应用程序的逻辑体系结构是什么？
- 在构建应用程序的过程中，如何使用 Web 服务技术？在哪里使用以及为什么使用？
- 在应用程序中使用 Web 服务得到了哪些具体好处？
- 对于所用的技术和方法，我们学到了什么（正面的和反面的）？
另外，需要提一下，我们将这一系列文章放在一起的目的之一是使用实际的客户方案，IBM Emerging Technologies jStart
团队和 IBM Global Services 团队一起实现了 Web 服务或类似于 Web 服务的应用程序。
在本文和后续的专栏文章中给出的分析是直接基于这些方案的。然而，为了保护 IBM 与客户之间关系的机密性和完好性，我们使用了虚构的公司名。但是，在这里要记住的关键一点是：这些项目是真实的，而不是基于假设的练习。我们将获得的最佳实践是基于设法使工作完成的真实情况，而不是基于理论或我们想当然的做法。
业务目标
Country-Wide Chartered Bank（CWC Bank）
是一家全球性银行机构，它在零售和批发银行业务领域提供服务，它直接或通过业务伙伴的分支机构网络，向最终消费者提供以下各方面的金融产品：储蓄、存款和资产帐户；投资管理和退休储蓄计划；信用卡和消费者贷款，
该银行一直在应用传统信息技术和手工流程相结合的方法来实现这些任务。
由于受到强大的业务和 IT 驱动因素驱使，将构建一个新的基于标准的信息传递和应用程序集成平台，供面向内部和消费者的信息系统使用，CWC Bank 决定应该开始研究新兴 Web 服务技术的应用程序了。
他们需要构建的企业规模的基础结构有一些非常严格的要求，这些要求对于银行的业务需求来说是关键，
并且受到各种业务种类的推动。
目前的这套 CWC Bank 应用程序是跨传统平台构建的，
它们涵盖了基于大型机的 CICS 应用程序、基于 MQ Series 的中间件、混合了 Oracle 和 Informix 数据库的异构 RDBMS 环境
以及广泛的客户机／服务器和 Web 应用程序组合。如全异的和异构的各种平台和应用程序开发环境所反映的那样，
开发和操作上的低效率一直在大大增加维护和扩展现有环境的成本。CWC Bank 的 IT 部门面临着这样一个挑战任务：通过各行业和供应商普遍采用的标准技术和平台、高度的平台独立性以及更方便地实现商家对商家交互的模型，来提供一个更灵活有效的方法。
另外，还必须将该基础结构设计成 CWC Bank 将来可能会选择实现的第三方产品的评估中心。
为了回应这个挑战，CWC 的 IT 部门决定首次展示两个单独的试验项目，一个称为定制促销程序（Custom Promotions Program，CPP），
其目的是允许客户查询可收回的促销余额、根据客户的资产组合查询合法的促销买卖、查询管理客户偿还喜好以及查询事务跟踪；
另一个应用程序向他们的业务伙伴提供对应用程序功能的访问，他们能够使用这些应用程序功能并将其作为信息传递系统的一部分提供给他们的最终消费者和业务流程。
CPP 应用程序是通过使用一个基于因特网浏览器的界面结合智能卡读卡器实现的，它利用了 CWC Bank 的标准化认证和授权功能（由组织的安全性服务部门提供）。该银行的客户可以通过 CWC 门户网站或者通过由 CWC 的业务伙伴管理的第三方伙伴网站访问该应用程序。这些第三方应用程序利用了 CWC 试验项目的下半部分来直接与 CWC 的 CPP 应用程序集成，以向最终用户提供对定制资产和偿还管理功能的完全访问，
同时允许伙伴扩展这些功能并将它们集成到其自己的业务流程中。
整套非功能需求强调了供应商支持和平台独立性、与现有安全性服务基础结构的无缝集成、
在 CWC Bank 中向内部主机到主机集成平台的可扩展性、在无需更改现有 CWC 网络的情况下对基础结构级安全性实现的支持、
使基础结构能够在功能和垂直性方面都可伸缩，以传递到许许多多类第三方业务伙伴，
还提供了排除低级编程活动以公开将来的 Web 服务的模型。其它关键目标包括了 CWC Bank 将流程延伸到客户以及第三方的综合能力，
与他们过去使用高度多样化且非集成的基础结构能够进行的管理相比，这种综合能力带来的是更快的速度和更高的效率。
选择适用的电子商务和应用程序模式
既然我们对要求完成什么任务有了一些了解，那我们就可以开始分析应该如何提供解决方案了。在下面的
表 1
中（您应从这个专栏的前几篇专栏文章中熟识），我们将业务要求映射到特定的电子商务模式。我们使用这张表来帮助确定特定的电子商务模式，该模式有助于我们确定我们需要构建的解决方案的基本组件。在这张表中，我们突出显示了最适用于我们的方案的需求。
表 1. 选择电子商务模式
| 业务和 IT 驱动因素 | 业务模式 | 集成模式 | |
自助服务
|
协作
|
信息聚集
|
扩展企业
|
访问集成
|
应用程序集成
| |
最终用户和客户需要直接与业务流程和／或数据进行交互。
|
X
|
X
|
X
| - |
X
| - | | 业务流程需要与现有的业务系统和信息进行集成。 | X | - | - | - | - | X | |
业务流程需要与存在于伙伴组织的流程和信息进行集成。
| - | - | - |
X
| - |
X
| | 业务活动需要聚集、组织并展示来自于组织内外的各种来源的信息。 | - | - | X | - | X | X | |
必须能以一种公共的、一致的并且简化的方式通过多个传输通道来访问业务流程。
|
X
| - | - | - |
X
| - | | 业务活动要求并鼓励在其参与者之间进行协作并共享信息。 | - | X | - | - | - | - |
复合电子商务模式：自助服务 + 扩展企业
在将模式分层的资产模型应用到 CWC Bank 规定的业务目标过程中，
我们认识到对于所规定的要求应用了模式混合。
在实际方案中，这是一个非常典型的案例，它进一步转变成复杂的解决方案体系结构。
在这个特例中，短期目标与组合的自助服务和扩展企业业务模式的特征相符；
因为期望 CWC 门户网站将功能直接提供给客户，所以使用自助服务业务模式。
因为期望业务伙伴通过编程来集成这些功能并进行扩展，所以使用扩展企业业务模式。
另外，要是不希望业务伙伴提供任何其它业务功能并按原样使用公开的 CWC 应用程序功能，
该模式将仅被归类为具有多种应用的访问集成模式来支持实现的自助服务模式。
除了 CPP 应用程序的直接目标外，CWC Bank 还在指望将这种基于 Web 服务的基础结构用于内部应用程序和主机到主机的集成，当这些组件被构建到解决方案中时，这将使信息聚集模式成为整个解决方案的组成部分。
这个事实强调了任何应用程序体系结构的主要最佳实践，而不管它是不是构建在 Web 服务技术之上：
始终知道为了满足将来的需要和非预期使用的规则所必需的任何体系结构和／或设计决策是至关重要的。
过于频繁地将业务应用程序构建成单片思洛，就无法调整它们来满足新的使用模式或业务目标。
然而，在这个方案中，我们看到一个截然不同且至关重要的要求，就是解决方案要灵活且适应性强。
从项目的开始，就应该把对这个目标的支持设计到系统中。
应用程序模式：受管公共流程
整体解决方案用于最终消费者直接访问 CWC 门户网站以及业务伙伴通过其自己的站点扩展这些服务，
它被设计成以部署在 CWC IT 基础结构内的大粒度应用程序服务的形式提供现有功能和新功能。
在详尽地分析可适用的应用程序模式之后，扩展企业管理的公共流程（Extended Enterprise Managed Public Process）模式满足给定的解决方案策略和整个业务目标。该解决方案明确使用三个主要的逻辑层：伙伴（Partner）、公共流程规则（Public Process Rule）和后端应用程序（Backend Application）。
在这个模式中，模式应用程序通过应用了多种处理规则的中介与后端应用程序交互。
在 CPP 解决方案中，这些规则涉及过滤规则、安全性验证和请求路由功能的应用，
以及将来由业务伙伴和 CWC 达成一致意见的业务协议的验证。
尽管试验项目集中在仅将应用程序服务公开给某个伙伴组织，但是基础结构必须是可扩展的，
以从长远考虑满足所有 CWC 当前和将来的业务伙伴。
此外，后端应用程序是由公开的 Web 服务通过基于开放标准的不断发展的中间件技术访问的，
预计该技术可以提供下一代 Web 服务基础结构。
该中间层使公开的业务流程与旧应用程序分开，并帮助保护银行的信息资产。
该模型还在依赖于后端应用程序的其它业务流程中提供连续性，
同时提供了银行探索做生意的其它渠道所需的灵活性。另请参阅
图 1。
帮助选择受管公共流程的主要业务和 IT 驱动因素有：
- 提高组织效率。
- 减少业务事件的等待时间。
- 支持与业务伙伴的结构化交换。
- 支持伙伴与应用程序之间相互实时访问。
- 支持伙伴与业务服务之间相互实时访问。
- 利用现有的技能。
- 利用以前的投资。
- 后端应用程序集成。
- 使应用程序复杂性降到最低。
- 使企业复杂性降到最低。
- 避免伙伴托管的基础结构。
- 减少伙伴对特定应用程序的依赖。
- 减少伙伴对特定业务协议的依赖。
图 2
说明了在 CWC 的解决方案中实现的三个逻辑层。如果我们考虑到将来的需求，
那么将看到流程规则（Processes Rule）层更细粒度地分离成私有（Private）流程和公共（Public）流程。
逻辑解决方案体系结构
正如前面所描述的那样，
该解决方案的组件已经分布于多种公共流程和后端应用程序，以满足短期业务目标所驱动的试验程序的直接需求。
在该模型中，至少有机会在 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。
Web 服务的适用性
在本系列的第二篇文章中，我们介绍了一条通用规则，该规则是“每当（在业务之间、在应用程序之间以及在解决方案的逻辑组件之间等等）存在必须交换信息的边界时，Web 服务将影响业务集成和应用程序模式的实现。”
我们在 CWC Bank 所提议的体系结构例子中看到，
解决方案的公共组件和由内部应用程序公开的接口都利用 Web 服务技术（请参阅
参考资料）。
后端应用程序服务主要构建于专利技术和本机协议之上，
这些服务在内部作为 Web 服务公开，通过应用了其它 Web 服务构造的中间层网关代理，最后向外提供给业务伙伴和客户。
使用本系列的第 1 专栏中展示的术语集（另请参阅图
4和
5
），由于 WSDL、SOAP 和 HTTP 分别用作描述、消息传递和传输协议，所以我们将对在外部公开为 XML Web 服务的 Web 服务进行分类。这样做是为了使得外部和内部流程之间具有最佳级别的互操作性。
然而，内部服务和网关之间的边界使用各种协议进行通信。
这些被作为 EJB 组件开发的公开的 Java 组件利用 MQSeries 进行异步，
确保大型机上 CICS 客户机应用程序之间的传递，但在某些情况下，后端平台中的其它打包应用程序变成使用 SOAP/HTTP。
通过使用我们建立的术语，这些内部服务将被视为企业 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 服务的互操作性。我们将在本系列未来的专栏文章中解决大量待解决的问题
（特别是着重讨论互操作性问题以及一些有关如何解决这些问题的最佳实践建议）。
参考资料
作者简介  | | | Holt Adams 是支持 IBM 的 jStart 计划的高级 IT 设计师，他与客户和业务伙伴一起工作，帮助他们采用新兴技术（如 Web 服务）。1982 年从 University of Tennessee 获得电子工程学位毕业后，他加入了 IBM 位于北卡罗来纳州的 Research Triangle Park。他在以下这些方面有经验：通信和网络产品的软硬件开发、移动和无线解决方案的技术市场营销以及基于因特网的解决方案的体系结构和集成。在过去两年间，他一直致力于把 Web 服务提升为 IBM 的战略性集成技术，起初是和客户一起开发概念的证据，最近在为生产环境开发解决方案。您可以通过
rhadams@us.ibm.com与 Holt 联系。
|
| | | Dan Gisolfi 是 IBM 的 jStart emerging technologies 小组的客户经理兼解决方案设计师。他从事客户约定的商业和技术两方面的工作。他有很多头衔，从业务开发经理和宣传者到解决方案设计师和合同谈判代表。Dan 目前致力于通过实际的商业解决方案来帮助 IBM 推进 Web 服务的采用。您可以通过
gisolfi@us.ibm.com与 Dan 联系。
|
| | | James Snell 是 IBM 的 software group 中的 emerging Internet technologies 小组的一名设计师兼策略专家，在这个小组中，他在 Web 服务技术不断发展的体系结构和实现中起到了积极的作用。他是
Programming Web Services with SOAP（O'Reilly 和 Associates 出版）一书的合著者。您可以通过
jasnell@us.ibm.com与 James 联系。
|
| | | Raghu Varadan 是 IBM Global Services 的 Architecture Center of Excellence 的顾问 IT 设计师。在软件咨询、阐述技术的广泛业务应用、策略技术规划以及系统体系结构方面，他有超过 14 年的经验。他在开发大型的、复杂的、企业范围的体系结构、面向对象和客户机-服务器体系结构和开发方面有丰富的经验，并且曾参与软件开发的整个生命周期的业务和技术两方面的工作。您可以通过
rvaradan@us.ibm.com与 Raghu 联系。
|
对本文的评价
| 
