JP2005196767A - ウェブ・サービス呼び出しをサポートするスケジューラ - Google Patents

ウェブ・サービス呼び出しをサポートするスケジューラ Download PDF

Info

Publication number
JP2005196767A
JP2005196767A JP2004369823A JP2004369823A JP2005196767A JP 2005196767 A JP2005196767 A JP 2005196767A JP 2004369823 A JP2004369823 A JP 2004369823A JP 2004369823 A JP2004369823 A JP 2004369823A JP 2005196767 A JP2005196767 A JP 2005196767A
Authority
JP
Japan
Prior art keywords
external service
message
execution
work
request message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004369823A
Other languages
English (en)
Other versions
JP3965185B2 (ja
Inventor
Fabio Benedetti
ファヴィオ・ヴェネデッティ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2005196767A publication Critical patent/JP2005196767A/ja
Application granted granted Critical
Publication of JP3965185B2 publication Critical patent/JP3965185B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

【課題】 スケジューラによる外部サービスの管理を可能にする。
【解決手段】 スケジューラ２０５は、実行エージェント２１０および記述子２４０をそれぞれの実行依頼されることになるジョブと関連付けるワークロード・データベース２２０へアクセスする。記述子は、所望のウェブ・サービス２５５および対応するＷＳＤＬドキュメント２４５のアドレスを識別する。ジョブの実行が依頼されるときには、スケジューラがその記述子を関連付けられたエージェントへ送る。エージェントは、対応するウェブ・サービスのＷＳＤＬドキュメントをダウンロードする。続いてそのウェブ・サービスのための要求メッセージ２５０が構築され、所望の内容がＷＳＤＬドキュメント内に指定された構造の中に埋め込まれる。この要求メッセージを、そのウェブ・サービスを実装しているエンドポイントへ送り、そのウェブ・サービスが呼び出される。
【選択図】図３

Description

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

Claims (11)

  1. 分散アーキテクチャを有するデータ処理インフラストラクチャ内における作業単位の実行を中央スケジューリング・アプリケーションの制御の下にスケジューリングする方法であって、
    前記作業単位の少なくとも１つと、事前定義インターフェース・ドキュメントに従ってアクセス可能な外部サービスの表示を含む記述子を関連付けるステップ（３０４）、
    事前定義プランに従った前記作業単位の実行を依頼するステップ（３０８）、
    実行依頼された作業単位に関連付けられたそれぞれの外部サービスのインターフェース・ドキュメントを検索するステップ（３３６）、
    前記実行依頼された作業単位に関連付けられたそれぞれの外部サービスのための要求メッセージを、対応するインターフェース・ドキュメントに従って構築するステップ（３３８〜３４２）、および、
    前記外部サービスの呼び出しを生じさせるために各要求メッセージを対応する外部サービスへ送るステップ（３６４）、
    を含む方法（３００）。
  2. さらに、
    呼び出された各外部サービスから応答メッセージを受け取るステップ（３７０）、および、
    各応答メッセージを、対応するインターフェース・ドキュメントに従って解釈するステップ（３７５）、
    を含む請求項１に記載の方法（３００）。
  3. 前記インターフェース・ドキュメントは、各メッセージの構造を指定し、前記記述子は、さらに前記要求メッセージの内容の表示を含み、前記要求メッセージを構築するステップ（３３８〜３４２）は、
    前記要求メッセージの内容を対応する構造内に埋め込むステップ（３４１〜３４２）、
    を含む請求項１または２に記載の方法（３００）。
  4. 前記要求メッセージの内容の表示は、前記外部サービスへ渡されるべき一組の入力パラメータを含み、その少なくとも１つの入力パラメータは記号変数であり、前記要求メッセージを構築するステップ（３３８〜３４２）は、さらに、
    各記号変数を実際の値に変換するステップ（３３８）、
    を含む請求項３に記載の方法（３００）。
  5. 前記中央スケジューリング・アプリケーションは、スケジューラ、および少なくとも１つのエージェントを含み、前記スケジューラは前記関連付けるステップ（３０４）および実行を依頼するステップ（３０８）を実行し、各記述子は、さらに、対応する作業単位に関連付けられたエージェントの表示を含み、前記方法がさらに、
    前記スケジューラが、それぞれの実行依頼された作業単位の実行の要求であって、対応する記述子の表示を含む実行の要求を関連付けられたエージェントへ送るステップ（３１６）、および
    前記エージェントが、対応する外部サービスのインターフェース・ドキュメントを検索し（３３６）、前記外部サービスのための要求メッセージを構築し（３３８〜３４２）、かつ前記実行の要求に応答して前記要求メッセージを前記外部サービスへ送る（３６４）ステップ、
    を含む、請求項１〜４のいずれかに記載の方法（３００）。
  6. 前記インターフェース・ドキュメントの表示は、前記インフラストラクチャ内の、前記インターフェース・ドキュメントを格納している外部の場所のアドレスからなり、前記インターフェース・ドキュメントを検索するステップは、
    対応する前記外部の場所から前記インターフェース・ドキュメントをダウンロードするステップ（３３６）を含む、請求項１〜５のいずれかに記載の方法（３００）。
  7. 前記記述子は、外部サービスについての認証情報を含み、前記方法は、さらに、
    前記外部サービスへ前記認証情報を送るステップ（３５２）を含み、前記認証情報に従って前記外部サービスの呼び出しが許可される、請求項１〜６のいずれかに記載の方法。
  8. 前記外部サービスがウェブ・サービスである、請求項１〜７のいずれかに記載の方法。
  9. データ処理システム（１０５、１１０）の作業メモリ内に直接ロード可能なコンピュータ・プログラムであって、請求項１〜８のいずれかに記載された方法をコンピュータに実行させるためのコンピュータ・プログラム（２０５、２１０）。
  10. 分散アーキテクチャを有するデータ処理インフラストラクチャ（１００）内における作業単位の実行をスケジューリングするためのシステムであって、前記作業単位の少なくとも１つと、事前定義インターフェース・ドキュメントに従ってアクセス可能な外部サービスの表示を含む記述子を関連付けるための手段（２２０）、事前定義プランに従った前記作業単位の実行を依頼するための手段（２０５）、実行依頼された作業単位に関連付けられたそれぞれの外部サービスのインターフェース・ドキュメントを検索するための手段（２１０）、前記実行依頼された作業単位に関連付けられたそれぞれの外部サービスのための要求メッセージを、対応するインターフェース・ドキュメントに従って構築するための手段（２１０）、および、前記外部サービスの呼び出しを生じさせるために各要求メッセージを対応する外部サービスへ送るための手段（２１０）を有する中央スケジューリング・アプリケーション（２０５、２１０）を含むシステム（１０５、１１０）。
  11. 請求項１０に従ったシステム（１０５、１１０）および、それぞれの外部サービスを実装するための少なくとも１つの外部サーバ（１２０）を含む、分散アーキテクチャを有するデータ処理インフラストラクチャ（１００）。
JP2004369823A 2003-12-30 2004-12-21 ウェブ・サービス呼び出しをサポートするスケジューラ Active JP3965185B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP03368129 2003-12-30

Publications (2)

Publication Number Publication Date
JP2005196767A true JP2005196767A (ja) 2005-07-21
JP3965185B2 JP3965185B2 (ja) 2007-08-29

Family

ID=34707291

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004369823A Active JP3965185B2 (ja) 2003-12-30 2004-12-21 ウェブ・サービス呼び出しをサポートするスケジューラ

Country Status (3)

Country Link
US (2) US7404189B2 (ja)
JP (1) JP3965185B2 (ja)
CN (1) CN100356329C (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007122189A (ja) * 2005-10-25 2007-05-17 Canon Inc スケジュール実行装置及びプログラム
JP2009223439A (ja) * 2008-03-13 2009-10-01 Canon Inc メッセージ生成処理方法及びメッセージ生成処理装置

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100153183A1 (en) * 1996-09-20 2010-06-17 Strategyn, Inc. Product design
US7099037B2 (en) * 2003-04-22 2006-08-29 Lightning Source Inc. N-up printing
CN1620060B (zh) * 2003-11-17 2010-04-28 国际商业机器公司 把浏览器不兼容的信息整合在网络内容中以及显示该信息的方法和设备
US8171474B2 (en) * 2004-10-01 2012-05-01 Serguei Mankovski System and method for managing, scheduling, controlling and monitoring execution of jobs by a job scheduler utilizing a publish/subscription interface
US9760647B2 (en) * 2004-12-08 2017-09-12 Oracle International Corporation Techniques for automatically exposing, as web services, procedures and functions stored in a database
US7983209B2 (en) * 2005-04-18 2011-07-19 Research In Motion Limited System and method for producing notification based web services
US8464317B2 (en) * 2005-05-06 2013-06-11 International Business Machines Corporation Method and system for creating a protected object namespace from a WSDL resource description
US7877350B2 (en) * 2005-06-27 2011-01-25 Ab Initio Technology Llc Managing metadata for graph-based computations
US8156500B2 (en) * 2005-07-01 2012-04-10 Microsoft Corporation Real-time self tuning of planned actions in a distributed environment
US7590935B2 (en) * 2005-07-08 2009-09-15 Microsoft Corporation Dynamic generation of WSDL documents based on database metadata
CN100383731C (zh) * 2005-08-25 2008-04-23 复旦大学 一个Web Services的实时、动态合成方法
US7603474B2 (en) 2005-10-05 2009-10-13 Microsoft Corporation Efficient endpoint matching using a header-to-bit conversion table
CN100571167C (zh) * 2006-02-24 2009-12-16 国际商业机器公司 Web服务业务流程的单元测试的方法和设备
US7739698B2 (en) * 2006-05-25 2010-06-15 International Business Machines Corporation Multiplatform API usage tool
AU2007286155B2 (en) * 2006-08-10 2013-12-12 Ab Initio Technology Llc. Distributing services in graph-based computations
GB0623904D0 (en) * 2006-11-30 2007-01-10 Ibm A method,apparatus and computer program for modifying an endpointreference representing a web service endpoint
KR100880536B1 (ko) * 2007-01-05 2009-01-28 아주대학교산학협력단 이기종 컴퓨팅 및 서비스 통합을 위한 오픈 프레임워크시스템
US7958188B2 (en) * 2007-05-04 2011-06-07 International Business Machines Corporation Transaction-initiated batch processing
US7797340B2 (en) * 2007-06-15 2010-09-14 Samsung Electronics Co., Ltd. Method and system for searchable web services
KR101635945B1 (ko) * 2007-07-26 2016-07-04 아브 이니티오 테크놀로지 엘엘시 에러 핸들링이 가능한 그래프 기반의 트랜잭션 연산 처리 방법 및 시스템
US8214244B2 (en) 2008-05-30 2012-07-03 Strategyn, Inc. Commercial investment analysis
WO2009126591A1 (en) 2008-04-07 2009-10-15 Express Mobile, Inc. Systems and methods for programming mobile devices
US8949713B1 (en) 2008-06-30 2015-02-03 Amazon Technologies, Inc. Version-specific request processing
US8266477B2 (en) 2009-01-09 2012-09-11 Ca, Inc. System and method for modifying execution of scripts for a job scheduler using deontic logic
US8832173B2 (en) * 2009-01-20 2014-09-09 Sap Ag System and method of multithreaded processing across multiple servers
CN105843684B (zh) 2009-02-13 2020-03-03 起元技术有限责任公司 管理任务执行
US8666977B2 (en) 2009-05-18 2014-03-04 Strategyn Holdings, Llc Needs-based mapping and processing engine
US8296774B2 (en) * 2009-06-26 2012-10-23 Microsoft Corporation Service-based endpoint discovery for client-side load balancing
US8667329B2 (en) * 2009-09-25 2014-03-04 Ab Initio Technology Llc Processing transactions in graph-based applications
CN101853156B (zh) * 2010-05-12 2013-07-17 上海普元信息技术股份有限公司 构件化软件系统中实现Web Service调用的方法
CN107066241B (zh) 2010-06-15 2021-03-09 起元技术有限责任公司 用于动态加载基于图的计算的系统和方法
US20130103767A1 (en) * 2011-10-21 2013-04-25 Microsoft Corporation Return notifications of tasks performed with entities
US8949429B1 (en) * 2011-12-23 2015-02-03 Amazon Technologies, Inc. Client-managed hierarchical resource allocation
US10108521B2 (en) 2012-11-16 2018-10-23 Ab Initio Technology Llc Dynamic component performance monitoring
US9507682B2 (en) 2012-11-16 2016-11-29 Ab Initio Technology Llc Dynamic graph performance monitoring
US9274926B2 (en) 2013-01-03 2016-03-01 Ab Initio Technology Llc Configurable testing of computer programs
US20150074678A1 (en) * 2013-09-09 2015-03-12 Avraham Vachnis Device and method for automating a process of defining a cloud computing resource
US10180821B2 (en) 2013-12-05 2019-01-15 Ab Initio Technology Llc Managing interfaces for sub-graphs
TW201539218A (zh) * 2014-02-17 2015-10-16 Microsoft Technology Licensing Llc 與外部內容項目之間的編碼的關聯性
US9948698B2 (en) 2015-06-04 2018-04-17 International Business Machines Corporation Web services documentation
US10657134B2 (en) 2015-08-05 2020-05-19 Ab Initio Technology Llc Selecting queries for execution on a stream of real-time data
US10671669B2 (en) 2015-12-21 2020-06-02 Ab Initio Technology Llc Sub-graph interface generation
US11971860B2 (en) 2015-12-28 2024-04-30 Dropbox, Inc. Embedded folder views
US11741300B2 (en) 2017-11-03 2023-08-29 Dropbox, Inc. Embedded spreadsheet data implementation and synchronization
CN109522139B (zh) * 2018-11-23 2021-04-27 杭州数梦工场科技有限公司 一种数据表服务生成调用方法、装置、设备及存储介质
US10514949B1 (en) * 2018-12-11 2019-12-24 Signals Analytics Ltd. Efficient data processing in a serverless environment

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2692058B1 (fr) * 1992-06-09 1994-07-29 Bull Sa Systeme de traitement transactionnel entre un serveur informatique et une pluralite de stations de travail.
GB2302966A (en) * 1995-06-30 1997-02-05 Ibm Transaction processing with a reduced-kernel operating system
WO1997049039A1 (en) * 1996-06-21 1997-12-24 Bell Communications Research, Inc. Apparatus and methods for highly available directory services in the distributed computing environment
US5790789A (en) * 1996-08-02 1998-08-04 Suarez; Larry Method and architecture for the creation, control and deployment of services within a distributed computer environment
US6247056B1 (en) 1997-02-03 2001-06-12 Oracle Corporation Method and apparatus for handling client request with a distributed web application server
AU735024B2 (en) * 1997-07-25 2001-06-28 British Telecommunications Public Limited Company Scheduler for a software system
US6256771B1 (en) * 1997-10-16 2001-07-03 At&T Corp. Method and apparatus for providing a dynamic service composition software architecture
WO1999044123A1 (en) * 1998-02-26 1999-09-02 Sun Microsystems, Inc. Downloadable smart proxies for performing processing associated with a remote procedure call in a distributed system
US6237005B1 (en) * 1998-06-29 2001-05-22 Compaq Computer Corporation Web server mechanism for processing multiple transactions in an interpreted language execution environment
US6282697B1 (en) * 1998-09-18 2001-08-28 Wylci Fables Computer processing and programming method using autonomous data handlers
US7386586B1 (en) * 1998-12-22 2008-06-10 Computer Associates Think, Inc. System for scheduling and monitoring computer processes
GB2346990B (en) * 1999-02-20 2003-07-09 Ibm Client/server transaction data processing system with automatic distributed coordinator set up into a linear chain for use of linear commit optimization
US6363065B1 (en) * 1999-11-10 2002-03-26 Quintum Technologies, Inc. okApparatus for a voice over IP (voIP) telephony gateway and methods for use therein
US6573910B1 (en) * 1999-11-23 2003-06-03 Xerox Corporation Interactive distributed communication method and system for bidding on, scheduling, routing and executing a document processing job
US20020161814A1 (en) * 2000-10-04 2002-10-31 Wical Kelly J. Batch processing system running in parallel on automated and distributed replication systems
US8812666B2 (en) * 2001-01-29 2014-08-19 Da Capital Fund Limited Liability Company Remote proxy server agent
US7099938B2 (en) * 2001-03-23 2006-08-29 Hewlett-Packard Development Company, L.P. Method, computer system, and computer program product for monitoring services of an information technology environment
US20050155042A1 (en) * 2001-07-02 2005-07-14 Michael Kolb Component-based system for distributed applications
US7124415B1 (en) * 2001-07-11 2006-10-17 Redback Networks Inc. Use of transaction agents to perform distributed transactions
EP1283466A1 (en) * 2001-08-06 2003-02-12 Hewlett-Packard Company (a Delaware corporation) Management system for a cluster
US20030204547A1 (en) * 2002-04-29 2003-10-30 Kevin Davis Technique for scheduling computer processes
US8219608B2 (en) * 2002-06-20 2012-07-10 Koninklijke Philips Electronics N.V. Scalable architecture for web services
US7549153B2 (en) * 2002-07-22 2009-06-16 Amberpoint, Inc. Apparatus and method for content and context processing of web service traffic
JP3874706B2 (ja) 2002-07-29 2007-01-31 株式会社東芝 アプリケーションプログラムプラン生成装置、アプリケーションプログラムプラン生成方法、プログラム及び記録媒体
US7440940B2 (en) * 2002-12-02 2008-10-21 Sap Ag Web service agent
US7383550B2 (en) * 2002-12-23 2008-06-03 International Business Machines Corporation Topology aware grid services scheduler architecture
GB0305959D0 (en) * 2003-03-15 2003-04-23 Ibm Client web service access
US7086063B1 (en) * 2003-03-25 2006-08-01 Electric Cloud, Inc. System and method for file caching in a distributed program build environment
JP3947136B2 (ja) 2003-05-30 2007-07-18 株式会社東芝 ウェブサービスシステム、フロー展開支援装置およびフロー展開支援プログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007122189A (ja) * 2005-10-25 2007-05-17 Canon Inc スケジュール実行装置及びプログラム
US8171074B2 (en) 2005-10-25 2012-05-01 Canon Kabushiki Kaisha Web service system, schedule execution apparatus and control method thereof
JP2009223439A (ja) * 2008-03-13 2009-10-01 Canon Inc メッセージ生成処理方法及びメッセージ生成処理装置

Also Published As

Publication number Publication date
US20080307420A1 (en) 2008-12-11
CN100356329C (zh) 2007-12-19
US7404189B2 (en) 2008-07-22
CN1637710A (zh) 2005-07-13
JP3965185B2 (ja) 2007-08-29
US20050149935A1 (en) 2005-07-07
US7707587B2 (en) 2010-04-27

Similar Documents

Publication Publication Date Title
JP3965185B2 (ja) ウェブ・サービス呼び出しをサポートするスケジューラ
US7949999B1 (en) Providing support for multiple interface access to software services
EP1483671B1 (en) Provisioning aggregated services in a distributed computing environment
US8751626B2 (en) Model-based composite application platform
Krishnan et al. GSFL: A workflow framework for grid services
US7546606B2 (en) System and method using a connector architecture for application integration
US20120036252A1 (en) Osgi-based heterogeneous service integrating system and method
US20060224702A1 (en) Local workflows in a business process management system
US20060029054A1 (en) System and method for modeling and dynamically deploying services into a distributed networking architecture
US8843938B2 (en) Methods, systems, and computer program products for asynchronous resumption of a dataflow
US20090165021A1 (en) Model-Based Composite Application Platform
US20060224428A1 (en) Ad-hoc and priority-based business process execution
US7934218B2 (en) Interprocess communication management using a socket layer
WO2003034183A2 (en) System and method using a connector architecture for application integration
Curbera et al. Toward a programming model for service-oriented computing
EP1569106B1 (en) A scheduler supporting web service invocation
US20100299677A1 (en) Article of manufacture for programmatically describing web service-driven applications
US8712786B2 (en) Method and apparatus for controlling a multi-node process
Lytra et al. A pattern language for service-based platform integration and adaptation
KR102637168B1 (ko) 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스 제공하는 프로그램이 저장된 컴퓨터가 판독 가능한 기록매체
KR102659150B1 (ko) 애플리케이션 서비스 제공 장치, 애플리케이션 서비스 제공 방법 및 애플리케이션 서비스를 제공하는 컴퓨터로 실행가능한 프로그램을 저장하는 저장매체
Mylläri Introducing REST Based API Management and Its Relationship to Existing SOAP Based Systems
Sebu et al. The design of stateful web services based on web service resource framework implemented in globus toolkit 4
Luo et al. Service grid for business computing
Sonntag Conceptual design and implementation of a bpel light workflow engine with support for message exchange patterns

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060801

RD12 Notification of acceptance of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7432

Effective date: 20060818

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20060818

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20061030

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070522

RD14 Notification of resignation of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7434

Effective date: 20070522

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070525

R150 Certificate of patent or registration of utility model

Ref document number: 3965185

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110601

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120601

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120601

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130601

Year of fee payment: 6