(57)【要約】      （修正有）【課題】  スケジューラによる外部サービスの管理を可能にする。【解決手段】  スケジューラ２０５は、実行エージェント２１０および記述子２４０をそれぞれの実行依頼されることになるジョブと関連付けるワークロード・データベース２２０へアクセスする。記述子は、所望のウェブ・サービス２５５および対応するＷＳＤＬドキュメント２４５のアドレスを識別する。ジョブの実行が依頼されるときには、スケジューラがその記述子を関連付けられたエージェントへ送る。エージェントは、対応するウェブ・サービスのＷＳＤＬドキュメントをダウンロードする。続いてそのウェブ・サービスのための要求メッセージ２５０が構築され、所望の内容がＷＳＤＬドキュメント内に指定された構造の中に埋め込まれる。この要求メッセージを、そのウェブ・サービスを実装しているエンドポイントへ送り、そのウェブ・サービスが呼び出される。【選択図】図３
2005196767.tif 000002
【特許請求の範囲】
【請求項１】
分散アーキテクチャを有するデータ処理インフラストラクチャ内における作業単位の実行を中央スケジューリング・アプリケーションの制御の下にスケジューリングする方法であって、
前記作業単位の少なくとも１つと、事前定義インターフェース・ドキュメントに従ってアクセス可能な外部サービスの表示を含む記述子を関連付けるステップ（３０４）、
事前定義プランに従った前記作業単位の実行を依頼するステップ（３０８）、
実行依頼された作業単位に関連付けられたそれぞれの外部サービスのインターフェース・ドキュメントを検索するステップ（３３６）、
前記実行依頼された作業単位に関連付けられたそれぞれの外部サービスのための要求メッセージを、対応するインターフェース・ドキュメントに従って構築するステップ（３３８〜３４２）、および、
前記外部サービスの呼び出しを生じさせるために各要求メッセージを対応する外部サービスへ送るステップ（３６４）、
を含む方法（３００）。
【請求項２】
さらに、
呼び出された各外部サービスから応答メッセージを受け取るステップ（３７０）、および、
各応答メッセージを、対応するインターフェース・ドキュメントに従って解釈するステップ（３７５）、
を含む請求項１に記載の方法（３００）。
【請求項３】
前記インターフェース・ドキュメントは、各メッセージの構造を指定し、前記記述子は、さらに前記要求メッセージの内容の表示を含み、前記要求メッセージを構築するステップ（３３８〜３４２）は、
前記要求メッセージの内容を対応する構造内に埋め込むステップ（３４１〜３４２）、
を含む請求項１または２に記載の方法（３００）。
【請求項４】
前記要求メッセージの内容の表示は、前記外部サービスへ渡されるべき一組の入力パラメータを含み、その少なくとも１つの入力パラメータは記号変数であり、前記要求メッセージを構築するステップ（３３８〜３４２）は、さらに、
各記号変数を実際の値に変換するステップ（３３８）、
を含む請求項３に記載の方法（３００）。
【請求項５】
前記中央スケジューリング・アプリケーションは、スケジューラ、および少なくとも１つのエージェントを含み、前記スケジューラは前記関連付けるステップ（３０４）および実行を依頼するステップ（３０８）を実行し、各記述子は、さらに、対応する作業単位に関連付けられたエージェントの表示を含み、前記方法がさらに、
前記スケジューラが、それぞれの実行依頼された作業単位の実行の要求であって、対応する記述子の表示を含む実行の要求を関連付けられたエージェントへ送るステップ（３１６）、および
前記エージェントが、対応する外部サービスのインターフェース・ドキュメントを検索し（３３６）、前記外部サービスのための要求メッセージを構築し（３３８〜３４２）、かつ前記実行の要求に応答して前記要求メッセージを前記外部サービスへ送る（３６４）ステップ、
を含む、請求項１〜４のいずれかに記載の方法（３００）。
【請求項６】
前記インターフェース・ドキュメントの表示は、前記インフラストラクチャ内の、前記インターフェース・ドキュメントを格納している外部の場所のアドレスからなり、前記インターフェース・ドキュメントを検索するステップは、
対応する前記外部の場所から前記インターフェース・ドキュメントをダウンロードするステップ（３３６）を含む、請求項１〜５のいずれかに記載の方法（３００）。
【請求項７】
前記記述子は、外部サービスについての認証情報を含み、前記方法は、さらに、
前記外部サービスへ前記認証情報を送るステップ（３５２）を含み、前記認証情報に従って前記外部サービスの呼び出しが許可される、請求項１〜６のいずれかに記載の方法。
【請求項８】
前記外部サービスがウェブ・サービスである、請求項１〜７のいずれかに記載の方法。
【請求項９】
データ処理システム（１０５、１１０）の作業メモリ内に直接ロード可能なコンピュータ・プログラムであって、請求項１〜８のいずれかに記載された方法をコンピュータに実行させるためのコンピュータ・プログラム（２０５、２１０）。
【請求項１０】
分散アーキテクチャを有するデータ処理インフラストラクチャ（１００）内における作業単位の実行をスケジューリングするためのシステムであって、前記作業単位の少なくとも１つと、事前定義インターフェース・ドキュメントに従ってアクセス可能な外部サービスの表示を含む記述子を関連付けるための手段（２２０）、事前定義プランに従った前記作業単位の実行を依頼するための手段（２０５）、実行依頼された作業単位に関連付けられたそれぞれの外部サービスのインターフェース・ドキュメントを検索するための手段（２１０）、前記実行依頼された作業単位に関連付けられたそれぞれの外部サービスのための要求メッセージを、対応するインターフェース・ドキュメントに従って構築するための手段（２１０）、および、前記外部サービスの呼び出しを生じさせるために各要求メッセージを対応する外部サービスへ送るための手段（２１０）を有する中央スケジューリング・アプリケーション（２０５、２１０）を含むシステム（１０５、１１０）。
【請求項１１】
請求項１０に従ったシステム（１０５、１１０）および、それぞれの外部サービスを実装するための少なくとも１つの外部サーバ（１２０）を含む、分散アーキテクチャを有するデータ処理インフラストラクチャ（１００）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理分野に関し、より詳細に述べれば、スケジューリング方法および対応するシステムに関する。
【背景技術】
【０００２】
スケジューリング方法は、データ処理システム内において異なる作業単位（たとえば、バッチ処理におけるジョブ）の実行依頼（サブミット）を制御するために一般的に使用されている。これを目的として、近年、いくつかのタイプの、大量のジョブの実行依頼を自動的に行うスケジューラが提案されている。スケジューラの一例として、ＩＢＭコーポレーションの“Ｔｉｖｏｌｉワークロード・スケジューラ”が挙げられる。
【０００３】
スケジューラは、事前定義プランに従ってジョブの実行依頼を行い、それがジョブの実行の望ましいフローを確立する。ジョブが実行依頼されなければならないときには、常に、スケジューラが対応するエージェントに対して実行要求をディスパッチし、エージェントは、ジョブの実行を直接的に制御し、スケジューラへフィードバック情報を返す。このようにしてスケジューラは、すべてのジョブのための単一の中心制御ポイントを提供する。
【０００４】
さらに、利用可能なスケジューラのほとんどは、追加のサービスも提供する。通常、スケジューラは、（たとえば、ほかのジョブの完了によって、またはシステム・リソースの可用性によって定義される）時間的制約および先行ジョブの制約の取り扱いにおいて非常に洗練されている。スケジューラには、グラフィカル・ユーザ・インターフェース（ＧＵＩ）を備えることも可能であり、それによってジョブまたはプランの定義の作成、修正、および削除が可能になり、また当該スケジューラによって行われているオペレーションの制御およびモニタが可能になる。しかも、スケジューラによっては、パフォーマンス・モニタ機能、負荷平準化機能、報告機能などを組み込んだものもある。
【０００５】
この分野で周知のスケジューラの欠点は、それらが、会社内の閉じた環境の中で働くために特別に設計されていることである。実際、これらのスケジューラは、通常、単一の（スケジューラ自体が実行されている）コンピュータでの実行のために作業単位をサブミットするか、あるいはせいぜい会社のプライベート・ネットワークを介して接続されているコンピュータのクラスタの管理をサポートするにとどまる。
【０００６】
いずれにおいてもこの分野では、（通常、サード・パーティによって提供される）外部サービスの呼び出しを制御する開いた環境において使用可能なスケジューラは知られていない。実際のところ、外部サービスへは多数の方法でアクセス可能であるが、概してそれらはスケジューラの要件と両立しない。
【０００７】
この問題は、インターネット、特にウェブ・サービスの広範な普及によってさらに悪化している。ウェブ・サービス（アプリケーション・サービスとも呼ばれている）は、（提供されている機能の実際のインプリメンテーションとは関係なく）標準化された方法で定義されたインターフェースを介して、別のアプリケーションによって利用されることの可能な機能の集合からなる。ウェブ・サービスは、ユビキタスなプロトコルおよびデータ・フォーマット（ＨＴＴＰ、ＳＯＡＰ、およびＸＭＬ等）を介してアクセスされる。このようにしてウェブ・サービスは、アプリケーション統合のための標準プラットフォームとなり、インターネット上の分散コンピューティングへの移行における基本ビルディング・ブロックとなっている。
【０００８】
したがって、利用可能なスケジューラの制限は、インターネットの完全な利用を強く妨げており、特に、サード・パーティによって提供されるウェブ・サービスを伴うレガシー・アプリケーションの相互運用性を損なう（たとえば、電子商取引アプリケーションにおいてオンライン・トランザクションを実装するとき）。
【０００９】
【非特許文献１】「Ｗｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＳＤＬ）」、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／＞
【非特許文献２】「ＳＯＡＰ  Ｖｅｒｓｉｏｎ  １．２  Ｐａｒｔ  ０：ｐｒｉｍｅｒ」、インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／＞
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明の目的は、スケジューラによる外部サービスの管理を可能にすることである。
【００１１】
特に、スケジューラによる外部サービスの呼び出しを可能にすることをその目的とする。
【００１２】
本発明の別の目的は、異機種環境で使用することのできるスケジューリング方法を提供することである。
【００１３】
本発明のさらに別の目的は、スケジューラと外部サービスの統合をサポートすることである。
【００１４】
特に、外部サービスを管理するために、スケジューラ内においてすでに利用可能な追加の機能を利用することを本発明の目的とする。
【課題を解決するための手段】
【００１５】
これらの、およびそのほかの関連する目的は、分散アーキテクチャを有するデータ処理インフラストラクチャ内における作業単位の実行を中央スケジューリング・アプリケーションの制御の下にスケジューリングする方法によって達成され、当該方法は、作業単位の少なくとも１つと、事前定義インターフェース・ドキュメントに従ってアクセス可能な外部サービスの表示を含む記述子を関連付けるステップ、事前定義プランに従って実行のために作業単位を実行依頼するステップ、実行依頼される作業単位に関連付けられたそれぞれの外部サービスのインターフェース・ドキュメントを検索するステップ、実行依頼される作業単位に関連付けられたそれぞれの外部サービスのための要求メッセージを対応するインターフェース・ドキュメントに従って構築するステップ、および、外部サービスの呼び出しを生じさせるために各要求メッセージを対応する外部サービスへ送るステップを含む。
【００１６】
本発明はまた、この方法を実行するためのコンピュータ・プログラム、およびそのプログラムを具体化する製品を提供する。作業単位の実行をスケジューリングするための対応するシステム、およびそのシステムを含むデータ処理インフラストラクチャも包含される。
【００１７】
本発明に独特であると考えられる新しい特徴は、付随する特許請求の範囲に示されている。しかしながら本発明自体はもとより、その目的およびそのほかの関連する目的ならびに利点は、添付図面とともに以下の詳細な説明を参照することによってもっともよく理解されることになろう。
【発明を実施するための最良の形態】
【００１８】
ここで特に図１を参照すると、分散アーキテクチャを有するデータ処理インフラストラクチャ１００の概要ブロック図が示されている。このインフラストラクチャ１００は、非対話式ジョブの実行依頼に使用される中央スケジューリング・サーバ１０５を含む。スケジューリング・サーバ１０５は、ジョブの実際の実行を制御する複数のサーバ１１０と通信する。実行サーバ１１０は、インターネット等のグローバル・ネットワーク１１５へアクセスする。その結果として、それらの実行サーバ１１０は、対応するサービス（たとえば、ストレージまたはカスタマ・リレーションシップ・マネジメント）を提供する複数のウェブ・サーバ１２０と対話することができる。インターネット１１５内において利用可能となっているウェブ・サービスは、分散レジストリ内にリストされる。分散レジストリは、対応する一組のサーバ１２５によって実装される。
【００１９】
より詳細に述べれば、分散レジストリは、ＵＤＤＩ（UniversalDescription, Discovery and Integration）仕様に準拠したＸＭＬベースのドキュメントからなる。各ビジネス組織によって提供されるウェブ・サービスは、ＷＳＤＬ（WebServices Description Language）ドキュメント内に指定される。ＷＳＤＬドキュメントは、一組のＸＭＬベースの定義からなり、それらは、抽象定義および具象定義に分けられる（異なるテクノロジのために抽象定義を再使用できるようにするため）。特に、抽象定義は、タイプ（ウェブ・サービスに関連したデータ型を指定する）、メッセージ（交換されるデータの型を指定する）、オペレーション（関係するメッセージに関してサポートされるアクションを指定する）、およびポート・タイプ（関連するオペレーションをグループ化する）を含む。これに対して、具象定義は、バインディング（ポート・タイプについて、具象プロトコルおよびデータ・フォーマット仕様をオペレーションおよびメッセージへ関連付ける）、ポート（ポート・タイプを実装するウェブ・サーバのためのネットワーク・アドレスを指定する）、およびサービス（関連するポートをグループ化する）を含む。さらにＷＳＤＬ仕様は、拡張性要素をサポートし、それらを使用して特定のテクノロジに特有の情報を（抽象定義または具象定義において）提供することができる。
【００２０】
ＷＳＤＬドキュメントの定義は、次の要素の中に入れられる。
【００２１】
＜ｄｅｆｉｎｉｔｉｏｎｓ  ｎａｍｅ＝ｍｙＮａｍｅ  ｔａｒｇｅｔＮａｍｅｓｐａｃｅ＝ｍｙＮａｍｅｓｐａｃｅ＞
・・・・
＜＼ｄｅｆｉｎｉｔｉｏｎｓ＞
【００２２】
属性“ｎａｍｅ”および“ｔａｒｇｅｔＮａｍｅｓｐａｃｅ”を、軽量化された形式でＷＳＤＬドキュメントを識別するためにオプションとして使用することができる。特に、属性“ｎａｍｅ”は、そのＷＳＤＬドキュメントに割り当てられた名前（“ｍｙＮａｍｅ”）を提供し、属性“ｔａｒｇｅｔＮａｍｅｓｐａｃｅ”は、対応する名前空間（“ｍｙＮａｍｅｓｐａｃｅ”）を指定する。名前空間は、名前を修飾するために使用される一意的な識別子からなり、一般に、希望するコンテンツのウェブ・ポイントのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）である（たとえば、ウェブ・サイトのアドレス）。
【００２３】
タイプは、次のステートメントによって定義される。
【００２４】
＜ｔｙｐｅｓ＞
＜ｓｃｈｅｍａ  ｔａｒｇｅｔＮａｍｅｓｐａｃｅ＝ｍｙＳｃｈｅｍａ＞
・・・・
＜／ｓｃｈｅｍａ＞
＜／ｔｙｐｅｓ＞
【００２５】
タグ“ｓｃｈｅｍａ”は、希望するスキーマ（”ｍｙＳｃｈｅｍａ”）のＵＲＩを指定するために使用することができる。スキーマは、ＸＳＤ（ＸＭＬスキーマ定義）仕様に従ったデータ型の抽象表現である。それに代えて、拡張性要素（型定義のためのＸＭＬコンテナを提供する）を介して特定のデータ型を追加することができる。好ましくは、基本データ型が次の形式で定義される。
【００２６】
＜ｅｌｅｍｅｎｔ  ｎａｍｅ＝ｍｙＥｌｅｍｅｎｔ  ｔｙｐｅ＝ｍｙＴｙｐｅ／＞
【００２７】
これにおいて、属性“ｎａｍｅ”は、ＷＳＤＬドキュメント内のデータ型の一意的な名前（“ｍｙＥｌｅｍｅｎｔ”）を提供し、属性“ｔｙｐｅ”は、希望するデータ型を参照する。逆を言えば、次の形式を用いて複数のデータ型を組み合わせれば、複合データ型が定義される。
【００２８】
＜ｅｌｅｍｅｎｔ  ｎａｍｅ＝ｍｙＥｌｅｍｅｎｔ＞
＜ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ａｌｌ＞
・・・・
＜／ａｌｌ＞
＜／ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｅｌｅｍｅｎｔ＞
【００２９】
各メッセージは、その論理要素を表す１つまたは複数のパーツからなる。
【００３０】
＜ｍｅｓｓａｇｅ  ｎａｍｅ＝ｍｙＭｅｓｓａｇｅ＞
＜ｐａｒｔ  ｎａｍｅ＝ｍｙＰａｒｔ  ｅｌｅｍｅｎｔ＝ｍｙＥｌｅｍｅｎｔ  ｔｙｐｅ＝ｍｙＴｙｐｅ／＞
＜／ｍｅｓｓａｇｅ＞
【００３１】
メッセージの属性“ｎａｍｅ”は、ＷＳＤＬドキュメント内における一意的な名前（“ｍｙＭｅｓｓａｇｅ”）を提供する。それぞれのメッセージ・パーツについて、属性“ｎａｍｅ”は、そのメッセージ内における一意的な名前（“ｍｙＰａｒｔ”）を定義する。このメッセージ・パーツは、１つまたは複数のパラメータを含み、そのそれぞれがパラメータの名前（“ｍｙＥｌｅｍｅｎｔ”）を指定する属性“ｅｌｅｍｅｎｔ”、およびその型（“ｍｙＴｙｐｅ”）を参照する属性“ｔｙｐｅ”からなる。
【００３２】
各ポート・タイプの定義は（対応するオペレーションとともに）、次の構文を有する。
【００３３】
＜ｐｏｒｔＴｙｐｅ  ｎａｍｅ＝ｍｙＰｏｒｔＴｙｐｅ＞
＜ｏｐｅｒａｔｉｏｎ  ｎａｍｅ＝ｍｙＯｐｅｒａｔｉｏｎ＞
＜．．．．  ｎａｍｅ＝ｍｙＭｅｓｓａｇｅ  ｍｅｓｓａｇｅ＝ｍｙＤｅｆｉｎｉｔｉｏｎ／＞
＜／ｏｐｅｒａｔｉｏｎ＞
・・・・
＜／ｐｏｒｔＴｙｐｅ＞
【００３４】
ポート・タイプの属性“ｎａｍｅ”は、ＷＳＤＬドキュメント内における一意的な名前（“ｍｙＰｏｒｔＴｙｐｅ”）を提供する。各オペレーションについて、属性“ｎａｍｅ”は、ポート・タイプ内の一意的な名前（“ｍｙＯｐｅｒａｔｉｏｎ”）を定義する。オペレーションは、１つまたは複数のメッセージからなる（以下において説明するとおり、対応する要素によって修飾される）。各メッセージは、そのメッセージの名前（“ｍｙＭｅｓｓａｇｅ”）を指定する属性“ｎａｍｅ”、およびその抽象定義（“ｍｙＤｅｆｉｎｉｔｉｏｎ”）を参照する属性“ｍｅｓｓａｇｅ”によって定義される。それに加えて、追加の属性“ｐａｒａｍｅｔｅｒＯｒｄｅｒ”を使用し、そのオペレーションの実際のシグニチャを（そのパラメータの順序付きリストを介して）指定することができる。
【００３５】
ＷＳＤＬは、４つのオペレーション・タイプをサポートする。すなわち、片方向（メッセージが受信されるだけ）、要求‐応答（メッセージが送信され、対応するメッセージが受信される）、送信請求‐応答（メッセージが受信され、対応するメッセージが送信される）、および通知（メッセージが受信されるだけ）である。片方向オペレーションは次のようになる。
【００３６】
＜ｏｐｅｒａｔｉｏｎ  ｎａｍｅ＝ｍｙＯｐｅｒａｔｉｏｎ＞
＜ｉｎｐｕｔ  ｎａｍｅ＝ｍｙＩｎｐｕｔ  ｍｅｓｓａｇｅ＝ｍｙＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎ／＞
＜／ｏｐｅｒａｔｉｏｎ＞
【００３７】
これは、要求のための要素“ｉｎｐｕｔ”を含む。
【００３８】
要求‐応答オペレーションは、次のようになる。
【００３９】
＜ｏｐｅｒａｔｉｏｎ  ｎａｍｅ＝ｍｙＯｐｅｒａｔｉｏｎ＞
＜ｉｎｐｕｔ  ｎａｍｅ＝ｍｙＩｎｐｕｔ  ｍｅｓｓａｇｅ＝ｍｙＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎ／＞
＜ｏｕｔｐｕｔ  ｎａｍｅ＝ｍｙＯｕｔｐｕｔ  ｍｅｓｓａｇｅ＝ｍｙＯｕｔｐｕｔＤｅｆｉｎｉｔｉｏｎ／＞
＜ｆａｕｌｔ  ｎａｍｅ＝ｍｙＦａｕｌｔ  ｍｅｓｓａｇｅ＝ｍｙＦａｕｌｔＤｅｆｉｎｉｔｉｏｎ／＞
＜／ｏｐｅｒａｔｉｏｎ＞
【００４０】
これは、要求のための要素“ｉｎｐｕｔ”、応答のための要素“ｏｕｔｐｕｔ”、およびオペレーションの結果として返されることのあるエラーのための要素“ｆａｕｌｔ”を含む。
【００４１】
類似するメッセージが送信請求‐応答オペレーションに含まれる。
【００４２】
＜ｏｐｅｒａｔｉｏｎ  ｎａｍｅ＝ｍｙＯｐｅｒａｔｉｏｎ＞
＜ｏｕｔｐｕｔ  ｎａｍｅ＝ｍｙＯｕｔｐｕｔ  ｍｅｓｓａｇｅ＝ｍｙＯｕｔｐｕｔＤｅｆｉｎｉｔｉｏｎ／＞
＜ｉｎｐｕｔ  ｎａｍｅ＝ｍｙＩｎｐｕｔ  ｍｅｓｓａｇｅ＝ｍｙＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎ／＞
＜ｆａｕｌｔ  ｎａｍｅ＝ｍｙＦａｕｌｔ  ｍｅｓｓａｇｅ＝ｍｙＦａｕｌｔＤｅｆｉｎｉｔｉｏｎ／＞
＜／ｏｐｅｒａｔｉｏｎ＞
【００４３】
通知オペレーションは、次のようになる。
【００４４】
＜ｏｐｅｒａｔｉｏｎ  ｎａｍｅ＝ｍｙＯｐｅｒａｔｉｏｎ＞
＜ｏｕｔｐｕｔ  ｎａｍｅ＝ｍｙＯｕｔｐｕｔ  ｍｅｓｓａｇｅ＝ｍｙＯｕｔｐｕｔＤｅｆｉｎｉｔｉｏｎ／＞
＜／ｏｐｅｒａｔｉｏｎ＞
【００４５】
オペレーションごとにその中でメッセージの名前設定を行わなければならないことを回避するために、ＷＳＤＬは、いくつかのデフォルトの値を提供している。特に、片方向または通知オペレーションの単一のメッセージについて属性“ｎａｍｅ”が指定されていない場合には、そのメッセージの名前のデフォルトがそれぞれのオペレーションの名前になる。同様に、要求‐応答または送信請求‐応答オペレーションの入出力メッセージについて、要素“ｎａｍｅ”が指定されていない場合には、そのメッセージの名前のデフォルトが“ｒｅｑｕｅｓｔ（要求）”／”ｓｏｌｉｃｉｔ（送信請求）”または“ｒｅｓｐｏｎｓｅ（応答）”が付属されたそれぞれのオペレーションの名前になる。
【００４６】
各ポート・タイプのバインディングは、次に示す要素によって与えられる。
【００４７】
＜ｂｉｎｄｉｎｇ  ｎａｍｅ＝ｍｙＢｉｎｄｉｎｇ  ｔｙｐｅ＝ｍｙＰｏｒｔＴｙｐｅ＞
・・・・
＜ｏｐｅｒａｔｉｏｎ  ｎａｍｅ＝ｍｙＯｐｅｒａｔｉｏｎ＞
・・・・
＜ｉｎｐｕｔ  ｎａｍｅ＝ｍｙＩｎｐｕｔ＞
・・・・
＜／ｉｎｐｕｔ＞
＜ｏｕｔｐｕｔ  ｎａｍｅ＝ｍｙＯｕｔｐｕｔ＞
・・・・
＜／ｏｕｔｐｕｔ＞
＜ｆａｕｌｔ  ｎａｍｅ＝ｍｙＦａｕｌｔ＞
・・・・
＜／ｆａｕｌｔ＞
＜／ｏｐｅｒａｔｉｏｎ＞
＜／ｂｉｎｄｉｎｇ＞
【００４８】
属性“ｎａｍｅ”は、ＷＳＤＬドキュメント内におけるバインディングのための一意的な名前（“ｍｙＢｉｎｄｉｎｇ”）を提供する。属性“ｔｙｐｅ”は、結合されるポート・タイプ（“ｍｙＰｏｒｔＴｙｐｅ”）を参照する。拡張性要素が使用されて、バインディングに関する追加情報が追加され、各オペレーションならびに任意の対応する入力、出力、およびフォールト・メッセージについての具象文法が指定される。
【００４９】
各サービスの定義は（対応するポートとともに）次の構文を有する。
【００５０】
＜ｓｅｒｖｉｃｅ  ｎａｍｅ＝ｍｙＳｅｒｖｉｃｅ＞
＜ｐｏｒｔ  ｎａｍｅ＝ｍｙＰｏｒｔ  ｂｉｎｄｉｎｇ＝ｍｙＢｉｎｄｉｎｇ＞
・・・・
＜／ｐｏｒｔ＞
・・・・
＜／ｓｅｒｖｉｃｅ＞
【００５１】
サービスの属性“ｎａｍｅ”は、ＷＳＤＬドキュメント内における一意的な名前（“ｍｙＳｅｒｖｉｃｅ”）を提供する。各ポートについて、属性“ｎａｍｅ”は、ＷＳＤＬドキュメント内における一意的な名前（“ｍｙＰｏｒｔ”）を提供する。属性“ｂｉｎｄｉｎｇ”は、対応するバインディング（“ｍｙＢｉｎｄｉｎｇ”）を参照する。拡張性要素が使用されて１つまたは複数のウェブ・サーバ（エンドポイントとも呼ばれる）の具象ネットワーク・アドレスが指定され、それが対応するポート・タイプのオペレーションを実際に具体化する。サービスがポート・タイプを共有する複数のポートを有している場合には、それらのポートは、意味的に等価の振る舞いを提供する（ただし、異なるバインディングまたはエンドポイントを使用する）。
【００５２】
好ましくは、ウェブ・サービスの定義が、対応する要素（“ｉｍｐｏｒｔ”）を使用して含められる独立のドキュメントに分けられる。さらに、可読情報を提供するために、任意の定義の中に要素“ｄｏｃｕｍｅｎｔａｔｉｏｎ”を使用することができる。
【００５３】
ＷＳＤＬは、もっとも一般的な、ＳＯＡＰ（Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）等の標準プロトコルのための特定のバインディング要素を用いて拡張される。ＳＯＡＰは、任意の種類のオペレーティング・システム内で走るプログラムが通信することを可能にするために特別に設計されたプロトコルである。特に、ＳＯＡＰの設計目標の１つは、ＲＰＣ（Ｒｅｍｏｔｅ  Ｐｒｏｃｅｄｕｒｅ  Ｃａｌｌ）をカプセル化することである。
【００５４】
ＳＯＡＰは、ノード間のメッセージの交換を伴う。詳細に述べれば、ＳＯＡＰメッセージが最初のセンダ・ノードから最終的なレシーバ・ノードまで伝わり、可能性としては対応するパスに沿った一組の中継ノードを通過する。各ＳＯＡＰメッセージは、次に示す構造を伴うＸＭＬベースのドキュメントからなる。
【００５５】
＜ｅｎｖ：Ｅｎｖｅｌｏｐｅ
ｘｍｌｓ：ｅｎｖ＝ｍｙＮａｍｅｓｐａｃｅ  ｅｎｖ：ｅｎｃｏｄｉｎｇＳｔｙｌｅ＝ｍｙＥｎｃｏｄｉｎｇＳｔｙｌｅ＞
＜ｅｎｖ：Ｈｅａｄｅｒ＞
・・・・
＜／ｅｎｖ：Ｈｅａｄｅｒ＞
＜ｅｎｖ：Ｂｏｄｙ＞
・・・・
＜／ｅｎｖ：Ｂｏｄｙ＞
＜／ｅｎｖ：Ｅｎｖｅｌｏｐｅ＞
【００５６】
ＳＯＡＰメッセージは、要素“ｅｎｖ：Ｅｎｖｅｌｏｐｅ”によって定義されるエンベロープ（ｅｎｖｅｌｏｐｅ）内に囲い込まれる。属性“ｘｍｌｓ：ｅｎｖ”は、対応する名前空間（“ｍｙＮａｍｅｓｐａｃｅ”）の指定を可能にする。さらに、属性“ｅｎｖ：ｅｎｃｏｄｉｎｇＳｔｙｌｅ”が使用されて、ＳＯＡＰメッセージの内容を（その内容をシリアル化するために使用される対応の規則に従って）修飾するＵＲＩ（“ｍｙＥｎｃｏｄｉｎｇＳｔｙｌｅ”）が提供される。
【００５７】
エンベロープは、ヘッダ（要素“ｅｎｖ：Ｈｅａｄｅｒ”によって定義される）およびボディ（要素“ｅｎｖ：Ｂｏｄｙ”によって定義される）を含み、通常はサブエレメント（ブロックと呼ばれる）に組織化される。ＳＯＡＰ仕様は、それらの要素がどのように取り扱われるかを決めているだけであり、それらの内容（アプリケーション依存）については決めていない。
【００５８】
具体的には、ヘッダは、追加のサービスを提供するために使用することのできるオプションの要素であり、その多くが中継ノードの関与を伴う。ヘッダのブロックは、メッセージ・パスに沿って遭遇することのある各種のノードに向けられる。これらのノードは、それぞれの役割によって識別され、それを属性“ｅｎｖ：ｒｏｌｅ”によって指定することができる。ＳＯＡＰ仕様では、“ｎｏｎｅ”（いずれのノードもヘッダ・ブロックを処理するべきでないことを意味する）、“ｎｅｘｔ”（メッセージ・パス内において遭遇する次のノードへ関連付ける）、または“ｕｌｔｉｍａｔｅＲｅｃｅｉｖｅｒ”（レシーバ・ノード用）といった、いくつかの標準化された役割が定義されている。属性“ｅｎｖ：ｒｏｌｅ”が欠如している場合には、そのヘッダ・ブロックはレシーバ・ノードへ向けられる。各ノードが特定の役割を引き受ける方法は、ＳＯＡＰ仕様とは関係がない（アプリケーション・レベルで決定される）。
【００５９】
ＳＯＡＰメッセージを受け取る各中継ノードは、その役割について意図されたヘッダ・ブロックを（もし可能であれば）処理し、その後そのＳＯＡＰメッセージを所望のパスに沿って中継する。デフォルトにより、中継ノード宛のヘッダ・ブロックは、アウトバウンドＳＯＡＰメッセージから除去される（しかしながら、処理の結果として、それらの内容の変更を伴わずに、または変更を伴ってそれらが再挿入されることもある）。ヘッダ・ブロックが任意の可能中継ノードに向けられなければならないときには、値“ｔｒｕｅ”を伴う属性“ｅｎｖ：ｒｅｌａｙ”が追加される。この場合において、中継ノード宛の各ヘッダ・ブロックは、それが処理不可能である場合に他の中継ノードに転送される。値“ｔｒｕｅ”を伴うオプションの属性“ｅｎｖ：ｍｕｓｔＵｎｄｅｒｓｔａｎｄ”を挿入して、中継ノードが、その役割に意図されたヘッダ・ブロックを、それらの仕様に従って無条件で処理しなければならない旨を示すことができる。一方、ＳＯＡＰメッセージは中継されず、フォールト例外が投じられる（次に説明する）。この特徴は、アプリケーションの包括的な目的に対して重要なヘッダ・ブロックが無視されないことを保証する。
【００６０】
これに対してボディは、レシーバ・ノードによって処理されなければならない必須要素である。通常、ＲＰＣアプリケーションにおいては、レシーバ・ノード上のプロシージャの呼び出しにボディが使用される。この目的から、ボディは、プロシージャへ渡されるべき入力パラメータの値およびＩＤを提供する。それに応答して、レシーバ・ノードは、出力パラメータの値およびＩＤを提供するボディを伴うＳＯＡＰメッセージを返す。ＲＰＣ用のＳＯＡＰは、プロシージャの戻りコードをほかの出力パラメータから区別する方法を提供する。戻りコードは、戻りコードを直接含むか、または（実際の戻りコードを含む）サブエレメント“ｍ：ｓｔａｔｕｓ”を含む要素“ｒｐｃ：ｒｅｓｕｌｔ”によって識別される。
【００６１】
ＳＯＡＰ仕様は、ＳＯＡＰメッセージの処理においてフォールトが生じる状況を取り扱うためのモデルを提供する。この目的から、すべてのフォールトが、ＳＯＡＰメッセージのボディ内の単一要素“ｅｎｖ：Ｆａｕｌｔ”を使用して報告される。要素“ｅｎｖ：Ｆａｕｌｔ”は、２つの必須サブエレメント“ｅｎｖ：Ｃｏｄｅ”および“ｅｎｖ：Ｒｅａｓｏｎ”を含む。要素“ｅｎｖ：Ｃｏｄｅ”は、必須サブエレメント“ｅｎｖ：Ｖａｌｕｅ”（フォールトの標準化された識別子を提供する）およびオプションのサブエレメント“ｅｎｖ：Ｓｕｂｃｏｄｅ”（さらにフォールトを修飾する）からなる。要素“ｅｎｖ：Ｒｅａｓｏｎ”は、フォールトの可読説明を提供する。要素“ｅｎｖ：Ｆａｕｌｔ”は、フォールトを生成したノードを識別するためのサブエレメント“ｅｎｖ：Ｎｏｄｅ”を含むこともできる（これがない場合には、フォールトがレシーバ・ノードによって生成されたことが黙示される）。さらに別のオプションのサブエレメント“ｅｎｖ：Ｒｏｌｅ”は、フォールトを生成したノードによって果たされる役割を指定する。
【００６２】
ＳＯＡＰメッセージは、基礎となる具象トランスポート・プロトコルと結合されなければならない。メッセージ・パスに沿った各ノードについて、トランスポート・プロトコルは、次のノードへの伝達が可能なＳＯＡＰメッセージのシリアル化された表現を提供する（各ノードは、異なるトランスポート・プロトコルをサポートするものであってもよい）。それに加えて、トランスポート・プロトコルは、アプリケーションにとって必要な異なる機能を実装する。特定の機能は、トランスポート・プロトコルによってサポートされているメッセージ交換パターンを定義する。たとえば要求‐応答パターンは、要求として作用するＳＯＡＰメッセージを、応答として作用するＳＯＡＰメッセージへ相関させる機能を提供する（これらのＳＯＡＰメッセージは、２つの隣接するノード間において交換される）。これに対して応答パターンは、対応するＳＯＡＰ応答が次に続く非ＳＯＡＰ要求からなる。またトランスポート・プロトコルは、一般的な機能も提供し、それによってアプリケーションは、レシーバ・ノード上において呼び出される実際のメソッドの選択に関して完全な制御を有することができる。
【００６３】
ＳＯＡＰ仕様は、ＨＴＴＰ等のようなもっとも一般的なトランスポート・プロトコルをサポートしている。ＨＴＴＰは、クライアントがＵＲＩを用いてサーバを識別し、基礎となるＴＣＰ／ＩＰプロトコルを使用してそのサーバとの通信を行い、同じ接続を介してＨＴＴＰ要求を発行し、かつＨＴＴＰ応答を受け取るという通信モデルを提供する。ＨＴＴＰのバインディングは、要求‐応答パターン（ＰＯＳＴウェブ・メソッドを使用）または応答パターン（ＧＥＴウェブ・メソッドを使用）をサポートする。この場合、要求／応答機能がネイティブな方法で提供される（その結果、アプリケーションまたはＳＯＡＰレベルにおいて追加のサポートを求める必要がなくなる）。
【００６４】
ＷＳＤＬドキュメントに戻るが、ＳＯＡＰプロトコルのためのバインディングは、以下の対応する要素内のステートメントによって示される。
【００６５】
＜ｓｏａｐ：ｂｉｎｄｉｎｇ  ｔｒａｎｓｐｏｒｔ＝ｍｙＴｒａｎｓｐｏｒｔ  ｓｔｙｌｅ＝ｍｙＤｅｆａｕｌｔＳｔｙｌｅ＞
【００６６】
属性“ｔｒａｎｓｐｏｒｔ”は、対応するトランスポート・プロトコル（“ｍｙＴｒａｎｓｐｏｒｔ”、たとえばＨＴＴＰ）を示す。以下に説明するように、属性“ｓｔｙｌｅ”は、含まれる各オペレーションのためのデフォルトのスタイル（“ｍｙＤｅｆａｕｌｔＳｔｙｌｅ”）を指定する。
【００６７】
一方、バインディング要素は、対応するポート・タイプによってサポートされる各オペレーションの具体的な定義を含む。このオペレーションに関する情報は、全体として次のステートメントによって提供される。
【００６８】
＜ｏｐｅｒａｔｉｏｎ  ｓｏａｐＡｃｔｉｏｎ＝ｍｙＡｃｔｉｏｎ  ｓｔｙｌｅ＝ｍｙＳｔｙｌｅ＞
【００６９】
属性“ｓｏａｐＡｃｔｉｏｎ”は、オペレーションのために実行されることになる実際のアクション（“ｍｙＡｃｔｉｏｎ”）を指定する。たとえば、ＨＴＴＰのバインディングにおいては、このアクションが対応するＨＴＴＰ要求のヘッダを定義する。属性“ｓｔｙｌｅ”は、オペレーションがＲＰＣ指向であるか（すなわち、入出力パラメータを含んでいるか）またはドキュメント指向であるか（すなわち、１つまたは複数のテキスト・ドキュメントを含んでいるか）を示す。属性“ｓｔｙｌｅ”が指定されていない場合には、要素“ｓｏａｐ：ｂｉｎｄｉｎｇ”内に示されている値がデフォルトになる。この要素がスタイルを指定していない場合には“ｄｏｃｕｍｅｎｔ”であると仮定される。属性“ｓｔｙｌｅ”の値は、ＳＯＡＰメッセージのボディ内において情報がアセンブルされる方法に影響を与える。具体的には、ドキュメント指向オペレーションにおいては、ドキュメントがボディ内に直接埋め込まれる。これに対して、ＲＰＣ指向オペレーションにおいては、各パラメータが、そのパラメータと同じ名前が付けられたラッパーの中に現れる。
【００７０】
各メッセージは、次に示すステートメントによって定義される。
【００７１】
＜ｓｏａｐ：ｂｏｄｙ  ｐａｒｔｓ＝ｍｙＰａｒｔｓ  ｕｓｅ＝ｍｙＵｓｅ
ｅｎｃｏｄｉｎｇＳｔｙｌｅ＝ｍｙＥｎｃｏｄｉｎｇＳｔｙｌｅ  ｎａｍｅｓｐａｃｅ＝ｍｙＮａｍｅｓｐａｃｅ／＞
【００７２】
オプションの属性“ｐａｒｔｓ”は、ボディ内に現れるメッセージ・パーツ（“ｍｙＰａｒｔｓ”）を示す。この属性が省略されている場合には、すべてのメッセージ・パーツがボディ内に含められると見なされる。必須属性“ｕｓｅ”は、メッセージの定義のタイプ（“ｍｙＵｓｅ”）を示す。この属性”ｕｓｅ”は、メッセージがそのメッセージの具象スキーマを定義する場合には値“ｌｉｔｅｒａｌ”を有し、メッセージが、いくつかのエンコーディング規則を使用してシリアル化された抽象仕様を定義する場合には値“ｅｎｃｏｄｅｄ”を有する。属性“ｅｎｃｏｄｉｎｇＳｔｙｌｅ”は、もっとも制限の高い規則からもっとも制限の低い規則まで、エンコーディング規則を識別するＵＲＩのリスト（“ｍｙＥｎｃｏｄｉｎｇＳｔｙｌｅ”）を指定する。属性“ｎａｍｅｓｐａｃｅ”は、エンコーディングに入力されなければならない名前空間（“ｍｙＮａｍｅｓｐａｃｅ”）を提供する。
【００７３】
またバインディングは、エンベロープ内に挿入することのできるヘッダの定義も含む。
【００７４】
＜ｓｏａｐ：ｈｅａｄｅｒ  ｍｅｓｓａｇｅ＝ｍｙＭｅｓｓａｇｅ  ｐａｒｔ＝ｍｙＰａｒｔ  ｕｓｅ＝ｍｙＵｓｅ
ｅｎｃｏｄｉｎｇＳｔｙｌｅ＝ｍｙＥｎｃｏｄｉｎｇＳｔｙｌｅ  ｎａｍｅｓｐａｃｅ＝ｍｙＮａｍｅｓｐａｃｅ／＞
【００７５】
属性“ｍｅｓｓａｇｅ”および“ｐａｒｔ”は、相伴ってヘッダ内に現れるメッセージ・パーツを参照する。属性“ｕｓｅ”、“ｅｎｃｏｄｉｎｇＳｔｙｌｅ”、および“ｎａｍｅｓｐａｃｅ”は、要素“ｂｏｄｙ”における場合と同じ方法で利用される。オプションの要素“ｈｅａｄｅｒｆａｕｌｔ”（要素“ｈｅａｄｅｒ”と同じ構文を有する）は、対応するエラー情報の送信に使用されるヘッダの指定を可能にする。
【００７６】
バインディングは、関連するエンドポイントのアドレスの指定を伴って終了する。
【００７７】
＜ｓｏａｐ：ａｄｄｒｅｓｓ  ｌｏｃａｔｉｏｎ＝ｍｙＬｏｃａｔｉｏｎ／＞
【００７８】
属性“ｌｏｃａｔｉｏｎ”は、エンドポイントを実装するウェブ・サーバのＵＲＩ（“ｍｙＬｏｃａｔｉｏｎ”）を提供する。
【００７９】
ＷＳＤＬ仕様のさらに詳細な説明については非特許文献１、ＳＯＡＰ仕様のさらに詳細な説明については非特許文献２から得ることができる。
【００８０】
図２に示されているように、上記のインフラストラクチャ（スケジューリング・サーバ、実行サーバ、ウェブ・サーバ、およびレジストリ・サーバ）の汎用コンピュータは、システム・バス１４５にパラレルに接続されているいくつかのユニットによって構成される。詳細に述べれば、１つまたは複数のマイクロプロセッサ（μＰ）１５０は、このコンピュータのオペレーションを制御する。ＲＡＭ１５５（通常、インターリーブされたモジュールからなる）は、マイクロプロセッサ１５０によって共有作業メモリとして直接使用され、ＲＯＭ１６０は、コンピュータのブートストラップのための基本コードを格納する。周辺ユニットは、ローカル・バス１６５のまわりに（それぞれのインターフェースを経由して）クラスタ化される。具体的には、大容量メモリは、１つまたは複数のハードディスク１７０、およびＣＤ‐ＲＯＭ１８０を読み出すためのドライバ１７５からなる。またこのコンピュータは、入力デバイス１８５（たとえば、キーボードおよびマウス）、ならびに出力デバイス１９０（たとえば、モニタおよびプリンタ）を含んでいる。ネットワーク・インターフェース・カード（ＮＩＣ）１９５は、コンピュータをインターネットへ接続するために使用される。ブリッジ・ユニット１９６は、システム・バス１４５をローカル・バス１６５にインターフェースする。各マイクロプロセッサ１５０およびブリッジ・ユニット１９６は、情報を送信するためにシステム・バス１４５へのアクセスを要求するマスタ・エージェントとして動作することができる。アービタ１９７は、システム・バス１４５に対する相互排除を伴うアクセスの許可を管理する。
【００８１】
データ処理インフラストラクチャが別のアーキテクチャを有する場合、または各コンピュータが等価の構造を有する場合（たとえば、異なるユニットを伴って）においても類似の考察が当てはまる。さらに、ウェブ・サービスを別のプロトコル（ＨＴＴＰ  ＧＥＴ  ＆  ＰＯＳＴまたはＭＩＭＥ等）と結合すること、またはＳＯＡＰメッセージを異なる方法（たとえば電子メール）で伝達することも可能である。より包括的に言えば、本発明の概念は、ウェブ・サービスが異なる機能を実装しているか、または等価のインターフェース・ドキュメントに従ってアクセス可能である場合においても（異なる言語で定義されている場合であっても）適用可能である。
【００８２】
図３に移って、本発明の方法の実施に使用することのできるメイン・ソフトウエア・コンポーネントが図示されている。情報（プログラムおよびデータ）は、通常、別のハードディスクに格納されており、オペレーティング・システムおよびほかのアプリケーション・プログラム（図中には示されていない）とともにプログラムが実行されているときに、対応する作業メモリへ（少なくとも部分的に）ロードされる。プログラムは、最初にＣＤ‐ＲＯＭからハードディスクへインストールされる。
【００８３】
具体的には、中央スケジューリング・アプリケーションは、異なるジョブの実行を制御する（通常、夜間）。たとえばこれらのジョブは、給与計算プログラム、コスト分析アプリケーションなどからなる。中央スケジューリング・アプリケーションは、ジョブ・スケジューラ２０５および１つまたは複数のエージェント２１０からなり、それらは、対応するサーバにインストールされる。
【００８４】
スケジューラ２０５は、ジョブの実行依頼を管理するためのコントローラ２１５を含む。コントローラ２１５は、各種のジョブに関する情報を格納しているワークロード・データベース２２０へアクセスする。ワークロード・データベース２２０は、それぞれのジョブについて、記述子、実行予定時刻、推定持続時間、およびほかのジョブもしくはシステムのリソースからの依存性を含んでいる。
【００８５】
記述子は、ジョブの実行の制御が委任されるエージェント２１０を識別する。標準的なシナリオにおいては、各エージェント２１０が１つまたは複数の（ローカル）ジョブを直接実行する。この場合、各ローカル・ジョブの記述子が、対応するステップを指定する（ＪＣＬ等の適切な制御言語を使用する）。それに加えて、またはそれに代えて、提案されている解決策は、さらに、ウェブ・サービスの呼び出しを伴う（リモート）ジョブの実行依頼をサポートする。この場合、各リモート・ジョブの記述子が、対応するウェブ・サービスに関係するＷＳＤＬドキュメントを識別する。記述子は、さらに、関連するサービスの名前（ＷＳＤＬドキュメント内に定義されたとおりの名前）を指定する。さらに記述子は、ポート（サービス内）およびオペレーション（ポート内）を識別する。記述子は、さらに、ウェブ・サービスへ渡されるメッセージの内容を定義するペイロード情報を含む。通常、ペイロード情報は、入力パラメータのリストからなる。入力パラメータのいくつかは、ウェブ・サービスを呼び出す前のランタイム時に解決すべき記号変数とすることができる。代替として、ペイロード情報は単純なドキュメントからなっていてもよい。また、記述子は、ウェブ・サービスの呼び出しを許可するためにそのウェブ・サービスによって要求される認証情報（ユーザＩＤおよびパスワード等）を含むことができる。
【００８６】
たとえば、総称リモート・ジョブのための記述子は、次のようなフォーマットを有している。
【００８７】
ａｇｅｎｔ＝ｍｙＡｇｅｎｔ
ＷＳＤＬＤｏｃｕｍｅｎｔ＝ｍｙＷＳＤＬ
ｕｓｅｒｉｄ＝ｍｙＵｓｅｒｉｄ
ｐａｓｓｗｏｒｄ＝ｍｙＰａｓｓｗｏｒｄ
ｓｅｒｖｉｃｅＮａｍｅＳｐａｃｅ＝ｍｙＮａｍｅＳｐａｃｅ
ｓｅｒｖｉｃｅＮａｍｅ＝ｍｙＳｅｒｖｉｃｅ
ｐｏｒｔＮａｍｅ＝ｍｙＰｏｒｔ
ｏｐｅｒａｔｉｏｎＮａｍｅ＝ｍｙＯｐｅｒａｔｉｏｎ
ｍｅｓｓａｇｅＣｏｎｔｅｎｔ＝
＜ｍｙＰａｒａｍｅｔｅｒ＞ｍｙＶａｌｕｅ＜／ｍｙＰａｒａｍｅｔｅｒ＞
・・・・
【００８８】
フィールド“ａｇｅｎｔ”は、関連するエージェントのネットワーク・アドレス（“ｍｙＡｇｅｎｔ”）を提供し、フィールド“ＷＳＤＬＤｏｃｕｍｅｎｔ”は、そのＷＳＤＬドキュメントをポイントするＵＲＩ（“ｍｙＷＳＤＬ”）を指定する。フィールド“ｕｓｅｒｉｄ”および“ｐａｓｓｗｏｒｄ”は、ユーザＩＤ（“ｍｙＵｓｅｒｉｄ”）をそのパスワード（“ｍｙＰａｓｓｗｏｒｄ”）とともに識別する。フィールド“ｓｅｒｖｉｃｅＮａｍｅＳｐａｃｅ”および“ｓｅｒｖｉｃｅＮａｍｅ”は、関連するサービスの名前空間（“ｍｙＮａｍｅＳｐａｃｅ”）および名前（“ｍｙＳｅｒｖｉｃｅ”）をそれぞれ提供し、フィールド“ｐｏｒｔＮａｍｅ”および“ｏｐｅｒａｔｉｏｎＮａｍｅ”は、ポート（“ｍｙＰｏｒｔ”）およびオペレーション（“ｍｙＯｐｅｒａｔｉｏｎ”）を指定する。フィールド“ｍｅｓｓａｇｅＣｏｎｔｅｎｔ”は、ペイロード情報を提供する。各入力パラメータは、同一の名前（“ｍｙＰａｒａｍｅｔｅｒ”）を伴うラッパーの内側に囲い込まれる。入力パラメータは、値または記号変数（たとえば、記号“＄”で開始する名前によって識別される）からなる。
【００８９】
コントローラ２１５は、実行されるべき各ジョブに関する（ワークロード・データベース２２０に格納された）情報をビルダ２２５へ渡す。ビルダ２２５は、所望のシーケンスでジョブのバッチの実行フローを制御するための１つまたは複数のプラン（たとえば２４時間の期間をカバーするプラン）を作成する。それぞれのプランは、いくつかのファクタに従って構築される。通常、実行のフローに影響を与えるファクタは、時間的な値（たとえば、日付け、時間、曜日）および依存性（たとえば、先行ジョブの完了、またはシステム・リソースの可用性）を含む。これらのプランは、対応するリポジトリ２３０内に格納される。リポジトリ２３０から選択されたプランは、コントローラ２１５を介して実行プログラム２３５へ供給される。実行プログラム２３５は、そのプランのジョブの実行を依頼する。この目的から、実行プログラム２３５は、参照番号２４０により示されている、それぞれの実行依頼されるジョブの記述子を（ワークロード・データベース２２０から）検索して、割り当てられたエージェント２１０へ送信する。
【００９０】
各エージェント２１０は、対応するジョブの実行を制御する。具体的には、各ローカル・ジョブのステップは、エージェント２１０によって直接実行される。これに対して、各リモート・ジョブについては、エージェント２１０が対応するウェブ・サービスのＷＳＤＬドキュメント（参照番号２４５により示されている）を、記述子２４０内に指定されているＵＲＩから検索する。以下に説明するように、エージェント２１０は、ＳＯＡＰ要求２５０を構築し、それを呼び出されるべきウェブ・サービス（参照番号２５５により示されている）へ送る。ウェブ・サービス２５５は、ＳＯＡＰ応答２６０をエージェント２１０へ返す（必要な場合）。総称ローカルまたはリモート・ジョブの実行が終了すると（すべてのオペレーションが完了するかエラーが発生したことによって）、対応するエージェント２１０がフィードバック情報をコントローラ２１５へ返す（実行プログラム２３５経由）。このフィードバック情報は、ジョブの実際の開始時刻および終了時刻、オペレーションの結果を指定する戻りコード、ならびにそのジョブによってもたらされた出力データがあればそれを含む。コントローラ２１５は、この情報を使用し、それに応じてワークロード・データベース２２０を更新する。
【００９１】
プログラムおよび対応するデータが別の方法で構成されている場合、異なるモジュールもしくは機能がサポートされている場合、またはプログラムが等価のコンピュータ可読メディア（ＤＶＤ等）で提供される場合においても類似の考察が当てはまる。代替として、ジョブが対応する記述子と異なる方法で（たとえばルックアップ・テーブルを使用して）関連付けられ、ワークロード・データベースが等価の情報を格納し、またはスケジューラが、実行依頼されたジョブの記述子へのポインタを対応するエージェントに渡すだけであってもよい。さらにまた、記述子が異なる構造（たとえば、１つまたは複数の独立のファイルからなる）を有すること、またはペイロード情報が別のフォーマット（それぞれが対応する入力パラメータのためのタイプ／値のペアのリストを伴うもの等）で提供されることも可能である。いずれにしても、本発明は、各種のジョブ、対話式タスク、またはより包括的に任意のほかの作業単位の実行依頼をスケジューリングするための使用に適している。
【００９２】
次に図４〜図６を参照すると、上記のインフラストラクチャで実行される方法３００は、“スケジューラ”の列内の黒い円の開始点３０２から開始する。ブロック３０４へ進むと、所望の（ローカルまたはリモート）のジョブがワークロード・データベース内に定義される（対応する記述子、実行予定時刻、およびほかのジョブまたはリソースからの依存性を入力）。続いてプロセスはブロック３０６へ進み、所望のジョブの実行フローを指定する新しいプランが作成される（または現存するプランが更新される）。これによりコントローラは、ブロック３０８において、プランの実行を依頼することができる。
【００９３】
続くアクティビティのフローは、同時に実行される２つのブランチを含む。第１のブランチは、ブロック３１０〜３１８を含み、第２のブランチはブロック３２０〜３２６を含む。これら２つのブランチは、同心の中黒二重丸の終了点３２８において合流する。
【００９４】
ここで特にブランチ３１０〜３１８を考察すると、実行プログラムがブロック３１０において、実行に使用可能なジョブを（それらの実行予定時刻および依存性に従って）識別する。それぞれの使用可能なジョブについて、関連する記述子が、ブロック３１２においてワークロード・データベースから検索される。ブロック３１４へ進むと、そのジョブの実行を委任されたエージェントが記述子から抽出される。続いてこの方法は、ブロック３１６へ進み、そこで実行プログラムが、そのジョブの実行の要求を関連するエージェントへ送る（この実行の要求は、対応する記述子を含む）。その後実行プログラムは、ブロック３１８においてプランのすべてのジョブの実行依頼が完了したか否かを検証する。完了していなければ、アクティビティのフローはブロック３１０へ戻り、そのプランの、まだ実行依頼の済んでいないジョブについて上記のオペレーションを反復する。これに対して完了しているときには、当該ブランチの実行が終了点３２８で終了する。
【００９５】
同時に、他方のブランチ３２０〜３２６においては、実行プログラムはブロック３２０で待機状態にある。総称ジョブがその実行を終了すると、直ちにブロック３２２において、それぞれのエージェントから対応するフィードバック情報が受け取られる。ブロック３２３へ進み、このフィードバック情報が実行プログラムによってコントローラへ渡され、続いてワークロード・データベースにログされる。さらにコントローラは、ブロック３２４において、ワークロード・データベース内のそのジョブの推定持続時間をそれに応じて更新する。たとえば、推定持続時間は、ジョブの完了したインスタンスに関して測定された値の移動平均として計算することができる（極端に異なる値は変則的なものとしてフィルタリングするのが好ましい）。続いてブロック３２６において、プランのすべてのジョブが終了しているか否かを判断する。終了していなければ、残りのジョブを完了するためにアクティビティのフローはブロック３２０へ戻り、待機する。それに対して終了していれば、このブランチの実行が終了点３２８で終了する。
【００９６】
次に総称エージェントの列に移ると、ジョブの実行の要求に応答して判断ブロック３３０に入る。続いてアクティビティのフローは、ジョブのタイプに従って分岐する。詳細に述べると、ジョブがローカルであればブロック３３２〜３３４が実行され、ジョブがリモートであればブロック３３６〜３７５が実行される；いずれの場合においても、本方法はブロック３７６で合流する。
【００９７】
ブロック３３２（ローカル・ジョブ）について考察すると、記述子の中に指定されているジョブのステップが、エージェントの制御の下に直接実行される。ジョブが完了すると、直ちにそのジョブの戻りコードおよび結果としてもたらされた出力データが、ブロック３３４においてエージェントによって収集される。その後のアクティビティのフローは、直接ブロック３７６まで進む。
【００９８】
これに対して、ジョブがリモートであれば、ブロック３３６においてエージェントが、記述子の中に指定されているＵＲＩから、関連するウェブ・サービスのＷＳＤＬドキュメントをダウンロードする。ブロック３３８へ進み、記述子のペイロード情報内に記号変数がある場合には、それが実際の値に変換される。このようにして獲得されたペイロード情報は、続いてブロック３４０において検証される。言い換えると、エージェントは、ペイロード情報がＷＳＤＬドキュメント内に与えられている対応する定義に準じているか否かの検証を行う。ペイロード情報が形式的に正しいとすると、対応するＳＯＡＰ要求がブロック３４１において（ＷＳＤＬドキュメント内に指定されているｂｉｎｄｉｎｇに従って）構築される。その後このＳＯＡＰ要求が、ブロック３４２においてＨＴＴＰメッセージ内に埋め込まれる。
【００９９】
所望のオペレーションを実行するエンドポイントのアドレスが、ブロック３４４において（ＷＳＤＬドキュメント内に定義されたとおりに）識別される。ブロック３４６へ進み、エージェントがエンドポイントとの接続を開く。それに応答して、そのエンドポイントが認証手続きを必要とする場合には（判断ブロック３５０）、対応する要求がエージェントへ返される。その場合、エージェントは、記述子の中に提供されているユーザＩＤおよびパスワードをブロック３５２においてエンドポイントへ送信する。エンドポイントの列へ戻ると、ブロック３５４において、エージェントから受信された情報によって識別されるユーザが、エンドポイントへのアクセス権を有するか否かが判断される。それを有している場合には、ブロック３５６においてアクセスが許可される。さもなければ、アクセスがブロック３５８において拒否される。いずれの場合においても、認証手続きの結果が、ブロック３５９においてエージェントへ返される。それに応答して、エージェントの列内の判断ブロック３６０へ入る。エンドポイントへのアクセスが拒否された場合には、ブロック３６２においてエージェントが、ジョブの戻りコードをエラー値にセットする。その後プロセスは、直接ブロック３７６まで進む。それに対して、エンドポイントへのアクセスが許可された場合には、アクティビティのフローはブロック３６４へ進む。判断ブロック３５０において、エンドポイントが認証手続きを必要としないと判断された場合も、ブロック３６４へ進む。
【０１００】
ブロック３６４において、ＳＯＡＰ要求がエンドポイントへ向けて送信される。それに応答してエンドポイントは、ブロック３６８においてそのＳＯＡＰ要求を解釈し、所望のウェブ・サービスを呼び出す。エージェントの列に戻ると、本方法は、ブロック３７０においてオペレーションのタイプに応じて分岐する。ＷＳＤＬによってオペレーションが応答を返さないことが指定されている場合には、ジョブの戻りコードが、ブロック３７１においてその完了を示す値にセットされる。応答を返す場合には、エージェントがブロック３７２で待機状態に入る。エンドポイントがＳＯＡＰ応答を返すと（ブロック３７４）、直ちにブロック３７５においてエージェントが、受け取ったメッセージをＷＳＤＬドキュメント内のその定義に従って解釈する。より詳細に述べれば、ウェブ・サービスが期待された出力メッセージを提供する場合には、ジョブの戻りコードが完了値にセットされる。それに対してウェブ・サーバがフォールト・メッセージを提供する場合には、ジョブの戻りコードがエラー値にセットされる。いずれにしても、受け取ったメッセージから抽出された情報が、ジョブの標準出力へダンプされる。その後、アクティビティのフローはブロック３７６において合流する。
【０１０１】
ここでブロック３７６を参照すると、ジョブ（すなわち、ローカル・ジョブのステップまたはウェブ・サービスの呼び出し）の実行に関連するフィードバック情報がスケジューラへ返される（対応する列のブロック３２２を参照されたい）。
【０１０２】
たとえば、ここで次に示すようなＷＳＤＬドキュメント（ＵＲＩ“ｒａｔｅＷＳＤＬ”に格納されている）を考える。
【０１０３】
＜ｄｅｆｉｎｉｔｉｏｎｓ  ｎａｍｅ＝ｒａｔｅＮａｍｅ  ｔａｒｇｅｔＮａｍｅｓｐａｃｅ＝ｒａｔｅＮａｍｅｓｐａｃｅ
＜ｔｙｐｅｓ＞
＜ｓｃｈｅｍａ  ｔａｒｇｅｔＮａｍｅｓｐａｃｅ＝ｒａｔｅＳｃｈｅｍａ
＜ｅｌｅｍｅｎｔ  ｎａｍｅ＝“ｒａｔｅＩｎｐｕｔ”＞
＜ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ａｌｌ＞
＜ｅｌｅｍｅｎｔ  ｎａｍｅ＝“ｃｕｒｒｅｎｃｙ”
ｔｙｐｅ＝“ｓｔｒｉｎｇ”／＞
＜／ａｌｌ＞
＜／ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｅｌｅｍｅｎｔ＞
＜ｅｌｅｍｅｎｔ  ｎａｍｅ＝“ｒａｔｅＯｕｔｐｕｔ”＞
＜ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ａｌｌ＞
＜ｅｌｅｍｅｎｔ  ｎａｍｅ＝“ｒａｔｅ”
ｔｙｐｅ＝“ｆｌｏａｔ”／＞
＜／ａｌｌ＞
＜／ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｅｌｅｍｅｎｔ＞
＜／ｓｃｈｅｍａ＞
＜／ｔｙｐｅｓ＞
＜ｍｅｓｓａｇｅ  ｎａｍｅ＝“ｇｅｔＲａｔｅＩｎｐｕｔ”＞
＜ｐａｒｔ  ｎａｍｅ＝“ｂｏｄｙ”
ｅｌｅｍｅｎｔ＝“ｒａｔｅＩｎｐｕｔ”／＞
＜／ｍｅｓｓａｇｅ＞
＜ｍｅｓｓａｇｅ  ｎａｍｅ＝“ｇｅｔＲａｔｅＯｕｔｐｕｔ”＞
＜ｐａｒｔ  ｎａｍｅ＝“ｂｏｄｙ”
ｅｌｅｍｅｎｔ＝“ｒａｔｅＯｕｔｐｕｔ”／＞
＜／ｍｅｓｓａｇｅ＞
＜ｐｏｒｔＴｙｐｅ  ｎａｍｅ＝“ｒａｔｅＰｏｒｔＴｙｐｅ”＞
＜ｏｐｅｒａｔｉｏｎ  ｎａｍｅ＝“ｇｅｔＲａｔｅ”＞
＜ｉｎｐｕｔ  ｍｅｓｓａｇｅ＝“ｇｅｔＲａｔｅＩｎｐｕｔ”／＞
＜ｏｕｔｐｕｔ  ｍｅｓｓａｇｅ＝“ｇｅｔＲａｔｅＯｕｔｐｕｔ”／＞
＜／ｏｐｅｒａｔｉｏｎ＞
＜／ｐｏｒｔＴｙｐｅ＞
＜ｂｉｎｄｉｎｇ  ｎａｍｅ＝“ｒａｔｅＢｉｎｄｉｎｇ”  ｔｙｐｅ＝“ｒａｔｅＰｏｒｔＴｙｐｅ”＞
＜ｓｏａｐ：ｂｉｎｄｉｎｇ  ｓｔｙｌｅ＝“ｄｏｃｕｍｅｎｔ”  ｔｒａｎｓｐｏｒｔ＝“ｈｔｔｔ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ．ｓｏａｐ／ｈｔｔｐ”／＞
＜ｏｐｅｒａｔｉｏｎ  ｎａｍｅ＝“ｇｅｔＲａｔｅ”＞
＜ｓｏａｐ：ｏｐｅｒａｔｉｏｎ  ｓｏａｐＡｃｔｉｏｎ＝ｍｙＡｃｔｉｏｎ／＞
＜ｉｎｐｕｔ＞
＜ｓｏａｐ：ｂｏｄｙ  ｕｓｅ＝“ｌｉｔｅｒａｌ”／＞
＜／ｉｎｐｕｔ＞
＜ｏｕｔｐｕｔ＞
＜ｓｏａｐ：ｂｏｄｙ  ｕｓｅ＝“ｌｉｔｅｒａｌ”／＞
＜／ｏｕｔｐｕｔ＞
＜／ｏｐｅｒａｔｉｏｎ＞
＜／ｂｉｎｄｉｎｇ＞
＜ｓｅｒｖｉｃｅ  ｎａｍｅ＝“ｒａｔｅＳｅｒｖｉｃｅ”＞
＜ｄｏｃｕｍｅｎｔａｔｉｏｎ＞
Ｒｅｔｕｒｎ  ｔｈｅ  ｅｘｃｈａｎｇｅ  ｒａｔｅ  ｏｆ  ａ  ｄｅｓｉｒｅｄ  ｃｕｒｒｅｎｃｙ
＜／ｄｏｃｕｍｅｎｔａｔｉｏｎ＞
＜ｐｏｒｔ  ｎａｍｅ＝“ｒａｔｅＰｏｒｔ”  ｂｉｎｄｉｎｇ＝”ｒａｔｅＢｉｎｄｉｎｇ”＞
＜ｓｏａｐ：ａｄｄｒｅｓｓ  ｌｏｃａｔｉｏｎ＝“ｒａｔｅＬｏｃａｔｉｏｎ”／＞
＜／ｐｏｒｔ＞
＜／ｓｅｒｖｉｃｅ＞
＜／ｄｅｆｉｎｉｔｉｏｎｓ＞
【０１０４】
ＷＳＤＬドキュメント（“ｒａｔｅＮａｍｅｓｐａｃｅ”の“ｒａｔｅＮａｍｅ”）は、ＨＴＴＰを介するＳＯＡＰを使用して、アドレス“ｒａｔｅＬｏｃａｔｉｏｎ”のエンドポイントによって提供される、非常に単純なサービス（“ｒａｔｅＳｅｒｖｉｃｅ”）を定義する。サービス“ｒａｔｅＳｅｒｖｉｃｅ”は、バインディング“ｒａｔｅＢｉｎｄｉｎｇ”を伴うポート“ｒａｔｅＰｏｒｔ”を含む。ポート“ｒａｔｅＰｏｒｔ”は、オペレーション“ｇｅｔＲａｔｅ”をサポートする。オペレーション“ｇｅｔＲａｔｅ”は、選択された通貨を表す文字列型の入力パラメータ“ｒａｔｅＩｎｐｕｔ”を含むＳＯＡＰ要求（“ｇｅｔＲａｔｅＩｎｐｕｔ”）を受け取り、その為替レートを表す浮動小数点型の出力パラメータ“ｒａｔｅＯｕｔｐｕｔ”を返す（両方のパラメータは、スキーマ“ｒａｔｅＳｃｈｅｍａ”に準じている）。
【０１０５】
上記のウェブ・サービスを（たとえば毎日の）実行のためにスケジュールしなければならない場合には、対応するジョブをワークロード・データベース内に定義する。たとえば、そのジョブの記述子は、次のような情報を含む。
【０１０６】
ａｇｅｎｔ＝ｒａｔｅＡｇｅｎｔ
ＷＳＤＬＤｏｃｕｍｅｎｔ＝ｒａｔｅＷＳＤＬ
ｕｓｅｒｉｄ＝ｒａｔｅＵｓｅｒｉｄ
ｐａｓｓｗｏｒｄ＝ｒａｔｅＰａｓｓｗｏｒｄ
ｓｅｒｖｉｃｅＮａｍｅｓｐａｃｅ＝ｒａｔｅＮａｍｅｓｐａｃｅ
ｓｅｒｖｉｃｅＮａｍｅ＝ｒａｔｅＳｅｒｖｉｃｅ
ｐｏｒｔＮａｍｅ＝ｒａｔｅＰｏｒｔ
ｏｐｅｒａｔｉｏｎＮａｍｅ＝ｇｅｔＲａｔｅ
ｍｅｓｓａｇｅＣｏｎｔｅｎｔ＝＜ｒａｔｅＩｎｐｕｔ＞＄ＶＡＲ＜／ｒａｔｅＩｎｐｕｔ＞
【０１０７】
考察中の例において、入力パラメータ“ｒａｔｅＩｎｐｕｔ”は、記号変数（“＄ＶＡＲ”）によって定義されており、これは、ウェブ・サービスが呼び出されるたびに、所望の通貨の識別子にセットされる。
【０１０８】
ジョブは、毎回異なる通貨について実行するために反復してスケジュールされる。リモート・ジョブが実行依頼されるときには、スケジューラは常に、関連するエージェント“ｒａｔｅＡｇｅｎｔ”へ記述子を送る。エージェントは、記号変数“＄ＶＡＲ”を実際の値（たとえば“ＵＳＤ”（米ドル））へ変換する。続いて対応するＳＯＡＰ要求が作られ、次のようなＨＴＴＰメッセージ内に埋め込まれる。
【０１０９】
ＰＯＳＴ
Ｈｏｓｔ：  ｒａｔｅＬｏｃａｔｉｏｎ
Ｃｏｎｔｅｎｔ‐Ｔｙｐｅ：  ｔｅｘｔ／ｘｍｌ；  ｃｈａｒｓｅｔ＝“ｕｔｆ‐８”
Ｃｏｎｔｅｎｔ‐Ｌｅｎｇｔｈ：  ．．．
ＳｏａｐＡｃｔｉｏｎ：  ｍｙＡｃｔｉｏｎ
＜ＣＲＬＦ＞
＜ｅｎｖ：Ｅｎｖｅｌｏｐｅ
ｘｍｌｓ：ｅｎｖ＝“ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｓｏａｐ／ｅｎｖｅｌｏｐｅ／”＞
＜ｅｎｖ：Ｂｏｄｙ＞
＜ｍ：ｇｅｔＲａｔｅＩｎｐｕｔ  ｘｍｌｎｓ：ｍ＝ｒａｔｅＮａｍｅｓｐａｃｅ＞
＜ｍ：ｃｕｒｒｅｎｃｙ＞ＵＳＤ＜／ｍ：ｃｕｒｒｅｎｃｙ＞
＜／ｍ：ｇｅｔＲａｔｅＩｎｐｕｔ＞
＜／ｅｎｖ：Ｂｏｄｙ＞
＜／ｅｎｖ：Ｅｎｖｅｌｏｐｅ＞
＜ＣＲＬＦ＞
【０１１０】
エージェントは、続いてエンドポイント“ｒａｔｅＬｏｃａｔｉｏｎ”とのＨＴＴＰ接続を開く。エンドポイントからの対応する要求に応答して、エージェントは、ユーザＩＤ“ｒａｔｅＵｓｅｒｉｄ”および対応するパスワード“ｒａｔｅＰａｓｓｗｏｒｄ”を提供する。その後、上記のＨＴＴＰメッセージが送信される。ＷＳＤＬドキュメントは、ウェブ・サービスが応答を返さなければならないことを指定している。したがって、エージェントは、次に示すフォーマットのＨＴＴＰメッセージを待つ。
【０１１１】
Ｃｏｎｔｅｎｔ‐Ｔｙｐｅ：  ｔｅｘｔ／ｘｍｌ；  ｃｈａｒｓｅｔ＝“ｕｔｆ‐８”
Ｃｏｎｔｅｎｔ‐Ｌｅｎｇｔｈ：  ．．．
＜ＣＲＬＦ＞
＜ｅｎｖ：Ｅｎｖｅｌｏｐｅ
ｘｍｌｓ：ｅｎｖ＝“ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｓｏａｐ／ｅｎｖｅｌｏｐｅ／”＞
＜ｅｎｖ：Ｂｏｄｙ＞
＜ｍ：ｇｅｔＲａｔｅＯｕｔｐｕｔ  ｘｍｌｎｓ：ｍ＝ｒａｔｅＮａｍｅｓｐａｃｅ＞
＜ｍ：ｒａｔｅ＞１．１８７５＜／ｍ：ｒａｔｅ＞
＜／ｍ：ｇｅｔＲａｔｅＯｕｔｐｕｔ＞
＜／ｅｎｖ：Ｂｏｄｙ＞
＜／ｅｎｖ：Ｅｎｖｅｌｏｐｅ＞
＜ＣＲＬＦ＞
【０１１２】
このＨＴＴＰメッセージ内のＳＯＡＰ応答は、エラーが生じていないことを示しており、また出力パラメータ“ｒａｔｅ”内において所望の通貨に関する為替レートの値（１．１８７５）を返す。
【０１１３】
等価の方法が実行される場合、またはいくつかの機能が異なるモジュールによって実行される場合においても、類似の考察が当てはまる。しかしながら、本発明の概念は、ウェブ・サービスが別のタイプのオペレーションを実装している場合、エージェントが異なる手続き（たとえば、ディジタル証明書の使用を伴う手続き）で検証される場合などにも適用することができる。
【０１１４】
より一般的に述べれば、本発明は、分散アーキテクチャを有するデータ処理インフラストラクチャにおける作業単位の実行をスケジューリングする方法を提案する。本方法は中央スケジューリング・アプリケーションの制御の下に実行される一連のステップを含み、１つまたは複数の作業単位を記述子と関連付けることから開始する。記述子は、事前定義インターフェース・ドキュメントに従ってアクセス可能な外部サービスの表示を含む。続いて、事前定義プランに従った作業単位の実行が依頼される。本方法は、実行依頼された作業単位に関連付けられているそれぞれの外部サービスのインターフェース・ドキュメントの検索を続ける。その後、実行依頼された作業単位に関連付けられているそれぞれの外部サービスについて、対応するインターフェース・ドキュメントに従って要求メッセージを構築する。本方法は、外部サービスを呼び出すために、それぞれの要求メッセージを対応する外部サービスへ送ると終了する。
【０１１５】
提案されている解決策は、スケジューラによる外部サービスの管理を可能にする。
【０１１６】
特にこれは、非常に単純な方法でスケジューラが外部サービスを呼び出すことを可能にする。
【０１１７】
したがって、本発明の方法は、異機種環境での使用に充分に適している。
【０１１８】
本発明の技法は、スケジューラと外部サービスの統合をサポートする。
【０１１９】
このように、スケジューラ内においてすでに利用可能な追加の機能を、外部サービスの管理のために容易に利用することができる。たとえば、時間および先行ジョブの制約を扱うこと、ＧＵＩを介してスケジューラによって実行されているオペレーションを制御し、モニタすること、またはパフォーマンス・モニタ機能、負荷平準化機能、および報告機能を利用することが（別の機能を提供するスケジューラとの併用を排除しない場合であっても）可能になる。
【０１２０】
前述した本発明の好ましい実施態様は、さらに別の利点を提供する。
【０１２１】
具体的には、ウェブ・サーバは、応答メッセージをエージェントへ返す（この応答メッセージは、対応するＷＳＤＬドキュメント内のその定義に従って解釈される）。
【０１２２】
これによれば、スケジューラとウェブ・サーバの間において完全な通信ループが閉じられる。
【０１２３】
都合のよいことに、要求メッセージの内容が記述子の中に含められ、続いてそれが、関連するＷＳＤＬドキュメント内に指定されている対応する構造の中に埋め込まれる。
【０１２４】
提案されている技法は、非常にシンプルであるが、同時に効果的でもある。
【０１２５】
さらに別の強化として、要求メッセージの内容が１つまたは複数の記号変数を含み、それらがランタイム時に実際の値に変換される。
【０１２６】
この機能は、本方法の柔軟性を高める（たとえば、同一のウェブ・サービスが異なる入力パラメータで繰り返し呼び出されるといったことが可能になる）。
【０１２７】
しかしながら本発明に従った解決策は、ウェブ・サービスが応答メッセージをまったく返さない場合であっても実施可能である。代替として、要求メッセージが、異なる方法で構築される。たとえば、本発明の別の実施態様においては、記述子が実際の要求メッセージを直接格納する（これは、単純にエージェントによって検索され、対応するウェブ・サービスへ渡される）。さらに、記号変数がスケジューラによって変換されることも可能であり、また記述子の中に格納されている要求メッセージの内容が、静的な入力パラメータだけから構成されることも可能である。
【０１２８】
本発明の好ましい実施形態においては、ジョブの実行依頼がスケジューラによって制御され、それらの実際の実行が１つまたは複数のエージェントによって制御される。
【０１２９】
提案されているアーキテクチャは、既存のスケジューラの利用を可能にする（ウェブ・サービスの呼び出しのために、単に特定のジョブをワークロード・データベース内に定義するだけ）。その代わりとして、ウェブ・サービスとの対話を制御するタスクは、標準のインフラストラクチャに簡単にプラグインできるエージェントに任される。
【０１３０】
各リモート・ジョブと、対応するウェブ・サーバのＷＳＤＬドキュメントを関連付けるための、提案されている選択肢は、それぞれの記述子の中にそのアドレスを格納することからなる。
【０１３１】
この機能は、エージェントが常に、所望のＷＳＤＬドキュメントの最新バージョンへアクセスすることを保証する。
【０１３２】
解決策をさらに改良する方法は、認証情報を記述子に含ませることであり、この認証情報は、その後ウェブ・サーバによって、エージェントによるその呼び出しを許可するために使用される。
【０１３３】
このようにして、ウェブ・サービスのスケジューリングを、セキュリティの懸念をまったく伴うことなく完全に自動化することができる。
【０１３４】
本発明の方法は、その一般的な適用可能性を減ずることなしに、特にウェブ・サービスを呼び出すために設計することができる。
【０１３５】
実際、この解決策は、インターネット上における分散コンピューティングへの移行における重要なステップとなる。特に、本発明の方法はインターネットの完全な利用を容易にする（たとえば、サード・パーティによって提供されるウェブ・サービスを伴うレガシー・アプリケーションの相互運用を可能にする）。
【０１３６】
しかしながら本発明に従った解決策は、異なるアーキテクチャ（たとえば、処理ロジック全体がスケジューラ内に埋め込まれているアーキテクチャ）を有するスケジューリング・アプリケーションを伴う実施にも適している。代替として、ＷＳＤＬドキュメントのコピーがローカルに格納される（かつ、対応するアドレスが記述子の中で指定される）か、またはＷＳＤＬドキュメントが記述子に直接埋め込まれる。たとえば、このアプローチは、いくつかのウェブ・サービスのＷＳＤＬドキュメントがインターネットで公開されていない場合に有用となり得る。いずれにしても、提案されている方法は、異なる標準化されたサービス（ＥＤＩ仕様に準拠するサービス等）、またはより一般的に、任意の外部サービスのスケジューリングにも適用可能である。
【０１３７】
好都合なことに、本発明に従った解決策は、適切な媒体に実装された製品として提供されるコンピュータ・プログラムを用いて実施することができる。
【０１３８】
代替として、プログラムをハードディスク上にあらかじめロードしておくことインターネットを介してコンピュータへ送信すること、ブロードキャストすること、またはより一般的に、コンピュータの作業メモリ内へ直接ロード可能なそのほかの任意の形式で提供することが可能である。しかしながら、本発明の方法は、ハードウエア構造（たとえば、半導体材料のチップ内に集積される）、またはソフトウエアとハードウエアの組み合わせを用いて実施することができる。
【図面の簡単な説明】
【０１３９】
【図１】本発明の方法が適用できるデータ処理インフラストラクチャの概略ブロック図である。
【図２】インフラストラクチャの汎用コンピュータの機能ブロック図である。
【図３】この方法の実施に使用することのできる主要なソフトウエア・コンポーネントを示したブロック図である。
【図４】例示したこの方法の実施に関係するアクティビティのフローの一部を示したフローチャートである。
【図５】例示したこの方法の実施に関係するアクティビティのフローの一部を示したフローチャートである。
【図６】例示したこの方法の実施に関係するアクティビティのフローの一部を示したフローチャートである。
【図１】
2005196767.tif 000003
【図２】
2005196767.tif 000004
【図３】
2005196767.tif 000005
【図４】
2005196767.tif 000006
【図５】
2005196767.tif 000007
【図６】
2005196767.tif 000008