面向服务的体系结构（Service-Oriented Architecture，SOA）正逐渐被广泛接受，但整个行业在方法、经验水平以及对如何将 SOA 应用到企业 IT 环境的理解之间存在较大的差异。本文将探索如何使用基于 SOA 的技术将关键业务功能作为业务服务公开，从而扩大遗留平台（如大型机）的 IT 投资回报。

　　面向服务的体系结构（SOA）是存在时间已超过 20 年但一直未得到广泛应用的技术之一。但由于 Web 服务的出现以及随后被广泛接纳，SOA 终于迎来了自己的“春天”。就开发体系结构方面而言，SOA 是将来的一个发展趋势。SOA 将数据和信息作为服务公开的模型使其成为了一个非常强大的概念，与当前的应用程序构建块范例截然不同。当与广受追捧的普及计算（ubiquitous computing） 或效用计算（utility computing） 模型（在此模型中，可以像在手电筒中添置和拆卸电池一样添加或删除处理容量）结合使用时，SOA 可提供巨大的大型企业计算潜能。

　　SOA 中一个正在逐渐受到广泛关注的领域是遗留应用程序的生命周期增长。本文说明了一些很有帮助的方法，以便通过 SOA 从遗留应用程序和大型机应用程序获得更大的投资回报（ROI）。大型机技术是一项非常成熟的技术，在本文中，您将了解各种方法，以通过为这些大型机应用程序提供 SOA 支持来延长其生命周期，从而便于信息技术（IT）组织继续利用大型机投资。

　　向面向服务的世界进发

　　SOA 的基本思想是将企业或组织封装在服务 组成的构造中，其中从数据到逻辑和业务功能都成为了某种类型的服务。

　　例如，可以使用一个采取以下方式公开功能的服务：传入一个邮政编码后，服务将返回关联的地区名称。尽管这并不特别复杂，但更为复杂的服务可能会涉及多个后端数据源、业务流程等等。

　　这些事务间的粘合剂主要是 Web 服务，Web 服务通常在超文本传输协议（HTTP）的基础上使用简单对象访问协议（SOAP）。我之所以用“主要”一词，是因为还可以通过其他方式连接到使用 IBM WebSphere? MQ 等技术的 SOA 总线。

　　大型机是否已成为历史？

　　大部分企业级组织都拥有大型机。这些大型机要么用于数据中心，要么仍然在执行核心的业务关键型功能。而且不难发现，这些大型机内应用的基础技术的存在时间均已超过了 15 年。

　　COBOL 就是其中之一，目前仍是企业大型机环境日常操作中很重要的一部分。事实上，Gartner Group 于 1999 年指出，仍然存在超过 2000 亿行 COBOL 代码。来自 Gartner 的最新消息表明，从那时起，COBOL 业务应用程序的数量并未减少。TSG Inc. 的总裁 Bill Ulrich 指出，新 COBOL 代码的数量以每年 5 百万行的速度递增，与 15 年前相比，IBM 的大型机事业部销售的成套产品也多了很多。显然，大型机尚未成为历史。由于在过去 20 年到 25 年间在大型机和遗留系统方面进行了这么多投资，将其全部抛开，使用更为商品化的平台进行替换，这种做法并不一定合理。

　　了解面临的挑战

　　IT 组织在大型机领域面临的挑战是复杂的、多方面的。首先，这些遗留平台上的很多应用程序都是多年前编写的，最初的开发人员已无从寻找。其次，应用程序通常非常复杂，也非常关键，自然使得很多组织在使其退役或移植到中型平台方面都感到非常紧张。

　　这个挑战是非常关键的。当将新的应用程序和功能添加到核心大型机之外的其他平台体系结构时，可能会给 IT 组织内部带来不和谐的因素；此类其他平台包括 Microsoft? .NET? 或 Java? 2 Platform, Enterprise Edition（J2EE）以及基于 Java Platform, Enterprise Edition（Java EE）的各种平台等。此类设计通常要求具有复杂的互操作机制，以将大型机连接到中型平台，而这会导致结构化的企业体系结构变得“支离破碎”。

　　再次，在 Internet 驱动的计算模型方面也有挑战，即 Internet 站点和门户要求访问存储在后端系统的数据的情况。此处的问题是，将这些后端遗留系统直接连接到 Internet 并不是一个很好的做法。大型机（以及其中的应用程序）设计为处理长时间运行的任务，通常支持数百或五千以下的并发用户负载。他们并未设计为同时以实时的方式支持数十、数百甚至数百万用户。

　　解决挑战

　　在以后几年，随着整个行业开始广泛采用 SOA，IT 架构师将开始购买业务流程包，而不是应用程序包。他们会随后将这些业务流程包作为现有业务服务聚合体的一部分进行部署，以便连接到企业服务总线（ESB），并与各个组成应用程序集成。知道了这一点后，IT 架构师应该如何使用面向服务的方法来帮助解决这些挑战呢？

　　首先，必须在大型机上（或在遗留环境中）对应用程序进行概念化，不是将其作为应用程序，而是作为服务的一个“部分”。必须从理念上将应用程序与基础平台体系结构（在这种情况下为大型机）分离开来。SOA 改变了应用程序的概念，使其成为了一组可通过服务接口访问的逻辑功能组。本文重点讨论各种可继续从大型机平台获得积极投资回报（ROI）的方法，从而探索上文列出的 IT 组织面临的主要挑战的解决方案。

　　大型机的 SOA 策略

　　可以使用 SOA 作为大型机应用程序的包装，从而使得这些遗留应用程序成为 ESB 的一部分。对架构师而言，如果能够以普遍的方式提供企业服务编录，以便可以在此基础上着手开发新的应用程序和业务功能，则再理想不过了；只需要简单地将新应用程序加入 ESB，然后就可以重用已公开的服务。

　　之所以听起来非常简单，是因为事实真的如此。如果您将本文中讨论的概念性大型机视为 IBM 系列产品之一（例如 IBM OS/390? 或 zSeries? 计算机），您的工作就非常轻松了。IBM 提供大量供开发人员使用的工具和工作台，SOA 架构师和设计人员可通过其采用拖放和 Point-and-Click 建模的方式连接到遗留服务。

　　例如，WebSphere Studio Enterprise Developer 等 IBM 产品允许开发人员或设计人员通过拖入遗留大型机环境公开的服务来设计其应用程序。此设计成果的运行时视图将提供服务总线构造（即 ESB），其中包括总线本身、代理以及中间的消息传递层。

　　此外，通过混和使用 IBM WebSphere Host Access Transformation Services（HATS）、SOAP for Customer Information Control System（CICS?）甚至 WebSphere Information Integrator 等 IBM 技术，可以将大型机的应用程序适配器和接口公开给其他也连接到共用 ESB 的任何对象（甚至是 Microsoft .NET 应用程序）。

　　这样，所开发的新应用程序就可以直接调用已经存在的服务，Java 开发人员就不需要知道所请求的服务驻留在大型机平台上。这是完全透明的。对于有些细节，这可能有些夸张，但不要误会——如果考虑到大型机的复杂性、成本以及状态，使用这些工具为遗留应用程序提供“新生”的确相当简单。

　　拖放功能

　　您可能已经使用过集成开发环境（Integrated Development Environment，IDE）的拖放功能，如 IBM Rational? Application Developer for WebSphere Software 中的此类功能。如果是这样，您可能已经注意到开发人员（或业务分析人员）在 IDE 中拖动组件来构建应用程序的基本内容的方便性。

　　对于支持 SOA 的环境，也提供了这样的功能。可以拖动相应的服务（位于目录或服务列表中），然后将此服务连接到其他应用程序流。随后，通过手动编码或使用 IDE 工具的“所见即所得”功能，可以将这些服务放入从目录列表中拖出的工作流中，然后将其连接到端到端业务流程中。

　　示例：面向 Internet 的门户应用程序

　　假定您有一个面向 Internet 的应用程序，允许客户订购各种美容产品。通过门户应用程序，客户可以从目录中选择产品，然后下订单。（请参阅图 1。）

　　图 1. 使用来自大型机的服务的示例门户应用程序
 
　　应用程序的订购模块包括来自大型机的客户详细信息。不过，由于基于大型机的 COBOL 应用程序的遗留配置非常复杂或者在设计上存在缺陷，大型机仅能存储邮政编码，而不能存储对应的地区。利用企业开发 IDE，您可以通过从 ESB 服务存储库拖放一个服务来创建门户应用程序的 Customer Suburb，并创建检索客户详细信息的流程，在此流程中使用 Postal Code 字段作为 IBM eServer? pSeries? 中型应用程序（承载邮政编码到地区查询服务）的输入参数。由于邮政编码到地区查询服务与公开的大型机应用程序的服务位于同一 ESB，因此将所有这些服务分组到一起来形状单个流程就再简单不过了。

　　不过，这个简单示例的一个缺陷是，如果该面向 Internet 的门户应用程序极为受欢迎，则可能在任何时候都有数万在线并发用户。为什么这是一个问题呢？因为此处要考虑的主要问题是，使用大型机公开的服务与与部署到 Internet 的应用程序之间的负载级差以及这个负载级差如何影响大型机。

　　正如我前面提到的，大型机并未设计为（或并不习惯）处理大量实时用户请求。每秒 20,000 到 50,000 的实时在线请求会导致典型的大型机环境崩溃。不过，通过将大型机环境封装在 SOA 层中，可以使用 WebSphere Process Server 等 ESB 提供的一些缓存和预读功能，从而将大型机隔离开来。图 2 重点说明了此类设置在典型环境中的情况。

　　图 2. 使用 ESB 缓存扩展大型机的可伸缩性
 
　　策略：通过 ESB 缓存数据

　　此策略的工作方式是这样的：可以通过 ESB 使某些数据（静态数据或变化不频繁的数据）变为持久性数据或可缓存数据。连接到 ESB 服务层的支持 SOA 的应用程序（如门户）可以随后以所需的性能进行事务处理，而不会使大型机后端崩溃。

　　例如，假定大型机上驻留了一个客户记录数据库。在理论上，此数据库将在 ESB 层进行缓存，从而不必每次直接从大型机应用程序获取频繁访问的常用信息或数据。可以通过 push-update 机制（大型机应用程序中进行了更新时，更改细节将 push 到 ESB 层）或将缓存设置为在定义的时段后过期来控制同步。

　　或者，可以对基于门户的应用程序（以及创建的后续服务工作流）进行特殊设计，以便客户首次登录到门户时，将通过异步后台请求（pre-fetch）从大型机应用程序公开的服务检索客户的信息，然后在用户会话期间将此信息缓存在 ESB 上。这种设置可减少大型机上的实时请求负载。

　　告诉每个人。将此请求提交到：

　　Digg
 
　　Slashdot

　　收获成果

　　这种类型的设计的实际好处在于，能以特定的方式公开驻留在大型机上的遗留业务功能，从而让应用程序架构师和设计者能够重用已存在的应用程序功能，而不必自己从头进行开发。这样做可以节省大量的成本，而且新的应用程序或功能也可以更快地投入使用。以银行和金融机构为例，此类机构都具有庞大的运行其核心业务的大型机环境。如果让这些大型机直接退役并替换为新的移植应用程序，成本将非常高，而且风险也很大。

　　您可能会问，通过进行 SOA 包装和封装遗留应用程序，我们是不是只是推迟了必然出现的情况呢？我们将来是不是仍然还要进行应用程序移植？我的答案是“是，也不是”，您是在延迟更改，但将以更为结构化的方式对更改进行管理。当然，随着时间的流逝，大型机应用程序将需要进行移植，但通过为这些大型机应用程序提供 SOA 支持，我们提供了将其核心服务功能映射出去的固有结构，以便在将来的移植和重新开发工作中进行实现。

　　请记住，移植大型机应用程序的风险和成本不仅限于所移植的应用程序。与之通过接口连接的外部应用程序也需要进行修改和回归测试。然而，通过在大型机上为其应用程序提供 SOA 支持，可以帮助减少将来进行移植的成本和影响，因为任何通过接口连接的应用程序仅需要关心其访问的服务。例如，如果 ESB 上的服务契约仍然传入输入参数 postalcode 并接受地区名称字符串，就不需要更改邮政编码到地区的应用程序示例。只要服务契约未更改，应用程序就会像以前一样工作。

　　因此，大型机并未退出历史舞台。IT 组织并不需要因为移植遗留应用程序而为其 IT 程序引入额外的风险、复杂性和成本。通过实现基于面向服务的方法，IT 组织可以继续从大型机投资获得回报，并同时顺利地将其企业程序逐渐向纯 SOA 模型过渡。不仅如此，组织还能获得其他好处，例如，能够通过恰当的企业级面向服务的体系结构的实现提高其平台的可用性、性能和可访问性。这样，当需要执行实际的移植时，应用程序间的影响就可以忽略，因为企业中的所有一切都是面向服务的，而不是面向应用程序的。

　　关于作者

　　Adam Neat 住在澳大利亚墨尔本，是管理和 IT 咨询公司 Accenture 的执行经理。Adam 负责亚太地区的自定义解决方案体系结构（Custom Solution Architecture）事业部，同时也是澳大利亚的创新和体系结构（Innovation and Architecture）事业部的负责人。Adam 通过了多个组织的不同平台技术行业认证，曾发表过很多文章，同时也是澳大利亚管理学院（Australian Institute of Management）的副院长。您可以通过 adam.neat@accenture.com 与 Adam 联系。