2. WebOTX ESBによるクラスタ機能

2.1. NMR

2.1.1. エンドポイントクラスタ

WebOTX ESBが提供するエンドポイントクラスタ機能により、エンドポイントの障害を 検知し、障害が発生したエンドポイントを閉塞することができます。 詳しい説明は以下を参照してください。 [ 製品構成と提供機能 > 4.ESB > 4.1.JBIコンテナと共通機能 > 4.1.6.プロバイダエンドポイントのクラスタ化 ]

2.2. バインディングコンポーネント

2.2.1. SOAP BC

多重化クラスタ環境でSOAP BCを使用する場合には、Inboundのメッセージをロードバランサによって振り分けます。

【図2.1.1a】 SOAP多重化の概念

ロードバランサの設定により、振り分けられたSOAPのHTTPリクエストが各マシンのSOAP BCのエンドポイントに到達するようにします。

Outboundのメッセージについては特別な設定は必要ありません。

2.2.2. JMS BC

想定している多重化構成、InboundとOutboundの多重化で必要な設定について説明します。

2.2.2.1. 多重化構成

複数ドメインでの多重化

WebOTX Application Server ExpressやスタンダードモードのStandard/Enterpriseベースの場合、同じサービスアセンブリを複数のドメインで動作するESBに配備することにより、ESBを多重化することができます。

ただし、送信先に関して、以下のいずれかの条件を満たす必要があります。

- 各ESBとは異なるドメインに送信先を配置すること。

異なるドメインの送信先にアクセスするためには、使用するコネクションファクトリのJMSリソースに、当該ドメインで動作するJMSサーバのホスト名とポート番号を設定してください。

送信先のJMSリソースには、異なるドメインに作成した物理的送信先の名前を設定してください。

- 各ESBのドメインの送信先を多重化するために、WebOTX Application ServerのJMS拡張機能「JMSサーバクラスタ」を有効にすること。

多重化させる全ドメインのJMSサーバに、クラスタに関する設定をしてください。詳細は、WebOTX JMSのマニュアル(運用編)を参照してください。

プロセスグループでの多重化

アドバンスドモードのStandard/Enterprise Editionの場合、ESBを有効にしたプロセスグループのプロセス多重度を上げることにより、ESBを多重化することができます。1つのサービスアセンブリを配備すると、すべてのプロセスで同じエンドポイントが活性化されます。

複数ドメインでの多重化のような、送信先に関する条件は特にありません。

2.2.2.2. 多重化動作

Inbound

QueueからのInbound要求は、デフォルトで多重化されたエンドポイントに分散して配信されます。

その応答については、エンドポイント定義に設定された応答用送信先、もしくは要求時のJMSメッセージのJMSReplyToに設定されている応答用送信先に対して送信されます。従って、応答用送信先がJMSクライアントで共有されている場合には、その配信も分散されてしまうため、要求元のJMSクライアントに応答が正しく返らない可能性があります。

そのため、JMSクライアントにおいて、次のような対応が必要となります。

- 専用の応答用送信先(例えばJMS標準のTemporaryQueue)を要求時のJMSReplyToに設定して自分の応答を受信する。

- 要求時に設定した値が設定される応答時のJMSCorrelationIDを利用したセレクタで自分の応答のみを受信する。

TopicからのInbound要求は、Topicの特性により、多重化されたエンドポイントすべてに対して同じメッセージが配信されてしまいます。

そのため、WebOTX Application Serverの JMSのTopicマルチコンシューマ機能を有効にするために、以下の設定が必要です。

項目 説明

クライアントID

コンシューマのグルーピングのために使用するクライアントIDを指定します。

クライアントIDの共有

複数のコンシューマで同じクライアントIDを使用できるようにtrueを指定します。

※ 設定は、「エンドポイント定義」もしくは「コネクションファクトリ」で行うことができます。

※ 「プロセスグループでの多重化」の場合、JMS BCが自動的に設定します。ただし、加えてドメインとの間でも多重化を行う場合は、上記設定が必要となります。

Topicの応答は、サポートしていません。

Outbound

QueueへのOutbound要求は、各エンドポイントから同じ送信先に送信するだけであり、特に問題ありません。

その応答については、Inbound同様に、同じ応答用送信先から要求元のエンドポイントに戻す必要があるため、JMS BCは要求時のJMSCorrelationIDにエンドポイント固有の情報を格納し、応答受信時にその情報を使用したセレクタにより、エンドポイントへの対応付けを行います。JMSクライアントにおいては、必ず、要求時のJMSCorrelationIDを応答時に設定してください。

この対応付けを有効にするには、「エンドポイント定義のオプション」に以下の設定が必要です。

項目 説明

MultipleEndpoint

多重化のために必要な動作を行うようにtrueを指定します。

※ 「プロセスグループでの多重化」の場合、この指定がなくても自動的に対応付けを行います。

※ このケースに限らず、Inbound、Outbound含め、多重化するエンドポイントすべてに設定しておいても構いません。

TopicへのOutbound要求は、各エンドポイントから同じ送信先に送信するだけであり、特に問題はありません。

Topicの応答は、サポートしていません。

2.2.3. JCA BC

クラスタ構成で使用するための特別な設定、注意制限事項はありません。

2.2.4. RMI BC

RMI BCを使用する場合、SOAP BCなどの他のJBIコンポーネントでInboundのメッセージを受け取ります。メッセージの振り分け方法については、Inboundのメッセージを受け取るJBIコンポーネントの設定方法を参照してください。

RMI BCから呼び出すEJBアプリケーションを、RMI BCが動作するドメイン以外で動作させる場合には、EJBアプリケーションのリファンレスを入手するJNDIサーバのアドレス情報を変更する必要があります。RMI BC用MOの「JNDIサーバと接続するためのURL」を変更してください。または、エンドポイント毎に接続先を変更する必要がある場合には、エンドポイントの定義の際に「JNDIサーバのアドレス(corbaname URL)」を変更してください。

Dotted-name:server.jbi.components.RMIBinding

属性名(attribute-name) 説明 既定値

JNDIサーバと接続するためのURL

(JndiProviderUrl)

JNDIサーバと接続するためのcorbaloc / corbaname URLを設定します。指定を省略した場合、ドメイン内のJNDIサーバに接続します。

なし

URLには、次の例のように複数のホストを指定することもできます。

rmiiiop://hostname1:2809, hostname2:2809

また、RMI BCから呼び出すEJBアプリケーションで、名前サーバのラウンドロビン機能を利用する場合には、呼び出し先のサーバを振り分けるために、RMI BC用MOの「CORBAのリファレンスのキャッシュ有無」にfalseを設定してください。

Dotted-name:server.jbi.components.RMIBinding

属性名(attribute-name) 説明 既定値

CORBAのリファレンスのキャッシュ有無

(CacheCorbaReference)

CORBAのリファレンスのキャッシュ有無。呼び出し先のEJBが名前サーバのラウンドロビン機能を使用する場合にはfalseを設定してください。

true

2.2.5. File BC

File BCは多重化クラスタを構成するそれぞれのマシン上のディレクトリからメッセージの入出力をおこないます。Inboundのメッセージについてはアプリケーションで入力ファイルを各マシンに振り分ける必要があります。また、Outboundのメッセージについても各マシン上の出力ディレクトリにファイルが出力されるので、アプリケーションで各マシン上の出力ディレクトリからファイルを収集する必要があります。

Caution
多重化クラスタの共有ディスク上で、同一ディレクトリを共有してFile BCによりファイルの入出力を行うことはできません。

2.2.6. CORBA BC

CORBA BCを使用する場合、SOAP BCなどの他のJBIコンポーネントでInboundのメッセージを受け取ります。メッセージの振り分け方法については、Inboundのメッセージを受け取るJBIコンポーネントの設定方法を参照してください。

CORBA BCから呼び出すサーバアプリケーションを、CORBA BCが動作するドメイン以外で動作させる場合には、サーバアプリケーションのリファンレスを入手する名前サーバのアドレス情報を変更する必要があります。CORBA BC用MOの「名前サーバと接続するためのURL」を変更してください。または、エンドポイント毎に接続先を変更する必要がある場合には、エンドポイントの定義の際に「名前サーバのアドレス(corbaname URL)」を変更してください。

Dotted-name:server.jbi.components.CORBABinding

属性名(attribute-name) 説明 既定値

名前サーバと接続するためのURL

(NameServerUrl)

名前サーバと接続するためのcorbaloc / corbaname URLを設定します。指定を省略した場合、ドメイン内の名前サーバに接続します。

なし

URLには、次の例のように複数のホストを指定することもできます。

rmiiiop://hostname1:2809, hostname2:2809

また、CORBA BCから呼び出すサーバアプリケーションで、名前サーバのラウンドロビン機能を利用する場合には、呼び出し先のサーバを振り分けるために、CORBA BC用MOの「CORBAのリファレンスのキャッシュ有無」にfalseを設定してください。

Dotted-name:server.jbi.components.CORBABinding

属性名(attribute-name) 説明 既定値

CORBAのリファレンスのキャッシュ有無

(CacheCorbaReference)

CORBAのリファレンスをキャッシュするかどうかを設定します。呼び出し先のCORBAアプリケーションが名前サーバのラウンドロビン機能を使用する場合にはfalseを設定してください。

true

2.2.7. JDBC BC

JDBC BCが動作するドメイン以外で動作しているデータソースを利用する場合には、データソースのリファンレスを入手するJNDIサーバのアドレス情報を変更する必要があります。JDBC BC用MOの「JNDIのプロバイダURL」を変更してください。または、エンドポイント毎に接続先を変更する必要がある場合には、エンドポイントの定義の際に「JNDIのプロバイダURL」を変更してください。

Dotted-name:server.jbi.components.JDBCBinding

属性名(attribute-name) 説明 既定値

JNDIのプロバイダURL

(JndiProviderUrl)

JNDIのプロバイダURLを設定します。

”rmiiiop://localhost”

URLには、次の例のように複数のホストを指定することもできます。

rmiiiop://hostname1:2809, hostname2:2809

2.2.8. FTP BC

FTP BCはクラスタリングをサポートしません。

2.2.9. HTTP BC

多重化クラスタ環境でHTTP BCを使用する場合には、Inboundのメッセージをロードバランサによって振り分けます。

【図2.11.1a】 HTTP多重化の概念

ロードバランサの設定により、振り分けられたHTTPリクエストが各ESBのHTTP BCのエンドポイントに到達するようにします。

Outboundのメッセージについては特別な設定は必要ありません。

2.2.10. TCP/IP BC

クラスタ構成で使用するための特別な設定、注意制限事項はありません。

2.2.11. Salesforce BC

多重化クラスタ環境でSalesforce BCを使用する場合には、Inboundのメッセージをロードバランサによって振り分けます。

【図2.2.10a】 Salesforce多重化の概念

ロードバランサの設定により、振り分けられたSalesforceのHTTPリクエストが各マシンのSalesforce BCのエンドポイントに到達するようにします。

Outboundのメッセージについては特別な設定は必要ありません。

2.3. サービスエンジン

2.3.1. XSLT SE

クラスタ構成で使用するための特別な設定、注意制限事項はありません。

2.3.2. Sequencing SE

クラスタ構成で使用するための特別な設定、注意制限事項はありません。

2.3.3. CBR SE

クラスタ構成で使用するための特別な設定、注意制限事項はありません。

2.3.4. UserProcessor SE

クラスタ構成で使用するための特別な設定、注意制限事項はありません。