Deploying Java applications on Windows Azure with ant

This article discusses the use of the popular ant tool:

• Build Java applications for Windows Azure with ant
• Laying out collected packages in Windows Azure and using a local emulator

Before you begin, it is recommended that you familiarize yourself with the general information about Windows Azure - Windows Azure E-Book - Microsoft Cloud Platform and 24 articles on Windows Azure in Russian . To work with Java applications in Windows Azure, we will use the Windows Azure Starter Kit for Java (for Eclipse users there is a Windows Azure Plugin for Eclipse plugin ). Windows Azure Starter Kit for Java uses Apache Ant as a tool during the build process - its documentation is available here: Apache Ant manual (there are materials available in Russian: Ant in 10 steps (make ant java) orApache Ant 101: Instant build of Java programs ). The article describes the use of the Windows Azure emulator - you can install it in the Downloads section of the Windows Azure site (the Emulators link), for more information, see Windows Azure Emulators On Your Desktop

Windows Azure Starter Kit for Java

In the Downloads section there is a link to the ZIP file inside which contains the project template - to get started, just unzip the contents of the archive. In addition to the standard Java components, there are several files inside the project that make working with Windows Azure easier.

Key elements of the project template

File	Description
.cspack.jar	Windowsazurepackage ant task implementation
ServiceConfiguration.cscfg	Windows Azure Service Configuration File
ServiceDefinition.csdef	Windows Azure Service Configuration File
package.xml	Configuration file (script) for ant
WorkerRole1 \ approot \ HelloWorld.war	A simple upload implementation example.
WorkerRole1 \ approot \ startup.cmd	This start script (batch file) is run every time the start of the upload process starts. In this file, you need to implement all the actions that you need to do when you start the WindowsAzure instance — such as installing and configuring individual components, for example, installing and starting the Java application server.
samples	This directory contains examples of installing and configuring popular Java application servers (Tomcat, JBoss, GlassFish, Jetty, etc.) - these examples can be used to create the desired startup.cmd implementation.
WorkerRole1 \ approot \ run.cmd	This script (batch file) is run every time after the upload process starts. This script is supposed to be executed all the time while the application is in working condition. In the event that an exit from this script occurs, Azure believes that the instance data needs to be restarted. The template implements an example run.cmd where you can see a call to another script - util \ whileproc.cmd with the java.exe parameter. The whileproc.cmd script (located in WorkerRole1 \ approot \ util) checks every 15 seconds to check that the java.exe process launched.
WorkerRole1 \ approot \ util unzip.vbs	The script (visual basic script) implements the unpacking of zip archives - this script is useful when implementing startup.cmd in cases where it may be necessary to unpack the zip archives.
WorkerRole1 \ approot \ util download.vbs	The script (visual basic script) implements the loading of the specified URL into the approot folder. This script can be very useful when implementing startup.cmd in cases when you need to download any data - it can be downloading a large distribution kit (in order not to include this distribution kit in our application package for Windows Azure), for example, a Java server distribution kit. A link (URL) can point to any resource that does not require authentication (including data located in blobs with anonymous access - see Restricting Access to Containers and Blobs ) or links in which all the information necessary for authorization is contained in URL link itself (for example, it can be blobs with shared access signature enabled ).
cert \ SampleRemoteAccessPrivate.pfx	An example of a private key with a certificate that can be downloaded through the Windows Azure web portal to allow Remote Desktop access to a running instance of Windows Azure - see Remote Desktop or Microsoft Windows Azure. Fast start. Part 4. Inside the Windows Azure Virtual Machine
cert \ SampleRemoteAccessPublic.cer	An example of a public key with a certificate - this key must be used in conjunction with a private key to gain access through Remote Desktop - for more details, see Remote Desktop or Microsoft Windows Azure. Fast start. Part 4. Inside the Windows Azure Virtual Machine

Choosing a start script implementation

The project template allows you to use various Java application servers: Tomcat, Jetty, JBoss and GlassFish (use with other application servers is also possible, but with some configuration changes). To configure the template for a specific Java server, you need to take the appropriate start script (they are in the samples folder) and copy the contents of this script to the startup.cmd script (thus completely replacing its contents). Further, if you need to make any changes to the startup script, it is recommended to immediately make them in startup.cmd

Adding the JDK.zip package to approot

For an example, we will consider using Sun Oracle's JDK v1.6 , but in general, just like with a Java server, we have the freedom to choose another JDK. I note that since the Windows Azure platform is 64-bit in terms of computing resources, it is necessary to use the 64-bit version of the JDK and the corresponding version of the Java server. This also means that to use the 64-bit JDK and develop / test in the Windows Azure emulator on the computer on which you will be developing, you need 64-bit Windows. First, install the selected JDK on your computer, then pack the JDK folder into the JDK.zip file so that there is one folder called JDK inside the archive and all the contents of the installed JDK (including the JRE) are inside this folder (see alsoWhere can I get the latest JRE / JDK as a zip file ). Once jdk.zip is created, you need to copy it to approot:

Adding a package with a java server to approot

The next step is to add the selected Java application server to the approot - to minimize the changes to the startup script, it is recommended to use the default names. Depending on the selected server, rename the packed archive to ZIP with Java server in accordance with the table

Server	File name
Apache Tomcat 7.x	tomcat7.zip
GlassFish Server OSE 3.x	glassfish3.zip
JBoss Application Server 6.x	jboss6.zip
JBoss Application Server 7.x	jboss7.zip
Jetty 7.x	jetty7.zip

Then copy this ZIP file to approot (for example, tomcat7.zip is taken here):



The next step is to set the correct value for the SERVER_DIR_NAME variable in the start script - the variable must point to the directory into which the Java server will be unpacked. As a rule, it is enough to set it equal to the name of the folder with the Java server inside the ZIP file. The reason the folder name for unpacking the Java server is best chosen equal to the folder name inside the ZIP is that, as a rule, different releases of the Java server have a strong relationship between the version and the directory name. The examples in the samples contain values ​​that may no longer be relevant and do not correspond to the latest releases of Java servers, therefore it is recommended to update the value of SERVER_DIR_NAME in accordance with the version used. For example, in the example for Apache Tomcat (file samples / startupApacheTomcat7. txt) for the value of this variable, the value SET SERVER_DIR_NAME = apache-tomcat-7.0.22 is taken. It is likely that by the time you read this document version 7.0.22 will not be the last, and accordingly you will use the new version (for example 7.0.29), so do not forget to update the value of the SERVER_DIR_NAME variable accordingly (in this case, SERVER_DIR_NAME = apache -tomcat-7.0.29). If this is not done, it is very likely that the application will not even be able to correctly deploy to the running instance. I would also like to note that a common source of errors is the use of extra (and inconspicuous) spaces when initializing this variable - please keep in mind that the initialization line should look like this (without double quotes) "SET SERVER_DIR_NAME = apache-tomcat-7.0.29" and after sign =, as well as after the end of the initialization line (after character 9 in this case) there should be no spaces. After this step, you can already try to build and run this project in the local Windows Azure emulator - you should see that the Java server is starting and the HelloWorld application is expanding correctly. HelloWorld application is included in the default template - you can see it in approot, the WAR_NAME value in the start script also points to this application. After you try to start the Java server and deploy the "Hello World" application, you can proceed with the following steps - if you do not plan to connect another Java application, you can skip the next section and proceed immediately to the assembly and testing of the application.

Preparing a Java Application

To begin with, I would like to once again draw attention to the fact that projects in Windows Azure are deployment projects, and not Java programming projects (moreover, a Windows Azure project may not contain Java code at all). That is, it is assumed that there is already a Java application that you are developing and it is possible to create a WAR file that contains the application. Then the steps to include the application in the Windows Azure project will be as follows:

1. Create a WAR file with the application (for example, MyWebApp.war).
2. Copy this WAR file to approot (this step can be added to the procedure for creating WAR files)
3. In the startup script startup.cmd, modify the WAR_NAME variable accordingly - in our case WAR_NAME = MyWebApp.war

As with SERVER_DIR_NAME, be careful and check that there are no spaces after = and at the end of the line (after .war). The content approot should look like this:

Build and test in Windows Azure emulator

Open a Windows command prompt, go to the folder where the project is located and run ant: This command tells ant to use the information from package.xml to build the application. The build process can take some time and be quite long, depending on the size of the application and the performance of the computer. If the assembly was successful, you will see a message in the window with the command line saying "BUILD SUCCESSFUL", it may look like this:
ant -buildfile package.xml






By default, the project is configured for local uploading to the emulator (the setting is specified by the packagetype parameter in the package.xml file - by default, packagetype = "local"). A folder named "emulatorTools" is created immediately after the "deploy" folder during project build. The "emulatorFolder" folder contains two scripts (batch files) that allow you to more conveniently work with the Windows Azure emulator - upload the project, restart the service, start it:

• RunInEmulator.cmd - this script starts the Windows Azure cloud emulator on the local computer and puts the project in this environment. If the project uses storage and you plan to use the Windows Azure storage emulator, you need to run the Azure Storage emulator separately.
• ResetEmulator.cmd - removes all running application instances in the local Azure Compute Emulator, unlocks the files used by the emulator and turns off the application factory. This command must be used at the end of testing or debugging the application.

The last step is to start the server in the emulator:

cd emulatorToolsRunInEmulator

If everything went well, the application will be launched on port 8080 - this can be checked by opening the link http: // localhost: 8080 / MyWebApp in a web browser

Project Changes for Layout on Windows Azure

In order to make the project available for work in the Windows Azure cloud, we need to make several changes in the package.xml file. This file has a special windowsazurepackage tag that defines the configuration of putting a project into a local or remote Windows Azure cloud environment.
<windowsazurepackage packagefilename="WindowsAzurePackage.cspkg" packagedir="${wapackagedir}" packagetype="local" projectdir="${basedir}" definitionfilename="ServiceDefinition.csdef" configurationfilename="ServiceConfiguration.cscfg"
>

Pay attention to the packagetype attribute - when the value of this attribute packagetype = "local" then the structure of the assembled project will be exactly the same as for use in the Windows Azure cloud, but the assembly itself will not be packaged for download, but on the contrary it will be prepared to run in the Windows emulator environment Azure If the value of the attribute packagetype = "cloud" then the assembly will be archived as a .cspkg file - through the Windows Azure web portal you can upload .cspkg and .cscfg files to the cloud and thereby upload and run the application in the cloud.

Laying out a project in Windows Azure

Putting the application into the Windows Azure cloud is quite simple - you go to the Windows Azure portal with your username / password and take two simple steps:

1. Download PFX certificates (if this has not been done before). This step is required to enable remote access to running virtual machines in the Windows Azure cloud through Remote Desktop — remote access is useful when developing, debugging, and testing applications in Windows Azure — see Remote Desktop or Microsoft Windows Azure for more details . Fast start. Part 4. Inside the Windows Azure Virtual Machine
2. Create a new deployment and load the .cspkg and .cscfg files that were created during the build process for the Azure application.

After completing these steps, the application should successfully deploy and run in the Windows Azure cloud. For more information on deploying to Windows Azure, see Microsoft Windows Azure. Quick start and Microsoft Windows Azure. Fast start. Part 2 . In the following articles, we will consider the use of remote access via Remote Desktop to work with Java applications in Windows Azure, as well as a more detailed discussion of the use of .cscfg and .csdef configuration files.

useful links

• Windows Azure Website
  
• Windows Azure E-Book - Microsoft Cloud Platform
  
• 24 articles about Windows Azure in Russian
  
• Windows Azure Development Center
  
• Microsoft Windows Azure Fast start