IBM Support and downloads - 3 SIBus 構成public.dhe.ibm.com/.../was6_adminguide/V6Guide_13_SIBus.pdf · 2009. 1. 27. · WebSphere AS V6.0 に内蔵されているデフォルトのJMS

- 1 -

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 メッセージングのタイプ • 非同期タイプ

送信者が受信者に対してメッセージを送信す

ることで処理が完了するタイプの処理方法で、一

方向型通信と呼ばれることもあります。バッチ処

理やメール送信など、実際の処理を後で実施す

ればよいアプリケーションに活用できます。

• 同期（要求／応答）タイプ通常のアプリケーションのように、送信者がメッ

セージを送信し、その処理結果を受信者から受

け取る同期タイプのオンライン処理も可能です。

ただし、この同期タイプでは要求宛先と応答宛

先は別になります。そのため要求処理と応答処

理は関連していないので、まったく別の処理とし

て実行されます。

送信者

宛先（キュー）宛先（キュー）

受信者

送信者

要求宛先（キュー）要求宛先（キュー）

受信者

応答宛先（キュー）応答宛先（キュー）

- 2 -

3-1-2 JMS JMS（Java Message Service）は、J2EE 仕様におけるメッセージングを実現する API として位置付けら

れています。アプリケーションは、JMS を使用し MOM（Message Oriented Middleware）製品と連携することによって、メッセージングシステムを構築することが可能です。代表的な MOM 製品としては、IBM WebSphere MQ があります。

JMS においては、「宛先」があり、一つの送信アプリケーション(＝プロデューサー)が宛先に対して、「メッセージ」を PUT します。もう一方の受信アプリケーション(＝コンシューマー)は、処理可能なタイミングで(→非同期)、その「メッセージ」を「宛先」から GET し、処理を実行します。

図 3-1 メッセージング概要

JMS は、JMS API と JMS プロバイダー、JMS クライアントから構成されます。

図 3-2 メッセージング・サービスの構成要素

• JMS プロバイダー JMS のインターフェース、管理、制御の機能を提供するメッセージング・サーバー・コンポーネント • JMS クライアント MS インターフェースを利用して、JMS サーバー・コンポーネントを利用するクライアント・コンポーネント

3-1-2-1 JMS のタイプ JMS には 2 種類の処理モデルがあります。 • Point-to-Point（PTP） PTP では、宛先をキューと呼びます。メッセージを生成する側をセンダー、メッセージを消費(使用)する側をレシーバーと呼び、センダーとレシーバーの関係が、1 対 1 となります。 PTP はキューをベースにしたモデルで、クライアントは特定のキューにメッセージを送信し、特定のキューからメッセージを受信します。

MOMドメイン

プロデューサーコンシューマー

JMSプロバイダー

メッセージング・サービス

SIBus

JMS

クライアントWMQ

他社メッセージング製品

JMS

クライアントJMS JMS

- 3 -

図 3-3 Point to Point(PTP)モデル

• Publish/Subscribe (Pub/Sub) Pub/Sub では、宛先をトピックと呼びます。メッセージを生成する側はパブリッシャー、メッセージを消費する側はサブスクライバーと呼ばれます。あ

るパブリッシャーがトピックに対してメッセージをパブリッシュします。次にサブスクライブ状態で待ってい

るすべてのクライアントがそのメッセージをサブスクライブします。Pub/Sub ドメインでは、サブスクライバーの数が不特定であり、パブリッシャーとサブスクライバーの関係が 1 対多の関係にあります。Pub/Sub ドメインは、複数のアプリケーションで、同一のメッセージを共有利用するという要件にあったメッセージン

グ・ドメインです。

図 3-4 Publish/Subscribe(Pub/Sub)モデル

3-1-2-2 JMS の特徴 • XA 対応 X/Open における XA インターフェースを使用することによって、複数リソースにおける 2 フェーズコミット処理を実現することが可能です。 • 高信頼性アプリケーションは最寄りのMOM製品と通信を行った段階で処理が完了します。そのため、MOM製品内での通信障害等に影響されることが無く動作することが出来ます。 • 高開発生産性

Send

Receive

JMSｸﾗｲｱﾝﾄ

JMSｸﾗｲｱﾝﾄｷｭｰ

Send

Receive

Point to point(PTP)ﾓﾃﾞﾙ




ﾌﾞﾛｰｶｰ


Publish

Subscribe

ﾄﾋﾟｯｸA


ﾄﾋﾟｯｸB

Publish/Subscribe(Pub/Sub)ﾓﾃﾞﾙ

- 4 -

上記の各特徴からアプリケーションは通信環境上でのエラーを意識せずに開発することができ、シンプ

ルな構造となります。

3-1-3 MDB（Message-Driven Bean） MDB（Message-Driven Bean）は、EJB 2.0 で新規に追加された JMS API を利用する EJB です。MDB

を利用することで、メッセージングシステムにアクセスする非同期の EJB アプリケーションを容易に開発できるようになります。

MDB はイベント駆動タイプの処理方式になります。 MessageListener インターフェースを実装して、非同期メッセージ受信のアプリケーションを作成することができます。メッセージを受信したという非同期のイベントを EJB コンテナーが検知して、onMessage メソッドが呼び出され、そこに記述された受信ロジックが稼動します。

図 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 製品にあわせて内容を設定する必要があります。

サーブレット 1インスタンス 1

onM essage ()

in it()スレッド 1

スレッド 2

アプリケーションサーバー(W ebC on ta in er)

JM S S e ss io n -1

se tM e ss a g e L is te n e r(th is )

イベント！

- 5 -

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 つの基礎技術から構成されます。

- 6 -

図 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 はインターオペラビリティ実現に適したプロトコルと言えます。

サービスを利用するアプリケーション

サービスのプロフィール(インターフェースetc.)

サービス

UDDI

レジストリー

リクエスター

プロバイダー WSDL

サービスの登録

SOAP

UDDI

サービスの検索

WSDL

サービスの要求と実行

- 7 -

2 点目は、SOAP プロトコルが下位プロトコルに依存しない点を挙げることが出来ます。SOAP 仕様書では HTTP 上での SOAP バインディングを取り上げていますが、これは下位プロトコルを HTTP に限定するものではなく、JMS や SMTP 等他のプロトコル上で SOAP 通信を行うことを許しています。

図 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 サービスに実際にどのようにアクセスしたらよいかという具体的な記述部分です。この部分からは、プロバイダーがどこ

に存在して、どのようなプロトコルでアクセスしたらよいかが分かります。インターフェースの抽象的な部分とサービス提供の具体的な部分が分かれることにより、サービス提

供の具体的な部分のみを変更することが柔軟に可能になります。

（SOAPボディ）実質的な通信内容

・基本的に書式は自由（RPCなどでは別途規定あり）

（SOAPヘッダー）オプションの要素

(SOAPエンベロープ）

（SOAPボディ）実質的な通信内容

・基本的に書式は自由（RPCなどでは別途規定あり）

（SOAPヘッダー）オプションの要素

(SOAPエンベロープ）

- 8 -

図 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 サービスのインターフェースを取得し、ロ

抽象的な定義（言語やプラットフォーム

に非依存）

インターフェース定義

下位データタイプ定義

論理操作単位の定義オブジェクトに相当operation要素（メソッドに相当）を定義

個々のデータフォーマットを定義

論理モデルと物理モデルの結び付け物理モデルの例： SOAP RPC

実際のアクセスポイント定義

binding 要素と実際のURLの結びつけ

具体的な記述（Webサイトに固有の情報）

抽象的な定義（言語やプラットフォーム

に非依存）

インターフェース定義

下位データタイプ定義

論理操作単位の定義オブジェクトに相当operation要素（メソッドに相当）を定義

個々のデータフォーマットを定義

論理モデルと物理モデルの結び付け物理モデルの例： SOAP RPC

実際のアクセスポイント定義

binding 要素と実際のURLの結びつけ

具体的な記述（Webサイトに固有の情報）

- 9 -

ーカルのクラスの様にそのインターフェースにアクセスします。また、この使用法とは別に動的バインディ

ングのアプリケーションを作成することも可能です。 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)」を参照してください。

- 10 -

3-2 SIBus(メッセージング)構成この節では、SIBus 上に WebSphere AS のデフォルトの JMS プロバイダーとして、メッセージング・エン

ジンを構成する方法を説明します。

3-2-1 トポロジー SIBus を構成し、バス・メンバーとしてアプリケーション・サーバーやクラスターを追加することで、メッセ

ージング・エンジン（ME）が構成されることになります。

3-2-1-1 基本トポロジー SIBus のバス・メンバーとしてアプリケーション・サーバーを追加することで構成するトポロジーです。

図 3-10 ME の基本トポロジー

3-2-1-2 高可用性構成 SIBus のバス・メンバーとしてクラスターを追加することで、クラスターメンバーに ME が構成されます。

この状態でクラスターを起動することで、クラスター内にメッセージング・エンジンが１つ起動され、他のク

ラスターメンバーのメッセージング・エンジンが待機状態になる構成が、メッセージング・エンジンクラスタ

リング構成です。この構成の特徴は、メッセージング・エンジンが起動しているサーバーにプロセス障害

やネットワーク障害が発生しても、HA マネージャーによりメッセージング・エンジンがフェイルオーバーされることで、サービスの提供を継続できることにあります。また、稼動系と待機系のメッセージング・エンジ

ンは、同じデータ・ストアを利用することで、構成情報やデータの引継ぎを行われます。

SIBus

SIB1

ノードHost01

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

JMS App

MEJDBC

Client(ブラウザ)

DB2[DataStore]

SIB1ME1[SCHEMA]

- 11 -

図 3-11 ME の高可用構成

3-2-1-3 パーティション構成ここまでで説明してきた「メッセージング・エンジン・クラスター構成」はクラスター内での高可用性を提

供しますが、クラスター内で稼働するメッセージング・エンジンが 1 つしかないためメッセージの処理が１メッセージング・エンジンに集中します。「パーティション構成」は、クラスター内でメッセージング・エンジンを複数稼働させることで、高可用性

＋メッセージ処理の分散を行うことができる構成です。この構成で、メッセージング・エンジンが起動する

サーバーに障害が発生した場合、メッセージング・エンジン毎のフェイルオーバーとメッセージの引き継

ぎが行われます。

図 3-12 ME のパーティション構成

パーティション構成の注意点パーティション構成を有効にするためには、JMS アプリケーションがメッセージング・エンジンを同じ検

索範囲で複数見つけることが必要となります。複数メッセージング・エンジンを構成していても、JMS アプリケーションが検索した際に、最初に見つかったのが、１メッセージング・エンジンであった場合には、パ

ーティション構成が有効にならないことに注意してください。

ノードHost01

ClusterClusterA

アプリケーション・サーバーAmember1

ME


ME

アプリケーション・サーバーServer1

JMS App

ノードHost02

SIBus

SIB01


JDBC

DB2[DataStore]

SIB1ME1[SCHEMA]JDBC

ノードHost02

ClusterClusterA



ノードHost03

SIBus

SIB01


JDBC

DB2[DataStore]

SIB1ME1[SCHEMA]JDBC

ノードHost01

アプリケーション・サーバーServer1

JMS App

ME

ME

ME

ME

- 12 -

メッセージング・エンジンの検索範囲 JMS アプリケーションが使用するメッセージング・エンジンは、検索範囲内で最初に見つかったメッセ

ージング・エンジンになります。下記の図の場合、Node１の Cluster01Member01 にある JMS アプリケーションは、メッセージング・エンジンを下記の順序で検索します。

図 3-13 ME の検索順

①JMS アプリケーションと同じサーバー上で稼動するメッセージング・エンジン ②同じクラスター内で稼動するメッセージング・エンジン ③JMS アプリケーションと同じノード上で稼動する、同一バス・メンバーのクラスターメンバー以外のサーバーのメッセージング・エンジン ④同一バス・メンバー上で稼動するメッセージング・エンジン

ただし、JMS 接続ファクトリーの設定にある、「接続の接近性」を設定することでどこまでを検索範囲とするかを制限することも可能です。設定は、「バス」、「クラスター」、「ホスト」、「サーバー」で、各設定によ

り下記の範囲が検索範囲になります。バス ①～④の範囲（デフォルト設定）クラスター ①～③の範囲ホスト ①②の範囲サーバー ①

パーティショニング構成でのメッセージの割り振りメッセージング・エンジンのパーティション構成を行った場合に、ワークロードシェアリングを有効にす

る場合は、JMS アプリケーションが稼動するクラスターまたは、アプリケーション・サーバーが使用するメッセージング・エンジンが所属する SIBus に参加している必要があります。同一 SIBus に所属することで、JMS アプリケーションの Put/Get を行う際に複数ある同じ検索範囲で見つかったメッセージング・エンジンをラウンドロビンで使用しますが、MDB アプリケーションは最初にアクセスを行ったメッセージング・エンジンのみを使用します。ワークロードシェアリングが有効になっている状態であれば、JMS アプリケーションは、１アプリケーション・サーバーに複数のメッセージング・エンジンが存在しても、ラウンドロビン

でメッセージング・エンジンを使用します。パーティショニング機能を使用する場合、設定手順の中で紹介した構成には、下記の構成の場合が

考えられます。 1). JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが

同一クラスター

ノードHost01

ClusterClusterB

アプリケーション・サーバーBmember1

ME


ME



JMS App

JMS App

ノードHost02

ClusterClusterA

SIBus

SIB01

ME

ME

1

2

3

4

- 13 -

図 3-14 JMS アプリケーションと ME が同一クラスターの場合

この構成の場合、JMS アプリケーションは同じサーバーで稼動しているメッセージング・エンジンを発見しますので、そのメッセージング・エンジンのみを使用します。図 3-14の場合、Cluster01Member01 の JMS アプリケーションは、同じサーバーに存在するメッセージング・エンジンのみを使用します。

2). JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが別クラスター

図 3-15 JMS アプリケーションと ME が別クラスターの場合

この構成の場合、JMS アプリケーションは自分が稼動しているアプリケーション・サーバー上にメッセージング・エンジンを見つけることができませんので、2 番目の検索範囲である同一クラスターを検索します。同一クラスターでも見つけることができないので、3 番目の検索範囲である同一ホストを検索します。そこにメッセージング・エンジンを見つけることができるので、そのメッセージ

ング・エンジンのみを使用します。

DB

ノードHost01

ClusterClusterB


ME


ME



JMS App

JMS App

ノードHost02

ClusterClusterA

SIBus

SIB01

ME

ME

ノードHost01



JMS App

ノードHost02

ClusterClusterA

SIBus

SIB01

ME ME

JMS App ME ME

DB

- 14 -

3). JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが別ノードかつ、同一 SIBus に所属する

図 3-16 JMS アプリケーションと ME が別クラスターかつ別ノードの場合

この構成の場合、JMS アプリケーションは自分が起動しているアプリケーション・サーバー上にメッセージング・エンジンが見つからないため、同じクラスター内を検索します。それでも見つから

ないため、他のノードにあるメッセージング・エンジンを検索し、同じ検索範囲にメッセージング・

エンジンを 2 つ見つけます。そのメッセージング・エンジンに対してラウンドロビンでメッセージをPut/Get します。

また、図には表れていませんが、JMS アプリケーションが存在するクラスターも SIBus のメンバーですのでキュー・ポイントに設定されていないメッセージング・エンジンが存在することになりま

す。 4). JMS アプリケーションが稼動するクラスターとメッセージング・エンジンが稼動するクラスターが

別ノードかつ、同一 SIBus に所属しない

図 3-17 JMS アプリケーションと ME が同一の SIBus に所属しない場合

この構成の場合、JMS アプリケーションは自分が起動しているアプリケーション・サーバー上にメッセージング・エンジンが見つからないため、同じクラスター内を検索します。それでも見つから

DB

ノードHost01

ClusterClusterB


ME


ME



JMS App

JMS App

ノードHost02

ノードHost04

ClusterClusterA

SIBus

SIB01

ME

ME

ノードHost03

DB

ノードHost01

ClusterClusterB


ME


ME



JMS App

JMS App

ノードHost01

ノードHost01

ClusterClusterA

SIBus

SIB01

ME

ME

ノードHost01

- 15 -

ないため、他のノードにあるメッセージング・エンジンを検索し、同じ検索範囲にメッセージング・

エンジンを 2 つ見つけます。しかし、SIBus メンバーに属していないため、最初に接続したメッセージング・エンジンに対してのみメッセージを Put/Get します。

3-2-2 メッセージング・エンジンの構成この節では、メッセージング・エンジンの構成方法を説明します。

3-2-2-1 シングル構成アプリケーション・サーバー、もしくはクラスターをSIBにバス・メンバーとして登録することで、メッセー

ジング・エンジンが作成できます。

メッセージング・エンジンの設定は、下記の手順で行います。

1). データ・ソースを作成する

2). バスを作成する

3). バス・メンバーを登録する

4). メッセージング・エンジンを設定する (Data Store) ここでは、アプリケーション・サーバー「mes1」をバス「sib1」に登録し、動作確認を行います。目指す構

成を図にすると、下図のようになります。

図 3-18 サンプル構成

SIB にアプリケーション・サーバー（図内[AP Server]）を、バス・メンバーとして追加すると、メッセージ

ング・エンジン（MQ の Queue Manager に相当）が自動で作成されます。メッセージング・エンジンは構成

情報を保持や、パーシスタント・メッセージを保持する為に、データベースを利用します。データベース

には JDBC で接続し、一つのメッセージング・エンジンはデータベース内の一つのスキーマに関連付けら

れます。

アプリケーションは、SIBus 内に定義された宛先に対してメッセージの send や receive を行います。

宛先は JMS 1.1 の Destination に相当するもので、実態がトピック・スペースであってもキューであって

も操作上は区別しません。

5). データ・ソースを作成するメッセージング・エンジンでデータ・ストアを利用する為に、データ・ソースを定義します。

今回は、以下のように設定します。

表 3-1 JDBC プロバイダーの設定

名前値

スコープノード

SIBus

SIB1

ノードHost01

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

JMS App

JDBC


DB2[DataStore]

SIB1ME1[SCHEMA]

ME

- 16 -

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 C:\Program Files\IBM\SQLLIB\java

DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH C:\Program Files\IBM\SQLLIB\lib

UNIVERSAL_JDBC_DRIVER_PATH ${WebSphere

AS_INSTALL_ROOT}/universalDriver/lib

尚、AIX の場合、WebSphere 変数にパスを設定する以外に、WebSphere AS 起動ユーザーに

db2profile を読み込ませておく必要があります。

表 3-3 データ・ソースの設定

名前値

名前 db2.sample.sib1.mes1

JNDI 名 jdbc/db2/sample/sib1/mes1

データ・ストア・ヘルパー・

クラス

DB2 ユニバーサル・データ・ストア・ヘルパー

(com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper)

コンテナー／コンポーネン

ト管理の認証別名

データベース名 SAMPLE

ドライバー･タイプ 2

6). バスを作成するメニューから、[サービス統合]→[バス]を選択し、バスを新規作成します。

表 3-4 バスの設定

名前値概要

名前 sib1 SIB の名前です。

（チェックあり）グローバル・セキュリティーの設定を引き継ぐかど

うか。

エンジン間認証別名（なし）この SIB にアクセスする為の認証別名。

メディエーション認証別

名

（なし）メディエーションでこの SIB にアクセスするための

認証別名。

内部エンジン・トランスポ

ート・チェーン名

同一 SIB 内のメッセージング・エンジン間で利用

するトランスポート・チェーン名。デフォルトでは

InboundBasicMessaging です。

メッセージを破棄する（チェックなし）キュー・ポイントなどが削除された時の処理。チェ

ックがした場合はメッセージを削除、チェックしな

い場合はシステム例外宛先に保持します。

- 17 -

構成の再ロードを使用可

能にする

（チェックあり）再起動しないで設定変更を反映するかどうか。

メッセージ高しきい値 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 マネージャーにより他サーバーのプロセス障害やネットワーク障害を検知し、ポリシーに基づきメッセージング・エンジンのフェイルオーバーを行

います。

- 18 -

図 3-19 HA マネージャーによる ME のフェイルオーバー

HA マネージャーの設定 HA マネージャーの動作に関する設定は、コア・グループ設定および関連するポリシーにより行いま

す。

コア・グループ設定コア・グループ設定では、HA マネージャー間の通信方式を指定します。「CHANEEL_FRAMEWORK」 HA マネージャー間の通信を、CHANEEL_FRAMEWORK を使用して行います。「UNICAST」 HA マネージャー間の通信を、サーバープロセスの JVM が直接行います。

ポリシーの設定と挙動 HA マネージャーがどのようにメッセージング・エンジンを起動するかは、ポリシー設定に基づいて行われます。ポリシー設定は、下記の項目から構成されそれぞれの設定のよる挙動は、下記のようになります。 • クォーラム

ClusterClusterA


ME


MEHAManager HAManager

ClusterClusterA


ME



ClusterClusterA


ME



プロセス障害発生

HAManagerがAmember1の障害を検知

HAManagerがポリシーと現状を判断し

必要に応じてMEの起動を指示する。

- 19 -

クラスター構成時に、クラスターメンバーが半数以上起動するまで、一致基準で指定されるメッ

セージング・エンジンを起動しません。

図 3-20 クォーラムの ON、OFF 時の動き

• フェイル・バック優先サーバーで指定されている、優先順位高いサーバーが障害から復帰したらそのサーバーの

メッセージング・エンジンが起動し、優先順位の低いサーバーのメッセージング・エンジンが停止

する。

ClusterClusterA


ME

ノードHost01

ノードHost02

SIBus

SIB01

ノードHost03

ClusterClusterA


ME


ME

ノードHost01

ノードHost02

SIBus

SIB01

ノードHost03

半数以上のクラスターメンバーが起動するまでMEは起動されない

クォーラムありクォーラムなし

- 20 -

図 3-21 フェイル･バックの ON、OFF 時の動き

• 優先サーバーのみ優先サーバーで指定されたサーバーのみで、メッセージング・エンジンを起動します。

• 一致基準どのメッセージング・エンジンにポリシーを設定するかを指定します。この指定に該当するコンポ

ーネントが HA グループを構成します。特定のメッセージング・エンジンに対してポリシーを設定する場合は、下記のように設定します。・対象となるメッセージング・エンジンの指定名前：WSAF_SIB_MESSAGING_ENGINE 値：クラスターメンバー名.メッセージング・エンジン番号-SIBus 名・メッセージング・エンジンに対する指定名前：type 値：WSAF_SIB ・優先サーバーメッセージング・エンジンが起動する順位を、サーバー単位で指定します。

HA マネージャーによる障害の検知 HA マネージャーが障害として検知するのは、下記の状態が発生した場合です。コア・グループ設定にあるトランスポート・タイプが「 CHANEEL_FRAMEWORK 」もしくは、

「UNICAST」でも検知ロジックは変わりません。 • プロセスダウンにより、ソケットがクローズされた場合 • HA マネージャー間の Haertbeat が断絶した場合

ClusterClusterA


ME

ノードHost01

ノードHost02

SIBus

SIB01

ClusterClusterA


ME


ME

ノードHost01

ノードHost02

SIBus

SIB01

ClusterClusterA


ME


ME

ノードHost01

ノードHost02

SIBus

SIB01

フェイルバックあり

フェイルバックなし

優先度の高いMEが使用される

フェィルオーバーされたMEがそのまま使用される

- 21 -

• OS の TCP/IP KeepAlive のタイムアウトにより、ソケットがクローズされた場合１．プロセスダウンにより、ソケットがクローズされた場合プロセス障害が発生したことにより、ソケットがクローズされると HA マネージャーにより即時検知され、対象ノードがダウンしたと判断します。

図 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 マネージャーは対象ノードがダウンしたと判断します。

ClusterClusterA


ME



プロセス障害発生

プロセス障害発生により、コネクションが

クローズされる

コネクションのクローズによって

Amember1の障害を検知

- 22 -

図 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 のタイムアウトにより、ソケットがクローズされた場合

ClusterClusterA


ME


MEHAManager

ClusterClusterA


ME



ClusterClusterA


ME



HBHB

HBHB

規定回数の送受信の失敗により

障害が発生したと判断

障害が発生したと判断されたサーバーは、

HAGroupから切り離される

HAManager同士は、HearBeatを

送受信している

HAManager

- 23 -

OS側のTCPKeepAlive時間が経過した場合、コネクションがクローズされます。このコネクションのクローズを検知し、対象サーバーがダウンしたと判断します。

図 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 台追加できたら、「次へ」を選択します。

ClusterClusterA


ME


MEHAManager

ClusterClusterA


ME



ClusterClusterA


ME



HAManager

OSのTCPKeepAlive設定によりコネクションが切断

HeartBeatが無通信状態となっている

コネクションのクローズによって

Amember1の障害を検知

- 24 -

2). データ・ソースを作成するメッセージング・エンジンを使う為には、データ・ソースが必須ですので、下表のように設定しま

す。本題からはずれますので、詳細については説明を省きます。


名前値

スコープ cluster01






ー・パス※



クラス名



表 3-6 データ・ソースの設定

名前値




クラス







サーバー名

ポート番号 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) データ・ストアを設定します。

- 25 -

ここでクラスターを起動し、メッセージング・エンジンの稼動状況を確認します。

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 つしかないためメッセージの処理が１メッセージング・エンジンに集中します。

ここから説明を行う、「パーティショニング構成」は、クラスター内でメッセージング・エンジンを複数稼

働させることで、高可用性＋メッセージ処理の分散を行うことができる構成です。この構成で、メッセージ

ング・エンジンが起動するサーバーに障害が発生した場合、メッセージング・エンジン毎のフェイルオー

バーとメッセージの引き継ぎが行われます。この節では、メッセージング・エンジンパーティショニング構成を行うための設定方法、メッセージのバ

ランシングメッセージング・エンジンが稼働するおよび、サーバープロセスに障害が発生したときの挙動

について解説を行います。

- 26 -

パーティショニング設定パーティショニングを行う為に、一つのバス・メンバー内に複数のメッセージング・エンジンを構成しま

す。今回は、sib1 のバス・メンバーcluster01 にメッセージング・エンジンを追加します。作成された二つのメ

ッセージング・エンジン「 cluster01.000-sib1 」と「 cluster01.001-sib1 」の稼動系をそれぞれ「cluster01member01」と「cluster01member02」にして、パーティショニングさせます。

SIB のデフォルト・ポリシーでは、それぞれのメッセージング・エンジンが同じアプリケーション・サーバーで稼動する可能性が高いため、新しいポリシーをメッセージング・エンジンごとに作成します。そうする

ことで、それぞれのポリシーの優先サーバーを別のアプリケーション・サーバーに設定できます。 (i) まず、一つのメッセージング・エンジンには一つのデータ・ストアが必要なので、追加するメ

ッセージング・エンジン用のデータ・ソースを定義します。


名前値

スコープ cluster01






ー・パス※



クラス名



表 3-8データ・ソースの設定

名前値




クラス







サーバー名

ポート番号 50000

(ii) 次に SIB 構成画面からバス・メンバーを表示し、先ほど導入したクラスターを選択します。 (iii) メッセージング・エンジンの一覧が表示されるので、「メッセージング・エンジンの追加」を選

択します。 (iv) 作成しておいたデータ・ソースの JNDI 名と、適切なスキーマ名を指定します。 (v) DefaultCoreGroup の構成画面で、ポリシーの設定を行う為、追加プロパティーのポリシー

を選択します。

- 27 -

(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) 作成した宛先を確認します。

- 28 -

(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 リンク

図 3-25 SIBus リンク概要

2 つの SIBus があるとき、それぞれに含まれるメッセージング・エンジン同士をリンクすることで、バス間でメッセージのやり取りを可能にする機能です。SIBus リンクは、リンクする相互のバス上に、同じ名前で作成する必要があります。 SIBus リンクを作成するには、事前にいくつかの情報をまとめておく必要があります。主に必要な情報は、下表のとおりです。

アプリケーション・サーバー server1


SIBusリンク

外部バス SIBus02


SIBus SIB01

SIBusSIB02

ME me01

ME me02

- 29 -

項目説明 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. 別名宛先を作成する

- 30 -

メッセージを外部バスに送信するために、別名宛先を作成します。管理コンソールのツリー・ビュー

上で、[サービス統合]→[バス]→[バス名]→[追加プロパティー：宛先]を選択し、[新規作成]ボタンを押下し、宛先タイプの一覧から、[別名]を選択します。別名宛先を作成するに当たって重要な項目を下表に記します。

項目説明 ID バス上に作成する別名宛先名です。バス別名宛先を作成するバス名です。ターゲット ID ターゲットの宛先名です。ターゲット・バスターゲットの宛先があるバス名です。応答宛先/応答宛先バス逆作業工程パス（Reverse Routing Path）に追加される宛先名/バス名。デフォルト転送ルーティ

ング・パス転送ルーティング・パス（Forward Routing Path）が含まれていない場合に、設定される値です。「bus_name:destination_name」（同一バス上の場合は｢:destination_name｣でも指定可能）の形式で指定します。

この別名宛先に対してメッセージを send することで、外部バスにメッセージを転送できます。

WebSphere MQ リンク

図 3-26 WebSphere MQ リンク概要

MQ の Qmgr が存在するとき、チャネル接続を作成することでメッセージのやり取りが可能になります。Qmgr はバス上に外部バスとして作成されます。チャネルは、バスから Qmgr にメッセージを転送するための送信チャネルと、Qmgr からバスにメッセージを転送するための受信チャネルを作成します。メッセージング・エンジンは Qmgr 上で外部 Qmgr として作成されます。そのため、MQ リンク作成時には、メッセージング・エンジンに仮想 Qmgr 名を設定します。 MQ リンクを作成するには、事前にいくつかの情報をまとめておく必要があります。主に必要な情報は、下表のとおりです。

項目説明仮想 Qmgr 名リンク先 Qmgr によって認識される、メッセージング・エンジンの仮想 Qmgr

名です。受信側 MQ チャネル名 Qmgr からメッセージング・エンジンにメッセージを送信するために利用す

る、Qmgr の送信チャネル名を指定します。


送信側MQチャネル

SIBus SIB01

ME me01

受信側MQチャネル


キュー・マネージャー QMGR1

- 31 -

インバウンド・非パーシスタ

ント・メッセージの信頼性 Qmgr からメッセージング・エンジンにメッセージが送信されるメッセージが、非パーシスタント・メッセージだったとき、メッセージング・エンジン側

で割り振られる信頼性レベルを指定します。インバウンド・パーシスタン

ト・メッセージの信頼性 Qmgr からメッセージング・エンジンにメッセージが送信されるメッセージが、パーシスタント・メッセージだったとき、メッセージング・エンジン側で

割り振られる信頼性レベルを指定します。送信側 MQ チャネル名メッセージング・エンジンから Qmgr にメッセージを送信するために利用す

る、Qmgr の受信チャネル名を指定します。 QM のホスト名 Qmgr が稼動しているホスト名を指定します。 MQ リスナーのポート番号 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 からメッセージング・エンジンにメッセージが送信されるメッセージが、パーシスタント・メッセージだったとき、メッセージング・エンジン

側で割り振られる信頼性レベルを指定します。

- 32 -

2. 別名宛先を作成するメッセージング・エンジンから SIBus にメッセージを送信する場合、Qmgr 上のローカル・キューに対して、SIBus 上に別名宛先を定義します。管理コンソールのツリー・ビュー上で、[サービス統合]→[バス]→[バス名]→[追加プロパティー：宛先]を選択し、[新規作成]ボタンを押下し、宛先タイプの一覧から、[別名]を選択します。別名宛先を作成するに当たって重要な項目を下表に記します。

項目説明 ID バス上に作成する別名宛先名です。バス別名宛先を作成するバス名です。ターゲット ID ターゲットのローカル・キュー名です。「Qlocal_name@Qmgr_name」の

形式で指定します。ターゲット・バスターゲットの宛先があるバス名です。この別名宛先に対してメッセージを send することで、Qmgr にメッセージを転送できます。

3. リモート・キューを作成する MQ から SIBus にメッセージを送信する場合、SIBus 上の宛先に対して、Qmgr 上にリモート・キューを定義します。

Qremote_name=Qmgr 上に定義するリモート・キュー名 Dest_name=SIBus 上の宛先名 ME_Qmgr_name=メッセージング・エンジンの仮想 Qmgr 名

このリモート・キューにメッセージを PUT することで、メッセージが SIBus に転送されます。

3-2-2-7 メディエーションメディエーション・プロセスは、アプリケーションが送信したメッセージが受信されるまで、移動中のメッ

セージを処理します。メディエーションはコーディング可能で、次のような処理が可能です。 • ある形式から別の形式へのメッセージ変換。 • 送信側アプリケーションによって指定されなかった 1 つ以上のターゲット宛先へのメッセージのル

ーティング。 • データ・ソースからデータを追加することによる、メッセージの拡大。 • 複数のターゲット宛先へのメッセージの配布。前述のとおり、メディエーションを利用する場合、事前にメディエーション・ハンドラーをコーディングして

おく必要があります。ここでは、メディエーション・ハンドラーの

Documents

IBM Support and downloads - 3 SIBus 構成public.dhe.ibm.com/.../was6_adminguide/V6Guide_13_SIBus.pdf · 2009. 1. 27. · WebSphere AS V6.0 に内蔵されているデフォルトのJMS