Editor’s Note: Today’s post, written by Shreekanth Joshi, AVP Cloud Computing at Persistent Systems describes how the company uses Windows Azure to develop and deliver Java based applications for their ISV customers.

Persistent Systems is a global company that specializes in software product and technology services. We focus on developing best-in-class solutions in four key next-generation technology areas: Cloud Computing, Mobility, BI & Analytics, and Collaboration. Persistent Systems has been an early entrant in the cloud space and has partnered with many pioneering start-ups and innovative enterprises to help develop and deploy various cloud applications. We’ve utilized our finely-tuned product engineering processes to develop innovative solutions for more than 300 customers across North America, Europe, and Asia.

Building on our SaaS capabilities and experience, we’ve established dedicated competency centers for leading cloud platforms. As active participants in the Windows Azure community, we have released Open Source Projects including:

Persistent Systems has recently launched a new open source project, CloudNinja for Java  as described below.

CloudNinja for Java

The demand for Java-based applications on Windows Azure is increasing as customers are realizing the openness of Windows Azure that can provide scalability and high availability to their Java applications. We get a lot of questions about from how to design various project components to manage single-tenant and multi-tenant applications, to how to integrate project components with Windows Azure services. The challenge often faced by our customers while learning Windows Azure is that there is only a limited amount of informative articles and code samples that cover platforms other than .NET.

Windows Azure is often perceived as being a .NET Cloud Platform, which isn’t true. This misconception is based on demos and how-to blogs that are written around Microsoft Visual Studio. As it turns out, Windows Azure provides virtual machines that are either Windows Server 2008 SP2 or Windows Server 2008 R2, meaning that most of the Windows-based executable or scripts can be run on Windows Azure. 

To increase awareness about the openness of Windows Azure, we recently released CloudNinja for Java, a reference application to illustrate how to build a multi-tenant application for Windows Azure. CloudNinja for Java encompasses the following features and functionalities: 

  • Tenant on-boarding
  • Tenant-level customization (for example, managing logos)
  • Per-tenant data isolation
  • Per-tenant metering
  • Providing support for log-in via different identity providers. For example, Yahoo!, Google, and Windows Live ID
  • General purpose task scheduler

This application is built on several common OSS libraries, such as Spring, Hibernate, Log4j and jqPlot.

The project runs in Windows Azure and was developed entirely using Windows Azure Plugin for Eclipse with Java. Here is the illustration that depicts the architecture of CloudNinja.

We utilized various Windows Azure services in the development and deployment of CloudNinja for Java. Some of the most important ones are:

We believe that CloudNinja for Java will be beneficial to the Java community and will encourage Java developers to create their own applications for Windows Azure.

When deploying a Java application for Windows Azure, there are a few things to consider:

  • Whether to bundle 3rd-party tools and runtimes with deployments
  • Monitoring an application
  • Dealing with missing SDK functionality

Whether to Bundle 3rd-party Tools and Runtimes with Deployments

Windows Azure plugin for Eclipse combines a Java application, along with a Windows Azure project, into a package that can be uploaded and deployed to Windows Azure. The Windows Azure project contains a startup script responsible for setting up the Java environment and starting the application, including:

  • WAR file deployment
  • Environment variable configuration Windows Azure plugin for Eclipse combines a Java application, along with a Windows Azure project, into a package that can be uploaded and deployed to Windows Azure. The Windows Azure project contains a startup script responsible for setting up the Java environment and starting the application, including:

Windows Azure plugin for Eclipse combines a Java application, along with a Windows Azure project, into a package that can be uploaded and deployed to Windows Azure. The Windows Azure project contains a startup script responsible for setting up the Java environment and starting the application, including:

  • Web Server setup (in our case, Apache Tomcat)
  • JRE setup
  • WAR file deployment
  • Environment variable configuration

When a Windows Azure virtual machine instance is started, the environment needs to be set up. This is done by the startup script. Since Tomcat and the JRE are not part of the Windows Server VM image, we need to provide these ourselves. It’s very easy to include these in the Windows Azure deployment package. However, adding Tomcat and the JRE adds about 70 MB to the package size, coupled the runtime applications to the deployment. This has a few issues:

  • It takes longer to upload the deployment package to Windows Azure.
  • If we ever want to update the version of Tomcat or the JRE, we have to redeploy the entire package. 

We don’t need to include Tomcat and the JRE with our deployment package. To avoid the abovementioned issues, we stored our runtimes in Windows Azure Blob storage. The startup script downloads Apache Tomcat and the JRE from the Blob storage and then starts Apache Tomcat. The download from the Windows Azure Blob storage to the virtual machine storage is extremely fast, since our virtual machines and storage accounts are in the same data center. The package size for such Java applications was reduced by the total size of Apache Tomcat and the JRE installable.

While upgrading our deployment to the latest Tomcat and JRE, we needed to copy new versions to the Blob storage. Then, using Windows Azure portal, we reimaged all virtual machines instances that host our application, and we were running the latest Tomcat/JRE version without having to redeploy any of our code! 

Monitoring an Application

Windows Azure provides a diagnostics monitor that’s able to capture performance counters, event logs, file directories, Windows Azure infrastructure logs and crash dumps. The default Windows Azure project with Java doesn’t offer diagnostics configuration. For CloudNinja for Java, we created a standalone utility that sets up specific performance counters we wanted to watch (mainly CPU utilization).

We also needed to look at Tomcat access logs and Storage Analytics logs to generate usage statistics for each tenant. To capture Tomcat logs, we configured Windows Azure Diagnostics to monitor files in the directory where Tomcat stores its access log files. The diagnostics monitor pushes the access logs to blobs, where we access them from a worker process later. This works extremely well, since we’re able to access logs for each running instance of Tomcat. Since these files are stored in Windows Azure storage, it’s easy to access them from external programs as well, so we could manually inspect the log files if something does not work as per our expectation.

When it comes to monitoring blob storage, the story changes a bit. In CloudNinja for Java, we store tenant logos in blob storage. We have image tags in our html output that point directly to these logos, which doesn’t go through a Apache Tomcat server, For capturing these blob accesses and related bandwidth, Windows Azure provides Storage Analytics. There are two types of analytics: Logging, which provides detailed statistics on every single blob access, and metering, which provides hourly rollups. Analytics are disabled by default. For CloudNinja for Java, we enabled logging for our Windows Azure Storage account. These logs provide details such as timestamp, source IP, blob being accessed, and result status (successful or failed access).  Storage Analytics is a great Windows Azure feature that was especially helpful for CloudNinja for Java, being a multi-tenant application for which we wanted to capture the tenant-level storage usage.

While debugging, logging is not always enough. We enabled remote access, allowing our developers to connect to the virtual machines that host our application. Through the Windows Azure portal, we can open up a Remote Access connection to any running instance. 

Dealing with Missing SDK Functionality

Some Windows Azure features are not yet provided in the Windows Azure SDK for Java. One such feature on which we really depend on is Access Control Services (ACS). We wanted to use ACS in CloudNinja for Java to allow tenants to login using one of several identity providers, such as Google, Yahoo! and Live ID. 

As it turns out, ACS has a complete REST-based management interface. With a bit of help from a REST library (Restlet), we were able to build ACS into CloudNinja for Java. The same technique could be used for any other REST-based feature in Windows Azure. Fortunately, the Windows Azure SDK for Java covers quite a bit today:

  • Service Runtime
  • Storage (blobs, queues, tables)
  • Service Bus

Summary

Windows Azure is a core technology for Persistent Systems, and we continue to build Java-based solutions for our customers. We successfully use almost every feature of Windows Azure in Java applications, without having to write .NET code. This is illustrated very well in CloudNinja for Java. For example, we interacted with the ACS Management Service even when the Microsoft’s Windows Azure SDK for Java does not have the API support for this service. We could successfully utilize the REST-based API to create relying party applications that interact with the ACS Management Service.  This REST-based approach really opens up opportunities to develop Windows Azure applications in any programing language. 

We encourage the Java community to refer CloundNinja for Java to build a multi-tenant application for Windows Azure.

Read the blog post, “Introducing CloudNinja for Java”, on the Persistent Systems blog for more information.