Eclipse Luna: Scout Cloud Apps
This article describes the initial cloud support that was added to Eclipse Scout with the Luna release. In the text below, we first motivate our efforts in this area and describe the approach chosen for the Scout framework. Then, the abstraction layer to implement access to distributed caching and messaging is discussed. And finally, we list the necessary requirements for Platform as a Service (PaaS) offerings and provide an overview of suitable public PaaS provider.
Motivation
Since 2006, when Amazon started its Web Services (AWS) offering, the cloud market has become a growing multi billion dollar market. Following customer demand, many software vendors start to provide their products on a Software as a Service (SaaS) basis. For organisations developing in-house applications, the usage of Platform as a Service (PaaS) offerings can help to significantly reduce time and costs to develop, deploy and operate applications. This is especially true for startup organisations, that need to focus their efforts on their product and the time to market for new features and critical bug fixes. In addition, many PaaS offerings support dynamic scaling by adding additional server nodes when the load on the existing infrastructure increases.
We are convinced that the trend to move applications to the cloud has only begun, and will grow even stronger in the future. With the Luna release we targeted public PaaS providers for Scout’s initial cloud support. This should minimize developers efforts to build scalable Scout applications and to actually run such application in the cloud. And because we know that you won’t be happy to rewrite your application when you need (or want) to change your PaaS provider in the future, Scout’s cloud support works as independent of any specific PaaS as possible. Exactly according to the spirit of Scout’s long term strategy.
How to scale Scout Applications
The classical way to scale web applications is to add/remove application server nodes depending on the actual load on the current nodes. Communication between the application’s clients to the server are running over a common load balancer that is distributing the requests from clients to the available server nodes. And the server nodes are accessing a common database infrastructure to store and retrieve data that is relevant to the specific application.
This is exactly the scenario that is supported by the initial Scout cloud support shipped with the Luna release train. As shown in the figure below, a Scout application may now work with a dynamic number of application servers operating behind a common load balancer. The load balancer then distributes incoming client requests to the next available application server. The individual servers then use a common infrastructure to access a distributed cache, the message queue and the data base.
In the past, a Scout server created a ServerSession for each individual client. This server session was then used to identify the Scout client and to store client specific data. Unfortunately, the new application architecture no longer guarantees that subsequent requests of a specific client are handled by the same Scout server instance. To ensure that each client request can be processed correctly the server sessions are now held in a distributed cache that is accessed through a caching service. This caching service is one of the newly added components to the Scout framework.
An additional change was necessary to properly handle client notification in scalable Scout applications. Client notifications are used in the Scout framework to push messages from the Scout server to the Scout clients. To manage the client notification messages, a queue is used to hold the messages that need to be delivered. With the scalable server architecture coming with the Luna release, Scout server applications hold individual queues that are updated from a common message queue using the Pub/Sub pattern. When a specific Scout server adds a client notification to the queue, or sends a notification to a specified client, the information is now distributed among all server instances using the newly added message queue.
PaaS Independence
To allow for long term planning, Scout applications should be as independent of individual PaaS providers as possible. Therefore, the Scout framework must not directly depend on the availability of specific distributed caching or message queues technologies. Rather, as shown in the diagram below, it takes advantage of its service oriented architecture. In the Scout runtime server bundle the necessary services to access caching and the message queue are located using the OSGi service registry.
By providing alternative implementations to specific caching and message queue technologies, the exact same server code can be used for different PaaS environments. To build Scout applications for a specific PaaS provider, the developer only needs to select matching service plugins and add these to the the server product. Scout caching support is already available on the Eclipse marketplace for memcached and redis. In the case of message queues, support is available for ActiveMQ and RabbitMQ . Together with the previously existing support for MySQL and PostgreSQL Scout allows to implement web application that run in many different environments.
Suitable PaaS Providers
Currently, most PaaS providers agree on a number of important core aspects such as support for Java 1.7, or providing Tomcat application servers. To quickly get started with Scout cloud application development, we tried to compile a short list of public PaaS providers that also offer application hosting. And for some of them, we did actual trials to verify, that the cloud support with the Scout Luna release actually works as expected.
Prior to the selection process for the short list, some hard and soft requirements where compiled. The goal of the list of requirements is to find PaaS providers that seem suitable to host realistically complex Scout applications including dynamic scaling of server nodes, and access to shared databases, message queues and caching. At the same time, these services should be based on open standards to allow for a painless migration of the application to a different PaaS provider.
The hard requirements also include full Java 1.7 support, a servlet container and access to a relational database, as well as messaging and caching. Once these requirements are met, dynamic scaling and the support of open standards for databases, caching and messaging have been added as soft requirements.
Hard Requirements
- Public PaaS with Hosting
- Java 1.7
- Servlet Container
- Relational Database
- Message Service
- Cache Service
Soft Requirements
- Automatic Scaling
- Open Source Database
- Open Source Caching
- Open Source Messaging
The overview provided below presents the short list of public PaaS provider. To create this shortlist, we started with the offerings listed of Khazret Sapenov’s PaaS list. The hard requirements to offer Java support reduced the list to roughly 35 entries. Requiring public hosting and eliminating double entries, offerings no longer available reduced the list to 14 elements. The HANA Cloud Platform, Uhuru PaaS and the WSO2 Stratos Live were also removed from the list as its offerings primarily focus on supporting proprietary software of the vendor itself. This process resulted in the list of the 11 “surviving” PaaS offerings.
| Provider | Product | Hard Requirements | Autoscaling | Other Soft Requirements |
|---|---|---|---|---|
| Amazon | Elastic Beanstalk | OK | OK | MySQL, Memacached, RabbitMQ |
| CentruyLink | AppFog | OK | NOK | MySQL, Redis, RabbitMQ |
| Clever Cloud | Clever Cloud | NOK: Message and cache services missing | OK | MySQL |
| CloudBees | Run@Cloud | OK | OK | MySQL, Memacached, RabbitMQ |
| AppEngine | Java Sandbox only, Message service missing | OK | MySQL, Memcached | |
| Hivext | Jelastic | OK | OK | MySQL, Memcached, JMS |
| Microsoft | Microsoft Azure | OK | OK | Azure SQL Database, Azure Cache, Azure Service Bus |
| Oracle | Cloud Java | OK | NOK | Oracle Database Cloud Service, Coherence, Oracle Messaging Cloud Service |
| Pivotal | Pivotal One | OK | NOK | MySQL, Memcached, RabbitMQ |
| Red Hat | OpenShift | OK | OK | MySQL, Redis, ActiveMQ |
| Salesforce | Heroku | OK | NOK | PostgreSQL, Memcached, RabbitMQ |
Please note that the above list is bound to be out of date almost immediately. Some of the offerings have been around for a while, but the dynamics in the PaaS space is very high. Just to name an example, we should have included the Stratos PaaS, as this offering has been donated to Apache last year and been promoted to an Apache top level project recently.
Conclusions and Outlook
With the Eclipse Luna relase, Scout adds initial cloud support for building enterprise applications. This support makes writing scalable business applications as simple as possible. And with Scout’s abstraction layer for databases, caching and messaging, Scout applications become de-facto independent of specific PaaS provider. This let’s you focus on implementing functionality and removes the worry of selecting the “right” PaaS provider.
When working with Scout desktop clients, complete scaling is already supported with the Scout Luna release. A logical next step is to add support for scaling the web servers. As the Scout web servers are running the web-clients of Scout web applications, this addition will then allow to scale complete Scout web applications.
Further Reading
- Scout in the Cloud session at EclipseCon, San Francisco, 2014
- Techtarget interview by Caroline de Lacvivier, 18 Mar 2014
- Wiki Tutorial to add Scout cloud support (work in progress)
- Other: Project Home, Forum, Wiki, Twitter
Acknowlegements
This article is based on the master thesis of Thomas Schweigler, that has been also supervised by Scout committer Judith Gull. We expect to be able to provide access to the full thesis (in German) in the near future. The cloud icon used at the beginning is available at www.iconarchive.com. According to its terms, the icon can be used freely for non-commercial use.
About the Authors
