図面 (/)

この項目の情報は公開日時点(2005年10月27日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (12)

課題

解決手段

本発明にかかるシステムは、ネットワークと通信するインターフェースモジュールと、インターフェースモジュールと通信する実施モジュールと、実施モジュールおよび少なくとも1つのデータベースと通信する実現モジュールとを含む。インターフェースモジュールは、クライアントからウェブサービス要求を受信し、この要求を当該システムの少なくとも1つの他のコンポーネントへ渡し、かつ、このウェブサービス要求に応答して適合されたデータをクライアントへ渡す。実施モジュールは、サービス要求に応答して、当該システムの少なくとも1つの他のコンポーネントによって提供されたデータを適合させる。実現モジュールは、サービス要求に応答して少なくとも1つのデータベースからデータを抽出し、かつ、当該抽出したデータを実施モジュールに提供する。

概要

背景

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

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

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

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

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

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

ウェブサービスによって、異なるソースからの異なるアプリケーションは、多くの時間を必要とするカスタムコーディングを行うことなく、互いに通信することが可能になる。
転送されたデータがすべてのタイプのシステムによって理解できるように、オブジェクトを渡すのではなく、テキストフォーマットが使用される。
すべての通信はXMLで行われるので、ウェブサービスは、どの特定の1つのオペレーティングシステムにもプログラミング言語にも拘束されない。
例えば、Java(商標)はPerlとトークすることができ、Windows(商標)アプリケーションはUNIX(商標)アプリケーションとトークすることができる。
さらに、ウェブサービスは、通信するのにインターネットブラウザの使用もハイパーテキストマークアップ言語HTML)の使用も必要としない。

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

概要

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

目的

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

効果

実績

技術文献被引用数
1件
牽制数
1件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ウェブサービスを提供するシステムであって、ネットワーク(30)を介して通信するインターフェースを有する少なくとも1つのサーバコンピュータ(26)と、前記サーバコンピュータ(26)と通信するインターフェースモジュール(52)であって、クライアント(28)からサービス要求を受信し、前記サービス要求を該システムの少なくとも1つの他のコンポーネントへ渡し、前記サービス要求に応答して適合されたデータを前記クライアント(28)へ渡すソフトウェアを備えるインターフェースモジュール(52)と、前記インターフェースモジュール(52)と通信する実施モジュール(54)であって、前記サービス要求に応答して、該システムの少なくとも1つの他のコンポーネントによって提供されたデータを適合させるソフトウェアを備える実施モジュール(54)と、前記実施モジュール(54)と通信する実現モジュール(56)であって、前記サービス要求に応答して少なくとも1つのデータベースからデータを抽出し、該抽出したデータを前記実施モジュール(54)に提供するソフトウェアを備える実現モジュール(56)とを備えるシステム。

請求項2

前記インターフェースモジュール(52)、前記実施モジュール(54)および前記実現モジュール(56)は、前記サーバコンピュータ(26)においてホストされる請求項1に記載のウェブサービスを提供するシステム。

請求項3

前記少なくとも1つのデータベースは、製品カタログデータベース(92)を含む請求項1に記載のウェブサービスを提供するシステム。

請求項4

前記少なくとも1つのデータベースは、製品コンフィギュレータデータベース(126)を含む請求項1に記載のウェブサービスを提供するシステム。

請求項5

前記少なくとも1つのデータベースは、製品注文データベース(142)を含む請求項1に記載のウェブサービスを提供するシステム。

請求項6

前記少なくとも1つのデータベースは、企業資源計画データベース(93)を含む請求項1に記載のウェブサービスを提供するシステム。

請求項7

前記インターフェースモジュール(52)は、SOAPエンジンを備える請求項1に記載のウェブサービスを提供するシステム。

請求項8

前記実施モジュール(54)のソフトウェアおよび前記実現モジュール(56)のソフトウェアは、オブジェクト指向型プログラミングを備える請求項1に記載のウェブサービスを提供するシステム。

請求項9

前記オブジェクト指向型プログラミングは、Javaである請求項8に記載のウェブサービスを提供するシステム。

請求項10

前記インターフェースモジュール(52)は、SOAPを使用して、前記実施モジュール(54)と通信する請求項1に記載のウェブサービスを提供するシステム。

技術分野

0001

同時係属中の出願の参照]
以下の同時係属中の米国特許出願が参照される。
すなわち、代理人整理番号第100204041−1号を有する「ARCHITECTURE AND METHODFOR PRODUCTCATALOG WEB SERVICE」という発明の名称の米国特許出願第10/190,154号;代理人整理番号第100204037−1号を有する「ARCHITECTURE AND METHOD FOR CONFIGURATION VALIDATION WEB SERVICE」という発明の名称の米国特許第10/189,974号;および代理人整理番号第100204039−1号を有する「ARCHITECTURE AND METHOD FOR ORDERPLACEMENTWEB SERVICE」という発明の名称の米国特許出願第10/190,180号が参照される。
各出願は、この出願と共に同じ日付で出願され、共通の発明者要件および譲渡を有する。

0002

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

背景技術

0003

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

0004

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

0005

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

0006

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

0007

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

0008

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

0009

ウェブサービスによって、異なるソースからの異なるアプリケーションは、多くの時間を必要とするカスタムコーディングを行うことなく、互いに通信することが可能になる。
転送されたデータがすべてのタイプのシステムによって理解できるように、オブジェクトを渡すのではなく、テキストフォーマットが使用される。
すべての通信はXMLで行われるので、ウェブサービスは、どの特定の1つのオペレーティングシステムにもプログラミング言語にも拘束されない。
例えば、Java(商標)はPerlとトークすることができ、Windows(商標)アプリケーションはUNIX(商標)アプリケーションとトークすることができる。
さらに、ウェブサービスは、通信するのにインターネットブラウザの使用もハイパーテキストマークアップ言語HTML)の使用も必要としない。

0010

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

発明が解決しようとする課題

0011

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

課題を解決するための手段

0012

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

発明を実施するための最良の形態

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

図2に示すように、本発明による一実施の形態では、ウェブサービスアーキテクチャ40は、インターフェースモジュール52、実施モジュール54、および実現モジュール56を含む。
インターフェースモジュール52は、通信リンク60を介してインターネット30に接続され、また、通信リンク61を介して実施モジュール54にも接続される。
実施モジュール54は、通信リンク62によって実現モジュール56に接続される。
実現モジュール56は、通信リンク63によってツールキットレイヤ24に接続され、通信リンク64によって基盤レイヤ22に接続される一方、ツールキットレイヤ24および基盤レイヤは、通信リンク65を介して接続される。
インターフェースモジュール52、実施モジュール54、および実現モジュール56は、モジュール52、54、56のさまざまなコンポーネントに対して適宜選択される1つまたは2つ以上の通信プロトコルを介して通信する。
例えば、SOAP、リモートメソッド呼び出し(RMI)、Java(商標)データベース接続(JDBC)等の通信プロトコルを使用することができる。

0022

本発明による例示の一実施の形態では、SOAPエンジン66がインターフェースモジュール52に使用される一方、エンタープライズJavaBean(商標)(EJB)技術が実施モジュール54および実現モジュール56に使用される。
具体的には、Java(商標)セッションビーン80が実施モジュール54に使用されて、処理タスクの分散および分離を行い、Java(商標)エンティティビーン82が実現モジュール56に使用されて、ツールキットレイヤ24のさまざまなツールと相互作用する。
インターフェースモジュール52と実施モジュール54との間の通信プロトコルはSOAPであり、実施モジュール54と実現モジュール56との間の通信プロトコルはRMIであり、実現モジュール56とツールキットレイヤ24のツールおよびデータベースとの間の通信プロトコルはJDBCである。

0023

インターフェースモジュール52は、本発明による上述した実施の形態では、SOAPエンジン66を備える。
SOAPエンジン66は、クライアント28から受信したサービスコールリスンする汎用リスナを有する。
インターフェースモジュール52は、インターネット30との通信リンク68を介してクライアント28から、特定のウェブサービスの(SOAP上でXMLを使用して送信された)サービスコールを受信するように機能する。
SOAPエンジンは、XMLを構文解析してSOAP「エンベロープ」を取り除き、サービスコールの発信元ユニフォームリソースロケータ(URL)を識別し、要求されたサービスおよびサービスパラメータ、ならびにデータタイプを識別し、次いで、必要なビジネスロジックを呼び出して、要求されたサービスを提供する。

0024

インターフェースモジュール52は、移植性のためにオブジェクト指向型プログラミングベースとなっており、プラグアンドプレイができるようにコンポーネントベースとなっている。
本発明による一実施の形態では、インターフェースモジュール52は、純粋なJava(商標)APIを使用して文書指向型のXMLメッセージの送信および受信を可能にするためにXMLメッセージング用Java(商標)API(JAXM)を含む。
本発明による別の実施の形態では、インターフェースモジュール52は、XMLベースPC用Java(商標)API(JAX−RPC)を含む。
JAX−RPCは、SOAP仕様によるXMLベースのリモートプロシージャコール(RPC)機能を組み込んだウェブサービスを可能にする。
RPCメカニズムによって、クライアント28からのリモートプロシージャコールをリモートサーバへ通信することが可能になる。
XMLベースのRPCでは、リモートプロシージャコールは、SOAP等のXMLベースのプロトコルを使用して表される。
XMLベースのRPCサーバアプリケーションは、RPCベースのサービスとしてウェブサービスの定義、記述、およびエキスポートを行うことができる。
また、JAX−RPCは、WSDLによって記述されたサービスを実施するのにも使用することができる。

0025

HP−SOAP、Apache Soap(アパッチソープ)、Apache Axis(アパッチアクシス)等、SOAPのさまざまなバージョンが市販されている。
所望の特徴に応じて、SOAPのこれらのバージョンおよび他のバージョンの1つまたは2つ以上をインターフェースモジュール52で使用することができる。

0026

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

0027

実現モジュール56は、実施モジュール54が必要とする処理タスクを実行して、要求されたサービスを提供する。
実現モジュール56は、ツールキットレイヤ24のツールおよびデータベース、ならびに/または、要求されたサービスを提供するのに必要なデータを含む基盤レイヤ22と通信する。
本発明による一実施の形態では、実現モジュール56は、移植性のためにエンタープライズJavaBean(商標)(EJB)技術を特徴として備え、プラグアンドプレイができるようにコンポーネントベースとなっている。
図2に示す実施の形態では、実現モジュール56は、エンティティビーン82を使用して、ツールキットレイヤ24の適切なツールおよびデータベース、ならびに/または、基盤レイヤ22と相互作用し、必要な処理タスクを実行する。
エンティティビーン82は、実施モジュール54のセッションビーン80によって呼び出される。
エンティティビーン82に加えて、実現モジュール56は、さらに、アプリケーションプログラミングインターフェース(API)を使用して、ツールキットレイヤ24の特定のツールおよびデータベース、ならびに/または、基盤レイヤ22と相互作用することができる。

0028

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

0029

重要な利益として、ウェブサービスアーキテクチャ40は、プラットフォーム不問(platform agnostic)である。
すなわち、ウェブサービスアーキテクチャ40は、例えば、Sun MicrosystemsのJava(商標)2プラットフォームのエンタープライズエディション(J2EE)またはMicrosoftの.NETプラットフォームで開発されたプラットフォームに配備でき、そのプラットフォームと相互作用することができる。
また、ウェブサービスがハードワイヤードネットワークデバイス(コンピュータ等)および携帯電話や携帯情報端末(PDA)等の無線デバイスの双方によってアクセスできる点で、アーキテクチャ40はデバイス不問(device agnostic)でもある。
ウェブサービスアーキテクチャ40はコンポーネントベースであり、それらコンポーネントは複数のウェブサービスに再利用可能である。
また、上述したアーキテクチャ40は、特定のクライアントアカウント用にデータをカスタム化する能力も提供する。
構造化照会言語SQL)サーバ、SAPAGのR/3集積スイート等のERP、およびインターネットプライシングアンドコンフィギュレーション(IPC(internet pricing and configuration))データベースに接続する能力も提供される。
複数の入出力フォーマットサポートされる。
これら入出力フォーマットは、あらゆるテキストに関係したフォーマット、例えばEDI、XML、またはフラットファイルを含むことができる。

0030

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

0031

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

0032

図3は、クライアント28がSOAP上でXMLを使用して製品カタログウェブサービス90を呼び出す、製品カタログウェブサービスのトランザクションを実施するウェブサービスフレームワークおよびアーキテクチャの一実施の形態を示している。
インターフェースモジュール52によって受信されると、クライアント識別情報がSOAPエンジン66によって抽出され、実施モジュール54および実現モジュール56によって使用されて、ツールキットレイヤ24の中央製品カタログデータベース92からデータが取り出されて、適合される。
この中央製品カタログ92は、例えば、企業資源計画(ERP)データベース93からのデータでポピュレートすることができる。

0033

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

0034

抽出され適合されたデータは、その後、クライアント識別情報に関連したフォーマットでのカスタム化された製品カタログの生成に使用される。
図3に示す実施の形態では、カスタム化された製品カタログは、実施モジュール54において拡張可能スタイル言語変換(XSLT)エンジン105を使用して生成されたXMLファイルである。
他の実施の形態では、カスタム化された製品カタログは、例えば、HTTPページ、フラットファイル、または他の任意のテキストに関係したフォーマットとすることができる。
さらに、カスタム化された製品カタログフォーマット(XML、HTTP、フラットファイル等)の各タイプは、クライアント28の仕様に応じて、そのフォーマットに任意の個数の変形を有することができる。
製品カタログウェブサービスのクライアントの呼び出し90に応答して、クライアントのカスタム化された製品カタログ94(図3の例示ではXMLフォーマットによる)が、その後、SOAP上でXMLを使用してクライアント28に通信される。

0035

製品カタログウェブサービスの一実施の形態では、インターフェースモジュール52は、例えばHP−SOAP、または、Apache SOAPやApache Axis等の別の適切なSOAPのバージョンを使用する。
製品カタログファイルは、文書交換がXMLを介して行われる添付ファイルとして送信することができる。

0036

本発明による製品カタログウェブサービスの一実施の形態のクラス図図4に示す。
クライアント28が、SOAP上でXMLを使用して製品カタログウェブサービス90を呼び出し、カスタム化された製品カタログを得ると、サービスコールがインターフェースモジュール52により処理されて(RequestProcessor(要求プロセッサ))、クライアント28が識別され、クライアント特有のJava(商標)サーバページ(JSP)98が呼び出される。
製品カタログウェブサービスが最初に要求された時、JSP98は、適切なセッションビーン80を呼び出し、次に、この適切なセッションビーン80は、汎用XMLファイルを生成するのに必要なエンティティビーン82を呼び出す。
続いて、この汎用XMLファイルは、クライアントの特定のXML製品カタログ94のフォーマットを表すクライアント特有のXMLファイル100に変換される。
製品カタログウェブサービス90が最初に要求された後、汎用XMLファイルがその最初の作成後に保存される場合、汎用XMLファイルを再生成する必要はない。
また、JSP98は、中央製品カタログセッションビーン102も呼び出し、次に、この中央製品カタログセッションビーン102は、中央製品カタログエンティティビーン104を呼び出す。
このエンティティビーン104は、中央製品カタログデータベース92と相互作用し、「注文仕様生産」の製品を構築するための製品ファミリー(getFamilies(ファミリーを得る))、製品モデル(getModels(モデルを得る))、製品オプション(getCSticsVals(訳不明?))、およびルール(getinCompatabilities(互換になる))を取り出す。
続いて、クライアントにカスタム化された製品カタログが、JSP98によって生成され、クライアント28に返信される。
本発明の一実施の形態では、サービスログマネージャ106も製品カタログセッションビーン102によって呼び出されて、ウェブサービスのサービス要求、応答、エラー、およびタイムスタンプログ記録することもできる。

0037

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

0038

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

0039

図6は、クライアント28がSOAP上でXMLを使用して構成妥当性確認サービスのウェブサービス要求120を送信する製品構成妥当性確認ウェブサービストランザクションを実施するウェブサービスフレームワークおよびアーキテクチャの一実施の形態を示している。
サービス要求120は、クライアント28が妥当性を確認させたい製品構成を含む。
製品構成妥当性確認サービス要求120がインターフェースモジュール52によって受信されると、インターフェースモジュール52は、その要求を構成妥当性確認要求として識別し、実施モジュール54の製品構成妥当性確認セッションビーン122を呼び出す。

0040

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

0041

製品構成妥当性確認ウェブサービスの一実施の形態では、インターフェースモジュール52は、例えば、HP−SOAP、または、Apache SOAPやApache Axis等の別の適切なSOAPのバージョンを使用する。
実現モジュール56では、コンフィギュレータAPI124は、例えば、SAPAGのコンフィギュレータIPC2.0とすることができる。
コンフィギュレータデータベース126は、例えば、SAP AGから入手可能な販売、価格、および構成(SPC(sales, pricing and configuration))データベースとすることができる。

0042

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

0043

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

0044

図8は、クライアント28がSOAP上でXMLを使用して製品注文発注ウェブサービス要求140を送信する製品注文発注トランザクションを実施するウェブサービスフレームワークおよびアーキテクチャの一実施の形態を示している。
この製品注文発注ウェブサービス要求140は、所望の製品構成、クライアントおよび顧客のデータ(口座番号住所等)、届け先住所課金情報、出荷オプション等の情報を含むことができる。
実施モジュール52によって受信されると、注文発注セッションビーン160が呼び出されて、要求されたサービスを提供するのに必要なビジネスロジックを実施する。
このセッションビーン160は、注文発注エンティティビーン162を呼び出し、また、ERP93と相互作用するように構成されたアプリケーションプログラムインターフェース164も呼び出す。
API164は、ERP93の注文実現システム/データベースに製品の注文を発注して、注文実現プロセスを起動する。
この注文は、エンティティビーン162が、注文のバックアップ、追跡、顧客サービス等の目的で、別個の注文データベース142にもさらに発注することができる。

0045

場合によっては、さまざまな理由から、クライアント28による注文発注は、SOAP上のXMLを使用して可能でない場合がある。
このような状況では、クライアント28は、電子データ交換(EDI)等の別のシステムを使用して製品注文発注サービス要求を起動することができる。
EDIを使用した製品注文発注トランザクションフロー図8破線によって示す。
EDIを使用して製品注文発注サービス要求140'が行われる場合には、サービス要求140'および必要なデータをXMLフォーマットの要求140"に変換しなければならない。
EDIからXMLへの変換は、トランスレータ150を使用して行われる。
トランスレータ150は、インターフェースモジュール52と通信する前に、EDIフォーマットの要求140'をXMLフォーマットの要求140"に変換する。
変換された要求140"は、SOAP上のXMLを介してインターフェースモジュール52へ送信され、ウェブサービス要求140"は、XMLフォーマットの要求として発信された要求140と同じように処理される。

0046

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

0047

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

0048

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

図面の簡単な説明

0049

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

符号の説明

0050

22・・・基盤レイヤ,
24・・・ツールキットレイヤ,
26・・・アプリケーションサーバレイヤ,
28・・・クライアント,
30・・・インターネット,
52・・・インターフェースモジュール,
54・・・実施モジュール,
56・・・実現モジュール,
66・・・SOAPエンジン,
80・・・セッションビーン,
82・・・エンティティビーン,
92・・・中央製品カタログデータベース,
102・・・セッションビーン,
104・・・エンティティビーン,
105・・・XSLTエンジン,
122,160・・・セッションビーン,
124・・・コンフィギュレータAPI,
126・・・コンフィギュレータ,
142・・・注文データベース,
150・・・トランスレータ,

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ