- Monitoring (1)
- All articles (246)
- Installation (10)
- Getting started with Liberty (6)
- Migration (1)
- Coding (59)
- Java EE (57)
- OSGi (16)
- Setting up your Liberty workflow (10)
- Extending Liberty (7)
- Liberty with open source (17)
- DevOps (67)
- Security (9)
- Internet of Things (7)
- Real-time comms (1)
- Microservices (3)
- Cloud (29)
- Labs (3)
- Fun projects (9)
- Videos (34)
- Podcasts (5)
- Early Access (11)
Over the years we have worked hard to improve the version-to-version migration experience for WebSphere Application Server customers, with tools to automate most or all of the changes needed to both user configuration files and applications. However, version upgrades remain a significant effort for most customers. When we began the Liberty project, we were determined to make product upgrades radically faster and easier for our users and so made it a core design principle of Liberty to strive for zero migration.
What is zero migration?
Zero migration is the ability to use existing, unmodified user files, both configuration and applications, with an updated version of the product runtime files, with no unwanted or unexpected change in behavior. Our vision is that, once users have made the move to the Liberty profile, they should experience no future migration costs.
How does Liberty make migration easier?
Separation of user and product files
The Liberty profile provides an absolute separation between product files and user files. Product files are shipped and serviced by IBM and do not need to be modified by users; in fact any such modifications are likely to be overwritten if product service is applied, thus modifications are strongly discouraged. If desired, the product files can be placed in a read-only location to prevent inadvertent modification.
The user files, such as server configuration and application files, are located under a separate directory from the product files by default, and users can override their location by setting the
WLP_USER_DIR environment variable, for example to put them on a separate filesystem from the product files.
When the installable archives are used, each fix pack is a complete product image and can be installed into a new location; for example, an existing 220.127.116.11 product installation can be left untouched, and the complete 18.104.22.168 product can be added alongside. By setting the
WLP_USER_DIR variable to the existing ‘usr’ directory containing the server configurations and application, the user can then start their existing servers using the new version of the runtime without copying the user files. It is extremely simple to move backwards and forwards between multiple service levels this way.
No migration of configuration files
Liberty user configuration files do not require modification when the runtime is updated, either for a fix pack or a new version. You simply point the new runtime at your existing configuration (or use a new copy of your configuration if you prefer) and start your servers.
You can even add new configuration into your files and then run them with the old level of the runtime; the runtime will simply ignore any configuration that it doesn’t recognize. This has been achieved through the design of a more loosely typed and flexible configuration, through tolerance of unrecognized configuration by the runtime, and through diligent policing for incompatible changes during our product development.
Liberty feature architecture
In traditional Java EE application servers there is typically one copy of each container and service, and if you want to modify the behavior of a container, for example, you have to set a configuration property that applies at the scope of the server. This has often been a problem when servers are upgraded to support a new level of the Java EE specification; despite improving efforts to ensure backward compatibility in the JSRs, it is not uncommon for a new specification level to force a behavior change on an existing service or container.
In a traditional application server with only one copy of that component, the new behavior has to be applied as the new default in order to meet specification compliance. A configuration property may be provided to revert to the previous behavior (to protect the operation of existing applications), but the user generally has to experience the behavior change and associate it with the new configuration property before regaining the behavior that they want. This is one of the reasons that Java EE version-to-version migration can be slow and expensive.
The Liberty feature architecture frees us from that forced default behavior change. Rather than updating a single implementation of each JSR technology, we can deliver a new feature for the new JSR without changing the behavior of our existing features. Both old and new features remain available with the current level of the runtime so all features can benefit from enhancements to the kernel, administration, security and other capabilities. The servlet specification is a good example for the Java EE 7 upgrade; you may have seen that we have started to deliver our implementation of servlet 3.1 from Java EE 7 in our recent beta drivers.
The servlet 3.1 specification includes a number of ‘clarifications’ to previous servlet versions that were considered to be ambiguous (perhaps evidenced by differing interpretations by different vendors). Any servlet 3.1 compliant implementation has to apply these clarifications which, given their nature, seems likely to result in at least some changes in behavior.
In Liberty we can restrict any such behavior changes to our new servlet 3.1 feature, but retain the existing behavior in the servlet 3.0 features. Users who want to keep the 3.0 behavior for their existing applications can continue to configure those servers with the servlet 3.0 feature and the behavior won’t change. If they want to write a new application using servlet 3.1 capability they just create a server using the new servlet 3.1 feature and get all the new behavior.
Will I be able to mix and match all the new features?
The Java EE 7 specification enforces relationships between some of the Java EE 7 technologies. For example, CDI 1.1 has some significant changes over CDI 1.0, and some Java EE 7 technologies (including Bean Validation 1.1 and JTA 1.2) require CDI 1.1 specifically; in those cases there will be restrictions on mixing the Java EE 6 and 7 levels of those features.
However, where the specification does not enforce such coupling, we aim to provide a useful set of features that will allow combinations of the available Java EE 6 and Java EE 7 features. This will enable some parts of an application to retain existing behavior while allowing others to take advantage of new capabilities.
This may be particularly useful if your applications are using the Java EE 6 JPA 2.0 feature and they have dependencies on the underlying Apache OpenJPA implementation. The new Java EE 7 JPA 2.1 feature uses the EclipseLink JPA provider, so applications that rely on OpenJPA classes directly will need to be migrated before the JPA 2.1 feature can be used. The ability to use other Java EE 7 features like websockets immediately while continuing to use the Java EE 6 JPA 2.0 feature provides developers with the flexibility to deliver new value quickly.
How close is Liberty to zero migration?
There is no migration required for user configuration files for Liberty. You can continue to use existing server configurations, without any changes, with new versions of the runtime.
If you decide to make changes to your server, you may need to update your applications. While the Java standards have a strong focus on backward compatibility, moving your server to a new Java SE version may impose a need for some application changes, particularly if the applications are recompiled against the new Java level. Similarly, most Java EE 6 applications will not need to be changed when moving to Java EE 7 features, but any feature update to the server configuration could introduce a need to update application code.
If you don’t change your server configuration, the continued availability of Java EE 6 features in the new runtime versions will avoid the need for any application updates at the Java EE layer. If you also continue to use your current Java SE version then you will not need to update your application for Java changes and you should experience the Liberty vision of zero migration.
The Liberty design for zero migration will save a lot of time and money by avoiding the need to migrate existing configuration and application files. Developers can instead focus on using the new capabilities and features to write new applications while still getting the benefits of improved performance and administration for their existing server configurations. I believe WebSphere is the only Java EE application server in the industry to provide this behavior and we are very excited about this benefit for our users.