In the previous article, Part 1: Onboarding migrations overview, you saw how IBM® PureApplication® System supports both virtual applications and virtual systems. In short, the difference between the two is a tradeoff between levels of control versus level of automation. In this article, we will examine how you can decide which deployment option is best suited for your particular application.
Advantages and limitations of virtual applications
A virtual application is a way of deploying a JEE application together with a set of policy decisions that determine how the application should scale 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 built-in set of shared services that handle the details of issues, such as load balancing and HttpSession management.
However, those automated benefits come with a price. The topology of your application (for example, how many application servers are running at once, which server handles what type of requests, and so on) is actively managed by PureApplication System. This means, for instance, that you cannot separate your application into a Web tier running servlets, and an EJB tier running remote EJBs. For many applications, this is not an issue, but for older applications that either have relied upon a multi-tier packaging, or that rely on features of a specific application topology, this can be problematic. Another part of that price is that only certain programming models are supported. For those applications that require more flexibility, PureApplication System also supports virtual systems.
Advantages and limitations of virtual systems
A virtual system is a mechanism that creates a template or a pattern of an entire topology built from virtual images. You can use the IBM-provided Hypervisor Edition images in building your virtual systems, or you can build your own starting from a base RHEL image using the IBM Tivoli® ICON tool.
Another possibility is the "Capture and Extend" feature of PureApplication System, which allows you to begin with one virtual image and add additional software into that image before repackaging it for later use. Another key consideration in building virtual systems is that you can add your own scripting into the virtual system. If you want to deploy an application into a topology pattern you have created, you will need to script that deployment so that it occurs as part of the instantiation process of deploying a virtual system instance into the PureApplication System hardware.
Choosing the right approach
In most cases, onboarding an application to PureApplication System is actually not a complicated process. However, a key to making the most of your migration process is to understand that you need to correctly choose the right approach for onboarding your application. PureApplication System supports a number of different ways in which your application can be deployed. Choosing one that results in the least amount of work for the greatest benefit is the most important decision you can make in the migration process. What we have found in onboarding a number of existing ISV applications is that the simplest way to go about this is to simply ask a series of questions:
- Are you building a new application?
The reason why you need to address this question first is simple – you want to take advantage of the simplest and easiest deployment mechanism. As you have seen earlier, the simplest deployment model offered by PureApplication System is the virtual application. If you are building a new application and have the opportunity to influence the technology and design choices made in the application, choose those that make an application compatible with a virtual application.
However, in most cases the applications that you deal with day-to-day are not greenfield applications. Instead, you deal with existing application that have already been built, and are already running in an existing environment. Then you have to consider the next question.
- Is this a Web application?
That is a deceptively simple question. What we really mean by this is, "Does this application only take requests on inbound HTTP or HTTPs?" This definition incorporates a number of different patterns in application development. This can mean any of the following:
- A Web Services provider implementing SOAP services for external clients on the Internet.
- A classic Web application built with servlets and JSPs.
However, this definition excludes some application types; for instance, a Java client-server application that uses a Java thick client that connects through RMI or RMI/IIOP to EJBs in a backend is not defined as a Web application using this definition. That consideration also leads us to the next question.
- Do you use remote EJBs?
EJBs have been a useful part of the JEE programming model almost since its inception. However, the benefit of remote EJBs is balanced by a tradeoff in the complexity of your application topology. Your application servers have to handle both incoming HTTP traffic to your servlets, JSPs, and Web Services, and also incoming RMI/IIOP traffic from the EJB clients. Usually, this is accomplished through building two tiers of application servers; one dedicated to handling HTTP traffic, and another dedicated to handling RMI traffic. As part of the simplification process that uses virtual applications, you have had to give up some of these topological options. Thus, as we discussed earlier, if you need remote EJBs, stick with using virtual systems where these topology options are available for your use.
- Is your application packaged in a standard way?
Again, this is a deceptively simple question. By "in a standard way", we mean is it packaged as an EAR file, a WAR file, a ZIP archive, or an EBA (an OSGi Enterprise Bundle Archive)? You see, even though the JEE standard has been to package applications as EAR or WAR files, and the OSGi Standard has introduced EBA archives, many applications are still not packaged that way – instead, they are shipped as "exploded" directory structures. While that may work for simple servers like Tomcat, doing things in a non-standard way makes it complicated for you to move to new JEE servers, such as the ones which support virtual applications. So, if your answer is no, repackage your application in one of these standard formats. Likewise, there are many other packaging strategies in WebSphere® Application Server that you may want to use; for instance, server associated shared libraries. Again, to simplify the model, these are not used in virtual applications. If you cannot avoid the use of these approaches, then consider using virtual systems instead.
- Is your application using standard JEE programming
An old phrase states that "One of the great things about standards is that there are so many of them to choose from." Unfortunately, that is true when you are speaking about programming models. New APIs are introduced at a rapid pace, and the Java community process is littered with the remains of JSRs that were either never approved, or never gained wide enough acceptance to officially become part of the JEE standard. Again, the problem is that with virtual applications, you want to keep things simple. Therefore, you have to restrict the set of APIs that are supported to a manageable set. So, if your application uses only standard APIs from JEE5, J2EE1.4, 1.3 or 1.2, OSGI, JPA, JAX-RPC, JAX-WS and JAX-RS, then you should be fine.
On the other hand, if you are writing to a newer JEE level than that (such as JEE 6), or you are using some obscure API from deep within the bowels of the JCP, then your application will probably not work as a virtual application. Having stated that, IBM's approach is to offer support for newer APIs through Feature Packs. Therefore, if you are planning for a new API level, you may want to consider building a virtual system using WebSphere Application Server V8 and incorporating the Feature Pack (and support for that API) when it becomes available.
- Does this application currently run on WebSphere Application
Server Version 7 or Version 8?
This is a soft question, but an important one. There are a couple of different answers to this that you need to consider. Even if your answer to this question is "yes", but you fall into one of the previous categories that addressed the programming model, packaging, or use of remote EJBs, then your decision is already made for you – your application cannot be a virtual application. However, if you answer "no", you may still be able to run as a virtual application. If your application is compliant with the programming model questions and packaging questions above, then everything may still be good. But, if your application is running on a much earlier version of WebSphere Application Server or on another application server, then you may have a migration effort to complete first before you can move to either a virtual application or a virtual system.
- Does your application require any WebSphere family products like
WebSphere Portal Server or WebSphere Process Server?
As we have described earlier, the virtual application approach is one that is targeted at building Web applications. If your application type (or "workload" if you want to use that terminology) is not a Web application, then the current virtual application approach is not the right one for you. Note that this is purely a point in time statement. New workload types will be added to IBM Workload Deployer and PureApplication System over time. Therefore, at some point, even if you have a business process management application, you can take advantage of the higher levels of automation that virtual applications offer to Web applications today. However, for the time being, if you require any of these products, you need to build a virtual system that incorporates the IBM Hypervisor Edition products that ship as part of the online catalog for PureApplication System or IBM Workload Deployer.
- Is your application ready to take advantage of session management
with WebSphere Extreme Scale?
As with many of the previous questions, there is a lot packed into this statement. Essentially, you have to first consider your use of the HttpSession API. Many applications are written in a completely stateless way and do not make any use of the HttpSession API at all – those applications are perfectly suited for virtual applications. On the other hand, if you are using HttpSessions currently in your application, then you have to think a bit about how you use them.
First of all, are all the contents of your HttpSession declared to be java.io.Serializable? If not, then you have an issue. The model that scaling policies follow for virtual applications is that application server instances may be dynamically created and destroyed as needed to handle the amount of load that an application is taking on at any time. If you assume that your server is long-lived and its memory is a "safe" repository for session information, you will be painfully surprised if you try to implement a virtual application.
Likewise, if your sessions are very large (hundreds of megabytes), then you may be surprised by the time it takes to load a session over the network from the WebSphere Extreme Scale grid. On the other hand, if you have small, completely serializable sessions that are compliant with HttpSession best practices, then you may use virtual applications.
- Does your application use an external security product, or does it
use special security APIs like Trust Authentication Interceptors (TAI)
or JAAS plugins?
Finally, one of the things to consider is what security requirements are placed on your application. If your application does not have security requirements, or simply uses WebSphere security, and it also uses one of the supported user registries (TDS, Microsoft® Active Directory), then you can implement your system as a virtual application. On the other hand, if you use a separate security product like Tivoli Authentication Manager, or one of its competitor products, or any of the special WebSphere Security features like JAAS or TAIs, then you need to plan on building a virtual system.
Picking the right approach at the right time
One important thing to consider is that applications have lifecycles, and a single deployment model may not hold for the entire lifetime of the application. For instance, you may want to deploy an application in your development and test environments as a virtual application to have the simplest model and to make sure that you correctly capture the configuration parameters (like the JVM policy) in those environments. However, you may want to deploy that as a virtual system in production to set up the most highly optimized environment for that application. Likewise, you may have an existing application that has to be deployed as a virtual system today, but in later versions of the application, you may work towards changing its code to make it compatible for deployment as a virtual application.
Planning for the future
The best thing you can do in planning about whether or not your application is ready for virtual applications is to simply take time to plan the process out. Fortunately, IBM is ready to help you through this process. The PureExperience process has several steps that expand on the questions that we have asked by asking more questions into each of these areas. Through this question-and-answer process, an IBM Client Technical Professional can help you understand which deployment model is best suited for your particular application. Likewise, IBM Software Services for WebSphere is ready to help with application migration services and other offerings to help you adopt PureApplication System. Contact your IBM sales representative for more help and to get started!
Part 2 of this article series discussed which deployment option is best suited for your particular application when preparing for IBM PureApplication System. You learned to distinguish between the virtual application and virtual system approaches. A set of questions was also provided to help you decide which approach is right for you.
- Part 1: Onboarding migrations overview
- Part 3: Choosing a database option
- Part 4: Onboarding your applications to the cloud using the Advanced Middleware Configuration tool
- Part 5: Developing virtual application patterns for IBM Workload Deployer with Rational Application Developer
- IBM PureSystems Centre
Get products and technologies
- Download the Plugin Development Kit