マイグレーション 日本アイ・ビー・エム(株) SW事業 WebSphere Technical Sales 田中 孝清 ()

マイグレーション
日本アイ・ビー・エム(株)
SW事業 WebSphere Technical Sales
田中 孝清 ([email protected])
Version 1.1a
© 2008 IBM Corporation
1
Disclaimer
WAS
WAS V7
V7 W/S
W/S
当資料で提供する技術情報は、各製品の出荷前コードに基づくものを含みます。
この資料は日本アイ・ビー・エム株式会社ならびに
日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式なレ
ビューを受けておりません。
当資料は、資料内で説明されている製品の仕様を保証するものではありません。
資料の内容には正確を期するよう注意しておりますが、この資料の内容は2008年
10月現在の情報であり、製品の新しいリリース、PTFなどによって動作、仕様が変
わる可能性があるのでご注意下さい。
今後国内で提供されるリリース情報は、対応する発表レターなどでご確認くださ
い。
WebSphere Application Server V7
Announcement Workshop 2008
#2
© IBM Corporation.
2
Agenda
WAS
WAS V7
V7 W/S
W/S
アプリケーションのマイグレーション
新しい標準仕様への対応
非推奨となった機能・削除された機能への対応
システムのマイグレーション
WebSphere Application Server V7
Announcement Workshop 2008
#3
© IBM Corporation.
3
WAS
WAS V7
V7 W/S
W/S
アプリケーションのマイグレーション
WAS
WAS V7
V7 W/S
W/S
WebSphere Application Server V7
Announcement Workshop 2008
#4
© IBM Corporation.
4
アプリケーションの単体テスト・統合テストの重要性
WAS
WAS V7
V7 W/S
W/S
アプリケーションのマイグレーションにあたっては，
文章化されていない変更が原因で修正が必要となるケースがある
仕様で定められた制限に違反しているアプリケーション
以前存在していた「バグ」に依存してしまったアプリケーション
非公開仕様・WAS/JDKの内部実装への依存
等
このような問題は，事前のコードレビューで発見することが難しい
「仕様の変更」は文書化されているが，
「仕様外の動作の変更」はほとんど文書化されていない
開発環境のコードチェック機能でも発見できないケースが多い
問題が発生するパターンが無数に考えられ，
事前検証で網羅することが不可能
テストを実行して発見することが最良の手段
最低限必要な修正を加えたら、まずは新環境でテストを行い
問題の洗い出しを行う
十分な期間のテストをスケジュールしておくことが必要
運用後のパッチ適用なども考え，テストの自動化も検討する
WebSphere Application Server V7
Announcement Workshop 2008
#5
© IBM Corporation.
アプリケーションのマイグレーションにあたって，ひとつ留意点があります。それは，
アプリケーションの修正が必要な箇所を，各種の資料で事前に全て洗い出すこと
は現実的ではない，ということです。
マイグレーションにあたっては，標準仕様やWebSphereの仕様変更に対応するだ
けではすまないケースがあります。それはアプリケーションがWASやJDKの内部実
装や仕様外の動作に依存してしまっている場合です。このような「APIを仕様外の
方法で使用したときの挙動」などは，バージョンによって変化しても，それがドキュメ
ント化されることはほとんどありません。また，バグの修正などは膨大な件数があり，
それらの一つ一つについてアプリケーションへの影響を検討することは実質的に不
可能です。
これらの変更による修正箇所の洗い出しは，アプリケーションのテストによっておこう
ことが，作業工数の面からも，検出の確実性の面からもすぐれています。仕様変更
への対応など，必須の修正をおこなったら，まずは新しいアプリケーションサー
バーのうえで実行するようにします。マイグレーションプロジェクトにあたっては，そ
のようなテストのスケジュールを組み込んでおくことが重要ですし，アプリケーション
開発者がローカルのPC上で単体テストが行える開発環境を使用することも考慮し
ます。
5
WAS
WAS V7
V7 W/S
W/S
新しい標準仕様への対応
WAS
WAS V7
V7 W/S
W/S
WebSphere Application Server V7
Announcement Workshop 2008
#6
© IBM Corporation.
6
それぞれのWASでサポートされている主な仕様
WebSphere
J2EE/Java EE J2SE/JDK
2.0
N/A
3.0
WAS
WAS V7
V7 W/S
W/S
Servlet
JSP
EJB
DB Connection
JDK 1.1
2.0
0.91
N/A
ConnMgr
N/A
JDK 1.1
2.0/2.1
0.91/1.0 1.0
3.5
N/A
J2SE 1.2
2.0/2.1
2.2
0.91/1.0 1.0+α ConnMgr
1.1
JDBC 2.0
4.0
J2EE 1.2
J2SE 1.3
2.2
1.1
1.1
JDBC 2.0
5.0
J2EE 1.3
J2SE 1.3
2.3
1.2
2.0
JDBC 2.0
5.1
J2EE 1.3
J2SE 1.4
2.3
1.2
2.0
JDBC 2.0
6.0
J2EE 1.4
J2SE 1.4
2.4
2.0
2.1
JDBC 3.0
6.1
J2EE 1.4
J2SE 5.0
2.4
2.0
2.1
JDBC 3.0
7.0
Java EE 5
Java SE 6 2.5
2.1
3.0
JDBC 4.0
ConnMgr＋α
使用している場合，移行に当たって大きな修正が必要なもの
使用している場合，移行に当たってある程度の修正が必要となる可能性が高いもの
WebSphere Application Server V7
Announcement Workshop 2008
#7
© IBM Corporation.
それぞれのWASのバージョンが対応している主な仕様のリストです。
画面，赤字で書かれている仕様が使用されていると，大規模なアプリケーション修
正が必要となります。黄色の仕様が使用されている場合にも，ある程度の修正が必
要となる可能性があります。
その他，黒字で書かれているバージョンについては，基本的な上位互換性がとら
れているため，一般的には大規模なアプリケーションの回収は必要ありません。た
だし，細かい仕様の違いにより，小規模なアプリケーション修正が必要となるケース
はあります。
WASのバージョンが4.0以上であれば，アプリケーションの改修はそれほど必要な
いことが多いことがわかります。
7
WAS V6.1からV7.0への移行
WAS
WAS V7
V7 W/S
W/S
「J2EE 1.4→Java EE 5」および「J2SE 5.0→Java SE 6」ともに，
高いレベルで上位互換がある
WAS V6.1で稼働していたアプリケーションは，ほとんど変更なく動く
WAS 6.0以前からのアプリケーションの移行については，
WAS 6.1への移行と同じ作業になる
移行先がWAS 6.1でも7.0でも
必要な作業・手順はほとんど変わらない
WAS 4.0
WAS 5.0
WAS 5.1
WAS 6.0
WAS 6.1
WAS 7.0
従来の移行ガイド
・移行情報がそのまま使える
WebSphere Application Server V7
Announcement Workshop 2008
#8
© IBM Corporation.
WAS V7.0を直近のバージョンであるV6.1と比較すると，非常に高いレベルの上位
互換性がとられています。WAS 7.0上では，WAS V6.1用に作成されたJ2EE 1.4
準拠のアプリケーションをそのまま稼働させることができます。WAS V7.0のBetaテ
スト段階からテストに参画いただいたお客様でも，問題となるような仕様の変更は見
つかっていません。
言い換えれば，WAS 6.0以前からの移行に当たっては，WAS V6.1へのマイグ
レーションで使用した手法がそのまま使用できると言うことです。以前のWASからの
マイグレーションは，移行対象がV6.1であってもV7.0であっても，必要なアプリケー
ション修正内容は同じになります。
8
WAS V6.0からV7.0への移行
WAS
WAS V7
V7 W/S
W/S
J2SE 1.4 → Java SE 6への対応が必要
追加された予約語「enum」の対応
Genericsへの対応
強化されたコードチェックによる，エラー・警告への対応
java.lang.reflect.Proxyと同名のjava.net.Proxyが追加
java.util.Loggerのコンストラクタの変更
等
Java Virtual Machine Profiler Interface (JVMPI)
Java Virtual Machine Debug Interface (JVMDI)を使用している場合は
対応が必要
これらの機能はJava SE 6で削除された
その他詳細についてはSunの文書を参照
http://java.sun.com/j2se/1.5.0/compatibility.html
http://java.sun.com/javase/6/webnotes/compatibility.html
WebSphere Application Server V7
Announcement Workshop 2008
#9
© IBM Corporation.
WAS V6.0からの移行にあたっては，J2EEの仕様は1.4になっているため，Java実
行環境の仕様がJ2SE 1.4からJava SE 6に変わったことによる対応が必要となりま
す。Java実行環境の仕様は，J2SE 1.4からJ2SE 5.0にあがる際に大きく変更され
ています。これらの変更への対処が必要となります。
また，Java SE 6では，J2SE 5.0にあった機能の一部が削除されています。
詳細については，Sunのサイトで情報が公開されています。
9
WAS V5.1以前からV7.0への移行
WAS
WAS V7
V7 W/S
W/S
J2EEの移行
J2EE 1.4アプリケーションへ移行すれば，
WAS V7.0で正常に稼働する
J2EE 1.2移行であれば，
ツールを使用してJ2EE 1.4へ移行可能
JDK/J2SEの移行
前ページの情報を参照
詳細については，既存の
マイグレーション資料を参照
RAD 7.5の
マイグレーション・ウイザード
WebSphere Application Server V7
Announcement Workshop 2008
# 10
© IBM Corporation.
WAS 5.1以前のアプリケーションにおいては，J2EEのバージョンを1.4に，
JDK/J2SEのバージョンをJava SE 6にあげることによって移行します。詳細につい
ては，既存のWAS V6.1へのマイグレーションの資料がそのまま使用できるので，
そちらを参照ください。
Java EE 5ではアプリケーションの記述方法が大きく変わっていますので，Java
EE 5へ移行する必要はありません。実際，Rational Application Developer 7.5で
提供されているマイグレーション・ウィザードでも，J2SE 1.2/1.3のアプリケーション
を1.4に変換することはできますが，Java EE 5へ変換する機能は提供されていま
せん。Java EE 5による開発は，新規アプリケーション開発をおこなうときに使用し
ます。
10
WAS
WAS V7
V7 W/S
W/S
V7で非推奨となった機能・削除された機能
WAS
WAS V7
V7 W/S
W/S
WebSphere Application Server V7
Announcement Workshop 2008
# 11
© IBM Corporation.
11
非推奨となった機能・削除された機能
WAS
WAS V7
V7 W/S
W/S
IBM独自機能は，標準仕様で同等のものが提供された時点で非推奨となる
これらを使用していた場合には，
基本的には標準仕様を使用する用にアプリケーションを修正する
原則として非推奨となってから2バージョンは使用可能
それ以降のバージョンで削除される可能性がある
JVM/JDKの機能などは，この原則よりも早く削除されることもある
正確なリストは以下の情報を参照
Information Center
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.web
sphere.nd.multiplatform.doc/info/ae/ae/rmig_deprecationlist.html
http://www.ibm.com/support/docview.wss?rs=180&uid=swg21316317
WebSphere Application Server V7
Announcement Workshop 2008
# 12
© IBM Corporation.
WASは，標準のJava仕様やWeb Services仕様で規定されている機能の他，それ
らを補完するIBM独自機能を数多く提供しています。それらの機能については，標
準仕様が拡張・新規策定され，同等の機能が提供されるようになると， 「非推奨」と
なり標準の仕様へ移行することが推奨されます。
非推奨となった機能は，即時に削除されることはなく，原則として非推奨となってか
ら2バージョンは提供されることになっています。そのため，修正は必須ではありま
せんが，将来のバージョンアップなどを考えると，可能な限り改修をしておくことが
推奨されます。
また，IBMが提供している機能ではなく，JVM/JDKで提供されている機能などは，
仕様自体の変更により，この原則よりも早く削除されることがあります。 JVMPIや
JVMTIなどの機能が，これに該当します。
以降のページでは，WAS V7.0で新たに非推奨となった機能をリストアップしてい
ます。これ以外にも，WAS V6.1以前で非推奨となった機能などもあります。全ての
非推奨機能の一覧については，Information Centerなどの情報を参照してくださ
い。
12
WAS V7で非推奨となった機能（サーブレット関連）
WAS
WAS V7
V7 W/S
W/S
Proxyオブジェクト
com.ibm.websphere.servlet.request.HttpServletRequestProxyおよび
com.ibm.websphere.servlet.response.HttpServletResponseProxy
Servlet APIのHttpServletRequestWrapper/HttpServletResponseWrapperを使用する
セッションマネージャー（HttpSession）
Shared Session Contextを使用したWAR/EAR間のHttpSessionの共有
Servlet21SessionCompatibilityプロパティを使用したHttpSessionの共有
BLA内で情報を共有するIBMApplicationSessionを使用する
SSL IDによるセッショントラッキング
CookieもしくはURLリライティングによるトラッキングに置き換える
システムプロパティ，Webコンテナカスタムプロパティによる設定
セッションマネージャーのカスタムプロパティで設定する
WebSphere Application Serverに同梱されていた以下のライブラリ
JavaServer Faces Widget Library (JWL) のJarファイル
Rationalツールに付属のものを使用する
Apache Struts 1.1, 1.2.4, and 1.2.7
Apache Strutsのサイトから最新のものをダウンロードして使用する
WebSphere Application Server V7
Announcement Workshop 2008
# 13
© IBM Corporation.
Proxyオブジェクトは，Webコンテナから提供される
HttpServletRequest/HttpServletResponseをwrapして独自機能を追加するため
に使用するものです。Servlet API 2.3で同等のものが提供されていますのでそち
らを使用します。
サーブレットAPIが2.1から2.2にあがった際に，HttpSessionのスコープはWebアプ
リケーション（WARファイル）内で閉じていること，Webアプリケーションをこえて情
報を共有することはできないことが規定されました。これ以前に作成されたアプリ
ケーションを救済するために，WASではWARやEARの境界を越えてHttpSession
の内容を共有する仕組みが実装されています。この機能はWAS V7.0で非推奨と
なりました。新しく提供されたIBMApplicaitonSessionなどの機能を利用してくださ
い。
また，以前のWASのバージョンに添付されていたライブラリのいくつかが非推奨と
なっています。これらについては，Rationalのツールや，開発元のサイトで提供され
ている最新のバージョンを使用するようにしてください。
13
WAS V7で非推奨となった機能（トランザクション）
WAS
WAS V7
V7 W/S
W/S
トランザクション関連
com.ibm.websphere.jtaextensions.ExtendedJTATransactionインターフェース
のregisterSynchronizationCallbackForCurrentTranメソッド
com.ibm.ws.extensionhelper.TransactionControlインターフェース
トランザクションの制御には新しく追加されたJTA 1.1の機能を使用する
UOWManager#registerIterposedSynchronization()
/javax.transaction.TransactionSynchronizationRegistry等
WebSphere Application Server V7
Announcement Workshop 2008
# 14
© IBM Corporation.
WASのトランザクションマネージャーが管理するトランザクションを，アプリケーショ
ンから操作することができる機能について，JTA 1.1で新しい機能が追加されたた
め，IBM独自機能として提供されていたものが非推奨となりました。
これらは，アプリケーションで直接使用されていることはほとんどありませんが，トラ
ンザクション管理機能を持ったフレームワークなどで使用されているケースがありま
す。
14
WAS V7で非推奨となった機能（DBアクセス）１
WAS
WAS V7
V7 W/S
W/S
DB接続関連クラス
com.ibm.websphere.rsadapterのクラス
JdbcAccessorImpl/OracleDataStoreHelper
com.ibm.websphere.rsadapterのインターフェース
Beginnable/HandleStates/Reassociateable/WSNativeConnectionAccessor
com.ibm.websphere.rsadapterのクラスのメソッド
WSCallHelperのsetConnectionError(Object conn)/call
WSConnectionのgetClientInformation/setClientInformation
com.ibm.ws.rsadapter.cciのクラスのメソッド
WSResourceAdapterBaseのgetNativeConnection(javax.resource.cci.Connection)
/getNativeConnection(com.ibm.ws.rsadapter.jdbc.WSJdbcConnection)
com.ibm.ws.rsadapter.jdbcのクラスのメソッド
WSJdbcUtilのgetNativeConnection(com.ibm.ws.rsadapter.jdbc.WSJdbcConnection)
com.ibm.websphere.rsadapterのクラスのフィールド
WSConnectionのCLIENT_ACCOUNTING_INFO/CLIENT_APPLICATION_NAME/CLIENT_ID/CLIENT_LOCATION
/CLIENT_OTHER_INFOCLIENT_TYPE
getNativeConnectionはJDBC 4.0で追加されたメソッドを使用する
その他はInformation Centerの記述にしたがって対処
WebSphere Application Server V7
Announcement Workshop 2008
# 15
© IBM Corporation.
WASが管理するDataSourceを制御することができるDataStoreHelperや，WAS
がJDBCオブジェクトWrapしているクラスの機能に関連して，非推奨となった項目
がいくつかあります。
このうち，比較的よく使われているのがgetNativeConnection()かと思います。
JDBC Driverで独自に提供されている機能を呼び出すために，WASのJDBC
Connection WrapperからNativeのConnectionを取得したいという要件がしばしば
あり，そのためにこのメソッドが使用されています。
Native Connectionの取得は，JDBC 4.0から標準仕様の機能として取り入れられ
ましたので，そちらを使用するようにします。
15
WAS V7で非推奨となった機能（DBアクセス）２
WAS
WAS V7
V7 W/S
W/S
SQLストリングによる妥当性検査
WebSphere Application Server データ・ソース・プロパティーに設定
「検証オプション」の「照会」に設定する
JDBC 4.0で追加された
Connection#isValid()メソッドを
使用することにより，SQL実行前に
有効性確認を行うことが可能になった
Connection
Connection conn
conn == ds.getConnection();
ds.getConnection();
if
if (!conn.isValid(10))
(!conn.isValid(10)) {{
//
// リトライ処理
リトライ処理
}}
Statement
Statement ss == conn.createStatement();
conn.createStatement();
s.executeUpdate(slq);
s.executeUpdate(slq);
s.close();
s.close();
JDBC 4.0の機能を利用した例
WebSphere Application Server V7
Announcement Workshop 2008
# 16
© IBM Corporation.
WASのDataSource設定にSQL文を指定し，Connectionの取得時にSQL実行を
おこなってConnectionの妥当性検査を行うという機能が実装されています。この機
能は，WAS V7.0より非推奨となりました。JDBC 4.0より，標準仕様でisValid()とい
うConnectionの妥当性検査をおこなうメソッドが追加されたので，これを利用するよ
うにします。
16
参考：DB接続障害のアプリケーション対応
WAS
WAS V7
V7 W/S
W/S
従来はSQL実行時するまで，Connectionが有効かを確認できなかった
StaleConnectionExceptionの発生で無効接続の検知をおこなっていた
DBC 4.0で追加されたConnection#isValid()メソッドを使用することによ
りSQL実行前に有効性確認を行うことが可能になった
これからは，可能な限りこちらの方式を利用する
Connection
Connection conn
conn == ds.getConnection();
ds.getConnection();
while
while (true)
(true) {{
try
{
try {
Statement
Statement ss == conn.createStatement();
conn.createStatement();
s.executeUpdate(sql);
s.executeUpdate(sql);
s.close();
s.close();
break;
break;
}} catch
catch (StaleConnectionException
(StaleConnectionException e)
e) {{
//
// リトライ処理
リトライ処理
}}
}}
従来の方法の例
Connection
Connection conn
conn == ds.getConnection();
ds.getConnection();
if
if (!conn.isValid(10))
(!conn.isValid(10)) {{
//
リトライ処理
// リトライ処理
}}
Statement
Statement ss == conn.createStatement();
conn.createStatement();
s.executeUpdate(slq);
s.executeUpdate(slq);
s.close();
s.close();
JDBC 4.0の機能を利用した例
WebSphere Application Server V7
Announcement Workshop 2008
# 17
© IBM Corporation.
JDBC 4.0のConnection#isValid()の追加は，SQL実行時のエラーハンドリングの
方法も大きく変更させます。
従来，WAS上のアプリケーションでDB接続障害に対応したアプリケーションを実装
しようとした場合，SQL実行時のStaleConnectionException発生をcatchし，リトラ
イ処理を実装する方法が推奨されていました。この方法は，
StaleConnectionExceptionがWAS独自で提供されているクラスであるため，作成
したアプリケーションがWASに依存したアプリケーションになってしまうという欠点が
あります。
JDBC 4.0のisValid()メソッドを使用すると，コンテナに依存することなく，DB接続障
害のリトライ処理を実装することができるようになります。
なお， StaleConnectionException自体は非推奨となっていないため，従来の形
式でDB接続障害に対処しているアプリケーションも，WAS V7.0 上で全く問題なく
稼働します。
17
WAS V7で非推奨となった機能（Messageリソース）
WAS
WAS V7
V7 W/S
W/S
J2C（J2EE Connector Architecture）1.5に準拠していないJMSプロバイ
ダーの使用
WAS V5でデフォルトで使用されていたJMSプロバイダーはWAS 6.1で非推奨と
なっている
WebSphere MQで提供されるJMSプロバイダーは，WMQ V7以降でJ2C 1.5対応に
JMSリスナーポートによるMDBの使用
リスナーポートを構成・管理するAdminConfigのコマンドやMBeanなども非推奨
JMS activation specificationによるMDBに置き換える
WebSphere Application Server V7
Announcement Workshop 2008
# 18
© IBM Corporation.
Message関連で非推奨となった機能です。
18
WAS V7で非推奨となった機能（Webサービス）１
WAS
WAS V7
V7 W/S
W/S
Java API for XML Web Services (JAX-WS) 2.0で使用されていた
WS-Addressingエンドポイントリファレンス
com.ibm.websphere.wsaddressing.jaxws.W3CEndpointReference
com.ibm.websphere.wsaddressing.jaxws.SubmissionEndpointReference
com.ibm.websphere.wsaddressing.jaxws.EndpointReferenceConverter
以下のものに置き換える
javax.xml.ws.wsaddressing.W3CEndpointReference
com.ibm.websphere.wsaddressing.jaxws21.SubmissionEndpointReference
com.ibm.websphere.wsaddressing.jaxws21.EndpointReferenceConverter
‘2006/02’WS-Addressing WSDLネームスペースのサポート
‘2006/05’ネームスペースを使用する
Web Services Distributed Management (WSDM) インターフェース
WAS標準のMBeanを使用した管理機能を利用する
WebSphere Application Server V7
Announcement Workshop 2008
# 19
© IBM Corporation.
Webサービス関連で非推奨となった機能です。
19
WAS V7で非推奨となった機能（Webサービス）２
WAS
WAS V7
V7 W/S
W/S
IBM独自実装のSOAP/JMSを利用したJAX-WS/JAX-RPCアプリケーション
標準のSOAP/JMSを利用したアプリケーションへ書き換える
Webサービス・プロバイダー側
ボトムアップ開発の場合：
BeanやEJBからプロバイダーを再作成する
トップダウン開発の場合：
WSDLから再度スケルトンを生成し，従来のロジックをコピーする
Webサービス・リクエスター側
WSDLからクライアント・スタブを再作成する
WebSphere Application Server V7
Announcement Workshop 2008
# 20
© IBM Corporation.
Webサービス関連で大きな変更点は，従来のWebSphere独自実装を用いた
SOAP/JMSでのWebサービス呼び出しが非推奨となったことです。Java EE 5より，
JMSを使用してWebサービスを呼び出す方法が，標準仕様の一部として策定され
ました。そちらの実装を使用することが推奨されています。
WebSphere Application ServerなどIBM製品どうしのSOAP/JMS通信であれば，
すぐに移行する必要はありません。ですが，他のSOAP/JMS実装と通信する可能
性があるシステムの場合には，標準の方式に移行することが推奨されます。
20
WAS V7で非推奨となった機能（SIBus）
WAS
WAS V7
V7 W/S
W/S
Websphere Common Configuration Model(WCCM)の以下の型
SIBJMSProvider/SIBJMSConnectionFactory/SIBJMSQueueConnectionFactory
/SIBJMSTopicConnectionFactory/SIBJMSQueue/SIBJMSTopic
スクリプト中でこれらのクラスが使用されている場合には，AdminTaskで提供さ
れる同等のメソッド（例：AdminTask.listSIBJMSQueues()など）に置き換える
wsadmin内で使用できる以下のSIBusのセキュリティ機能
createSIBus, modifySIBusコマンドの-secureオプション
-busSecurityオプションを使用する
listInheritSenderForTopic, listInheritReceiverForTopic,
listInheritDefaultsForDestinationコマンド
isInheritSenderForTopic, isInheritReceiverForTopic, isInheritDefaultsForDestinatonコマン
ドに置き換える
Inter-engine authentication alias
createSIBus, modifySIBusコマンドから-interEngineAuthenticationAliasオプションを削除する
WebSphere Application Server V7
Announcement Workshop 2008
# 21
© IBM Corporation.
SIBus関連で非推奨となった機能です。
基本的に，wsadminで使用するスクリプトの機能です。WAS上で稼働するアプリ
ケーションに影響のある変更はありません。
21
WAS V7で非推奨となった機能（サーバー構成・管理）
WAS
WAS V7
V7 W/S
W/S
disablePK54589プロパティ
「disablePK54589=true」を設定している場合には
「isConnectionSharingBasedOnCurrentState=false」に置き換える
Core GroupトランスポートのUnicast/Multicast
チャネルトランスポートに移行する
Collectorツール（collector.bat, collector.sh）
IBM Support Assistant（ISA）に統合されているAutoPDツールを使用する
ISAについては，以下のサイトを参照
http://www.ibm.com/software/support/isa/
http://www.ibm.com/support/docview.wss?rs=3455&uid=swg27013569
WebSphere Touchpoint機能
標準のWAS管理機能を使用する
AdminTaskオブジェクトのSecureConversationコマンドグループ
WS-Security分散キャッシュ構成を管理するためにはWSSCacheManagementを使用
する
WebSphere Application Server V7
Announcement Workshop 2008
# 22
© IBM Corporation.
サーバー構成・管理機能で非推奨となったものです。
比較的影響の大きい変更は，Collectorツールの使用が非推奨となったことです。
問題発生時の情報収集のために，ISAまたはISA Agentをサーバー環境に導入し
ておきます。
22
WAS V7で非推奨となった機能（IBM HTTP Server）
WAS
WAS V7
V7 W/S
W/S
mod_file_cacheモジュール
mod_mem_cacheやmod_cacheなどのキャッシング機能に置き換える
mod_ibm_ldapモジュール
mod_ldapに置き換える
mod_mime_magic・mod_proxy_ftpモジュール
これらの使用は推奨されないので，関連ディレクティブを削除する
AFPA機能（mod_afpa_cacheモジュール）
AFPA（Adaptive Fast Path Architecture）機能は，
ほとんどの環境でパフォーマンス上の効果が無く，
様々なトラブルの原因ともなるため，使用は推奨されません
WebSphere Application Server V7
Announcement Workshop 2008
# 23
© IBM Corporation.
IBM HTTP Serverで非推奨となった機能です。
従来より使用がすすめられていなかったAFPA機能が，正式に非推奨となりました。
23
WAS V7で削除された機能
WAS
WAS V7
V7 W/S
W/S
Java Virtual Machine Profiler Interface (JVMPI)
Java Virtual Machine Debug Interface (JVMDI)
Java Virtual Machine Tool Interface (JVMTI)を使用する
com.ibm.websphere.servlet.filterパッケージのクラス
サーブレットAPIで提供されるServletFilterに移行する
Integrated Cryptographic Services Facility (ICSF)認証機構
Lightweight Third-Party Authentication (LTPA)認証機構を使用する
mb2mdbツール
後継機能は無し
Web services gateway customization API
JAX-RPC handlerおよびSIBusメディエーションへ移行する
com.ibm.websphere.servlet.session.UserTransactionWrapper
UserTransactionを直接HttpSessionに格納する
com.ibm.websphere.rsadapter.DataDirectDataStoreHelper
com.ibm.websphere.rsadapter.ConnectJDBCDataStoreHelperを使用する
com.ibm.websphere.rsadapter.MSSQLServerDataStoreHelper
com.ibm.websphere.rsadapter.MicrosoftSQLServerDataStoreHelperを使用する
WebSphere Application Server V7
Announcement Workshop 2008
# 24
© IBM Corporation.
WAS V7で削除された機能です。大部分が，以前のバージョンより非推奨となって
いた機能です。
24
WAS V7で削除された機能（JDBCサポート）
WAS
WAS V7
V7 W/S
W/S
以下のJDBC Driverのサポート
WebSphere Connect JDBC driver
Microsoft SQL Server 2000 Driver for JDBC
WebSphere SequeLink JDBC driver for Microsoft SQL Server
DB2® Legacy CLI-based Type 2 JDBC Driverのサポート
DB2® Legacy CLI-based Type 2 JDBC Driver (XA)のサポート
DB2 Universal JDBC Driverを使用する
WebSphere Application Server V7
Announcement Workshop 2008
# 25
© IBM Corporation.
JDBCでサポートが削除されたものです。
とくに，DB2 Legacy Type 2 Driverがサポートされなくなったことにご注意ください。
25
WAS
WAS V7
V7 W/S
W/S
システム環境のマイグレーション
WebSphere Application Server V7
Announcement Workshop 2008
WAS
WAS V7
V7 W/S
W/S
# 26
© IBM Corporation.
26
システムのマイグレーションの概要
WAS
WAS V7
V7 W/S
W/S
WAS V4.0以前からのマイグレーション
サーバーの管理トポロジーが根本的に変更になっているため
従来の構成や設定内容，運用スクリプトなどを流用することはできない
新規にアプリケーション実行環境を設計し直す必要がある
WAS V5.0からのマイグレーション
基本的な管理トポロジーは変更されてないため，同様の構成を取ることが可能
ツールによるマイグレーションがサポートされていないため，
手動で同様のアプリケーション実行環境を再作成する
WAS V5.1/6.0/6.1からのマイグレーション
WAS V7.0との共存や相互運用がサポートされる
ツールによる既存のアプリケーション実行環境の自動移行が可能
WebSphere Application Server V7
Announcement Workshop 2008
# 27
© IBM Corporation.
システム環境の移行については，大きく三つに分けられます。
WAS V4.0以前とV5.0以降では，サーバーの管理トポロジーが根本的に変更され
ています。これらのバージョン間では，起動しているプロセスの種類やその役割，出
力されるログの種類と場所，サーバーを管理するためのコマンドの名前や使用方
法，構成情報が保存される場所や方式などが全て異なっています。WAS V4.0以
前のサーバー構成情報や運用・監視手段は，新しい環境に移行することができま
せん。完全に新しく設計し直す必要があります。
WAS V5.0以降であれば，構成情報などは新環境に引き継ぐことが可能です。
V5.0はツールによる自動移行ができませんが，V5.1以降ではツールによる移行も
サポートされます。
27
参考：WAS V3.5やWAS V4.0 AEの管理トポロジー
WAS
WAS V7
V7 W/S
W/S
管理モデル
z
z
z
z
z
全てのノードに管理サーバー（AdminServer）が必要
各アプリケーションサーバーは
管理サーバー経由で起動
構成情報はDBMS上に保存
（リポジトリDB)
z
z
Application
Server
Application
Server
アプリケーションサーバーは
管理サーバー経由で構成情報を入手
Admin Serverの正常稼働には
リポジトリDBの稼働が必須
管理ツール
z
Administrative Domain
Node
Node
Admin
Console
Admin Server
Admin Server
Javaアプリケーションベースの
管理コンソール
XMLConfig
Admin
Console
Adminstrative
Repository
WebSphere Control Program
(WSCP)
WebSphere Application Server V7
Announcement Workshop 2008
# 28
© IBM Corporation.
WAS V4.0以前の管理トポロジーです。
28
参考：WAS V5.0以降の管理トポロジー
WAS
WAS V7
V7 W/S
W/S
管理モデル
各NodeにNode Agentが必要
構成情報はXMLファイルで保存
各Application Serverは個別に
構成ファイルを参照
Cell
Node
Node
Application
Server
Deployment Managerが
マスターの構成を保持し、
Node Agent経由で
各Nodeのファイルを同期
Deployment Managerと
各Node Agentは独立して起動可能
（構成の同期などだけが不可に）
管理ツール
Webブラウザベースの
管理コンソール
Application
Server
XML
Node Agent
XML
Node Agent
Deployment
Manager
Admin
Console
XML
wsadminコマンド
WebSphere Application Server V7
Announcement Workshop 2008
# 29
© IBM Corporation.
WAS V5.0以降のサーバー管理トポロジーです
JMXを使用して各サーバーが連携するようになり，リポジトリDBが必要なくなりまし
た。また，サーバー間の依存関係が無くなるなど，多くの改良が行われました。この
管理トポロジーは最新のWAS V7.0まで基本的には変わっていません。
29
混合バージョンセルのサポート
WAS
WAS V7
V7 W/S
W/S
WAS V7.0のDeployment Managerは，
V5.1，V6.0，V6.1のノードを含むことができる
ただし，6.0.0.xおよび6.0.1.xの
ノードは管理することがでない
かならず修正パッチを当てて
6.0.2.xにあげておく必要がある
Deployment Managerは，
各ノードよりもバージョンが
上でなければならない
V7
Deployment
Manager
V6
V7
NodeAgent
NodeAgent
混合セルを使用した
マイグレーションの手順例
1. Deployment Managerを
WAS V7にマイグレーションする
2. Cell内のNodeを，クラスター単位で
V7にマイグレーションする
J2EE
Apps
(EARs)
Config
Files
V6
V6
…
Application
Application
Server
Server
V6
V6
V7
V7
Application
Application
Server
Server
V6 Node
V6
Config
Files
J2EE
1.4
Apps
…
Application
Application
Server
Server
V7
V7
Application
Application
Server
Server
V7 Node
Cell
V7
Config
Files
WebSphere Application Server V7
Announcement Workshop 2008
Java
EE 5
Apps
# 30
© IBM Corporation.
WAS V7.0では，一つのセル内に旧バージョンのノードも同居させることができます。
これにより，複数サーバーで構成された環境を段階的にマイグレーションすることが
できます。
30
混合バージョンセルの注意事項
WAS
WAS V7
V7 W/S
W/S
混合バージョンセルは，
マイグレーション中の一時てきな構成として使用する
混合セルのまま，長期運用することは避ける
混合セルでは，アプリケーションサーバーの作成などに制限がある
Nodeをマイグレーションした直後は，
syncNodeコマンドを使用して手動で同期を行う必要がある場合も
一つのアプリケーションが実行されているクラスター内に，
複数のバージョンのWASが混在する構成は避ける
HttpSessionの内容を新旧バージョン間で共有することなどはできない
トラブルを避けるために，
既存の環境は最新のFixPackを適用しておくことが望ましい
WebSphere Application Server V7
Announcement Workshop 2008
# 31
© IBM Corporation.
混合セル環境には，可能な管理操作に制限があるため，そのまま長期運用を行う
ことは推奨されません。あくまで，マイグレーションの際の一時的な構成として使用
するようにします。
31
同一サーバー上での異なるWASバージョンの共存
WAS
WAS V7
V7 W/S
W/S
インストール時の導入ディレクトリを変更することで，
旧バージョンを残したまま，WAS V7.0を導入することが可能
逆に，同じディレクトリに上書き導入はできない
WAS 5.0以降が導入されている環境では，
使用しているポート番号を自動認識し，
異なるポートを使用してサーバーが
起動するように構成できる
プロファイル管理ツールで
プロファイルを作成する際に選択できる
既存環境を無視して
デフォルト構成で作成もきできる
WebSphere Application Server V7
Announcement Workshop 2008
# 32
© IBM Corporation.
WAS V5.0以降は，導入ディレクトリを変更することで，同一のサーバー筐体上に
複数のバージョンのWASを導入することができます。そのような環境では，WASは
既存環境を自動的に認識し，共存が可能となるよう，すでに使用されているポート
を避けて構成を作成する機能があります。
32
ツールによる既存WAS環境のマイグレーション
WAS
WAS V7
V7 W/S
W/S
V5.1およびV6.0/V6.1からのマイグレーションがサポートされる
マイグレーション・ツールにより既存環境から構成情報を抽出し，
新規導入されたV7.0のプロファイルに適用することができる
既存環境とは別のディレクトリにV7.0を導入し，プロファイルを作成する
そのプロファイルに，既存環境の情報がコピーされる
既存環境を上書きしないので，トラブル発生時の切り戻しが容易
アプリケーションを移行するかどうかを選択可能
アプリケーションが新旧バージョンで互換性がある場合，
ツールにより新環境へ自動的にコピーさせることができる
互換性がなく，アプリケーションの修正が必要な場合は，
ツールによるコピーは行わず，
別途，新環境に修正後のアプリケーションを再デプロイする
WebSphere Application Server V7
Announcement Workshop 2008
# 33
© IBM Corporation.
既存のWAS環境を構成情報などを新環境に移行するツールが提供されます。
このツールによるマイグレーションでは，既存のWAS環境のファイルを上書きする
のではなく，別ディレクトリに導入された新環境に旧環境の構成情報がコピー・反映
されます。旧環境がそのまま残るため，トラブルが発生した際の旧バージョンへの
切り戻しなどが簡単にできます。
33
マイグレーションツール
WAS
WAS V7
V7 W/S
W/S
コマンドラインツール
WASPreUpgrade / WASPostUpgrade
GUIツール
マイグレーションウィザード
コマンドラインツールのフロントエンド・プログラム
指定されたパラメーターでWASPreUpgradeとWASPostUpgradeが実行される
Profileの新規作成も行える
WebSphere Application Server V7
Announcement Workshop 2008
# 34
© IBM Corporation.
マイグレーションのツールは，コマンドラインのツールとGUIを使用したツールの二
種類が提供されます。後者は前者のフロントエンド・プログラムであり，実際にはコ
マンドラインツールによって全ての移行作業が行われます。
34
ツールによるマイグレーションの概要
WAS
WAS V7
V7 W/S
W/S
1. WAS V7インストール
2. プロファイルの作成
WAS V7
Application
Server
V7
3. 旧WASプロセスの停止
WAS V5/6
Application
Server
5. WASPostUpgradeの実行
バックアップ
ファイル
4. WASPreUpgradeの実行
Migrated WAS V7
Application
Server
6. WAS V7プロセスの起動
WebSphere Application Server V7
Announcement Workshop 2008
# 35
© IBM Corporation.
ツールによるマイグレーションの概要です。
まず，既存環境にWAS V7.0を別ディレクトリを指定して導入し，そこで新規にプロ
ファイルを作成します。旧バージョンのプロセスを停止した状態で
WASPreUpgradeを実行すると，旧環境の構成情報が抽出され，バックアップファ
イルに保存されます。次にWASPostUpgradeを実行すると，バックアップファイル
が読み込まれ，その内容がWAS V7.0のプロファイルに反映されます。この後，
WAS V7.0のプロセスを起動すると，旧バージョンの構成を引き継いだ新サーバー
が稼働することになります。
35
マイグレーションウィザードによる移行（１）
複数バージョンが導入されている場合
マイグレーション対象（ソース）を
選択することができる
WAS
WAS V7
V7 W/S
W/S
WAS V6.0/6.1では，
移行対象のプロファイルを選択する
WebSphere Application Server V7
Announcement Workshop 2008
# 36
© IBM Corporation.
マイグレーションウイザードによる移行の画面です。
36
マイグレーションウィザードによる移行（２）
移行先のプロファイル（ターゲット）
を選択する
新しいプロファイルの作成を
指定することもできる
WAS
WAS V7
V7 W/S
W/S
移行に使用するディレクトリを指定
このディレクトリに
バックアップが作成される
このディレクトリのしたの
logsディレクトリに経過が記録される
WebSphere Application Server V7
Announcement Workshop 2008
# 37
© IBM Corporation.
移行先のWAS V7.0のプロファイルは，既存のものを使用することもできますし，新
規に作成することもできます。既存のものを指定した場合，現在のプロファイルを
backupConfigコマンドでバックアップさせることもできます。
また，ここで指定したバックアップディレクトリに，各種の構成ファイルを格納した
バックアップファイルが作成されます。後述するように，このディレクトリのファイルを
別サーバーにコピーして，そこで新環境に反映させることもできます。また，この
ディレクトリにはコマンド実行時のログファイルも記録されます。実際に
WASPreUpgradeとWASPostUpgradeが実行されたときのコマンドライン引数など
も参照することができますので，テスト環境で実施したマイグレーションを本番環境
で実行する際の参考などにも利用できます。
37
マイグレーションウィザードによる移行（３）
WAS
WAS V7
V7 W/S
W/S
他にも以下のような項目を指定可能
アプリケーションを移行するかどうか
移行後のアプリケーションのディレクトリ
移行後のポートを変更するか，以前のものを使うか
管理コンソールのカスタマイズ情報を移行するか
スクリプトの互換性を維持するか
WebSphere Application Server V7
Announcement Workshop 2008
# 38
© IBM Corporation.
その他，後続の画面では各種の指定を行うことができます。
38
マイグレーションウィザードによる移行（４）
WAS
WAS V7
V7 W/S
W/S
指定された内容でWASPreUpgradeがバックグラウンドで実行され
続いてWASPostUpgradeが実行される
WebSphere Application Server V7
Announcement Workshop 2008
# 39
© IBM Corporation.
「マイグレーションの要約」画面で「次へ」をおすと， WASPreUpgradeと
WASPostUpgradeが順次実行されます。
39
ツールによるマイグレーションの注意点
WAS
WAS V7
V7 W/S
W/S
アプリケーションが多数導入された大規模なCellのマイグレーションでは，
通信タイムアウトによりWASPostUpgradeの実行に失敗することがある
<WAS Root>/properties/ssl.client.props を編集し，
com.ibm.SOAP.requestTimeout の値をデフォルトの180秒から10倍程度に増やす
旧環境の動いているOSがWAS V7でサポートされない場合
異なる物理筐体にWAS V7を導入する場合
サプリメントディスクにあるmigration/binディレクトリには，
ディスクから直接起動できるマイグレーションツールが収録されいている
ディスクに収録されいているJDKが稼働しない場合には，別途JDK 1.6を用意し，
ツールをHDD上にコピーのうえ，setupCmdLine.batまたはsetupCmdLine.shを編集して起動する
ここからWASPreUpgradeコマンドを実行して現環境をバックアップする
新しいOSを導入した環境にWAS V7をセットアップする
バックアップされたファイルを新環境に転送し，WASPostUpgradeを実行
WebSphere Application Server V7
Announcement Workshop 2008
# 40
© IBM Corporation.
マイグレーションにあたってOSも入れ替える場合には，旧環境でマイグレーション
ツールのみを実行し，バックアップファイルを作成しておくことに夜以降も可能です。
ただし，移行前後のホスト名などの情報は同じになるようにしておきます。ホスト名
などが異なる場合には， WASPreUpgradeの引数の変更が必要となります。
40
ツールによるマイグレーションの注意点（１）
WAS
WAS V7
V7 W/S
W/S
Cell環境のマイグレーション
移行後のセル名・ノード名は，移行前と同じにしておく必要がある
SSL証明書および鍵管理
使用していたSSL証明書はそのままインポートされる
WAS 7.0から採用された階層付きの証明書の構成にはならない
WAS 6.1までのデフォルトの環境では自己署名証明書が使用されている
必要であれば，wsadminのconvertSelfSignedCertificatesToChainedタスクを使用して，
自己署名証明書を階層付き証明書に変換する
変換しない場合，証明書の自動更新によるアクセス障害などに注意する
WAS 7.0では，署名者証明書（Root証明書）がデフォルトで15年間の有効期限を持つため，
個人証明書が1年ごとに更新されても，証明書の検証失敗による接続障害は起こらない
非rootユーザーで導入された環境
いったんrootユーザーのプロファイルへマイグレーションする
その後，非rootユーザーへファイルの所有権・アクセス権を変更する
WebSphere Application Server V7
Announcement Workshop 2008
# 41
© IBM Corporation.
ツールによるマイグレーションを行った際の注意点です。
WAS V7.0の証明書管理機能で作成される証明書は，以前のバージョンとは異な
り，階層付きの証明書になっています。つまり，有効期限の長いルート証明書がコ
ンポーネント間で共有され，実際にSSL通信を行うための証明書はルート証明書に
よって署名された証明書が使用されるようになっています。これにより，通信につか
う証明書を一定期間ごとに更新を行いつつ，証明書の更新に伴う諸問題を回避す
ることができるようになりました。
これに対し，WAS V6.1で作成される証明書は全て自己署名証明書になっていま
す。証明書の検証には，その証明書自体の情報が必要となります。またWAS V6.0
までは，WAS出荷時に作成された自己署名証明書が同梱されており，これがSSL
通信に使用されています。
マイグレーションツールを使用した移行では，これら以前の証明書環境がそのまま
移行されます。階層付きの証明書を使うよう環境を変更するためには， wsadminの
convertSelfSignedCertificatesToChainedタスクを使用して手動で証明書を変換
する必要があります。
41
ツールによるマイグレーションの注意点（２）
WAS
WAS V7
V7 W/S
W/S
HA ManagerのCore Group
WAS 5.1からのマイグレーションでは，
全体が単一のCore Groupにマイグレーションされる
Cell内のNode数やApplication Server数が多い場合，
Core Groupを適切に分割してパフォーマンスへの影響を避ける
プラグイン構成ファイル
WAS V5.1からマイグレーションされた環境では，
生成されるPlug-in.cfgには，全てのアプリケーションが含まれている
WAS V6.0以降では、特定のアプリケーションを特定のWebサーバーにのみ
割り当てることができるようになっている
WAS V5.1のトポロジー
WAS V6.0以降で可能なトポロジー
Webサーバー
Application
Webサーバー
Application
Webサーバー
Application
Webサーバー
Application
Webサーバー
Application
Webサーバー
Application
WebSphere Application Server V7
Announcement Workshop 2008
# 42
© IBM Corporation.
ツールによるマイグレーションを行った際の注意点です。
WAS V6.0からHA Managerが実装され，WASのプロセス間では互いの生存確認
が行われるようになっています。この通信の負荷は，HA Managerの構成単位であ
るCore Groupに参加しているプロセスの数に応じて幾何級数的に増加する特性を
持っています。ノードやサーバーが多数ある環境でマイグレーションを行った際に
は，Core Groupに属するプロセス数が30～50程度になるように適切に分割します。
42
Summary
WAS
WAS V7
V7 W/S
W/S
WAS V7.0は，V6.1と高いレベルのアプリケーション互換性がある
既存アプリケーションは，
WAS V6.1へマイグレーションすれば，WAS V7.0でも稼働する
非推奨となった機能，削除された機能を使用している場合は対処が必要
システム環境の移行はWAS 5.1以降からがサポートされる
WebSphere Application Server V7
Announcement Workshop 2008
# 43
© IBM Corporation.
43
Reference
WAS
WAS V7
V7 W/S
W/S
Information Center “Migrating, coexisting, and interoperating”
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ib
m.websphere.nd.multiplatform.doc/info/ae/ae/welc6topmigrating.html
Knowledge Collection:
Migrating WebSphere Application Server
http://www.ibm.com/support/docview.wss?rs=180&uid=swg21318221
Knowledge Collection:
Migrating to (or from) WebSphere Application Server V7.0
http://www.ibm.com/support/docview.wss?rs=180&uid=swg27013842
WebSphere Application Server Version 6.1へのマイグレーションガイド
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_m
igration/
WebSphere Application Server V7
Announcement Workshop 2008
# 44
© IBM Corporation.
44
資料の変更略歴
1.0 2008-10-17
1.1 2008-10-19
1.1a 2008-10-20
WAS
WAS V7
V7 W/S
W/S
最初の公開バージョン
スピーカーノート/Referenceを追加，ミスを修正
誤字を修正
WebSphere Application Server V7
Announcement Workshop 2008
# 45
© IBM Corporation.
45