JP2007514990A

JP2007514990A - サービス指向アーキテクチャにおいてサービス要求を処理するための方法および装置

Info

Publication number: JP2007514990A
Application number: JP2006534749A
Authority: JP
Inventors: ジョセフ、ジョシー
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-10-14
Filing date: 2004-10-05
Publication date: 2007-06-07
Also published as: CN1867898A; WO2005041035A1; TW200517917A; US20050080930A1; EP1683013A1

Abstract

【課題】サービス指向アーキテクチャにおいて、既存のプロトコルの待ち時間問題を最小限にするような形でサービス要求および応答を処理するための方法および装置を提供すること。
【解決手段】累積したクライアントサービス要求は、要求の実行順序を指定するワークフロー情報と共に単一のメッセージにパッケージングされ、これがネットワーク接続のサーバ側に伝送される。ネットワーク接続のサーバ側では、個々の要求がワークフロー情報と共にメッセージから抽出され、所期のサービス・プロバイダにルーティングされ、ここでワークフロー情報によって指定された順序で実行される。サービス要求に対する応答は、同様に戻りメッセージにパッケージングされ、これがクライアント側に返送されて、ここで応答がメッセージから抽出され、発信元クライアントにルーティングされる。
【選択図】図５

Description

本発明は、サービス指向アーキテクチャにおいてサービス要求を処理するための方法および装置に関する。とりわけ本発明は、こうした要求を一括（ｂａｔｃｈ）するため、ならびに、サービス指向アーキテクチャにおいてこうした一括された要求を順次および並列に実行するための、方法および装置に関する。

本明細書では、以下の出版物を参照とする（カッコ内の番号を使用）。
１．２００１年３月１５日、Ｗ３Ｃ覚書「Ｗｅｂサービス記述言語（ＷＳＤＬ）１．１」
２．２００３年３月、ウェリ・ヴァーリ等による「ＷｅｂＳｐｈｅｒｅバージョン５、Ｗｅｂサービス・ハンドブック」ＩＢＭＲｅｄｂｏｏｋ、ＳＧ２４−６８９１−００
３．２００２年６月２６日、Ｗ３Ｃワーキング・ドラフト「ＳＯＡＰバージョン１．２パート０：入門」
４．２００２年６月２６日、Ｗ３Ｃワーキング・ドラフト「ＳＯＡＰバージョン１．２パート１：メッセージング・フレームワーク」
５．２００２年６月２６日、Ｗ３Ｃワーキング・ドラフト「ＳＯＡＰバージョン１．２パート２：付属」
６．２００３年３月、アーロン・スコナードによる「ＳＯＡＰについて」、ＭＳＤＮライブラリ
７．２０００年１０月６日、Ｗ３Ｃ勧告「拡張可能マークアップ言語（ＸＭＬ）１．０（第２版）」
８．２００３年１月１４日、ピーター・フリン（編集）による「ＸＭＬＦＡＱバージョン３．０１」
９．２００３年８月２８日出版、ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ「ＪａｖａＡＰＩｆｏｒＸＭＬ−ＢａｓｅｄＲＰＣ（ＪＡＸ−ＲＰＣ）」
１０．２００２年６月２２日、イアン・フォスター等による「グリッドの生理：分散システム統合のためのオープン・グリッド・サービス・アーキテクチャ」
１１．２００２年７月１７日、スティーブ・テュエッケ等による「グリッド・サービスの仕様」第３稿
１２．２０００年１２月１１日、Ｗ３Ｃ覚書「添付ファイル付きＳＯＡＰメッセージ」

ここ数年の情報技術の分野におけるさらに重要なイベントの１つが、Ｗｅｂサービスおよびその近い親類であるグリッド・サービスの仕様およびインプリメンテーションの開発である。参照文献［２］の７ページに記載されるように、「Ｗｅｂサービスは、ネットワークを介した記述、公表、配置、および呼出しが可能な、自己完結型のモジュラ・アプリケーションである。Ｗｅｂサービスは、単一の要求応答から完全なビジネス・プロセス対話にまで及ぶ、カプセル化ビジネス機能を実行する。」Ｗｅｂサービスは、Ｗｅｂサービス記述言語（ＷＳＤＬ）［１］などの標準仕様で体系化されている。グリッド・サービス［１０、１１］は、クライアントがグリッド・サービスと対話する方法を定義する規約セット（インターフェースおよび動作）に準拠するＷｅｂサービスとして定義されている。グリッド・サービスは、実際にリモートに配置された使用可能コンピューティング・リソース（アプリケーション、プロセッサなど）がユーザに対するローカル・リソースとして現われる、仮想組織（ＶＯ）を作成するために使用されている。

Ｗｅｂサービスのようなサービス指向アーキテクチャでは、サービス・プロバイダは、サービスにアクセスするためのバインディングに使用されるいくつかのトランスポート・プロトコルを提供することができる。これは、クライアントにより良いサービス品質（ＱＯＳ）機能を提供するために実行される。相互運用性に関する要件に基づいて、ほとんどのサービス指向アーキテクチャは、構造化メッセージを交換するための軽量プロトコルとしてシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）［３、４、５、６］を使用する。これは、ビルディング・ブロックとして拡張可能マークアップ言語（ＸＭＬ）［７、８］を使用する単純かつ拡張可能なモデルである。これはその単なる応用例ではないが、ＳＯＡＰはしばしば、リモート・プロシージャ・コール（ＲＰＣ）の要求および応答（まとめて「要求／応答」）を伝送するための手段として使用される。

ＳＯＡＰをメッセージ交換メカニズムとして使用することの主な問題点の１つは、その性能の低さである。ＳＯＡＰプロトコルおよびその処理エンジンの性能問題を解決するために、バイナリＸＭＬ処理、ＸＭＬプロセッサ改良（たとえばプル・パーサ）、プリコンパイル済みメッセージング・フレームワークなどを含む、多数の提案がある。本発明は、ＳＯＡＰメッセージング・アーキテクチャのサービス要求プロセスにおける待ち時間増加の問題に対処する。このサービス呼び出しに関連する待ち時間の増加は、ＳＯＡＰＲＰＣ固有の性質に拠るものである。通常は、サービス要求が呼び出されると必ず、メッセージがフォーマット化され、ＳＯＡＰ本体でバンドルされて、ワイヤを横切ってサーバに渡される。従来から、リモートＲＰＣが呼び出されるのと同様に、一度に１つのサービスに対処するためにＳＯＡＰプロセッサが作成される。これにより、ＲＰＣ呼び出しの細分性（いくつかの小規模な呼び出しまたは１つの大規模な呼び出しを実行する）によって、分散アーキテクチャにおける待ち時間が増加することになる。
２００１年３月１５日、Ｗ３Ｃ覚書「Ｗｅｂサービス記述言語（ＷＳＤＬ）１．１」２００３年３月、ウェリ・ヴァーリ等による「ＷｅｂＳｐｈｅｒｅバージョン５、Ｗｅｂサービス・ハンドブック」ＩＢＭＲｅｄｂｏｏｋ、ＳＧ２４−６８９１−００２００２年６月２６日、Ｗ３Ｃワーキング・ドラフト「ＳＯＡＰバージョン１．２パート０：入門」２００２年６月２６日、Ｗ３Ｃワーキング・ドラフト「ＳＯＡＰバージョン１．２パート１：メッセージング・フレームワーク」２００２年６月２６日、Ｗ３Ｃワーキング・ドラフト「ＳＯＡＰバージョン１．２パート２：付属」２００３年３月、アーロン・スコナードによる「ＳＯＡＰについて」、ＭＳＤＮライブラリ２０００年１０月６日、Ｗ３Ｃ勧告「拡張可能マークアップ言語（ＸＭＬ）１．０（第２版）」２００３年１月１４日、ピーター・フリン（編集）による「ＸＭＬＦＡＱバージョン３．０１」２００３年８月２８日出版、ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ「ＸＭＬベースＲＰＣのためのＪａｖａＡＰＩ（ＪＡＸ−ＲＰＣ）」２００２年６月２２日、イアン・フォスター等による「グリッドの生理：分散システム統合のためのオープン・グリッド・サービス・アーキテクチャ」２００２年７月１７日、スティーブ・テュエッケ等による「グリッド・サービスの仕様」第３稿２０００年１２月１１日、Ｗ３Ｃ覚書「添付ファイル付きＳＯＡＰメッセージ」

したがって、インターネット規模のシステム、大規模なワイド・エリア・ネットワーク、およびグリッドを取り扱う場合の問題点の１つは、サービス呼び出しに関連付けられた待ち時間の増加に対処することである。サービス呼び出しの細分性に関して、賢明な決定（すなわち、より多くの数のより小規模な呼び出しを実行するか、またはより少ない数の大規模な呼び出しを実行するか）を下さなければならない。しかしながらほとんどの分散システムは、（少なくともＲＰＣＡＰＩレベルでは）この機能を考慮せずに設計されている。ＳＯＡＰプロトコルでは、ＳＯＡＰが一度に１つのサービスを呼び出す単純なＲＰＣ呼び出しメカニズムとしてモデル化されている場合と同様の、待ち時間の問題に直面する。これは、データまたはジョブのセットが単一のプログラム実行中に処理される、分散システムに関する呼び出し一括要件には対処していない。

一般に、本発明は、既存のプロトコルの待ち時間問題を最小限にするような形で、サービス指向アーキテクチャにおいてサービスの要求および応答（まとめて、「要求／応答」）を処理するための方法および装置に関する。累積したクライアントサービス要求は単一のメッセージにパッケージングされ、これがネットワーク接続のサーバ側に伝送される。ネットワーク接続のサーバ側では、個々の要求がメッセージから抽出され、所期のサービス・プロバイダにルーティングされる。サービス要求に対する応答は、同様に戻りメッセージにパッケージングされ、これがクライアント側に返送されて、ここで応答がメッセージから抽出され、発信元クライアントにルーティングされる。好ましい実施形態では、個々の要求／応答は、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）メッセージへの添付ファイルとして搬送される。さらに好ましくは、各メッセージは要求だけでなく、要求が実行される順番を指定するワークフロー情報（たとえば、所与の要求が並列に実行可能であるか、または順次実行しなければならないか）も含む。このワークフロー情報は、たとえばクライアント・エンドとの追加の双方向（ｒｏｕｎｄ−ｔｒｉｐ）通信を必要とせずに、新しい要求の実行を開始することができるように、サーバ・エンドで要求を実行する順序を制御するために使用される。

本発明は、サービス指向アーキテクチャにおける待ち時間増加の問題に対処する。好ましい実施形態では、通信パスの各エンドで通信パスの他方のエンドに伝送するために要求または応答を一括し、通信パスの他方のエンドから受信した要求または応答を抽出する、クライアントおよびサーバでのサービス要求の一括および分離フレームワークを企図する。さらに、本発明の好ましい実施形態は、ワークフロー情報を（サービス呼び出しプロファイルとして）サーバに渡すことによって、呼び出し実行プロセスでのワークフロー定義を企図する。（本明細書では、「ワークフロー情報」は、たとえば要求２は要求１の後に実行される、要求３は要求２と並列に実行できるなど、要求の実行順序を指定する情報を意味する。）最終的に、すべての個々の呼び出しセマンティクスを保持しながら、［１２］（以下、「添付ファイル仕様付きＳＯＡＰ」）で定義され、図４に示されたような、ＳＯＡＰメッセージ交換のためのワイヤ・メッセージ・フォーマット（すなわち、バイト文字列とみなされるメッセージの実際の物理構造）を企図する。（「呼び出しセマンティクス」と言う用語には、ワークフロー情報だけでなく、メッセージ呼び出しのセキュリティ、トランザクション要件、ルーティング、アドレス指定、および他の面に関する情報も含まれる。）

このフレームワークは、いくつかの想定を考慮して定義される。第１に、ほとんどのサービスは、多くの単一の呼び出しではなく１つの要求呼び出しに好適な集合ビジネス論理を利用して定義されることはない、あるいは定義することはできない、またはその両方である。第２に、クライアントからサーバへのビジネス論理ワークフローを構成するサービス呼び出しのバッチの動きにより、高性能となる。第３にクライアントは、呼び出しを一括し、正しいワークフロー・プロセス（会話プロセス）を選択するだけの十分な知性を備える。

本発明を使用すると、低速のＳＯＡＰＲＰＣプロトコルを介して要求呼び出しを一括することによって、分散システムでの待ち時間問題が軽減される。これは、クライアントが、ビジネス論理の並列および順次実行を含み、サーバ側で一連の要求を実行することの可能な、ワークフロー・メカニズムを提供するものである。セキュリティ、相関、およびトランザクション要件などの、すべての要求呼び出しセマンティクスを維持する。クライアントは、クライアント側ＡＰＩ（ＪＡＸ−ＲＰＣと同様）によって定義されるのと同じプログラミング・パターンに従うことが可能であり、インフラストラクチャはほとんどの複雑性に対処する。このフレームワークは、既存のインフラストラクチャに対する透過性を提供し、クライアントによって要求されたとおりのフォーマットで結果を提供する。これにより、同期または非同期の呼び出しをサポートすることができる。最終的に、障害をクライアントに返送するか、または、あるサービス呼び出しでの障害が他のサービス呼び出しに影響を与える可能性があるワークフロー定義を使用することによって複雑なシナリオをサポートすることができる、単純な呼び出しストラテジに基づいて、障害を処理することができる。

本発明は、好ましくはソフトウェアでインプリメントされるが、ハードウェア、ソフトウェア、またはこの２つの何らかの組み合わせでインプリメントすることも可能である。ソフトウェアでインプリメントされる場合、定義された方法ステップを実行するためにマシンによって実行可能な命令のプログラムを明白に具体化する、マシンによる読み取りか可能なプログラム・ストレージ・デバイス（磁気または光ディスク、あるいは半導体メモリ）の形を取ることができる。

次に、本発明の諸実施形態について、以下の図面を参照しながら単なる例として説明する。

本発明は、要求を一括することにより、サービス呼び出しに関連付けられた待ち時間の増加により良く対処するための、サービス指向アーキテクチャにおけるクライアントおよびサーバ向けのサービス要求一括フレームワークを企図する。このフレームワークは、クライアント側のアプリケーション・プログラミング・インターフェース（ＡＰＩ）と、呼び出しを一括するためのクライアント側の要求一括エンジンを提供する。サーバ側のフレームワークは、サービス要求の分解、識別、マッピング、およびディスパッチのための機構を提供する。このフレームワークは、サービス・バインディングのためのトランスポート・メッセージング・プロトコルとして、ＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）を使用する。クライアントの基本設定あるいはポリシーまたはその両方に基づいてサービス呼び出しの順次および並列の実行を管理するためのワークフロー・プロセスも、企図される。

図１は、一括なしの従来のＳＯＡＰＲＰＣインプリメンテーションにおける、クライアント−サーバ対話を示す図である。図に示されるように、クライアント１０２は、ＳＯＡＰ／ＨＴＴＰプロトコル（すなわち、ＨＴＴＰトランスポート・バインディングを使用するＳＯＡＰメッセージ・プロトコル）を使用して、インターネットなどのネットワーク１０６を介してサービス・プロバイダ（または単に「サービス」）１０４と対話する。この従来のインプリメンテーションでは、クライアント１０２は各呼び出しについて１つのメッセージを送信することにより、サービス・プロバイダ１０４へのリモート・プロシージャ・コール（ＲＰＣ）を実行する。同様の形でサービス・プロバイダ１０４は、各応答について１つのメッセージをクライアント１０２に返送することにより、これらの呼び出しに応答する。ＲＰＣは同期または非同期のいずれかとすることができる。同期呼び出しは、前の呼び出しへの応答が実行されるまで待機しなければならない。これに対して非同期呼び出しは、前の呼び出しへの応答を待つことなく実行することができる。このシナリオでは、同期呼び出しは重複が不可能であるため、伝送プロトコルに何らかのかなりの待ち時間が存在する場合、相当な性能上の損失が生じる可能性がある。

図２は、要求一括を伴う本発明のＳＯＡＰＲＰＣインプリメンテーションにおけるクライアント−サーバ対話を示す図である。このインプリメンテーションでは、クライアント１０２はネットワーク１０６を介してサービス・プロバイダ１０４へのリモート・プロシージャ・コール（ＲＰＣ）を実行し、サービス・プロバイダ１０４は前の場合と同様に呼び出しに応答する。しかしながら、各呼び出しについて１つのメッセージを送信する代わりに、クライアント１０２は呼び出しを累積し、累積された呼び出しを含む単一のメッセージを送信する。同様の形でサービス・プロバイダ１０４は、各応答について１つのメッセージをクライアント１０２に返送する代わりに応答を累積し、累積された応答を含む単一のメッセージを送信する。図１のシナリオと同様に、ＲＰＣは同期または非同期のいずれかとすることができる。しかしながらここでは以下で説明するように、クライアント１０２は、要求自体と共にサービス・プロバイダ１０２に送信されるワークフロー情報を伴う、様々な要求の実行に必要な任意の順序を指定することができる。

図１および２のどちらでも、クライアント１０２は、別々に示されていないクライアント・マシン上の複数のこうしたクライアント（または「サービス要求者」）のうちの１つとすることができる。同様にサービス・プロバイダ１０４は、サーバ・マシン（または「サーバ」）上の複数のこうしたサービス・プロバイダのうちの１つとすることができる。本明細書に記載されている場合を除き、クライアント１０２およびサービス・プロバイダ１０４の詳細なオペレーションは本発明のいかなる部分をも形成するものではないため、図示していない。同様に、クライアント１０２およびサービス・プロバイダ１０４が常駐するマシンの詳細なオペレーションも、本発明のいかなる部分をも形成するものではないため、これらのマシンは別々に図示していない。同様に、本明細書に記載されたプロトコルをサポート可能であることは別として、ネットワーク１０６の詳細なオペレーションも本発明のいかなる部分をも形成するものではないため説明していない。

図３は、従来のＳＯＡＰインプリメンテーションにおけるＳＯＡＰメッセージ３００のデータ・フォーマットを示す図である。図示されたメッセージ３００は要求メッセージであるが、応答メッセージも同様にフォーマット化されることになる。図を参照すると、ＳＯＡＰメッセージ３００は、ヘッダ３０４およびボディ３０６を含むエンベロープ３０２からなる。ヘッダ３０４およびボディ３０６はそれぞれ、エンベロープ３０２のようにＸＭＬタグのそれぞれのペアで区切られる。ヘッダ３０４はオプションであり、ヘッダ・ブロックに編成された様々なタイプの制御情報を含むことができる。これに対して、ボディ３０６は必須であり、たとえば図に示された単一ＲＰＣメソッド呼び出しなどの実際のエンド・ツー・エンド・メッセージを含む。

図３は、ＳＯＡＰメッセージ３００の論理構造を示す。ＨＴＴＰ要求に埋め込まれたＳＯＡＰ要求メッセージ３００の実際のＸＭＬフォーマットは、［２］から選んだ以下の例のようになる場合がある。

この例では、標準ＨＴＴＰヘッダ（１〜５行目）がＳＯＡＰサーバのＵＲＬを含み、この場合は/www.messages.com/servlet/rpcrouterである。このＵＲＬに関して、Ｗｅｂサービスはurn:NextMessageによって識別される。ＨＴＴＰヘッダの次に、伝送されるメッセージを含むＳＯＡＰエンベロープ３０２（６〜１５行目）が続く。この特定の例では、ＳＯＡＰエンベロープ３０２はボディ３０６（８〜１４行目）を含むが、ヘッダ３０４は含まない。ここでメソッド呼び出しは、ＳＯＡＰサーバに常駐するurn:Nextmessageと呼ばれるＷｅｂサービスのメソッドgetMessage(UserID, Password)への呼び出しのＳＯＡＰＲＰＣ表現である。１０行目のhttp://schemas.xmlsoap.org/soap/encoding/は、クライアント側およびサーバ側の両方でプログラミング言語からＸＭＬへ、およびその逆に、パラメータ値を変換する際に使用されるエンコード方式を指定する。

図４は、本発明のＳＯＡＰＲＰＣインプリメンテーションにおけるＳＯＡＰメッセージ４００のデータ・フォーマットを示す。図示されたメッセージ４００は要求メッセージであるが、応答メッセージも同様にフォーマット化されることになる。図を参照すると、前の場合と同様にＳＯＡＰメッセージ４００は、ヘッダ４０４およびボディ４０６を含むエンベロープ４０２からなる。しかしながら、ＳＯＡＰメッセージ４００は、参照された添付ファイル仕様付きＳＯＡＰ［１２］に定義されるように、１つまたは複数のＭＩＭＥ添付ファイル４０８（そのうちの２つを図示）をさらに含む。（図４の論理ビューは、エンベロープ４０２が添付ファイル４０８を含んでいるものとして示している。しかしながら、［２］に示されるような実際のメッセージ・フォーマットでは、添付ファイル４０８はエンベロープ４０２の外部にある。）

図４に示された添付ファイル付きＳＯＡＰのフォーマットは、普通であれば個々のＳＯＡＰメッセージ３００となるものを単一のＳＯＡＰメッセージ４００にパッケージングするために使用される。好ましい実施形態では、メッセージ４００に含まれる個々のＳＯＡＰメッセージそれぞれのボディ３０６（ＲＰＣ要求または応答に対応する）が、ＳＯＡＰＭＩＭＥ添付ファイル４０８として埋め込まれる。ＳＯＡＰヘッダ４０４は、すべての個々のＳＯＡＰメッセージ・ヘッダ３０４の集約されたコレクションを含み、ＭＩＭＥ添付ファイル４０８への参照（すなわちポインタ）を含むため、個々のＳＯＡＰメッセージ３００を再構築することができる。ボディ４０６は実際のメッセージを含むのではなく、添付ファイル４０８に関する情報（ＸＭＬのエンティティ）を含む。とりわけボディ４０６は、個々のＳＯＡＰメッセージ３００のボディ３０６に対応するＭＩＭＥ添付ファイル４０８への参照またはポインタを含む。ボディ４０６内のこれらの参照をヘッダ４０４内の個々のヘッダ３０４への参照と組み合わせて使用すると、個々のメッセージ３００を再構築することができる。

図５は、本発明の基本サービス呼び出し一括エンジンを示す。図に示されるように、クライアント１０２は要求一括および応答分離エンジン５０２を介してネットワーク１０６と対話し、同様に、サービス１０４は応答一括および要求分離エンジン５０４を介してネットワーク１０６と対話する。単一のクライアント１０２およびサービス・プロバイダ１０４のみが示されているが、通常、接続の各エンドでこうしたエンティティ（ｅｎｔｉｔｙ，ｅｎｔｉｔｌｅｓ）は複数存在することができる。その名前からわかるように、要求一括および応答分離エンジン５０２は、ネットワーク１０６を介した伝送のために、クライアント１０２からの個々の要求を複数の要求を含む単一のメッセージ４００（図４）にパッケージングし、応答一括および要求分離エンジン５０４は、サービス１０４による処理のためにメッセージ４００から個々の要求を抽出する。サーバ・バウンド（要求）メッセージ４００の場合、これは個々の要求メッセージ３００のボディ３０６を、ＭＩＭＥ添付ファイル４０８として（ボディ４０６内の添付ファイル４０８へのポインタと共に）メッセージ４００に埋め込むこと、および、メッセージ４００のヘッダ４０４内に個々の要求メッセージ３００のヘッダ３０４を（対応する添付ファイル４０８へのポインタと共に）入れることを伴うことになる。インバウンド（応答）メッセージ４００の場合、これは、単一のヘッダ４０４から個々のヘッダ３０４を抽出すること、ＭＩＭＥ添付ファイル４０８から個々のボディ３０６を抽出すること、および、抽出された構成要素から単一のＲＰＣ応答を含むメッセージ３００を再構築することを伴うことになる。

同様に復路の場合、応答一括および要求分離エンジン５０４は、ネットワーク１０６を介して伝送するために、クライアント１０４からの個々の応答を複数の応答を含む単一のメッセージ４００にパッケージングし、要求一括および応答分離エンジン５０２は、クライアントによる処理のためにメッセージ４００から個々の応答を抽出する。一括および分離エンジン５０２および５０４は、それぞれの呼び出し相関関係子５０６および５０８の支援によって前述の機能を実行する。クライアント側の呼び出し相関関係子５０６は応答が適切なクライアント１０２にルーティングされることを保証し、サーバ側の呼び出し相関関係子５０８は要求が適切なサービス・プロバイダ１０４にルーティングされることを保証する。加えてサーバ側のワークフロー・プロセス要素５１０は、クライアント・エンドから受信したワークフロー情報を使用して、受信した要求の処理の順序を管理する。

本発明は、要求呼び出しの一括の概念を導入すること、および、サーバで要求を順次および並列に実行するために要求メッセージにワークフロー・セマンティクスを追加することによって、通常のＳＯＡＰ要求呼び出しに関連付けられた待ち時間を削減するためのフレームワークを企図する。主要なアーキテクチャの目標の１つが、クライアント側およびサーバ側で同じＡＰＩおよびＳＯＡＰメッセージング・ミドルウェアを使用することによって、クライアント側とサーバ側のインプリメンテーションが損なわれないように維持することである。

前述の概要の項で示したように、本発明は、（１）クライアントおよびサーバでのサービス要求呼び出し一括および分離フレームワーク（図５に示す）、（２）ワークフロー情報を（サービス呼び出しプロファイルとして）サーバに渡し、サーバでそれを実行する、呼び出し実行プロセスに関するワークフロー定義（図５に示す）、ならびに（３）すべての個々の呼び出しセマンティクスを保持しながら、添付ファイル仕様付きＳＯＡＰ［１２］で定義されたようなＳＯＡＰメッセージ交換を行うためのワイヤ・メッセージ・フォーマット（図４に示す）、を提供することによって、サービス指向アーキテクチャにおける待ち時間増加の問題に対処する。

これら項目の最初である、サービス要求呼び出しの一括および分離フレームワークは、呼び出し一括要件、ワークフロー関係情報、および要求制御機能を定義するための、クライアント側ＡＰＩをサポートする。このＡＰＩは、要求一括の開始と、要求一括の終了と、どの呼び出しが並列に実行可能であるか、どの呼び出しが他の呼び出しの結果を待機すべきであるか、どの順序で呼び出しが実行されることになるか、などを含む、呼び出しセマンティクスに関するワークフローの関連付けとを含む。このワークフローは、ＷＳＤＬセマンティクスへの拡張とするか、または新しいクライアント側のサービス呼び出しポリシー言語（たとえば、サービス呼び出し会話言語）とすることができる。

好ましくは、サービス要求呼び出しの一括および分離フレームワークは、同期化プリミティブおよび呼び出しキューを使用する同期および非同期の両方のクライアント呼び出し、およびメッセージとメッセージ相関関係子との関連付けをサポートする。

クライアント側のフレームワークは、添付ファイル仕様付きＳＯＡＰによって定義されたように、ＳＯＡＰメッセージを作成し、第１のＭＩＭＥ部分、すなわちＳＯＡＰボディメッセージを介して識別される良く知られたサーバ側フレームワークにＳＯＡＰメッセージを送信する。このＳＯＡＰメッセージは、添付ファイル仕様付きＳＯＡＰによって定義されたように、すべての関連情報および他のＭＩＭＥ部分（ここではそれぞれが、グループ化された個々のＳＯＡＰ要求である）へのポインタを含む。

クライアント側フレームワークは、メッセージ相関関係子をサポートするための相関エンジンと協働するため、成功した応答または失敗が正しい要求元に戻される。これがサービス呼び出し応答および失敗を処理し、それらを正しいクライアントにディスパッチする。好ましい実施形態では、これはプラグ可能フレームワークであり、要求呼び出し一括の必要性に基づいて実行可能となる。それぞれの個々の要求のＳＯＡＰヘッダ（それぞれの個々の要求はそれぞれが１つまたは複数のヘッダを有する）は、一括された要求の新しいＳＯＡＰヘッダにパッケージングされる。これらのＳＯＡＰヘッダは、ＭＩＭＥ部分をポイントするように修正される。以下で説明するようなサーバ・フレームワークを有することによって、仲介を含むＳＯＡＰヘッダ・プロセッサは、ＳＯＡＰメッセージを容易に解釈し、適切な決定を下すことができる。

サーバ側は、要求を分離し、ワークフロー・エンジンの元でそれらを実行するために、必要なフレームワークを提供する。サーバ側フレームワークは、呼び出しに関連付けられたセマンティクスを理解するために、ワークフロー・エンジンおよび呼び出し相関関係子に関連してプロセスを定義する。これらの呼び出しセマンティクスは、ＳＯＡＰヘッダ内のＳＯＡＰメッセージと共に渡される。このフレームワークはサービス・エンドポイント（一括サービス・インプリメンテーション）とするか、またはサービス・エントリ・ポイントの一部（サーブレットまたはハンドラ）とすることができる。この成果物（ａｒｔｉｆａｃｔ）（すなわち、サービス・エントリ・ポイントまたはエンドポイント）は、コンテナ要件に基づいてモデル化および管理される。すなわちサーバ側フレームワークは、要求の分離、実行（同期あるいは並列またはその両方）、結果／失敗のマッピング、および一括された応答処理に対する責務を負う。

前述のように、このワークフロー情報は、クライアント側あるいはサーバ側またはその両方の要求処理エンジンで定義することができる。これは、ＷＳＤＬに関連付けるか、またはポリシー・ファイルとして別々に定義することができる。このワークフロー情報は単純（メソッドの呼び出しに順序またはセマンティクスがない）とするか、または非常に複雑とすることができる。ワークフロー・エンジンを使用するサーバは、実行を制御する。

ＳＯＡＰメッセージ交換のための開示されたワイヤ・メッセージ・フォーマットは、本発明の好ましい実施形態の重要な特徴の１つである。これは、各呼び出しに関連付けられたサービス呼び出しセマンティクスを損なうことなく、ＳＯＡＰメッセージ交換パターンを定義する。図４に示されるように、好ましい実施形態は、添付ファイル仕様付きＳＯＡＰ［１２］で指定されたメッセージ・フォーマットを使用する。それぞれの要求はＭＩＭＥ部分を使用して識別され、ＳＯＡＰヘッダおよびＳＯＡＰボディから参照することができる。ＳＯＡＰボディは、各メッセージ部分の分離および要求の実行の責務を負うサービス側フレームワークへのＲＰＣメッセージを定義する。各ＳＯＡＰヘッダ属性は、修正なしに要求に関連付けられたままである。ＳＯＡＰヘッダおよびＭＩＭＥ部分は、要求および応答／失敗を相関させるために、メッセージと共に相関情報を搬送する。メインのＳＯＡＰ部分は、ワークフロー管理に必要な追加のプロファイルを搬送することができる。

これはプラグ可能フレームワークであり、当該クライアントは、ワークフロー・プロセスの下でサーバ側での呼び出し一括および要求実行をサポートするために、現在のコードを変更せずに、これと共にその現在のインフラストラクチャを使用することができる。これは呼び出し待ち時間を削減することが可能であり、ジョブを完了するためのサーバへの複数の双方向通信を避けることによって性能を上げることができる。

図６および７は、ＪＡＸ−ＲＰＣハンドラを使用するＪａｖａ環境における、本発明の一括エンジンの特定のインプリメンテーションを示す。とりわけ、図６は、従来のインプリメンテーションにおけるクライアントからサーバへのメッセージ・フローの一例を示し、図７は、本発明の呼び出し一括を使用したクライアントからサーバへのメッセージ・フローの一例を示す。ここでアーキテクチャは、任意のサービス指向フレームワークを使用した汎用方法で定義され、要求／応答呼び出しの一括およびワークフロー情報プロファイルへの要求セマンティクスの提供のために使用することができる。

初めに図６を参照すると、従来のＳＯＡＰＲＰＣインプリメンテーションにおいて、クライアント１０２はＪＡＸ−ＲＰＣ［９］ハンドラまたはＡＰＩ６０２を介してネットワーク１０６とインターフェースし、サービス１０４はアプリケーション・サーバまたはＳＯＡＰ呼び出しレシーバ６０４を介してネットワーク１０６とインターフェースする。クライアント側では、ＪＡＸ−ＲＰＣハンドラ６０２はＳＯＡＰメッセージ・ハンドラ６０６と協働して、ネットワーク１０６を介した伝送のための単一のＲＰＣ要求を含むＳＯＡＰメッセージ３００（図３）を生成する。とりわけ、ＪＡＸ−ＲＰＣハンドラ６０２はＲＰＣ要求を生成し、ＳＯＡＰメッセージ・ハンドラ６０６は、メッセージごとに１つの要求３０６で要求をＳＯＡＰメッセージ３００（図３）にパッケージングする。同様にサーバ側では、アプリケーション・サーバまたはＳＯＡＰ呼び出しレシーバ６０４はＳＯＡＰメッセージ・ハンドラ６０８と協働して、サービス１０４による処理のために各メッセージ３００から単一のＲＰＣ要求を抽出する。とりわけ、アプリケーション・サーバ６０４はＳＯＡＰメッセージ３００を受信し、ＳＯＡＰメッセージ・ハンドラ６０８は各メッセージから個々のＲＰＣ呼び出しを抽出する。これらの要素の機能は、サーバからの復路では同様である。サーバ側では、アプリケーション・サーバ６０４はＳＯＡＰメッセージ・ハンドラ６０８と協働して、ネットワーク１０６を介した伝送のために単一のＲＰＣ応答を含むＳＯＡＰメッセージ３００を生成する。同様にクライアント側では、ＪＡＸ−ＲＰＣハンドラ６０２はＳＯＡＰメッセージ・ハンドラ６０６と協働して、クライアント１０２による処理のために各メッセージ３００から単一のＲＰＣ応答を抽出する。

図７は、図６に示された従来のインプリメンテーションが本発明に従って修正される方法を示す。クライアント側では、ＪＡＸ−ＲＰＣハンドラ６０２がＳＯＡＰ呼び出し一括ＡＰＩ７０２によって補足され、ＳＯＡＰメッセージ・ハンドラ６０６は、クライアントＳＯＡＰ呼び出し一括送信ハンドラ７０４、クライアントＳＯＡＰ呼び出し一括受信ハンドラ７０８、および呼び出し相関関係子７１２によって置き換えられる。クライアントＳＯＡＰ呼び出し一括送信ハンドラ７０４は、複数の要求４０６をサーバ側に伝送するための単一のＳＯＡＰメッセージ４００への添付ファイルとしてパッケージングし、クライアントＳＯＡＰ呼び出し一括受信ハンドラ７０８は、呼び出し相関関係子７１２によって所期のクライアント１０２へディスパッチするために、戻りメッセージ４００から個々の応答を抽出する。

サーバ側では、ＳＯＡＰメッセージ・ハンドラ６０８はサーバＳＯＡＰ呼び出し分離ハンドラ７０６、サーバＳＯＡＰ呼び出し一括応答ハンドラ７１０、呼び出し相関関係子７１４、および順次および並列の呼び出し処理エンジンまたはワークフロー・マネージャ７１６によって置き換えられる。サーバＳＯＡＰ呼び出し分離ハンドラ７０６は、呼び出し相関関係子７１４によって所期のサービス・プロバイダ１０４へディスパッチするために、アプリケーション・サーバ６０４によって受信されたメッセージ４００から個々の要求４０６を抽出し、サーバＳＯＡＰ呼び出し一括応答ハンドラ７１０は、アプリケーション・サーバ６０４によってクライアント側に返送するために、単一のメッセージ４００に応答をパッケージングする。最終的に、順次および並列の呼び出し処理エンジン７１５は、メッセージ４００からのワークフロー情報を使用して、クライアント側から受信した要求４００の実行を順序付ける。このようにして、ワークフロー情報が並列に実行可能であると示す要求は並列に実行され、ワークフロー情報が順次実行しなければならないと示す要求は順次実行される。

以上、特定の実施形態について図示および説明してきたが、当業者であれば様々な修正が明らかとなろう。

付録：省略語および頭字語
ＨＴＴＰＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ
ＩＩＯＰＩｎｔｅｒｎｅｔＩｎｔｅｒ−ＯＲＢＰｒｏｔｏｃｏｌ
ＩＰＣＩｎｔｅｒｐｒｏｃｅｓｓｃｏｍｍｕｎｉｃａｔｉｏｎ
ＪＡＸ−ＲＰＣＪａｖａＡＰＩｆｏｒＸＭＬ−ｂａｓｅｄＲＰＣ
ＪＭＳＪａｖａＭｅｓｓａｇｉｎｇＳｅｒｖｉｃｅ
ＭＩＭＥＭｕｌｔｉｐｕｒｐｏｓｅＩｎｔｅｒｎｅｔＭａｉｌＥｘｔｅｎｓｉｏｎｓ
ＱＯＳＱｕａｌｉｔｙｏｆｓｅｒｖｉｃｅ
ＲＤＦＲｅｓｏｕｒｃｅＤｅｓｃｒｉｐｔｉｏｎＦｒａｍｅｗｏｒｋ
ＲＭＩＲｅｍｏｔｅＭｅｔｈｏｄＩｎｖｏｃａｔｉｏｎ
ＲＰＣＲｅｍｏｔｅｐｒｏｃｅｄｕｒｅｃａｌｌ
ＳＬＡＳｅｒｖｉｃｅｌｅｖｅｌａｇｒｅｅｍｅｎｔ
ＳＯＡＰＳｉｍｐｌｅＯｂｊｅｃｔＡｃｃｅｓｓＰｒｏｔｏｃｏｌ
ＵＤＤＩＵｎｉｖｅｒｓａｌＤｅｓｃｒｉｐｔｉｏｎ，ＤｉｓｃｏｖｅｒｙａｎｄＩｎｔｅｇｒａｔｉｏｎ
ＷＳＤＬＷｅｂＳｅｒｖｉｃｅＤｅｆｉｎｉｔｉｏｎＬａｎｇｕａｇｅ
ＷＳＩＦＷｅｂＳｅｒｖｉｃｅｓＩｎｖｏｃａｔｉｏｎＦｒａｍｅｗｏｒｋ
ＸＭＬＥｘｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ

従来のＳＯＡＰＲＰＣインプリメンテーションにおけるクライアント−サーバ対話を示す図である。本発明のＳＯＡＰＲＰＣインプリメンテーションにおけるクライアント−サーバ対話を示す図である。従来のＳＯＡＰＲＰＣインプリメンテーションにおけるＳＯＡＰメッセージのデータ・フォーマットを示す図である。本発明のＳＯＡＰＲＰＣインプリメンテーションにおけるＳＯＡＰメッセージのデータ・フォーマットを示す図である。本発明の一実施形態の基本サービス呼び出し一括エンジンを示す図である。クライアントからサーバへのメッセージ・フローの一例を示す図である。呼び出し一括を使用したクライアントからサーバへのメッセージ・フローの一例を示す図である。

Claims

クライアントがサービス・プロバイダにサービス要求を発行し、前記サービス要求への応答を前記サービス・プロバイダから受信する、サービス指向アーキテクチャにおいて、要求および応答を処理する方法であって、前記クライアントおよび前記サービス・プロバイダは通信パスの第１および第２のエンドでエンティティを構成し、
前記通信パスの一方のエンドで、前記通信パスの他方のエンドにあるエンティティに伝送するために複数の要求または応答を累積するステップと、
前記累積された複数の要求または応答を含む単一のメッセージを生成するステップと、
前記累積された複数の要求または応答を含む前記生成されたメッセージを、前記通信パスの他方のエンドにある前記エンティティに伝送するステップと、
を有する、方法。
前記生成されたメッセージが、ＳＯＡＰ添付ファイルとして前記累積された複数の要求または応答を含むＳＯＡＰメッセージである、請求項１に記載の方法。
前記メッセージが前記通信パスの前記第１のエンドから伝送され、要求を含むものであって、
前記サービス・プロバイダによって生成されたサービス要求への複数の応答を含む前記通信パスの前記第２のエンドからのメッセージを受信するステップと、
前記通信パスの前記第１のエンドで処理するために前記受信されたメッセージから個々の応答を抽出するステップと、
をさらに有する、請求項１に記載の方法。
前記メッセージが前記通信パスの前記第１のエンドから伝送され、要求を含むものであって、
前記通信パスの前記第２のエンドで前記メッセージを受信するステップと、
前記通信パスの前記第２のエンドで処理するために前記受信されたメッセージから個々の要求を抽出するステップと、
をさらに有する、請求項１に記載の方法。
前記メッセージが前記要求の実行順序を指定するワークフロー情報を含み、
前記要求を前記ワークフロー情報によって指定された順序で実行するステップをさらに有する、請求項４に記載の方法。
前記ワークフロー情報が、前記メッセージ内の要求が順次実行されるかまたは並列に実行されるかを指定し、前記要求が、前記ワークフロー情報によって指定されたように順次または並列に実行される、請求項５に記載の方法。
クライアントがサービス・プロバイダにサービス要求を発行し、前記サービス要求への応答を前記サービス・プロバイダから受信する、サービス指向アーキテクチャにおいて、要求および応答を処理する方法であって、前記クライアントおよび前記サービス・プロバイダは通信パスの第１および第２のエンドでエンティティを構成し、
前記通信パスの一方のエンドで、複数の要求または応答を含む前記通信パスの他方のエンドからのメッセージを受信するステップと、
前記通信パスの前記一方のエンドで処理するために前記受信されたメッセージから個々の要求または応答を抽出するステップと、
を有する、方法。
前記メッセージが前記通信パスの前記第２のエンドで受信され、前記要求の実行順序を指定するワークフロー情報と共に要求を含むものであって、
前記ワークフロー情報によって指定された順序で前記要求を実行するステップをさらに有する、請求項７に記載の方法。
クライアントがサービス・プロバイダにサービス要求を発行し、前記サービス要求への応答を前記サービス・プロバイダから受信する、サービス指向アーキテクチャにおいて、要求および応答を処理するための装置であって、前記クライアントおよび前記サービス・プロバイダは通信パスの第１および第２のエンドでエンティティを構成し、
前記通信パスの一方のエンドで、前記通信パスの他方のエンドにあるエンティティに伝送するために複数の要求または応答を累積するための手段と、
前記累積された複数の要求または応答を含む単一のメッセージを生成するための手段と、
前記累積された複数の要求または応答を含む前記生成されたメッセージを、前記通信パスの他方のエンドにある前記エンティティに伝送するための手段と、
を有する、装置。
前記メッセージが前記通信パスの前記第１のエンドから伝送され、要求を含むものであって、
前記サービス・プロバイダによって生成されたサービス要求への複数の応答を含む前記通信パスの前記第２のエンドからのメッセージを受信するための手段と、
前記通信パスの前記第１のエンドで処理するために前記受信されたメッセージから個々の応答を抽出するための手段と、
をさらに有する、請求項９に記載の装置。
前記メッセージが前記通信パスの前記第１のエンドから伝送され、要求を含むものであって、
前記通信パスの前記第２のエンドで前記メッセージを受信するための手段と、
前記通信パスの前記第２のエンドで処理するために前記受信されたメッセージから個々の要求を抽出するための手段と、
をさらに有する、請求項９に記載の装置。
前記メッセージが前記要求の実行順序を指定するワークフロー情報を含み、
前記要求を前記ワークフロー情報によって指定された順序で実行するための手段をさらに有する、請求項１１に記載の装置。
クライアントがサービス・プロバイダにサービス要求を発行し、前記サービス要求への応答を前記サービス・プロバイダから受信する、サービス指向アーキテクチャにおいて、要求および応答を処理するための装置であって、前記クライアントおよび前記サービス・プロバイダは通信パスの第１および第２のエンドでエンティティを構成し、
前記通信パスの一方のエンドで、複数の要求または応答を含む前記通信パスの他方のエンドからのメッセージを受信するための手段と、
前記通信パスの前記一方のエンドで処理するために前記受信されたメッセージから個々の要求または応答を抽出するための手段と、
を有する、装置。
前記メッセージが前記通信パスの前記第２のエンドで受信され、前記要求の実行順序を指定するワークフロー情報と共に要求を含むものであって、
前記ワークフロー情報によって指定された順序で前記要求を実行するための手段をさらに有する、請求項１３に記載の装置。
マシンによる読み取りが可能であり、請求項１から８のいずれかに記載の方法ステップを実行するためにマシンによって実行可能な命令のプログラムを有形に具体化する、プログラム・ストレージ・デバイス。