概念とアーキテクチャ
|
 |
 |
|
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 のオンライン ヘルプの「リソース ブラウザ」で「新しいスキーマの追加」を参照してください。
BEA 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 のトランスフォーメーション マップをコンフィグレーションする方法については、「XQuery Mapper を使用したデータの変換」を参照してください。
WSDL (Web Service Definition Language) インタフェースは、SOAP サービスまたは XML サービスのサービス インタフェースを定義します。WSDL には、インタフェース内のオペレーションを含むサービスの抽象インタフェース、およびオペレーションのシグネチャのメッセージ部の型が記述されます。また、メッセージ部のメッセージへのバインディング (パッケージング)、およびメッセージの転送へのバインディングを記述できます。さらに、WSDL では、サービスの具象インタフェース (たとえば、転送 URL) を記述することもできます。
AquaLogic Service Bus Console を使用して WSDL をコンフィグレーションする方法については、AquaLogic Service Bus Console のオンライン ヘルプの「リソース ブラウザ」で「新しい WSDL の追加」を参照してください。
WS-Policy にはセキュリティ ポリシーが記述されます。メッセージのどの部分を署名および暗号化するか、およびどのセキュリティ アルゴリズムを適用するかが記述されます。また、メッセージ受信時に使用する認証メカニズムも記述されます。必要に応じて、ポリシーを WSDL に埋め込むこともできます。
WS-Policy の詳細については、『BEA AquaLogic Service Bus ユーザーズ ガイド』の「着信メッセージおよび発信メッセージの保護」で「Web サービス ポリシー」を参照してください。
プロキシ サービス、およびプロキシ サービスから呼び出されるビジネス サービスのいずれもサービスとして扱われることは、AquaLogic Service Bus の基本的な概念です。
AquaLogic Service Bus では、SOAP ベースおよび XML ベースの Web サービス、メッセージング サービス、および抽象定義で指定可能なサービスをサポートしています。また、具象インタフェースとサービス タイプのみが定義される SOAP サービスおよび XML サービスにも対応しています。
以下の 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 は、サービスの正式な記述の部分では 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 の追加」を参照してください。
プロキシ サービスは、AquaLogic Service Bus のローカルにホストされた仲介 Web サービスの AquaLogic Service Bus での定義です。プロキシ サービスは、WSDL、パイプライン、ポリシーの観点で定義します。プロキシ サービスに資格レベルの検証が必要な場合は、AquaLogic Service Bus Console で、そのプロキシ サービスのセキュリティ資格を管理する「プロキシ サービス プロバイダ」を作成できます。
AquaLogic Service Bus Console を使用してプロキシ サービスをコンフィグレーションする方法については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「プロキシ サービスの追加」を参照してください。AquaLogic Service Bus Console を使用してプロキシ サービス プロバイダをコンフィグレーションする方法については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス プロバイダ」で「プロキシ サービス プロバイダの追加」を参照してください。
以下の節では、プロキシ サービスの構造および定義に関する主要な概念を説明します。
プロキシ サービスの中核となるのが「コンテキスト」です。コンテキストは、要求フローと応答フローで共有される一連の XML 変数です。コンテキストでの変数の追加および削除は動的に行えます。あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、転送ヘッダ、セキュリティ プリンシパル、現在のプロキシ サービスのメタデータ、およびプロキシ サービスから呼び出されるプライマリ ルーティング サービスとパブリッシュ サービスのメタデータが含まれます。コンテキストの読み込みおよび変更は 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-4 を参照してください。
AquaLogic Service Bus には、設計時に使用できるタイプ システムが組み込まれています。条件、同位置更新アクション、またはトランスフォーメーションのそれぞれについて XQuery 式を作成するとき、エディタ側では変数の型を任意に宣言しておくことができるため、XQuery の作成が容易になります。使用できる型は以下のとおりです。
各ステージは、ステージでエラーが発生した場合に実行される一連の手順を持つことができます。この一連の手順がそのステージのエラー パイプラインを構成しています。また、エラー パイプラインは、パイプライン (要求または応答) またはプロキシ サービス全体に対して定義することができます。最も小さいスコープで指定されたエラー パイプラインがエラー時に呼び出されます。このエラー パイプラインによってエラーを処理できる方法は以下のとおりです。
ビジネス サービスは、メッセージの交換先となるエンタープライズ サービスの AquaLogic Service Bus での定義です。ビジネス サービスの定義はプロキシ サービスと似ていますが、パイプラインを持ちません。ビジネス サービスへの接続時に AquaLogic Service Bus の認証が必要な場合は、AquaLogic Service Bus Console を使用して「サービス アカウント」を作成できます。サービス アカウントは、必要なユーザ名/パスワードのペアのエリアス リソースとして機能します。詳細については、AquaLogic Service Bus Console のオンライン ヘルプで「ビジネス サービス」および「サービス アカウント」を参照してください。
ビジネス サービスで資格レベルの検証が必要な場合は、WebLogic Server を直接使用してセキュリティの資格を管理する必要があります。ビジネス サービスのセキュリティに関する考慮事項の詳細については、『BEA AquaLogic Service Bus ユーザーズ ガイド』の「着信メッセージおよび発信メッセージの保護」を参照してください。
|
|
|