iSeries ｖｓ UNIX Server

Transcription

1 IBM i 勉強会 2008 秋 IBM Power Systems IBM i IBM i Web 化手法の選択 2008 年 11 月日本アイ ビー エム株式会社 Power 事業部

2 目次 1. Web 化手法 ツールの選定 2. IBMの提供するIBM i Web 化ソリューション 3. IBM i(i5/os) のWebアプリケーション実行環境 ( 復習 ) 4. Web 化時のパフォーマンスチューニングについて 2

3 Part.1 Web 化手法 ツールの選定 3

4 Web におけるアプリケーション実行環境 Web アプリケーション実行に必要な 3 層構造 クライアント クライアントとの通信 アプリケーションロジックの実行 データベース処理 ブラウザー リッチクライアント インターネット社内ネットワーク HTTP サーバー アプリケーション サーバー Web 用画面 JSP 等 Web 用アプリケーションロジック データベースサーバー ホストアプリケーションロジック (RPG, COBOL 等 ) データベースデータベース HTTP サーバー クライアント ( ブラウザー等 ) との通信を実行 アプリケーション サーバー ビジネス ロジックの実行 Web のダイナミックな画面の生成 (JSP 等 ) アプリケーション サーバー ソフトウェア HTTP サーバー ジョブ上でアプリケーションロジックを実行する場合もあります ( 例 PHP) = WAS(WebSphere アプリケーション サーバー ) LWI (IBM i 組込アプリケーションサーバー ) データベース サーバー データベース処理の実行 アプリケーションサーバーから呼び出された RPG, COBOL, C/C++ などのアプリケーションの実行 4

5 既存アプリケーションと Web アプリケーションの連携 JAVA, PHP による新規作成 データベース以外は全て新規作成 他システムからの移行 Web インターフェース Java PHP RPG,COBOL によるアプリケーションロジック作成 画面は JSP などの Web ページ ロジックは RPG,COBOL で作成 Web 化ツールの利用 Java SQL (JDBC, ODBC) HATS などのツールで CUI 画面から Web 画面に変換 プログラム連携 (PCML) 5250 端末環境 旧来環境のまま利用 CUI 画面 RPG COBOL データベース 5

6 IBM i アプリケーションの Web 化パターン 開発言語 ツール 既存資産利用の有無 クライアントの形態などによっていくつかのパターンがあります Web 化パターン 1 ツールやフレームワークを利用し開発工数を削減 オープン系とまったく同一の手法で開発 ブラウザーリッチクライアント Web 画面 JSP 等 アプリケーションロジック (Java, PHP 等 ) WAS( アプリケーションサーバー ) HTTP サーバー データベースデータベース Web 化パターン 2 RPG,COBOL の命令拡張で Web 化に対応 ブラウザーリッチクライアント ツールやフレームワークを利用し開発工数を削減 Web 画面 JSP 等 Web 画面制御用モジュール WAS( アプリケーションサーバー ) HTTP サーバー RPG,COBOLによるロジック記述 Web 画面操作用拡張コマンド アプリケーションロジック (RPG, COBOL 等 ) データベース データベース Web 化パターン 3 ツールを利用して既存のアプリケーションロジックとのインターフェースを生成 既存 5250 アプリケーションを GUI 化 ブラウザーリッチクライアント Web 用画面 JSP 等 既存ロジックとのインターフェース WAS( アプリケーションサーバー ) HTTP サーバー アプリケーションロジック (RPG, COBOL 等 ) データベース =Web アプリケーション用に新規作成 =5250 バッチ用既存システム資産 6

7 何を選択基準として手法を選択したらいいか? 残念ながら全てのユーザーに共通の絶対の選択基準は存在しません それゆえ異なる手法 たくさんのツールが存在する と言うこともできます 自社の現状と Web 化の目的 ( 狙っている効果 ) そして制約条件を考慮し手法を決定する必要があります Web 化の目的 ( 期待効果 ) 照会系の生産性向上 U/I をブラウザーに統一エミュレーター導入の廃止 自社の現状 開発コスト 期間を重視生産性を重視機能を重視 RPG のみ Java, VB プログラマーあり 今後自社開発 メンテ 今後委託メンテ 自社開発 外部委託 全面再構築 一部リニューアル 制約事項 費用上限 開発期間 要員 リスクの評価 次期開発計画 7

8 参考 ) IBM i Web アプリケーション手法選択のポイント IBM i の独自ポイントとして必ずしも Web アプリケーションを 1 から全て作る必要はありません お客様の前提条件 業務内容によっては既にある 5250 アプリケーションをベースに短期間 低コストで開発することもできます また Java, php などの言語も他のオープン系サーバーや Windows と同じように選択する事ができます 複数の手法を組み合わせる事も可能です iseries アプリケーションの Web 化 既存資産の活用をしたい ( プログラムやスキル ) JavaやPHP Javaによりロジックを再構築して [ フルJava 型へ ] 新規にWebシステムを作りたいで新規開発 既存画面の制約を受けても対話型の画面やロジックをそのまま使用したい 既存画面の制約を受けずに画面やロジックを自由に設計したい 開発なしでそのまま 画面の見栄えを 画面とともに画面の流れも Javaの開発は JSFを中心とした ブラウザーに表示したい カストマイズしたい カストマイズしたい 一切おこないたくない Java 技術で開発したい ( 画面 DDS 必要 ) ( 画面 DDS 不要 ) キー操作を継承して入力スピード重視 代表的リフェーシングソリューション マウス操作も取り入れて GUI インターフェース重視 HOD* WebFacing HATS* XML-Bridge フレームワーク Web Revolution framework CS Bridge for Java PCOM* と同等の機能を 5250 画面 DDSソースから 対話型 5250 画面を RPG/COBOLプログラムを呼び出すJavaフレームワーク Javaで実現するようにした Web 用画面 (JSP) を 定義されたルールに基づき JT/400ドライバーにより直接呼出 Socket 通信により連携 Appletエミュレーター 生成するツール 動的にHTML 変換するツール スタイルシート (XSL) により画面生成 JSFにより画面生成 *HOD = Host On-Demand *HATS = Host Access Transformation Services *PCOM=iSeries や zseries のエミューレーター S/W 8 右に行くほど開発の柔軟性とアプリケーションの機能拡張の範囲を高める事が可能となります 低カストマイズレベル & 開発コスト高

9 例 ) IBM i アプリケーション Web 化手法選択ポイント 以下は一例です 個々のケースでどの項目を優先させるかによって最適な手法が変わってきます 自社が重視すべき項目と適用したいツールを特定して下記のようなマトリックスで比較することをお勧めいたします 以下は典型的なSystem i ユーザーを想定したケースです 一例ですので個々のユーザーの条件により などは異なってきます RPGで既存アプリケーションを開発 RPG 開発スキルあり Java, PHPなどの言語スキルはあまりない 自社が優先する項目 説明 方法 1 オープン系の手法 方法 2 RPG,COBOL をロジックに活用 方法 3 既存 5250 アプリケーションを GUI 化 方法 4 RAD, 4GL ツールの利用 備考 開発生産性 開発のリスク 他の Web アプリケーションとの連携 SQL チューニング アプリケーション開発の生産性 パフォーマンスネックなどトラブルが発生する可能性 他サーバー (UNIX, Windows 含 ) 上の Web アプリケーションとの連携 中 高 高 高 高 低 低 問題なし 問題なし 問題なし DB インデックスや SQL 文のチューニング 必須 不要 不要 低 問題なし ケース毎 Java, PHP もフレームワーク利用で生産性は にできます Java, PHP スキルがあれば方法 1 は になります Web ページとしての連携に差異はありません SQL での DB アクセス使用時は DB インデックスと SQL 文のチューニングが必須です 価格 ツール価格 ランタイムユーザーの価格 ケース毎 ケース毎 ケース毎 ケース毎 ツール本体の価格 実行時のユーザーライセンスの価格は異なります 保守性 プログラムの保守性 ケース毎 ケース毎 ケース毎 ケース毎 保守性についてどのような観点を重視するかによって評価が変わります バージョンアップ時のリスク OS, プログラムバージョンアップが容易か ケース毎 リスク低 リスク低 ケース毎 OS, ツールのバージョンアップについても考慮が必要です 将来的な機能拡張 将来的な機能拡張 制約なし 制約なし 制約あり 制約なし 第 2 次ステップ以降での機能拡張時 制約などはないか 9 評価基準となる項目はユーザーごとに異なります 自社の評価基準を明確にする事が必要です

10 ワークシート自社 IBM i アプリケーション Web 化手法適用について 自社が優先する項目 自社のケースを考えてみましょう 説明 方法 1 オープン系の手法 方法 2 RPG,COBOL をロジックに活用 方法 3 既存 5250 アプリケーションを GUI 化 方法 4 RAD,4GL ツールの利用 備考 開発生産性 開発のリスク 他の Web アプリケーションとの連携 SQL チューニング 価格 保守性 バージョンアップ時のリスク 将来的な機能拡張 アプリケーション開発の生産性 パフォーマンスネックなどトラブルが発生する可能性 他サーバー (UNIX, Windows 含 ) 上の Web アプリケーションとの連携 DB インデックスや SQL 文のチューニング ツール価格 ランタイムユーザーの価格 プログラムの保守性 OS, プログラムバージョンアップが容易か 将来的な機能拡張 10

11 Part.2 IBM の提供する IBM i Web 化ソリューション 11

12 1. HOD : Host On-Demand ホスト オン デマンド 機能概要 PCOMM エミュレーターの実行プログラムを HOD サーバー上にインストールしておき ユーザー実行時に ( 初回のみ )HOD サーバーからダウンロードしてエミュレーターを実行する PCOMM とほぼ同等の CUI インターフェースのみ メリット クライアント PC に対して一台ずつ PCOMM エミュレーターを導入する必要がない PCOMM の端末セッション定義を HOD サーバー上で一元管理できる クライアント PC 上での設定不要 バージョンアップや PTF 適用は HOD サーバーだけでよい PCOMM を導入していない PC 例えば 急な外出先や取り引き先からも 5250 エミュレーターを利用可能 CUI で通信トラフィックが非常に軽い ( 通常, 一画面 2~5KB 程度 ) HOD 初回実行時のみ または指定したタイミングでエミュレーターのプログラムを PC にダウンロード HOD サーバー HODサーバーはIBM i 業務機と同一でも可 PCサーバーでも可 telnet5250 で接続 IBM i 業務機 12

13 開発環実行環境IBM Power Systems - IBM i 従来の HATS と WebFacing が完全に統合され 実行時ライセンス WDHT は新しく HATS V7.1 に統合されました ~HATS V5 HATS V6 HATS V HATS for 5250 V7.1 WDSc WDSc HATS WebFacing HATS 境Tool Kit Tool Tool Kit WebFacing Tool RDi SOA HATS Tool Kit WebFacing Tool HATS for iseries WAS (Exp/Base/ND) WDHT WDHT HATS V7.1 DDS なし画面を ebfacing で Web 化する場合 WAS (Exp/Base/ND) WAS *1 (Exp/Base/ND) *1 HATS V7.1 で作成した WebFacing アプリケーションについては IBM i の統合 Web アプリケーションサーバー (LWI) でも実行可能です 13

14 HATS V7.1 実行環境 開発者 RDi SOA で開発 JSP, ビーン etc PC 上でコード開発し WAS へデプロイ ( エクスポート ) オリジナルの 5250 画面 IBM Software Group WebFacing アプリケーション * 年以降発表の iseries や i5 + i5/os V5R4 では HATS, WebFacing とも対話型 CPW を使用しません エンドユーザー HATS アプリケーション HTTP / HTTPS HTTP サーバー WAS WebFacing サーバー プログラム実行 RPG,COBOL,etc. 対話型ジョブ (QINTER) 1WebFacing サーバージョブ経由 Telnet 2Telnet 接続 14 i5/os V5R4 以降 HATSアプリケーションの接続形態は1WebFacingサーバージョブ経由接続 2Telnet 接続の二種をサポート HATSアプリケーションにおけるワークステーションIDの固定機能は2Telnet 接続のみサポート (WebFacingアプリケーションの場合 ワークステーションIDの固定機能はありません ) *1 旧 System i モデルでの5250 対話型 CPWが不要となるのはWebFacingアプリケーションと HATSアプリケーションで1WebFacingサーバージョブ経由接続の場合のみ Power Systems JS12ほかブレードサーバーではCPU 能力に対話型 CPWとバッチ型 CPWの区分はなく 対話型 バッチ型いずれも最大限に CPU 能力を使用可能です

15 HATS V7.1 の新しい機能 従来の HATS, WebFacing 機能を一つに統合 また従来のブラウザーだけでなくモバイル リッチクライアントなどあらゆる環境で HATS を利用可能になりました リッチクライアント ブラウザー ポータル モバイル Web サービス クライアント上での実行され より高機能なアプリケーションを作成可能 Eclipse Rich Client Platform(RCP) 上での稼動 Lotus Expeditor 上での稼動 クライアント側はブラウザーだけで稼動 HTML だけを使用 Internet Explorler, Firefox をサポート ポータルでの HATS アプリケーションサポート ポートレット間連携機能をサポート JSR 168 ポートレット仕様に準拠 モバイル端末からのホストアクセスをサポート セルフサービストランザクションの構築 ホスト上の基幹業務を Web サービスに展開 重要なアプリケーション データにたいするコントロールされたアクセスを実現 既存 5250 アプリケーションを最小限の工数 費用であらゆる形式に拡張可能 HATS V4, V5, V6, V7, HATS V4 LE, V5 LE から HATS V7.1 へのマイグレーションが可能です IBM Software Group 15 プログラム RPG,COBOL,etc.

16 2-1. WebFacing 機能概要 ユーザー作成の 5250 アプリケーションについては画面 DDS を RDi SOA に含まれる WebFacing Tool でプリコンパイルして JSP 画面を事前に作成しておく IBM i システム画面 QUERY などは HATS のデフォルトレンダリング機能を利用して Web 画面を生成 WebFacing で開発したアプリケーションは 5250 画面 : Web 画面は必ず 1 : 1 となる ただし WDSC V7 以降の WebFacing+HATS プロジェクトでアプリケーションを開発した場合 特定画面を HATS モジュールで開発し 5250 複数画面を 1 Web 画面に統合も可能 ランタイムライセンスとして 2 ユーザーが RDi SOA に標準添付 3 ユーザー以降は HATS アプリケーションと共通で使用可能な HATS V7 ライセンスが必要 メリット RDi SOA に含む WebFacing Tool で開発 5250 DDS の知識だけで開発が可能 非常に簡単 5250 プログラム変更不要 既存の 5250 アプリケーションで機能が十分で 画面インターフェースだけを GUI, ブラウザー化したい 低コスト 短期間開発に最適 WDSC V7 RDi SOA V7.1 以降で HATS と統合したアプリケーションを作成可能となり カスタマイズの範囲が広くなった DDS 画面をプリコンパイルする事により 入力フィールドの入力値チェック用 Javaスクリプト等を自動生成 ( 数値 文字 DBSC, 混合など入力可能文字の属性を制限できる ) 特に入力画面を短時間で作る場合には生産性が非常に高い 対話型ジョブとして RPG,COBOL などを CALL する HTTP サーバー WebFacing アプリケーション アプリケーションサーバー WASなど RPG, COBOL, CLなど データベース 16 ブラウザーで接続 IBM i 業務機

17 WebFacing アプリケーションのメリット PCOMM と同等のユーザー操作性を実現 5250 画面定義 (DDS ソースファイル ) から事前コンパイルを行い Web ページ (JSP) を生成して使用 カスタマイズ無しで PCOMM と同等の操作性を実現 以下の機能を自動生成 PCOM フィールド属性 (SBCS, DBCS, 混在フィールド 数値 文字 ) のエラーチェック カスタマイズ機能は HATS アプリケーションより限定的 複数 5250 画面を 1 枚の Web ページに統合できない (HATS アプリケーションは可能 ) など 追加スキル不要で開発 ウィザードによる変換だけで基本開発ができる DDS の知識だけで開発が可能 HATS と同じ開発ツール RDi SOA に含まれる WebFacing Tool 上で開発を実行 イメージ プルダウンリスト フィールド等の追加も容易 HATS やユーザー作成 Web アプリケーションとの連携が可能 対話型プロセッサー不要 2003 年以降発表の iseries から Power Systems 以前までのモデルでは対話型プロセッサー不要 * Power Systems, 2008 年以降のブレードサーバー上で IBM i を稼動させる場合は CPW 値に対話型 CPW, バッチ型 CPW の区分けはなく 全 CPU の能力を対話型ジョブでも使用可能です 17

18 WebFacing アプリケーションの特徴 WebFacing は現在の Web 化ツール中 PCOMM の操作性を最も忠実に実現しています WebFacing は 5250 の DDS ソースファイルを元に Web 用の JSP を生成する方法を採用しています この方法によって 5250 フィールド情報を WEB ページ上でも再現可能にし PCOMM と同等の入力値のチェックやカーソルタブの動作を再現しています (HATS V7 以降でも同様の機能を実現しています ) また Field Exit キーなど PCOM ユーザーが常用する機能も標準でサポートします (HATS V7.1 では一部機能のカスタマイズが必要 ) WDSc V6 以降の WebFacing Tool ではシステム提供画面 (OS/400 画面 QUERY, DFU 等の DDS ソースファイルの無い 5250 画面 ) を含むすべての 5250 画面を利用可能となりました この機能は HATS の自動変換機能を WebFacing に組み込むことで実現されました HATS と WebFacing が製品統合されたこともあり WebFacing アプリケーションの V7 以降ではラインタイムユーザー数分の HATS ライセンスが必要となります (2 ユーザー分は開発ツール RDi SOA に付属しています ) 生成される Web ページ (JSP) は DDS のレコード様式単位に生成され バックグラウンドで実行される 5250 対話型ジョブの 5250 画面と 1:1 の対応になります このため 5250 上で複数の画面を一枚の JSP にまとめて表示することができません また 端末 ID の固定にも対応していません このように いくつかの制限はありますが 特に大量の 5250 画面を一括変換し かつ カスタマイズ工数は最小化したい ( 一画面ずつカスタマイズはしたくないといったような ) ケースでは最適なツールです IBM i HTTP/ HTTPS HTTP サーバージョブ プログラム実行 RPG,COBOL,etc. DB ブラウザー WAS にインストール WebFacing JSP, ビーン,etc IBM i 対話ジョブ制御 WebFacing Tool WebFacing JSP, ビーン,etc WAS WebFacing サーバージョブ 開発用 PC に RDi SOA を導入 DSPF ソースを取り込み一括変換 JSP 等を自動生成 同一 PGM を WebFacing Tool と 5250 端末の両方から使用可能 18

19 2-2. HATS : Host Access Transformation Service 機能概要 ブラウザーから IBM i に接続して 5250 対話型ジョブを起動 この際生成される 5250 データストリームを動的に HTTP に変換して Web 画面を生成する ユーザー作成によるカスタマイズ画面がアプリケーションサーバー上にあった場合にはユーザー作成のカスタマイズ画面を使用 WDSC V7 以降で WebFacing+HATS プロジェクトを作成可能 デフォルトは WebFacing で作成し 画面統合などカスタマイズが必要な特定画面を HATS モジュールで開発する といった組合せが可能に また WDSC V7 では WebFacing と似た入力値チェックスクリプトも生成可能 ランタイムライセンスとして 2 ユーザーが RDi SOA に添付 3 ユーザー以降は WebFacing と共通で使用可の HATS V7 ライセンスが必要 メリット あらゆる 5250/3270 画面を http に変換可能 ブラウザー以外の携帯端末もサポート 端末 ID 固定が可能 強力なカスタマイズ機能 ( 複数 5250 画面の統合 フレーム分けなど ) Java スクリプトのスキルがあった方がベター WDSC V7 以降で WebFacing と統合したアプリケーションを作成可能となり 簡単なカスタマイズで済む場合は WebFacing で変換 複雑な機能が必要な場合は HATS を選択といった選択の範囲が広くなった 対話型ジョブとして RPG,COBOL などを CALL する HTTP サーバー HATS アプリケーション アプリケーションサーバー WASなど RPG, COBOL, CLなど データベース 19 ブラウザーで接続携帯端末も可能 System i 業務機

20 WDSC V7 以降での HATS の機能拡張 WDSC V7 RDi SOA V7.1 以降では HATS アプリケーションでも入力値チェックスクリプトなどを生成できる WebFacing と同様に 従来のエミュレーターの使い勝手に近づける事が可能 HATS プロジェクトで 従来型端末エミュレーター を指定してプロジェクトを作成する 20

21 HATS アプリケーションのメリット あらゆる画面を即 Web 化 アプリケーション実行時の 5250 / 3270 データストリームをリアルタイムに解釈して Web ページをダイナミックに生成 事前にユーザーが作成したカスタマイズした Web ページがある場合は画面単位でそちらを使用する 既存の RPG, COBOL などの 5250 アプリケーションは一切変更しない状態で Web 化が可能 あらゆる 5250 / 3270 画面を Web 化しブラウザーから利用可能 標準機能で OS/400 システム画面, QUERY, DFU 等々も利用可能 高度かつ容易なカスタマイズが可能 強力なカスタマイズ機能 WebFacing より高度なカスタマイズが可能 複数の 5250 画面を一ページの JSP にまとめて表示が可能 グラフ, イメージ, プルダウンリスト, フィールド等の追加も可能 複数画面をタブ化して統合 端末 ID の固定が可能 必須ではないが Java スクリプトのスキルがある方がカスタマイズをより高度に可能 21 対話型プロセッサー不要 WebFacing と同様のハードウェアにおいて対話型 CPW 不要で動作 ( ただし端末 ID 固定ができません ) 旧バージョンで作成した HATS アプリケーション実行時には対話型プロセッサーが必要になります (HATS V6 にバージョンアップが必要 ) * Power Systems, 2008 年以降のブレードサーバー上で IBM i を稼動させる場合は CPW 値に対話型 CPW, バッチ型 CPW の区分けはなく 全 CPU の能力を対話型ジョブでも使用可能です

22 HATS アプリケーションの特徴 HATS アプリケーションは WebFacing アプリケーションと比較すると その特性がわかりやすくなります まず WEB 画面を表示するためのしくみとして DDS のソース画面を元に事前コンパイルするのではなく 5250 データストリームを WAS 上で Web ページに変換しています このため 5250 画面であれば種類を問わずどのような画面でも Web ページに変換が可能です また WebFacing と比較すると 端末 ID の固定が出来るなどの特徴もあります 加えて HATS ではカスタマイズ機能が強力な点も魅力です 例えばマクロ機能を利用して 複数の 5250 画面を一枚の Web ページにまとめて表示する事ができます また 5250 画面のうち表示したくない画面をスキップして必要な画面だけを web に表示する事もできます 例えば ログイン後 5250 では 1. メインメニュー 2. 営業メニュー 3. 照会メニューとある場合 5250 アプリケーションを変更せずに ログイン後に 3. 照会メニューを表示する事ができます また JSP ページを Java スクリプトを使用して高度にカスタマイズも可能です HATS のアドバンテージはカスタマイズなしの場合には非常に低コスト 短時間 ( おそらく WebFacing 以上に ) でありながら カスタマイズした場合には通常の Web アプリケーションと同等にカスタマイズ可能な点 といえます ( ただしカスタマイズの場合 カスタマイズなしのケースより相応の開発工数は必要となりますが ) また最新版の HATS V7 以降でサポートされる WebFacing アプリケーションとの融合もアドバンテージです Web 化したい 5250 画面毎にカスタマイズする しない WebFacing と組み合わせる などを選択可能です IBM i ブラウザー HTTP / HTTPS 変換ルール定義後 WAS にインストール HTTP サーバージョブ HATS サーバージョブ WAS プログラム実行 RPG,COBOL,etc. IBM i 対話ジョブ DB HATS スタジオ HATS サーバージョブ定義 * 定義作成 / カスタマイズ用に PC 側に導入 HATS サーバー 同一 PGM を HATS と 5250 端末の両方から使用可能 22

23 WebFacing の基本機能 1 入出力フィールドの入力値チェック 5250 DDS 情報から入力フィールド属性に合わせて入力値チェックの Java スクリプトを自動生成 ブラウザー上で入力した値のチェックができるため 従来の 5250 端末と近い操作性を実現 23

24 WebFacing の基本機能 2 選択項目のラジオボタン化 DDS キーワードに RANGE キーワードが指定されている場合 自動的にラジオボタン化されます 24

25 WebFacing の基本機能 3 ブラウザー クローズ時 バックエンド対話型 5250 ジョブの ENDJOB 実行 ユーザーが WebFacing のブラウザー画面を index.html 以外の画面でクローズした時 5250 対話型ジョブに ENDJOB を実行する機能が拡張されました これにより WebFacing の対話型ジョブだけが残る状況が発生しにくくなります ( ただし ファイル更新中のクローズなどはロックが発生し 対話型ジョブが残る可能性があります これは PCOM などでも同様ですが できるだけ INDEX.HTML 以外でのブラウザークローズは避けることをお勧めいたします ) 対話型 5250 ジョブをクローズ 25

26 WebFacing でのカスタマイズ例 画像の追加 5250 画面に表示される商品コードと同じ商品画像ファイルを追加して表示 26

27 OS 画面 ライセンス画面など DDS のない画面の表示 HATSとの統合により実現した機能例 ) QUERY/400 実行画面 27

28 HATS の基本機能 メニュー画面の変換パターン選択 画面単位に変換パターンを設定可能 メニューは 1 ボタン 2 ボタンテーブル 3 リストボックス 4ラジオボタンから変換方法を選択 特定メニュー番号のみ表示させるには選択後 JSPをカスタマイズするだけ ホスト側の修正一切不要 1 ボタン 2 ボタンテーブル 4 ラジオボタン 3 リストボックス 28

29 HATS 基本機能 ワークステーション ID の固定 HATS Studio 上の プロジェクト設定 - 拡張接続設定 で設定できます ホスト側の修正不要 現行業務の運用を Web ユーザーがそのまま継承可能 3270 LU 固定 5250 WSID 固定 * ただし WebFacing サーバー経由で HATS を接続する場合 端末 ID 固定できません 29

30 HATS 基本機能 マクロによる操作の簡略化 不要な画面や 決まった操作を行う画面はサーバー側のマクロ設定でスキップ 途中の画面はブラウザーに表示されません (=PCOMM HOD のマクロとの相違点 ) 従来のエミュレーター画面遷移 メニュー番号を選択 検索キー種類を選択 検索したいコードを入力 検索データ表示 HATS のマクロ機能を使用すると 途中の画面はスキップして検索結果データだけ表示 30

31 HATS によるカスタマイズ 複数画面の統合 複数ページ ( サブファイルなど ) のホスト画面情報を Web ブラウザー上で 1 ページに 複数ページ分のデータを取得 1 ページの中でスクロール表示可能に 31

32 IBM Power Systems - IBM i HATS によるカスタマイズ 複数画面マージ バックエンドで実行している複数の 5250 対話型プログラムの画面を画面フローに関係なく 統合して 1 画面に表示できます 基幹ホスト (IBM i / Systemz) & データベース JDBC 接続 09 在庫照会 DB 07 発注残照会 ユーザーに見せたくない画面 フィールドはHATSでスキップし ブラウザーに表示しません 01 得意先照会 04 受注入力 PFキー H A T S による変換と画面生成 得意先マスターファイルを検索する SQL 実行 32

33 複数のメニュー実行結果をフレームに表示 データベース統合オブジェクトで得意先マスターを直接照会 プルダウンにセット ホストアクセス統合オブジェクトでホスト画面からデータ取得複数の 5250 画面を一つに統合 33

34 HATS によるカスタマイズ サブファイルのテーブルへの変換 数値のグラフ表示 サブファイルなど表形式で表示される数値データにVisualで効果的な変換を与えます 数値データ テーブルで見やすく 2 水平棒グラフ 折れ線 棒グラフに変換 1 テーブル 3 折れ線グラフ HATS Studio での設定画面 34

35 HATS によるカスタマイズ ポータル対応 ( ポートレット化 ) 5250 アプリケーション 既存の 5250 アプリケーションと画像検索のアプリケーションを WebSphere Portal と連携してフロントエンド統合した例 35

36 お客様からのご要望が多い Web 化の要件例 画面インターフェース リストボックスによる項目選択 ラジオボタンによる項目選択 WebFacing カレンダーによる日付入力 HATS 子ウィンドウによる項目検索 画面統合 1 画面統合 1 画面スクロール 画面のフレーム分け タブによる画面切替 バナーの展開 省略による画面切替 画面フローの見直し WebFacing HATS 36

37 画面インターフェース WebFacing ボタン 2 行で表示 ドロップダウン ( 選択 ) HATS ラジオ ボタン ( 選択 ) 2 行で表示 リンク 2 行で表示 ボタン テーブル 2 行で表示 37

38 カレンダー入力画面 WebFacing HATS 38

39 ( 参考 )5250 コンポーネントと HATS ウィジェットのマッピング比較 HATS V5 HATS V5 ホスト コンポーネントコマンド行フィールドフィールド テーブルファンクション キー入力フィールド 39 テキスト入力ドロップダウン ( データ入力 ) ポップアップラジオ ボタン ( データ入力 ) フィールド テーブル水平棒グラフ 折れ線グラフ垂直棒グラフボタン リンクボタン テーブルドロップダウン ( 選択 ) ラジオ ボタン ( 選択 ) テキスト入力チェック ボックス カレンダー ウィジェット ドロップダウンデータ入力ポップアップ ラジオ ボタンデータ入力 選択リスト ホスト コンポーネント ヒント付き入力フィールド サブファイルテキスト表示されるテーブル ウィジェット ドロップダウンデータ入力ポップアップラジオ ボタンデータ入力ドロップダウン ( 選択 ) ラジオ ボタン ( 選択 ) ボタンリンクボタン テーブルサブファイルラベルテーブル水平棒グラフ折れ線グラフ垂直棒グラフ HATS はこの範囲ならば GUI で選択するだけで カスタマイズなしで簡単に Web 化可能 強力なカスタマイズ機能が標準搭載

40 画面統合 (HATS での統合例 1) F2 キーを押すと得意先の詳細内容が表示される 受注入力画面 1 受注入力画面 1 の内容を確定すると明細入力画面へ進む タブ化可能 受注入力明細入力画面 40 画面統合可能

41 画面統合 (HATS での統合例 2: フレーム分け ) メインメニュー 10 を選択して実行キーを押下すると サブメニューに進む メインメニューとサブメニューをフレームわけすることが不可能 メインメニュー 受注 売上メニューボタンを押下すると サブメニューに進む 受注 売上メニュー 41 受注 売上メニュー

42 3. XML-Bridge フレームワーク 機能概要 すべてのビジネスロジックを RPG/COBOL 言語にて開発 フル Java での開発に比べ開発生産性が高く短納期 低コストでの開発が可能 WebFacing, HATS は既存で対話型 5250 アプリケーションがあり その 5250 アプリケーションは変更しない という開発手法が基本であるが XML-Bridge ではアプリケーションロジックを新たに RPG, COBOL などで作成する ( あるいは既存 5250 アプリケーションを修正して使用する ) という開発手法になる Java,php の代わりに RPG を使用して新たに Web 用ロジックを作る というイメージ メリット お客様が有する高いRPG/COBOLスキルと修得しやすいXMLスキルのみで開発可能 Javaスキル一切不要でも開発可能 WebFacing, HATSなど既存 5250アプリケーションの制約に囚われずに より自由度の高いWebアプリケーションを構築可能 画面や機能の変更は XMLとRPG/COBOLの変更のみで保守が容易 携帯端末も利用可能 バッチジョブとして RPG,COBOL などを CALL する HTTP サーバー XML- Bridge アプリケーション アプリケーションサーバー WASなど RPG, COBOL, CLなど データベース 携帯端末で接続 ブラウザーで接続 System i 業務機 42

43 XML-Bridge フレームワークの特徴 ブラウザー IBM i HTTP サーバー XML による PGM 呼出定義 バッチジョブとして実行 特徴 携帯やハンディ端末 XML-Bridge フレームワーク WAS XSL による画面スタイルシート PCML Call RPG, COBOL DB お客様が有する高い RPG/COBOL スキルと修得しやすい XML スキルのみで Web 化できます Java スキルを一切必要としません すべてのビジネスロジックを RPG/COBOL 言語にて開発するため Java での開発に比べ開発生産性が高く 短納期 低コストでの開発が可能です ミドルウェアやツールの持つ制約条件に縛られずに自由度の高い Web アプリケーションを構築できます 画面や機能の変更には XML と RPG/COBOL の変更のみおこなえばよいため保守が非常に容易です 43

44 XML-Bridge での画面例 1 F2 キーを押すと得意先の詳細内容が表示される 受注入力画面 1 受注入力画面 1 の内容を確定すると明細入力画面へ進む タブ化可能 カレンダーの赤反転可能 受注入力明細入力画面 44 画面統合可能

45 XML-Bridge での画面例 2 メインメニュー 10 を選択して実行キーを押下すると サブメニューに進む メインメニューとサブメニューを フレームわけすることが可能 受注 売上メニュー 45

46 XML-Bridge フレームワークのデザインコンセプト 1RPG/COBOL を簡単に呼び出せること RPG/COBOL 資産を有効活用することを最大の目的としたフレームワークである以上 RPG/COBOL プログラムを簡単に呼び出せなくてはなりません 2 画面の変更を簡単におこなえること 最も変更要求の高い画面回りの変更を簡単におこなえるようにすることで Web システムの開発基盤としての全体の開発生産性が高くなります XML ファイルによる呼出定義 XSL ファイルによる画面生成定義 3Java のスキルを必要としないこと RPG/COBOL プログラマーにとっては敷居の高い Java スキルを必要としないことが フレームワークによる Web システム開発に使いやすさをもたらします 4 ロジックを RPG/COBOL で開発すること すべてのビジネスロジックを RPG/COBOL で開発できればこれまでの基幹システム開発と同じレベルで自由に欲しい機能を実現できます XML/XSL/RPG or COBOL スキルだけで開発 フレームワークは必要最小限の機能のみ 46

47 4. C/S Bridge 機能概要 フロントエンドのプレゼンテーションまたはアプリケーションロジックとi5 上のデータベース またはアプリケーションロジックを連携するための通信ミドルウェア フロントエンドの開発言語は Delphi VB6 VB.NET, Javaをサポート C/S BridgeはWeb 版とクライアントサーバー (C/S) 版の2 種類があります ビジネスロジックはi5 上のILE-RPGもしくはILE-COBOLで記述 メリット RPGにより開発したビジネスロジックとJSFをベースとしたWebアプリケーション ( フロント部分 ) を連動することにより 基幹 Webアプリケーションを容易に開発可能 既存のクライアント サーバーアプリケーションのユーザーインターフェースを変更せずにデータベースをDB2/400 化するなどしてi5 上に統合する事が可能 高速な通信処理速度を実現しており 複雑なユーザーインターフェースでもレスポンスを良好に保てる バッチジョブとして ILE-RPG,ILE-COBOL を CALL する HTTP サーバー C/S Bridge アプリケーション アプリケーションサーバー WASなど ILE-RPG, ILE- COBOL データベース 上記構成は一例です 携帯端末で接続 ブラウザーで接続 System i 業務機 47

48 IBM IBM Power Systems - IBM i C/S Bridge (Web 版 ) の特徴 クライアント Web ブラウザーインターフェース サーバー Power Systems - IBM i Web コンテナー部 (JAVA) ビジネスロジック (ILE RPG / ILE COBOL) 特徴 特徴を記述 JAVA のオープン性を最大限に活用可能 基幹 WEB アプリケーション用拡張機能 Java Server Faces (JSF) 基幹 RPG/COBOL 連携プログラム WebSphere Application Server Web Revolution ( 通信ミドルウェア ) 高速連携 iseries の性能を最大限に活用可能 基幹システム業務ロジック ( 下図ボックスは一例です ) 受注 売上管理 売掛管理 在庫管理 経営統計 発注 仕入管理 買掛管理 特徴 i5os( 優れた堅牢性 ) RPG により開発したビジネスロジックと JSF をベースとした Web アプリケーション ( フロント部分 ) を連動することにより 基幹 Web アプリケーションを容易に開発できます RPG/COBOL Web 間のデータ送受信を専用のソケット通信で実装 非常に高速な処理が可能 従来の WEB アプリケーションでは困難であった WEB ブラウザーインターフェースでのリッチクライアント化を容易に実現できます スプールファイルも Web ブラウザーから閲覧 印刷可能です 48

49 ( 参考 )C/S Bridge によるクライアント サーバー型データベースの統合 想定ケース VB, VB.NET, Delphi 等で業務ロジックを記述し PC サーバー上でデータベースを持つ C/S 型アプリケーションがすでに存在している 各支店ごとに独立した PC サーバー上のデータベースがあり バッチ処理で MS Access <-> DB2/400 間のデータレプリケーションを行っている 問題点 支店毎に PC サーバーのデータベースが分散しており データの整合性保持の問題 ( データ不整合 データレプリケーション エラーへの対応 ) やメンテナンスの工数増大 PC サーバー上のデータベースと本社データベースの更新はバッチ更新のためクライアント側のアプリケーションから本社データベースをリアルタイムに参照できない C/S Bridge でのアプリケーション改修メリット VB, VB.NET, Delphi で記述したユーザーインタフェースは変更せずにデータベースを MS Access -> DB2/400 へ統合が可能 上記の問題点の改善 C/S Bridge は Web ソリューション以外に クライアント サーバーアプリケーションを System i へ統合するツールとして活用できます A 支店 A 支店 本社 VB 等 VB 等 データベース MS Access 等 B 支店データベース CS Bridge で改修 B 支店 VB 等 VB 等 CS Bridge インターフェースプログラム 業務ロジック DB2/400 MS Access 等 49 ユーザー インターフェースは変更せずに統合も可能 ( 既存クライアント側ロジックの修正は必要です ) System i

50 5. Java IBM Power Systems - IBM i 概要 業務用 Webアプリケーション開発用としては最もポピュラー かつ実績の多い言語 プログラミングに習熟するためには相応の学習が必要だが フレームワークの活用によりカバーできる場合も多い 現時点のJavaバージョンでは PHPなどの言語 ( インタプリター型やスクリプト言語 ) に比較すると単純なプログラムをすばやく作る という点ではやや劣る 一方標準化や正規化 作成したプログラムの管理がし易く ある程度の規模以上のアプリケーション開発用に向いている メリット PHPなど他の言語 ( インタプリター型やスクリプト言語 ) に比べプログラムの標準化 管理がし易く プログラム数が多くなるほど生産性でメリットが出てくる フレームワークと呼ばれる市販製品 サービス製品を利用する事でアプリケーション開発の生産性を飛躍的に向上させる事が出来る ( 例 Intramart( イントラマート,NTTデータ) 楽々 FrameworkⅡ( 住友電工情報システム ) WACCS(IBM) など ) 次期 Javaバージョンはphpなどスクリプト言語のメリットを組み込んだものになるといわれている PCML, Web サービスで RPG,COBOL をバッチ CALL 可能 HTTP サーバー Java アプリケーション アプリケーションサーバー WASなど RPG, COBOL, CL など データベース 50 ブラウザーで接続 System i 業務機

51 6. PHP IBM Power Systems - IBM i 概要 ブラウザー等からアクセスするWebアプリケーション作成に特化した言語 HTTPサーバー上で動作し HTTPサーバー上の文書が要求される毎に文書に記述されたPHPのプログラムを実行し その結果をウェブブラウザに対して送信する ウェブブラウザに送信されるデータは通常のHTMLであり PHPのプログラムを含まない この点でHTML 埋め込み型のクライアントサイド スクリプト言語 (JavaScriptなど) と本質的に異なる 個人のホームページに簡単に動的なコンテンツを追加したい というのが元々の発想 一方でシステムが大規模になったときの管理や標準化には難しい点もある PHP 5 でオブジェクト指向が強化され Java 的なオブジェクト指向プログラミングができるようになった メリット スクリプト言語で非常に単純な構成であるため 分かり易い オープンソースで業務利用可能な部品が多く存在している これらを組み合わせる事で低コストで業務アプリケーションを構築する事も可能 著名なオープンソースの例 ) XOOPS( ズープス ) CMS( コンテンツ管理 ) WordPress( ワードプレス ) MySQLを使用したブログソフトウェア PukiWiki( プキウィキ ) ウィキソフトウエア Zend Core とは php 実行環境を提供するソフトウェア 各種 OS 用が存在する HTTP サーバー PHP アプリケーション PASE 上の HTTP サーバー RPG,COBOL をバッチ実行も可能 RPG, COBOL, CL など データベース 51 ブラウザーで接続 System i 業務機

52 Web 化ツールにおける印刷 Web 化ツールはエミュレーター画面の GUI 化 /Web 化に主眼印刷セッションについては多くの方法があるため Web 化ツールには組み込まれていない場合が多い 以下のような印刷用機能 ツールを組み合わせる必要がある PCOMM 印刷セッション HPT(Host Print Transform) InfoPrintサーバー (5722-IP1 ) Web 印刷ソリューション PCOMM などエミュレーターの印刷セッションを従来どおり使用する メリットは既存の印刷プログラム 印刷フォーマットなどを変更なしで使用できる点 OS/400 標準機能 ( 無料 ) System I 上でスプールファイルを ASCII 印刷データストリームに変換しプリンターへ送信 印刷 LIPS, ESC/P はじめサポートするプリンタータイプが多い OS/400 のライセンスプログラム HPT より高度な機能を提供 スプールの PDF への変換 GIF, JPEG 等イメージの追加が可能など ベンダー製 Web 環境用印刷ソリューション SVF,Print-pro,UT/400 -Web 他 多くのソリューションを利用可能 52

53 基幹業務を Web 化すると 印刷業務はどうなる? 既存印刷環境 アプリケーション スプールファイル (EBCDIC コード ) EBCDIC TWX 接続 / LAN 接続 ホスト プリンター ASCII IBM 5x27 IBM 54xx PC プリンター エミュレータ上でデータ変換 IBM PAGES プリンター 他社製プリンター EBCDIC ASCII の変換を行っていたエミュレータが Web 化に伴い廃止されると PC プリンターへの出力は?? プリンター機種は? 接続形態は? 機能は? 費用は? 53

54 移行方法その 1: 既存印刷環境を可能な限り活用 方法 1. ホストプリンターは LAN 接続化方法 2. PCOM+PC の代替として 5400 エミュレーターを使用して 557x プリンターを接続方法 3. HPT を利用して iseries より直接 IBM PAGES 対応プリンターへ出力 * 他社製プリンターは別な方法を検討 ( 方法 3. の HPT は他社製プリンターでは制約あり ) アプリケーション LAN 接続 ホスト プリンター IBM 5x27 IBM 54xx EBCDIC スプールファイル (EBCDIC コード ) LAN 接続 5400 エミュレーター ASCII HPT (OS/400 標準機能 ) PC プリンター IBM 5577, 5579 ASCII コードへ変換 ブラウザ ( スプール表示, 印刷指示 ) ASCII LAN / WAN 接続 ASCII PC プリンター IBM PAGES プリンター 54

55 移行方法その 2: 印刷出力を PDF 化 PDF 化することで, あらゆるプリンターに対応可能 iseries 上で既存アプリケーションの印刷出力をPDF 変換 Infoprint Server と AFP フォントが必須 *1 APWを使用している場合, APW IPDS フィーチャー (5722-AP1オプションライセンス) が追加で必要 iseries Access for Web からGUIでスプール表示,PDF 変換等の管理も可能 注 *1 iseries Access for Web だけでも PDF ファイルに変換可能ですが AFP フォントがない場合 テキスト部分もイメージ変換されてしまいます 既存アプリケーション (SCS) 既存アプリケーション (AFP) 既存アプリケーション (APW) IPDS フィーチャー SCS 印刷出力 ( スプール ) AFP 印刷出力 ( スプール ) AFP 印刷出力 Infoprint Server AFP フォント PDF PDF ファイル生成 保管 55 ブラウザ ( スプール表示, 印刷指示 ) iseries Access for Web により管理可能 (HATS アプリケーション等からリンク可能 )

56 移行方法その 3 印刷アプリケーションを新規に開発 HPT+IBM PAGES,PDF で対応できない場合, 印刷ソリューションを活用します ( 印刷アプリケーションは新規作成 ) 他社製プリンター, IBM PAGES 対応プリンターを使用する場合 プリントサーバーとして PC サーバーが別途必要な場合があります 帳票設計用 PC が必要な場合があります 印刷用データ 印刷ソリューション DURL JointBase/PrintLauncher Ricoh Print Server PrintPro for Web Super Visual Formade UT/400 WPM+e-SYOHSHI 印刷ソリューション製品の詳細は p.37 以降を参照下さい 帳票フォーム 帳票設計用 PC 印刷データ PDF IXA / IXS *1 *1 IXA / IXS 以外の PC サーバー上でも可能です ブラウザ ( スプール表示, 印刷指示 ) LAN / WAN 接続 PC プリンター IBM PAGES プリンター 他社製プリンター 56

57 Part.3 IBM i(i5/os) の Web アプリケーション実行環境 ( 復習 ) 57

58 IBM i の JVM 58

59 IBM i はオープン系と全く同じ Java, Web 環境を実装しています IBM i の Java 環境はオープン系と全く同一 オープン系と同一実装の IBM JVM (J9) で稼動 IBM J9 は全てのサーバーに共通の実装を持つ IBM Technology for Java VM を実装しています AIX, Linux, Windows 版 IBM J9 と同じ実装の JVM 特に AIX とは同じ H/W(Power Systems) でもあり全く同一にしか動作しない i5/os V5R3 以前は i5/os 独自実装の JVM のためチューニングやプログラムコーディング パフォーマンス上で特別な考慮点が必要でした オープン系サーバーと Java プログラム動作上差異はない さらに IBM i 上で動作させる事でサーバー統合 安定稼動 パフォーマンス向上 柔軟な稼動環境の実現などのメリットが得られる UNIX / Windows Web アプリケーション Web アプリケーション WAS アプリケーションの動作はオープン系と IBM i で全く同一 IBM i Web アプリケーション Web アプリケーション WAS IBM JVM (J9) AIX, Linux, Windows ハードウェア UNIX,Windows と IBM i は同じ実装の JVM を装備 IBM JVM (J9) IBM i ハードウェア 59

60 IBM i は業界最速クラスの Java パフォーマンスを実現 IBM Power Systems の Java パフォーマンス SPECjbb core benchmarks 結果 ベンダー システム名 GHz CPU OS JVMバージョン 数 IBM Power AIX 5.3 IBM J9 32bit 公開日 IBM Power Linux RHEL 5 IBM J9 32bit 4Q07 335,424 IBM Power IBM i V6R1 IBM J9 32bit 1Q08 311,505 Sun Sun Fire X Solaris Java HotSpot 32-Bit Server VM 1Q07 スコア Result 346,742 1Q08 303,297 Dell PowerEdge Windows BEA JRockit 1Q08 302,089 Server 2003 Enterprise x64 Edition IBM i は他社オープン系サーバーよりも高い Java, Web パフォーマンスを実現 AIX よりパフォーマンスが低いのは主に OS のオーバーヘッド ( セキュリティチェック 実行管理機能がより厳密 ) が高いため 言い換えればほんの少し処理速度を犠牲にして より安定した稼働環境 高いセキュリティを獲得している とも言えます SPEC and the benchmark name SPECjbb 2005 are registered trademarks of the Standard Performance Evaluation Corp. (SPEC). 60

61 HTTP サーバー, WAS サーバーは別サーバーが必須か? 特に POWER6 以降の Power Systems は処理能力が飛躍的に向上しています このためサーバーの CPU 処理能力的には必ずしも WAS, HTTP を別サーバー化する必要性はなくなっています ただしメモリ ディスクアーム数は 5250 だけの場合より多く必要となります 本来はプロトタイピングのアプリケーションを作成し サイジングの基礎データを取得してから サーバーの H/W 構成を決定するべきです しかしプロトタイピングを行わずにサーバー構成を決定しなければならない事が多く発生します プロトタイピングによるパフォーマンスデータ取得と その結果からのサイジングが不可能な場合 メモリの目安としては 500CPW あたりメモリ 1GB( 以上 ) を搭載する (POWER6 の場合 ) ディスクアーム数については一般化が難しいのですが 5250 だけの場合よりアーム数が相応に多くなるように構成を検討します HTTP, WAS サーバーを別サーバー ( 別 LPAR) 化したほうがいい場合としては以下が考えられます セキュリティ的な理由で HTTP サーバーや WAS サーバーを DMZ に配置したい場合など 冗長化構成や負荷分散の観点から複数サーバーで HTTP, WAS を稼動させたい場合など 61

62 IBM i のサポート JVM 57xx-JV1 *BASE に加えて 使用する Java バージョン ( 複数可能 ) を選択し GO LICPGM コマンドから導入します ライセンスプログラム 57xx-JV1 のオプション番号 JAVA_HOME 環境変数に指定するパス Java のバージョン オプション 6 - Classic 1.4 /QIBM/ProdData/Java400/jdk14/ 1.4 オプション 7 - Classic 5.0 /QIBM/ProdData/Java400/jdk15/ 1.5 オプション 8 - IBM Technology for Java ビット オプション 9 - IBM Technology for Java ビット /QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit 1.5 /QOpenSys/QIBM/ProdData/JavaVM/jdk50/64bit 1.5 オプション 10 - Classic 6 /QIBM/ProdData/Java400/jdk6 1.6 オプション 11 - IBM Technology for Java 6 32 ビット オプション 12 - IBM Technology for Java 6 64 ビット /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit 1.6 /QOpenSys/QIBM/ProdData/JavaVM/jdk60/64bit 1.6 Classic JVM IBM Technology for Java 62 今後は IBM Technology for Java (J9) の利用が推奨されます

63 IBM i 上で稼動する Java バージョンの設定 Classic JVM の場合 java.version システム プロパティーによって 実行される JDK が決定します Java 仮想マシンが稼働状態になってから java.version システム プロパティーを変更した場合 Java 仮想マシンを再起動後に反映されます IBM Technology for Java の場合 JAVA_HOME 環境変数を設定することによって どの 5761-JV1 オプション ( つまりどの JDK/ ビット モード ) を実行するかを選択します 必要に応じて使用する Java バージョンの環境変数を設定します ADDENVVAR ENVVAR(JAVA_HOME) VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit') ADDENVVAR ENVVAR(JAVA_HOME) VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk50/64bit') ADDENVVAR ENVVAR(JAVA_HOME) VALUE( /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit ) ADDENVVAR ENVVAR(JAVA_HOME) VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk60/64bit') 複数の JDK をインストールしている場合のデフォルト JVM の優先順位は以下のとおりです (IBM i 6.1 の場合 ) 1. オプション 7 - Classic オプション 10 - Classic 6 3. オプション 6 - Classic オプション 8 - IBM Technology for Java ビット 5. オプション 9 - IBM Technology for Java ビット 6. オプション 11 - IBM Technology for Java 6 32 ビット 7. オプション 12 - IBM Technology for Java 6 64 ビット 今後は IBM Technology for Java の使用が推奨されます 63

64 実行している JVM バージョンの確認方法 現在どの JVM を使用しているかは以下の方法で確認できます 結果に IBM J9 VM と表示されていれば IBM Technology for Java を使用していることになります ジョブ ログで確認 * JVM が実行されているジョブのジョブ ログを調べます シ ョフ. : ADMIN2 ユーサ ー. : QLWISVR 番号... : QHTTPSVR のサブシステム QHTTPSVR のジョブ /QLWISVR/ADMIN2 が 08/07/28 09:20:57 に開始された ジョブは 08/07/28 09:20:57 にシステムに入れられました JAVA 仮想マシンは IBM TECHNOLOGY FOR JAVA です PID(281) Java コマンドで確認 Java コマンド -showversion を追加するか * qsh または qp2term から java -version を実行します 64 $ > java -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build SR6b) IBM J9 VM (build 2.3, J2RE IBM J9 2.3 OS400 ppc-32 j9vmap (JIT enabled) J9VM _14218_bHdSMR

65 IBM i Java 環境の柔軟性 IBM i はジョブ毎に Java バージョンを変更可能 複数のJavaバージョンを1つのOS 上に導入可能 ジョブ実行時にJavaバージョンを指定可能 64ビットJVM, 32ビットJVMの変更 共存も可能 アプリケーションの移行 バージョンアップ時柔軟に対応可 旧バージョンのアプリケーションを稼動させながら 新バージョンのJVMで新規アプリケーションを開発 テストする 等 一つのOS 上で複数のJVMバージョン 異なった環境変数の実行環境を任意に構築できる UNIX / Windows 例 ) 原則 1 つの OS 上に 1 つの WAS バージョンのみ IBM i 例 ) 1 つの OS 上に複数の WAS バージョンを共存 HATS の 3 世代のアプリケーションを実行 HATS アプリケーション HATS 旧アプリケーション HATS 現行アプリケーション 次期アプリケーション WAS V5.1 WAS V4 WAS V5.1 WAS V6 JVM 1.4 JVM 1.3 AIX, Linux, Windows JVM 1.4 JVM 5.0 IBM i 65

66 Classic JVM IBM Technology for Java VM 比較 (1) 稼動条件 Classic JVM IBM Technology for Java VM (32 ビット版 ) サポート中の全 IBM i 但し今後サポート終了予定 I5/OS V5R4 以降 JDK リリース多数 ( ) Java (JDK1.5 以降 ) メモリー使用率 利点 64-Bit JVM は内部ポインターに 2 倍のサイズが必要 非同期 GC はヒープを大きくする傾向がある コンパクションが起こりにくい 理論上の最大ヒープサイズは 240GB 大きなヒープ サイズは複雑なアプリケーションで有利 ( ポータル, Workplace など ) ILE のネイティブ呼び出しは速い 32-Bit JVM はアドレス空間が小さい 最大値に達すると Stop-the-world GC が起こる ( デフォルト ) コンパクションが起こりやすい 32Bit では最大ヒープサイズは 4GB System が 25% 程度使用するため 実質的な最大ヒープ サイズは 3GB 程度 ILE のネイティブ呼び出しは遅い 66

67 Notes: Classic JVM IBM Technology for Java VM 32 ビット版比較 (1) 稼動条件 IBM i における IBM Technology for Java VM32 ビット版稼動の前提は IBM i 5.4 以降であることと JDK1.5 (Java 5) 以降であることです これらの前提を満たさない場合は デフォルトで Classic JVM が使用されます メモリー使用率 利点 Classic JVM はメモリーを多く使用する傾向にあります メモリー使用率が高くなる理由には以下があります : 64-bit JVM は 32-bit JVM に比べて 内部ポインターに 2 倍のサイズが必要です 非同期 GC はヒープを大きくする傾向があります Classic JVM の GC では コンパクションが起こりにくいアルゴリズムになっています これに対し IBM Technology for Java VM は以下の理由からメモリー使用率が低くなります 32-Bit JVM はアドレス空間が小さいです 最大値に達すると Stop-the-world GC が起こる ( デフォルト ) GC はコンパクションが (Classic に比べると ) 多く発生するアルゴリズムになっています IBM Technology for JVM では Classic JVM に比べて最大で 40% のメモリー使用率が削減できます ただし この値はアプリケーションによって変わります ( 参考 ) コンパクション : 使用中の領域をまとめてメモリのフラグメンテーションを低下させる機能をコンパクションと呼びます ガーベッジ コレクションがコンパクションの機能を含むかどうかは実装アルゴリズムに依存します Classic JVM は 64-bit JVM であるため 論理上のヒープ サイズは 240GB です 大きなヒープサイズの JVM は大規模で複雑なアプリケーションに適しています また PASE 上で実行される IBM Technology for Java VM よりも JNI などによる ILE の呼び出しは速くなります この点で 多くの ILE 呼び出しがあるアプリケーションの場合は Classic が有利です 67

68 Classic JVM IBM Technology for Java VM 比較 (2) パフォーマンス 考慮点 Classic JVM JDK のクラスは SUN JDK から移行されている より多くの能力が必要であるため L2/L3 キャッシュの効果は低い 他の IBM JVM とは異なるチューニング方法が必要 ヒープサイズ (WAS の mx など ) の設定不要 など 今後サポート終了 PASE ネイティブ プログラムの呼び出しは遅い IBM Technology for Java VM (32 ビット版 ) パフォーマンスの観点で重要な JDK クラスは IBM R&D によって最適化されている L2/L3 キャッシュによる効果が高い 他サーバー用 IBM JVM(J9) と同様な初期ヒープと最大ヒープによるチューニング方法 他サーバー上の IBM Technology for Java VM と同じチューニング手法で行う 分析ツールなども他サーバー用 IBM JVM と同じものを利用可能 IBM i 上の将来的な JVM IBM i 6.1 から 64-bit 版もサポート PASE ネイティブ プログラムの呼び出しは速い 例 Remote AWT 68

69 Notes: Classic JVM IBM Technology for Java VM 32 ビット版比較 (2) パフォーマンス 考慮点 ClassicJVM では SUN のクラスが移行されていますが IBM Technology for Java VM はパフォーマンスを向上させるために 多くのクラスが IBM によって最適化されています また 32-bit の IBM Technology for Java VM は L2/L3 キャッシュの効果的が高くなります テストでは 約 20% のパフォーマンス向上が報告されています Classic JVM は他の IBM JVM とは異なる特殊なチューニング方法があります これらは IBM Technology for Java VM では使用できなくなります Classic JVM は今後サポートを終了する予定です その後は IBM Technology for Java VM の 64-bit 版がサポートされる予定です IBM Technology for Java VM は PASE で稼動するため 他の PASE ネイティブ プログラムの呼び出しが比較的速いという特徴があります 例えば PASE 上で稼動する Native AWT ではパフォーマンス的に有利となります 69

70 WebSphere Application Server 6.1 のエディション IBM i でサポートされる WAS 6.1 のエディションは以下の 4 つです スケール アップ // メインフレーム コンピューティング WebSphere Application Server Community WebSphere Application Server - Express (5733-W61, Option 1) WebSphere Application Server (5733-W61, Option 2) WebSphere Application Server for Developers (5733-W61, Option 2) WebSphere Application Server Network Deployment (5733-W61, Option 3) WebSphere Application IBM i でサポートされるエディション Server for z/os WebSphere Application Server Express WebSphere Application Server WebSphere Application Server Developer WebSphere Application Server Network Deployment スケール アウト / 分散コンピューティング WebSphere Extended Deployment 70

71 i5/os V5R4, IBM i V6R1 以降の WAS での IBM J9 の有効化 1 i5/os,ibm i 6.1 上に導入した WAS はデフォルトでは Classic JVM が使用されます 以下の手順で enablejvm コマンドを実行する事で WAS も IBM Technology for Java VM (J9) を使用可能になります 事前準備 1. PASE が導入済みであること (PASE OSオプション 33) 2. 使用したいIBM Technology for Java VM (J9) のライセンスが導入済みであること 3. Java の最新グループ PTF がインストール済みであること グループ PTF 番号は下記の通り * グループPTF 適用後にPASE JVMオプションを導入した場合にはグループPTFを再度導入してください Java グループ ハイパー DB2 UDB for iseries WAS 6.1 WAS 6.0 TCP/IP HTTP IBM i 6.1 SF99652 SF99609 SF99601 SF99353 SF99352 なし SF99115 i5/os V5R4 SF99291 SF99539 SF99504 SF99323 SF99312 SF99315 SF99114 グループ PTF は用途に応じて必要なものだけを適用でも可 ですが 通常は上記全てを適用しておく事を推奨 (WAS は導入しているバージョンのみで可 ) 71

72 i5/os V5R4, IBM i V6R1 以降の WAS での IBM J9 の有効化 2 enablejvm コマンドの実行 WAS 導入ディレクトリに含まれる enablejvm スクリプトを実行して WAS のプロファイルを変更 WAS 6.1 Express の場合の enablejvm が含まれる IBM i 上の IFS ディレクトリ /QIBM/ProdData/WebSphere/AppServer/V61/Express/bin * エミュレーターから実行する場合ホストコードページ 939, ジョブ CCSID=5035(CHGJOB CCSID(5035)) に設定した端末から実行します step.1 QSHELL を起動 qsh step.2 QSHELL より以下のコマンドを実行 /QIBM/ProdData/WebSphere/AppServer/V61/Express/bin/enableJVM -jvm jvm_version profile profile_name jvm_version : std32 = J9 JVM 32 ビットをこの WAS プロファイルで使用, classic = Classic JVM 64 ビットを WAS プロファイルで使用 profile_name : WAS のプロファイル名 ( 通常は WAS インスタンス名と同じ ) * 変更を適用するには WAS の再起動が必要です * パスまたはディレクトリーがない 等のエラーが表示される場合はパスが通っていないので /QIBM/ProdData/WebSphere/AppServer/V61/Express/bin/enableJVM.. とパス名も含め実行します 72

73 Notes: enablejvm コマンドが正常実行された際のメッセージ WAS のジョブログ IBM JVM(J9) で稼動していることが 分かります enablejvm 完了時のメッセージ QSH コマンド入力 > /qibm/proddata/websphere/appserver/v61/express/bin/enablejvm -jvm std32 -prof ile GOMA61_55500 ADEJ0014I: Enabling profile GOMA61_55500 to use the specified JVM. ADEJ0002I: Success: The profile will now use the specified JVM. $ ===> F3= 終了 F6= 印刷 F9= コマンドの複写 F12= 切断 F13= 消去 F17= 先頭 F18= 最後 F21=CL コマンド入力 WAS のジョブログ (IBM JVM(J9) 使用時 ) WAS の起動時間 IBM JVM (J9) は非常に高速であることがわかります QSH コマンド入力すべてのメッセージの表示ニ ュホ. : GOMA61_555 マーナ ー. : QEJBSVR 番号... : 使用するJVM WAS 起動までの時間 classic JVM 3 分 IBM J9 32ビット 45 秒 * 環境 System i 515 1way, メモリ 1GB IBM i 6.1 >> CALL PGM(QWAS61A/QWASSTRSVR) PARM('-profilePath' '/QIBM/UserData/WebSphere /AppServer/V61/Express/profiles/GOMA61_55500' '-server' 'GOMA61_55500') /QEJBSVR/GOMA61_555 の ACGDTA がジャーナルできない 理由は 1 です Java Virtual Machine is IBM Technology for Java. PID(30279) Server starting with user profile QEJBSVR and JDK WebSphere application server GOMA61_55500 ready. 73

74 まとめ Classic JVM を IBM Technology for Java VM(J9) に変更するメリット i5/os V5R4 以降を使用している場合 従来の Classic JVM から IBM JVM(J9) に変更することで以下のメリットがあります 1. パフォーマンスの向上 同じシステム上で実行する場合でも IBM JVM J9 を使用することでパフォーマンスが向上します WAS も使用する JVM を IBM JVM J9 に変更する事でパフォーマンスが向上します 2. システム負荷の低減 CPU, メモリ ディスクアーム稼働率を低減させる効果があります 3. 他サーバー用 IBM JVM(J9) と同じチューニング手法に統一できる Windows, Linux, AIX など他サーバー用の IBM JVM J9 と同じチューニング手法を適用できます 4. JVM 分析用ツールを IBM JVM(J9) 用で他サーバー用と共通化できる デバッグやパフォーマンス分析などに私用する JVM 分析用,WAS 分析用のツールも IBM JVM J9 用のものを使用できます 74

75 統合 Web アプリケーションサーバー (LWI) 75

76 統合 Web アプリケーション サーバー Integrated Web Application Server (LWI) 統合 Web アプリケーション サーバーとは LWI : Light Weight Integration server と表記される事もあり IBM i (OS) 標準機能に含まれるアプリケーション サーバー i5/os V5R4で 前提 : i5/os V5R4, IBM i 6.1 以降はPTFで提供 WASなどのようにアプリケーション サーバーを別途導入する必要なし 軽量なアプリケーション サーバー WASよりもCPU, メモリ負荷が軽い 比較的大きなシステムや複数サーバーでアプリケーション サーバーを構築する場合にはWASの使用を推奨 OSGi フレームワークを基盤とした Web コンテナ.war.wab ファイルにパッケージされたアプリケーションをサポート.ear ファイルのサポートはなし Toolbox JDBC ドライバー ネイティブ JDBC ドライバーをサポート IBM Technology for Java 32bit JVM(J9) で稼動 ASF Tomcat の後継製品 以下の IBM i 新機能でもベース機能として利用されている Web Query Web サービスゲートウェイ使用時のアプリケーション サーバー ( 統合 Web サービス サーバー ) 76

77 IBM i で稼動するアプリケーション サーバーの位置づけ 主要な想定用途 製品パッケージング 統合 Web アプリケーション サーバー (LWI) 軽量なアプリケーション IBM i を中心としたアプリケーションの実行 IBM i5.4 以降で提供 WebSphere Application Server Express 他サーバー OS への展開も意識した比較的小規模なアプリケーション IBM i ライセンスプログラムとして購入 (Web Enablement for i5/os) WebSphere Application Server ND (Network Deployment) 冗長化 クラスター構成まで意識した比較的大きなアプリケーション IBM S/W 製品として購入 フィックス (PTF) 提供方法 IBM i の PTF WebSphere ifix WebSphere ifix クロス プラットフォームのサポート No Yes Yes JSF, JSP, & Servlets のサポート Yes Yes Yes J2EE 完全サポート No Yes Yes Java ベース Messaging Engine 機能 No Yes Yes JNDI ネームスペース接続 1 複数複数 DB2 for i5/os への接続 Yes Yes Yes 複数インスタンス Yes Yes Yes 拡張ワークロード管理, 高可用性, スケーラビリティー 77 備考 No No Yes WebSphere Application Server よりも軽量 他サーバー, OS 用の WAS と同じ実装 他サーバー, OS 用の WAS と同じ実装

78 統合 Web アプリケーションサーバー (LWI) の前提条件 i5/os V5R4 以降 (i5/os V5R4ではPTFで提供 IBM i 6.1 では標準 ) 57xx-SS1 オプション3 拡張ベース ディレクトリー サポート 57xx-DG1 IBM HTTP Server for i5/os 57xx-JV1 IBM Developer Kit for Java 57xx-SS1 オプション30 Qshell 57xx-SS1 オプション31 Portable Appl Solutions Environment 78

79 統合 Web アプリケーション サーバーのジョブ 統合 Webアプリケーション サーバーのジョブ QHTTPSVRサブシステム下で稼動 対になるHTTPサーバーと同じジョブ名でアプリケーション サーバー ジョブも稼動 WRKACTJOB コマンドの場合 機能欄でアプリケーションサーバーのジョブを識別可能 *WAS の場合 QWAS61 など WAS 専用のサブシステムが作成され WAS 専用サブシステム下で実行されます サーバー作成時に指定した ユーザー名にてジョブを実行 IBM Technology for Java で 実行されているので状況は THDW になります 現行 OPT サフ システム / シ ョフ ユーサ ー タイフ CPU % 機能 状況 QHTTPSVR QSYS SBS.0 DEQW GOMALWI557 QLWISVR BCI.0 JVM-com.ibm.lw THDW GOMALWI557 QTMHHTTP BCH.0 PGM-QZHBMAIN SIGW GOMALWI557 QTMHHTTP BCI.0 PGM-QZSRLOG SIGW GOMALWI557 QTMHHTTP BCI.0 PGM-QZSRHTTP SIGW サーバー作成時に指定した サーバー名と同じジョブ名 アプリケーション サーバーと同名の HTTP サーバー用のジョブが複数起動 79

80 まとめ 統合 Web アプリケーションサーバー (LWI) を利用するメリット i5/os V5R4 以降を使用している場合 アプリケーションサーバーとして LWI を使用することで以下のメリットを享受できます 1. パフォーマンスの向上 主に小規模アプリケーションにおいて WAS よりもパフォーマンスが向上します 2. システム負荷の低減 CPU, メモリ ディスクアーム稼働率を低減させる効果があります 3. Web サービス ゲートウェイを利用して既存 RPG,COBOL を簡単に Web サービス化できる 後述の Web サービス ゲートウェイは LWI が前提となっています LWI を利用すると簡単に既存 RPG, COBOL を Web サービス化することができます *LWI 使用時の注意事項 比較的大きいアプリケーション 複雑なアプリケーションで利用する場合は WAS の使用が推奨されます LWI は WAS とは異なる実装のため LWI 用にチューニングやデバッグを行う必要があります 80

81 SOA レディ 81

82 なぜ SOA 化が必要か? SOA は 2008 年現在 全ユーザーにあまねく普及している状況 とはいえません しかしながら 昨今 IBM 以外にも主要なベンダーが SOA 対応を謳うようになり今後数年間で大きく状況が変わってくるものと思われます SOA の最大のメリットは異なるプログラム言語 異なるシステム 異なるプロトコル 異なる企業間でも最低限度の情報 (WSDL など ) を事前に交換しておけば相互に通信可能となる点です 現在全銀手順 JCA 手順などの業界標準であれば企業間でバッチ伝送が可能です たとえて言えば SOA は全銀 JCA 通信を拡張し リアルタイム処理で企業間のデータ交換を可能とするもの という言い方も今後可能になってくると思われます 今後のシステム化にあたっては SOA レディ ESB の導入などを検討していくべきでしょう SOA 異機種 異言語 異プロトコル 異データタイプ / フォーマット でのリアルタイム連携 RPG IBM i SOA / Web サービス Java Linux 82 C++/C Windows COBOL メインフレーム

83 既存 RPG, COBOL の Web サービス化, SOA 化 RPG, COBOL のプログラムは変更せずに Web サービス用のインターフェースを追加する という方法で行います RPG, COBOL を PCML 呼び出しする Web サービス対応のモジュール (Java コンポーネント ) をウィザード (Web サービスゲートウェイなど ) で生成します 呼び出し元サービス FTP JDBC SAP Oracle EBS Webサービス MQ JMS SCA HTTP ESB エンタープライズ サービス バス 呼び出し元サービス Web サービス Web サービス用モジュール PCML 呼び出し用モジュール アプリケーション サーバー PCML Call PCML RPG Web サービス データベース IBM i 83

84 SOA(ESB) のメリット : 通信プロトコルの透過性 リクエスターとプロバイダーで使用する通信プロトコルが異なる場合に プロトコルの変換を行う リクエスターはプロバイダーがどのような通信プロトコルを使用しているのかを意識する必要がなくなり プロトコルの透過性を実現 プログラム サービスリクエスター MQ ESB Web サービス サービスプロバイダー プログラム リクエスターはプロバイダーが使用するプロトコルを意識しない FTP JDBC SAP Oracle EBS Webサービス MQ JMS SCA HTTP MQ から Web サービスへ変換 FTP JDBC SAP Oracle EBS Webサービス MQ JMS SCA HTTP 84

85 SOA(ESB) のメリット : インターフェース ( データタイプ ) の透過性 リクエスト メッセージを サービス プロバイダーが求めるフォーマットに合わせて ESB が変換 データのフォーマット XML, HTTP, CSV, MQ メッセージ 固定長 データの属性桁数やデータの型 リクエスターがプロバイダーのメッセージ フォーマットを意識しないため インターフェースの透過性を実現 Customer Name = Taro Suzuki Customer No = サービスリクエスター MQ メッセージ ESB XML サービスプロバイダー First Name = Taro Last Name = Suzuki Customer No = リクエスターはプロバイダーが使用するインターフェースを意識しない XML MQメッセージ JMSメッセージ CSV 固定長 DBレコード データの型変換マッピング計算などのロジック付与 XML MQメッセージ JMSメッセージ CSV 固定長 DBレコード SCA バイナリ SCA バイナリ HTML HTML 85

86 RPG, COBOL の Web サービス化 既存のRPG,COBOLプログラムをWebサービスでラッピングしてWebサービスから実行する事ができます RPG,COBOLを変更する必要はありません 既存のプログラミングスキル プログラミング資産を活かし Web サービス アプリケーションを開発できます RPG IPH110PCML Web サービスから RPG を呼び出し Web サービス用モジュール PCML 呼び出し用モジュール (Java) PCML Call パラメーター *ENTRY PLIST CUSTNO CUSTNAME ADR1 URIZAN アプリケーション サーバー アプリケーション サーバーはリモートサーバー上でも RPG が実行される IBM i (i5/os) 上でも可 得意先マスター TOKMSP RDi, WDSC の Web サービス ウィザードを使用して Web サービスから呼び出すための EAR ファイル WDSL ファイルなどをコーディングレス ( プログラム開発不要 ) で生成できます 既存の RPG COBOL を変更せずにそのまま利用可能 Web サービス対応化した後も従来どおり CLP, RPG, COBOL などから呼び出して実行可能 86

87 Web サービス ゲートウェイとは 呼び出し元サービス 統合 Web アプリケーションサーバー (LWI) を利用した既存プログラムの Web サービス化を実現する機能 ILE プログラムのコンパイルと LWI への ILE プログラムの登録だけで Web サービスから RPG, COBOL を呼び出し可能に 最も少ない作業 工数で RPG,COBOL を Web サービス対応に拡張できます Web サービスとのゲートウェイ サーバーに LWI を利用 WAS など他のアプリケーションサーバーは Web サービス ゲートウェイ用には利用できません FTP JDBC SAP Oracle EBS Webサービス MQ JMS SCA HTTP ESB エンタープライズ サービス バス 呼び出し元サービス Web サービス Web サービス用モジュール PCML 呼び出し用モジュール 統合 Web アプリケーションサーバー (LWI) PCML Call PCML RPG Web サービス データベース IBM i 87 Webサービスからの呼び出しに必要なモジュールはウィザー 2008 IBM ドで Corporation LWI 上に生成される ILE のコンパイルオプション PGMINFO パラメーターで PCML 生成を指定

88 5250 対話型アプリケーションの SOA 化 Web サービス化 HATS V7.1 の HATS アプリケーション WebFacing アプリケーションは Web サービス化が可能 Web サービス経由で HATS アプリケーションを実行 既存の 5250 対話型アプリケーションを Web サービスから呼び出し 他システム FTP JDBC ユーザー SAP Oracle EBS Webサービス MQ ESB Web サービス Web サービス用モジュール IBM Software Group HATS アプリケーション WebFacing アプリケーション JMS SCA HTTP プログラム RPG,COBOL,etc. 88

89 参考 RPG, COBOL からの Web サービス呼び出し RPG,COBOL から Web サービスを呼び出す事も可能です この場合 XML Toolkit (IBM i 無償オプションライセンス ) を使用します RPG, COBOL から Web サービスを呼び出すために C++/C プログラムを作成し C++/C プログラムから SOAP クライアント (Apache AXIS クライアント ) を操作して Web サービスと通信を行います Web Services Client for C++ に含まれる WSDL2Ws ツールにより WSDL ファイルから C++ スタブを生成 Client application (RPG, COBOL など ) は C++ スタブと Axis クライアントを経由してインターネット上のサーバーと Web サービス通信が可能となる その際 クライアントアプリケーション (RPG, COBOL) からは XML データのマッピング操作 SOAP メッセージの作成などの操作などは隠蔽される RPG, COBOL で作成 89

90 RPG, COBOL からの Web サービス呼び出し参考情報 System i で RPG または COBOL プログラムから Web サービスを使う Web サービス クライアント for C++ Apache Axis WSDL2Ws Tool 90

91 参考 - 開発ツールについて ADT 以外は全てEclipseベースで共通ですが開発目的に応じていくつかのパッケージに分かれています 複数の開発ツールを1 台のPCに導入する事も可能です 他システム FTP HATS アプリケーション WebFacing アプリケーション ユーザー JDBC SAP Oracle EBS Webサービス MQ ESB メディエーション Web サービス HATS, WebFacing 用 Web サービスモジュール IBM Software Group JMS SCA HTTP EGL プログラム RPG,COBOL,etc. 開発ツール WID ESB 用アプリケーション開発用 RDi SOA HATS, WebFacing, XML-Bridge, C/S Bridge, EGL RDi RPG, COBOL ADT SEU,PDM など 5250 端末開発環境 91

92 Part.4 Web 化時のパフォーマンスチューニングについて 92

93 Web アプリケーションを導入した際の考慮事項 一般的に従来の5250 環境とは異なる考慮事項が発生する ツール 手法にも依存 サイジング システム負荷 SQLのチューニング 分析 データベースインデックス作成 HTTPサーバー WAS, データベースサーバーの設定 運用の変更 セキュリティ 93

94 1. パフォーマンスの考え方 スループットと応答時間 スループット = 単位時間当りに処理可能なトランザクション数 ( 例 ) 一時間あたり処理可能なHTTPリクエストの最大数 応答時間 = 一トランザクションの実行時間 ( 例 )JSPのリクエスト送信から 結果の画面が返されるまでの時間 スループットが大きくなる方向でチューニングをすると 個々の応答時間が遅くなるようなケースも起こりえる ( 例 ) 同時処理可能な JDBC 接続数を増やす HTTP の最大接続可能数を増やす そのシステムの 指標 を設定しその値を満たすようなポイントを探す 応答時間 =XX 秒以内 スループット =HTTP XXX リクエスト以上 94

95 既存の 5250 アプリケーションを Web アプリケーションに移行した際 発生しやすいパフォーマンスの問題 ( 現象 ) レスポンスが非常に悪くなる 遅くなる等の現象 ( 問題判別の方法 ) 5250 アプリケーションと Web アプリケーションの相違について確認し 原因を特定する必要がある 1 サーバー側の処理負荷増 (CPU, メモリ, ディスク ) 2 ネイティブアクセスからSQLアクセスへの変更 3 HTTP, WAS, データベース それぞれのコネクション数などの基本設定 4 アプリケーションコードの問題 5 ネットワーク トラフィック量の劇的な増加 6 クライアント側の処理負担増 7 ユーザー数の増加 セッション数の増加など 95

96 1 サーバー側の処理負荷増 RPG, COBOL と比較して Java, PHP など Web アプリケーションはサーバー側の処理負荷が高い 画面周りは GUI で処理するためデータ量が多い 例 ) 画面は 5~20KB/1 画面程度 Web 画面では 100KB~ 数 MB/1 画面 演算処理に要する能力も RPG,COBOL よりも Web アプリケーションは大きくなることが多い 対策 ベストは事前にアプリケーションの雛形を作成してベンチマークを取得し 想定ハードウェアで十分かを検証する 過去に類似ケースの測定値がない場合 机上シュミレーションでのサイジングはたいへん難しい 事前のベンチマークが困難な場合は用意するハードウェアの能力を大きめに想定する 本番稼動後であればパフォーマンスデータを取得して状況を確認する IBM i の収集データ SQL を利用しているケースでは必要に応じて SQL パフォーマンスモニターも取得 WAS 上で稼動するアプリケーションのパフォーマンス収集ツールの利用 96

97 2 ネイティブアクセスから SQL アクセスへの変更 RPG, COBOLのネイティブアクセスと比較してSQLの処理負荷は非常に高い 基本的にSQL 処理はCOBOL, RPGのデータベース処理よりも負荷が高い 対策 バッチ系では積極的に RPG, COBOL によるデータベース処理をさせる RPG, COBOL のデータベース処理は Java, PHP などオープン系言語に比較して非常に高速 かつどのような処理でも処理速度がほぼ一定またはある程度予測可能 C/S Bridge, XML-Bridge のようなツールを利用してデータベース処理は RPG, COBOL で記述する という方法は非常に有効 97 SQL アクセスを使用する場合 必ずデータベースのインデックスチューニングを行う 実行する SQL 文と参照するデータベースのキーの分布の組み合わせによって使用されるアクセスパスは変わってくる ビジュアル エクスプレインによる処理時間の長い SQL 文の特定と分析 必要ならば SQL 文の修正 SQL アクセスされるライブラリー テーブル ( 物理ファイル ) ビュー ( 論理ファイル ) は CRTLIB コマンド CRTPF コマンド, CRTLF コマンドでなく以下の SQL 文で作成する (DB2/400 のオプティマイザーが最高の能力を発揮できるようにするため ) CREATE SCHEMA, CREATE TABLE, CREATE INDEX

98 3 HTTP, WAS, データベースのコネクション数などの基本設定 HTTP サーバー WAS, データベースの基本的な設定値を使用する環境に応じて変更しておく システムデフォルトで使用しない 必ず想定する最大同時ユーザー数などを元に設定を変更する 対策 HTTP サーバー : 最大接続数 WAS : ヒープサイズ MX, MS の設定 負荷テストを行うなどして検証する事が望ましい WAS, JVM は J9 JVM (32 ビット ) を使用する CPU, メモリ, ディスクの負荷減に有効 WAS : データベースのコネクションプール接続数 負荷テストを行うなどして検証することが望ましい データベース SQL 処理を行うサーバージョブ QZDASOINIT のジョブ数設定などを行う SQL エンジンについては基本的には最新の OS バージョン 最新の累積 グループ PTF ほど処理速度が速くなっている と考える 98

99 4 アプリケーションコードの問題 RPG, COBOL と比較して Java, PHP などオープン系の言語では基本的なコーディングのミスによりパフォーマンス劣化になっているケースがしばしば見受けられる 特にあまり Java の開発経験がない場合など 対策 事前に Rational コードチェッカーなどのツールを用いて推奨されないプログラムコードのチェックを行う 必要なものはコードを訂正する 事後ではアプリケーション実行時のボトルネック パフォーマンス分析を行うための専用のツールを用いてどのアプリケーションコードに問題があるかをデータ収集 分析する 99

100 5 ネットワーク トラフィック量の劇的な増加 RPG, COBOL と比較して Java, PHP など GUI 系のアプリケーションは 10 倍 ~ 数百倍のネットワークトラフィックを生成する 5250 画面 5~20KB 程度 / 1 画面 GUI 画面 100KB~ 数 MB / 1 画面 対策 事前にサンプルケースなどを作成してデータ収集を行い ネットワークが十分であるかを検証する リッチクライアント化してネットワークトラフィックを低減する ユーザーの利便性 操作性を犠牲にして 伝送データ量を低減する アプリケーションコードを修正して 1 実行ボタンで送受信されるレコード件数などデータ量を少量にする サーバー クライアント双方の処理負荷低減にも効果あり 100

101 6 クライアント側の処理負担増 5250 の場合 クライアント側はエミュレーターの負荷のみ ブラウザー上で JSP を表示させる場合 クライアントの CPU 上で JSP の組み立てを行うため クライアント側の負荷は高い 対策 JSP などの表現を簡素にして クライアント側の処理負荷を低減させる あまりに旧式な PC の場合 処理能力的に問題がある可能性を検証する 必要ならそれなりの新しい PC への置き換えを検討する リッチクライアントとブラウザーを比較して処理速度の速いほうを採用する 1 回の実行ボタンで送受信されるレコード件数 ( データ量 ) を少量にして処理負荷を低減する 101

102 7 ユーザー数の増加 セッション数の増加 想定していたユーザー数 セッション数と実際の使用ユーザー数 セッション数は合致しているかを確認 対策 当初, 予定していたユーザー数等と乖離がないかを確認 また処理するデータベースのレコード数の劇的な増加なども SQL 処理負荷などの増加につながる このためデータベースのレコード件数なども定期的に確認を行う 102

103 パフォーマンスチューニング QZDASOINIT サーバーサイドのチューニング : QZDASOINIT のジョブ数 i5/os(os/400) 側で ODBC アクセスを処理するプログラム ( サーバージョブ ) 名は QZDASOINIT です ( サブシステム QUSRWRK または QSYSWRK 下で実行されます ) QZDASOINITだけでなくサーバージョブの開始時には様々な処理が発生するためシステム負荷が高くなり 結果パフォーマンスに影響を及ぼす事があります QZDASOINITはシステムIPL 時 ( サブシステム開始時 ) に指定されたジョブ数を事前に起動しておき 実際のユーザーからのアクセス時のパフォーマンスが低下しないようにしています IPL 時に起動されるQZDASOINITのジョブ数をピーク時のODBCクライアント数 (= 通常はユーザー数に近くなると思われます ) と同数程度に設定することが推奨されます これによりユーザーがODBCアクセスした際にQZDASOINIT ジョブが起動されることにより発生するパフォーマンス低下を防ぐ事ができます 103

104 パフォーマンスチューニングその 2 QZDASOINIT QZDASOINIT ジョブ i5/os V5R4 では QUSRWRK サブシステム下で実行されます QZDASOINITの数を無用に大きくするとディスクへの同期 I/O 処理が多くなり 結果かえってパフォーマンスを劣化させてしまいます 最大のODBCアクセス数と同数以下に調整するのが多くの場合適切です 104

105 パフォーマンスチューニングその 2 QZDASOINIT 1. ODBC アクセス数の調査 - 実際に使用されている ODBC アクセス数を調査します - これは QZDASOINIT のジョブ数で測定します - DSPACTPJ コマンドを使用してピーク時の QZDASOINIT ジョブの数を調査します - DSPACTPJ コマンドをプログラム名 QZDASOINIT で実行します 105

106 パフォーマンスチューニングその 2 QZDASOINIT 2. DSPACTPJ コマンドでの QZDASOINIT ジョブのピーク数の調査 - 事前開始ジョブ の 1 現在数が IPL 時に自動開始されるジョブ数です 右図では 8 です - 事前開始ジョブ の 2 ピーク時の数が IPL 以降での QZDASOINI ジョブの同時実行数の最大です 右図では 9 です - 使用中の事前開始ジョブ数 の 3 現在数が今現在実行されている QZDASOINT のジョブ数です 右図では 6 です - 使用中の事前開始ジョブ数 の 4 ピーク時の数が 5 経過時間内における QZDASOINIT ジョブの同時実行最大数です 右図では 8 です 通常は 2 のピーク時の QZDASOINIT ジョブ数 =ODBC アクセスの同時最大数と考えられますので 2 の値と同数だけ QZDASOINIT のジョブを IPL 時に開始しておくとパフォーマンス上効率的と考える事ができます * 注 1 の値が一時的 例外的な最大数となっていることもありえます そのような場合には平均数や 4 の値など参考にして適切な数に設定した方がいい場合もあります QZDASOINIT ジョブ数を必要以上に多くするとディスクへの同期 I/O 処理が増えかえってパフォーマンス劣化の容易になりかねませんのでご注意ください 106

107 パフォーマンスチューニングその 2 QZDASOINIT 2. 現在の QZDASOINIT ジョブの設定確認 - DSPSBSD SBSD(QUSRWRK) コマンドを実行し 10. 事前開始ジョブ項目を選択します - お使いの OS/400 バージョンによっては QZDASOINIT ジョブが QSYSWRK サブシステム下で実行されている場合もありますので その場合は DSPSBSD SBSD(QSYSWRK) と実行します - QZDASOINIT の欄に 5 ( 明細の表示 ) を入力します ( 右上図 ) - 右下の図の 1 初期ジョブ数を確認します 右図では 1 です - この 1 初期ジョブ数を前ページで調査した QZDASOINT の最大数に変更することで IPL 後 ( サブシステム開始後 ) に必要な QZDASOINIT ジョブ数が起動されることになり ユーザーからの ODBC 接続の都度ジョブが起動されることによるパフォーマンスの劣化を防ぐ事ができます 1 107

108 パフォーマンスチューニングその 2 QZDASOINIT 3. QZDASOINIT ジョブの起動数の変更 - CHGPJE コマンドを使用して QZDASOINT ジョブの初期ジョブ数を変更します - CHGPJE SBSD(QUSRWRK) PGM(QZDASOINIT) INLJOBS(xx) -xx には IPL 時に起動させたい QZDASOINIT のジョブ数を指定します 右図では 9 を指定しています - 上記は i5/os V5R4 の場合です お使いのバージョンによっては SBSD(QSYSWRK) で QZDASOINIT を実行している場合もありますので現在の設定を確認してから実行してください 108

109 パフォーマンスチューニングその 2 QZDASOINIT 4. QZDASOINIT ジョブが変更されたかを確認 -2. の手順を再度実行して QZDASOINIT の初期ジョブ数が変更されたかを確認します - 右の例では初期ジョブ数が 9 に変更されています - 設定の変更は次回 IPL 時 ( 正確にはサブシステム再起動時 ) に反映されます 109

110 SQL 処理時間の分析手順 手順 1. パフォーマンス情報の収集 -SQL パフォーマンスモニターで情報を収集 - パフォーマンス上問題のある SQL 文を特定 手順 2. パフォーマンス上問題のある SQL 文を詳細に分析 - Visual Explain で SQL の内部処理を分析 110

111 DB2/400 での SQL 問題判別とチューニング データベースモニター (SQL パフォーマンス モニター ) で SQL の問題判別を容易に行う事ができます パフォーマンスモニターでは以下の 2 タイプを指定できます 詳細データベース モニター 短時間のデータ収集向き ディスクに収集 システム名 ジョブ名 ユーザー名 SQL ステートメント テキスト ステートメントの開始と終了のタイムスタンプ 処理時間の見積もり値 照会されたテーブルに含まれる合計行数 選択された行数 合計の最適化時間と実行時間 要約データベース モニター 長時間のデータ収集向き メモリー上に収集 個々の SQL ステートメントの詳細データは収集されない 全体の傾向把握 111

112 DB2/400 での SQL 問題判別とチューニング ( 続き ) Visual Explain を使用すると SQL パフォーマンスモニターで収集したデータや SQL インターフェースから実行した SQL の詳細な内部動作を確認する事ができます またパフォーマンス改善のためのシステム推奨インデックスの確認 作成が可能です SQL ステートメントの動きを確認 アクセス プランの確認 推奨される索引の確認 作成 他のデータベース製品の場合でも推奨インデックス提示など類似機能をもつ DB 製品がありますが, その正確性は必ずしも実用レベルではない場合が多いようです 他の DB 製品では DBMS がデータベースの統計情報や SQL の実行状況を正確 ( 精密 ) に把握できていない事がその要因のひとつです DB2/400 ではデータベースの統計情報 ( テーブルのレコード件数, キー値の統計, インデックス情報等 ) を i5/os 組み込みの DB2/400 が自動で収集 更新しています これと前ページの SQL パフォーマンスモニターを組み合わせることにより正確 精密な SQL チューニング, パフォーマンスチューニングを可能にしています 112

113 データベース モニターの開始方法 5250 端末 STRDBMON コマンド iseries ナビゲーター 1. データベース ( データベース名 ) SQL パフォーマンスモニター 2. 右下ウィンドウのデータベースタスクから新規要約 SQL パフォーマンスモニターまたは新規詳細 SQL パフォーマンスモニターを選択 3. すべてのジョブを対象にする ( または特定ジョブを指定 ) 4. 要約 SQL パフォーマンスモニターの場合は, 収集するデータタイプを指定 5. SQL, SQL を使用したジョブを実行することでパフォーマンスデータを取得 113

114 Visual Explain の開始方法 データベース モニターから連携して使う 1. データベース ( データベース名 ) SQLパフォーマンスモニター 2. 該当のデータベースモニターを右クリックしてステートメントを表示 3. 左下の検索ボタンを押すと実行された該当のSQL 文を表示 4. 分析したいSQLステートメントをクリックしてVisual Explainの実行ボタンを押す 114

115 Visual Explain( ビジュアル エクスプレイン ) SQL パフォーマンス モニターのデータ, または SQL を iseries ナビゲーターの SQL 実行画面から対話型で実行した際の SQL の実行プロセスを細分化して表示 内部動作の理解 確認 トータル処理時間 (CPU 時間 ), ステップごとの概算 CPU 時間 処理レコード件数等の情報を確認 テーブルへのアクセス方法の確認 チューニングポイントの判断 システム推奨値の確認 ステップ毎処理時間 合計処理時間などを表示 SQL の内部処理手順をステップ毎にアイコン表示 115

116 システム推奨インデックスの確認, 作成 索引アドバイザー Visual Explainから行う場合 統計および索引アドバイザーボタンをクリックします 索引名に確認したいテーブル ( 物理ファイル ) 名を入力して OK ボタンを押す 推奨インデックスが提示されている場合には, 指定されたインデックを作成 116

117 索引アドバイザーデータベースアイコンより実行時 インデックスの作成がアドバイスされているテーブルをまとめて表示可能 統計情報に基づき インデックスを作成することでデータベースのパフォーマンスが向上する可能性の高いテーブル インデックスを表示 表示画面から直接インデックスを作成可能 117

118 インデックス作成後の動作確認 再度パフォーマンスモニターを取得するか SQL を実行して Visual Explain を行う インデックス作成前と比較して処理時間 内部処理動作等を比較してインデックス作成の効果を検証します 合計時間が 3 ページ前と比較して短縮されています 3 ページ前と同じ SQL を実行していますが内部処理手順が変わって ( 簡素化されて ) います 118

119 ( 参考 ) オンデマンド パフォーマンス センター IBM i 6.1~ 実行中の SQL 処理をリアルタイムにビジュアル エクスプレイン分析が可能 119