用于 Paas 平台的 Mule ESB /GigaSpaces XAP/Appistry/GoGrid 将多个应用程序作为 SaaS 加载？

Question

我们正在开展一个项目，开发一个平台，使我们能够轻松地将多个应用程序添加到云平台上，以便可以在 SaaS 的基础上提供应用程序。将对所有应用程序进行单点登录访问（可能通过开放 SSO）。

我们正在考虑：1.m子ESB（集成使用不同语言开发的应用程序）2。GIGASPACES XAP（用于可伸缩性）3。Appistrist Cloud IQ平台（上传应用程序）4。GoGrid 托管

这是正确的工具组合吗？你能推荐其他组合吗？

Answer 1

我首先要声明的是，我是 Appistry 最初的工程师之一，现在是产品经理。我将坚持技术事实。:-)

正如您所提到的，您可以使用 Appistry CloudIQ Manager 来简化跨云服务器的应用程序和相关服务的部署、管理和生命周期。管理员可以对任意服务或服务/应用程序组合执行此操作，并确保它们在每台服务器上保持正常运行。随着服务器的出现和消失，管理器可以扩大或缩小应用程序的规模。CloudIQ Manager 可与 Mule 和 GigaSpaces 良好配合。

至于其他组合，特别是对于可扩展性的要求以及不同语言开发的应用程序的集成，您可以考虑将CloudIQ Engine作为应用程序平台。Engine 可以用来代替 GigaSpaces，或者与它们结合使用，具体取决于您要处理的部分。

CloudIQ Engine 是一个完全去中心化的应用程序容器。Engine支持多种语言集成，无论是客户端还是云端。

在客户端，您可以使用Spring和.NET远程处理来调用引擎托管的对象（调用者和被调用者必须使用相同的语言）或使用CloudIQ客户端API（C / C ++ / Java / .NET / SWIG-wrappable）使用用户定义的流程提交请求，可能消除对 ESB 的需求。流程在引擎上的云中执行，并允许单个请求跨多个方法编排调用。这些方法可以使用不同的语言。

在云端，您可以部署Java对象（PO​​JO和Spring Beans）和.NET对象（PO​​NO）以及C/C++库作为引擎应用程序。Java 和.NET 对象可以不加修改地部署。C/C++（和其他二进制库）可能需要一些包装器代码。元数据描述代码的工作负载策略和其他云端行为。

发动机应用是完全对称的。云中的每台服务器都运行您的应用程序代码。内置的、基于软件的负载平衡将请求定向到最能处理作业的服务器。您的代码继承了平台的可扩展性，无需更改代码。除了规模之外，您的应用程序还可以免费获得可靠性和自动故障转移，以及在元数据中定义您希望应用程序如何响应故障的能力。引擎会在所有可用的 CPU 核心上自动扩展您的代码，除非它是非线程安全的。如果您的代码不是线程安全的，CloudIQ 可以高效地运行它，但代价是不利用所有核心。

您可以轻松尝试一下。CloudIQ Platform Community Edition 允许在最多五台服务器和/或十个处理核心（包括生产）上免费、无限制地使用该软件。社区版可在 Appistry Peer2Peer 上获取（需要注册）： Appistry点对点

Appistry 客户 Presidio Health 在 GoGrid 上运行基于 Java 的 CloudIQ Engine 应用程序，取得了巨大成功。这里有一个网络研讨会和案例研究以及技术讨论（需要注册）： Appistry 资源库

Answer 2

您实际上选择了一个很好的堆栈。 Mule和Gigaspaces经常一起使用，Mule ESB Enterprise（不是开源版本）实际嵌入Gigaspaces技术以提供 高可用性.

Gogrid拥有一个出色的平台，支持Mule ESB，Gigaspace和Appistry的公司都是Gogrid Partners，因此您可以期望使用该堆栈获得良好的支持。我对Appistry不太熟悉，所以我无法直接对它们发表评论。