ibm-cloud-architecture / refarch-jee

This project provides a Reference Implementation for migrating existing Java EE applications from on-premise to cloud-based deployments, as well as migration to a microservices-based architecture.

Enterprise Application Modernization through Java EE on Cloud

This project provides a reference implementation for modernizing Java EE-based applications, running on present-day application servers (ie WebSphere Application Server), to run on the Cloud and outside the walls of traditional datacenters. This is an iterative process, as these applications have traditionally grown to be quite large over time, allowing teams to adopt and build best practices as they progress. This repository provides the content for both the overall strategy required for these types of modernizations, as well as reference implementation code that can be used to walk through the iterative process on your own.

The end result of this modernization effort is to build applications that are more nimble, more resilient, and more secure. At the "end" of this modernization, users will generally be building microservices-based applications. These applications contain components that are much smaller in nature, much more distributed, and much more autonomous. However, the power of these smaller components is realized when they are able to evolve much more rapidly than the existing traditional enterprise applications.

Contents

• Strategy
  • Phases
  • Techniques & Design Decisions
• Application Overview
• Repositories
• Getting Started
• Additional Resources

Strategy

The Enterprise Application Modernization strategy that this reference implementation employs is built out through phases. These phases, documented below, provide teams, with existing application ownership, the ability to learn and grow into Cloud Native principles, while at the same time not sacrificing Production efficiency or outages to the business.

Phases

Phase 0: Current State

This phase is the ASIS, current state of the existing applications. These are often on-premises, with very high-touch deployments, complicated by many different "owners" and layers of inefficiencies.

Phase 1: Modernization

Initial need to migrate to current runtimes, projects, and supporting libraries on WAS 8.5.5 or WAS 9.0, as it’s an intermediate modernization step and not a complete rearchitecture. This phase focuses on modernizing application components to present-day versions, as well as development environments and delivery pipelines to modern practices.

Phase 2: Mitigation Phase

This phase focuses on moving core pieces of compute-based business logic to cloud-based services iteratively. This reinforces proper cloud principles, while not sacrificing production workloads and efficiency.

Additional networking and security practices are usually defined during this phase, as legacy Enterprise teams are exposed to public cloud provider configurability for the first time.

Most existing database and messaging capabilities are left in-tact during this phase, while the focus is on the core compute functionality in the new cloud environment.

Phase 3: Production Lift & Shift

A potential end goal for some Enterprise clients, the lifted application and all core critical components are moved to the cloud provider. Additional components may still exist on-premise, and depending on latency requirements, either directly connected to the cloud provider or cached via secured, higher-latency direct connections to the on-premises resources.

Adoption of newer cloud-based services, such as newer databases and messaging capabilities, are often adopted during this phase as well.

Phase 4: Evolve to Microservices

Through iterative assessment, teams move to microservices on a per-business capability basis, depending on prioritized pain-points the existing lifted monolith is still presenting. This is done repeatedly until the application teams can move at the speed the business requires.

Techniques and Design Decisions

DevOps

Hybrid Connectivity

Security

Application Overview

The application is a simple store front shopping application, built during the early days of the Web 2.0 movement several years ago. As such, it is in major need of upgrades from both the technology and business point of view. Users interact directly with a browser-based interface and manage their cart to submit orders. This application is built using the traditional 3-Tier Architecture model, with an HTTP server, an application server, and a supporting database.

Application architecture details are detailed at length in the Customer Order repository.

Repositories

• Customer Order - Main Legacy monolithic application GitHub repository

  • Branch was70-dev - Development branch for WebSphere Application Server V7.0 application code. Development Environment: RAD V9.6 + WAS V7.0. Builds either from RAD or using Maven.
  • Branch was70-prod - Production branch for WebSphere Application Server V7.0 application code. Does not contain any IDE specific file. Builds only using Maven.
  • Branch was90-dev - Development branch for WebSphere Application Server V9.0 application code. Development Environment: eclipse MARS 2 + WAS V9.0. Builds either from eclipse or using Maven.
  • Branch was90-prod - Production branch for WebSphere Application Server V9.0 application code. Does not contain any IDE specific file. Builds only using Maven.

• Customer Order - Main microservices based application GitHub repository

  • Legacy backend microservices
  • Customer Order Service microservice repository
  • Product Search Service microservice reopository
  • Shopping Service microservice repository

Getting Started

These phases are iterative in nature and require the previous Phases to be completed before moving on. In the links below, you will be able to move through the Phases of modernizing the reference application leveraging your own cloud resources.

• Phase 1: Modernizing the Existing Application README & Blog post
• Phase 2: Mitigation Phase README & Blog post
• Phase 3: Production Lift & Shift (TBD)
• Phase 4: Evolve to Microservices README & Blog post

Additional Resources

• WebSphere... on Cloud? webinar - Learn how to "Life & Shift" your WebSphere Applications to the Cloud
• WebSphere Application Server Migration Toolkit - The WebSphere migration toolkit provides a rich set of tools that help you migrate between versions of traditional WebSphere, to Liberty, to cloud platforms such as Liberty for Java on IBM Bluemix Instant Runtimes, and from non-IBM application servers.
• IBM WebSphere Application Server V9.x Developer Tools - An eclipse 4.x IDE for building and deploying Java EE, OSGi and Web 2.0 applications to WebSphere Application Server traditional V9.x with Java EE 7.
• Build and continuously deliver a Java microservices app in IBM Cloud Private - Stand up a private cloud instance, deploy DB2, MQ, and Redis services, supporting a Stock Trader application.
• Developing microservices for IBM Cloud Private - Explore the programming model used to build the Stock Trader application's microservices.
• Refactor existing monolithic applications to microservices one bite at a time - Multi-part series covering the complex problem of refactoring monoliths into microservices step-by-step. Learn how to implement a systematic approach to refactor your monolithic applications and then run that monolith in the cloud.

refarch-jee's Issues

Potential security issue

The following paragraph and the below it in the phase2.md file can be interpreted as endorsing a long standing security anti-pattern....placement WAS and it's JDK in a DMZ, as opposed to separation of the HTTP server refer to point 1 in http://www.ibm.com/developerworks/websphere/techjournal/1210_lansche/1210_lansche.html

IBM® WebSphere Application Server in IBM® Bluemix® is a service that facilitates quick setup on a pre-configured WebSphere Application Server Liberty, Traditional Network Deployment, or Traditional WebSphere Java EE instance in a hosted cloud environment on Bluemix on a virtual machine guests with root access to the guest operating system.

Perhaps change the above paragraph to something like this:

IBM WebSphere Application Server for Bluemix is a service that returns guests (virtual machines) in a shared environment for consumers to deploy applications. A VPN protects the public service from generic port scans and other unsolicited network-based attacks. However, it is important to note that the service VPN you use to access your service instance might be shared between multiple Bluemix organizations and users. The virtual machines provide compute, memory, and I/O resources, which come from a shared pool of IaaS resources. Additionally the patterns above depicting collocation of tWAS with IHS and Liberty with IHS are intended for development and testing connivence, not production deployment. If you want to run your applications in a secure private environment as is typical for production deployment, contact your IBM Sales representative who can speak to our dedicated IBM WebSphere Application Server for Bluemix offering.

Config Migration

WebSphere Customization Toolbox

I would change this name of the above to Migration Wizard and add this hyperlink https://www.ibm.com/support/knowledgecenter/en/SSAW57_9.0.0/com.ibm.websphere.migration.nd.doc/ae/tmig_profiles_gui.html

I would also change the example from using the WebSphere Customization Toolkit to using the recommended tooling as described in the above link

AND

~Eclipse-based application migration tool

The above name and hyperlink is incorrect.

The name should be Eclipse based configuration migration tool

The hyperlink should be: https://developer.ibm.com/wasdev/downloads/#asset/tools-WebSphere_Configuration_Migration_Tool

V2V Upgrade Process - On-Prem then In Cloud

Our best practice in moving applications from on-premise to the cloud is to first do the upgrade on premise and pass at least the integration (or functional) tests. Then once that is done to move it to the cloud and handle the connectivity issues. So, I would start this session with the upgraded migration - the one that worked on-prem in WAS V9 ... so you would only see the connectivity issues at this time and would not see all of the other issues that were addressed in the previous section. So, I'd re-run the tool with the on-prem migrated ear/war.

We can see in the report that the issues in the green boxes were already reported during the previous code migration phase in which these were already addressed. The reason for these issues to appear again in the report is because we did not address them per se since we are 'lifting & shifting' our existing old WebSphere Application Server applications running on existing on-premise resources to a newer WebSphere Application Server version and different IBM platform. That is, we want to do that 'lift & shift' the simplest and least intrusive. This means to do the least changes to the code or structure of the applications as well as reuse as most as possible the same Java Technologies and versions of them as long as the new WebSphere Application Server version and IBM platform support them.

Add additional WAS migration links to additional resources section

• ibm.biz/MigrationDiscovery
• https://developer.ibm.com/wasdev/downloads/#asset/tools-Migration_Toolkit_for_Application_Binaries
• https://developer.ibm.com/wasdev/downloads/#asset/tools-WebSphere_Configuration_Migration_Tool
• https://developer.ibm.com/wasdev/docs/migration/

Removing Feature Packs

You may be right on this, but I would wait on taking this action until testing showed that is was a real not an imagined. In fact, I would continue to include those jars in the application so long as it does not violate the license agreement. Once again, remember that the app worked with that set of libraries so keep it unless you absolutely know or determine that the app will not work with that jar.

In addition to this, you should also remove old WebSphere Application Server specific libraries. In our case, we should remove the reference to the IBM WebSphere Application Server traditional V7.0 JAX-RS Library which was installed as a Feature pack:

So I would keep it at this point and simply note that this is a potential problem.
.

websphere customization toolbox

This procedure can be followed only if the migration is between different versions of WebSphere.

You may also want to mention that waspreupgrade and waspostupgrade can be used for more complex nd migrations ... I'm not certain, but the websphere customization toolkit may be limited to base; not nd. here's a link to the more general set of command line tools for the cloud migration strategy for nd.

See slides 4-8 and 12: https://ibm.box.com/s/4242qf5uw1iucbr8h5pdb16oijgn8ke3

You may also want to mention that the above tools are best suited for lift and shift scenarios where there is also a like for like migration of the cells. That is they are great where the target cell has the same number of node agents, the same number of clusters, the same number of cluster members, etc. Those tools do not work well if there is some consolidation or other re-architecture of their topologies.

When there is refactoring of the topologies then that is when you may want to use the eclipse based wcmt. See slides 8-10 in https://ibm.box.com/s/4242qf5uw1iucbr8h5pdb16oijgn8ke3

jpa

The difference is not with regard to method or annotations in the code ... its openpa proprietary xml vs eclipselink proprietary ... you may also want to look at the help associated with those xml file warnings/errors as they may provide you with some hints on how to resolve these problems ... for instance, you may be able to use openjpa as an alternate jpa provider in jpa 2 and if so those proprietary annotations would be ok ...

btw to see the help in wamt select window => show view => other => help => help ... then whenever you click on one of the results in the eclipse "software analyzer results" tab you will see the help associated with that error in the help view ... if you then look at the help view and scroll down to the bottom of it you will see a "see also => detailed help" button. if you press on the "detailed help" button it will show you additional ideas on how to resolve that problem ... oft-times it shows several options for your consideration

The last error reported is about the JPA version used in our code. In the WebSphere Application Server V7.0 we are migrating our code from, we were using its Feature Pack for OSGI and JPA which comes with the JPA 2.0 version. In contrast, the WebSphere Application Server V9.0 which we want to migrate our code to uses JPA 2.1 where the provider has changed from being openJPA to eclipseLink. As a result, methods, annotations, etc are no longer valid or its behaviour has changed

Yes! The following is great!

Remember that our goal is to migrate our existing code/apps running on WebSphere Application Server V7.0 to run on a newer WebSphere Application Server version supported by WASaaS on Bluemix but with the minimum possible changes which is what the 'lift & shift' pattern consist of (modernization of your application, Java technologies wise, might be carried out on a later stage). Because of this, we can take advantage of the backwards compatibility on the JPA version and providers the new WebSphere Application Server V9.0 comes with and configure it to use JPA 2.0 so that we do not need to change anything in our app at all:

apache wink client ..

Again, I'm pretty sure that the apache wink api's were in the application and you removed them. So, if you would not have removed them then I am pretty certain that you would not be seeing this error.

We have to be careful and thoroughly review each of the errors and warning either of the toolkits report since there might be some that actually do not apply due to the possibility of having WebSphere Application Server fixpacks or feature packs installed. For instance, in our case, both toolkits report an error because we are using the org.codehaus.jackson packages that are exposed as a third-party API in JAX-RS 1.1 but are not part of the new JAX-RS 2.0 version WebSphere Application Server V9.0 comes initially with. However, we find out that our WebSphere Application Server V9.0 comes with such packages possibly because of later fix packs installed as we are really using the 9.0.0.3 version of WebSphere Application Server:

Step 5.4: Suggested Re-Write

Currently, these are the instructions in Step 5.4 of the end-to-end tutorial for setting up OpenVPN. My suggested re-write is inline below the original text:

Original:

"4. Once done, you can access the Admin console using the Open the Admin Console option. In order to access the Admin console, install the VPN as instructed.

Windows 64-Bit (OpenVPN)
Windows 32-Bit (OpenVPN)
Linux (OpenVPN)
Mac (Tunnelblick)

Download, extract, and install the VPN configuration files by clicking the Download button.

VPN - Windows Configuration

From the openVPN Windows download link, download openvpn-install-2.3.4-I001-x86_64.exe for 64-bit, or openvpn-install-2.3.4-I001-i686.exe for 32-bit.

Ensure you Run as a Windows Administrator and openVPN is installed.

Download the VPN configuration files from the OpenVPN download link of the WebSphere Application Server in Bluemix instance in the service dashboard. Extract all four files in the compressed file to the {OpenVPN home}\config directory.

C:\Program Files\OpenVPN\Config

Start the openVPN client program "OpenVPN GUI". Ensure that you select Run as a Windows Administrator to start the program. If you do not, you might not be able to connect."

Replace with:

**4. Now you will access the WASaaS Admin Console to reconfigure your WAS cloud server. But first, you need to install and configure a VPN connection (if you have not already done so as a prerequisite):

A. Install the VPN Client

For Windows users, use the links provided on your WASaaS dashboard to download the installation executables for the latest versions of OpenVPN. Once downloaded, these files can be opened in that location. Follow the installation instructions. Install the VPN client using the following directory:

C:\Program Files\OpenVPN

For Linux users, use the link provided on your WASaaS dashboard and download the application binary for your version of Linux to install OpenVPN.

For Mac users, use the link provided on your WASaaS dashboard and follow the instructions to download and install OpenVPN.

Note: no links provided in this section. Users will use the links provided on their Bluemix WASaaS dashboard.

B. Download and Extract the VPN Config Files

For Windows users, download the VPN configuration archive file using the "Download VPN Configuration" button on your WASaaS dashboard. From the download location, extract the files to the following required location:

C:\Program Files\OpenVPN\Config

For Linux and Mac users, download the VPN configuration archive file using the "Download VPN Configuration" button on your WASaaS dashboard. From the download location, extract the files to the following location:

{OpenVPN home}\config

C. Establish Your VPN Connection

For Windows users:

1.) Right-click on the OpenVPN GUI icon on your desktop, select "Run as administrator"
2.) Right-click on the OpenVPN GUI icon in your Windows system tray, select "Connect"

Your VPN connection should now be established.

For Linux and Mac users:

{Can someone with a Mac or Linux OS please complete this section?}

D. You should now be able to access the WASaaS Admin Console by selecting "Open the Admin Console" on your WASaaS dashboard.**

Why the changes?

1.) The original text of the tutorial contains the same links as provided on the WASaaS dashboard, however they are static and the WASaaS dashboard may be updated. Also, there are multiple overlapping and inconsistent links provided that confuse the setup process. Seems best to just use the links provided on the WASaaS dashboard.

2.) The instructions linked here:

https://console.bluemix.net/docs/services/ApplicationServeronCloud/systemAccess.html#setup_openvpn

are the same instructions copied and pasted into the tutorial. They are not clear, outdated and/or are incorrect. Here are corrections (Windows setup):

#1 - some of the OpenVPN download links reference v11 and some reference v4 of this client app. The WASaaS dashboard has the latest link.

#3 - see previous git issue when downloading and extracting VPN config files

#4 - once the OpenGUI VPN client is started, the user must then right-click on the OpenVPN icon in the Windows system tray and choose "Connect"

All of these changes should be corrected with the above proposed re-write.

Asess: Duplicate or unused classes

The following paragraph is too strong and in some sense misleading and there is a typo higly => highly

As we can see in the report, there are several concerning facts such as duplicate or unused libraries we should pay attention to and which we higly recommend fixing before migrating your application to a newer WebSphere Application Server version and/or different IBM platform

Although it is nice to see these jar's there is really nothing that you can do with this information except to store it away as potential problems. It would not be advisable at all to simply start removing duplicate or unused classes. Remember that application worked with this collection or jars. So its best to keep these jars unless you discover some class loading issues during testing.

AND

After removing the unused libraries and verifying that this does not introduce any other problem/error in the code, we look at the ear structure, its ejb, web and test projects. We realise that there are several libraries being used by multiple projects but yet included in each of them as opposed to packaging them at the ear level as a shared library among all ear project components. After repackaging libraries at the ear level, this is how the inventory report looks like:

I would never recommend changing any jars based on this report ... you can only change the jars during the testing phase. For instance, there are many frameworks that do dynamic class loading. So the report may give incorrect information regarding unused jars .... Also, as mentioned remember that this app did work with the "as is" classes and packaging ... do not change it! the more you move away from the working app the more chances you have of introducing a crit sit ... again, only repackage or change jars based on resolving defects during testing ...

AND

We see now that both web projects and the ejb project look fine library wise. However, the report indicates that there are still several duplicate libraries. Looking in detail at what packages those duplicate libraries come with, we realise that, in effect, several libraries packages are included by others (normally broader and heavier Java libraries. For instance, the jackson-all library includes all packages the other three lighter and more specific jackson libraries come with). We then remove remaining duplicate libraries and run the report again:
We see now that both web projects and the ejb project look fine library wise. However, the report indicates that there are still several duplicate libraries. Looking in detail at what packages those duplicate libraries come with, we realise that, in effect, several libraries packages are included by others (normally broader and heavier Java libraries. For instance, the jackson-all library includes all packages the other three lighter and more specific jackson libraries come with). We then remove remaining duplicate libraries and run the report again:

Never ever do that ...

AND

Again, we remove these libraries and run the report. This time, the report comes finally clean except from some warnings regarding missing dependencies on some projects/libraries.

No, no, no, Never do that ...

AND

We have repackaged and refactor our application structure to a situation were we do not have duplicate or unused libraries and the libraries we want/need to include are packaged in the proper location. At this point, we are now ready to start the migration to the newer WebSphere Application Server version or IBM Platform.

Don't repackage and refactor the app base on the unused libraries, etc.

Step 5.4: Redundant path specified for OpenVPN Config files (Windows Users)

Redundant Path Specified for OpenVPN for Windows Config Files:

1.) In Step 5.4, the user is directed to download the OpenVPN configuration files. This "openVPNConfig.zip" file, that is downloaded from the Bluemix WASaaS service dashboard by selecting the "Download VPN Configuration" button, has within itself an "openvpn" subdirectory where the .ovp, key and certificate files are located.

2.) The correct directory path (using the default suggested install path for the application binary, using the OpenVPN installer executable for Windows), where the files above MUST be located, is

C:\Program Files\OpenVPN\config

3.) The instructions found at

https://console.bluemix.net/docs/services/ApplicationServeronCloud/systemAccess.html#setup_openvpn

(which were copied and pasted into the text of the this tutorial, and also linked from this page), tell the user to extract these files to C:\Program Files\OpenVPN\Config

4.) Therefore, by extracting the files as specified, they will extract to

C:\Program Files\OpenVPN\Config\openvpn\

instead of

C:\Program Files\OpenVPN\Config

which is required, according to both readme.txt files.

After extracting the files from the "openVPNConfig.zip" to the directory noted in the instructions, I had to copy the .ovp, key and certificate files up a level in my directory, then delete the redundant "openvpn" subdirectory.

Additional Strategy Planning Tools

Perhaps you want to add these two tools to the strategy planning?
 

1. WAS V9 TCA Calculator (Latest WAS V9 flexible pricing options)
   https://advantage.ibm.com/2015/04/02/was-vs-jboss-license-and-support-cost-calculator-updated/
   Compare your existing S&S costs against the latest WAS V9 flexible license and support options
    
2. WAS V9 TCO Calculator (On-Premise versus In Cloud)
   https://roi-calculator.mybluemix.net/
   Evaluate costs of moving your applications to Bluemix (WAS as a Service, IBM Container, or Buildpack) 

If so, see slides 6-8 in this link from which to start:

https://ibm.box.com/s/luy29aoc7n9vu5g29nbvlh91awz6yzk8

clarification of binary scanner and wamt usage

The binary scanner is used for assessment (judging the migration complexity of an app so you can create a detailed cost effort for migrating it) ... binary scanner runs against the class files ... it is not for repackaging the application or making coding changes ... the wamt is used for source migration ... it runs against the source code and can bring up the existing line of code where there is a problem or a potential problem so you can determine whether or not that change is actually required ... remember also that both of these tools are helpers ... in that you still need to provide intelligence in interpreting the results ... you just can simply make all the changes or even apply all the quick fixes ... you have to "apply intelligence" in interpreting the results and making the changes or ignoring them

As we said previously, there are pros and cons of using the Migration Toolkit for Application Binaries Analyze report over the eclipse-based WebSphere Application Server Migration Toolkit plugin to migrate your code to a newer WebSphere Application Server version and viceversa. Therefore, we suggest to use both in conjunction. The advantage of using the eclipse-based WebSphere Application Server Migration Toolkit plugin is, in fact, because it is used in an IDE so you can take advantage of using IDE's suggestions, tools and help:

See slides 5-10 (https://ibm.box.com/s/v8zy4alao59ev27fj4123506jjzc3ado ) for a description of why you use the binary scanner and pay careful attention to slide #10 as that is the ultimate rationale for using the binary scanner .. that is the binary scanner is primarily used to "quantify the migration effort" . For instance, you should not be opening or modifying the JAR/WAR/EAR while using the binary scanner. That's not the intended use of the binary scanner. It treats the archive's as black boxes. On the other hand the WAMT works of an eclipse project so any refactoring or code changes should be made by using the WAMT; not the binary scanner ...

Traditional WebSphere Applications

Change this section heading from this

Traditional WebSphere Applications

to this

Traditional WebSphere (Profile Migration)

AND

Make this a section heading

Third Party Application Servers / Traditional WebSphere Application Server

AND then change the name of that section heading to:

Traditional WebSphere (Resource Migration

Note: I do not think you need to mention 3rd party app server migrations in the above section heading simply because the target audience is WAS V2V upgrade; they are not 3rd party app server migrations. That said, if you wanted to mention liberty migrations or 3rd party app server migrations then you can add notes in the text; but its not needed in the section heading

Step 2: Heading consistency, better flow, and minor edits

Suggest the following edits to headings to improve consistency and provide clarity and also to enable the user to determine where they are within the larger migration plan; i.e.,

Phase 1: Plan (Strategy, Discovery), Phase 2: Assess (Evaluate, Inventory, Analyze), and Phase 3: Migrate (Dev, Code, Config)

1.)

Replace

Step 2.1 Use the Migration Toolkit for Application Binaries to evaluate the applications

With

Step 2.1 Assess CustomerOrderServicesApp's readiness for migration

Reason

Step 2.1.1 says the same thing, and that is where we should say that, because Assessment (Phase 2) includes sub-phases of Evaluation, Inventory and Analysis

Note: In 2.1.1.5, the instructions say "close the browser." The user should not close their browser! Please update that to say something like "close the browser tab just created by this report."

2.)

Replace

2.1.2: Generate the Application Inventory Report for CustomerOrderServicesApp

With

2.1.2: Use the Migration Toolkit for Application Binaries to inventory CustomerOrderServicesApp

Reason

Clarity and consistency across headings and to keep the user oriented to the big picture of where they currently are in the 3-Phase migration project.

Note: As before, 2.1.2.5 asks the user to close the entire browser instead of the previously generated tab. Better to say "close the browser tab just created by this report."

3.)

Replace

Step 2.2: Analyze the CustomerOrderServicesApp Application code

In this section you will use the WebSphere Application Migration Toolkit (WAMT) to analyze the CustomerOrderServicesApp application code for readiness to run on traditional WebSphere Application ServerV9 (tWAS V9). An Eclipse Workspace has been provided with the CustomerOrderServicesApp Application Source Code already imported. The following features have been installed in to Eclipse IDE for Java EE Developers:

WebSphere Developer Tools for Eclipse Neon
WebSphere Application Server Migration Toolkit

With

Step 2.2: Use Eclipse IDE Tools to analyze the application code

In this section you will use the WebSphere Application Migration Toolkit (WAMT) to analyze the CustomerOrderServicesApp application code for readiness to run on traditional WebSphere Application ServerV9 (tWAS V9). An Eclipse Workspace has been provided with the CustomerOrderServicesApp Application Source Code already imported.

First, you will need an Eclipse IDE client application on your workstation.

If you have already installed Eclipse Neon.3, ensure that you have the following plugins installed:

WebSphere Developer Tools for Eclipse Neon

Note: Select the box for WebSphere Application Server Migration Toolkit as part of the download.

If you have already installed Eclipse Oxygen, ensure that you have the Websphere Developer Tools for Eclipse Oxygen by going to the Help menu, selecting Eclipse Marketplace, searching for "Websphere Developer Tools", and clicking the Install button.

Note: Select the box for WebSphere Application Server Migration Toolkit as part of the download.

If you do NOT have an Eclipse IDE installed on your workstation, or have a version prior to Neon.3, you can download the Eclipse Neon.3 image containing all the necessary tools already installed at the following links. (You may have previously downloaded these in the prerequisites section.)

Eclipse Neon.3 for Windows w/ WAMT
Eclipse Neon.3 for Mac w/ WAMT

Alternatively, you can click here to install Eclipse Neon 3 Eclipse IDE for Java EE Developers Neon.3. You will then have to install the Developer Tools and Migration Toolkit plugins as described above.

Second, all users should download the required Eclipse Workspace - Cross-platform containing the CustomerOrderServicesApp Application Source Code.

Reason

The logic flows better and the links are better.

4.)

Replace

2.2.1: Review the CustomerOrderServicesAppApplication Code

In this section you will open a provided Eclipse workspace containing the CustomerOrderServicesApp source code in Eclipse Neon

You can download the Eclipse image containing all the necessary packages already installed at the following links. (You may have previously downloaded these in the prerequisites section.)

Eclipse for Windows

Eclipse for Mac

Eclipse Workspace - Cross-platform

Once this is done, open Eclipse with a clean workspace.

Navigate to the Eclipse directory and run Eclipse:

cd {ECLIPSE_NEON_HOME}
eclipse {-clean}

With

2.2.1: Analyze the CustomerOrderServicesApp application code

1.) Open Eclipse with a clean workspace, from your application menu or using the command line:

cd {ECLIPSE_NEON_HOME}
eclipse {-clean}

2.) In Eclipse, go to the File menu and choose Import....

3.) Expand General option and select Existing Projects into Workspace.

4.) Choose the option Select Archive File and then browse the workspace refarch-jee-customerorder-was70-dev (Export-Archive-File).zip.

5.) Ensure all four of the CustomerOrderServices projects are selected and click Finish to complete the import.

Reason

The logic flows better and the links are better.

The rest of the write up can proceed as it is from there. Once these edits are complete, it should be much easier to follow. I can go through it again for overall flow and to make sure we didn't miss anything.

Analysis Command Line Options

Please add the --includePackages=org.pwte.example to the --analyze report

e.g.

--sourceAppServer=was70 --targetAppServer=was90 --sourceJava=ibm6 --targetJava=ibm8 --targetJavaEE=ee7 --includePackages=org.pwte.example

You only want to scan the code that you wrote for upgrade issues; not 3rd party libraries.

Almost all the time 3rd party libraries is just java cone and it will run on later versions of the jdk (its not a was upgrade issue) ... its an issue of whether the 3rd party jar is certified to run on this later version of the jdk ... most of the time you the 3rd party jar will have some statement about minimum jdk requirements. that would be the way to look at the 3rd party jars; not the binary scanner. thus, use the --includePackages option.

Code Analysis

You should not be re-running the analysis tool here. You should be staring with the eclipse workspace. Using that workspace then you would run the WAMT from eclipse run => sanalysis ... and then select the"cloud application migration" and press the set button. Next, select WebSphere on cloud (virtual machine) as your target cloud platform and press the analyze button. That should show you the db connectivity and url issues ... and you can fix them inside eclipse ... remember binary scanner is not intended to be used for fixing problems ... its just used for assessment ... by the time you get ot moving your application to WAS as a Service you are well past the assessment stage so should be using the WAMT; not the binary scanner.

For doing so, we run again the same command: java -jar binaryAppScanner.jar binaryInputPath --analyze [OPTIONS].
(I) binaryInputPath is an absolute or relative path to a J2EE archive file or directory that contains J2EE archive files. (II) in this case, we need to update the options to the current WebSphere Application Server version as well as to the target IBM platform. That is, our [OPTIONS] this time are: --sourceAppServer=was90 --targetAppServer=was90 --sourceJava=ibm8 --targetJava=ibm8 --targetJavaEE=ee7 --targetCloud=wasVM

clarify wamt help and fix the typo ...

WAMT also has help and I believe that the rule help may in fact be the same in both.

There is also a type in the text "coming" => coming

However, the Migration Toolkit for Application Binaries Analyze report has the advantage of comming with an explanation of the rule being applied so that the user can better understand the reason why a warning or error has been reported:

consistency of migration rules across the binary scanner and wamt

Please change this sentence

After

running the Software Analyzer you should see a Software Analyzer Results tab at the bottom. In here, we should have the exact same errors and warnings as the Analyzer report in the previous section.

to something like this:

After running the Software Analyzer, the number of results can be different (due to scanning class files vs source files), but the same rules should be flagged. The only case where this might not be true is JPA. There were several very complex JPA rules that were not implemented in the binary scanner. But the binary scanner flag JPA migration issues, just not as extensively (since many of these more complex rules were to provide quick fixes which are not even available in the binary scanner).

J2EE deprecated

J2EE has been deprecated since Java 2 EE V4; use JEE since Java EE 5.

Change all references to J2EE to JEE

Development Environment -- Eclipse

The development environment should suggest Eclipse Neon instead of Mars

Instead of

Eclipse Mars 2 for JEE developers

use

Eclipse Neon 3 for JEE developers.

Note that the hyperlink is ok; just change the title.

tooling refresh and the new "application migration report"

You may want to refresh the migration tooling. There was a new release of the binary scanner, application migration toolkit, and configuration migration toolkie in june. Here's a link to the latest version of these tools:

https://developer.ibm.com/wasdev/downloads/#filter/sortby=relevance;q=migration

The binary scanner also has a new "application migration report" that consolidates all of the other reports into a single report. It will be quicker to run and describe that consolidated "application migration report" than it is to run and describe the individual report.

Here's a link to an example of the consolidated report: https://developer.ibm.com/wasdev/docs/migration-toolkit-application-binaries-tech/#all