Planning your virtual application

Creating a virtual application consists of using the Pattern Builder to define and create the virtual application templates and patterns, and then deploying the pattern in the cloud environment. A deployed virtual application pattern is a virtual application instance.

First steps

Gather the application artifacts and necessary information to configure the cloud components.
  • For the web application component type, a Java™ Platform, Enterprise Edition (Java EE) artifact, such as a web archive (WAR) file, is required.
  • For the enterprise application component type, a Java EE artifact, such as an enterprise archive (EAR) file, is required.
  • For the database component type, a SQL script that can be deployed on an IBM® DB2® server is required.
  • For the user registry component type, an LDIF file that can be deployed on an IBM Tivoli® Directory Server is required.
  • For the generic target component type, the values for the target host and port are required.
Gather the necessary information to configure the quality of service (QoS) policies.
  • You can add a scaling policy if you want high availability.You can add a scaling policy if you want your virtual application to be elastic. Scaling is a virtual application runtime capability to automatically scale your application platform as the load changes. A scaling policy defines the conditions for processor, memory, response time, and database connections, under which scaling activities are performed for your application.

    Starting in IBM Cloud Pak Software Version 1.1.0.2, the Java virtual machine (JVM) heap can be scaled based on the relative time spent on garbage collection. Garbage collection is the process that reclaims memory occupied by objects that are no longer referenced by the application and returns memory to the JVM heap. The collection is triggered automatically and its behavior depends on the JVM garbage collection policy in use. The garbage collection is an overhead to the application because it pauses the JVM during its execution. This overhead (garbage collection time) can be estimated as the ratio between the average time the garbage collection takes to execute and the average interval that collections occur.

    The JVM heap-based scaling uses the garbage collection time as the metric to trigger the increase in the JVM heap and virtual machine memory. By providing more memory to the JVM, both the garbage collection interval and pause should increase, but the ratio should be smaller, resulting in a higher application throughput. Your choice of the threshold value to configure depends on several factors, including the JVM garbage collection being used, the type and intensity of workload, and so on. Ideally, a garbage collection analysis should be conducted on the application with expected regular load to define the initial heap settings and under heavy workload to define which garbage collection time threshold to use. Typically, when the time spent on garbage collection is greater than 10%, you should increase the JVM heap size to minimize the overhead on the workload.

    When the scale up condition is met, the virtual memory for the WebSphere® Application Server virtual machine is increased until the usage falls back into the configured range, or until the maximum virtual memory limit that is configured in the policy is reached. After the virtual memory increases, the WebSphere Application Server JVM heap size is adjusted automatically to take advantage of the extra virtual memory. The WebSphere Application Server process must restart to enable the new heap size configuration so that this configuration change can take effect. If there are multiple WebSphere virtual machine instances in the deployment, the application servers are divided into two groups and are restarted by using a rolling method to allow for the restart to occur without down time. If there is only one single WebSphere virtual machine instance in the deployment, there is no rolling restart and the WebSphere process will be restarted.

  • You can add a JVM policy to debug the WebSphere Application Server process by using an integrated development environment (IDE) like IBM Rational® Application Developer for WebSphere.

After you collect the necessary information and artifacts, you can begin by using the Pattern Builder to design and configure the cloud components and policies to create your virtual applications.

Limitations

If you plan to develop a customized plug-in to extend the functionality in IBM Web Application Pattern with additional configuration or update code, the following configurations are not supported:
  • WebSphere Application Server Network Deployment quality of service configurations.
  • Creating multiple application servers on the same virtual machine.
Your plug-in code can include more configuration changes within application servers if they do not conflict with the configuration changes made by Web Application Pattern. For example, you cannot delete a data source that is created by Web Application Pattern from your customized plug-in.