Service Wrapper for Play Framework

Today, I would like to share one of the script that runs Play Framework Projects as service in linux. We as administrators are always in need to make any of the projects a typical service that can be handled by executing commands like “service play start”, “service play stop” or anything that runs Play Framework in background (silent mode) as service in linux.

What is Play?

Play Website says: “Play is a high-productivity Java and Scala web application framework that integrates the components and APIs you need for modern web application development. Play is based on a lightweight, stateless, web-friendly architecture and features predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications thanks to its reactive model, based on Iteratee IO.”

Why Play?

In Sphata Systems, we are developing a platform “HUB” that is purely a cloud friendly platform. Before even we stared thinking about the design, first we started understanding the problem of any application that is / to be hosted in cloud if its scalable, flexible, modularized and so on. We clearly understood the demand of any cloud application and we started dismantling each and every block of the system in such a way that each block / module shall be treated as standalone, scalable services that runs and grows on its own. This design enables us to upscale or downsize the computing capacity of the instance that hosts any service in cloud. We in Sphata are trying to come up with a patent-able approach to design a cloud based platform.

For highly demanding design like this, we were in need of a front-end web container that has the capacity for distribution in cloud and flexible enough for us to develop and manage within our custom containers. For this, we chose “Play Framework”. We use Play to manage all VIEWS / GUI that interacts directly to our service containers via web calls.

Need for Startup Scripts:

Play Framework supports CI greatly and even though there are quite a lot of options in play to package and build for production deployment, there is no such great service wrappers in built. But, as administrators, we will be in need of a startup script that starts the project and run silently. Also, we should be in a position to stop, start and manage like any other service in linux. Even though there are lot of scripts available in forums to automate Play Project to run as service in Linux, I took one good example from Play’s google groups and slightly customized to fit my needs. This works fine for me in my cloud instance.

Startup Script to run Play as Service
Just copy this code and make a file as “play” and save it to “/etc/init.d” and then do “chmod +x play”. Now the script is ready to run as executable service for you.

# chkconfig: 345 20 80
# description: Play start/shutdown script
# processname: play
# Installation:
# copy file to /etc/init.d
# chmod +x /etc/init.d/play
# chkconfig --add /etc/init.d/play
# chkconfig play on
# Usage: (as root)
# service play start
# service play stop
# service play status
# Remember, you need python 2.6 to run the play command, it doesn't come standard with RedHat/Centos 5.5
# Also, you may want to temporarily remove the >/dev/null for debugging purposes

# Path to play install folder

# User running the Play process

# Path to the application

# source function library
. /etc/init.d/functions


start() {
echo -n "Starting Play service: "
su -s /bin/sh $USER -c "target/start >/dev/null &"

if [ $RETVAL -eq 0 ]; then
stop() {
su -s /bin/sh $USER -c "kill -9 `cat ${APPLICATION_PATH}/RUNNING_PID` >/dev/null"
su -s /bin/sh $USER -c "rm -rf ${APPLICATION_PATH}/RUNNING_PID >/dev/null"
# su -s /bin/sh $USER -c "play clean stage >/dev/null"
echo -n "Stopping Play Application: ${APPLICATION_PATH}"

if [ $RETVAL -eq 0 ]; then
status() {
su -s /bin/sh $USER -c "${PLAY} state"
clean() {
su -s /bin/sh $USER -c "rm -f ${APPLICATION_PATH}/"
su -s /bin/sh $USER -c "rm -f ${APPLICATION_PATH}/RUNNING_PID"
case "$1" in
sleep 10
echo "Usage: $0 {start|stop|restart|status}"
exit 0

After copying the above script to /etc/init.d/ you shall execute as

# chmod +x /etc/init.d/play
# service play start
# service play stop

Note: You need to customize this script based on where you installed Play and where your project is. Otherwise, this script should be able to handle the play as service.

How to use this script for multiple play projects?
This is quite simple as all you have to do is to just clone this service file and then rename to corresponding play_<project_name> and then edit the file with respective path to that project. Then start it as a different service.

Bootstrap (Service Loader)

Bootstrap has different meaning based on the context of the current subject. Today, we are going to talk about Bootstrap that is related to Software / programming technique. Bootstrap is a technique where we use to load different services at the system start based on context of any program.

Where can we use Bootstrap?

  • Where we need to load the Services / Systems / Modules dynamically. (In this program, we use to define the Services to load). Something that needs
  • Where we need to load the Services based on State of Server. For eg., any application server may be started / running with different state like NORMAL, IDLE, ERROR, UPDATE, … so on.. In that case, we can define different services to be turned on based on the modules as specified in file.
  • Where we need to take complete control of Services loaded to the System. As well, if we need to have total control of the Services to turn ON / OFF based on some events. Total instrumentation over Services can be achieved by using this technique.

Some real-time example for Bootstrap:

How is Bootstrap designed?

Check out this link in Wiki of Bootstapping where it says that Bootstrapping can be interpreted as some step by step process where it initiates each service at the boot of the system. Here in our system we made it completely property file driven (I don’t recommend to keep all configuration to be kept in database as even Database should be treated as service). So, entire Bootstrap system is a self-sustained system that doesn’t need any service to work.

Step 1. Load Service list and State of system from Property file:

We create a custom property file that defines the current state of system to be started. As mentioned above, the current state can be NORMAL, IDLE, ERROR and more.. For each and every state, we will specify list of Services that are to be started in the Bootstrap startup. The Bootstrap will first load the property file and will prepare the list of Services to be started with any optional arguments specified in the property file.

Step 2. Init and Start the Services:

Now after loading the list of Services to be loaded, the Bootstrap will start one service after another sequentially as specified in the property file. What are services? A Service is again a self-sustained module / system that will be serving application for one specific context. Some examples can be Database Access Service, Scheduler Service, SMS Service, EMAIL Service, and so on… Here we can have any types of services in the System based on its function. But, they are broadly classified under two types as ESSENTIAL or ADDON based on its need. At the Bootstrap startup, when any of the Essential services are not started due to some problem, then the booting process will be put to error mode and shut down the system automatically (Remember what happens when memory service fails when you start the computer? similar system).

Each service will run independently providing access to the system. We should be having a Service Directory something similar to JNDI implementation where we will register all booted services for further use. Any modules / application layer will access the Service Directory and will get the working instance of the service and will invoke its functionality.

After successfully starting all the services, now Bootstrap itself will change its state to NORMAL or any state as specified in

Step 3: Accessing Service:

Now, once the Bootstrap is successfully executed and started, all the Services will be available in the Service Directory. Service Directory as said before, is a JNDI kind of implementation where we keep all the instances of services in a map where we can get it object by passing its Simple Name (of class) as context. We shall get instance that is initialized and started at Bootstrap with complete accessibility.

Step 4: Shutting down Bootstrap

If we have to put system on halt for any need, we will be executing Bootstrap’s shutdown function, where it will stop each services one by one and will finally put the server to shutdown mode. This will be really useful to take complete control on each services that are running at the time of shutdown. Particularly if we have any thread based application, we should make sure all the threads are put down before we shutdown the system.

Instrumentation / Control Panel for Services:

This Bootstrap and Service Directory totally enables us to create an Instrumentation layer, where we can create a Control panel where we can manage each and every service individually. You can think like a dashboard panel where you can turn on / off any specific service.

Programmatic Implementation (Java Based):

Considering above 4 steps, I created a simple Bootstrap implementation based on Java (We can use the same technique to create the same in any languages). Here is the class diagram generated from my source code:

Bootstrap Class Diagram

Bootstrap Class Diagram

Source Code:

I shared the source code at GitHub You can download the source code and use it in your project. You can always ping me to get any information regarding Bootstrap.

Sample Implementation:

In the source code, there is a package com.test where we have two Service Classes, TestService and DummyService for you to understand how to create a service. Also, refer to to see how to configure a properties file to start the bootstrap. There is a another file having main method where you can run and see the output of Bootstrap.


I used Apache’s Logger for using as logger for the Bootstrap and you can run with the BasicConfigurator to see the output in console itself.


Hope this Bootstrap system is easy-to-implement in your existing architecture. And it helps you to make your system more towards SOA and improves the modularity of the system.


Kousik Rajendran.

Message Driven Framework for decoupling UI Portlets / UI Modules (ExtJS 4 Sample)

Hey, Hope all of you are having nice time out there.. Today I am interested in sharing one of my own framework how to create totally decoupled GUI apps. But, what does that mean? Well, that ‘s a million dollar question that needs to be understood first before we start talking about the solution . One best example I can quote today for you is Portlets.

What are portlets? Wikipedia says, Portlets are pluggable user interface software components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into a portal. Typically, following the desktop metaphor, a portal page is displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet. Hence a portlet (or collection of portlets) resembles a web-based application that is hosted in a portal. Some examples of portlet applications are email, weather reports, discussion forums, and news.

Consider dashboard environment. The portlets that are loaded in dashboard may be based on ACL data. Lets go by a scenario to understand this problem better.

Scenario: We need to create a dashboard where we have a button in tool bar of dashboard. On click of that we need to reload data of portlets. In that case, what we shall do is this,

Problematic Solution: We may get instance of all the portlets (registered in some kind of Map or Session manager) and then invoke corresponding portlet’s refresh method. For this we may intelligently use the help of Interfaces. But think if prototyping languages like javascript are so strict about that. Answer is NO. Even otherwise, if we deeply think about the programming intelligence, we would end up in restricting the flexibility of Portlets or any module. We need to communicate properly to all the other teams that we would be using so and so methods to refresh. And  we need to maintain stack of documents to know which object has which method to refresh.

But, as devolpers should we think like this? again No. We will have to adopt a methodology that totally decouples the portlets or modules in this whole game. But how is that  possible?

Optimal Solution: I hope we all are aware about Producer and Consumer problem. Where consumer will be subscribing to an interested topic and producer will be producing messages to that topic. Yes, its a JMS kind of implementation we have to do to decouple the portlets / any system. This strategy can be used widely for any of your systems based on its demands. I used this methodology for alteast 2 of the products I designed so far.

Example of Implementation: For our example I used ExtJS 4.1 based portlets. I picked the portlets example of ExtJS library and then implemented a Message Driven Framework for UI (MDF-UI) and solved the question I put in above block. This implementation totally decoupled the portlets and even my other modules where all my events are published as topics and interested subscriber portlets  will respond based on the topic and message.

Note: You need to know few things about ExtJS to understand this example easily

MDF-UI  Blocks:


Above is the representation of components used to create MDF-UI in ExtJS.

Logger: is used to printing any messages in to browser console.

Constants: is a directory used to maintain all TOPICS

Manager:  is a Lookup Index where we can use it for storing any components object to it. It is not used in this framework directly, but still thought of sharing it. You can use this to register all UI components loaded in the system.

NotifierMap: is extension of Ext.util.MixedCollection where I have implementation for how to use it to easily manage all registered Producers and Subscriber informations.

NotificationManager: is the brain of this framework where we use this to register / de-register producers and subscribers along with the topic.

IPublishedMessage: can be used as Mixin where it is used to fetch messages for specified topic

INotifier: is a Mixin where it is abstract implementation of Notifier.

INotificationLsnr: is a Mixin where it is abstract implementation of Notification Listener.

AbstractMessenger: is a sample implementation of MDA-UI

How it works:

Once the UI / Portlet compoent is loaded the initComponent method will be called Ext. There, I am subscribing the same object by calling NotificationManger via INotificationLsnr mixin with the relevant topic. Like wise, any notifier buttons or components will have INotifier mixin with the topics. So, whenever there is an event, the notifiers will send a message to the NotificationManger which in turn will iteratively call the notified methods of all Subscribers with the message.

Download Source: You can download the sample code here or you can visit here to look at the working demo. Codes are very simple and self explanatory. You can look at them and then post me if you need any clarity on that. To set up your environment, simply download the source code and extract to your htdocs / webapp folder of your server and call http://localhost/works/extjs/mda/index.html. You should see the app in action.

Learning Framework: You should open /works/extjs/mda/ux/messaging folder to see Ext.ux.messaging.* components.

(Warning: If your browser is not loading the app, please try refreshing it once. I am still working to solve the Ext.Loader issues. 😦 )

Feel free to download and use this framework. I would be more than glad to explain this more if you someone is looking for 🙂

%d bloggers like this: