JP2012142017A - ワイヤレス・アプリケーションのスクリーン・エレメント又はデータ・オブジェトを生成する方法及びシステム - Google Patents

Abstract

【課題】アプリケーション・データ・ドメインとＵＩ・スクリーン及びコントロールの間で直接マッピングを実行することによって，ワイヤレス・デバイスの効果的な管理を行うためのシステム及び方法を提供すること。
【解決手段】デバイスが、一連のリンクされたスクリーン及びデータ・コンポーネント定義を含む、ワイヤレス・アプリケーションを管理するための１つの組のベーシック・サービスを提供するインテリジェント・ワイヤレス・デバイス・ランタイム環境（デバイス・ランタイム）を有しており、それらの相互作用が開発努力と資源割り当てを簡単にできる。この範疇のアプリケーションに対するデータ・ドメインは、アトミック・データ・コンポーネント定義を用いて定義される。デバイス・ユーザー・インタフェースとデータ・コンポーネントとの間のコミュニケーションは、アトミック・データ・コンポーネント定義を用いて定義される。
【選択図】図１

Description

本発明は、一般的には、ワイヤレス・デバイスのユーザー・インターフェースにおけるワイヤレス・アプリケーションの表示に関する。

携帯電話、ワイヤレス・コミュニケーション機能を有するＰＤＦ、双方向ポケベルのように今日使用されているワイヤレス・デバイスの数は増加し続けている。これらのデバイスで作動するソフトウエア・アプリケーションの実用性が高まっている。例えば、携帯電話が、ある範囲の都市の天気を検索するアプリケーションを含んでいることもあり、あるいはＰＤＦが、ユーザーが食料雑貨類の買い物をできるようにするアプリケーションを含んでいることもある。これらのソフトウエア・アプリケーションは、ユーザーにタイムリーで有用なサービスを提供するために、ネットワークとの接続性を活用している。しかし、ある種のデバイスは供給源が限定されており、またそれらのデバイスに大量のデータを転送するのが複雑であるため、種々のデバイスに対するソフトウエア・アプリケーションを開発するのは、相変わらず困難でかつ時間を要する仕事である。

現在では、 デバイスは、インターネット・ベース・ブラウザー及び／又はネイテイブ
・アプリケーションによってウエブ・サービスとコミュニケーションするように構成されている。ブラウザーは、種々の異なるデバイスに対して、クロスプラットフォーム・ベースで動作するように適合しうる利点を有しているが、ウエブ・サービスからページ（ＨＴＭＬでのスクリーン定義）を要請するので、それがスクリーンに含まれたデータの持続を妨げるという難点がある。ネイテイブ・アプリケーションは、デバイス・プラットフォームのタイプに対して特別に開発され,各ランタイム環境に対して比較的最適化されアプリケーション・プログラムを提供するという利点を有する。しかし、ネイテイブ・アプリケーションは、プラットフォーム非依存でないので、同じアプリケーションの多数のバージョンを開発する必要があるとともに、サイズが比較的大きく、デバイスのメモリ資源に重い負担をかけることになるという難点を有する。さらに、アプリケーション・デベロッパーは、スクリーン・エレメントとデータ・エェメントとのハードコードされた静的相互作用を含むハードコードされたネイテイブ・アプリケーションを構成するためには、Ｊａｖａ（登録商標）やＣ++のようなプログラム言語の経験を必要とする。データとスクリーン・エレメントとの間の動的相互作用を利用して種々のランタイム環境を有するとともに、デバイス資源の消耗の少ないクライアント・デバイスで作動し得るアプリケーション・プログラムが必要とされる。

本明細書で開示されるシステム及び方法は、上述した難点の少なくとも幾つかを排除または軽減するためのリンクしたスクリーン及びデータ・コンポーネント定義環境を提供する。

明示的コード化を行う必要性を軽減するとともに、組み入れ時にアプリケーションによって利用されるデバイス資源を軽減することによって、ワイヤレス・アプリケーションの開発時に伴う複雑性を少なくすることが望ましい。アプリケーション・データ・ドメインとユーザー・インタフェース（ＵＩ）スクリーン及びコントロールとの間で直接のマッピングを実行することによる、ワイヤレス・デバイスのユーザー・インタフェース（ＵＩ）の効果的な管理のためのシステム及び方法について記述する。デバイスは、一連のリンクしたスクリーン及びデータ・コンポーネント定義を含むワイヤレス・アプリケーションを管理するための１つの組の基本サービスを提供するインテリジェントなワイヤレス・デバイス・ランタイム環境(デバイス・ランタイム)を有しており、かつそれらの相互作用が
、開発努力を単純化させ、そして資源の割り当てを少なくすることができる。このカテゴリのアプリケーションに対するデータ・メインは、アトミック・データ・コンポーネント定義を用いて定義される。デバイス・ユーザー・インタフェースとデータ・コンポーネントの間のコミュニケーションは、アトミック・スクリーン・コンポーネント定義を用いて定義される。スクリーンとデータのコンポーネント定義の両方とも、ＸＭＬのような体
系的な定義言語を用いてメタデータで記述される。スクリーン及びデータ・コンポーネント定義の間の関係は、スクリーン／データ・マッピングの形でＸＭＬ定義で具現化される。通常は、表示のための描画スクリーンは、ある基調をなすデータ・コンポーネントから得られ、かつユーザー事象によって影響されるスクリーン・コントロールがアプリケーションの現在の状態（またはデータ表示）に影響を与える。アプリケーション・ドメイン・データに対する変化は、ユーザー・インタフェースと自動的に同期化され、ユーザーが入れたデータがアプリケーション・ドメイン・データに自動的に反映される。この同期化の背後における主要な機構は、スクリーン及びデータのマッピングである。この機構が、動的でかつ対話的なスクリーンの生成を可能にする。データ・コンポーネントの変化はすべて、スクリーンに直ちに反映され、またその逆のこともなされる。このモデルは、サー
バーとデバイスとの通知に基づいて、効果的なワイヤレス・アプリケーションを構築することを可能にする。サーバーから非同期的に押されるデータ更新は即時にＵＩスクリーンに反映される。

本発明によれば、少なくとも１つのデータ・フィールド定義を有するデータ・コンポーネント及び少なくとも１つのスクリーン・エレメント定義を有するスクリーン・コンポーネントを含んでいて、コンポーネント定義が構造化定義言語で表現されているワイヤレス・アプリケーションのスクリーン・エレメントをワイヤレス・デバイスのユーザー・インタフェースに表示されるデータ・オブジェクトに基づいて生成する方法であって、表示のために選択されるスクリーン・エレメントに対応するスクリーン・コンポーネントを選択するステップと、スクリーン・コンポーネントに存在する少なくとも１つのマッピングであって、マッピングを表わす識別子によって定義されるスクリーン・コンポーネントとデータ・コンポーネントとの間の関係を指定するためのマッピングを識別するステップと、前記マッピング識別子に従って前記マッピングによってマップされたデータ・コンポーネントを選択するステップと、マップされたデータ・コンポーネントのデータ・フィールド定義に対応するデータ・オブジェクト・フィールド値を取得するステップと、マップされたデータ・コンポーネントで定義されたデータ・フィールド定義のフォーマットに従ってフィールド値を含むように、スクリーン・エレメント定義からスクリーン・エレメントを生成するステップとを含む、ワイヤレス・アプリケーションのスクリーン・エレメントを生成する方法が提供される。

本発明の他の態様によれば、少なくとも１つのデータ・フィールド定義を有するデータ・コンポーネント及び少なくとも１つのスクリーン・エレメント定義を有するスクリーン・コンポーネントを含んでいて、コンポーネント定義が構造化定義言語で表現されているワイヤレス・アプリケーションのスクリーン・エレメントをワイヤレス・デバイスのユーザー・インタフェースに表示されるデータ・オブジェクトに基づいて生成するシステムであって、前記スクリーン・エレメントに対応するスクリーン・コンポーネントを選択しかつ前記スクリーン・コンポーネントに存在する少なくとも１つのマッピングを識別するマッピング・マネージャであり、前記マッピングはスクリーン・コンポーネントと前記マッピングを表わす識別子によて定義されたデータ・コンポーネントとの間の関係を特定し、前記マッピング・マネージャはマッピング識別子によるマッピングによってマップされたデータ・コンポーネントを選択するマッピング・マネージャと、マップされたマッピング・マネージャのデータ・フィールド定義に対応したデータ・オブジェクト・フィールド値を取得するデータ・マネージャと、マップされたデータ・コンポーネントで定義されたデータ・フィールド定義のフォーマットによるデータ・オブジェクト・フィールド値を含むように、スクリーン・エレメント定義からスクリーン・エレメントを生成するスクリーン
マネージャとを具備する、ワイヤレス・アプリケーションのスクリーン・エレメントを
生成するシステムが提供される。

本発明のさらに他の態様によれば、少なくとも１つのデータ・フィールド定義を有するデータ・コンポーネント及び少なくとも１つのスクリーン・エレメント定義を有するスクリーン・コンポーネントを含んでいて、コンポーネント定義が構造化定義言語で表現されているワイヤレス・アプリケーションのデータ・オブジェクトをワイヤレス・デバイスのユーザー・インタフェースに表示されるスクリーン・エレメントの変化に基づいて生成する方法であって、スクリーン・エレメントに対応するスクリーン・コンポーネントを選択するステップと、スクリーン・コンポーネントとデータ・コンポーネントとの間の関係を指定するためのマッピングであって、スクリーン・コンポーネントに存在する少なくとも１つのマッピングを識別するステップと、マッピングによってマップされたデータ・コンポーネントを選択するステップと、マップされたデータ・コンポーネントに対応するスクリーン・エレメントから変化した値を取得するステップと、前記マップされたデータ・コンポーネントで定義されたデータ・フィールド定義のフォーマットに従ってデータ・オブジェクトのデータ・フィールド値に、前記変化した値を割り当てるステップとを含む、ワイヤレス・アプリケーションのデータ・オブジェクトを生成する方法が提供される。

本発明のさらに他の態様によれば、少なくとも１つのデータ・フィールド定義を有するデータ・コンポーネント及び少なくとも１つのスクリーン・エレメント定義を有するスクリーン・コンポーネントを含んでいて、コンポーネント定義が構造化定義言語で表現されているワイヤレス・アプリケーションのスクリーン・エレメントをワイヤレス・デバイスのユーザー・インタフェースに表示されるデータ・オブジェクトに基づいて生成する装置であって、表示のために選択されるスクリーン・エレメントに対応するスクリーン・コンポーネントを選択する手段と、スクリーン・コンポーネントとマッピングを表わす識別子によって定義されるデータ・コンポーネントとの間の関係を指定するためのマッピングであって、スクリーン・コンポーネントに存在する少なくとも１つのマッピングを識別する手段と、前記マッピングによってマップされたデータ・コンポーネントを選択する手段と、マップされたデータ・コンポーネントのデータ・フィールド定義に対応するデータ・オブジェクト・フィールド値を取得する手段と、マップされたデータ・コンポーネントで定義されたデータ・フィールド定義のフォーマットに従ってフィールド値を含むように、スクリーン・エレメント定義からスクリーン・エレメントを生成する手段と、を含む、ワイヤレス・アプリケーションのスクリーン・エレメントを生成する装置が提供される。
本発明のさらに他の態様によれば、少なくとも１つのデータ・フィールド定義を有するデータ・コンポーネント及び少なくとも１つのスクリーン・エレメント定義を有するスクリーン・コンポーネントを含んでいて、コンポーネント定義が構造化定義言語で表現されているワイヤレス・アプリケーションのスクリーン・エレメントをワイヤレス・デバイスのユーザー・インタフェースに表示されるデータ・オブジェクトに基づいて生成するコンピュータ・プログラム製品であって、コンピュータ可読媒体と、前記コンピュータ可読媒体に格納され、前記スクリーン・エレメントに対応するスクリーン・コンポーネントを選択しかつスクリーン・コンポーネントに存在する少なくとも１つのマッピングであって、マッピングを表わす識別子によって定義されるスクリーン・コンポーネントとデータ・コンポーネントとの間の関係を指定するためのマッピングを識別し、マッピング識別子に従ってマッピングによってマップされたデータ・コンポーネントを選択するマッピング・モジュールと、前記コンピュータ可読媒体に格納され、前記マップされたデータ・コンポーネントのデータ・フィールド定義に対応したデータ・オブジェクト・フィールド値を取得するデータ・モジュールと、前記コンピュータ可読媒体に格納され、前記マップされたデータ・コンポーネントで定義されたデータ・フィールド定義のフォーマットに従ってデータ・オブジェクト・フィールド値を含むように前記スクリーン・エレメント定義からスクリーン・エレメントを生成するスクリーン・モジュールと、
を備えるコンピュータ・プログラム製品が提供される。

ネットワーク・システムのブロック図である。 図１のワイヤレス・デバイスのブロック図である。 図２のデバイスのインテリジェント・フレームワークのブロック図である。 図２のコンポーネント・アプリケーション・プログラムのブロック図である。 図４の例示コンポーネント・アプリケーションに対する代表的なアプリケーション・パッケージング及びホステイング・モデルを示している。 図５のコンポーネント・アプリケーション・プログラムを実行する例示方法を示している。 図５のコンポーネント・アプリケーション・プログラムを実行する他の例示方法を示している。 図２のアプリケーションのためのデータとスクリーン・コンポーネントの間のマッピングを示している。 図８のマッピングに対する初期スクリーン・デイスプレイの動作を示している。 図８のマッピングに対するユーザー事象によるデータ・オブジェクトの更新を示している。 図８のマッピングに対する非同期メッセージによるデータ・オブジェクトの更新を示している。

これらの及び他の特徴は、例示のためのみに添付図面を参照してなされる下記の詳細な説明において、さらに明らかとなるであろう。

図１を参照すると、ネットワーク・システム１０は、インタネットのようなものであるが、それに限定されない結合広域ネットワーク（ＷＡＮ）１０４を経由して、１またはそれ以上のジェネリック・サービス１０６と相互作用するための複数のワイヤレス・デバイス１００を含んでいる。これらのデバイス１００は、ＰＤＡ、ポケベル、携帯電話等の
ようなものでありうるが、それらに限定されない。サービス１０６によって提供されるジェネリック・サービスは、ＳＱＬデータベース、ＩＤＬベースＣＯＲＢＡ及びＲＭＩ／ＩＩＯＰシステム、レガシー・データベース、Ｊ２ＥＥ、ＳＡＰ ＲＦＣ、及びＣＯＭ／ＤＣＯＭコンポーネントのようなものであるが、それらに限定されないウエブ・サービス及び／又は他のサービスでありうる。さらに、システム１０は、ワイヤレス・デバイス１００をＷＡＮ１０４に接続するためのワイヤレス・ネットワーク１０２を有していてもよい。他のデバイス（図示せず）がＷＡＮ１０４及び図１に示されているもの以外の関連ネットワークを経由してウエブ・サービス１０６に接続されうることが分かる。システム１
０についての下記の説明では、簡単のために、スキーマに従って定義されたウエブ・サービス１０６が選択される。しかし、もし所望されれば、そのウエブ・サービス１０６を他のサービスに置き換えてもよいことが認めされている。さらに、システム１０のネットワーク１０２、１０４を、以後簡単のために、ネットワーク１０４と呼ぶことにする。

図１を再び参照すると、デバイス１００は、ウエブ・サービス１０６とコミュニケーションしているときに、リクエスト／レスポンス・メッセージ１０５をそれぞれ送信しかつ受信する。デバイス１００は、例えば製品価格及びオンライン・マーチャントからの入手可能性を要求して受信するように、メッセージ・ヘッダー情報及び関連したデータ内容の形態でのリクエスト／レスポンス・メッセージを用いることによってウエブ・サービス１０６のウエブ・クライアントとして動作することができる。ウエブ・サービス１０６は、コミュニケーション・デバイス１００のユーザーに便益を提供するために、コミュニケーション・デバイス１００におけるクライアント・アプリケーション・プログラム３０２（図２参照）が、ネットワーク１０４を介して、相互作用するシステムの一例である。

適切なリクエスト／レスポンス・メッセージ１０５を充足させるために、ウエブ・サービス１０６は、デバイス１００にいったん搭載されたクライアント・アプリケーション・プログラム３０２（図２参照）に、該当するビジネス・ロジック(方法)を顕在化させるための種々のプロトコル（ＨＴＴＰ及びコンポーネントＡＰＩのようなものであるが、それらに限定されない）を介してアプリケーション・サーバー１１０とコミュニケートすることができる。アプリケーション・サーバー１１０は、ウエブ・サービス１０６がアプリケーション・サーバー１１０のサブセットと認定できるように、ウエブ・サービス１０６ソフトウエアを含んでいてもよい。デバイス１００のアプリケーション・プログラム３０
２は、オブジェクト（又は機能）についての方法を呼び出すために、アプリケーション・サーバー１１０のビジネス・ロジックをどうように使用することができる。クライアント・アプリケーション・プログラム３０２は、ネットワーク１０４を経由してメッセージ１０５を通じて、アプリケーション・サーバー１１０に関連して、デバイス１００に直接にダウンロード／ダウンロードすることができることが分かる。デバイス１００は、ネットワーク１０４を経由して、１つまたはそれ以上のウエブ・サービス１０６及び関連するアプリケーション・サーバー１１０とコミュニケートできることがさらに分かる。
サーバー環境
図１を参照すると、ウエブ・サービス１０６は、デバイス１００上のクライアント・アプリケーション・プログラム（図２参照）によって同期的にまたは非同期的に使用される情報メッセージ１０５を提供する。あるいは、またはさらに、ウエブ・サービス１０６
は、デバイス１００で実行されるクライアント・アプリケーション・プログラム３２０によって提供される情報メッセージ１０５を受信かつ使用してもよく、あるいはデバイス１００で実行されるクライアント・アプリケーション・プログラム３０２のためにタスクを行ってもよい。ウエブ・サービス１０６は、ウエブ・サービス・レジストリにおけるユニバーサル・デイスカバリ・デスクリプション・アンド・インテグレーション（ＵＤＤＩ）に登録されたウエブ・サービス記述言語（ＷＳＤＬ）を用いて表現されるようなインタフェースを実行可能なソフトウエアサービスとして定義することができ、かつシンプル・
オブジェクト アクセス プロトコル（ＳＯＡＰ）のような適切なプロトコルによりネットワーク１０４上に露呈されることによって、メッセージ１０５を介してクライアント・デバイス１００とコミュニケートすることができる。ある種の実行場面では、ＳＯＡＰが、ＳＯＡＰエレメントに封入された適格なＸＭＬフラグメントを含むメッセージ１０５のためのＸＭＬフォーマットを定義する規格である。ＳＯＡＰはまた、ＳＯＡＰメッセージ１０５がＸＭＬ文書のまわりのラッパーである文書形式のアプリケーションをサポートする。ＳＯＡＰの他の任意の部分がＨＴＴＰバインデイング（すなわち、ヘッダー）を定義し、他方、あるＳＯＡＰ実行がＭＳＭＱ、ＭＱシリーズ、ＳＭＴＰ、又はＴＣＰ／ＩＰトランスポート・プロトコルをサポートする。あるいは、ウエブ・サービス１０６は、他の
既知のコミュニケーション・プロトコル、メッセージ１０５フォーマットを使用してもよく、かつインタフェースは、上述した以外のウエブ・サービス言語で表現されてもよい。クライアント環境
図２を参照すると、コンポーネント・アプリケーション３０２は、ネットワーク１０４を経由して伝送され、そしてデバイス１００のデバイス・インフラストラクチャー２０４のメモリ・モジュール２１０にロードされる。あるいは、コンポーネントアプリケーシ
ョン３０２は、シリアル接続、ＵＳＢ接続、あるいはＩＲ，８０２．１１（ｘ）ブルーツースＴＭ（図示せず）のような短距離ワイヤレス・コミュニケーション・システムを介してロードされてもよい。デバイス１００にいったんロードされると、コンポーネント・アプリケーション３０２は、デバイス１００におけるインテリジェント・ランタイム・フレームワーク２０６によって実行することができ、それでコンポーネント・アプリケーション３０２をネイテイブ・コードに変換することができ、そのネイテイブ・コードがデバイス・インフラストラクチャー２０４におけるプロセッサ２０８によって実行される。あ
るいは、アプリケーション３０２は、デバイス１００における他のソフトウエア・モジュール又はオペレーテイング・システムによって解釈されてもよい。いずれにしても、コンポーネント・アプリケーション３０２は、デバイス１００によって提供されるターミナル・ランタイム環境で作動され、ランタイム環境が典型的なアプリケーション３０２動作（例えば、持続、メッセージング、スクリーン、ナビゲーションおよびデイスプレイ）を管理しかつ実行する１つの組のベーシック・サービスを提供するインテリジェント・ソフトウエア・フレームワーク２０６である。

図１を再び参照すると、デバイス１００によって提供されるクライアント・ランタイム環境は、デバイス１００をウエブ・サービス１０６のウエブ・クライアントとして動作させるように構成されうる。クライアント・ランタイム環境は、他の任意のジェネリック・スキーマ定義されたサービスのデバイス１００クライアントをネットワーク１０４上で作成することもできることが分かる。デバイス１００のクライアント・ランタイム環境は、デバイス１００上でクライアント・アプリケーション・プログラム３０２（データ４００及びスクリーン４０２コンポーネント定義を含む‐図４及び下記の説明を参照）を生成し、ホステイングし、かつ実行できることが好ましい。さらに、クライアント・ランタイム環境の特定の機能は、言語に対するサポート、メモリ割り当ての調整、ネットワーキング、Ｉ／Ｏ動作時におけるデータの管理、デバイス１００のうちの１つの出力デバイスにおけるグラフィックスの調整、コア・オブジェクト・オリエンテッド・クラスへのアクセスの提供、及びファイル／ライブラリのサポート等を含むが、それらに限定されない。デバイス１００によって実行されるランタイム環境の例は、マイクロソフトの共通言語ランタイム（ＣＬＲ）およびサン・マイクロ・システムのＪａｖａ（登録商標）ランタイム環境（ＪＲＥ）を含んでいてもよいが、それらに限定されない。

デバイス１００のターミナル・ランタイム環境は、クライアント・アプリケーション・プログラム３０２（図２参照）の常駐実行可能バージョンに対する下記のような、ただしそれらに限定されない基本機能をサポートすることが好ましい。すなわち、
メッセージ１０５をウエブ・サービス１０６に、あるいはネットワーク１０４を経由してデバイス１００に接続された任意の他のジェネリック・スキーマ定義サービスにメッセージ１０５を送るためのコミュニケーション機能を提供すること；
ウエブ・サービス１０６発信メッセージ１０５（そのサービスへのメッセージ）に対するデータ部分を供給するための入力デバイスに対するユーザーによるデータ入力機能を提供すること；
ウエブ・サービス１０６レスポンス・メッセージ１０５（着信メッセージ）又は出力デバイスにおける無相関の告知のためのデータ・プレゼンテーション又は出力機能を提供すること；
デバイス１００のメモリ・モジュール２１０（図２参照）にローカル・クライアント・データを維持するためのデータ格納サービスを提供すること；
クライアント・アプリケーション・プログラム３０２のコンポーネント４００、４０２（図４参照）の動作を調整するためのスクリプト言語に対する実行環境を提供することである。

図２、４及び５を参照すると、クライアント・ランタイム（例えばコンポーネント・フレームワーク２０６によって提供される）が、コンポーネント４００、４０２定義に含まれたメタデータをロードし、そしてまた、例えば実行環境３００を介してデバイス１００上のアプリケーション・プログラム３０２の実行可能バージョンを構成する。クライアント・ランタイムに対しては、テンプレート・ベース・ネイテイブ実行とメタデータ・ベース実行との２つのオペレーショナル・モードがあるが、それらには限定されない。完全に定義されたコンポーネント・ベース・アプリケーション３０２（データ４００、スクリーン４０２、メッセージ４０４０、及びワークフロー４０６コンポーネントを有する‐図４参照）の場合には、フレームワーク２０６は、データ、メッセージ、及びネイテイブ・コードを用いてデバイス１００上に予め構築されたスクリーン・テンプレート５００をホステイングするためのテンプレート・ベース・ネイテイブ実行モデルを実行することができる。アプリケーション・プログラム３０２定義がロードされる場合には、フレームワーク２０６によって提供されるクライアント環境が、コンポーネント４００、４０２、４０４からのメタデータ定義パラメータをテンプレート５００に充填し、そして実行可能なクライアント・アプリケーション・プログラム３０２をネイテイブ・フォーマットで構築する。ワークフロー・コンポーネント４０６のワークフロー・スクリプト（例えばＥＣＭＡＳスクリプト)は、ネイテイブ・コードに変換されるか、あるいはネイテイブ・コード・リ
デイレクタ５０４に適当なスクリプト・インタプリタ５０２（例えばＥＣＭＡＳスクリプト・インタプリタ）を用いて実行されてもよく、この場合、リデイレクタ５０４は、ネイテイブ・ランタイム・エンジン５０６を介して、ネイテイブ・コンポーネントにおける動作内でのスクリプト言語への呼びかけを解釈する。メタデータ・ベース実行では、フレームワーク２０６のランタイム環境は、実行時間の間に解析されるＸＭＬ（例えば）でのコンポーネント４００、４０２、４０４、４０６定義を保持するか、あるいはＸＭＬ（例えば）ノードのネイテイブ・リプレゼンテーションを用いる。実行時には、ネイテイブ・ランタイム・エンジン５０６が、ネイテイブ・コンポーネント・エンテイテイに対してではなくて、コンポーネント４００、４０２、４０４、４０６の定義に対して動作する。他の形式の実行モデルは、データとスクリーンに対してコンポーネント定義４００、４０２を有するアプリケーションを含んでいるとともに、アプリケーション３０２の他のメッセージ及びワークフロー要素に対する、よりハード・コードされた４０５アプローチを有するであろうことが分かる。

従って、ネイテイブ・クライアント・ランタイム環境は、デバイス・インフラストラクチャー２０４のプロセッサ２０８及び関連オペレーテイング・システムのデバイス１００機能性にクライアント・アプリケーション・プログラム３０２に対するインタフェースを提供する。ランタイム環境は、コンポーネント・アプリケーション・プログラム３０２が実行するコントロールされた確実で安定した環境をデバイス１００上に供給することが好ましい。デバイス１００の各デバイス・インフラストラクチャー２０４に固有の事実上のウエブ・クライアントを生成するために、ランタイム環境は、コンポーネント４００、４０２の定義（及び使用されておれば、定義４０４、４０６）を供給する。簡単のために、下記の説明では、一例のみとして、フレームワーク２０６によって提供されているクライアント・ランタイム環境について述べる。
コミュニケーション・デバイス
図２を再び参照すると、デバイス１００は、携帯電話、ＰＤＡ、双方向ポケベル、あるいはデユアル・モード・コミュニケーション・デバイス等のデバイスであるが、それらに限定されない。デバイス１００は、コネクション２１８を介してデバイス・インフラストラクチャー２０４に接続されたワイヤレス・トランシーバー２０４のようなネットワーク・コネクション・インタフェース２００を含んでいる。コネクション・インタフェース２００は、デバイス１００の動作時に、ネットワーク１０４を介してデバイス１００を互いにかつ外部システム（ウエブ・サービス１０６のような）コミュニケートさせ、かつクライアント・アプリケーション・プログラムs３０２とサービス１０６（図一参照）との間
のリクエスト／レスポンス・メッセージ１０５を調和させるワイヤレス・ネットワーク１０２のようなネットワーク １０４にワイヤレス・リンク（例えば、ＦＲ、ＩＲ、等）に
よって接続可能である。ネットワーク１０４は、このネットワーク１０４に接続されるデバイスと外部システムとの間のリクエスト／レスポンス・メッセージ１０５におけるデータの伝送をサポートする。ネットワーク１０４はまた、デバイスとこのネットワークの外部のデバイスとの間の電話呼び出しのための音声コミュニケーションをもサポートすることができる。ＤａｔａＴＡＣ、ＧＰＲＳあるいはＣＤＭＡのような、しかしそれらに限定されないワイヤレスデータ伝送 プロトコルが、ワイヤレス・ネットワーク１０２によって使用できる。

図２を再び参照すると、デバイス１００はまた、ユーザー１００（図示せず）と通話するために、ユーザー・インタフェース２０２をコネクション２２２によってデバイス・インフラストラクチャー２０４に結合されている。ユーザー・インタフェース２０２は、ＱＷＥＲＴＹキーボード、キーパッド、トラックホイール、スタイラス、マウス、マイクロホン、及びＬＣＤスクリーン・デイプレイ及び／又はスピーカーのようなユーザー出力デバイスのような、しかしそれらに限定されない１つ又はそれ以上のユーザー入力デバイスを具備している。スクリーンがタッチセンシテイブである場合には、デイスプレイは、デバイス・インフラストラクチャー２０４によって制御されるユーザー入力デバイスとしても使用されうる。ユーザー・インタフェース２０２は、さらに後述するように、フレームワーク２０６のクライアント・アプリケーション・プログラム３０２によって用いられるシステム１０（図１参照）上でリクエスト／レスポンス・メッセージ１０５を調整するために、デバイス１００のユーザーによって使用される。

図２を再び参照すると、デバイス１００の動作が、デバイス・インフラストラクチャー２０４によって可能とされる。デバイス・インフラストラクチャー２０４は、コンピュータ・プロセッサ２０８及び関連したメモリ・モジュール２０１を具備している。コンピュータ・プロセッサ２０８は、メモリ・モジュール２１０内に配置されたオペレーテイング・システム及びクライアント・アプリケーション・プログラム３０２によって与えられる関連する命令を実行することによって、コミュニケーション・デバイス１００のネットワーク・インタフェース２００、ユーザー・インタフェース２０２及びフレームワーク２０６の動作を操作する。さらに、デバイス・インフラストラクチャー２０４は、プロッセ
さに及び／又はメモリ・モジュール２１０におけるロード／更新クライアント・アプリケーション・プログラム３０２に命令を与えるためにプロッセに結合されたコンピュータ可読記憶媒体２１２を含んでいてもよいことが分かる。コンピュータ可読媒体２１２は、例示としてのみの磁気デイスク、磁気テープ、ＣＤ／ＤＶＤ ＲＯＭＳのような光学的に読み取り可能な媒体、及びメモリ・カードのようなハードウエア及び／又はソフトウエア
を含んでいてもよい。それぞれの場合において、コンピュータ可読媒体２１２は、小型デイスク、フロッピー（登録商標）・デイスケット、カセット、ハード・デイスク・ドライブ、固体メモリ・カード、あるいはメモリ・モジュール２１０で提供されるＲＡＭの形態をなしうる。上記に例示したコンピュータ可読媒体２１２は、単独でまたは組み合わせで使用できることに注目すべきである。
コンポーネント間のマッピング関係
実際には、通常、デベロッパーによるコンポーネント４００、４０２の表現は重複した内容を有していてもよいが、アプリケーション３２０の各コンポーネント４００、４０２の動作は異なっている。従って、ユーザー・インタフェース２０２（図１参照）内容がある種の基調をなすデータ・エレメントから生成されることが多いことを認識し、かつこれらのコンポーネント４００、４０２の表現間の類似性を考慮すると、後述するように、スクリーン・コンポーネント４０２の表現に所定のマッピング８０４（図８参照）を導入するのが好都合である。図４及び８を参照すると、これらのマッピング８０４は、スクリーン・コンポーネント４０２に関連したスクリーン・エレメント８０２(スクリーン・エレ
メント定義)の表現への、及びアプリケーション３０２の実行時のランタイムで、スクリ
ーン・コンポーネント４０２がどのように動作するかへの、本質的にショートカットである。マッピング８０４は、スクリーン・コンポーネントのスクリーン・エレメント定義とデータ・コンポーネント４００定義の間の規定された関係である。スクリーン・コンポーネント４０２の表現との関連では、マッピング８０４を用いると、コンポーネント４０２を記述するために要するメタデータ４０２の量を軽減することができる。従って、マッピング８０４を使用することは、アプリケーション３０２を記述するのに要する「コード」の量に直接の影響を及ぼしうる。コンポーネント４０２がランタイムでどのように動作するかに関連して、リンクしたデータ・エレメント（データ・コンポーネント４００によって記述された）がスクリーン・エレメント８０２状態によって、どのように解決されかつ影響されるかを、マッピング８０４が指定する。この関連で、マッピング８０４を指定すると、デベロッパーがアプリケーション３０２に付加的な特定のスクリーン処理コードを提供する必要性を軽減することができる。

図８を参照すると、スクリーン・コンポーネント４０２（図４参照）のスクリーン・リプレゼンテーションは、ユーザー・インタフェース２０２上に表示されかつ対応するデータ・オブジェクト８００のデータ・フィールド事例に関連したＵＩコントロールのような、しかしそれに限定されないスクリーン・エレメント８０２よりなる。従って、各スクリーン・エレメント８０２は、該当するデータ・オブジェクト８００のフィールドにバインドまたはマップ８０４される。アプリケーション３０２のユーザーは、ユーザー・インタフェース２０２（図１参照）におけるスクリーン・エレメント８０２を選択し、かつそれら内の、すなわちユーザー事象によるコントロールを編集することができる。スクリーン・エレメント８０２の修正は、スクリーン・エレメント８０２にマップされるデータ・オブジェクト８００に伝播される。同様に、データ・オブジェクト８００に対する全ての修正（アプリケーション３０２ロジック又は着信サーバー・メッセージ１０５によって駆動される）は、これらのデータ・オブジェクト８００に対してマッピングされるスクリーン・エレメント８０２に反映される。ユーザー事象及びデータ・オブジェクト８００に対する直接の修正の追跡は、後述するように、マッピング・マネージャ３１２を介してモニターされる。マッピング８０４は、このマッピング８０４によって影響されるデータ・オブジェクト８００の同定及び修正を規定する。マッピング８０４は、対応するスクリーン・コンポーネント４０４のスクリーン・エレメント８０２がリンクされるデータ・コンポーネント４００のデータ・オブジェクト８００を隔離する。

スクリーン・コンポーネント４０２又はデータ・コンポーネント４００定義が、データ・オブジェクト８００とスクリーン・エレメント８０２の間の関係又はデータ・オブジェクト８００の個々のデータ・フィールド（又はデータ・フィールドのグループ）とスクリーン・エレメント８０２との間の関係を定義するマッピング８００を含んでいることが分かる。データ・オブジェクト８００は、パラメーターとしてユーザー・インタフェース２０２に通過されてもよいことが分かる。この場合には、スクリーン・エレメント８０４にマップされたデータ・オブジェクト８００のデータ・フィールド値が、通過されたパラメーターから抽出されるであろう。例えば、スクリーン・コンポーネント４０２のスクリーン・フィールド定義で定義された編集コントロール（スクリーン・エレメント８０２）が、リンクされたデータ・コンポーネント４００のデータ・フィールド定義内に（すなわち１対１マッピング８０４）マッピングされうるか、あるいはスクリーン・コンポーネント４０２のスクリーン・フィールド定義で定義された選択コントロール（スクリーン・エレメント８０２）が、データ・コンポーネント４００のコレクションの特定のデータ・フィールド定義内に（すなわち、１対多数マッピング８０４）マップされうる。

図４及び８を参照すると、スクリーン・コンポーネント・メタデータが、それの他の属性に加えて、リンクされたデータ・コンポーネント４００のデータ・フィールド定義へのマッピングを記述することができる。例えば、単一のスクリーン・エレメント８０２は下記に対してマップできる：
・データ・コンポーネント４００のデータ・フィールド定義の１つ
・プライマリ・キー（又はマッピング識別子）によるデータ・コンポーネント４００の全てのデータ・フィールド定義‐この場合には、マッピング８０４はプライマリ・キー・フィールドに帰着する。
選択／リスト・スクリーン・エレメント８０２は下記に対してマップできる：
・データ・コンポーネント４００の全ての事例のコレクション、又は
・コレクションであるデータ・コンポーネント４００のデータ・フィールド定義の１つ。

「ユーザー」データ・コンポーネント４００の特定のデータ・オブジェクト８００の「ネーム」フィールドに対してマップされたエデイット・スクリーン・エレメント８０２「ｅｂＮａｍｅ」の一例と、「ユーザー」データ・コンポーネント４００の全てのデータ・オブジェクト８００の「ネーム」フィールドに対してマップされた選択スクリーン・エレメント８０４「ｃｂＮａｍｅｓ」の一例に対しては、下記の例示コンポーネントアプリ
ケーション３０２を参照されたい。
デバイスのフレームワーク
図２を参照すると、デバイス１００のフレームワーク２０６が、コネクション２２０によって、デバイス・インフラストラチャー２０４に接続されている。デバイス１００のクライアント・ランタイム環境は、フレームワーク２０６によって提供され、かつメタデータ定義からクライアント・アプリケーション・プログラム３０２（コンポーネント定義を含む‐下記を参照）を生成し、ホステイングし、そして実行できることが好ましい。デバイス・ランタイムは、持続、提供、メッセージング、スクリーン・ナビゲーション、及びユーザー・インタフェース/スクリーン・サービスのような、しかしそれらに限定されな
い典型的なアプリケーション３０２動作を管理しかつ実行するための１つの組の基本サービス３０４を提供するインテリジェント・ソフトウエア・フレームワーク２０６と考えることができる。従って、フレームワーク２０６は、クライアント・アプリケーション・
プログラム３０２に対するネイテイブ・クライアント ランタイム環境を提供し、かつデ
バイス・インフラストラクチャー２０４のプロセッサ２０８および関連したオペレーテイング・システムのデバイス１００機能性に対するインタフェースである。フレームワーク２０６は、好ましくはデバイス１００上にコントロールされた確実で安定した環境を供給することによってランタイム環境を提供し、この場合には、コンポーネント・アプリケーション・プログラム３０２が、例えばアプリケーション・コンナテナ又は実行環境３００で実行する。

図３を参照すると、フレームワーク２０６は、ターミナル・ランタイム環境内でクライアント・アプリケーション・プログラム３０２（ウエブ・サービス・クライアント・アプリケーションのような）を実行するために使用することができ、かつネットワーク１０４上でリクエスト／レスポンス・メッセージ１０５を経由してのウエブ・サービス１０６及び関連アプリケーション・サーバー１１０（図１参照）へのアクセスをサポートする。コンポーネント・アプリケーション・プログラム３０２は、フレームワーク２０６によって実行されるソフトウエア・アプリケーションを含んでいる。フレームワーク２０６は、アプリケーション・プログラム３０２が実行されるごとに、アプリケーション・プログラム３０２の各コンポーネント４００、４０２（及びもし使用されておれば定義４０４、４０６-図４参照）に対する実行環境３００を生成する。実行環境３００は、アプリケーション・プログラム３０２のコンポーネント４００、４０２（もし使用されていれば定義４０４、４０６）をロードし、かつデバイス・インフラストラクチャー２０４におけるプロ
セッサ２０８によって実行されるネイテイブ・コードを生成する。従って、フレームワーク２０６は、コンポーネント４００、４０２の定義（もし使用されていれば定義４０４、４０６）を提供するためのホスト実行環境３００を提供して、コミュニケーション・デバイス１００の各該当するデバイス・インフラストラクチャー２０４に固有の実際のウエブ
クライアントを生成する。実行環境３００は、例示のみとして上述したテンプレート・
ベース・ネイテイブ実行モデル及びメタデータ・ベース実行モデルによって、アプリケーション３０２を提供することができる。実行環境３００は、クライアント・アプリケーション・プログラム３０２のためのスマート・ホスト・コンテナを称することができ、かつスクリーン値（スクリーン・エレメント８０２の、図８参照）を解析すること及びメモリ・モジュール２１０における値（データ・オブジェクト８００）の表示を更新することを受け持つことができる。

図３を再び参照すると、フレームワーク２０６はまた、ある種のサービスがコンポーネント４００、４０２（もし使用されていれば定義４０４、４０６‐図４参照）の一部として含まれていないか、あるいはコンポーネント・アプリケーション・プログラム３０２の一部としての個別のコンポーネント（図示せず）として受け取られなり場合には、クライアント・アプリケーション・プログラム３０２にフレームワーク・サービス３０４（標準の組のジェネリックサービス）を提供する。アプリケーション・プログラム３０２は、
実行環境３００を伴うコミュニケーション２１４を有しており、それで必要に応じて、フレームワーク・サービス３０４とのコミュニケーション２１６を調整することができる。フレームワーク２０６のフレームワーク・サービス３０４は、デバイス・インフラストラクチャー２０４とのコネクション２２０を介してのコミュニケーションを調整する。従って、デバイス・インフラストラクチャー２０４、ユーザー・インタフェース２０２及びネットワーク・インタフェース２００に対するアクセスが、フレームワーク２０６及び関連サービス３０４によって、クライアント・アプリケーション・プログラム３０２に与えられる。デバイス・インフラストラクチャー２０４（図２参照）のオペレーテイング・システムは、フレームワーク・サービス３０４の実行環境３００及び選択されたサービス／マネージャを表わしうることが分かる。

図３及び８を参照すると、フレームワーク・サービス３０４は、コミュニケーション・マネージャ３０６、プレゼンテーション・マネージャ３０８、データ・マネージャ３１０を含むが、それらに限定されるものではなく、またアクセス・サービス、提供サービス及び実用サービスを含む。アクセス・サービス（図示せず）は、コミュニケーション・デバイス１００上に存在する他のソフトウエア・アプリケーションにアプリケーション・プログラム３０２アクセスを提供する。提供サービス(図示せず)は、コミュニケーション・デバイス１００でのソフトウエア・アプリケーション３０２の提供を管理する。アプリケ
ーション提供は、新規の及び更新されたプリケーション・プログラム３０２を要請しかつ受け取ること、ネットワーク１０４を介してアクセス可能なサービスへのアクセスのためのアプリケーション・プログラム３０２を構成すること、アプリケーション・プログラム３０２及びサービス３０２の構成を修正すること、アプリケーション・プログラム３０２及びサービスを削除することを含むことができる。実用サービス（図示せず）は、種々のフォーマットの変換においてデータ操作を行うような種々の一般的なタスクを達成するために用いられる。

図３、８及び９を参照すると、コミュニケーション・マネージャ３０６は、アプリケーション３０２のためにウエブ・サービス１０６に関して（コミュニケーション・マネージャ３０６によって）送信され／受信されるメッセージ１０５及び関連データ３０６のようなアプリケーション・プログラム３０２と外部システム１０との間の接続性を管理する。下記にさらに説明されるように、コミュニケーション・マネージャ３０６は、一連のマッピング８０４を実行するために用いることができる。プレゼンテーション・マネージャ３０８は、ユーザー・インタフェース２０２（図２参照）の出力デバイスに出力されるときに、アプリケーション・プログラム３０２のリプレゼンテーションを管理する。データ・マネージャ３１０は、コンポーネント・アプリケーション・プログラム３０２が、デバイス・インフラストラクチャー２０４（図２参照）のメモリ・モジュール２１０にデータを格納できるようにする。データ・マネージャ３１０は、マッピング８０４を介してスクリーン・コンポーネント４０２にリンクされたデータ・コンポーネント４００のデータ事例の修正／生成を調整するために用いることができる。フレームワーク２０６は、各データ・オブジェクト８００とスクリーン・エレメント８０２の間の個々の関係（マッピング）を追跡するマッピング・マネージャ３１２をも有している。マッピングは、マッピング・マネージャ３１２に連結されたマッピング・テーブル３０９に格納される。スクリーン・エレメント８０２がユーザー・インタフェース２０２で初期化されると、プレゼンテーション・マネージャ３０８が、スクリーン・エレメント８０２と表示された対応するデータ・オブジェクト８００との間に動的な一体性を維持するために、theマッピング・マネージャ３１２を用いる。スクリーン・エレメント８０２の１つが、ユーザー・インタフェースを介してユーザーによって修正された場合には、マッピング・マネージャ３１２が、メモリ２１０における正しいデータ・オブジェクト８００に対する変化を、データ・マネージャ３１０を通じて伝搬させるようにする。メモリ２１０内のデータ・オブジェクト８００のうちの１つが修正された場合には、マッピング・マネージャ３１２は、オブジェクト８００がユーザー・インタフェース２０２に現在表示されているかどうかを見るためにチェックし、もし表示されていれば、プレゼンテーション・マネージャ３０８を通じて、対応するスクリーン・エレメント８０２を更新させて、テーブル４０９における対応マッピング８０４のエントリを参照することによって、データ・オブジェクト８００の変化を反映させるひょうにする。コミュニケーション・デバイス１００のフレームワーク・サービス３０４が、上述したマネージャを含む機能性をコンポーネント・アプリケーション・プログラム３０２に提供することが分かる。

従って、フレームワーク２０６が、通常アプリケーション３０２ドメインからの情報を提示するユーザー・インタフェース２０２における対話型アプリケーション３０２の表示を可能にするとともに、ユーザーが関連したデータ・オブジェクト８００及びスクリーン・エレメント８０２を入力しかつ修正できるようにする。フレームワーク２０６は、アプリケーション・データ・ドメイン（データ・オブジェクト８００）とＵＩスクリーン・エレメント８０２（例えば、ＵＩコントロール）との間での直接マッピング８００を実行することによって、ユーザー・インタフェース２０２の効果的な管理のためのシステムを提供する。アプリケーション・ドメイン・データ・オブジェクト８００の変化が、ユーザー・インタフェース２０２と自動的に同期化され、かつユーザー入力データが、アプリケーション・ドメイン・データ・オブジェクト８００に自動的に反映される。この同期化の背後における主要なメカニズムは、対をなすスクリーン・エレメント８０２及びデータ・オブジェクト８００の間のマッピング８０４である。このマッピング・システムは、ＸＭＬのような構造化言語で表現されたメタデータを用いて定義されたワイヤレス・アプリケーション３０２に関係する。このマッピング８０４メカニズムは、ユーザー・インタフェース２０２上での動的で対話型のスクリーンの生成を可能にする。データ・オブジェクト８００に対する全ての変化が、ユーザー・インタフェース上に同期的に反映されることができ、またその逆もありうる。このマッピング８０４の実行が、サーバー対デバイス通知に基づいたワイヤレス・アプリケーション３０２の構築を容易にする。サーバー（ウエブ・サービス１０６）から非同期的にプッシュされるデータ・オブジェクト８００更新は、リンクされたＵＩスクリーン・エレメント８０２によってユーザー・インタフェース２０２上に非同期的に反映される。これらのマッピング８００は、株式取引、ニュース更新、警報、天気予報更新等の種々のワイヤレス・アプリケーション３０２に適用可能である。

アプリケーション・コンポーネント
図２を参照すると、クライアント・アプリケーション・プログラム３０２が、フレームワーク２０６のターミナル・ランタイム環境内で実行され、そしてサービス１０６（図１参照）へのアクセスをサポートする。ＷＳＤＬ及びＳＯＡＰプロトコル定義が、メッセージ／データ・パターンを明確に示す。ＷＳＤＬウエブ・サービス定義では、ウエブ・サービスクライアント・アプリケーション・プログラム３０２を関連データ４００とメッセ
ージ４０４コンポーネントの１つの組として（図４参照）定義するために使用できるメッセージとデータ部分の概念を用いて、動作が定義される。

図４を参照すると、コンポーネント・アプリケーション・プログラム３０２のブロック図は、データ・コンポーネント４００と、プレゼンテーション・コンポーネント４０２を含んでいる。アプリケーション３０２の他のメッセージ／ワークフロー部分４０５は、実行環境３００を有するコミュニケーション２１４を介してワークフロー・コンポーネント４０６によって調整されるメッセージ・コンポーネント４０４によって提供されることができるが、アプリケーション３０２のハード・コードされたエレメント４０５（アプリケーション・デベロッパーによって定義された）として提供されることもできる。各エレ
メントが１つ又はそれより多い値を有しうるように１つのリソースの固有の属性を表す多数の予め定義されたエレメントよりなる一連のメタデータ・レコードとしてコンポーネント４００、４０２（及びもし使用されていれば４０４）を構成するために、構造化定義言語を用いることができる。各メタデータスキーマは、通常、限定された数のエレメント
、各エレメントのネーム、及び各エレメントの意味のような、しかしそれらに限定されない定義された特徴を有する。例示メタデータ・スキーマとしては、ダブリン・コア（ＤｕｂｌｉｎＣｏｒｅ (ＤＣ)）、アングロ・アメリカン・カタロギング・ルールズ（Ａｎｇｌｏ−Ａｍｅｒｉｃａｎ Ｃａｔａｌｏｇｉｎｇ Ｒｕｌｅｓ (ＡＡＣＲ2)）、ガバメント・インフォーメイション・ロケータ・サービス（Ｇｏｖｅｒｎｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｌｏｃａｔｏｒ Ｓｅｒｖｉｃｅ(ＧＩＬＳ)）、エンコーデッド・アーカイブス・デイスクリプション（Ｅｎｃｏｄｅｄ Ａｒｃｈｉｖｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ
(ＥＡＤ)）、アイエムエス・グローバル・ラーニング・コンソーテイウム（ＩＭ Ｇｌｏｂａｌ Ｌｅａｒｎｉｎｇ Ｃｏｎｓｏｒｔｉｕｍ (ＩＭＳ)）、及びオーストラリアン・ガバメント・ロケータ・サービス（Ａｕｓｔｒａｌｉａｎ Ｇｏｖｅｒｎｍｅｎｔ Ｌｏｃａｔｏｒ Ｓｅｒｖｉｃｅ (ＡＧＬＳ)）等があるが、それらに限定されない。コード化構文は、コンポーネント４００、４０２（及びもし使用されていれば、４０４）のメタデータをデバイス・インフラストラクチャー２０４（図２参照）によって処理できるようにし、コード化スキームとしては、ＸＭＬ、ＨＴＭＬ、ＸＨＴＭＬ、ＸＳＭＬ、ＲＤＦ、マシーン・リーダブル・カタロギング（Ｍａｃｈｉｎｅ Ｒｅａｄａｂｌｅ Ｃａｔａｌｏｇｉｎｇ (ＭＡＲＣ)）、及びマルチパーパス・インターネット・メール・エクステンションズ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎｓ (ＭＩＭＥ)）等があるが、それらに限定されない。

図4及び８を参照すると、データ・コンポーネント４００が、例えばネイテイブ・コー
ド又はＸＭＬで表されたアプリケーション・データを含むコンポーネント・アプリケーション・プログラム３０２によって使用さｓれるデータ・オブジェクト８００を定義する。

データ・コンポーネント４００が記述しうるデータ・オブジェクト８００の例は、オー
ダー、ユーザー、及び金融取引である。データ・コンポーネント４００は、データ・オブジェクト８００を記述するためにどのような情報が必要とされるか、およびその情報がどのようなフォーマットで表現されるかを定義する。例えば、データ・コンポーネント４
００は、番号としてフォーマット化されたオーダーに対する固有の識別子、文字列としれフォーマット化されたアイテムのリスト、日付・時刻フォーマットを有するオーダーが生成された時刻、文字列としてフォーマット化されたオーダーの状況、データ・コンポーネント４００の他の１つの定義に従ってフォーマット化されたオーダーを入れたユーザーで構成されたオーダーを定義するが、それに限定はされない。データ部分（エレメント）は通常、ウエブ・サービスの１０６の振り付けルールに従ってメッセージ１０５からメッセージ１０５へと転送されるので、データ・オブジェクト８００の持続が存在することが好ましい。データ・オブジェクト８００は、ウエブ・サービスの１０６の振り付けルール定義（もしあれば）に従って動的に生成されてもよく、あるいは複合型定義及び／又はメッセージ相互関係情報に基づいてアプリケーション設計者によって定義されてもよい。後述するように、スクリーン・コンポーネント４０２は、マッピング８０４を介して、データ・コンポーネント４００（図９参照）にリンクされうることが分かる。

さらに、データ・コンポーネント４００は、ＨＴＭＬ、ＸＨＴＭＬ、ＸＭＬおよび構造か定義言語のような、しかしそれに限定されない言語で書かれた一連のデータ・フィールド定義で構成されることができ、データ・オブジェクト８００（図９参照）は、データ・フィールド定義に従ったデータ事例である。データ・オブジェクト定義が、データ・フィールドの構造の定義及びそれらの対応するデータ形式を提供し、データ・オブジェクト８００は、特定のデータ・オブジェクト定義の事例である。データ・フィールドは、データ・オブジェクト定義よりなり、かつすべてのデータ・フィールドは、関連するデータ形式を有する。さらに、複合データ・フィールドは、サブ・データ・フィールドの構造を含む。データ・オブジェクト８００の定義は、アプリケーション３０２のデータ・コンポーネント４００スキーマに含まれる。これらの定義が、アプリケーション３０２によって使用されるようなデータ・オブジェクト８００を定義するためのデータ・モデルを提供する。従って、データ・コンポーネント４００は、データ・オブジェクト８００として例示化された場合に対応するデータ・フィールド値のフォーマットを定義するためにグループ分けされた１つの組の１つまたはそれより多いデータ・フィールド定義である。データ・コンポーネント４００定義は、基本キー又は複合キーを有していてもよく、あるいは必要に応じてキーを伴いことなしに定義されてもよい。これらのキーは、1対のマップ化されたデ
ータ４００とスクリーン４０２コンポーネントとの間に固有のリンクを提供するために、マッピング８０４と一緒に使用されうる。

図４を再び参照すると、プレゼンテーション／スクリーン・コンポーネント４０２は、ユーザー・インタフェース２０２によって表示された場合のアプリケーション・プログラム３０２の外観と動作を定義する。プレゼンテーション・コンポーネント４０２は、ＧＵＩスクリーン及びコントロール、そしてを特定することができ、かつユーザーがユーザー・インタフェース２０２を用いてコンポーネント・アプリケーション３０２と対話する場合に実行されるべき動作を特定することができる。例えば、プレゼンテーション・コンポーネント４０２は、スクリーン、ラベル、エデイット・ボックス、ボタン及びメニュー、及びユーザーがエデイット・ボックスにタイプする場合又はボタンを押す場合行われるべき動作を定義しうる。ウエブ・サービス需要者の大部分が、ウエブ・サービス動作結果の視覚的プレゼンテーションを使用し、従って、ユーザー・インタフェース・スクリーンを表示することができる、それらのデバイス１００上にランタイム環境を提供する。

スクリーン・コンポーネント４０２にパラメータを送る例示アプリケーション３０２と、その送られたパラメータを受け取るスクリーン・コンポーネント４０２について、下記に例示する。
下記の事項、
・データ・コンポーネント４００「ユーザー」
・選択されたユーザーの詳細を表示するためのボタン／メニュー・アイテムと一緒にてのユーザーの選択ボックスを列挙するスクリーン・コンポーネント４０２「ｓｃｒＡｌｌユーザー」
・パラメータとして送られたユーザーに対する詳細を表示するスクリーン・コンポーネント４０２「ｓｃｒＵｓｅｒＩｎｆｏ」
を有するアプリケーションについて検討する。

例示ＸＭＬデータ・コンポーネント４００
基本キー・フィール「ネーム」を有するデータ・コンポーネント４００「ユーザー」は、下記のメタデータを用いて定義することができる:

例示ＸＭＬプレゼンテーション コンポーネント４０２
「scrAllUsers」スクリーンは、ユーザー・データ・コンポーネント４００の全ての事
例の「ネーム」フィールドにマップされた選択コントロール「ｃｂＮａｍｅｓ」を定義することができる。スクリーン メタデータ定義は、ユーザー・インタフェース２０２に対
するパラメーターとして選択され、送られるパラメーター「ユーザー」を有するデイスプレイ・スクリーン「scrUserInfo」に対する動作とともにボタン又はメニュー・アイテム
を含む。

スクリーン「scrUserInfo」は、パラメーターとして送られる固有の事例の「ネーム」
フィールドに対してマップされたエデイット・コントロール「ｅｂＮａｍｅ」を定義する:

図４を再び参照すると、他のメッセージ及びアプリケーション３０２の他のワークフロー部分１０５が、ハードコードされたハードコードされたアプリケーション３０２エレメントによって提供されことができ、及び／又は構造化定義言語及びコード／スクリプトでそれぞれ記述された他のコンポーネント４０４、４０６として提供されることができる。アトミック・メッセージ・コンポーネント４０４を用いる場合には、これらは、ウエブ・サービス１０６のような外部システムとコミュニケートするためのコンポーネント・アプリケーション・プログラム３０２によって使用されるメッセージ１０５のフォーマットを定義し、かつ例えばネイテイブ・コード又はＸＭＬで表示されたメッセージ・データを含む。例えば、メッセージ・コンポーネント４０４の１つは、オーダーのための固有の識別子を含むオーダーを入れるためのメッセージ、そのオーダーの状況、及びそのオーダーに関連するノートを記述できるが、それらに限定されない。構造化定義言語で書かれたメッセージ・コンポーネント４０４定義が、ＷＳＤＬメッセージ（及びそれに対するマッピング）を固有に表示することができ、かつランタイムで動的に生成されうる。従って、例えばＷＳＤＬ及びＢＰＥＬのような、しかしそれらに限定されないウエブ・サービス・インタフェースを表現するために用いられる定義言語での標準的なウエブ・サービス・メタデータから、クライアント・アプリケーション・メッセージ１０５に対するコンポーネント及び関連するデータ内容の動的生成が行われうる。ウエブ・サービス・メッセージ１０５は、動作の範囲内で定義され、かつコンポーネント・アプリケーション・プログラム３０２定義のメッセージコンポーネント４０４の間の交互関係が定義される。この相互関係
は、さらに後述するように、予め定義されたメッセージ・パラメーターを用いて及び／又は個別のワークフロー・コンポーネント４０６を通じて行われうる。

図４を再び参照すると、コンポーネント・アプリケーション・プログラム３０２のアトッミク・ワークフロー・コンポーネント４０６を用いる場合には、これらが、上述したようにプレゼンテーション・コンポーネント４０２によって特定された動作のような動作、あるいはシステム１０からメッセージ１０５（図１参照）が到着するときに行われるべき動作が行われるべき場合に生ずる処理を定義する。プレゼンテーション・ワークフロー及びメッセージ１０５処理は、ワークフロー・コンポーネント４０６によって定義されうる。ワークフロー・コンポーネント４０６は、プログラミング言語で又はＥＣＭＡＳｃｒｉｐｔのような、しかしそれに限定されないスクリプト言語で書かれ、そして上述のように、ネイテイブ・コードに編集され、実行環境３００によって実行されうる。ワークフロー・コンポーネント４０６の一例は、データに値を割り当てること、スクリーンを操作すること、あるいはメッセージ１０５を送ることでありうる。ワークフロー・コンポーネント４０６は、メッセージ１０５の間の相関関係をサポートし、かつアプリケーション・フローを他のコンポーネント４００、４０２、４０４における動作のために１つの組のルールとして定義する。

一般に、ＥＣＭＡ(Ｅｕｒｏｐｅａｎ Ｃｏｍｐｕｔｅｒ Ｍａｎｕｆａｃｔｕｒｅｒ
ｓ Association)スクリプトは、標準のスクリプト言語であり、この場合ん、スクリプトは、コンピュータ・プロセッサによってではなくて他のプログラムによって解釈されるかあるいは実行される命令のシーケンスと呼ばれうる。スクリプト言語の幾つかの他の例は、Ｐｅｒｌ、Ｒｅｘｘ、ＶＢＳｃｒｉｐｔ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、及びＴｃｌ／Ｔｋである。一般に、スクリプト言語は、デバイス１００のような既存のシステムの機能を操作し、カストマイズし、そして自動化するために用いられる命令言語である。このようなシステムでは、有用な機能性がユーザー・インタフェース２０２（図２参照）を通じて既に利用可能であり、かつスクリプト言語は、その機能性をプログラム・コントロールに顕在化させるための機構である。このようにして、デバイス１００は、オブジェクトのホスト・ランタイム環境及びスクリプト言語の能力を完成する機能を提供すると言われている。

コンポーネント・ベース・アプリケーション３０２に対する例示コンポーネント４０４、４０６は、下記のようでありうる：

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

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

ＸＭＬ又はそれの派生語を用いてデータ４００、メッセージ４００４、プレゼンテーション４０２コンポーネントを表現すること及びＥＣＭＡスクリプト言語又はそれのサブセットを用いてワークフロー・コンポーネント４０６を表現することは、アプリケーション・デベロッパーに任意固有のプラットフォーム又は環境からウエブ・サービス・クライアントを抽出することができるようにし、かつ原理的に「一度作成すれば、どこでも動く」アプリケーション（'ｄｅｖｅｌｏｐ ｏｎｃｅ ｒｕｎ ｅｖｅｒｙｗｈｅｒｅ'ａｐｐｌｉｃａｔｉｏｎｓ）を実行できるようにさせる。下記の例は、ウエブ・サービス・クライアント・アプリケーション・プログラムＸＭＬのような、しかしそれに限定されない構造化定義言語及びＥＣＭＡＳｃｒｉｐｔ定義コンポーネントのような、しかしそれに限定されないプラットフォーム・ニュートラル・スクリプト／プログラミング言語を用いてどのようにして表現できるかを示している。

さらに、図４を参照すると、上述のように、メッセージ・コンポーネント４０４が、メッセージ１０５の入力及び出力のための所要データを中継することができることが分かる。対応するデータ・コンポーネント４００が、プレゼンテーション・コンポーネント４０２によるユーザー・インタフェース２０２（図２参照）における爾後のプレゼンテーションに対するデバイス１００のメモリ・モジュール２１０（図２参照）におけるデータの格納を調整する。ワークフロー・コンポーネント４０６は、データ４００、プレゼンテーション４０２、及びメッセージ４０４コンポーネント間のデータの転送を調整する。クライアント・ランタイムは、アトミック・データ・オブジェクト８００を直接格納しかつ更新することができる。
コンポーネント・ベース・アプリケーションの例示基本動作
マッピング８０４を処理の詳細な動作について、図９、１０、及び１１を参照して下記に説明することに注目すべきである。

例えば、図１、３及び６を参照すると、動作６００は、デバイス１００がメッセージ・データを含むレスポンス・メッセージ１０５を受信６０２するときに、該当ワークフロー・コンポーネント４０６が該当メッセージ・コンポーネント４０４に従ってメッセージ１０５のデータ内容を解釈する６０４ことを示している。次に、ワークフロー・コンポーネント４０６がデータ内容を処理６０６し、そしてメモリ・モジュール２１０（図２参照）に爾後に格納６１２するために、そのデータを対応するデータ・コンポーネント４００内に挿入９１０する。さらに、必要であれば、ワークフロー・コンポーネント４０６はまた、ユーザー・インタフェース２０２（図２参照）における爾後の表示６１４のために該当プレゼンテーション・コンポーネント４０２にデータを挿入６０８する。

図１、３及び７を参照すると、動作７００は、ユーザーがユーザー・インタフェース２０２（図２参照）を通じてユーザー・インタフェース・エレメントに対して実行７０２したボタンを押したりあるいはメニュー・アイテムを選択したりするような動作のための入力７０２を示している。該当ワークフロー・コンポーネント４０６が、該当プレゼンテーション・コンポーネント４０４に従って入力データを解釈７０４し、そして該当データ・コンポーネント４００によって定義されたデータ・エンテイテイを生成７０６する。次に、ワークフローコンポーネント４０６が、メモリ・モジュール２１０（図２参照）に爾
後に格納７１２するためにユーザーによって提供される入力データをデータ・コンポーネント４００に投入７１０する。さらに、ワークフロー・コンポーネント４０６はまた、メッセージ・コンポーネント４０４によって定義されるように、メッセージ１０５におけるウエブ・サービスに対するデータ・エンテイテイのような入力データを爾後に送る７１４ために入力データを該当メッセージ・コンポーネント４０４に挿入７０８する。

上記の動作では、ワークフロー４０６及びメッセージ４０４コンポーネントの動作が、アプリケーション３０２のハードコードされた部分４０５として含まれている場合には、それに対応して異なった動作となるであろうことが分かる。
予め定義された動的なスクリーン生成
ワイヤレス・アプリケーション３０２は、スクリーン・エレメント８０２及びデータ・オブジェクト８００の予め定義された組を有していてもよく、その場合、これらの組の間の関係は、データ・コンポーネント４００及びスクリーン・コンポーネント４０４のフィールド定義におけるアプリケーション設計フェーズで確認される。このモデルは、予め定義されたスクリーン及びデータ関係モデルと呼ぶことができ、ユーザーに提示されるスクリーン・エレメント８０２とデータ・オブジェクトとの間のマッピング８０４が、ＸＭＬ
のような構造化言語を用いてコンポーネント・フィールド定義においてメタデータで表
現できるようになされる。

ユーザー・インタフェース２０２のスクリーンはまた、スクリーン・エレメント８０２に関連したデータ・オブジェクト８００の構造に基づいて動的に生成できる。 ある状況
では、メッセージ１０５（図１参照）を介してサーバー（ウエブ・サービス１０６）から入力として受信されたデータ・ストリームのフォーマットは、前もって予想することはできない（例えば、ウエブ・サービス１０６動作が任意のＸＭＬを戻す）。受信されたデータ・ストリームが構造化されたフォーマット（例えばＸＭＬ）で提示される場合には、デバイス１００が、データ・ストリームによって表示されたデータ・オブジェクト８００を提示するために、スクリーン・フォーマット（例えば、ＵＩコントロール、レイアウト等）で、定義された翻訳ルールを用いてフレームワーク２０６によって知的予想を行うことができる。これは、データ・ストリームにおいてＸＭＬ（例えば）ノードで動作して対応するデータ・コンポーネント４００を構築することによって行うことができ、その対応するデータ・コンポーネント４００が次にマッピング・マネージャ３１２（図８参照）によって解釈され、フレームワーク２０６によって最も良く決定されたマップされたスクリーン・コンポーネント４０２を介して対応するスクリーン・エレメント８０２を割り当てて、変換されデータ・ストリームのデータ・コンテンツを処理する。ＸＭＬコンテンツのためのスキーマは、そのスキーマに基づいたデータ・ストリームをマッピング・マネージャ３１２及び翻訳ルールのデベロッパーによって良く理解されるコンポーネント定義フォーマットに翻訳するために、ワイヤレス・アプリケーション３０２及びルールの開発時に予め定義される。翻訳ルールは、マッピング・マネージャ３１２の一部分であり、最も普通に出会うＸＭＬ（例えば）構造化データ・ストリーム・コンテンツを翻訳するように設計されるであろう。さらに、ユーザーは、ＵＩフィールドを、それがデバイス１００に格納されるか又はサーバーに送り戻される前に、更新しかつそのデータを修正する機会を持つことができる。

下記の例は、ＸＭＬスキーマの任意のＸＭＬデータ・ストリーム・フラグメントを示している：

マッピング・マネージャ３１２は、データ・フィールド定義を含むアプリケーション・デベロッパーによって提供されるスキーマ定義を用いる：

そして翻訳ルールを動的に適用して、ＸＭＬデータ・ストリームをアプリケーション許容フォーマット（提供されるスキーマにつき）に変換し、そして適格なＸＭＬデータ・オブジェクト４００を生成する：

ユーザー・インタフェースにおけるデータ・オブジェクトのプレゼンテーション
ユーザー・インタフェース２０２のスクリーンが描画されると、マップされたスクリーン・エレメント８０２に対して表示されるデータ・オブジェクト８００は分解される必要がある。初期値に対して用いられるべき特定のデータ・オブジェクト８００を分解するための異なるオプションは下記のとおりである:

スクリーン・パラメーターに基づいた初期化
通常、データ・コンポーネント４００のデータ・オブジェクト８００が、マップされたスクリーン・エレメント８０２の値とともに、パラメーターとして、ユーザー・インタフェース２０２のスクリーンに送られる。上記の例示スクリーン・コンポーネント４０４では、スクリーン‘ｓｃｒＵｓｅｒＩｎｆｏ’が、パラメーターとして、ユーザーのデータ・オブジェクト８００を受信した。ユーザー・データ・コンポーネント４００のデータ・フィールド定義４００に対してマップされた、このスクリーン上のスクリーン・エレメント８０２は、このパラメーターからデータ値を表示するであろう。

分解されていない初期値
スクリーンに対してマッピング８０４が定義されるが、関連データ・コンポーネント４００の初期データ・オブジェクト８００が分解されていない場合には、マップされたスクリーン・エレメント８０２に対しては初期データ値は表示されない。これの一例は、新しいユーザーに対するデータ値を入力するために定義されたスクリーンであろう。初期ユーザー・データ・コンポーネント４００は適切ではないだろう。ユーザーがスクリーン・エレメント８０２のデータ・フィールドに新しい値を入れた後で、ユーザー・データ更新に関して後述するように、このデータ・コンポーネント４００の当たらしデータ・オブジェクト８００を生成するために、マッピング定義が用いられる。

すべてのデータ・オブジェクトのリスト
スクリーン・エレメント８２０の選択コントロール／リスト・タイプに対して、マッピング８０４は、上記の例示スクリーン・コンポーネント４０４で示されたように、すべての生成されたデータ・オブジェクトが使用されるべきことを指定することができる。
スクリーン・プレゼンテーション
図３、８、及び９を参照すると、このシナリオ８５０は、新しいスクリーンがユーザー・インタフェース２０２上に描かれた場合にスクリーン・エレメント８２０に対して実行されるステップを記述する。ステップ８５２で、マッピング・マネージャ３１２が、データ・コンポーネント４００フィールドにマップされたスクリーン・エレメント８０２を検知する。ステップ８５４で、このタイプのデータ・オブジェクト８００が、スクリーンに付着されたかどうか、すなわち、パラメーターとして送られたかどうかを、マッピング・マネージャ３１２がチェックする。もし肯定（ｙｅｓ）であれば、マッピング・マネージャが、ステップ８５８で、データ・オブジェクト８００のデータ・フィールド値を取り出し、そしてそれをプレゼンテーション・マネージャ３０８に送って、スクリーン上に表示させる。もし否定（ｎｏ）であれば、フィールド・タイプに対するデフォルト値が、ステップ８５６で、スクリーン２０２上に表示される（例えば、スクリーンは空白、数は０、のように）。
データの更新に対するコントロール
図３及び８を参照すると、マッピング８０４メタデータに基づいて、ユーザーが入力する値が、メモリ２１０の該当データ・オブジェクト８００のフィールド値に反映される。このプロセスは下記の機能性を含む：
・入力検証
・データ作成
・データ更新

入力検証
ユーザーが入力したデータの検証は、データｃｍｐ（例えば、電話番）に基づいて自動的に行われうるであろう。

データ作成
新しいデータ・キー値に遭遇した場合には、入力値に基づいて、新しいデータ・オブジェクト８００が作成される。上記の例示データ・コンポーネント４００では、前に定義されていないネームが入力された場合には、新しいユーザー・データ・オブジェクト８００が作成される。

データ更新
既存のデータ・コンポーネント４００に対するデータ・オブジェクト８００のフィールド値が、ユーザー・インタフェース２０２に対してユーザーが入力した結果として、更新されうる。

更新動作
２方向更新モデルが２つのモードで作用すであろう：
・自動コミット（Ａｕｔｏｍａｔｉｃ ｃｏｍｍｉｔ）
ユーザーがスクリーンを離れると、データがコミットされる（ｃｏｍｉｔｔｅｄ）。
・管理されたトランザクション・モード（Ｍａｎａｇｅｄ ｔｒａｎｓａｃｔｉｏｎ ｍｏｄｅ）
特定のメニュー動作（スクリーン・エレメント８０２）がデータを処理するためにマッピングされる。例えば、マルチプル・オーダー・スクリーンの場合には、最後のスクリーン上の「サブミット」（‘ｓｕｂｍｉｔ’）メニュー・アイテムが、得られたデータ・オブジェクト８００を更新／作成するであろう。他のメニュー・アイテム（例えば、「キャンセル」（‘ｃａｎｃｅｌ’）は、入力されたデータを廃棄することになるであろう。

図３、８及び１０を参照すると、下記のシナリオが、ユーザー・インタフェース２０２におけるマッピング・ユーザー入力データ(ユーザー事象)の、データ・オブジェクト８００内へのフロー（流れ）を記述する。ステップ８７２において、ユーザーがスクリーン・エレメント８０２でデータを入力／更新すると、ＵＩマネージャ３０８が、その値をマッピング・マネージャ３１２に送る。ステップ８７４において、もしこれがマップされた
スクリーン・エレメント８０２であれば、マッピング・マネージャ３１２が、該当データ・コンポーネント４００を分解し、データ・マネージャ３１０からのデータ・オブジェクト８００を要請する。ステップ８７６において、データ・コンポーネント４００のフィールド・タイプに合致したスクリーン・エレメント８０２に対して入力された値に、このスクリーン・エレメント８０２がマッピングされることを、データ・マネージャ３１２が検証する。ステップ８７８において、データ・マネージャ３１０が、修正されたデータ値を一時的記憶器内に、付託されていない「汚い」データとして保持する。データ・マネージャはまた、これが既存のデータ・オブジェクト８００の更新であるか、あるいは新しいデータ・オブジェクトの作成であるかを判定する。ステップ８８０において、ユーザー事象が、コミットされた（ｃｏｍｉｔｔｅｄ）（オプションＡ）又はアボーテッド（ａｂｏｒｔｅｄ）（オプションＢ）として認定される。

コミットされた判定の場合：
オプションＡ：コミット、
１)ユーザーがコミット・アクションにマップされたボタン又はメニュー・アイテムを選
択する；
２)ＵＩマネージャ３０８が、アクションについてマッピング・マネージャ３１２に通知
する；
３）マッピング・マネージャ３１２がデータ・マネージャ３１０に変化をコミットするように要請する；
４）データ・マネージャ ３１０が、変化をコミットし、そしてデータ・オブジェクト８
００をメモリ２１０に格納する。
アボートされた認定の場合：オプションＢ ロールバック、
１）ユーザーが、コミット・アクションに対してマップされていないボタン又はメニュー・アイテム（スクリーン・エレメント８０２）を選択することによって、スクリーンを離れることを選ぶ；
２）ＵＩマネージャ３０８が、アクションについてマッピング・マネージャ３１２に通知する；
３）マッピング・マネージャ３１２が、変化をロールバックするようにデータ・マネージャ３１０に要請する；
４）データ・マネージャ３１２が変化を廃棄する−これは、個々のフィールドに対する変化だけを廃棄すること意味するか、あるいは、スクリーン・コンポーネント４０２対データ・コンポーネント４００マッピング８０４の結果として新しい変化が生成された場合には、全データ・オブジェクト８００を除去することを意味する。

更新をコントロールするためのデータ
デバイス１００が外部ソース（例えば、ウエブ・サービス１０６）データ更新を非同期的に受信できる場合には、クリーン・エレメント８０２に関連したデータ値の変化が、新しい情報を有するスクリーン・リフレッシュを生ずるであろう。図３、８、及び１１を参照すると、メッセージ・マネージャ３１２は、サーバー１０６からメッセージ１０５を受信９５２すると、このメッセージ１０５がフレームワーク２０６における現在実行しているアプリケーション３０２のデータ・コンポーネント４００に対してマップされるかどうかを認定９５４する。もしそうである場合には、下記の他のステップが行われる：ステップ９５６、デバイス・フレームワーク２０６が、データ変更についてのサーバー１０６からの通知を受け取る；ステップ９５８、メッセージ・マネージャ３０６が、データ・オブジェクト８００に対して任意の該当するデータ更新を行うようにデータ・マネージャ３１０に通知する；ステップ９６０、メッセージ・マネージャ３０６はまた、データ変更をマッピング・マネージャ３１２に通知する；ステップ９６２、マッピング８０４メタデータを用いて、データ変更が現在のスクリーンに該当するかどうかを、マッピング・マネージャ３１２が検証する；ステップ９６４、変更が現在表示されている情報に関係していれば、マッピング・マネージャ３１２が、スクリーンをリフレッシュするように、ＵＩマネージャ３０８に要請する；そしてステップ９６６、スクリーンが、更新されたデータ・オブジェクト８００を表示するようにリフレッシュされる。そうでないと、ステップ９６８では、メッセージ１０５は、ユーザー・インタフェース２０２に表示されるスクリーン・エレメント８０２の現在値に影響しない。

本明細書での開示は１つまたは複数の例示的なシステムと方法について記述したものであるが、この分野に精通した人には、多くの変更が明らかとなるであろうし、そのような変更は本願の範囲内にある。例えば、ＸＭＬ及びＥＣＭＡＳｃｒｉｐｔのサブセット実施例で用いられたが、コンポーネント・アプリケーション３０２を定義するためには、他の言語及び言語変形を用いてもよい。さらに、上述したマッピング８０４に対する代替として、データ・フィールドの定義をスクリーン・コンポーネント４０２（図４参照）に含ませてもよいことが分かる。従って、スクリーン・エレメント８０２の生成は、スクリーン・コンポーネント４０２定義に含まれたデータ・フィールド定義に基づくことになり、そしてデータ・コンポーネント４００が、データ・フィールド定義を含んだ対応するスクリーン・コンポーネント４０２に対してマップされるであろう。従って、データ・オブジェクト８００の生成は、マップされたスクリーン・コンポーネント４０２に含まれたデータ・フィールド定義に依存するであろう。

１０ ネットワーク・システム
１００ ワイヤレス・デバイス
１０２ ワイヤレス・ネットワーク
１０４ 広域ネットワーク
１０５ リクエスト／レスポンス・メッセージ
１０６ ウエブ・サービス
１１０ アプリケーション・サービス

Claims (1)

1. 明細書に記載の発明。

Images