One of the aims of cloud computing is to shield developers from the complexity of understanding and managing hardware and software infrastructure, allowing them to concentrate on their applications' functionality. This goal is achieved to varying degrees by Infrastructure as a Service (IaaS) clouds and Platform as a Service (PaaS) clouds. IaaS clouds provide the hardware and allow you to bring your own software. PaaS clouds additionally provide software that typically lets you focus on building and deploying applications, handling the deployment of the infrastructure and middleware on your behalf. After a brief survey of PaaS and IaaS options for running Java in the cloud, this article gives you an in-depth look at what IBM is offering via the IBM Application Pattern for Java.

Java applications in the cloud

Most of the major cloud providers either allow or enable the use of Java technology in their cloud offerings. At one end of the scale is Amazon EC2, which is really an IaaS cloud. You deploy Amazon Machine Images (AMIs), which Amazon describes as "a special type of pre-configured operating system and virtual application software which is used to create a virtual machine within the Amazon Elastic Compute Cloud (EC2)." That is, you need to deploy either a self-built or prebuilt image that contains the software that you require, which could include a Java runtime.

Next on the scale comes the likes of Microsoft Azure and Salesforce.com Heroku. Both are PaaS clouds that provide a software environment and allow Java applications to be run. However, of the two, only Heroku provides that Java runtime for you by making OpenJDK 6 available. For Azure, you must provide your own Java runtime.

Google App Engine and Amazon Elastic Beanstalk both provide the most application offerings. You needn't worry about virtual machines and software installs; you just provide your application. However, you can only run web-based applications, and both services impose some restrictions on what those applications can do.

Back to top

Deploying into the IBM cloud

IBM's approach is to provide a set of technologies with both IaaS- and PaaS-type capabilities. At the IaaS end of the scale is the ability to deploy virtual appliances. A virtual appliance is a prepackaged software stack — containing operating system, software application, middleware, application and additional libraries, and metadata to configure and launch the software stack — in one image using the standard Distributed Management Task Force (DMTF) Open Virtualization Format (OVF) specification. It also supports the use of scripting to reconfigure the software stack contained in the appliance.

The more PaaS-like capabilities are provided by two types of workload patterns — virtual system patterns and virtual application patterns:

• A virtual system pattern is a topology-centric definition of a deployment. A Pattern Editor enables you to design a topology by defining a number of virtual-machine images, the software components to install on them, and the use of scripting packages (metadata) to configure them. You can do this by using either manually created virtual machines, imported virtual machines, or one of a number of IBM Hypervisor Edition images. Once the virtual system pattern has been created for a recurring topology with the configuration scripts for installing an application, you can then reuse it as a standard platform.
• A virtual application pattern is an application-centric definition of a deployment. A Virtual Application Builder lets you provision the application itself, along with the definition of any resources it requires through the use of components covering database connections, messaging queues, and so on, and policies covering scalability, service-level agreements (SLAs), and the like.

Figure 1 illustrates these three mechanisms for deploying to the IBM cloud:

Table 1 compares the characteristics of the three deployment mechanisms:

IBM cloud offerings

Virtual appliances, virtual system patterns, and virtual application patterns can be used in all three IBM cloud offerings. The offerings range from an IBM-provided public cloud to an integrated hardware and software appliance used for a private cloud:

• IBM SmartCloud: The IBM SmartCloud is the IBM-hosted cloud, which can be private and specific to a given client, or public with provisioning done to individuals. You can think of it as an IBM-provided cloud solution.
• IBM Workload Deployer: The IBM Workload Deployer is a hardware appliance that provides provisioning and management capabilities for deploying virtual appliances and the workload patterns onto user-provided hardware, enabling existing hardware resources to have cloud capabilities. Think of it as bring your own cloud.
• IBM PureApplication System: The IBM PureApplication System is a workload-optimized integrated hardware and software appliance that provides provisioning and management capabilities, along with the optimized hardware into which the workloads are deployed. Think of it as a cloud-in-a-box solution.

The fact that the same deployment and management mechanisms are used for all three offerings means that it's easy to move your applications from one deployment offering to another — and that a hybrid model that uses two or more deployment offerings is possible.

Back to top

The IBM Application Pattern for Java

The IBM Application Pattern for Java is a virtual application pattern that enables you to deploy new and existing Java-based applications into the IBM cloud simply and quickly. The process is simple because predefined building blocks are provided and default capabilities are built in. That simplicity provides the speed; most Java virtual applications can be built in under three minutes!

Building blocks of a Java virtual application

The IBM Application Pattern for Java currently provides five simple building blocks you can use to create a new Java virtual application. They allow you to deploy your application and any additional libraries or configuration files it may require, configure the incoming and outgoing firewall, and add your application log files into the provided monitoring framework:

• Java application: This is the component that enables you to supply and configure the main part of a Java application. You must provide the application itself as an archive file — for example, a ZIP, TAR.GZ, or TGZ file — that contains the compiled Java application code. Once you supply the application, you declare the appropriate option for how the application will run: Main method (for example, com.ibm.sample.HelloWorld along with any parameters and additional classpath entries) or Command line if a startup script (such as /bin/start.sh) launches your application.

  Health Center

  IBM Monitoring and Diagnostic Tools for Java - Health Center (Health Center) is a free low-overhead diagnostic tool for monitoring an application running on an IBM Java Virtual Machine. It is available as part of the IBM Support Assistant. The IBM Application Pattern for Java uses its "late attach" capability to enable you to start monitoring at run time.

  In addition to the configuration of the Java application you are deploying, you can optionally add a JVM Policy, which enables you to alter the configuration of the underlying Java runtime. You can set minimum and maximum Java heap sizes, enable debug mode, enable Health Center monitoring, or add other Generic JVM Arguments. Enabling either debug mode or Health Center monitoring also causes the necessary firewall ports to be opened, and you can limit the range of IP addresses that are allowed to connect to the Java application.

• Additional archive file: This component allows you to add files to the virtual application by supplying an archive file that contains the additional files. It can be a Java archive (a JAR, WAR, or EAR file, for example) that will be deployed as-is into the specified location, or a normal archive file (such as ZIP, TAR.GZ, or TGZ) containing the additional files that can then be unpacked into the desired location. The Java archive option is useful for adding additional components such as JDBC drivers or deploying a web application if the main Java application is an application server such as Apache Tomcat. The normal archive option is useful for adding or overwriting default configuration files, such as a server.xml file, to change default port usage or add user IDs.
• Generic listener: By default, the deployed application doesn't allow any incoming or outgoing network traffic. The generic listener component enables you to configure the firewall for incoming network traffic. Note that this only configures the firewall and does not cause an HTTP server to be deployed. It does, however, allow you to use an IP/netmask to limit the range of IP addresses that can connect to the application.
• Generic target: The generic target is the counterpart to the generic listener but is used for configuring outgoing network connections. It likewise lets you specify an IP address or range of IP addresses that the application can connect to. For example, if the application connects to a database, then a generic target is required to allow the connection.
• Monitored file: The monitored file component lets you add one or more files into the Log Viewer of the workload console provided by the IBM SmartCloud, IBM Workload Deployer, and IBM PureApplication System user interface. The monitored file component allows the use of wildcards, and several monitored file components can be added if multiple files or multiple directories need to be added to the Log Viewer. For example /logs/*.log will add any file in the logs directory with a .log suffix to the Log Viewer.

The combination of these five simple components makes it possible to build and deploy a surprisingly wide range of server-based Java virtual applications.

Expert integration: Default capabilities

In addition to providing a set of components that can be used to deploy the application easily, configure the JVM, allow incoming and outgoing network connections, and set up monitoring of files, the pattern also builds in a number of default capabilities based on expert knowledge of deploying Java applications. These include:

• Life-cycle monitoring: The state of the Java application is monitored and displayed as part of the workload console in the IBM SmartCloud, IBM Workload Deployer, and the IBM PureApplication System. The UI shows whether the application is running, whether it has errored (exited with a nonzero return code, failed because of a crash or OutOfMemoryError) or exited cleanly. In the case of an error, the predefined logging, monitoring, and First Failure Data Capture (FFDC) capabilities can help you determine why the error occurred.
• Predefined logging and monitoring: In addition to any monitoring requested via the Monitored file component, all deployed applications have their stdout, stderr, and verbose:gc data captured and available via the Log Viewer. Predefined monitoring is also available via the Monitoring tab in the Virtual Application Console, and you can connect the Health Center live-monitoring tool. If the use of Health Center has not been enabled via the JVM Policy at startup, you can enable it at run time.
• Predefined FFDC: If an error occurs in the deployed application, certain data collection is predefined. This includes the generation of javadump and system dump files as appropriate, along with the automatic running of the jextract utility against system dumps.

Back to top

Creating a Java virtual application: Hello World

With the provided set of building blocks and default capabilities, creating a Java virtual application is a relatively straightforward task. I'll use the traditional Hello World example to show how to create and deploy a Java application using the IBM Application Pattern for Java.

How to build and deploy an application

Before you can deploy an application you need to write it and then package it as an archive (ZIP, TAR.GZ, or TGZ) file. Listing 1 shows a simple implementation of HelloWorld, which adds a delay before exiting to provide time for connecting a monitoring tool:

package com.ibm.sample;

public class HelloWorld {

    public static void main(String[] args) {
        /* Print "Hello World!" to stdout */
        System.out.println("Hello World!");
        try {
            /* Sleep for 5 minutes */
            Thread.sleep(5 * 60 * 1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

After compiling this code, you have a com.ibm.sample.HelloWorld.class file that you must add to a ZIP file. HelloWorld.zip (available for download) contains just one file: /com/ibm/sample/HelloWorld.class.

Now that you have the application, the next step is to create a new virtual application using the IBM Application Pattern for Java:

1. Open the Virtual Application Pattern panel using Patterns -> Virtual Applications.
2. Select Application Pattern Type for Java 1.0 from the Virtual Application Patterns pull-down menu.
3. Click the + button to create a new virtual application.
4. Click the Start Building button to start building a new application from a blank template.

The Virtual Application Builder opens in a new window. It contains a palette of available components on the left-hand side, a canvas in the middle for building the application, and a panel on the right-hand side for configuring application components. Complete the following steps, illustrated in Figure 2, to create the virtual application for HelloWorld:

1. Drag a Java application widget from the palette to the canvas.
2. Optionally, fill in the Name field with a name (such as HelloWorld) for the Java application.
3. From the Archive File field in the configuration panel, browse to the location on your local system of the HelloWorld.zip file.
4. From the Application launch type list, choose Main Class.
5. Under Main Class, specify the name of the main class for your application (com.ibm.sample.HelloWorld in this example).
6. Optionally, add a JVM Policy using the + icon on the Java application widget. Use the slider in the configuration panel to configure the Java heap size, and check the Enable Health Center box to enable Health Center monitoring.

Click Save in the top left-hand corner to save a virtual application for HelloWorld, giving it a name and description.

Returning to the Virtual Application Pattern window, deploy the new virtual application:

1. Select the HelloWorld application from the left-hand list of applications.
2. Click the Deploy button.
3. Select the appropriate environment profile or cloud group, and click OK.

The application is now being deployed and will be available shortly!

How to monitor your application: Log files

Once you have a deployed application, it appears in the Virtual Application Instances panel. The following steps (shown in Figure 3) enable you to monitor the state of your Java application deployments:

1. Select Instances -> Virtual Applications to open the Virtual Application Instances panel.

2. Ensure that Application Pattern Type for Java 1.0 is selected in the Virtual Application Instances pull-down menu.

   All of your deployed Java virtual applications should be listed in the left hand panel, along with a high-level view of their status: Running, Stopped, or Error. To get more details about your virtual application:

   1. Select the application from the left-hand panel.
   2. Click the Log link under VM Status to open the Log Viewer.
   3. Click the Manage icon to open the Virtual Application Console.

In the Log Viewer (shown in Figure 4), you can use the tree view in the left-hand panel to browse the log files for the deployed application. The following steps show you the log files of the Java application itself:

1. Select JAVA -> /opt/java-deploy from the tree view.
2. Select stdout.log to show the "Hello World!" message from the application in the main panel.
3. Optionally, select verbosegc001.log to see the garbage-collection history.
4. Optionally, select the download symbol on the right-hand side of the filename to download the file.

Any dump files will also show up in this part of the view, along with any files added to the Log Viewer using the Monitored file widget.

How to monitor your application: Live monitoring

In the Virtual Application Console, you have the option of using:

• The Monitoring tab to see some live monitoring of the deployed application's resource usage
• The Logging tab to open the Log Viewer
• The Operation tab to make modifications to the running application

The IBM Application Pattern for Java allows you to enable Health Center to be attached to the application, even if it wasn't configured via the JVM Policy in the Virtual Application Builder. Use the following steps (shown in Figure 5):

1. Select the Operation tab.
2. Select the JAVA entry from the list of available operations.
3. Expand the Attach Health Center item.
4. Optionally, specify the port that Health Center can connect on.
5. Optionally, specify the IP address or IP/netmask that the Health Center client can connect from.
6. Click the Submit button.

The IBM Monitoring and Diagnostic Tools for Java - Health Center client that is available in the IBM Support Assistant can then be connected to the application to provide very-low-overhead monitoring of what the application is doing. It also provides a route for requesting dump files to be generated and enables a higher level of data collection — for instance, allocation profiling.

Back to top

Java Virtual Application Pattern usage scenarios

It was convenient to use HelloWorld to show the steps for deploying a Java application as a virtual application. But HelloWorld isn't exactly a useful example of a real-world application, particularly when it's being deployed into a server-based cloud environment. Now I'll provide a number of far more useful examples to show how existing applications can be moved into the cloud via the IBM Application Pattern for Java. They're all based on using open source Java applications, so you can try out the examples with no licence cost.

Open source middleware: Apache Tomcat

You can use the IBM Application Pattern for Java to create a virtual application or any Java-based middleware by providing the middleware as part of the application. A good example is deploying Apache Tomcat and a web application. You can do this in one of two ways: bundle both into an archive file you upload into the Java application component; or, deploy Apache Tomcat as the Java application, and deploy the web application using an Additional archive component. The second method is usually preferable, because it doesn't require the manipulation of archive files, and you can save the Apache Tomcat configuration as a template, just adding the web application to create a new virtual application.

As an exercise, you'll create a deployment of Apache Tomcat 7.0.27 with a sample web application added separately in the Virtual Application Builder. Start by downloading and saving both a Tomcat archive from Apache.org and the sample web application (simpleapp.war) I've provided with this article (see Download). Then follow these steps (illustrated in Figure 6):

1. Drag a Java application widget from the palette to the canvas to be the Tomcat server. Optionally, give it a name (such as Apache Tomcat 7.0.27 Server).
2. In the Archive File configuration field, browse to the Tomcat archive that you've downloaded from Apache.org (apache-tomcat-7.0.27.tar.gz, for example). Use this file exactly as-is; you don't need to make any changes to it.
3. Select Command Line as the Application launch type for the Java application component and specify the Tomcat launch script — for example, /apache-tomcat-7.0.27/bin/startup.sh. This is the launch script — provided in the download from apache.org — that is used to start the Tomcat server.
4. Add a Generic listener by dragging it from the Other Components under the palette's Assets onto the canvas, and configure it to allow connections on port 8080. This will open in the firewall for incoming connections on port 8080 that Tomcat will listen to.
5. Drag a Monitored file from the Other Components list to the canvas and configure it to monitor the Tomcat log files — for example, /apache-tomcat-7.0.27/logs/*.log. This adds the log files created by Tomcat into the Log Viewer. The use of the *.log wildcard means that it will pick up all the .log files in that directory: catalina.log, manager.log, and so on.
6. Add an Additional archive file for deploying the simpleapp.war web application. Give it a Deploy path value of /apache-tomcat-7.0.27/webapps/ and chose Java archive file as the Type of archive file.

You now have an instance of Apache Tomcat with the SimpleApp web application that you can deploy. Once deployed, it will be available at the supplied IP address, and port 8080 (http://IP address:8080/ will give the Tomcat front page.

Rather than adding the SimpleApp web application, it would also have been possible to add the Additional archive file component and configure it with the Deploy path but not add the web application. The virtual application could then be saved as a reusable template with the Additional archive file option as the only unlocked (modifiable) field in the template. Subsequent users could then create their own application from the standard Tomcat 7.0.27 profile, with only the ability to add their web application.

Cloud-based load testing: Apache JMeter

Another usage scenario for the IBM Application Pattern for Java is cloud-based load testing, whereby cloud-based engines are deployed for load-testing web (or other) applications. For this purpose, you can use the IBM Application Pattern for Java to deploy Apache JMeter and use its server load-testing engine capability.

Assuming you've downloaded and saved a JMeter archive from Apache, follow these steps (illustrated in Figure 7) to create a deployment of Apache JMeter 2.7 in server mode in the Virtual Application Builder:

1. Drag in a Java application widget from the palette to be the JMeter server. You can optionally give it a name, such as Apache JMeter 2.7 Server.
2. From the Archive File configuration field, browse to the JMeter archive that you've downloaded from Apache.org — such as apache-jmeter-2.7.tar.gz. You don't need to make any changes to the download.
3. Select Command Line from the Application launch type list and enter /apache-jmeter-2.7/bin/jmeter-server -Jserver.rmi.localport=6437 in the Command Line field. This is the server launch script — provided in the download from apache.org — that is used to start the JMeter server, along with an additional option that sets the RMI connection port rather than using a randomly assigned one (which would cause problems with the firewall).
4. Add one Generic listener for RMI Registry on 1099 and another for RMI connection on 6437 (specified using the localport option). Two generic listeners are required because you can only specify a single port in each. The RMI Registry defaults to port 1099, and the RMI connection port was specified using the Jserver.rmi.localport=6437 option on the command line.
5. Add a Generic target on 9080 for the application server (AppServer in Figure 7) hosting the web application that you'll test. A server IP/netmask of 0.0.0.0/0.0.0.0 allows for any application-server IP address. The generic target component with a port of 9080 means that it can send traffic to port 9080 on the target server, which is the port that an application deployed using the Web Application Pattern will use. This is useful when you do not yet know where the target application will be. You can also limit it to a specific IP address or range of IP addresses.
6. Drag in a Monitored file and configure it to monitor the JMeter log files, such as /jmeter-server.log, the default JMeter log file that shows the status of the load tests being run through the server.

Once the JMeter server application has been deployed, you can run a load test from a client/desktop install of JMeter by launching the client with the -Jremote_hosts=comma-separated server list option and using the Run -> Remote Start option inside the JMeter Client UI to launch the testing from the servers in the cloud.

You can run a sample JMeter test plan (see Download and the associated footnote) against a deployment of the "Sample Web application only" sample provided as part of the Web Application Pattern Type 2.0 pattern, using the following steps:

1. Run JMeter from the command line with the address of the JMeter server deployment — for example:
   jmeter -Jremote_hosts=172.17.108.222.
2. Inside JMeter, click File -> Open to open a test plan.
3. Select the SampleWebAppTestPlan.jmx file.
4. Select Test Plan -> Thread Group -> HTTP Requests Default from the tree view in the left-hand panel.
5. Modify the Web Server: Server Name or IP address in the main panel to be the address part of the endpoint for your deployed "Sample Web application only" sample.
6. Modify the HTTP Request: path to be any other part of the endpoint address before /webapp/.
7. Select Run -> Remote Start -> JMeter Server Address to start the test.

The following steps enable you to see if load is being driven against the "Sample Web application only" sample:

1. For the deployed sample, select Manage to launch the Virtual Application Console.
2. Select Monitoring > Middleware.
3. Select the web application item from the list — for example, Web-Application-was.11342004774648.

The main panel should then display a number of graphs that can be used to monitor the deployed web application. If the web application is receiving load from the JMeter server, then the Web Applications Request Count graph should show requests being serviced, as illustrated in Figure 8:

Other use cases

It's possible to create virtual applications for a number of other use cases and middleware in addition to virtual application deployments using Apache Tomcat and Apache JMeter. These include:

• Eclipse Jetty
• JBoss
• Apache ftpServer
• Apache Derby
• Apache MINA

Usually, the challenge for creating any new virtual application using third-party middleware is knowing which incoming and outgoing firewall ports need to be configured using the generic listener and generic target components. If the product documentation doesn't list the ports that need to be opened, then you can either deploy the application and check the product logs for SocketExceptions, or deploy the product locally to use tools such as netstat to see which ports are in use.

To help you get started, templates for Tomcat and JMeter are provided with this article (see Download), and templates for Eclipse Jetty, JBoss, Derby, ftpServer, and more will become available from the IBM Application Pattern for Java blog (see Resources). To use the templates, simply download the appropriate middleware package, upload it into the Java application component via the Virtual Application Builder, and hit Deploy!

Back to top

Conclusion

The IBM Application Pattern for Java is neither a IaaS or PaaS offering in the truest sense of either term. The flexibility it provides in allowing the deployment of any application involves a trade-off: The user must define some topology and — when a middleware service is required — provide the middleware. In this sense it fits more closely into the IaaS definition. However, it does also have a number of platform features: a runtime for deploying any pure Java-based application in a simple and repeatable fashion with built-in expertise covering tuning, life-cycle management, and application monitoring. Any existing Java application now has the potential to be moved into a cloud-based environment easily. Once it has been moved, it can be reused as a platform or as a modifiable template that does become more like a PaaS offering.

Back to top

Downloads

Information about download methods

Note

1. This test plan runs against the "Sample web application" supplied as part of the Web Application Type 2.0 pattern. You will need to adjust the IP address and paths.

Resources

Learn

• IBM Application Pattern for Java: Visit the InfoCenter for the IBM Application Pattern for Java.
  
  
• IBM Workload Deployer: IBM Workload Deployer is a hardware appliance that provides access to IBM middleware virtual images and patterns.
  
  
• IBM Workload Deployer: Pattern-based Application and Middleware Deployments in a Private Cloud: This IBM Redbooks publication looks at two different aspects of customizing virtual systems for deployment into the cloud.
  
  
• "IBM PureSystems Raise the Bar for Preintegrated Systems": Learn more about IBM expert integrated systems from this industry-analyst blog.
  
  
• "Java PaaS shootout" (Michael Yuan, developerWorks, April 2011): Compare how three PaaS offerings support Java technology.
  
  
• developerWorks Java technology zone: Find hundreds of articles about every aspect of Java programming.
  
  

Get products and technologies

• IBM PureSystems trial: Try the IBM Application Pattern for Java using this trial, hosted by IBM SmartCloud Application Services.
  
  
• IBM Monitoring and Diagnostic Tools for Java - Health Center: Use the Health Center tool to monitor your application.
  
  
• Apache Tomcat: Download a Tomcat archive.
  
  
• Apache JMeter: Download a JMeter archive.
  
  

Discuss

• IBM Application Pattern for Java blog: Get new application templates and provide feedback to the development team.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Chris Bailey is a member of the IBM Java Technology Center team at the Hursley Park Development Lab in the United Kingdom. As the technical architect for the IBM Java service and support organization, he is responsible for enabling users of the IBM SDK for Java to deliver successful application deployments. Chris is also involved in gathering and assessing new requirements, delivering new debugging capabilities and tools, making improvements in documentation, and improving the quality of the IBM SDK for Java.

Rate this article

Comments

Back to top

Table of contents

• Java applications in the cloud
• Deploying into the IBM cloud
• The IBM Application Pattern for Java
• Creating a Java virtual application: Hello World
• Java Virtual Application Pattern usage scenarios
• Conclusion
• Downloads
• Resources
• About the author
• Comments

Next steps from IBM

Learn more, join the cloud community

---

• Community: Cloud computing conversations led by IBM community members
• Buy: Try IBM software on IBM SmartCloud Enterprise

Dig deeper into Java on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers