概念とアーキテクチャ
|
 |
 |
|
AquaLogic Service Bus では、メッセージの処理方法を決定する際に、リソースおよびサービスに関するユーザ コンフィグレーション メタデータに依存します。このトピックは、SOA においてメッセージ ブローカをコンフィグレーションする IT スペシャリストを対象としています。
この節では、AquaLogic Service Bus のリソースおよびサービスについて説明します。また、AquaLogic Service Bus ドキュメント セット内の詳細情報へのリンクを提供します。
AquaLogic Service Bus のリソースとは、再利用可能なエンティティ定義またはエンティティ記述であり、通常はそれらのエンティティのメタデータが含まれています。リソースは複数のサービスで使用可能で、企業や部署全体で使用できるように標準化された定義または記述を持ちます。AquaLogic Service Bus のリソースの例として、次のものがあります。
AquaLogic Service Bus のリソースおよびサービスを一連の「プロジェクト」としてまとめることができ、各プロジェクトはフォルダ構造を持ちます。リソースおよびサービスをプロジェクトにまとめることで、名前の衝突を回避できるほか、部署などのビジネス カテゴリごとにリソースおよびサービスをまとめたり検索したりするのに便利です。
また、AquaLogic Service Bus には、一連の変更を長期間保持できる「セッション」があり、デプロイメントの更新バッチとして送信されるまでそれらの変更を非公開にしておくことができます。複数のセッションをアクティブにすることができます。セッションではオプティミスティック ロックが使用されているため、衝突が発生する可能性があります。セッションを正常に送信するには、これらの衝突を解決する必要があります。
スキーマとは、基本データや構造化データのタイプを表すものです。XML スキーマは、XML ビジネス データが従う必要のあるルールを表す XML ボキャブラリです。XML スキーマは、ドキュメントの構造、およびドキュメントに含まれる各要素と属性のデータ型を指定します。XML スキーマには、他の XML スキーマをインポートまたは含めることができます。AquaLogic Service Bus Console を使用してスキーマを作成する方法については、『AquaLogic Service Bus Console の使い方』の「XML スキーマ」で「XML スキーマの追加」を参照してください。
AquaLogic Service Bus では、メッセージ フォーマット言語 (MFL) というメタデータ言語を使用して、型付きの非 XML データの構造を記述します。BEA Format Builder ツールを使用すると、MFL ドキュメントと呼ばれるデータ ファイルとしてメタデータを作成および管理できます。MFL ドキュメントの作成方法については、Format Builder のオンライン ヘルプを参照してください。
トランスフォーメーション マップには 2 つのデータ型の間のマッピングが記述されます。AquaLogic Service Bus は、XQuery または eXtensible Stylesheet Language Transformation (XSLT) 標準のどちらかを使用したデータ マッピングに対応しています。また、MFL で記述されたデータは自動的に同等の XML に変換され、XQuery または XSLT でのトランスフォーメーションで使用できます。ターゲット サービスで必要な場合、結果の XML は自動的に MFL に変換されます。
条件付きルーティングおよびトランスフォーメーションでは、コンテンツ ベースのルーティングがサポートされます。このため、AquaLogic Service Bus は、まったく異なるサービス エンドポイント間を仲介し、高度なルーティングを実行できます。このようにして、SOA エンドポイントの疎結合が実現します。コンテンツ ベース ルーティングがよく使用されるのは、さまざまなバージョンのサービスを使用可能にする必要がある場合です。次の図では、プロキシ サービスのルート ノードでのコンテンツ ベース ルーティングにより、2 つのバージョンの getCustomerCredit サービスを仲介しています。
図 2-1 AquaLogic Service Bus でのコンテンツ ベース ルーティング
AquaLogic Service Bus を使用すると、トランスフォーメーションとルーティングの機能を組み合わせてサービスを充実させることができます。ここでは、前の図に示した getCustomerCredit サービスの使用方法から展開して、プロキシ サービスでトランスフォーメーションと条件付きルーティングの機能を組み合わせて、サービスの内容を充実させサービスを再利用しやすくするシナリオを説明します。この例のシナリオでは、2 つのサービスそれぞれ (getCustInfo および getCustAddress) にサービス コールアウトが行われ、コールアウトの結果がプロキシ サービスによって結合されます。前の図でコンフィグレーションされていたのと同じコンテンツ ベース ルーティングが、getCustomerCredit サービスにコンフィグレーションされています。
図 2-2 AquaLogic Service Bus でのサービスの充実
BEA XQuery Mapper を使用して AquaLogic Service Bus XQuery を作成する方法については、『XQuery Mapper を使用したデータの変換』を参照してください。
WSDL (Web Service Definition Language) インタフェースは、SOAP サービスまたは XML サービスのサービス インタフェースを定義します。WSDL には、インタフェース内のオペレーションを含むサービスの抽象インタフェース、およびオペレーションのシグネチャのメッセージ部の型が記述されます。また、メッセージ部のメッセージへのバインディング (パッケージング)、およびメッセージの転送へのバインディングを記述できます。さらに、WSDL では、サービスの具象インタフェース (たとえば、転送 URL) を記述することもできます。
AquaLogic Service Bus Console を使用して WSDL をコンフィグレーションする方法については、『AquaLogic Service Bus Console の使い方』の「WSDL」で「WSDL の追加」を参照してください。
WS-Policy にはセキュリティ ポリシーが記述されます。メッセージのどの部分を署名および暗号化するか、およびどのセキュリティ アルゴリズムを適用するかが記述されます。また、メッセージ受信時に使用する認証メカニズムも記述されます。
ポリシーは URI によって参照されます。URI は、WSDL の埋め込み、HTTP URI、ポリシー URI (たとえば policy:myPolicy) のいずれかです。ポリシー URI では組み込まれたポリシーを参照できます。
WS-Policy の詳細については、BEA AquaLogic Service Bus の『ユーザーズ ガイド』の「着信メッセージおよび発信メッセージの保護」にある「Web サービス ポリシー」を参照してください。
プロキシ サービス、およびプロキシ サービスから呼び出されるビジネス サービスのいずれもサービスとして扱われることは、AquaLogic Service Bus の基本的な概念です。
AquaLogic Service Bus では、SOAP ベースおよび XML ベースの Web サービスおよびメッセージング サービスをサポートしています。また、具象インタフェースとサービス タイプのみが定義される SOAP サービスおよび XML サービスにも対応しています。
SOAP ベースのサービスへのメッセージは、SOAP エンベロープでラッピングされた、XML を含む SOAP メッセージです。XML ベースのサービスへのメッセージは XML ですが、プロキシ サービス コンフィグレーションで許可されているタイプを使用できます。メッセージング サービス (メッセージング サービス タイプとして作成されたビジネス サービスまたはプロキシ サービス) へのメッセージは、タイプが異なることも可能です。メッセージング サービスで、まったく異なるコンテンツタイプのメッセージを交換することができます。このようなメッセージ交換は、要求/応答または一方向にすることができます。Web サービスとは異なり、要求と応答のコンテンツ タイプは同じでなくてもかまいません。メッセージング ベースのサービスには WSDL 定義はありません。このサービス タイプの詳細については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」を参照してください。
以下の 3 つのサービス タイプについて AquaLogic Service Bus がサポートするカテゴリを示します。
AquaLogic Service Bus では、HTTP と JMS の非同期転送プロトコルの双方向 (要求と応答) および一方向のパラダイムがサポートされます。基底の転送が順序付きメッセージ配信に対応している場合、AquaLogic Service Bus でも同様に対応できます。
AquaLogic Service Bus では、以下の転送プロトコルがサポートされます。
AquaLogic Service Bus Console を使用してプロキシ サービス用の転送をコンフィグレーションする方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」で「プロキシ サービスの追加」を参照してください。AquaLogic Service Bus Console を使用してビジネス サービス用の転送をコンフィグレーションする方法については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」で「ビジネス サービスの追加」を参照してください。
AquaLogic Service Bus は、Web サービスの正式な記述の部分では WSDL に依存します。Web サービスの場合、WSDL には Web サービスのインタフェース、場所、および呼び出し方法が記述されます。AquaLogic Service Bus では WSDL に関する以下の 2 つの性質を考慮して、プロキシ サービスおよびビジネス サービスが定義されます。
AquaLogic Service Bus Console を使用して、WSDL を WSDL リポジトリにインポートします。また、すべてのスキーマおよび WSDL が正しくリンクされるように、AquaLogic Service Bus Console を使用して WSDL 内の参照を解決します。リポジトリに格納された WSDL は、新しくプロキシ サービスおよびビジネス サービスを追加するときに使用できます。メッセージング サービスの場合、AquaLogic Service Bus 独自のインタフェース表現が使用されます。
AquaLogic Service Bus Console を使用して WSDL をインポートおよび解決する方法については、『AquaLogic Service Bus Console の使い方』の「WSDL」で「WSDL の追加」を参照してください。
プロキシ サービスは、AquaLogic Service Bus のローカルにホストされた仲介 Web サービスの AquaLogic Service Bus での定義です。プロキシ サービスは、インタフェース、メッセージ フロー、ポリシーの観点で定義します。プロキシ サービスに資格レベルの検証が必要な場合は、AquaLogic Service Bus Console で、そのプロキシ サービスのセキュリティ資格を管理する「プロキシ サービス プロバイダ」を作成できます。
AquaLogic Service Bus Console を使用してプロキシ サービスをコンフィグレーションする方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」で「プロキシ サービスの追加」を参照してください。AquaLogic Service Bus Console を使用してプロキシ サービス プロバイダをコンフィグレーションする方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス プロバイダ」で「プロキシ サービス プロバイダの追加」を参照してください。
以下の節では、プロキシ サービスの構造および定義に関する主要な概念を説明します。
プロキシ サービスによって送受信されるすべてのメッセージは、プロキシ サービスの内部で一連のプロパティによって定義されます。これらのプロパティは、メッセージ データや、そのメッセージに関連するメタデータを保持しています。この一連のプロパティは、メッセージ コンテキスト (コンテキスト) と呼ばれ、コンテキスト変数を使用して実装されます。メッセージ コンテキストは XML スキーマによって定義されます。コンテキスト変数はそれぞれ個別のプロパティに関連しており、事前定義されているものと、ユーザが定義するものがあります。プロキシ サービスの中核となるのが「メッセージ コンテキスト」です。メッセージ コンテキストやメッセージ フローで使用されるコンテキスト変数の詳細については、『AquaLogic Service Bus Consoleの使い方』の「メッセージ コンテキスト」を参照してください。
あらかじめ定義された変数には、メッセージに関する情報、転送ヘッダ、セキュリティ プリンシパル、現在のプロキシ サービスのメタデータ、およびプロキシ サービスから呼び出されるプライマリ ルーティング サービスとパブリッシュ サービスのメタデータが含まれます。通常は、XQuery 式を使用して、メッセージ フローのコンテキスト変数を操作します。トランスフォーメーションや同位置更新アクションを使用して変更することもできます。
メッセージ関連のコンテキスト変数である $header、$body、および $attachments は、メッセージ フロー内のメッセージの標準形式を表します。これらは SOAP ヘッダ要素、SOAP 本体要素、および MIME 添付を含むラッパー変数です。コンテキストによって、すべてのメッセージが SOAP メッセージであり、非 SOAP メッセージがこのパラダイムにマップされるように見えます。次の表に、メッセージ タイプごとのマッピングを示します。
添付ファイルの場合、$attachments には、添付ファイルごとに以下のものが含まれます。
プロキシ サービスの実装は、「メッセージ フロー」定義によって指定されます。メッセージ フローは、プロキシ サービスでのメッセージの流れを定義します。メッセージ フローの構成要素は 4 つあります。これらの構成要素は以下のとおりです。
これらの要素を任意で組み合わせてツリー構造を形成します。開始ノードは常に (必ず) ツリーのルートに配置し、ルート ノードは必ずリーフ部分に配置します。要求メッセージは開始ノードから始まり、要求パイプラインのアクションを実行しながらリーフまでの経路を辿ります。リーフがルート ノードの場合、応答が生成されます。一方向のサービスの場合は空の応答になることがあります。リーフがエコー ノードの場合、要求そのものが応答として扱われます。応答では、ブランチ ノードのアクションをスキップしながらツリーの経路を逆に辿ります。ただし、応答パイプラインのアクションは実行されます。インタフェースまたはオペレーションが要求/応答であれば、最後にツリーの一番上から応答が送信されます。それ以外の場合、応答は破棄されます。
ルート ノードの仕様は非常に柔軟性に富んでいます。if 構造と case 構造を結合 (およびネスト) することができ、メッセージをルーティングするための単一のエンドポイントおよびオペレーションを定義できます。ルート ノードのコンフィグレーション方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」で「ルート ノードの追加」を参照してください。
コンテキスト変数に影響する一連のトランスフォーメーションは、選択したエンドポイントへのメッセージの送信前、または応答の受信後に定義できます。XQuery または XSLT トランスフォーメーションの代わりに Web サービス コールアウトを使用して、コンテキスト変数を設定できます。AquaLogic Service Bus のトランスフォーメーション マップをコンフィグレーションする方法については、『XQuery Mapper を使用したデータの変換』を参照してください。
WS-Security の処理および許可は、開始ノードで透過的に実行されます。WS-Security の処理は、WS-Policy を持つビジネス サービスが呼び出されるときに透過的に実行されます。AquaLogic Service Bus のセキュリティをコンフィグレーションする方法については、BEA AquaLogic Service Bus の『ユーザーズ ガイド』の「着信メッセージおよび発信メッセージの保護」を参照してください。
パイプライン ペア、ステージ、およびアクションの詳細については、「メッセージ フローの定義」を参照してください。
一般的なメッセージ フローの例については、「オペレーション パイプライン」の図 1-11 を参照してください。
メッセージ フローの詳細については、BEA AquaLogic Service Bus の『ユーザーズ ガイド』の「AquaLogic Service Bus でのメッセージ フローの作成」を参照してください。
AquaLogic Service Bus には、設計時に使用できるタイプ システムが組み込まれています。条件、同位置更新アクション、またはトランスフォーメーションのそれぞれについて XQuery 式を作成するとき、エディタで変数の型を任意に宣言できるため、XQuery の作成が容易になります。使用できる型は以下のとおりです。
各ステージは、ステージでエラーが発生した場合に実行される一連の手順を持つことができます。この一連の手順がそのステージのエラー パイプラインを構成しています。また、エラー パイプラインは、パイプライン (要求または応答) またはプロキシ サービス全体に対して定義することができます。最も小さいスコープで指定されたエラー パイプラインがエラー時に呼び出されます。
図 2-3 ステージ、ノード、およびサービスレベルのエラー ハンドラ
このエラー パイプラインによってエラーを処理できる方法は以下のとおりです。
ビジネス サービスは、メッセージの交換先となるエンタープライズ サービスの AquaLogic Service Bus での定義です。ビジネス サービスの定義はプロキシ サービスと似ていますが、パイプラインを持ちません。ビジネス サービスへの接続時に AquaLogic Service Bus の認証が必要な場合は、AquaLogic Service Bus Console を使用して「サービス アカウント」を作成できます。サービス アカウントは、必要なユーザ名/パスワードのペアのエリアス リソースとして機能します。詳細については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」および「サービス アカウント」を参照してください。
ビジネス サービスで資格レベルの検証が必要な場合は、WebLogic Server を直接使用してセキュリティの資格を管理する必要があります。ビジネス サービスのセキュリティに関する考慮事項の詳細については、BEA AquaLogic Service Bus の『ユーザーズ ガイド』の「着信メッセージおよび発信メッセージの保護」を参照してください。
|
|
|
