正如我前面提到的，大型机并未设计为(或并不习惯)处理大量实时用户请求。每秒 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 模型过渡。不仅如此，组织还能获得其他好处，例如，能够通过恰当的企业级面向服务的体系结构的实现提高其平台的可用性、性能和可访问性。这样，当需要执行实际的移植时，应用程序间的影响就可以忽略，因为企业中的所有一切都是面向服务的，而不是面向应用程序的。