GigaSpaces XAP 6.0：简化的以 Spring 为基础的面向空间架构 API

GigSpaces 最近发布了他们的极限应用平台 （XAP）的6.0 版，它是一个软件底层构造平台，可以让应用程序扩展到分布式环境中。InfoQ 对GiaSpace 的 Geva Perry 和 Nati Shalom 进行了采访，以了解更多关于这一版本以及其中变化的信息。 首先，Perry 和 Shalom 介绍了 6.0 中的主要变化：

• OpenSpaces － 这是 6.0 中的主要开发平台，将 Spring 框架提供的 POJO 驱动开发模型像组件一样使用，以获得高伸缩性、事件驱动和面向服务架构。它提供了诸如内存数据网格、远程调用、声明式事件容器和事务等组件，并具有类似 OSGi 的部署模型。
• 持久化即服务（PaaS） － 又被称作镜象服务，它用后端数据库提供了可靠的内存数据网格异步持久化。镜像服务会以透明方式处理一切，无需修改应用代码或配置。
• JMS 1.1 交互能力 － 它允许将输入直接通过 JMS 的 API 立即转送到空间的入口处，极大地减少了延迟，而且由于模块数量的减少，也简化了基于事件驱动的应用的开发和部署。
• SLA 驱动容器 － 服务网格是通过服务等级协议（Service-Level Agreements，SLAs）来动态地管理集群实例的，现在通过 Spring 的使用，该方式得到了极大的简化，并被集成到这一产品的所有版本中（包括免费的社区版）。
• 对.Net 的增强支持 － 性能已经得到了提升，并实现了.Net 的本地化支持，而且有一套新的 API 让运行于嵌入模式下的.Net 和 Java 间实现双向的无缝交互。 GigaSpaces 还与微软一道，提供了更多基于微软技术的打包解决方案，如 Excel、SharePoint、Visual Studio 和 Windows 计算机集群服务。
• 支持亚马逊弹性计算集群（EC2） － 6.0 版现在已可以工作于 EC2 平台上，EC2 是一个成本仅为每服务器每小时 0.10 美元的服务平台，所以用户可以在此平台上进行实验，并确定应用该如何扩展到多服务器上。
• 对基于空间架构（SBA）的 **** 集成支持 － 在前一版中实现 SBA 需要一些开发和配置代价，这在 6.0 版中得到了简化，SBA 组件就像处理单元（Processing Unit）一样明确成为了 API 的一部分。

当请他们进一步描述什么是处理单元（Processing Unit）时，Perry 和 Shalom 说：

在基于空间的架构中，一个处理单元代表一个应用的扩展和容错单元，它通常包括所有对延迟（latency）和运行时具有紧密依赖 的应用服务和中间件模块，它将那些服务封装在一个单独的容器（即处理单元）中，并对所有的这些组件以一种通用的方式来保证一致的扩展和容错语义。例如，对 于一个失败事件，它将自动同时触发中间件模块（如消息、数据网格）和关联的业务逻辑的恢复进程，通过这种方式，我们可以避免当一个实际的失败事件发生后， 消息系统已将事件传送出去，但应用服务却还没有准备好去处理它而引起的局部失效和不一致行为。从延迟的角度来看，这种将所有组件封装于相同运行时的容器中 方式减少了网络开销，因为他们的交互全部是在内存进行。扩展特性变得像增加处理单元那样简单，换句话说，就是不需要再分别去扩展数据、业务逻辑和／或消息层。

他们还讲述了他们怎样看待这一版本在蓝图中的位置：

6.0 是把我们一直为之努力的理想向前推进的又一重要步骤，这一理想的核心是让那些使用多层构架和 J2EE 栈构建应用的日子走向终结！这些架构和依赖于这些架构的中间件技术，在支持现代商业应用要求的可扩展性、可靠性和性能等方面，已经走进了死胡同。除 此以外，新出现的架构将基于低成本硬件来支持横向扩展，而非纵向扩展；他们将利用内存数据网格来实现实时的、在线的事务化记录系统来替代关系型数据库管理 系统（RDBMS）；他们将通过数据和服务的动态定位，用单独的“持续可用”的容错集群来创建自给自足的“处理单元”。

Perry 和 Shalom 同时还提到，很多主流网站如 eBay、Google、MySpace 和亚马逊也提出了类似的观念， MapReduce , Hadoop 和 memcached 便是现成的例子。不过他们也很清楚的表示，他们正在通过对 JDBC、JMS 和 Spring 的支持来小心地维护与 J2EE 世界、现有开发者技能之间的互操作性。他们还指出 XAP 社区版本和 OpenSpaces 这类产品针对主流开发者的意向甚过他们那些主要由大型公司使用的企业级产品。

被问及 GigaSpaces 与 GridGain、Coherence 和 Terracotta 相比会如何时，他们认为这些供应商正试图教育社区以更佳 的方式去创建和部署应用，相比之下，GigaSpaces 被设计作为全面的应用平台以解决扩展、性能和高可用性等方面的问题，而其它的供应商则更关注于分 布式计算的细节方面，如分布式缓存。他们还提到，GigaSpaces 之前并不是一个关注于批量应用的企业级网格计算解决方案，为了提供这种方案， GigaSpaces 与 GridGain、DataSynapse 和 Platform Computing 这样的公司进行了合作。相比在交互的应用网格中处理共享资源的多个应用而言，GigaSpaces 还更多地侧重于在内部应用网格中运行 单个应用。 InfoQ 又请 Perry 和 Shalom 对 Cameron Purdy 最近的“对网格计算未来的思考”给予评论，他们说：

Cameron 的声明一直强调 Tangosol 是最好的数据缓存技术，因为它主要就是关注于这一点：数据缓存。我们认为它现在自信能以端到端的方式解决整个应用的扩展 性、性能和可用性问题，而不仅是应用的数据瓶颈，但这将有更多要求，远不止分布式缓存这样的功能（尽管它被称为数据网格）。Oracle 已经认识到这一 点，这也正是他们收购 Tangosol 的原因，他们试图将缓存加到他们的 Fusion 中间件栈中，该中间件栈中还将包括他们的传统应用服务器和消息技术。无论如何，就算把不同技术集成的再好（而这一点也有待证实），在为所有协作组件的可测量性、性能和持续可用性提供一个通用动态集群模型这方面，它也一直存在有先天的不足。相比 GigaSpaces 6.0 XAP 所使用的 SBA 整体方案而言，它压根就是完全错误的。

最后，当被问到 XAP 会拥有怎样的未来时，他们说：

对于 EC2 和我们的社区版本，我们计划提供一个特别的“起步助力”，允许那些刚起步的非营利性开源项目在他们的产品中免费使用这些版本。这是我们第一次对此进行公开声明，在未来几周内就会启动，所以敬请留意。

查看英文原文： GigaSpaces XAP 6.0: Simplified, Spring-based API for Space-Based Architecture