JP2010527472A - フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出す方法 - Google Patents

Abstract

フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出すシステムおよび方法を開示する。本方法は発見サブシステムを使用してアプリケーションサーバー上で利用可能なサービスを発見し、アプリケーションサーバー上のサービスのメタデータ記述を検索し、発見されたサービスおよびメタデータ記述を使用してウェブサービスインターフェースを作成し、そのサービスがウェブサービス記述言語を使用して利用可能となるようにする。

Description

本発明は、フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出す方法に関する。

本背景技術は、本特許出願の基本的な状況を提供することを意図しており、特定の解決すべき問題を記述することを意図していない。

ある環境で稼動するよう設計されたコンピューターアプリケーションが、異なる環境で稼動することを必要とされることはよくあることである。例えば、コンピューターアプリケーションは、データを容易に利用可能にするよう、コンピューターのハードドライブ上にインストールされるように設計され得る。しかし、時が経つにつれ、異なる環境が所望され得る。例えば、インターネット上で利用可能なアプリケーションを有することが望ましい場合に、そのアプリケーションを使用している全てのコンピューター上の全てのハードドライブ上にそのアプリケーションがインストールされているわけではい。アプリケーションで使用されるフォームおよびテーブルを記述するデータは利用可能であるが、アプリケーションをインターネット上で利用可能なように修正することには、注意深い見直しと修正が要求される。

本概要は、以下の発明を実施するための形態でさらに説明されている選択した概念を簡略化した形式で紹介するために提供するものである。本概要は、特許請求の範囲に記載されている主題事項の重要な特徴または本質的な特徴を特定することを目的とするものでも、特許請求の範囲に記載されている主題事項の範囲の決定に際して、補助として使用することを目的とするものでもない。

多くのアプリケーションは、フォームおよびテーブルなどのデータのアブストラクションがアプリケーション設計の駆動力である、データ駆動型のアプリケーションである。アプリケーション内のそれらのアブストラクション（テーブル、フォームなど）の背後にメタデータを定義することに、多大な努力が払われてきた。メタデータは、どのフィールドが重要な意味があり、どのインタラクションが利用可能であるかなどの、アプリケーションとのインターフェースを記述する。例えば、注文書のフォームのメタデータは、ヘッダのフィールド（購入者、日付、引渡条件など）およびそのフォームを作成する線を含有する。メタデータはまた、保管、郵送、出荷などの、ユーザーがフォームでできることを含有し得る。このデータを使用することにより、プログラム的なアクセスが、シンプル・オブジェクト・アクセス・プロトコルすなわちＳＯＡＰを使用して、許可され得る。

フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出すシステムおよび方法を開示する。本方法は発見サブシステムを使用して、アプリケーションサーバー上で利用可能なサービスを発見する。本方法は、アプリケーションサーバー上のサービスのメタデータ記述を検索する。本方法は、発見されたサービスおよびメタデータ記述を使用してウェブサービスインターフェースを作成し、そのサービスがウェブサービス記述言語を使用して利用可能となるようにする。

特許請求の範囲に従って動作し得るコンピューティングシステムのブロック図である。 フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出す方法のフローチャート図である。 図２の方法を実装するシステムの説明図である。 システムを実装するのに役立つ方法の一部の説明図である。

以下の文章は多数の異なる実施形態の詳細な説明を記載するが、当然のことながら、その説明の法的な範囲は、本特許の最後に記載される特許請求の範囲の言葉により定義される。詳細な説明は、単なる例示であると解釈されるべきであり、全ての可能な実施形態を記述するわけではない。それは全ての可能な実施形態を記述することが、不可能ではないが実用的ではないからである。多数の代替的実施形態が、現在の技術、または本特許の出願日より後に開発される技術を使用して実装可能であろうが、それらも特許請求の範囲に含まれる。

また当然のことながら、用語が、「本明細書において使用されるとき、用語「 」は・・・を意味するとここに定義される」という文章、または同様の文章を使用して、本特許において明示的に定義される場合を除いて、その用語の意味を、明示的にまたは暗に、その単純なまたは普通の意味を超えて制限する意図はなく、またそのような用語を本特許の任意の節にある任意の文（特許請求の範囲の言語以外）に基づく範囲に制限して解釈するべきではない。本特許の最後の特許請求の範囲に列挙される任意の用語が、本特許において単一の意味に一致して参照される限り、それは明確さのみのため、読者を混乱させないためになされるのであり、また、そのような特許請求の範囲の用語は、制限されて、暗に、または他の方法で、その単一の意味を意図するのではない。最後に、特許請求の範囲の要素が、単語「意味する」および何ら構造の説明文の無い機能を列挙することにより定義される場合を除いて、如何なる特許請求の範囲の要素の範囲も米国特許法第１１２条第６段落の適用に基づき解釈されるよう意図しない。

図１は、特許請求の範囲に記載されている方法および装置のステップのためのシステムを実装し得る適切なコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の単なる一例であり、特許請求の範囲の方法または装置の使用または機能性の範囲について何ら制限を示唆することを意図していない。コンピューティング環境１００は、例示的動作環境１００に示されるコンポーネントの任意の１つまたは組合せに関して、如何なる依存も要件も有するものと解釈されるべきではない。

特許請求の範囲に記載されている方法および装置のステップは、多数の他の汎用または専用コンピューティングシステム環境または構成で動作可能である。特許請求の範囲の方法または装置と共に使用するために最適な既知のコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピューター、サーバーコンピューター、ハンドヘルドまたはラップトップ装置、マルチプロセッサーシステム、マイクロプロセッサーベースのシステム、セットトップボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピューター、メインフレームコンピューター、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれるが、これらに限定されない。

特許請求の範囲に記載されている方法および装置のステップを、コンピューターによって実行されるプログラムモジュールなど、コンピューター実行可能な命令の一般的なコンテクストに即して実装することができる。一般に、プログラムモジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。本方法および装置はまた、タスクが、通信ネットワークを通じてリンクされたリモート処理装置によって実行される分散コンピューティング環境においても実装することができる。分散コンピューティング環境において、プログラムモジュールを、メモリ記憶装置を含むローカルおよびリモートのコンピューター記憶媒体に配置することができる。

図１を参照すると、特許請求の範囲に記載されている方法および装置のステップを実装する例示的システムは、コンピューター１１０の形式の汎用コンピューティング装置を含む。コンピューター１１０のコンポーネントは、処理ユニット１２０、システムメモリ１３０、および、システムメモリを含む種々のシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１を含み得るが、これらに限定されない。システムバス１２１は、メモリバスまたはメモリコントローラー、周辺バス、および任意の様々なバスアーキテクチャのいずれかを使用するローカルバスを含む、いくつかの種類のバス構造のいずれかとすることができる。そのようなアーキテクチャには、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、メザニンバスとしても知られるＰＣＩ（Peripheral Component Interconnect）バス、および、ＰＣＩ−Ｅ（Peripheral Component Interconnect-Express）が含まれるが、これらに限定されない。

コンピューター１１０は一般的に様々なコンピューター読み取り可能な媒体を含む。コンピューター読み取り可能な媒体は、コンピューター１１０によりアクセス可能な任意の利用可能な媒体とすることができ、揮発性および不揮発性、取り外し可能および取り外し不可能な媒体が含まれる。コンピューター読み取り可能な媒体には、コンピューター記憶媒体および通信媒体が含まれるが、これらに限定されない。コンピューター記憶媒体には、コンピューター読み取り可能な命令、データ構造体、プログラムモジュール、または他のデータなどの情報を格納する任意の方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能な媒体が含まれる。コンピューター記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（Digital Versatile Disk）もしくは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または、所望の情報を格納するために使用可能であり、コンピューター１１０によりアクセス可能な任意の他の媒体が含まれるが、これらに限定されない。通信媒体は、典型的には、コンピューター読み取り可能な命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の転送機構などの変調データ信号として具現化したものであり、また、任意の情報配信媒体が含まれる。「変調データ信号」という用語は、その特性の１つまたは複数が、その信号中の情報を符号化するように設定または変更された信号を意味する。通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線および他の無線媒体などの無線媒体が含まれるが、これらに限定されない。上記の任意の組合せも、コンピューター読み取り可能な媒体の範囲内に含まれるものとする。

システムメモリ１３０は、ＲＯＭ（Read Only Memory）１３１およびＲＡＭ（Random Access Memory）などの、揮発性および／または不揮発性メモリの形式のコンピューター記憶媒体が含まれる。起動時などにコンピューティングシステム１１０内の要素間の情報の転送を助ける基本ルーチンを含むＢＩＯＳ（Basic Input/Output System）は、一般的にはＲＯＭ１３１内に格納される。ＲＡＭ１３２は一般的には、処理ユニット１２０によりすぐにアクセス可能な、および／または現在処理ユニット１２０により操作されているデータおよび／またはプログラムモジュールを含有する。限定ではなく例として、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピューター１１０はまた、他の取り外し可能／取り外し不可能な、揮発性／不揮発性コンピューター記憶媒体を含み得る。単なる例として、図１は、取り外し不可能な不揮発性の磁気媒体に読み書きするハードディスクドライブ１４１、取り外し可能な不揮発性の磁気ディスク１５２に読み書きする磁気ディスクドライブ１５１、および、ＣＤ−ＲＯＭまたは他の光媒体など、取り外し不可能な不揮発性の光ディスク１５６に読み書きする光ディスクドライブ１５５を示す。例示的動作環境で使用可能な他の取り外し可能／取り外し不可能な、揮発性／不揮発性コンピューター記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれるが、これらに限定されない。ハードディスクドライブ１４１は一般的には、インターフェース１４０などの取り外し不可能なメモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般的には、インターフェース１５０などの取り外し可能なメモリインターフェースによりシステムバス１２１に接続される。

上記で検討し図１に示すドライブおよびそれらに関連するコンピューター記憶媒体は、コンピューター読み取り可能な命令、データ構造、プログラムモジュール、およびコンピューター１１０の他のデータの記憶域を提供する。図１において、例えば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示されている。これらのコンポーネントが、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と、同じでもあることも異なることも可能であることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、ここでは異なる番号を与えて、それらが少なくとも異なる複製品であることを示す。ユーザーは、キーボード１６２および一般にはマウスと称されるポインティングデバイス１６１、トラックボール、またはタッチパッドなどの入力装置を介して、コマンドおよび情報をコンピューター１１０に入力し得る。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが含まれる。これらの入力装置および他の入力装置は、システムバスに結合されるユーザー入力インターフェース１６０を介して、処理ユニット１２０へ接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースにより接続することもできる。モニタ１９１または他のタイプのディスプレイ装置も、ビデオインターフェース１９０などのインターフェースを介して、システムバス１２１へ接続される。モニタに加えて、コンピューターは、出力周辺インターフェース１９５を介して接続し得るスピーカー１９７およびプリンタ１９６など、他の周辺出力装置を含み得る。

コンピューター１１０は、リモートコンピューター１８０など、１つまたは複数のリモートコンピューターへの論理接続を使用するネットワーク化された環境において動作し得る。リモートコンピューター１８０は、パーソナルコンピューター、サーバー、ルーター、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることができ、図１ではメモリ記憶装置１８１のみを示したが、一般的にはコンピューター１１０に関して上記で記述した多くのまたは全ての要素を含む。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含み得る。そのようなネットワーク環境は、オフィス、企業規模のコンピューターネットワーク、イントラネット、およびインターネットにおいて一般的である。

ＬＡＮネットワーク環境で使用されるとき、コンピューター１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ １７１に接続される。ＷＡＮネットワーク環境で使用されるとき、コンピューター１１０は一般的には、モデム１７２、またはインターネットなどのＷＡＮ １７３を介した通信を確立するための他の手段を含む。モデム１７２は、内蔵でも外付けでも良く、ユーザー入力インターフェース１６０または他の適切な機構を介して、システムバス１２１に接続し得る。ネットワーク化された環境では、コンピューター１１０に関して、またはその一部として示されたプログラムモジュールをリモートメモリ記憶装置に格納することができる。限定ではなく例として、図１は、リモートアプリケーションプログラム１８５をメモリ装置１８１上に備わるものとして示す。図示されたネットワーク接続は例示的なものであり、コンピューター間で通信リンクを確立する他の手段を使用できることは理解されよう。

図２は、フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出す方法の説明図である。より多くのアプリケーションがローカルベースからウェブベースへ移行されるにつれて、ローカルベースのアプリケーションを、インターネットなどのより広範囲のネットワーク上で利用可能なアプリケーションに変換する処理を自動化する必要が出てきた。ほとんどのビジネスアプリケーションは、フォームおよびテーブルなどのデータのアブストラクションがアプリケーションの設計の駆動力である、データ駆動型のアプリケーションである。アプリケーション内のそれらのアブストラクション（テーブル、フォームなど）の背後にメタデータを定義することに、多大な努力が払われてきた。メタデータは、どのフィールドが重要な意味があり、どのインタラクションが利用可能であるかなどのアプリケーションとのインターフェースを記述する。例えば、注文書のフォームのメタデータは、ヘッダのフィールド（購入者、日付、引渡条件など）およびそのフォームを作成する線を含有する。メタデータはまた、保管、郵送、出荷などの、ユーザーがフォームでできることを含有し得、これを、フォーム上のボタンまたはメニューの選択肢として、または他の手段により表し得る。このデータを使用することにより、プログラム的なアクセスが、シンプル・オブジェクト・アクセス・プロトコルすなわちＳＯＡＰを使用して、許可され得る。

いくつかのアプリケーションにおいて、テーブルは最も低いレベルのアブストラクションであると見なされ得る。例えば、テーブルは、エンティティに関するフィールドの組を定義し得、それらのフィールドは、値を含むか、または、このテーブル内の値からまたは他のテーブル内の値から計算され得る。フィールドはまた、値型（文字列、整数など）およびそのサイズ（例えば、文字列長が５０）などのプロパティを有し得る。加えて、テーブルはまた、挿入、更新および削除における検証ロジックのための、エンティティおよびトリガ／イベントの発見を最適化する指標を含み得る。

符号ユニットのアブストラクションは、ビジュアルベーシックのようなプログラム言語と同様の様式で方法に対してインターフェースを定義する、標準方法指向の手続きアブストラクションである。

フォームのアブストラクションは、アプリケーションのためのユーザーインターフェースを定義する。フォームのアブストラクションは、ユーザー用のフィールドを一緒にグループ化し、そのユーザーに関連のあるフィールドのみを示す。フォームのアブストラクションはまた、ユーザーが、見る、挿入する、および修正するなどのようにデータとインタラクトすること、ならびに、注文書を郵送するまたは出荷通知を生成するなどのようにシステムの機能性にアクセスすることのための手段を提供し得る。フォームは、エンティティ（例えば注文書など）の外観ビューを定義し、ビュー内にフィールドを定義し、また、ビューが、読み込む、修正する、挿入する、削除するなどの機能を許可または可能にする場合、どのフィールドが読み込み専用で、どのフィールドが編集可能であるかを定義する。アプリケーションのためのユーザーインターフェースから導き出されることにより、アプリケーションを、ウェブサービス技術などのリモート技術を使用して、利用可能にし得る。

再度図２を参照すると、ブロック２００において、発見サブシステムを使用して、アプリケーションサーバー上の利用可能なサービスを発見し得る。図３は、この方法のシステム開発の実例の説明図であり得る。サービスクライアント３０５は、サービスの消費者または開発者であり得る。サービスクライアント３０５は、通信クラウド３２０を介して発見要求３１０をアプリケーションのサーバー３１５へ通信し得る。一実施形態において、通信クラウドはインターネットであり、ＴＣＰ／ＩＰ上のｈｔｔｐを使用して通信が行われる。もちろん、他の実施形態が可能である。例えば、クライアントおよびサーバーは、イントラネット上などのように、ローカルであってもよい。

ブロック２１０において、サービスクライアント３０５（図３）は、アプリケーションサーバー３１５上のサービスのメタデータ記述３２５を要求し得る。サーバー３１５は、通信クラウド３２０を使用してメタデータ要求３２５に返答し得る。別の実施形態において、メタデータは、ウェブサービス定義言語要求を使用して検索される。サービス要求３３０はまた、通信クラウド３２０を使用し得る。

ブロック２２０において、発見されたサービス３１０およびメタデータ記述３２５を使用してウェブサービスインターフェースを作成し、サービスがウェブサービス記述言語を使用して利用可能となるようにする。サービスクライアントからアプリケーションサーバーへの通信は、挿入および更新などのサービスインタラクションにｈｔｔｐ上のｓｏａｐを使用し得る。

図４は、種々の要求をどのように扱うかについての説明図である。先に触れたように、クライアントまたは開発者４０５は、アプリケーションからのメタデータ４１０を要求し得る。要求は、サーバーインフラストラクチャ（ＩＩＳ）４１５によりサービスブローカ４２０へ配信され得る。次にサービスブローカ４２０は、それがどのタイプの要求であるかを判定し、次いで、適用可能なサブシステムへルーティングし得る。個々のサブシステムが要求を扱う。

一つのサブシステムは、発見サブシステム４２５である。発見サブシステムは、どのサービスがシステムから利用可能であるかをクライアント／開発者が発見するのを可能にする。応答は、本件出願人のＤＩＳＣＯフォーマットを含む様々なフォーマットであり得る。ウェブサービスが一旦展開されると、潜在的ユーザーはそのウェブサービスがどこにあり、どのように機能するかを発見することが可能であるはずである。ＤＩＳＣＯは、ウェブサービスを公開し発見するための本件出願人の技術である。ＵＤＤＩ（Universal Description, Discovery, and Integration）は、ウェブサービス情報のリポジトリを更新およびクエリするためのＳＯＡＰベースのプロトコルを定義する、業界全体のイニシアチブである。ＤＩＳＣＯと同様、ＵＤＤＩは、ウェブサービスの公開および発見を可能にし、サイトの広がりと最終的な成功を最大限にする。

ＷＳＤＬ(Web Services Description Language）は、ウェブサービスをどのようにＸＭＬフォーマットで記述可能にするかを標準化するよう試みている、進行中のイニシアチブである。ＷＳＤＬドキュメントは、メッセージおよび（一般的には）ＸＭＬスキーマタイプの定義に関してサービスの動作を記述し、サービスの動作をどのように種々のプロトコルおよびエンドポイントに結びつけるかについても記述する。クライアントが一旦ＷＳＤＬドキュメントを入手できると、目的のウェブサービスとどのようにインタラクトするかを知るのに十分な情報を持つことになる。クライアントが、ＷＳＤＬドキュメントがどこに存在するかを知っている場合、クライアントはＨＴＴＰを介して簡単にそれを求めることが可能である。しかし、クライアントが、ＷＳＤＬがどこに所在するかを知らない場合、発見機構が必要である。

ＤＩＳＣＯを用いる発見
以前は、ほとんどの消費者が、ウェブを閲覧する、電子メールを受信する、または口コミにより、新しいウェブサービス（およびそのエンドポイントアドレス）に関する情報を得ていた。ＤＩＳＣＯは、ドキュメントのフォーマットをインタロゲーションアルゴリズムに沿って定義することが可能であり、所与のサーバー上に露出しているウェブサービスを発見することを可能にする。ＤＩＳＣＯはまた、各ウェブサービスの能力を（ドキュメンテーションを介して）発見すること、および各ウェブサービスと（ＷＳＤＬを介して）どのようにインタラクトするかを発見することを可能にする。ＤＩＳＣＯを使用して展開されるウェブサービスを公開するために、ユーザーは、アプリケーションサーバーにサービスを登録する必要がある。

「．ｄｉｓｃｏ」の応答は、ウェブサービスを記述する他のリソースへのリンクを単に含有するＸＭＬドキュメントであり、人が読めるドキュメンテーションまたはインターフェース規約を含有するＷＳＤＬファイルを含有するＨＴＭＬファイルに酷似する。

フォーム４３０およびテーブル４３５などのウェブサービスとしてウェブアクセス可能であると意図されるアプリケーションの根底にあるデータからのアブストラクションが、データベースのテーブルに登録される。発見サブシステム４２５は、データベーステーブルからポピュレートされる。データベース内の各レコードは、ユーザーがそれをサービスとしてマークしている場合、応答内のＤＩＳＣＯ応答でウェブサービスエントリになる。応答内の各エントリは、サービスのＷＳＤＬ記述を指すＵＲＬ（Uniform Resource Locator）を含有し得る。

メタデータプロバイダ
メタデータプロバイダ４４０は、ＷＳＤＬフォーマットを理解可能なツールなどの標準ツールにより使用され得るサービスインターフェースの記述を提供し得る。クライアント／開発者は、特定のサービスの記述を要求し得る。システムは、フォーム４３０およびテーブル４３５などのこのサービスを記述するメタデータ４２７をロードする。次に、メタデータ４２７を使用して、サービスに渡される値型およびメッセージを定義する。

ＷＳＤＬの値型部は、フォーム４３０およびテーブル４３５の両方に記述されるメタデータ４２７から導き出される。システムは、フォームのメタデータ４２７をロードすることにより起動し、フォームのメタデータ４２７は、フォーム４３０がデータをどのテーブル４３５に保存するかについての情報を保持する。フォーム４３０のメタデータ４２７はまた、テーブル４３５からのどのフィールドがフォーム４３０上に示されるかを指摘する。テーブルのメタデータ４３７は、フィールド、ならびに、型（および大きさ）および名称のようなそのプロパティを含有する。ｘｍｌ型は、サービスの名称に加えてこのメタデータ情報４２７から構築される。サービスの名称は値型の名称を形成し、フォーム上の各フィールドは、フィールドの名称および型が使用される値型上のフィールドとして現れる。

アプリケーションがテーブル４３５を有する場合。
ｔａｂｌｅ ｉｄ＝１ ＝＞ Ｃｕｓｔｏｍｅｒｓ｛
ｆｉｅｌｄ ｉｄ＝１ ＝＞ Ｎａｍｅ：ｓｔｒｉｎｇ（１００），
ｆｉｅｌｄ ｉｄ＝２ ＝＞ ＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒ：ｓｔｒｉｎｇ（ｌ６），
ｆｉｅｌｄ ｉｄ＝３ ＝＞ Ｒａｔｉｎｇ：ｉｎｔ
｝
およびフォーム４３０：
ｆｏｒｍ ｉｄ＝２ ＝＞ ＣｕｓｔｏｍｅｒＣａｒｄ｛
ｔａｂｌｅ−ｒｅｆ１，
ｆｉｅｌｄ−ｒｅｆ１，
ｆｉｅｌｄ−ｒｅｆ２，
ｃａｎ−ｒｅａｄ ｔｒｕｅ，
ｃａｎ−ｉｎｓｅｒｔ ｔｒｕｅ，
ｃａｎ−ｍｏｄｉｆｙ ｔｒｕｅ，
ｃａｎ−ｄｅｌｅｔｅ ｆａｌｓｅ
｝

このフォーム４３０は、新しいレコードをテーブルＣｕｓｔｏｍｅｒｓに挿入することが可能である。このフォーム４３０はまた、フィールドＮａｍｅおよびＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒを編集および読み込むことが可能であるが、レコードを削除することも、Ｒａｔｉｎｇフィールドを読み込みまたは編集をすることもできない。プログラム可能な構成としてこのビュー／フォーム４３０にアクセスすることが望ましい。そうするために、ビュー／フォーム４３０をサービスとして登録し得る。

Ｆｏｒｍ：２をＣｕｓｔｏｍｅｒとして登録する
サービスとしてフォーム４３０のＣｕｓｔｏｍｅｒＣａｒｄを登録することにより、ＷＳＤＬ記述を検索し得、ＷＳＤＬで記述されたサービスを呼び出し得る。ＷＳＤＬファイルは、以下の情報を含有する：
メソッド: 発見、挿入、更新および取得
２つのフィールド、ＮａｍｅおよびＴｅｌｅｐｈｏｎｅＮｕｍｂｅｒを有するＣｕｓｔｏｍｅｒという型を含有する。
この型は、メソッドに対するパラメータである。

ディスパッチャ
ディスパッチャ４４５が、実際のサービス要求を受信する。サービス要求は、メタデータプロバイダ４４０により提供されるＷＳＤＬで提供される仕様にフォーマットされる。ディスパッチャ４４５の基本動作は、フォーム４３０に仮想的に書き込みかつフォーム４３０の正しいメソッドを呼び出すことにより、メッセージをディスパッチすること、またはフォーム４３０からの情報を応答に書き込むことである。

前述の文章は、多数の異なる実施形態の詳細な説明を記載するが、当然のことながら、特許の範囲は、本特許の最後に記載される特許請求の範囲の言葉により定義される。詳細な説明は、単なる例であると解釈されるべきであり、全ての可能な実施形態を記述するわけではない。なぜなら、全ての可能な実施形態を記述することが、不可能ではないが実用的ではないからである。多数の代替的実施形態が、現在の技術、または本特許の出願日より後に開発される技術を使用して実装可能であろうが、それらも特許請求の範囲の範囲に含まれる。

従って、本特許請求の範囲の精神および範囲から逸脱することなく、本明細書に記述され示される技術および構造に、多くの修正および変更がなされ得る。従って、当然のことながら、本明細書に記述される方法および装置は、単なる例示であり、特許請求の範囲に関して制限するものではない。

Claims (20)

1. フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出す方法であって、
   アプリケーションサーバー上で利用可能なサービスを発見する発見サブシステムを使用するステップ２００と、
   前記アプリケーションサーバー上の前記サービスのメタデータ記述を検索するステップ２１０と、
   前記発見サブシステムからの前記発見されたサービスおよび前記メタデータ記述を使用してウェブサービスインターフェースを作成し、前記サービスがウェブサービス記述言語を使用して利用可能となるようにするステップ２２０と
   を含むことを特徴とする方法。
2. 前記メタデータは、ウェブサービス定義言語要求を使用して検索される（３０５）ことを特徴とする請求項１に記載の方法。
3. 発見およびメタデータ検索のために、ｈｔｔｐを使用して前記アプリケーションサーバーへ通信するステップをさらに含むことを特徴とする請求項１に記載の方法。
4. サービスインタラクションにｈｔｔｐ上のｓｏａｐを使用して、サービスクライアントから前記アプリケーションサーバーへ通信するステップをさらに含むことを特徴とする請求項１に記載の方法。
5. 前記発見サブシステムの応答は、ＤＩＳＣＯフォーマットである（４２５）ことを特徴とする請求項１に記載の方法。
6. ウェブサービスとしてウェブアクセス可能であると意図されるアブストラクションは、データベーステーブルに登録されることを特徴とする請求項１に記載の方法。
7. 前記発見サブシステムは、前記データベーステーブルからポピュレートされる（４２５）ことを特徴とする請求項６に記載の方法。
8. 前記データベース内の各レコードは、前記レコードがサービスとしてマークされている場合、前記応答内のエントリになる（４２５）ことを特徴とする請求項７に記載の方法。
9. 前記応答内の各エントリは、前記サービスのＷＳＤＬ(Web Services Description Language）記述を指すＵＲＬ（Uniform Resource Locator）を含有する（４２５）ことを特徴とする請求項８に記載の方法。
10. メタデータプロバイダが、ＷＳＤＬフォーマットと互換性のある標準ツールにより使用され得る前記サービスインターフェースの記述を提供する（４４０）ことを特徴とする請求項１に記載の方法。
11. 前記メタデータを使用して、メッセージに加えて前記サービスに渡される値型を定義する（４２７）ことを特徴とする請求項１０に記載の方法。
12. 前記フォームメタデータはどのテーブルからのどのフィールドにフォームがそのデータを保存するかを指摘し、前記フォームメタデータは前記テーブルからのどのフィールドが前記フォーム上に示されるかを指摘する（４２７）ことを特徴とする請求項１０に記載の方法。
13. 前記テーブルメタデータは、前記フィールドおよびそのプロパティを含有する（４３７）ことを特徴とする請求項１０に記載の方法。
14. ＸＭＬ型は前記フォームメタデータおよび前記テーブルメタデータならびに前記サービスの名称から構築される（４２７）ことを特徴とする請求項１０に記載の方法。
15. 前記フォーム上の各フィールドは、フィールドの名称および型が使用される前記値型上のフィールドとして現れる（４２７）ことを特徴とする請求項１に記載の方法。
16. フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出すためのコンピューター実行可能コードを備えるコンピューター読み取り可能な記憶媒体であって、前記ココンピューター実行可能コードは、
    アプリケーションサーバー上で利用可能なサービスを発見する発見サブシステムを使用するステップ２００と、
    前記アプリケーションサーバー上の前記サービスのメタデータ記述を検索するステップであって、前記メタデータはウェブサービス定義言語要求を使用して検索されるステップ２１０と、
    前記発見サブシステムからの前記発見されたサービスおよび前記メタデータ記述を使用してウェブサービスインターフェースを作成し、前記サービスがウェブサービス記述言語を使用して利用可能となるようにするステップ２２０と
    のためのコードをさらに備えることを特徴とするコンピューター読み取り可能な記憶媒体。
17. ウェブサービスとしてウェブアクセス可能であると意図されるアブストラクションはデータベーステーブルに登録され、前記発見サブシステムは前記データベーステーブルからポピュレートされることを特徴とする請求項１６に記載のコンピューター読み取り可能な記憶媒体。
18. 応答内の各エントリは、前記サービスのＷＳＤＬ記述を指すＵＲＬを含有することを特徴とする請求項１６に記載のコンピューター読み取り可能な記憶媒体。
19. コンピューター実行可能コードを実行するプロセッサーと、コンピューター実行可能コードを記憶するメモリと、入出力回路とを備えるコンピューターシステムであって、前記コンピューター実行可能コードは、フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出すためのコードをさらに備え、前記コンピューター実行可能コードは、
    アプリケーションサーバー上で利用可能なサービスを発見する発見サブシステムを使用するステップ２００と、
    前記アプリケーションサーバー上の前記サービスのメタデータ記述を検索するステップであって、前記メタデータはウェブサービス定義言語要求を使用して検索されるステップ２１０と、
    前記発見サブシステムからの前記発見されたサービスおよび前記メタデータ記述を使用してウェブサービスインターフェースを作成し、前記サービスがウェブサービス記述言語を使用して利用可能となるようにするステップ２２０と
    のためのコードをさらに備えることを特徴とするコンピューターシステム。
20. メタデータプロバイダが、ＷＳＤＬフォーマットと互換性のある標準ツールにより使用され得る前記サービスインターフェースの記述を提供することと、
    前記フォームメタデータはどのテーブルからのどのフィールドにフォームがそのデータを保存するかを指摘し、前記フォームメタデータは前記テーブルからのどのフィールドが前記フォーム上に示されるかを指摘することと、
    前記テーブルメタデータは、前記フィールドおよびそのプロパティを含有することと
    を特徴とする請求項１９に記載のコンピューターシステム。

Images