WebSphere Application Server：Traditionalランタイムの現状について

IBMの提供するエンタープライスJavaアプリケーション向けミドルウェアであるWebSphere Application Server（WAS）では，WebSphere TraditionalランタイムとWebSphere Libertyランタイムの二つの実行環境が提供されています。

このうち，従来型のランタイムであるTraditionalランタイムは，互換性の維持のために提供されています。現在提供されているVersion 9.0.xが最後のバージョンになります。機能を改善したり新しい仕様やプラットフォームに対応した次期バージョンは提供されません。

既にご利用いただいているお客様が継続してご利用いただくことは問題ありません。そのようなお客様に向けては，IBMは少なくとも2030年までという長期のサポートを表明しています。ですが，現状で対応している機能の陳腐化が始まっており，これから新規に導入をおこなったり，あるいはTraditionalランタイムへのバージョンアップなどをおこなうことは推奨していません。

これからWASをご利用いただくお客様は，かならずLibertyランタイムをご利用ください。Libertyランタイムは，現在も活発に開発や機能改善がおこなわれています。また，クラウドネイティブ時代に対応した軽量・高速なランタイムであり，お客様の運用のモダナイゼーション，コストの削減，品質向上を実現することができます。

Traditionalランタイムの陳腐化

WASでは，Javaやインターネットの標準技術の進歩に合わせ，定期的に新規のバージョンを提供してきました。

こちらの図は，過去のWASのバージョンが出てから，次のバージョンが出るまでの日数，そのバージョンが最新バージョンだった期間をグラフ化したものです。WASでは，遅くとも3〜4年ごとに新しいバージョンを提供してきました。

ですが，Traditionalランタイムの最新版，Version 9.0は，2022年4月現在で，出荷から6年たってしまっています。本来であれば，とうに新しいバージョンが出ているはずの時間が経過しています。今後，新しいバージョンは出ませんので，この期間はますます長くなっていきます。

そのため，現在も進歩が続いているLibertyランタイムとの機能の差はますます広がっています。

Java SEは，二つのLTS（Long Term Support）バージョンである11および17が登場しています。17まではJava 8以前からのマイグレーションを考慮した仕様の更新がおこなわれていますが，今後は破壊的な変更も取り入れられ，Java 8以前からの移行の負荷が高くなることが予想されています。そのため，今後もJavaの利用を予定している多くのお客様では，Java 8からの17への移行プロジェクトが開始されています。

また，Java EEの最終バージョンである8，コミュニティベースの仕様策定に移行したJakarta EE，マイクロサービス・アーキテクチャーに対応するためのMicroProfileなど，WAS V9.0が出荷された2016年以降も，多くの新しい技術がJavaの世界に登場しています。Traditionalランタイムは，これらの仕様に全く対応できていません。

これからもTraditionalランタイムを使用し続けることは，ITシステムの中に技術的な負債をかかえ続けることになってしまいます。これからWebSphereをご利用いただくお客様は，必ずLibertyランタイムを使用するようにしてください。

Libertyランタイムを利用するメリット

WebSphere Libertyは，2012年から提供されているWebSphere Application Serverの新しいランタイムです。2018年からはOpen LibertyとしてOSSとして開発されており，それを取り込むかたちで製品版のWebSphere Libertyが提供されています。

WebSphere Libertyは，従来のTraditionalランタイムがクラウドネイティブ時代に必ずしも適していない構造になっていたため，サーバーランタイムのカーネルから再実装し，昨今のあらゆるプラットフォームに対応できるアプリケーションサーバーとなっています。

軽量・高速

Libertyランタイムは，従来のTraditionalランタイムとくらべ，あるいは他のJava EEアプリケーションサーバーとくらべ，非常に少ないメモリで動作し，起動や動作も高速です。

提供されているAPIやサーバー機能の全てがFeatureという単位でモジュール化されており，必要なFeaturだけを有効にすることができます。そのため，使用するディスク領域もメモリも必要最小限にとどめることができます。

導入・管理の容易さ

Libertyランタイムの導入は，ZIPやJAR形式のアーカイブファイルを展開するだけで完了します。専用のインストーラーや構成ツールなどは必要ありません。また構成ファイルもサイズの小さい小数のファイルを作成し配置するだけです。エディタで簡単に編集することができますし，Gitなどのバージョンコントロールシステムで管理することも可能です。

また，アプリケーションを導入し構成が完了した環境を，まるごとZIPファイルにパッケージする機能も提供されており，ZIPファイルを展開するだけで，すぐにつかえるアプリケーションサーバー環境ができあがります。

このため，DevOpsやPlatform as Codeなど，モダンな運用・開発スタイルとの親和性が非常に高くなっています。

ゼロマイグレーション・ポリシー

Libertyは，バージョンが上がり新しいAPIへの対応や新機能が追加されたときに，既存のFeatureを置き換えることはしません。かならず新しいFeatureを追加することで機能更新がおこなわれます。既存のFeatureも継続して提供されます。そのため，構成を変えず，従来のFeatureを使う構成になっていれば，バージョンが上がっても新機能は有効になりません。いままで使っていた機能が（バグが直っただけで）そのまま利用し続けることができます。

また，構成ファイルのデフォルト値を変更しない，などのポリシーも徹底されているため，Fixpackをあてて最新版にしても，アプリケーションや構成の「マイグレーション」は必要ありません。

TraditionalランタイムからLibertyランタイムへの移行

現在，WASのTraditionalランタイムでご利用いただいているアプリケーションは，その多くが，比較的簡単にLibertyランタイムへ移行していただくことができます。ですが，一部の古い非推奨となったAPIを使用したアプリケーションについては，大幅な書き換えが必要になるケースもあります。具体的には，以下のAPIを使用しているアプリケーションです。

移行が難しくなるケース

EJBのEntity Bean

J2EE/Java EEでは，DBのレコードとJavaのオブジェクトを関連付けるORMフレームワークとして，EJB Entity Beanという機能が提供されていました。ですが，その設計自体を原因とした扱いにくさやパフォーマンスなどの問題もありました。それを改善するために，JPAという新しい技術が登場し，従来のEntity Beanの仕様は非推奨となりました。

LibertyランタイムはJPAのみに対応しているため，Entity Beanを使用したアプリケーションは，JPAや，その最新仕様であるJakarta Persistenceに移行する必要があります。

JAX-RPC

XML形式で情報を交換するSOAP通信でシステム間連携をおこなうWebサービス，その古い仕様であるJAX-RPCも，Libertyランタイムでは利用できません。改善された仕様であるJAX-WSに移行します。

CommonJ

かつてIBMが独自仕様として提供していたJava EEで非同期処理を実現するAPIです。 Java EE使用に標準として追加されたConcurrency Utilities for Java EEに移行する必要があります。¹

移行の負荷を調査するツール

これらの移行が難しくなるAPIがアプリケーションの内部で使用されていないか，またそれ以外にも移行に当たって修正などが必要な箇所が無いかを調査するツールとして，Migration Toolkit for Application Binariesが無償で提供されています。こちらは，Java実行環境が導入されたPC上で実行できるツールで，エンタープライズJavaアプリケーションをパッケージしたEAR/WARファイルを対象に分析をおこなうことができます。

ダウンロードしたファイルを解凍すると，binaryAppScanner.jarというファイルが生成されます。以下のようにコマンドラインから，現在アプリケーションを実行いただいている環境の情報，および移行先のJavaのバージョンを指定してください。

java -jar binaryAppScanner.jar <WAR/EAR>
    --sourceJava=[oracle5|oracle6|oracle7|oracle8|ibm7|ibm8]
    --sourceAppServer=[weblogic|jboss|tomcat|was85|was80|was70]
    --targetJava=[ibm8|java11|java17]
    --targetAppServer=liberty

結果はHTMLファイルとしてカレントディレクトリに生成されます。このファイルをブラウザで開くと結果を確認できます。アプリケーションで利用しているAPIの一覧や，それらがLiberty環境で対応しているか。また，修正が必要な場合はどのような修正が必要なのかが出力されます。

こちらのツールで調査いただき，Libertyランタイムでも実行可能なアプリケーションをご利用であれば，ぜひともLibertyランタイムへ移行していただくことをご検討ください。

1. CommonJは，Version 22.0.0.1からHeritage プログラミング・モデルとして提供されるようになりました。heritageAPIs-1.1フィーチャーを有効にすることで，CommonJを使用したアプリケーションが，そのままLibertyランタイム上でも稼働します。もちろん，新規に作成するアプリケーションでは，CommonJではなく，Concurrency Utilities for Java EEを使用するようにしてください。 ↩