技術 ウェブサービスアーキテクチャおよび方法

0001

［同時係属中の出願の参照］
以下の同時係属中の米国特許出願が参照される。
すなわち、代理人整理番号第１００２０４０４１−１号を有する「ARCHITECTURE AND METHODFOR PRODUCTCATALOG WEB SERVICE」という発明の名称の米国特許出願第１０／１９０，１５４号；代理人整理番号第１００２０４０３７−１号を有する「ARCHITECTURE AND METHOD FOR CONFIGURATION VALIDATION WEB SERVICE」という発明の名称の米国特許第１０／１８９，９７４号；および代理人整理番号第１００２０４０３９−１号を有する「ARCHITECTURE AND METHOD FOR ORDERPLACEMENTWEB SERVICE」という発明の名称の米国特許出願第１０／１９０，１８０号が参照される。
各出願は、この出願と共に同じ日付で出願され、共通の発明者要件および譲渡を有する。

0002

［発明の分野］
本発明は、ウェブサービスアーキテクチャおよび使用方法に関し、特に、ネットワークを介したウェブサービスアーキテクチャおよび使用方法に関する。

0003

［発明の背景］
ネットワークシステムは、毎日の個人的な目的およびビジネス目的のための通信リンクとして利用される。
ネットワークシステム、特にインターネットの成長、および、コンピュータハードウェアおよびソフトウェアの技術の進歩と共に、拡大している１組のサービスがインターネットを介して提供されている。
提供されるサービスのタイプには、基本ネットワークアクセス、情報検索、ストリーミングメディア、テレビ会議および他のコラボレーションツール、企業対企業の販売および企業対顧客の販売、ならびにアプリケーションのアウトソーシングが含まれるが、これらに限定されるものではない。

0004

上記で言及したサービスのすべてを容易にする、インターネットを介して提供されている固有で新しいタイプのアプリケーションは、ウェブサービスと呼ばれる。
ウェブサービスは、自己充足的で、自己記述型のモジュール形式のアプリケーションであり、本明細書では交換可能に使用されるインターネットまたは「ウェブ」全体にわたって消費できる（公開され、突き止められ、呼び出される）アプリケーションである。
ウェブサービスは、簡単な要求から複雑なビジネスプロセスに至るまでのあらゆるものとすることができる機能を実行する。
ウェブサービスが配備されると、他のアプリケーションおよび他のウェブサービスは、配備されたウェブサービスを発見して使用することができる。

0005

ウェブサービスは、ある意味では、分散コンポーネントを公衆インターネット上へ発展させたものである。
コンポーネント「ミドルウェア」によって、或るソフトウェアが、別のコンピュータの別のソフトウェアに含まれる機能を利用することが可能になるのとちょうど同様に、ウェブサービスは、インターネットのプロトコルを使用して、インターネット全体にわたって同じことを行うコンポーネントインフラストラクチャを提供する。

0006

共通オブジェクトリクエストブローカアーキテクチャ（ＣＯＲＢＡ）、Microsoftの分散コンポーネントオブジェクトモデル（ＤＣＯＭ）、Sun Microsystemsのリモートメソッド呼び出し（ＲＭＩ）等の、分散コンピューティング用に現在使用されているさまざまな分散コンポーネントプラットフォームの使用は限られていることから、ウェブサービスが望ましい。
特に、現在利用可能な分散コンポーネントプラットフォームは、一般に、企業のイントラネット等の厳重に管理されたネットワーク中でしか使用できない。
それらプラットフォームは、マシンが同じプロトコル（例えば、ＤＣＯＭ対ＤＣＯＭ等）を使用していない限り、相互使用できないので、公衆インターネット等のオープン環境ではうまく機能しない。
一方、インターネットは、均一で広くアクセス可能なインターフェースを提供することによって、分散コンポーネントプラットフォームを補完する。

0007

ウェブサービスと、先行者である分散ネットワーク接続技術との間には、基本的な相違がある。
ウェブサービスと先行の分散コンピューティング技術との間の主要な相違は、ウェブサービスがインターネットの異種環境用に設計されているということである。
インターネットは、均一なソフトウェア標準規格を課すことができる均一な制御下にはない非常に多くの極めて多種多様なコンピュータから構成されるので、ウェブサービスは、必然的に、インターネットを構成するコンピュータのプログラミング言語、オペレーティングシステム、およびハードウェアから完全に独立している。

0008

ウェブサービスは、拡張マークアップ言語（ＸＭＬ）、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、ウェブサービス記述言語（ＷＳＤＬ）、ならびに統一的な記述、発見、および統合（ＵＤＤＩ）をインターネットプロトコルバックボーン上で使用してウェブベースのアプリケーションを統合することにより、インターネット全体にわたって最大の相互使用可能性を得るように設計される。
ＸＭＬはデータをタグ付けするのに使用され、ＳＯＡＰはデータを転送するのに使用され、ＷＳＤＬはサービスを利用可能に定義して記述するのに使用され、ＵＤＤＩはどのサービスがレジストリで利用可能であるかを列挙するのに使用される。

0009

ウェブサービスによって、異なるソースからの異なるアプリケーションは、多くの時間を必要とするカスタムコーディングを行うことなく、互いに通信することが可能になる。
転送されたデータがすべてのタイプのシステムによって理解できるように、オブジェクトを渡すのではなく、テキストフォーマットが使用される。
すべての通信はＸＭＬで行われるので、ウェブサービスは、どの特定の１つのオペレーティングシステムにもプログラミング言語にも拘束されない。
例えば、Ｊａｖａ（商標）はＰｅｒｌとトークすることができ、Ｗｉｎｄｏｗｓ（商標）アプリケーションはＵＮＩＸ（商標）アプリケーションとトークすることができる。
さらに、ウェブサービスは、通信するのにインターネットブラウザの使用もハイパーテキストマークアップ言語（ＨＴＭＬ）の使用も必要としない。

0010

したがって、ウェブサービスは、基本レベルにおいて、本質的に異なるシステムが独自のクライアントライブラリを使用することなく互いに通信することを可能にする普遍的なクライアントサーバアーキテクチャとみなすことができる。
ウェブサービスアーキテクチャは、クライアントとサーバとの間のコード依存関係またはプログラミング依存関係を有効に除去することによって、クライアント／サーバアプリケーションに通常関連した開発プロセスを簡単にする。
カスタムコネクタもエンタープライズアプリケーション統合（ＥＡＩ）も必要とされない。
サーバインターフェース情報は、ＷＳＤＬファイルの使用等によって標準フォーマットでコード化された構成ファイルを介してクライアントに開示される。
そうすることによって、サーバは、ＵＤＤＩレジストリ等において、すべてのターゲットのクライアントプラットフォーム用に単一のファイルを公開することが可能になる。
米国特許第6643650号
米国特許第6460072号
米国特許第5819285号
米国特許第5974416号
米国特許第6618705号
米国特許第6714778号

0011

競争的な環境における劇的な変化に応じて、すなわち、製品のライフサイクルの短縮、利幅の低下、および消費者がより情報に通じることに応じて、消費者ビジネスの活動はインターネットに速やかに移行している。
ウェブサービスは、異なるクライアントシステムに対して広範囲にわたるカスタム化を必要とすることなく、インターネットの異種システム上で動作できることから、この移行において重要な役割を果たすことになる。
さらに、ウェブサービスは、ウェブサービスの動的に発見する性質のため、クライアントの「稼働時間」を増加させることになる。
このように、さまざまなチャネルを介してそれらのサービスを提供するウェブサービスおよびシステムの開発が必要とされ、望まれている。

0012

［発明の概要］
ネットワークを介してクライアントにウェブサービスを提供するシステムが開示される。
本発明による一実施の形態では、システムは、ネットワークに接続されたサーバコンピュータを含む。
インターフェースモジュールが、サーバコンピュータを介してネットワークと通信する。
実施モジュールがインターフェースモジュールと通信し、実現モジュールが実施モジュールおよび少なくとも１つのデータベースと通信する。
インターフェースモジュールは、クライアントからウェブサービス要求を受信し、この要求を当該システムの少なくとも１つの他のコンポーネントへ渡し、かつ、このウェブサービス要求に応答して適合されたデータをクライアントへ渡すソフトウェアから成る。
実施モジュールは、サービス要求に応答して、当該システムの少なくとも１つの他のコンポーネントによって提供されたデータを適合させるソフトウェアを備える。
実現モジュールは、サービス要求に応答して少なくとも１つのデータベースからデータを抽出し、かつ、当該抽出したデータを実施モジュールに提供するソフトウェアを備える。

0013

［好ましい実施の形態の説明］
好ましい実施の形態の以下の詳細の説明では、本明細書の一部を形成する添付図面を参照する。
添付図面には、例示として、本発明を実施できる特定の実施の形態を示す。
本発明の範囲から逸脱することなく、他の実施の形態を利用でき、構造的または論理的な変更を行うことができることが理解されるべきである。
したがって、以下の詳細な説明は、限定する意味に解釈されるべきではなく、本発明の範囲は、添付した特許請求の範囲によって画定される。

0014

図１Ａに示すように、ウェブサービスフレームワーク２０は、要求されたウェブサービスを提供するのに使用されるデータのエンジンまたはソースである基盤レイヤ２２を含む。
この基盤レイヤ２２は、例えば、以下でより詳細に説明するような企業資源計画（ＥＲＰ）システムから構成することができる。
基盤レイヤ２２上には、基盤レイヤ２２からのデータを使用してウェブサービスの要求に基づき動作するツールキットレイヤ２４がある。
このツールキットレイヤ２４は、基盤レイヤ２２のデータを使用して、要求されたウェブサービスを提供するのに必要なツールから構成される。
以下でより詳細に説明するように、例示のツールは、製品構成（configuration of products）をチェックするコンフィギュレータ、製品カタログおよび価格カタログ（pricing catalog）を含むデータベース、および製品の注文を含むデータベースを含むことができる。
ウェブサービスフレームワーク２０の次のレイヤは、アプリケーションサーバレイヤ２６であり、このアプリケーションサーバレイヤ２６は、ウェブサービスアーキテクチャ４０を含み、以下でより詳細に説明する。
アプリケーションサーバレイヤ２６に含まれるウェブサービスアーキテクチャ４０は、ウェブサービス要求を受信し、サービス要求からのデータを構文解析し、ツールキットレイヤ２４のツールを呼び出してサービスを提供し、サービス要求に対する応答を送信する。
すべてのウェブサービスは、或るネットワークを介して利用可能でなければならず、本明細書で説明するように、ウェブサービスは、インターネット３０を介してクライアント２８に提供される。
このネットワークは、ＴＣＰ−ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、ＳＭＴＰ等の任意のオープンインターネットプロトコルに基づくものとすることができるが、他の種類のオープンネットワークプロトコルも使用することができる。

0015

用語「ネットワーク」は、この出願の全体を通して具体的に使用されるが、公衆ネットワークおよびプライベートネットワークを含めて、インターネットシステムおよび他のネットワークシステムを含むものと定義される。
例として、インターネット、イントラネット、エクストラネット、電話システム、ならびに他の有線ネットワークおよび無線ネットワークが含まれる。
用語「インターネット」は、この出願の全体を通して具体的に使用されるが、ネットワークの一例であり、本明細書では交換可能に使用される。

0016

図１Ａのアプリケーションサーバレイヤ２６を図１Ｂにより詳細に示す。
アプリケーションサーバレイヤ２６は、ネットワークを介して通信するインターフェースを有する少なくとも１つのサーバコンピュータを備え、ウェブサービスアーキテクチャ４０を含む。
本発明に従って本明細書で開示されたウェブサービスアーキテクチャ４０の実施の形態は、いくつかの主要なモジュールを含む。
これら主要なモジュールのそれぞれは、１つまたは２つ以上のソフトウェアコンポーネントを備える。
一実施の形態では、ウェブサービスアーキテクチャ４０は、インターフェースモジュール５２、実施モジュール５４、および実現（fulfillment）モジュール５６を含む。
インターフェースモジュール５２は、インターネット３０と通信し、インターネット３０は、次に、クライアントコンピューティングデバイス２８と通信する。
クライアントコンピューティングデバイス２８は、デスクトップコンピュータ、ラップトップコンピュータ、携帯情報端末（ＰＤＡ）、携帯電話等（以下「クライアント２８」と総称する）である。
インターフェースモジュール５２は、クライアント２８からウェブサービス要求を受信し、その要求をシステム２０の少なくとも１つの他のコンポーネントに渡し、サービス要求に応答してクライアント２８に適合したデータ（assimilated data）を渡すソフトウェアを備える。
実施モジュール５４は、インターフェースモジュール５２と通信し、ウェブサービス要求に応答して、システム２０の少なくとも１つの他のコンポーネントによって提供されたデータを適合させるソフトウェアを備える。
実現モジュール５６は、実施モジュール５４と通信し、ウェブサービス要求に応答して、ツールキットレイヤ２４の少なくとも１つのデータベースまたは基盤レイヤ２２からデータを抽出し、次いで、抽出したデータを実施モジュール５４に提供するソフトウェアを備える。

0017

ウェブサービスアーキテクチャ４０の各モジュール５２、５４、５６では、簡単なオープンプロトコルおよびアプリケーションプログラミングインターフェース（ＡＰＩ）が、モジュール間の通信に使用される。
モジュールは互いに増強し合い、各モジュール５２、５４、５６は別個の問題に対処する。
したがって、ウェブサービスアーキテクチャ４０は、個人個人（individuals）およびアプリケーション（本明細書ではクライアントと総称する）がウェブサービスを消費すること（consume）を可能にする標準化プロトコルおよびＡＰＩの固有の集まりおよび配列（arrangement）である。
ウェブサービスアーキテクチャ４０は、言語中立で環境中立なプログラミングモデルを使用するシステムおよび方法を提供する。

0018

本発明によるウェブサービスフレームワーク２０およびウェブサービスアーキテクチャ４０の主要なソフトウェアコンポーネントは、１つまたは２つ以上のコンピュータまたはサーバシステム上で実行される。
一実施の形態では、主要なソフトウェアプログラムコンポーネントのそれぞれは、それ自身の分散コンピュータシステム上で実行される。
他の実施の形態では、主要なソフトウェアコンポーネントは、同じローカルコンピュータシステム上で同時に実行される。

0019

一態様では、各ソフトウェアコンポーネントの少なくとも一部は、オブジェクト指向型プログラミング言語で記述され、このオブジェクト指向型プログラミング言語では、プログラマは、データ構造体のデータタイプだけでなく、そのデータ構造体に適用できるオペレーション（関数）のタイプも定義する。
このように、データ構造体は、データおよび関数の双方を含むオブジェクトとなる。
手続型プログラミング技法を上回るオブジェクト指向型プログラミングの重要な利点の１つは、オブジェクト指向型プログラミング技法では、新たなタイプのオブジェクトが追加された時に変更する必要のないモジュールの作成が可能であるということである。
既存のオブジェクトからその特徴の多くを継承する新たなオブジェクトを作成することができる。
これによって、オブジェクト指向型プログラムの変更がより簡単になる。
本発明による一実施の形態では、オブジェクト指向型プログラミング言語は、Ｊａｖａ（商標）プログラミング言語であり、本発明は、本明細書では、Ｊａｖａ（商標）プログラミング言語に関して説明される。
しかしながら、当業者には、他のオブジェクト指向型プログラミング言語を使用できることが理解されよう。
他の適切なオブジェクト指向型プログラミング言語には、Ｃ＋＋、Ｓｍａｌｌｔａｌｋ、およびＰａｓｃａｌのオブジェクト指向版が含まれる。

0020

オブジェクト指向型プログラミング言語および主要なソフトウェアコンポーネントのそれぞれは、転送プロトコルを使用して互いに通信する。
本発明による一実施の形態では、転送プロトコルはシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）である。
ＳＯＡＰは、ＴＣＰ−ＩＰ、ＨＴＴＰ等の既存で既知のインターネットプロトコルに基づいているので、ＸＭＬでコード化されたテキストデータを渡す均一な方法を定義することによって、プラットフォームとは独立に、アプリケーションがインターネットを介して互いに通信する方法を提供する。
本質的に、ＳＯＡＰは、ＸＭＬメッセージを送信するための「エンベロープ」を提供する。
ＳＯＡＰは、ウェブページ要求と同様に、ＸＭＬデータをラップし、インターネットプロトコル上にピギーバックして、サーバファイアウォールを貫通する。
ＳＯＡＰは、ＸＭＬに依拠して情報のフォーマットを定義し、次いで、情報を送信するのに必要なＨＴＴＰヘッダを追加する。
当業者には、本出願を読んだ後に、本発明と共に使用するのに適した他のプログラミング言語および通信プロトコルが明らかになる。

0021

図２に示すように、本発明による一実施の形態では、ウェブサービスアーキテクチャ４０は、インターフェースモジュール５２、実施モジュール５４、および実現モジュール５６を含む。
インターフェースモジュール５２は、通信リンク６０を介してインターネット３０に接続され、また、通信リンク６１を介して実施モジュール５４にも接続される。
実施モジュール５４は、通信リンク６２によって実現モジュール５６に接続される。
実現モジュール５６は、通信リンク６３によってツールキットレイヤ２４に接続され、通信リンク６４によって基盤レイヤ２２に接続される一方、ツールキットレイヤ２４および基盤レイヤは、通信リンク６５を介して接続される。
インターフェースモジュール５２、実施モジュール５４、および実現モジュール５６は、モジュール５２、５４、５６のさまざまなコンポーネントに対して適宜選択される１つまたは２つ以上の通信プロトコルを介して通信する。
例えば、ＳＯＡＰ、リモートメソッド呼び出し（ＲＭＩ）、Ｊａｖａ（商標）データベース接続（ＪＤＢＣ）等の通信プロトコルを使用することができる。

0022

本発明による例示の一実施の形態では、ＳＯＡＰエンジン６６がインターフェースモジュール５２に使用される一方、エンタープライズＪａｖａＢｅａｎ（商標）（ＥＪＢ）技術が実施モジュール５４および実現モジュール５６に使用される。
具体的には、Ｊａｖａ（商標）セッションビーン８０が実施モジュール５４に使用されて、処理タスクの分散および分離を行い、Ｊａｖａ（商標）エンティティビーン８２が実現モジュール５６に使用されて、ツールキットレイヤ２４のさまざまなツールと相互作用する。
インターフェースモジュール５２と実施モジュール５４との間の通信プロトコルはＳＯＡＰであり、実施モジュール５４と実現モジュール５６との間の通信プロトコルはＲＭＩであり、実現モジュール５６とツールキットレイヤ２４のツールおよびデータベースとの間の通信プロトコルはＪＤＢＣである。

0023

インターフェースモジュール５２は、本発明による上述した実施の形態では、ＳＯＡＰエンジン６６を備える。
ＳＯＡＰエンジン６６は、クライアント２８から受信したサービスコールをリスンする汎用リスナを有する。
インターフェースモジュール５２は、インターネット３０との通信リンク６８を介してクライアント２８から、特定のウェブサービスの（ＳＯＡＰ上でＸＭＬを使用して送信された）サービスコールを受信するように機能する。
ＳＯＡＰエンジンは、ＸＭＬを構文解析してＳＯＡＰ「エンベロープ」を取り除き、サービスコールの発信元のユニフォームリソースロケータ（ＵＲＬ）を識別し、要求されたサービスおよびサービスパラメータ、ならびにデータタイプを識別し、次いで、必要なビジネスロジックを呼び出して、要求されたサービスを提供する。

0024

インターフェースモジュール５２は、移植性のためにオブジェクト指向型プログラミングベースとなっており、プラグアンドプレイができるようにコンポーネントベースとなっている。
本発明による一実施の形態では、インターフェースモジュール５２は、純粋なＪａｖａ（商標）ＡＰＩを使用して文書指向型のＸＭＬメッセージの送信および受信を可能にするためにＸＭＬメッセージング用Ｊａｖａ（商標）ＡＰＩ（ＪＡＸＭ）を含む。
本発明による別の実施の形態では、インターフェースモジュール５２は、ＸＭＬベースＲＰＣ用Ｊａｖａ（商標）ＡＰＩ（ＪＡＸ−ＲＰＣ）を含む。
ＪＡＸ−ＲＰＣは、ＳＯＡＰ仕様によるＸＭＬベースのリモートプロシージャコール（ＲＰＣ）機能を組み込んだウェブサービスを可能にする。
ＲＰＣメカニズムによって、クライアント２８からのリモートプロシージャコールをリモートサーバへ通信することが可能になる。
ＸＭＬベースのＲＰＣでは、リモートプロシージャコールは、ＳＯＡＰ等のＸＭＬベースのプロトコルを使用して表される。
ＸＭＬベースのＲＰＣサーバアプリケーションは、ＲＰＣベースのサービスとしてウェブサービスの定義、記述、およびエキスポートを行うことができる。
また、ＪＡＸ−ＲＰＣは、ＷＳＤＬによって記述されたサービスを実施するのにも使用することができる。

0025

ＨＰ−ＳＯＡＰ、Ａｐａｃｈｅ Ｓｏａｐ（アパッチソープ）、Ａｐａｃｈｅ Ａｘｉｓ（アパッチアクシス）等、ＳＯＡＰのさまざまなバージョンが市販されている。
所望の特徴に応じて、ＳＯＡＰのこれらのバージョンおよび他のバージョンの１つまたは２つ以上をインターフェースモジュール５２で使用することができる。

0026

実施モジュール５４は、要求されたウェブサービスを提供するのに必要なビジネスロジック用の「論理コンテナ」を提供する。
上述したように、本発明による一実施の形態では、実施モジュール５４は、移植性のためにエンタープライズＪａｖａＢｅａｎ（商標）技術（ＥＪＢ）を特徴として備え、プラグアンドプレイができるようにコンポーネントベースとなっている。
図２に示す実施の形態では、実施モジュール５４は、セッションビーン８０を使用して、要求されたサービスを提供するのに必要な処理タスクの分散および分離を行う。
インターフェースモジュール５２が、クライアント２８からサービスコールを受信し、どのウェブサービスが要求されているかを決定した後に、セッションビーン８０は、インターフェースモジュール５２によって呼び出される。

0027

実現モジュール５６は、実施モジュール５４が必要とする処理タスクを実行して、要求されたサービスを提供する。
実現モジュール５６は、ツールキットレイヤ２４のツールおよびデータベース、ならびに／または、要求されたサービスを提供するのに必要なデータを含む基盤レイヤ２２と通信する。
本発明による一実施の形態では、実現モジュール５６は、移植性のためにエンタープライズＪａｖａＢｅａｎ（商標）（ＥＪＢ）技術を特徴として備え、プラグアンドプレイができるようにコンポーネントベースとなっている。
図２に示す実施の形態では、実現モジュール５６は、エンティティビーン８２を使用して、ツールキットレイヤ２４の適切なツールおよびデータベース、ならびに／または、基盤レイヤ２２と相互作用し、必要な処理タスクを実行する。
エンティティビーン８２は、実施モジュール５４のセッションビーン８０によって呼び出される。
エンティティビーン８２に加えて、実現モジュール５６は、さらに、アプリケーションプログラミングインターフェース（ＡＰＩ）を使用して、ツールキットレイヤ２４の特定のツールおよびデータベース、ならびに／または、基盤レイヤ２２と相互作用することができる。

0028

上述したウェブサービスアーキテクチャ４０は、インターネットを介して多数の多種多様なサービスを提供するのに使用することができる。
本明細書で説明するウェブサービスフレームワークおよびアーキテクチャによって提供されるサービスは、いくつかの既存のサービスと同様に見えることがあるが、本発明によるウェブサービスフレームワークおよびアーキテクチャはかなり異なっている。
例えば、複数の小売業者は、顧客が製造業者からのカスタムまたはセミカスタムの製品を構成して注文（すなわち「注文仕様生産」製品）できる店内のコンピュータキオスクを提供することがある。
一方、そのキオスクは、特定の小売業者向けにカスタム開発された分散コンピューティングネットワークの一部であり、注意深く管理された同種ネットワークの一部である。
このキオスクを介して新しいサービスを提供するには、各小売業者のシステムに対して固有でカスタムな変更が必要とされ、これは、多くの時間を要すると共に、費用を要する。
これに対して、アーキテクチャ４０のモジュール形式の性質は、多種多様なクライアントおよびトランザクションに適応することができる。
個々のモジュール５２、５４、５６またはモジュール５２、５４、５６内のエレメントは、変更、再利用、追加、またはアーキテクチャからの除去を容易に行うことができ、それによって、他のモジュールに影響を与えることなく、新しいまたは異なるウェブサービスを提供することができる。
アーキテクチャ４０に対する変更は、各クライアントのカスタム開発なしにすべてのクライアント２８に直ちに利用可能である。
クライアント２８によるウェブサービスへの実時間アクセス（ウェブサービス要求は直ちに作用を受ける）によって、アーキテクチャ４０は、オフライン処理を必要とするのではなく、ウェブサービス要求の実時間処理を使用することが可能になる。
これによって、要求されたサービスが直ちに提供されるという点で、クライアント２８に利益が提供される。

0029

重要な利益として、ウェブサービスアーキテクチャ４０は、プラットフォーム不問（platform agnostic）である。
すなわち、ウェブサービスアーキテクチャ４０は、例えば、Sun MicrosystemsのＪａｖａ（商標）２プラットフォームのエンタープライズエディション（Ｊ２ＥＥ）またはMicrosoftの．ＮＥＴプラットフォームで開発されたプラットフォームに配備でき、そのプラットフォームと相互作用することができる。
また、ウェブサービスがハードワイヤードネットワークデバイス（コンピュータ等）および携帯電話や携帯情報端末（ＰＤＡ）等の無線デバイスの双方によってアクセスできる点で、アーキテクチャ４０はデバイス不問（device agnostic）でもある。
ウェブサービスアーキテクチャ４０はコンポーネントベースであり、それらコンポーネントは複数のウェブサービスに再利用可能である。
また、上述したアーキテクチャ４０は、特定のクライアントアカウント用にデータをカスタム化する能力も提供する。
構造化照会言語（ＳＱＬ）サーバ、ＳＡＰＡＧのＲ／３集積スイート等のＥＲＰ、およびインターネットプライシングアンドコンフィギュレーション（ＩＰＣ（internet pricing and configuration））データベースに接続する能力も提供される。
複数の入出力フォーマットがサポートされる。
これら入出力フォーマットは、あらゆるテキストに関係したフォーマット、例えばＥＤＩ、ＸＭＬ、またはフラットファイルを含むことができる。

0030

ウェブサービスアーキテクチャ４０は、ウェブサービスを提供するのに使用することができる。
このウェブサービスには、カスタム化された製品カタログを提供すること、製品構成の妥当性を確認すること、または製品の注文を発注することが含まれるが、これらに限定されるものではない。
例示のウェブサービスの実施態様は、以下でより詳細に説明する。
以下で説明するウェブサービスアーキテクチャ４０および方法は、カスタム構成で注文を発注することができるコンピュータ等の「注文仕様生産」の製品の状況で説明される。
これらのアーキテクチャおよびサービスは、他のタイプの製品にも同様に適用でき、したがって、以下の詳細な説明は、限定した意味に解釈されるべきではなく、本発明の範囲が添付した特許請求の範囲によって規定されることが容易に理解できよう。

0031

＜製品カタログウェブサービス＞
一実施の形態では、上述したウェブサービスフレームワーク２０およびウェブサービスアーキテクチャ４０を使用して、製品カタログウェブサービスを提供することができる。
特に、リモート製品カタログをポピュレートするのに必要で、かつ、製品カタログをリモートで提示するのに必要な情報をサポートすることができる。
製品カタログウェブサービスは、「注文仕様生産」（すなわち、カスタム化された）製品を構築するために利用可能な製品ファミリー、製品モデル、製品オプション、およびルールを含む情報を提供することができる。

0032

図３は、クライアント２８がＳＯＡＰ上でＸＭＬを使用して製品カタログウェブサービス９０を呼び出す、製品カタログウェブサービスのトランザクションを実施するウェブサービスフレームワークおよびアーキテクチャの一実施の形態を示している。
インターフェースモジュール５２によって受信されると、クライアント識別情報がＳＯＡＰエンジン６６によって抽出され、実施モジュール５４および実現モジュール５６によって使用されて、ツールキットレイヤ２４の中央製品カタログデータベース９２からデータが取り出されて、適合される。
この中央製品カタログ９２は、例えば、企業資源計画（ＥＲＰ）データベース９３からのデータでポピュレートすることができる。

0033

より詳細には、クライアント識別情報は、インターフェースモジュール５２から実施モジュール５４に渡されて、要求されたサービス（すなわち製品カタログ）を提供するのに必要なビジネスロジックが呼び出される。
本発明による一実施の形態では、実施モジュール５４は、セッションビーン１０２を使用してビジネスロジックを実施し、実現モジュール５６のエンティティビーン１０４を呼び出す。
エンティティビーン１０４は、中央製品カタログデータベース９２から、識別されたクライアントの特定の製品および価格を抽出する。
本発明による一実施の形態では、製品カタログは、（サービス要求が受信された後であって、カタログがクライアントへ返信される前に）オフラインでキャッシュされる。
カタログのサイズが十分大きく、中央製品カタログデータベース９２から必要な情報を抽出するのに比較的長い期間を必要とする場合に、オフラインでキャッシュすることが望ましい場合がある。

0034

抽出され適合されたデータは、その後、クライアント識別情報に関連したフォーマットでのカスタム化された製品カタログの生成に使用される。
図３に示す実施の形態では、カスタム化された製品カタログは、実施モジュール５４において拡張可能スタイル言語変換（ＸＳＬＴ）エンジン１０５を使用して生成されたＸＭＬファイルである。
他の実施の形態では、カスタム化された製品カタログは、例えば、ＨＴＴＰページ、フラットファイル、または他の任意のテキストに関係したフォーマットとすることができる。
さらに、カスタム化された製品カタログフォーマット（ＸＭＬ、ＨＴＴＰ、フラットファイル等）の各タイプは、クライアント２８の仕様に応じて、そのフォーマットに任意の個数の変形を有することができる。
製品カタログウェブサービスのクライアントの呼び出し９０に応答して、クライアントのカスタム化された製品カタログ９４（図３の例示ではＸＭＬフォーマットによる）が、その後、ＳＯＡＰ上でＸＭＬを使用してクライアント２８に通信される。

0035

製品カタログウェブサービスの一実施の形態では、インターフェースモジュール５２は、例えばＨＰ−ＳＯＡＰ、または、Ａｐａｃｈｅ ＳＯＡＰやＡｐａｃｈｅ Ａｘｉｓ等の別の適切なＳＯＡＰのバージョンを使用する。
製品カタログファイルは、文書交換がＸＭＬを介して行われる添付ファイルとして送信することができる。

0036

本発明による製品カタログウェブサービスの一実施の形態のクラス図を図４に示す。
クライアント２８が、ＳＯＡＰ上でＸＭＬを使用して製品カタログウェブサービス９０を呼び出し、カスタム化された製品カタログを得ると、サービスコールがインターフェースモジュール５２により処理されて（RequestProcessor（要求プロセッサ））、クライアント２８が識別され、クライアント特有のＪａｖａ（商標）サーバページ（ＪＳＰ）９８が呼び出される。
製品カタログウェブサービスが最初に要求された時、ＪＳＰ９８は、適切なセッションビーン８０を呼び出し、次に、この適切なセッションビーン８０は、汎用ＸＭＬファイルを生成するのに必要なエンティティビーン８２を呼び出す。
続いて、この汎用ＸＭＬファイルは、クライアントの特定のＸＭＬ製品カタログ９４のフォーマットを表すクライアント特有のＸＭＬファイル１００に変換される。
製品カタログウェブサービス９０が最初に要求された後、汎用ＸＭＬファイルがその最初の作成後に保存される場合、汎用ＸＭＬファイルを再生成する必要はない。
また、ＪＳＰ９８は、中央製品カタログセッションビーン１０２も呼び出し、次に、この中央製品カタログセッションビーン１０２は、中央製品カタログエンティティビーン１０４を呼び出す。
このエンティティビーン１０４は、中央製品カタログデータベース９２と相互作用し、「注文仕様生産」の製品を構築するための製品ファミリー（getFamilies（ファミリーを得る））、製品モデル（getModels（モデルを得る））、製品オプション（getCSticsVals（訳不明？））、およびルール（getinCompatabilities（互換になる））を取り出す。
続いて、クライアントにカスタム化された製品カタログが、ＪＳＰ９８によって生成され、クライアント２８に返信される。
本発明の一実施の形態では、サービスログマネージャ１０６も製品カタログセッションビーン１０２によって呼び出されて、ウェブサービスのサービス要求、応答、エラー、およびタイムスタンプをログ記録することもできる。

0037

図５では、図４のクラス図について上述した動作の可能な一シーケンスを示すシーケンス図を提示する。
当業者は、他のシーケンスが容易に実施されることを認識する。
まず、クライアント２８が製品カタログウェブサービスを呼び出して製品カタログを得ると、インターフェースモジュール５２が、要求プロセッサとして機能し、特定のクライアント２８（図５の例では小売業者）を識別する。
続いて、サービス要求が、サービスログマネージャ１０６を用いてログ記録される。
続いて、クライアント特有のＪＳＰ９８が呼び出されて、注文仕様生産の製品を構築するためにどの製品ファミリー、どの製品モデル、どの製品オプション、およびどのルールを特定のクライアント２８に適用できるかが判断される。
続いて、セッションビーン１０２が呼び出されて、サービス要求のビジネスロジックが実行される。
セッションビーン１０２は、エンティティビーン１０４を呼び出して、中央製品カタログデータベース９２と相互作用し、注文仕様生産の製品を構築するための製品ファミリー（getFamilies）、製品モデル（getModels）、製品オプション（getCSticsVals）、およびルール（getinCompatabilities）を抽出する。
中央製品カタログデータベース９２から抽出されたデータが返信されると、セッションビーン１０２は、エンティティビーン１０４からの応答をログ記録する。
ＸＭＬベースの製品カタログが、事前に呼び出されたＪＳＰ９８を使用して生成される。
続いて、このＸＭＬベースの製品カタログは、インターフェースレイヤ５２を通じ、ＳＯＡＰ上のＸＭＬを介してクライアント２８に返信される。

0038

＜製品構成妥当性確認ウェブサービス＞
別の実施の形態では、クライアントがカスタム製品または「注文仕様生産」の製品の注文を発注している場合等に、上述したウェブサービスフレームワーク２０およびウェブサービスアーキテクチャ４０を使用して、製品構成の妥当性を確認することができる。

0039

図６は、クライアント２８がＳＯＡＰ上でＸＭＬを使用して構成妥当性確認サービスのウェブサービス要求１２０を送信する製品構成妥当性確認ウェブサービストランザクションを実施するウェブサービスフレームワークおよびアーキテクチャの一実施の形態を示している。
サービス要求１２０は、クライアント２８が妥当性を確認させたい製品構成を含む。
製品構成妥当性確認サービス要求１２０がインターフェースモジュール５２によって受信されると、インターフェースモジュール５２は、その要求を構成妥当性確認要求として識別し、実施モジュール５４の製品構成妥当性確認セッションビーン１２２を呼び出す。

0040

本発明による一実施の形態では、提出された製品構成の妥当性を確認することは、２つのステップを含む；すなわち、第１に、提出された製品構成が実際に製品であることを確認すること、および、第２に、提出された製品構成が妥当であることを確認すること、を含む。
したがって、構成妥当性確認セッションビーン１２２は、まず、実現モジュール５６のエンティティビーン１０４を呼び出して中央製品カタログ９２と相互作用し、提出された製品構成が実際に製品であることを確認する。
提出された製品構成が製品であると確認されると、セッションビーン１２２は、次に、実現モジュール５６のコンフィギュレータアプリケーションプログラムインターフェース（ＡＰＩ）１２４を呼び出す。
コンフィギュレータＡＰＩ１２４は、コンフィギュレータデータベース１２６と相互作用して、提出された製品構成の妥当性を実時間で確認し、クライアント２８に返答１２８を返信する。
この返答１２８は、クライアント２８に妥当でない構成を説明するエラーメッセージであれば、当該メッセージと共に、「製品構成が妥当である」や「製品構成が妥当でない」等のメッセージを含む。
必要に応じて、本発明による別の実施の形態では、提出された製品構成が実際に製品であることを確認するステップは省略することができる。

0041

製品構成妥当性確認ウェブサービスの一実施の形態では、インターフェースモジュール５２は、例えば、ＨＰ−ＳＯＡＰ、または、Ａｐａｃｈｅ ＳＯＡＰやＡｐａｃｈｅ Ａｘｉｓ等の別の適切なＳＯＡＰのバージョンを使用する。
実現モジュール５６では、コンフィギュレータＡＰＩ１２４は、例えば、ＳＡＰＡＧのコンフィギュレータＩＰＣ２．０とすることができる。
コンフィギュレータデータベース１２６は、例えば、ＳＡＰ ＡＧから入手可能な販売、価格、および構成（ＳＰＣ（sales, pricing and configuration））データベースとすることができる。

0042

本発明による製品構成妥当性確認ウェブサービスの一実施の形態のシーケンス図を図７に示す。
クライアント２８が製品構成妥当性確認ウェブサービスを（ＳＯＡＰ上でＸＭＬを使用して）呼び出して、製品構成の妥当性を確認する時、このサービスコールは、構成妥当性確認セッションビーン１２２を呼び出す。
定義によれば在庫注文の製品は妥当な構成を有するので、このセッションビーン１２２は、カスタム化されていないか、または、「在庫注文（stock-to-order）」の製品をサービス要求から取り除く（removeSTOitem（ＳＴＯ項目を取り除く））。
また、構成妥当性確認セッションビーン１２２は、コンフィギュレータＡＰＩ１２４も呼び出して、コンフィギュレータデータベース１２６と相互作用し、提出された製品構成の妥当性を確認する。
構成の妥当性が確認された後、返答１２８が、「正当である」または「正当でない」のいずれかの結果と共にクライアント２８に渡される。
提出された製品構成の利用可能な出荷日等の他の情報もクライアント２８に渡すことができる。

0043

＜製品注文発注ウェブサービス＞
別の実施の形態では、上述したウェブサービスフレームワーク２０およびウェブサービスアーキテクチャ４０を使用して、製品注文発注ウェブサービスを提供することができる。
特に、このサービスは、製品注文を満たすのに必要な情報を収集でき、注文実現プロセスを起動することができる。

0044

図８は、クライアント２８がＳＯＡＰ上でＸＭＬを使用して製品注文発注ウェブサービス要求１４０を送信する製品注文発注トランザクションを実施するウェブサービスフレームワークおよびアーキテクチャの一実施の形態を示している。
この製品注文発注ウェブサービス要求１４０は、所望の製品構成、クライアントおよび顧客のデータ（口座番号、住所等）、届け先住所、課金情報、出荷オプション等の情報を含むことができる。
実施モジュール５２によって受信されると、注文発注セッションビーン１６０が呼び出されて、要求されたサービスを提供するのに必要なビジネスロジックを実施する。
このセッションビーン１６０は、注文発注エンティティビーン１６２を呼び出し、また、ＥＲＰ９３と相互作用するように構成されたアプリケーションプログラムインターフェース１６４も呼び出す。
ＡＰＩ１６４は、ＥＲＰ９３の注文実現システム／データベースに製品の注文を発注して、注文実現プロセスを起動する。
この注文は、エンティティビーン１６２が、注文のバックアップ、追跡、顧客サービス等の目的で、別個の注文データベース１４２にもさらに発注することができる。

0045

場合によっては、さまざまな理由から、クライアント２８による注文発注は、ＳＯＡＰ上のＸＭＬを使用して可能でない場合がある。
このような状況では、クライアント２８は、電子データ交換（ＥＤＩ）等の別のシステムを使用して製品注文発注サービス要求を起動することができる。
ＥＤＩを使用した製品注文発注トランザクションフローを図８の破線によって示す。
ＥＤＩを使用して製品注文発注サービス要求１４０'が行われる場合には、サービス要求１４０'および必要なデータをＸＭＬフォーマットの要求１４０"に変換しなければならない。
ＥＤＩからＸＭＬへの変換は、トランスレータ１５０を使用して行われる。
トランスレータ１５０は、インターフェースモジュール５２と通信する前に、ＥＤＩフォーマットの要求１４０'をＸＭＬフォーマットの要求１４０"に変換する。
変換された要求１４０"は、ＳＯＡＰ上のＸＭＬを介してインターフェースモジュール５２へ送信され、ウェブサービス要求１４０"は、ＸＭＬフォーマットの要求として発信された要求１４０と同じように処理される。

0046

図９は、製品注文発注サービス要求１４０または１４０"がクライアント２８に送信される際に行われるオペレーションの可能な一シーケンスを示している。
サービス要求１４０、１４０"が受信された後、注文発注セッションビーン１６０が呼び出される。
製品構成が、事前に正当であると確認されていない場合には、注文された製品構成の妥当性を確認するために、注文発注セッションビーン１６０は、まず、製品構成妥当性確認セッションビーン１２２を呼び出し、次に、製品構成妥当性確認セッションビーン１２２が、上記でより詳細に説明したように、コンフィギュレータＡＰＩ１２４を呼び出して構成妥当性確認サービスを提供する。
製品構成の妥当性が確認された後、注文発注セッションビーン１６０は、次に、注文発注エンティティビーン１６２を呼び出し、次いで、注文要求を順番に並べる。
注文発注エンティティビーン１６２は、注文データベース１４２と相互作用して、指定されたデータをデータベース１４２に記録する。
続いて、注文発注セッションビーン１６０は、ＥＲＰ ＡＰＩ１６４を呼び出して、ＥＲＰ９３の注文実現システム／データベースに製品の注文を発注し、（工場に注文を送信する等によって）注文の実現を開始する。
続いて、注文または製品構成に関する適切なエラーメッセージ１７０があれば、当該メッセージがクライアント２８に返信され、その結果、必要な訂正があれば、当該訂正を行うことができる。

0047

本発明による一実施の形態では、注文データベース１４２は、図１０に示すようなさまざまな情報を含む。
例示の注文情報には、製品構成に関するデータ、顧客に関するデータ、および顧客の口座に関するデータが含まれる。
データの具体的な例には、購入注文番号、購入日、口座ＩＤ、製品構成、届け先住所等が含まれる。
本発明による一実施の形態では、注文実現システム／データベースは、例えば、ＳＡＰＡＧのＲ／３エンタープライズ資源プログラムスイートである。

0048

本明細書では、好ましい実施の形態を説明するために、特定の実施の形態を図示して説明してきたが、当業者には、本発明の範囲から逸脱することなく、多種多様の代わりの、かつ／または、均等な実施態様を、図示して説明した特定の実施の形態の代わりに使用できることが理解されよう。
化学の分野、機械の分野、メカトロの分野、電気の分野、およびコンピュータの技術分野の当業者には、本発明を非常に多種多様の実施の形態で実施できることが容易に理解されよう。
この出願は、本明細書で説明した好ましい実施の形態のあらゆる適合または変形をカバーするように意図されている。
したがって、この発明は、特許請求の範囲およびその均等物によってのみ限定されることが明白に意図されている。

0049

本発明によるウェブサービスフレームワークの一実施の形態を示すブロック図である。
本発明によるアプリケーションサーバレイヤ上のウェブサービスアーキテクチャの一実施の形態を示すブロック図である。
本発明によるウェブサービスアーキテクチャの例示の一実施の形態を示すブロック図である。
ウェブサービスフレームワークおよびアーキテクチャの一実施の形態において実際される製品カタログウェブサービストランザクションの例示の一実施の形態を示すブロック図である。
製品カタログウェブサービスの例示の一実施の形態を示すクラス図である。
製品カタログウェブサービスの例示の一実施の形態を示すシーケンス図である。
ウェブサービスフレームワークおよびアーキテクチャの一実施の形態において実施される製品構成妥当性確認ウェブサービストランザクションの例示の一実施の形態を示すブロック図である。
製品構成妥当性確認ウェブサービスの例示の一実施の形態を示すシーケンス図である。
ウェブサービスフレームワークおよびアーキテクチャの一実施の形態において実施される製品注文発注ウェブサービストランザクションの例示の一実施の形態を示すブロック図である。
製品注文発注ウェブサービスの例示の一実施の形態を示すシーケンス図である。
製品注文データベースの例示の一実施の形態を示すブロック図である。

0050

２２・・・基盤レイヤ，
２４・・・ツールキットレイヤ，
２６・・・アプリケーションサーバレイヤ，
２８・・・クライアント，
３０・・・インターネット，
５２・・・インターフェースモジュール，
５４・・・実施モジュール，
５６・・・実現モジュール，
６６・・・ＳＯＡＰエンジン，
８０・・・セッションビーン，
８２・・・エンティティビーン，
９２・・・中央製品カタログデータベース，
１０２・・・セッションビーン，
１０４・・・エンティティビーン，
１０５・・・ＸＳＬＴエンジン，
１２２，１６０・・・セッションビーン，
１２４・・・コンフィギュレータＡＰＩ，
１２６・・・コンフィギュレータ，
１４２・・・注文データベース，
１５０・・・トランスレータ，