用于 Paas 平台的 Mule ESB /GigaSpaces XAP/Appistry/GoGrid 将多个应用程序作为 SaaS 加载？
我们正在开展一个项目，开发一个平台，使我们能够轻松地将多个应用程序添加到云平台上，以便可以在 SaaS 的基础上提供应用程序。将对所有应用程序进行单点登录访问（可能通过开放 SSO）。
我们正在考虑： 1. Mule ESB（集成不同语言开发的应用程序） 2.GigaSpaces XAP（用于可扩展性） 3. Appistry Cloud IQ Platform（上传应用程序） 4. GoGrid for Hosting
这是正确的工具组合吗？你能推荐其他组合吗？
We are working on a project to develop a platform that will allow us to easily add multiple applications onto a cloud platform so that the applications can be offered on a SaaS basis. There will be single sign on access to all the apps (likely through Open SSO).
We are thinking of:
1. Mule ESB (to integrate apps developed in different languages)
2. GigaSpaces XAP (for scalability)
3. Appistry Cloud IQ Platform (to upload applications)
4. GoGrid for Hosting
Is this the right combination of tools? Can you recommend other combinations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我首先要声明的是，我是 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对象（POJO和Spring Beans）和.NET对象（PONO）以及C/C++库作为引擎应用程序。 Java 和.NET 对象可以不加修改地部署。 C/C++（和其他二进制库）可能需要一些包装器代码。元数据描述代码的工作负载策略和其他云端行为。
发动机应用是完全对称的。云中的每台服务器都运行您的应用程序代码。基于软件的内置负载平衡将请求定向到最能处理作业的服务器。您的代码继承了平台的可扩展性，无需更改代码。除了规模之外，您的应用程序还可以免费获得可靠性和自动故障转移，以及在元数据中定义您希望应用程序如何响应故障的能力。引擎会在所有可用的 CPU 核心上自动扩展您的代码，除非它是非线程安全的。如果您的代码不是线程安全的，CloudIQ 可以高效地运行它，但代价是不利用所有内核。
您可以轻松尝试一下。 CloudIQ Platform Community Edition 允许在最多五台服务器和/或十个处理核心（包括生产核心）上免费、无限制地使用该软件。社区版可在 Appistry Peer2Peer 上获取（需要注册）：Appistry Peer2Peer
Appistry 客户 Presidio Health 正在运行GoGrid 上基于 Java 的 CloudIQ Engine 应用程序取得了巨大成功。这里有一个包含技术讨论的网络研讨会和案例研究（需要注册）：Appistry 资源库
I'll state up front that I'm one of Appistry's original engineers, and now product manager. I'll stick to the technical facts. :-)
As you mention, you can use Appistry CloudIQ Manager to simplify deploying, managing and life-cycling your applications and associated services across your cloud servers. Manager can do this with any arbitrary service or service/application combination, and make sure they stay up and running on each server. Manager scales applications up and down as servers come and go. CloudIQ Manager will work fine with Mule and GigaSpaces.
As for other combinations, particularly for your requirements of scalability, and integration of apps developed in different languages, you could consider CloudIQ Engine as an application platform. Engine could be used in the place of GigaSpaces, or working in combination with them, depending on which piece you are addressing.
CloudIQ Engine is a fully decentralized application container. Engine supports multiple languages for integration, both on the client-side and the cloud-side.
On the client-side, you can use Spring and .NET remoting to call Engine-hosted objects (caller and callee must be in same language) or use the CloudIQ client API (C/C++/Java/.NET/SWIG-wrappable) to submit requests with user-defined process flows, possibly eliminating the need for the ESB. Flows execute in the cloud on Engine, and allow a single request to orchestrate calls across multiple methods. The methods can be in different languages.
On the cloud-side, you can deploy Java objects (POJOs and Spring Beans) and .NET objects (PONOs), as well as C/C++ libraries as Engine applications. Java and .NET objects can be deployed unchanged. C/C++ (and other binary libraries) likely require some wrapper code. Meta-data describes workload policies and other cloud-side behavior for your code.
Engine applications are fully symmetrical. Every server in the cloud runs your application code. Built-in, software-based load balancing directs requests to the server best able to handle the job. Your code inherits scalability from the platform without code changes. Beyond scale, your application also gets reliability and automatic fail-over for free, along with the ability to define in metadata how you want your application to act in response to failures. Engine automatically scales your code, unless it is non-thread-safe, across all available CPU cores. If your code is not thread-safe, CloudIQ can run it efficiently, but at a cost of not utilizing all cores.
You can easily try it out. CloudIQ Platform Community Edition allows free, unlimited use of the software on up to five servers and/or ten processing cores (including production). The community edition is available at Appistry Peer2Peer (registration required): Appistry Peer2Peer
Appistry customer Presidio Health is running Java-based CloudIQ Engine applications on GoGrid with great success. There is a webinar and case study with technical discussion here (registration required): Appistry Resource Library
您实际上正在选择一个非常好的堆栈。 Mule 和 Gigaspaces 经常一起使用，Mule ESB Enterprise（不是开源版本）实际上嵌入了 Gigaspaces 技术来提供 高可用性。
GoGrid 拥有一个优秀的平台，支持 Mule ESB、GigaSpaces 和 Appistry 的公司都是 GoGrid 合作伙伴，因此您可以期待使用该堆栈的良好支持。我对 Appistry 不太熟悉，所以无法直接评论它们。
You are actually choosing an very good stack. Mule and Gigaspaces are frequently used together and Mule ESB Enterprise (not the open source version) actually embeds Gigaspaces technology to provide high availability.
GoGrid has an excellent platform and the companies that support Mule ESB, GigaSpaces, and Appistry are all GoGrid partners, so you can expect good support using that stack. I'm not too familar with Appistry, so I can't comment directly on them.