根据摩尔定律，自从晶体管在1958年发明以来，处理速度和容量一直是大约每两年提高一倍。因此，我们制作更大和更复杂的软件系统的时候也要跟上这种容量增长的速度以满足这些系统的需求。

　　我们如何领先于这种趋势？考虑到内存和存储在企业计算领域一直在增长，软件需要跟上这种增长速度。我们要使用正确的方法从一开始就设计软件具有灵活的伸缩性和可预见的延迟。数据文件和信息传输的尺寸日益增大要求进行更多的处理。在许多情况下，在进行处理之前还需要使用多个输入的信息来源才能进行数据处理。

　　制作电信电话设置和计费、在线游戏、证券交易、风险管理和在线订购旅游等XTP(极限事务处理)式的应用程序的那些人也了解这种难题。在许多行业都能够使用的更广泛的应用案例是Web应用程序。这种应用程序能够升级要满足互联网的通讯量，也能适应从来不处理那种通讯的后台系统。

　　边界成本

　　在与客户讨论有关用可预见的延迟升级一个SOA应用的时候，经常会遇到“边界成本”这个词汇。在一个应用环境中解释一下这个词汇。考虑一下这个情况，一个XML文件也许是来自内部应用程序、外部业务合作伙伴或者是从一个EDI文件转换过来的，需要由许多服务进行处理，这些服务是由一个BPEL(业务处理执行语言)流程协调的或者由一个企业服务总线流程管道协调。通用的方法是把XML文件放在总线上，让总线根据这个流程的定义调用这个服务，把这个XML文件作为这个服务请求载荷的一部分传送。需要处理那个数据的每一个服务都要相应地访问这个XML文件。也许还会出现与数据库的交流。这种方法听起来是很简单的，见图1

　　图1：使用BPEL流程或者服务总线管道调用服务

　　然而，在实践上，使用这种方法会有一些伸缩性方面的挑战。从一个服务到另一个服务的跨边界成本是什么？在调用一个简单的业务流程的情况下会产生多少次这种成本？如果这个XML文件容量有数MB大，或者有数千个这种文件，怎么办？或者这两种情况同时出现怎么办？

　　使这种挑战更困难的是这个现实：大多数IT环境都是许多平台和技术的混合体。不管你的处理引擎或者服务总线是多么充分，在服务端点进行处理都是一个瓶颈。最近，一个客户网站发表的谈话披露了一个一般需要15秒钟的15个步骤的业务流程。但是，在工作量的最高峰时，这个流程违反了30秒钟的服务级协议。开发人员用了两年的时间优化和微调这15个服务中的每一个服务的性能，发现的端对端的延迟的其它原因是服务之间的边界成本。详细的检查发现，在开源web服务工具集中分析和配置XML工作负荷的过程中，这15个服务中的每一个服务的调用都需要1至2秒的时间。

　　图2：图2是传统的SOA数据负载模型，显示把XML从一个服务转送到另一个服务的过程。显示每一个服务调用的XML至对象(Object)和关系(Relational)与其相反顺序之间的服务请求边界成本。

　　什么是应用程序网格？

　　应用程序网格是内存存储引擎中显示应用程序状态数据的一个平行的可伸缩的代理。它有效地提供一个分布式共享的内存池，能够线性地伸缩以适应不同种类的机器网格。这些机器包括高端硬件和低成本的商品硬件。在一个应用程序中使用应用程序网格可同时向内存中的数据提供新能、伸缩性和可靠性。

　　应用程序使用一个应用程序网格的一个方法是使用类似于Java Hashmap、.NET目录或者JPA接口等API级别的接口。一种替代的方法是使用SOA环境中的一个服务级接口。

　　如图3所示，应用程序网格接受一个把数据放到地图中的请求，并且通过一个高效率的网络协议传送到拥有主要实例数据的网格节点P。然后，这个主要节点把这些副本转变为更新的值传送到第二个节点B进行备份。接下来向这个服务返回控制。

　　图3：应用程序网络集群保证不同机器上的主要/备份的内存中的数据。

　　图4显示一段数据的主要拥有者“P”在提取服务数据过程中出现的故障。这个“get()”请求将立即被路由到一个备份节点，然后分配一对新的主要/备份节点。

　　图4：应用程序节点提供内存内部状态数据的连续不断的容错能力

　　SOA与应用程序网格

　　使用应用程序网格的下一代SOA平台提供一些你在服务基础设施中常见的东西，如服务级提取、协调数据转换与路由、多协议支持、适配器等。

　　我们目前如何应用这些方式实现这个好处呢?在一个典型的SOA环境中，一个流程中的多个服务会调用相同的数据。没有网格，每一次调用这个服务时候都需要提供它需要的数据。

　　我们使用这个应用程序网格把那个信息存储在内存。每一个服务都把一个密钥或者一个密钥列表发送给它将操作的数据。这就意味着，根据企业服务总线、流程引擎和传输的不同，把密钥从一个服务发送到下一个服务也是不同的。但是，一般来说，把密钥从一个服务发送到下一个服务是在作为一个具体协议的文件头的一部分由服务请求发送的，或者作为一个较小的XML负载的一个一致同意的要素发送的。这些服务将变得熟悉网格并且能够根据需要访问数据并且能够对那个数据集进行集合运算。一旦进行处理，那个数据集就能够保存在内存中以便进行非常快的读数据操作，或者这个数据集继续放在一个使用异步延迟写入技术的数据库中。这个数据集通常采用子集和适合长期关系数据存储的格式（见图5）。

　　图5：SOA和应用程序网格向服务状态数据提供内存中的访问，使用“Claim Check”（领取单）方式最大限度减少边界成本。

　　XML网格的例子

　　这个例子是这样的：一个大型的MXL文件需要由许多服务处理。这个文件不需要每一个服务反串行化、解析、操作和再串行化整个文件，而是分解为更小的文件，转换为Java对象并且存储在应用程序网格中。这个操作由这个链条中的第一项服务执行，或者由一项公用服务在这个文件到达第一项服务之前拦截这个XML文件。比较小的XML消息要从一个服务传送到下一个服务。这个比较小的XML消息(“claim check”)包含访问在应用程序网格中的数据的一个密钥。

　　分解这个XML文件

　　我们使用一个StAX（XML流API）解析器分析这个XML文件并且把这个文件分解为这个文件的组成部分。因为STAX在获悉在什么地方开始的时候将实现一个对象树，我们首先寻找许多重复的组成部分中的第一个组成部分。如果这个XML在一个项目节点的容器中包含数千个项目，我们就开始分析这个项目以避免实现整个项目树。

　　然后，我们使用JAXB(Java Architecture for XML Binding)把单个的XML要素转变为Java对象。一旦拥有这个项目的JAXB对象的参考，我们就可以把它放在一个应用程序网格中。

　　接下来的操作还有深入了解应用程序网格的力量、把基于网格的处理逻辑当作一个事件处理和重构XML文件等。

　　总之，我们了解到的情况是一个应用程序网格能够用来显著改善处理大量数据的基于SOA的应用程序的效率和伸缩性。通过在一个具有水平升级功能的应用程序网格中存储和操作服务请求负载（无论这个负载的大小和数量如何），我们都能够以可以预计的延迟升级这个应用程序。此外，使用这个应用程序网格的强大功能，我们能够以内存内部的访问速度执行分布式查询和更新。随着数据越来越大，我们能够简单地升级这个网格以满足需求。这有助于我们使用不太强大的硬件和从一开始就拥有伸缩性的架构实现比以前更强大的处理能力，不用在你每一次遇到升级极限的时候都重新访问这个应用程序设计。