interstage certified professional アプリケーション...

Interstage Certified Professional アプリケーションサーバ

V9

2007 年 7 月初版



Interstage Certified Professionalアプリケーションサーバ

V9

2007年7月初版

富士通株式会社

i


はじめに

本書は、富士通ミドルウェアマスター「 Interstage Certified Professional

アプリケーションサーバ V9」試験対策のために作成されたテキストです。

● Microsoft、Windows は、米国 Microsoft Corporation の米国およびそのほ

かの国における登録商標です。

● Linux は、Linus Torvalds の米国およびそのほかの国における登録商標ま

たは商標です。

● Oracle は、米国 Oracle Corporation の登録商標です。

● CORBA、 Object Management Group、 OMG、 OMG IDL、 IIOP、 Object Request

Broker、および ORB は、 Object Management Group の米国およびそのほかの

国における商標または登録商標です。

● Interstage は、富士通株式会社の登録商標です。

● Java およびその他の Java を含む商標は、米国 Sun Microsystems, Inc.の

米国およびそのほかの国における商標です。

● UNIX は、米国およびそのほかの国におけるオープン・グループの登録商標

です。

● Sun、 Sun Microsystems、 Solaris およびすべての Solaris に関連する商

標は、米国およびそのほかの国における米国 Sun Microsystems, Inc. の

商標または登録商標であり、同社のライセンスを受けて使用しています。

● 本資料では、Solaris ™ Operating System を Solaris と表記しています。

● 本資料に記載されているシステム名、製品名などには必ずしも商標表示

(TM、 R) を付記しておりません。

● そのほか記載された会社名および製品名などは該当する各社の商標また

は登録商標です。

2007 年 7 月初版

i


＜目次＞

第 1 章 Interstage の概要 ·······················································································································1

1.1 Interstage の製品体系 ························································································································2

1.2 Foundation の製品体系 ······················································································································3

1.3 Interstage Application Server の概要 ·································································································5

1.4 Interstage Business Application Server の概要 ·················································································6

1.5 Interstage Job Workload Server の概要·····························································································7

1.6 Interstage SIPnet の概要 ···················································································································8

1.7 Interstage Security Director の概要····································································································10

1.8 Interstage Traffic Director の概要·······································································································11

第 2 章 Interstage Application Server の関連技術とサービス ·························································13

2.1 Interstage Application Server が提供する標準技術 ············································································14

2.2 Interstage Application Server の機能 ·································································································15

2.3 Web サーバ ········································································································································ 20

2.3.1 Interstage HTTP Server のログ ··································································································· 22

2.4 Servlet················································································································································ 24

2.5 JSP ···················································································································································· 25

2.6 Servlet サービス ································································································································· 26

2.6.1 Servlet サービスのコンポーネント ································································································· 27

2.6.2 Servlet サービスの機能 ················································································································ 28

2.6.3 Web サーバコネクタによる負荷分散 ····························································································· 30

2.7 EJB ···················································································································································· 31

2.7.1 Session Bean の特長と種類 ········································································································ 32

2.7.2 Entity Bean の特長と種類 ············································································································ 33

2.7.3 Message-driven Bean の特長 ····································································································· 35

2.8 EJB サービス ······································································································································ 36

2.8.1 処理性能を向上させる機能 ··········································································································· 37

2.8.2 トランザクション制御······················································································································ 38

2.8.3 時間監視機能······························································································································· 39

2.9 CORBA ·············································································································································· 41

2.10 CORBA サービス······························································································································ 43

2.10.1 CORBA アプリケーション運用時のタイマ監視 ············································································· 44

2.11 Web サービス···································································································································· 45

2.11.1 WSDL ········································································································································ 46

2.11.2 Web サービスの標準規約 ··········································································································· 47

2.12 Interstage Web サービス ·················································································································· 48

2.12.1 Web サービスのコンポーネント ··································································································· 49

ii


2.12.2 Web サービスの運用方法··········································································································· 51

2.13 JMS·················································································································································· 52

2.14 Interstage JMS································································································································· 54

2.14.1 イベントサービス ························································································································· 55

2.14.1.1 ノーティフィケーションサービス ······························································································ 57

2.14.1.2 メッセージ保証機能 ·············································································································· 58

2.14.1.3 通信モデル ·························································································································· 59

2.14.1.4 メッセージングモデル ············································································································ 61

2.14.2 Interstage JMS のメッセージングモデル ····················································································· 63

2.14.3 メッセージセレクタ機能 ················································································································ 64

2.15 JNDI ················································································································································· 65

2.16 JNDI サービスプロバイダ(JNDI SP) ·································································································· 66

2.17 ワークユニット···································································································································· 67

2.17.1 ワークユニットの機能 ·················································································································· 69

2.17.2 IJServer ····································································································································· 74

2.18 FJVM················································································································································ 76

2.18.1 Java VM 起動オプション ············································································································ 77

2.19 JDK ツール(解析用ツール)················································································································ 78

2.20 バックアップ・リストア ························································································································· 84

2.21 一括情報採取ツール ························································································································· 86

第 3 章 Interstage Application Server の高度な機能········································································ 89

3.1 業務処理能力を保証する異常監視・再起動 ························································································· 90

3.2 システムの連続運用を保証する活性保守 ···························································································· 92

3.3 セキュリティの強化 ······························································································································ 93

3.4 マルチサーバ管理 ······························································································································· 94

3.4.1 IJServer の多階層システム設計(リレーション)··············································································· 96

3.4.2 プロビジョニング···························································································································· 98

3.5 シングルサインオン ····························································································································· 99

3.6 Systemwalker Centric Manager 連携による稼働監視/性能監視 ························································· 101

3.7 Systemwalker Operation Manager 連携による自動運転 ···································································· 102

3.8 Systemwalker Service Quality Coordinator 連携による性能分析/レスポンス監視 ······························ 103

第 4 章 Interstage Business Application Server ············································································· 105

4.1 Interstage Business Application Server の機能 ················································································· 106

4.1.1 ミッションクリティカル向け制御ロジック··························································································· 107

4.1.2 アプリケーション連携実行基盤 ······································································································ 108

4.1.3 メッセージ保証機能······················································································································· 112

4.1.4 ルーティング制御 ·························································································································· 113

4.1.5 高信頼性ログ(ジャーナルログ)······································································································ 115

iii


第 5 章 Interstage Job Workload Server ··························································································· 117

5.1 Interstage Job Workload Server の機能····························································································· 118

5.1.1 ファイル資源の一括排他機能········································································································ 120

5.1.2 ファイルの世代管理 ······················································································································ 121

5.1.3 ジョブ異常時のリカバリ機能 ·········································································································· 122

5.1.4 ジョブの開発支援機能 ·················································································································· 123

第 6 章 Interstage Studio でのアプリケーション開発 ··········································································· 125

6.1 Interstage Studio とは························································································································· 126

6.2 アプリケーション開発手順 ···················································································································· 127

6.3 ワークベンチの画面····························································································································· 129

6.4 アプリケーションの配備························································································································ 131

6.5 J2EE アプリケーションファイル············································································································· 132

6.6 IJServer ビュー ··································································································································· 133

第 7 章 Interstage Security Director ··································································································· 135

7.1 Interstage Security Director の機能···································································································· 136

7.2 ファイアウォール機能··························································································································· 137

7.2.1 IP パケットフィルタリング機能 ········································································································ 138

7.2.2 暗号通信機能······························································································································· 139

7.2.3 ユーザ認証機能 ··························································································································· 140

7.3 HTTP アプリケーションゲートウェイ機能 ······························································································ 142

7.3.1 アクセス制御 ································································································································ 143

7.3.2 ユーザ認証··································································································································· 145

7.3.2.1 InfoProxy 認証······················································································································· 146

7.3.2.2 ディレクトリサーバ連携機能 ···································································································· 147

7.3.2.3 SSL ユーザ認証機能 ············································································································· 148

7.3.2.4 Interstage シングルサインオン連携機能 ················································································· 149

7.3.3 リバース機能 ································································································································ 151

7.3.4 仮想ホスト機能 ····························································································································· 152

7.4 IIOP アプリケーションゲートウェイ機能································································································· 153

第 8 章 Interstage Traffic Director ······································································································· 155

8.1 Interstage Traffic Director の機能······································································································· 156

8.2 Standard Edition と Enterprise Edition について ················································································· 157

8.3 負荷分散機能 ····································································································································· 159

8.3.1 サイト負荷分散 ····························································································································· 160

8.3.1.1 転送方式································································································································ 161

8.3.1.2 サーバ分散方式 ····················································································································· 162

iv


8.3.1.3 HTTP ヘッダ負荷分散············································································································ 164

8.3.1.4 セッション維持(一意性の保証) ································································································ 165

8.3.1.5 故障監視································································································································ 167

8.3.1.6 IIOP 負荷分散 ······················································································································· 169

8.3.1.7 IJServer と Web サーバを分離して運用するシステムの負荷分散 ··········································· 170

8.3.2 透過デバイス負荷分散 ················································································································· 172

8.4 QoS(帯域)制御 ··································································································································· 173

8.4.1 帯域幅制御 ·································································································································· 174

8.4.2 その他の帯域制御························································································································ 176

8.5 キャッシュ機能····································································································································· 178

8.6 Interstage Application Server との連携 ······························································································ 180

付録

付録 1 用語集 ··········································································································································· 180

付録 2 模擬問題········································································································································ 189

付録 2-1 解答用紙 ·································································································································· 205

付録 2-2 カテゴリ別出題範囲················································································································· 206

付録 2-3 正解表 ···································································································································· 206

付録 2-4 模擬問題解説 ························································································································· 207

Copyright 2007 FUJITSU LIMITED 1


第１章Interstageの概要

本章ではInterstageの全体概要、およびInterstage Certified Professional Application Server試験にかかわるFoundation製品について説明します。


Copyright 2007 FUJITSU LIMITED2

Interstageは、柔軟性と信頼性を兼ね備えたシステムの構築を支援

1.1 Interstageの製品体系1.1 Interstageの製品体系

サーバストレージネットワーク

Interstage

Foundation

IntegrationDevelopment

Suite

業務アプリケーション ISVアプリケーション

「Foundation」「Integration」「Development Suite」のカテゴリからなる製品群から構成されます。

Interstageは、標準テクノロジーと数多くの基幹システム構築の実績から培われた高い信頼性と優れた高性能化技術を融合し、安定した業務継続、業務の適化、セキュリティ強化を実現し、中規模から大規模システムまで広範囲なシステム構築を支援します。

Interstageは、複雑化するシステムや多様化するニーズに応えるため多くの製品がラインナップされています。これらの製品はそれぞれの役割に応じて、以下の「Foundation」、「Integration」、「Development Suite」のカテゴリに分類されます。

■Foundation安定した業務サービスを支援するアプリケーション・プラットフォーム

■IntegrationSOAに対応したシステム構築を支援し、ビジネス環境の変化に即応する柔軟な業務システムを実現

■Development Suiteオープンな統合開発環境と充実したコンポーネント、ツール群でWebシステムの容易で迅速な開発を支援



1.2 Foundationの製品体系1.2 Foundationの製品体系

新の標準技術に対応し、ビジネスにあわせ高信頼性・高性能なシステムを、迅速に構築するためのアプリケーション・プラットフォームです。

Interstage Application Server豊富なアプリケーション形態と、短時間でセットアップできる高信頼・高性能の実行環境を提供する、アプリケーションサーバです。

Interstage Business Application Server安全かつ短期にオープンミッションクリティカル・システムを構築・運用するための基盤ソフトウェアです。

Interstage Traffic Director安定したレスポンスとサービス品質(QoS)を保証し、ノンストップ稼動を実現する負荷分散ソフトウェアです。

Interstage Security Director強固なセキュリティ管理を実現するセキュリティ基盤ソフトウェアです。

Foundation

Interstage Job Workload Serverオープンシステム上で基幹バッチ処理の安定稼動を実現する基盤ソフトウェアです。

Interstage SIPnetサービスの多様化に対応したWebと音声の連携を可能とするソフトウェアです。

Interstage Web ServerWebサーバ機能と、Servlet、JSPなどの標準Java技術をサポートし、負荷分散、ホットスタンバイ、マルチサーバ管理機能を使用しないシングルサーバ環境Webサーバシステム構築ソフトウェアです。

Interstage製品体系のカテゴリであるFoundationは、新の標準技術に対応し、ビジネスにあわせ高信頼・高性能なシステムを迅速に構築するためのアプリケーション・プラットフォームです。

「Foundation」は、以下の製品で構成されています。

■Interstage Application Server豊富なアプリケーション形態と、短時間でセットアップできる高信頼・高性能のアプリケーション実行環境を提供する、アプリケーションサーバです。

■Interstage Business Application Serverオープンプラットフォームを活用した基幹系システム構築に必要な共通技術、基幹システムのアプリケーション構造の共通化と連携技術、および業務運用を支援する機能を提供することで、生産性および堅牢性の高い、柔軟性および拡張性に富むシステム構築と運用を支援するソフトウェア製品です。

■Interstage Job Workload Serverオープンシステム上で基幹バッチ処理の安定稼動と運用性向上を実現する基盤ソフトウェアです。

■Interstage Security Director強固なセキュリティ管理を実現するセキュリティ基盤ソフトウェアです。

■Interstage Traffic Director安定したレスポンスとサービス品質（QoS）を保証し、ノンストップ稼動を実現する負荷分散ソフトウェア

です。


■Interstage SIPnet国際標準プロトコルであるSIP、SIMPLEプロトコル、およびVoiceXMLなどのオープン技術の採用でサービスの多様化に対応したWebと音声の連携を可能とします。

Interstage SIPnetは、下記の3製品を提供しています。

・Interstage SIPnet Application Container・Interstage SIPnet VoiceXML Server・Interstage SIPnet Client

■Interstage Web ServerWebサーバ機能と、Servlet、JSPなどの標準Java技術をサポートし、負荷分散、ホットスタンバイ、マルチサーバ管理機能を使用しないシングルサーバ環境Webサーバシステム構築ソフトウェアです。

Interstage Web Serverは、Interstage Application Server Web-J Edition (V8)の後継製品になります。



業務システムの構築・運用を支えるアプリケーションプラットフォーム

1.3 Interstage Application Serverの概要1.3 Interstage Application Serverの概要

Interstage Application Server Enterprise Edition

Interstage Application Server Standard-J Edition

Interstage Web Server

●高信頼性機能ホットスタンバイ負荷分散セションリカバリ

●マルチサーバ管理●C/C++ /COBOL●CORBAサービス

●メインフレーム連携

●Java/J2EE●Webサービス

●シングルサインオン ●Webサーバ (HTTPサーバ)●Java(Servlet/JSP)実行環境●ワークユニット●活性変更

Webブラウザ

携帯端末

フロント業務

レガシーシステム

ERP

既存資産

既存システム

Interstage Application Server

管理コンソール

アプリケーション管理

メインフレーム

ERP

バックエンド業務

CRM

データベース

アプリケーション・コンテナ

EJB Servlet

COBOL / C

Web

サービス

Web

サーバ

サービスバス※

※： Webサービスなどの標準仕様に準拠してサービスを連携させる機能/製品(Interstage Service Integratorなど)

Interstage Application Serverは、SOA時代の安定した業務サービスを支えるアプリケーションプラットフォームです。J2EE、Webサービス、CORBAを始めとする標準技術に、富士通が長年にわたって培って

きた基幹システム構築のための高信頼・高性能技術を集積し、業務システムの安定稼動を実現します。ワークユニット、Interstage管理コンソール、シングルサインオンなどにより運用性の向上も実現しています。また、Javaに加え、C/C++/COBOLで開発したアプリケーションを利用することもできます。

Interstage Application Serverは、Standard-J Edition、 Enterprise Editionの2つの製品をそろえており、Webアプリケーションを利用した小規模なシステムから、ノンストップ運用や多数のクライアントを同時にサービスするような高信頼・高性能が要求される基幹業務や大規模EC(Electronic Commerce)の企業

システムまで、幅広く適用できます。

■Interstage Application Server Standard-J EditionJavaに対応したシングルサーバ環境(負荷分散、ホットスタンバイ、マルチサーバ管理機能を使用しない環境)向けのスタンダードモデルです。J2EE1.3に準拠し、Webサービス標準技術やWebサーバ機

能、シングルサインオン機能をサポートしています。

■Interstage Application Server Enterprise Editionマルチ言語に対応し、高信頼・高可用を実現するマルチサーバ環境(負荷分散、ホットスタンバイ、マルチサーバ管理機能のいずれかを使用する環境)向けのエンタープライズモデルです。

Standard-J Editionの機能に加え、マルチ言語対応(C/C++/COBOL)、負荷分散、ホットスタンバイ、マルチサーバ管理機能などをサポートしています。安定したレスポンスと24時間、365日の無停止シス

テムを実現する大規模システム構築に適です。

上記の製品以外に、Interstage Application Server と組み合わせて、Webフロントシステム構築に使用するためのInterstage Web Server を提供しています。

Interstage Application Server では、Interstage Application Server をインストールしたシステムの前段に、Webサーバによるシステムを構築するための機能(Web Package機能)を提供しています。

Interstage Application Server を購入することで、Interstage Application Serverで構築したバックエンドシステムとWeb Package機能で構築したWebフロントシステムを連携したシステムの構築が可能です。

また、Interstage Application Server Enterprise Edition で提供しているWeb Package機能では、故障

監視が可能です。



エラーキュー

通信制御機能

ログ制御機能

アプリケーション制御とコンポーネント化により拡張性の高いシステムを構築

1.4 Interstage Business Application Serverの概要1.4 Interstage Business Application Serverの概要

Webサーバ

端末制御アプリケーション

受付

結果確認

業務ロジック(COBOL）

業務ロジック(Java）

バックエンドアプリケーション実行環境

インターネット

入力キュー

処理結果キュー

業務DB

ジャーナルログ

データベース更新・参照

ジャーナルログ出力

Webアプリケーション実行環境データベース／トランザクション制御機能

Webアプリケーション実行環境データベース／トランザクション制御機能

データベース／トランザクション制御機能

業務ロジック(C）

メッセージ

メッセージ

メッセージ

メッセージ

メッセージ

正常なら

異常なら

突き放し処理

会話処理

Interstage Business Application Server

会話処理：応答を待ち合わ

せる形態突き放し処理：応答を待たずに、

処理結果を問い合わせる

Interstage Business Application Serverは、基幹系オンラインシステムの構築に必要な制御機能とアプ

リケーションのコンポーネント化により、拡張性の高いオンラインシステムの構築を支援する基盤ソフトウェアです。

業務ロジックだけでなく、バックエンドアプリケーションの制御、通信制御、データベース制御、トランザクション制御、ログ制御などの基幹業務に不可欠な高度な制御機能により、高信頼なシステムの短期構築が可能です。

■通信制御機能Webアプリケーションとバックエンドアプリケーションの通信形態には、会話処理と突き放し処理の2種類

があります。会話処理向けのメッセージ送受信処理と、突き放し処理向けのメッセージキューからの要求取り出しとメッセージキューへの処理結果の格納により、通信形態に依存しないアプリケーションの開発が可能です。

■トランザクション制御機能アプリケーションの処理結果にしたがってデータベースに対するコミットやロールバックを自動的に実施します。

また、突き放し処理の場合は、入力メッセージと出力メッセージに対して自動的にコミットやロールバックが可能です。これによりアプリケーションの処理結果とデータの整合性が保証されます。

■データベース制御機能バックエンドアプリケーションでデータベースにアクセスする場合、データベースへの事前コネクション機能やコネクションプーリング機能により、データベースへのアクセスを高速化できます。

また、コネクション再接続機能により、システムの連続運転が可能になります。

■ログ制御機能データベースと同等の堅牢な書き込みと順序性を保証します。また、エンドレスなログ採取により、運用性の向上とシステムの連続運転を保証します。

オンラインで処理した業務データはログ取得(ジャーナルログ)することで、業務処理の履歴管理や後続の

バッチ処理への引き継ぎデータとして活用できます。



一括排他

プロセスの常駐化と資源競合を解消し、バッチシステムの計画運用と安定稼動を実現

1.5 Interstage Job Workload Serverの概要1.5 Interstage Job Workload Serverの概要

計画実行

バッチ処理の投入

結果確認

プログラム1

ジョブログ

バッチ起動要求

Interstage Job Workload Server

プログラム2

プログラム3

プログラム4

ジョブ管理

ジョブキュー

ログ機能

ファイル管理

ジョブスケジューラ

Ａ

Ｂ

Ｃ

バッチジョブ定義

Interstage Job Workload Serverは、バッチ処理の高速化と多重実行時の資源競合を解消し、バッチシ

ステムの計画運用と安定稼動を支援するソフトウェアです。

日次や月次処理のようにあらかじめ計画された時間に実行するバッチ処理と、随時実行するバッチ処理の2形態におけるバッチシステムの計画運用と安定稼動を実現します。

■バッチシステムの負荷の平準化あらかじめ定義された数以上のバッチ処理の起動が要求された場合、ジョブキューにキューイングすることにより、システムにかかる負荷を平準化します。また、キューから取り出し時は優先度制御により、緊急度の高いバッチ処理を優先して実行できます。

■世代ファイルと連結ファイルによる処理手順の短縮ファイルに世代番号を付与して管理する世代ファイル機能により、ファイル破壊に備えたバックアップを不要とし、処理手順を短縮できます。

また、連結ファイル機能は、世代ファイルを含めて複数のファイルをひとつのファイルとして取り扱い、時間ごとに集計したファイル群をマージ処理することなく日次で集計するなど、処理手順の短縮が可能です。

■バッチ処理の高速実行バッチ処理を実行するプロセスの常駐化によるプロセス開始･終了のオーバヘッドの解消とプロセスの多重化により、バッチ処理の高速実行を実現します。

従来のシェルスクリプトによるバッチ処理でのアプリケーション/コマンドの開始・終了を繰り返すことで、

システムに不要な負荷がかかり、計画通りに処理が完了しないという問題を解決できます。

■ジョブスケジューラによるバッチ処理の計画実行Systemwalker Operation Managerなどのジョブスケジューラ製品を利用し、バッチ処理を実行する時間

や曜日などを定義できます。指定した時間でのバッチ処理の自動実行や、実行状況や処理結果のタイムリーな把握により、計画実行と異常の早期検出、対処が可能です。

■ウィザードによるバッチジョブ定義の容易な作成Interstage Studioで利用するバッチジョブ定義エディタウィザードにより、バッチジョブ定義をＧＵＩで簡単に

定義できます。アプリケーションの呼び出し順序、使用するファイル資源の事前排他獲得、異常発生時の実行順序などを簡単に定義できます。



情報系サービスと通信サービスを統合したサービスを開発・実行

1.6 Interstage SIPnetの概要1.6 Interstage SIPnetの概要

アプリケーション開発環境

Interstage SIPnetApplication Container

SDK

Interstage SIPnetApplication Container

業務連携アプリケーション

HTTP/SIP Servletコンテナ


J2EE

Interstage SIPnetVoiceXML Server

VoiceXML(音声対話) 音声合成

録音・再生音声認識

SIP DTMF

電話接続・転送など

GW装置

InterstageSIPnet Client

Webブラウザ

連携

SIP HTTP/SIP SIP

IP電話

業務アプリケーション


Interstage SIPnetは情報系サービスと通信サービスを統合したサービスを開発・実行するためのソフ

トウェアです。

■Interstage SIPnet Application ContainerWebと音声を統合させた新たな業務サービスの短期構築を実現するアプリケーション開発・実行環境を提供します。情報(Web)と通信(SIP)のセション管理を統合し、情報、通信どちらかでも統一的に制御

します。

・SIPサーバ機能利用者情報(電話番号、SIPアドレス、IPアドレス)の登録、更新、削除を管理するレジストリを提供すべてのSIPサーバに登録されている利用者情報を蓄積管理するロケーションサーバを実装SIPメッセージの発信者と着信者の間で発着呼を制御する機能を提供

・JCPで規定されるSIP ServletおよびServlet API 2.3/JSP 1.2の実行基盤を提供

・IETF RFC 2068で規定されたHTTPと、IETF RFC 3261で規定されたSIPをサポート

・SIP Servletや融合アプリケーション開発のためのSDKを提供

■Interstage SIPnet VoiceXML ServerVoiceXML2.0に準拠したSIPベースの高品質な音声認識・音声応答サービスを実現します。Webアプリケーションに音声対話サービスを付加した新たな業務サービスを実現します。Interstage SIPnetApplication ContainerやInterstage Realtime Communicatorなどのサーバで動作するアプリケー

ションと連携できます。

・SIP対応新規または既設のVoIPサービス環境で、音声自動応答サービスを提供可能

・VoiceXMLインタプリタの搭載Voice Extensible Markup Language Version 2.0に準拠したVoiceXMLインタプリタを搭載音声対話サービスをXMLから作成可能


■Interstage SIPnet ClientInterstage SIPnet Application ContainerをSIPサーバとしたソフトフォンとして利用できるソフトウェアです。VoIPによるソフトフォン機能に加え、Interstage SIPnet Application Containerと連携したプレゼンス機能と豊富なコラボレーション機能により、Webと音声を連携したビジネスコミュニケーション環境

を提供します。

・電話機能音声通話 / TV電話 / 通話保留 / 発着信履歴保存 / 録音 / 録画/ キャッチフォン / メンバリストのアドレスとプレゼンスの表示

・コミュニケーション機能プレゼンス変更・表示 / インスタントメッセージ

・P2Pアプリケーション機能 (SIPサーバがないクライアント間での直接通信)ファイル転送 / ホワイトボード

・多地点会議機能 ( 大4人で多地点での双方向ビデオ会議)・メール連携機能 (メンバリストと連携したメール送信)・Internet Explorer連携 (ブラウズ中ページの電話番号への直接発信などが可能)・IPv6機能 (Windows XP(SP1以上)において、IPv6ネットワーク環境で利用可能)



Webサーバやアプリケーションサーバのための強固なセキュリティ基盤を提供

1.7 Interstage Security Directorの概要1.7 Interstage Security Directorの概要

InterstageApplication ServerInterstage

Security Director

アプリケーションゲートウェイ

ファイアウォール

ユーザ認証・認可

携帯端末認証

アクセス制御VPN接続

SSL

Interstage Security Director

etc

Webサーバ

アプリケーションサーバ

ネットワーク

認証サーバ

リポジトリサーバ

InterstageInteractionManager

Webサーバ

Webサーバ

グループウェア

Webメール

サーバ

認証

情報

の通

知

認証・認可

認証情報の通知

認証

情報

の通

知

暗号化による安全な通信経路

フロントエンドでのアクセス制御による

安全なアクセス

1ライセンスで機能ごとに別サーバにインストールし

サーバ負荷分散

認証情報の通知による利便性向上

VPN(IPsec)

不正アクセス制御

アドレス変換

Interstage Security Directorは、インターネット上でサービスを提供するWeb サーバやアプリケーションサーバのために強固なセキュリティを確保するソフトウェアです。不正アクセスの防止、通信データの保護、ユーザ認証、内部サーバの隠ぺいなど、強固なセキュリティ基盤を提供します。

Interstage Security Directorは、以下の機能を提供します。

■ファイアウォール機能

インターネットから内部ネットワークへの不正なアクセスを検出し、遮断する機能を提供します。

■アプリケーション・ゲートウェイ機能

利用者認証、暗号化、アクセス制御などにより、HTTPおよびIIOPを使用した通信データを、安全に中継する機能を提供します。



負荷分散やQoS制御により可用性・信頼性の高いトラフィック管理機能を提供

InterstageApplication Server

【アプリケーションサーバ】

InterstageApplication

Server【Webサーバ】

1.8 Interstage Traffic Directorの概要1.8 Interstage Traffic Directorの概要

InterstageTraffic Director

InterstageTraffic Director

ワークユニット1





ワークユニット2 異常

ファイアウォール

HTTP

その他

FNA

クラスタリング・ホットスタンバイ

Interstage Traffic Director Enterprise Edition Interstage Traffic Director Standard Edition●負荷分散：HTTPヘッダ負荷分散、IIOP負荷分散、

ワークユニット監視、コネクション・リセット、HTTPエラーメッセージ転送、Webアクセラレーション

●負荷分散：URLベース負荷分散、一意性保証、故障監視

●QoS制御：上下帯域制御、パケットサイズ適化●キャッシュ機能：HTTP、FTP

Standard Edition

負荷分散

キャッシュ

QoS制御

Enterprise Edition

IIOP負荷分散

ワークユニット監視

負荷計測エージェント



安定した帯域の確保豊富な

負荷分散方式サーバ負荷異常を通知

セション維持（一意性の保障）

Interstage Traffic Directorは、さまざまな負荷情報にもとづく分散機能によって、きめ細かなトラフィック管理を提供し、Webシステムや企業システムに要求されるパフォーマンス、安定性、拡張性を高いレベルで実現します。Webサーバやアプリケーションサーバの追加や故障時にもサービスを停止させない、可用性・信頼性の高いシステムを構築できます。

Interstage Traffic Directorでは、以下の機能を提供します。

■負荷分散機能

多数の利用者からのアクセスに対して、つねに優れたレスポンスを返せるようにサーバを負荷分散する機能を提供します。

■QoS(帯域)制御機能

ネットワークを流れるパケットに対して、必要に応じて帯域幅を割り当てることで、重要度の低い過剰なトラフィックから重要度の高いトラフィックを保護し、安定したサービスを提供する機能を提供します。

■キャッシュ機能

クライアントがサーバから取得したデータを一時的に保存し、再び同じ要求がなされた場合に、保存したデータを返すことにより、レスポンスの向上、およびネットワークトラフィック量を軽減する機能を提供します。

また、Interstage Traffic Directorは、以下の製品から構成されます。

■Interstage Traffic Director Standard Edition様々な情報に基づいて、サーバ側のトラフィックを分散する負荷分散機能やQoS(帯域)制御、キャッシュ機能を提供する。

■Interstage Traffic Director Enterprise EditionStandard Editionの機能に加え、Interstage Application Serverとの連携など高度な負荷分散機能を提供する。


MEMO



第２章Interstage Application Serverの

関連技術とサービス

本章ではInterstage Application Serverがサポートしている標準技術と、各アプリケーションの動作基盤として提供して

いるサービスについて説明します。



2.1 Interstage Application Serverが提供する標準技術2.1 Interstage Application Serverが提供する標準技術

1.0Connector(J2EE Connector Architecture)2.0JDBC1.2JNDI1.0.1JTA(Java Transaction API)1.0JTS(Java Transaction Service)1.2JavaMail

2.0CPPA(Collaboration-Protocol Profile and Agreement Specification Version)

2.0ebMS(ebXML Message Service Specification Version)

ebXML1.0RMI-IIOP

1.0JAAS(Java Authentication and Authorization Service)

1.0.3_01JSSE(Java Secure Socket Extension)1.2.2JCE(Java Cryptography Extension)1.2JAXP(Java API for XML Parsing)1.0JAF(JavaBeans Activation Framework)

1.0.2JMS2.0EJB2.0JSP2.4Servlet1.3J2EEJava

バージョン標準技術名カテゴリ

2.3 , 2.4CORBACORBA

1.0LDIF2.0 , 3.0LDAPディレクトリ

サービス

1.1HTTP1.1CGIWebサーバ

1.2SAAJ(SOAP with Attachments API for Java)

1.1JAX-RPC(Java API for XML-based RPC)1.1JAXM(Java API for XML Messaging)1.1WSDL2.0UDDI1.1 , 1.2SOAPWebサービ

ス

バージョン標準技術名カテゴリ

Interstage Application Server では、アプリケーションサーバに必要とされる、数々の標準技術を提

供しています。

Interstage Application Serverが提供しているおもな標準技術を以下に示します。

■Java・ J2EE ：サーバサイドでJavaテクノロジを実装するための環境

・ Servlet ：サーバサイドでJavaアプリケーションを動作させる技術

・ JSP ： HTMLをベースとして、サーバサイドで動的にWebページを生成するJavaアプリケーション技術

・ EJB ：ソフトウェアを部品化するJavaBeans仕様にサーバ側で必要な機能を追加した規約

・ JMS ：メッセージを使用してデータ送受信を行うJavaアプリケーション技術

・ JDBC ： Javaプログラムよりデータベースへアクセスする技術

・ JNDI ：ネームサービスおよびディレクトリサービスへアクセスするためのインタフェース

■CORBA・ CORBA ：分散システム環境でオブジェクト同士がメッセージを交換するための技術仕様

■Webサービス

・ SOAP ： Webサービスなどの分散環境における情報交換に使用される軽量プロトコル

・ UDDI ： Webサービスを検索、照会するための情報を格納したディレクトリ

・ WSDL ： Webサービスのインタフェースを定義するXMLベースの言語

■ディレクトリサービス

・ LDAP ： TCP/IPネットワークでディレクトリ管理データベースへアクセスするためのプロトコル

以降、上記の技術の中でも代表的な技術である「Servlet」、「JSP」、「EJB」、「CORBA」、「Webサービス（SOAP）」、「JMS」、「JNDI」について取り上げて説明します。



2.2 Interstage Application Serverの機能 (1/5)2.2 Interstage Application Serverの機能 (1/5)

Webサーバ機能

・Webサーバとして、 Interstage HTTP Server (Apache 2.0.59ベース)を提供

Webサービス機能

・ SOAP（Simple Object Access Protocol）、ebXML（e-Business XML）、UDDIなどのWebサービスの国際標準技術に対応

J2EE対応

・ J2EE（Java 2 Platform, Enterprise Edition）に対応しており、Servlet、JSP、EJB（Enterprise JavaBeans）などを使用可能

CORBA対応

・ OMGによって定められた分散オブジェクトの標準技術であるCORBAに対応

IPv6対応

・ブロードバンドインターネット対応として、IPv6をサポート

Interstage Application Serverは、J2EE、SOAP、UDDI、ebXML、CORBAを始めとする新の国際標準技術に、これまで富士通が培ってきた高信頼/高性能の基幹システムの構築技術を融合した基盤

ソフトウェアです。

ここでは、説明してきた特長を実現するために提供されている機能について紹介します。

■Webサーバ機能

Webアプリケーションの動作環境として、Apache 2.0.59をベースとした、高信頼、高性能なWebサーバ(Interstage HTTP Server)を搭載しています。

■Webサービス機能

SOAP（Simple Object Access Protocol）、ebXML（e-Business XML）、UDDIなどのWebサービスの国際標準技術に対応しています。これらの機能を使って、さまざまなWebサービスとシームレスに連

携できるので、柔軟かつ低コストで企業システムを構築できます。

■J2EE対応

新のコンポーネント化技術であるJ2EE（Java 2 Platform, Enterprise Edition）に対応しています。Servlet、JSP、EJB（Enterprise JavaBeans）などを使用することにより、高い生産性でシステム構築

できます。

■CORBA対応

OMGによって定められた分散オブジェクトの標準技術であるCORBAに対応しています。プラットフォー

ムや開発言語に依存しないアプリケーション実行環境の提供や、異なるベンダ間の相互接続性を保証しています。

■ブロードバンドインターネット対応

ブロードバンドインターネット対応として、IPv6をサポートしています。既存のIPv4に加え、IPv6でシステ

ム構築が可能です。




OLTP機能

大規模・高信頼システム対応

・クラスタサービス機能 (Enterprise Editionで提供)・ロードバランス (Enterprise Editionで提供)・動的アプリケーション入れ替え機能 (Enterprise Editionで提供)・高性能な実行環境

・ノンストップのサービス提供・レスポンス保証・データ一貫性保証・即時性・リソースの平準化

・ノンストップのサービス提供・レスポンス保証・データ一貫性保証・即時性・リソースの平準化

OLTP Technologyon Interstage

ホットスタンバイ

動的アプリケーション

入れ替え

メインフレームネットワークコンピューティング

AIM Interstage

OLTP Technologyon AIM

■OLTP機能

富士通がメインフレーム分野で培った高信頼化技術を継承することにより、省資源化を実現するリソース共有機能、応答性の保証のためのキュー管理機能を含む高性能、高信頼なOLTP機能を実現していま

す。

■大規模・高信頼システム対応

・ホットスタンバイ

－業務運用中のサーバに対して、同様の環境を備えたサーバを待機として準備し、業務運用中のサーバが故障したときに、待機していたサーバが業務を引き継ぎます。（1対1運用待機型ホットスタンバイ）

－Solaris版のInterstage Application Serverでは、待機側のサーバも運用させることにより、サーバ

相互で引き継ぎ可能な環境を構築できます（相互待機型ホットスタンバイ）。相互待機型のクラスタは、Interstage Application Serverのマルチシステム機能を利用することに

より、システム単位での相互待機が可能です。

・負荷分散

－複数台のサーバを同一システムとして並行処理し、クライアントからの処理を自動的に分散します。サーバ異常時は異常サーバを切り離して残りのサーバで運用します。クライアント側は使用するサーバを意識する必要はなく、システムが自動的にサーバに振り分けます。

－Interstage Traffic Directorとの連携により、サーバ異常発生時に短時間でクライアントに異常通

知することもできます。

・動的アプリケーション入れ替え機能 (Enterprise Editionで提供)ノンストップ運用が求められるシステムに対応します。システム運用を停止することなく、業務アプリケーションの追加や入れ替え、環境変数など動作環境の変更が可能です。(トランザクションアプリケーションのワークユニットの活性変更(業務を停止することなくワークユニット定義を変更し、変更後の定義どおりにワークユニットを起動し運用すること)が可能です。)

・高性能な実行環境J2EEの実行環境として、高速のJava実行基盤（コンテナ）を提供しています。これにより、EJB、Servlet、JSPなどのJavaアプリケーションを高速に処理できます。




ディレクトリサーバ機能

・X.500、LDAP（Lightweight Directory Access Protocol）V3準拠のディレクトリサーバを提供

ディレクトリサービス機能

・ユーザ管理情報やWebサービス情報を格納できるディレクトリサービス機能を提供

セキュリティ機能

・CORBA標準に準拠したFireWallセキュリティ機能・HTTPトンネリング機能・SSL 3.0、TLS 1.0認証、128ビット暗号機能

・ベリサイン社、日本認証サービスの証明書を使用したＳＳＬ通信・LDAPをベースとしたユーザ認証、アクセス制御

・シングルサインオン機能・JAXM 1.1、JAX-RPC 1.0の実装、WS-Security仕様に準拠したセキュリティ機能

分散トランザクション機能

・複数データベースへのアクセス時に、更新データに矛盾が発生しないように同期更新を保証(Enterprise Editionで提供)

・異常時のリカバリ処理 (Enterprise Editionで提供)

■ディレクトリサーバ機能

OSI（開放型システム相互接続）標準の国際規格の1つであるX.500、インターネット標準であるLDAP（Lightweight Directory Access Protocol）V3準拠のディレクトリサーバを提供します。これにより、ネットワーク内の利用者や資源をディレクトリで一元管理やユーザの認証が可能です。

■ディレクトリサービス機能

従来のユーザ管理情報(ユーザ名、パスワード、ユーザの権限など)やWebサービス情報(国際標準UDDI規定の企業情報、インタフェースなど)を格納できるディレクトリサービス機能を提供します。

■セキュリティ機能

Webサービス、J2EEおよび分散システムに不可欠な各種セキュリティ機能を実装し、安全なイントラネット/エクストラネットシステム構築を実現します。

・CORBA標準に準拠したFireWallセキュリティ機能（Interstage Security Directorとの組み合わせが必要です。）

・CORBAクライアントとサーバアプリケーション間のHTTPによる通信のためのHTTPトンネリング機能

・SSL 3.0、TLS 1.0のクライアント・サーバ認証と128ビット暗号機能

・ベリサイン社、日本認証サービスの証明書を使用したSSL通信

・分散サーバ環境での適用性を高めるため、分散ディレクトリ（LDAP：Lightweight Directory AccessProtocol）をベースとして以下の機能を提供します。

－アプリケーション（クライアント/サーバ）からの要求によるユーザ認証－認証結果による業務環境やアプリケーション単位のアクセス制御

・1回のサインオンで、複数のシステムやWebサービスへのアクセスを可能とする認証/認可サービス(シングルサインオン機能)

・国際標準技術JavaAPIの実装と業界標準WS-Securityの仕様に準拠したWebサービスのセキュリティ機能

■分散トランザクション機能 (Enterprise Editionで提供)・アプリケーションが複数のデータベースにアクセスした場合、更新データに矛盾が発生しないように同

期更新を保証します。

・アプリケーションが別システムに配置されている複数のデータベースにアクセスした場合にも、更新データに矛盾が発生しないように同期更新を保証します。

・Interstage Application Serverが異常時のリカバリ処理をします。




非同期通信機能

・メッセージキューを介したアプリケーション間の非同期通信をサポート・非同期通信機能として、Interstage JMS、イベントサービス、Message Queue Director を提供・IBM社のWebSphere MQとの非同期通信による連携が可能

既存ホストシステムの活用

PRIMEFORCE,GS/M,(Interstage for GS)

PRIMEFORCE,GS/M，他社メインフレーム

他社サーバ

IIOP FNA/OSI/SNA/ほか SMTP/SMIME,ファイル転送,MQ

ラッピング

Interstage Application ServerInterstage Application Server

業務用アプリケーション／パッケージ非同期通信機能

Server2000 NETSTAGE Director

UNIX/Windows インターネット／イントラネット

■非同期通信機能

・メッセージキューを介したアプリケーション間の非同期通信をサポートします。アプリケーション間の通

信でメッセージが使用され、送信側のアプリケーションが出力したメッセージを、受信側のアプリケーションが必要な時に取り出して利用できます。また、グローバルサーバとの接続もできるため、ネット

ワークを介して基幹業務と連携した業務構築も可能です。

・Interstageでは、非同期通信機能として、以下の機能を提供しています。

－Interstage JMSJ2EEの規約に準拠した非同期通信機能

－イベントサービスCORBAの規約に準拠した非同期通信機能

－MessageQueueDirector富士通が規定した機能豊富な非同期通信機能グローバルサーバの機能(ACM、TJNL)と連携する場合、およびSymfowareトランザクション連携機能を使用する場合は、MessageQueueDirectorを使用します。

－IBM社のWebSphere MQとの非同期通信による連携が可能です。

■既存ホストシステムの活用既存のアプリケーションやデータベースをカプセル化するラッパー機能を利用することで、既存業務システムを充分に活用した新たなシステム構築を短期間で実現できます。また、エミュレータベースからWebブラウザへの移行は操作性の向上が図れる上、新たな設備投資(専用端末、専用線) が不要です。(ホスト資産の活用はServer2000ホスト連携プレミアム V1.1またはNETSTAGE Director V2.0以降が必要です。)




運用管理機能

・Systemwalker Centric Managerを利用し、アプリケーションの稼動管理、性能管理が可能・Systemwalker Operation Managerを利用し、システム運用･管理作業の自動化が可能

簡易導入機能

・ワンタッチインストール機能、システム環境の自動設定機能を提供

プラットフォームや開発言語に依存しない実行環境

フロントシステムフロントシステム

Java



ミドルシステムミドルシステム

Java



ミドルシステムミドルシステム

COBOL



バックシステムバックシステム

COBOL



入出力画面処理業務・環境の変化に素早く対応

安定した仕様（ISO規格）高性能・高信頼システム

大量データ処理ビジネスロジック記述に適な言語仕様

変更に柔軟に対応コンポーネント技術による部品化

インターネット

■運用管理機能

・Systemwalker Centric Managerを利用することにより、Interstage Application Server上で運用

されているアプリケーションの稼動管理、性能管理が可能です。これにより、万一トラブルが発生した場合でも、ネットワーク経由で復旧できるなど、システムの運用性を大幅に高めることができます。

・Systemwalker Operation Managerを利用することにより、ワークユニットの自動実行/監視/操作など

のシステムの運用･管理作業を自動化できます。

■簡易導入機能

ワンタッチインストール機能や、運用規模に合わせたInterstageシステム環境の自動設定機能などを

提供しており、容易に導入できます。

■プラットフォームや開発言語に依存しない実行環境

Solaris、Windows、LinuxのプラットフォームやJava／C／C++／COBOLのアプリケ

ーションの実行環境をサポートしています。

COBOLは、大量データ処理、伝票・帳票処理、高速性・高信頼性など、ビジネスアプリケーションに適した特長があります。既存のCOBOLアプリケーションを流用またはノウハウを活用することにより、高生産

性を実現できます。

さらに、EJB/Javaとの連携も可能であり、効率的にシステムを構築することが可能です。

Interstage Application Serverは、ほかのWebアプリケーションサーバにみられるJavaだけのサポートではなく、Javaと使いなれた言語（C/C++/COBOL）を組み合わせてシステムを構築できます。



Apache 2.0.59をベースとしたWebサーバ(Interstage HTTP Server)を提供

2.3 Webサーバ2.3 Webサーバ

複数Webサーバ機能

・1つのシステム上で複数のWebサーバを構築・運用可能

認証とアクセス制御

SSL

バーチャルホスト

仮想ディレクトリサーバステータスの監視

IPv6対応

コンテンツ圧縮機能

・任意のディレクトリをURLの仮想パスとして割り当て可能

・Webブラウザからのアクセスをユーザ認証やIPアクセスコントロールにより制限可能

・SSLによるクライアント・サーバ認証と暗号化通信をサポート

・IPアドレス/ポート番号またはホスト名を別とした仮想Webサーバを作成可能

・Webブラウザ-Webサーバ間のアクセス数、転送量、通信プロセス（スレッド）などを確認可能

・IPv6に対応したWebサーバを提供(Solaris/Linuxのみ)

・Webブラウザ-Webサーバ間のコンテンツ転送量を減少しネットワーク負荷を軽減

Interstage Application Serverでは、Apache 2.0.59をベースとしたWebサーバ機能としてInterstage HTTP Serverを提供しています。

Webサーバは、Webブラウザからのリクエストの内容に応じて、指定された文字や画像データなどを送信したり、コネクタ(Webサーバコネクタ)を使用して、アプリケーションに対する処理要求をアプリケー

ションサーバに転送したりします。

Interstage HTTP Serverでは、おもに以下の機能を提供しています。

■ 仮想ディレクトリ任意のディレクトリをURLの仮想的なパスに割り当てることができます。

■ 認証とアクセス制御資源(ディレクトリ全体、そのディレクトリ配下のHTML文書、画像データなど)に対して、Webブラウザからのアクセスをユーザ認証やIPアクセスコントロールにより制限できます。また、ユーザ認証に使用するユーザ名/パスワードおよびグループ情報は、ディレクトリサーバ(LDAPサーバ)上で一括管理できます。これにより、Webサーバ間共通のユーザ名/パスワードなどの使用が可能となります。

■ SSLWebブラウザとWebサーバ間の通信プロトコルとして、SSLによるクライアント・サーバ認証と暗号化通信を利用することで、盗聴/改ざん/なりすましなどの危険を回避し、情報のプライバシーを守ること

ができます。

■ バーチャルホストホスト名(IPアドレス/ポート番号)が異なるWebサーバを同一のサーバマシン上で運用することで、Webブラウザから複数のマシンを仮想的に利用できます。バーチャルホストには、複数のIPアドレス/ポート番号を設定し、それぞれのIPアドレス/ポート番号にバーチャルホストを実現するIP/ポート番号ベースのバーチャルホストと、1つのIPアドレスに対して

複数のホスト名を割り当てることにより、それぞれのホスト名のバーチャルホストを実現するネームベースのバーチャルホストがあります。ネームベースのバーチャルホストでは、SSLを使用することはできません。バーチャルホストの起動/停止は、バーチャルホストを設定するWebサーバの起動/停止に依存します。


■ サーバステータスの監視機能アクセス数、転送量、通信プロセス（スレッド）の状態など、Webサーバに関するさまざまな動作状態を表示

し、確認することができます。

■ 複数Webサーバ機能1つのシステム(マシン)上で、複数( 大16個)のWebサーバを構築・運用できます。これにより業務ごとの

柔軟な運用や問題発生時の影響の極小化を実現することが可能となります。Webサーバは、Interstage HTTP Server運用コマンド、またはInterstage管理コンソールを使用して構築

します。

■ IPv6対応 (Solaris/Linux のみ)Webサーバのリクエスト待ち受けポートにおいて、IPv6のソケットをサポートしています。これによりIPv6パケットによるWebブラウザからのリクエストに対応することができます。

■ コンテンツ圧縮機能

クライアントに送信するコンテンツを圧縮する機能を提供しています。これによりコンテンツの転送量が減少するため、ネットワークの負荷が軽減し、リクエストの転送効率を向上させることができます。コンテンツの圧縮機能を設定した場合、HTTPヘッダのContent-Lengthの値は圧縮後のサイズとなります。



2.3.1 Interstage HTTP Serverのログ2.3.1 Interstage HTTP Serverのログ

エラーログ

トレースログ

オペレーションログ

アクセスログ

Interstage HTTP Serverが出力するログの種類

保守ログ

・クライアントからのアクセス状況を出力クライアントからWebサーバへアクセスが行われる度に出力されるどのページがだれによってよく参照されているかなど、Webページの利用状況解析などによく利用される

・Webサーバで発生したエラーを出力クライアントからサーバに存在しないファイルが要求された場合などに出力される

・クライアントおよびWebサーバモジュールとの入出力情報を出力クライアントからの要求に対し、どのようなモジュールを呼び出し、どのような情報を出力したかを確認可能

・Webサーバに対する操作履歴を記録するためのログを出力Webサーバの作成/削除、起動/停止がいつ行われたかなどの情報を確認可能

・Webサーバの保守に関するログ（内部的に行っている詳細なログ）を出力

[ 下線部：重要ポイント ]

Point！

Point！

Point！

Point！

Point！

Point！

Interstage HTTP Serverでは、Webサーバのセキュリティ確保および障害発生時の対応のため、以下のログが出力できるように設計されています。

■ アクセスログWebクライアントからのアクセス状況を出力します。・出力先

アクセスログの出力先は、初期設定では、以下のファイルに出力するように設定されています。－ Windows ： C:¥Interstage¥F3FMihs¥servers¥(Webサーバ名)¥logs¥accesslog－ Solaris ： /var/opt/FJSVihs/servers/(Webサーバ名)/logs/accesslog－ Linux ： /var/opt/FJSVihs/servers/(Webサーバ名)/logs/accesslog(インストールパスはデフォルト)出力先は、Interstage管理コンソールまたはWebサーバの環境定義ファイル(httpd.conf)で変更可能です。

・出力形式アクセスログは、初期値のフォーマット(ihs-analysis)では、以下の形式で出力され、Webサーバの環境定義ファイル(httpd.conf)で変更可能です。------------------------------------------------------------------------------------------------------------------------------ホスト名ユーザ名識別ユーザ名日時 “リクエスト” ステータスコードデータ転送量

WebサーバのIPアドレス：ポート番号 HostヘッダプロセスID 処理時間リクエストID------------------------------------------------------------------------------------------------------------------------------

■ エラーログWebサーバでエラーが発生したときのエラー状況をログとして出力します。・出力先

エラーログの出力先は、初期設定では、以下のファイルに出力するように設定されています。－ Windows ： C:¥Interstage¥F3FMihs¥servers¥(Webサーバ名)¥logs¥errorlog－ Solaris ： /var/opt/FJSVihs/servers/(Webサーバ名)/logs/errorlog－ Linux ： /var/opt/FJSVihs/servers/(Webサーバ名)/logs/errorlog(インストールパスはデフォルト)出力先は、Interstage管理コンソールまたはWebサーバの環境定義ファイル(httpd.conf)で変更可能です。

・出力形式エラーログは、以下の形式で出力されます。------------------------------------------------------------------------------------------------------------------------------[日時] [ログレベル] [client IPアドレス] (エラー番号)エラー説明: メッセージ本文------------------------------------------------------------------------------------------------------------------------------なお、「client IPアドレス」「エラー番号」「エラー説明」は省略される場合があります。


■ トレースログWebクライアントとの入出力情報、およびプラグインモジュールとの入出力情報のログを採取します。

各トレース情報は、以下のタイミングで出力されます。

・Webクライアントとの入出力情報

－ TCPコネクション接続時/切断時－ HTTPリクエスト受信時/HTTPレスポンス送信時

・プラグインモジュールとの入出力情報

－プラグインモジュールの応答処理関数の呼び出し時/復帰時

・出力先トレースログの出力先は、初期設定では、以下のファイルに出力するように設定されています。

－ Windows ： C:¥Interstage¥F3FMihs¥servers¥(Webサーバ名)¥logs¥tracelog－ Solaris ： /var/opt/FJSVihs/servers/(Webサーバ名)/logs/tracelog－ Linux ： /var/opt/FJSVihs/servers/(Webサーバ名)/logs/tracelog(インストールパスはデフォルト)なお、出力先は、Webサーバの環境定義ファイル(httpd.conf)で変更することもできます。

・出力形式トレースログは、以下の形式で出力されます。------------------------------------------------------------------------------------------------------------------------------[日/月/年:時:分:秒.ミリ秒][プロセスID][スレッドID]イベント詳細情報------------------------------------------------------------------------------------------------------------------------------なお、「スレッドID」はWindowsの場合のみ出力されます。

■ オペレーションログWebサーバに対する操作履歴を記録するためのログを採取します。ファイル数の上限値2、1ファイル当たりの大ファイルサイズは1Mバイト(合計2Mバイト)でログファイルをローテーションします。ファイル数が上限値2に達した場合は、古いログファイルを削除して新しいログファイルを作成します。不要であれば、Webサーバが停止しているときに削除します。

・出力先オペレーションログは、以下のファイルに出力されます。

－ Windows ： C:¥Interstage¥F3FMihs¥var¥opelog¥opelog－ Solaris ： /var/opt/FJSVihs/var/opelog/opelog－ Linux ： /var/opt/FJSVihs/var/opelog/opelog(インストールパスはデフォルト)

■ 保守ログWebサーバの保守用のログを採取します。ファイル数の上限値2、1ファイル当たりの大ファイルサイズは5Mバイト(合計10Mバイト)でログファイルをローテーションします。ファイル数が上限値2に達した場合は、古いログファイルを削除して新しいログファイルを作成します。不要であれば、Webサーバが停止しているときに削除します。

・出力先保守ログは、以下のファイルに出力されます。

－ Windows ： C:¥Interstage¥F3FMihs¥var¥.ihsapi¥ihsapi.log－ Solaris ： /var/opt/FJSVihs/var/.ihsapi/ihsapi.log－ Linux ： /var/opt/FJSVihs/var/.ihsapi/ihsapi.log(インストールパスはデフォルト)

Interstage HTTP Serverでは、出力するログファイルのローテーションを行うことができます。ログファイ

ルのローテーションとは、保存するログファイル数の上限値を超えてログファイルを出力する場合に、も古いログファイルを削除し、新しいログファイルを作成することを示します。出力するログのローテーションを設定することで、むやみにディスク資源を圧迫するのを防ぐことができます。



2.4 Servlet2.4 Servlet

Servletコンテナ

J2EEJavaVM

Servletコンテナ

プロセス起動コネクタ

実行

■Servletの仕組み

■ServletとCGIの違い

リクエストごとにプロセスを生成

リクエストにスレッドが対応

Webサーバアプリケーションサーバ

サーブレットのライフサイクル

ブラウザブラウザ

初期化

終了

ブラウザ

Servlet

Servlet

CGI

CGI

CGI

Servletとは、サーバ側で実行するJavaアプリケーションのことです。Servletは、クライアントであるWebブラウザからの要求に対して、Webサーバ上のServletコンテナ(Servletの実行環境)上で動作します。Servletの実行環境を提供するWebコンテナ(Servletコンテナ)もJavaVM上で動作するJavaアプリケーションです。

ServletはWebブラウザからのHTTPリクエストを、HTTPサーバを経由して受け取ります。3階層システムにおいて、Servletはリクエストに対する処理方式を決定し、次の画面を指示するコントローラとして動作し、ビジネスロジックからの結果をWebブラウザに表示するHTML文書を生成し、レスポンスとして返却する役割を担います。

この他、Servletでは認証機能、パラメタのチェックなどを実装することもできます。または、Servletにビジネスロジックを実装することもできます。

また、Servletには以下のような特徴があります。

■マルチスレッド

CGIがリクエストごとにプロセスを生成するのに対し、Servletは、リクエストに対して1つの実行スレッドが対応しており、プロセス生成によるオーバヘッドがありません。さらに、一度実行されたServletは、Servletコンテナ上に常駐化(インスタンス化)するため、2回目以降にリクエストのレスポンスが速くなります。また、リクエストごとにプロセスを起動する必要がないため、省資源化を図ることも可能となります。

■ライフサイクルServletはライフサイクルにもとづいて動作します。ライフサイクルには、Servletの初期化、サービス実行(繰り返し)、終了というプロセスがあり、Servletコンテナによって制御されています。具体的には、以下のようなAPIによって処理が実行されます。

・初期化： HttpServlet.init()メソッド

すべてのブラウザからのアクセスの中で、初回のアクセスに対して、1度だけ実行され、初期化時に実行したい処理を実行します。

・サービス実行(繰り返し) ： HttpServlet.service()メソッド

クライアントからのリクエストを処理し、ブラウザからのパラメタ取得、ビジネスロジック、画面出力を記述します。また、マルチスレッドで動作し、複数のクライアントからのリクエストを多重で処理します。

・終了： HttpServlet.destroy()メソッド

Servletコンテナの終了時に呼び出され、データベースのコネクションなどの回収処理をします。

Servletの初期化は初回リクエスト時のみ実行され、2回目以降のリクエストでは、サービスの実行のみをします。そのためWebブラウザへのレスポンスが速くなります。



J2EE

JavaVM

ServletコンテナWebサーバ

ブラウザ

2.5 JSP2.5 JSP

JSP Javaソース

JSP

ビジネスロジック(EJB)

Servlet：プログラムロジックでHTMLを出力する

JSP：HTMLの中にプログラムを記述する

⇒制御やロジックの処理に向いている

⇒コンテンツの出力に向いている

初回呼び出し時に、JSPからJavaソースコードへの変換とServletクラス

へのコンパイル処理が行われる。

■JSPの仕組み

■ServletとJSPの使い分け

機能役割（MVCモデル）リクエストを受けて、処理を振り分ける

HTMLを生成し、

インタフェースを提供

業務処理

２回目以降の呼び出し時には、直接Servletが呼び出される。

Servlet

Servlet

JSP(JavaServer Pages)は、HTMLの中にJavaのプログラムコードやコンポーネントを埋め込み、動的にWebページを生成する技術です。

HTMLコンテンツとプログラムの切りわけは、JSPタグ（<%、%>）を使用します。JSPタグを使用してHTMLの中にJavaプログラムを記述することができます。これにより、デザインの変更はJSPファイルを編集するだけでよく、コーディング、コンパイル、デバッグなどの作業を簡素化することができます。

JSPは、クライアントから呼び出されると、アプリケーションサーバの内部でServletのソースコードに変換され、その後コンパイルされ、Servletプログラムとして動作します。再度同じJSPファイルが呼び出された場合は、すでに生成済みのServletプログラムが動作し、何度もソースコード変換、およびコンパイルが行われることはありません。Servletコンテナの起動時か初のクライアントからの呼び出し時に一度だけソースコー

ド変換、コンパイルが行われます。

ServletとJSPは、クライアント側からの依頼により、処理を実行し、HTMLを出力するプログラムという点で同じですが、プログラムの記述の仕方が異なります。ServletはJavaプログラムがベースであり、HTMLの生成はプログラムで出力命令(printlnなど)を記述します。

一方、JSPはHTMLコンテンツの記述がベースであり、その中にHTMLを出し分ける条件などの処理を、

スクリプトレットで記述します。

また、処理の少ないものであれば、ServletやJSPの中で行うことも可能ですが、一般的にビジネスロジックはEJBやJavaBeansで行い、ServletやJSPでは画面制御と画面表示をする、という形態にすることで、

役割分担が明確になります。

具体的には、Webアプリケーションを構築する際に、ServletはHTTPリクエストの解析と制御をするController(コントローラ)、JSPはクライアントへ表示するHTMLを生成するView(ビュー)、ビジネスロジックはEJBをModel(モデル)としたMVCモデル構成にすることで、それぞれのコンポーネントの独立性、可読

性を高めることができます。

JSPは、 MVCモデルにおいて、クライアントへ表示する画面を生成するビューとしての使用に適しています。



Webアプリケーションの実行を制御

2.6 Servletサービス2.6 Servletサービス

クライアント

Servletサービス

WebアプリケーションWebアプリケーション

HTMLファイル

JSPファイル

EJBアプリケーション

CORBAアプリケーション

URL

HTML

Webサーバ

Servlet

ServletおよびJSPの実行環境は、Interstage Servletサービスで提供されます。Servletサービスは、Webサーバ上でWebアプリケーションの実行を制御するソフトウェアです。Webアプリケーションとは、HTMLファイル、イメージファイル、Servlet、JSPファイルなどのWebリソースから構成されているアプリケーションです。WebサーバではHTMLファイルやイメージファイルの制御が可能ですが、Servletサービスはそれに加え、ServletやJSPファイルの制御を行っています。

また、Servletサービスは、WebサーバとCORBAサービスやEJBサービスとのゲートウェイとしての役割

を担っています。

Webアプリケーションですべての機能を実現することも可能ですが、WebアプリケーションからCORBAアプリケーションやEJBアプリケーションを呼び出し、それぞれの実行結果を表示することもできます。これにより、業務アプリケーションをWebブラウザで表示させるアプリケーションの構築ができます。



WebサーバコネクタとServletコンテナ

2.6.1 Servletサービスのコンポーネント2.6.1 Servletサービスのコンポーネント

Webサーバコネクタ


Servletコンテナ

Servletコンテナ

URL URL

HTML HTML HTML

URL

起動呼び出し

HTML返却

Java VM



Servletコンテナ

Servletコンテナ

URL URL

HTML HTML HTML

URL

起動呼び出し

HTML返却

Java VMJSPロード

変換・コンパイル

クライアント

Webサーバ

クライアントWebサーバ

・Interstage HTTP Server・Microsoft Internet Information Services・Sun Java System Web Server

Servlet

Servlet

Interstage Application Serverが提供するServletサービスのコンポーネントについて説明します。Servletサービスは、WebサーバコネクタとServletコンテナの2つのコンポーネントで構成されています。

Interstage HTTP Serverでは、WebサーバコネクタはApache APIを使用したDSO(Dynamic SharedObjects)モジュールとしてWebサーバ上で動作し、Webサーバの起動と停止に連動します。

■Webサーバコネクタ

・WebブラウザのリクエストをServletコンテナへ中継します。

・Servletの処理結果を、Webサーバを通して、Webブラウザに返却します。

・Webサーバコネクタは、Webサーバの拡張機能として動作します。

■Servletコンテナ

・Servletコンテナは、Webアプリケーションを制御します。

・Webサーバコネクタの要求にしたがって、処理結果を返却します。

・Javaアプリケーションで、Java VM(Java Virtual Machine)上で動作します。

Webアプリケーション(Servlet/JSP)は、クライアントからのリクエスト(要求)に対してServletコンテナ上で

動作します。



2.6.2 Servletサービスの機能2.6.2 Servletサービスの機能

セションリカバリ機能、処理スレッド縮退機能、オートリロード機能を提供

・Servletの起動(クラスのローディング、インスタンス化)、Servletの呼び出しといったServletの制御（JavaTM Servlet API 2.4に準拠しているServletの実行）

・ JSPをServletのソースファイルに変換、コンパイルし、生成されたServletを起動といったJSPの制御（JavaServer Pages 2.0 Specificationに準拠しているJSPの実行）

Servletの制御

JSPの制御

・ Servletコンテナが複数に分散された環境で、あるServletコンテナで異常発生時、利用中のセション情報を他の運用中のServletコンテナで引き継いで運用可能

セションリカバリ機能

・サーバへ配備されたクラスおよびJSPを監視し、ファイルが直接更新された場合に更新を即座に反映(リロード)する機能を提供

オートリロード機能

・処理が完了して使用されていない待機中のスレッドを監視し、指定数を超えるスレッドを解放し、サーバ資源を節約する機能を提供

Servletコンテナの処理スレッド縮退機能

Servletサービスでは、ServletやJSPの制御のほかに、以下の機能を提供しています。

■セションリカバリ機能

Servletコンテナ、またはサーバマシンが複数に分散された環境において、異常発生時に利用中のセション情報を他の運用中のServletコンテナが引き継いで利用できます。

セション情報は、Servletコンテナ内で、Webアプリケーション単位で管理しています。Servletコンテナがダウンした場合、そのコンテナ内に格納されたセション情報は破棄されてしまいます。

セションリカバリ機能を有効にすることにより、各Servletコンテナで生成されたセション情報を、SessionRegistry Serverにバックアップしておき、運用中のServletコンテナにセション情報をリカバリして引き継ぎ、

継続して処理を行うことができます。また、Servletコンテナ(IJServerワークユニット)を再起動した場合に、再起動前のServletのセションを

破棄せずに継続して使用することも可能になります。

セションをバックアップする契機は以下の2種類から選択できます。

・リクエストごと(完了後)にバックアップ

リクエストの完了後にセションをバックアップします。また、クライアントへのレスポンスはセションがSession Registry Serverにバックアップされるのを待ってから完了します。

クライアントからのリクエストの処理時間にセションのバックアップ時間も含まれるため、クライアントからのリクエストを処理する時間は一定間隔でバックアップする場合と比較して長くなります。

・一定間隔でバックアップ

セションはリクエスト処理が完了した後にServletコンテナによって定期的にバックアップされます。

リクエスト処理とは独立してバックアップが行われるため、個々のリクエスト返却までの性能には直接影響しません。セションがSession Registry Serverにバックアップされる前にServletコンテナがダウン

した場合、そのセションはリカバリすることができません。


通常、Session Registry ServerはIJServerワークユニットからセションが無効になったことを通知された時に保持しているセションを破棄します。しかし、IJServerワークユニットがダウンしている場合はセションが無効になったことがIJServerワークユニットから通知されないため、不要なセションがSession Registry Serverに残り、Session Registry Serverのリソースを圧迫します。

そのため、Session Registry Serverは保持しているセションを一定間隔で監視し、期限切れ(タイムアウト)となっているセションを破棄することでリソースの圧迫を防ぎます。この監視間隔はデフォルトでは60秒

です。監視間隔は設定で変更できます。

Session Registry ServerはIJServerワークユニット上で動作します。Session Registry Server用のIJServerワークユニットを作成し、Session Registry Server(srs.ear)を配備します。

■Servletコンテナの処理スレッド縮退機能

Servletコンテナで処理するスレッド数について、以下の設定ができます。

・同時処理数の初期値(増分値)・待機中(アイドル状態)の処理スレッド大値

・同時処理数の大値

処理完了後、待機中となり使用されていない処理スレッドは、１分間隔の監視によって、待機中の処理スレッド大値を超えている分が解放されます。これにより、一時的に負荷がかかった場合、負荷が下がったときにサーバ資源を解放するなど、資源を節約することができます。

■オートリロード機能

サーバへ配備されたWebアプリケーションのクラス(Servlet)ファイルおよびJSPファイルの更新を監視し、Webアプリケーションを再配備するのではなく、配備されたファイルを直接更新された場合にファイルをリロ

ードし、すぐに更新を反映する機能です。

クラスのオートリロードとJSPのリロードを、それぞれ個別に設定できます。

JSPのみ変更した場合、JSPのオートリロードは動作しますが、クラスのオートリロードは動作しないため、IJServerプロセスの資源(クラスの更新監視用スレッド)の節約や、監視対象の削減によるIJServerプロセ

スの処理を軽減できます。

JSPのリロード動作は、「リクエスト時リロード」と「一定間隔監視によるリロード」から選択できます。

オートリロード機能では、deployment descriptor(web.xml)の更新により動作することはありませんが、Servletクラスのオートリロードが実行される際、deployment descriptor(web.xml)も再読み込みされます。そのため、JSPまたはクラスの変更とともにフィルタやリスナ、初期化パラメタなどを設定したdeployment descriptorを入れ替えておくことで、オートリロード後、すぐに情報が反映されます。

オートリロード機能は、更新チェックの負荷が発生するため、アプリケーション開発時のみの利用を推奨します。



2.6.3 Webサーバコネクタによる負荷分散2.6.3 Webサーバコネクタによる負荷分散

■ ijsdispatchcont コマンドによる振り分け指定

Webサーバ


IPアドレス：123.123.123.110

IJServer A apl01

ポート：9000

IJServer B apl02

ポート：9001

停止

IPアドレス：123.123.123.111

IJServer A apl01

IJServer B apl02

故障IJServer（コンテナ）を負荷分散振り分け対象から除外

IPアドレスのみを指定し、マシン単位で振り分け対象から

除外することも可能

■ 故障監視機能

Webサーバ


IPアドレス：172.16.30.10

IJServer A apl01

IJServer B apl02

停止

IPアドレス：172.16.30.11

IJServer A apl01

IJServer B apl02

故障監視機能

：ポート監視（connect 送信)

Interstage管理コンソールで故障監視設定

マシンまたはIJServer（コンテナ）の故障を監視し、監視パケット(ping/connect)の

返答がないものは故障と判断し、自動的に振り分け対象から除外

復旧が確認されたら自動的に振り分け対象に

ijsdispatchcont OFF 123.123.123.110:9000


Point！

Webサーバとアプリケーションサーバ(IJServerワークユニット)を別々のサーバで運用し、同じアプリケーション(Servlet/JSP)が動作するアプリケーションサーバが複数台存在する環境において、Webサーバコネクタは、各IJServerワークユニットに対しリクエスト振り分け制御を行うことができます。(Servlet/JSPアプリケーションは、Servletコンテナを包含したIJServerワークユニット上で動作します。)

Webサーバコネクタから各IJServerワークユニットへのリクエスト振り分けは処理中リクエストがも少ないところに振り分けられます。ただし、Webアプリケーションでセション管理を使用している場合には、セションを生成したIJServerワークユニットと同じIJServerワークユニットに以降のリクエストも振り分けられます。

Webサーバコネクタでは、ネットワーク障害やマシンのハード障害などの場合に当該IJServerワークユニット(または当該マシン)を一時的にリクエスト振り分け対象から外し、保守完了後や障害対処後に振り分け対象に戻すといった運用ができます。

IJServerワークユニットのリクエスト振り分け制御(振り分け対象にする/しない)は、ijsdispatchcontコマンドで指定できます。

■振り分け操作コマンド(ijsdispatchcont)・形式

-----------------------------------------------------------------------------------------ijsdispatchcont ON|OFF IPアドレス[:ポート番号] [-s Webサーバ名]-----------------------------------------------------------------------------------------

IJServerワークユニットをリクエストの振り分け対象にする/しない(ON/OFF)の操作を、IPアドレスまたはIPアドレス:ポート番号で指定します。IPアドレスの指定ではマシンに対する振り分け操作を制御し、IPアドレス:ポート番号の指定では、Servletコンテナに対して振り分けを制御します。振り分け操作コマンドで操作した状態は、Webサーバの再起動後や異常停止後でも保持されます。振り分けの状態を変更したい場合は、再度振り分け操作コマンドを実行します。

また、分散先のIJServerマシンやServletコンテナの稼動状況を監視し、故障したIJServerマシンやServletコンテナを自動的に振り分けの対象から除外することや、故障から復旧したIJServerマシンやServletコンテナを自動的に振り分けの対象に戻す故障監視機能も提供しています。

故障監視機能は、WebサーバのInterstage管理コンソールで、 [システム] > [サービス] >[Webサーバ] > “Webサーバ名” > [Webサーバコネクタ] > [故障監視設定]タブを表示し、設定します。

・ping監視： IJServerマシンの稼動状況をpingで確認します。(IJServerマシン監視)・ポート監視： IJServerマシンの稼動状況をpingで確認すると同時に、connectでServletコンテナの稼動

状況を監視します。(Servletコンテナ監視)



2.7 EJB2.7 EJB


クライアント

J2EEJavaVM

EJBコンテナ

J2SE

■EJBの仕組み

EJB(Enterprise Bean)

JavaApplication

Servlet

JSP

■EJBの３つのモデル

実行環境の定義情報

Session Bean クライアントとの対話処理を実現するオブジェクト

Message-driven Bean メッセージを非同期で受け取ることができるオブジェクト

「STATEFUL Session Bean」・「STATELESS Session Bean」

「BMP Entity Bean」・「CMP Entity Bean」

「Point To Pointモデル」・「Publish/Subscribeモデル」

実行環境定義ファイル

Entity Bean データベースの情報をオブジェクトとして取り出したり、格納したりするためのオブジェクト

EJB(Enterprise JavaBeans)は、分散オブジェクト指向におけるサーバコンポーネントであり、コンポーネント

の「ライフサイクル管理」、「トランザクション管理」、「データベース処理」などのシステムに依存するインタフェースをコンテナで隠ぺいし、ビジネスロジックの処理記述だけでサーバ側のプログラム部品の作成を可能にします。

従来のサーバアプリケーションの開発では、開発者はサーバアプリケーションの本体処理であるビジネスロジック以外にも、ネットワーキングや排他制御などを意識する必要がありましたが、EJBは低レベルなインタフェース

を隠ぺいします。

EJBの構成要素として、ビジネスロジックを実装した部分をEnterprise Beanと呼び、データベース処理、トランザクション処理などのシステムに依存するインタフェースを隠ぺいする部分をEJBコンテナと呼びます。

EJBでは、実行環境定義ファイル(deployment descriptor)に、Enterprise Beanがもつ各種の属性値を指定することができます。実行環境定義ファイルによりEnterprise Beanのソースコードを変更することなく、個々の

環境やニーズに合わせて運用環境をカストマイズできます。

このように、EJBはプラットフォームやミドルウェアに依存しないアプリケーション開発が可能であり、EJBを

利用することにより、開発者は、アプリケーション開発時にビジネスロジック部分の開発だけに専念できます。

Enterprise Beanには、以下の3つのモデルがあります。

■ Session Bean

■ Entity Bean

■ Message-driven Bean



クライアントとの会話を制御するSession Bean

2.7.1 Session Beanの特長と種類2.7.1 Session Beanの特長と種類

■STATEFUL Session Bean と STATELESS Session Beanの違い

EJBアプリケーション起動時クライアントからのcreate要求インスタンスの生成

トランザクション管理の範囲

メソッド間で保持されないメソッド間で保持されるEJBアプリケーションの状態

（変数、トランザクション数など）

１つのビジネスメソッド複数のビジネスメソッド

複数のクライアントで共有クライアントごとに１つインスタンス

STATELESS

Session Bean

STATEFUL

Session Bean比較項目

STATEFUL Session Bean：対話状態を保持する

STATELESS Session Bean：対話状態を保持しないSession Bean

EJBコンポーネントモデルの1つであるSession Beanは、クライアントとの対話処理を行う機能を提供します。対話とは、クライアントからのEnterprise Bean生成依頼であるcreate()メソッドや、ビジネスメソッド、またはEnterprise Bean破棄依頼であるremove()メソッドを呼び出すことを示します。

Session Beanには、STATEFULとSTATELESSの2種類が存在します。

STATEFUL/STATELESSの指定は、EJBアプリケーションの開発時に指定します。

■STATEFUL

・ 1トランザクション内で複数メソッドの処理が可能です。

・変数、トランザクションなど、対話中のEJBアプリケーションの状態を保持します。

・クライアント1個に対し、EJBアプリケーションのインスタンスは1個です。

・ EJBアプリケーションのインスタンスは、クライアントからのcreate要求により生成されます。

■STATELESS

・対話中のEJBアプリケーションの状態は保持されません。

・ EJBアプリケーションのインスタンスはEJBアプリケーション起動時に生成されます。

・クライアントｎ個に対してEJBアプリケーションのインタンスはｎ個以下を設定できます。

・ 1メソッドを１トランザクションで処理します。

・ EJBアプリケーションのインスタンスを少なくできる分、STATEFULに比べて、メモリ消費量が少ないという利点があります。



データの永続性(データベース）を制御するEntity Bean

EJBサーバ

EJBコンテナ

2.7.2 Entity Beanの特長と種類2.7.2 Entity Beanの特長と種類


DB DB

■BMP Entity Bean ■CMP Entity Bean

JDBC JDBC

アプリケーションにSQLなど記述しデータ操作

BMP Entity Bean：アプリケーションでデータ操作を制御

CMP Entity Bean：コンテナでデータ操作を制御

Entity Bean

EJBサーバ

EJBコンテナ


EJBコンテナがデータ操作

Entity Beanは、業務データ(顧客情報、注文情報など）を表現するオブジェクトです。Entity Beanのクラスは、リレーショナルデータベースのテーブルに、Entity Beanのインスタンスは、そのテーブル内の行(レコード)に、それぞれマッピングされます。

Entity Beanは、以下のような特長があります。

■Entity Beanの状態はデータベースのレコードとしてディスクに保存されるため、永続性があり、システ

ムの異常やサーバ停止でも消滅しません。

■Entity Beanは複数のクライアントから共有され、同時にアクセスされることがあります。この場合、データの整合性保証は、トランザクション管理により実現されます。

■Entity Beanはそれぞれ一意なオブジェクト識別子(Primary Key)をもっています。この識別子によって、クライアントが特定のEntity Beanを検索できます。

Entity BeanにはBMPとCMPの2種類があり、それぞれ以下のような特長があります。

■BMP (Bean-managed persistence)EJBアプリケーションにデータベース操作文を発行する処理を記述することにより、EJBアプリケーショ

ンがデータを永続化します。アプリケーションの処理状況に応じたきめ細かいデータベース管理ができます。

■CMP (Container-managed persistence)CMPには、CMP1.1とそれを拡張したCMP2.0が提供されています。

CMP1.1では、コンテナがデータを永続化します。EJBアプリケーション自身にデータベース操作文を記述することなく、データベースにアクセスすることが可能です。EJBアプリケーションにデータ操作文

を記述する必要がないため、ポータビリティが高いアプリケーションを容易に開発することが可能です。


CMPのデータ操作では以下のSQL機能を使用できます。

・テーブル操作のSQL処理（SELECT、INSERT、UPDATE、DELETE）

・データの永続性フィールドとデータベースのカラムが１対１であるテーブル操作

・検索条件はWHERE/ORDER BY句だけ

CMP2.0では、CMP1.1の機能に加え、Entity Beanが別のEntity Beanとの関係を保持する機能を備えたことにより、CMP1.1と比べてはるかに複雑化したデータをEntity Beanに関連づけることができます。また、CMP2.0を使用することでデータベースのテーブル間のマッピングや、データベースへのSQLクエリおよびEJB QLなどに対する可搬性が向上します。



メッセージングをEJBで実現するMessage-driven Bean

2.7.3 Message-driven Beanの特長2.7.3 Message-driven Beanの特長

JMSアプリケーション

JMSDestination

ブラウザ

EJBサーバ

EJBコンテナ

Point-To-Pointモデル：1対1のメッセージングモデル

Publish/Subscribeモデル：複数受信者の1対nのメッセージング

Message-driven Bean

Message-drivenBean

Webサーバ

Webコンテナ

Message-driven Beanは、EJB2.0規約から追加されたEnterprise Beanです。Message-driven Beanは、JMSメッセージを受信して処理するオブジェクトであり、JMSの受信メッセージをEJBアプリケーションで処理できます。コンテナは、JMSのメッセージを受信してからMessage-driven Beanのイン

スタンスにマッピングを行い、ビジネスロジックを実現します。

メッセージは、Message-driven Beanに記述されたonMessageメソッドで処理します。

Message-driven Beanは、以下のJMSメッセージングモデルを実現しており、それぞれのモデルには、

以下の特長があります。

■Point-To-Pointモデル

特定の受信者に対してメッセージを配信する１対１のメッセージングモデルです。

■Publish/Subscribeモデル

複数の受信者に対して同一のメッセージを配信する1対nのメッセージングモデルです。

Message-driven Beanが起動していない状態でDestinationに送信されたメッセージをJMSが保持し、Message-driven Beanが起動した後にメッセージを受信できるdurable Subscription機能を使用で

きます。



EJB2.0の規約に準拠

CMP2.0の複数件検索時の高速化

複数レコードの一括更新

SQL文のキャッシュ

ローカル呼び出し機能

トランザクション制御

時間監視機能

2.8 EJBサービス2.8 EJBサービス

EJBサービスとは、Interstageが提供するサービスの1つであり、EJBの考え方をベースとしたサーバアプリケーションを実行するための実行環境です。EJBサービスは、EJB2.0規約に準拠しています。また、サーバ/クライアント間の通信形態として、RMI over IIOPを採用しているため、RMIの規約でアプリケー

ションを開発することが可能です。

EJBサービスでは以下の機能を提供しています。

■CMP2.0の複数件検索時の高速化

■複数レコードの一括更新

■SQL文のキャッシュ

■ローカル呼び出し機能

■トランザクション制御

■時間監視機能



2.8.1 処理性能を向上させる機能2.8.1 処理性能を向上させる機能

複数レコードの一括更新

Statementキャッシュ機能

・複数レコードの一括更新でトランザクション中に同一のCMP Entity Beanに対して複数回更新するデータベースへのアクセス回数を削減

・データベース(Oracle/Symfoware)に発行するSQL文をEJBサービス内部でキャッシュし、SQL文の準備に必要な処理を削除

CMP2.0の複数件検索時の高速化

・すべてのデータをデータベースからロードするような処理の場合に、Primary Keyだけでなく、すべてのカラムデータを一括で検索するSQL文を実行し、SQL文の発行回数を削減

EJBサービスでは、処理性能を向上させる方法として、以下の機能を提供しています。

■CMP2.0の複数件検索時の高速化すべてのデータをデータベースからロードするような処理の場合に、Primary Keyだけでなく、すべてのカラムデータを一括で検索するSQL文を実行し、SQL文の発行回数を削減するオプションです。この

機能は、以下のようなメソッド実行時に有効です。

・CMP2.0 Entity Beanの複数件finderメソッド・1:多 relationshipのCMRに対するgetアクセッサメソッド・多:多 relationshipのCMRに対するgetアクセッサメソッド

※CMR：CMP2.0の定義情報の一つで、データベースのテーブル間を関連付けます。データベースのテーブルとテーブルの間の関係を、relationship(リレーション)と呼び、relationshipフィールドをCMR(Container managed relationship)と呼びます。

■複数レコードの一括更新

EJBコンテナは、トランザクションで同一のCMP Entity Beanに対して複数回更新する場合に、複数

レコードを一括更新することでデータベースへのアクセス回数を削減し、処理性能を向上しています。

■Statementキャッシュ機能

以下の場合に、Statementキャッシュ機能を使用できます。

・データベースタイプが“Oracle”で、データソースの種類が“Oracleのコネクションプーリングを使用する”

の場合この場合、Oracle10gのStatementキャッシュ機能が使用可能になります。なお、“Oracleのコネクションプーリングを使用する”データソースでは分散トランザクションが使用でき

ないため、本機能は分散トランザクション環境では使用できません。

・データベースタイプが“Symfoware”で、データソースの種類が“Interstageのコネクションプーリングを

使用する”の場合

Statementをキャッシュすることによって、SQL文の解析、作成によるオーバヘッドの軽減や、データ

ベースとの通信回数を削減する効果があります。



DBDB

2.8.2 トランザクション制御2.8.2 トランザクション制御

トランザクション管理種別“Bean”の例トランザクション管理種別“Container”の例

【トランザクション属性】

none：トランザクションが開始されていない状態

T1：呼び出し元で開始したトランザクションで動作している状態

T2：呼び出し先で開始したトランザクションで動作している状態

error：エラーが発生

コンテナ

処理の流れ

コンテナ

処理の流れ

クライアントクライアント

トランザクション管理種別“Bean”

呼び出し元でトランザクションを制御

UserTransaction.begin() _1EntityBean1の呼び出し _2EntityBean2の呼び出し _4UserTransaction.commit() _6

Session Bean1

{･･･getConnection()･･･DBアクセス _3}

Entity Bean1

{･･･getConnection()･･･DBアクセス _5}

Entity Bean2

UserTransaction.begin()findByPrimaryKey(...)updateMethod(...)UserTransaction.commit()

Session Bean2（更新専用）

findByPrimaryKey(_);{//検索結果･･･return XXX;}void updateMethod(_){//更新処理･･･Return XXX}

Entity Bean1

//条件検索findByPrimaryKey(...)

Session Bean1（検索専用）

呼び出し元のトランザクションを利用

トランザクション属性“Required”

コンテナが起動したトランザクションを利用

ErrorT1

T1T1

T2T1

T1T1

T1T1

noneT1

nonenoneNever

errornoneRequiresNew

T2noneRequiresNew

nonenoneSupports

T2noneRequired

nonenoneNotSupported

呼び出し先トランザクション状態

呼び出し元トランザクション状態

呼び出し先で指定したトランザクション属性

EJBサービスが提供するトランザクション制御を使用すると、トランザクション管理種別やトランザクション属性を定義することにより、トランザクションの制御方法や実行時の制御内容などを定義することができ、アプリケーションの特性に応じたトランザクション処理を行うことができます。

トランザクション管理種別には、“Bean”と“Container”の2つがあり、EJBアプリケーションごとに定義します。

■BeanUserTransactionインタフェースを使用して、EJBアプリケーションがトランザクションを制御します。トランザクション管理種別として”Bean”を指定できるのは、Session BeanとMessage-driven Beanです。

■Containerコンテナがトランザクションを制御します。EJBアプリケーションにトランザクション処理の記述をしなくてよいため、EJBアプリケーションのポータビリティが向上します。

Container管理種別では、実行時のトランザクション制御内容を “トランザクション属性”で指定します。

・トランザクション属性

－Mandatory：つねに呼び出し元で開始されているトランザクションで実行されます。

－Required：つねにトランザクションが開始された状態で実行されます。呼び出し元でトランザクションが開始されていない場合、コンテナがトランザクションを開始します。

－Supports：呼び出し元でトランザクションが開始されている場合は、呼び出し元のトランザクションを実行します。トランザクションの一貫性・整合性が保たれない可能性があるため、推奨されていません。

－RequiresNew：コンテナがトランザクションを実行します。呼び出し元でトランザクションが開始されている場合は、コンテナが呼び出し元のトランザクションを中断し、コンテナのトランザクションが完了後、呼び出し元トランザクションを再開します。

－NotSupported：つねにトランザクションが開始されていない状態で実行されます。呼び出し元でトランザクションが開始されている場合、コンテナが、そのトランザクションを中断し、処理が終了した後、コンテナは、中断していた呼び出し元のトランザクションを再開します。

－Never：つねにトランザクションが開始されていない状態で実行されます。呼び出し元でトランザクションが開始されている場合、呼び出し元に例外が返却されます。



アプリケーションの大処理時間の時間監視機能

2.8.3 時間監視機能2.8.3 時間監視機能

・EJBアプリケーションの無限ループを検出－アプリケーションが存在するプロセスを強制停止する設定の場合

・サーバのシステムログに以下のメッセージを出力[extp: エラー: EXTP4704: アプリケーションの処理時間が監視時間を超過しました]

・クライアントに以下の例外を通知[java.rmi.RemoteException:CORBA UNKNOWN]

－アプリケーションが存在するプロセスを強制停止しない設定の場合・サーバのシステムログに以下のメッセージが出力

[extp: 警告: EXTP4705: アプリケーションの処理時間が監視時間を超過しました]・クライアントには通知なし

STATEFUL Session Beanの無通信監視機能

EJB objectのタイマ削除機能

・プロセス外から呼び出された（生成された）Entity BeanのEJB objectに対して、終アクセスから一定時間後に、放置されたEJB objectのインスタンスを削除

・STATEFUL Session BeanのEJB objectに対して、一定時間超過してもビジネスメソッドが実行されなかった場合、コンテナが該当のインスタンスと対応するEJB objectを削除

EJBサービスでは、以下の時間監視機能を使用できます。

■EJBアプリケーションの大処理時間の時間監視機能

EJBアプリケーションの無限ループを検出できます。この機能は、IJServerを利用して、アプリケー

ションを動作させる場合に使用できます。

サーバ処理中にアプリケーションの大処理時間を超過した場合の処理について説明します。

・アプリケーションが存在するプロセスを強制停止する設定の場合プロセスが強制停止され、トランザクション処理中の場合は、ロールバックされます。また、サーバのシステムログにメッセージを出力し、クライアントに例外を通知します。

・アプリケーションが存在するプロセスを強制停止しない設定の場合プロセスは強制停止されません。サーバのシステムログにメッセージを出力し、クライアントには何も通知しません。

アプリケーションの大処理時間、および大処理時間を超過した場合にアプリケーションが存在するプロセス強制停止をするかしないかは、Interstage管理コンソールの

［ワークユニット］ > ［IJServer名］ > ［環境設定］ > ［ワークユニット設定］の「アプリケーション大処理時間」、「アプリケーション大処理時間超過時の制御」でIJServerワークユ

ニット単位に設定します。

■STATEFUL Session Beanの無通信監視機能

STATEFUL Session BeanのEJB objectに対して、一定時間超過してもビジネスメソッドが実行されなかった場合、コンテナが該当のインスタンスと対応するEJB objectを削除する機能です。この機能を使用することによって、ejbRemoveメソッドを発行し忘れている不要なEJB objectが削除されるため、使用

するメモリの適化ができます。

STATEFUL Session Beanの無通信監視機能は、Interstage管理コンソールの

［ワークユニット］ > ［IJServer名］ > ［EJBアプリケーション］ > ［アプリケーション環境定義］ >［Interstage拡張情報］の「無通信監視時間」でEJBアプリケーション単位に設定します。


■EJB objectのタイマ削除機能

Entity Beanは、通常removeメソッドが発行されないBeanであるため、Entity Beanをプロセス外から呼び出した場合、create/finderメソッドにより生成されたEJB objectのインスタンスがメモリ上に残存し

ます。

このような状況の発生を防ぐために、Entity Beanへの終アクセスから一定時間後に、放置されたEJB objectのインスタンスを削除する機能を提供します。

EJB objectのタイマ削除機能は、プロセス外から呼び出されるEntity Beanで有効です。

Entity Beanをプロセス内で呼び出した場合は、以下のタイミングでEJB objectがJavaのガーベジ

コレクションの対象となり、自動的に削除されます。

・Entity Beanを呼び出すBeanがremoveされたとき

・Entity Beanを呼び出すBean(Session Beanの場合）のSTATEFUL Session Beanの無通信監視機能でタイムアウトが発生したとき

・Entity Beanを呼び出すBean（Entity Beanの場合）のEJB objectのタイムアウトが発生したとき

EJB objectのタイマ削除機能は、Interstage管理コンソールの

［ワークユニット］ > ［IJServer名］ > ［EJBアプリケーション］ > ［アプリケーション環境定義］ >［Interstage拡張情報］の「EJB objectタイムアウト値」でEJBアプリケーション単位に設定します。



分散オブジェクト通信の基盤技術

ORB

2.9 CORBA2.9 CORBA

クライアントアプリケーション

サーバアプリケーション

ネーミングサーバ

インタフェースリポジトリインプリメンテーション

リポジトリ

ネーミングサービス

BOA

IDLファイル

スタブスケルトンスケルトン

サーバクライアント

スタブ

IDLコンパイラ

(インタフェース定義)

インタフェース情報登録

CORBAとは、ネットワーク接続された複数のコンピュータ上にある分散されたソフトウェアが互いの物理的な配置を考慮することなく、通信して連携するために、OMG(Object Management Group：オブジェクト指向技術の標準化と普及を目的として1989年に設立された非営利団体)によって標準化が行われている技術です。CORBAを利用することで、プラットフォームにもプログラミング言語にも依存しない分散オ

ブジェクト環境を構成できます。

クライアントからの要求はORB（Object Request Broker）によってネットワーク上の異なるシステムで動作するアプリケーションに転送されます。ORBとは、オブジェクトがほかのオブジェクトと通信する際に使

用する共通インタフェースの総称であり、クライアントオブジェクトからのリクエストを適切なサーバに伝える仲介役です。クライアントオブジェクトとサーバオブジェクトは、つねにORBを経由し、ORBの先がどのようになっているかはすべてORBに任されます。ORBは、分散システムの各コンピュータ上に個々に分散し

て存在しており、アプリケーションのバックグラウンドで通信しています。

ORBを利用した通信は次のような手順で行われます。

1. クライアントオブジェクトは、リクエストを送信する相手がローカルなマシン上に存在するのか、ネット

ワーク上に存在するのかを意識することなくリクエストを送信します。

2. リクエストを受信したORBは、ローカルマシン上に該当するサーバオブジェクトが存在する場合は、そのオブジェクトにリクエストを送信します。存在しない場合は、ネットワーク上のORBにリクエストを送信し

ます。

3. ORBの機能の一つであるBOA（Basic Object Adapter）は、ORBに登録されているサーバオブジェ

クトが活性状態にあるか非活性状態にあるかを知っており、必要に応じてサーバオブジェクトを活性化するなど、サーバオブジェクトの活性状態／非活性状態を管理しています。

4. クライアントからのリクエストはすべてBOAに渡され、BOAはサーバオブジェクトが活性状態にあること

を確認し、リクエストをサーバオブジェクトに送信します。


CORBAアプリケーションの構築/運用では、以下の定義ファイルおよびコンポーネントが利用されます。

■IDLファイル

IDL(Interface Definition Language)とは、言語やOSに依存しないインタフェース定義を行うためのイ

ンタフェース定義言語です。

IDLにより、サーバアプリケーションが提供するインタフェースを定義できます。

■インタフェースリポジトリ

インタフェースリポジトリとは、オブジェクトのインタフェース情報を一括して管理するデータベースです。

通常、IDLファイルをもとに、IDLコンパイラによりサーバオブジェクトのインタフェース情報がインタ

フェースリポジトリに登録されます。

スタブ・スケルトンが静的なインタフェース情報を提供するのに対して、インタフェースリポジトリは動的なインタフェースを提供します。

■スタブ・スケルトン

スタブ・スケルトンとは、IDLコンパイラにより生成されるクライアント・サーバ用の通信用ライブラリです。

スタブ・スケルトンは、アプリケーションと結合されて静的なインタフェースを提供します。

■インプリメンテーションリポジトリ

インプリメンテーションリポジトリとは、サーバアプリケーション内でのアプリケーションの格納位置(パス名)、サーバアプリケーションの開発言語、サーバタイプなどのサーバアプリケーション自身の情報を格納するデータベースです。

インタフェース情報の制御には、静的と動的の２つ方法が提供されています。

■静的なインタフェース

呼び出すサーバオブジェクトのインタフェース(メソッド)が既知の場合に用いられ、メソッド呼び出しが高

速に行えます。

■動的なインタフェース

クライアントの実行時に動的にインタフェースの結合が行われ、サーバ側でサービスの追加などが行われても柔軟に対応できます。



CORBAサーバアプリケーションの実行環境を提供

2.10 CORBAサービス2.10 CORBAサービス

クライアント運用形態：プレインストール型(すべての開発言語で使用可能)

InterstageサーバInterstageサーバ

CORBAサービス/EJBサービス

Servletサービス

Webサーバ

ワークユニットワークユニット

JavaアプレットJavaアプレット


CORBAクライアント/EJBクライアント Webブラウザ


InterstageサーバInterstageサーバ

CORBAサービス/EJBサービス

Servletサービス

Webサーバ

ワークユニットワークユニット



CORBAクライアント(Portable-ORB)/EJBクライアント

Webブラウザ




CORBAサーバアプリケーション

CORBAサーバアプリケーション

クライアント運用形態：Portable-ORB(Java言語で使用可能)

CORBAアプリケーションは、CORBAサーバアプリケーションとCORBAクライアントで構成されます。

CORBAアプリケーションは、Java／C／C++／COBOLを使用して作成することができます。

CORBAサーバアプリケーションの実行環境はCORBAサービスで提供されます。

CORBAクライアントの運用には、以下の2つの形態があります。

■プレインストール型 (すべての開発言語で使用可能)あらかじめクライアントマシンにクライアントランタイム(CORBAサービスクライアント)をインストールして、

運用する形態です。プレインストール型は、すでにクライアントマシンにインストールされているため、実行時にクライアントランタイムをダウンロードするための時間はかかりません。

■Portable-ORB (Java言語だけ使用可能)あらかじめサーバマシンにクライアントランタイム(Portable-ORB)をインストールして、実行時にサーバマシン(Webサーバ)からアプレットとともにクライアントランタイム(Portable-ORB)をダウンロードして、運用する形態です。Portable-ORBは、個々のクライアント端末に事前にJavaランタイムをインストール

する必要がないため、クライアントの運用・保守コストを削減できます。



2.10.1 CORBAアプリケーション運用時のタイマ監視

2.10.1 CORBAアプリケーション運用時のタイマ監視

１．クライアントアプリケーションからリクエストの発行

２．リクエストの送信（コネクションの確立）

３．サーバメソッドの起動（Persistentタイプ以外）

４．CORBA_ORB_initメソッドの発行

５．サーバメソッドの復帰

６．コネクションの切断

クライアントサーバ

クライアント

アプリケーション

CORBAサービス

CORBAサービス

サーバメソッド

１ 23

4

5

6

T1

T4

T2

T3

×

・・

T1：period_receive_timeoutT2：period_server_timeoutT3：period_idle_con_timeoutT4：period_client_idle_con_timeout

CORBAサービスは、アプリケーションのハングアップなどを防ぐため、アプリケーションの稼動状況を監視するためのタイマ監視機能を備えています。クライアント/サーバアプリケーションの動作中に、設定され

たタイムアウト時間に応じてタイムアウトを発生させ、アプリケーションに通知します。CORBAサービスでは、以下のタイムアウト時間を設定できます。

■period_receive_timeoutクライアントにおける、リクエスト送信(サーバメソッド発行)から返信までの待機時間です。サーバメソッド

からの返信がないまま、この時間を経過すると、クライアントアプリケーションにタイムアウトが通知されます。

■period_server_timeoutサーバにおける、サーバメソッド起動からCORBA_ORB_initメソッド(ORB初期化メソッド：C言語インタフェースのメソッド名)発行までの監視時間です。CORBA_ORB_initメソッドが発行されずにこの時間を経過すると、クライアントにNO_IMPLEMENT例外(サーバメソッド未実装を意味)が通知されます。

このタイムアウト時間は、サーバにおいて、クライアントから要求があった時点でサーバアプリケーションを自動起動する設定が行われている場合に限り有効です。

■period_idle_con_timeoutサーバにおける、無通信状態(クライアントからのリクエスト送信なし)の監視時間(リクエスト返信完了後のコネクション維持時間)です。この時間を超えてもクライアントからのリクエスト送信がない場合、クライ

アントとのコネクションを切断し、リクエスト処理に使用したメモリ資源を解放します。

■period_client_idle_con_timeoutクライアントにおける、無通信状態(サーバへのリクエスト送信なし)の監視時間(リクエストの復帰完了後のコネクション維持時間)です。この時間を超えてもサーバへのリクエスト送信がない場合、次回のリクエ

スト送信時には、サーバとのコネクションの切断・再接続後にリクエストを送信します。

CORBAアプリケーション運用時のタイマ監視は、CORBAサービスの動作環境ファイル(config)で設定

します。



Web技術によりアプリケーションの機能をネットワーク経由で利用

SOAP

2.11 Webサービス2.11 Webサービス

WSDL

UDDIレジストリ

サービス利用者サービス提供者

Webサービス

①サービスの登録・公開

②サービスの検索

③インタフェース情報の取得

④Webサービス

の利用

Webサービスとは、インターネット上で公開されるサービス全般を示します。Webサービスの世界では、

サービスが動的に相手を発見し、接続できるようになることを目指しています。その目標を目指して、UDDI、WSDL、SOAPなど、さまざまな技術が作成/使用されています。

現在、Webサービスの流れとして考えられている代表的な形態は、以下のようになります。

1. Webサービス提供者がUDDIレジストリのサービス内容、サービス提供場所を登録する。

2. サービス利用者は、UDDIレジストリに接続し、利用したいサービスを検索する。

3. 「2.」で利用したいサービスが見つかった場合は、そのサービスのインタフェース情報、サービス提供

元の場所を取得する。

4. 「3.」で取得したサービス提供元へアクセスし、Webサービスを利用する。

これらのWebサービスを使用するためのデータ通信には、SOAPプロトコルが使用されます。



WSDLのおもな要素

2.11.1 WSDL2.11.1 WSDL

wsdl:definitions要素

wsdl:types要素

wsdl:message要素

wsdl:portType要素

wsdl:operation要素

wsdl:binding要素

wsdl:service要素

wsdl:port要素

wsdl:binding要素で定義されたバインディングに、通信エンドポイントの具体的なネットワークアドレスを関連付けます。

wsdl:port要素

wsdl:port要素で定義したポートのうち、関連するポートをひとまとめにして、サービスを定義します。

wsdl:service要素

抽象的な操作や抽象的なメッセージを、具体的なプロトコルや具体的なメッセージにバインドします。

wsdl:binding要素

抽象的な操作（メソッド）を定義します。その操作を呼び出すための入力メッセージと、処理結果を返すための出力メッセージ、エラー情報を通知するためのフォルトメッセージという3種類のメッセージで構成されます。

wsdl:operation要素

抽象的な操作の集合を定義します。wsdl:portType要素

Webサービスで使用する入出力メッセージやフォルトメッセージのフォーマットを抽象的に定義します。

wsdl:message要素

おもにユーザ定義の型を使用する場合など、メッセージのフォーマットを定義する際に使用する型を抽象的に定義します。省略可能です。

wsdl:types要素

WSDLの上位要素を表します。WSDL内で使用する名前空間を定義します。

wsdl:definitions要素

説明WSDL要素

WSDLは、Webサービスのインタフェースを定義するXMLベースの言語です。

Webサービス提供者は、WSDLに、Webサービスのインタフェースや提供している場所、実行方法などを記述し、UDDIにそのWSDLのURLを登録しておきます。

Webサービス利用者は、UDDIを検索し、そこで得たWSDLから目的のWebサービスの情報を取得し、Webサービスへ接続し、実行するためのアプリケーションを作成することができるようになります。また、Interstage Studioなどの開発ツールでは、WSDLを読み込むことで、提供されているWebサービスを呼

び出すためのソースコードの雛形を自動で生成することができます。

WSDLは、おもに以下の要素によって構成されています。

■wsdl:definitions要素WSDLの上位要素です。WSDL内で使用する名前空間を定義します。

■wsdl:types要素wsdl:message要素で使用する型を抽象的に定義します。

■wsdl:message要素

入出力メッセージやフォルトメッセージのフォーマットを抽象的に定義します。wsdl:typesで定義された型は、ここで使用します。

■wsdl:portType要素抽象的な操作(wsdl:operation要素)の集合を定義します。Javaにおけるインタフェースに相当します。

■wsdl:operation要素抽象的な操作(メソッド)を定義します。その操作を呼び出すための入力メッセージと、処理結果を返す出力メッセージ、エラー情報を通知するためのフォルトメッセージの3種類で構成されます。

■wsdl:binding要素抽象的な操作(wsdl:operation要素)や抽象的なメッセージ(wsdl:message要素)を、具体的なプロトコ

ルや具体的なメッセージに結び付けます。

■wsdl:service要素wsdl:port要素で定義したポートのうち、関連するポートをひとまとめにして、サービスとして定義します。

■wsdl:port要素wsdl:binding要素で定義されたものに、通信エンドポイントの具体的なネットワークアドレス(URL)を関

連付けます。



Web Services for J2EE

2.11.2 Webサービスの標準規約2.11.2 Webサービスの標準規約

Webサービスの相互運用性の向上を目的とした組織

Basic Profile 1.0

UDDI 2.0

SOAP 1.1

WSDL 1.1

セキュリティ適合要件を定義

主要Webサービス・

ベンダによるサンプルも提供

富士通は国内ベンダ唯一のWS-I設立メンバ/

ボードメンバ

XML 1.0

WS-I（Web Services Interoperability Organization）

■JAX-RPC（Java API for XML-based RPC）JavaでXML リモート・プロシージャ・コール（RPC）を行うための基盤とAPIを提供。RMIに対して、Webサービスでの利用のためXMLでRPCを実現しているのが特徴。

■SAAJ（SOAP with Attachment API for Java）JavaでSOAPによる通信を行うための基盤とAPIを提供。ファイルの添付された SOAP メッセージの作成を支援。

APIを提供するWeb Services for J2EE／相互接続推進組織のWS-I

現在、Webサービスは以下の標準規約で構成されています。

■Web Services for J2EE 1.1Webサービスアプリケーション、およびWebサービスクライアントで利用するAPI/deployment descriptor/モジュールの構成物など、J2EEにおけるWebサービスのアプリケーション作成方法や配備処理について規定したものです。本規約で、WebアプリケーションやEJBアプリケーションと同様に、Webサービスアプリケーションを標準に従った方法で開発可能になり、また、同じ仕様に準拠した製品への配備ができます。

APIには、JAX-RPC1.1およびSAAJ1.2を使用します。

・JAX-RPC 1.1Webサービスアプリケーション、およびWebサービスクライアントを実装するためのJavaの標準APIです。Webサービスでの利用のためXMLでRPCを実現しているのが特徴であり、JavaでXML リモート・プロシージャ・コール（RPC）を行うための基盤とAPIを提供しています。また、通信プロトコルにはSOAPが使用されます。

Ver.1.1からWS-I Basic Profile 1.0に対応しています。

・SAAJ 1.2Webサービスで送受されるSOAPのメッセージ内容を、XMLレベルで参照/更新するJavaの標準APIです。SOAPの添付ファイルの参照/更新も可能です。Ver.1.2からXML部分をDOMとしても利用できます。

また、API以外にも相互接続性向上のための規約もあります。

■WS-I Basic Profile 1.0Webサービスの標準仕様であるSOAP/WSDL/UDDI、および同時に用いられるHTTPなどの仕様について、Webサービスとしての相互接続性向上の観点から以下のように詳細化・制約付加を規定した規約です。

・仕様上曖昧な点の明確化

・仕様上許されるが使用すべきでない機能の規定(使用すべき範囲の限定)



2.12 Interstage Webサービス2.12 Interstage Webサービス

＊ WS-I BP：世界160社によるWebサービスの相互接続推進団体(WS-I)が規定したガイドライン

Interstage Webサービス（オープンソースのAxis1.3を採用）

WS-I Basic Profile

Web Services for J2EE 1.1 JAX-RPC SAAJ

WebサービスでのSOAP/UDDI/WSDLおよび

HTTP仕様についてのガイドライン

Webサービス Interstage Application Server

メインフレーム

既存資産

データベース

Interstage Webサービス

.NET

OSS

他社ベンダ

Webサービスクライアント


Webサービスアプリケーション


WS-I BP(*)で接続

Interstage Application Serverは、SOA適用システムの基盤としてサービスの構築・運用・連携を支援します。

SOA／ESBのコア技術であるWebサービスについて、WS-I Basic Profileに対応したアプリケーションをJ2EE1.4の標準にしたがって容易に開発・運用可能になり、ポータビリティのあるサービス開発およびサービス間連携の相互接続性を確保します。これにより、.NETシステムなどとの接続性が大幅に向上し、

通信オプションなど事前の接続仕様の調整や接続確認のためのコストを削減できます。

また、Interstage管理コンソールによるWebサービスの環境設定、アプリケーション配備、そしてWebサービスアプリケーションの処理時間などのモニタリングによる可視化を実現しており、実用的で使いやすいWebサービスを実現できます。



2.12.1 Webサービスのコンポーネント2.12.1 Webサービスのコンポーネント


Webサービスも管理コンソールの共通操作ビューで可能

Webサービスアプリのモニタ

アプリケーション管理機構の作成・削除・起動・停止

Webサービスアプリの配備/配備解除

IJServer

Webサービス


Servletコンテナ

Servletコンテナ

Webサービスアプリケーション

EJBコンテナ

Webサービス


Webサービス


【 iswsgen のサブコマンドと生成ファイル】

client

WSDLファイルwsdl

サービスエンドポイントインタフェースソース、サービスインタフェースソース、ユーザ定義型クラスソース、そのほかのクラスソース

サービスエンドポイントインタフェースソース、ユーザ定義型クラスソース、そのほかのクラスソース、<WSDLファイル名>_mapping.xml

server

生成ファイルサブコマンド

Interstage Webサービスでは、以下のコンポーネントから構成されています。

■Webサービスサーバ(Webサービスを提供する)機能

JAX－RPCに準拠したWebサービスアプリケーションをIJServerに配備することで、SOAPを利用して呼び出し可能なWebサービスを構築できます。提供するWebサービスのインタフェース情報としてWSDLも生成します。

■Webサービスクライアント(Webサービスを利用する)機能

SOAPを利用してWebサービスを利用する(呼び出す)、JAX-RPCに準拠したWebサービスクライアントアプリケーションを開発・運用できます。

■Webサービス開発コマンド(iswsgen)サービスエンドポイントインタフェースやWSDLファイルから、WebサービスアプリケーションおよびWebサービスクライアントの開発資産(Serviceインタフェース、実装クラス、および定義ファイル)を自動生成

します。指定されるサブコマンドごとに、それぞれ異なるファイル生成コマンドとして動作します。ファイルなどが自動生成されることで、利用者は効率的な開発ができます。iswsgenコマンドで指定するサブコマンドは、以下になります。

・wsdlサービスエンドポイントインタフェースから、WSDLファイル、およびWebサービスアプリケーション開発

に必要な以下のファイルを生成します。

－ WSDLファイルWebサービスのインタフェース定義ファイルです。出力先のWEB-INF/wsdlディレクトリ配下に生成されます。ファイル名は-wsdlFileオプションで指定できます。WSDLのPortType要素の名前は、サービスエンドポイントインタフェース名が使用されます。

－ <WSDLファイル名>_mapping.xmlWebサービスアプリケーションとしてパッケージする際に、アプリケーションとともにパッケージングするファイルです。プロトコル(SOAP)で使用するXMLとアプリケーションの対応付けが記述されます。出力先のWEB-INFディレクトリ配下に生成されます。


・serverWSDLファイルからWebサービスアプリケーション開発に必要な以下のファイルを生成します。

－サービスエンドポイントインタフェースソースWebサービスとして提供するWebサービスアプリケーションの公開インタフェースを定義するJavaインタフェースのソースです。インタフェース名はWSDLのPortType要素の名前が使用されます。

－ユーザ定義型クラスソースWSDLのoperationのパラメタとしてユーザ定義型が指定されている場合に、対応するJavaクラスソー

スを生成します。クラス名はユーザ定義型の型名が使用されます。

－そのほかのクラスソースアプリケーションの実行に必要なクラスのソースです。生成するJavaソースファイルに応じて必要なものが生成されます(WSDLの内容によって生成される場合と、生成されない場合があります)。クラス名はすべて“_isws_”で始まります。

－ <WSDLファイル名>_mapping.xmlWebサービスアプリケーションとしてパッケージする際に、アプリケーションとともにパッケージングするファイルです。プロトコル(SOAP)で使用するXMLとアプリケーションの対応付けが記述されます。出力先のWEB-INFディレクトリ配下に生成されます。

・clientWSDLファイルからWebサービスクライアント開発に必要な以下のファイルを生成します。

－サービスエンドポイントインタフェースソースWebサービスとして提供するWebサービスアプリケーションの公開インタフェースを定義するJavaインタフェースのソースです。インタフェース名はWSDLのPortType要素の名前が使用されます。

－サービスインタフェースソースWSDLファイルに記述されたWebサービスを表すJavaインタフェースのソースです。Webサービスアプリケーションのスタブを取得できます。インタフェース名はWSDLのService要素の名前が使用されます。

－ユーザ定義型クラスソースWSDLのoperationのパラメタとしてユーザ定義型が指定されている場合に、対応するJavaクラスソース

を生成します。クラス名はユーザ定義型の型名が使用されます。



Webサービスの実行環境

IJServer

2.12.2 Webサービスの運用方法2.12.2 Webサービスの運用方法


IJServer

Webサービス


Servletコンテナ

Servletコンテナ

WebサービスアプリケーションEJBコンテナ

同一VM設定のIJServerの

Servletコンテナ上でWebサービスを提供

Webサービス


Webサービス


Webサービスクライアントアプリケーション

(Javaアプリケーション)


・同一VM運用コンテナのWebサービス機能を有効にする

・同一VM運用以外isws.jarをクラスパスに設定

・isws.jar、isws-lib.jarをクラスパスに設定

Webサービスは、以下の方法で運用します。

■Webサービス（サーバ機能）の運用方法Webサービスアプリケーションは、Interstage管理コンソール、またはコマンドを使用して運用操作を行

います。

・実行環境Webサービスアプリケーションは、 IJServerのServletコンテナ上で動作します。また、選択できるIJServerのタイプは「WebアプリケーションとEJBアプリケーションを同一JavaVMで運用」だけとなり

ます。

・アプリケーションの配備/配備解除Webサービスアプリケーションを含むWAR/EARを、IJServerに配備します。

・公開用WSDLの取得IJServerにWebサービスアプリケーションを配備すると、そのWebサービスの公開用WSDLを取得できます。公開用WSDLは、配備後にInterstage管理コンソールのワークユニット > “IJServer名” > [アプリケーション状態/配備解除]タブでWebモジュールを選択して、[Webサービス環境定義]タブより

取得可能です。

■Webサービス（クライアント機能）の運用方法

Webサービスクライアントの場合、クライアントアプリケーションの形態によって、運用方法が違います。Webサービスクライアントは、IJServerおよびJ2EEアプリケーションクライアントの実行環境で動作させる

ことができます。

・IJServer上で動作するアプリケーション (Servlet /EJB)作成したアプリケーションとスタブなどをパッケージ化し配備（配備解除）します。また、IJServerのタイプに応じて以下の設定も必要です。

－「 WebアプリケーションとEJBアプリケーションを同一JavaVMで運用」の場合IJServerの環境設定で、コンテナのWebサービス機能を“有効”にします。

－上記以外の場合IJServerの環境設定で、ライブラリ(isws.jar) ファイルをクラスパスに設定します。

・上記以外のアプリケーション (J2EEアプリケーションクライアント実行環境)作成したアプリケーション、スタブなどと、ライブラリ(isws.jar、isws-lib.jar)ファイルをクラスパスに設定し

て、実行します。



2.13 JMS2.13 JMS

J2EE

受信アプリケーション（メッセージ・コンシューマ）

JMSプロバイダ

送信アプリケーション（メッセージ・プロデューサ）

メッセージメッセージ

JMSクライアント JMSクライアント

メッセージ

メッセージ本文ボディ

メッセージに関する各種情報を格納

受信側でメッセージをフィルタリングするパラメタとして使用

プロパティ

メッセージの送受信に関する情報を格納ヘッダ

JMS (Java Message Service) は、企業のメッセージングシステムのメッセージの作成、送信、受信、および読み取りを行う一般的な方法を Java プログラムに提供するものです。

JMSは、MOM(Message Oriented Middleware：メッセージ指向ミドルウェア)と呼ばれるメッセージングシステムにアクセスするための標準APIを提供しています。

JMSを利用することで、複数のアプリケーション間で、メッセージの交換による通信を行うことができるようになります。メッセージによる通信を行うことで、1対nの通信や、非同期通信を行うことも可能です。

JMSを利用した基本的なメッセージングシステムは、JMSクライアント、JMSプロバイダ、メッセージで

構成されます。

■ JMSクライアント

メッセージの送受信を行うJavaプログラムです。

■ JMSプロバイダ

JMSインタフェースを実装し、管理機能や制御機能を提供するメッセージングシステムです。

■ メッセージ

クライアント・アプリケーション間の情報通信に使用されるオブジェクト(リクエスト、レポートなど)です。

送信側JMSクライアントは、メッセージをJMSプロバイダに送信します。メッセージを受け取ったJMSプロバイダは受信側JMSクライアントへメッセージを送信します。受信側JMSクライアントが何らかの原因でメッセージを受信できない場合、いったんJMSプロバイダでメッセージを預かり、受信側JMSクライアントの復旧時に再度送信する(JMSクライアントからJMSプロバイダへ取りに行く)ことも可能です。

JMSアプリケーションで送受信されるメッセージは、標準のヘッダ、アプリケーション固有のプロパティ、メッセージ本文の3つの要素で構成されます。


■ ヘッダフィールド

メッセージの送受信に関する情報を格納したヘッダです。標準で(自動で)設定される情報のほか、Javaプログラム側で設定することもできます。

■ プロパティフィールド

メッセージの内容に関する各種情報を格納します。標準で設定されるものもありますが、おもにJavaプロ

グラム側で設定します。受信側でメッセージをフィルタリングするパラメタとして利用できます。

■ボディフィールド

メッセージ本文です。



2.14 Interstage JMS2.14 Interstage JMS

Interstage

JMSクライアント

JMSクライアント

Notificationクライアント

Interstage

InterstageJMSプロバイダ

InterstageJMSプロバイダ

ノーティフィケーション

サービス

イベントチャネル

CO

RB

A

サービス

IIOP

IIOP

Interstage JMS構成IIO

P

Interstage JMSはイベントサービスのノーティフィケーションサービス上に構築され、通信層などメッ

セージング処理の基盤部分を利用します。

Interstage JMSプロバイダは、JMSクライアントからのメッセージ送受信要求を受けるとノーティフィ

ケーションサービスのイベントチャネルに対してメッセージを送受信します。

おもな機能を以下に示します。

■Publish/Subscribeメッセージングモデル

■Point-To-Pointメッセージングモデル

■メッセージセレクタ機能

■メッセージ保証



2.14.1 イベントサービス2.14.1 イベントサービス

【イベント通信でのイベントデータ、サプライヤ、コンシューマ、イベントチャネルの位置づけ】

複数クライアントへの同時送信イベントを集約して通過

サーバ

InterstageInterstage

クライアント

サーバ


クライアントクライアントクライアントクライアントクライアント


イベントサービスイベントサービス


イベントサービスイベントサービス

イベント発生

イベント発生イベント発生イベント発生

イベントデータ





サプライヤイベントチャネルコンシューマ

イベントサービスとイベントサービスを拡張したサービスであるノーティフィケーションサービスは、イベントチャネルを介し、分散アプリケーション間の通信をオブジェクトを使用して非同期に行う機能を提供するオブジェクトサービスです。

CORBA規定によるイベントサービスに準拠したInterstageイベントサービスでは、マルチスレッドによる

高速処理などの高性能機能や、イベントチャネルの各種カスタマイズなどの優れた運用性・保守性を提供しています。

イベントサービスは、アプリケーションプログラムの処理中に発生したエラーメッセージの通知、およびシステム間でのメッセージ送信など片方向通信を必要とする業務処理などに使用します。とくに1対多、多

対多の通信で有効です。イベントサービスを使用してアプリケーションプログラム間の通信を行う場合、データを送信、受信するアプリケーションは、イベントチャネルを通して通信を行うことにより、アプリケーションプログラムでは通信相手を認識する必要がありません。イベントチャネルに接続するサプライヤ、コンシューマを変更することで通信相手の変更に対応することが可能です。

イベントサービスで使用するおもな用語について以下に説明します。

■イベント通信 (Event Communication)イベントサービスでの通信です。

■イベントデータ(Event Data)イベントサービスで送受信を行う利用者のデータです。

■サプライヤ(Supplier)イベントサービスでは、イベントデータの送信者のことです。サプライヤは、利用者がアプリケーションプログラム上で作成するオブジェクトです。


■コンシューマ(Consumer)イベントサービスでは、イベントデータの受信者のことです。コンシューマは、利用者がアプリケーションプログラム上で作成するオブジェクトです。

■イベントチャネル(EventChannel)イベントチャネルは、イベント通信を行う場合、サプライヤとコンシューマの間に存在するオブジェクトで、イベントデータの受け渡しを制御します。イベントチャネルは、イベントサービスが提供するコマンドで生成するオブジェクトと、利用者が作成するアプリケーションプログラム上で作成するオブジェクトがあります。

■イベントファクトリ(EventFactory)イベントファクトリは、アプリケーションプログラムから動的にイベントチャネルを生成するオブジェクトです。



2.14.1.1 ノーティフィケーションサービス2.14.1.1 ノーティフィケーションサービス

QoS機能

メッセージ保証機能

・メッセージの優先度やメッセージの有効時間などを設定可能

×○メッセージ

×○静的生成チャネル

○○動的生成チャネル

AdminプロパティQoSプロパティ

データベース連携サービス


ノーティフィケーションサービスのイベントチャネル

メッセージ

チャネル間連携機能

③グローバルトランザクション

②ローカルトランザクション

①不揮発化

④チャネル間連携

イベントサービスにいくつかの機能を拡張したサービス

ノーティフィケーションサービスは、イベントサービスにいくつかの機能を拡張したサービスです。ノーティフィケーションサービスはQoS機能により、イベントデータ単位の各種カスタマイズなどのイベントサービ

スと比較して優れた運用性を提供します。さらに、イベントデータの不揮発化やトランザクション機能によりメッセージを保証する機能を備えています。

また、イベントチャネルの閉塞、閉塞解除を行い、サプライヤからの送信要求を一時的に受け付けなくする機能や、CORBA標準ファクトリインタフェースをサポートしています。

■QoS機能

メッセージの優先度やメッセージの有効時間などを設定できます。QoS機能には、メッセージ単位、および静的生成/動的生成したノーティフィケーションサービスのイベントチャネル単位に設定できる“QoSプロパティ”と、動的生成したノーティフィケーションサービスのイベントチャネル単位に設定できる“Adminプロパティ”の2種類があります。

■メッセージ保証機能

ノーティフィケーションのイベントチャネルの不揮発化機能、トランザクション機能、チャネル間連携機能を使用することでシステムダウン、アプリケーション異常、回線ダウンなどのトラブルによりメッセージロスト、およびメッセージの二重送信を防止できます。

ノーティフィケーションサービスでは、QoS機能により、アプリケーションプログラムの処理で、通常のメッ

セージ送信中に緊急度の高いメッセージ送信を必要とする業務処理などに使用することができます。

また、メッセージ保証機能により、高信頼性を求められる業務処理などに使用することができます。



メッセージロストおよびメッセージの二重送信を防止

2.14.1.2 メッセージ保証機能2.14.1.2 メッセージ保証機能

不揮発化

ローカルトランザクション

グローバルトランザクション

チャネル間連携機能

イベントデータイベントデータイベントデータ


接続情報


トランザクション開始

不揮発媒体

イベントデータトランザクション開始


データ送信

トランザクション終了

データ受信



不揮発媒体

イベントデータトランザクション開始


データ送信


ほかのリソースへアクセス


ほかのリソース

ほかのリソース

ほかのリソースへアクセス

データ受信


サプライヤ

データ送信



コンシューマ


データ受信


チャネル間連携

チャネル間連携


システムダウン

ノーティフィケーションサービスでは、ノーティフィケーションのイベントチャネルの不揮発化機能、トランザクション機能、チャネル間連携機能を使用することで、システムダウン、アプリケーション異常、回線ダウンなどのトラブルにより起こるメッセージロストおよびメッセージの二重送信を防止できます。

■不揮発化

接続情報およびイベントデータを不揮発化することにより、チャネルダウンおよびシステムダウンなどが発生した場合であってもデータが保証されるため、信頼性を要求される基幹業務への適用が可能となります。システムが復旧してコンシューマが再起動すると、イベントデータを受信できます。

不揮発化は、esmkchnlコマンドを使用してイベントチャネルの作成時に指定します。-persistオプションにより、以下の2つのモードが指定可能です。

all：イベントデータ、接続情報が不揮発化の対象となります。

con：接続情報だけが不揮発化の対象となります。

■ローカルトランザクション

不揮発化機能とローカルトランザクション機能を使用することで、システムダウン、アプリケーション異常、回線ダウンなどのトラブルによるメッセージロストおよびメッセージの二重送信を防止できます。

ローカルトランザクションは、esmkchnlコマンドを使用してイベントチャネルの作成時に指定します。

■グローバルトランザクション

不揮発化機能とグローバルトランザクション機能を使用することで、ほかのリソースとの分散トランザクションを実現できます。システムダウン、アプリケーション異常、回線ダウンなどのトラブルによるメッセージロストおよびメッセージの二重送信を防止できます。グローバルトランザクションは、esmkchnl コマンドを使用してイベントチャネルの作成時に指定します。なお、グローバルトランザクション連携機能は、V4以降のInterstageと接続できます。

■チャネル間連携機能

ネットワークにまたがるサーバ間のチャネルを連携する機能です。システムダウン、アプリケーション異常、回線ダウンなどのトラブルによりメッセージロストおよびメッセージの二重送信を防止できます。

チャネル間連携機能は、Interstage Application Server Enterprise Editionで使用できます。



2.14.1.3 通信モデル2.14.1.3 通信モデル

Pushモデル

Pullモデル

Mixedモデル

① コンシューマが、イベントチャネルに接続。コンシューマはイベントデータ受信待ちの状態になります。

② サプライヤがイベントデータをイベントチャネルに送信。イベントチャネルは、接続されているコンシューマだけにイベントデータを送信します。

③ コンシューマがイベントデータを受信すると、次のイベントデータの受信を待ち合わせます。

① サプライヤは、イベントチャネルに接続。サプライヤはイベントデータ受信要求待ちの状態になります。

② コンシューマがチャネルにイベントデータの送信を要求。③ イベントチャネルは、接続しているサプライヤに送信要求。④ 送信要求を受け取ったサプライヤはイベントデータがあ

ればイベントチャネルに送信し、次の送信要求を待ち合わせます。

⑤ コンシューマは、サプライヤからのイベントデータをイベントチャネルから受信。

① コンシューマは、イベントチャネルに対して接続。② サプライヤは、イベントデータをイベントチャネルに送信。③ イベントチャネルでは、イベントデータを一時的に蓄積。④ イベントチャネルに接続しているコンシューマが、イベント

チャネルに蓄積されているイベントデータを取り出す要求を出します。

⑤ イベントチャネルは、蓄積されているイベントデータを取り出して送信し、コンシューマが受信。

サプライヤイベントチャネル

コンシューマ②送信①接続

③受信

サプライヤイベントチャネル

コンシューマ

①接続

⑤受信

②通信要求③送信要求

④送信


①接続

⑤受信

②送信 ④取り出し

③蓄積

Pushモデル Pullモデル

イベントサービスでは、以下の3種類の通信モデルをサポートします。

■Pushモデル

サプライヤがイベントデータの受信待ち状態にあるコンシューマにイベントデータを送信します。サプライヤが送信したイベントデータをイベントチャネルに接続されているコンシューマへ高速、かつ同時に送信する場合に使用します。Pushモデルでは、コンシューマ側のアプリケーションはサーバアプリケーション

である必要があります。

■Pullモデル

コンシューマがイベントデータの送信要求待ち状態にあるサプライヤにイベントデータの“引き出し”(pull)を要求します。要求した結果、送信するイベントデータがサプライヤにあれば、そのイベントデータ

をコンシューマに送信する通信モデルです。サプライヤは、コンシューマの準備ができるまでイベントデータ受信要求待ちの状態になります。1台のサプライヤに対して複数のコンシューマが、データを取得

する場合に有効です。

コンシューマがイベントデータの“引き出し”をサプライヤへ要求するには2つの形態があります。

・pull型コンシューマがサプライヤに送信要求を出した際に、その時点でイベントデータがなければイベントデータがサプライヤで生成されるまで待ち合わせます。

・try_pull型イベントデータがサプライヤにない場合は、すぐにコンシューマに制御を返します。

Pullモデルでは、サプライヤ側のアプリケーションはサーバアプリケーションである必要があります。


■Mixedモデル

サプライヤ側をPushモデル、コンシューマ側をPullモデルとした通信モデルです。サプライヤもコン

シューマも待ち合わせることなく、その中間にあるイベントチャネルが一時的にイベントデータを蓄積し、受け渡しします。このモデルは、サプライヤとコンシューマが互いの動作状態に関係なくイベント通信する、非同期のアプリケーション間通信を実現できます。

また、Pushモデルと同様に、同時に複数のコンシューマに対してメッセージを送信したり、1台のコン

シューマが複数のサプライヤからのメッセージを受信する場合に有効です。そして、一定時間ごとにコンシューマがイベントチャネルに蓄積されているデータを受け取る場合においても有効です。

コンシューマ、サプライヤ側のマシン環境でサーバアプリケーションを運用できない場合は、Mixedモデ

ルを使用します。



2.14.1.4 メッセージングモデル2.14.1.4 メッセージングモデル

MultiCastモデル

Point-To-Pointモデル

・複数コンシューマへの配信が可能

・コンシューマ数の増減によるサプライヤの変更、イベントチャネルの再作成が必要ない

・業務アプリケーションのシステム性能を向上させることが可能

・運用性が向上

イベントデータ5





コンシューマ

コンシューマ

コンシューマ





サプライヤイベントデータ6





コンシューマ

コンシューマ

コンシューマ



サプライヤイベントデータ7



イベントサービスでは、以下の2種類のメッセージングモデルをサポートします。

■MultiCastモデル

接続しているすべての端末のコンシューマに同一のメッセージを送信します。MultiCastモデルを使用した場合は、以下のような効果があります。

・複数コンシューマへの配信

サプライヤは、ある1つのイベントチャネルに対してイベントデータを送信することにより、複数のコン

シューマを意識することなく、各コンシューマにイベントデータを配信できます。

・運用変更によるアプリケーションへの影響

コンシューマ数の増減によるサプライヤへの影響はなく、サプライヤを変更したり、イベントチャネルを再作成する必要はありません。ただし、コンシューマの数が増加する場合は、イベントチャネルの資源

を十分に確保しておく必要があります。

■Point-To-Pointモデル

接続している1つのコンシューマだけにメッセージを送信します。複数のコンシューマが接続している場合でも、メッセージは1つのコンシューマでだけ受信できます。また、メッセージはpullメソッド発行中のコンシューマに自動的に割り振られます。したがって、1拠点から1拠点への非同期通信に適用できます。Point-To-Pointモデルを使用した場合は、以下のような効果があります。

・システム処理性能の向上

コンシューマの多重度を増加させることにより、業務アプリケーションのシステム性能を向上させることが可能です。コンシューマがイベントデータを受信した後にデータベース処理などを並行して動作することで、システム性能の向上につながります。


・運用性向上

MultiCastモデルでは、コンシューマが事前に接続しておかないとイベントデータが破棄されますが、Point-To-Pointモデルでは、コンシューマの接続処理に関わらずイベントデータを受信することができます。MultiCastモデルでは、イベントデータの破棄を防止するため、コンシューマが事前に接続して、オブジェクトリファレンスを不揮発媒体に保存する必要がありますが、Point-To-Pointモデルでは、

その必要はありません。



2.14.2 Interstage JMSのメッセージングモデル2.14.2 Interstage JMSのメッセージングモデル


Interstage JMS

ノーティフィケーションサービス


Interstage JMS



Interstage JMS


Message Listener


Interstage JMS

ノーティフィケーションサービス1対ｎのメッセージモデル

SubscriberSubscriber

Subscriber

起動型

Publisher

■Publish/Subscribeメッセージングモデル

■Point to Pointメッセージングモデル


Interstage JMS



Interstage JMS



1対1のメッセージモデル

Receiver

ReceiverJMSアプリケーション

Interstage JMS


Sender


Interstage JMSでは、Publish/Subscribeメッセージングモデル、Point-To-Pointメッセージング

モデルに対応しており、それぞれで以下の機能を提供しています。

■Publish/Subscribeメッセージングモデル(1対nメッセージングモデル)

・複数の受信者に対して同一のメッセージを配信

ノーティフィケーションサービスを介して、送信アプリケーション(Publisher)と受信アプリケーション(Subscriber)が連携します。

・受信アプリケーションの形態として待機型とメッセージがあて先に到達すると、自動で処理するMessage Listenerを使用した起動型をサポート

・ノーティフィケーションサービスによるメッセージの優先度や生存時間の制御

■Point-To-Pointメッセージングモデル(1対1メッセージングモデル)

・1拠点から1拠点への非同期通信

ノーティフィケーションサービスを介して、送信アプリケーション(Sender)と受信アプリケーション(Receiver)が連携します。複数のReceiverが接続している場合、メッセージを受信できるのは1つのReceiverだけで、メッセージは自動的に振り分けられます。

・受信アプリケーションの形態として待機型とMessage Listenerを使用した起動型をサポート

・ノーティフィケーションサービスによるメッセージの優先度や生存時間の制御

なお、メッセージングモデル(Publish/Subscribeメッセージングモデル、Point-To-Pointメッセージングモデル) の指定はチャネル作成時(esmkchnl)に指定できます。

また、両メッセージングモデルともに、受け側アプリケーションとしてMessage-driven Beanを使用する

ことができます。



2.14.3 メッセージセレクタ機能2.14.3 メッセージセレクタ機能

メッセージセレクタ機能

color=“blue”

条件一致


メッセージcolor=“red”

メッセージcolor=“red”

メッセージcolor=“blue”

メッセージcolor=“blue”

送信アプリケーション

［プロパティ]color=“red”[本文]

プロパティにcolor=“red”を指定してメッセージ送信

送信アプリケーション

［プロパティ]color=“blue”[本文]

プロパティにcolor=‘blue’を指定してメッセージ送信

受信アプリケーション

条件式color=‘blue’を指定してメッセージ送信

プロパティがcolor=‘blue’のメッセージだけ受信

［プロパティ]color=“blue”[本文]

メッセージ要求

メッセージセレクタ機能は、送信アプリケーションから送られる多様なメッセージの中から、受信アプリケーションが受信したいメッセージを指定して受け取ることができる機能です。

以下に、メッセージセレクタ機能の動作を説明します。

■送信アプリケーションでは、メッセージを識別/分類するための情報をメッセージのプロパティフィールド

に設定し、メッセージを送信します。

■受信アプリケーションでは、受信したいメッセージを特定するための条件式を受信開始時に指定します。以降、受信アプリケーションは条件式に一致したプロパティをもつメッセージだけを受信します。

■Publish/Subscribeメッセージングモデルでは、条件式に一致しないメッセージは破棄され、Point-To-Pointメッセージングモデルでは、条件式に一致しないメッセージは読み飛ばされます。

メッセージセレクタ機能を使用した場合の効果を以下に示します。

■受信アプリケーションが興味のある情報だけを取得可能

送信アプリケーションが送信したすべてのメッセージを受信することなく、受信アプリケーションが興味のあるメッセージだけを受信することができ、運用性が向上します。

たとえば、送信アプリケーションが国際/社会/政治/経済/天気予報/スポーツ/芸能などのジャンルのニュースを送信する場合、ある受信アプリケーションは天気予報/スポーツなどの特定の情報だけを受信

できます。

■イベントチャネル数の削減およびシステム資源の削減

従来、あるメッセージを特定の拠点だけに送信する場合、拠点ごとにチャネルを作成しておく必要があり、拠点が増加するにつれ、システム資源を使用してシステムを圧迫してきました。

メッセージセレクタ機能を使用して各拠点の受信アプリケーションが受信メッセージを選択できるようになるため、チャネルを1つにするなど、使用するチャネル数を削減できます。これにより、拠点が増加した場

合のシステム資源を削減できます。



2.15 JNDI2.15 JNDI

・・・

Javaアプリケーション Javaアプリケーション Javaアプリケーション

JNDI API

JNDI ネーミングマネージャ

JNDI SPI

LDAP Cos-Naming

RMIレジストリ

DNS ファイルシステム

JNDIサービス

プロバイダ


JNDI(Java Naming and Directory Interface) は、Java プラットフォーム用の標準拡張機能で、Java テクノロジに対応したアプリケーションに、複数のネームサービスおよびディレクトリサービスへの統

一したインタフェースを提供しています。これにより、強力かつ移植性の高いディレクトリ対応アプリケーションを構築できます。

■ネームサービス

名前とオブジェクトの関連付けを記憶し、名前をもとに関連付けられたオブジェクトを検索できるサービスです。

■ディレクトリサービス

名前とオブジェクト、およびオブジェクトの属性との関連付けを記憶し、名前をもとに関連付けられたオブジェクト、およびオブジェクトの属性を検索できるサービスです。

JNDIアーキテクチャは、API(Application Programming Interface)およびSPI(Service ProviderInterface)で構成されます。APIはJavaアプリケーションに対して、共通インタフェースを提供します。

SPIはサービスに対して共通インタフェースを提供します。このSPIを利用して実際のサービスと通信するのがJNDIサービスプロバイダです。JNDIサービスプロバイダは、ネーミングサービスおよびディレクトリサービスごとに用意され、JNDI SPIにプラグインされます。これにより、Javaアプリケーションは、JNDI APIを利用することで、さまざまなネーミングサービスやディレクトリサービスに対して、アクセス手法

などを意識することなく透過的にアクセスできるようになります。

JNDIを利用しJavaアプリケーションがネーミングサービスへアクセスするまでの、コンポーネントの使用

順序は、以下のようになります。

「Javaアプリケーション」→「JNDI API」→「JNDIネーミングマネージャ」→「JNDI SPI」→「JNDIサービスプロバイダ」



2.16 JNDIサービスプロバイダ(JNDI SP)2.16 JNDIサービスプロバイダ(JNDI SP)

EJBコンテナ Webコンテナクライアントコンテナ

JDBCリソース

JMSリソース

JavaMailリソース

connectorリソース

EJB/CosNaming

リソース

Interstage JNDI SP


Webアプリケーション

J2EEアプリケーションクライアント

Interstageでは、JNDI(Java Naming and Directory Interface)の考え方をベースとした、サーバアプリケーションを実行するための実行環境として、JNDIサービスプロバイダ(以降JNDI SPと記述する)機能を提供しています。

JNDI SPでは、EJBアプリケーション、Webアプリケーション、およびJ2EEアプリケーションクライアントで使用するJNDI名と、Interstage(運用)環境で使用するリソース名の対応付けが管理されます。

このJNDI SPを利用することで、各アプリケーションで使用するリソース情報を、アプリケーションの動作環境ごとに定義する必要がなくなり、Interstage環境で統合された管理を行うことが可能となります。

Interstage JNDISPでは、J2EEが提供するjavax.naming.InitialContext、javax.naming.Contextのlookup(String name)メソッドのみがサポートされます。



2.17 ワークユニット2.17 ワークユニット

データベース

業務アプリケーション業務アプリケーションデータベース業務アプリケーション業務アプリケーション

業務アプリケーション業務アプリケーション




ORB機能ORB機能

アプリケーション管理機能アプリケーション管理機能

●業務アプリケーション●共用制御●多重化●デバッグ機能●スナップショット/実行時ログ

●運用管理機能●高信頼化●スケーラビリティ

業務単位の起動・終了

アプリケーション管理機構（ワークユニット）

Interstage Application Serverでは、構築したシステムを安心して運用していただくために、運用状

態を監視するアプリケーション管理機能として、ワークユニットを提供しています。ワークユニットはアプリケーションの運用の単位となります。そのため、1つのワークユニットには、同時に起動、停止を行うアプリ

ケーションを設定します。

ワークユニットは運用の単位となるため、ワークユニット内の1つのアプリケーションが起因してワークユ

ニットが異常終了となった場合でも、ワークユニット内のすべてのアプリケーションは停止します。任意のアプリケーションが原因で、ほかのアプリケーションに影響を及ぼしたくない場合は、ワークユニットをわけることが必要です。

ワークユニットは、業務単位の環境構築を行い、以下の設定を可能としています。

■アプリケーションプロセス多重度

■サーバアプリケーションの動的プロセス数変更

■サーバアプリケーションタイマ機能

■アプリケーション自動再起動

■アプリケーション自動再起動失敗時の縮退運用

■環境変数

■カレントディレクトリ

■バッファ制御

■キュー制御(キュー閉塞/閉塞解除、大キューイング機能、滞留キュー数のアラーム通知機能)■アプリケーションの常駐/非常駐運用、マルチオブジェクト常駐運用

また、Systemwalkerなどのネットワーク管理マネージャと連携することにより、多様な形態でのアプリケーション運用操作/監視を行うことができます。


Interstage Application Serverでは、ワークユニットによる運用として、以下のアプリケーションを対象とすることができ

ます。

■CORBAアプリケーション (CORBAワークユニット)■J2EEアプリケーション (IJServerワークユニット)■トランザクションアプリケーション

■ラッパーオブジェクト [Windows版、Solaris版]■Interstage Application Server配下外の一般アプリケーション

(ユーティリティワークユニット(UTYワークユニット)) [Solaris版、Linux版]



2.17.1 ワークユニットの機能 (1/5)2.17.1 ワークユニットの機能 (1/5)

・複数クライアントから１つのアプリケーションへの同時要求に対して、実行単位（プロセス）を複数起動し、同時に処理できるプロセス多重度の設定が可能

サーバアプリケーションタイマ機能

・ワークユニット配下アプリケーションの呼び出しから復帰までの応答時間を監視－アプリケーション処理遅延によるクライアントへのレスポンス遅延を防止

・CORBAアプリケーション、J2EEアプリケーション、トランザクションアプリケーションに対して有効

サーバアプリケーションの動的プロセス数変更

・運用中のワークユニットの停止やワークユニット定義を変更することなくサーバアプリケーションのプロセス多重度を変更することが可能

・CORBAワークユニット、トランザクションアプリケーションのワークユニットに対してだけ行うことが可能

アプリケーションプロセス多重度

Interstage Application Serverが提供するワークユニットでは、以下の機能を提供しています。

■アプリケーションプロセス多重度複数のクライアントから、1つのアプリケーションに同時に要求が出された場合に、実行単位(プロセス)を複数にして、同時に処理できるプロセス多重度を設定できます。多重度に関しては、Interstage管理

コンソールのワークユニット設定で設定します。プロセス多重度については、１処理あたりの処理時間とクライアントへのレスポンス時間、および時間あたりの要求数により、決定する必要があります。また、必要以上にプロセス多重度を大きくすると、メモリなどシステム資源に影響があるため、妥当な多重度に設定を行う必要があります。

■サーバアプリケーションの動的プロセス数変更運用中のワークユニットの停止やワークユニット定義を変更することなく、サーバアプリケーションのプロセス多重度を変更できます。また、CORBAワークユニットおよびトランザクションアプリケーションのワークユニットに対してだけ行うこ

とが可能です。ismodifyprocnumコマンド、またはInterstage管理コンソールから、アプリケーションのプロセス多重度を変更します。Interstage管理コンソールによる変更は、CORBAワークユニットだけ可能です。

指定されたプロセス数が現在動作中のプロセス数よりも多い場合は、指定された値となるようプロセスを追加起動し、指定されたプロセス数が現在動作中のプロセス数よりも少ない場合は、超過分のプロセスを停止します。

■サーバアプリケーションタイマ機能アプリケーションの大処理時間(タイムアウト時間)を指定し、ワークユニット配下で動作するサーバア

プリケーションの呼び出しから復帰までの、応答時間の監視を行うことができます。指定した大処理時間を超過した場合、超過メッセージの出力やプロセスの強制停止を行うことができます。アプリケーション障害によるハングアップ、ループなどが原因となる処理遅延によるクライアントへのレスポンス遅延を防止する場合に使用します。アプリケーションの大処理時間に関しては、Interstage管理コンソールのワークユニット設定に指定します。サーバアプリケーションタイマ機能は、CORBAアプリケーション、J2EEアプリケーション、トランザクションアプリケーションに対して有効です。




アプリケーション自動再起動失敗時の縮退運用

・プロセス多重で動作していたワークユニットにおいて、アプリケーション自動再起動に失敗した場合、アプリケーション再起動失敗のメッセージを出力し、残りのプロセスでのワークユニット運用を継続する

・アプリケーション自動再起動失敗により、減少してしまったプロセス多重度を、プロセスの再起動により、本来のプロセス多重度に復元する

アプリケーション自動再起動

・アプリケーションが異常終了した場合にアプリケーションを自動的に再起動することが可能・アプリケーションが設定した回数だけ連続異常終了した場合は、ワークユニットを異常終了する

－ワークユニット内のアプリケーションプロセスはすべて停止－該当ワークユニットで処理中の要求は、クライアントへエラーで復帰

・プロセスの再起動に失敗した場合、ワークユニットを異常終了する

■アプリケーション自動再起動クライアントからの入力データの誤りなどにより、アプリケーションが異常終了した場合には、アプリケーションを自動的に再起動させることができます。自動再起動を設定すると、クライアントからの新たな要求を処理できます。アプリケーション自動再起動に関しては、Interstage管理コンソールのワークユニット設定で設

定します。設定内容は、連続異常終了回数を設定します。連続異常終了回数とは、アプリケーションの障害などにより、該当アプリケーションが１度も正常に処理されず、異常終了と再起動が繰り返される回数です。アプリケーションの再起動が連続異常終了回数に達した場合、ワークユニットは異常終了します。ワークユニットが異常終了した場合は、同一ワークユニット内のアプリケーションのプロセスはすべて停止され、該当ワークユニットで処理中の要求はクライアントにエラーで復帰します。連続終了回数まで1度でも該当アプリケーションの処理が正しく動作した場合(アプリケーションが復帰)、終了回数はリセットされます。(IJServerワークユニット以外の場合)IJServerワークユニットの場合、初のアプリケーション異常終了からInterstage管理コンソールの「環境

設定」画面で設定された「リトライカウントリセット時間」が経過すると連続異常終了回数はリセットされます。また、プロセスの再起動が失敗した場合は、ワークユニットは異常終了となり、同一ワークユニット内で動作しているすべてのアプリケーションが停止します。

■アプリケーション自動再起動失敗時の縮退運用アプリケーションの再起動が失敗した場合は、ワークユニットは異常終了となります。アプリケーションが複数多重(プロセス多重)で起動されているワークユニットでは、これを回避し、アプリケーションの再起動に

失敗した場合でも、アプリケーション再起動失敗のメッセージを出力し、残りのプロセスでワークユニット運用を継続する機能を提供します。本機能は、CORBAワークユニットおよびIJServerワークユニットで有効です。CORBAワークユニットの場合は、ワークユニット定義の“Control Option”セクションの“Process degeneracy”ステートメントに“YES”を設定します。IJServerワークユニットの場合は、Interstage管理コンソールの「環境設定」画面において「アプリケー

ション自動再起動失敗時の制御」の項目で「ワークユニットの運用を継続する」を選択します。また、アプリケーションの自動再起動失敗により、減少してしまったプロセス多重度を、プロセスの再起動を実行し、本来のプロセス多重度に復元する機能を提供します。プロセス多重度を動的に変更している場合は、変更後のプロセス多重度に復元します。縮退運用しているワークユニットは、コマンド(isrecoverwu)、または、Interstage管理コンソールの操作に

より復元されます。




カレントディレクトリ

・ワークユニット配下で動作するアプリケーションは、それぞれ異なった作業ディレクトリで動作させることが可能

バッファ制御

・クライアントからの要求データを一時的に保持するデータ域(通信バッファ域)を制御・CORBAアプリケーションおよびIJServerのEJBアプリケーションでは、バッファ長および

バッファ数をチューニング可能

環境変数

・ワークユニット配下で動作するアプリケーションが使用する環境変数は、Interstage管理コンソールのワークユニット設定で設定することが可能

・ワークユニット配下で動作するアプリケーションプロセスの環境変数は、ワークユニット定義に記載された環境変数およびInterstage実行環境で設定されている環境変数の両方が有効になる

・ワークユニット定義の環境変数とInterstage実行環境の環境変数が重複している場合には、ワークユニット定義の環境変数が優先される

■環境変数ワークユニット配下で動作するアプリケーションプロセスの環境変数は、Interstage管理コンソールのワークユニット設定に記載された環境変数、およびInterstage実行環境で設定されている環境変数の

両方が有効となります。Interstage実行環境で設定されている環境変数は、Windowsでは、システム環境変数が引き継がれ、Solaris およびLinuxでは、Interstageの起動方法により異なります。

・isstartコマンドを使用してInterstageを起動する場合isstartコマンド実行環境で設定されている環境変数が引き継がれます。なお、システム初期化スクリプト(S99startis)を使用して自動起動している場合は、システム初期化スクリプト実行環境の環境変数が

引き継がれます。

・Interstage管理コンソールよりInterstageを起動する場合isjmxstartコマンド実行環境で設定されている環境変数が引き継がれます。なお、システム初期化スクリプト(S95isjmxstart)を使用してInterstage JMXサービスを自動起動している場合は、システム初

期化スクリプト実行環境の環境変数が引き継がれます。

また、Interstage管理コンソールのワークユニット設定の環境変数とInterstage実行環境の環境変数が重複している場合には、Interstage管理コンソールのワークユニット設定の環境変数が優先されます。

■カレントディレクトリワークユニットで起動したアプリケーションが動作する作業ディレクトリ(カレントディレクトリ)を指定するこ

とができます。カレントディレクトリにより、ワークユニット配下で動作するアプリケーションはそれぞれ異なる作業ディレクトリで動作することが可能となります。

■バッファ制御クライアントからの要求データは、キューイングされているあいだは、一時的に共用メモリ上に保持しつづけます。この共用メモリ上のデータ域を通信バッファといい、バッファ域を管理する制御をバッファ制御といいます。通信バッファは１つの要求データを埋め込む領域であるバッファ域が複数個で構成されます。なお、バッファ域の大きさをバッファ長、バッファ域の数をバッファ数といいます。CORBAアプリケーションおよびIJServerのEJBアプリケーションでは、バッファ長およびバッファ数をワークユニット定義で設定(チューニング)可能です。




キュー制御

・クライアントからの要求を該当するアプリケーションの待ち行列（キュー）に接続（キューイング）し、キューイングされた要求をアプリケーションが順次処理する

キュー閉塞/閉塞解除

・キューの閉塞、閉塞解除を行い、クライアントからの要求を一時的に受け付けない状態にしたり、要求の受け付けを再開したりすることが可能

大キューイング機能

・キューイングされる要求の大数を制限することで、アプリケーションにかかる負荷を抑えることが可能

滞留キュー数のアラーム通知機能

・処理が終わらず滞留しているキュー数が、監視キューイング数として設定した数を超えた場合にアラーム通知を行うことが可能

■キュー制御

複数クライアントから同一アプリケーション(オブジェクト)に対して要求が出された場合に、すべての要求

分のアプリケーションを起動すると、サーバの負荷が大きくなります。このような場合に、キュー制御で負荷を平準化させることができます。クライアントからの要求は、該当するアプリケーションの待ち行列であるキューに接続(キューイング)され、キューイングされた要求は、アプリケーションにより順に処理されます。CORBAアプリケーション、IJServerのEJBアプリケーション、トランザクションアプリケーションでは、

以下の機能を利用できます。

・キュー閉塞/閉塞解除

キューの閉塞、閉塞解除を行い、クライアントからの要求を一時的に受け付けないような状態にしたり、要求の受け付けを再開したりすることができます。キューの閉塞、閉塞解除は以下のような場合に有効です。

－時間帯により使用を制限したい業務がある場合－負荷が高く、一時的に要求を受け付けない状態にしたい場合－業務停止前に要求を抑止し、すべての処理が終わったのち停止を行う場合

なお、キューの閉塞中にクライアントからの要求を行った場合、クライアントへ異常が復帰します。

・大キューイング機能キューイングされる要求の大数が指定できます。これにより、サーバアプリケーションに一定以上の負荷がかかった場合に、クライアントからの要求を制限できます。クライアントからの要求が指定された大キューイング数を超えた場合、クライアントへエラーが復帰します。

・滞留キュー数のアラーム通知機能処理状況に応じて、処理が終わらず滞留しているキュー数が、設定した監視キューイング数を超えるとアラーム通知を行い、設定した監視再開キューイング数まで滞留キュー数が減少すると、監視を再開します。これにより、システムの負荷状態をリアルタイムに監視できます。

滞留キュー数を監視する場合、以下の3つのポイントを監視できます。

－滞留キュー数が大キューイング数を超過した場合－滞留キュー数が監視キューイング数(任意)と同じになった場合－滞留キュー数が監視再開キューイング数(任意)と同じになった場合




アプリケーションの常駐/非常駐運用、マルチオブジェクト常駐運用

・トランザクションアプリケーションで、メモリ上にローディングされるアプリケーションをメモリ上に常駐させるか、非常駐にさせるかを、ワークユニットで定義することが可能

－常駐運用・1つのプロセスに1つのアプリケーションを常駐可能・連続してクライアントからの要求が多い場合に有効

－非常駐運用・クライアントからの要求があるごとにメモリ上にローディングされ、

アプリケーション終了後にメモリ上から消去される・クライアントからの要求が少なく、アプリケーションの種類が多い場合に有効

－マルチオブジェクト常駐運用・１つのプロセス上で複数のオブジェクトを処理可能・常駐運用に比べローディングするアプリケーションプロセスの数を少なくできるため、

メモリ消費を削減できる

■アプリケーションの常駐/非常駐運用、マルチオブジェクト常駐運用

トランザクションアプリケーションの場合、クライアントからの要求で、メモリ上にローディングされるアプリケーションをメモリ上に常駐させるか、非常駐にさせるかを、ワークユニットで定義できます。また、常駐の場合も１つのプロセス上で１つのアプリケーションをローディングするか、１つのプロセス上で複数のアプリケーションをローディングするかを定義できます。

・常駐運用1つのプロセスに1つのアプリケーションを常駐できます。

連続してクライアントからの要求が多い場合には、常駐運用が有効です。ワークユニット定義に指定しなかった場合の初期値は、常駐運用になります。

・非常駐運用アプリケーションは、クライアントからの要求があるごとにメモリ上にローディングされ、アプリケーション終了後にメモリ上から消去されます。システム資源などを省資源化したい場合で、クライアントからの要求が少なく、アプリケーションの種類が多い場合に有効です。非常駐のプロセスは、多重で起動できます。ただし、各プロセスではサーバアプリケーションの処理が完了するまで、次のクライアントからの要求は処理されません。そのため、クライアントからの要求数に応じたプロセスの多重度を設定します。また、それぞれのアプリケーションが格納される実行モジュールについては、実行モジュールを分ける必要があります。

・マルチオブジェクト常駐運用１つのプロセス上で複数のオブジェクトを処理できます。マルチオブジェクト常駐運用では、常駐運用に比べローディングするアプリケーションプロセスの数を少なくできるため、メモリ消費を削減できます。アプリケーションの種類が多く、クライアントからの要求も多い場合には、マルチオブジェクト常駐運用により、システム資源を省資源化できます。マルチオブジェクト常駐のプロセスは、多重で起動できます。ただし、サーバアプリケーションの処理が完了するまで、次のクライアントからの要求は処理されません。そのため、クライアントからの要求数に応じたプロセスの多重度を設定してください。また、それぞれのアプリケーションが格納される実行モジュールについては、実行モジュールを分ける必要があります。



IJServer(EJBアプリケーションだけ運用）

Java VM

Webブラウザ

2.17.2 IJServer2.17.2 IJServer

[Webアプリ、EJBアプリを同一JavaVMで運用]・ EJBアプリケーションは別のIJServerのアプリ

ケーション(またはEJBのクライアントアプリケーション)から呼び出すことはできない

・ EJBアプリケーションだけ配備して運用することはできない

[Webアプリ、EJBアプリを別JavaVMで運用]・EJBアプリケーションだけ配備されていた場合

には、EJBのJavaVMだけ起動される

・Webアプリケーションだけ配備されていた場合には、WebのJavaVMだけ起動される

[Webアプリケーションだけ運用]・EJBアプリケーションを配備しようとした場合、

EJBアプリケーションの配備処理はスキップされる

[EJBアプリケーションだけ運用]・Webアプリケーションを配備しようとした場合、

Webアプリケーションの配備処理はスキップされる

Webサーバ

IJServer(WebアプリケーションとEJBアプリケーションを同一JavaVM上で運用）

Java VM

Servletコンテナ EJBコンテナ

Webブラウザ

Webサーバ

IJServer(WebアプリケーションとEJBアプリケーションを別JavaVM上で運用）

Java VM

Servletコンテナ

Webブラウザ

Webサーバ

IJServer(Webアプリケーションだけ運用）

Java VM

Servletコンテナ EJBコンテナ

Java VM

EJBコンテナ

Servlet

JSPEJBアプリケーション

JSP

JSP

Servlet

Servlet



Interstage Application Serverでは、運用性の向上を目的として、J2EEアプリケーションを運用する環境であるInterstage Java Server(IJServerと略します)という概念を導入しています。IJServerはJ2EEアプリケーションの実行環境であるEJBコンテナとServletコンテナを内包し、これらのコンテナの

上位に位置づけられる論理的な概念です。

IJServerはワークユニット上で動作します。IJServerワークユニットとして動作することでワークユニットが提供している高度なアプリケーション運用操作/監視機能を利用できます。

IJServerには4つのタイプがあり、用途に合わせてタイプを選択できます。

■WebアプリケーションとEJBアプリケーションを同一JavaVMで運用

WebアプリケーションとEJBアプリケーションを同一のJavaVMで運用します。

Servlet/JSPからEJBを高速に呼び出すことができ、アプリケーションが動作するJavaVMが同一になるためメモリ資源を節約できます。Webアプリケーションだけの場合でも運用可能です。

EJBアプリケーションだけ配備して運用することはできません。また、EJBアプリケーションは、別のIJServerのアプリケーション(またはEJBのクライアントアプリケーション)から呼び出すことはできません。

■WebアプリケーションとEJBアプリケーションを別JavaVMで運用

WebアプリケーションとEJBアプリケーションが動作するJavaVMを別々で運用できます。アプリケーションが動作するJavaVMを別々にすることでメモリ資源を消費しますが、JavaVMごとにプロセス多重

度を設定することでプロセスダウンのリスクが分散でき、アプリケーション異常の影響を局所化することができるという利点があります。

EJBアプリケーションだけ配備されていた場合には、EJBのJavaVMだけ起動されます。Webアプリケーションだけ配備されていた場合には、WebのJavaVMだけ起動されます。

EJBアプリケーションは、別のIJServerのアプリケーションから呼び出すことができます。


■Webアプリケーションだけ運用

Webアプリケーションだけで運用できます。

別のIJServer(同一JavaVMで運用を除く)のEJBアプリケーションを呼び出すことができます。

■EJBアプリケーションだけ運用

EJBアプリケーションだけで運用できます。

EJBアプリケーションは、別のIJServerのアプリケーションから呼び出すことができます。

IJServerには、「V8.0互換モードのIJServer」も存在し得ます。

「V8.0互換モードのIJServer」とは、Interstage Application Serverの8.0までに提供してきたIJServer機能の互換性を保ったIJServerです。V9.0のIJServerは、Servlet2.4/JSP2.0を実装した業界標準であるTomcat5.5ベースのServlet実行環境に対応し、JDK/JRE 5.0をサポートするようになっていますが、「V8.0互換モードのIJServer」では対応していません。

「V8.0互換モードのIJServer」を使用する場合には、事前にTomcat4.1ベースのServletサービスがイン

ストールされている必要があります。(「V8.0互換モードのIJServer」では、Servlet2.3/JSP1.2を実装したTomcat4.1ベースのServlet実行環境で、JDK/JRE 1.4をサポートした環境を提供します。)



2.18 FJVM2.18 FJVM

Java HotSpot Server VMをベースに、富士通独自技術を組み込んだJava VM

◆ Java VM

OS-A OS-B OS-C

Java VM Java VM Java VM中間バイトコード中間バイトコード中間バイトコード

・Javaアプリケーション(中間バイトコード)はJava VM上で動作・OSごとに用意されたJava VMにより、各種OS上で中間バイトコードが実行可能

◆ Java VMの種類

安定性および、スループットの向上を考慮して設計されたサーバ環境向けのJava VMJava HotSpot Server VM

アプリケーション起動時間を短縮し、メモリ消費を抑制するように設計されたクライアント環境向けJava VM

Java HotSpot Client VM

説明Java VMの名称

◆ FJVMの特長

中間バイトコード

OS

FJVM・性能改善したGC(ガーベジコレクション)の実装・New世代領域サイズ自動調整・各種ログ/メッセージ出力

(Java VM異常終了/GC処理結果/メモリ領域不足/スタックオーバーフローなど)・コンパイラ異常発生時の自動リカバリ

など

Java言語で書かれたプログラムは、コンパイルすることで、JavaVMが認識/動作するための中間バイトコード (*.class)が作成され、Java VMが動作している環境であれば、OSに依存しないで動作できます。

Java VMとは、「Java Virtual Machine」を略したもので、Javaで書かれたプログラムを実行する仮想

マシンを意味します。

各OSに対応したJavaVMを利用することで、Java言語で作成したプログラムは、プラットフォームに依

存しないで動作できます。

Java VMには、大別してJava HotSpot Client VM とJava HotSpot Server VM の2種類あります。

■ Java HotSpot Client VMアプリケーション起動時間を短縮し、メモリ消費を抑制するように設計されたクライアント環境向けのJava VMです。

■ Java HotSpot Serverアプリケーション起動時間の短縮などよりも、安定性および、スループットの向上を考慮して設計されたサーバ環境向けのJava VMです。

Interstage Application Serverでは、Sun Microsystems, Inc.のJava VMであるJava HotSpot ServerVMをベースに、富士通独自技術による性能改善やJava VMのトラブルシューティングに関する機能強化などを追加実装したFJVMを提供し、デフォルトで使用しています。

また、Java HotSpot Client VMに富士通独自技術によるトラブルシューティングに関する機能強化などを追加実装した富士通版Java HotSpot Client VMも提供しています。富士通版Java HotSpot Client VMを使用したい場合は、javaコマンドのオプションに“-client”を指定します。

FJVMが提供する独自のGC(ガーベジコレクション)機構やJavaヒープ領域の調整、各種ログ出力、コンパイラの異常検出/リカバリ機能などにより、Java業務アプリケーションを安全かつ効率よく運用できます。



2.18.1 Java VM 起動オプション2.18.1 Java VM 起動オプション

【 JavaVM起動オプション（Javaヒープ/スタック関連）】

初期ヒープサイズを指定します。-Xms

大ヒープサイズを指定します。-Xmx

New世代領域のヒープサイズを指定します。-XX:NewSize (注1)

New世代領域の大ヒープサイズを指定します。-XX:MaxNewSize (注1)

New世代領域とOld世代領域のサイズ比率を指定します。-XX:NewRatio (注1)

New世代領域を構成するEden領域とSurvivor領域のサイズ比率を指定します。-XX:SurvivorRatio (注1)(注2)

ガーベジコレクション(GC)処理後の生存オブジェクトがSurvivor領域を占める割合を、指定したパーセンテージ値に調整します。

-XX:TargetSurvivorRatio (注1)

Permanent世代領域の初期値を指定します。-XX:PermSize

Permanent世代領域の大値を指定します。-XX:MaxPermSize

スレッドの大スタックサイズを指定します。-Xss

説明起動オプション

注1) FJGCを使用する場合、このオプションへの指定値は無効となります。注2) パラレルGCを使用する場合、このオプションへの指定値は無効となります。

【 FJVMでサポートされるGC処理を実行(指定)するための起動オプション】

(デフォルト)

-XX:+UseFJGC(64ビットモードでは未サポート)

-XX:-UseParallelGC

JDK/JRE 5.0JDK/JRE 1.4

(未サポｰﾄ)New世代領域用GC制御に対し、「当該処理を並列化して実行する機能」を追加して構成されたGC処理

パラレルGC

(デフォルト)New世代領域用GC制御に対し、富士通独自技術による「New世代領域サイズ自動調整機能」を追加して構成されたGC処理

FJGC

-XX:-UseFJGCNew世代領域用GC制御に対して何も付加機能を追加していない「標準機能のみ」で構成されたGC処理

シリアルGC(標準GC)

指定オプション説明GCの種類

Javaで作成した業務アプリケーションを安定して動作させるには、業務アプリケーションを動作させるJava VMのメモリサイズ(ヒープサイズやスタックサイズ)を適切に設定することも必要になってきます。

Java VMが使用するメモリサイズは、Java VM 起動オプションによりチューニングできます。

ここでは、Java VM 起動オプションの使用例として、ヒープサイズの初期値/ 大値の設定例を示します。

ヒープサイズの初期値/ 大値の設定には、以下のオプションを利用します。

–Xms ：初期Javaヒープサイズ設定

–Xmx ：大Javaヒープサイズ設定

JavaVMは、起動時に「–Xms」で指定された初期ヒープサイズのヒープ領域を確保します。インスタンスなどをたくさん使用し、この初期ヒープサイズを使い切ると自動的に拡張され、大で「–Xmx」で指定した

大ヒープサイズまで拡張します。

たとえば、Javaアプリケーションの実行中に、JavaVMがヒープサイズ不足となる場合には、-Xmxの値

を増やすことが有効です。

[ java –Xmx256m ･･･]のように指定します。

“256m”は、256MBを意味します。ギガ単位の領域が必要な場合には、“g”を使用して“1g” (1GB)のよ

うに指定することも可能です。

Javaヒープサイズは、小さすぎるとGC(ガーベジコレクション)が頻発しパフォーマンスが悪くなり、大きすぎるとGCに時間がかかりパフォーマンスが悪くなるという性質があります。極端な値の設定はしないでく

ださい。

初期ヒープサイズと大ヒープサイズを近づけることで、ヒープサイズ拡張によるオーバーヘッド、およびGC発生回数を軽減できます。

<指定例>[ java –Xms512m –Xmx512m ・・・ ]



2.19 JDKツール(解析用ツール) (1/4)2.19 JDKツール(解析用ツール) (1/4)

Qualyzer ：性能情報の収集/表示機能、メモリダンプ機能を提供◆ 性能情報の収集

・Java VM起動オプションに「 -Xrunfts:[OPTIONS] 」を指定

性能情報収集のログの出力先ファイル名を指定log=file

g=0:性能情報収集を一時停止させた状態で起動g=1:起動時から性能情報収集(省略値)

g=0|1

b=0 :ssbを利用しない場合に指定(省略値)b=1or3:Java VMが単独で動作している環境で、ssbを利用す

る場合に指定b=2or4:Java VMが複数で動作している環境で、ssbを利用す

る場合に指定(ssb :性能情報収集の一時停止/再開/出力を行うコマンド)

b=0|1|2|3|4

heap=0:メモリ/GC情報を収集しない(省略値)heap=1:メモリ/GC情報を収集heap=2:メモリ/GC情報を2秒ごとに収集heap=3:メモリ情報のみを2秒ごとに収集

heap=0|1|2|3

リモートマシンでメモリ/GC情報を収集する場合にポート番号をnに指定

port=n

リモート情報収集機能を利用する場合に、リモートホスト名またはIPアドレスをhostに指定

server=host

cpu=0:CPU情報を収集しない(省略値)cpu=1:CPU情報を収集

cpu=0|1

サンプリング情報を収集する際のインターバル時間(ミリ秒)をnに指定(n=0:収集しない(省略値))

sample=n

メソッドトレース情報を収集する際のトレースの深さをnに指定(n=0:収集しない(省略値))

trace=n

性能情報格納先ディレクトリを、folderに指定d=folder

説明OPTIONS

◆ 性能情報の表示・「 fts.jar 」を実行

◆ ヒープ(ダンプ)情報の収集・Java VM起動オプションに

「 -Xrunholmes[:t=depth][,f=0|1][,d=folder][,b=0|1|2|3|4] 」を指定

◆ ヒープ情報のHTML/CSVファイル生成

・「 holmes.jar 」を実行

◆ ヒープ情報の表示

・「 holmes.jar -h html-folder 」を実行

Interstage Application Serverでは、Javaプログラムのチューニングやトラブルシューティングに有用なツールとして、以下のツールを提供しています。

■ QualyzerJavaプログラムの性能ボトルネック部分を検出し、利用者のプログラムチューニングや性能問題解決を支援するツールです。Qualyzerは、以下の2つの機能を持ちます。

・性能情報分析機能

以下の4種類のデータを採取し、Javaプログラムの性能チューニングを支援します。

－メモリ/GC情報メモリ割当量、メモリ使用量およびGC実行時間帯を採取します。これらにより、プログラム実行の全体を通じて、メモリ(ヒープ)の使用量が安定しているか、GCが効果的に動作しているか(たとえば、GCが動作することで使用メモリ量が減少しているかなど)を確認します。

－ CPU情報Javaプログラムの各メソッドで消費されるCPU時間(CPU命令走行時間)を調べ、メソッド単体の実行時間およびメソッドの呼び出し回数を採取し、高コストなメソッドを検出します。

－サンプリング情報時間(ミリ秒)刻みのサンプリング情報をメソッドレベルで採取します。簡易的な高コストメソッドの検出機能です。

－メソッドトレース情報Javaプログラムで使用される全メソッドのスタックトレースを採取します。

サーバアプリケーションの性能情報収集は、Java VM起動オプションで以下を指定します。

OPTIONSには、表1で表したオプションが指定可能です。

収集した情報は、fts.jar を実行し、GUI画面上で確認できます。

・メモリ(ヒープ)ダンプ機能

Javaプログラムのメモリ(ヒープ)使用に関する性能トラブルの原因究明を支援します。オブジェクト割当数、オブジェクト残存数、オブジェクトを生成したメソッドのスタックトレース、オブジェクトの参照情報、およびオブジェクトの内容を採取します。メモリを圧迫しているオブジェクト(群)が、どこで作成され、なぜGCで回収されないのかを調査する場合に有効です。

-Xrunfts:[OPTIONS]


サーバアプリケーションのヒープ情報収集は、Java VM起動オプションに以下を指定します。

t=depth ：call stack情報を精査する深さを、depthに指定(省略値:t=5)f=0|1 ：f=0:ヒープ情報を収集する直前に、GCを起動しない

f=1:ヒープ情報を収集する直前に、GCを起動(省略値)d=folder ：ヒープ情報格納先ディレクトリを、folderに指定b=0|1|2|3|4 ：b=0 :ssbを利用しない場合に指定(省略値)

：b=1or3:Java VMが単独で動作している環境でssbを利用する場合に指定：b=2or4:Java VMが複数で動作している環境でssbを利用する場合に指定

収集した情報は、HTMLファイルやCSVファイルとして保存できます。HTMLファイルやCSVファイルを生成するには、以下のように holmes.jar を実行します。

-i input-folder ：ヒープ情報格納先ディレクトリを、input-folderに指定-o output-folder ：HTML/CSVファイル格納先ディレクトリを、output-folderに指定-heap ：ヒープ情報をフレームなしHTMLファイルに構成frame ：ヒープ情報をフレームありHTMLファイルに構成(heapオプションのサブオプション)-csv ：ヒープ情報をCSV形式のファイルに構成

収集したヒープ情報(HTMLファイル)は、以下のように holmes.jar を実行し、GUI画面上で確認できます。

-h html-folder ：HTMLファイル格納先ディレクトリを、html-folderに指定-i input-folder ：ヒープ情報格納先ディレクトリを、input-folderに指定-view ：HTMLファイルを表示frame ：フレームありHTMLファイルを表示(viewオプションのサブオプション)

-Xrunholmes[:t=depth][,f=0|1][,d=folder][,b=0|1|2|3|4]

java -jar holmes.jar [-i input-folder] [-o output-folder] [-heap[,frame]|-csv]

java -jar holmes.jar -h html-folder [-i input-folder] -view[,frame]




jheap ： Javaヒープ使用量を出力

% jheap 123<new> [used: 847728] [free: 1511568] [total: 2359296]<old> [used: 33699152] [free: 2820784] [total: 36519936]<perm> [used: 6460336] [free: 93264] [total: 6553600]<new> [used: 847728] [free: 1511568] [total: 2359296]<old> [used: 33699152] [free: 2820784] [total: 36519936]<perm> [used: 6460336] [free: 93264] [total: 6553600]<new> [used: 847728] [free: 1511568] [total: 2359296]<old> [used: 33699152] [free: 2820784] [total: 36519936]<perm> [used: 6460336] [free: 93264] [total: 6553600]・・・

% jheap 123<new> [used: 847728] [free: 1511568] [total: 2359296]<old> [used: 33699152] [free: 2820784] [total: 36519936]<perm> [used: 6460336] [free: 93264] [total: 6553600]<new> [used: 847728] [free: 1511568] [total: 2359296]<old> [used: 33699152] [free: 2820784] [total: 36519936]<perm> [used: 6460336] [free: 93264] [total: 6553600]<new> [used: 847728] [free: 1511568] [total: 2359296]<old> [used: 33699152] [free: 2820784] [total: 36519936]<perm> [used: 6460336] [free: 93264] [total: 6553600]・・・

【 jheapコマンド実行時の出力例】

new :New世代領域old :Old世代領域perm:Permanent世代領域

used :現在の使用量 (byte)free :現在の空き容量(byte)total :現在の領域長 (byte)

◆ New世代領域、Old世代領域、Permanent世代領域の使用状況を確認可能

【 Javaヒープの構造】

Javaヒープ

New世代領域 Old世代領域 Permanent世代領域

インスタンス(オブジェクト)を格納

Javaのクラス、メソッドや定数など静的オブジェクトを格納

・New世代領域：生成されて比較的新しいオブジェクトを格納

・Old世代領域：一定期間New世代領域で生存したオブジェクトを格納

・Permanent世代領域：Javaのクラスなど、永続的に参照される静的オブジェクトを格納

New世代領域は、さらにEden領域(生成されたばかりのオブジェクトを格納) とSurvivor領域(1度以上GCを経験し生き残ったオブジェクトを格納) に分けられます。

<参考>


Point！

■ jheapjheapは、実行中のJavaプログラムのヒープ使用状況を出力するツールです。FJVMがサポートするGC処理に対して動作し、FJVM以外のJava VMでのGC処理には対応していません。

jheapは、jheapモジュールをコマンドプロンプトから以下の形式で起動して使用します。

-i interval ：測定の間隔を秒単位でintervalに指定(省略時:5秒間隔)-c count ：出力する回数をcountに指定(省略時:指定したプロセス(pid)が終了するまで出力)-t ：タイムスタンプを出力する場合に指定(省略可能)pid ：プロセスIDを指定

jheapは、pidで指定した動作中のJavaプログラムのヒープ使用状況を一定時間の間隔で標準出力に出力します。Interstage管理コンソールのIJServerモニタ画面で、各ワークユニットのプロセスIDを確認できます。

total として出力される情報は、現在メモリがマッピングされている量であり、大値ではないことに注意してください。測定対象のJavaプログラムが終了すると、jheapも終了します。jheapの実行を途中で終了するには、jheapを実行したコマンドプロンプトで[Ctrl]+[C]を押下します。

Javaヒープの使用状況は、以下で確認することができますが、プログラム起動時に指定するか、あらかじめソースコードに仕込む必要があります。

・Java VM 起動オプションで指定：-verbose:gc・Javaソースコード中で呼び出し：java.lang.RuntimeパッケージのtotalMemory() / freeMemory()

jheapにより、Javaプログラムのヒープ使用状況を、プログラムの起動後に調査することができます。

Javaヒープは、New世代領域、Old世代領域、Permanent世代領域の3つに大別されます。これら3つの領域は、インスタンス生成によるメモリ確保やGC処理などにより増減します。New世代領域には、生成されてからの時間が比較的短いインスタンスが格納されます。

Old世代領域には、生成されてからの時間が比較的長いインスタンスがGC処理により、New世代領域から移動されます。

Permanent世代領域は、Javaのクラスや定数などの不変な情報が格納される領域です。Javaプログラムで使用するクラスの種類が多かったり、クラスのサイズが大きかったりする場合に不足する場合があります。

記録された値をもとに、ヒープ域の使用状況と実際の処理の経過時間とを比較し、繁忙時のヒープの使用状況を確認できます。もし結果がヒープ域の大値に近接した値であれば、ヒープ域の大値を拡張し、余裕を持たせる必要があります。

jheap [-i interval] [-c count] [-t] pid




thdump ： Javaプログラム/Java VMのスレッドダンプを採取するツールを提供

Windows Only・Windowsでは、サービスとして動作するJavaプログラム(Servlet/EJBなど)や、Webブラウザ上で動作するJavaプログラム(アプレット)に対して、スレッドダンプを取得する方法がない。

→ thdumpで、これらのプログラムでもスレッドダンプを取得可能

・Windows Vistaで導入された”セション0分離”に対応するため、Windowsサービスとして動作するスレッドダンプツール「thdumpSVC」を提供


FJVM

Servlet / EJB

IJServer ワークユニット

サーバ

スレッドダンプ

Interstage Application Server(テスト環境)

FJVM

Servlet / EJB

IJServer ワークユニット

クライアント (Windows Vista / Interstage Studio)

スレッドダンプ

【運用環境】【開発環境】

VMスレッドダンプ

スタックトレース

thdump.exe ・・・ thdumpSVC –Install

sc start thdumpService ・・・

VMスレッドダンプ

スタックトレース

■ thdumpthdumpは、スレッドダンプ(各スレッドのスタックトレース)を採取するツール(コマンド)です。スレッドダンプには、Java VM上で動作するJava VM内部のスレッドや、Javaプログラムの各スレッドのスタックトレースが出力されます。スレッドダンプを解析することで、プログラム全体や、各スレッドの実行状況をある程度解析することができます。

thdumpは、コマンドプロンプトから以下の形式で起動して使用します。

または

-f logfile ：スレッドダンプの出力先を指定(省略時:標準出力または標準エラー出力に出力)-jオプションと同時に指定不可

-j ：ヘッダおよびフッタをJava VMの出力ルーチンを用いて出力する場合に指定JNI(Java Native Interface)のJNI_CreateJavaVM()関数に、vfprintf_hookオプションを指定して起動したJava VMに対して指定JBKプラグインのjbkplugin.propertiesファイルに、“jbk.plugin.debug.showvmmsg=true”と指定した場合は、このオプションを使用

-p processid ：対象とするプロセスをプロセスIDで指定program namewith “.exe” ：対象とするプロセスをjava.exeなど".exe"で終わるコマンド名で指定

また、Windows Vistaでは“セション0分離”が導入されたため、Windowsサービスとして動作するサーバアプリケーション(ワークユニットとして動作しているServletやEJBなど) のスレッドダンプを採取するには、スレッドダンプツールもWindowsサービスとして動作する必要があります。そのため、Windowsサービスとして動作するthdumpSVCコマンドも提供しています。thdumpSVCは、［ thdumpSVC –Install ］コマンドでWindowsサービスとして登録後、以下のコマンドを起動して使用(開始)します。

または

スレッドダンプの採取を停止するには、［ sc stop thdumpService ］コマンドを実行します。

thdump.exe [-f logfile | -j] -p processid

thdump.exe [-f logfile | -j] program name with ".exe"

sc start thdumpService [-f logfile | -j] -p processid

sc start thdumpService [-f logfile | -j] program name with ".exe"




FJTRACE ： Javaアプリケーションのメソッド呼び出しをトレースする

Javaアプリケーション

ユーザ作成クラスファイル(バイトコード)

FJVM

ユーザ作成クラスファイル(バイトコード)

メソッドトレースクラスライブラリ

バイトコード変換メソッド

トレース情報出力メソッド

メソッドトレース用クラスファイル(バイトコード)



java –XX:FJTRACE=○○

トレース情報

Javaコマンドのオプションで、メソッドトレース機能を使用することを指示

読み込み

呼び出し

書き出し

変換メソッドで、クラスファイルをメソッドトレース用クラスファイルに変換

［1.］

［2.］［3.］

［4.］［5.］

［6.］

・アプリケーション(Servlet/EJBなど)のメソッド呼び出し情報および引数、戻り値の情報を出力

→ トラブル発生時のメソッド呼び出し状態、授受データの確認により問題発生箇所を確認

■ FJTRACE (メソッドトレース機能)メソッドトレース機能とは、Javaアプリケーションのメソッドの呼び出しをトレースする機能です。メソッドトレース機能が出力するトレース情報により、次のことがわかります。

・アプリケーションの処理の流れ

・Java Servlet APIのメソッドに渡される引数、およびメソッドから返される戻り値の情報

・EJBアプリケーションのメソッドに渡される引数、およびメソッドから返される戻り値の情報

たとえば、次のような現象が発生する場合、処理がどこまで実行されているか、どの処理で停止や異常が起こっているかを診断するうえでの有用な情報を得ることができます。

・アプリケーションの応答がなくなった場合

・出力や処理結果の異常

・Exceptionの発生

メソッドトレース機能のモジュールは、JDK/JRE インストールディレクトリ内の「tools」>「fjtrace」内に格納されています。メソッドトレース機能は、以下のような流れで実現します。

1. Java VMにメソッドトレース機能を有効に起動オプションを指定して、アプリケーションを起動します。

・ JDK/JRE 5.0環境の場合に指定する起動オプション

・ JDK/JRE 1.4環境の場合に指定する起動オプション

制御ファイルとは、メソッドトレース機能の動作を定義するためのファイルで、あらかじめ準備しておく必用があります。(メソッドトレース機能の格納先に、制御ファイルのサンプル(fjtrace.conf)があります。)

2. アプリケーションのクラスファイル(バイトコード)が、クラスローダ経由でJava VMに読み込まれます。

3. Java VMからメソッドトレースクラスライブラリのバイトコード変換メソッドが呼び出されます。

4. バイトコード変換メソッドによって、アプリケーションのバイトコードに、メソッドトレースクラスライブラリのトレース情報出力メソッドを呼び出すコードが埋め込まれます。

-agentlib:TraceAgent=制御ファイル名または

-agentpath:C:¥Interstage¥jdk5¥tools¥fjtrace¥TraceAgent.dll=制御ファイル名

-XX:FJTRACE=制御ファイル名


5. 変換されたバイトコードがJava VMに渡され、アプリケーションが開始されます。

6. 開始されたアプリケーションのバイトコード内に、トレース情報出力メソッドの呼び出しコードがあると、メソッドトレースクラスライブラリによって、トレース情報が出力されます。

トレース情報として出力される情報には、以下の2種類があります。

・enter情報

トレース対象に指定されたメソッドが呼び出されたことを示す情報で、以下の形式で出力します。

・exit情報

トレース対象に指定されたメソッドから復帰したことを示す情報で、以下の形式で出力します。

Java VMは、enter情報およびexit情報を見つけるたびにトレース情報を出力します。正常にトレース情報が出力された場合、enter情報とexit情報は、対となって出力されます。

引数および戻り値を出力するかどうかは、制御ファイルで指定します。

以下に、NumGameというServletのトレース出力例を示します。

このトレース情報より、以下のことがわかります。

・“19/10/2006 10:59:59:670, in, Thread-20, NumGameParameter, getParameter”が出力されていることから、NumGameParameter#getParameterメソッドは呼び出されている。

・他方、対となるNumGameParameter#getParameterに対する“..., out, ...”が出力されていないことから、NumGameParameter#getParameterメソッドが復帰していない。

以上より、NumGameParameter#getParameterメソッドの中で処理が止まっていたことがわかります。

EJBやJavaアプリケーションの場合も同様です。 “in, ...”に対して“out, ...”がなく、ログが出力されていない

ような場合、応答がないということがわかります。

[日時,]in,スレッド名,クラス名,メソッド名[,PARAM:引数の情報]

[日時,]out,スレッド名,クラス名,メソッド名[,RET:戻り値の情報]

19/10/2006 10:59:53:922, in, Thread-20, NumGame, doGet19/10/2006 10:59:54:032, in, Thread-20, pkgNumGameBean.NumGameBean, <init>19/10/2006 10:59:55:434, out, Thread-20, pkgNumGameBean.NumGameBean, <init>19/10/2006 10:59:58:408, in, Thread-20, NumGameParameter, <init>19/10/2006 10:59:58:418, out, Thread-20, NumGameParameter, <init>19/10/2006 10:59:59:630, in, Thread-20, NumGameParameter, setRequest19/10/2006 10:59:59:640, out, Thread-20, NumGameParameter, setRequest19/10/2006 10:59:59:670, in, Thread-20, NumGameParameter, getParameter



2.20 バックアップ・リストア2.20 バックアップ・リストア


IJServer

バックアップ用ディレクトリ

JSP/Servlet

Webサーバ Enterprise

BeanEnterprise

Bean

サーバインターネットイントラネット

環境設定

環境設定

・Interstageの資源ごとにバックアップ/リストアするコマンドを提供・Interstage資源を一括してバックアップ/リストアするバッチファイル/シェルスクリプトを提供

クライアント媒体退避

Interstage Application Serverでは、Interstage資源の破壊など万一の事態が発生した場合に、早急に運用環境を復元できるように、Interstage資源をバックアップ/リストアするツールを提供しています。

Interstage資源のバックアップ・リストアは、バックアップ用ディレクトリに資源ファイルをバックアップ(退避)しておき、資源の復旧が必要な場合に資源ファイルをバックアップ用ディレクトリからリストア(復元)します。

Interstage資源のバックアップ・リストアツールを使用することで、以下のWebサーバ(Interstage HTTP Server)資源、IJServer資源のバックアップ/リストアが可能です。

■Webサーバ(Interstage HTTP Server)資源・Interstage HTTP Serverの環境定義ファイル

－ Windows ：C:¥Interstage¥F3FMihs¥etc¥.servers.confC:¥Interstage¥F3FMihs¥servers¥(Webサーバ名)¥conf配下の全ファイル

－ Solaris/Linux ：/etc/opt/FJSVihs/etc/.servers.conf/etc/opt/FJSVihs/boot/FJapache/var/opt/FJSVihs/servers/(Webサーバ名)/conf配下の全ファイル

・パスワードファイル環境定義ファイル(httpd.conf)のAuthGroupFileディレクティブおよびAuthUserFileディレクティブで指定したファイル

・公開用ルートディレクトリ環境定義ファイル(httpd.conf)のDocumentRootディレクティブで指定したディレクトリ

環境定義ファイル(httpd.conf)のAliasディレクティブで指定した仮想ディレクトリは、バックアップ対象ではありませんので、仮想ディレクトリを使用時は別途バックアップをとっておく必要があります。

■IJServer資源(Interstage Application Server V9のIJServerの資源)・IJServer環境定義ファイル

[J2EE共通ディレクトリ]内の「ijserver」 > 「[IJServer名]」直下の環境定義ファイル[J2EE共通ディレクトリ]内の「ijserver」 > 「[IJServer名]」 > 「conf」配下

・アプリケーション[J2EE共通ディレクトリ]内の「ijserver」 > 「[IJServer名]」 > 「apps」配下

・クライアント配布物[J2EE共通ディレクトリ]内の「ijserver」 > 「[IJServer名]」 > 「distribute」配下

・ユーザ格納資源[J2EE共通ディレクトリ]内の「ijserver」 > 「[IJServer名]」 > 「Shared」配下[J2EE共通ディレクトリ]内の「ijserver」 > 「[IJServer名]」 > 「ext」配下


Interstage資源のバックアップ・リストアは、資源ごとに用意されたバックアップコマンド・リストアコマンド

を使用します。

■資源ごとのバックアップ / リストアコマンド (対象資源名：バックアップコマンド / リストアコマンド)・Interstageセットアップ資源： iscbackupsys / iscrestoresys・Interstage管理コンソール資源： isguibackup / isguirestore・Interstage JMXサービス資源： isjmxbackup / isjmxrestore・業務構成管理のリポジトリ資源： isrepbackup / isreprestore・CORBAサービス資源： odbackupsys / odrestoresys・イベントサービス資源： esbackupsys / esrestoresys・Portable-ORB資源： copyコマンドなどを使用してバックアップ用ディレクトリにファイルを

コピー / 復元します。・コンポーネントトランザクションサービス資源： tdbackupsys / tdrestoresys・データベース連携サービス資源： otsbackupsys / otsrestoresys・Interstage シングルサインオン資源： ssobackup / ssorestore・Interstage HTTP Server資源： ihsbackup / ihsrestore・J2EE共通資源ファイル： j2eebackup / j2eerestore・IJServer資源： ijsbackup / ijsrestore・Interstage JMS資源： jmsbackup / jmsrestore・Interstage SOAPサービス資源： issoapbackup / issoaprestore・UDDIサービスの資源： copyコマンドなどを使用してバックアップ用ディレクトリにファイルを

コピー / 復元します。・Interstage ディレクトリサービス資源： irepbacksys / ireprestsys

(リポジトリデータのバックアップは、リポジトリデータを格納しているRDBのバックアップ/リストア方法に従う。)

・Interstage証明書環境資源： copyコマンドなどを使用してバックアップ用ディレクトリにファイルをコピー / 復元します。

・負荷計測エージェント環境設定資源： svagbackup / svagrestore

なお、Interstage Application Serverでは、資源のバックアップとリストアを一括して行うためのバッチファイル(Windows)およびシェルスクリプト(SolarisおよびLinux)のサンプルを提供します。

使用者は、バッチファイルおよびシェルスクリプトに対して、それぞれの環境に適した手順を記述し、実行することで必要な資源を一括で(一度の実行操作で)バックアップ・リストアすることができます。

資源のバックアップ・リストアを一括実行するためのサンプルは、Interstage Application Serverをインス

トールしたマシンにある以下のファイルです。

■Windows環境用バッチファイル

・バックアップC:¥Interstage¥sample¥backup_restore¥isbackup.bat

・リストアC:¥Interstage¥sample¥backup_restore¥isrestore.bat

■Solaris環境用シェルスクリプト

・バックアップ/opt/FJSVisas/sample/backup_restore/isbackup

・リストア/opt/FJSVisas/sample/backup_restore/isrestore

バックアップ・リストア対象資源については、バックアップ・リストア対象定義ファイルに定義します。バックアップ・リストア対象定義ファイルは、任意の名前で作成できます。サンプルは以下にあります。

/opt/FJSVisas/sample/backup_restore/sample.def■Linux環境用シェルスクリプト

・バックアップ/opt/FJSVisas/sample/backup_restore/isbackup

・リストア/opt/FJSVisas/sample/backup_restore/isrestore



iscollectinfo コマンド

2.21 一括情報採取ツール2.21 一括情報採取ツール


IJServer

JSP/ServletWeb

サーバ

EnterpriseBean

EnterpriseBean

サーバインターネットイントラネット

設定情報

設定情報

クライアント

調査用情報

iscollectinfo

ログログ各種ログ

ログログ各種ログ

システム情報

システム情報

システム情報

調査用情報を一括収集

※

Interstage HTTP Serverのアクセスログ、エラーログ、トレースログは、出力先を初期値から変更した場合、iscollectinfoコマンドでは採取されません。

※：

【形式】

iscollectinfo [-M system] [-d directory]

格納先ディレクトリを指定する場合に記述

対象システムを指定する場合に記述 (Solarisのみ)

Interstage Application Serverでは、Interstage運用中に何かしらのトラブル発生時に、富士通技術調査員が調査のために必要とする資料一式をまとめて採取することができる一括情報採取ツール (iscollectinfoコマンド)を用意しています。トラブル発生時、技術員連絡を行う前に本コマンドを使用して調査資料の採取を行っておくことで、トラブル調査をスムーズに進めることができます。

iscollectinfoは以下の場所に格納されています。

■Windows の場合 (インストールパスはデフォルト)C:¥Interstage¥bin

■Solaris / Linux の場合 (インストールパスはデフォルト)/opt/FJSVisas/bin

iscollectinfoコマンドでは、以下のオプションを指定することができます。

■「-d」オプション調査資料の格納先ディレクトリを指定します。以下の形式で格納されます。

・Windowsの場合<指定ディレクトリ>¥collect¥<YYYYMMDDHHMMSS>

・Solarisの場合<指定ディレクトリ>/collect/<YYYYMMDDHHMMSS>/<system>

・Linuxの場合<指定ディレクトリ>/collect/<YYYYMMDDHHMMSS>/default

<YYYYMMDDHHMMSS>は年4桁・月2桁・日2桁・時間2桁・分2桁・秒2桁の形式です。例えば2007年4月23日12時34分56秒の場合、20070423123456になります。<system>は運用の対象となるシステム名です。「-d」オプションを指定しない場合は対話形式で格納先ディレクトリの問い合わせがあります。デフォルトではカレントディレクトリ配下となっています。問い合わせに答えて格納先ディレクトリを指定してください。

■「-M system」オプション (Solarisの場合のみ指定可能)Interstage Application Serverの拡張システムを生成した場合に、対象となるシステム名を指定します。「-M」オプションを省略するとデフォルトシステムが対象となります。「-M」オプションは、 Interstage Application Server Enterprise Editionで指定可能です。

なお、Interstage HTTP Serverのアクセスログおよびエラーログ、トレースログのログファイルの出力先を初期値から変更した場合、iscollectinfoコマンドでは採取できません。その場合、別途ログファイルを採取してください。


■注意事項

・本コマンドはトラブルが発生した直後に実行してください。

・本コマンドは管理者権限で実行してください。

・資料採取時に以下のメッセージが出力されることがありますが、問題はありません。qff32022u・qff32301iメッセージについてはプラットフォームがSolarisの場合はIDCM使用手引書を、Windowsの場合はIDCMヘルプを参照してください

－ IJServer10007, IJServer10008, IJServer10134－ es10924－ od10712, od10713, od10717, od10719, od10723, od10724, od10725, od10726, od10727,

od10728, od10900, od10901, od10905, od10966－ ots9343, ots9378－ qff32022u, qff32301i

・資料格納先に1024バイトを超えるディレクトリ名は指定できません。1024バイトを超えるディレクトリ名を指定した場合、is30893メッセージを出力してエラーとなります。

・資料格納先に<YYYYMMDDHHMMSS>ディレクトリがすでに存在している場合、is30892メッセージを出力してエラーとなります。別端末で同時期にiscollectinfoコマンドを実行している場合や、OSの

時計が正しくない場合などが該当します。

・Windowsの場合、Interstageインストール先を資料格納先に指定できません。Interstageインストール先を資料格納先に指定した場合、is30896メッセージを出力してエラーとなります。

・Solarisの場合、“/FSUN”または“/FJSV”という文字列が含まれるディレクトリ名を資料格納先に指定できません。“/FSUN”または“/FJSV”という文字列が含まれるディレクトリ名を資料格納先に指定した場合、is30896メッセージを出力してエラーとなります。

・Linuxの場合、“/FJSV”が含まれるディレクトリ名を資料格納先に指定できません。“/FJSV”という文字列が含まれるディレクトリ名を資料格納先に指定した場合、is30896メッセージを出力してエラーとなり

ます。

■備考

・採取時間の目安は5分程度です。ただし、マシン環境により目安以上に時間を要する場合があります。

・デフォルトの設定から変更がない場合、採取に必要なディスク容量の目安は100Mバイト程度です。デ

フォルトの設定内容から変更して各種のログサイズを大きくした場合等はより多くのディスク容量を必要としますので資料格納先のディスクには十分な空きを用意してください。


MEMO



第３章Interstage Application Serverの

高度な機能

本章ではInterstage Application Serverが提供する高度な機能について説明します。



3.1 業務処理能力を保証する異常監視・再起動3.1 業務処理能力を保証する異常監視・再起動

システムに異常（異常終了、ループ、デッドロックなど）が発生しても人手を介することなく業務を再起動し、業務処理と処理多重度を保証

復旧中でもクライアント要求は継続して受け付け

実行中


デッドロック


クライアント



強制終了・再起動自動復旧

実行中実行中異常発生

アプリケーション管理機能（ワークユニット）による異常監視と自動復旧を提供

Interstage Application Serverでは、アプリケーション管理機能により、アプリケーションに異常(異常終了、ループ、デッドロックなど)が発生した場合でも自動復旧する機能を提供し、業務処理と処理の多重度を保証します。また、復旧中でもクライアントの要求を継続して受け付けることが可能です。

■業務アプリケーションの自動復旧

業務アプリケーション運用中の異常(異常終了、ループ、デッドロック)を早期に検知し、自動的に業務を再起動(復旧)します。復旧中も業務リクエストを受け付けることができるため、業務の停止や遅延を回避し、高い信頼性を保証します。

業務アプリケーション自動復旧(再起動)は、以下のアプリケーションで利用可能です。

・CORBAアプリケーション・J2EEアプリケーション(IJServer)［Webサービスアプリケーションを含む］・トランザクションアプリケーション・ラッパーオブジェクト・一般アプリケーション(Interstage Application Server配下外のアプリケーション)

■システム資源の予兆監視・自動拡張

運用中、負荷にあわせ自動的にシステムメモリなどのシステム資源をチューニングし、自動拡張します。そのため、運用の前に資源見積もりをする必要がありません。また、システム資源の消費を監視し、資源不足によるアプリケーション異常を事前に回避し、資源不足による運用停止などの問題を未然に防止できます。

■JavaVMの予兆監視

JavaVMのヒープ使用量、および、Perm領域を監視し、ヒープ不足、およびそれにともなうガーベジコレクションの多発による業務レスポンス低下の可能性を検出し、ヒープ領域の問題を警告メッセージで通知します。警告メッセージはイベントログに出力されます。警告メッセージに記載されている不足リソースの情報をもとにチューニングを実施することにより、Javaアプリケーションの安定運用を実現します。

さらに、Javaヒープ、またはPerm領域が不足した場合のIJServerの制御を、以下のオプションから選択できる機能が提供されています。

・プロセスを再起動

・アプリケーションにjava.lang.OutOfMemoryErrorを返却する


警告メッセージは、以下の基準で出力されます。

以下の条件をすべて満たす場合。・過去3回のガーベジコレクション間

隔時間が20000ミリ秒より短い・過去3回のガーベジコレクション時

間の平均値が500ミリ秒より長い・System.gcによって発生したGCの

頻度が高い

System.gcが短い間隔

で発生しています。

System.gc() are run with the short intervals: TIME={0} INTERVAL={1}TIME: 発生時刻INTERVAL: System.gcのインターバル時間(ミリ秒単位)

過去3回のガーベジコレクション間隔時間が20000ミリ秒より短い場合。

ガーベジコレクションが短い間隔で発生しています。

The garbage collections are run with the short intervals: TIME={0} INTERVAL={1}TIME: 発生時刻INTERVAL:ガーベジコレクションのインタバール時間(ミリ秒単位)

Perm領域の使用量が90%より大きい

場合。

Perm領域不足のため、OutOfMemoryが発生

する危険性があります。

There are possibilities of OutOfMemoryError because of the lack of the Perm region: TIME={0} SIZE={1}TIME: 発生時刻SIZE: 警告発生時に不足していたPerm領域サイズ(バイト単位)

ガーベジコレクション直後のヒープ使用率が95%より大きい場合。

または、ガーベジコレクション直後のヒープ使用率が90%より大きく、かつ、

前回のガーベジコレクション発生時よりヒープ使用サイズが増加している状態が3回以上続いた場合。

メモリ不足のため、OutOfMemoryが発生


There are possibilities of OutOfMemoryError because of the lack of the memory: TIME={0} SIZE={1}TIME: 発生時刻SIZE: 警告発生時に不足していたヒープサイズ(バイト単位)

過去3回のガーベジコレクション間隔時間が20000ミリ秒より短い場合、か

つ、ガーベジコレクション直後のヒープ使用率が65%より大きい場合。

メモリ不足のため、ガーベジコレクションが短い間隔で発生しています。

The garbage collections are run with the short intervals because of the lack of the memory: TIME={0} SIZE={1}TIME: 発生時刻SIZE: 警告発生時に不足していたヒープサイズ(バイト単位)

過去3回のガーベジコレクション間隔時間が20000ミリ秒より短い場合、かつ、ガーベジコレクション直前のOld世代のヒープ使用率が65%よりも小さい

場合。

非効率なガーベジコレクションが短い間隔で発生しています。

Inefficent garbage collections are run with the short intervals: TIME={0} WEIGHT={1}TIME: 発生時刻WEIGHT: ガーベジコレクション直前の旧世代の使用率(%単位)

過去3回のガーベジコレクション時間の平均値が5000ミリ秒より長い場合。

ガーベジコレクションに長い時間かかる状態が続いています。

It takes long time to do the garbage collections many times: TIME={0} AVERAGE={1}TIME: 発生時刻AVERAGE: 過去3回の平均ガーベジコレクション時間(ミリ秒単位)

前回の測定からのPerm領域の使用量の増加が、Perm領域全体の１割よ

り大きく、かつ、次も同じ割合で増えると仮定したときのPerm領域の使用率が、90%より大きい場合。

Perm領域の使用量が

急増しているため、OutOfMemoryが発生


OutOfMemoryError warning is occuredbecause the Perm region is exhausted: TIME={0} SIZE={1}TIME: 発生時刻SIZE: 急増したPerm領域サイズ(バイト単位)

発生条件警告の意味詳細メッセージ



Ｊ２ＥＥ / Ｃ / Ｃ＋＋ / ＣＯＢＯＬアプリケーションをシステムを止めることなく入れ替え可能

3.2 システムの連続運用を保証する活性保守3.2 システムの連続運用を保証する活性保守



入れ替え対象のアプリケーションA

旧モジュール


システム管理者

入れ替え指示

１操作で入れ替え可能

業務アプリケーションの入れ替え

入れ替え対象のアプリケーションA’

新モジュール

Interstage Application Serverでは、システムを停止することなく、J2EE/C/C++/COBOLアプリケーションの入れ替えが可能です。J2EEアプリケーションの修正やインタフェース変更が発生しても、業務を

停止することなく、動的に入れ替えすることができるため、システム変更に伴うコスト削減と環境変化への柔軟な対応が可能となります。

■HotDeploy機能

運用中のWebアプリケーション、またはEJBアプリケーションを別のアプリケーションに入れ替える場合、運用中のアプリケーションを停止することなく、入れ替えることができます。(活性変更できます。)これに

より運用の連続性を保ち、アプリケーション開発におけるアプリケーションのテストが効率的に実施可能となります。

なお、活性変更はJ2EEアプリケーション以外では、トランザクションアプリケーションだけが可能です。

また、インタフェースが変更された場合は活性変更できません。




IJServer

3.3 セキュリティの強化3.3 セキュリティの強化

【セキュリティ監査証跡機能】

Webサーバ

Servlet EJBDB

Systemwalker Centric Manager

分析

分析

記録記録

ログ集約

SymfowareServer

監査ログ監査ログ

Symfowareの監査ログに

WebサーバのIPアドレス・

WebサーバのリクエストID・Web認証ユーザ名・IJServer

名を記録

【 Secure By Default 】

V8まで

インストール

環境設定

アプリ配備

セキュリティを高める設定変更

監査

インストール

環境設定

アプリ配備

監査

V9大幅削減インストール時にデフォルトで設定

・業務のすべてのリソースへの適切なアクセス許可設定

・運用操作者の限定・運用に伴う通信の暗号化など

Interstage Application Serverでは、セキュリティ強化のため、以下の機能を強化して提供しています。

■セキュリティ監査証跡機能

以下の機能で自動的に出力される監査ログから不正アクセス/不正操作の痕跡を追跡できます。

・アクセスログ保護資産へのアクセスについて、「いつ(アクセス日時)」「どこで(クライアントIPアドレス)」「だれが(ユーザ識別情報)」「なにを(アクセス対象やリクエスト内容)」「どうした(処理結果)」を記録します。

・ログインログInterstage JMXサービス(Interstage管理コンソール)に対するログイン要求を、「いつ」「だれが」「どこ

から」発行したか、また、その「結果」がどうであったかを記録します。

このほか、Interstage Application ServerからSymfoware Serverのデータベースへアクセスを行う場合、SymfowareServerの監査ログに以下の情報を記録できます。

・WebサーバのIPアドレス・WebサーバのリクエストID・Web認証ユーザ名・IJServer名

また、Systemwalker Centric Manager V13以降を使用すると、分散されたサーバから監査ログを収集して一元管理することができるため、分散したサーバのログであってもログの収集/分析が容易です。

■ Secure By DefaultInterstage Application Server (Solaris / Linux)では、Interstage資源ファイルが、外部ネットワークからの侵入者によって破壊(資源ファイルの書き替え・削除など)されてシステムが運用不能になる危険を減

らすために、インストール時に強化セキュリティモードを指定することで、以下を実施できます。

・業務のすべてのリソースへの適切なアクセス許可を設定・運用操作者を限定・運用に伴う通信の暗号化適用



3.4 マルチサーバ管理3.4 マルチサーバ管理

Interstage管理コンソール

業務クライアント

サイトサーバグループ管理サーバ

サーバグループ

管理対象サーバ






単体運用の管理対象サーバ

リザーブサーバ

スタンドアロンサーバ

マルチサーバ管理機能では、複数サーバ（マルチサーバ）で構成されたシステム上で運用するInterstageや業務を統合的に運用管理する機能を提供しています。

複数サーバで運用している業務を、単一のInterstage管理コンソール上で統合的に管理することがで

きます。また、これらの業務の運用管理操作を、論理的な業務の単位で一括して行うことができます。これによりスケールアウトの容易な実現、そしてシステムの導入、維持、管理のためにかかる費用(TCO)の削減を図ることができます。

マルチサーバ管理機能を利用して、以下の運用ができます。

■同一業務を複数サーバ上で並列に運用する場合、これらのサーバを仮想的な1つの業務として運用

操作できます。マルチサーバ管理を使用しない場合、サーバごとに個別に運用操作する必要があります。

■IJServerは1つの業務がWebサーバ（Webサーバコネクタ）/Webアプリケーション/EJBアプリケーショ

ンなどで構成されます。これらのアプリケーションの資源を多階層のサーバに分散して配置できます。

マルチサーバ管理機能では、多階層構成となったIJServerのアプリケーションを、1つのIJServerとして運用操作できます。マルチサーバ管理を使用しない場合、これらのIJServerは、サーバごとに別々のIJServerとなり、運用操作を個別に行う必要があります。

本機能には、複数サーバで運用している同一サービスや同一業務、複数サーバにまたがる業務の運用操作を簡易化し、複数あるサーバ内の一部のサーバに対する業務の起動漏れや、アプリケーションの配備漏れなどを防ぐ効果があります。

マルチサーバ管理は「サイト」と「サーバグループ」という機構を提供します。

サイトとはマルチサーバ管理の管理する範囲を示し、1台の管理サーバによって管理されます。サイトには複数のInterstageをインストールしたサーバを所属させることができます。サイトに所属しているサーバ

のことを管理対象サーバと呼びます。また、同一の業務を実行する複数の管理対象サーバをひとまとめにして一括して運用管理できます。そのまとめた単位のことをサーバグループと呼びます。

保守状態にある管理対象サーバで、サイトに所属しているが業務を実行していないサーバをリザーブサーバと呼びます。


Interstageをインストールしているサーバでサイトに所属していないサーバのことをスタンドアロンサーバ

と呼びます。

また、マルチサーバ管理機能では、Systemwalker Software Deliveryと連携したアプリケーション配付・

世代管理を提供しています。

■アプリケーション資源の一括配付

Systemwalker Software Deliveryの資源配付機能により、アプリケーションとアプリケーション以外の資

源を一括して、複数のサーバへ配付することができます。このことにより、複数サーバへのアプリケーション資源の配付がより効率的に行えるようになります。

■アプリケーションの世代管理Systemwalker Software Deliveryは、配付したアプリケーションを複数世代にわたって管理できます。こ

のことにより、サーバに複数の世代が配付されていない場合には、世代順に適用して世代抜けが発生しないように配付することができます。



3.4.1 IJServerの多階層システム設計（リレーション）

3.4.1 IJServerの多階層システム設計（リレーション）

■ ライン型Webサーバ Servletコンテナ EJBコンテナ

Webサーバ Servletコンテナ EJBコンテナ

Webサーバ Servletコンテナ EJBコンテナロード

バランサ

サーバグループサーバグループサーバグループ

■ メッシュ型

EJBコンテナ

EJBコンテナ

EJBコンテナ

Webサーバ

Webサーバ

Webサーバ

Servletコンテナ

Servletコンテナ

Servletコンテナ

サーバグループ

TrafficDirector

ロードバランサ

サーバグループサーバグループ

■ Traffic Directorを使用する EJBコンテナ

EJBコンテナ

EJBコンテナ

Webサーバ Servletコンテナ

Webサーバ Servletコンテナ

Webサーバ ServletコンテナTraffic

DirectorTraffic

Director

ロードバランサ

サーバグループサーバグループサーバグループ


マルチサーバ管理機能において、IJServerを多階層システムで運用する場合、各階層のサーバ間の連携方式（リレーション）を「ライン型」、「メッシュ型」、「Traffic Directorを使用する」の方式から選択し

ます。

■ライン型

前段のサーバグループに所属する管理対象サーバと、後段のサーバグループに所属する管理対象サーバを1対1で関連付ける方式です。関連付けられる管理対象サーバは、サーバグループ内通番が

同じ管理対象サーバです。業務データは、関連付けられたサーバ間でだけ通信されます。

ライン型はIJServerを運用する以下のサーバ間で指定できます。

・Webサーバ（Webサーバコネクタ）とServletコンテナの間

・ServletコンテナとEJBコンテナの間

■メッシュ型

前段のサーバグループに所属する管理対象サーバと、後段のサーバグループに所属する管理対象サーバを網羅的にn対mで関連付ける方式です。業務データの通信は、前段のサーバから後段のサー

バ群に対し、分散して行われます。

メッシュ型は、IJServerを運用するWebサーバ（Webサーバコネクタ）とServletコンテナの間で指定でき

ます。

■Traffic Directorを使用する

Traffic Directorを使用して負荷分散を行う方式です。Traffic Directorを使用する場合は、前段の

サーバグループに所属する管理対象サーバと後段のサーバグループに所属する管理対象サーバを網羅的にn対mで関連付ける方式です。業務データの通信は、前段のサーバから後段のサーバ群に対し、

分散して行われます。


Traffic Directorの使用は、以下のサーバ間で指定できます。

・Webサーバ（Webサーバコネクタ）とServletコンテナの間

・ServletコンテナとEJBコンテナの間

ライン型、メッシュ型、Traffic Directorの使用は、サーバグループ間ごとに指定します。たとえば、WebサーバとServletコンテナ間はメッシュ型とし、ServletコンテナとEJBコンテナ間はライン型とするシステム

構成も構築できます。



業務を停止することなくシステムの適化を実現

Systemwalker Resource Coordinator サーバプールからサーバグループへ移動する時の業務環境の構築をサポート


サーバの高負荷が発生しても、迅速なサーバ追加により処理能力を確保サーバの用途変更などにともなうサーバ再配置の簡易化

サーバ故障時、迅速な代替サーバの組み込みによりアップタイムを向上

※サーバグループ：同一業務を運用するサーバ群を示す枠組みサーバプール：空き（予備）サーバを管理するグループ

サーバの増強業務環境の構築

Systemwalker Resource Coordinator

サーバグループサーバプール

3.4.2 プロビジョニング3.4.2 プロビジョニング

コピー

管理サーバ

業務環境

業務環境

業務環境

再配置

Interstage Application Serverは、Systemwalker Resource Coordinatorのリソースプロビジョニング機能と連携することで、富士通のIT基盤であるTRIOLEのプロビジョニングに対応します。

Systemwalker Resource Coordinatorのプロビジョニングでは、Interstage Application Serverを運用するサーバのスケールアウト(サーバの追加と削除)を行う機能を提供します。

プロビジョニングを利用することで、以下のような効果が期待できます。

■アプリケーションサーバの負荷が増大しても、空きサーバをアプリケーションサーバとして迅速に追加することで、サービス品質を維持できます。

■アプリケーションサーバの再配置が容易に行えます。

■アプリケーションサーバの故障が発生した際に、代替アプリケーションサーバを迅速に構築できます。

■複数サーバの資源を有効活用できます。

アクセス集中や、サーバ異常などによるレスポンス低下に対して、ハードウェアの追加/変更だけでなく、

業務環境も動的に整備するため、簡単で安全にシステムの安定稼動が実現できます。

なお、サーバプロビジョニングを行う場合には、以下のサーバ構成にする必要があります。

■管理サーバ

Interstage Application Serverの管理サーバは、Systemwalker Resource Coordinatorのサイト管

理サーバと同一サーバ上に配置します。管理サーバは、プロビジョニングの制御を行うサーバであり、プロビジョニングの対象とはなりません。

■管理対象サーバ

Interstage Application ServerおよびSystemwalker Resource Coordinatorのサイトに配置します。

プロビジョニング機能によるサーバ追加／削除の対象となります。



3.5 シングルサインオン3.5 シングルサインオン

■ 利用者の利便性向上■ 利用者の管理／保守に関する運用コストの削減■ セキュリティ機能のための開発コストを削減■ なりすましやセキュリティアタックへの耐性を強化(セション管理など)

リポジトリサーバ

認証サーバ

負荷分散

追加

システム管理者

システムA

システムB

利用者

認証情報を一元管理

マスタ

スレーブ認証は初回のアクセス時だけ

ID1パスワード１

スケーラブルに構築可能

ユーザ情報のメンテナンスは簡単

Interstage Application Serverでは、企業システムを構成する複数のWebサーバ、Webサービスに対して、認証・認可の基盤となるInterstageシングルサインオンを提供します。一度のサインオン(認証)で、複数のWebサーバおよびWebサービスへのアクセスを可能(認可)とします。

認証サーバやリポジトリサーバ(ユーザ情報を格納するサーバ)は、ユーザの増大などにより、スケーラブ

ルな構成やデータベースを利用できます。規模や運用形態に応じた柔軟な構成が可能です。

Interstage シングルサインオンを導入することで以下の効果があります。

■利便性の向上

利用者は、使用するWebシステムや、WebサービスごとにユーザID/パスワードを管理する(覚えておく)必要がなくなり、利便性が向上します。利用者は1つのユーザID /パスワードで、さまざまなWebシステム、Webサービスを安心して利用できます。

■運用コストの削減

管理者は、人事異動などによる利用者の追加/変更/削除に対するシステムの管理/保守を一元化する

ことが可能となり、それらに要するコストを削減できます。

■開発コストの削減

セキュリティ機能のための開発をシステムごとに実施する必要がなくなり、開発のコストを削減できます。

■高度なセキュリティレベルの実現

一元的にセキュリティレベルを向上させることができるため、新のセキュリティアーキテクチャに迅速に対応できます。

Interstageシングルサインオンでは、業務サーバ/認証サーバ/リポジトリサーバと呼ばれる3つのサーバ機能を提供しています。(認証サーバ/リポジトリサーバ機能は、Interstage Application Server Standard-J Edition/Enterprise Editionで提供しています。)利用者は、Webブラウザで各Webシステム、Webサービス(業務サーバが提供するシステム)のURLを指定するだけで、認証サーバやリポジトリ

サーバを意識する必要はありません。


Interstage シングルサインオンでは、以下の認証方式で利用者を認証できます。

■パスワード認証

利用者をユーザID/パスワードにより認証する方式で、利用者が使用するコンピュータが不特定な場合

に簡単に認証が行えます。簡単に認証が行える反面、パスワードが盗まれ、本人に成りすまされるという危険性があります。

パスワード認証を運用するにあたり、利用者がユーザID/パスワードを入力する画面として、フォーム認証ページを使用します。しかし、セションの管理を行わないシステムにおいてのみ、ユーザID/パスワード

を入力する画面として基本認証ダイアログを使用することができます。

■証明書認証

利用者を証明書により認証する認証方式で、使用するコンピュータが特定される場合に便利です。Interstage シングルサインオンでは、ICカードに格納された証明書を使用して認証することができます。認証に必要な情報をICカードに格納して携帯することで、第三者に不正に使用されることを防ぐことがで

きます。この認証方式では、提示された証明書から利用者が特定できることで認証されたとみなします。

また、セションの管理を行わないシステムにおいては、利用者が使用するWebブラウザにあらかじめ証

明書を登録しておくことで認証を行うことができます。

なお、Interstage シングルサインオンでは、以下で発行された証明書をサポートしています。

・Systemwalker PKI Manager(インターネット／イントラネットで証明書管理を実現する富士通製ソフトウェア)

・日本ベリサイン株式会社

・日本認証サービス株式会社

■パスワード認証または証明書認証

パスワード認証、または証明書認証のどちらかが成功した場合に、認証されたものとする方式です。

証明書認証で認証を行っている利用者が、出張先のコンピュータからリソースにアクセスする場合や、ICカードを携帯しているがICカードが利用できないコンピュータからアクセスするような場合、または、ICカ

ードを忘れてしまった場合や、何らかの理由で証明書が使用できない場合にパスワード認証でアクセスができるため柔軟な運用が可能です。

■パスワード認証かつ証明書認証

パスワード認証と証明書認証のどちらも成功した場合にだけ認証されたものとする方式です。より厳密な認証を行いたい場合に適しています。

■統合Windows認証

利用者がWindowsにログオンする際に指定するユーザID/パスワードを使用して、利用者を認証する方式で、利用者はWindowsログオンすることで、Interstage シングルサインオンを使用することができま

す。

Windowsログオンした後、利用者のWebブラウザにて保護リソースにアクセスした場合、統合Windows認証時のサインオン確認画面が表示されます。統合Windows認証を行う場合は、「はい」ボタンをクリックすることで、サービスを利用することができます。また、「いいえ」をクリックし、統合Windows認証でサ

インオンしない場合には、パスワード認証、または証明書認証で再度認証する運用ができます。

なお、クライアントで使用できるWebブラウザは、Internet Explorerのみです。また、統合Windows認証を行う場合は、ユーザID/パスワードを入力する画面として基本認証ダイアロ

グを使用することはできません。



3.6 Systemwalker Centric Manager連携による稼動監視/性能監視

3.6 Systemwalker Centric Manager連携による稼動監視/性能監視

性能監視のグラフ

（トランザクション量）

運用管理サーバ運用管理クライアント

業務サーバ(Interstage Application Server)


アラーム通知

異常発生

Systemwalker Centric Manager を利用することにより、Interstage Application Server上で運用さ

れているアプリケーションの稼動管理・性能管理を行うことができます。これにより、万一トラブルが発生した場合でもネットワーク経由で復旧できるなど、システムの運用性を大幅に高めることができます。

イベント監視、資源配付、リモート操作などの標準機能で、日々の運用や異常時のリカバリを効率よく行えます。また、リアルタイムのシステムの監視や、迅速なトラブル復旧を行うことで、24時間365日利用者に

継続したサービスを提供できます。

Interstage Application Serverでは、 Systemwalker Centric Managerと連携して、以下の機能が使用できます。

■稼動監視

・ワークユニットおよびオブジェクトの稼動状態監視 (IJServerは除きます。)以下のワークユニット(オブジェクト)の稼動状態を監視できます。

－CORBAアプリケーション

－トランザクションアプリケーション

－ラッパーオブジェクト (Windows版、Solaris版)－ユーティリティワークユニットで動作する一般アプリケーション (Solaris版)－非同期アプリケーション (Solaris版)

■性能監視

・アプリケーション処理状況のリアルタイム監視以下に対しての滞留キュー数(待ちメッセージ数)をリアルタイムに監視できます。(IJServerは対象外です。)－CORBAワークユニットのインプリメンテーションリポジトリ

－トランザクションワークユニットのオブジェクト

Systemwalker Centric Managerの機能により、リアルタイムに異常事象の発生を知ることができます。また、任意のリカバリ処理などを作成して、Systemwalker Centric Managerへ登録することにより、異

常発生時に、自動的にリカバリ処理を実行することも可能です。



3.7 Systemwalker Operation Manager連携による自動運転

3.7 Systemwalker Operation Manager連携による自動運転

【各ワークユニット（サーバ）の起動／停止をスケジューリング】


運用管理クライアント

スケジューラ

運用管理サーバ

業務業務業務

2:00～3:00 3:00～4:00 4:00～5:00

Interstage Application Serverでは、Systemwalker Operation Managerとの連携により、以下の

ようなシステムの運用・管理作業を自動化できます。

■自動運転

・ワークユニットの自動実行/監視/操作

ワークユニットをジョブネット内のジョブとして登録することにより、ワークユニットの自動起動や、監視、操作が可能となります。

・ワークユニットおよびバッチジョブ間の資源の排他制御

ワークユニットとバッチジョブをグループとして実行することもできます。この時、ワークユニットとバッチジョブの間の排他制御が可能となります。

なお、ジョブとして登録できるワークユニットは、以下のワークユニットに限ります。

・ユーティリティワークユニット（Solaris版/Linux版だけ）

・CORBAワークユニット

IJServerワークユニットはジョブとして登録できません。

Systemwalker Operation Managerの機能により、スケジュールに沿ったワークユニットの運用(起動・停止)が行えます。




Java VM

3.8 Systemwalker Service Quality Coordinator連携による性能分析／レスポンス監視

3.8 Systemwalker Service Quality Coordinator連携による性能分析／レスポンス監視

Agent

Systemwalker ServiceQuality Coordinator

業務クライアント

リクエスト

レスポンス

■EJB/CORBAアプリケーション・処理時間・待ち時間・要求数 etc■IJServer・JavaVMヒープ/Perm/ガベージコレクション etc

性能分析やレスポンス監視

これらのコンポーネントの処理時間を測定し、1つのトランザクションとして関連付け

ServletコンテナWebアプリケーション

(Servlet/JSP) EJBコンテナ EJBアプリケーション

業務アプリケーションの性能状況については、Interstage管理コンソールでモニタすることができます。さらにSystemwalker Service Quality Coordinatorと連携すれば、さらにさまざまな観点からの比較や

傾向分析が可能となります。

Systemwalker Service Quality Coordinatorは、ITシステムの提供するサービス品質を可視化し、シ

ステム全体の適化を支援する製品です。

Systemwalker Service Quality Coordinatorと連携することにより、Javaヒープ量/GC状況/処理量/CPU使用率などの業務アプリケーション性能をレポーティングしたり、システムリソースと業務アプリケー

ション性能の関係を分析することができます。

例えば、業務アプリケーションの処理量とCPU使用率の関係を可視化することで、今後の業務処理量の

拡大に備えて設備増強するなどの判断材料に使うことができます。

また、Systemwalker Service Quality Coordinatorと連携することにより、業務のレスポンスを監視す

ることができます。さらに、レスポンスに問題が発生した場合には、ドリルダウンすることでボトルネック箇所を特定することができます。

例えば、Webサーバ、APサーバ、DBサーバのどの階層に問題があるのか、また、その問題が、システ

ムリソースが枯渇したことによる問題なのか、排他制御などの業務アプリケーションのロジックの問題なのか、などを切り分けることができます。

これらのレスポンス監視やボトルネックの分析機能は、業務アプリケーションに修正を加えることなく、Systemwalker Service Quality Coordinatorを導入するだけで利用可能です。


MEMO

interstage certified professional アプリケーション...

Documents