4. ESB

本章では、WebOTX ESBの機能と実装仕様について説明します。

4.1. JBIコンテナと共通機能

WebOTX ESBは、ESB実行環境であるJBIコンテナとさまざまなプロトコル通信やルーティング機能をもつ各種コンポーネントから成り立ちます。本章ではJBIコンテナが持つ機能および各種コンポーネントが共通して持つ機能を紹介します。

4.1.1. JBIコンテナ

【図4.1.1a】JBIコンテナの構成

JBIコンテナは、JBIフレームワークを基に作成されたJBI仕様準拠のコンポーネントやサービスを実行するための環境です。JBIコンテナは【図4.1.1a】のようにWebOTX Application Server が提供するJava EEをベースにして動作し、WebOTXのドメイン上にあるWebコンテナやEJBコンテナと並列して存在します。WebOTX ESBでは、SOAP、JMS、JCA、RMI、CORBA、JDBC、FTP、HTTP、Fileといった各種プロトコルに対応したBCと、XSL変換やメッセージの内容に応じたルーティングを行うSEといった幅広い用途に対応する豊富なコンポーネント群がJBIコンテナにあらかじめインストールされています。これらのコンポーネントに対応するサービスユニットとサービスアセンブリ(SA)を作成・配備することで、JBIコンテナはESBとしての動作を行います。

Memo
各用語の意味については、付録の用語集もご参照下さい。

4.1.2. 共通ハンドラ

共通ハンドラ機能とは、各コンポーネント(BC/SE)を流れるメッセージを編集する任意の処理を組み込む機能です。共通ハンドラ機能は、メッセージの一部またはメッセージのスキーマやフォーマットを変更したい場合や、動的にメッセージ送信先を変更したい場合などにも有効となります。共通ハンドラは目的に応じて次の2種類があります。

メッセージコンバートハンドラは、各BCのメッセージエクスチェンジを作成するタイミングもしくは各BCの通信プロトコルで送るオブジェクトを作成するタイミングで任意の変換処理を埋め込めます。

メッセージエクスチェンジハンドラは、各BCおよびSEの内部でメッセージエクスチェンジの中身を確認したり、書き換えたり、内容によってエンドポイントを変更することが可能です。

以下ではそれぞれについて説明します。

4.1.2.1. メッセージコンバートハンドラ

JBIコンポーネントが外部サービスと送受信するメッセージに対して、編集などの任意の処理を追加することができる機構です。規定のインタフェースに従ったハンドラクラスを作成し、その中で外部サービスと送受信するメッセージを直接変更する実装ができます。

メッセージコンバートハンドラは外部サービスとメッセージ送受信する部分で動作します。一つのハンドラクラスで送信と受信の各メッセージについて処理します。

このメッセージコンバートハンドラを装備しているのは次のJBIコンポーネントになります。

File BC、FTP BC、HTTP BC、JMS BC

【図4.1.2a】メッセージコンバートハンドラ機構(Inbound側)

【図4.1.2b】メッセージコンバートハンドラ機構(Outbound側)

ハンドラは開発環境のSUエディタを使用して各コンポーネントのendpoints.xmlに設定します。

設定内容はハンドラ名、ハンドラクラス名、ハンドラの初期化パラメータです。ハンドラクラスを複数登録することで、これらのハンドラを順次実行します。図4.1.2a,bのようにハンドラをA, B, Cの順に複数登録した場合、Inbound側もOutbound側もメッセージの受信側ではハンドラは設定登録順に実行しますが、送信側では設定登録順とは逆になります。

Memo
図中の受信メッセージとは、コンシューマから発するリクエストメッセージで、メッセージエクスチェンジに変換される前のものです。図中の送信メッセージとは、プロバイダからのレスポンスメッセージで、メッセージエクスチェンジから元のメッセージ形式に変換された後のものです。

4.1.2.2. メッセージエクスチェンジハンドラ

JBIコンポーネントを流れるメッセージエクスチェンジに含まれるノーマライズメッセージに対して、編集などの任意の処理を追加することができる機構です。規定のインタフェースに従ったハンドラクラスを作成し、その中でノーマライズメッセージを直接変更する実装ができます。

メッセージエクスチェンジハンドラはJBIコンポーネントとNMRがメッセージ送受信する部分で動作し、流れてくるメッセージの状態に合わせて、一つのハンドラクラスでIn、Out、Fault、Error毎に処理を追加することが可能です。ハンドラ内からIn、Out、Faultメッセージの内容を変更やメッセージの宛先の変更処理を行うことができます。

メッセージエクスチェンジのプロパティを利用し、Sequencing SEのメッセージコンバートハンドラやメッセージエクスチェンジハンドラ間で情報を共有することができます。

プロバイダ、およびコンシューマで開始したXAトランザクションにメッセージエクスチェンジハンドラを参加させることができます。また、プロバイダ、およびコンシューマで開始したXAトランザクションをメッセージエクスチェンジハンドラからロールバックさせることもできます。

このメッセージエクスチェンジハンドラを装備しているのは次のJBIコンポーネントになります。

COBRA BC、File BC、FTP BC、HTTP BC、JCA BC、JDBC BC、JMS BC、RMI BC、SOAP BC、TCPIP BC、Salesforce BC、HL7 BC
CBR SE、XSLT SE

【図4.1.2c】メッセージエクスチェンジハンドラ機構(Inbound側)

【図4.1.2d】メッセージエクスチェンジハンドラ機構(Outbound側)

ハンドラは開発環境のSUエディタを使用して各コンポーネントのartifact(endpoint.xml)に設定します。

設定内容はハンドラ名、ハンドラクラス名、ハンドラの初期化パラメータです。ハンドラクラスを複数登録することで、これらのハンドラを順次実行します。図4.1.2c,dのようにハンドラをA, B, Cの順に複数登録した場合、Inbound側もOutbound側も受信メッセージ側ではハンドラは設定登録順に実行しますが、送信メッセージ側では設定登録順とは逆になります。

Memo
図中のInメッセージとは、コンシューマから発するリクエストメッセージで、NMRが受信するメッセージエクスチェンジにあたります。図中のOutメッセージとは、プロバイダからのレスポンスメッセージで、NMRから外部に送信されるメッセージエクスチェンジにあたります。

Memo
ノーマライズメッセージのメッセージコンテント(NormalizedMessageクラスのgetMessage, setMessageメソッドで取得・設定される)には、通常はXML文書を格納しますが、WebOTX ESB では javax.xml.transform.stream.StreamSource 型を使用することで非XML文書をメッセージコンテントに格納することが可能です。ただし、SOAP BC/JCA BC/RMI BC/CORBA BC/JDBC BC/Salesforce BC/XSLT SE/CBR SEがハンドラからメッセージを受け取る場合、これらのコンポーネントは非XML文書を扱うことができません。

4.1.3. 統計情報

WebOTX ESBが提供する全てのコンポーネント(BC/SE)は統計情報を取得する機能を提供しています。統計情報により、パフォーマンスや負荷に関する情報を採取することができます。統計情報には以下の2つのものがあります。

以下ではそれぞれ説明します。

コンポーネント統計情報

コンポーネント統計情報は、コンポーネント(BC/SE)毎で統計情報を採取します。コンポーネント統計情報では以下のような情報を採取できます。

設定方法や具体的な項目は[ 運用ガイド > 6. モニタリング ] を参照してください。

エンドポイント統計情報

エンドポイント統計情報は、エンドポイント毎で統計情報を採取します。コンポーネント統計情報よりもさらに粒度の高い情報を採取することが可能です。エンドポイント統計情報では以下のような情報が採取できます。

設定方法や具体的な項目は[ 運用ガイド > 6. モニタリング ] を参照してください。

4.1.4. メッセージログ

メッセージログ機能は、各コンポーネント(BC/SE)で交換するサービスバス(NMR)を流れるメッセージの内容をログとして出力する機能です。メッセージログ機能を利用することで、開発時のデバックや運用時の障害のトレースを効率的に行うことが可能です。また、出力先は手軽に利用可能なファイルシステムへのファイル出力に加え、Oracleなどのデータベースへの出力にも対応しています。

メッセージログ機能の設定方法や詳細な内容は[ 運用ガイド > 2. メッセージログ ] を参照してください。

4.1.5. 分散ESB

分散ESB機能は、複数のESBを仮想的に1つのESBとして開発・運用することを実現します。

複数のESBからなる大規模分散システムの場合、従来は全てのESBが独立していたため個別に接続設定する必要があり、運用操作が煩雑になっていました。分散ESB機能により、異なるバックエンドのシステムを連携する場合の構築期間が短縮し、なおかつ運用操作のミスを提言することができます。

【図4.1.5a】分散ESB概要

分散ESB機能を使用した場合のシステム構成について説明します。複数のESBサーバ間はMessage Exchangeをシリアライズしたメッセージで通信します。この通信では2つの通信プロトコル「JMS、SOAP」をサポートします。分散ESBのシステムの構成の説明は下記の通りです。

【図4.1.5b】分散ESBのシステム構成

(1) 分散ESB環境

複数のESBインスタンスが協調して動作する環境です。

(2) 分散管理サーバ(Proxyドメイン)

分散ESB環境全体を運用操作する特別なESB実行環境です。分散ESB環境全体で0〜1つ存在して、ESBインスタンスを一括して運用操作します。分散ESB環境に管理ドメインが存在しなくても、各々のユーザドメインを個別で運用操作することでも分散ESB環境を構築可能です。このESB管理サーバ上では運用のみが行われ、BC/SE/NMRといったESBのルーティングに関する機能は動作しません。

(3) ESBインスタンス

ESB実行環境が動作して、メッセージングを実行します。ESBインスタンスは、従来からのESB実行環境と同じです。分散ESB環境に複数存在することができます。

ESBインスタンスには分散環境内でユニークな固有のESBインスタンス名を持ちます。ExpressやStandard/Enterpriseエディションのスタンダードモードの場合はドメイン毎にESBインスタンスが存在します。Standard/Enterpriseエディションのアドバンスドモードの場合はプロセスグループ毎にESBインスタンスが存在します。

(4) Proxy BC

分散ESB環境において、ESBインスタンス間でメッセージを仲介します。通信プロトコルはSOAPとJMSから選択できます。

(5) JMS

Proxy BC間でJMSにより通信を行う場合に、メッセージ交換を仲介します。ESBインスタンス毎に1つのJMSキューを用意します。

4.1.6. プロバイダエンドポイントのクラスタ化

ESBを介して連携する外部システムのクラスタ構成(負荷分散やフェールオーバ)にあわせて、複数のプロバイダエンドポイントをグルーピング定義することにより、プロバイダエンドポイントへの経路をNMRで制御することができます。

ESBを介して連携する外部システムのクラスタ構成にあわせて、2つの方式を利用できます。

【図4.1.6a】プロバイダエンドポイントのクラスタ化

ラウンドロビン

ラウンドロビンでは、サービスアセンブリに指定された重み付けに従って、配分を調整しながら順番に経路を選択していきます。ロードバランスクラスタ構成をとる外部システムに対して、メッセージ処理を負荷分散させるような場合に利用します。

経路が選択された場合でも、、スロースタートの処理状態によっては選択をスキップします。

固定シーケンス

固定シーケンスでは、サービスアセンブリに指定された順序に従って、優先度の高いものから経路を選択していきます。フェールオーバクラスタ構成をとる外部システムに対して、障害発生時にバックアップ側でメッセージ処理を継続させるような場合に利用します。

固定シーケンスの場合、スロースタートは無効です。

4.1.6.1. 経路閉塞

次の場合、経路が閉塞されて選択対象から外れます。

自動閉塞

自動閉塞は、Outbound側外部システムとの間で通信エラーのような致命的な障害が発生した場合に、プロバイダが自動閉塞を示すErrorを返すことにより、自動的に経路を閉塞するものです。対象となるErrorについては、「付録 異常系メッセージ(Fault/Error)」のエンドポイント閉塞の欄をご覧ください。

外部システムに依存した動作があるために自動閉塞させたくない場合、設定で無効にすることも可能です。

運用者は、自動閉塞を次の事象で認識することができます。

閉塞した経路は、次の運用操作により復旧します。

閾値制御

サービスアセンブリのグルーピング定義で以下の設定を行うことにより、自動閉塞の発生を遅延させることが可能です。

エラー発生回数を指定すると、次のように制御します。

エラー発生回数(回)

説明

0

自動閉塞しません。

1

1回エラーが発生した時点で自動閉塞します。(既定値)

n

指定回数分エラーが発生した時点で自動閉塞します。

エラー発生率を指定すると、次のように制御します。

エラー発生率(%)

説明

0

リセットします。(既定値)

1〜99

起動後もしくはリセット後の最初のエラーが発生した時点から制御を開始(開始時点の発生率は100%)し、指定値を下回った時点で累積値をリセットします。

100

起動後もしくはリセット後の最初のエラーが発生した時点から制御を開始し、エラーが連続発生しなかった時点で累積値をリセットします。

Memo
閾値を設定していないサービスアセンブリ(例えばV8.5より前の環境で構築したもの)についても、メッセージサービスMOの属性でデフォルト値を変更することで閾値制御を有効にできます。

ロードバランシング方式が固定シーケンスの場合、コンシューマがエラーリトライを行っても、同じ経路が利用されてエラーが発生し続ける可能性があります。
このため、エラーリトライ時に経路を切り替えるための設定を、メッセージサービスMOの属性として提供しています。

利用回数(回)

説明

-1

エラーリトライも同じ経路を利用します。 (既定値)

0

エラーリトライは次の経路を利用します。

n

指定回数を超えたエラーリトライは次の経路を利用します。

また、メッセージサービスMOでは、次の操作を提供しています。


4.1.6.2. グルーピング定義

次に示すグルーピング定義は、開発環境でのサービスアセンブリ作成時に行います。

経路に相当するプロバイダエンドポイントは、それぞれ別のサービスアセンブリに定義してください。すべてを1つのサービスアセンブリに定義することも可能ですが、経路ごとの重み付け/順序の指定、経路の追加削除や経路ごとの運用操作を考慮すると、経路ごとにサービスアセンブリを作成することが基本です。

コンシューマエンドポイントは、プロバイダエンドポイントを定義したサービスアセンブリと同じでも別でも構いません。同じ定義内容でSU名も同じものであれば、経路すべてのサービスアセンブリに重複して定義しても構いません。通常は配備エラーとなりますが、グルーピング定義がなされたサービスアセンブリでは可能です。ただし、最初に配備したファイルをESB実行環境が使用するため、最初に配備したサービスアセンブリの配備解除は、他がすべて配備解除された後に行う必要があります。従って、追加削除の対象とならない、普遍的な経路を最初に配備することを推奨します。また、起動状態からストップやシャットダウン状態にする場合、1つでも起動状態のものがある場合は起動状態のままとなります。

通常、サービス名とエンドポイント名が一致するプロバイダエンドポイントが経路として選択されますが、複数の経路を定義する場合には、エンドポイント名が一致しないものが生じます。この場合、サービス名だけが関連付けの要素となるため、意図しない経路と関連付かないように、他の定義とサービス名を一意にする必要があります。

4.1.6.3. スロースタート

サービスアセンブリのスロースタート操作を利用することにより、新しく追加した経路でのメッセージ処理量を徐々に増加させていく運用を行うことができます。

スロースタート操作では、指定した制御完了時間(デフォルト3分)を3つの段階(25%、50%、75%)に分けて処理を配分します。


4.1.7. データ検証機能

指定したスキーマを利用し、コンポーネントへの入出力メッセージの妥当性を検証できます。

妥当でないメッセージの場合は処理を中断し、Faultを返却します。

4.1.8. セキュリティ機能

SECUREMASTERやカスタムLoginModuleとの連携を行い、認証・認可を行うことができます。

認証・認可に失敗した場合は処理を中断し、Faultを返却します。

4.1.9. メッセージ送信優先度

EventManagerのスレッド数が少ない場合、ワークスレッドのプール数が少ない場合、Outbound側の送信処理で遅延が発生している場合など、NMRのキューにメッセージが滞留してしまう可能性があります。メッセージ送信優先度を指定することにより、そのような状況下で優先するメッセージを処理させることが可能です。

メッセージ優先度は、コンシューマエンドポイントに-5(優先度低)から5(優先度高)の範囲で指定します。また、MessageExchangeハンドラで"ESB_MSG_PRIORITY"プロパティで優先度を更新することもできます。

デフォルトでは、NMRのキューは単一であり優先度は無効です。優先度を有効にするには、ESBのメッセージサービスの設定「メッセージ優先度の幅」に必要な優先度の幅を指定しておく必要があります。

JMS BCのみ、エンドポイントで指定することはできません。 JMSメッセージに付与されている優先度(0〜9)をESBのメッセージ送信優先度(-4〜5)に自動的に対応付けるためです。

4.1.10. エラーリトライ

コンシューマがトランザクションに対応していない場合でも、プロバイダからのエラーに対してメッセージ送信を有限回リトライさせることが可能です。

エラーリトライは、コンシューマエンドポイントに、リトライ回数とリトライ間隔を指定します。

4.1.11. エラー通知

プロバイダエンドポイントをエラー通知先として定義しておくと、コンシューマがプロバイダからのエラーを受けた際にメッセージをエラー通知先に転送することができます。

トランザクションをサポートする場合、エラー通知は行われません。

エラーリトライが有効な場合、リトライ回数を超過するまでエラー通知は行われません。

エラー通知先は、プロバイダエンドポイント作成時に定義します。

4.1.12. トランザクション

トランザクションに参加する処理を持たないコンポーネントのコンシューマでトランザクションの制御を行うための機能です。 この機能を利用することで、JMS BC、JDBC BCといったトランザクションに参加する処理を持つコンポーネントと、その他のコンポーネントを組み合わせた場合にも、トランザクション処理を行えるようになります。

トランザクション機能を有効にすることで、コンシューマでトランザクションの開始・終了が行われるようになり、エラー発生時にトランザクションをロールバックし、トランザクションをサポートするプロバイダの処理を巻き戻すことができます。

トランザクション機能を有効にした場合、エラーリトライ・エラー通知は行われません。

以下のコンポーネントでこのトランザクション機能をサポートします。
SOAP BC、JCA BC、File BC、FTP BC、HTTP BC、TCPIP BC、Salesforce BC、HL7 BC

以下に、トランザクション機能の利用例を挙げます。

サポートするMEPとコミット・ロールバックする条件については、以下の通りです。

MEP

動作

In-Only

Doneを受信:トランザクションをコミット (※1)
Errorを受信/Inboundでエラー発生:トランザクションをロールバック

Robust In-Only

Doneを受信/Faultを受信:トランザクションをコミット (※1、※2)
Errorを受信/Inboundでエラー発生:トランザクションをロールバック

In-Out

Outを受信/Faultを受信:トランザクションをコミット (※2)
Errorを受信/Inboundでエラー発生:トランザクションをロールバック

(※1) エンドポイント定義のオプションTransactionAlwaysCommitInDoneにtrueを指定することで、Done受信後にエラーが発生したとしてもコミットさせることが可能です。
(※2) エンドポイント定義のオプションTransactionRollbackInFaultにtrueを指定することで、Fault受信の場合にもロールバックさせることが可能です。

Caution
  JDBC BCやJMS BCと組み合わせた際にそれらのBCの操作をトランザクションに参加させるための機能であり、トランザクション機能を有効にしたコンポーネント自体の操作をトランザクションに参加させることはできません。

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

4.2.1. SOAP BC

SOAP BCは、外部のWebサービス、またはWebサービスクライアントとHTTP/SOAPメッセージを送受信するためのBCです。

【図4.2.1a】SOAP BCの機能概要

図4.2.1aのように、NMRから送られてきたリクエストメッセージを外部のWebサービスに送信し、そのレスポンスを受信しNMRへ返却するプロバイダ機能と、外部のWebサービスクライアントからリクエストメッセージを受け取ってNMRに送信し、そのレスポンスを受信して外部のWebサービスクライアントへ返却するコンシューマ機能の2つあります。本書では前者をoutboundと呼び、また外部のWebサービスに対するクライアントとして振舞うためSOAPクライアント機能とも呼びます。後者をinboundと呼び、また外部からSOAPのリクエストを受け付けるためSOAPサーバ機能とも呼びます。

4.2.1.1. Outbound (SOAPクライアント機能)

Outbound(SOAPクライアント機能)は、NMRから渡ってきたメッセージエクスチェンジをSOAPメッセージに変換(デノーマライズ)し、外部のWebサービスをHTTP/SOAPで呼び出します。また、外部のWebサービスからの返却値を受け取って、そのSOAPメッセージをメッセージエクスチェンジに変換(ノーマライズ)し、NMRに渡します。

プロキシ

プロキシを介して外部のWebサービスアクセスすることができます。認証つきやSSL(HTTPS)のプロキシにも対応しています。

SSL(HTTPS)

外部のWebサービス(サーバ側)の証明書をドメインのキーストアに登録することで、外部のWebサービスとの間にSSL(HTTPS)を使用することができます。

4.2.1.2. Inbound (SOAPサーバ機能)

Inbound(SOAPサーバ機能)は、外部SOAPクライアントからのHTTP/SOAPリクエストを待ち受けます。SOAPメッセージを受信したら、メッセージエクスチェンジに変換(ノーマライズ)し、NMRへ送信します。返却値としてNMRから戻されたメッセージエクスチェンジをSOAPメッセージに変換(デノーマライズ)し、リクエスト元の外部SOAPクライアントに返します。

外部のSOAPクライアントからHTTP/SOAPリクエストを受け付ける仕組みは、図4.2.1bの通り、サーブレットでHTTPのリクエストを受け付け、受け付けたURL(サービスエンドポイントURL)とSOAPメッセージをSOAP BCに渡すようになっています。SOAP BCでは、受け取ったサービスエンドポイントURLをJBIコンテナ上のエンドポイントに1対1で対応させ、処理を行います。サーブレットは、あらかじめ用意されており、既定値ではエンドポイントの配備と同時に自動でサーブレットも配備されます。

【図4.2.1b】外部からのSOAPリクエストを受け付ける仕組み

SSL(HTTPS)

外部のSOAPクライアントとの間にSSL(HTTPS)を使用することができます。片方向認証の場合は、サービスエンドポイントURLをHTTPSにすることで利用できます。双方向認証の場合は、外部のSOAPクライアントの証明書をドメインのキーストアに登録することで利用できます。

Memo
外部のSOAPクライアントにも別途SSLの設定が必要です。

4.2.1.3. SOAPメッセージハンドラ機構

SOAPメッセージハンドラ機構は、SOAP BCに流れるSOAPメッセージに対して、ノーマライズの前、デノーマライズの後で、何らかの処理を行うための機構です。既定のインタフェースに従ったハンドラクラスを作成し、その中でSOAPメッセージを直接処理する実装を行い、ハンドラクラスをWebOTXに登録することで、利用できます。JAX-RPC、JAX-WS、Apache Axisなどのハンドラと似た仕組みを持っており、既存のハンドラ実装の活用も可能です。

【図4.2.1c】SOAPメッセージハンドラ機構

図4.2.1cは、SOAP BC内のSOAPメッセージハンドラ機構部分について示したものです。一つのハンドラクラスで、リクエスト、レスポンス、Faultの各メッセージについて処理をすることができます。

ノーマライズの際、SOAPメッセージハンドラ間で引き渡されてきたプロパティは、ノーマライズメッセージのプロパティに挿入され、内容がそのまま引き継がれます。同様に、デノーマライズの際、ノーマライズメッセージのプロパティをSOAPメッセージハンドラ間で引き渡すプロパティとして引き継がれます。これにより、SOAPメッセージハンドラで取得した認証情報や証明書などのセキュリティ情報、エンドポイントリファレンス、トランザクションコンテキストなどを、SOAP BC以外のJBIコンポーネントに伝播させることが可能です。

Memo
V7まで存在したメッセージエクスチェンジハンドラ機構は共通ハンドラに統合されました。

4.2.1.4. OAuth 連携

OAuth 1.0a仕様をベースとして定められたシステム間の認証方式であるxAuthを用いた認証を行うことが出来ます。
認証後は、xAuth認証プロトコルに従い、認証トークンを付加した外部Webサービスの呼び出しを行います。

4.2.2. JMS BC

JMS BCは、外部のJMSクライアントとの間でJMSメッセージを送受信するためのBCです。

【図4.2.2a】JMS BCの機能概要

図4.2.2aのように、NMRから送られてきたリクエストメッセージを外部のJMSクライアントに送信し、そのレスポンスメッセージを受信してNMRへ返却するプロバイダ機能と、外部のJMSクライアントからリクエストメッセージを受け取ってNMRに送信し、その応答メッセージがあれば外部のJMSクライアントへ返却するコンシューマ機能の2つがあります。本書では、前者をoutboundと呼び、後者をinboundと呼びます。

コネクションファクトリ

JMSでは、JMSサーバと接続するためにコネクションファクトリを使用します。JMS BCが利用するコネクションファクトリについて、そのJMSリソースをあらかじめ作成しておく必要があります。

WebOTX JMSの場合、SSLによるメッセージの暗号化などの各種拡張機能を利用することができます。必要に応じて、JMSリソースに設定してください。

エンドポイント定義では、JMSリソース作成時に指定したJNDI名を指定してください。

送信先

JMSでは、QueueやTopicといった送信先を介してメッセージの受け渡しを行います。JMS BCが利用する送信先について、物理的送信先と、そのJMSリソースをあらかじめ作成しておく必要があります。

WebOTX JMSの場合、最大メッセージ数の指定やフロー制御などの各種拡張機能を利用することができます。必要に応じて、物理的送信先に設定してください。

Outboundでは、リクエストメッセージを送信する送信先と、そのリプライメッセージを受信する応答用送信先が必要です。応答用送信先はエンドポイント単位に必要ですが、JMS BC共通となるデフォルトの応答用送信先を使用することもできます。

Inboundでは、リクエストメッセージを受信する送信先と、そのリプライメッセージを送信する応答用送信先が必要です。Inboundの場合は、リクエストメッセージのJMSReplyToに指定された応答用送信先を使用することもできます。

送信先タイプには、QueueとTopicとがありますが、応答用に使用できるのはQueueだけです。

エンドポイント定義では、JMSリソース作成時に指定したJNDI名を指定してください。

JMSメッセージ

JMSでは、5種類のメッセージタイプが規定されていますが、JMS BCで利用できるのは、TextMessageとBytesMessageの2つです。

TextMessageはXMLデータを格納します。

BytesMessageでは任意のバイナリデータをひとつのバイト配列として格納します。

エンドポイント定義では、オペレーションの入出力タイプとして選択することができます。

4.2.2.1. Outbound

Outboundでは、NMRから受け付けたメッセージエクスチェンジをJMSメッセージに変換(デノーマライズ)し、外部のJMSクライアントが待ち受ける送信先に送信します。また、外部のJMSクライアントから返却されたJMSメッセージは応答用送信先から受信し、メッセージエクスチェンジに変換(ノーマライズ)し、NMRに返却します。

4.2.2.2. Inbound

Inboundは、外部のJMSクライアントからのリクエストを待ち受けます。JMSメッセージを受信したら、メッセージエクスチェンジに変換(ノーマライズ)し、NMRに渡します。NMRから渡ってきたメッセージエクスチェンジをJMSメッセージに変換(デノーマライズ)し、外部のJMSクライアントに返します。

XAトランザクション

JMS BCでは、JMSとのメッセージ送受信において、2フェーズコミット(JTAのトランザクション制御)をサポートしています。これにより、ESBを介したJMSメッセージの送受信結果に一貫性を保障し、高い信頼性を提供します。

【図4.2.2b】XAトランザクションの概要

XAトランザクションを利用するには、リソースアダプタの定義が必要です。

Inboundの場合、In-Only、In-Out、Robust In-OnlyのMEPで利用することができます。リクエストメッセージを受信するとトランザクションを開始し、MEPシーケンスのinに対する結果に応じて、そのトランザクションを完了します。rollbackするとJMSメッセージは再配信されます。

MEP

動作

In-Only

doneを受信すると、トランザクションをcommitします。

Errorを受信すると、トランザクションをrollbackします。

Robust In-Only

doneもしくはFaultを受信すると、トランザクションをcommitします。

Errorを受信すると、トランザクションをrollbackします。

In-Out

outもしくはFaultを受信すると、トランザクションをcommitします。

Errorを受信すると、トランザクションをrollbackします。

※       ErrorだけでなくFaultの場合にもrollbackさせることが可能です。エンドポイント定義のオプションTransactionRollbackPolicyにfaultを指定してください。

※       MEPシーケンスがタイムアウトするとデフォルトではrollbackされますが、これをcommitさせ、In-Onlyであれば破棄に、In-Out、Robust In-Onlyであればエラー応答にすることが可能です。エンドポイント定義のオプションTransactionInboundTimeoutPolicyにcommitを指定してください。

※       Outbound側で発生したタイムアウト(相手JMSクライアントからの無応答など)は、Inbound側にはErrorとして返すためrollbackされます。これを、commitさせ、In-Onlyであれば破棄に、In-Out、Robust In-Onlyであればエラー応答にすることが可能です。エンドポイント定義のオプションTransactionOutboundTimeoutPolicyにcommitを指定してください。

Outboundの場合、In-OnlyのMEPで利用することができます。JMS BCでトランザクションを開始するのではなく、Inbound側のBCもしくはSEで開始されたトランザクションがメッセージエクスチェンジに格納されている場合に、そのトランザクションに参加します。Outbound側で送信したJMSメッセージは、Inbound側でトランザクションがcommitされると送信が完了し、rollbackされると送信が取り消されます。

MEP

動作

In-Only

inにトランザクションが格納されていると、トランザクションに参加します。

Inbound側にJMS BCのXAトランザクション対応のエンドポイントを配置すると、リクエストをInboundとOutboundとの間でメッセージを失うことなく、「少なくとも1回」Outbound側で処理させることができます。

さらに、Outbound側にもJMS BCのXAトランザクション対応のエンドポイントを配置することにより、「必ず1回」Outbound側で処理させる保障レベルを実現できます。

リソースアダプタ

リソースアダプタを利用することで、次のようなことが実現されます。

・メッセージ処理の多重化/同期化

・受信側JMSプロバイダとの自動再接続

・送信側JMSプロバイダとのコネクションプール管理

・分散トランザクションへの参加(Inboundメッセージ受信とOutboundメッセージ送信を2フェーズコミットメントで処理することが可能)

JMS BCでは、次の3つのリソースアダプタをサポートしています。

・WebOTX JMSと接続する場合に使用する既存JMSリソースアダプタ

・他社JMSプロバイダと接続する場合に使用する汎用JMSリソースアダプタ

・他社JMSプロバイダと接続する場合に使用する他社JMSリソースアダプタ

設定については、[ アプリケーション開発ガイド(Enterprise Service Bus) > 2. プログラミング・開発ガイド > 2.9. バインディングコンポーネントの定義 > 2.9.2. JMSバインディング > 2.9.2.2. エンドポイントの設定 ] や [ 2.9.2.12. JMSリソースアダプタの設定 ] をご覧ください。

JMS付加情報の伝播

JMS BCは、InboundとOutboundが共にJMS接続となる構成において、JMSヘッダやプロパティなどの付加情報を両者間で伝播する機能を提供します。デフォルトではメッセージボディのみが引き継がれます。

伝播の有無は、要求および応答ごとに指定することができます。

JMSヘッダについては各ヘッダ、プロパティについてはJMSベンダ固有プロパティおよびユーザプロパティごとに伝播の指定をすることが可能です。特定のプロパティのみの伝播は、対象外リストに目的のプロパティを指定することで実現できます。またプロパティの伝播を指定した場合でも、特定のプロパティのみ対象外とする機能もサポートしています。

伝播した値を固定の値で更新したい場合は更新リストを利用することで上書きできます。更新リストを指定すると、Outbound送信時およびInboud送信時にJMSヘッダやプロパティの値を更新できます。更新リストには、JMSヘッダおよびプロパティを指定することができます。

伝播の設定については、エンドポイントの「JMS付加情報の伝播」で指定してください。

設定については、[ アプリケーション開発ガイド(Enterprise Service Bus) > 2. プログラミング・開発ガイド > 2.9. バインディングコンポーネントの定義 > 2.9.2. JMSバインディング > 2.9.2.13. JMS付加情報の伝播設定 ] をご覧ください。

4.2.3. JCA BC

JCA BCは、既存JCAリソースアダプタを介してEISと連携するためのBCです。

【図4.2.3a】JCA BCの機能概要

図4.2.3aのように、NMRから送られてきたXML形式のデータをJCAのRecordに変換しリソースアダプタに投げ(out)、その返却Recordがある場合は受け取ってXML形式に変換しNMRに渡す(bound)という動作をする機能と、リソースアダプタからRecordを受け取ってXML形式に変換しNMRに投げ(in)、その返却値がある場合は受け取ってRecord変換しリソースアダプタに渡す(bound)という動作をする機能の2つがあります。本書では、前者は、NMRから見たメッセージの流れの方向がout→boundの順となっていることからOutboundと呼んでおり、後者は、NMRから見たメッセージの流れの方向がin→boundの順となっていることからInboundと呼んでいます。

4.2.3.1. Outbound

Outboundは、NMRから渡ってきたメッセージエクスチェンジ中の送信データをRecordに変換し、CCIインタフェースを使用してリソースアダプタを呼び出します。また、リソースアダプタからの返却Recordを受け取って、返却Record中の受信データをメッセージエクスチェンジに変換し、NMRに渡します。

4.2.3.2. Inbound

Inboundは、リソースアダプタからのRecordの受信を待ち受けます。Recordを受信したら、メッセージエクスチェンジに受信データを変換し、NMRに渡します。また、NMRから渡ってきたメッセージエクスチェンジ中の返却データをRecordに変換し、リソースアダプタに返します。

4.2.3.3. セキュリティ

JCAでは、EISとAPサーバ間のセキュリティ規約が規定されています。この規約により、リソースアダプタがEISへのセキュリティ保護されたアクセスを提供しています。このような背景から、JCA BC自体はセキュリティの機能を用意していません。EISへのセキュリティ保護されたアクセスについてはリソースアダプタの機能をご使用ください。

4.2.4. RMI BC

RMI BCは、EJBアプリケーションをサービスの1つとして利用するためのBCです。

【図4.2.4a】RMI BCの機能概要

RMI BCは、EJBのクライアント機能を提供します。図4.2.4aのように、NMRから送られてきたXML形式のデータを、Javaのクラスに変換してEJBアプリケーションを呼び出します。 EJBアプリケーションからの戻り値がある場合は、XML形式に変換してNMRへ返却します。

このような動作を、NMRから見たメッセージの流れの方向がout→boundの順となっていることからOutboundと呼び、またJBIコンテナの外部から見てメッセージを提供することから、プロバイダとも呼びます。

4.2.4.1. Outbound(EJBのクライアント機能)

RMI BCは、SOAPのRPC形式のメッセージを解釈し、EJB呼び出しに変換します。また、EJBアプリケーションからの戻り値を、SOAPのRPC形式のメッセージに変換します。

EJBの呼び出し制御

RMI BCでは、CORBAのDII(Dynamic Invocation Interface)という機能を利用してEJBアプリケーションの呼び出しを行います。このため、EJBアプリケーションのスタブクラスは不要です。ただし、EJBアプリケーションのオペレーションの引数や戻り値の型を判断するために、Remoteインタフェースクラスの情報を利用します。そのため、EJBアプリケーションのRemoteインタフェースクラスをクラスパスに追加する必要があります。

設定については、[ リファレンス集 運用管理・設定・構成編 > 1. コンフィグレーション > 1.3. バインディングコンポーネントに関する設定 > 1.3.4. RMI BC > 1.3.4.2. Remoteインタフェースクラスのクラスパスへの追加 ] をご覧ください。

RMI BCでは、作成する応答メッセージの情報を取り込むために、WSDLファイルを利用します。

設定については、[ アプリケーション開発ガイド(Enterprise Service Bus) > 2. プログラミング・開発ガイド > 2.9. バインディングコンポーネントの定義 > 2.9.4. RMIバインディング > 2.9.4.1. サービスユニットのファイル構成 ] の「WSDLファイルについて」をご覧ください。

ステートフルのEJBアプリケーションサポート

RMI BCでは、ステートを持つEJBアプリケーションであるStateful Session Beanにも対応しています。Stateful Session Beanをサービスとして利用する場合は、Sequencing SEのセッション管理機能を利用する必要があります。

Sequencing SEのセッション管理機能の利用については、[ アプリケーション開発ガイド(Enterprise Service Bus) > 2. プログラミング・開発ガイド > 2.9. バインディングコンポーネントの定義 > 2.9.4. RMIバインディング > 2.9.4.10. その他 ] の「ステートフルのEJBアプリケーションサポート」を参照してください。

4.2.4.2. セキュリティ

RMI BCでは、EJBアプリケーションの呼び出しの際に、ユーザ名およびパスワードを指定する機能を提供しています。そのほか、EJBアプリケーションの呼び出しでSSL通信を行う場合には、Object BrokerのSSL通信機能を利用してください。 また、エンドポイントのセキュリティ設定で「外部サービスの認証」を定義すると、コンシューマから伝播された認証情報を利用したシングルサインオンが可能です。

4.2.5. File BC

File BCはESBとローカルファイルシステム間の通信機能を提供するためのBCです。

【図4.2.5a】File BCの機能概要

図4.2.5aのように、NMRから受信したinメッセージを「出力ファイル格納ディレクトリ」にファイルとして出力し、「入力ファイル格納ディレクトリ」に入力ファイルがある場合そのファイルをoutメッセージとして受信しNMRへ返却するという動作をする機能と、「入力ファイル格納ディレクトリ」を監視して入力ファイルがあればそのファイルをinメッセージとしてNMRに送信し、その返却値がある場合は受け取って「出力ファイル格納ディレクトリ」にファイルとして出力するという動作をする機能の2つがあります。前者は、Outboundと呼んでおり、プロバイダとして動作します。後者は、Inboundと呼んでおり、コンシューマとして動作します。

4.2.5.1. Outbound(プロバイダ機能)

Outboundは、NMRから受信したメッセージをデノーマライズ処理によりファイル形式に変換し、ファイルを設定した出力ディレクトリ(ファイルシステム)に保存します。 またMEPがIn-Outの場合は、ファイル出力後にOutboundの入力用ディレクトリの監視を開始し、 ファイルがあれば取得してoutメッセージとしてNMRへ返却します。

4.2.5.2. Inbound(コンシューマ機能)

Inboundは、設定した入力ディレクトリ(ファイルシステム)のファイルを読み込んでノーマライズ処理を行い、メッセージをNMRに送信します。メッセージ交換方式をin-outに設定した場合は、NMRから受け取ったレスポンスのメッセージにデノーマライズ処理を行い、ファイルとして出力用ディレクトリに保存します。

4.2.5.3. 外部コマンド実行機能

出力先ディレクトリにファイルが出力される前後、また読み取り先ディレクトリからファイルを読み取る前後で、 予め登録されていたコマンドを実行できます。

4.2.5.4. 大容量ファイル処理機能

転送メッセージのサイズが大きい場合にメモリ不足でエラーが発生しないように、ファイル転送時にオンメモリ化せずストリーム転送とすることで大容量のメッセージ転送できます。また、メッセージサービスの設定で、転送スピード上限と転送スピード調整頻度を設定可能です。

Memo
大容量ファイル処理機能は対応BC同士でのみ有効になります。

4.2.5.5. 文字コード変換機能

File BCは入力/出力するファイルのエンコーディングを指定することによって、コード変換機能を提供しています。

4.2.5.6. 集配信履歴情報ログ出力

本機能はFile BCで処理したファイルの集配信履歴情報をログに出力する機能です。
詳細内容は[ 運用ガイド > 3.6. 集配信履歴情報ログ出力 ] を参照して下さい。

4.2.6. CORBA BC

CORBA BCは、CORBAアプリケーションをサービスの1つとして利用するためのBCです。

【図4.2.6a】CORBA BCの機能概要

CORBA BCは、CORBAのクライアント機能を提供します。図4.2.6aのように、NMRから送られてきたXML形式のデータを、Javaのクラスに変換してサーバアプリケーションを呼び出します。サーバアプリケーションからの戻り値がある場合は、XML形式に変換してNMRへ返却します。

このような動作を、NMRから見たメッセージの流れの方向がout→boundの順となっていることからOutboundと呼び、またJBIコンテナの外部から見てメッセージを提供することから、プロバイダとも呼びます。

4.2.6.1. Outbound(CORBAのクライアント機能)

CORBA BCは、SOAPのRPC形式のメッセージを解釈し、CORBA呼び出しに変換します。また、サーバアプリケーションからの戻り値を、SOAPのRPC形式のメッセージに変換します。

サーバアプリケーションの呼び出し制御

CORBA BCでは、サーバアプリケーションを呼び出すためにスタブクラスが必要です。

設定については、[ リファレンス集 運用管理・設定・構成編 > 1. コンフィグレーション > 1.3. バインディングコンポーネントに関する設定 > 1.3.6. CORBA BC > 1.3.6.2. スタブクラスのクラスパスへの追加 ] をご覧ください。

CORBA BCでは、作成する応答メッセージの情報を取り込むために、WSDLファイルを利用します。

設定については、[ アプリケーション開発ガイド(Enterprise Service Bus) > 2. プログラミング・開発ガイド > 2.9. バインディングコンポーネントの定義 > 2.9.6. CORBAバインディング > 2.9.6.1. サービスユニットのファイル構成 ] の「IDLファイルからWSDLファイル生成について」をご覧ください。

ステートフルのサーバアプリケーションサポート

CORBA BCでは、ステートを持つサーバアプリケーションにも対応しています。StatefulのWebOTX CORBAアプリケーションをサービスとして利用する場合は、Sequencing SEのセッション管理機能を利用する必要があります。具体的には、Sequencing SEのエンドポイントのサービス定義で、session-close-requiredにtrueを設定してください。

4.2.7. JDBC BC

JDBC BCは、JDBCドライバを介してデータベースへの接続機能を実現するためのBCです。

【図4.2.7a】JDBC BCの機能概要

図4.2.7aのように、NMRから送られてきたリクエストメッセージを基に外部のデータベースに対してSQL命令を発行し、その実行結果をNMRへ返却するプロバイダ機能と、外部のデータベースからのクエリ結果を変換したリクエストメッセージをNMRに送信し、そのレスポンスを受信してレコードの更新を行うコンシューマ機能の2つがあります。本書では前者をoutboundと呼び、後者をinboundと呼びます。

4.2.7.1. Outbound

OutboundのSQL命令発行機能では、NMRから受信したデータを元に作成したSQL命令(select/insert/delete/update)およびストアドプロシージャを実行します。

4.2.7.2. Inbound

Inboundのクエリ機能では、クエリ(select)を実行して得られたデータを元に作成したメッセージをNMRに送信した上で取得したデータレコードを更新あるいは移動、削除します。

4.2.7.3. 使用するSQL命令の種類

Consumer

Consumerでは、クエリ(select命令)を実行してデータを取得します。実行するselect命令は、次の2通りの方法で指定することができます。

Artifactに両方が指定されている場合には、SQL命令(select)のコマンドイメージが使用されます。

また、取得したデータレコードは、次のいずれかの方法で再取得しないようにすることができます。

Provider

Providerで使用できるSQL命令は、「select」、「insert」、「update」、「delete」とストアドプロシージャです。実行するSQL命令のコマンドイメージをArtifactに指定します。そのSQL命令のコマンドイメージと、NMRから受信したメッセージ中の値からSQL命令を生成し、実行します。

4.2.7.4. トランザクション制御機能

Inbound処理

Inbound処理におけるトランザクション制御について説明します。Artifactに「トランザクション制御が必要」と指定されている場合にトランザクション制御を行います。

トランザクション制御機能では、データベースの一貫性保障などによる信頼性向上やJMS BCのトランザクション制御との連携を実現しています。

制御

JDBC BCの動作

開始

トランザクションの開始は、監視対象テーブルに対する送信対象レコードの検出処理の中で行います。トランザクションの開始位置をレコード検出用のSQL命令を発行する前とするか後とするかは、Artifactの「トランザクション開始位置」で指定します。

一時停止

送信対象レコードが検出された場合、送信するMessageExchangeはNMRを介して他のBC/SEへと送信され、同じトランザクションの中でOutbound処理を行うことができるように、NMRへの送信前にトランザクションを一時停止し、そのトランザクションをMessageExchangeのプロパティとして登録しておきます。

プロパティ名:javax.jbi.transaction.jta

再開

NMRから対象レコードの送信結果(done/error/fault)を受け、MessageExchangeのプロパティに登録されているトランザクションを取得し、そのトランザクションを再開します。送信結果がdoneの場合のみ、送信対象となったレコードの更新または削除処理を行います。

完了

レコードの送信結果および再開後の処理結果に従ってトランザクションを完了(rollback/commit)させます。

Outbound処理

Outbound処理におけるトランザクション制御について説明します。Outboundのトランザクションへの参加は、MessageExchangeのプロパティからトランザクションを取得できた場合に行います。Outboundでトランザクションを開始することはありません。

制御

JDBC BCの動作

再開

MessageExchangeのプロパティに登録されているトランザクションを再開します。その後、受信したメッセージから値を取得してSQL命令を作成後、発行します。

一時停止

SQL命令を発行後、MessageExchangeのプロパティに登録されているトランザクションを一時停止して、結果(done)をNMRへ送信します。

4.2.8. FTP BC

FTP BCはFTPプロトコルによりESBとFTPサーバの間の通信機能を提供するためのBCです。

【図4.2.8a】FTP BCの機能概要

図4.2.8aのように、NMRから受信したinメッセージを出力先FTPサーバのディレクトリにファイルとして出力し、外部からメッセージの返却がある場合はその返却メッセージをoutメッセージとして受信しNMRへ返却するという動作をする機能と、FTPサーバのディレクトリを監視してファイルが入力ディレクトリにアップロードされるとそのファイルをinメッセージとして受信してNMRへ送信し、その返却値がある場合は受け取ってFTPサーバの出力ディレクトリにアップロードするという動作をする機能の2つがあります。

前者は、Outboundと呼んでおり、プロバイダとして動作します。後者は、Inboundと呼んでおり、コンシューマとして動作します。プロバイダとコンシューマのいずれの場合においても、FTP BCはFTPクライアントとして動作します。

4.2.8.1. Outbound(プロバイダ機能)

OutboundはNMRからinメッセージを受信すると、メッセージの内容をFTPサーバの出力用ディレクトリにファイルを出力します。またMEPがIn-Outの場合は、ファイル出力後にFTPサーバの入力用ディレクトリの監視を開始し、ファイルがあれば取得してoutメッセージとしてNMRへ返却します。

SSL(FTPS)

外部のFTPサーバ側の証明書をドメインのキーストアに登録することで、外部のFTPサーバとの間にSSL(FTPS)を使用することができます。

4.2.8.2. Inbound(コンシューマ機能)

InboundはFTPクライアントとして動作します。指定したFTP上のディレクトリに対して一定間隔でのポーリングを行い、指定したファイル名のパターンにマッチするファイルがあれば取得します。また、MEPがIn-Outの場合はNMRからのレスポンスメッセージを指定したFTP上のディレクトリにファイルとして出力します。

SSL(FTPS)

外部のFTPサーバとの間にSSL(FTPS)を使用することができます。片方向認証の場合はFTPアドレスをFTPSにすることで利用できます。双方向認証の場合は外部のFTPサーバの証明書をドメインのキーストアに登録することで利用できます。

4.2.8.3. FTP送受信の前後処理

FTPサーバ上のファイルの送受信操作を実行する前後に、以下の操作を指定することが可能です。

送信前・受信前

送信後・受信後

4.2.8.4. 文字コード変換機能

FTP BCは入力/出力するファイルデータの文字エンコーディングを変換する機能を提供しています。異なる文字エンコーディングを利用するシステム間を連携することが可能です。

4.2.8.5. 大容量ファイル処理機能

転送メッセージのサイズが大きい場合にメモリ不足でエラーが発生しないように、ファイル転送時にオンメモリ化せずストリーム転送とすることで大容量のメッセージ転送できます。また、メッセージサービスの設定で、転送スピード上限と転送スピード調整頻度を設定可能です。

Memo
大容量ファイル処理機能は対応BC同士でのみ有効になります。

4.2.8.6. ファイル一時退避機能

FTP BCはFTPサーバにあるファイルを取得した後、自動的に一定期間退避する機能を提供しています。保持期間は管理ツールにより設定可能で、既定値は10日です。1回目のローテートはSU起動当日の24:00に実行し、その後、指定した日数毎に実行します。

4.2.8.7. ダイレクト転送機能

ESBを経由せず、メッセージをFTPサーバ間で直接転送する機能です。送受信ともFTP BCはFTPの制御情報のみを中継し、メッセージはESBを経由しないため、ESBサーバ上のメッセージ配送のための処理コストを大幅に軽減することができます。

Memo
ダイレクト転送機能はFTP BC同士でのみ利用できます。

4.2.8.8. 集配信履歴情報ログ出力

本機能はFTP BCで処理したファイルの集配信履歴情報をログに出力する機能です。
詳細内容は[ 運用ガイド > 3.6.集配信履歴情報ログ出力 ]を参照して下さい。

4.2.9. HTTP BC

HTTP BCは、外部のWebサーバ、またはWebクライアントとHTTPメッセージを送受信するためのBCです。

【図4.2.9a】HTTP BCの機能概要

図4.2.9aのように、NMRから送られてきたリクエストメッセージを外部のWebサーバに送信し、そのレスポンスを受信しNMRへ返却するプロバイダ機能と、外部のWebクライアントからリクエストメッセージを受け取ってNMRに送信し、そのレスポンスを受信してWebブラウザなどのWebクライアントへ返却するコンシューマ機能の2つがあります。本書では前者をoutboundと呼び、また外部のWebサーバに対するクライアントとして振舞うためHTTPクライアント機能とも呼びます。後者をinboundと呼び、また外部からHTTPのリクエストを受け付けるためHTTPサーバ機能とも呼びます。

4.2.9.1. Outbound(HTTPクライアント機能)

Outbound(HTTPクライアント機能)は、NMRから受信したメッセージをHTTPメッセージに変換(デノーマライズ)し、外部のWebサーバへ送信します。また、外部のWebサーバからのレスポンスを受け取って、そのHTTPメッセージをメッセージ変換(ノーマライズ)してNMRに返却します。

4.2.9.2. プロキシ

プロキシを介して外部のWebサーバにアクセスすることができます。認証つきやSSL(HTTPS)のプロキシにも対応しています。

4.2.9.3. SSL(HTTPS)

外部のWebサーバとの間にSSL(HTTPS)を使用することができます。

4.2.9.4. 文字コード変換

リクエスト時に外部のWebサーバへ送信するHTTPリクエストの文字コードを変換して送信することができます。また、外部のWebサーバから受信するHTTPレスポンスの文字コードをチェックすることができます。

4.2.9.5. Inbound(HTTPサーバ機能)

Inbound(HTTPサーバ機能)は、Webブラウザなどの外部HTTPクライアントからのHTTPリクエストを待ち受けます。HTTPメッセージを受信したら、メッセージエクスチェンジに変換(ノーマライズ)し、NMRへ送信します。NMRから戻されたメッセージをHTTPメッセージに変換(デノーマライズ)し、リクエスト元の外部HTTPクライアントに返します。

外部のHTTPクライアントからHTTPリクエストを受け付ける仕組みは、図4.2.9bの通り、サーブレットでHTTPのリクエストを受け付け、受け付けたURLとHTTPメッセージをHTTP BCに渡すようになっています。HTTP BCでは、サービスエンドポイントURLをJBIコンテナ上のエンドポイントに1対1で対応させ、受け付けたURLをエンドポイントのオペレーションに1対1で対応させ、処理を行います。

【図4.2.9b】外部からのHTTPリクエストを受け付ける仕組み

Memo
サービスエンドポイントURLは受け付けたURLからオペレーション名を除いたものです。

Memo
汎用サービスエンドポイントで受け付けるサーブレットは提供されています。Webコンテナに配備して使用してください。

4.2.9.6. SSL(HTTPS)

外部のHTTPクライアントとの間に、片方向認証/双方向認証でのSSL(HTTPS)を使用することができます。

4.2.9.7. 文字コード変換

外部のHTTPクライアント受信するHTTPリクエストの文字コードをチェックすることができます。また、レスポンス時には外部のWebクライアントへ送信するHTTPレスポンスのエンコードを変換して送信します。

4.2.9.8. OAuth連携

OAuth 1.0a仕様をベースとして定められたシステム間の認証方式であるxAuthを用いた認証を行うことが出来ます。
認証後は、xAuth認証プロトコルに従い、認証トークンを付加した外部Webサーバの呼び出しを行います。

4.2.10. TCP/IP BC

TCP/IP BCは、 独自プロトコルを使用しているシステムとの接続性を高めるため、また、性能にシビアなシステムでメッセージ転送性能を極限まで高めるために、 従来のBCからプロトコル処理を省きユーザが自由にプロトコル処理を組み込むことができるコンポーネントです。 TCP/IP BCはソケットを開き、任意のプロトコルで送受信可能なBCです。

【図4.2.10-1】TCP/IP BCの機能概要

図4.2.10-1のように、NMRから送られてきたリクエストメッセージを外部サーバアプリケーションに送信し、そのレスポンスを受信しNMRへ返却するプロバイダ機能と、外部クライアントアプリケーションからリクエストメッセージを受け取ってNMRに送信し、そのレスポンスを受信してクライアントアプリケーションへ返却するコンシューマ機能の2つがあります。本書では前者をOutboundと呼び、後者をInboundと呼びます。

4.2.10.1. Outbound

Outboundは、NMRから受信したメッセージを、TCP/IPハンドラのsendメソッドにより変換(デノーマライズ)し、指定したホストおよびポートの外部サーバアプリケーションへ送信します。また、外部サーバアプリケーションからのレスポンスを受け取って、そのメッセージをTCP/IPハンドラのreceiveメソッドにより変換(ノーマライズ)してNMRに返却します。

4.2.10.2. Inbound

Inboundは、起動すると指定したポートで待ち受けを開始し、クライアントアプリケーションから接続を受けると、受信したメッセージをTCP/IPハンドラのreceiveにより変換(ノーマライズ)し、NMRへ送信します。また、NMRからレスポンスを受け取って、そのメッセージをTCP/IPハンドラのsendメソッドにより変換(デノーマライズ)してクライアントアプリケーションに返却します。また返却後TCPコネクションは切断しないため1つのTCPコネクションで複数のメッセージを連続して処理することができます。

4.2.10.3. プロトコルハンドラ機能

ユーザはTCP/IP BCで通信するメッセージのプロトコル処理をTCP/IPハンドラとして実装し組み込みます。 独自のプロトコルを組み込むことであらゆるプロトコルに対応できる他、汎用のプロトコルよりも高い性能を実現可能です。

4.2.10.4. コネクションプーリング機能

Outboundは外部サーバアプリケーションとのTCPコネクションをキープし、TCPコネクションをプール管理する機能を持ちます。 これによりTCPコネクション確立のコストの低減と一時ポート枯渇を防ぎます。

またオプションでコネクションチェック機能をもち、定期的に巡回して廃れたコネクションを廃棄してリソースの節約することも可能です。

4.2.11. Salesforce BC

Salesforce BCは、SOAPメッセージを用いてSalesforce.comと連携するためのBCです。

【図4.2.11a】Salesforce BCの機能概要

図4.2.11aのように、NMRから送られてきたリクエストメッセージをSalesforce.comに送信し、そのレスポンスを受信しNMRへ返却するプロバイダ機能と、Salesforce.comからリクエストメッセージを受け取ってNMRに送信し、そのレスポンスを受信してSalesforce.comへ返却するコンシューマ機能の2つがあります。本書では前者をoutboundと呼び、またSalesforce.comに対するクライアントとして振舞うためSOAPクライアント機能とも呼びます。後者をinboundと呼び、またSalelsforce.comからのリクエストを受け付けるためWebサービス機能とも呼びます。

4.2.11.1. Outbound(SOAPクライアント機能)

Outbound(SOAPクライアント機能)は、NMRから受信したメッセージをSOAPメッセージに変換(デノーマライズ)し、Salesforce.comへ送信します。また、Salesforce.comからのレスポンスを受け取って、そのSOAPメッセージを変換(ノーマライズ)してNMRに返却します。

4.2.11.2. プロキシ

プロキシを介してSalesforce.comにアクセスすることができます。認証つきやSSL(HTTPS)のプロキシにも対応しています。

4.2.11.3. SSL(HTTPS)

Salesforceとの間にSSL(HTTPS)を使用することができます。

Memo
SSL(HTTPS)を使用してSalesforce.comにアクセスするためには、VeriSignからルート証明書を入手する必要があります。導入に際してはルート証明書の有効期限にご注意ください。

4.2.11.4. SOAPメッセージ要素の簡易操作

Salesforce BCではメッセージにWS APIのオペレーションを設定できます。この設定によってオペレーション要素をSOAPボディに組み込むことができます。

4.2.11.5. セッション更新

Salesforce BCでは、管理しているセッションの有効期限が切れないように自動的に更新します。

4.2.11.6. 自動再接続

Salesforce.comへ接続できない時、自動的に再度ログインできます。

4.2.11.7. Inbound(Webサービス機能)

Inbound(Webサービス機能)は、Salesforce.comからのSOAPメッセージを待ち受けます。SOAPメッセージを受信したら、変換(ノーマライズ)し、NMRへ送信します。NMRから戻されたメッセージによってACKをSalesforce.comに返します。

Salesforce.comからSOAPメッセージを受け付ける仕組みは、図4.2.10bの通り、サーブレットでHTTPのリクエストを受け付け、受け付けたURLとSOAPメッセージをSalesforce BCに渡すようになっています。Salesforce BCでは、サービスエンドポイントURLをJBIコンテナ上のエンドポイントに1対1で対応させ、受け付けたURLをエンドポイントのオペレーションに1対1で対応させ、処理を行います。

【図4.2.10b】外部からのSOAPリクエストを受け付ける仕組み

Memo
サービスエンドポイントURLは受け付けたURLからオペレーション名を除いたものです。

Memo
汎用サービスエンドポイントで受け付けるサーブレットは提供されています。Webコンテナに配備して使用してください。

4.2.11.8. SSL(HTTPS)

Salesforce.comとの間に、片方向認証/双方向認証でのSSL(HTTPS)を使用することができます。

Memo
Salesforce.comからクライアント証明書を入手してください。

4.2.11.9. 組織認証

Salesforce.comからの要求がSalesforce.comで設定したユーザの組織からのものである場合にのみ、メッセージを受信することができます。

4.2.12. HL7 BC

HL7 BC は、 医療系システムにおける国際規約であるHL7によるメッセージ転送の機能を提供するBCです。

【図4.2.12-1】HL7 BCの機能概要

図4.2.12-1のように、NMRから送られてきたリクエストメッセージを外部サーバアプリケーションに送信し、そのレスポンスを受信しNMRへ返却するプロバイダ機能と、外部クライアントアプリケーションからリクエストメッセージを受け取ってNMRに送信し、そのレスポンスを受信してクライアントアプリケーションへ返却するコンシューマ機能の2つがあります。本書では前者をOutboundと呼び、後者をInboundと呼びます。

4.2.12.1. Outbound

Outboundは、NMRから受信したノーマライズメッセージをHL7メッセージに変換(デノーマライズ)し、下位層プロトコル(LLP)により処理したメッセージを指定したホストおよびポートの外部サーバアプリケーションへ送信します。また、外部サーバアプリケーションからのレスポンスを受け取って、LLPに従ってそのメッセージからHL7メッセージを抽出し、ノーマライズメッセージに変換(ノーマライズ)してNMRに返却します。

4.2.12.2. Inbound

Inboundは、起動すると指定したポートで待ち受けを開始し、外部クライアントアプリケーションから接続を受けると、LLPに従って受信したメッセージからHL7メッセージを抽出し、ノーマライズメッセージに変換(ノーマライズ)してNMRへ送信します。また、NMRからレスポンスのノーマライズメッセージを受け取って、そのメッセージをHL7メッセージに変換(デノーマライズ)して、LLPにより処理したメッセージを外部クライアントアプリケーションに返却します。また返却後TCPコネクションは切断しないため1つのTCPコネクションで複数のメッセージを連続して処理することができます。

4.2.12.3. メッセージ変換

InboundとOutboundで入力/出力するメッセージのフォーマットをER7形式とXML形式に変換できます。
入出力メッセージの変換パターンは以下の4パターンです。

・ER7形式 → XML形式
・XML形式 → ER7形式
・ER7形式 → ER7形式
・XML形式 → XML形式

4.2.12.4. 固定応答機能

HL7クライアントが応答メッセージを必要とするにも関わらず、外部サーバアプリケーションが応答メッセージを返却しない場合に、ESBが要求メッセージに応じた固定の応答メッセージを外部サーバアプリケーションに代わってクライアントに返信する機能です。

4.2.12.5. シーケンス番号プロトコル

HL7のシーケンス番号プロトコルに対応し、HL7 BCでシーケンス番号の管理ができます。 シーケンス番号プロトコルを使用することにより、トランザクションの重複を防ぐ事ができます。

4.2.12.6. MLLPハンドラ

HL7 BCでは、デフォルトのLLPとしてMLLP v1.0をサポートし、MLLP v1.0のメッセージ送受信を実装したMLLPハンドラを提供しています。 MLLPハンドラでのメッセージ受信時は、外部アプリケーションからMLLPベースのメッセージを受け取り、 スタートブロック・エンドブロック等の制御文字を除去してHL7メッセージを抽出します。 また、メッセージ送信時は、HL7メッセージにスタートブロック・エンドブロック等の制御文字を付与して外部アプリケーションにメッセージを送信します。

4.2.12.7. コネクションプーリング

Outboundは外部サーバアプリケーションとのTCPコネクションをキープし、TCPコネクションをプール管理する機能を持ちます。 これによりTCPコネクション確立のコストの低減と一時ポート枯渇を防ぎます。

4.3. サービスエンジン

4.3.1. XSLT SE

XSLT SEは、NMRから受信したXMLデータを変換するためのSEです。

【図4.3.1a】XSLT SEの機能概要

4.3.1.1. メッセージ変換機能

XSL Transformations (XSLT)Version 1.0に準拠したXSL変換機能を提供します。NMRから受け取ったメッセージを指定のXSLTファイルまたはXSLファイルによってXSL変換を行います。

4.3.2. Sequencing SE

Sequencing SEは、あるサービスから受け取ったメッセージを使って、サービスを(Sequencing SEに)設定した順番で呼び出します。メッセージハンドラ機構を使うと、メッセージの内容によって呼び出すサービスを自由に切り替えることができます。また、最初から最後まで完全に同期で構成されたシーケンスではない場合、シーケンスの途中で発生したFaultメッセージをFault処理用のサービスを呼び出して処理する機構があります。

【図4.3.2a】ハンドラ機構やFault処理機能を使ったシーケンシングパターンの例

ハンドラ定義

Sequencing SEから利用するJavaで実装したハンドラを定義することができます。

メッセージの加工処理やルーティング制御処理を記述することができます。

メッセージエクスチェンジのプロパティを利用し、Sequencing SEのメッセージコンバートハンドラやメッセージエクスチェンジハンドラ間で情報を共有することができます。

Memo
インタフェースは [リファレンス集 開発編(Enterprise Service Bus) > 1. APIリファレンス] を参照してください。

4.3.2.1. 異常処理

呼び出し先のサービスからエラー/フォルトが返却された場合の動作を制御することができます。

処理を打ち切り、受け取ったエラー/フォルトをコンシューマに返却することや処理を継続させることができます。

4.3.2.2. セッション機能

Sequencing SEはサービスリストの実行時に全ての発信メッセージSESSION-IDを付加して、サービスリストを完了する際に、<session-close-required>サービスに対してセッションクローズメッセージを発信します。各コンポーネントはセッションクローズメッセージを受け取ったタイミングでEJBのremove()やCORBAのReleaseServerObject()など呼び出すことにより状態管理を行えます。

4.3.2.3. ブロードキャスト

同一のメッセージを複数の送信先へ同時に送信することができます。

ブロードキャストの送信先を複数のサービスとハンドラに指定できます。メッセージを同時にすべてのブロードキャストの送信先へ送信した後、<waiting-response>によりすべての応答を待つか、応答を待たないか決定します。

4.3.2.4. 繰り返し

同じメッセージを同じ送信先に繰り返し送信することができます。次回の送信は前回の応答を待ってから行われます。

一つのinメッセージに複数の情報が含まれている場合、ハンドラなどと組み合わせてinメッセージを分割して、同一のシステムへの複数回の呼び出しに利用することができます。

繰り返しの終了条件は下記のいずれかです。
    ・設定した回数を超える
    ・サービスからのMessageExchangeにプロパティESB_SEQ_REPEAT_FINISHがtrueに設定される
    ・サービスからError/Faultを受信するとき、フォルト処理が定義していないあるいは一致するフォルト処理を見つけられない(呼び出し元にError/Faultを転送しサービスリスト終了)
    ・フォルト処理の呼び出しにError/Faultを受信(呼び出し元にError/Faultを転送しサービスリスト終了)
    ・フォルト処理の呼び出しにDone/outを受信、且つフォルト処理の次の処理でREPEAT以外を指定

4.3.2.5. 入出力メッセージの保持

呼び出し元からのinメッセージと送信先からの応答メッセージの両方をSequencing SEに保持することができます。呼び出し元からのinメッセージを<list-inName>で指定した名前とし、送信先からの応答メッセージを<outName>で指定した名前としてSequencing SEに保持します。繰り返し機能を利用する場合、応答メッセージは「<outName>で指定した名前+何回目送信(1...n)」の名前で保持します。

Sequencing SEに保持しているメッセージは以下のパターンで利用できます。
    ・呼び出し元へのMessageExchangeに、どのメッセージをoutメッセージとして扱うか<list-outName>で指定できます。
    ・送信先へのMessageExchangeに、どのメッセージをinメッセージとして扱うか<inName>で指定できます。
    ・送信先へのMessageExchangeに、どのメッセージを保持メッセージとして扱うか<retention-names>で指定できます。
    ・Fault処理用のサービスへのMessageExchangeに、どのメッセージをinメッセージとして扱うか<name>で指定できます。

<retention-names>でMessageExchangeに保持しているメッセージは以下のパターンで利用できます。
    ・ユーザが実装するSequenceHandler初期化パラメータから"ESB_SEQSE_RETAINED_MESSAGES"をキーとして取得できます。
    ・ユーザが実装するMessageExchangeHandlerのhandleInMessageメソッドを呼び出し前にinitメソッドの初期化パラメータから"ESB_SEQSE_RETAINED_MESSAGES"をキーとして取得できます。
    ・ユーザが実装するUserProcessor SEプロセッサでMessageExchangeのgetMessage(メッセージ名前)を呼び出して取得できます。

4.3.2.6. 即時返信

呼び出し元からのinメッセージに対して送信先の応答メッセージを待たせずに、呼び出し元へ即時に応答を返すことができます。

MEPはIn-onlyに限定して、固定的にdoneメッセージを返答します。

4.3.3. CBR SE

CBR SEは、NMRから入力されたメッセージの内容により宛先を決定し、メッセージをそのまま次のエンドポイントへ転送します。宛先BC/SEから返却されたメッセージはそのまま呼び出し側へ返却されます。

【図4.3.3a】CBR動作イメージ

Memo
CBRは「コンテンツベースルーティング」の略称です。

4.3.3.1. ルーティング定義

CBR SEではXPathとJavaScriptのDOM APIによりNormalizedMessageに格納されているXMLメッセージを参照します。XML形式ではないNormalizedMessageの内容やattachmentの内容は参照できません。

4.3.4. UserProcessor SE

UserProcessor SEは、インタフェースをユーザが任意に実装することにより、自由にカスタマイズをすることができるSEです。ESBに流れるメッセージを加工したり、記録したりすることが可能です。

【図4.3.4a】UserProcessor SEの機能概要

図4.3.4aのように、NMRから受信したリクエストメッセージをユーザの実装したロジックにより処理され、結果をNMRへ返信します。UserProcessor SEはプロバイダとして動作します。

4.3.4.1. ユーザ実装

ユーザはUserProcessor SEへ組み込むため、UserProcessor SEで規定するインタフェースを実装します。JBI仕様よりもインタフェースが簡潔となっており、最低1クラスからの開発で動作させることができます。
また、フォルトメッセージ生成用に一部実装されたFaultProcessorクラスを提供しており、ユーザはFaultProcessorを継承したクラスを実装するだけで、ESB内でフォルトを返却させることができます。

Memo
インタフェースは [リファレンス集 開発編(Enterprise Service Bus) > 1. APIリファレンス] を参照してください。

4.3.4.2. 組込み定義プロセッサ

組込み定義プロセッサとして、以下のProcessorを標準で用意しています。

- Font Avenue UniAssist コード変換

Font Avenue UniAssistコード変換は、Unicode(UTF-8/16/32)とG2000/JIPS(E)/JIPS(J)/Shift_JIS/JIS/JEF+EBCDIK/JEF+EBCDIC/KEISとの相互変換機能を提供します。またユーザが外部変換テーブルを用意するとユーザ独自の定義で変換を行うことができます。

UniAssistのProcessorを利用すると、パラメータを指定するだけで、WebOTX ESBからFont Avenue UniAssist コード変換を利用することができます。また、必要に応じて外部変換テーブルファイルを指定したコード変換も可能です。

- EDIトランスレータ

EDIトランスレータは、XMLと非XMLなどのデータフォーマット相互変換機能を提供します。

EDIトランスレータのProcessorを利用すると、パラメータ、EDIトランスレータの処理設定ファイル、EDIトランスレータの実行ディレクトリを指定ることで、WebOTX ESBからEDIトランスレータを利用することができます。