WebSphere Application Server V9
アナウンスメント・セミナー
V9への移行
日本アイ・ビー・エム株式会社
クラウド・ソフトウェア事業部
アプリケーション・プラットフォーム
田中 孝清
アジェンダ
この章ではWAS V8.5 Fullプロファイルや
WAS 8.0以前から，WAS V9.0 traditionalへの
マイグレーションを扱います
 Libertyプロファイルへの移行は扱いません
マイグレーション概要
 アプリケーションの移行
 環境の移行
2
© 2016 IBM Corporation
マイグレーション概要
3
© 2016 IBM Corporation
マイグレーションのロードマップ
調査
計画
スキルの習得
開発環境
 開発環境の更新
 アプリケーションの
マイグレーション
 単体テスト
実行環境
 実行環境のマイグレーション
 実行環境のテスト
統合テスト
サービス開始
調査
計画
スキル習得
開発環境
実行環境
アプリケーションの
マイグレーション
実行環境の
マイグレーション
単体テスト
環境のテスト
統合テスト
サービス開始
4
© 2016 IBM Corporation
非推奨および削除となった機能・安定化された機能
削除された機能（Removed features）
そのバージョンから使用できなくなった機能
使用している場合は，必ず移行が必要
非推奨となった機能（Deprecated features）
将来のバージョンで削除が予定される機能
使用している場合は，可能な限り移行を検討する
安定化された機能（Stabilized features）
将来のバージョンでの削除は予定されていないが，
代替機能があるため機能改善や新機能の追加は行われな
いもの。
移行の必要はないが，代替機能の検討はおこなう
5
© 2016 IBM Corporation
WAS V9で削除された主な機能
 JavaServer Faces (JSF) 1.2機能を提供するSun参照実装 (RI)
 使用している場合はJSF 2.2へ移行する
 Web 2.0 and Mobile Toolkit
 Dojo toolkit, WebDAV拡張，Commet対応等
 Open Service Component Architecture (SCA)モデルの実行環境
 Edge ComponentのLoad Balancer for IPv4
 WAS V7以前に対する集中インストレーションマネージャー機能
 一部のWebサーバーPlugin手動構成スクリプト
 WebSphere Customization Toolboxで構成を作成する
 HP-UX環境におけるGUIベースの
WebSphere Customization Toolbox
 Communications Enabled Applications（CEA）
 WAS V7 Feature Pack for CEAで提供されていた機能
 Common Event Infrastructure（CEI）および関連するAPI
6
© 2016 IBM Corporation
WAS V9で非推奨となったAPI
Java EE 7仕様で非推奨となったもの
EJBのEntity Beanによる永続化
JAX-RPCによるSOAP通信
JAX-R / Java EE Application Deployment
Asynchronous beans / CommonJ
Concurrency Utilities for Java EE (JSR 236)へ移行
7
© 2016 IBM Corporation
WAS V9で非推奨となった主なシステム管理機能
wsadminスクリプト（jython 2.7へ移行）
 jacl
 jython 2.1
SIBus（IBM MQへ移行）
WAS V4形式のDataSource / DataSource MBean
Lifecycle Managementを使用した
LibertyプロファイルのWAS ND/ODRへの統合
IBM Support Assistant（ISA）Data Collectorによる
問題判別資料の収集（推奨がCollectorに戻りました）
DMZ Secure Proxy Server
8
© 2016 IBM Corporation
アプリケーションの移行
9
© 2016 IBM Corporation
対応しているJava EE / Java SE仕様
WAS V6.1
WAS V7.0
WAS V8.0
WAS V8.5
WAS V9.0
10
J2EE 1.4
Servlet 2.4/JSP 2.0
EJB 2.1
Java EE 5
Servlet 2.5/JSP 2.1
EJB 3.0
Java EE 6
Servlet 3.0/JSP 2.2
EJB 3.1
Java EE 6
Servlet 3.0/JSP 2.2
EJB 3.1
Java EE 7
Servlet 3.1/JSP 2.3
EJB 3.2
J2SE 5.0
Java SE 6
Java SE 6
Java SE 6
Java SE 7
Java SE 8
2016/1Qより
Java SE 8
© 2016 IBM Corporation
Java SE仕様のマイグレーション
Java SE 8では，言語仕様レベルの大きな変更が行われた
 Project Lambda
 過去二回（1.1→1.2および1.4→5.0）に匹敵する
あるいは，それ以上のインパクトのある大変革
バイトコードレベル（コンパイル済みコード）では
上位互換は保証されている
Java言語仕様
1st Edition
JDK 1.0
1.1
Java言語仕様
2nd Edition
J2SE 1.2
1.3
Java言語仕様
3rd (SE 7) Edition
1.4
J2SE 5.0 Java SE 6
7
Java言語仕様 Java SE 8 Edition
Java SE 8
11
© 2016 IBM Corporation
Java SE：Generics（総称型）への対応
汎用的なオブジェクトを扱うクラスにおいて，
扱うオブジェクトの型をパラメーターとして指定できる
 Java SE 5より導入
 コンパイル時点での型の安全性の保証／型キャストの排除
コレクション・フレームワークをはじめとして
多くの標準APIが総称型を使用したものに変更
 型を指定しないで使用するとコンパイル時に警告が出るように
 既存のコードについては警告を無視すれば，稼働するコードは生成可
 潜在的なバグを抑制するためにも，正しく型を指定することを推奨
Java SE 8のLambdaをはじめとする
新機能を使用する場合には総称型の仕様が前提
 総称型で指定した型をもとに型推論がおこなわれるため
12
© 2016 IBM Corporation
Java SE：Genericsを使用するように変更したコードの例
private HashMap hosts;
// 型は指定しない
public void init() throws IOException {
hosts = new HashMap();
hosts.put("localhost", InetAddress.getLocalHost());
hosts.put("publicdns", "8.8.8.8");
// エラーとならない
}
public InetAddress getAddress(String hostname) {
return (InetAddress)hosts.get(hostname); // キャストが必要
}
潜在的なバグ
ClassCastExceptionが
発生する可能性
private HashMap<String, InetAddress> hosts; // 型を指定する
public void init() throws IOException {
hosts = new HashMap<String, InetAddress>();
hosts.put("localhost", InetAddress.getLocalHost());
hosts.put("publicdns", "8.8.8.8");
// コンパイルエラーとなる
}
public InetAddress getAddress(String hostname) {
return hosts.get(hostname);
// キャストは不要
}
13
© 2016 IBM Corporation
Java SE：バージョン間の非互換への対応
コンパイルが正常に通った場合も，Java SEのバージョンが
上がることによりAPIの挙動がかわることがあります
 J2SE 5.0からJava SE 6への移行
極めて高いレベルで上位互換性がとられている
非互換の詳細については，以下の文書を参照
http://www.oracle.com/technetwork/java/javase/compatibility-137541.html
 Java SE 6からJava SE 7への移行
Exceptionをcatch節の中でRe-throwする際の言語仕様変更など軽微なもののみ
非互換の詳細については，以下の文章を参照
http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
 Java SE 7からJava SE 8への移行
高いレベルで上位互換性がとられている
クラスの構造などに，ある種の前提をおいているコードなどが動かないことも
 インターフェースは実装をもたない
 同一のアノテーションが複数指定されることはない
など
非互換の詳細については，以下の文章を参照
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibilityguide-2156366-ja.html
14
© 2016 IBM Corporation
Java EE仕様のマイグレーション（１）
基本的にJava EE 5以降アプリケーションであれば，
Java EE仕様自体で上位互換が取られているため，
WAS V9.0環境でも稼働する
 V9.0でサポートされているJava EE仕様については下記URLを参照
http://www.ibm.com/support/knowledgecenter/en/SSAW57_9.0.0/com.ibm.
websphere.nd.multiplatform.doc /ae/rovr_specs.html
 WAS V9.0上ではJava EE 6/7仕様がサポートされており，
Java EE 5のアプリケーションも稼働する
 J2EE 1.4/1.3/1.2のDD（デプロイメントディスクリプタ）を
持ったアプリケーションも，構成は成城に読み取られて稼働する
一部の仕様については，J2EE 1.3→1.4などで
動作変更になった部分があるために修正が必要なこともある
15
© 2016 IBM Corporation
Java EE仕様のマイグレーション（２）
Java EE 6 / 7の新機能を使用する場合には
マイグレーションする
 新仕様に対応した開発環境で，
Java EE 6/7のアプリケーションとしてコンパイルする
 アプリケーションのコンパイル環境をあげた場合，
メソッド追加などソースコードの修正が必要になるケースがある
ユーザーが実装することを前提としたインターフェースは，
仕様のバージョンが上がってもほとんど変更されることはない
コンテナが実装することを前提としたインターフェースは，
仕様のバージョンが上がると機能の追加がしばしば行われる
16
© 2016 IBM Corporation
Java EE仕様のマイグレーション（３）
Java EEで非推奨と指定された仕様については
可能な限り新しい仕様に変更する
 EJBのEntity Beanによる永続化
→ JPAへ移行する
 JAX-RPCによるSOAP通信
→ JAX-WSへ移行する
 JAX-R / Java EE Application Deployment
→ 使用しない（Java EE標準仕様では後継機能はない）
JSF 1.2でWAS提供のSun Reference Implementation 1.2を
使用していた場合は，アプリケーション自身で実装を持つか，
JSF 2.xへ移行する
17
© 2016 IBM Corporation
マイグレーションに使用できるツール（１）
 WASの旧バージョンからの
移行を支援するツール
無償でダウンロードして使用することができる
EclipseやRational Application Developerに
組み込んで使用
Rational Software Analyzerの技術を使用して
Javaコード，JSP，デプロイメント記述子の調査
修正が必要な箇所をリストアップし
修正方法についてガイドを表示
Tomcat
JBoss AS / EAP
WebSphere Application Migration Tool
WAS
V7.0
V6.0 & 6.1
V5.1
Oracle AS
 WebLogic，JBoss，Oracle ASなどからの
移行を支援するツール
移行の負荷を大幅に削減
Oracle WLS
Application Server Migration Toolkit
Competive Application Migration Tool
Application
Migration Tool
WebSphere
Application Server
V9.0, 8.5
https://www.ibm.com/developerworks/websphere/downloads/migtoolkit/
18
© 2016 IBM Corporation
マイグレーションに使用できるツール（２）
Migration Toolkit for Application Binaries
アプリケーションのバイナリ（EAR/WARファイル）を
直接調査して，使用しているAPIやクラスを検出する
移行が必要な仕様やクラスを簡便に調査できる
WASdevからダウンロード可能
https://developer.ibm.com/wasdev/downloads/
19
© 2016 IBM Corporation
実行環境の移行
20
© 2016 IBM Corporation
実行環境のマイグレーションの概要
システムトポロジー
WAS 5.0以降では，管理概念は大きく変わってはいない
WAS 7.0以降なら，基本的にはツールによる9.0への移行が可能
V6.0より前のバージョンからの移行では，
HA機能への対応，プロファイルへの対応が必要
V6.1より前のバージョンからの移行では，
改良されたセキュリティ機能への対応が必要
パフォーマンス・パラメーター
バージョン間で方式や意味が変わったものが多く，
再度のチューニングが必要
Javaヒープメモリサイズ・GC方式
各種タイムアウト時間
21
© 2016 IBM Corporation
異なるバージョンの共存
１つのCell内で
V9.0, V8.5, V8.0, V7.0の
ノードを混在することが可能
DMはより新しいバージョンで
なければならない
旧ノードは異なるOSでも可能
V9
Deployment
Manager
V8
V9
NodeAgent
NodeAgent
V8
Application
Server
…
V8
V9
Application
Server
Application
Server
V8 Node
V8
Config
Files
22
J2EE
Apps
(EARs)
Config
Files
Java
EE 6
Apps
…
V9
Application
Server
V9 Node
Cell
V7
Config
Files
Java
EE 5
Apps
© 2016 IBM Corporation
WAS V7.0以降の環境からのマイグレーション
 ツールによるマイグレーションが可能
 既存のV6，V7環境から構成情報を抜き出し，V8環境に取り込む
 旧環境と同様の構成（スタンダード）にするか
ポートを変更した構成（クローン）にするか選択が可能
 クローンでは旧環境と共存も可能
 スタンダードも旧環境は削除されていないので，切り戻すことも可能
 Deployment Managerを含むトポロジーでの段階移行では使用が必須
 導入されているアプリケーションを含めて移行するかどうかは
選択することが可能
23
© 2016 IBM Corporation
WebSphere
Application Server
24
© 2016 IBM Corporation

3位 3位