WebSphere Application Server & Liberty

So, you've been working on modernizing your WebSphere application. With the help of the WebSphere Application Toolkit for Application Binaries (Binary Scanner), you've selected a runtime that supports the technologies you depend on. You've gotten an understanding of what libraries you need and what's already packaged in your archive. You've completed required and recommended code changes to get your application fully compatible with your chosen runtime.

It's finally time to try it out! You pull the Open Liberty container image and build a new image with your application. But wait...

What about the database connections--don't we need to configure data sources? And the JMS queues and topics? And doesn't the application authorize users via our LDAP server? How do we set all this up?

Configuration Generation

In other articles, we discuss the Inventory, Evaluation, and Analysis reports generated by the Binary Scanner. All of these are HTML reports intended to advise you on different aspects of your application; they help you identify, build, and execute a modernization plan, based on information discovered from your application's binary archive. 

Configuration generation is a little different. Rather than a report, the Binary Scanner's ability to generate configuration for your application is more of an accelerator on your way to getting up and running in the environment you've selected. And rather than just looking at your application binary, the configuration generation feature considers your application within the WebSphere Application Server cell it's deployed to.

The result: the configuration from the source cell related to your application, translated to a form compatible with your choice of environment: a Liberty server.xml and related files¹ or a WebSphere traditional Base edition wsadmin script. 

Let's explore. Using the Binary Scanner to generate configuration is very similar to generating the reports--there's one key requirement for the path to the application. To get started:

1. Download the Binary Scanner Installer from here.
2. Unpack the Binary Scanner by issuing: java -jar binaryAppScannerInstaller.jar
3. Run the unpacked jar on your application by issuing: java -jar wamt/binaryAppScanner.jar /path/to/your/was/profile/config/cells/cellname/applications/SampleApplication.ear --generateConfig

Note that the path to the application to scan is located within a WebSphere profile's applications directory (the important part is config/cells/cellname/applications/SampleApplication.ear.)

The Binary Scanner will automatically discover the configuration related to the application, and will generate the requested configuration files:



Areas of WebSphere configuration that are supported include:

• JDBC configuration
• JMS configuration, including IBM MQ
• Authentication aliases
• Application security with LDAP registries (standalone and federated)
• String-value JNDI entries
• JVM properties

and more.

There are several unique properties of this configuration, so let's go over them.

Application-Centric Configuration

WebSphere applications, especially in WebSphere Network Deployment, are often deployed together. That means each cell will have many configuration objects (data sources, connection factories, activation specs) used only by certain applications.

When the Binary Scanner detects and examines the cell's configuration, it also scans your application binary for occurrences of unique identifiers, such as JNDI names. Using this information, the Binary Scanner knows to only include the configuration actually referenced by application code or properties. Since "one container, one application" is a modernization best practice, you don't have to go through the generated configuration to manually remove irrelevant objects.

Variable Substitution (Liberty Exclusive)

Another modernization best practice is "immutable images, configurable containers." We want to provide a default configuration for the application, but we don't want to hard code those configuration values so they can't be changed easily. This allows a single application image to be deployed to development, test, preproduction, and production environments; each deployment specifies the values for information like remote service hosts and ports, queue manager names, and so on.

Both Open Liberty and WebSphere Liberty support reading certain values from environment variables and using them as part of configuration. 

The Binary Scanner automatically extracts the values of certain configuration attributes likely to change between environments: hosts and ports, channels and queue managers, and LDAP baseDNs, to name a few. These values are replaced with variables that default to their original values, but can be overridden by environment variables with matching names. 

Sensitive Data

Configuration generation necessarily requires reading configuration that might contain sensitive data (passwords). It's important to control where this sensitive data is stored and transferred, so by default the Binary Scanner does not include sensitive pieces of configuration in any generated files. Instead, the values for those items are replaced with variables, and the variable definitions are moved to a separate sensitiveData.xml file, where you are free to populate those variables whenever and however works best for you.

Unlike normal variable substitution, sensitive data variables do not have default values, so that no passwords are contained in configuration--especially container images. Instead, these sensitive values should stored separately and be provided to the runtime only at deployment time.

For WebSphere base, variables in the wsadmin script are created but not assigned a value. Fill these in manually when you configure your WebSphere profile or container image.

If you are testing your application on a local workstation, or a secure test environment, you may want sensitive data to be included. If this is the case, you can supply the optional parameter --includeSensitiveData to the Binary Scanner when generating configuration. The sensitive data variables will be populated with the value from the source configuration, reducing the amount of steps from configuration generation to running the application.

Wrapping Up

Writing out configuration is yet another step on the journey to modernization. Once you've set up your application on the new environment, the real testing and fix loop begins. Getting to the point where your application starts, even if it not all of it works yet, is a big step along the path.

There's a lot to consider when migrating configuration from an application from one environment to another. Give the Binary Scanner a try on your environment, and let us know in the comments what worked for you and what you need to be successful in modernizing your applications!

Footnotes

1. In addition to the server.xml and sensitiveData.xml discussed in this article, you may get a jvm.options file containing JVM-related parameters. Back.

See the IBM Developer learning path Modernizing applications to use WebSphere Liberty to discover all the application modernization tools available with WebSphere Hybrid Edition. Also, check out the other articles in this app modernization blog series.