V6Guide_13_SIBus.pdf

by user

on 15 сентября 2016

Category: Documents

>> Downloads: 7

views

Report

Comments

Description

Download V6Guide_13_SIBus.pdf

Transcript

V6Guide_13_SIBus.pdf

3 SIBus 構成
この章では、メッセージング及び Web サービスについて説明します。WebSphere Application Server
(以下 WebSphere AS) V6.0 では、SIBus の機能によりメッセージングを WebSphere AS 単独で実行するこ
とが可能になるだけでなく、Web サービスも同じ基盤の上で実行することが可能となります。この章では、
WebSphere AS V6.0 の新機能である SIBus を中心に構成方法を説明します。
3-1 概要
この節では、メッセージングと Web サービスの概要について説明します。
3-1-1 メッセージング
メッセージングとは、メッセージを介したソフトウエア・コンポーネントやアプリケーション間の通信方式
の１つであり、疎結合の分散コミュニケーションを実現します。つまり、メッセージの送信者と受信者は、
通信のために同時に利用可能状態にある必要は必ずしもありません。送信者は受信者に関して何も
知る必要はなく、また受信者も送信者に関して知っている必要はありません。送信者と、受信者が知っ
ておかなければならないのは、メッセージのフォーマットと宛先(キュー)のみです。この点が、EJB のクラ
イアントとサーバーのように、相手のリモート・メソッドを直接呼び出すような緊密な結合をするテクノロジ
ーと異なるところです。
3-1-1-1 メッセージングのタイプ
•
非同期タイプ
送信者が受信者に対してメッセージを送信す
ることで処理が完了するタイプの処理方法で、一
方向型通信と呼ばれることもあります。バッチ処
理やメール送信など、実際の処理を後で実施す
ればよいアプリケーションに活用できます。
送信者
受信者
宛先（キュー）
•
同期（要求／応答）タイプ
通常のアプリケーションのように、送信者がメッ
セージを送信し、その処理結果を受信者から受
け取る同期タイプのオンライン処理も可能です。
ただし、この同期タイプでは要求宛先と応答宛
先は別になります。そのため要求処理と応答処
理は関連していないので、まったく別の処理とし
て実行されます。
要求宛先（キュー）
送信者
受信者
応答宛先（キュー）
-1-
3-1-2 JMS
JMS（Java Message Service）は、J2EE 仕様におけるメッセージングを実現する API として位置付けら
れています。アプリケーションは、JMS を使用し MOM（Message Oriented Middleware）製品と連携するこ
とによって、メッセージングシステムを構築することが可能です。代表的な MOM 製品としては、IBM
WebSphere MQ があります。
JMS においては、「宛先」があり、一つの送信アプリケーション(＝プロデューサー)が宛先に対して、
「メッセージ」を PUT します。もう一方の受信アプリケーション(＝コンシューマー)は、処理可能なタイミン
グで(→非同期)、その「メッセージ」を「宛先」から GET し、処理を実行します。
プロデューサー
コンシューマー
MOM
ドメイン
図 3-1 メッセージング概要
JMS は、JMS API と JMS プロバイダー、JMS クライアントから構成されます。
JMSプロバイダー
SIBus
JMS
JMS
JMS
WMQ
クライアント
JMS
クライアント
他社メッセージ
ング製品
メッセージング・サービス
図 3-2 メッセージング・サービスの構成要素
•
JMS プロバイダー
JMS のインターフェース、管理、制御の機能を提供するメッセージング・サーバー・コンポーネント
•
JMS クライアント
MS インターフェースを利用して、JMS サーバー・コンポーネントを利用するクライアント・コンポーネント
3-1-2-1 JMS のタイプ
JMS には 2 種類の処理モデルがあります。
•
Point-to-Point（PTP）
PTP では、宛先をキューと呼びます。メッセージを生成する側をセンダー、メッセージを消費(使用)する
側をレシーバーと呼び、センダーとレシーバーの関係が、1 対 1 となります。
PTP はキューをベースにしたモデルで、クライアントは特定のキューにメッセージを送信し、特定のキュ
ーからメッセージを受信します。
-2-
Point to point(PTP)ﾓﾃﾞﾙ
Receive
Send
JMS
ｸﾗｲｱﾝﾄ
ｷｭｰ
Send
Receive
JMS
ｸﾗｲｱﾝﾄ
図 3-3 Point to Point(PTP)モデル
•
Publish/Subscribe (Pub/Sub)
Pub/Sub では、宛先をトピックと呼びます。
メッセージを生成する側はパブリッシャー、メッセージを消費する側はサブスクライバーと呼ばれます。あ
るパブリッシャーがトピックに対してメッセージをパブリッシュします。次にサブスクライブ状態で待ってい
るすべてのクライアントがそのメッセージをサブスクライブします。Pub/Sub ドメインでは、サブスクライバー
の数が不特定であり、パブリッシャーとサブスクライバーの関係が 1 対多の関係にあります。Pub/Sub ドメ
インは、複数のアプリケーションで、同一のメッセージを共有利用するという要件にあったメッセージン
グ・ドメインです。
Publish/Subscribe(Pub/Sub)ﾓﾃﾞﾙ
JMS
ｸﾗｲｱﾝﾄ
JMS
ｸﾗｲｱﾝﾄ
Publish
ﾌﾞﾛｰｶｰ
ﾄﾋﾟｯｸB
ﾄﾋﾟｯｸA
JMS
ｸﾗｲｱﾝﾄ
Subscribe
JMS
ｸﾗｲｱﾝﾄ
JMS
ｸﾗｲｱﾝﾄ
図 3-4 Publish/Subscribe(Pub/Sub)モデル
3-1-2-2 JMS の特徴
•
XA 対応
X/Open における XA インターフェースを使用することによって、複数リソースにおける 2 フェーズコミット
処理を実現することが可能です。
•
高信頼性
アプリケーションは最寄りの MOM 製品と通信を行った段階で処理が完了します。そのため、MOM 製品
内での通信障害等に影響されることが無く動作することが出来ます。
•
高開発生産性
-3-
上記の各特徴からアプリケーションは通信環境上でのエラーを意識せずに開発することができ、シンプ
ルな構造となります。
3-1-3 MDB（Message-Driven Bean）
MDB（Message-Driven Bean）は、EJB 2.0 で新規に追加された JMS API を利用する EJB です。MDB
を利用することで、メッセージングシステムにアクセスする非同期の EJB アプリケーションを容易に開発
できるようになります。
MDB はイベント駆動タイプの処理方式になります。
MessageListener インターフェースを実装して、非同期メッセージ受信のアプリケーションを作成すること
ができます。メッセージを受信したという非同期のイベントを EJB コンテナーが検知して、onMessage メソ
ッドが呼び出され、そこに記述された受信ロジックが稼動します。
イベント！
アプリケーションサーバー
(W e b C o n t a in e r)
サーブレット1
インスタンス1
in it()
スレッド1
s e tM e s s a g e L is te n e r(th is )
スレッド2
J M S S e s s io n -1
o n M e s s a g e ()
図 3-5 イベント駆動型処理
3-1-4 利用可能な JMS プロバイダー
WebSphere AS V6.0 は、J2EE 1.4 準拠のアプリケーション・サーバー製品のため、JMS／MDB を稼動
させるために必要なフル機能の JMS プロバイダーが内蔵されています。その他にも WebSphere AS V6.0
では WebSphere AS 以外の JMS プロバイダーも利用可能です。
•
SIBus
WebSphere AS V6.0 に内蔵されているデフォルトの JMS プロバイダー
•
WebSphere MQ
多種多様な環境でメッセージングを扱うための MOM 製品
•
その他の JMS プロバイダー
WebSphere AS V6.0 では、上記以外にも複数の JMS プロバイダーがサポートされます。
「V5 デフォルト・メッセージング」JMS プロバイダーを使用し、WebSphere AS V5.x で使用して
いた組み込みメッセージング・サービスも使用することが可能です。ただし、これは WebSphere
AS V5.x からのマイグレーション時にのみ使用可能です。
「汎用」JMS プロバイダーは WebSphere MQ 以外の MOM 製品を利用する場合に使用されま
す。「汎用」JMS プロバイダーは特定の JMS プロバイダー向けに設定されていないので、ユーザ
ーが使用する MOM 製品にあわせて内容を設定する必要があります。
-4-
3-1-5 WebSphere MQ
WebSphere MQ は、異なる環境間でメッセージングを扱うためのメッセージング専用製品です。
WebSphere MQ を使用することにより、異なる OS 間でメッセージングを行うことが可能となります。また、
その OS ネイティブのアプリケーションを作成することも可能となります。さらに、クラスター環境を構成す
ることにより負荷分散および高可用性を実現できます。例えば、Linux 上の WebSphere AS で JMS を使
用した J2EE アプリケーションから、z/OS ネイティブのアプリケーションにメッセージを渡しシステム連携す
るシステムを構築できます。
WebSphere MQ を使用するためには、別途 WebSphere MQ 環境を構築し WebSphere AS の JMS プロ
バイダーを設定する必要があります。詳細は「3-3-2WebSphere MQ メッセージ・プロバイダー (p.75)」を
参照してください。
3-1-6 SIBus
SIBus は、WebSphere AS V6.0 が提供するデフォルトのメッセージング・エンジンです。
WebSphere AS V5 では、WebSphere MQ をベースとした組み込みメッセージング・サービスがデフォ
ルトのメッセージング・サービスとして提供されていました。WebSphere AS V6.0 では、新規に作成された
SIBus がデフォルトのメッセージング・エンジンとなっています。この SIBus は、JMS 環境で最高のパフォ
ーマンスを出せるよう設計され Java 言語で実装されています。
SIBus は、クラスタリング構成をとることにより負荷分散および高可用性のある構成を構築することが可
能となります。
SIBus は、現在 WebSphere AS V6.0 専用の環境ですが、WebSphere MQ 環境とリンクすることが可能
です。これにより、WebSphere MQ と連携したメッセージング環境を構築することが可能となります。
SIBus を使用するには、メッセージング・エンジンを構成し、デフォルトの JMS プロバイダーを設定する
必要があります。
3-1-7 Web サービス
Web サービスとは、XML 形式メッセージを使用した分散コンピューティングを実現するためのアーキ
テクチャです。Web サービスでは XML を使用することにより、軽量でインターオペラビリティの高いシス
テムを構築できます。また、Web サービスで実現されたシステムは疎結合となるため非常に柔軟性が高
くなるのが特徴です。下図は Web サービスのアーキテクチャを表したものです。Web サービスは、3 つの
コンポーネントと 3 つの基礎技術から構成されます。
-5-
サービスのプロフィール
(インターフェースetc.)
UD
サービスの登録
UD
DI
レジストリー
サービスの検索
DI
プロバイダー
WSDL
WSDL
サービスを利用する
アプリケーション
サービス
サービスの要求と実行
SOAP
リクエスター
図 3-6
Web サービスのアーキテクチャ
まず Web サービスを構成する 3 つのコンポーネントであるプロバイダー、リクエスター、レジストリーを
説明します。
プロバイダーは、サービスを提供するコンポーネントです。ここでいうサービスとは、株価照会とか飛行
機の予約状況確認など、Web サービスを介して不特定のコンポーネントやユーザーに提供されるサー
ビス（＝アプリケーション）を指します。プロバイダーは Web サービスにおけるサーバーにあたり、クライア
ントによって利用されるサービスを提供するのがその役割です。一方、プロバイダーの提供するサービ
スを利用するクライアントにあたるのが、リクエスターです。
レジストリーは、サービスを検索するためのキーワードとサービスを呼び出すために必要な情報（サー
ビス記述）のマッピングを格納するデータ・ストアです。サービス開発後、プロバイダーはこれらのマッピ
ング情報をレジストリーに登録します。リクエスターは必要に応じて適切なキーワードでレジストリーを検
索し、その応答としてサービス記述を得ます。サービス記述にはサービスの呼び出しに使用される URI
が含まれているので、これをもとにリクエスターはサービスを呼び出すことが出来るようになります。リクエ
スターによるレジストリーの検索とサービスの呼び出しは、実行時に行うことも出来ます（これを動的バイ
ンディングと呼びます）。
なお、Web サービスの基本的なアーキテクチャにはレジストリーが存在しますが、実際の Web サービ
ス環境においてはサービス情報（後述の WSDL）を何らかの手段で渡すことによりレジストリーが存在し
ないシステムを構築する場合が多々あります。ただし、その場合には動的バインディングを実行すること
ができません。
3-1-7-1 SOAP
SOAP (Simple Object Access Protocol) は、Web サービスのプロバイダーとリクエスター間での通信に
使用されるプロトコルです。
SOAP は XML 形式で送受信する情報を記述し、分散コンピューティングでの軽量情報交換のための
単純で拡張性の高いプロトコルとなっています。SOAP V1.1 は 2000 年 5 月に IBM や Microsoft 等によ
り W3C に技術ノートとして提案され標準なプロトコルとして扱われています。
SOAP は次に挙げる２つの特徴を持っています。
１つ目の特徴は SOAP 実装に XML を採用している点です。SOAP プロトコル上でやりとりされるメッセ
ージ・フォーマットは XML で記述されています。OS やハードウェア・プラットフォームに依存しない汎用
的なデータ形式である XML を採用することで、SOAP はインターオペラビリティ実現に適したプロトコル
と言えます。
-6-
2 点目は、SOAP プロトコルが下位プロトコルに依存しない点を挙げることが出来ます。SOAP 仕様書
では HTTP 上での SOAP バインディングを取り上げていますが、これは下位プロトコルを HTTP に限定
するものではなく、JMS や SMTP 等他のプロトコル上で SOAP 通信を行うことを許しています。
<SOAP-ENV:Envelope>
(SOAPエンベロープ）
<SOAP-ENV:Header> （SOAPヘッダー）
オプションの要素
<SOAP-ENV:Body> （SOAPボディ）
実質的な通信内容
・基本的に書式は自由
（RPCなどでは別途規定あり）
図 3-7 SOAP の構造
3-1-7-2 WSDL
WSDL (Web Service Description Language) とは、XML ベースのインターフェース記述言語です。
プロバイダーが提供するサービスのインターフェースを XML 形式で記述したものです。CORBA の IDL
や、RMI の Remote Interface に相当するものです。リクエスターはこの WSDL からプロバイダーに送受
信する SOAP メッセージを知ることができます。WSDL V1.1 は 2001 年 3 月に IBM や Microsoft 等によ
り W3C に技術ノートとして提案され標準なプロトコルとして扱われています。
WSDL では、記述する内容を大きく２つに分けています。
１つは、データ型やメッセージの形式を定めている抽象的な定義の部分です。この部分から Java での
メソッド名や引数、戻り値及び使用されるクラスの構造が分かります。もう１つは、その Web サービスに実
際にどのようにアクセスしたらよいかという具体的な記述部分です。この部分からは、プロバイダーがどこ
に存在して、どのようなプロトコルでアクセスしたらよいかが分かります。
インターフェースの抽象的な部分とサービス提供の具体的な部分が分かれることにより、サービス提
供の具体的な部分のみを変更することが柔軟に可能になります。
-7-
<definitions>
<types> 下位データタイプ定義
<message> 個々のデータフォーマットを定義
<portType> 論理操作単位の定義
オブジェクトに相当
operation要素（メソッドに相当）を定義
抽象的な定義
（言語やプラットフォーム
に非依存）
インターフェース定義
<binding> 論理モデルと物理モデルの結び付け
物理モデルの例： SOAP RPC
<service> 実際のアクセスポイント定義
<port> binding 要素と実際のURLの結びつけ
具体的な記述
（Webサイトに固有の情報）
図 3-8 WSDL の構造
3-1-7-3 UDDI
UDDI (Universal Description, Discover and Integration) とは、サービス記述を共有するためのフレー
ムワーク仕様で、レジストリー（UDDI レジストリー）仕様とレジストリーを操作するための API (UDDI API)
から構成されます。UDDI V1.0 は IBM、Ariba、Microsoft によって 2000 年９月に規定されました。その
後、2001 年６月に UDDI V2.0 仕様が、2002 年７月に UDDI V3.0 仕様が発表されています。
UDDI レジストリーは、サービス記述を格納するデータ・ストアで、大きくホワイト・ページ（ビジネス名等
の格納場所）、イエロー・ページ（業界、製品、サービス等の登録場所）、グリーン・ページ（サービスのイ
ンターフェース仕様の登録場所）の３つに分かれています。プロバイダーは、自身のサービスをここに登
録し、リクエスターは要件に応じたサービスを見つけるためにこのレジストリーを検索します。
UDDI レジストリーは必要に応じて自由に導入、運用することが出来ます。イントラネットや限定された
プロバイダーを対象として運用される UDDI レジストリーは、プライベート UDDI レジストリーと呼ばれま
す。
一方、Web サービスを使って世界規模のマーケットを立ち上げるためには、全世界共通の UDDI レジ
ストリー作成し運用しなければなりません。現在、IBM、Microsoft などの複数のブローカーがそれぞれ
共通の内容を格納する全世界規模の UDDI レジストリーを運営しています。これらはパブリック UDDI レ
ジストリーと呼ばれています
3-1-7-4 J2EE 1.4
J2EE では、v1.4 になり Web サービスの仕様が取り込まれました。J2EE 1.4 以前の環境では、Web サ
ービスの実装ごとに仕組みや API が違っており、その環境ごとに Web サービス・アプリケーションを作成
する必要がありました。しかし、J2EE 1.4 からは標準仕様で仕組みや API が決められているため、どの実
行環境でも使用できるアプリケーションを作成することが可能となります。
J2EE 1.4 で Web サービス・アプリケーションを作成する場合、通常 JAX-RPC と呼ばれる API を使用し
て Web サービスを作成します。JAX-RPC では、プロバイダー側は Web コンテナー上稼動する通常の
Java クラスか、EJB コンテナー上で稼動するステートレス・セッション・ビーンとして作成し、それを Web サ
ービスとして公開します。リクエスター側は、JAX-RPC の API を使用して作成しますが、基本的な構造は
EJB を呼び出す方式と似ています。JNDI で Lookup して Web サービスのインターフェースを取得し、ロ
-8-
ーカルのクラスの様にそのインターフェースにアクセスします。また、この使用法とは別に動的バインディ
ングのアプリケーションを作成することも可能です。
J2EE 1.4 では、Web サービス・アプリケーションに関する各種情報（Web サービスの名称やデータのマ
ッピング情報等）は、デプロメント・ディスクリプターに記述することになっています。
3-1-7-5 Web サービス実行環境
WebSphere AS V5 では Web サービスの実行環境として Apache SOAP が使用されていましたが、
WebSphere AS V6.0 では J2EE 1.4 に対応した WebSphere AS 独自実装の Web サービス実行環境を提
供しています。そのため WebSphere AS V6.0 で Web サービスを作成する場合は、J2EE 1.4 の API を使
用することになります。J2EE 1.4 として作成された Web サービスの EAR はそのままデプロイ可能ですが、
IBM 独自拡張のデプロメント・ディスクリプターを設定することも可能です。その場合は、WebSphere AS
V6.0 付属の AST（Application Server Toolkit）または Rational の開発ツールを使用します。
WebSphere AS V6.0 では、EAR を Web サービスとしてデプロイすれば他に特に設定しなくてもすぐに
Web サービスとして稼動させることが可能です。Web サービスとしてデプロイするには、EAR デプロイ時
のステップ１で「Web サービスのデプロイ」の項目にチェックを入れるだけです。
図 3-9 Web サービスのデプロイ
WebSphere AS V6.0 では、上記のようにして J2EE 1.4 準拠の通常の Web サービスとして稼動させる
以外に SIBus 上で Web サービスのアプリケーションを稼動させることも可能です。SIBus 上で稼動させる
ことにより、通常の Web サービス（SOAP/HTTP）よりも堅牢なメッセージングの基盤を使用して信頼性の
高いシステムを構築することが可能です。また、SIBus 上の JMS の様な Web サービス以外のアプリケー
ションと連携することも可能となるので、疎結合で柔軟なシステムを簡単に構築できるようになります。
Web サービスを SIBus 上で稼動させるには、SIBWS（SIBus Web Services）の環境を構築する必要が
あります。詳細は、「3-4SIBWS 構成 (p.83)」を参照してください。
-9-
3-2 SIBus(メッセージング)構成
この節では、SIBus 上に WebSphere AS のデフォルトの JMS プロバイダーとして、メッセージング・エン
ジンを構成する方法を説明します。
3-2-1 トポロジー
SIBus を構成し、バス・メンバーとしてアプリケーション・サーバーやクラスターを追加することで、メッセ
ージング・エンジン（ME）が構成されることになります。
3-2-1-1 基本トポロジー
SIBus のバス・メンバーとしてアプリケーション・サーバーを追加することで構成するトポロジーです。
SIBus
SIB1
ノード
Host01
Client
(ブラウザ)
DB2
[DataStore]
アプリケーションサーバー
Server1
JMS App
JDBC
SIB1ME1
[SCHEMA]
ME
図 3-10 ME の基本トポロジー
3-2-1-2 高可用性構成
SIBus のバス・メンバーとしてクラスターを追加することで、クラスターメンバーに ME が構成されます。
この状態でクラスターを起動することで、クラスター内にメッセージング・エンジンが１つ起動され、他のク
ラスターメンバーのメッセージング・エンジンが待機状態になる構成が、メッセージング・エンジンクラスタ
リング構成です。この構成の特徴は、メッセージング・エンジンが起動しているサーバーにプロセス障害
やネットワーク障害が発生しても、HA マネージャーによりメッセージング・エンジンがフェイルオーバーさ
れることで、サービスの提供を継続できることにあります。また、稼動系と待機系のメッセージング・エンジ
ンは、同じデータ・ストアを利用することで、構成情報やデータの引継ぎを行われます。
- 10 -
SIBus
Cluster
ClusterA
SIB01
ノード
Host01
アプリケーション・サーバー
Server1
アプリケーション・サーバー
Amember1
JMS App
ME
JDBC
Client
(ブラウザ)
ノード
Host02
DB2
[DataStore]
アプリケーション・サーバー
Amember2
JDBC
SIB1ME1
[SCHEMA]
ME
図 3-11 ME の高可用構成
3-2-1-3 パーティション構成
ここまでで説明してきた「メッセージング・エンジン・クラスター構成」はクラスター内での高可用性を提
供しますが、クラスター内で稼働するメッセージング・エンジンが 1 つしかないためメッセージの処理が１
メッセージング・エンジンに集中します。
「パーティション構成」は、クラスター内でメッセージング・エンジンを複数稼働させることで、高可用性
＋メッセージ処理の分散を行うことができる構成です。この構成で、メッセージング・エンジンが起動する
サーバーに障害が発生した場合、メッセージング・エンジン毎のフェイルオーバーとメッセージの引き継
ぎが行われます。
SIBus
Cluster
ClusterA
SIB01
ノード
Host02
ノード
Host01
アプリケーション・サーバー
Amember1
JDBC
ME
アプリケーション・サーバー
Server1
DB2
[DataStore]
ME
Client
(ブラウザ)
JMS App
JDBC
ノード
Host03
SIB1ME1
[SCHEMA]
アプリケーション・サーバー
Amember2
ME
ME
図 3-12 ME のパーティション構成
パーティション構成の注意点
パーティション構成を有効にするためには、JMS アプリケーションがメッセージング・エンジンを同じ検
索範囲で複数見つけることが必要となります。複数メッセージング・エンジンを構成していても、JMS アプ
リケーションが検索した際に、最初に見つかったのが、１メッセージング・エンジンであった場合には、パ
ーティション構成が有効にならないことに注意してください。
- 11 -
メッセージング・エンジンの検索範囲
JMS アプリケーションが使用するメッセージング・エンジンは、検索範囲内で最初に見つかったメッセ
ージング・エンジンになります。
下記の図の場合、Node１の Cluster01Member01 にある JMS アプリケーションは、メッセージング・エン
ジンを下記の順序で検索します。
SIBus
SIB01
ノード
Host01
Cluster
ClusterA
Cluster
ClusterB
アプリケーション・サーバー
Bmember1
アプリケーション・サーバー
Bmember1
JMS App
ME
ME
ノード
Host02
3
1
アプリケーション・サーバー
Bmember2
アプリケーション・サーバー
Bmember2
JMS App
ME
ME
4
2
図 3-13 ME の検索順
①JMS アプリケーションと同じサーバー上で稼動するメッセージング・エンジン
②同じクラスター内で稼動するメッセージング・エンジン
③JMS アプリケーションと同じノード上で稼動する、同一バス・メンバーのクラスターメンバー以外のサー
バーのメッセージング・エンジン
④同一バス・メンバー上で稼動するメッセージング・エンジン
ただし、JMS 接続ファクトリーの設定にある、「接続の接近性」を設定することでどこまでを検索範囲と
するかを制限することも可能です。設定は、「バス」、「クラスター」、「ホスト」、「サーバー」で、各設定によ
り下記の範囲が検索範囲になります。
バス
①～④の範囲（デフォルト設定）
クラスター
①～③の範囲
ホスト
①②の範囲
サーバー
①
パーティショニング構成でのメッセージの割り振り
メッセージング・エンジンのパーティション構成を行った場合に、ワークロードシェアリングを有効にす
る場合は、JMS アプリケーションが稼動するクラスターまたは、アプリケーション・サーバーが使用するメ
ッセージング・エンジンが所属する SIBus に参加している必要があります。同一 SIBus に所属すること
で、JMS アプリケーションの Put/Get を行う際に複数ある同じ検索範囲で見つかったメッセージング・エン
ジンをラウンドロビンで使用しますが、MDB アプリケーションは最初にアクセスを行ったメッセージング・
エンジンのみを使用します。ワークロードシェアリングが有効になっている状態であれば、JMS アプリケ
ーションは、１アプリケーション・サーバーに複数のメッセージング・エンジンが存在しても、ラウンドロビン
でメッセージング・エンジンを使用します。
パーティショニング機能を使用する場合、設定手順の中で紹介した構成には、下記の構成の場合が
考えられます。
1). JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが
同一クラスター
- 12 -
SIBus
SIB01
Cluster
ClusterA
ノード
Host01
アプリケーション・サーバー
Bmember1
DB
JMS App
ノード
Host02
ME
ME
アプリケーション・サーバー
Bmember2
JMS App
ME
ME
図 3-14 JMS アプリケーションと ME が同一クラスターの場合
この構成の場合、JMS アプリケーションは同じサーバーで稼動しているメッセージング・エンジ
ンを発見しますので、そのメッセージング・エンジンのみを使用します。図 3-14の場合、
Cluster01Member01 の JMS アプリケーションは、同じサーバーに存在するメッセージング・エンジ
ンのみを使用します。
2). JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが
別クラスター
SIBus
SIB01
ノード
Host01
Cluster
ClusterA
Cluster
ClusterB
アプリケーション・サーバー
Bmember1
アプリケーション・サーバー
Bmember1
JMS App
ノード
Host02
アプリケーション・サーバー
Bmember2
JMS App
ME
ME
DB
アプリケーション・サーバー
Bmember2
ME
ME
図 3-15 JMS アプリケーションと ME が別クラスターの場合
この構成の場合、JMS アプリケーションは自分が稼動しているアプリケーション・サーバー上に
メッセージング・エンジンを見つけることができませんので、2 番目の検索範囲である同一クラスタ
ーを検索します。同一クラスターでも見つけることができないので、3 番目の検索範囲である同一
ホストを検索します。そこにメッセージング・エンジンを見つけることができるので、そのメッセージ
ング・エンジンのみを使用します。
- 13 -
3). JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが
別ノードかつ、同一 SIBus に所属する
SIBus
SIB01
Cluster
ClusterA
ノード
Host01
Cluster
ClusterB
アプリケーション・サーバー
Bmember1
ノード
Host03
アプリケーション・サーバー
Bmember1
ME
JMS App
ノード
Host02
アプリケーション・サーバー
Bmember2
ノード
Host04
DB
ME
アプリケーション・サーバー
Bmember2
ME
JMS App
ME
図 3-16 JMS アプリケーションと ME が別クラスターかつ別ノードの場合
この構成の場合、JMS アプリケーションは自分が起動しているアプリケーション・サーバー上に
メッセージング・エンジンが見つからないため、同じクラスター内を検索します。それでも見つから
ないため、他のノードにあるメッセージング・エンジンを検索し、同じ検索範囲にメッセージング・
エンジンを 2 つ見つけます。そのメッセージング・エンジンに対してラウンドロビンでメッセージを
Put/Get します。
また、図には表れていませんが、JMS アプリケーションが存在するクラスターも SIBus のメンバ
ーですのでキュー・ポイントに設定されていないメッセージング・エンジンが存在することになりま
す。
4). JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが
別ノードかつ、同一 SIBus に所属しない
SIBus
SIB01
Cluster
ClusterA
ノード
Host01
Cluster
ClusterB
アプリケーション・サーバー
Bmember1
ノード
Host01
ME
JMS App
ノード
Host01
アプリケーション・サーバー
Bmember2
アプリケーション・サーバー
Bmember1
ノード
Host01
DB
アプリケーション・サーバー
Bmember2
ME
JMS App
ME
ME
図 3-17 JMS アプリケーションと ME が同一の SIBus に所属しない場合
この構成の場合、JMS アプリケーションは自分が起動しているアプリケーション・サーバー上に
メッセージング・エンジンが見つからないため、同じクラスター内を検索します。それでも見つから
- 14 -
ないため、他のノードにあるメッセージング・エンジンを検索し、同じ検索範囲にメッセージング・
エンジンを 2 つ見つけます。しかし、SIBus メンバーに属していないため、最初に接続したメッセ
ージング・エンジンに対してのみメッセージを Put/Get します。
3-2-2 メッセージング・エンジンの構成
この節では、メッセージング・エンジンの構成方法を説明します。
3-2-2-1 シングル構成
アプリケーション・サーバー、もしくはクラスターをSIBにバス・メンバーとして登録することで、メッセー
ジング・エンジンが作成できます。
メッセージング・エンジンの設定は、下記の手順で行います。
1). データ・ソースを作成する
2). バスを作成する
3). バス・メンバーを登録する
4). メッセージング・エンジンを設定する (Data Store)
ここでは、アプリケーション・サーバー「mes1」をバス「sib1」に登録し、動作確認を行います。目指す構
成を図にすると、下図のようになります。
SIBus
SIB1
ノード
Host01
Client
(ブラウザ)
アプリケーションサーバー
Server1
DB2
[DataStore]
JMS App
JDBC
SIB1ME1
[SCHEMA]
ME
図 3-18 サンプル構成
SIB にアプリケーション・サーバー（図内[AP Server]）を、バス・メンバーとして追加すると、メッセージ
ング・エンジン（MQ の Queue Manager に相当）が自動で作成されます。メッセージング・エンジンは構成
情報を保持や、パーシスタント・メッセージを保持する為に、データベースを利用します。データベース
には JDBC で接続し、一つのメッセージング・エンジンはデータベース内の一つのスキーマに関連付けら
れます。
アプリケーションは、SIBus 内に定義された宛先に対してメッセージの send や receive を行います。
宛先は JMS 1.1 の Destination に相当するもので、実態がトピック・スペースであってもキューであって
も操作上は区別しません。
5). データ・ソースを作成する
メッセージング・エンジンでデータ・ストアを利用する為に、データ・ソースを定義します。
今回は、以下のように設定します。
表 3-1 JDBC プロバイダーの設定
名前
スコープ
値
ノード
- 15 -
JDBC プロバイダー名
クラス・パス※
DB2 Universal JDBC Driver Provider
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc.jar
${UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cu.jar
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cisuz.jar
${DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH}
ネイティブ・ライブラリ
ー・パス※
インプリメンテーション・ com.ibm.db2.jcc.DB2ConnectionPoolDataSource
クラス名
※ ${}で参照される WebSphere 変数は、ノード単位で設定済みであるものとします。
表 3-2 WebSphere 変数の設定 (例) Windows の場合
名前
DB2UNIVERSAL_JDBC_DRIVER_PATH
DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH
UNIVERSAL_JDBC_DRIVER_PATH
値
C:\Program Files\IBM\SQLLIB\java
C:\Program Files\IBM\SQLLIB\lib
${WebSphere
AS_INSTALL_ROOT}/universalDriver/lib
尚、AIX の場合、WebSphere 変数にパスを設定する以外に、WebSphere AS 起動ユーザーに
db2profile を読み込ませておく必要があります。
表 3-3 データ・ソースの設定
名前
名前
JNDI 名
データ・ストア・ヘルパー・
クラス
コンテナー／コンポーネン
ト管理の認証別名
データベース名
ドライバー･タイプ
値
db2.sample.sib1.mes1
jdbc/db2/sample/sib1/mes1
DB2 ユニバーサル・データ・ストア・ヘルパー
(com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper)
<<db2 インスタンス・ユーザーの J2C 認証データ・エントリー>>
SAMPLE
2
6). バスを作成する
メニューから、[サービス統合]→[バス]を選択し、バスを新規作成します。
表 3-4 バスの設定
名前
値
名前
sib1
（チェックあり）
エンジン間認証別名
メディエーション認証別
名
内部エンジン・トランスポ
ート・チェーン名
（なし）
（なし）
メッセージを破棄する
（チェックなし）
概要
SIB の名前です。
グローバル・セキュリティーの設定を引き継ぐかど
うか。
この SIB にアクセスする為の認証別名。
メディエーションでこの SIB にアクセスするための
認証別名。
同一 SIB 内のメッセージング・エンジン間で利用
するトランスポート・チェーン名。デフォルトでは
InboundBasicMessaging です。
キュー・ポイントなどが削除された時の処理。チェ
ックがした場合はメッセージを削除、チェックしな
い場合はシステム例外宛先に保持します。
- 16 -
構成の再ロードを使用可
能にする
メッセージ高しきい値
（チェックあり）
再起動しないで設定変更を反映するかどうか。
50000
キュー・ポイントなどの閾値です。メッセージング・
エンジンを追加するとこの値がデフォルト値になり
ます。
7). バス・メンバーを登録する
アプリケーション・サーバーをバス・メンバーとして登録します。
作成したバスの設定画面を開き、追加プロパティーの「バス・メンバー」を選択して、遷移した画面で
「追加」ボタンを選択します。
バス・メンバーはウィザード形式で追加できます。
必要な項目を入力して、次へ進みます。次は確認画面なので、そのまま終了を選択すると、バス・メ
ンバーに登録されます。
8). メッセージング・エンジンを設定する (Data Store)
アプリケーション・サーバーをバス・メンバーとして登録すると、メッセージング・エンジンが自動で作
成されます。これと同時に、システム例外宛先（System Exception Destination、WMQのDead Letter
Queueに相当）が自動で作成されます。
これらが自動で作成されているのを確認できたら、次にメッセージング・エンジンのデータ・ストアを
設定します。作成したメッセージング・エンジンの構成画面を開き、データ・ストアを選択します。
データ・ソースJNDI名を入力します。なお一つのデータ・ソースを複数のメッセージング・エンジンで
利用するには、それぞれのメッセージング・エンジンで異なるスキーマ名を指定します。
3-2-2-2 HA マネージャー
HA マネージャーは、すべてのサーバープロセス（Dmgr や nodeagent なども含む）に存在し、お互い
に通信を行うことで、各プロセスの稼働状態を確認しています。HA マネージャーは障害を検知すると、
障害の発生したメンバーをポリシーで設定された HA グループから除去し、必要に応じてメッセージン
グ・エンジンの起動を指示します。
また、高可用性構成およびパーティション構成を行う場合、どのアプリケーション・サーバーでメッセー
ジング・エンジンを稼働させるのかなどのは、HA マネージャーにより管理されます。
障害検知と検知時の動作
高可用性構成およびパーティション構成を行うことで、各クラスターメンバーに HA 機能を提供するコン
ポーネントである HA マネージャーが組み込まれます。この HA マネージャーにより他サーバーのプロセ
ス障害やネットワーク障害を検知し、ポリシーに基づきメッセージング・エンジンのフェイルオーバーを行
います。
- 17 -
Cluster
ClusterA
プロセス
障害発生
アプリケーション・サーバー
Amember1
ME
アプリケーション・サーバー
Amember2
ME
HAManager
HAManager
HAManagerが
Amember1の
障害を検知
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ME
アプリケーション・サーバー
Amember2
ME
HAManager
HAManager
HAManagerが
ポリシーと現状を判断し
必要に応じて
MEの起動を指示する。
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ME
アプリケーション・サーバー
Amember2
ME
HAManager
HAManager
図 3-19 HA マネージャーによる ME のフェイルオーバー
HA マネージャーの設定
HA マネージャーの動作に関する設定は、コア・グループ設定および関連するポリシーにより行いま
す。
コア・グループ設定
コア・グループ設定では、HA マネージャー間の通信方式を指定します。
「CHANEEL_FRAMEWORK」
HA マネージャー間の通信を、CHANEEL_FRAMEWORK を使用して行います。
「UNICAST」
HA マネージャー間の通信を、サーバープロセスの JVM が直接行います。
ポリシーの設定と挙動
HA マネージャーがどのようにメッセージング・エンジンを起動するかは、ポリシー設定に基づいて行わ
れます。
ポリシー設定は、下記の項目から構成されそれぞれの設定のよる挙動は、下記のようになります。
•
クォーラム
- 18 -
クラスター構成時に、クラスターメンバーが半数以上起動するまで、一致基準で指定されるメッ
セージング・エンジンを起動しません。
クォーラムなし
クォーラムあり
SIBus
SIBus
SIB01
SIB01
Cluster
ClusterA
ノード
Host01
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ノード
Host01
アプリケーション・サーバー
Amember1
ME
ノード
Host02
ME
ノード
Host02
アプリケーション・サーバー
Amember2
半数以上のクラスター
メンバーが起動するまで
MEは起動されない
ME
ノード
Host03
ノード
Host03
図 3-20 クォーラムの ON、OFF 時の動き
•
フェイル・バック
優先サーバーで指定されている、優先順位高いサーバーが障害から復帰したらそのサーバーの
メッセージング・エンジンが起動し、優先順位の低いサーバーのメッセージング・エンジンが停止
する。
- 19 -
SIBus
優先度の高いMEが
使用される
SIB01
Cluster
ClusterA
ノード
Host01
アプリケーション・サーバー
Amember1
ME
ノード
Host02
アプリケーション・サーバー
Amember2
ME
SIBus
SIB01
Cluster
ClusterA
フェイルバックあり
ノード
Host01
SIBus
SIB01
ノード
Host02
アプリケーション・サーバー
Amember2
ME
Cluster
ClusterA
フェイルバックなし
フェィルオーバーされたMEが
そのまま使用される
ノード
Host01
アプリケーション・サーバー
Amember1
ME
ノード
Host02
アプリケーション・サーバー
Amember2
ME
図 3-21 フェイル･バックの ON、OFF 時の動き
•
優先サーバーのみ
優先サーバーで指定されたサーバーのみで、メッセージング・エンジンを起動します。
•
一致基準
どのメッセージング・エンジンにポリシーを設定するかを指定します。この指定に該当するコンポ
ーネントが HA グループを構成します。
特定のメッセージング・エンジンに対してポリシーを設定する場合は、下記のように設定します。
・対象となるメッセージング・エンジンの指定
名前
：WSAF_SIB_MESSAGING_ENGINE
値
：クラスターメンバー名.メッセージング・エンジン番号-SIBus 名
・メッセージング・エンジンに対する指定
名前
：type
値
：WSAF_SIB
・優先サーバー
メッセージング・エンジンが起動する順位を、サーバー単位で指定します。
HA マネージャーによる障害の検知
HA マネージャーが障害として検知するのは、下記の状態が発生した場合です。
コア・グループ設定にあるトランスポート・タイプが「 CHANEEL_FRAMEWORK 」もしくは、
「UNICAST」でも検知ロジックは変わりません。
•
プロセスダウンにより、ソケットがクローズされた場合
•
HA マネージャー間の Haertbeat が断絶した場合
- 20 -
•
OS の TCP/IP KeepAlive のタイムアウトにより、ソケットがクローズされた場合
１．プロセスダウンにより、ソケットがクローズされた場合
プロセス障害が発生したことにより、ソケットがクローズされると HA マネージャーにより即時検知され、対
象ノードがダウンしたと判断します。
プロセス障害発生に
より、コネクションが
クローズされる
Cluster
ClusterA
プロセス
障害発生
アプリケーション・サーバー
Amember1
ME
アプリケーション・サーバー
Amember2
ME
HAManager
コネクションの
クローズによって
Amember1の
障害を検知
HAManager
図 3-22 プロセスダウンにより、ソケットがクローズした場合の障害検知
プロセス障害を検知した場合、SystemOut に下記のメッセージが出力されます。
[05/03/10 13:16:56:334 JST] 00000017 DiscoveryRmmP W
DCSV1111W: DCS スタック DefaultCoreGroup
メンバー silver2Cell11\silver2CellManager11\dmgr: 別のメンバーからの発信接続がクローズされたた
め、他のメンバーが疑われました。疑いがあるメンバーは silver2Cell11\umiNode07\nodeagent です。 DCS
論理チャネルは Connected|Ptp です。
[05/03/10 13:16:56:367 JST] 00000015 RoleViewLeade I
DCSV8053I: DCS スタック DefaultCoreGroup
メンバー silver2Cell11\silver2CellManager11\dmgr: ビュー変更が処理中です。除外されるメンバーは
[silver2Cell11\umiNode07\nodeagent] です。
２．HA マネージャー間の Haertbeat が断絶した場合
ネットワーク障害やサーバーのハングにより Heartbeat の送信が、正常に行えない回数が一定回数を
超えると、HA マネージャーは対象ノードがダウンしたと判断します。
- 21 -
HAManager同士は、
HearBeatを
送受信している
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ME
HAManager
アプリケーション・サーバー
Amember2
ME
HB
HAManager
HB
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ME
HAManager
アプリケーション・サーバー
Amember2
ME
HB
規定回数の送受信の
失敗により
障害が発生したと判断
HAManager
HB
障害が発生したと判断
されたサーバーは、
HAGroupから
切り離される
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ME
アプリケーション・サーバー
Amember2
ME
HAManager
HAManager
図 3-23 Heartbeat による障害検知
デフォルトの Heartbeat 設定は、10 秒間隔で送信を行い 20 回失敗したらダウンと見なします。この
「HeartBeat の送信間隔」「Heartbeat の送信が何回失敗したらダウンと見なすか」の設定は、コア・グルー
プ設定のカスタム・プロパティに下記の値を設定することで行えます。
●HeartBeat 設定項目
IBM_CS_FD_CONSECUTIVE_MISSED
HeartBeat の送信がこの値で設定された回数失敗したら、対象サーバーをダウンと判断します。単位は、
回数です。
IBM_CS_FD_PERIOD_SECS
この値で指定される間隔で、HeartBeat を送信します。単位は、秒です。
HeartBeat 断絶によりサーバーを障害と判断する場合、SystemOut に下記のメッセージが出力されます。
また、このときに表示されるタイムアウトの値は、
「IBM_CS_FD_CONSECUTIVE_MISSED」×「IBM_CS_FD_PERIOD_SECS」の値となります。
[05/03/09 16:31:58:368 JST] 00000015 RmmPtpGroup
W
DCSV1112W: DCS スタック DefaultCoreGroup
メンバー silver2Cell11\silver2CellManager11\dmgr: ハートビート・タイムアウトのため、メンバー
silver2Cell11\umiNode07\nodeagent は疑いがあります。構成されているタイムアウトは 200000 ミリ秒
です。 DCS 論理チャネルは View|Ptp です。
[05/03/09 16:31:58:405 JST] 00000015 DiscoveryRmmP W
DCSV1112W: DCS スタック DefaultCoreGroup
メンバー silver2Cell11\silver2CellManager11\dmgr: ハートビート・タイムアウトのため、メンバー
silver2Cell11\umiNode07\nodeagent は疑いがあります。構成されているタイムアウトは 200000 ミリ秒
です。 DCS 論理チャネルは Connected|Ptp です。
３．OS の TCP/IP KeepAlive のタイムアウトにより、ソケットがクローズされた場合
- 22 -
OS 側の TCPKeepAlive 時間が経過した場合、コネクションがクローズされます。このコネクションのクロー
ズを検知し、対象サーバーがダウンしたと判断します。
HeartBeatが
無通信状態
となっている
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ME
HAManager
アプリケーション・サーバー
Amember2
ME
HAManager
OSのTCP
KeepAlive設定により
コネクションが切断
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ME
HAManager
アプリケーション・サーバー
Amember2
ME
HAManager
コネクションの
クローズによって
Amember1の
障害を検知
Cluster
ClusterA
アプリケーション・サーバー
Amember1
ME
HAManager
アプリケーション・サーバー
Amember2
ME
HAManager
図 3-24 KeepAlive タイムアウトにより、ソケットがクローズした場合の障害検知￥
OS の TCP/IP KeepAlive のタイムアウトにより、ソケットがクローズされた場合、SystemOut に出力され
る内容は、プロセス障害を検知した場合と同様になります。
3-2-2-3 高可用性構成
ここでは、JMS アプリケーションが稼働するアプリケーション・サーバーとメッセージング・エンジン・クラ
スター構成を行うための設定について説明します。
メッセージング・エンジン・クラスターを構成する手順は、下記のようになります
1). クラスターを作成する
2). データ・ソースを作成する
3). クラスターをバス・メンバーとして登録する
4). メッセージング・エンジンの稼動状況（HA 機能稼動状況）を確認する
以下で詳細な手順を説明します。
1). クラスターを作成する
最初に SIB に追加するクラスターを作成します。
(i) クラスター名を入力して、「次へ」を選択します。
(ii) 今回はクラスターを構成するアプリケーション・サーバーを同一ノードに 2 つ作ります。「メン
バー名」を入力し、「ノードの選択」でノードを選択し、「適用」を選択することで、アプリケー
ションが追加できます。
(iii) 2 台追加できたら、「次へ」を選択します。
- 23 -
2). データ・ソースを作成する
メッセージング・エンジンを使う為には、データ・ソースが必須ですので、下表のように設定しま
す。
本題からはずれますので、詳細については説明を省きます。
表 3-5 JDBC プロバイダーの設定
名前
スコープ
JDBC プロバイダー名
クラス・パス※
値
cluster01
DB2 Universal JDBC Driver Provider
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc.jar
${UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cu.jar
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cisuz.jar
${DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH}
ネイティブ・ライブラリ
ー・パス※
インプリメンテーション・ com.ibm.db2.jcc.DB2ConnectionPoolDataSource
クラス名
※ ${}で参照される WebSphere 変数は、ノード単位で設定済みであるものとします。
表 3-6 データ・ソースの設定
名前
名前
JNDI 名
データ・ストア・ヘルパー・
クラス
コンテナー／コンポーネン
ト管理の認証別名
データベース名
ドライバー･タイプ
サーバー名
ポート番号
値
db2.sample.sib1.mes01
jdbc/db2/sample/sib1/mes01
DB2 ユニバーサル・データ・ストア・ヘルパー
(com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper)
<<db2 インスタンス・ユーザーの J2C 認証データ・エントリー>>
SAMPLE
4
<<hostname>>
50000
3). クラスターをバス・メンバーとして登録する
クラスターをバス・メンバーとして追加すると、デフォルトでは HA 機能が有効になります。また後ででてく
るメッセージング・エンジンの管理画面で、メッセージング・エンジンを追加することができます。メッセー
ジング・エンジンを追加することで、複数メッセージング・エンジンへのパーティショニング機能が利用可
能になります。
参考：InfoCenter「Service integration high availability and workload sharing configurations」
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.nd.
doc/concepts/cjt0007_.html
(i) メニューから、「サービス統合」⇒「バス」を選択して sib1 を開き、追加プロパティーの「バ
ス・メンバー」を開きます。
バス・メンバーがクラスターの場合、メッセージング・エンジンの追加ができます。
メッセージング・エンジンを追加すると、一つの宛先に複数のメッセージング・エンジンが割り
当てられ、パーティショニングが行われるようになります。
(ii) データ・ストアを設定します。
- 24 -
ここでクラスターを起動し、メッセージング・エンジンの稼動状況を確認します。
4). メッセージング・エンジンの稼動状況を確認する
次に、クラスター内のどのサーバーでメッセージング・エンジンが起動しているかを確認します。
(i) メニューで「サーバー」⇒「コア・グループ」⇒「コア・グループ設定」を選択し、コア・グルー
プの一覧から DefaultCoreGroup を選択します。
(ii) コア・グループのランタイムを表示します。
「ランタイム」タブをクリックして、そのまま「グループの表示」ボタンを選択します。
なお後でポリシーの設定を確認します。その時は、追加プロパティーの「ポリシー」を選択しま
す。
(iii) 高可用性グループ（ HA グループ）の一覧が表示されるので、この中から、
「WSAF_SIB_MESSAGING_ENGINE=cluster01.000-sib1」を含む行を選択します。
メッセージング・エンジンの HA グループの稼動状況が確認できます。
一つ前の画面で選択した行のポリシーを見ると、「Default SIBus Policy」が適用されている
のがわかります。
このポリシーは、「One of N」（N ポリシーの中の１つ）ポリシー・タイプです。これによりメッセ
ージング・エンジンは高可用性が保たれています。つまり稼動系のアプリケーション・サーバー
が停止しても、クラスター内のほかのアプリケーション・サーバーに引き継ぐことで、システム全
体への影響を抑制できます。
(iv) ここで、デフォルトのポリシーの設定を確認します。ポリシーの構成画面から一致基準を選
択します。
「type=WSAF_SIB」が選択されているのがわかります。これは全てのメッセージング・エンジ
ンに適用されることを意味します。メッセージング・エンジンのデフォルト・ポリシーの設定である
為です。
SIB のデフォルト・ポリシーでは、一致基準で type のみが指定されていましたが、この他に
も、「 WSAF_SIB_MESSAGING_ENGINE （ ME 名）」「 WSAF_SIB_BUS （ SIB 名）」
「IBM_ham_cluster（クラスター名）」などの一致基準を利用することで、より細かく HA グループ
を分け、動作を制御することができます。
参考：InfoCenter「Using match criteria to associate a policy with a messaging engine」
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.nd.
doc/tasks/tjt0035_.html
HA 機能とパーティショニング機能の詳細については、Information Center に詳細な記述があります。
参考：InfoCenter「Service integration high availability and workload sharing configurations」
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.nd.
doc/concepts/cjt0007_.html
3-2-2-4 パーティション構成
ここまでで説明してきた「メッセージング・エンジン・クラスター構成」はクラスター内での高可用性を提
供しますが、クラスター内で稼働するメッセージング・エンジンが 1 つしかないためメッセージの処理が１
メッセージング・エンジンに集中します。
ここから説明を行う、「パーティショニング構成」は、クラスター内でメッセージング・エンジンを複数稼
働させることで、高可用性＋メッセージ処理の分散を行うことができる構成です。この構成で、メッセージ
ング・エンジンが起動するサーバーに障害が発生した場合、メッセージング・エンジン毎のフェイルオー
バーとメッセージの引き継ぎが行われます。
この節では、メッセージング・エンジンパーティショニング構成を行うための設定方法、メッセージのバ
ランシングメッセージング・エンジンが稼働するおよび、サーバープロセスに障害が発生したときの挙動
について解説を行います。
- 25 -
パーティショニング設定
パーティショニングを行う為に、一つのバス・メンバー内に複数のメッセージング・エンジンを構成しま
す。
今回は、sib1 のバス・メンバーcluster01 にメッセージング・エンジンを追加します。作成された二つのメ
ッセージング・エンジン「 cluster01.000-sib1 」と「 cluster01.001-sib1 」の稼動系をそれぞれ
「cluster01member01」と「cluster01member02」にして、パーティショニングさせます。
SIB のデフォルト・ポリシーでは、それぞれのメッセージング・エンジンが同じアプリケーション・サーバ
ーで稼動する可能性が高いため、新しいポリシーをメッセージング・エンジンごとに作成します。そうする
ことで、それぞれのポリシーの優先サーバーを別のアプリケーション・サーバーに設定できます。
(i) まず、一つのメッセージング・エンジンには一つのデータ・ストアが必要なので、追加するメ
ッセージング・エンジン用のデータ・ソースを定義します。
表 3-7 JDBC プロバイダーの設定
名前
スコープ
JDBC プロバイダー名
クラス・パス※
値
cluster01
DB2 Universal JDBC Driver Provider
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc.jar
${UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cu.jar
${DB2UNIVERSAL_JDBC_DRIVER_PATH}/db2jcc_license_cisuz.jar
${DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH}
ネイティブ・ライブラリ
ー・パス※
インプリメンテーション・ com.ibm.db2.jcc.DB2ConnectionPoolDataSource
クラス名
※ ${}で参照される WebSphere 変数は、ノード単位で設定済みであるものとします。
表 3-8データ・ソースの設定
名前
値
名前
db2.sample.sib1.mes02
JNDI 名
jdbc/db2/sample/sib1/mes02
データ・ストア・ヘルパー・ DB2 ユニバーサル・データ・ストア・ヘルパー
クラス
(com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper)
コンテナー／コンポーネン <<db2 インスタンス・ユーザーの J2C 認証データ・エントリー>>
ト管理の認証別名
データベース名
SAMPLE
ドライバー･タイプ
4
サーバー名
<<hostname>>
ポート番号
50000
(ii) 次に SIB 構成画面からバス・メンバーを表示し、先ほど導入したクラスターを選択します。
(iii) メッセージング・エンジンの一覧が表示されるので、「メッセージング・エンジンの追加」を選
択します。
(iv) 作成しておいたデータ・ソースの JNDI 名と、適切なスキーマ名を指定します。
(v) DefaultCoreGroup の構成画面で、ポリシーの設定を行う為、追加プロパティーのポリシー
を選択します。
- 26 -
(vi) ポリシーの一覧が表示されます。「Default SIBus Policy」がメッセージング・エンジンのポ
リシーのデフォルトです。
ここでは新規作成を選択します。まずメッセージング・エンジン「cluster01.000-sib1」のポリシ
ーを作成します。
(vii) パーティショニングを行う各メッセージング・エンジンは、一台を稼動系とする「N of 1」ポリ
シーを適用させます。
(viii) ポリシーの構成画面で、適切な名前を設定します。
また、「フェイル・バック」を有効に設定します。これでポリシーで設定した優先サーバーを優
先的に稼動系にできます。そのほかに「優先サーバーのみ」を有効にすると、後ほど設定する
優先サーバーの設定に含まれるサーバーでのみメッセージング・エンジンを稼動させることがで
きます。しかし、今回はすべてのアプリケーション・サーバーで稼動することが可能なように設定
しますので、無効に設定します。
ポリシーの構成画面で「適用」を選択すると、追加プロパティーの「一致基準」と「優先サーバ
ー」が選択可能になるので、それぞれ設定していきます。
(ix) まず一致基準を設定します。ここで設定した一致基準に該当するオブジェクトに対して HA
ポリシーが適用されます。ここでは「type」の他に「WSAF_SIB_MESSAGING_ENGINE」
でメッセージング・エンジン名を設定することで、ポリシーを適用するメッセージング・エンジ
ンを絞り込みます。
(x) 次に優先サーバーを設定します。ここで設定した順に、メッセージング・エンジンが稼動す
るサーバーが選択されます。
(xi) 次に追加したメッセージング・エンジン「cluster01.001-sib1」のポリシーを作成します。設
定内容はメッセージング・エンジン「cluster01.000-sib1」の場合とほとんど同じですので、
異なる部分のみコメントします。
ポリシーの名前がメッセージング・エンジン「cluster01.001-sib1」の場合と異なります。
「WSAF_SIB_MESSAGING_ENGINE」の値が異なります。
優先サーバーの順位が異なります。
(xii) 設定が完了したので、クラスターを起動後、コア・グループのランタイムを表示します。
そして HA グループの一覧から、作成したポリシーが適用されている 2 行を開きます。
(xiii) まず「WSAF_SIB_MESSAGING_ENGINE=cluster01.000-sib1」が含まれる方の HA
グループを開いて確認します。ここでは優先サーバーの上位に設定したアプリケーション・
サーバー「cluster01.member01」でメッセージング・エンジンが稼動していることが確認で
きます。
(xiv) 次に「WSAF_SIB_MESSAGING_ENGINE=cluster01.000-sib1」が含まれる方の HA グ
ループを開いて確認します。ここでも優先サーバーの上位に設定したアプリケーション・サ
ーバー「cluster01.member02」でメッセージング・エンジンが稼動していることが確認でき
ます。
これでパーティショニング機能の為に用意した二つのメッセージング・エンジンが、それぞれ
HA 機能が有効になっていることがわかりました。
3-2-2-5 宛先の設定
メッセージを受け取る宛先を作成します。
(i) 新規作成を選択すると、ウィザード形式で宛先を作成します。今回はキューを作成します。
(ii) 宛先のタイプはキューを選択し、宛先名をつけます。
(iii) 最後にどのバス上にキュー・ポイントを作成するかを選択します。
(iv) 作成した宛先を確認します。
- 27 -
(v) 宛先を作成後、例外宛先（WMQ のバックアウト・キューに相当）を設定します。そのデフォ
ルト値はこのシステム例外宛先です。
3-2-2-6 外部バス
SIBus には、SIBus 同士を接続する SIBus リンク機能と、バスと WebSphere MQ（以下 WMQ）のキュ
ー・マネージャー（Qmgr）をチャネル接続する MQ リンク機能があります。これらの機能では、リンク先の
バスや Qmgr を外部バスとして作成します。リンクを作成すると、バス間でメッセージのやり取りを行えるよ
うになります。
SIBus リンクや MQ リンクを利用するには、SIBus 上に外部バスを作成します。管理コンソールのツリー･
ビュー上で、[サービス統合]→[バス]→[バス名]→[追加プロパティー：バス名]を選択し、[新規作成]ボ
タンを押下すると、外部バスを作成できます。
項目
説明
外部バス名
SIBus リンクの場合、リンク対象のバス名を指定します。
MQ リンクの場合、任意の名前を指定します。
ルーティング・タイプ
直接サービス統合バス・リンク＝SIBus リンクを利用する場合に選択します。
直接 WebSphere MQ リンク＝MQ リンクを利用する場合に選択します。
間接＝第 3 のサービス統合バスへのブリッジとして使用される中間サービス
統合バスを表している場合は、このルーティング定義タイプを使用します。
当資料では直接リンクの設定方法のみを解説します。
Inbound user ID
外部バスから届くメッセージのユーザーID を、この ID に置換します。セキュア
なバスではない場合、何も影響を与えません。
Outbound user ID
外部バスに送るメッセージのユーザーID を、この ID に置換します。リンク元とリ
ンク先が共にセキュアなバスではない場合、何も影響を与えません。
ここからは、SIBus リンクと MQ リンクの作成方法を別々に解説します。
SIBus リンク
SIBus
SIB02
SIBus
SIB01
アプリケーション・
サーバー
server1
ME
me01
外部バス
SIBus01
外部バス
SIBus02
SIBusリンク
アプリケーション・
サーバー
server2
ME
me02
図 3-25 SIBus リンク概要
2 つの SIBus があるとき、それぞれに含まれるメッセージング・エンジン同士をリンクすることで、バス間
でメッセージのやり取りを可能にする機能です。SIBus リンクは、リンクする相互のバス上に、同じ名前で
作成する必要があります。
SIBus リンクを作成するには、事前にいくつかの情報をまとめておく必要があります。主に必要な情報
は、下表のとおりです。
- 28 -
項目
SIBus リンク名
説明
SIBus リンクは、相互に同じ名前で作成する必要があります。そのため、事前に任意
の SIBus リンク名を決めておく必要があります。
ホスト名
リンクするメッセージング・エンジンが稼動しているホストの名前です。
ポート番号
接続先メッセージング・エンジンが稼動しているサーバーの、トランスポート・チェー
ン、InboundBasicMessaging（SSL を利用する場合は InboundSecureMessaging）に設
定されているポート番号です。このポート番号を指定して、メッセージング・エンジンの
Bootstrap Server にアクセスすることで、メッセージング・エンジン間の接続を確立でき
ます。
サーバー構成画面で、ポート番号一覧を開き、SIB_ENDPOINT_ADDRESS（SSL を
利用する場合は SIB_ENDPOINT_SECURE_ADDRESS）でも確認できます。
メッセージン
接続先のメッセージング・エンジン名です。SIBus リンクの実体は、メッセージング・エ
グ・エンジン名
ンジン間の接続です。
以下に SIBus リンクを作成して、外部バス上の宛先に対して、別名宛先を作成するまでの手順を解説
します。この別名宛先に対してメッセージを send することで、外部バスにメッセージを送ることができま
す。なお、外部バスは作成済みであるものとします。
1.
SIBus リンクを作成する
管理コンソールのツリー･ビュー上で、[サービス統合]→[バス]→[バス名]→[追加プロパティー：メ
ッセージング・エンジン]→[メッセージング・エンジン名]→[追加プロパティー：サービス統合バス・リ
ンク]を選択し、[新規作成]ボタンを押下すると、SIBus リンクを作成できます。SIBus リンクを作成す
るに当たって重要な項目を下表に記します。
項目
説明
名前
SIBus リンクの名前です。SIBus リンクは、リンク先とリンク元に、同じ名前
で作成する必要があります。
外部バス名
事前に作成しておいた、外部バスを選択します。
リモート・メッセージﾝグ・リンク先のメッセージング・エンジン名です。
エンジン名
通常メッセージング・エンジンは、
「Node_name.Server_name-Bus_name」（クラスター構成されたメッセージ
ング・エンジンの場合「Cluster_name.00#-Bus_name」（“00#”は 3 桁の連
番））というネーミングルールに従って、名前が付けられます。
ターゲット・インバウンド・ターゲットのメッセージング・エンジンに接続するプロトコルを指定しま
トランスポート・チェーン
す。
InboundBasicMessaging＝標準の TCP/IP 接続（JFAP-TCP/IP）です。
InboundSecureMessaging＝SSL でラップされた InboundBasicMessaging
プロトコルです。
ブートストラップ・エンド
ブートストラップ・サーバーのリストを”,”（カンマ）区切りで指定します。指
ポイント
定方法は、「host:port:protocol」です。protocol には、
InboundBasicMessaging の場合 BoootstrapBasicMessaging、
InboundSecureMessaging の場合 BootstrapSecureMessaging を指定しま
す。
認証別名
外部バスに接続する際に使用する J2C 認証エイリアスを指定します。
SIBus リンクをリンク先とリンク元のメッセージング・エンジンの双方に定義すると、接続を開始できる
ようになります。
2.
別名宛先を作成する
- 29 -
メッセージを外部バスに送信するために、別名宛先を作成します。管理コンソールのツリー・ビュー
上で、[サービス統合]→[バス]→[バス名]→[追加プロパティー：宛先]を選択し、[新規作成]ボタン
を押下し、宛先タイプの一覧から、[別名]を選択します。別名宛先を作成するに当たって重要な項
目を下表に記します。
項目
説明
ID
バス上に作成する別名宛先名です。
バス
別名宛先を作成するバス名です。
ターゲット ID
ターゲットの宛先名です。
ターゲット・バス
ターゲットの宛先があるバス名です。
応答宛先/応答宛先バス逆作業工程パス（Reverse Routing Path）に追加される宛先名/バス名。
デフォルト転送ルーティ転送ルーティング・パス（Forward Routing Path）が含まれていない場合
ング・パス
に、設定される値です。「bus_name:destination_name」（同一バス上の
場合は｢:destination_name｣でも指定可能）の形式で指定します。
この別名宛先に対してメッセージを send することで、外部バスにメッセージを転送できます。
WebSphere MQ リンク
SIBus
SIB01
アプリケーション・
サーバー
server1
ME
me01
キュー・マネージャー
QMGR1
外部バス
SIBus02
送信側MQチャネル
受信側MQチャネル
図 3-26 WebSphere MQ リンク概要
MQ の Qmgr が存在するとき、チャネル接続を作成することでメッセージのやり取りが可能になります。
Qmgr はバス上に外部バスとして作成されます。チャネルは、バスから Qmgr にメッセージを転送するた
めの送信チャネルと、Qmgr からバスにメッセージを転送するための受信チャネルを作成します。メッセ
ージング・エンジンは Qmgr 上で外部 Qmgr として作成されます。そのため、MQ リンク作成時には、メッ
セージング・エンジンに仮想 Qmgr 名を設定します。
MQ リンクを作成するには、事前にいくつかの情報をまとめておく必要があります。主に必要な情報は、
下表のとおりです。
項目
説明
仮想 Qmgr 名
リンク先 Qmgr によって認識される、メッセージング・エンジンの仮想 Qmgr
名です。
受信側 MQ チャネル名
Qmgr からメッセージング・エンジンにメッセージを送信するために利用す
る、Qmgr の送信チャネル名を指定します。
- 30 -
インバウンド・非パーシスタ
ント・メッセージの信頼性
インバウンド・パーシスタン
ト・メッセージの信頼性
送信側 MQ チャネル名
QM のホスト名
MQ リスナーのポート番号
トランスポート・チェーン
メッセージング・エンジンが
稼動しているホスト名
メッセージング・エンジンの
エンドポイント
Qmgr からメッセージング・エンジンにメッセージが送信されるメッセージ
が、非パーシスタント・メッセージだったとき、メッセージング・エンジン側
で割り振られる信頼性レベルを指定します。
Qmgr からメッセージング・エンジンにメッセージが送信されるメッセージ
が、パーシスタント・メッセージだったとき、メッセージング・エンジン側で
割り振られる信頼性レベルを指定します。
メッセージング・エンジンから Qmgr にメッセージを送信するために利用す
る、Qmgr の受信チャネル名を指定します。
Qmgr が稼動しているホスト名を指定します。
MQ リスナーが待ち受けるポート番号を指定します。
Qmgr とのやり取りに利用するプロトコルを選択します。
Qmgr 上に送信チャネルを作成するときに指定します。
SIB_MQ_ENDPOINT_ADDRESS（もしくは
SIB_MQ_ENDPOINT_SECURE_ADDRESS）に設定されているポート番
号です。Qmgr 上に送信チャネルを作成するときに指定します。
以下に MQ リンクを作成して、Qmgr 上のローカル・キューに対して、別名宛先を作成するまでの手順
を解説します。この別名宛先に対してメッセージを send することで、Qmgr にメッセージを送ることができ
ます。なお、外部バスは作成済みであるものとします。また、QM 上には送信チャネルと受信チャネルが
作成済みであるものとします。（作成するためのコマンドについては、Appendix を参照）
1.
MQ リンクを作成する
管理コンソールのツリー･ビュー上で、[サービス統合]→[バス]→[バス名]→[追加プロパティー：メ
ッセージング・エンジン]→[メッセージング・エンジン名]→[追加プロパティー：WebSphere MQ リ
ンク]を選択し、[新規作成]ボタンを押下すると、MQ リンクを作成できます。MQ リンクを作成するに
当たって重要な項目を下表に記します。
項目
説明
名前
MQ チャネルを管理するために使用する、任意の名前です。
外部バス名
Qmgr につける外部バス名です。事前に定義しておく必要がありま
す。
キュー･マネージャー名
リンク先 Qmgr によって認識される、メッセージング・エンジンの仮想
Qmgr 名です。
送信側 MQ チャネル名
メッセージング・エンジンから Qmgr にメッセージを送信するために利
用する、Qmgr の受信チャネル名を指定します。
ホスト名
Qmgr が稼動しているホスト名を指定します。
ポート
MQ リスナーが待ち受けるポート番号を指定します。
トランスポート・チェーン
Qmgr とのやり取りに利用するプロトコルを選択します。
受信側 MQ チャネル名
Qmgr からメッセージング・エンジンにメッセージを送信するために利
用する、Qmgr の送信チャネル名を指定します。
インバウンド非パーシスタ Qmgr からメッセージング・エンジンにメッセージが送信されるメッセー
ント・メッセージの信頼性
ジが、非パーシスタント・メッセージだったとき、メッセージング・エンジ
ン側で割り振られる信頼性レベルを指定します。
インバウンド・パーシスタ
Qmgr からメッセージング・エンジンにメッセージが送信されるメッセー
ント・メッセージの信頼性
ジが、パーシスタント・メッセージだったとき、メッセージング・エンジン
側で割り振られる信頼性レベルを指定します。
- 31 -
2.
別名宛先を作成する
メッセージング・エンジンから SIBus にメッセージを送信する場合、Qmgr 上のローカル・キューに対
して、SIBus 上に別名宛先を定義します。管理コンソールのツリー・ビュー上で、[サービス統合]→
[バス]→[バス名]→[追加プロパティー：宛先]を選択し、[新規作成]ボタンを押下し、宛先タイプの
一覧から、[別名]を選択します。別名宛先を作成するに当たって重要な項目を下表に記します。
項目
説明
ID
バス上に作成する別名宛先名です。
バス
別名宛先を作成するバス名です。
ターゲット ID
ターゲットのローカル・キュー名です。「Qlocal_name@Qmgr_name」の
形式で指定します。
ターゲット・バス
ターゲットの宛先があるバス名です。
この別名宛先に対してメッセージを send することで、Qmgr にメッセージを転送できます。
3.
リモート・キューを作成する
MQ から SIBus にメッセージを送信する場合、SIBus 上の宛先に対して、Qmgr 上にリモート・キュー
を定義します。
DEFINE QREMOTE('Qremote_name') RNAME('Dest_name') RQMNAME('ME_Qmgr_name')
Qremote_name=Qmgr 上に定義するリモート・キュー名
Dest_name=SIBus 上の宛先名
ME_Qmgr_name=メッセージング・エンジンの仮想 Qmgr 名
このリモート・キューにメッセージを PUT することで、メッセージが SIBus に転送されます。
3-2-2-7 メディエーション
メディエーション・プロセスは、アプリケーションが送信したメッセージが受信されるまで、移動中のメッ
セージを処理します。メディエーションはコーディング可能で、次のような処理が可能です。
•
ある形式から別の形式へのメッセージ変換。
•
送信側アプリケーションによって指定されなかった 1 つ以上のターゲット宛先へのメッセージのル
ーティング。
•
データ・ソースからデータを追加することによる、メッセージの拡大。
•
複数のターゲット宛先へのメッセージの配布。
前述のとおり、メディエーションを利用する場合、事前にメディエーション・ハンドラーをコーディングして
おく必要があります。ここでは、メディエーション・ハンドラーのコーディング方法には解説しませんが、メ
ディエーションを理解するには、いくつかのキーワードを理解する必要があります。以下にそれらのキー
ワード略を列挙します。
•
メディエーション
SIBus 上の定義です。実態は EJB デプロイメント記述子に定義されている、メディエーション・ハン
ドラー・リストです。つまりメディエーションは、メディエーション・ハンドラー・リストへのポインターで
す。メディエーションを宛先に設定すると、宛先に入ったメッセージは、メディエーション・ハンドラ
ー・リストに登録されているハンドラーを経由するようになります。
このとき、メディエーションされる前、メッセージが蓄積されるキューを、メディエーション・ポイント
（もしくは Pre-mediated）、メディエーションされた後、メッセージが蓄積されるキューを、キュー・ポイ
ント（もしくは Post-mediated）と呼びます。
なお、アプリケーションは、キュー・ポイントからメッセージを receive できますが、メディエーション・
ポイントからは receive できません。
- 32 -
メディエーション・
ハンドラー
メディエーション・
ハンドラー・リスト
メディエーション
3
送信アプリケーション
受信アプリケーション
メッセージ・
6
5
4
2
メディエーション・
キュー・
ポイント
ポイント
1
ポイント
図 3-27 メディエーションの概要
•
メディエーション・ハンドラー
実態はロジックを記述された Stateless Session Bean です。
com.ibm.websphere.sib.mediation.handler.MediationHandler クラスを継承して作成します。ロジック
は、handle(MessageContext context)メソッドに記述します。この MessageContext を使って、メッセー
ジを操作します。
•
メディエーション・ハンドラー・リスト
複数のメディエーション・ハンドラーをまとめた定義です。どのハンドラーを、どのような順番で呼び
出していくかを定義してあります。メディエーション・ハンドラー・リストは、EJB デプロイメント記述子
に定義します。メディエーション・ハンドラー・リストには、一意の名前を割り当てる必要がありま
す。メディエーションはこの名前に対するポインターです。
メディエーション・ハンドラーの handle メソッドが true を返すと、次のメディエーション・ハンドラーを
実行します。これに対して false を返すと、次のメディエーション・ハンドラーは呼び出されず、メッセ
ージ「再デリバリー回数」が 1 回インクリメントされ、メディエーション・ポイントに戻ります。メディエ
ーション・ポイントに戻ったメッセージの「再デリバリー回数」が、宛先に設定された「最大デリバリ
ー失敗数」を上回ると、メッセージは例外宛先に転送されます。例外宛先を設定していない場合
は、メディエーションはリトライを繰り返し続けます。
メディエーション・ハンドラー･リストを定義済みの EAR ファイルが用意できていることを前提に、管理
コンソールによるメディエーションの設定方法を解説します。
1. エンタープライズ・アプリケーションをデプロイする
メディエーション・ハンドラー・リストを含むエンタープライズ・アプリケーションをデプロイします。
2.
メディエーションを作成する
- 33 -
管理コンソールのツリー・ビュー上で、[サービス統合]→[バス]→[バス名]→[宛先リソース：メディ
エーション]を選択し、[新規作成]ボタンを押下します。
項目
説明
メディエーション名
このメディエーションに割り当てる名前を設定しております。
ハンドラー・リスト名
デプロイメント記述子に設定した、メディエーション・ハンドラー・リスト
の名前を入力してください。
グローバル・トランザクショングローバル・トランザクションを利用可能です。このオプションを有効
にすると、メディエーションで処理された各メッセージに対してグロー
バル・トランザクションが開始されます。これにより、メディエーション
と RM のトランザクションの保全性が確保できます。
並行メディエーション
スレッドを利用して、複数の処理を同時に進行できます。並行処理
をしたい場合、チェックしてください。
なお、並行メディエーションに利用するスレッド・プール
mediationThreadPool は、次のコマンドで作成できます。
$AdminConfig create ThreadPool $messagingEngine {{name
stitch.server1-bus2-mediationThreadPool}} mediationThreadPool
セレクター
メディエーションが仲介するメッセージを選択できます。セレクターは
JMS の仕様で定義されています。
3.
メディエーションを宛先に設定する
管理コンソールのツリー・ビュー上で、[サービス統合]→[バス]→[バス名]→[宛先リソース：宛先]
を選択します。宛先一覧が表示されるので、メディエーションを設定した宛先をチェックして、[仲
介]ボタンを押下します。
項目
説明
この宛先に適用するメディ
この宛先に適用するメディエーションを選択します。
エーション
メディエーション・ポイントのメディエーションがインストールされているバス・メンバーを選択して
割り当て先のバス・メンバーください。
4.
メディエーションを始動/停止する
管理コンソールのツリー・ビュー上で、[サービス統合]→[バス]→[バス名]→[宛先リソース：宛先]
→[メッセージ・ポイント：メディエーション・ポイント]を選択します。ここで、メディエーション・ポイント
を選択し、[始動]/[停止]ボタンを押下すると、メディエーションを始動/停止します。
3-3 JMS 接続設定
3-3-1 デフォルトのメッセージング・プロバイダー
メッセージング・エンジンにメッセージを配置する場合に必要となる、メッセージ・リソースの設定を行
います。
メッセージ・リソースの設定は、JMS のバージョンにより異なります。
使用する設定と JMS のバージョンは、下記のようになります。
- 34 -
JMS 接続ファクトリー
z JMS 1.0 の場合
JMS 接続ファクトリーは、キュー接続用の「JMS キュー接続ファクトリー」とトピック接続用の「JMS ト
ピック接続ファクトリー」に分かれていますので、用途に応じて構成する必要があります。
z JMS 1.1 の場合
JMS 接続ファクトリーは、キュー接続用およびトピック接続用に関わらず、「JMS 接続ファクトリー」を
使用します。
宛先
宛先の設定は、JMS1.0/1.1 ともに共通です。
JMS1.1 用
JMS1.0 用
宛先設定は、
JMS1.0/1.1 共通です
図 3-28 デフォルトのメッセージング・プロバイダーの設定箇所
3-3-1-1 JMS 接続ファクトリーの設定
JMS 1.1 を使用してメッセージング・エンジン接続を行う際に使用する、JMS 接続ファクトリーを設定しま
す。JMS 1.1 では、キューを使用する場合、トピックを使用する場合でも使用する接続ファクトリーは共通
です。
1. [JMS プロバイダー]→[デフォルトのメッセージング]を選択します。
2. 設定が適用される範囲として、作成したクラスター[ClusterA]を指定します。
3. [クラスターの参照]をクリックします。
- 35 -
図 3-29 デフォルトのメッセージング・プロバイダーの設定
4.
[ClusterA]を指定して、[OK]をクリックします。
図 3-30 クラスターの選択
- 36 -
5.
クラスターに、[ClusterA]が表示されていることを確認したら、[JMS 接続ファクトリー]をクリックしま
す。
図 3-31 JMS 接続ファクトリーの選択
6.
[新規作成]をクリックします。
図 3-32 接続ファクトリーの新規作成
- 37 -
7.
JMS 接続ファクトリーの設定を、下記のように行います。
※画面が長いため、設定項目毎に紹介します。
[管理]
名前：設定している JMS 接続ファクトリーの識別名称を設定します。
JNDI 名：設定している JMS 接続ファクトリーの JNDI 名を設定します。
図 3-33 接続ファクトリーの設定（1）
[接続]
バス名：接続先のバス名を指定します。
ターゲット：メッセージング・エンジンのグループを識別するターゲットの名前を指定します。
ターゲット・タイプ：「ターゲット」で指定されたターゲットのタイプ
ターゲット重要度：ターゲットで指定されるメンバーのみを使用するかを指定します。
ターゲット・インバウンド・トランスポート・チェーン：
メッセージング・エンジンの名前解決に使用される、トランスポート・チェーンを指定します。
プロバイダー・エンドポイント：
メッセージング・エンジンの為のブート・ストラップ・ポートを指定します。
接続の接近性：メッセージング・エンジンを検索する範囲を指定します。
図 3-34 接続ファクトリーの設定（2）
- 38 -
[永続サブスクリプション]
クライアント ID：
永続トピック・サブスクリプションに必要な固有の JMS クライアント ID を指定します。
永続サブスクリプション・ホーム：
永続サブスクリプションに配信されるメッセージを保管するために使用される、メッセージング・
エンジンの名前を指定します。
図 3-35 接続ファクトリーの設定（3）
[サービスの品質]
非パーシスタント・メッセージの信頼性：
非永続 JMS メッセージに適用される信頼性を指定します。
パーシスタント・メッセージの信頼性：
永続 JMS メッセージに適用される信頼性を指定します。
図 3-36 接続ファクトリーの設定（4）
[拡張メッセージング]
先読み：コンシューマーにメッセージを先制して割り当てる最適化を行うかどうかを指定します。
一時キュー名の接頭部：
一時キューの名前に使用される 12 文字までの接頭部を指定します。
一時トピック名の接頭部：
一時トピックの名前に使用される 12 文字までの接頭部を指定します。
永続サブスクリプションを共用：
永続サブスクリプションが、接続を越えてサーバー・クラスターのメンバーとの間で共用されるか
どうかを指定します。
図 3-37 接続ファクトリーの設定（5）
[拡張管理]
コンポーネント管理の認証別名：
JMS プロバイダーとの接続に使用される J2C 認証エントリを指定します。
トランザクション・コンテキストの欠落をログに記録：
接続を取得したときに、トランザクション・コンテキストが欠落していることを、コンテナーがログに
記録するかどうかを指定します。
キャッシュ・ハンドルの管理：
- 39 -
キャッシュされた Bean 内のインスタンス変数に保持されているハンドル) をコンテナーで追跡
するかどうかを指定します。
CMP とデータ・ソースを共用：
JMS と CMP Entity Bean 間の接続の共用を許可するかどうかを指定します。
XA リカバリーの認証別名：
トランザクションのリカバリー時に使用される J2C 認証エントリを指定します。
図 3-38 接続ファクトリーの設定（6）
3-3-1-2 JMS キュー接続ファクトリーの設定
JMS 1.0 で、Point-to-Point のメッセージングを使用する場合は、キュー接続ファクトリーを取得する必要
があります。
※1～4 までの手順は、3-3-1-1 と変わりません。
1. [JMS プロバイダー]→[デフォルトのメッセージング]を選択します。
2. 設定が適用される範囲として、作成したクラスター[ClusterA]を指定します。
3. [クラスターの参照]をクリックします。
4. [ClusterA]を指定して、[OK]をクリックします。
5. クラスターに、[ClusterA]が表示されていることを確認したら、[JMS キュー接続ファクトリー]をクリ
ックします。
- 40 -
図 3-39 JMS キュー接続ファクトリーの選択
6.
[新規作成]をクリックします。
図 3-40
7.
JMS キュー接続ファクトリーの新規作成
JMS キュー接続ファクトリーの設定を、下記のように行います。
※画面が長いため、設定項目毎に紹介します。
[管理]
名前：設定している JMS 活動化仕様の識別名称を設定します。
JNDI 名：設定している JMS 活動化仕様の JNDI 名を設定します。
- 41 -
図 3-41
JMS キュー接続ファクトリーの設定（1）
[接続]
バス名：接続先のバス名を指定します。
ターゲット：メッセージング・エンジンのグループを識別するターゲットの名前を指定します。
ターゲット・タイプ：「ターゲット」で指定されたターゲットのタイプ
ターゲット重要度：ターゲットで指定されるメンバーのみを使用するかを指定します。
ターゲット・インバウンド・トランスポート・チェーン：
メッセージング・エンジンの名前解決に使用される、トランスポート・チェーンを指定します。
プロバイダー・エンドポイント：
メッセージング・エンジンの為のブート・ストラップ・ポートを指定します。
接続の接近性：メッセージング・エンジンを検索する範囲を指定します。
図 3-42
JMS キュー接続ファクトリーの設定（2）
[サービスの品質]
非パーシスタント・メッセージの信頼性：
非永続 JMS メッセージに適用される信頼性を指定します。
パーシスタント・メッセージの信頼性：
永続 JMS メッセージに適用される信頼性を指定します。
- 42 -
図 3-43
JMS キュー接続ファクトリーの設定（3）
[拡張メッセージング]
先読み：コンシューマーにメッセージを先制して割り当てる最適化を行うかどうかを指定します。
一時キュー名の接頭部：
一時キューの名前に使用される 12 文字までの接頭部を指定します。
図 3-44
JMS キュー接続ファクトリーの設定（4）
[拡張管理]
コンポーネント管理の認証別名：
JMS プロバイダーとの接続に使用される J2C 認証エントリを指定します。
トランザクション・コンテキストの欠落をログに記録：
接続を取得したときに、トランザクション・コンテキストが欠落していることを、コンテナーがログに
記録するかどうかを指定します。
キャッシュ・ハンドルの管理：
キャッシュされた Bean 内のインスタンス変数に保持されているハンドル) をコンテナーで追跡
するかどうかを指定します。
CMP とデータ・ソースを共用：
JMS と CMP Entity Bean 間の接続の共用を許可するかどうかを指定します。
XA リカバリーの認証別名：
トランザクションのリカバリー時に使用される J2C 認証エントリを指定します。
図 3-45
JMS キュー接続ファクトリーの設定（5）
3-3-1-3 JMS トピック接続プロバイダーの設定
JMS 1.0 で、Publish/Subscribe のメッセージングを使用する場合は、トピック接続ファクトリーを取得する
必要があります。
※1～4 までの手順は、3-3-1-1 と変わりません。
1. [JMS プロバイダー]→[デフォルトのメッセージング]を選択します。
2. 設定が適用される範囲として、作成したクラスター[ClusterA]を指定します。
3. [クラスターの参照]をクリックします。
4. [ClusterA]を指定して、[OK]をクリックします。
- 43 -
5.
クラスターに、[ClusterA]が表示されていることを確認したら、[JMS トピック接続ファクトリー]をクリ
ックします。
図 3-46 JMS トピック接続ファクトリーの選択
6.
[新規作成]をクリックします。
図 3-47
7.
JMS トピック接続ファクトリーの新規作成
JMS トピック接続ファクトリーの設定を、下記のように行います。
※画面が長いため、設定項目毎に紹介します。
[管理]
名前：設定している JMS 活動化仕様の識別名称を設定します。
JNDI 名：設定している JMS 活動化仕様の JNDI 名を設定します。
- 44 -
図 3-48
JMS トピック接続ファクトリーの設定（1）
[接続]
バス名：接続先のバス名を指定します。
ターゲット：メッセージング・エンジンのグループを識別するターゲットの名前を指定します。
ターゲット・タイプ：「ターゲット」で指定されたターゲットのタイプ
ターゲット重要度：ターゲットで指定されるメンバーのみを使用するかを指定します。
ターゲット・インバウンド・トランスポート・チェーン：
メッセージング・エンジンの名前解決に使用される、トランスポート・チェーンを指定します。
プロバイダー・エンドポイント：
メッセージング・エンジンの為のブート・ストラップ・ポートを指定します。
接続の接近性：メッセージング・エンジンを検索する範囲を指定します。
図 3-49
JMS トピック接続ファクトリーの設定（2）
[永続サブスクリプション]
クライアント ID：
永続トピック・サブスクリプションに必要な固有の JMS クライアント ID を指定します。
永続サブスクリプション・ホーム：
永続サブスクリプションに配信されるメッセージを保管するために使用される、メッセージング・
エンジンの名前を指定します。
- 45 -
図 3-50
JMS トピック接続ファクトリーの設定（3）
[サービスの品質]
非パーシスタント・メッセージの信頼性：
非永続 JMS メッセージに適用される信頼性を指定します。
パーシスタント・メッセージの信頼性：
永続 JMS メッセージに適用される信頼性を指定します。
図 3-51
JMS トピック接続ファクトリーの設定（4）
[拡張メッセージング]
先読み：
コンシューマーにメッセージを先制して割り当てる最適化を行うかどうかを指定します。
一時トピック名の接頭部：
一時トピックの名前に使用される 12 文字までの接頭部を指定します。
永続サブスクリプションを共用：
永続サブスクリプションが、接続を越えてサーバー・クラスターのメンバーとの間で共用される
かどうかを指定します。
図 3-52
JMS トピック接続ファクトリーの設定（5）
[拡張管理]
コンポーネント管理の認証別名：
JMS プロバイダーとの接続に使用される J2C 認証エントリを指定します。
トランザクション・コンテキストの欠落をログに記録：
接続を取得したときに、トランザクション・コンテキストが欠落していることを、コンテナーがログに
記録するかどうかを指定します。
キャッシュ・ハンドルの管理：
キャッシュされた Bean 内のインスタンス変数に保持されているハンドル) をコンテナーで追跡
するかどうかを指定します。
CMP とデータ・ソースを共用：
JMS と CMP Entity Bean 間の接続の共用を許可するかどうかを指定します。
XA リカバリーの認証別名：
トランザクションのリカバリー時に使用される J2C 認証エントリを指定します。
- 46 -
図 3-53
JMS トピック接続ファクトリーの設定（6）
3-3-1-4 JMS キューの設定
JMS 1.0/1.1 で、Point-to-Point のメッセージを送るときに使用するキューを設定します。
※1～4 までの手順は、3-3-1-1 と変わりません。
1. [JMS プロバイダー]→[デフォルトのメッセージング]を選択します。
2. 設定が適用される範囲として、作成したクラスター[ClusterA]を指定します。
3. [クラスターの参照]をクリックします。
4. [ClusterA]を指定して、[OK]をクリックします。
5. クラスターに、[ClusterA]が表示されていることを確認したら、[JMS 接続キュー]をクリックします。
図 3-54 JMS 接続キューの選択
6.
[新規作成]をクリックします。
- 47 -
図 3-55
7.
JMS 接続キューの新規作成
JMS 接続キューの設定を、下記のように行います。
図 3-56
JMS 接続キューの設定
[管理]
名前：設定している JMS 活動化仕様の識別名称を設定します。
JNDI 名：設定している JMS 活動化仕様の JNDI 名を設定します。
[接続]
キュー名：メッセージング・エンジンに定義した宛先を指定します。
バス名：キュー名で指定する宛先を持つバス名を指定します。
デリバリー・モード：この宛先に送信されるメッセージのデリバリー・モードを指定します。
存続時間：メッセージが到着してからの存続時間を指定します。
- 48 -
優先順位：この宛先に送信されるメッセージの優先順位を指定します。
[拡張]
先読み：
メッセージ配信時に先読み最適化を行うかどうかを指定します。
3-3-1-5 JMS トピックの設定
JMS 1.0/1.1 で、Publish/Subscribe のメッセージを送るときに使用するトピックを設定します。
※1～4 までの手順は、3-3-1-1 と変わりません。
1. [JMS プロバイダー]→[デフォルトのメッセージング]を選択します。
2. 設定が適用される範囲として、作成したクラスター[ClusterA]を指定します。
3. [クラスターの参照]をクリックします。
4. [ClusterA]を指定して、[OK]をクリックします。
5. クラスターに、[ClusterA]が表示されていることを確認したら、[JMS 接続トピック]をクリックします。
図 3-57 JMS トピックの選択
6.
[新規作成]をクリックします。
- 49 -
図 3-58 JMS トピックの新規作成
7.
JMS 接続トピックの設定を、下記のように行います。
※画面が長いため、設定項目毎に紹介します。
[管理]
名前：設定している JMS 活動化仕様の識別名称を設定します。
JNDI 名：設定している JMS 活動化仕様の JNDI 名を設定します。
図 3-59
JMS トピックの設定（1）
[接続]
トピック名：トピックの割り当て先のトピックの名前を指定します。
トピック・スペース：メッセージング・エンジンに定義したトピック・スペースを指定します。
バス名：トピック・スペースで指定したトピック・スペース宛先を持つバス名を指定します。
デリバリー・モード：この宛先に送信されるメッセージのデリバリー・モードを指定します。
存続時間：メッセージが到着してからの存続時間を指定します。
優先順位：この宛先に送信されるメッセージの優先順位を指定します。
図 3-60
JMS トピックの設定（2）
[拡張]
先読み：
メッセージ配信時に先読み最適化を行うかどうかを指定します。
- 50 -
図 3-61
JMS トピックの設定（3）
3-3-1-6 MDB を使用する際の構成
JMS1.1 の MDB では、MDB はリスナー・ポートを使用するのではなく、「JMS 活動化仕様」を使用し
監視する宛先などを設定します。
ここでは、JMS1.1 の MDB の為に、「JMS 活動化仕様」を設定する方法を、紹介します。
3-3-1-7 JMS 活動化仕様の設定
JMS1.1 の MDB を使用するために必要な、JMS 活動化仕様を設定します。
1. [JMS プロバイダー]→[デフォルトのメッセージング]を選択します。
2. 設定が適用される範囲として、作成したクラスター[ClusterA]を指定します。
3. [クラスターの参照]をクリックします。
図 3-62 適用クラスターの選択（1）
4.
[ClusterA]を指定して、[OK]をクリックします。
- 51 -
図 3-63 適用クラスターの選択（2）
5.
クラスターに、[ClusterA]が表示されていることを確認したら、[JMS 活動化仕様]をクリックします。
図 3-64 JMS 活動化仕様の選択
6.
[新規作成]をクリックします。
図 3-65 JMS 活動化仕様の新規作成
7.
[JMS 活動化仕様]の設定を行います。
※画面が長いので、項目毎に説明を行います。
[管理]
- 52 -
名前：設定している JMS 活動化仕様の識別名称を設定します。
JNDI 名：設定している JMS 活動化仕様の JNDI 名を設定します。
図 3-66 JMS 活動化仕様の設定（1）
[宛先]
宛先タイプ：MDB が監視する宛先のタイプを指定します。
宛先 JNDI 名：MDB が監視する宛先の JNDI 名を指定します。
メッセージ・セレクター：
メッセージ・ヘッダー内のフィールド、およびメッセージ・プロパティー内のフィールドを元に、取
得するメッセージを選択する場合に設定します。
バス名：宛先 JNDI 名で指定される宛先が存在するバス名を指定します。
応答モード：
ターゲット・インバウンド・トランスポート・チェーン：
監視対象の宛先を持つバス・メンバーとして MDB が稼働するアプリケーション・サーバーが含
まれていない場合に、接続先となるメッセージング・エンジンを指定します。
図 3-67
JMS 活動化仕様の設定（2）
[追加]
認証別名：サービス・統合バスへ接続する際に使用する J2C 認証エントリを指定します。
最大バッチ・サイズ：単一バッチで受信するメッセージの最大数を指定します。
最大平行エンドポイント数：
メッセージが同時に配信されるエンドポイントの最大数を指定します。
図 3-68
JMS 活動化仕様の設定（3）
[サブスクリプション耐久性]
- 53 -
サブスクリプション耐久性：トピック・サブスクリプションが永続的か非永続的かを指定します。
サブスクリプション名：サブスクリプション名を指定します。
クライアント ID：
永続トピック・サブスクリプションに必要な固有の JMS クライアント ID を指定します。
永続サブスクリプション・ホーム：
永続サブスクリプションに配信されるメッセージを保管するために使用される、メッセージング・
エンジンの名前を指定します。
図 3-69 JMS 活動化仕様の設定（4）
[拡張]
永続サブスクリプションを共用：
永続サブスクリプションが、接続を越えてサーバー・クラスターのメンバーとの間で共用されるか
どうかを指定します。
CMP とデータ・ソースを共用：
JMS と CMP Entity Bean 間の接続の共用を許可するかどうかを指定します。
先読み：コンシューマーにメッセージを先制して割り当てる最適化を行うかどうかを指定します。
図 3-70
JMS 活動化仕様の設定（5）
3-3-1-8 障害時の動作
クラスター構成の例
説明に使用するクラスター構成として、下記の 2 つの構成を使用します。
a.アプリケーションが動くクラスターと、メッセージング・エンジンが動くクラスターが同一クラスター
- 54 -
SIBus
SIB01
Cluster
ClusterA
ノード
Host01
アプリケーション・サーバー
Amember1
JMS App
ノード
Host01
ME
DB
アプリケーション・サーバー
Amember2
JMS App
ME
図 3-71 アプリケーションとメッセージング・エンジンが同一クラスターで稼動している場合
b. アプリケーションが動くクラスターと、メッセージング・エンジンが動くクラスターが別クラスター
SIBus
SIB01
Cluster
ClusterA
ノード
Host01
ノード
Host02
Cluster
ClusterB
アプリケーション・サーバー
Bmember1
アプリケーション・サーバー
Bmember1
JMS App
ME
アプリケーション・サーバー
Bmember2
アプリケーション・サーバー
Bmember2
JMS App
ME
図 3-72 アプリケーションと ME が異なるクラスターで稼動している場合
一般的な JMS アプリケーションの動作フロー
この説明の中で使用している JMS アプリケーションの動作フローを説明します。
- 55 -
DB
a.メッセージを Put する JMS アプリケーション
SIBus
SIB01
Cluster
ClusterA
ノード
Host01
アプリケーション・サーバー
Bmember1
ME
JMS App
Client
(ブラウザ)
1
ノード
Host02
11
DB
アプリケーション・サーバー
Bmember2
JNDI
4～14
2～3
ME
JMS App
図 3-73 メッセージを Put するアプリケーションの概要
1. クライアントは、JMS アプリケーションを実行します
2. JMS アプリケーションは、JMS 接続ファクトリーおよびキューの情報を JNDI に問い合わせます。
3. JNDI は、JMS 接続ファクトリーおよびキューの情報を返します。
4. JMS 接続ファクトリーを使用して、Connection を作成します。
5. Session を作成します。
6. メッセージを送信するための MessageProducer を作成します。
7. JMS メッセージを作成します。
8. JMS メッセージに返信先をセットします。
9. JMS 接続に対して、操作開始を指示します。
10. メッセージを PUT します。
11. メッセージング・エンジンは PUT されたメッセージをパーシステント・データベースに格納します。※
12. MessageProducer をクローズします。
13. Session をクローズします。
14. Connection を切断します。
※ 11.パーシステント・データベースへのメッセージの保存を行うかどうかについては、「メッセージ品質
による挙動の変化」で説明しています。
- 56 -
b.メッセージを GET する JMS アプリケーション
SIBus
SIB01
Cluster
ClusterA
ノード
Host01
アプリケーション・サーバー
Bmember1
ME
JMS App
Client
(ブラウザ)
1
ノード
Host01
9
DB
アプリケーション・サーバー
Bmember2
JNDI
4～12
2～3
ME
JMS App
図 3-74 メッセージを Get するアプリケーションの概要
1. クライアントは、JMS アプリケーションを実行します。
2. JMS アプリケーションは、JMS 接続ファクトリーおよびキューの情報を JNDI に問い合わせます。
3. JNDI は、JMS 接続ファクトリーおよびキューの情報を返します。
4. JMS 接続ファクトリーを使用して、Connection を作成します。
5. Session を作成します。
6. メッセージを受信するための MessageConsumer を作成します。
7. JMS 接続に対して、操作開始を指示します。
8. メッセージを GET します。
9. メッセージング・エンジンは GET されたメッセージをパーシステント・データベースから削除します。※
10. MessageConsumer をクローズします。
11. Session をクローズします。
12. Connection を切断します。
※ 11.パーシステント・データベースへのメッセージの保存を行うかどうかについては、「メッセージ品質
による挙動の変化」で説明しています。
プロセス障害発生時の挙動
メッセージング・エンジンが稼動するアプリケーションのプロセス障害が発生した場合は、HA マネージ
ャーにより即時に検知され、同一 HA グループに所属するメッセージング・エンジンが起動されます。障
害が発生した時点で、JMS アプリケーションが JMS のコネクションを作成している状態であれば、そのリ
クエストを処理しているアプリケーションでは、アプリケーションの実行フローに応じた JMSException を
受け取ります。ただし、メッセージング・エンジンのフェイルオーバーはほぼ即時に完了しますので、再
度リクエストを送信するか、エラーハンドリングの中で、再度 Put/Get を行うことでリクエストは正常に完了
することができます。
- 57 -
Put を行うアプリケーションの場合
Put を行うアプリケーションのフロー毎に、メッセージング・エンジンが起動しているアプリケーション・サ
ーバー（MECluster01Member01）にプロセス障害が発生した場合の挙動を説明します。
2. JMS アプリケーションは、JMS 接続ファクトリーおよびキューの情報を JNDI に問い合わせます。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。障害が発生した時点で
アクセスが行われている JMS アプリケーションに対して、例外は発生しません。
3. JNDI は、JMS 接続ファクトリーおよびキューの情報を返します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。障害が発生した時点で
アクセスが行われている JMS アプリケーションに対して、例外は発生しません。
4. JMS 接続ファクトリーを使用して、Connection を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0241E: メソッド
JmsManagedConnectionFactoryImpl.createConnection の呼び出し中に例外を受信しました:
com.ibm.websphere.sib.exception.SIResourceException: CWSIT0019E: バス JMSTest に使用可能な適切
なメッセージング・エンジンがありません。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
5. Session を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
CWSIA0053E: メソッド JmsSessionImpl. の呼び出し中に例外を受信しました
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0044E: すでにクロー
ズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
6. メッセージを送信するための MessageProducer を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
- 58 -
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl. の呼び出し中に例外を受信しまし
た:
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0047E: すでにクロー
ズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
7. JMS メッセージを作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
メッセージ作成時点での障害が原因での例外は発生しませんが、メッセージ Put 時に
javax.jms.JMSException が返され障害が発生した時点でアクセスが行われている JMS アプリケーション
に対して、アプリケーションの実行は失敗します。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
8. JMS メッセージに返信先をセットします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
メッセージ作成時点での障害が原因での例外は発生しませんが、メッセージ Put 時に
javax.jms.JMSException が返され障害が発生した時点でアクセスが行われている JMS アプリケーション
に対して、アプリケーションの実行は失敗します。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
9. JMS 接続に対して、操作開始を指示します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
メッセージ作成時点での障害が原因での例外は発生しませんが、メッセージ Put 時に
javax.jms.JMSException が返され障害が発生した時点でアクセスが行われている JMS アプリケーション
に対して、アプリケーションの実行は失敗します。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
10. メッセージを PUT します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl.sendMessage (#4) の呼び出し中に
例外を受信しました: com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0047E:
すでにクローズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
12. MessageProducer をクローズします。
- 59 -
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl.close の呼び出し中に例外を受信
しました: com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0047E: すでにクロ
ーズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に行
われます。
13. Session をクローズします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl.close の呼び出し中に例外を受信
しました: com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0047E: すでにクロ
ーズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
14. Connection を切断します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0022E: メソッド JmsConnectionImpl.close の呼び出し中に例外を受信し
ました:
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0047E: すで
にクローズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
GET を行うアプリケーションの場合
GET を行うアプリケーションのフロー毎に、メッセージング・エンジンが起動しているアプリケーション・
サーバー（MECluster01Member01）にプロセス障害が発生した場合の挙動を説明します。
2. JMS アプリケーションは、JMS 接続ファクトリーおよびキューの情報を JNDI に問い合わせます。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。障害が発生した時点で
アクセスが行われている JMS アプリケーションに対して、例外は発生しません。
3. JNDI は、JMS 接続ファクトリーおよびキューの情報を返します。
- 60 -
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。障害が発生した時点で
アクセスが行われている JMS アプリケーションに対して、例外は発生しません。
4. JMS 接続ファクトリーを使用して、Connection を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0241E: メソッド
JmsManagedConnectionFactoryImpl.createConnection の呼び出し中に例外を受信しました:
com.ibm.websphere.sib.exception.SIResourceException: CWSIT0019E: バス PME_JMSTest に使用可能な
適切なメッセージング・エンジンがありません。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
5. Session を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
CWSIA0053E: メソッド JmsSessionImpl. の呼び出し中に例外を受信しました
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0044E: すでにクロー
ズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
6. メッセージを受信するための MessageConsumer を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl. の呼び出し中に例外を受信しまし
た: com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0044E: すでにクローズさ
れた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
7. JMS 接続に対して、操作開始を指示します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動しますが、操作開始の指示をし
た時点での障害が原因での例外は発生しません。しかし、メッセージ Get 時に javax.jms.JMSException
が返され障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、アプリケーショ
ンの実行は失敗します。
- 61 -
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
8. メッセージを GET します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
CWSIA0103E: メッセージの受信中に例外が発生しました:
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0044E: すでにクロー
ズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
10. MessageConsumer をクローズします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
CWSIA0053E: メソッド JmsSessionImpl. の呼び出し中に例外を受信しました
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0044E: すでにクローズされた
接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に行
われます。
11. Session をクローズします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
CWSIA0053E: メソッド JmsSessionImpl. の呼び出し中に例外を受信しました
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0044E: すでにクローズされた
接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
12. Connection を切断します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
- 62 -
CWSIA0022E: メソッド JmsConnectionImpl.close の呼び出し中に例外を受信しました
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0044E: すでにクローズされた
接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
ネットワーク障害発生時の挙動
プロセス障害と同様に、JMS アプリケーションのフロー毎に、メッセージング・エンジンが起動している
アプリケーション・サーバー（MECluster01Member01）にプロセス障害・ネットワーク障害が発生した場合
の挙動を説明します。ネットワーク障害時もプロセス障害時と同様に HA マネージャーによる検知および
フェイルオーバーが行われます。
PUT を行うアプリケーションの場合
PUT を行うアプリケーションのフロー毎に、メッセージング・エンジンが起動しているアプリケーション・
サーバー（MECluster01Member01）にネットワーク障害が発生した場合の挙動を説明します。
2. JMS アプリケーションは、JMS 接続ファクトリーおよびキューの情報を JNDI に問い合わせます。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャーに
より検知され、Cluster01Member02 のメッセージング・エンジンが起動します。障害が発生した時点でア
クセスが行われている JMS アプリケーションに対して、例外は発生しません。
3. JNDI は、JMS 接続ファクトリーおよびキューの情報を返します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。障害が発生した時点で
アクセスが行われている JMS アプリケーションに対して、例外は発生しません。
4. JMS 接続ファクトリーを使用して、Connection を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0241E: メソッド JmsManagedConnectionFactoryImpl.createConnection の
呼び出し中に例外を受信しました: com.ibm.websphere.sib.exception.SIResourceException:
CWSIT0019E: バス PME_JMSTest に使用可能な適切なメッセージング・エンジンがありません。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
5. Session を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
- 63 -
javax.jms.JMSException: CWSIA0053E: メソッド JmsSessionImpl.<constructor> の呼び出し中に例外を
受信しました: com.ibm.ws.sib.jfapchannel.JFapConnectionBrokenException:CWSIJ0056E: 予期しない条
件により、ネットワーク接続がクローズしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
6. メッセージを送信するための MessageProducer を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl.<constructor> の呼び出し中に例
外を受信しました: com.ibm.ws.sib.jfapchannel.JFapConnectionBrokenException: CWSIJ0056E: 予期し
ない条件により、ネットワーク接続がクローズしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に行
われます。
7. JMS メッセージを作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
メッセージ作成時点での障害が原因での例外は発生しませんが、メッセージ Put 時に
javax.jms.JMSException が返され障害が発生した時点でアクセスが行われている JMS アプリケーション
に対して、アプリケーションの実行は失敗します。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
8. JMS メッセージに返信先をセットします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
メッセージ作成時点での障害が原因での例外は発生しませんが、メッセージ Put 時に
javax.jms.JMSException が返され障害が発生した時点でアクセスが行われている JMS アプリケーション
に対して、アプリケーションの実行は失敗します。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
9. JMS 接続に対して、操作開始を指示します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
メッセージ作成時点での障害が原因での例外は発生しませんが、メッセージ Put 時に
javax.jms.JMSException が返され障害が発生した時点でアクセスが行われている JMS アプリケーション
に対して、アプリケーションの実行は失敗します。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
10. メッセージを PUT します。
- 64 -
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl.close の呼び出し中に例外を受信
しました: com.ibm.ws.sib.jfapchannel.JFapConnectionBrokenException: CWSIJ0056E: 予期しない条件
により、ネットワーク接続がクローズしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
12. MessageProducer をクローズします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl.close の呼び出し中に例外を受信
しました: com.ibm.ws.sib.jfapchannel.JFapConnectionBrokenException: CWSIJ0056E: 予期しない条件
により、ネットワーク接続がクローズしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
13. Session をクローズします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E:CWSIA0022E: メソッド JmsConnectionImpl.close の呼び出し中に
例外を受信しました: com.ibm.ws.sib.jfapchannel.JFapConnectionBrokenException: CWSIJ0056E: 予期
しない条件により、ネットワーク接続がクローズしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に行
われます。
14. Connection を切断します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0022E: メソッド JmsConnectionImpl.close の呼び出し中に例外を受信し
ました: com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0056E: すでにクロー
ズされた接続での操作が行われようとしました。
- 65 -
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に行
われます。
GET を行うアプリケーションの場合
GET を行うアプリケーションのフロー毎に、メッセージング・エンジンが起動しているアプリケーション・
サーバー（MECluster01Member01）にネットワーク障害が発生した場合の挙動を説明します。
2. JMS アプリケーションは、JMS 接続ファクトリーおよびキューの情報を JNDI に問い合わせます。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。障害が発生した時点で
アクセスが行われている JMS アプリケーションに対して、例外は発生しません。
3. JNDI は、JMS 接続ファクトリーおよびキューの情報を返します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。障害が発生した時点で
アクセスが行われている JMS アプリケーションに対して、例外は発生しません。
4. JMS 接続ファクトリーを使用して、Connection を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0241E: メソッド JmsManagedConnectionFactoryImpl.createConnection の
呼び出し中に例外を受信しました: com.ibm.websphere.sib.exception.SIResourceException:
CWSIT0019E: バス PME_JMSTest に使用可能な適切なメッセージング・エンジンがありません。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
5. Session を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0053E: メソッド JmsSessionImpl.<constructor> の呼び出し中に例外を
受信しました: com.ibm.ws.sib.jfapchannel.JFapConnectionBrokenException:
CWSIJ0056E: 予期しない条件により、ネットワーク接続がクローズしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
6. メッセージを受信するための MessageConsumer を作成します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
- 66 -
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0085E: メソッド JmsMsgConsumerImpl.createCoreConsumer の呼び出し中
に例外を受信しました: com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException:
CWSIJ0044E: すでにクローズされた接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
7. JMS 接続に対して、操作開始を指示します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動しますが、操作開始の指示をし
た時点での障害が原因での例外は発生しません。しかし、メッセージ Get 時に javax.jms.JMSException
が返され障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、アプリケーショ
ンの実行は失敗します。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
8. メッセージを GET します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
CWSIA0085E: メソッド JmsMsgConsumerImpl.start の呼び出し中に例外を受信しました:
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0047E: すでにクローズされた
接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に行
われます。
10. MessageConsumer をクローズします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
CWSIA0085E: メソッド JmsMsgConsumerImpl.stop の呼び出し中に例外を受信しました:
com.ibm.wsspi.sib.core.exception.SIConnectionDroppedException: CWSIJ0047E: すでにクローズされた
接続での操作が行われようとしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
11. Session をクローズします。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
- 67 -
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0067E: メソッド JmsMsgProducerImpl.sendMessage (#4) の呼び出し中に
例外を受信しました: com.ibm.ws.sib.jfapchannel.JFapConnectionBrokenException: CWSIJ0056E: 予期
しない条件により、ネットワーク接続がクローズしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
12. Connection を切断します。
この時点で、メッセージング・エンジンが稼働しているプロセスに障害が発生すると、HA マネージャー
により検知され、Cluster01Member02 のメッセージング・エンジンが起動します。
障害が発生した時点でアクセスが行われている JMS アプリケーションに対して、
javax.jms.JMSException が返されアプリケーションの実行は失敗します。
返される JMSException の全文
javax.jms.JMSException: CWSIA0022E:CWSIA0022E: メソッド JmsConnectionImpl.close の呼び出し中に
例外を受信しました: com.ibm.ws.sib.jfapchannel.JFapConnectionBrokenException: CWSIJ0056E: 予期
しない条件により、ネットワーク接続がクローズしました。
メッセージング・エンジンのフェイルオーバーが完了した後でのクライアントからのアクセスは、正常に
行われます。
返される JMSException の詳細と、エラーハンドリングについて
JMS アプリケーションでは、メッセージング・エンジンが原因で起きる例外はすべて粒度の高い
「 JMSException 」として返されます。実際にアプリケーション的にリトライが可能かどうかは、
JMSException からエラー・コードを取得し、エラー・コード毎に判断する必要があります。
＜コード例＞
catch(JMSException e){
String errorCode = e.getErrorCode();
If(errorCode.equal(“CWSIA0067”)){
//エラーハンドリングのコード
}else if(errorCode.equal(“CWSIA0053”)){
//エラーハンドリングのコード
}
}
パーティショニング構成の障害時の動作
この節では、パーティショニング構成で稼働している際に、プロセス障害やネットワーク障害が発生し
た場合どのように動作するのかについて説明します。
使用するメッセージング・エンジンと、同一 SIBus に所属するメッセージング・エンジンがいる JMS アプ
リケーションであれば、メッセージング・エンジンが障害から復旧することで、ワークロードシェアリングも
正常に稼動しますが、同一 SIBus に所属するメッセージング・エンジンがいない場合、メッセージの偏り
が発生する可能性が出てきます。
- 68 -
ここでは、どのようにフェイルオーバーとメッセージの Put/Get が行われるかについてのみ説明を行
い、アプリケーションの動作フローにそってどのような例外が返されるかについては、クラスター構成時
での解説と同じですので割愛します。また、説明を行う構成は、「パーティショニング構成でのメッセージ
の割り振り (p.12)」と同じ構成です。
１． JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが同一
クラスター
SIBus
SIB01
ノード
Host01
Cluster
ClusterA
アプリケーション・サーバー
Bmember1
JMS App
ME
ME
DB
ノード
Host02
アプリケーション・サーバー
Bmember2
JMS App
SIBus
SIB01
ノード
Host01
ME
ME
Cluster
ClusterA
アプリケーション・サーバー
Bmember1
JMS App
ME
ME
DB
ノード
Host02
アプリケーション・サーバー
Bmember2
図 3-75 アプリケーションと ME が同一クラスター上で稼動している場合の障害時の挙動
JMS アプリケーションとメッセージング・エンジンが起動しているサーバーの１つがダウンすると、HA マ
ネージャーにより検知され、稼動しているサーバー上でメッセージング・エンジンが起動します。このよう
にメッセージング・エンジンが、１サーバーで複数稼動することになりますが、最初に接続されているメッ
セージング・エンジンのみを使用します。
- 69 -
２． JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが別クラ
スター
SIBus SIB01
Cluster
ClusterA
Cluster
ClusterB
ノード
Host01
アプリケーション・サーバー
Bmember1
JMS App
アプリケーション・サーバー
Bmember1
ME
ME
ノード
Host02
アプリケーション・サーバー
Bmember2
JMS App
アプリケーション・サーバー
Bmember2
ME
ME
DB
SIBus SIB01
Cluster
ClusterA
Cluster
ClusterB
ノード
Host01
アプリケーション・サーバー
Bmember1
JMS App
アプリケーション・サーバー
Bmember1
ME
ME
ノード
Host02
アプリケーション・サーバー
Bmember2
JMS App
アプリケーション・サーバー
Bmember2
DB
図 3-76 アプリケーションと ME が異なるクラスター上で稼動している場合の障害時の挙動
この構成の場合、最初の時点では JMS アプリケーションは、稼動しているサーバーと同じノードにある
メッセージング・エンジンを使用します。障害が発生すると、障害が発生したメッセージング・エンジンを
使用していたアプリケーションは、障害が発生していない側のサーバーが使用しているメッセージング・
エンジンを使用します。この後、メッセージング・エンジンが起動しているサーバーが再起動しても、使用
するメッセージング・エンジンが変更されることはありません。
- 70 -
３． JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが別ノ
ードかつ、同一 SIBus に所属する
SIBus SIB01
Cluster
ClusterA
Cluster
ClusterB
ノード
Host01
アプリケーション・サーバー
Bmember1
JMS App
アプリケーション・サーバー
Bmember1
ME
ME
ノード
Host02
アプリケーション・サーバー
Bmember2
JMS App
アプリケーション・サーバー
Bmember2
ME
ME
DB
SIBus SIB01
Cluster
ClusterA
Cluster
ClusterB
ノード
Host01
アプリケーション・サーバー
Bmember1
JMS App
アプリケーション・サーバー
Bmember1
ME
ME
ノード
Host02
アプリケーション・サーバー
Bmember2
JMS App
アプリケーション・サーバー
Bmember2
DB
図 3-77 アプリケーションと ME が同一 SIBus 上の異なるクラスター上で稼動している場合の障害時の
挙動
この構成の場合、それぞれの JMS アプリケーションは、すべてのメッセージング・エンジンに対して、ラ
ウンドロビンでメッセージを Put/Get します。障害が発生することにより、１サーバーに複数メッセージン
グ・エンジンが起動してもラウンドロビンにてメッセージを Put/Get します。
- 71 -
４． JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが別ノ
ードかつ、同一 SIBus に所属しない
SIBus SIB01
Cluster
ClusterA
ノード
Host01
Cluster
ClusterB
アプリケーション・サーバー
Bmember1
JMS App
ノード
Host01
アプリケーション・サーバー
Bmember2
JMS App
ノード
Host02
アプリケーション・サーバー
Bmember1
ME
ME
DB
ノード
Host02
アプリケーション・サーバー
Bmember2
ME
ME
SIBus SIB01
Cluster
ClusterA
ノード
Host01
Cluster
ClusterB
アプリケーション・サーバー
Bmember1
JMS App
ノード
Host01
アプリケーション・サーバー
Bmember2
JMS App
ノード
Host02
アプリケーション・サーバー
Bmember1
ME
ME
DB
ノード
Host02
アプリケーション・サーバー
Bmember2
図 3-78 アプリケーションと ME が異なるクラスター、異なるノード上で稼動している場合の障害時の挙
動
この構成の場合、最初の時点ではすべての JMS アプリケーションは、最初に使用されたメッセージン
グ・エンジンのみを使用します。障害が発生すると、障害が発生したメッセージング・エンジンを使用して
いたアプリケーションは、障害が発生していない側のサーバーが使用しているメッセージング・エンジン
を使用します。この後、メッセージング・エンジンが起動しているサーバーが再起動しても、使用するメッ
セージング・エンジンが変更されることはありません。
ネットワーク障害時固有の考慮点
パーシステント・データベースに DB2 を使用している場合、ネットワーク障害発生時に DB2 はネットワ
ーク障害を検知できません。そのためテーブルロックが解除されず、フェイルオーバーにより起動するメ
ッセージング・エンジンがパーシスタンス・データベースを使用できません。その結果、メッセージング・
エンジンのフェイルオーバーが失敗することがあります。DB2 がネットワーク障害を検知してテーブルロ
ックを解除するためには、DB2 が稼働しているノードの TCP/IP タイムアウトの値を、調整する必要があり
ます。そのため、ネットワーク障害を検知するには、パーシステント・データベースが稼働しているノード
の TCP/IP タイムアウトの値を、HA マネージャーによるネットワーク障害検知とほぼ同じ時間になるよう
に調整します。
AIX の場合、ネットワーク障害検知までの時間は下記の様に構成されます。
(tcp_keepcnt*tcpkeepintvl)+tcp_keepidle ÷ 2 = ネットワーク障害検知までの時間
- 72 -
各項目の意味は下記のようになります。
項目名
意味
tcp_keepcnt
キープアライブ・プローブをいくつ送信したら接続を終了するか
（デフォルト設定：8）
tcp_keepidle アイドル TCP 接続をアクティブにしておく時間
（デフォルト設定：14400 <2 時間>）
tcp_keepintvl TCP 接続を検査するため、何秒おきにパケットを送信するか
（デフォルト設定：150 <75 秒>）
この設定は、下記のコマンドにて行います。
# no -o [tcp_keepcnt/tcp_keepidle/tcp_keepintvl] = value
HA マネージャーによるネットワーク障害検知までの時間は、下記のように構成されます。
IBM_CS_FD_PERIOD_SECS×IBM_CS_FD_CONSECUTIVE_MISSED
=ネットワーク障害検知までの時間
各項目の意味は下記のようになります。
●IBM_CS_FD_PERIOD_SECS
この値で指定される間隔で、Heartbeat を送信します。
（デフォルト値 10 秒）
●IBM_CS_FD_CONSECUTIVE_MISSED
HeartBeat の送信がこの値で設定された回数失敗したら、対象サーバーをダウンと判断します。
（デフォルト値 20 回）
この設定は、コア・グループ設定のカスタム・プロパティに上記の値を設定することで行います。
1. 管理コンソールより、[サーバー]→[コア・グループ]→[コア・グループ]設定の順に選択します。
2. 設定対象のコア・グループを選択します。
3. [追加プロパティー]にある[カスタム・プロパティ]を選択します。
4. [新規作成]をクリックし、名前と値のペアを設定します。
5. 構成を保存します。
3-3-1-9 接続プールの設定
WebSphere AS V6.0 SIBus 環境において、JMS プロバイダーとしてデフォルト・メッセージング・プロバ
イダーを利用した場合、J2EE Connector Architecture (JCA または J2C)の仕様に基づいたコネクション・
プーリング機能が利用可能です。この機能により、JMS クライアントの SIBus 接続処理のオーバーヘッド
を緩和することができます。
1). JMS クライアントの場合
JMS クライアントからの接続要求は「J2C 接続プール」に保持され、その後の接続要求に対して再
利用されます。管理コンソールの[リソース]→[リソース・アダプター]→[SIB JMS Resource
Adapter]→[接続プール]から最大接続数などの項目が設定可能です。
- 73 -
図 3-79 JMS クライアントの場合の接続プールの設定
2)MDB の場合
MDB と SIBus のコネクションは、サーバーの「スレッド・プール」の「Default」に保持されます。管理コン
ソールの[アプリケーション・サーバー]→[server1]→[スレッド・プール]→[Default]から最大サイズなど
が設定できます。
- 74 -
図 3-80 MDB の場合の接続プールの設定
3-3-2 WebSphere MQ メッセージ・プロバイダー
WebSphere MQ を JMS プロバイダーとして利用することができます。アプリケーションは、WebSphere
MQ のキュー・マネージャー（Qmgr）に対して接続し、キューにメッセージを送信/受信できます。
WebSphere AS の JMS プロバイダーとして、WebSphere MQ V5.3 を使用するためには、WebSphere MQ
V5.3 の製品を別途購入／インストールする必要があります。
WebSphere MQ を JMS プロバイダーとして利用するには、2 種類の接続方法があります。
・バインディング接続
アプリケーション・サーバーと Qmgr が、同じ筐体（OS）上で動作している場合、バインディング接続
が利用できます。Qmgr に直接アクセスする為、クライアント接続より高速です。また、XA や、MQ ク
ラスターの負荷分散機能が利用可能であるなど、クライアント接続より多くの機能を利用できます。
- 75 -
ノード
Host01
アプリケーション・
サーバー
server1
リソース・
アダプター
キュー・マネ
ージャー
QMGR1
JMS
キュー
Queue
図 3-81 バインディング接続
・クライアント接続
Qmgr に対して、チャネル経由で接続します。基本的に XA が利用不可能であるなど、バインディン
グ接続と比べると低速で、利用できる機能も制限されます。
MQ クライアントでは、Qmgr のサーバー・接続チャネル名を指定します。
ノード
Host01
アプリケーション・
サーバー
server1
リソース・
アダプター
MQ
クライアント
ノード
Host02
キュー・
マネージャー
QMGR1
チャネル接続
JMS
図 3-82 クライアント接続
この他に、DIRECT という接続方法がありますが、DIRECT モードを使用する WebSphere MQ Event
Broker 用です。当ガイドにはその解説を含めません。
なお、バインディング接続、クライアント接続ともに設定の方法は共通ですので、本ガイドでは、接続
形態による区別はしていません(クライアント接続の場合には、バインディング接続時の構成に加え、ホ
スト名／ポート番号／チャネル名など、クライアント接続のためのプロパティーを定義する必要がありま
す)。WebSphere AS の JMS プロバイダーとして、WebSphere MQ V5.3 を使用するためには、WebSphere
MQ V5.3 の製品を別途購入／インストールして、適切に設定しておく必要があります。
＜参考＞
WebSphere MQ を使用したバインディング接続の場合には、MQ 側で以下ステップが必要になります。
1. キュー・マネージャー作成
2. キュー・マネージャー開始
3. ローカル・キュー作成
WebSphere MQ を使用したクライアント接続の場合には、バインディング接続の場合に加えて、MQ 側で
以下ステップが必要になります。
4. サーバー接続チャネル作成
5. リスナー開始
主な MQ コマンドについては、「3-5 Appendix WebSphere MQ 関連のコマンド (p.116)」を参照してくださ
い。ここでは、既に MQ が適切に構成されていることを前提として、作業手順をご紹介いたします。
- 76 -
3-3-2-1 事前準備
環境変数設定
WebSphere MQ に対して接続を行う場合、WebSphere MQ のネイティブ･ライブラリーを利用します。
UNIX 系の OS では、プロセスが起動する前に、ネイティブ・ライブラリーを読み取れるような設定を行っ
ておく必要があります。（AIX などに WebSphere MQ をインストールすると、デフォルトで読み込むネイテ
ィブ・ライブラリー・パス（/usr/lib など）に必要なパスが追加されるので、特に変更する必要はありませ
ん。）ネイティブ・ライブラリー・パスを設定する環境変数名は、OS ごとに異なります。この環境変数名
は、下表に記します。なお、Windows ではこの設定は必要ありません。
OS
環境変数名
AIX
LIBPATH
Linux
LD_LIBRARY_PATH
Solaris
LD_LIBRARY_PATH
HPUX
SHLIB_PATH
WebSphere 変数の設定
WebSphere MQ についての WebSphere 環境変数を設定します。
管理コンソールのツリー・ビュー上で、[環境]→[WebSphere 変数の管理]を選択します。複数表示され
る変数のうち、以下 2 つの値を編集してください。
名前
説明
MQ_INSTALL_ROOT WebSphere MQ のインストール先ディレクトリー ( 例えば、 C:¥Program
Files¥IBM¥WebSphere MQ)。
MQJMS_LIB_ROOT
ライブラリーのパス ( 例えば、 C:¥Program Files¥IBM¥WebSphere
MQ¥Java¥lib)。デフォルトで${MQ_INSTALL_ROOT}/java/lib に設定され
ているので、MQ_INSTALL_ROOT さえ設定すれば変更しないでも問題あり
ません。
WebSphere 変数(MQ_INSTALL_ROOT)の編集画面。編集が終了したら、[OK]をクリックします。
3-3-2-2 接続ファクトリーの設定
WebSphere MQ を利用する場合にも SIBus 同様、3 種類の接続ファクトリーを利用できます。
設定するには、管理コンソールのツリー・ビュー上で、[リソース]→[JMS プロバイダー]→[WebSphere
MQ メッセージング・プロバイダー]を選択します。WebSphere MQ メッセージング・プロバイダー構成画
面が表示されたら、右下のような追加プロパティーが表示されるので、設定したい項目を選択すると、接
続ファクトリーの一覧画面が表示されます。そこで、[新規作成]ボタンを押すと、ウィザード形式で接続フ
ァクトリーを作成できます。
WebSphere MQ 接続ファクトリー
JMS1.1 で新しく定義された Common Interface を
利用するための、接続ファクトリーです。このインタ
ーフェースを利用することで、メッセージングのタイ
プ（PTP や Pub/Sub）に依存しないメッセージング・ア
プリケーションを作成できます。アプリケーションから
は、javax.jms.ConnectionFactory として lookup しま
す。
- 77 -
WebSphere MQ キュー接続ファクトリー
PTP メッセージングで利用するための、接続ファクトリーです。アプリケーションからは、
javax.jms.QueueConnectionFactory として lookup します。
WebSphere MQ トピック接続ファクトリー
PTP メッセージングで利用するための、接続ファクトリーです。アプリケーションからは、
javax.jms.TopicConnectionFactory として lookup します。
キュー接続ファクトリーとトピック接続ファクトリーは、メッセージングのタイプ（PTP もしくは Pub/Sub）によ
って使い分けます。これに対して接続ファクトリーは、JMS1.1 で定義されたインターフェース（Common
Interface）で、どのメッセージングのタイプでも利用できます。
接続ファクトリーを作成するに当たって、重要な項目を下表に記します。（Common=接続ファクトリー、
Queue=キュー接続ファクトリー、Topic=トピック接続ファクトリー）
項目
Common
Queue
Topic
説明
名前
◎
◎
◎
名前です。
JNDI 名
◎
◎
◎
JNDI 名です。
コンポーネント管理の認証
△
△
△
JMS プロバイダーへの接続の際に
別名
使用するエイリアスを指定します。
エンタープライズ・アプリケーション
のデプロイメント・ディスクリプター
において、リソース認証の型が｢ア
プリケーション｣である場合、こちら
に、エイリアス名を指定します。
コンテナー管理認証別名
△
△
△
JMS プロバイダーへの接続の際に
使用するエイリアスを指定します。
エンタープライズ・アプリケーション
のデプロイメント・ディスクリプター
において、リソース認証の型が｢コ
ンテナー｣である場合、こちらに、
エイリアス名を指定します。なお、
WebSphere AS V6.0 からは、コンテ
ナー管理認証は非推奨です。コン
ポーネント管理認証を利用するよ
うにしてください。
キュー・マネージャー
◎
◎
◎
Qmgr 名です。
ホスト
○
○
○
Qmgr が稼動するホスト名です。
ポート
○
○
○
Qmgr への接続に使用される MQ
リスナーのポート番号です。
チャネル
○
○
○
Qmgr 上に定義されている、サー
バー接続チャネル名です。
トランスポート・タイプ
◎
◎
◎
接続方法を指定します。
モデル・キュー定義
△
△
要求されたキューがまだ存在して
いない場合に、キュー・マネージャ
ーが、一時キューの作成のために
使用するモデル・キュー定義の名
前です。
- 78 -
クライアント ID
△
△
△
CCSID
△
△
△
メッセージ保存を使用可能
にする
△
△
XA を使用可能にする
△
△
シャットダウン時にリターン・
メソッドを使用可能にする
△
△
MQ 接続プールを使用可
◎
◎
能にする
◎：必須 ○：クライアント接続で必須 △：オプション
△
◎
WebSphere MQ キュー・マネージャ
ーへの接続に使用される JMS クラ
イアント ID を指定します。
WebSphere MQ キュー・マネージャ
ーで使用される CCSID(Coded
Character Set Identifier)を指定しま
す。
メッセージ・セレクターを使用して
いる時、メッセージ・セレクターの
選別条件に合わないメッセージ
(＝どのリスナーにも処理されない
メッセージ)がキューに入った際の
挙動を決めます。このチェックボッ
クスにチェックが入っていた場合
は、処理されないメッセージはキュ
ーに残されます。チェックが入って
いない場合には、処理されないメ
ッセージは後処理オプションに応
じて処理されるようになります。
このキュー接続ファクトリーが、XA
トランザクションに使用されるもの
か、非 XA トランザクションのため
のものかを指定します。
キュー・マネージャーが制御された
シャットダウン状態になった場合
に、メソッド呼び出しからアプリケー
ションが戻されるかどうかを指定し
ます。
接続プールを利用するかどうかを
設定します。
接続プールの構成
WebSphere MQ による接続プール機能を使用可能にすると、接続が必要とされなくなった時に、
WebSphere MQ がこの接続を破棄せず、未使用接続としてプールし、再度必要とされた時に再利用しま
す。この、プールできる未使用接続の最大数と、未使用接続がタイムアウトするまでの時間を設定しま
す。
設定項目と設定方法は、JDBC の接続ファクトリーと同じですので、そちらを参照してください。
セッション・プールの構成
JMS クライアントにおいては、接続を作成し、その接続を元にセッションを作成／開始します。接続(＝
Connection)は、クライアントから JMS プロバイダーへのアクティブな接続を表すオブジェクトであり、この
接続から、Session オブジェクトを作成します。
セッション(＝Session)は、メッセージを送信／受信するためのシングルスレッドのコンテキストであり、
プロデューサー、コンシューマーのファクトリーとして機能します。また、一同期点処理の単位となりま
- 79 -
す。(WebSphere MQ の観点から見ると、JMS セッションが作成されると、MQCONN が発行されることに
なります)。キュー接続ファクトリーを利用する場合は javax.jms.QueueSession、トピック接続ファクトリーを
利用する場合は javax.jms.TopicSession、Common Interface を利用する場合には javax.jms.Session イン
ターフェースを利用します。
このセッションを、未使用になった時に破棄せず、セッション・プールに保持しておき、次回のリクエス
ト時にこのプールからセッションを再利用させることができます。
設定項目と設定方法は、JDBC の接続ファクトリーと同じですので、そちらを参照してください。
宛先の設定
宛先には二つの種類があります。PTP を行う為のキュー宛先と、Pub/Sub を行う為のトピック宛先で
す。
これに対して Common Interface の接続ファクトリーを利用する場合には、キュー宛先とトピック宛先を、
共に javax.jms.Destination として利用可能です。
設定するには、前項と同様、WebSphere MQ メッセージング・プロバイダー構成画面を開きます。そこ
で、追加プロパティーから宛先の種類を選択すると宛先一覧画面が表示されます。そこで新規作成ボタ
ンを押すと、ウィザード形式で宛先が作成できます。
キュー宛先
PTP メッセージングに利用するためのキューです。キュー接続ファクトリーを利用する場合は、キュ
ー宛先を javax.jms.Queue インターフェースで使用できます。Common Interface の接続ファクトリー
を利用する場合は、javax.jms.Destination インターフェースで使用できます。
トピック宛先
Pub/Sub メッセージングに利用するためのトピックです。トピック接続ファクトリーを利用する場合は、
トピック宛先を javax.jms.Topic インターフェースで使用できます。Common Interface の接続ファクト
リーを利用する場合は、javax.jms.Destination インターフェースで使用できます。
JMS 宛先には二つの種類があります。これらの JMS 宛先を作成するに当たって、重要な項目を下表
に記します。
項目
Queue
Topic
説明
名前
◎
◎
名前です。
JNDI 名
◎
◎
JNDI 名です。
パーシスタンス
◎
◎
このキュー宛先に送信されたメッセージが全て永続すると
いう場合は[PERSISTENT]を、全て非永続の場合は[NON
PERSISTENT]を指定します。アプリケーションによって永
続／非永続を決定する場合は [APPLICATION
DEFINED] を選択します。また、永続／非永続が
WebSphere MQ キュー定義プロパティーで決定される場
合は、[QUEUE DEFINED]を指定します。
優先順位
◎
◎
この宛先に入るメッセージの優先順位について設定しま
す。①優先順位が、メッセージを宛先に入れるアプリケー
ションで決定される場合は[APPLICATION DEFINED]を
指定します。②優先順位がキューごとに決定される場合は
[QUEUE DEFINED]を指定します。③優先順位が[指定さ
れた優先順位]プロパティー(後述)にて決定される場合に
- 80 -
は[SPECIFIED]を指定します。
上の[優先順位]プロパティーの値が[SPECIFIED]になって
いる場合、このフィールドに、このキューのメッセージの優
先順位(０－９)を指定します。優先順位は 0 が一番低く、9
が一番高くなります。
有効期限
△
△
このキューに入ったメッセージの有効期限について設定し
ます。①有効期限がアプリケーションで決定される場合は
[APPLICATION DEFINED]を指定します。②有効期限が
[指定された有効期限]プロパティー(後述)にて決定される
場合には、[SPECIFIED]を指定します。③このキューに入
ったメッセージの期限を無期限とする場合には、
[UNLIMITED]を指定します。
指定された有効期
△
△
上の[有効期限]プロパティーの値が[SPECIFIED]になって
限
いる場合、このフィールドに、このキューに入るメッセージ
が期限切れになるまでの時間(ミリ秒単位)を指定します。
基本キュー名/基
◎
◎
前ステップにて作成したキューの名前を指定します。大文
本トピック名
字小文字が区別されます。(mqsc で作成したキュー名は、
シングルクォーテーションで囲わなかった場合には、大文
字になります。)
基本キュー・マネ
○
○
メッセージが送信されるキュー・マネージャー名を指定しま
ージャー名
す。
CCSID
△
△
キュー・マネージャーにより使用される CCSID(Coded
Character Set Identifier)を指定します。
ターゲット・クライア
△
△
受信側アプリケーションが JMS 互換のアプリケーションか、
ント
または JMS を使用しない、一般的な WebSphere MQ アプリ
ケーションかを指定します。
キュー・マネージャ
○
キュー宛先が定義されているキュー・マネージャーの存在
ーのホスト名
するホスト名
キュー・マネージャ
○
キュー宛先が定義されているキュー・マネージャーによっ
ーのポート
て使用されるポート番号
サーバー接続チャ
○
キュー・マネージャーへの接続のために使用するチャネル
ネル名
の名前。
ユーザーID
○
キュー・マネージャーに接続する際の認証に対して使用さ
れるユーザーID
パスワード
○
上記ユーザーID に対応するパスワード
◎：必須 ○：クライアント接続で必須 △：オプション
指定された優先順
位
△
△
3-3-2-3 MDB 関連の設定
WebSphere MQ のキューを MDB で利用す
る場合、メッセージ・リスナー・サービスを設定
する必要があります。メッセージ・リスナー・サ
ービスを設定するには、管理コンソールのツリ
ー・ビュー上で、[サーバー] → [サーバー
- 81 -
名] → [通信：メッセージング：メッセージ・リスナー・サービス] を選択します。
リスナー・ポートの構成
リスナー・ポートは MDB を動作させるために必要で、宛先の監視に必要な、接続ファクトリーや宛先
の情報を設定します。
設定するには、管理コンソールのツリー・ビュー上で、[サーバー]→[サーバー名]→[通信：メッセージ
ング：メッセージ・リスナー・サービス]→[リスナー・ポート]を選択すると、リスナー・ポート一覧画面が表
示されます。この画面では、メッセージ・リスナーを始動/停止できます。ここで新規作成ボタンを押すと、
リスナー・ポートを作成できます。
主な設定項目を下表に記します。
項目
説明
名前
リスナー・ポートの名前です。
初期状態
サーバーが最初に開始されるときの、リスナー・ポートの実行状態
です。開始済み／停止済みの 2 つが選択できます。MDB によるキ
ュー／トピックの監視を行うためには、開始済みになっている必要
があります。
接続ファクトリーJNDI 名
JMS 接続ファクトリーの JNDI 名を指定します。
宛先 JNDI 名
JMS 宛先の JNDI 名を指定します。
最大セッション数
リスナーが使用できる JMS サーバーのセッション数の最大値です。
最大再試行数
ここに指定した回数だけ、リスナーはメッセージの配信を試行しま
す。この数だけ再試行を行うと、リスナーは停止します。
最大メッセージ数
JMS サーバー・セッションで、リスナーが処理できるメッセージ数の
最大値です。
スレッド・プールの構成
スレッド・プールは、一度作成された MDB インスタ
ンスを再利用するための仕組みです。MDB を利用
する上でのパフォーマンス・チューニングが可能に
なります。
設定するには、管理コンソールのツリー・ビュー上
で、[サーバー]→[サーバー名]→[通信：メッセージ
ング：メッセージ・リスナー・サービス]→[スレッド・プ
ール]を選択すると、スレッド・プール構成画面が表
示されます。
- 82 -
主な設定項目を下表に記します。
項目
説明
最小サイズ
プールされるスレッドの最小数です。
最大サイズ
プールされるスレッドの最大数です。
スレッド非活動タイムアウト
使用されないスレッドが破棄されるまでの時間間隔(ミリ
秒)を指定します。
最大スレッド・サイズを超えたススレッド・プールに設定されている最大サイズ(上から 2 番
レッド割り振りを許可
目のプロパティー)を超えた数のスレッドを作成できるか
否かを設定します。最大サイズ以上の数のスレッドを作
成可能にするためには、チェックボックスにチェックを入
れます。
3-4 SIBWS 構成
この節では、SIBus 上で Web サービスを扱えるようにするための機能である SIBWS（Service
Integration Bus Web Services enablement）について説明します。
3-4-1 SIBWS 概要
SIBWS を使用することにより SIBus 上の宛先（ディスティネーション）を Web サービスとして外部に公
開することが可能となります（インバウンド・サービス）。また、SIBus 上のアプリケーションから Web サービ
スを呼び出すことも可能になります（アウトバウンド・サービス）。このインバウンド・サービスとアウトバウン
ド・サービスの両方を使用することにより Web サービスの間に SIBus を通すシステムを構築することがで
きます。
WebSphere AS ND 環境の場合は、SIBWS を使用して Web サービス・ゲートウェイを構築することも可能
となります。
WSDL
WSDL
Webサービス
・クライアント
Server A
Server B
ME
ME
ME
ME
Webサービス
SIBus
インバウンド・
サービス
アウトバウンド・
サービス
図 3-83 SIBWS 概要
SIBWS を使用することにより、SIBus と Web サービスを連携させるシステムを容易に構築できるように
なります。既存の Web サービスがあれば、アプリケーションを変更することなく管理コンソールから
SIBWS の設定をするだけでシステム構築を完了させることが可能となります。
Web サービスの要求が SIBus を通ることにより、通常の SIBus 上のアプリケーションと同じく管理コンソ
ールからメディエーション機能を設定できるようになります。また、SIBWS ではメディエーション以外に
JAX-RPC ハンドラーや WS-Security 機能を管理コンソールから設定できるようになります。通常の Web
- 83 -
サービスでは、JAX-RPC ハンドラーや WS-Security は開発時にデプロイメント・ディスクリプターに設定
する必要がありますが、SIBWS 機能を使用すると WebSphere AS へデプロイ後に管理コンソールから設
定することができるようになります。これにより、アプリケーション作成後も非常に柔軟にシステムを構成
／変更することが可能となり、メンテナンス性も向上します。
また、SIBWS を使用することにより SIBus 上で Web サービスに対して次のような事を実現することがで
きます。
•
プロトコルの変換（例： SOAP/HTTP → SOAP/JMS）
•
サービスリクエストのルーティング
•
メッセージの取得／加工
3-4-1-1 インバウンド・サービス
インバウンド・サービスは、SIBus 上の宛先を Web サービスとして外部からコールできるようにするため
の機能です。
JAX-RPC
ハンドラー
WS-Security
SOAP over HTTP
エンドポイント・
リスナー
Webサービス・
クライアント
WSDL
インバウンド・
ポート
インバウンド・サービス
SOAP over JMS
エンドポイント・
リスナー
インバウンド・
ポート
JAX-RPC
ハンドラー
サービス宛先
WS-Security
メディエーション
SIBus
図 3-84 インバウンド・サービスの構造
エンドポイント・リスナーとは、SIBus で Web サービスの要求受付口となる部分です。エンドポイント・リ
スナーの実態は Web サービスの要求を受け付ける J2EE アプリケーションで、インバウンド・サービスを使
用する各アプリケーション・サーバー／クラスター上にインストールする必要があります。エンドポイント・
リスナーには、SOAP/HTTP 用と SOAP/JMS 用の 2 種類があり、さらにそれぞれの種類ごとに 2 つずつ、
合計４つのエンドポイント・リスナーが作成可能です。それぞれの種類ごとの２つのエンドポイント・リスナ
ーは特に違いはなく、使い分けが必要な環境で自由に区別して使用することができます。例えば、社内
用と社外用に分けてセキュリティーをそれぞれごとに変えるといったような使い分けをします。
インバウンド・ポートは、エンドポイント・リスナーとインバウンド・サービスの間に位置し、インバウンド・
サービスごとに複数作成することが可能です。インバウンド・ポートでは、接続するエンドポイント・リスナ
ーや WS-Security、使用する JAX-RPC ハンドラーを設定できます。この設定は、インバウンド・ポート内
の設定項目として設定できるので開発時に WS-Security や JAX-RPC ハンドラーを設定する必要はな
く、いつでも管理コンソールから自由に設定の変更が可能になります。
インバウンド・サービスは、サービスとして公開する単位毎に作成し、エンドポイント・リスナー、インバ
ウンド・ポートと結び付けます。作成されたインバウンド・サービスは自分自身を表す WSDL を必ず１つ
持っていて、これを Web サービス・クライアントに公開します。
- 84 -
サービス宛先とは、Web サービスとして公開する SIBus 上の宛先です。サービス宛先として登録できる
ものは、キュー、トピック、宛先の別名、他の SIBus 上の宛先があります。これらのサービス宛先はメッセ
ージング・エンジン(ME)上に存在します。
サービス宛先では通常の SIBus のアプリケーションと同様に、使用するメディエーションも設定するこ
とが可能です。メディエーションを作成することにより、SIBus で Web サービスのメッセージを取得したり
変更したりすることが可能となります。メディエーションの設定は、該当宛先を使用する全てのサービス
に影響を及ぼす点に注意してください。
3-4-1-2 アウトバウンド・サービス
アウトバウンド・サービスは、SIBus を利用するアプリケーションから Web サービスをコールすることがで
きるようにします。アウトバウンド・サービスは、SIBus 上ではサービス宛先として見えます。言い換えれ
ば、アウトバウンド・サービスは Web サービスをサービス宛先として扱うための機能と言えます。
WS-Security
JAX-RPC
ハンドラー
SOAP over HTTP
アウトバウンド・
ポート
ポート
宛先
WSDL
SOAP over JMS
アウトバウンド・サービス
アウトバウンド・
ポート
サービス宛先
ポート
宛先
Webサービス
EJB
メディエーション
JAX-RPC
ハンドラー
アウトバウンド・
ポート
ポート
宛先
WS-Security
SIBus
図 3-85 アウトバウンド・サービスの構造
アウトバウンド・サービスを作成するには、WSDL を公開している実際の Web サービスが既に存在して
いる必要があり、対象となる Web サービス毎にアウトバウンド・サービスを作成します。
アウトバウンド・サービスには接続するアウトバウンド・ポートを指定します。このアウトバウンド・ポートに
対して WS-Security と使用する JAX-RPC ハンドラーを設定できます。この設定は、アウトバウンド・ポート
内の設定項目として設定できるので開発時に WS-Security や JAX-RPC ハンドラーを設定する必要はな
く、いつでも管理コンソールから自由に設定の変更が可能になります。通常の SIBus のアプリケーション
と同様に、アウトバウンド・サービスのサービス宛先に対してメディエーションも設定することも可能で
す。
ポート宛先は、Web サービスをコールするための Service Invoker の役割を果たします。Web サービス
側からは、ポート宛先が Web サービス・クライアントとして見えます。ポート宛先と Web サービス間の通信
には SOAP/HTTP、SOAP/JMS、EJB(IIOP)のいずれかを選択できます。
- 85 -
3-4-1-3 Web サービス・ゲートウェイ
Web サービス・ゲートウェイは、WebSphere AS V5 で提供されていた Web サービス・ゲートウェイ機能
を置き換える機能です。WebSphere AS V6.0 では、この機能は単体で稼動するのではなく SIBus に融合
され SIBus の一機能として稼動します。これにより、SIBus 上の宛先をターゲットにすることが可能となりま
す。この機能を使用するには WebSphere AS ND 環境が必要となります。
Web サービス・ゲートウェイ機能には、ゲートウェイ・サービスとプロキシー・サービスの 2 つのサービス
があります。
Web サービス・ゲートウェイを使用するには、初めに Web サービス・ゲートウェイ・インスタンスを作成す
る必要があります。Web サービス・ゲートウェイ・インスタンスは、ゲートウェイ・サービスとプロキシー・サー
ビスの 2 つのサービスを論理的に 1 つのグループとして管理するためのものです。これにより外部からの
Web サービスへのアクセスに対して、セキュリティーやルーティング、プロトコル変換等の管理を管理コン
ソールから集中して行うことが可能となります。
ゲートウェイ・サービスは、Web サービス間を仲介する役目を果たします。この機能は実態は、インバウ
ンド・サービスとアウトバウンド・サービスを同時に提供するものです。
WS-Security
SOAP over HTTP
アウトバウンド・ポート
ポート宛先
WSDL
SOAP over JMS
アウトバウンド・サービス
アウトバウンド・ポート
ポート宛先
サービス宛先
Webサービス
EJB
メディエーション
アウトバウンド・ポート
ポート宛先
JAX-RPC
ハンドラー
SOAP over HTTP
WSDL
エンドポイント・
リスナー
Webサービス・
クライアント
インバウンド・
ポート
ゲートウェイ・サービス
SOAP over JMS
エンドポイント・
リスナー
インバウンド・
ポート
JAX-RPC
ハンドラー
サービス宛先
WS-Security
メディエーション
SIBus
図 3-86 ゲートウェイ・サービスの構造
このサービスにより、別々に作成していたインバウンド・サービスとアウトバウンド・サービスを一括して
作成／管理することが可能になります。機能としては、インバウンド・サービスやアウトバウンド・サービス
と同じように、セキュリティー、プロトコル変換、メッセージ取得／変換をゲートウェイ・サービスで行うこと
ができるようなります。また、公開しているサービス情報（WSDL）をそのままにしてターゲットの Web サー
ビスを管理コンソールから簡単に変更することができるようになるので、クライアントには一貫したサービ
スを提供しつつ実態の Web サービスを必要に応じて変えることが可能となります。
プロキシー・サービスは、JAX-RPC ハンドラーによるプロキシーを実現する機能です。
ゲートウェイ・サービスでは実際に稼動している Web サービスを指定しますが、プロキシー・サービスで
は設定時には実体のないダミーの宛先を指定します。実際の要求は、JAX-RPC ハンドラーにより宛先
をセットする必要があります。この機能により、JAX-RPC ハンドラーのプログラムが動的に宛先の Web サ
ービスを決定することが可能なので、何らかのキーにより複数の Web サービスの中から対象とする Web
サービスに要求を投げることが可能となります。その際、事前に宛先の対象となる複数の Web サービス
を登録しておく必要がなくなります。
- 86 -
3-4-2 SIBWS の構築
WebSphere AS V6.0 を導入しただけでは、SIBWS は使用できません。別途 SIBWS 実行モジュールを
使用するアプリケーション・サーバー／クラスターに導入する必要があります。ここでは、SIBWS 実行モ
ジュールの導入手順を示していきます。構築するサンプル・構成を図 3-87に示します。
ME
データストア
INMEDS
ME
データストア
OUTMEDS
SIBus: SIBus01
Cluster: OutboundCluster
Cluster: InboundCluster
Node:
host1Node01
OutMember11
InMember11
ME
ME
アウトバウンド
サービス
インバウンド
サービス
Webサービス
・プロバイダー
Webサービス
・リクエスター
OutMember21
InMember21
ME
ME
Node:
host2Node01
アウトバウンド
サービス
インバウンド
サービス
SDO
リポジトリー
SDO
図 3-87 SIBWS のサンプル構成
ここでは、インバウンド・サービスとアウトバウンド・サービスをそれぞれ異なるクラスターで実行する構
成を説明しますが、インバウンド・サービスとアウトバウンド・サービスはどちらもクラスターではなく、単一
のアプリケーション・サーバー上で稼動させることもできますし、インバウンド・サービスとアウトバウンド・
サービスを同一のアプリケーション・サーバー（またはクラスター）上で稼動させることも可能です。つま
り、もっとも簡単な構成では、単一のアプリケーション・サーバー上で、インバウンド・サービスとアウトバウ
ンド・サービスを同居させて稼動させることも可能です。インバウンド・サービスとアウトバウンド・サービス
をクラスター上に構成する場合と、単一のアプリケーション・サーバー上に構成する場合には、以下のよ
うな違いがあります。
•
wsadmin スクリプトに渡す変数が、一部異なる
•
WebSphere AS ND 上に構成する場合、SDO リポジトリーのデータ・ソースとして、デフォルトの
組み込み Cloudscape データベースを使用することはできない
•
WebSphere AS ND 上に構成する場合は、メッセージング・エンジンのパーティショニング構成や
メッセージング・エンジンのポリシーの設定が必要になる
ただ、基本的な構成手順に違いはありません。スクリプトの引数などの手順の違いについては、それ
ぞれの手順の中で説明します。
SIBWS 構築の手順の概要は下記のようになります。
1). SIBWS 稼動に必要なリソースの作成と構成
SDO リポジトリーの作成や SIBus にバス・メンバーを追加します。
2). SIBWS 稼動に必要なアプリケーションのインストール
- 87 -
Web サービス・メッセージ(SOAP メッセージ)が、SIBus を経由する際に必要となるアプリケーショ
ンをインストールします。
3). SIBWS の構成
エンドポイント・リスナー、インバウンド・サービス、アウトバウンド・サービスを構成します。
3-4-2-1 SIBWS 稼動に必要なリソースの作成と構成
SIBWS の稼動に必要な、SDO リポジトリーの作成や SIBus にバス・メンバーを追加します。具体的な
手順は下記のとおりです。
1). SDO リポジトリー用データベース、テーブルの作成
2). メッセージング・エンジンのデータ・ストア用データベースの作成
3). SDO リポジトリー用データベースにアクセスするデータ・ソースの作成
4). メッセージング・エンジンのデータ・ストア用データベースにアクセスするデータ・ソースの作成
5). インバウンド・サービス/アウトバウンド・サービス用のクラスターの作成
6). SIBus の作成
7). SIBus にバス・メンバーの追加
Step1 SDO リポジトリー用データベース、テーブルの作成
SIBWS は SDO リポジトリー（データベース）を使用して、WSDL 定義を保管し、サービス提供を行いま
す。インバウンド・サービスやアウトバウンド・サービスを作成する際、必ず WSDL 定義を読み込む必要
があります。このとき読み込まれた WSDL 定義は SDO リポジトリーに保管されます。
SDO リポジトリーとしては、DB2 などのデータベースを使用します。その他、Oracle や Microsoft SQL
Server なども使用可能ですが、デフォルトで使用される組み込み Cloudscape については、WebSphere
AS Base 版でのみ使用可能ですので、ご注意ください。手順の詳細は下記の InfoCenter の記載を参照
ください。
InfoCenter「SDO リポジトリーのインストール」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_install_sdo.html
ここでは、データベースとして DB2 V8.2 を使用する場合の手順を説明します。
テーブル定義は、各データベース用に準備されています。設定する項目、使用するスクリプトは下記の
表のとおりです。
データベース名
SDO (任意)
テーブル定義の <WAS_root>/util/SdoRepository/DB2UDB_V82/Table.ddl
スクリプト
( 各データベースやバージョンによって、DB2UDB_V82 の部分は異なります。例え
ば、Oracle 10g の場合は下記のファイルを使用します。
<WAS_root>/util/SdoRepository/ORACLE_V10G/Table.ddl )
データベースとテーブルを作成するには、下記のコマンドを実行します。今回は WebSphere AS と
DB2 が同居する構成で、実行していますが、WebSphere AS とデータベースが異なる筐体の場合は、使
用する Table.ddl ファイルをデータベース・サーバーにコピーし、データベースの作成とテーブルの作成
を実行します。
例 3-1 SDO レポジトリー用データベースとテーブルの作成
$ db2 create db SDO
DB20000I
CREATE DATABASE コマンドが正常に終了しました。
$
$ db2 connect to SDO user db2inst1 using db2inst1
- 88 -
データベース接続情報
データベース・サーバー
= DB2/6000 8.2.0
SQL 許可 ID
= DB2INST1
ローカル・データベース別名
= SDO
$ cd /usr/WebSphere60/AppServer/util/SdoRepository/DB2UDB_V82
$
$ db2 -tvf Table.ddl
CREATE SCHEMA SDOREP
DB20000I
SQL コマンドが正常に終了しました。
CREATE TABLE SDOREP.BYTESTORE (NAME VARCHAR(250) NOT NULL, BYTES BLOB(1G), TIMES
TAMP1 BIGINT NOT NULL)
DB20000I
SQL コマンドが正常に終了しました。
ALTER TABLE SDOREP.BYTESTORE ADD CONSTRAINT PK_BYTESTORE PRIMARY KEY (NAME)
DB20000I
SQL コマンドが正常に終了しました。
$
$ db2 terminate
DB20000I
TERMINATE コマンドが正常に終了しました。
$
この操作により、SDO レポジトリー用のデータベース：SDO にスキーマ：SDOREP とテーブル：
BYTESTORE が作成されます。
尚、Oracle、Sybase、および SQL Server の各データベースでは、事前に SDOREP というユーザー
ID が作成され、SDO リポジトリー・データベースへのアクセス権が付与されている必要があります。
SDOREP ユーザーには、データベースに対する、読み取りおよび書き込みのアクセス権を付与する必
要があります。
また、WebSphere AS Base を使用したスタンドアローン構成で、Cloudscape をデータベースとして使用
する場合は、上記のデータベース作成の操作は必要ありません。後ほど実施する SDORepository アプリ
ケーションのインストール時に、同時に Cloudscape 上にデータベースを作成します。さらに、次のメッセ
ージング・エンジン用のデータ・ストアとしても Cloudscape を使用する場合には、「Step6 SIBus の作成
(p.96)」の手順にすすんでください。ただ、本番環境での Cloudscape の使用は、推奨されていませんの
で、できるかぎり DB2 などのデータベースを使用することをお勧めします。
Step2 メッセージング・エンジンのデータ・ストア用データベースの作成
インバウンド・サービスやアウトバウンド・サービスを実行するアプリケーション・サーバーまたはクラスタ
ーは SIBus のメンバーとして登録する必要があり、アプリケーション・サーバーまたはクラスターでは、メッ
セージング・エンジンが稼動します。したがって、バス・メンバーに登録する前に、メッセージング・エンジ
ン用のデータ・ストア用のデータベースを準備する必要があります。SDO リポジトリー用のデータベース
と同様に、WebSphere AS Base を使用したスタンドアローン構成の場合は組み込み Cloudscape をデータ
ベースとして使用することも可能ですが、クラスターをバス・メンバーとして登録する場合には、組み込み
の Cloudscape を使用することはできませんので、DB2 などのデータベースを使用する必要があります。
- 89 -
メッセージング・エンジンのデータ・ストア用データベースの詳細は、「3-2-2 メッセージング・エンジンの
構成 (p.15)」を参照ください。
ここでは、インバウンド・サービス用とアウトバウンド・サービス用にそれぞれ異なるクラスターをバス・メ
ンバーとして登録し、2 つのデータベースを作成します。インバウンド・サービスとアウトバウンド・サービ
スを同一のアプリケーション・サーバーまたはクラスターで稼動させる場合には、1 つのデータベースで
十分です。インバウンド・サービスとアウトバウンド・サービスを異なるアプリケーション・サーバーまたはク
ラスターで稼動させる場合にも、スキーマを分離して同一のデータベースを使用することもできます。ま
た、クラスターをバス・メンバーとして登録し、キュー宛先を複数のクラスターメンバー上で同時に稼動
し、負荷分散を実行するパーティショニングの構成を行うには、それに合わせて複数の、データベース
またはスキーマを作成する必要があります。メッセージング・エンジンのパーティションニングの詳細は、
「3-2-1-3パーティション構成11)」を参照ください。
ここでは、SDO レポジトリーを作成したのと同様の DB2 を使用し、下記のインバウンド・サービス用とア
ウトバウンド・サービス用のデータベースを作成します。
インバウンド・サービス用データベース名
INMEDS (任意)
アウトバウンド・サービス用データベース名 OUTMEDS (任意)
実行コマンドは下記のようになります。
例 3-2 メッセージング・エンジンのデータ・ストア用のデータベースの作成
$ db2 create db INMEDS
DB20000I
CREATE DATABASE コマンドが正常に終了しました。
$
$ db2 create db OUTMEDS
DB20000I
CREATE DATABASE コマンドが正常に終了しました。
$
尚、今回はインバウンド用とアウトバウンド用でデータベースを分けましたが、バス・メンバーの登録時
に、メッセージング・エンジンのデータ・ストアのスキーマ名を指定することができますので、インバウンド
用とアウトバウンド用でスキーマ名を分けて同一のデータベースを使用することもできます。
Step3 SDO リポジトリー用データベースにアクセスするデータ・ソースの作成
SDO リポジトリー用データベースにアクセスするデータ・ソースを作成します。すでに業務アプリケー
ションやセッション・パーシスタンスのためにデータベースへの接続設定を行っていて、すでに定義され
ている項目がある場合には、その設定を利用してください。
データ・ソースの定義を作成するには、以下の手順で設定を行います。
1). WebSphere 環境変数の設定
2). J2C 認証データの設定
3). JDBC プロバイダーの設定
4). データ・ソースの設定
以下の設定作業はすべて管理コンソールから行います。
まず、WebSphere 環境変数の設定を行います。SDO リポジトリーのデータ・ソースは、有効範囲をセル
レベルで定義する必要がありますので、WebSphere 環境変数の設定も有効範囲をセルレベルで行い、
それよりも優先されるノードレベルやサーバーレベルで不適切な値に上書きされないように、同一の値も
しくは適切な値を入力するか、その変数を削除する必要があります。デフォルトで変数値が空白または
入力されている箇所がありますので注意してください。（デプロイメント・マネージャー・ノードの値に注
意。）
DB2 Universal JDBC Driver を使用する場合に設定が必要な WebSphere 変数の値は下記の表のと
おりです。
- 90 -
変数名
変数値
WAS_INSTALL_ROOT
<WAS_root>
UNIVERSAL_JDBC_DRIVER_PATH
${WAS_INSTALL_ROOT}/universalDriver/lib
DB2UNIVERSAL_JDBC_DRIVER_PATH
<DB2_root>/java
DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH <DB2_root>/lib
WebSphere 変数の設定を変更するには、管理コンソールで、[環境]→[WebSphere 変数]を選択しま
す。有効範囲の設定で、ノード、クラスター、サーバーの設定を空白にして、[適用]ボタンを押下します。
デフォルトでは、セルレベルの変数はありませんので、[適用]ボタンを押下して、上記表の変数を設定し
ます。（図 3-88参照）。
図 3-88 WebSphere 変数の設定
その後、必ず、WebSphere 変数の有効範囲を変更して、すべてのノードで同一の変数名の値が空白
値や不適切な値になっていないか確認してください。変数名がない場合には、上位の変数の値が使用
されますので、特に問題にはなりません。
次に J2C 認証データの設定を行います。これは WebSphere AS からデータベースにアクセスするときに
使用するユーザーID とパスワードを登録します。下記の設定を新規作成します。
別名
WebSphere AS 上での表示・登録名 (任意、ここでは db2inst1 とする)
ユーザーID DB へのアクセス・ユーザーID
パスワード
DB へのアクセス・ユーザーのパスワード
- 91 -
管理コンソールで、[セキュリティー]→[グローバル・セキュリティー]→[認証]→[JAAS 構成]→[J2C
認証データ]を選択し[新規作成]ボタンを押下します。上記表の設定を入力します（図 3-89参照）。
図 3-89 J2C 認証データの設定
次に、JDBC プロバイダーの設定を行います。SDO リポジトリー用のデータ・ソースを定義する JDBC
プロバイダーはセルレベルで定義する必要があり、データ・ソースの種類としては、XA のデータ・ソース
を構成する必要があります。ここでは、DB2 Universal JDBC ドライバーを使用しての設定を行います。
設定値は下記の表のようになります。
有効範囲
セルレベル
データベース
DB2
プロバイダー・タイプ
DB2 Universal JDBC Driver Provider
インプリメンテーション・タイプ
XA データ・ソース
名前
DB2 Universal JDBC Driver Provider (XA)
インプリメンテーション・クラス名 com.ibm.db2.jcc.DB2XADataSource
管理コンソールで、[リソース]→[JDBC プロバイダー]を選択し、有効範囲をセルレベルに変更（有効
範囲の設定で、ノード、クラスター、サーバーの設定を空白にして、[適用]ボタンを押下）した後、[新規
作成]ボタンを押下します。上記表の値を入力します（図 3-90参照）。
- 92 -
図 3-90 JDBC プロバイダーの設定
続いて SDO レポジトリー用のデータ・ソースの設定を行います。データ・ソースの設定では、「コンテナ
ー管理パーシスタンス (CMP) 内でこのデータ・ソースを使用する」のチェックボックスを ON にすること
と、JNDI 名を「jdbc/com.ibm.ws.sdo.config/SdoRepository」に設定することが必須になります。設定値は
下記の表のようになります。
名前
SDO Repository DS (任意)
JNDI 名
jdbc/com.ibm.ws.sdo.config/SdoRepository
コンテナー管理パーシスタンス ON
で使用
コンポーネント管理の認証別名 db2inst1 (J2C 認証データで設定した別名)
データベース名
SDO (SDO レポジトリー用に作成したデータベース名)
ドライバー・タイプ
4 (type 2 でも構いません)
サーバー名
DB サーバーのホスト名を指定 (type4 の場合に設定が必要)
ポート番号
50000 (type4 の場合に設定が必要。DB のポート番号が異なる場合
は変更)
管理コンソールで、[リソース]→[JDBC プロバイダー]を選択し、先ほど作成した JDBC プロバイダー
[DB2 Universal JDBC Driver Provider (XA)]のハイパーリンクをクリックします。JDBC プロバイダー
のプロパティー画面で、[追加プロパティー]→[データ・ソース]を選択し、[新規作成]ボタンを押下しま
す。上記表の値を入力します（図 3-91参照）。図では、画面の一部しか表示されていませんが、画面を
スクロールして、接続先データベースの設定も入力してください。
- 93 -
図 3-91 データ・ソースの設定
データ・ソースの設定を構成情報に保管した後、データ・ソースのプロパティー画面にある[テスト接
続]ボタンを使用して、データ・ソースの接続が正しくできていることを確認してください。
Step4 メッセージング・エンジンのデータ・ストア用データベースにアクセスする
データ・ソースの作成
SDO リポジトリー用データベースの作成と同様に、メッセージング・エンジンのデータ・ストア用データ
ベースにアクセスするデータ・ソースを作成します。WebSphere 変数と J2C 認証データの設定は、SDO リ
ポジトリー用の設定を共用します。メッセージング・エンジン用のデータ・ソースのタイプは XA である必
要はありませんので、JDBC プロバイダーから新規に作成します。メッセージング・エンジン用のデータ・
ソースの詳細は下記の InfoCenter の記載を参照ください。
InfoCenter「JDBC データ・ソースの構成」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjm0040_.html
DB2 Universal JDBC ドライバーを使用しての設定は下記の表のようになります。
有効範囲
セルレベル (必ずしもセルレベルで定義する必要はありません。ク
ラスターレベルや各クラスターメンバーが存在するノードごと設定し
ても構いません。)
データベース
DB2
プロバイダー・タイプ
DB2 Universal JDBC Driver Provider
インプリメンテーション・タイプ
接続プール・データ・ソース
名前
DB2 Universal JDBC Driver Provider
インプリメンテーション・クラス名
com.ibm.db2.jcc.DB2ConnectionPoolDataSource
設定方法は SDO リポジトリー用の JDBC プロバイダーを設定したときと同様です。
続いて、データ・ソースを設定します。今回は、インバウンド・サービス用とアウトバウンド・サービス用に
別々のデータベースを作成しましたので、それぞれについてデータ・ソースを作成します。設定値はそ
れぞれ下記の表のとおりです。
- 94 -
例 3-3 インバウンド・サービスのメッセージング・エンジン用のデータ・ソース設定
名前
JNDI 名
コンテナー管理パーシスタンス
で使用
コンポーネント管理の認証別名
データベース名
ドライバー・タイプ
サーバー名
ポート番号
Inbound ME DS (任意)
jdbc/inboundMEDS
ON
db2inst1 (J2C 認証データで設定した別名)
INMEDS (インバウンド・サービスのメッセージング・エンジン用に作
成したデータベース名)
4 (type 2 でも構いません)
DB サーバーのホスト名を指定 (type4 の場合に設定が必要)
50000 (type4 の場合に設定が必要。DB のポート番号が異なる場合
は変更)
例 3-4 アウトバウンド・サービスのメッセージング・エンジン用のデータ・ソース設定
名前
JNDI 名
コンテナー管理パーシスタンス
で使用
コンポーネント管理の認証別名
データベース名
Outbound ME DS (任意)
jdbc/outboundMEDS
ON
db2inst1 (J2C 認証データで設定した別名)
OUTMEDS (アウトバウンド・サービスのメッセージング・エンジン用に
作成したデータベース名)
ドライバー・タイプ
4 (type 2 でも構いません)
サーバー名
DB サーバーのホスト名を指定 (type4 の場合に設定が必要)
ポート番号
50000 (type4 の場合に設定が必要。DB のポート番号が異なる場合
は変更)
設定方法は SDO リポジトリー用の JDBC プロバイダーを設定したときと同様です。メッセージング・エ
ンジンのデータベースは、Web サービス・クライアントからリクエスト・メッセージや Web サービス・サーバ
ーからのレスポンス・メッセージが SIBus を通過するときに保管されるデータベースになりますので、接続
プールのサイズのチューニングが必要になる場合があります。
Step5 インバウンド・サービス/アウトバウンド・サービス用のクラスターの作成
SIBWS を稼動するアプリケーション・サーバーまたはクラスターを作成します。必ずしも新規にアプリ
ケーション・サーバーまたはクラスターを作成することはなく、既存のアプリケーション・サーバーまたはク
ラスターを使用することもできます。
また、インバウンド・サービス用とアウトバウンド・サービス用のアプリケーション・サーバーまたはクラス
ターを分離することもできますし、同一のアプリケーション・サーバーまたはクラスターで稼動させることも
できます。
ここでは、インバウンド・サービス用とアウトバウンド・サービス用にそれぞれ異なるクラスターを新規に
作成します。以下の表のクラスターを作成します。
インバウンド・サービス用クラスター名
InboundCluster (任意)
クラスターメンバー名
名前：InMember11, ノード：host1Node01 (任意)
クラスターメンバー名
名前：InMember21, ノード：host2Node01 (任意)
アウトバウンド・サービス用クラスター名 OutboundCluster (任意)
クラスターメンバー名
名前：OutMember11, ノード：host1Node01 (任意)
クラスターメンバー名
名前：OutMember21, ノード：host2Node01 (任意)
- 95 -
Step6 SIBus の作成
インバウンド・サービス及びアウトバウンド・サービスを稼動する SIBus を作成します。既存の SIBus が
セル内に存在する場合には、その SIBus を使用できます。
ここでは、新規に下記の SIBus を作成します。
SIBus 名
SIBus01 (任意)
SIBus を新規に作成するには、管理コンソールで、[サービス統合]→[バス]を選択し、[新規作成]ボタ
ンを押下します。
Step7 SIBus にバス・メンバーの追加
インバウンド・サービス用およびアウトバウンド・サービス用のアプリケーション・サーバーもしくはクラス
ターを SIBus にバス・メンバーとして追加します。
バス・メンバーの追加時の設定項目は下記の表のとおりです。
表 3-9 インバウンド用クラスターをバス・メンバーとして追加時の設定値
追加先 SIBus 名
バス・メンバーの種類
クラスター名
データ・ソース JNDI 名
スキーマ名
認証別名
テーブルの作成
SIBus01
クラスター
InboundCluster
jdbc/inboundMEDS
IBMWSSIB (変更可能)
必要に応じて追加
ON
表 3-10 アウトバウンド用クラスターをバス・メンバーとして追加時の設定値
追加先 SIBus 名
SIBus01
バス・メンバーの種類
クラスター
クラスター名
OutboundCluster
データ・ソース JNDI 名
jdbc/outboundMEDS
スキーマ名
IBMWSSIB (変更可能)
認証別名
必要に応じて追加
テーブルの作成
ON
バス・メンバーを追加するには、管理コンソールで、[サービス統合]→[バス]を選択し、先ほど作成し
た SIBus[SIBus01]のハイパーリンクをクリックします。SIBus のプロパティー画面で、[トポロジー]→[バ
ス・メンバー]を選択し、[追加]ボタンを押下します。上記表のクラスター名、データ・ソース JNDI 名の値
を入力し、バス・メンバーを追加します（図 3-92参照）。尚、デフォルトでは、スキーマ名は IBMWSSIB
でテーブルが作成されます。一つのデータベースを複数のメッセージング・エンジンのデータ・ストアとし
て共有する場合には、スキーマ名を変更する必要があります。スキーマ名を変更するには、管理コンソ
ールで、[サービス統合]→[バス]を選択し、SIBus[SIBus01]のハイパーリンクをクリックします。SIBus の
プロパティー画面で、[トポロジー]→[メッセージング・エンジン]を選択し、新規に作成されたメッセージ
ング・エンジン[Cluster_name.00*-SIBus_name]のハイパーリンクをクリックします。メッセージング・エ
ンジンのプロパティー画面で、[追加プロパティー]→[データ・ストア]を選択します（図 3-93参照）。デー
タ・ストアのプロパティーでスキーマ名を変更します。
- 96 -
図 3-92 SIBus にバス・メンバーを追加
図 3-93 メッセージング・エンジンのスキーマ名の変更
アプリケーション・サーバーまたはクラスターをバス・メンバーに追加した後、アプリケーション・サーバ
ーまたはクラスターを起動し、管理コンソールで、[サービス統合]→[バス]を選択し、SIBus[SIBus01]の
ハイパーリンクをクリックします。SIBus のプロパティー画面で、[トポロジー]→[メッセージング・エンジン]
- 97 -
を選択し、メッセージング・エンジンのプロパティー画面で正しくメッセージング・エンジンが起動している
ことを確認します。
以上で、SIBWS の稼動に必要なリソースの作成と構成は完了です。
3-4-2-2 SIBWS 稼動に必要なアプリケーションのインストール
Web サービスの SOAP メッセージが SIBus を経由する際に必要となるアプリケーションをインストール
します。
下記のアプリケーションをインストールする必要があります。
•
SDO リポジトリー・アプリケーション(SDO Repository.ear)
•
リソース・アダプター(sib.ra.rar)
•
SIBWS アプリケーション(sibws.ear)
•
エンドポイント・リスナー・アプリケーション
インバウンド・サービスとアウトバウンド・サービスを異なるアプリケーション・サーバーまたはクラスター
で稼動させる場合には、それぞれ下記のアプリケーションをインストールします。
•
インバウンド・サービス用
SDO リポジトリー・アプリケーション(SDO Repository.ear)
SIBWS アプリケーション(sibws.ear)
エンドポイント・リスナー・アプリケーション
•
アウトバウンド・サービス用
SDO リポジトリー・アプリケーション(SDO Repository.ear)
リソース・アダプター(sib.ra.rar)
SIBWS アプリケーション(sibws.ear)
尚、アプリケーションのインストールは、wsadmin のスクリプトを使用して行います。
インバウンド・サービス用、アウトバウンド・サービス用のクラスターにそれぞれインストールするコンポー
ネントとその役割の詳細は下記の InfoCenter の記載を参照ください。
InfoCenter「SIBWS インストールの計画」
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.nd.
doc¥concepts¥cjw_install_plan.html
Step8 SDO リポジトリー・アプリケーションのインストール
SDO リポジトリー・アプリケーションは、インバウンド・サービス用クラスター（またはアプリケーション・サ
ーバー）、アウトバウンド用クラスター（またはアプリケーション・サーバー）そしてデプロイメント・マネージ
ャーに対してインストールする必要があります。
インストールに必要なスクリプトは<WAS_root>/bin ディレクトリーにある installSdoRepository.jacl ファイ
ルを使用します。複数の対象のクラスターやデプロイメント・マネージャーに対してインストールを行うと
き、また、使用する SDO リポジトリーのデータベースを指定するときに、それぞれオプションを変更して、
このスクリプトを実行します。SDO リポジトリー・アプリケーションのインストールの詳細は下記の
InfoCenter の記載を参照ください。
InfoCenter「SDO リポジトリーのインストール」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_install_sdo.html
まず、デプロイメント・マネージャーに SDO リポジトリー・アプリケーションをインストールします。オプショ
ンとして、デプロイメント・マネージャーのノード名とサーバー名（dmgr）を指定します。実行例は以下のよ
うになります。ここでは、wsadmin コマンドのオプションとして、-port 18879 を指定していますが、デフォル
トの SOAP コネクターポートである 8879 を使用する場合には、指定する必要はありません。
- 98 -
# cd /usr/WebSphere/AppServer/bin
#
# ./wsadmin.sh -port 18879 -f installSdoRepository.jacl host1CellManager01 dmgr
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[host1CellManager01, dmgr]"
CWSJO0016I: ノード host1CellManager01、サーバー dmgr に SDO リポジトリーをインス
トールしています。
CWSJO0021I: SDO リポジトリー EJB アプリケーションをインストールしています。
CWSJO0052I: データ・ソース・バックエンド ID CLOUDSCAPE_V5 を使用します
WASX7327I: was.policy ファイルの内容:
grant codeBase "file:${application}" {
permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete";
};
ADMA5016I: SDO Repository のインストールが開始されました。
ADMA5058I: アプリケーションとモジュールのバージョンは、デプロイメント・ターゲッ
トのターゲットと検証されました。
ADMA5005I: アプリケーション SDO Repository が WebSphere Application Server リポジ
トリーに構成されます。
ADMA5053I: インストール済みオプション・パッケージのライブラリー参照が作成されま
す。
ADMA5005I: アプリケーション SDO Repository が WebSphere Application Server リポジ
トリーに構成されます。
ADMA5001I: アプリケーション・バイナリーは /usr/WebSphere/AppServer/profi
les/Dmgr01/wstemp/Script106442fb61d/workspace/cells/guideCell01/applications/SD
O Repository.ear/SDO Repository.ear に保管されます。
ADMA5005I: アプリケーション SDO Repository が WebSphere Application Server リポジ
トリーに構成されます。
SECJ0400I: アプリケーション SDO Repository が appContextIDForSecurity 情報で正常
に更新されました。
ADMA5011I: アプリケーション SDO Repository の一時ディレクトリーのクリーンアップ
が完了しました。
ADMA5013I: アプリケーション SDO Repository は正常にインストールされました。
CWSJO0022I: 構成を保管しています。
CWSJO0023I: SDO リポジトリー・インストールは正常に完了しました。
#
次に、インバウンド・サービスとアウトバウンド・サービスを実行するクラスターに対して、それぞれ SDO
リポジトリー・アプリケーションをインストールします。オプションに-cluster Cluster_name を指定します。イ
ンバウンド・サービスとアウトバウンド・サービスを同一のクラスターで実行する場合には、そのクラスター
に対して 1 回インストールを行います。尚、スタンドアローンのアプリケーション・サーバーに対してインス
トールする場合には、オプションに Node_name AppServer_name を指定します。実行例は以下のように
なります。
# ./wsadmin.sh -port 18879 -f installSdoRepository.jacl -cluster InboundCluster
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
- 99 -
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[-cluster, InboundCluster]"
CWSJO0048I: クラスター InboundCluster に SDO リポジトリーをインストールします。
CWSJO0022I: 構成を保管しています。
CWSJO0023I: SDO リポジトリー・インストールは正常に完了しました。
#
# ./wsadmin.sh -port 18879 -f installSdoRepository.jacl -cluster OutboundCluster
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[-cluster, OutboundCluster]"
CWSJO0048I: クラスター OutboundCluster に SDO リポジトリーをインストールします。
CWSJO0022I: 構成を保管しています。
CWSJO0023I: SDO リポジトリー・インストールは正常に完了しました。
#
続いて、使用する SDO リポジトリーのデータベースを指定します。オプションに-editBackendId
Database_product_name を指定します。ここでは DB2 V8.2 を使用した場合の例を示します。
# ./wsadmin.sh -port 18879 -f installSdoRepository.jacl -editBackendId DB2UDB_V82
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[-editBackendId, DB2UDB_V82]"
CWSJO0061I: アプリケーション SDO Repository のバックエンド ID を更新します。
･･･････････途中略
ADMA5013I: アプリケーション SDO Repository は正常にインストールされました。
CWSJO0022I: 構成を保管しています。
CWSJO0023I: SDO リポジトリー・インストールは正常に完了しました。
#
以上で、SDO リポジトリー・アプリケーションのインストールは完了です。管理コンソールで、[アプリケー
ション]→[エンタープライズ・アプリケーション]を選択すると、[SDO Repository]アプリケーションがリス
トに追加されていることが確認できます。
尚、ここでは、SDO リポジトリー・データベースとして、DB2 を使用した場合の例を示しましたが、
WebSphere AS Base 版を使用した、スタンドアローン構成の場合には、SDO リポジトリーのデータベース
として組み込みの Cloudscape データベースを使用することができます。その場合には、この Step8 の手
順は下記のコマンドを 1 回実行します。このコマンドを実行したときに、Cloudscape データベースも自動
的に生成されます。
wsadmin.sh –f installSdoRepository.jacl -createDb
また、SDO リポジトリーのインストールに失敗した場合や、SDO リポジトリーが不要になった場合に、
SDO リポジトリー・アプリケーションをアンインストールするためのスクリプトとして、
uninstallSdoRepository.jacl ファイルが準備されています。オプションの詳細は InfoCenter を参照くださ
い。尚、このアンインストール・スクリプトでは、データベース上のデータの削除は行いませんので、デー
タベースの削除などは手動で行う必要があります。
InfoCenter「SDO リポジトリー・アンインストール・スクリプト」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/ref/r
jw_uninstall_sdo.html
- 100 -
Step9 リソース・アダプターのインストール
アウトバウンド・サービスは Web サービス宛先から Web サービス・メッセージを取り出す際、MDB を使
用して取り出します。デフォルトの MessageListener では、JMS メッセージしか扱えないため、Web サービ
ス・メッセージの入った SDO データを取り出すために新たなリソース・アダプター
（com.ibm.wsspi.sib.ra.SibRaMessageListener）をインストールする必要があります。
リソース・アダプターのインストールは、アウトバウンド用のクラスター・メンバー（またはアプリケーショ
ン・サーバー）が稼動する各ノードレベルでインストールします。クラスター単位やアプリケーション・サー
バー単位ではありませんので、ご注意ください。
インストールに必要なスクリプトは<WAS_root>/util ディレクトリーにある sibwsInstall.jacl ファイルを使用
します。複数のノードに対してリソース・アダプターをインストールするには、ノード名のオプションを変更
して、複数回スクリプトを実行します。
リソース・アダプターをインストールするときの構文は以下のとおりです。オプションにリソース・アダプタ
ーのインストールを表す：INSTALL_RA、WebSphere AS のインストールディレクトリー、ノード名、クラスタ
ー名を指定します。クラスター名の指定はオプションで、スタンドアローンのアプリケーション・サーバー
に対してインストールする場合には、クラスター名は指定しません。wsadmin コマンドと sibwsInstall.jacl
ファイルの存在するディレクトリーが異なりますので、ご注意ください。
wsadmin.sh –f ../util/sibwsInstall.jacl INSTALL_RA –installRoot <WAS_root> -nodeName Node_name
[–clusterName Cluster_name]
リソース・アダプターのインストールの詳細は下記の InfoCenter の記載を参照ください。
InfoCenter「サービス統合テクノロジーのリソース・アダプターのインストール」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_install_ra.html
ここでは、OutboudCluster のクラスターメンバーが稼動する host1Node01 と host2Node01 の 2 つのノー
ドにリソース・アダプターをインストールする例を示します。実行コマンドが 2 行にまたがっていますが、入
力時には 1 行で入力して下さい。また、今回の環境では、host1Node01 は AIX 上で稼動し、
host2Node01 は Windows 上で稼動しているため、installRoot オプションのパスの指定が異なります。ま
た、Windows のパスを指定する場合は、パスの区切り文字を必ず「¥」記号ではなく、「/」を使用してくだ
さい。
# ./wsadmin.sh -port 18879 ../util/sibwsInstall.jacl INSTALL_RA -installRoot
/usr/WebSphere/AppServer -nodeName host1Node01 -clusterName OutboundCluster
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[INSTALL_RA, -installRoot, /usr/WebSphere/AppServ
er, -nodeName, host1Node01, -clusterName, OutboundCluster]"
CWSWS5056I: リソース・アダプター: SIB_RA をインストールしています。
CWSWS5059I: 活動化仕様: SIBWS_OUTBOUND_MDB を作成しています。
CWSWS5058I: リソース・アダプター: SIB_RA が正常に開始されました
CWSWS5056I: リソース・アダプター: OutboundCluster.SIB_RA をインストールしていま
す。
CWSWS5058I: リソース・アダプター: OutboundCluster.SIB_RA が正常に開始されました
CWSWS5060I: 構成を保管しています。
#
# ./wsadmin.sh -port 18879 ../util/sibwsInstall.jacl INSTALL_RA -installRoot
C:/WebSphere/AppServer -nodeName host2Node01 -clusterName OutboundCluster
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
- 101 -
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[INSTALL_RA, -installRoot, C:/WebSphere/AppServer,
-nodeName, host2Node01, -clusterName, OutboundCluster]"
CWSWS5056I: リソース・アダプター: SIB_RA をインストールしています。
CWSWS5059I: 活動化仕様: SIBWS_OUTBOUND_MDB を作成しています。
CWSWS5058I: リソース・アダプター: SIB_RA が正常に開始されました
CWSWS5060I: 構成を保管しています。
#
以上で、リソース・アダプターのインストールは完了です。管理コンソールで、[リソース]→[リソース・ア
ダプター]を選択し、インストール時に指定したノードのリソースを確認すると、[SIB_RA]のリソース・アダ
プターがリストに追加されていることが確認できます。
Step10 SIBWS アプリケーションのインストール
SIBWS アプリケーションは、インバウンド・サービス用クラスター（またはアプリケーション・サーバー）、
アウトバウンド用クラスター（またはアプリケーション・サーバー）の両方にインストールする必要がありま
す。
SIBWS アプリケーションをインストールするときの構文は以下のとおりです。オプションに SIBWS アプリ
ケーションのインストールを表す：INSTALL、WebSphere AS のインストールディレクトリー、ノード名とサ
ーバー名、もしくはクラスター名を指定します。スタンドアローンのアプリケーション・サーバーに対してイ
ンストールする場合には、ノード名とサーバー名を指定し、クラスターに対してインストールする場合に
は、クラスター名を指定します。
スタンドアローンのアプリケーション・サーバーにインストールする場合
wsadmin.sh –f ../util/sibwsInstall.jacl INSTALL –installRoot <WAS_root> –serverName
ApplicationServer_name -nodeName Node_name
クラスターにインストールする場合
wsadmin.sh –f ../util/sibwsInstall.jacl INSTALL –installRoot <WAS_root> –clusterName Cluster_name
SIBWS アプリケーションのインストールの詳細は下記の InfoCenter の記載を参照ください。
InfoCenter「SIBWS およびエンドポイント・リスナー・アプリケーションのインストール」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_install_sibws_epl.html
ここでは、InboundCluster と OutboudCluster の 2 つのクラスターに SIBWS アプリケーションをインスト
ールする例を以下に示します。
# wsadmin.sh –f ../util/sibwsInstall.jacl INSTALL –installRoot /usr/WebSphere/AppServer
-clusterName InboundCluster
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[INSTALL, -installRoot, /usr/WebSphere60/AppServer,
-clusterName, InboundCluster]"
CWSWS5050I: アプリケーション: sibws.InboundCluster をインストールしています。
ADMA5016I: sibws.InboundCluster のインストールが開始されました。
ADMA5058I: アプリケーションとモジュールのバージョンは、デプロイメント・ターゲッ
トのターゲットと検証されました。
ADMA5005I: アプリケーション sibws.InboundCluster が WebSphere Application Server
リポジトリーに構成されます。
- 102 -
ADMA5053I: インストール済みオプション・パッケージのライブラリー参照が作成されま
す。
ADMA5005I: アプリケーション sibws.InboundCluster が WebSphere Application Server
リポジトリーに構成されます。
ADMA5001I: アプリケーション・バイナリーは /usr/WebSphere/AppServer/profi
les/Dmgr01/wstemp/Script10644e86fdf/workspace/cells/guideCell01/applications/si
bws.InboundCluster.ear/sibws.InboundCluster.ear に保管されます。
ADMA5005I: アプリケーション sibws.InboundCluster が WebSphere Application Server
リポジトリーに構成されます。
SECJ0400I: アプリケーション sibws.InboundCluster が appContextIDForSecurity 情報
で正常に更新されました。
ADMA5011I: アプリケーション sibws.InboundCluster の一時ディレクトリーのクリーン
アップが完了しました。
ADMA5013I: アプリケーション sibws.InboundCluster は正常にインストールされました
。
CWSWS5060I: 構成を保管しています。
CWSWS5053I: アプリケーションを開始しています: sibws.InboundCluster InMember21 ho
st2Node01
CWSWS5055I: アプリケーションが開始されました: sibws.InboundCluster
#
# wsadmin.sh –f ../util/sibwsInstall.jacl INSTALL –installRoot /usr/WebSphere/AppServer
-clusterName OutboundCluster
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[INSTALL, -installRoot, /usr/WebSphere/AppServer,
-clusterName, OutboundCluster]"
CWSWS5050I: アプリケーション: sibws.OutboundCluster をインストールしています。
･･･････････途中略
ADMA5013I: アプリケーション sibws.OutboundCluster は正常にインストールされました
。
CWSWS5060I: 構成を保管しています。
#
以上で、SIBWS アプリケーションのインストールは完了です。管理コンソールで、[アプリケーション]→
[ エンタープライズ・アプリケーション ] を選択すると、 [sibws.Cluster_name] または
[sibws.Node_name.ApplicationServer_name]アプリケーションがリストに追加されていることが確
認できます。今回の場合、sibws.InboundCluster と sibws.OutboundCluster の 2 つのエンタープライズ・ア
プリケーションがインストールされます。
Step11 エンドポイント・リスナー・アプリケーションのインストール
エンドポイント・リスナーとは、インバウンド・サービスのメッセージが受信されるポイントです。
WebSphere AS が提供するエンドポイント・リスナーには、SOAP over HTTP と SOAP over JMS の 2 種類
があります。
エンドポイント・リスナー・アプリケーションは、インバウンド・サービス用クラスター（またはアプリケーシ
ョン・サーバー）にインストールする必要があります。
エンドポイント・リスナー・アプリケーションをインストールするときの構文は以下のとおりです。SOAP
over HTTP のメッセージを受信するエンドポイント・リスナーを構成する場合は、オプションに
- 103 -
INSTALL_HTTP を、SOAP over JMS のメッセージを受信するエンドポイント・リスナーを構成する場合
は、オプションに INSTALL_JMS を指定します。その他のオプションは、SIBWS アプリケーションのイン
ストールと同様に、WebSphere AS のインストールディレクトリー、ノード名とサーバー名、もしくはクラスタ
ー名を指定します。スタンドアローンのアプリケーション・サーバーに対してインストールする場合には、
ノード名とサーバー名を指定し、クラスターに対してインストールする場合には、クラスター名を指定しま
す。
スタンドアローンのアプリケーション・サーバーにインストールする場合
wsadmin.sh –f ../util/sibwsInstall.jacl [INSTALL_HTTP | INSTALL_JMS] –installRoot <WAS_root>
–serverName ApplicationServer_name -nodeName Node_name
クラスターにインストールする場合
wsadmin.sh –f ../util/sibwsInstall.jacl [INSTALL_HTTP | INSTALL_JMS] –installRoot <WAS_root>
–clusterName Cluster_name
エンドポイント・リスナー・アプリケーションのインストールの詳細は下記の InfoCenter の記載を参照くだ
さい。
InfoCenter「SIBWS およびエンドポイント・リスナー・アプリケーションのインストール」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_install_sibws_epl.html
また、SOAP over JMS をエンドポイント・リスナーとして使用する場合には、アプリケーションのインスト
ールだけでなく、JMS キューなどのリソースの設定が必要になります。リソース設定の詳細は下記の
InfoCenter の記載を参照ください。
InfoCenter「同期 SOAP over JMS エンドポイント・リスナーの JMS リソースの構成」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_epl_soapjms.html
ここでは、InboundCluster のクラスターに SOAP over HTTP のエンドポイント・リスナー・アプリケーション
をインストールする例を以下に示します。
# wsadmin.sh –f ../util/sibwsInstall.jacl INSTALL_HTTP –installRoot /usr/WebSphere/AppServer
-clusterName InboundCluster
WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使っ
て接続しました。プロセスのタイプは DeploymentManager です。
WASX7303I: 次のオプションはスクリプト環境に渡され、argv 変数に格納される引数とし
て使用可能になります: "[INSTALL_HTTP, -installRoot, /usr/WebSphere60/AppSe
rver, -clusterName, InboundCluster]"
CWSWS5050I: アプリケーション: sibwshttp1.InboundCluster をインストールしています
。
ADMA5016I: sibwshttp1.InboundCluster のインストールが開始されました。
ADMA5058I: アプリケーションとモジュールのバージョンは、デプロイメント・ターゲッ
トのターゲットと検証されました。
ADMA5005I: アプリケーション sibwshttp1.InboundCluster が WebSphere Application Se
rver リポジトリーに構成されます。
ADMA5053I: インストール済みオプション・パッケージのライブラリー参照が作成されま
す。
ADMA5005I: アプリケーション sibwshttp1.InboundCluster が WebSphere Application Se
rver リポジトリーに構成されます。
ADMA5001I: アプリケーション・バイナリーは /usr/WebSphere60/AppServer/profi
les/Dmgr01/wstemp/Script106450db175/workspace/cells/guideCell01/applications/si
bwshttp1.InboundCluster.ear/sibwshttp1.InboundCluster.ear に保管されます。
ADMA5005I: アプリケーション sibwshttp1.InboundCluster が WebSphere Application Se
- 104 -
rver リポジトリーに構成されます。
SECJ0400I: アプリケーション sibwshttp1.InboundCluster が appContextIDForSecurity
情報で正常に更新されました。
ADMA5011I: アプリケーション sibwshttp1.InboundCluster の一時ディレクトリーのクリ
ーンアップが完了しました。
ADMA5013I: アプリケーション sibwshttp1.InboundCluster は正常にインストールされま
した。
CWSWS5060I: 構成を保管しています。
CWSWS5050I: アプリケーション: sibwshttp2.InboundCluster をインストールしています
。
･･･････････途中略
ADMA5013I: アプリケーション sibwshttp2.InboundCluster は正常にインストールされま
した。
CWSWS5060I: 構成を保管しています。
#
管理コンソールで、[アプリケーション]→ [エンタープライズ・アプリケーション]を選択すると、
[sibhttp1.Cluster_name]
と
[sibhttp2.Cluster_name]
（
ま
た
は
[sibhttp1.Node_name.ApplicationServer_name]
と
[sibhttp2.Node_name.ApplicationServer_name]）アプリケーションがリストに追加されていることが
確認できます。
SOAP over HTTP のエンドポイント・リスナーアプリケーションをインストールした場合、アプリケーション
をインストールした直後は、Web サーバーに対するマッピングが行われていません。SOAP メッセージを
IBM HTTP Server などの Web サーバー経由で受信する場合には、Web サーバーに対するマッピングを
構成する必要があります。
マッピングは使用するエンドポイント・リスナー・アプリケーションに対して行います。管理コンソールで、
[アプリケーション]→[エンタープライズ・アプリケーション]を選択し、[sibwshttp1.Cluster_name]など
のエンドポイント・リスナー・アプリケーションのハイパーリンクをクリックします。エンタープライズ・アプリケ
ーションのプロパティー画面で、[追加プロパティー]→[サーバーにモジュールをマップ]を選択します
（図 3-94参照）。モジュールをマッピングする、クラスターまたはアプリケーション・サーバーとともに、必
要な Web サーバーを選択し、また、モジュールを選択するチェックボックスを ON にして[適用]ボタンを
押下して、マッピング対象の Web サーバーを追加します。
- 105 -
図 3-94 エンドポイント・リスナー・アプリケーションの Web サーバーへのマッピングの追加
以上で、エンドポイント・リスナー・アプリケーションのインストールは完了です。
3-4-2-3 SIBWS の構成
ここからは、SIBWS 構成に必要なコンポーネントを構成していきます。下記のコンポーネントを構成し
ます。
•
エンドポイント・リスナー
•
アウトバウンド・サービス
•
インバウンド・サービス
Step12 エンドポイント･リスナーの構成
Step11 でインストールしたエンドポイント・リスナー・アプリケーションをアプリケーション・サーバーもしく
は、クラスター上で構成し、エンドポイント・リスナーを SIBus に接続します。
ここでは、新規に下記の HTTP エンドポイント・リスナーを構成します。
構成先サーバー
InboundCluster (Step5 で作成したインバウンド・サービス用の
クラスターまたはアプリケーション・サーバー)
エンドポイント・リスナーの名前
SOAPHTTPChannel1
URL ルート
http://host_name:port_number/wsgwsoaphttp1
HTTP URL ルートにサービスを http://host_name:port_number/sibws/wsdl
提供する WSDL
接続先バス名
SIBus01 (Step6 で作成した SIBus)
エンドポイント・リスナーの構成の詳細は、下記の InfoCenter の記載を参照ください。
InfoCenter「新規エンドポイント・リスナー構成の作成」
- 106 -
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_epl_new.html
エンドポイント・リスナーの名前は、インストール済みのエンドポイント・リスナーに対応する下記の 2 つ
の名前のうちの 1 つでなければなりません。
•
SOAPHTTPChannel1
•
SOAPHTTPChannel2
URL ルートには、WSDL ファイル内にエンドポイント・アドレスを作成して、リクエスターをこのエンドポ
イント・リスナーに誘導するために使用する Web アドレスのルートを指定します。URL ルートのポート番
号以下はエンドポイント・リスナー・アプリケーションのコンテキスト・ルートとなりますので、固定値となりま
す。
HTTP URL ルートにサービスを提供する WSDL には、このエンドポイント・リスナーで使用可能なイン
バウンド・サービスの WSDL ファイルの Web アドレスのルートを入力します。
これらの入力値の詳細は、下記の InfoCenter の記載を参照ください。
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.nd.
doc¥ref¥rjw_epl_details.html
ここでは、インバウンド・サービス用のクラスターにエンドポイント・リスナーを作成しますので、管理コン
ソールで、[サーバー]→[クラスター]→[Cluster_name]→[追加プロパティー]→[エンドポイント・リスナ
ー]を選択し、[新規作成]ボタンを押下します。アプリケーション・サーバー上にエンドポイント・リスナーを
作成する場合には、[サーバー]→[アプリケーション・サーバー]→[ApplicationServer_name]→[追
加プロパティー]→[エンドポイント・リスナー]を選択します。上記表の名前、URL ルート、HTTP URL ル
ートにサービスを提供する WSDL を入力します（図 3-95参照）。エンドポイント・リスナーの一般プロパテ
ィーを入力後、[適用]ボタンを押下し、[追加プロパティー]→[接続プロパティー]を選択し、[新規作成]ボ
タンを押下します。バス名として、Step5 で作成した SIBWS を稼動する SIBus を選択します（図 3-96参
照）。
図 3-95 エンドポイント・リスナーの構成
- 107 -
図 3-96 エンドポイント・リスナーの SIBus との接続構成
以上で、エンドポイント・リスナーの構成は完了です。管理コンソールで、[サービス統合]→[バス]→
[SIBus_name] → [ 宛先リソース ] → [ 宛先 ] を選択すると、
[Cluster_name.SOAPHTTPChannel1Reply]キューがリストに追加されていることが確認できます。
この Cluster_name.SOAPHTTPChannel1Reply キューは、エンドポイント・リスナーが使用するリプライ・キ
ューで Web サービスの応答結果はこのリプライ・キューに入れられ、インバウンド・ポートより取り出されま
す（図 3-97参照）。
図 3-97 リプライ・キューの確認
Step13 アウトバウンド・サービスの構成
アウトバウンド・サービスは、外部でホスティングされた Web サービスに SIBus を介してアクセス可能に
します。最初に、外部の Web サービスを SIBus 上で稼動するサービス宛先と関連付け、次に、サービス
要求および応答を外部サービスに渡す際に経由する 1 つ以上のポート宛先（SOAP over HTTP や
SOAP over JMS など、各タイプのバインディングごとに 1 つ）を構成します。
アウトバウンド・サービスを構成する前に、事前に Web サービス・プロバイダーを起動しておいてくださ
い。Web サービス・プロバイダーから、HTTP 経由で WSDL を受け取れるか確認しておいてください。も
しくは、UDDI レジストリーに Web サービス・プロバイダーを登録しておく必要があります。
アウトバウンド・サービス作成方法の詳細は下記の InfoCenter の記載を参照ください。
InfoCenter「新規アウトバウンド・サービス構成の作成」
- 108 -
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_out_new.html
ここでは、host4.ise.ibm.com のサーバー上で下記の WSDL で表される Web サービス・プロバイダーが
稼動しているものとして説明します。
例 3-5 WSDL ファイルのサンプル
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://ise.com" xmlns:impl=
･･･途中略>
<wsdl:types>
<schema targetNamespace="http://ise.com" xmlns=
･･･途中略>
<element name="sayHelloResponse">
<complexType>
<sequence>
<element name="sayHelloReturn" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</element>
<element name="sayHello">
<complexType>
<sequence/>
</complexType>
</element>
</schema>
</wsdl:types>
<wsdl:message name="sayHelloRequest">
<wsdl:part element="impl:sayHello" name="parameters"/>
</wsdl:message>
<wsdl:message name="sayHelloResponse">
<wsdl:part element="impl:sayHelloResponse" name="parameters"/>
</wsdl:message>
<wsdl:portType name="HelloWorldService">
<wsdl:operation name="sayHello">
<wsdl:input message="impl:sayHelloRequest" name="sayHelloRequest"/>
<wsdl:output message="impl:sayHelloResponse" name="sayHelloResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="HelloWorldServiceSoapBinding" type="impl:HelloWorldService">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="sayHello">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="sayHelloRequest">
<wsdlsoap:body use="literal"/>
</wsdl:input>
<wsdl:output name="sayHelloResponse">
<wsdlsoap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
- 109 -
</wsdl:binding>
<wsdl:service name="HelloWorldServiceService">
<wsdl:port binding="impl:HelloWorldServiceSoapBinding" name="HelloWorldService">
<wsdlsoap:address
location="http://host4.ise.ibm.com:9080/HelloWorldWeb/services/HelloWorldService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
アウトバウンド・サービスの構成の設定値は下記の表のとおりです。
構成する SIBus
SIBus01 (Step6 で作成した SIBus)
WSDL ロケーション http://host4.ise.ibm.com:9080/HelloWorldWeb/services/HelloWorldService?wsdl
(一例)
サービス名
HelloWorldServiceService （一例）
アウトバウンド・サ HelloWorldServiceService （任意）
ービス名
サービス宛先名
http://ise.com:HelloWorldServiceService （任意）
ポート宛先名
http://ise.com:HelloWorldServiceService:HelloWorldService （任意）
バス・メンバー
OutboundCluster （Step5 で作成したアウトバウンド用クラスター）
アウトバウンド・サービスはを構成するには、管理コンソールで、[サービス統合]→[バス]→
[SIBus_name]→[サービス]→[アウトバウンド・サービス]を選択し、[新規作成]ボタンを押下します（図
3-98参照）。[WSDL ロケーション]欄に Web サービス・プロバイダーの WSDL を取得できる URL を入力
し、[次へ]を押下します。
図 3-98 アウトバウンド・サービスの作成（Step1）
WSDL ファイルに記述されているサービスから、実行するサービスを選択し、[次へ]を押下します（図
3-99参照）。
- 110 -
図 3-99 アウトバウンド・サービスの作成（Step2）
Web サービス・プロバイダーに関連付けられたアウトバウンド・サービス・ポートを構成します。選択欄の
チェックボックスを選択し、[次へ]を押下します（図 3-100参照）。
図 3-100 アウトバウンド・サービスの作成（Step3）
- 111 -
必要に応じて、アウトバウンド・サービス名、サービス宛先名、ポート宛先名を変更します。
図 3-101 アウトバウンド・サービスの作成（Step4）
ポート宛先、および Web サービス宛先のキューを構成するバス・メンバーを指定します。アウトバウンド
用に作成したクラスターメンバーまたはアプリケーション・サーバーのバス・メンバーを選択します。
図 3-102 アウトバウンド・サービスの作成（Step5）
以上で、アウトバウンド・サービスの構成は完了です。
- 112 -
Step14 インバウンド・サービスの構成
インバウンド・サービスは、SIBus 上でサービスとして公開する単位ごとに作成し、エンドポイント・リスナ
ー、アウトバウンド・サービス宛先とひもづけます。インバウンド・サービスは自分自身のサービスを表す
WSDL を必ず 1 つ持ち、インバウンド・サービス作成時に自動的に作成されます。
インバウンド・サービス作成方法の詳細は下記の InfoCenter の記載を参照ください。
InfoCenter「新規インバウンド・サービス構成の作成」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.pmc.nd.doc/task
s/tjw_in_new.html
インバウンド・サービスの構成の設定値は下記の表のとおりです。
サービス宛先名
http://ise.com:HelloWorldServiceService （Step13 で指定したサービス宛先名）
テンプレート WSDL http://host4.ise.ibm.com:9080/HelloWorldWeb/services/HelloWorldService?wsdl
ロケーション
(一例)
サービス名
HelloWorldServiceService （一例）
インバウンド・サー httpisecomHelloWorldServiceServiceInboundService （任意）
ビス名
インバウンド・サービスはを構成するには、管理コンソールで、[サービス統合]→[バス]→
[SIBus_name]→[サービス]→[インバウンド・サービス]を選択し、[新規作成]ボタンを押下します（図
3-103参照）。[サービス宛先名]には、Step13 で指定したサービス宛先名をプルダウンメニューから選択
します。また、[テンプレート WSDL ロケーション]には SIBus 経由でアクセスする Web サービス・クライア
ントに提供するための WSDL のテンプレートを指定します。
図 3-103 インバウンド・サービスの作成（Step1）
テンプレートの WSDL ファイルの中から公開するサービスを選択します（図 3-104参照）。
- 113 -
図 3-104 インバウンド・サービスの作成（Step2）
インバウンド・サービスとエンドポイント・リスナーを関連付けます。また、インバウンド・サービス名をデフ
ォルトの名前から変更することも可能です（図 3-105参照）。
図 3-105 インバウンド・サービスの作成（Step3）
構成したインバウンド・サービスを Web サービスとして、UDDI レジストリーに公開することができます。
（図 3-106参照）
- 114 -
図 3-106 インバウンド・サービスの作成（Step4）
以上で、インバウンド・サービスの構成は完了です。尚、インバウンド・サービスが自分自身を表す Web
サービスの WSDL を取得するには、[サービス統合]→[バス]→[SIBus_name]→[サービス]→[インバ
ウンド・サービス]→[InboundService_name]→[追加プロパティー]→[WSDL ファイルの ZIP への公
開]を選択します（図 3-107参照）。”InboundService_name.zip”のハイパーリンクをクリックすると WSDL
ファイルを zip 化したファイルを取得できます。
図 3-107 インバウンド・サービスの WSDL ファイルの取得
- 115 -
3-5 Appendix WebSphere MQ 関連のコマンド
主なコマンド一覧
コマンド
dspmq
crtmQmgr Qmgr_name
dltmQmgr Qmgr_name
strmQmgr Qmgr_name
endmQmgr Qmgr_name
runmqlsr -m Qmgr_name -t TCP -p
Port_number
mqrc Return_code
runmqsc Qmgr_name
主な MQSC コマンド一覧
コマンド
END
DISPLAY QLOCAL(*)
DIS QL(*)
DISPLAY QUEUE(*)
DIS Q(*)
DISPLAY CHANNEL(*)
DISPLAY CHSTATUS(*)
DEFINE QLOCAL(QL_name)
DEF QL(QL_name)
DEFINE QLOCAL('MEQmgr_name') +
USAGE(XMITQ)
DEFINE CHANNEL('MQQmgr.MEQmgr') +
CHLTYPE(SDR) TRPTYPE(TCP) +
CONNAME('was01(1414)')
XMITQ('MEQmgr_name')
DEFINE
CHANNEL('MEQmgr_name.MQQmgr_name')
CHLTYPE(RCVR) TRPTYPE(TCP)
START
CHANNEL('MQQmgr_name.MEQmgr_name')
説明
定義されている Qmgr 一覧と、稼動状態を
表示します。
Qmgr、Qmgr_name を作成します。
Qmgr、Qmgr_name を削除します。
Qmgr、Qmgr_name を始動します。
Qmgr、Qmgr_name を停止します。-i オプシ
ョンを指定することで、強制停止できます。
Qmgr、Qmgr_name に対するリスナーを始
動します。
リターン・コード、Return_code の意味を調
べます。
Qmgr、Qmgr_name を設定するために、
MQSC を開始します。
説明
MQSC を終了します。
ローカル・キュー一覧を表示します。
*の代わりにキュー名を入れると、より詳細
な設定を確認できます。
キュー一覧を表示します。
*の代わりにキュー名を入れると、より詳細
な設定を確認できます。
チャネル一覧を表示します。
*の代わりにチャネル名を入れると、より詳
細な設定を確認できます。
チャネル・ステータスの一覧を表示します。
ローカル・キューを定義します。
トランスミッション・キューMEQmgr_name を
定義します。トランスミッション・キュー名
は、それを利用するチャネルの接続先
Qmgr 名を設定してください。
送信チャネル MQQmgr.MEQmgr を定義し
ます。（トランスミッション・キュー名
=MEQmgr_name、接続先ホスト名=was01、
接続先 Qmgr のリスナー・ポート番号
=1414）
受信チャネル
MEQmgr_name.MQQmgr_name を定義し
ます。
チャネル MQQmgr_name.MEQmgr_name
を始動します。
- 116 -
- 117 -