拥抱面向遗留领域的SOA
在以后几年，随着整个行业开始广泛采用 SOA，IT 架构师将开始购买业务流程包，而不是应用程序包。他们会随后将这些业务流程包作为现有业务服务聚合体的一部分进行部署，以便连接到企业服务总线（ESB），并与各个组成应用程序集成。知道了这一点后，IT 架构师应该如何使用面向服务的方法来帮助解决这些挑战呢？
首先，必须在大型机上（或在遗留环境中）对应用程序进行概念化，不是将其作为应用程序，而是作为服务的一个“部分”。必须从理念上将应用程序与基础平台体系结构（在这种情况下为大型机）分离开来。SOA 改变了应用程序的概念，使其成为了一组可通过服务接口访问的逻辑功能组。本文重点讨论各种可继续从大型机平台获得积极投资回报（ROI）的方法，从而探索上文列出的 IT 组织面临的主要挑战的解决方案。
可以使用 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 的应用程序，允许客户订购各种美容产品。通过门户应用程序，客户可以从目录中选择产品，然后下订单。
应用程序的订购模块包括来自大型机的客户详细信息。不过，由于基于大型机的 COBOL 应用程序的遗留配置非常复杂或者在设计上存在缺陷，大型机仅能存储邮政编码，而不能存储对应的地区。利用企业开发 IDE，您可以通过从 ESB 服务存储库拖放一个服务来创建门户应用程序的 Customer Suburb，并创建检索客户详细信息的流程，在此流程中使用 Postal Code 字段作为 IBM eServer® pSeries™ 中型应用程序（承载邮政编码到地区查询服务）的输入参数。由于邮政编码到地区查询服务与公开的大型机应用程序的服务位于同一 ESB，因此将所有这些服务分组到一起来形状单个流程就再简单不过了。
不过，这个简单示例的一个缺陷是，如果该面向 Internet 的门户应用程序极为受欢迎，则可能在任何时候都有数万在线并发用户。为什么这是一个问题呢？因为此处要考虑的主要问题是，使用大型机公开的服务与与部署到 Internet 的应用程序之间的负载级差以及这个负载级差如何影响大型机。
正如我前面提到的，大型机并未设计为（或并不习惯）处理大量实时用户请求。每秒 20,000 到 50,000 的实时在线请求会导致典型的大型机环境崩溃。不过，通过将大型机环境封装在 SOA 层中，可以使用 WebSphere Process Server 等 ESB 提供的一些缓存和预读功能，从而将大型机隔离开来。图 2重点说明了此类设置在典型环境中的情况。
此策略的工作方式是这样的：可以通过 ESB 使某些数据（静态数据或变化不频繁的数据）变为持久性数据或可缓存数据。连接到 ESB 服务层的支持 SOA 的应用程序（如门户）可以随后以所需的性能进行事务处理，而不会使大型机后端崩溃。
例如，假定大型机上驻留了一个客户记录数据库。在理论上，此数据库将在 ESB 层进行缓存，从而不必每次直接从大型机应用程序获取频繁访问的常用信息或数据。可以通过 push-update 机制（大型机应用程序中进行了更新时，更改细节将 push 到 ESB 层）或将缓存设置为在定义的时段后过期来控制同步。
或者，可以对基于门户的应用程序（以及创建的后续服务工作流）进行特殊设计，以便客户首次登录到门户时，将通过异步后台请求（pre-fetch）从大型机应用程序公开的服务检索客户的信息，然后在用户会话期间将此信息缓存在 ESB 上。这种设置可减少大型机上的实时请求负载。
