When we created WebSphere Liberty we designed it to be easy to use and run well in any cloud, so that Liberty could always be the enterprise Java container regardless of the choice of cloud infrastructure. ÉgalitĂ© in all clouds for the Java EE 7 fraternitĂ©… OK, I’m still working on that. But let me illustrate what I mean.

Cloud infrastructure provides a number of new ways to build and run applications and easily assemble new services exposing RESTful APIs. At the heart of any of these cloud choices is still a business application that interacts with data, performs operations on that data, and generates events and responses from it. Between the business application and the systems it interacts with is a common need for enterprise application services like persistence frameworks, role-based security, session-caching, and so on. This is true regardless of the cloud provider and regardless of whether the cloud offers platform-as-a-service (PaaS), infrastructure-as-a-service (IaaS), or container-as-a-service (CaaS).

All of the *aaS’s

These different *aaS’s subtly change the way that Java applications are packaged and delivered to the cloud, but not the relationship between the application and the Java EE services they use. We designed Liberty with a wide variety of cloud deployment strategies in mind, and with a common and simple experience for developers regardless of the strategy employed. I’ll illustrate this with a Java EE 7 application that is developed in a common fashion and then packaged according to chosen cloud strategy to run in an identical manner with the same Liberty server runtime in all cases.

I’ll use one of our new Java EE 7 samples, the WebSocket Sample. This illustrates how to develop a WebSocket endpoint using the Java API for WebSocket and deploy it to Liberty. As we’ll see, it’s the same application running inside the same Liberty runtime regardless of deploying locally, to a PaaS, to a Docker CaaS, or to IaaS.

On premise or local deployment

Let’s start with local deployment. For this, the pre-req is an installed WebSphere Liberty runtime with the appropriate set of runtime features enabled. Download the latest version of Liberty from the Liberty repository; just follow the first 2 steps on the download page and you have a basic sever runtime installed and ready.

Now download and extract the WebSocket Sample from the Liberty repository as described in the sample’s documentation.


If you take a look at what you extracted, you’ll notice one of the things that make it so easy for Liberty to run in any cloud: the extracted sample has all its content under a directory structure wlp/usr/servers/, which contains a server.xml configuration for a server called WebsocketSample and server-specific subdirectories containing the web application. This single, self-contained archive has both the application and the server configuration for that application.

Take a look at the server.xml. These 7 lines of XML are the entire configuration for the server. The important part is the list of features required by the application, which contains websocket-1.1. The websocket-1.1 feature is a new Java EE7 feature available from the Liberty repository – you add it to your Liberty server installation by running the featureManager command described in the feature documentation.

And that’s it. You can now start the server and run the application as described in the sample doc, pointing your browser at http://localhost:9136/WebsocketApp. If you use the WebSphere Developer Tools for Eclipse (WDT) you can also import the application WAR into the tool to play around with the application and redeploy it to the server from within WDT.

Platform as a Service (PaaS)

If local deployment is easy, PaaS deployment is even easier because it removes the need to install the Liberty server locally. With PaaS you just push the application WAR to the cloud. The cloud then provisions the application server runtime and deploys the application into it, with the cloud provider taking responsibility for managing the lifecycle of the application server componentry. WebSphere Liberty runs inside many PaaS clouds including Cloud Foundry, OpenShift, and Heroku.

IBM’s Bluemix provides an “Instant Runtimes” PaaS based on Cloud Foundry with Liberty built-in as the Java application runtime. When you push a web application to Bluemix, the cloud infrastructure provisions the same familiar Liberty runtime and runs the application in it. All the Java EE 7 features required for the application, including the websocket-1.1 feature, are available to the Liberty runtime in Bluemix although only those required by the application are actually started.

To further simplify application deployment, you can easily push the application and its server configuration at the same time as part of a single push. To deploy the WebsocketSample application to Bluemix Instant Runtimes, you can use either WDT or the CF command line.

For the WebsocketSample application, for example, change to the directory you downloaded the sample to and push the server directory, giving the application the name you want to call it on Bluemix. For example:

cf push IanWebsocketApp –p wlp/usr/servers/WebsocketApp

This doesn’t require any server runtime code on the developer machine – that’s already installed in Bluemix. This is just pushing the self-contained application and server configuration directory. You’ll see output like:

Creating app IanWebsocketApp in org ian_robinson@uk.ibm.com / space dev as ian_robinson@uk.ibm.com...
Creating route ianwebsocketapp.mybluemix.net...
Binding ianwebsocketapp.mybluemix.net to IanWebsocketApp...
Uploading IanWebsocketApp...

requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: ianwebsocketapp.mybluemix.net

The same application is then available in the Liberty runtime in Bluemix with a default route of http://ianwebsocketapp.mybluemix.net/WebsocketApp/ and without any end-user Liberty runtime installation having been required.

Container as a Service (CaaS)

CaaS is increasingly popular, with technologies like Docker providing a lightweight virtualization container between the operating system and the application server. This gives you an experience that is somewhat similar to PaaS but with greater flexibility; the cloud still provides the infrastructure and management of container instances but the deployer has much greater control over the content of the deployed containers, and can compose containers from any arbitrary software content.

Again, Liberty is very easy to stand up inside a Docker container and very easy to extend in customized docker images. An official websphere-liberty image from IBM is available in the Docker Hub registry along with WebSphere Liberty Dockerfiles to build the Liberty image at various releases. You’ll see from the Dockerfiles that the images are created by layering Liberty and IBM Java 7 on top of an Ubuntu 14.04 image. The self-contained Liberty server file structure makes it very easy to build a docker image that extends this to add the WebsocketSample application. We’ll make one change to the sample server.xml to enable a non-localhost host name to be used to access the application. Edit the server.xml in the WebsocketSample directory to add a host="*" attribute to the httpEndpoint element.

The end result should be:

  <server description="default WebSocket engine">
   <httpEndpoint host="*" httpPort="9136" id="defaultHttpEndpoint"/>

The following simple Dockerfile, if added to the WebsocketSample directory, can then be used to build a docker image that contains a Liberty runtime with the application deployed to a configured Liberty server which is started when a container instance of the docker image is started:

FROM websphere-liberty:beta
ADD WebsocketSample /opt/ibm/wlp/usr/servers/WebsocketSample
# Server is called WebsocketSample and is configured to use port 9136
CMD ["/opt/ibm/wlp/bin/server", "run", "WebsocketSample"]

The FROM instruction takes the current Liberty Beta driver as its starting point since this already contains the websocket-1.1 feature. The ADD instruction copies the WebsocketSample content (which defines the WebsocketSample server and the applications that run on it) to the servers directory of the container’s file system. The CMD instruction ensures that when a container instance is created then the WebsocketSample server is started by default. To build this image from the WebsocketSample directory, and tag it with the label websocket-app, run:

docker build –t websocket-app .

A container instance of this image can be created locally by running:

docker run -d -p=80:9136 --name websocket websocket-app

and accessed via http://<docker-virtual-host>/WebsocketApp.

The –p=80:9136 publishes the container port to the host, in this case mapping the host port 80 to the container port 9136 which we configured the WebSocketSample server to listen on.

You now have a very portable container image of an application deployed to Liberty on Ubuntu that can run anywhere there is a Docker engine. To share the image, push it to a public or private Docker registry, using docker push image-name ; the image can then simply be retrieved using docker pull image-name and run in another Docker environment.


The IBM Bluemix cloud provides a hosted Docker environment in addition to the Instant Runtimes described above, called IBM Containers, which includes a private Docker registry for each organizational space. It’s then easy to run and manage your application in the cloud inside a Docker container that contains Liberty: push your Docker image to your private registry in Bluemix and use the hosted Docker environment to start and stop container instances of your Java EE 7 WebSocket application in the cloud.

Infrastructure as a Service (IaaS)

The final type of cloud I’ll mention is IaaS. This is for ultimate flexibility and consequently has the most set-up. Liberty obviously runs here too since this is just a collection of VMs and a mechanism for self-service-based definition and provisioning of those VMs. Bluemix provides this environment too, called (imaginatively) Virtual Machines.

Once a VM is set up, the methodology for deploying Liberty and applications on it is the same as previously described for local deployment. The benefit of this approach is the ability to request and provision hardware resources from a pool as soon as they are required with no constraint over what goes into the VMs. You could put Docker containers here too if you wanted to but, unlike IBM Containers, you’d also be responsible for providing and configuring the Docker environment itself.

Choose your VM size, choose your operating system, fire up the VMs, and install your software stack into them, exactly as you would on premise but with cloud-provided compute resources. The set-up time here is higher than the other two options but this is a topic we’ll be coming back to in a new article soon about rapid provisioning of WebSphere VMs on Bluemix.

In conclusion

Cloud provides choices and WebSphere Liberty runs Java EE 7 the same in each environment – whichever one you pick. It protects the application from needing to know or care about which cloud it’s running in, whether it’s a PaaS, an IaaS or built into a Docker image in a CaaS cloud. ÉgalitĂ© for all clouds. And none of that mort.

2 comments on"WebSphere Liberty, égalité, fraternité – in all clouds"

  1. You’re right – we will be updating the sample server.xml config to websocket-1.1 and I jumped the gun a little here. You can either do as you suggest or else grab the websocker-1.0 feature from the repository instead of websocket-1.1 – it doesn’t matter so long as the feature used and sample config are consistent.

  2. The websocket sample server.xml required the websocket-1.0 feature instead of the websocket-1.1 feature described here. Changing the feature in server.xml to websocket-1.1 allowed the sample to start.

Join The Discussion

Your email address will not be published. Required fields are marked *