Prepare for IBM pureapplication System (ii)

Is your application ready for virtualization?

Brief introduction

In the previous installment, part 1th: Migration Overview, you saw how IBM pureapplication system supports virtual applications and virtual systems. In short, the difference between the two is the trade-off between the level of control and the level of automation. In this article, we'll explore how to determine which deployment options are best for your particular application.

Advantages and limitations of virtual applications

A virtual application is a way to deploy a JEE application that leverages a set of policy decisions to determine how the application should extend and use the resources of the Java virtual machine (JVM). When you deploy an application as a virtual application, you also take advantage of a set of built-in shared services to handle some of the details, such as load balancing and HttpSession management.

However, the advantages of these automation are at a cost. The topology of the application (for example, how many application servers are run at a time, which server handles which types of requests, and so on) will be proactively managed by Pureapplication System. This means that you may not be able to isolate applications into the WEB layer running the servlet, and in the EJB layer that runs remote EJBS. This may not be a problem for many applications, but this can be a serious problem for legacy applications that rely on the features of multi-tier packaging or specific application topologies. On the other hand, the cost is to support only certain programming models. If the application requires greater flexibility, the pureapplication system also supports virtual systems.

Advantages and limitations of virtual systems

Virtual Systems This mechanism creates a template or pattern of a complete topology built through virtual mirrors. When you build a virtual system, you can take advantage of the Hypervisor Edition mirrors provided by IBM, or you can use the IBM Tivoli ICON tool to build your own mirrors using the basic RHEL mirrors.

Alternatively, you can take advantage of the capture and extend feature of Pureapplication System, which allows you to start with a virtual image and add additional software to the mirror before you package it for later use. Another key consideration when building a virtual system is that you can add your own scripts to the virtual system. If you want to deploy your application to a topology pattern that you have already created, you need to write a deployment script that can be executed when you deploy the virtual system instance to the Pureapplication system hardware instantiation process.

Choose the Right method

In most cases, it is not complicated to migrate applications to Pureapplication System. However, the key to the migration process is to understand whether you need to reasonably choose the right way to migrate your application. Pureapplication system supports a variety of methods for deploying applications. Choosing a method that brings the best results through minimal workloads is the most important decision that needs to be made during the migration process. In the process of migrating many existing ISV applications, we find that the easiest way to do this is to ask a series of questions:

Are you building a new application?

The reason to answer this question first is very simple: you need to take advantage of the simplest and most convenient deployment mechanism. As mentioned earlier, the simplest deployment model that Pureapplication System provides is a virtual application. If you are building new applications and have the opportunity to influence decision making for application-related technology and design choices, select the options that make your application compatible with virtual applications.

In most cases, however, the application you are dealing with every day is not an untapped new application. You often need to deal with existing applications that have been built and run in an existing environment. You must then consider the next question.

Is this a WEB application?

This is a seemingly simple and actually hidden problem. The real meaning of this question is "does this application only get inbound HTTP or HTTPs requests?" "This definition consolidates a variety of different patterns within application development." The implication might be as follows:

An application provides RESTful services to the user interface written using JavaScript and AJAX technology.

A WEB service provider that implements SOAP services for external clients on the Internet.

A traditional WEB application built using servlet and JSP.

However, this definition does not include certain application types, for example, when using this definition, the Java client-server application that connects to a Java-rich client that is connected to the back-end EJB via RMI or RMI/IIOP is defined as a WEB application, which leads us to the next Problem.

Do you use remote EJB?

EJB has been a very useful part of the JEE programming model almost from the moment of its inception. But while getting the remote EJB advantage, you're paying for the complexity of the application topology. The application server must also handle HTTP incoming traffic sent to your servlet, JSP, and Web service, and RMI/IIOP incoming traffic from the EJB client. Typically, this is done by building a two-tier application server, a layer dedicated to HTTP traffic, and another layer dedicated to RMI traffic. To simplify processes using virtual applications, you must discard some of these topology options. So, as we discussed earlier, if you need to use a remote EJB, you should use these topology options whenever you can use a virtual system.

Is your application packaged in a standard way?

Again, this is a seemingly simple and actually hidden problem. The meaning of the "standard Way" representation is: Is it packaged as an EAR file, WAR file, ZIP Archive, or EBA (OSGi Enterprise Bundle Archive)? Although the JEE standard packs an application as an EAR or a WAR file, and the OSGi Standard introduces the EBA archive, many applications are still not packaged in this way, but are provided as a "decentralized" directory structure. This may be true for simple servers such as Tomcat, but using a non-standard approach can cause you to encounter resistance when migrating to a new JEE server, such as a server that supports virtual applications. Therefore, if you answer "no" to this question, you should repackage the application in one of these standard formats. Similarly, there are many other packaging strategies in WebSphere application server that you can use, such as server-related shared libraries. Similarly, in order to simplify the model, these options are not used in virtual applications. If you cannot avoid using these methods, you should consider using virtual systems.

Does your application use a standard JEE programming model?

It is often said that "one of the greatest advantages of standards is that there are many criteria to choose from". Unfortunately, in terms of programming models, this is a very appropriate statement. With the rapid launch of the new API, the Java community is flooded with a large number of JSR that have never been approved, widely accepted, and therefore cannot be a formal part of the JEE standard. The problem is that when using virtual applications, we want to simplify everything. Therefore, you must limit the supported APIs to a set of APIs that can be managed. If your application uses only standard APIs provided by JEE5, j2ee1.4, 1.3 or 1.2, OSGI, JPA, Jax-RPC, JAX-WS, and Jax-rs, there is no need to worry about this issue at all.

On the other hand, if you are programming for newer versions of JEE, such as JEE 6, or if you are using some kind of obsolete API that is buried deep in JCP, you may not be able to use your application as a virtual application. In view of the above issues, IBM's approach is to support the newer APIs with the Feature Pack. Therefore, if you are planning to take a newer version of the API, you might want to consider building a virtual system using WebSphere application Server V8 and consolidating the Feature pack when publishing Feature packs that support this API.