JP2005285105A - 通信メッセージ・インスタンスを生成する方法および装置、および、データ・インスタンスを生成する方法 - Google Patents

Abstract

【課題】アプリケーションによって利用される装置資源を低減し、明示的な符号化を行う必要を低減することにより、ワイヤレス・アプリケーションを開発する際の複雑さを軽減する。
【解決手段】ワイヤレス・アプリケーションを管理するための基本サービス・セットを提供する。ワイヤレス・アプリケーションはコンポーネント・セットとして記述される。アプリケーションのカテゴリのデータ範囲は最小単位のデータ・コンポーネントにより定義される。装置とデバイスとの通信は最小単位のメッセージ・コンポーネントにより定義される。メッセージ・コンポーネントおよびデータ・コンポーネントはＸＭＬのような構造化定義言語によりメタデータで記述される。メッセージ・コンポーネントとデータ・コンポーネントとの関係はメッセージ／データ・マッピングの形態でＸＭＬ定義に埋め込まれる。
【選択図】図１

Description

本発明は、ネットワークによる装置へのサービスの通信に関する。

携帯電話、ワイヤレス通信機能を持つＰＤＡ、パーソナル・コンピュータ、セルフ・サービス・キオスク、および二方向ポケットベルなど、今日使用されている端末装置の数は増加し続けている。これらの装置で動作するソフトウェア・アプリケーションは、それらの実用性を高める。例えば携帯電話は、ある範囲の都市の天候をリトリーブするアプリケーションを含むことができ、あるいはＰＤＡは、ユーザが食料品を買い求めることを可能にするアプリケーションを含むことができる。これらのソフトウェア・アプリケーションは、時宜に適った有用なサービスをユーザに提供するために、ネットワークへの接続を利用する。しかし、一部の装置の限られた資源、および大量のデータを装置に配布する複雑さのため、多種多様な装置用のソフトウェア・アプリケーションを開発することは、依然として困難かつ時間のかかる仕事である。

現在、装置は、インターネット・ベースのブラウザおよび／またはネイティブ・アプリケーションを通して、ウェブ・サービスと通信するように構成される。ブラウザは、多種多様な装置に対しクロス−プラット・フォーム方式で動作するように適応可能であるという利点を有するが、ウェブ・サービスからページ（ＨＴＭＬのスクリーン定義）を要求し、それはスクリーンに含まれるデータの保持を妨げるという不利点を有する。ブラウザのさらなる不利点は、資源集約的になるおそれのあるスクリーンのレンダリングが実行時に行なわれることである。ネイティブ・アプリケーションは装置プラット・フォームの型専用に開発され、よって各実行時環境に対し比較的最適化されたアプリケーション・プログラムを提供するという利点を有する。しかし、ネイティブ・アプリケーションはプラット・フォーム依存性があり、よって同一アプリケーションの複数のバージョンを開発する必要があるだけでなく、サイズも比較的大きく、よって装置のメモリ資源に負担がかかるという不利点を有する。さらに、アプリケーション開発者は、これらのハード・コード化されたネイティブ・アプリケーションを構築するために、Ｊａｖａ（登録商標）およびＣ＋＋のようなプログラミング言語の経験を必要とする。

本発明のシステムおよび方法は、上記した不利点の少なくとも幾つかを回避または緩和するために、コンポーネント・ベースのアプリケーション環境を提供する。

明示的コード化を行なう必要性を低減すると共に、提供されたときにアプリケーションによって利用される装置資源を低減することにより、ワイヤレス・アプリケーションの開発に関わる複雑さを緩和することが望ましい。一連のアプリケーション・コンポーネントとしてのワイヤレス・アプリケーションおよびそれらのインタラクションを管理するために基本的サービス・セットを提供する、インテリジェンス・ワイヤレス装置実行時環境（装置実行時）を持つことにより、開発努力を簡素化し、かつ資源割当を低減することができる。ワイヤレス・アプリケーションはコンポーネント・セットとして記述される。このカテゴリのアプリケーション用のデータ領域は、最小単位のデータ・コンポーネントを使用して定義される。装置とサーバとの間の通信は、最小単位のメッセージ・コンポーネントを使用して定義される。メッセージおよびデータ・コンポーネントは両方とも、ＸＭＬのような構造化定義言語を使用して、メタデータで記述される。メッセージおよびデータ・コンポーネント間の関係は、メッセージ・データ・マッピングの形態でＸＭＬ定義に埋め込まれる。一般的に、出メッセージは基礎を成す幾つかのデータ・コンポーネントから導出され、入メッセージはアプリケーションの現在の状態（またはデータ表現)に影響を及ぼす。したがって、データおよびメッセージ・コンポーネントの表現間のメタデータ定義マッピング関係は好ましいことが明らかである。

本発明の第一の態様の方法は、装置で実行されるアプリケーションとのインタラクションのためにデータ・インスタンスに基づいて通信メッセージ・インスタンスを生成する方法であって、前記アプリケーションは、少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントと、少なくとも一つのメッセージ・フィールド定義を有するメッセージ・コンポーネントと、を含み、コンポーネント定義は構造化定義言語で表現され、 前記方法は、メッセージ・インスタンスに対応するメッセージ・コンポーネントを選択するステップと、前記メッセージ・コンポーネントに存在する少なくとも一つの一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定するマッピングを識別するステップと、一意のマッピング識別子によるマッピングによってマップされたデータ・コンポーネントを選択するステップと、マップされた前記データ・コンポーネントのデータ・フィールド定義に対応するデータ・インスタンス・フィールド値を取得するステップと、マップされた前記データ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記データ・インスタンス・フィールド値を含むように前記メッセージ・インスタンスのメッセージ・フィールド値を生成するステップと、を含む。

本発明の第二の態様の方法は、装置で実行されるアプリケーションに対応するメッセージ・インスタンスに基づいてデータ・インスタンスを生成する方法であって、前記アプリケーションは、少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントと、少なくとも一つのメッセージ・フィールド定義を有するメッセージ・コンポーネントと、を含み、コンポーネント定義は構造化定義言語で表現され、前記方法は、前記メッセージ・インスタンスに対応するメッセージ・コンポーネントを選択するステップと、前記メッセージ・コンポーネントに存在する少なくとも一つの一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定するための該マッピングを識別するステップと、一意のマッピング識別子によるマッピングによってマップされたデータ・コンポーネントを選択するステップと、マップされた前記データ・コンポーネントに対応するメッセージ・インスタンスからメッセージ・インスタンス・フィールド値を取得するステップと、マップされたデータ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記メッセージ・インスタンス・フィールド値を前記データ・インスタンスのデータ・インスタンス・フィールド値に割り当てるステップと、を含む。

本発明の第三の態様の方法は、装置で実行されるアプリケーションとのインタラクションのためにデータ・インスタンスに基づいて通信メッセージ・インスタンスを生成する方法であって、前記アプリケーションは、少なくとも一つのメッセージ・フィールド定義および少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントおよびメッセージ・コンポーネントを含み、コンポーネント定義は構造化定義言語で表現され、前記方法は、前記データ・インスタンスに対応するデータ・コンポーネントを選択するステップと、前記データ・コンポーネントに存在する一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定する該マッピングを識別するステップと、一意のマッピング識別子によるマッピングによってマップされたメッセージ・コンポーネントを選択するステップと、マップされた前記メッセージ・コンポーネントのメッセージ・フィールド定義に対応するデータ・インスタンス・フィールド値を取得するステップと、マップされた前記メッセージ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記データ・インスタンス・フィールド値を含むように前記メッセージ・インスタンスのメッセージ・フィールド値を生成するステップと、を含む。

本発明の第四の態様の方法は、装置で実行されるアプリケーションに対応するメッセージ・インスタンスに基づいてデータ・インスタンスを生成する方法であって、前記アプリケーションは、少なくとも一つのメッセージ・フィールド定義および少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントおよびメッセージ・コンポーネントを含み、前記コンポーネント定義は構造化定義言語で表現され、前記方法は、前記メッセージ・インスタンスに対応するメッセージ・コンポーネントを選択するステップと、前記データ・コンポーネントに存在する一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定するための該マッピングを識別するステップと、一意のマッピング識別子によるマッピングによってマップされたメッセージ・コンポーネントを選択するステップと、マップされた前記メッセージ・コンポーネントのメッセージ・フィールド定義に対応するメッセージ・インスタンスからメッセージ・インスタンス・フィールド値を取得するステップと、マップされた前記メッセージ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記メッセージ・インスタンス・フィールド値をデータ・インスタンスのデータ・フィールド値に割り当てるステップと、を含む。

本発明の第五の態様の装置は、装置で実行されるアプリケーションとのインタラクションのためにデータ・インスタンスに基づいて通信メッセージ・インスタンスを生成する装置であって、前記アプリケーションは、少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントと、少なくとも一つのメッセージ・フィールド定義を有するメッセージ・コンポーネントと、を含み、前記コンポーネント定義は構造化定義言語で表現され、前記装置は、メッセージ・インスタンスに対応するメッセージ・コンポーネントを選択する手段と、前記メッセージ・コンポーネントに存在する少なくとも一つの一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定する該マッピングを識別する手段と、一意のマッピング識別子によるマッピングによってマップされたデータ・コンポーネントを選択する手段と、マップされた前記データ・コンポーネントのデータ・フィールド定義に対応するデータ・インスタンス・フィールド値を取得する手段と、マップされた前記データ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記データ・インスタンス・フィールド値を含むように前記メッセージ・インスタンスのメッセージ・フィールド値を生成する手段と、を含む。

本発明の特長は、単なる例として添付の図面に関連して述べる以下の詳細な説明からさらに明らかになるであろう。

「ネットワーク・システム」
図１を参照すると、ネットワーク・システム１０は、インターネットに限らずそのような結合されたワイド・エリア・ネットワーク（ＷＡＮ）１０４を介して、一つまたはそれ以上の汎用スキーマ定義サービス１０６とインタラクションするための複数の汎用端末装置１００を含む。これらの汎用端末装置１００は、パーソナル・コンピュータ１１６、ワイヤレス装置１０１、ＰＤＡ、セルフ・サービス・キオスク、および類似物のようなものとすることができるが、それらに限らない。サービス１０６によって提供される汎用サービスはウェブ・サービスおよび／または他のサービス、例えばＳＱＬデータベース、ＩＤＬベースのＣＯＲＢＡおよびＲＭＩ／ＩＩＯＰシステム、レガシー・データベース、Ｊ２ＥＥ、ＳＡＰ ＲＦＣ、およびＣＯＭ／ＤＣＯＭコンポーネントとすることができるが、それらに限らない。さらに、システム１０は、ローカル・エリア・ネットワーク（ＬＡＮ）１１４を介してデスクトップ端末１１６をサービス１０６に接続するためのゲートウェイ・サーバ１１２を持つこともできる。さらに、システム１０は、ワイヤレス装置１０１をＷＡＮ１０４に接続するためのワイヤレス・ネットワーク１０２を持つこともできる。ＷＡＮ１０４および図１に示す以外の関連ネットワークを介して、他の装置およびコンピュータ（図示せず）をウェブ・サービス１０６に接続することができることが認識される。簡素化するために、以下では、汎用端末装置１００、ワイヤレス装置１０１、およびパーソナル・コンピュータ１１６を装置１００と呼ぶ。簡素化するために、システム１０の以下の説明では、ウェブ・サービス１０６を選択する。しかし、所望するならば、ウェブ・サービス１０６を他のサービスに置き換えることができることが認識される。さらに、簡素化するために、以下ではシステム１０のネットワーク１０２、１０４、１１２をネットワーク１０４と呼ぶ。

再び図１を参照すると、装置１００は、ウェブ・サービス１０６との通信時に、要求／応答メッセージ１０５をそれぞれ送信および受信する。装置１００は、メッセージ・ヘッダ情報および関連データ内容の形の要求／応答メッセージ１０５を使用し、例えばオン−ライン・マーチャントからの製品の価格提示および入手可能性を要求しかつ受信することによって、ウェブ・サービス１０６のウェブ・クライアントとして動作することができる。ウェブ・サービス１０６は、通信装置１００上のクライアント・アプリケーション・プログラム３０２（図２参照）が、通信装置１００のユーザに実用性を提供するために、ワイヤレス・ネットワーク１０２を介してインタラクションする相手システムの一例である。

適切な要求／応答メッセージ１０５を満足させるために、ウェブ・サービス１０６は、装置１００に提供されたときに関連ビジネス論理（方法）をクライアント・アプリケーション・プログラム３０２（図２参照）にさらすための様々なプロトコル（例えばＨＴＴＰおよびコンポーネントＡＰＩなどがあるが、それらに限らず）を通して、アプリケーション・サーバ１１０と通信することができる。アプリケーション・サーバ１１０がウェブ・サービス１０６ソフトウェアを含むこともできるので、ウェブ・サービス１０６はアプリケーション・サーバ１１０のサブセットとみなすことができる。装置１００のアプリケーション・プログラム３０２は、オブジェクト（または機能）に関する方法を呼び出すのと同様に、アプリケーション・サーバ１１０のビジネス論理を使用することができる。クライアント・アプリケーション・プログラム３０２はアプリケーション・サーバ１１０に関連して、ネットワーク１０４を介してメッセージ１０５を通して、装置１００に直接ダウンロード／アップロードすることができると認識される。さらに、装置１００は、ネットワーク１０４を介して、一つまたはそれ以上のウェブ・サービス１０６および関連アプリケーション・サーバ１１０と通信することができると認識される。

「サーバ環境」
図１を参照すると、ウェブ・サービス１０６は、装置１００上のクライアント・アプリケーション・プログラム３０２（図２参照）によって使用される情報メッセージ１０５を提供する。代替的に、または追加的に、ウェブ・サービス１０６は、装置１００上で実行されるクライアント・アプリケーション・プログラム３０２によって提供される情報メッセージ１０５を受信して使用するか、あるいは装置１００で実行されるクライアント・アプリケーション・プログラム３０２の代わりにタスクを実行することができる。ウェブ・サービス１０６は、ウェブ・サービス・レジストリのＵｎｉｖｅｒｓａｌ Ｄｉｓｃｏｖｅｒｙ Ｄｅｓｃｒｉｐｔｉｏｎ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ（ＵＤＤＩ）に登録されたウェブ・サービス記述言語（ＷＳＤＬ）を使用して表現されたようなインタフェースを実現することのできるソフトウェア・サービスと定義することができ、ネットワーク１０４でＳｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）のような適切なプロトコルを通してさらされることによって、メッセージ１０５を通してクライアント装置１００と通信することができる。実現によっては、ＳＯＡＰは、ＳＯＡＰエレメントに囲まれたよくまとめられたＸＭＬフラグメントを含む、メッセージ１０５のＸＭＬフォーマットを定義する仕様書である。ＳＯＡＰはまた文書スタイル・アプリケーションをサポートし、その場合ＳＯＡＰメッセージ１０５はＸＭＬ文書を取り囲むラッパである。ＳＯＡＰのさらなるオプション部はＨＴＴＰバインディング（つまりヘッダ）を定義する一方、一部のＳＯＡＰ実現はＭＳＭＱ、ＭＱシリーズ、ＳＭＴＰ、またはＴＣＰ／ＩＰトランスポート・プロトコルをサポートする。代替的に、ウェブ・サービス１０６は他の公知の通信プロトコルを使用することができ、メッセージ１０５のフォーマット、およびインタフェースは、上述した以外のウェブ・サービス言語を使用することができる。

「クライアント環境」
図２を参照すると、コンポーネント・アプリケーション３０２はネットワーク１０４を介して伝送され、装置１００の装置インフラストラクチャ２０４のメモリ・モジュール２１０にロードされる。代替的に、コンポーネント・アプリケーション３０２はシリアル接続、ＵＳＢ接続、またはＩＲ、８０２．１１（ｘ）ブルートゥースＴＭ（図示せず）のような短距離ワイヤレス通信システムを介してロードすることができる。装置１００にロードされると、コンポーネント・アプリケーション３０２は装置１００上のコンポーネント・フレームワーク２０６によって実行することができ、それはコンポーネント・アプリケーション３０２をネイティブ・コードに変換することができ、それを装置インフラストラクチャ２０４のプロセッサ２０８で実行することができる。代替的に、コンポーネント・アプリケーション３０２は、装置１００上の別のソフトウェア・モジュールまたはオペレーティング・システムによって解釈することができる。いずれにしても、コンポーネント・アプリケーション３０２は装置１００によって提供される端末実行時環境で動作することができるので、実行時環境は、一般的なアプリケーション３０２の挙動（例えば保持性、メッセージング、スクリーン・ナビゲーションおよび表示）を管理して実行する基本的サービス・セットを提供する、インテリジェンス・ソフトウェア・フレームワークである。

再び図１を参照すると、装置１００によって提供されるクライアント実行時環境は、装置１００をウェブ・サービス１０６のウェブ・クライアントとして動作させるように構成することができる。クライアント実行時環境は、装置１００をネットワーク１０４でいずれかの他の汎用スキーマ定義サービスのクライアントにすることもできる。装置１００のクライアント実行時環境は、装置１００上のクライアント・アプリケーション・プログラム３０２（コンポーネント・アプリケーションの形態を採る−図４および以下の説明を参照）を生成し、ホスト化し、実行することができることが望ましい。さらに、クライアント実行時環境の特定の機能は、言語のサポート、メモリ割当ての調整、ネットワーキング、Ｉ／Ｏ動作中のデータの管理、装置１００の出力装置上のグラフィックスの調整、ならびにコア・オブジェクト指向クラスおよびサポート・ファイル／ライブラリへのアクセスの提供などを含むことができるが、それらに限らない。装置１００によって実現される実行時環境の例は、マイクロソフトによるＣｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ（ＣＬＲ）およびサン・マイクロシステムズによるＪａｖａ（登録商標） Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ（ＪＲＥ）を含むことができるが、それらに限らない。

装置１００の端末実行時環境は、クライアント・アプリケーション・プログラム３０２の常駐実行可能バージョンのために、以下の基本的機能をサポートすることが好ましい（図２参照）。

例えば、
●メッセージ１０５をウェブ・サービス１０６に送信するか、またはネットワーク１０４を介して接続されたいずれかの他の汎用スキーマ定義サービスへのメッセージ１０５を装置１００に送信するために通信機能を提供すること、
●ウェブ・サービス１０６の出メッセージ１０５（サービスへのメッセージ）用のデータ部を供給するために装置１００の入力装置でユーザがデータを入力する機能を提供すること、
●ウェブ・サービス１０６の応答メッセージ１０５（入メッセージ）または出力装置に関する無相関通知のためのデータ表示または出力機能を提供すること、
●ローカル・クライアント・データを装置１００のメモリ・モジュール２１０（図２参照）に維持するためにデータ・ストレージ・サービスを提供すること、
●クライアント・アプリケーション・プログラム３０２のアプリケーション・コンポーネント４００、４０２、４０４、４０６（図４参照）の動作を調整するためのスクリプト言語のための実行時環境を提供すること、
などがあるが、それらに限らない。

図２、４、および５を参照すると、クライアント実行時（例えばコンポーネント・フレームワーク２０６によって提供される）は、コンポーネント４００、４０２、４０４、４０６の定義に含まれるメタデータをロードし、次いで、例えばアプリケーション・コンテナ３００を介して、装置１００上のアプリケーション・プログラム３０２の実行可能バージョンを作成する。クライアント実行時用に、テンプレート−ベースのネイティブ実行およびメタデータ−ベースの実行の二つのオペレーショナル・モデルなどがあるが、それらに限らない。テンプレート−ベースのネイティブ実行モデルでは、実行時ホスト・データ、メッセージ、およびスクリーン・テンプレート５００が、ネイティブ・コードを使用して装置１００に事前作成される。アプリケーション・プログラム３０２の定義がロードされると、コンポーネント・フレームワーク２０６によって提供されるクライアント環境は、テンプレート５００にコンポーネント４００、４０２、４０４からのメタデータ定義パラメータを充填し、ネイティブ・フォーマットの実行可能なクライアント・アプリケーション・プログラム３０２を作成する。ワークフロー・コンポーネント４０６のワークフロー・スクリプト（例えばＥＣＭＡＳｃｒｉｐｔ）はネイティブ・コードに変換されるか、あるいは適切なスクリプト・インタプリタ５０２（例えばＥＣＭＡＳｃｒｉｐｔ Ｉｎｔｅｒｐｒｅｔｅｒ）を使用してネイティブ・コード・リダイレクタ５０４に対して実行されることができる。リダイレクタ５０４は、ネイティブ実行時エンジン５０６を通して、スクリプト言語の呼出しをネイティブ・コンポーネントに対する動作に翻訳する。メタデータ−ベースの実行では、コンポーネント・フレームワーク２０６の実行時環境は、（例えば）ＸＭＬのコンポーネント４００、４０２、４０４、４０６の定義を維持し、それが実行時に構文解釈されるか、あるいは（例えば）ＸＭＬノードのネイティブ表現を使用するかのいずれかである。実行中に、ネイティブ実行時エンジン５０６は、ネイティブ・コンポーネント・エンティティに対してではなく、コンポーネント４００、４０２、４０４、４０６の定義に対して動作する。

したがって、ネイティブ・クライアント実行時環境は、クライアント・アプリケーション・プログラム３０２のために、装置１００のプロセッサ２０８の機能および装置インフラストラクチャ２０４の関連オペレーティング・システムへのインタフェースを提供する。実行時環境は、コンポーネント・アプリケーション・プログラム３０２が実行される装置１００の制御された確実かつ安定な環境を供給することが好ましい。実行時環境は、装置１００のそれぞれの各装置インフラストラクチャ２０４に特定的な実際のウェブ・クライアントを生成するために、コンポーネント４００、４０２、４０４、４０６の定義を提供する。簡素化するために、以下の記述では、単なる一例としてコンポーネント・フレームワーク２０６によって提供されるクライアント実行時環境について言及することを認識されたい。

「通信装置」
再び図２を参照すると、装置１００は、携帯電話、ＰＤＡ、二方向ポケットベル、またはデュアル−モード通信装置のような装置であるが、それらに限らない。装置１００は、接続２１８を介して装置インフラストラクチャ２０４に結合される、ワイヤレス・トランシーバまたはワイヤード・ネットワーク・インタフェース・カードもしくはモデムのような、ネットワーク接続インタフェース２００を含む。接続インタフェース２００は装置１００の動作中に、ワイヤレス・リンク（例えばＲＦ、ＩＲ等）によるワイヤレス・ネットワーク１０２のようなネットワーク１０４に接続され、それはネットワーク１０４を介して装置１００が相互におよび外部システム（ウェブ・サービス１０６のような）と通信し、かつクライアント・アプリケーション・プログラム３０２とサービス１０６（図１参照）との間で要求／応答メッセージ１０５を調整することを可能にする。ネットワーク１０４はネットワークに接続された、装置と外部システムとの間の要求／応答メッセージ１０５でのデータの伝送をサポートする。ネットワーク１０４はまた、装置１００とネットワーク１０４の外部にある装置との間の電話の音声通信をもサポートすることができる。ワイヤレス・ネットワーク１０２は、ＤａｔａＴＡＣ、ＧＰＲＳ、またはＣＤＭＡなどのワイヤレス・データ伝送プロトコルを、それらに限らず、使用することができる。

再び図２を参照すると、装置１００は、ユーザ（図示せず）とインタラクションするために、接続２２２によって装置インフラストラクチャ２０４に結合されたユーザ・インタフェース２０２をも有する。ユーザ・インタフェース２０２は、ＱＷＥＲＴＹキーボード、キーパッド、トラックホイール、スタイラス、マウス、マイクロホンなど、それらに限らず、一つまたはそれ以上のユーザ入力装置、ならびにＬＣＤスクリーン・ディスプレイおよび／またはスピーカのようなユーザ出力装置を含む。スクリーンがタッチ感応である場合には、ディスプレイは、装置インフラストラクチャ２０４によって制御されるユーザ入力装置としても使用することができる。ユーザ・インタフェース２０２は、さらに下述するコンポーネント・フレームワーク２０６のクライアント・アプリケーション・プログラム３０２によって使用されるシステム１０（図１）での要求／応答メッセージ１０５を調整するために、装置１００のユーザによって使用される。

再び図２を参照すると、装置１００の動作は、装置インフラストラクチャ２０４によって可能になる。装置インフラストラクチャ２０４はコンピュータ・プロセッサ２０８および関連メモリ・モジュール２１０を含む。コンピュータ・プロセッサ２０８は、メモリ・モジュール２１０に位置するオペレーティング・システムおよびクライアント・アプリケーション・プログラム３０２によって提供される関連命令を実行することによって、ネットワーク・インタフェース２００、ユーザ・インタフェース２０２、および通信装置１００のコンポーネント・フレームワーク２０６の動作を操作する。さらに、装置インフラストラクチャ２０４は、プロセッサに命令を提供するために、かつ／またはメモリ・モジュール２１０内のクライアント・アプリケーション・プログラム３０２をロード／更新するために、プロセッサ２０８に結合されたコンピュータ可読記憶媒体２１２を含むことができる。コンピュータ可読媒体２１２は、単なる例として磁気ディスク、磁気テープ、ＣＤ／ＤＶＤ ＲＯＭのような光学的可読媒体、およびメモリ・カードのようなハードウェアおよび／またはソフトウェアを含むことができる。各々の場合に、コンピュータ可読媒体２１２は小型ディスク、フロッピー（登録商標）・ディスケット、カセット、ハード・ディスク・ドライブ、固体メモリ・カード、またはメモリ・モジュール２１０に設けられたＲＡＭの形態を採ることができる。上に列記した例のコンピュータ可読媒体２１２は単独でも組み合わせても使用することができることに注目されたい。

「装置のコンポーネント・フレームワーク」
再び図２を参照すると、装置１００のコンポーネント・フレームワーク２０６は、接続２２０によって装置インフラストラクチャ２０４に結合される。装置１００のクライアント実行時環境はコンポーネント・フレームワーク２０６によって提供され、かつメタデータ定義からクライアント・アプリケーション・プログラム３０２（コンポーネント・アプリケーションの形態を採る−下記参照）を生成し、ホスト化し、実行することができることが望ましい。したがって、コンポーネント・フレームワーク２０６は、クライアント・アプリケーション・プログラム３０２のためにネイティブ・クライアント実行時環境を提供し、装置１００のプロセッサ２０８の機能および装置インフラストラクチャ２０４の関連オペレーティング・システムへのインタフェースである。コンポーネント・フレームワーク２０６は、好ましくはコンポーネント・アプリケーション・プログラム３０２が例えばアプリケーション・コンテナ３００で実行される装置１００の制御された確実かつ安定な環境を供給することによって、実行時環境を提供する。アプリケーション・コンテナ３００は、クライアント・アプリケーション・プログラム３０２用のスマート・ホスト・コンテナと呼ぶことができ、（メッセージ１０５の−図１参照）メッセージ・メタデータの解析、およびメモリ・モジュール２１０内のメタデータの表現の更新に関与することができる。

図３を参照すると、コンポーネント・フレームワーク２０６は、端末実行時環境内でクライアント・アプリケーション・プログラム３０２（ウェブ・サービス・クライアント・アプリケーションなど）を実行するために使用することができ、要求／応答メッセージ１０５を介して、ウェブ・サービス１０６および関連アプリケーション・サーバ１１０（図１参照）へのアクセスをサポートすることができる。コンポーネント・アプリケーション・プログラム３０２は、コンポーネント・フレームワーク２０６で実行されるソフトウェア・アプリケーションを含む。コンポーネント・フレームワーク２０６は、コンポーネント・アプリケーション・プログラム３０２が実行されるたびに、アプリケーション・プログラム３０２の各コンポーネント４００、４０２、４０４、４０６（図４参照）用のアプリケーション・コンテナ３００を生成する。アプリケーション・コンテナ３００は、アプリケーション・プログラム３０２のコンポーネント４００、４０２、４０４、４０６をロードし、装置インフラストラクチャ２０４内のプロセッサによって実行されるネイティブ・コードを生成することができる。したがってコンポーネント・フレームワーク２０６は、通信装置１００のそれぞれの各装置インフラストラクチャ２０４に特定的な実際のウェブ・クライアントを生成するために、コンポーネント４００、４０２、４０４、４０６の定義を提供するためのホスト・アプリケーション・コンテナ３００を提供する。アプリケーション・コンテナ３００は、単なる例として上述したテンプレート−ベースのネイティブ実行モデルおよびメタデータ−ベースの実行モデルに従って、コンポーネント・アプリケーション３０２を提供することができる。

再び図３を参照すると、コンポーネント・フレームワーク２０６は、特定のサービスがコンポーネント４００、４０２、４０４、４０６（図４参照）の一部として含まれないかあるいはコンポーネント・アプリケーション・プログラム３０２の一部として別個のコンポーネント（図示せず）として受信されない場合、クライアント・アプリケーション・プログラム３０２にフレームワーク・サービス３０４（汎用サービスの標準セット）を提供することもできる。アプリケーション・プログラム３０２は、必要に応じてフレームワーク・サービス３０４との通信２１６を調整することができるアプリケーション・コンテナ３００との通信２１４を有する。コンポーネント・フレームワーク２０６のフレームワーク・サービス３０４は、装置インフラストラクチャ２０４との接続２２０を介して通信を調整する。したがって、装置インフラストラクチャ２０４、ユーザ・インタフェース２０２、およびネットワーク・インタフェース２００へのアクセスは、コンポーネント・フレームワーク２０６および関連サービス３０４によってクライアント・アプリケーション・プログラム３０２に提供される。装置インフラストラクチャ２０４（図２参照）のオペレーティング・システムの一部分は、アプリケーション・コンテナ３００およびフレームワーク・サービス３０４のいずれかのサービスを表わすことができる。

フレームワーク・サービス３０４は、通信サービス３０６、プレゼンテーション・サービス３０８、パーシステンス・サービス３１０、アクセス・サービス３１２、供給サービス３１４、およびユーティリティ・サービス３１６などを含むことができるが、それらに限らない。通信サービス３０６は、コンポーネント・アプリケーション３０２に代わって（通信サービス３０６により）ウェブ・サービスに関して送信／受信されるメッセージ１０５および関連データのような、コンポーネント・アプリケーション・プログラム３０２と外部システム１０との間の接続を管理する。図８ａ、８ｂ、９ａ、９ｂ、１０ａ、１０ｂに関連してさらに下述するように、通信サービス３０６は一連のマッピング８００（図８ａ参照）を実現するために使用することができる。プレゼンテーション・サービス３０８は、コンポーネント・アプリケーション・プログラム３０２がユーザ・インタフェース２０２（図２参照）の出力装置に出力されるときに、コンポーネント・アプリケーション・プログラム３０２の表現を管理する。パーシステンス・サービス３１０は、コンポーネント・アプリケーション・プログラム３０２が装置インフラストラクチャ２０４のメモリ・モジュール２１０（図２参照）にデータを格納することを可能にする。パーシステンス・サービス３１０は、マッピング８００（図８ａ参照）を介してメッセージ・コンポーネント４０４にリンクされたデータ・コンポーネント４００のデータ・インスタンスの変更／生成を調整するために使用することができると認識される。アクセス・サービス３１２は、コンポーネント・アプリケーション・プログラム３０２に、通信装置１００上に存在する他のソフトウェア・アプリケーションへのアクセスを提供する。供給サービス３１４は、通信装置１００上のソフトウェア・アプリケーションの供給を管理する。アプリケーション供給は、新規および更新コンポーネント・アプリケーション・プログラム３０２を要求および受信し、ネットワーク１０４を介してアクセス可能なサービスにアクセスするようにコンポーネント・アプリケーション・プログラム３０２を構成し、コンポーネント・アプリケーション・プログラム３０２およびサービスの構成を変更し、コンポーネント・アプリケーション・プログラム３０２およびサービスを除去することを含むことができる。ユーティリティ・サービス３１６は、文字列の異なるフォーマットへの変換におけるデータ操作の実行など、様々な一般的タスクを達成するために使用される。

通信装置１００のフレームワーク・サービス３０４はコンポーネント・アプリケーション・プログラム３０２に機能を提供することができ、それは上述したサービスを含むことができることが認識される。さらに、フレームワーク・サービス３０４は、アプリケーション３０２のコンポーネント４００、４０２、４０４、４０６を別個のフレームワーク３０４として提供するのではなく、それらと一体化することができる。いずれにしても、コンポーネント・アプリケーション・プログラム３０２は、一体化および／または別個のフレームワーク・サービス３０４を通して、通信装置１００の機能性にアクセスすることができる。

「コンポーネント・アプリケーション・プログラム例」
図２を参照すると、ウェブ・サービス（例えば）クライアント・アプリケーション・プログラム３０２は、コンポーネント・フレームワーク２０６の端末実行時環境内で実行され、サービス１０６（図１参照）によって提供されるウェブ・サービス・オペレーションへのアクセスをサポートする。ＷＳＤＬおよびＳＯＡＰプロトコル定義は、メッセージ・データ・パターンを黙示することが明らかである。ＷＳＤＬウェブ・サービス定義では、オペレーションはメッセージおよびデータ部の表記を使用して定義され、それらはウェブ・サービス・クライアント・アプリケーション・プログラム３０２を関連データ・セット４００およびメッセージ４０４のコンポーネント（図４参照）として定義するために使用される。

図４を参照すると、コンポーネント・アプリケーション・プログラム３０２のブロック図は、データ・コンポーネント４００、プレゼンテーション・コンポーネント４０２、およびメッセージ・コンポーネント４０４を含み、それらはアプリケーション・コンテナ３００との通信２１４を通してワークフロー・コンポーネント４０６によって調整される。各エレメントが一つまたはそれ以上の値を持つように資源の特定の属性を表わす複数の予め定められたエレメントから成る一連のメタデータとして、コンポーネント４００、４０２、４０４を構築するために構造化定義言語を使用することができる。メタデータ・スキーマの例として、ダブリン・コア（ＤＣ）、アングロ−アメリカン・カタロギング規則（ＡＡＣＲ２）、政府情報ロケータ・サービス（ＧＩＬＳ）、符号化アーカイブ記述（ＥＡＤ）、ＩＭＳグローバル・ラーニング・コンソシアム（ＩＭＳ）、およびオーストラリア政府ロケータ・サービス（ＡＧＬＳ）などを含むが、それらに限らない。符号化構文は、コンポーネント４００、４０２、４０４のメタデータを装置インフラストラクチャ２０４（図２参照）によって処理することを可能にし、符号化スキームはＸＭＬ、ＨＴＭＬ、ＸＨＴＭＬ、ＸＳＭＬ、ＲＤＦ、機械可読カタロギング（ＭＡＲＣ）、および多目的インターネット・メール・エクステンション（ＭＩＭＥ）などを含むが、それらに限らない。

再び図４を参照すると、データ・コンポーネント４００は、例えばネイティブ・コードまたはＸＭＬで表現されるアプリケーション・データを含め、コンポーネント・アプリケーション・プログラム３０２によって使用されるデータ・エンティティを定義する。データ・コンポーネント４００が記述することのできるデータ・エンティティの例として注文、ユーザ、および財務トランザクションがある。データ・コンポーネント４００はデータ・エンティティを記述するためにどの情報が必要か、および該情報をどのフォーマットで表現するかを定義する。例えば、データ・コンポーネント４００は、数字としてフォーマットされる注文の一意の識別子から構成される注文、文字列としてフォーマットされる品目のリスト、日付−時刻フォーマットを有する注文が作成された時間、文字列としてフォーマットされる注文の状態、データ・コンポーネント４００の別の一つの定義に従ってフォーマットされる注文を出したユーザなどを定義することができるが、それらに限らない。データ部（エレメント）は通常ウェブ・サービス１０６の振付規則に従ってメッセージ１５０からメッセージ１０５に転送されるので、データ・コンポーネント４００の保持性があることが好ましい。データ・コンポーネント４００はウェブ・サービス１０６の振付定義（利用可能ならば）に従って動的に生成するか、あるいは複合型定義および／またはメッセージ相関情報に基づいてアプリケーション設計者によって定義することができる。さらに下述するように、メッセージ・コンポーネント４０４はマッピング８００を介してデータ・コンポーネント４００（図８ａ参照）にリンクすることができる。

再び図４を参照すると、メッセージ・コンポーネント４０４は、ウェブ・サービス１０６のような外部システムと通信するためにコンポーネント・アプリケーション・プログラム３０２によって使用されるメッセージのフォーマットを定義し、かつ、例えば、ネイティブ・コードまたはＸＭＬで表現されるメッセージ・データを含む。例えば、メッセージ・コンポーネント４０４の一つは、注文の一意の識別子、注文の状態、および注文に関連する注意を含む、注文を出すためのメッセージなどを記述することができるが、それに限らない。構造化定義言語で書かれたメッセージ・コンポーネント４０４の定義は、ＷＳＤＬメッセージを一意に表現する（かつそれにマップする）ことができ、かつ実行時に動的に生成することができる。したがって、ウェブ・サービス・インタフェースを表現するために使用される、例えばＷＳＤＬおよびＢＰＥＬに限らずそのような定義言語の標準ウェブ・サービス・メタデータから、クライアント・アプリケーション・メッセージ１０５および関連データ内容のためのコンポーネント定義の動的生成を行なうことができる。ウェブ・サービス・メッセージ１０５はオペレーションのコンテクスト内で定義され、コンポーネント・アプリケーション・プログラム３０２の定義のメッセージ・コンポーネント４０４間に定義された相関関係がある。この相関は、予め定められたパラメータを使用して、かつ／またはさらに下述するように別個のワークフロー・コンポーネント４０６を通して行なうことができる。

再び図４を参照すると、プレゼンテーション・コンポーネント４０２は、ユーザ・インタフェース２０２によって表示されるときのコンポーネント・アプリケーション・プログラム３０２の外観および挙動を定義する。プレゼンテーション・コンポーネント４０２はＧＵＩスクリーンおよび制御、ならびにユーザがユーザ・インタフェース２０２を使用してコンポーネント・アプリケーション３０２とインタラクションするときに実行される動作を指定することができる。例えばプレゼンテーション・コンポーネント４０２はスクリーン、ラベル、編集ボックス、ボタン、およびメニュー、ならびにユーザが編集ボックスに打ち込んだときまたはボタンを押したときに行なわれる動作を定義することができる。大部分のウェブ・サービス消費者はウェブ・サービス・オペレーション結果の視覚的表現を使用し、したがってユーザ・インタフェース・スクリーンを表示することのできる彼らの装置１００に実行時環境を提供する。

再び図４を参照すると、コンポーネント・アプリケーション・プログラム３０２のワークフロー・コンポーネント４０６は、上述したようにプレゼンテーション・コンポーネント４０２によって指定された動作、またはシステム１０からメッセージ１０５（図１参照）が到着したときに実行される動作などの動作を実行するときに発生する処理を定義する。プレゼンテーション・ワークフローおよびメッセージ１０５の処理は、ワークフロー・コンポーネント４０６によって定義される。ワークフロー・コンポーネント４０６は、プログラミング言語またはＥＣＭＡＳｃｒｉｐｔに限らずそのようなスクリプト言語の一連の命令として書かれ、かつ上述したように、アプリケーション・コンテナ３００によってネイティブ・コードにコンパイルされ実行される。ワークフロー・コンポーネント４０６の一例として、データに値を割り当てること、スクリーンを操作すること、あるいはメッセージ１０５を送信することが挙げられる。ワークフロー・コンポーネント４０６はメッセージ１０５間の相関関係をサポートし、他のコンポーネント４００、４０２、４０４に対するオペレーションの規則セットとしてアプリケーション・フローを定義する。所定のアプリケーション・プログラム３０２に関し、多数のワークフロー・コンポーネントを定義することができる。

ＥＣＭＡ（欧州コンピュータ製造工業会）スクリプトは標準スクリプト言語であり、スクリプトは、コンピュータ・プロセッサによってではなく、別のプログラムによって翻訳されるか実行される一連の命令と呼ぶことができる。スクリプト言語の幾つかの他の例としてＰｅｒｌ、Ｒｅｘｘ、ＶＢＳｃｒｉｐｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、およびＴｃｌ／Ｔｋがある。スクリプト言語は一般的に、装置１００のような既存のシステムの機能を操作し、カスタマイズし、自動化するために使用される命令言語である。そのようなシステムでは、有用な機能性はユーザ・インタフェース２０２（図２参照）を通してすでに利用可能であり、スクリプト言語はその機能性をプログラム制御にさらすための機構である。このようにして装置１００は、スクリプト言語の機能を達成する、オブジェクトおよび機能のホスト実行時環境を提供すると言われている。

したがって、図４を参照すると、クライアント・アプリケーション・プログラム３０２は、ＸＭＬ（または他の適切な構造化定義言語）を使用してプラット・フォーム・ニュートラルなコンポーネント定義セットとして、すなわちデータ４００およびメッセージ４０４コンポーネントならびにプレゼンテーション・コンポーネント４０２に対して定義することができる。ワークフロー・コンポーネント４０６は、ＥＣＭＡＳｃｒｉｐｔ（またはいずれかの他の適切なプラット・フォーム・ニュートラルなスクリプト言語）を使用して定義することができる。コンポーネント・フレームワーク２０６（図２参照）のクライアント実行時環境は、コンポーネント・アプリケーション・プログラム３０２のコンポーネント４００、４０２、４０４、４０６が装置１００に供給されたときに、さらに下述するように、メタ定義に基づいてコンポーネント・テンプレートを生成することができる。多種多様な端末実行時環境により、ＸＭLまたはＥＣＭＡＳｃｒｉｐｔのようなクロス−プラット・フォーム標準を使用して、コンポーネント・アプリケーション・プログラム３０２を事前に作成するのではなく、アプリケーション・コンポーネント・メタデータを定義することができる。この遅延バインディングにより、種々の異なる装置１００によって表わされる多種多様な端末システム環境で、コンポーネント・アプリケーション・プログラム３０２の汎用アプリケーション定義を実行することが可能になる。

ＸＭＬまたはその派生語を使用してデータ４００、メッセージ４０４、およびプレゼンテーション４０２のコンポーネントを表現し、かつＥＣＭＡＳＣｒｉｐｔ言語またはそのサブセットを使用してワークフロー・コンポーネント４０６を表現することにより、アプリケーション開発者は特定のプラット・フォームまたは環境からウェブ・サービス・クライアントを抽出し、主要な「一度作成すればどこででも動く」アプリケーションを実現することが可能になる。以下の例は、ＸＭＬのような構造化定義言語（これに限定されるものではない）およびＥＣＭＡＳｃｒｉｐｔのようなプラット・フォーム・ニュートラルな言語（これに限定されるものではない）で定義されたコンポーネントを使用して、ウェブ・サービス・クライアント・アプリケーション・プログラム３０２をいかに表現することができるかを示す。

ＸＭＬデータ・コンポーネント４００の例

ＸＭＬメッセージ・コンポーネント４０４の例

ＸＭＬプレゼンテーション・コンポーネント４０２の例

ＥＣＭＡＳｃｒｉｐｔワークフロー・コンポーネント４０６の例

図４を参照すると、上述の通り、メッセージ・コンポーネント４０４は、メッセージ１０５の入力および出力のために必要なデータを中継することが分かる。対応するデータ・コンポーネント４００は、プレゼンテーション・コンポーネント４０２によるユーザ・インタフェース２０２（図２参照）でのその後のプレゼンテーションのために、装置１００のメモリ・モジュール２１０（図２参照）内のデータの格納を調整する。ワークフロー・コンポーネント４０６は、データ４００、プレゼンテーション４０２、およびメッセージ４０４コンポーネント間のデータの転送を調整する。

さらに、コンポーネント・アプリケーション・アーキテクチャは、ハード・コード化ネイティブ・アプリケーションおよび有効データ・ストレージおよびパーシステンス・モデルに比較して、相対的に小さいアプリケーション・ダウンロード・サイズ（コンポーネント定義のみから構成される）を提供することができる。クライアント実行時環境は、最小単位のデータ・エンティティを格納しかつ構成することができ、ブラウザ・アプリケーションのためのＨＴＭＬページのようなレンダリングされたプレゼンテーションを操作することに対して、最小単位のデータ・エンティティを直接格納し更新することができる。

「コンポーネント・アプリケーション・モデルのオペレーション例」
例えば図１、３および６を参照すると、オペレーション６００は、装置１００がメッセージ・データを含む応答メッセージ１０５を受信するときに（６０２）、適切なワークフロー・コンポーネント４０６が適切なメッセージ・コンポーネント４０４に従ってメッセージ１０５のデータ内容を翻訳する（６０４）ことを示す。ワークフロー・コンポーネント４０６は次いでデータ内容を処理し（６０６）、メモリ・モジュール２１０（図２参照）へのその後の格納（６１２）のために、対応するデータ・コンポーネント４００にデータを挿入する（６１０）。さらに、必要ならば、ワークフロー・コンポーネント４０６は、ユーザ・インタフェース２０２（図２参照）におけるその後の表示（６１４）のために、データを適切なプレゼンテーション・コンポーネント４０２にも挿入する（６０８）。

図１、３および７を参照すると、オペレーション７００は、ボタンを押しあるいはメニュー項目を選択するなどの動作（ユーザがユーザ・インタフェース２０２（図２参照）を介してユーザ・インタフェース・エレメントに実行する（７０３））のためのデータ入力（７０２）を示す。関連ワークフロー・コンポーネント４０６は、適切なプレゼンテーション・コンポーネント４０２に従って入力データを翻訳し（７０４）、適切なデータ・コンポーネント４００によって定義されるデータ・エンティティを生成する（７０６）。ワークフロー・コンポーネント４０６は次いで、メモリ・モジュール２１０（図２参照）へのその後の格納（７１２）のために、ユーザによって提供された入力データをデータ・コンポーネント４００に投入する（７１０）。さらに、ワークフロー・コンポーネント４０６はまた、メッセージ・コンポーネント４０４によって定義されるように、メッセージ１０５で入力データをデータ・エンティティとしてウェブ・サービスに後で送信する（７１４）ために、適切なメッセージ・コンポーネント４０４に入力データを挿入する（７０８）。

「データおよびメッセージ・コンポーネント間のマッピング」
図４に関連して上述したように、ワイヤレス・アプリケーション３０２は、メッセージ４０４、データ４００、およびコンポーネント４０２、４０６の集合として、これらのコンポーネントがどのようにインタラクションするかを指定する情報を含めて表現される。アプリケーション３０２は、ＸＭＬのような構造化定義言語を使用して表現される。メッセージ４０４およびデータ４００両方のコンポーネントとしての表現は、以下の類似性を共有することが注目される。

◎各コンポーネント４００、４０４は一意の名前によって識別される。
◎各コンポーネント４００、４０４は、名前および宣言型から成る一つまたはそれ以上のサブフィールドを指定する。

実際には、一般的に開発者によるコンポーネント４００、４０４の表現はほとんど同一であるが、アプリケーション３０２のコンポーネント４００、４０４の各々の挙動は区別される。したがって、メッセージ１０５（図１参照）の内容が基礎を成すデータ・エレメントからしばしば生成されることを認識することにより、かつ、これらのコンポーネント４００、４０４の表現の間の類似性に照らして、さらに下述するように、メッセージ・コンポーネント４０４の表現に対するマッピング８００（図８ａ参照）を導入すると便利である。これらのマッピング８００は本質的に、メッセージ・コンポーネント４０４に関してメッセージの定義がどのように得られるか、およびアプリケーション３０２の実行中にメッセージ・コンポーネント４０４が実行時にどのように挙動するかを指定するメッセージ１０５の表現の近道である。マッピング８００は、メッセージ・コンポーネント４０４の定義とデータ・コンポーネント４００の定義との間の定められた関係である。メッセージ・コンポーネント４０４に関連して、マッピング８００を使用することにより、メッセージ・コンポーネント４０４を記述するために必要なメタデータの量を低減することができる。したがって、マッピング８００の使用は、アプリケーション３０２を記述するために必要な「コード」の量に直接的な影響を及ぼすことができる。実行時にコンポーネント４０４がいかに挙動するかに関連して、マッピング８００は、リンクされたデータ・エレメント（データ・コンポーネント４００によって記述される）をメッセージ状態によっていかに解決しかつ影響を及ぼすかを指定する。これに関し、マッピング８００を指定することにより、開発者がアプリケーション３０２に追加的な特定のメッセージ取扱いコードを設ける必要性を低減することができる。

「マッピング解決規約」
再び図１および８ａを参照すると、アプリケーションおよび対応するサービス３０４は、一意の識別子８０２（図８ａ参照）を有するマッピング解決規約またはマッピング規則に依存する。このマッピング規則は、データ・コンポーネント４００に付加されたどのマッピング８００も、マップされたデータ型毎に厳密に一つのキー・フィールド８０４をマップすることを定める。このマッピング規則は、マッピング８００によって影響されるデータ・インスタンスの一意の識別および変更を規定する。マッピング規則は、対応するメッセージ・コンポーネント４０４のメッセージ内容がリンクされるデータ・コンポーネント４００のインスタンスをマッピング８００が分離することを定める。データ・コンポーネント４００インスタンスは、一意の識別子８０２（例えばキー）によって解決される。この識別子８０２の組成は、単純な一次キーまたは二つ以上のフィールドから発生する複合キーなどとすることができるが、それらに限らないことが注目される。データ・コンポーネント４００のデータ定義の単一フィールド８０４（コンポーネント名など）は、この識別子８０２を表わすものとして識別される。マッピング解決規約は、リンクされた各データ・コンポーネント４００のマッピング８００に厳密に一つの一次キー・フィールド８０４が含まれることを規定する。マッピング８００のこの一対一の性質は、さらに下述するように、入メッセージ・データが適用されるデータ・インスタンスの一意の解決をもたらす。特定のデータ・インスタンスは、フィールド名８０８の各々にデータ値が割り当てられた、選択されたデータ・コンポーネント４００として表わされる。メッセージ・インスタンス８０６は、マッピング８００を通して、含まれるメッセージ・フィールドにデータ値が割り当てられる、選択されたメッセージ・コンポーネント４０４として表わされる。

二つの型のマッピング８００、つまりフィールド・レベル・マッピング９０１およびメッセージ・レベル・マッピング８０１について記述する。以下で、メッセージ４０４対データ４００のコンポーネント・マッピング８００がいかに表現され、メッセージ内容がどこに適用されるかを一意に判断するために存在する実行時解決規約を指定することができるかを詳述する。

「メッセージ・レベル・マッピング８０１」
再び図８ａを参照すると、メッセージ・レベル・マッピング８０１は、メッセージ・コンポーネント４０４から指定されたデータ・コンポーネント４００の定義への直接のマッピング８００であるので、メッセージ８０６フィールド・プロパティ（メッセージ・インスタンス）はマップされたデータ・コンポーネントのそれと同一である。メッセージ・レベル・マッピング８０１は、メッセージ・インスタンス８０６がデータ・コンポーネント４００のリンクされたデータ・エレメントからその完全な指定を導出するように定める。リンクされたデータ・コンポーネント４００に記述された全てのフィールドが、フィールド名８０８および型宣言８１０の両方およびフィールド順序を監視して、メッセージ・インスタンス８０６に存在する。例えば、この型のメッセージ・レベル・マッピング８０１は、入または出メッセージ・インスタンス８０６が、データ・コンポーネント４００のデータ・インスタンスによって表わされる情報を厳密に複製する場合に好適であり取得する。図８ｂを参照すると、「Ｏｒｄｅｒ」データ・コンポーネント４００と「ｓｕｂｍｉｔＯｒｄｅｒ」メッセージ・コンポーネント４０４との間のサンプル・メッセージ・レベル・マッピング８０１が示されている。マッピング８０１のマッピング解決規約は、「ＯｒｄｅｒＩｄ」一次キー・フィールド８０２の暗黙のリンク付けによって満たされる。この関係のサンプル構造化定義言語記述（例えばＸＭＬ）を図８ｂに示す。ＸＭＬ表現から、このマッピング８０１を導入することによって、データ・コンポーネント４００の引数８１２のリストがリンクされたメッセージ・コンポーネント４０４内で繰り返されないので、アプリケーション３０２定義（図４参照）のサイズを低減することができることが明らかである。

「フィールド・レベル・マッピング９０１」
フィールド・レベル・マッピング９０１（図９ａ、９ｂ参照）は、メッセージ・コンポーネント４０４の定義の特定のフィールド９０４から指定されたデータ・コンポーネント４００の定義の指定されたフィールド８０８へのマッピング８００を提供する。フィールド・レベル・マッピング９０１は、マッピング８００のより柔軟な構成が要求される場合に生じることができる。この構成では、各フィールド・マッピング９０１が、メッセージ・インスタンス９０６の各選択フィールド９０４とデータ・コンポーネント４００に対応するデータ・インスタンスのフィールド８０８との間のリンケージを指定する。任意の個数のそのようなフィールド・マッピング９０１が存在することができる。フィールド・マッピング９０１は一つのターゲット・データ・コンポーネント４００だけを含むことができ（一対一のリンケージ）、あるいは別個のフィールド・マッピング９０１を通して、複数のデータ・コンポーネント４００をメッセージ・インスタンス９０６にリンクすることができる（一対多数のリンケージ）。マッピング解決規約を満足するために、メッセージ・コンポーネント４０４にリンクされる全てのデータ・コンポーネント４００のためのキー・フィールド８０２が含まれる。

図９ａを参照すると、一対一のマッピング９０１の構成は、単一のデータ・コンポーネント４００へのリンクを含む。一つのフィールド・マッピング９０１は、データ・コンポーネント４００の一次キー８０２を表わすフィールドに対して行なわれ、したがってメッセージ・インスタンス９０６がデータ・コンポーネント４００のデータ・インスタンスとリンクされる。他のマッピング９０１は、コンポーネント４０４の選択されたメッセージ・フィールド９０４と、コンポーネント４００の対応するデータ・フィールド８０８との間で行なわれる。図９ａは、「Ｐａｒｔ」フィールド８０８が「ｐｒｉｃｅＲｅｄｕｃｔｉｏｎ」メッセージ・フィールド９０４にリンクされる、一般的なフィールド・レベル・マッピング９０１の関係を示す。マッピング解決規約は、「Ｐａｒｔ」のキー・フィールド８０２として識別される「ｐａｒｔＮｏ」フィールドに対しリンク９０１を形成することによって満たされる。これらの関係のサンプルＸＭＬ表現を図９ｂに提示する。ここでキー・フィールド・マッピング９０１はボールド体で示されている。メッセージ・インスタンス９０６は二つ以上のメッセージ・フィールド９０４を持つことができ、同じキー８０２のもとで各々がそれぞれのデータ・フィールド８０８にマップされる（つまり、メッセージ・コンポーネント４０４は同じキー８０２を使用してデータ・コンポーネント４００の二つ以上のデータ・フィールド８０８にリンクすることができる）ことが認識される。

「複合マッピング１００１」
図１０ａおよび１０ｂを参照すると、複合マッピング１０００の構成は、二つ以上のデータ・コンポーネント４００へのフィールド・レベル・マッピング９０１から成る。図８ａ、８ｂの一対一のマッピングの場合と同様に、フィールド・マッピング９０１のセットを通してリンクされた全てのデータ・コンポーネント４００に対して、異なる一意の一次キー・フィールド８０２のマッピングが提供される。図１０ｂは、「ｏｒｄｅｒＵｐｄａｔｅ」メッセージ４０４と「Ｏｒｄｅｒ」および「Ｉｎｖｅｎｔｏｒｙ」データ・コンポーネント４００との間の関係のＸＭＬ表現を示す。リンクされた二つのデータ・コンポーネント４００の各々に対し、キー８０２によるそれぞれの主フィールド・マッピング９０１が、つまり「Ｏｒｄｅｒ」４００に対する「ｏｒｄｅｒＩｄ」フィールド・キー８０２および「Ｉｎｖｅｎｔｏｒｙ」４００に対する「ｐａｒｔＮｏ」フィールド・キー８０２が、所定の位置に配置される。これはマッピング解決規約を満足する。これらの一次キー・フィールド・マッピング９０１はボールド体で示されている。

図８ａ、８ｂ、９ａ、９ｂ、１０ａ、１０ｂに示した例に鑑み、他のマッピング８００構成が可能である。そのようなものの例として、さらに下述するように、拡張定義、メッセージ・プロトタイピング、および到着イベント処理などがあるが、それらに限らない。拡張定義とは、追加的非マップ・フィールド９０４を定義することによって、メッセージ８０１またはフィールド・マッピング９０１の構成を拡張するメッセージ・コンポーネント４０４である。この拡張メッセージ・インスタンス９０６は、マッピング８０１、９０１の存在下で、それぞれのデータ・コンポーネント４００にマップされないがメッセージ・コンポーネント定義４０４内のそれ自体の仕様を完全にする、フィールド９０４を追加することによって、その定義を拡張することができる。これらのフィールド９０４は、一つまたはそれ以上のフィールド・マッピング８０１、９０１を有するメッセージ９０６、またはそれぞれのデータ・コンポーネント４００にマップされるメッセージ９０６のいずれかに追加することができる。拡張定義は、マップされるメッセージ９０６の仕様に柔軟性を与える追加的手段を提供することができる。メッセージ・プロトタイピングは、別のメッセージ・コンポーネント４０４の規定された定義を拡張する機能と定義することができる。このメカニズムは、オブジェクト指向承継と同様の効果を有する。つまり、親メッセージ９０６の全ての宣言フィールド９０４が、拡張メッセージ９０６に利用可能になる。マッピング８０１、９０１の関係に関して、拡張メッセージ・マッピング８０１、９０１は、親メッセージ９０６で定められたマッピング仕様を無効にすることができる。メッセージ到着イベント処理の場合、メッセージ受信に対する追加処理コードの関連付けを許可することによって、マッピング・メカニズムをさらに増強することができる。処理コードの本体は、アプリケーションＸＭＬを通してメッセージ・コンポーネント４０４の仕様を通して識別することができる。処理コードは、アプリケーション３０２（例えばワークフロー・コンポーネント４０６）に埋め込まれたスクリプト（ＥＣＭＡＳｃｒｉｐｔなど）とすることができ、あるいはコンポーネント・フレームワーク２０６（図２参照）の装置実行時環境によって提供される標準ネイティブ変換を識別することができる。メッセージ到着イベント処理の取扱いについてはさらに下述する。

「メッセージ生成１１００」
図８ａ、８ｂ、９ａ、９ｂ、１１ａ、１１ｂを参照すると、メッセージ・インスタンス９０６の発生のために、メッセージ対データのマッピング８０１、９０１は、メッセージ・インスタンス９０６が伝える内容のソースおよびフォーマットを定義する。メッセージ・フォーマットはリンクされたデータ・コンポーネント４００から同じように導かれることができ（メッセージ・マッピング８０１）、あるいは複数のデータ・コンポーネント４００関係の集合的効果によって定義することができる（フィールド・レベル・マッピング９０１）。最後に、幾つかのメッセージ・フィールドはそれ自体の宣言を伝えることができる（拡張定義）。いずれかの型のマッピング８０１、９０１を指定する発生メッセージ・インスタンス９０６を生成するために、全ての従属データ・コンポーネント４００インスタンスが生成プロセス１１００の入力に供給される。加えて、フィールド９０４の拡張宣言は、供給されるメッセージ・インスタンス９０６が必要なフィールド値を提供することを暗に示す。

図９ａ、９ｂ、１１ａ、１１ｂを参照すると、メッセージ・インスタンス「Ｍ」（メッセージ・インスタンス８０６、９０６に対応する）の最終的生成１１１４が、メッセージ宣言「Ｍｓ」（メッセージ・コンポーネント４０４に対応する）を使用して行なわれる。ダイレクト・メッセージ・マッピング８０１の場合、マップされたデータ・コンポーネント定義「Ｄｓ」（データ・コンポーネント４００に対応する）が入力データ・インスタンス「ｄ」と共に使用され、最終的メッセージ・インスタンス「Ｍ」が判断される。ステップ１１０２で、メッセージ・コンポーネント「Ｍｓ」が得られ、ステップ１１０４で、コンポーネント「Ｍｓ」を検査してメッセージ・レベル・マッピング８０１が存在するか否かを調べることにより、装置実行時環境（例えば通信サービス３０６−図３参照）によって判断が行なわれる。肯定の場合、マッピング８０１によって定義される通り、メタデータ宣言「Ｄｓ」が得られる（１１０６）。サービス３０６はパーシステンス・サービス３１０からデータ・インスタンス「ｄ」値を入力し（１１０８）、メッセージ・インスタンス「Ｍｓ」のメッセージ・フィールド９０４に書き込む（１１１２）。次いで通信サービス３０６はデータ・コンポーネント「Ｄｓ」を分析して（１１１０）、マッピング８０１によって暗示されるメッセージ・インスタンス「Ｍ」に関連付けるためのデータ・フィールド８０８がまだあるかどうかを調べる。肯定の場合、全てのフィールド８０８がメッセージ・インスタンス「Ｍ」に含まれるまで、ステップ１１０６、１１０８、および１１１２が繰り返される。次いでステップ１１１４でメッセージ・インスタンス「Ｍ」が生成される。

フィールド・マッピング９０１の場合、通信サービス３０６によってメッセージ・フィールド・レベル・マッピング９０１を照会することにより、データ・コンポーネント定義「Ｄｓ_p」および従属データ・フィールド宣言「Ｄｓ．ｆ_n」が抽出される。入力データ・インスタンス「ｄ_i」からの適切なフィールド値８０８（ｄ．ｆ_n）が出力メッセージ・インスタンス「Ｍ」に追加される。ステップ１１０４で否定の場合、ステップ１１１６で、通信サービス３０６はフィールド・マッピング９０１があるかどうかを判断し、無い場合には、上述した通り、メッセージ・インスタンス「Ｍ」の現在の内容がステップ１１１４で生成される。そうでない場合、メッセージ・フィールド９０４の記述が分析され（１１１８）、フィールド・マッピング９０１がある場所（１１２０）で、マップされたデータ・コンポーネント型が得られ（１１２４）、マップされたフィールド型宣言がデータ・コンポーネント「Ｄｓ」から得られ（１１２６）、宣言に対応するデータ・インスタンスのデータ値がパーシステンス・サービス３１０から得られる（１１２８）。次いで値は、データ・コンポーネント「Ｄｓ」のフォーマットを使用して、対応するメッセージ・フィールド９０４に書き込まれる。それ以上マッピング９０１が無ければ、メッセージ・インスタンス「Ｍ」がステップ１１１４で生成される。最後に、拡張定義の場合、フォーマットは「Ｍｓ」から直接採られ（１１２２）、フィールド値が入力メッセージ・インスタンス「Ｍ」を通して入手できると期待される。特に二つ以上の型のマッピングがメッセージ・インスタンス「Ｍ」に提供される場合（つまりメッセージ・コンポーネント「Ｍｓ」に複数のコンポーネント「Ｄｓ」がリンクされる多重マッピング８０１、９０１の場合）には、上述した通り、メッセージおよびフィールド・マッピング８０１、９０１の組合せを提供することができる。

「メッセージ処理１２００」
メッセージ・インスタンス「Ｍ」の到着により（図１１ａ、１１ｂ参照）、マッピング８００は次の二つの効果のうちの一つを持つ。
◎マップされたデータ・コンポーネント・インスタンス「ｄ」でフィールド「ｄ．ｆ_n」を更新させる。
◎さらなるマッピング関係８００によって判断されるように、フィールド「ｄ．ｆ_n」で新しいデータ・コンポーネント・インスタンス「ｄ」を生成させる。

メッセージ・フィールド値「Ｍ．ｆ_n」が適用されるデータ・インスタンス「ｄ」は、メッセージ対データ・マッピング解決規約によって判断される。データ・インスタンス「ｄ」は、データ一次キー・フィールド８０２（図８ａ参照）にマップされたメッセージ・フィールド値「Ｍ．ｆ_n」を採ることによって解決される。使用されるマッピング８００の型に応じて、装置１００またはウェブ・サービス１０６のいずれかにおけるメッセージ「Ｍ」の到着によって影響されるデータ・インスタンス「ｄ」は一つ（メッセージ・マッピング８０１）、または一つ以上（フィールド・マッピング９０１）存在する。データを見つけて更新するために、データ一次キー・フィールドにマップされたメッセージ・フィールド９０４（図９ａ参照）に対応するメッセージ・フィールド値「Ｍ．ｆ_n」は一意ではない。一次キー値８０２を持つマップされた型のデータ・インスタンス「ｄ」がすでに存在している。データ・インスタンス「ｄ」はこの一次キー値８０２によって解決され、このデータ型に対する他の全てのマッピング８００により、このデータ・インスタンス「ｄ」のフィールド「ｄ．ｆ_n」は更新される。フィールド・マッピング９０１が使用される場合、このプロセスによって影響される二つ以上のデータ・インスタンス「ｄ」があるかもしれないことが注目される。新しいデータを生成するために、データ一次キー・フィールドにマップされたメッセージ・フィールドに対応するメッセージ・フィールド値「Ｍ．ｆ_n」は一意である。その結果、関連する一次キー・フィールド値８０２を持つデータの新しいインスタンス「ｄ」が生成される。このデータ型に対するその後のマッピングは全て、新しく生成されたデータ・インスタンス「ｄ」のフィールド「ｄ．ｆ_n」を更新する。「見つけて更新する」ことにより、フィールド・マッピング９０１を使用する場合、二つ以上のデータ・インスタンス「ｄ」が生成されることがある。データ解決および更新プロセスについて、到着メッセージ「Ｍ」の処理および既存の／新しいデータ・インスタンス「ｄ」に対する影響を図１２ａ、１２ｂに示す。拡張定義（非マップ）フィールドはデータ解決および更新プロセスに関係しない。簡素化するために、このフィールド型を検出する場合については、以下では示さない。図１２ａ、１２ｂは、マッピング８００を通してメッセージ・インスタンス「ｍ」に関連付けられたデータ・コンポーネント４００の解決および更新プロセスを示す。

ステップ１２０２で、メッセージ・インスタンス「ｍ」のメタデータ定義がメッセージ・コンポーネント「Ｍｓ」から得られ、ステップ１２０４で、メッセージ・インスタンス「ｍ」はメッセージ・コンポーネント４０４に関連付けられる。ダイレクト・メッセージ・マッピング８０１の場合、ステップ１２０６で、データ・コンポーネント仕様「Ｄｓ」がマッピング情報から得られる（１２０８）。「Ｄｓ」の一次キー・フィールドが判断され（１２１０）、このフィールドに適用される値（ｍ．ｆ_pk）が「ｍ」の対応フィールドから得られる（１２１２）。ステップ１２１４で、インスタンス「ｄ」の既存のバージョンがメモリ２１０（図２参照）で探索される。この値を使用して、「Ｄｓ」のインスタンスを見つける（１２１６）か、あるいは作成する（１２１８）ことができ、これにより「ｄ」が生成される。ステップ１２２０で、データ・コンポーネント「Ｄｓ」のさらなるフィールドが判断される。肯定の場合、対応するフィールドのデータ・コンポーネント定義が分析され（１２２２）、解決された対応フィールドの各々に「ｍ」の残りのフィールド値が適用され（１２２４）、これにより更新／作成されたデータ・インスタンス「ｄ」が生成される（１２２６）。

フィールド・マッピング９０１の場合、ステップ１２２８で、各々のフィールド・マッピング９０１の一次キーが判断される。マッピング情報９０１からデータ・コンポーネント仕様「Ｄｓ」が得られる（１２３０）。解決プロセスは、データ・コンポーネント主フィールド「Ｍｓ．ｆ_pki」にマップされる「Ｍｓ」から全てのフィールド・レベル・マッピング９０１を判断することに依存する。フィールド・マッピング９０１のコンポーネント・データ型は「Ｍｓ．ｆ_pki」から「Ｄｓ_i」として判断することができる。このフィールド（ｍ．ｆ_pki）の入力メッセージ「ｍ」からキー値８０２を使用して（１２３２）、「Ｄｓ_i」のデータ・インスタンスを見つける（１２３６）か、あるいは作成する（１２３４）することができ、これにより「Ｄｓ_i」に対応するデータ・インスタンス「ｄ_i」が生成される。データ・インスタンス「ｄ_i」は、各フィールド「ｄ_i．ｆ_n」を順に選択すること（１２３８）によって一度に一つずつ解決され更新される。マップされたメッセージ・フィールド「Ｍｓ．ｆ_p」が得られ（１２４０）、対応するマップ・フィールド定義「Ｄｓ_i．ｆ_n」が得られる（１２４２）。「Ｄｓ_i」のフィールドにマップ９０１されたＭｓの残りのフィールドは、メッセージ・インスタンス・フィールド「ｍ．ｆ_p」から採られたそれらの値を持ち、「Ｄｓ_i」の対応するフィールド・フォーマット：「Ｄｓ_i．ｆ_n」を使用して「ｄ_i．ｆ_n」に適用される（１２４４）。マップされたすべてのデータ・インスタンスが更新され、これによりステップ１２２６で「ｄ」が生成されるまで、このプロセスは続く。

図１を参照して前述した通り、メッセージ１０５が到着したときに、アプリケーション３０２に追加処理または変換を実行するように、スクリプトまたは他の実行可能なユニット（例えばワークフロー・コンポーネント４０６）（図４参照）を関連させることが望ましいかもしれない。この目的のために、メッセージ・コンポーネント定義４０４は、この型のメッセージ１０５を受信したときに呼び出されるカスタム処理ユニット（フレームワーク２０６の一部）のアドレスを指定することができる。スクリプトの実行に加えて、インテリジェンス装置実行時は、メッセージ１０５および全てのそのフィールド値を処理ユニットの範囲で利用可能にする。さらに、マッピング８００により影響される全てのデータ・インスタンス「ｄ_i」、処理装置の範囲で利用可能になる。

本書の開示を一つまたはそれ以上の例示的システムおよび方法に即して示したが、当業熟練者には多くの変形が明白であり、そのような変形は本願の範囲内である。例えば、提示した例ではＸＭＬおよびＥＣＭＡＳｃｒｉｐｔのサブセットを使用したが、他の言語および改変言語を使用してコンポーネント・アプリケーション３０２を定義してもよい。上記マッピング８００およびオペレーション（１１００、１２００）の代替例として、データ・フィールド８０８（図８ａ参照）の定義はメッセージ・コンポーネント４０４（図４参照）に含めることができる。したがって、メッセージ・インスタンスの生成は、メッセージ・コンポーネント４０４の定義に含まれるデータ・フィールド定義に基づくことになり、データ・コンポーネント４００は、データ・フィールド定義を含む対応するメッセージ・コンポーネント４０４にマップされる。これにより、データ・インスタンスの生成は、マップされたメッセージ・コンポーネント４０４に含まれるデータ・フィールド定義に依存する。

ネットワーク・システムのブロック図である。 図１の装置のブロック図である。 図２の装置のコンポーネント・フレームワークのブロック図である。 図２のコンポーネント・アプリケーション・プログラムのブロック図である。 図１のシステムの例示的アプリケーション・パッケージおよびホスト・モデルのブロック図である。 図４のコンポーネント・アプリケーション・プログラムを実現する方法の一例を示すフローチャートである。 図４のコンポーネント・アプリケーション・プログラムを実現する方法の別の一例を示すフローチャートである。 図４のアプリケーションのメッセージ・レベルのマッピングの例である。 図４のアプリケーションのメッセージ・レベルのマッピングの例である。 図４のアプリケーションのフィールド・レベルのマッピングの例である。 図４のアプリケーションのフィールド・レベルのマッピングの例である。 図４のアプリケーションの複合マッピングの例である。 図４のアプリケーションの複合マッピングの例である。 図８ａ、８ｂ、９ａ、９ｂ、１０ａ、１０ｂのメッセージ・マッピングの効果により出メッセージを生成するアルゴリズムを示すフローチャートである。 図８ａ、８ｂ、９ａ、９ｂ、１０ａ、１０ｂのメッセージ・マッピングの効果により出メッセージを生成するアルゴリズムを示すフローチャートである。 図８ａ、８ｂ、９ａ、９ｂ、１０ａ、１０ｂのメッセージ・マッピングの効果により入メッセージを処理するアルゴリズムを示すフローチャートである。 図８ａ、８ｂ、９ａ、９ｂ、１０ａ、１０ｂのメッセージ・マッピングの効果により入メッセージを処理するアルゴリズムを示すフローチャートである。

符号の説明

１０ ネットワーク・システム
１００ 装置
１０２ ワイヤレス・ネットワーク
１０４ ワイド・エリア・ネットワーク
１０６ ウェブ・サービス
１１０ アプリケーション・サーバ
１１２ ゲートウェイ・サーバ
１１４ ローカル・エリア・ネットワーク

Claims (35)

1. 装置で実行されるアプリケーションとのインタラクションのためにデータ・インスタンスに基づいて通信メッセージ・インスタンスを生成する方法であって、
   前記アプリケーションは、
   少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントと、
   少なくとも一つのメッセージ・フィールド定義を有するメッセージ・コンポーネントと、
   を含み、
   コンポーネント定義は構造化定義言語で表現され、
   前記方法は、
   メッセージ・インスタンスに対応するメッセージ・コンポーネントを選択するステップと、
   前記メッセージ・コンポーネントに存在する少なくとも一つの一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定するマッピングを識別するステップと、
   一意のマッピング識別子によるマッピングによってマップされたデータ・コンポーネントを選択するステップと、
   マップされた前記データ・コンポーネントのデータ・フィールド定義に対応するデータ・インスタンス・フィールド値を取得するステップと、
   マップされた前記データ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記データ・インスタンス・フィールド値を含むように前記メッセージ・インスタンスのメッセージ・フィールド値を生成するステップと、
   を含む方法。
2. 前記データ・コンポーネントの複数のデータ・フィールド定義が、前記マッピングによって表わされる、メッセージ・コンポーネントとデータ・コンポーネントとの間で共有される、請求項1に記載の方法。
3. 一意の前記識別子によって表わされる、複数の前記データ・フィールド定義を前記メッセージ・コンポーネントのメッセージ・フィールドの対応する一つにリンクするステップをさらに含む、請求項２に記載の方法。
4. 前記メッセージ・インスタンスの処理を支援するために、前記メッセージ・コンポーネントに結合された追加処理コードを識別するステップをさらに含む、請求項２に記載の方法。
5. 処理コードが該処理コードを取り扱うための供給ユニットのアドレスを指定する、請求項４に記載の方法。
6. 一意の前記識別子に関連してメッセージ・フィールド定義の追加的な非マップ定義を識別するステップをさらに含む、請求項３に記載の方法。
7. マッピングが、メッセージ・フィールド定義の第一の一つをデータ・フィールド定義の第一の一つにリンクし、メッセージ・フィールド定義の第二の一つをデータ・フィールド定義の第二の一つにリンクする、フィールド・レベル・マッピングである、請求項２に記載の方法。
8. 前記メッセージ・コンポーネントのメッセージ・フィールド定義の数が、マップされた前記データ・コンポーネントのデータ・フィールド定義の数より少ない、請求項７に記載の方法。
9. 第一メッセージ・フィールド定義が一意の識別子の第一の一つによってデータ・コンポーネントの第一の一つにマップされ、第二のメッセージ・フィールド定義が一意の識別子の第二の一つによって第一のデータ・コンポーネントとは異なるデータ・コンポーネントの第一の一つにマップされる、請求項７に記載の方法。
10. 第一メッセージ・フィールド定義および第二メッセージ・フィールド定義が一意の識別子を使用して同一データ・コンポーネントにマップされる、請求項８に記載の方法。
11. 前記構造化定義言語がＸＭＬベースである、請求項２に記載の方法。
12. 前記アプリケーションがワイヤレス・アプリケーションであり、前記装置がワイヤレス装置である、請求項１１に記載の方法。
13. 一意の識別子が単純な一次キーである、請求項２に記載の方法。
14. 一意の識別子が複合キーである、請求項２に記載の方法。
15. 前記メッセージ・コンポーネントが従属メッセージ・コンポーネントに結合された親メッセージ・コンポーネントを定義する、請求項２に記載の方法。
16. 従属メッセージ・コンポーネントのマッピングのそれぞれ一つによって親メッセージ・コンポーネントのマッピングの一つを無効にするステップをさらに含む、請求項１５に記載の方法。
17. 装置で実行されるアプリケーションに対応するメッセージ・インスタンスに基づいてデータ・インスタンスを生成する方法であって、
    前記アプリケーションは、
    少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントと、
    少なくとも一つのメッセージ・フィールド定義を有するメッセージ・コンポーネントと、
    を含み、
    コンポーネント定義は構造化定義言語で表現され、
    前記方法は、
    前記メッセージ・インスタンスに対応するメッセージ・コンポーネントを選択するステップと、
    前記メッセージ・コンポーネントに存在する少なくとも一つの一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定するための該マッピングを識別するステップと、
    一意のマッピング識別子によるマッピングによってマップされたデータ・コンポーネントを選択するステップと、
    マップされた前記データ・コンポーネントに対応するメッセージ・インスタンスからメッセージ・インスタンス・フィールド値を取得するステップと、
    マップされたデータ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記メッセージ・インスタンス・フィールド値を前記データ・インスタンスのデータ・インスタンス・フィールド値に割り当てるステップと、
    を含む方法。
18. 前記データ・コンポーネントの複数のデータ・フィールド定義が、前記マッピングによって表わされる、メッセージ・コンポーネントとデータ・コンポーネントとの間で共有される、請求項１７に記載の方法。
19. 一意の前記識別子によって表わされる、複数の前記データ・フィールド定義を前記メッセージ・コンポーネントのメッセージ・フィールドの対応する一つにリンクするステップをさらに含む、請求項１８に記載の方法。
20. 前記メッセージ・インスタンスの処理を支援するために、前記メッセージ・コンポーネントに結合された追加処理コードを識別するステップをさらに含む、請求項1８に記載の方法。
21. 処理コードが該処理コードを取り扱うための供給ユニットのアドレスを指定する、請求項２０に記載の方法。
22. 一意の前記識別子に関連してメッセージ・フィールド定義の追加的な非マップ定義を識別するステップをさらに含む、請求項１９に記載の方法。
23. 前記マッピングが、メッセージ・フィールド定義の第一の一つをデータ・フィールド定義の第一の一つにリンクし、メッセージ・フィールド定義の第二の一つをデータ・フィールド定義の第二の一つにリンクするフィールド・レベル・マッピングである、請求項１８に記載の方法。
24. 前記メッセージ・コンポーネントのメッセージ・フィールド定義の数が、マップされた前記データ・コンポーネントのデータ・フィールド定義の数より少ない、請求項２３に記載の方法。
25. 第一メッセージ・フィールド定義が一意の識別子の第一の一つによってデータ・コンポーネントの第一の一つにマップされ、第二のメッセージ・フィールド定義が一意の識別子の第二の一つによって第一のデータ・コンポーネントとは異なるデータ・コンポーネントの第一の一つにマップされる、請求項２３に記載の方法。
26. 第一メッセージ・フィールド定義および第二メッセージ・フィールド定義が一意の識別子を使用して同一データ・コンポーネントにマップされる、請求項２４に記載の方法。
27. 前記構造化定義言語がＸＭＬベースである請求項１８に記載の方法。
28. 前記アプリケーションがワイヤレス・アプリケーションであり、前記装置がワイヤレス装置である、請求項２７に記載の方法。
29. 一意の前記識別子が単純な一次キーである、請求項１６に記載の方法。
30. 一意の前記識別子が複合キーである、請求項１８に記載の方法。
31. 前記メッセージ・コンポーネントが従属メッセージ・コンポーネントに結合された親メッセージ・コンポーネントを定義する、請求項１８に記載の方法。
32. 従属メッセージ・コンポーネントのマッピングのそれぞれ一つによって親メッセージ・コンポーネントのマッピングの一つを無効にするステップをさらに含む、請求項３１に記載の方法。
33. 装置で実行されるアプリケーションとのインタラクションのためにデータ・インスタンスに基づいて通信メッセージ・インスタンスを生成する方法であって、
    前記アプリケーションは、少なくとも一つのメッセージ・フィールド定義および少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントおよびメッセージ・コンポーネントを含み、
    コンポーネント定義は構造化定義言語で表現され、
    前記方法は、
    前記データ・インスタンスに対応するデータ・コンポーネントを選択するステップと、
    前記データ・コンポーネントに存在する一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定する該マッピングを識別するステップと、
    一意のマッピング識別子によるマッピングによってマップされたメッセージ・コンポーネントを選択するステップと、
    マップされた前記メッセージ・コンポーネントのメッセージ・フィールド定義に対応するデータ・インスタンス・フィールド値を取得するステップと、
    マップされた前記メッセージ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記データ・インスタンス・フィールド値を含むように前記メッセージ・インスタンスのメッセージ・フィールド値を生成するステップと、
    を含む方法。
34. 装置で実行されるアプリケーションに対応するメッセージ・インスタンスに基づいてデータ・インスタンスを生成する方法であって、
    前記アプリケーションは、少なくとも一つのメッセージ・フィールド定義および少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントおよびメッセージ・コンポーネントを含み、
    前記コンポーネント定義は構造化定義言語で表現され、
    前記方法は、
    前記メッセージ・インスタンスに対応するメッセージ・コンポーネントを選択するステップと、
    前記データ・コンポーネントに存在する一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定するための該マッピングを識別するステップと、
    一意のマッピング識別子によるマッピングによってマップされたメッセージ・コンポーネントを選択するステップと、
    マップされた前記メッセージ・コンポーネントのメッセージ・フィールド定義に対応するメッセージ・インスタンスからメッセージ・インスタンス・フィールド値を取得するステップと、
    マップされた前記メッセージ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記メッセージ・インスタンス・フィールド値をデータ・インスタンスのデータ・フィールド値に割り当てるステップと、
    を含む方法。
35. 装置で実行されるアプリケーションとのインタラクションのためにデータ・インスタンスに基づいて通信メッセージ・インスタンスを生成する装置であって、
    前記アプリケーションは、
    少なくとも一つのデータ・フィールド定義を有するデータ・コンポーネントと、
    少なくとも一つのメッセージ・フィールド定義を有するメッセージ・コンポーネントと、
    を含み、
    前記コンポーネント定義は構造化定義言語で表現され、
    前記装置は、
    メッセージ・インスタンスに対応するメッセージ・コンポーネントを選択する手段と、
    前記メッセージ・コンポーネントに存在する少なくとも一つの一意のマッピングであって、該マッピングを表わす一意の識別子によって定義されるメッセージ・コンポーネントとデータ・コンポーネントとの間の関係を特定する該マッピングを識別する手段と、
    一意のマッピング識別子によるマッピングによってマップされたデータ・コンポーネントを選択する手段と、
    マップされた前記データ・コンポーネントのデータ・フィールド定義に対応するデータ・インスタンス・フィールド値を取得する手段と、
    マップされた前記データ・コンポーネントに定義されたデータ・フィールド定義のフォーマットに従って、前記データ・インスタンス・フィールド値を含むように前記メッセージ・インスタンスのメッセージ・フィールド値を生成する手段と、
    を含む装置。

Images