(57)【要約】  ＣＲＭプログラムのＡＰＩの機能を拡張する方法と、当該方法を実装するためのシステムが開示される。この方法により、過去に定義したクラスを拡張させることによって新たなビジネスロジックとオペレーションを作成するためのＣＲＭウェブサービスモジュールとして提示される単一のインタフェースにより、ユーザにリクエストメッセージとレスポンスメッセージの使用を可能とする。
2009500753.tif 000002
【特許請求の範囲】
【請求項１】
カスタマーリレーションシップマネージメント（「ＣＲＭ」）システムにおけるアプリケーションプログラミングインタフェースの機能を拡張するために、メッセージを使用する方法であって、
ＣＲＭオペレーションである、オペレーションを選択するステップと、
前記選択されたオペレーションに基づいて、リクエストメッセージをＣＲＭウェブサービスに伝達するステップと、
前記リクエストメッセージがリクエストメッセージ名にビジネスエンティティタイプ名を有している場合、当該リクエストメッセージは、名前付きエンティティに対してのみ有効であるものとして、
前記リクエストメッセージをインスタンス化し、
リクエストメッセージフィールドを割り当て、
前記リクエストメッセージを実行するステップと、
前記リクエストメッセージがリクエストメッセージ名にビジネスタイプ名のない一般的なリクエストメッセージであり、かつ前記リクエストメッセージがターゲットプロパティを有している場合、
前記リクエストメッセージをインスタンス化し、
サポートされているターゲットクラスの１つを選択してインスタンス化し、
ターゲットクラスフィールドを割り当て、
前記リクエストメッセージフィールドを割り当て、
ターゲットクラスと前記リクエストメッセージを関連付け、
前記リクエストメッセージを実行するステップと、
前記リクエストメッセージ名がビジネスエンティティ名を含んでおらず、前記メッセージがターゲットプロパティも有していない場合、
前記リクエストメッセージをインスタンス化し、
前記リクエストメッセージフィールドを割り当て、
前記リクエストメッセージを実行するステップとを備えることを特徴とする方法。
【請求項２】
全ての新しいメッセージは、基本リクエストクラスおよび基本レスポンスクラスから導出されることを特徴とする請求項１に記載の方法。
【請求項３】
前記方法は、リクエストメッセージを伝達し、レスポンスメッセージを返すことによって実行されることを特徴とする請求項１に記載の方法。
【請求項４】
前記リクエストメッセージは、ＣＲＭウェブサービスのクライアントによって、インスタンス化され、構築されることを特徴とする請求項１に記載の方法。
【請求項５】
前記メッセージは、トランスポートプロトコルによって前記ＣＲＭウェブサービスに送信されることを特徴とする請求項１に記載の方法。
【請求項６】
ビジネスオペレーションは、ビジネスエンティティに割り当てられることを特徴とする請求項１に記載の方法。
【請求項７】
カテゴリによってサポートされるビジネスオペレーションに基づいて、ビジネスエンティティを前記カテゴリに分類することにより、ターゲット基本クラスを作成することを特徴とする請求項１に記載の方法。
【請求項８】
どのビジネスエンティティがどのオペレーションをサポートするかを判断するために、ターゲットクラス階層を使用することを特徴とする請求項１に記載の方法。
【請求項９】
ビデオ画像を生成可能な表示部と、
入力装置と、
前記表示部および前記入力装置と動作可能に結合された処理装置であって、プロセッサと、該プロセッサと動作可能に結合されたメモリとを含む処理装置と、
ネットワークおよび前記処理装置に接続されたネットワークインタフェースとを備えるコンピューティング装置であって、
前記処理装置は、
カスタマーリレーションシップマネージメント（ＣＲＭ）のオペレーションであるオペレーションを選択し、
前記選択したオペレーションに基づきトランスポートプロトコルを介して、リクエストメッセージをＣＲＭウェブサービスに伝達し、
前記リクエストメッセージがリクエストメッセージ名にビジネスエンティティタイプ名を有している場合、当該リクエストメッセージは、名前付きエンティティに対してのみ有効であるものとして、
前記リクエストメッセージをインスタンス化し、
リクエストメッセージフィールドを割り当て、
前記リクエストメッセージを実行し、
前記リクエストメッセージがリクエストメッセージ名にビジネスタイプ名のない一般的なリクエストメッセージであり、かつ前記リクエストメッセージがターゲットプロパティを有している場合、
前記リクエストメッセージをインスタンス化し、
サポートされているターゲットクラスの１つを選択してインスタンス化し、
ターゲットクラスフィールドを割り当て、
前記リクエストメッセージフィールドを割り当て、
ターゲットクラスと前記リクエストメッセージを関連付け、
前記リクエストメッセージを実行し、
前記リクエストメッセージがリクエストメッセージ名にビジネスエンティティ名を含んでおらず、前記メッセージがターゲットプロパティも有していない場合、
前記リクエストメッセージをインスタンス化し、
前記リクエストメッセージフィールドを割り当て、
前記リクエストメッセージを実行するためにプログラミングされていることを特徴とするコンピューティング装置。
【請求項１０】
前記リクエストメッセージは、ＣＲＭウェブサービスのクライアントによって、インスタンス化され、構築されることを特徴とする請求項９に記載のコンピューティング装置。
【請求項１１】
カテゴリによってサポートされるビジネスオペレーションに基づいて、ビジネスエンティティを前記カテゴリに分類することにより、ターゲット基本クラスを作成し、どのビジネスエンティティがどのオペレーションをサポートするかを判断するために、ターゲットクラス階層を評価することができることを特徴とする請求項９に記載のコンピューティング装置。
【請求項１２】
カスタマーリレーションシップマネージメント（「ＣＲＭ」）システムのアプリケーションプログラミングインタフェースの機能を拡張するために、メッセージを使用して、コンピュータで実行可能なコードを格納するよう適応させたコンピュータ読み取り可能な媒体であって、前記コンピュータで実行可能なコードは、
カスタマーリレーションシップマネージメント（ＣＲＭ）のオペレーションである、オペレーションを選択し、
前記選択されたオペレーションに基づき、ＣＲＭウェブサービスのクライアントによってインスタンス化および構築されるリクエストメッセージをＣＲＭウェブサービスに伝達し、
前記リクエストメッセージがリクエストメッセージ名にビジネスエンティティタイプ名を有している場合、当該リクエストメッセージは、名前付きエンティティに対してのみ有効であるものとして、
前記リクエストメッセージをインスタンス化し、
リクエストメッセージフィールドを割り当て、
前記リクエストメッセージを実行し、
前記リクエストメッセージがリクエストメッセージ名にビジネスタイプ名のない一般的なリクエストメッセージであり、かつ前記リクエストメッセージがターゲットプロパティを有している場合、
前記リクエストメッセージをインスタンス化し、
サポートされているターゲットクラスの１つを選択してインスタンス化し、
ターゲットクラスフィールドを割り当て、
前記リクエストメッセージフィールドを割り当て、
ターゲットクラスと前記リクエストメッセージを関連付け、
前記リクエストメッセージを実行し、
前記リクエストメッセージがリクエストメッセージ名にビジネスエンティティ名を含んでおらず、前記メッセージがターゲットプロパティも有していない場合、
前記リクエストメッセージをインスタンス化し、
前記リクエストメッセージフィールドを割り当て、
前記リクエストメッセージを実行するためのコンピュータコードを含むことを特徴とするコンピュータ読み取り可能な媒体。
【請求項１３】
前記リクエストメッセージは、ＣＲＭウェブサービスのクライアントによってインスタンス化および構築されることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【請求項１４】
カテゴリによってサポートされるビジネスオペレーションに基づいて、ビジネスエンティティを前記カテゴリに分類することにより、ターゲット基本クラスを作成し、どのビジネスエンティティがどのオペレーションをサポートするかを判断するために、ターゲットクラス階層を評価することができることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【請求項１５】
全ての新しいメッセージは、基本リクエストクラスおよび基本レスポンスクラスから導出されることを特徴とする請求項１２に記載のコンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＣＲＭ機能の拡張にメッセージを使用する方法に関する。
【背景技術】
【０００２】
典型的なビジネスアプリケーションには、数多くのビジネスエンティティが設けられ、これらのエンティティには、ビジネスロジックに基づいて、様々なオペレーションを行うことができる。このようなアプリケーションには、アプリケーションプログラミングインタフェース（ＡＰＩ）が設けられており、これらのエンティティへのアクセスや、当該エンティティに関連したビジネスロジックの実行が可能である。ビジネスアプリケーションにおいては、相互運用性が非常に重要な要件であることから、ＡＰＩの設計にウェブサービス技術を使用することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ＡＰＩの消費者はＡＰＩの署名に依存しており、ライフサイクルの間に、ＡＰＩの変更によって影響されている。また、そのようなアプリケーション内に存在するビジネスエンティティの数に比例し、同様の数の静的オペレーション（メソッド）が定義されており、ＡＰＩを通じて利用可能となっている。
【課題を解決するための手段】
【０００４】
ＣＲＭプログラムのＡＰＩの機能を拡張する方法と、当該方法を実装するためのシステムが開示される。この方法により、ユーザは、ＣＲＭウェブサービスモジュールと通信するリクエストメッセージとレスポンスメッセージを使用して、過去に定義したクラスを拡張し、単一のＡＰＩインタフェースを介して、新しいビジネスロジックおよびオペレーションを作成することができる。ターゲット基本クラスは、サポートするビジネスオペレーションに基づいて、ビジネスエンティティをカテゴリに分類することによって作成され、ターゲットクラス階層を見直すことによって、どのビジネスエンティティがどのオペレーションをサポートするかが判断される。
【発明を実施するための最良の形態】
【０００５】
以下の文章は、様々な異なる実施形態の詳細な説明を記述するものであるが、本記述の法的適用範囲は、本願に添付の特許請求の範囲の文言によって定義されることが理解されなければならない。なお、可能な全ての実施形態を説明するのは、たとえ不可能でなかったとしても、非現実的であるため、本明細書の詳細な説明は単に例でしかなく、可能な全ての実施形態を説明するものではない。現行の技術、または本願の出願日以降に開発される技術を使用して、その他数多くの形態を実施することが可能であるが、それらも請求項の範囲内に含まれるものとする。
【０００６】
さらに、用語については、「本明細書では、用語『＿＿＿』は、…を意味するものとここで定義する」という文章、またはそれに類する文章によって明示的に定義されている場合を除き、明示的または黙示的を問わず、単純なまたは通常の意味を超えて、当該用語の意味は一切制限されないものとし、当該用語は、本特許のいかなる部分における、いかなる文章によっても（ただし、請求の範囲における言語は除く）、その範囲が制限されるものと解釈されてはならない。本願に添付の特許請求の範囲において引用された用語が、本特許において、単一の意味で一貫して使用される範囲については、読者を混乱させないよう、明確さの目的のためにそうしたものであって、そのような請求の範囲における用語を、黙示的なまたはそれ以外の如何を問わず、その単一の意味に制限することは、意図するところではない。最後に、請求項の要素が、いかなる構造にも言及することなく、「手段」という用語を使用して、または機能として定義されている場合、いかなる請求項の要素の範囲も、米国特許法第１１２条第６項の適用を受けて解釈されることを意図するものではない。
【０００７】
図１は、請求の範囲に記載の方法のステップ、および装置のシステムが実装可能な、適切なコンピューティングシステム環境１００の一例を示す図である。コンピューティングシステム環境１００は、単に、適したコンピューティング環境の一例を示すものであって、請求項記載の装置の方法の使用、または機能の範囲の制限を示唆するものでは一切ない。さらに、コンピューティング環境１００は、例示のオペレーティング環境１００に示した如何なる要素、またはその組み合わせに依存する、若しくはそれを要件とするものとして、解釈してはならない。
【０００８】
請求項に記載の方法および装置のステップは、その他の多くの汎用または目的に特化したコンピューティングシステム環境または構成で運用することができる。請求項の方法または装置で使用するのに適した公知のコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、携帯型またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブルコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む、分散型コンピューティング環境等があるが、これに制限されるものではない。
【０００９】
請求項記載の方法および装置のステップは、コンピュータによって実行されるプログラムモジュール等、コンピュータで実行可能な命令の一般的な文脈で記述することができる。一般的に、プログラムモジュールには、特定のタスクを実行したり、または特定の抽象的なデータタイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれる。当該方法および装置は、通信ネットワークを介して接続された、遠隔の処理装置によってタスクを実装する、分散型コンピューティング環境でも実施することができる。分散型コンピューティング環境では、プログラムモジュールは、メモリストレージ装置を含む、ローカルおよびリモートコンピュータストレージ媒体のいずれにも配置することができる。
【００１０】
図１を参照すると、請求の範囲に記載の方法および装置を実装する例示的なシステムは、コンピュータ１１０としての汎用コンピューティング装置を含む。コンピュータ１１０の構成要素には、処理部１２０、システムメモリ１３０、システムメモリと処理部１２０の接続を含む、様々なシステム部品を結合するシステムバス１２１等があるが、これに制限されるものではない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、様々なバスアーキテクチャを使用したローカルバス等、様々なバス構造の、いずれであっても構わない。そのようなアーキテクチャには、例えば、Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ  ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとしても知られるＰｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バス等があるが、これに制限されるものではない。
【００１１】
コンピュータ１１０には、通常、様々なコンピュータで読み取り可能な媒体が設けられる。当該コンピュータで読み取り可能な媒体は、コンピュータ１１０でアクセス可能であれば、利用可能な媒体のうち、どのようなものであってもよく、揮発性および不揮発性の媒体、着脱可能または固定の媒体の両方を含むものとする。コンピュータで読み取り可能な媒体には、コンピュータストレージ媒体および通信媒体があるが、これに制限されるものではない。コンピュータストレージ媒体は、コンピュータで読み取り可能な命令、データ構造、プログラムモジュールまたは他のデータ等の情報を格納するための方法および技術により実装される、揮発性および不揮発性、ならびに着脱可能または固定の媒体両方を含むものとする。コンピュータストレージ媒体には、例えば、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又はその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージ装置、若しくは所望の情報を格納するのに使用可能であってコンピュータ１１０によりアクセス可能な、その他の媒体等を含むが、これに制限されるものではない。通信媒体は、通常、キャリア波などの、変調されたデータ信号またはその他の伝送機構により、コンピュータで読み取り可能な命令、データ構造、プログラムモジュールまたは他のデータを具体化するものであり、情報送達媒体を含むものとする。「変調されたデータ信号」とは、信号に情報を符号化するために、１つまたは複数の特性を設定または変更した信号をいう。通信媒体には、例えば、有線ネットワークまたは直接配線接続、および音波、無線周波数などの無線媒体およびその他の無線媒体等があるが、これに制限されるものではない。なお、コンピュータ読み取り可能媒体の範囲には、上記を組み合わせたものも含まれるものとする。
【００１２】
システムメモリ１３０は、リードオンリーメモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２等、揮発性および／または不揮発性のメモリとしてのコンピュータストレージ媒体が含まれる。基本入出力システム１３３（ＢＩＯＳ）は、例えば、起動時等に、コンピュータ１１０内の要素間での情報伝送を支援する、基本的なルーチンを含むものとし、通常、ＲＯＭ１３１に格納される。ＲＡＭ１３２には、通常、処理部１２０が即座にアクセス可能な、および／または現在操作しているデータおよび／またはプログラムモジュールを維持する。図１では、例として、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７が示されているが、これに制限されるものではない。
【００１３】
コンピュータ１１０には、他の着脱可能／固定の、揮発性／不揮発性コンピュータストレージ媒体を設けても良い。図１では、例として、固定の不揮発性磁気媒体からの読み出しと書き込みを行うハードディスクドライブ１４０、着脱可能な不揮発性の磁気ディスク１５２からの読み出しと書き込みを行う磁気媒体磁気ディスクドライブ１５１、ならびにＣＤ  ＲＯＭや、その他の光学媒体等の、着脱可能な不揮発性の光学ディスク１５６からの読み出しや書き込みを行う光学ディスクドライブ１５５が示されているが、これに制限されるものではない。この例示的な運用環境で利用可能な、他の着脱可能／固定、揮発性／不揮発性のコンピュータストレージ媒体には、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ等があるが、これらに制限されるものではない。ハードディスクドライブ１４１は、通常、インタフェース１４０等、固定のメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光学ディスクドライブ１５５は、通常、インタフェース１５０等、着脱可能なメモリインタフェースによってシステムバス１２１に接続される。
【００１４】
以上に説明し、図１に示したドライブおよびドライブに関連付けられたコンピュータストレージ媒体は、コンピュータ１１０のためのコンピュータ読み取り可能な命令、データ構造、プログラムモジュール及び他のデータのストレージを提供する。例えば、図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納することが示されている。なお、これらの要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても、または異なってもよい。ここでは、少なくとも、これらは別々のコピーであることを示すために、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、異なった参照符号が付与されている。ユーザは、キーボード１６２、および一般的にマウス、トラックボール、またはタッチパッド等と呼ばれるポインティングデバイス１６１などの入力装置を介して、コンピュータ２０に命令や情報を入力することができる。（図示されていない）他の入力装置には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送アンテナ、スキャナなどが含まれる。これらおよびその他の入力装置は、多くの場合、ユーザ入力インタフェース１６０を介して処理部１２０に接続され、ユーザ入力インタフェース１６０がシステムバスに接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）等、その他のインタフェースおよびバス構造によって接続する構成も可能である。さらに、モニタ１９１またはその他の表示装置が、ビデオインタフェース１９０等のインタフェースを介して、システムバス１２１に接続される。モニタに加え、コンピュータには、スピーカ１９７およびプリンタ１９６等の他の周辺出力装置を、出力周辺インタフェース１９５を介して接続することによって設けてもよい。
【００１５】
コンピュータ１１０は、リモートコンピュータ１８０等、１つまたは複数のリモートコンピュータに対する論理接続を使用した、ネットワーク化された環境で動作させることができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、またはその他の一般的なネットワークノード等である。なお、図１では、メモリストレージ装置１８１しか図示されていないが、通常、リモートコンピュータ１８０は、コンピュータ１１０に関して上述した要素のうち多くまたは全てを含んでいる。図１に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１やワイドエリアネットワーク（ＷＡＮ）１７３等があるが、他のネットワークを含んでもよい。そのようなネットワーキング環境は、事務所、全社的コンピュータネットワーク、イントラネットおよびインターネット等、広く使用されている。
【００１６】
ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介して、ＬＡＮ１７１に接続する。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０には、通常、インターネット等のＷＡＮ１７３を介して通信を確立するためのモデム１７２、またはその他の手段が設けられる。内蔵型または外付けのモデム１７２は、ユーザ入力インタフェース１６０、またはその他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境において、コンピュータ１１０に関連付けて示されるプログラムモジュール、またはその部分は、リモートメモリストレージ装置に格納することができる。例えば、図１では、リモートアプリケーションプログラム１８５は、メモリ装置１８１上にあるものとして示されているが、これに制限されるものではない。なお、図に示したネットワーク接続は、例示の目的で示したものであって、コンピュータ間に通信接続を確立するための他の手段についても、使用可能である。
【００１７】
典型的なビジネスアプリケーションには、数多くのビジネスエンティティが設けられ、これらのエンティティには、ビジネスロジックに基づいて様々なオペレーションを行うことができる。このようなアプリケーションには、アプリケーションプログラミングインタフェース（ＡＰＩ）が設けられており、これらのエンティティへのアクセス、および当該エンティティに関連したビジネスロジックの実行が可能である。ＡＰＩは、開発者が、ハードウエア装置、ネットワーク、オペレーティングシステム、ソフトウエアライブラリ、またはアプリケーションとやり取りをするために使用する、プログラム、コードライブラリ、またはインタフェースの集合等から構成される。ビジネスアプリケーションにおいては、互換性が非常に重要な要件であることから、ＡＰＩの設計にウェブサービス技術を使用することができる。ＡＰＩの消費者はＡＰＩの署名に依存しており、ライフサイクルの間に、ＡＰＩに変更が加えられると、影響が生じる。また、そのようなアプリケーション内に存在するビジネスエンティティの数に比例し、同様の数の静的オペレーション（メソッド）が定義されており、ＡＰＩを通じて利用可能となっている。このモデルは、いくつかの理由により、拡張が困難である。
【００１８】
１．ＡＰＩに何らかの変更を加える場合、その全ての消費者に変更が必要となる。メソッドベースの拡張性は、多用途性と費用対効果においてあまり優れていない。そのようなＡＰＩを拡張するためには、ＡＰＩセットに、新しいメソッドを追加しなければならない。
【００１９】
２．ＡＰＩによってサポートされているタイプシステムに何らかの変更があった場合、ＡＰＩの実装および全ての消費者に変更が必要となる。
【００２０】
３．多くの数のメソッドを管理及び保守するために、複雑さと費用が継続的に発生する。
【００２１】
４．タイプの異なるビジネスエンティティ間でのオペレーションおよびデータの整合性を管理するために、複雑さと費用が継続的に発生する。
【００２２】
５．数多くの異なるアプリケーションバージョンを通じてのＡＰＩの寿命とライフタイムが問題となる。
【００２３】
６．ＡＰＩにおけるメッセージおよび／またはタイプの数が膨大であるため、プログラミングモデルおよび開発作業が、複雑化する場合がある。
【００２４】
７．エンドユーザが、カスタマイズを行ったり、新しいタイプ（例えば、新しいビジネスエンティティ）を導入した場合、システム側のビジネスエンティティとは異なるプログラミングモデルが必要となる。
【００２５】
８．ＡＰＩのエンドユーザが、ＡＰＩの機能を容易に拡張することができない。および
【００２６】
９．ワークフローやビジネスプロセスを、ＡＰＩに容易に統合することができない。
【００２７】
メッセージ指向型のアプローチは、上記の問題全てを解決する、拡張ポイントを形成し、新しいメッセージを介して新しいビジネスロジックを実装するための枠組みとなる。この方法によれば、任意のメッセージを受け入れることが出来、たとえ、それが実装後に定義されたメッセージであったとしても、ＡＰＩ署名またはタイプシステムに変更を加えることなく対応することができる。メッセージ指向アプローチには、以下の利点がある。
【００２８】
１．新しいメッセージを追加することにより、メソッドの署名を変更したり、メソッドの既存消費者に影響を与えることなく、ＡＰＩの変更を実装することができる。
【００２９】
２．既存の消費者を遮断することなくシステムタイプを拡張することができる。
【００３０】
３．開発環境において、利用性を高め、開発作業を改善する方法として、比較的多数のビジネスエンティティおよびビジネスロジックを、よく整理された、ブラウズ可能なメッセージリストとして集中一元化できる。
【００３１】
４．単純なメッセージクラス階層を使用することによって、タイプの異なるビジネスエンティティ間でのオペレーションおよびデータの整合性を管理するのに必要である、継続的な費用や複雑さを大幅に軽減することができる。
【００３２】
５．メッセージとして拡張性ポイントを単一化したことから、ＡＰＩの寿命とライフタイムが改善される。
【００３３】
６．エンドユーザによる、カスタマイズや、新しいタイプ（例えば、新しいビジネスエンティティ）の導入は、メッセージクラス階層に適合させ、システム側のビジネスエンティティと比較して同一のプログラミングモデルで消費することができる。
【００３４】
７．新しいメッセージを定義することにより、ＡＰＩとその機能を、簡単に拡張することができる。
【００３５】
８．ワークフロー手順やプロセスの記述を含むメッセージ群を新しく定義することにより、ワークフローおよびビジネスプロセスを、ＡＰＩに容易に統合することができる。
【００３６】
メッセージ指向型ＡＰＩにおいては、ビジネスアプリケーションユーザは、メッセージを介して、ビジネスロジックを実行し、ビジネスオペレーションおよびデータにアクセスすることができる。図２は、例えば、カスタマーリレーションシップマネジメント（「ＣＲＭ」）システムにおける、そのようなシステムの設計を示したものである。ＣＲＭは、取引関係および顧客満足に関し、クライアント、顧客およびサービスエージェントとのコネクションを整理および維持する能力を維持する方法として使用することができ、ＣＲＭアプリケーションは、営業担当者が、顧客のためによりよいサービスを提供し、顧客との関係を全体的に改善させることを支援するために、顧客情報のプロファイリングを行い、追跡を行うプログラムである、カスタマーリレーションマネジメントアプリケーションの頭字語でもある。
【００３７】
アプリケーションユーザが使用するインタフェースとして、ＣＲＭウェブサービス２００を使用することができる。このインタフェースは、カスタマイズ後にＣＲＭに追加された新しいメッセージ（拡張）、および初期状態からシステム内に含まれていたオリジナルのメッセージを、同一のインタフェースを介して提示する。システム側のオリジナルのビジネスエンティティに使用されていたのと同じインタフェースとプログラミングモデルが、カスタマイズのビジネスエンティティにも使用され、プログラミング作業をシームレスに行うことができる。このウェブサービス２００は、Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＳＤＬ）で規定された、よく定義されたウェブサービスの記述を含んでいるが、それ以外の所望の定義言語で定義することもできる。ＷＳＤＬは、ＵＤＤＩを介してウェブサービスプロバイダが提供する、ネットワークサービスを規定するためのＸＭＬベースのコントラクト言語である。ＵＤＤＩとは、Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ，  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎの略語であり、ネットワーク上で利用可能なウェブサービスおよびプログラマブルリソースの位置を特定するために使用する、ウェブサービス消費者のためのＸＭＬまたはＳＯＡＰベースの検索サービスである。ＷＳＤＬは、ウェブサービスから、ウェブサービス消費者に対し、公開メソッド、全てのパラメータのデータタイプ、戻り値、およびバインディングなどを記述することができる。ＳＯＡＰとは、シンプルオブジェクトアクセスプロトコルの略であり、ウェブサービスリクエスト（Ｒｅｑｕｅｓｔ）およびレスポンス（Ｒｅｓｐｏｎｓｅ）メッセージ内の情報を、ネットワークに送出する前に、符号化するのに使用される、ＸＭＬベースの軽量なメッセージングプロトコルである。ＳＯＡＰメッセージは、どのようなオペレーティングシステムまたはプロトコルからも独立させることができ、ＳＭＴＰ、ＭＩＭＥ、およびＨＴＴＰ等、様々なインターネットプロトコルを使用して伝送することができる。ＷＳＤＬは、システムのユーザのためにダイナミックに生成され、ユーザがウェブサービスにアクセスし、それをプログラミングすることを可能にする。
【００３８】
システムは、実行（Ｅｘｅｃｕｔｅ）とよばれる単一のウェブサービスを有する場合がある。例としては、次のようになる。
【００３９】
［ＷｅｂＭｅｔｈｏｄ］  ｐｕｂｌｉｃ  Ｒｅｓｐｏｎｓｅ  Ｅｘｅｃｕｔｅ  （Ｒｅｑｕｅｓｔ  ｒｅｑｕｅｓｔ）
【００４０】
この同じメソッドとインタフェースを使用して、システム内のさまざまなビジネスエンティティ、およびビジネスオペレーションならびにデータを扱うことができる。実行（Ｅｘｅｃｕｔｅ）メソッドは、リクエストメッセージ２１０を受け取り、レスポンスメッセージ２２０を返すことができる。リクエストメッセージは、ＣＲＭウェブサービス２３０のクライアントによって、インスタンス化および構築化させることが可能である。呼び出し側（Ｃａｌｌｅｒ）が実行（Ｅｘｅｃｕｔｅ）メソッドをウェブサービス２３０上に呼び出すことによって、メッセージをＣＲＭプラットフォームに送信する。メッセージは、クライアント２４０によって、ＣＲＭウェブサービス２００に送信される前に、ＳＯＡＰパケットに直列化され、ＣＲＭウェブプラットフォームが非直列化することによって、メッセージオブジェクトに戻される。次に、メッセージはサーバ２５０に送信され、そこで処理される。メッセージ処理の結果は、レスポンスメッセージ２２０として、実行（Ｅｘｅｃｕｔｅ）ウェブメソッドの呼び出し側（Ｃａｌｌｅｒ）に返される。呼び出し側（Ｃａｌｌｅｒ）がタイプを扱う際に、よりよい開発環境支援を提供するために、リクエストメッセージおよびレスポンスメッセージ両方の中身を、強力にタイプ化しておくことも可能である。なお、ＳＯＡＰは、集中をなくした分散型環境において、構造化された情報を交換するために利用可能なプロトコルの１つであるが、適切なプロトコルであれば、どのようなものを使用しても構わない。
【００４１】
図３は、実行（Ｅｘｅｃｕｔｅ）メソッドに関連づけて使用される、リクエストメッセージおよびレスポンスメッセージのクラス階層を示す、クラス図である。リクエストメッセージからは、いくつかクラスが派生しており、これらのクラスは、ＣＲＭシステムがサポートする様々なビジネスオペレーションを示している。リクエストから派生した各クラスには、それに対応する、レスポンスから派生したクラスが存在する。例えば、作成リクエスト（ＣｒｅａｔｅＲｅｑｕｅｓｔ）クラスは、リクエストクラスから派生したものであり、レスポンスクラスから派生した作成レスポンス（ＣｒｅａｔｅＲｅｓｐｏｎｓｅ）クラスに対応する。一般的な規則として、典型的なウェブメソッド上のパラメータは、リクエストメッセージ３１０のメンバーにマッピングされ、典型的なウェブメソッド上の戻りパラメータは、レスポンスメッセージ３２０のメンバーにマッピングされる。サポートされる全てのビジネスオペレーションおよびビジネスロジックは、リクエストメッセージ３３０のサブクラスを介して提示され、リクエストおよびレスポンスキーワードの末尾に付加（ｐｏｓｔｆｉｘ）される。メッセージは、全て、オペレーション（Ｏｐｅｒａｔｉｏｎ）名から始まるものとする。ここで、オペレーション（Ｏｐｅｒａｔｉｏｎ）は、ＣＲＭプラットフォームでサポートされているビジネスオペレーションである。これらの２つの命名規則により、開発環境でメッセージを容易にブラウズすることができ、ＡＰＩの利用性を向上させることができる。
【００４２】
図４は、ＣＲＭシステムのアプリケーションプログラミングインタフェースの機能を拡張するのに、メッセージを使用するメソッドを示す。ブロック４０５において、メソッドが、オペレーションを選択する。ここで、オペレーションは、ＣＲＭオペレーションであるものとする。メッセージ指向型の設計では、プロセスを中心としていることから、開発者は、具体的なリクエストメッセージを選択することにより、所望のビジネスオペレーションを選択することにより（アカウントを作成する、アカウントをまとめる、Ｅメールを送信する）、プログラミング作業を開始することができる。
【００４３】
ブロック４０５において、メソッドは、選択したオペレーションに基づき、リクエストメッセージを通信する。通信は、有線または無線チャネルを介して、選択したチャネルに適した通信プロトコルを使用して行うものとする。上記でも説明したが、メソッドは、リクエストメッセージを受け取り、レスポンスメッセージを返すことができる。リクエストメッセージは、ＣＲＭウェブサービスのクライアントによって、インスタンス化および構築される。呼び出し側（Ｃａｌｌｅｒ）は、ウェブサービス２３０上に、実行（Ｅｘｅｃｕｔｅ）メソッドを呼び出すことによって、メッセージをＣＲＭプラットフォームに送信することができる。そのメッセージは、例えば、ＳＯＡＰ等のトランスポートプロトコルによって、ＣＲＭサーバに送信され、そこで処理が行われる。
【００４４】
ブロック４１５において、リクエストメッセージの一部に、ビジネスエンティティのタイプ名を有する場合、そのメッセージは、その特定のビジネスエンティティに対してのみ有効であることをユーザに示し、ユーザは、そのリクエストメッセージを次のようにインスタンス化することができる。すなわち、ブロック４２０において、リクエストメッセージパラメータを入力し、ブロック４２５において、ＣＲＭサーバに対し、処理を行うよう、リクエストメッセージを送信する。
【００４５】
ブロック４３０において、リクエストメッセージ名にビジネスタイプ名が指定されていない、一般的なリクエストメッセージである場合、ユーザは、そのリクエストメッセージをインスタンス化する。ブロック４３５において、ユーザは、ターゲットクラスタイプを参照し、サポートされているターゲットビジネスエンティティを見つけることにより、ターゲット基本クラスをインスタンス化することができる。ブロック４４０で、ユーザは、ターゲットクラスパラメータをリクエストメッセージに入力する。このアプローチによって、ユーザは、設計時に、所定のビジネスエンティティでサポートされているオペレーションだけを、確実に実行することができる。
【００４６】
ブロック４４５において、メソッドが、リクエストメッセージにターゲットクラスを追加し、ブロック４２５において、メソッドが、そのリクエストメッセージを実行する。実行の結果は、実行（Ｅｘｅｃｕｔｅ）ウェブメソッドの呼び出し側（Ｃａｌｌｅｒ）に、レスポンスメッセージとして返されることができる。呼び出し側（Ｃａｌｌｅｒ）がタイプを扱う際に、よりよい開発環境支援を提供するために、リクエストメッセージおよびレスポンスメッセージ両方の内容を、強力にタイプ化しておくことも可能である。無論これは、メソッドを実行するための方法の１つであって、他の方法も可能である。
【００４７】
ブロック４５０において、ユーザは、リクエストメッセージ名またはリクエストメッセージクラスのいずれにも、ビジネスエンティティに関する言及が一切ない場合、リクエストメッセージをインスタンス化することができる。この種のメッセージからは、ビジネスエンティティついては一切知ることができず、ビジネスエンティティに対する言及が必ずしも必要でない一般的なオペレーションを実行するのに使用することができる。ブロック４５５において、メソッドは、リクエストメッセージにパラメータを入力することができる。そして、ブロック４２５において、処理をしてもらうために、リクエストメッセージがＣＲＭサーバに送信される。
【００４８】
ＡＰＩは、新しいメッセージで拡張することができる。全ての新しいメッセージは、基本リクエストメッセージおよび基本レスポンスメッセージから導出されるため、新しいメッセージを追加しても、メソッドの署名を変更する必要がない。例えば、ＣＲＭの１つのバージョンがＥメール送信（ＳｅｎｄＥｍａｉｌ）リクエストを提示することによって、Ｅメールを送信する機能を備えていた場合、後ほど、単純に、ファックス送信（ＳｅｎｄＦａｘ）リクエストと呼ばれる新しいメッセージを追加することにより、電話回線を使用してファックスを送信する新しい機能を追加することができる。いずれのメッセージも、基本リクエストクラスから生成されているため、実行（Ｅｘｅｃｕｔｅ）メソッドに、一切変更を加える必要がない。また、クラス階層が存在していることから、クライアントとサーバ両方で、メッセージの直列化および非直列化を正しく行うことが可能となる。
【００４９】
リクエストメッセージ階層上の多態性とは、各ビジネスエンティティに対して、新しく別途、インタフェースを設ける必要なく、複数のビジネスエンティティタイプに対して、同一のインタフェースを使用すること、という意味にとることも可能である。例えば、同じメッセージと同じ実行（Ｅｘｅｃｕｔｅ）メソッドで、異なるタイプのビジネスエンティティの新しいインスタンスを作成するために、作成（Ｃｒｅａｔｅ）リクエストを使用することができる。これが、メッセージ指向型アプローチの有する利点の１つである。
【００５０】
ビジネスアプリケーションで提供される異なるタイプのビジネスオペレーションに対応するために、システム内で、異なるタイプのメッセージを定義することができる。メッセージの中には、一般的なオペレーションを示し、システム内のほとんどのビジネスエンティティに適用されるメッセージもあれば、特定のビジネスエンティティ群に向けられたメッセージもある。場合によっては、ビジネスアプリケーションのＡＰＩを使用する開発者は、ドキュメンテーションを参照することなく、設計環境において、どのビジネスエンティティがどのビジネスオペレーションでサポートされているか見つけ出す必要がある。開示のシステムにおいては、この問題を、ターゲット（Ｔａｒｇｅｔ）クラスと、ビジネスエンティティカテゴリ（Ｃａｔｅｇｏｒｙ）により解決することができる。ターゲット（Ｔａｒｇｅｔ）クラスは、どのビジネスエンティティに対して、どのメッセージがサポートされているかを開発者が特定できるようにするものである。ビジネスエンティティは、カテゴリ（Ｃａｔｅｇｏｒｙ）でサポートされているビジネスオペレーションに基づいてそれぞれ異なるカテゴリにグループ化され、そして各グループに対して、ターゲット（Ｔａｒｇｅｔ）基本クラスが作成される。
【００５１】
図５は、ターゲット（Ｔａｒｇｅｔ）クラス階層の２つの例を示す図である。ターゲット集約（ＴａｒｇｅｔＭｅｒｇｅ）５１０およびターゲット定量化（ＴａｒｇｅｔＱｕａｎｔｉｆｙ）５２０は、それぞれ、様々なオペレーションをサポートするビジネスエンティティのカテゴリである。当該カテゴリに属する各ビジネスエンティティは、これらのクラスから派生したターゲット（Ｔａｒｇｅｔ）クラスを有する。例えば、ターゲット集約（ＴａｒｇｅｔＭｅｒｇｅ）を例にとると、ターゲット集約案件（ＴａｒｇｅｔＭｅｒｇｅＡｃｃｏｕｎｔ）クラスは、案件（Ａｃｃｏｕｎｔ）ビジネスエンティティが、ターゲット集約（ＴａｒｇｅｔＭｅｒｇｅ）カテゴリのメンバーであることを示す、ターゲット集約（ＴａｒｇｅｔＭｅｒｇｅ）カテゴリから派生したクラスである。このクラス階層により、ＡＰＩのユーザは、プログラムによって、または開発環境のツールを使用して、ターゲット（Ｔａｒｇｅｔ）クラス階層をブラウジングすることができ、ドキュメンテーションを必要とせず、サポートされている構成すべてを見つけることができる。
【００５２】
集約（Ｍｅｒｇｅ）オペレーションを実行するサンプルコードは次の通りである。
【００５３】
／／１）  Ｃｒｅａｔｅ  ａ  Ｍｅｒｇｅ  Ｒｅｑｕｅｓｔ
ＭｅｒｇｅＲｅｑｕｅｓｔ  ｍｙＭｅｒｇｅＲｅｑ  ＝  ｎｅｗ  ＭｅｒｇｅＲｅｑｕｅｓｔ（）；
／／２）  Ｔｈｅ  ｔｙｐｅ  ｏｆ  Ｔａｒｇｅｔ  ｆｉｅｌｄ  ｏｆ  ＭｅｒｇｅＲｅｑｕｅｓｔ  ｉｓ  ＴａｒｇｅｔＭｅｒｇｅ  ｓｏ  ｔｈｅ  ｄｅｒｉｖｅｄ  ｃｌａｓｓｅｓ
／／  ａｒｅ  ｎａｍｅｄ  ａｓ  ＴａｒｇｅｔＭｅｒｇｅ＜Ｂｕｓｉｎｅｓｓ  Ｅｎｔｉｔｙ  Ｎａｍｅ＞．  Ｃｒｅａｔｅ  ａｎ  ｉｎｓｔａｎｃｅ  ｏｆ  ａ  ｃｌａｓｓ  ｄｅｒｉｖｅｄ  ｆｒｏｍ  ＴａｒｇｅｔＭｅｒｇｅ  ｔｈａｔ  ｃｏｒｒｅｓｐｏｎｄｓ  ｔｏ  ａ  ｓｅｌｅｃｔｅｄ  Ｂｕｓｉｎｅｓｓ  Ｅｎｔｉｔｙ．
ＴａｒｇｅｔＭｅｒｇｅＡｃｃｏｕｎｔ  ｍｙＴａｒｇｅｔＦｉｒｓｔＡｃｃｏｕｎｔ  ＝  ｎｅｗ  ＴａｒｇｅｔＭｅｒｇｅＡｃｃｏｕｎｔ（）；
ｍｙＴａｒｇｅｔＦｉｒｓｔＡｃｃｏｕｎｔ．ＥｎｔｉｔｙＩｄ  ＝  ａｃｃｏｕｎｔＩｄ；
／／３）Ｓｅｔ  ｔｈｅ  Ｔａｒｇｅｔ  ｏｎ  ｔｈｅ  Ｒｅｑｕｅｓｔ  ｍｅｓｓａｇｅ
ｍｙＭｅｒｇｅＲｅｑ．Ｔａｒｇｅｔ  ＝  ｍｙＴａｒｇｅｔＦｉｒｓｔＡｃｃｏｕｎｔ；
ｍｙＭｅｒｇｅＲｅｑ．  ＳｕｂｏｒｄｉｎａｔｅＩｄ  ＝  ｓｕｂｏｒｄｉｎａｔｅＩｄ；
ｍｙＭｅｒｇｅＲｅｑ．ＰｅｒｆｏｒｍＰａｒｅｎｔｉｎｇＣｈｅｃｋｓ  ＝  ｔｒｕｅ；
／／４）  Ｅｘｅｃｕｔｅ  ｔｈｅ  Ｍｅｒｇｅ  Ｒｅｑｕｅｓｔ，  ｔｙｐｅ  ｏｆ  Ｒｅｓｐｏｎｓｅ  ｍｅｓｓａｇｅ  ｗｉｌｌ  ｂｅ  ＭｅｒｇｅＲｅｓｐｏｎｓｅ．
ＭｅｒｇｅＲｅｓｐｏｎｓｅ  ｍｙＭｅｒｇｅＲｅｓ  ＝  （ＭｅｒｇｅＲｅｓｐｏｎｓｅ）ｍｙＳｅｒｖｉｃｅ．Ｅｘｅｃｕｔｅ（ｍｙＭｅｒｇｅＲｅｑ）；
【００５４】
プログラミングモデルにカスタマイズを行う場合、シームレスで、プログラミングモデルの残りの部分と一貫性を持たせて、統合化することができる。ユーザは、ＣＲＭシステムによって、システムに新しいビジネスエンティティを追加することができる。ビジネスエンティティを追加すると、ＣＲＭウェブサービスのサービス定義における新しいタイプとメッセージの生成に自動的にトリガがかかり、メッセージ階層を拡張する。これによって、開発者は、オリジナルとカスタマイズ、両方の、強力にタイプ化されたビジネスエンティティクラスと、それらのクラスを受け入れるメッセージによって作業を進め、その上で、ビジネスロジックとオペレーションを実行させることができる。
【００５５】
既に、カスタマイゼーションの一部として追加された新しいビジネスエンティティを生成するコードと、インスタンスの別の例を以下に示す。
【００５６】
／／Ｕｓｅｒ  ｃｏｍｐａｎｙ  ＦＡＢ  ｈａｓ  ｃｒｅａｔｅｄ  ａ  ｃｕｓｔｏｍ  ｂｕｓｉｎｅｓｓ  Ｅｎｔｉｔｙ  ｉｎ  ｔｈｅ  ｓｙｓｔｅｍ  ｎａｍｅｄ  ／／ｆａｂ＿Ｖｅｎｄｏｒ．  Ｔｈｅ  ｕｓｅｒ  ｇｅｔｓ  ｔｈｅ  ｓａｍｅ  ｅｘｐｅｒｉｅｎｃｅ  ａｓ  ｗｏｒｋｉｎｇ  ｗｉｔｈ  ｓｙｓｔｅｍ  ｅｎｔｉｔｉｅｓ
／／Ｂｕｓｉｎｅｓｓ  Ｏｐｅｒａｔｉｏｎ  ｉｓ  Ｕｐｄａｔｅ
ｆａｂ＿ｖｅｎｄｏｒ  ｍｙ  Ｖｅｎｄｏｒ  ＝  ｎｅｗ  ｆａｂ＿ｖｅｎｄｏｒ（）；
Ｋｅｙ  ｍｙＶｅｎｄｏｒＫｅｙ  ＝  ｎｅｗ  Ｋｅｙ（）；
ｍｙＶｅｎｄｏｒＫｅｙ．Ｖａｌｕｅ  ＝  ｎｅｗ  Ｇｕｉｄ（“｛ＥＦ６８７１９０−６Ｆ８５−４４５５−Ｂ２２５−９３ＢＦ８４２４２５ＤＤ｝”）；
ｍｙＶｅｎｄｏｒ．ｆａｂ＿ｄｅｓｃｒｉｐｔｉｏｎ  ＝  “Ａ  ｔｒｕｓｔｅｄ  ｖｅｎｄｏｒ  ｔｈａｔ  ｐｒｏｖｉｄｅｓ  ｓａｆｅｔｙ  ｅｑｕｉｐｍｅｎｔ  ｆｏｒ  Ｂｉｋｅｓ”；
ｍｙＶｅｎｄｏｒ．ｆａｂ＿ｐｒｅｆｅｒｅｎｃｅ  ＝  ｎｅｗ  ＰｉｃｋＬｉｓｔ（）；
ｍｙＶｅｎｄｏｒ．ｆａｂ＿ｐｒｅｆｅｒｅｎｃｅ．Ｖａｌｕｅ  ＝  ２；
ＵｐｄａｔｅＲｅｑｕｅｓｔ  ｍｙＵｐｄａｔｅＲｅｑｕｅｓｔ  ＝  ｎｅｗ  ＵｐｄａｔｅＲｅｑｕｅｓｔ（）；
ＴａｒｇｅｔＵｐｄａｔｅＦａｂ＿Ｖｅｎｄｏｒ  ｍｙＶｅｎｄｏｒＴａｒｇｅｔ  ＝  ｎｅｗ  ＴａｒｇｅｔＵｐｄａｔｅＦａｂ＿Ｖｅｎｄｏｒ（）；
ｍｙＶｅｎｄｏｒＴａｒｇｅｔ．ｆａｂ＿ｖｅｎｄｏｒ  ＝  ｍｙＶｅｎｄｏｒ；
ｍｙＵｐｄａｔｅＲｅｑｕｅｓｔ．Ｔａｒｇｅｔ  ＝  ｍｙＶｅｎｄｏｒＴａｒｇｅｔ；
ＵｐｄａｔｅＲｅｓｐｏｎｓｅ  ｍｙＶｅｎｄｏｒＲｅｓｐｏｎｓｅ  ＝  （ＵｐｄａｔｅＲｅｓｐｏｎｓｅ）ｍｙＳｅｒｖｉｃｅ．Ｅｘｅｃｕｔｅ（ｍｙＵｐｄａｔｅＲｅｑｕｅｓｔ）；
【００５７】
図６は、新しいビジネスエンティティであるダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）６１０と、そのメンバーを示すクラス図である。このクラスは、ビジネスエンティティ（ＢｕｓｉｎｅｓｓＥｎｔｉｔｙ）６２０から派生した、残りのＣＲＭビジネスエンティティと同格とすることができる。ダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）６１０は、ビジネスエンティティ（ＢｕｓｉｎｅｓｓＥｎｔｉｔｙ）６２０から派生した、新しいクラスであって、ＷＳＤＬ言語によるＣＲＭウェブサービス記述の中に完全に定義されていなくても、エンティティインスタンスに対し、プログラミングすることを可能とする。ダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）６１０は、エンティティ属性を示す、強力にタイプ化されたプロパティ（Ｐｒｏｐｅｒｔｙ）６３０の列と、エンティティの論理名を示す、名前（Ｎａｍｅ）６４０を有することができる。ダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）６１０クラスは、プロパティ列を有するクラスとしてＷＳＤＬで定義されるため、ＡＰＩのユーザは、コンパイル時／設計時にエラーを発生させることなく、このクラスのインスタンスを作成し、所望のビジネスエンティティ（システムまたはカスタムのもの、ＷＳＤＬに含まれているもの、いないものも）にその名前を設定し、所望のプロパティ（ＷＳＤＬに含まれているもの、いないもの）を列に追加することができる。実行時にプロパティ列の内容が検査され、エンティティ名が存在しない場合、または列で名前が指定されているプロパティが認識されない場合、実行時の例外を投じることができる。
【００５８】
ダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）を定義するためのコードは、例えば、以下のようになる。
【００５９】
ｐｕｂｌｉｃ  ｃｌａｓｓ  ＤｙｎａｍｉｃＥｎｔｉｔｙ  ：  ＢｕｓｉｎｅｓｓＥｎｔｉｔｙ
｛
Ｐｒｏｐｅｒｔｙ［］  Ｐｒｏｐｅｒｔｉｅｓ；
ｐｕｂｌｉｃ  ｓｔｒｉｎｇ  Ｎａｍｅ
）
【００６０】
ダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）クラス６１０は、強力にタイプ化されたクラスを超越して、ＡＰＩを拡張することができ、ビジネスエンティティを取り扱い、そのビジネスロジックを実行するための一般的かつ拡張性の高い方法となり得る。ユーザは、強力にタイプ化されたビジネスエンティティクラス、ダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）６１０フォーマットを使用することを決定することができる。また、ユーザは、強力にタイプ化されたビジネスエンティティ（ＢｕｓｉｎｅｓｓＥｎｔｉｔｉｅｓ）６２０オブジェクトまたはダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）６１０フォーマットで、ビジネスオペレーションを実行した結果を受け取ることを決定することができる。ダイナミックエンティティ（ＤｙｎａｍｉｃＥｎｔｉｔｙ）６１０の場合、設計時に、ユーザは、特定のビジネスエンティティタイプのウェブサービス定義が完全に記述しておく必要はなく、ダイナミックにコードを開発し、ターゲットのＣＲＭの実装中に、定義された様々なビジネスエンティティを実行時に発見し、設計時／コンパイル時に、定義がなくても、これらのエンティティを取り扱う（オペレーションを実行する）ことができるという利点がある。
【００６１】
以上の文章は、様々な異なる実施形態を、詳細に定めたものであるが、本発明の範囲は、本特許の末尾に定められた請求の範囲の文言によって定義されることが、理解されなければならない。なお、可能な全ての実施形態を説明するのは、たとえ不可能でなかったとしても、非現実的であるため、ここの詳細な説明は、例でしかなく、可能な全ての実施形態を説明するものではない。現行の技術、または本願の出願日以降に開発される技術を使用して、その他、数多くの形態が実施可能であるが、それらも請求項の範囲内に含まれるものとする。
【００６２】
従って、請求項の精神と範囲から逸脱することなく、本明細書で説明および示した技術および構造の様々な変更およびバリエーションが可能である。従って、ここに記述した方法および装置は、説明のためにのみ提示されたものであって、請求の範囲を一切制限するものではない。
【図面の簡単な説明】
【００６３】
【図１】請求項に従い動作することができるコンピューティングシステムを示すブロック図である。
【図２】利用者が、メッセージを介して、ビジネスロジックを実行し、ビジネスオペレーションおよびデータにアクセスすることが可能な、メッセージ指向型ＡＰＩを示す図である。
【図３】メッセージ指向型アプローチの概念を示す図である。
【図４】実行メソッドとともに使用される、リクエストメッセージとレスポンスメッセージのクラス階層を示すクラス図である。
【図５】ＣＲＭシステムにおけるアプリケーションプログラミングインタフェースの機能を拡張するためにメッセージを使用する方法を示す図である。
【図６】２つの例に対するターゲットクラス階層を示す図である。
【図１】
2009500753.tif 000003
【図２】
2009500753.tif 000004
【図３】
2009500753.tif 000005
【図４】
2009500753.tif 000006
【図５】
2009500753.tif 000007
【図６】
2009500753.tif 000008
【国際調査報告】
2009500753.tif 000009