JP4589113B2 - ミドルウェア・アプリケーション・メッセージ／イベント・モデル - Google Patents

Description

本発明は一般に無線遠隔通信の分野に関し、より詳細には、例えば無線遠隔通信システムの移動端末中のアプリケーション・ソフトウェアとプラットフォームのソフトウェア・サービス・コンポーネントとの間など、第１と第２のソフトウェア・コンポーネント間でメッセージを送受信するためのシステムおよび方法に関する。

１９８０年代にセルラー遠隔通信システムが初めて導入されて以来、システム中で利用される移動端末（移動局）は、ますます複雑になってきている。当初、移動端末は主に音声電話サービスの提供、すなわち音声通信の送受信のために設計されていた。後年になって、音声電話通話のユーザ・データとは関係のないユーザ・データを転送する能力をも備える移動端末が開発された。このようなユーザ・データには、例えば、パーソナル・コンピュータ（ＰＣ）によって開始されたダイヤルアップ・ネットワーキング接続を介して転送されるデータが含まれる。

将来の移動遠隔通信システムに向けて、現在、いわゆる「第３世代」（３Ｇ）システムが開発されている。３Ｇシステムは、高速インターネット・アクセスを従来の音声通信と組み合わせ、音声通信に加えてインターネット閲覧、ストリーミング・オーディオ／ビデオ、測位、ビデオ会議、およびその他多くの機能へのアクセスをユーザに提供することになる。

世界中で開発されている複数の３Ｇシステム間での互換性を保証するために、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）が設立された。音声、データ、マルチメディアを世界中どこでも送達することのできる地上および衛星システムを含む３Ｇシステムを提供するために、３ＧＰＰによってユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）が開発されている。

３ＧＰＰ標準化によってセルラー遠隔通信システムに備わりつつある機能の激増は、システム中で使用されることになる移動端末の開発者に対してかなりの要求を課してきた。この要求は、移動端末がサイズ、メモリ、電力に限りのある「リソース不十分な」環境であるということによって悪化する。

従来、移動端末の製造業者は、市場のニーズに対する彼らの認識に基づいて、基本的な端末操作に必要なすべてのハードウェアおよびソフトウェア、ならびに製造業者または特定ユーザによって望まれる特徴および機能を提供するのに必要なハードウェアおよびソフトウェアを備えた、ほぼ完全な移動端末システムを設計し、製作し、市場に出してきた。このような手法は、市場の需要の変化に素早く適応するための柔軟性、または複数の出資者の多様な要件を満たすための柔軟性をもたらさない。

移動端末の設計および製作における従来手順の欠点を認識して、複数のユーザに対して１つのユニットとして市場に出すことのできる機能的に補完する複数のソフトウェア・ユニットおよびハードウェア・ユニットを備えた、移動端末プラットフォーム・アセンブリが開発された。この場合、各ユーザは、ユーザ自身のアプリケーション・ソフトウェアをアセンブリにインストールし、ロードし、実行して、ユーザ自身の特定のニーズを満たす個別仕様の移動端末用プラットフォーム・システムを提供することができる。この移動端末プラットフォーム・アセンブリおよびプラットフォーム・システムは、本願の譲受人に譲渡される米国特許出願第１０／３５９９１１号および１０／３５９８３５号に詳細に記載されており、この開示内容は参照により本明細書に組み込れ、本願の内容をなすものである。

前述のようなプラットフォーム・システムでは、移動端末プラットフォーム・アセンブリ・ソフトウェアとアプリケーション・ソフトウェアとが別々に開発され、その後、アプリケーション・ソフトウェアが移動端末プラットフォーム・アセンブリ中でインストールされロードされ実行されることによって結合されるが、このようなプラットフォーム・システムでは、サービス要求から発生した結果メッセージ（イベント情報の送達を含む場合もある）が、プラットフォーム・アセンブリ中のソフトウェアからプラットフォーム・アセンブリ中のインターフェースを介してアプリケーションに送られる必要がある。このようなメッセージは、スタック／プロシージャベースの手法（すなわちコールバック・モード）と直列ベースの手法（すなわち完全メッセージ・モード）のどちらかを使用して送ることができる。

コールバック・モードは、アプリケーションがアプリケーション特有の機能に的を絞り、基本的および複雑な機構関係の処理はプラットフォームまたはフレームワークに任せることができるようにする、単純で十分に立証された技法である。ソフトウェア開発者は、メッセージを結果のハンドラ（関数／プロシージャ／メソッド）に直接にルーティングすることが可能である。例えば、開発者／ユーザは、例えばウィンドウ・マネージャがユーザ対話イベント情報またはメッセージ情報を保持するメッセージを明確に定義されたハンドラに渡した場合に、ユーザ・インターフェース・アプリケーションを開始することができる。ユーザ・コードの呼出しは、完全にウィンドウ・マネージャによって決定される。開発者は付加価値機能へのアクセスまたは付加価値機能の利用が可能だが、ユーザからはメッセージ・ループおよびメッセージ開放は見えない。したがって、開発者は、様々なメッセージをプログラムの専用部分にルーティングする必要はなく、また開発者は、システムのグレードを下げることはできない。このため、コールバック・モードでは、アプリケーション・コードは、あるメッセージをいつどの順序で処理するかについて制御を持たない。状況によっては、アプリケーションは、メッセージの処理順序または特定のメッセージを処理する時を制御する必要がある場合もある（すなわち優先処理）。

したがって、完全メッセージ・モードとして示す別の技法を、コールバック・モードの代替として利用することができる。完全メッセージ・モードは、例えばアプリケーション・スレッドにおいて、メッセージをキューに入れる。次いで、キューに入れられたメッセージは、アプリケーションによる処理を待機する。キューに入れられたメッセージは、ＦＩＦＯ技法などで順番に処理することもでき、あるいは並列または優先順に処理することもできる。この場合、アプリケーション・コードは、メッセージ・ループの完全な制御を有する。

ＰａｌｍＯＳやＢｒｅｗの環境に組み込まれているものなど現在の解決法では、ユーザは、コールバック・モードと完全メッセージ・モードのどちらかを使用することができるが、ユーザまたはアプリケーション・ソフトウェアは、着呼メッセージを受け取る際のモードを自由に選択することができない。コールバック・モードまたは完全メッセージ・モードがアプリケーションに対してあらかじめ決まっている。
米国特許出願第１０／３５９９１１号 米国特許出願第１０／３５９８３５号 米国特許出願第１０／３５９７７２号

したがって、コールバック・モードと完全メッセージ・モードのどちらかでメッセージを受け取る選択をユーザ（アプリケーション・ソフトウェア）に提供するメッセージ・モデルが必要とされている。ユーザは、どちらのメッセージ・モードが問題に最も適合するかを、個々の場合ごとに選択することができる。

本発明の一実施形態では、製品のプラットフォーム領域とアプリケーション領域の間でメッセージを伝送するためのシステムは、ソフトウェア・コンポーネントとインターフェース・コンポーネントとを有するプラットフォーム領域を備える。インターフェース・コンポーネントは、ソフトウェア・コンポーネントへのアクセスをアプリケーション領域中のアプリケーションまたはモジュールに提供するための少なくとも１つのインターフェースと、このインターフェースを介してプラットフォーム領域とアプリケーション領域の間でメッセージを伝送するためのメッセージ伝送機構とを有する。メッセージ伝送機構は、アプリケーション領域中のアプリケーションまたは別のモジュールがプラットフォーム領域からメッセージを受け取るためにコールバック・モードと完全メッセージ・モードの間で選択または切替えができるようにするためのメッセージ・モデルを備える。メッセージ伝送モデルは、選択されたモードに従ってメッセージングをルーティングするためのメッセージ・ハンドラも備える。

本発明の別の実施形態では、プラットフォーム領域がソフトウェア・コンポーネントとインターフェース・コンポーネントとを有し、インターフェース・コンポーネントは、ソフトウェア・コンポーネントへのアクセスをアプリケーション領域中のアプリケーションまたはモジュールに提供するための少なくとも１つのインターフェースを有する。アプリケーション領域とプラットフォーム領域の間でメッセージを伝送する方法は、アプリケーション領域中のアプリケーションまたは別のモジュールがコールバック・モードと完全メッセージ・モードとのどちらかを選択するか、あるいはコールバック・モードと完全メッセージ・モードの間で切り替えることを含む。これらのモードは、プラットフォーム領域からメッセージを受け取るためのモードである。メッセージ・ハンドラが、選択されたモードに従ってメッセージングをルーティングする。

第１と第２のソフトウェア・コンポーネント間でメッセージを伝送するためのメッセージ伝送機構は、第１と第２のソフトウェア・コンポーネントのうちの一方がコールバック・モードと完全メッセージ・モードのどちらかを選択することができるように、またはコールバック・モードと完全メッセージ・モードの間で切り替えることができるようにする、メッセージ・モデルを備える。これらのモードは、第１と第２のソフトウェア・コンポーネント間でメッセージを受け取るためのモードである。この機構は、選択されたモードに従ってメッセージングをルーティングするためのメッセージ・ハンドラも備える。

本発明のこれ以上の利点および具体的詳細は、図面と共に以下に提供する詳細な記述から、下記において明らかになるであろう。

図１は、本発明の原理の説明を助けるための、無線遠隔通信システムの移動端末用のプラットフォーム・システムを概略的に示すブロック図である。このプラットフォーム・システムは参照番号１０で一般に示されており、移動端末プラットフォーム・アセンブリ１２と、移動端末プラットフォーム・アセンブリ中でインストールされロードされ実行された１つまたは複数のアプリケーション（すなわちアプリケーション・ソフトウェア）１４とを備える。プラットフォーム・システム１０は、破線１６で一般に示す移動端末に組み込まれるように適合されている。

移動端末プラットフォーム・アセンブリ１２は、ソフトウェア・サービス・コンポーネント２２、ハードウェア・コンポーネント２４、インターフェース・コンポーネント２６を備える。ソフトウェア・サービス・コンポーネント２２は、インターフェース・コンポーネント２６を介してユーザに提供されるサービスを提供するための、適切に構造化された複数の機能ソフトウェア・ユニットを含む。ユーザには、プラットフォーム・ユーザ（例えば電話機の製造業者）およびエンド・ユーザ（例えば電話機のユーザ）が含まれる。図１に示す例示的なシステムでは、複数のソフトウェア・ユニットには、垂直に配向された複数の機能ソフトウェア・スタック３０〜３８が含まれる。

ハードウェア・コンポーネント２４はハードウェア・ユニットのセットを含み、これらのハードウェア・ユニットは、それぞれの機能ソフトウェア・スタックに関連し、それぞれの機能ソフトウェア・スタックによって制御される。図１に示す例示的なシステムでは、ハードウェア・ユニットは、ソフトウェア・スタック３０〜３８に関連する種々のハードウェア・ブロック４０〜４８である。

インターフェース・コンポーネント２６は、移動端末プラットフォーム・アセンブリ１２中で１つまたは複数のアプリケーションをインストールしロードし実行するための少なくとも１つのアプリケーション・プログラミング・インターフェース（ＡＰＩ）を備えるミドルウェア・サービス・レイヤを含み、このミドルウェア・サービス・レイヤは、移動端末プラットフォーム・アセンブリ１２を使用するアプリケーションから移動端末プラットフォーム・アセンブリ１２を隔離し、また、その他の様々なサービスをアプリケーション１４に提供する。ミドルウェア・サービス・レイヤの具体的な詳細については後述する。

移動端末プラットフォーム・アセンブリ１２は、後でプラットフォーム・システム１０の機能を拡張するために、アプリケーション・ソフトウェア１４とは別個の完全な閉鎖型ユニットとして設計、実装（組立）、テストされるよう適合されている（本明細書で使用する用語「アプリケーション・ソフトウェア」は、ユーザが利用可能にしたいと思う機能を提供する任意のソフトウェアとすることができる）。したがって、移動端末の製造業者、および開発能力を有するその他の関係者は、独自のアプリケーション・ソフトウェアを開発するかまたは他の方法で獲得することができ、このソフトウェアを後で移動端末プラットフォーム・アセンブリ１２に追加して、プラットフォーム・システム１０を個別仕様にすることができる。したがって、移動端末プラットフォーム・アセンブリ１２を複数の異なるユーザに販売するかまたは他の方法で譲渡することができ、各ユーザは、プラットフォーム・システムに対するユーザ自身の特定の要件を満たすために、ユーザ自身のアプリケーション・ソフトウェアをアセンブリ中でインストールしロードし実行することによって、プラットフォーム・システム１０を個別仕様にすることができる。

図２は、本発明の原理の理解をさらに助けるための、図１の移動端末プラットフォーム・システム１２の展開図の一例を概略的に示すブロック図である。図２に示すように、移動端末プラットフォーム・アセンブリ１２は、メインＣＰＵ５０中で実行されるソフトウェアを介して制御される。メインＣＰＵ５０は、マイクロプロセッサ、マイクロ・プログラマブル・プロセッサ、ＤＳＰ（デジタル信号プロセッサ）など、１つまたは複数のプロセッサを含むことができる。ソフトウェア・サービス・コンポーネント２２のソフトウェア・スタック３０〜３８はそれぞれ、各スタックに関連するハードウェア・ユニットを操作するためのハードウェア・ドライバ・ソフトウェア６０〜６８を備える。移動端末プラットフォーム・アセンブリ１２およびプラットフォーム・システム１０に関するこれ以上の詳細は、前述の本願の譲受人に譲渡される米国特許出願第１０／３５９８３５号に提供されている。

移動端末プラットフォーム・アセンブリ１２に組み込まれるソフトウェアは、より容易に設計でき、より容易にアップグレードできるかまたは他の方法で修正できるように、ソフトウェア組織を理解しやすくするようにして構成されることが好ましい。図３は、本発明の原理の説明をさらに助けるための、移動端末プラットフォーム・アセンブリ１２のソフトウェア・アーキテクチャを概略的に示すブロック図である。

図３に示すように、ソフトウェア・サービス・コンポーネント２２は、前述のように複数の垂直な機能ソフトウェア・スタックに構成されるのに加えて、複数の水平レイヤを定義するようにも構成され、それにより、ミドルウェア・サービス・レイヤのソフトウェアとソフトウェア・サービス・コンポーネント２２のソフトウェアは共に、参照番号７０で一般に示される階層型アーキテクチャを定義する。この階層型アーキテクチャ中では、レイヤは、より高レベルのサービス・レイヤからより低レベルのサービス・レイヤへと降順で構成される。

このソフトウェア・アーキテクチャは、垂直区分化された複数のソフトウェア・レイヤを補完する水平区分化された複数の機能ソフトウェア・ユニットを含むという点で、標準ＩＳＯ／ＯＳＩ（ＩＳＯオープン・システムズ・インターコネクション）モデルとは異なる。水平区分化は、独立したモジュール式（サービス）コンポーネントを生み出すのに大きく寄与する。

階層型アーキテクチャの最上レイヤは、ミドルウェア・サービス・レイヤである。ソフトウェア・サービス・コンポーネント２２のレイヤは、アプリケーション・サービスを提供するためのアプリケーション・サーバ・レイヤ８０と、アプリケーションにプラットフォーム特有サービスを提供するためのプラットフォーム・サービス・レイヤ８２と、セッション・プロトコルおよびアプリケーション特有プロトコルを提供するためのプラットフォーム・プロトコル・レイヤ８４と、オーディオ・アクセス／制御やデータコム・トランスポート・プロトコルやメッセージング・トランスポート・プロトコルなどを提供するためのトランスポート・レイヤ８６と、外部データＩＦアクセスや構造化記憶サービスやその他の低レベルのプラットフォーム・サポート・サービスを提供するためのデータ・アクセス・レイヤ８８と、ハードウェア依存性をカプセル化する論理ドライバ・レイヤ９０および物理ドライバ・レイヤ９２とを含む。さらに、ソフトウェア・サービス・コンポーネント２２は、プラットフォーム・アセンブリによって必要とされる一般的なサービスを提供する基本システム・サービス・レイヤ９４も含む。

下の２つのレイヤ９０および９２は、ソフトウェアとハードウェアとの間の依存性を隔離するハードウェア抽象化レイヤ（ＨＡＬ）を構成する。物理ドライバ・レイヤだけが、ハードウェアの詳細（すなわち、ＡＳＩＣハードウェア中のどのレジスタがアドレス指定されるか）に関係がある。論理ドライバ・レイヤ９０は、ハードウェアへの論理マッピングを提供する。すなわち、このレイヤは、移動端末プラットフォーム・アセンブリ１２のハードウェア部分とソフトウェア部分の間のブリッジを提供する。

ソフトウェア自体は複数のソフトウェア・モジュールに構成され、図３では、モジュール１０２、１０４、１０６が具体的に示されている。ソフトウェア・サービス・コンポーネント２２中で、単一のモジュールは、１つの垂直機能スタック中だけで、そのスタック内の１つの水平レイヤだけに存在することができる。各レイヤは、１つのモジュールから多くのモジュールまでを含むことができ、特定スタック中の特定レイヤにあるすべてのモジュールは、同じ抽象化レベルを有する。様々なモジュール間の通信は、ソフトウェア・モジュール間アクセスに関する基本規則のセットに従うソフトウェア・バックプレーン（ＳｗＢＰ）１１２を介して達成される。これらの規則は、以下のように要約することができる。

− ソフトウェア・モジュールは、それ自体のレイヤよりも下にあるすべてのレイヤ・インターフェース中の機能を呼び出すことができる。

− 直列化されたデータ・フローの方向に制限はない。これらはどの方向に行くこともできる。

− ソフトウェア・モジュールは、それ自体のレイヤよりも上にあるレイヤ・インターフェース中（ＳｗＢＰ１１２中）の機能を、そのレイヤの属するモジュールから独立して呼び出すことはできない。

− ソフトウェア・モジュールは、同じ垂直スタック中のそれ自体のレイヤにあるレイヤ・インターフェース中の機能を呼び出すことができる。

− ソフトウェア・モジュールは、別の垂直スタック中の同じレイヤにあるソフトウェア・モジュール中の機能を呼び出すことができる（この機能は、垂直スタック中のレイヤの数を制限するために許可される）。

ＳｗＢＰ１１２中の様々なモジュールおよびインターフェースの間には、ハード結合はない。この結果、インターフェースに対するクライアントにどんな影響も及ぼさずに、モジュールおよび／またはインターフェース実装を自由に変更することができる。これは、プラットフォーム・アセンブリ中の他のモジュールに影響を及ぼさずに個々のモジュールを追加、削除、または変更することを可能にするので、重要な機能である。

移動端末プラットフォーム・アセンブリ内のモジュール間の内部通信を可能にするＳｗＢＰソフトウェア構造を含めた階層型アーキテクチャに関するこれ以上の詳細は、前述の本願の譲受人に譲渡される米国特許出願第１０／３５９９１１号に記載されている。

ミドルウェア・サービス・レイヤは、移動端末プラットフォーム・アセンブリ１２中のソフトウェアと、プラットフォーム・アセンブリ中でインストールされロードされ実行されることになるアプリケーション・ソフトウェア１４との間に、明確に定義されたインターフェースを提供するように機能する。さらに、ミドルウェア・サービス・レイヤは、移動端末プラットフォーム・アセンブリ１２をカプセル化し、ミドルウェア・サービス・レイヤを介してアセンブリをアプリケーション１４から隔離し、その他の様々なサービスをアプリケーション１４に提供する。

図４は、ミドルウェア・サービス・レイヤの詳細を概略的に示すブロック図である。図４に示すように、ミドルウェア・サービス・レイヤは、非ネイティブ環境、例えばＪａｖａ（登録商標）実行（Ｊａｖａ（登録商標） Ｅｘｅ）環境ＡＰＩ領域２０２、オープン・アプリケーション・フレームワーク（ＯＡＦ）ＡＰＩ領域２０４、オープン・プラットフォームＡＰＩ（ＯＰＡ）領域２０６、ＵＩツールキットＡＰＩ領域２０８を含めた、複数のＡＰＩ領域を備える。

ミドルウェア・サービス・レイヤ中のＡＰＩを介して、移動端末プラットフォーム・アセンブリ１２は複数のアプリケーション環境をサポートする。図４では、ミドルウェア・サービス・レイヤは、ネイティブ・アプリケーション（すなわち特定のプロセッサおよびその命令セットと共に実行されるようにコンパイルされたアプリケーション）と、非ネイティブ・アプリケーション（例えばＪａｖａ（登録商標） Ｊ２ＭＥ ＣＬＤＣ／ＭＩＤＰ（Ｊａｖａ（登録商標）２ Ｍｉｃｒｏ Ｅｄｉｔｉｏｎ Ｃｏｎｎｅｃｔｅｄ Ｌｉｍｉｔｅｄ Ｄｅｖｉｃｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ／Ｍｏｂｉｌｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｄｅｖｉｃｅ Ｐｒｏｆｉｌｅ）アプリケーションなど）のための環境をサポートする。各アプリケーション環境は、独自の特徴を有し、以下のように定義される。

− アプリケーションの開発方法（プログラミング言語サポート、コンパイル、リンケージ）
− アプリケーションの実行方法（例えば解釈やネイティブ・コード実行）
− 提供される機能サービス
− 使用時に課される可能性のある制限
複数の代替アプリケーション環境を提供することにより、コスト、使い易さ、市場に出す時期、機能セット、サイズ、可搬性などについて異なる要求を有する幅広い製品が促進される。

ミドルウェア・サービス・レイヤに関するこれ以上の詳細は、本願の譲受人に譲渡される米国特許出願第１０／３５９７７２号に記載されており、この開示内容は参照により本明細書に組み込れ、本願の内容をなすものである。

図５は、本発明の原理による、オープン・プラットフォーム（ＯＰＡ）領域２０６の主要なソフトウェア・モジュールを概略的に示すブロック図である。図示のように、ＯＰＡ領域２０６は５つのモジュールを含む。すなわち、ネイティブ環境管理（ＮＥＭ）モジュール２３０、ネイティブ・アプリケーション・コア（ＮＡＣ）モジュール２３２、ＯＰＡインターフェースおよびハンドラ・モジュール２３４、ミドルウェア・サポート・サービス・モジュール２３６、ネイティブ拡張プラグイン・モジュール２３８である。ネイティブ環境管理モジュール２３０は、プラットフォーム・システム１０中のネイティブ・アプリケーションを制御することを担い、アプリケーション・マネージャからのネイティブ・アプリケーションに関する制御コマンドの受領側であり、システム中で現在実行されているネイティブ・アプリケーションを常に把握している。ミドルウェア・サポート・サービス・モジュール２３６は、例えばオブジェクト管理やリソース監視など、様々なハンドラに共通のサービス、または集中化させる必要のあるサービスをＯＰＡ領域に提供する。

ネイティブ拡張プラグイン・モジュール２３８は、ＯＰＡインターフェースおよびハンドラ・モジュール２３４を介した、プラットフォーム・アセンブリ機能のオプション拡張と見なすことができる。ＮＥプラグイン・モジュール２３８は、ＯＰＡインターフェースおよびハンドラ・モジュール２３４を統治するのと同じ、およびＯＰＡインターフェースおよびハンドラ・モジュール２３４に適用されるのと同じガイドライン、パラダイム、機構に従う。ＯＰＡネイティブ拡張プラグイン・モジュール２３８は、ＯＰＡインターフェースおよびハンドラ・モジュール２３４を介してプラットフォーム機能にアクセスする。

ネイティブ・アプリケーション・コア・モジュール２３２は、通常ならアプリケーション自体が対処しなければならないスレッディングおよびメッセージ処理の複雑性を管理および処理する。また、メッセージ・ルーティング／フィルタリングおよびメッセージ関連リソース処理を含めたランタイム複雑性からアプリケーションを解放するために、ＯＳの実装詳細を隠蔽することによってＯＳの独立性を達成する目的にも役立つ。ネイティブ・アプリケーション・コア・モジュール２３２の主要な任務の１つは、アプリケーション１４の起動およびシャットダウンの段階の詳細と、メッセージ処理における詳細を隠蔽することである。

図６に、本発明の原理による、アプリケーション１４がコールバック・モードと完全メッセージ・モードのどちらかを利用してプラットフォーム・アセンブリ１２のソフトウェア・サービス・コンポーネント２２からミドルウェア・サービス・レイヤを介してメッセージを受け取ることに関係するコンポーネントおよびシグナリングを示す。メッセージ・モデル２５０は、アプリケーション１４がその現在の動作および状況にとって何が最も有益であるかに応じてコールバック・モード２５２と完全メッセージ・モード２５４の間で選択できるようにする。アプリケーション１４が所望のモードに入ると、メッセージ・モデル２５０は、選択されたモードすなわちコールバック・モードまたは完全メッセージ・モード２５４に関連するシグナリング規約を開始する。ＮＡＣモジュール２３２は、選択されたモードがわかっており、必要なシグナリング規約に従ってメッセージを処理する。

アプリケーション１４がコールバック・モード２５２に入ることを選択した場合は、ＮＡＣモジュール２３２は、メッセージをＯＰＡインターフェースおよびハンドラ・モジュール２３４中の適切なハンドラに向け、次いでこのハンドラは、メッセージをコールバック・モードに従ってフォーマットする。コールバック・モード２５２では、ソフトウェア開発者は、一般関数や専用関数など、関数／プロシージャ／メソッド中で直接に結果を受け取ることが可能である。コールバック・モード２５２に入るのは、アプリケーション１４がコールバックの実行後に実行制御をミドルウェア・サービス・レイヤに返すときである。アプリケーション１４が制御をミドルウェア・サービス・レイヤに返した後は、他のコールバック関数をトリガすることが可能である。ただし、コールバック関数の実行中は、アプリケーション１４は他のメッセージを完全メッセージ・モード２５４を使用して処理することができる。

アプリケーション１４が完全メッセージ・モード２５４に入ることを選択した場合は、ＮＡＣモジュール２３２は、メッセージを完全メッセージ・モード２５４に従って適切なアプリケーション・メッセージ・キューに向ける。ソフトウェア開発者はこの場合、メッセージ・ループの完全な制御を有する。完全メッセージ・モード２５４はデフォルト・モードであり、アプリケーション１４がそれ自体のスレッドを制御しているときにアクティブである。この場合、アプリケーション１４は、いつでもミドルウェア・サービス・レイヤへの明示的な要求によってメッセージ・キューをポーリングすることを選択することができる。完全メッセージ・モード２５４でメッセージを受け取るために、いくつかのオプションが利用可能である。例えば、ユーザまたはソフトウェア開発者は、任意選択でタイムアウト付きで、メッセージが利用可能になるまで呼出しスレッドがブロックされるよう要求することを選択することもでき、あるいは、スレッドをブロックせず、メッセージがあるかどうかチェックすることを選択することもできる。また、フィルタ・パラメータを使用することもでき、それにより、重要度の低いメッセージは後で処理されるようフィルタアウトして、何らかの順番でメッセージに応答するのを可能にすることができる。完全メッセージ・モード２５４では、アプリケーション・コードがメッセージの解放を担う。したがって、状況によっては、アプリケーション１４は、受け取ったメッセージを解放して再び割り振る必要なしに別のアプリケーション１４に転送することを選択することができ、これにより性能が向上する。

完全メッセージ・モード２５４からコールバック・モード２５２に切り替えるとき、ソフトウェア開発者は、ミドルウェア・サービス・レイヤのソフトウェアが適切なコールバック関数を呼び出すことができるようにする。さらに、アプリケーション１４は、コールバック・モード２５２と完全メッセージ・モード２５４の間でいつでも、リアルタイムでも変更することができる。したがって、アプリケーション１４は、個々の問題に最も適合するメッセージ受領モードをいつでも選択することができる。コールバック・モード２５２と完全メッセージ・モード２５４は、アプリケーション・ソフトウェア領域のソフトウェア・エンティティのどんな組合せにおいても共存することができる。

図７は、本発明の原理による、完全メッセージ・モードまたはコールバック・モードの呼出しを示す流れ図である。ステップ３００で、アプリケーション１４は、システムが起動されてから初めてその主要スレッドに対する制御を得る。ステップ３０２で示すように、アプリケーション１４は、ミドルウェア・サービス・レイヤからのメッセージを待機すると決定するまで、この制御を維持する。次いでアプリケーション１４は、メッセージをコールバック・モードで待機するか完全メッセージ・モードで待機するかの決定３０４を行う。決定がコールバック・モードであった場合は、アプリケーション１４はリターン文を実行し、これにより、３１６で示すようにアプリケーション・スレッドの制御はＮＡＣモジュール２３２に移る。次いでＮＡＣモジュール２３２は、３１８で示すように、メッセージが存在するかどうかこのスレッドのメッセージ・キューをポーリングする。ＮＡＣモジュール２３２は、メッセージが見つかるまでキューをポーリングし続け、メッセージが見つかると、３２０で示すようにキューからメッセージを取得し、３１４で示すようにメッセージをコールバック・フォーマットに変換し、前にアプリケーション１４によって指定されたコールバック・メソッドを呼び出してメッセージを処理する。これによりループは終了し、アプリケーション１４は、３０４で示すように、コールバック・モードに入るか完全メッセージ・モードに入るかの決定を再び行うことができる。

完全メッセージ・モードが選択された場合は、アプリケーション１４は、３０６で示すように、ブロッキング・モードに入るか非ブロッキング・モードに入るかを決定しなければならない。アプリケーション１４は、ミドルウェア・サービス・レイヤ中のＯＰＡインターフェースおよびハンドラ・モジュール２３４にメッセージを要求することによってこれを行う。要求のタイプはまた、要求が非ブロッキングであるべきかブロッキングであるべきかも指示する。非ブロッキング要求が発行された場合は、要求は、３０８で示すようにアプリケーション・スレッドの制御をＮＡＣモジュール２３２に移す。次いでＮＡＣモジュール２３２は、要求の明細に従って、メッセージが存在するかどうかこのスレッドのメッセージ・キューをポーリングする（３１０）。合致するメッセージが見つかった場合は、このメッセージをメッセージ・キューから取り除き（３１２）、アプリケーション１４に返す。メッセージが見つからなかった場合は、ＮＡＣモジュール２３２は、どんなメッセージも渡さずにスレッドの制御をアプリケーション１４に返す。これによりループは終了し、アプリケーション１４は再び、３０４で示すように、コールバック・モードに入るか完全メッセージ・モードに入るかの決定を行うことができる。

完全メッセージ・モードが選択された場合は、アプリケーション１４は再び、３０６で示すように、ブロッキング・モードに入るか非ブロッキング・モードに入るかを決定しなければならない。前に非ブロッキング・モードの場合で述べたように、アプリケーション１４は、ミドルウェア・サービス・レイヤ中のＯＰＡインターフェースおよびハンドラ・モジュール２３４にメッセージを要求することによってこれを行う。この場合もやはり、要求のタイプは、要求が非ブロッキングであるべきかブロッキングであるべきかを指示する。ブロッキング要求が発行された場合は、要求は、３２２で示すようにアプリケーション１４のスレッドの制御をＮＡＣに移す。次いでＮＡＣモジュール２３２は、要求の明細に従って、メッセージが存在するかどうかこのスレッドのメッセージ・キューをポーリングする。メッセージが見つからなかった場合は、ＮＡＣモジュール２３２は、メッセージが見つかるまで、または指定されている場合のあるタイムアウト期間を超えるまで、要求されたメッセージがあるかどうかメッセージ・キューをポーリングし続ける（３２４で示す）。合致するメッセージが見つかるとすぐに、このメッセージをメッセージ・キューから取り除き（３１２で示す）、アプリケーション１４に返す。これによりループは終了し、アプリケーション１４は再び、３０４で示すように、コールバック・モードに入るか完全メッセージ・モードに入るかの決定を行うことができる。

以上の記述は本発明の例示的な実施形態を構成するが、本発明はその範囲を逸脱することなく多くの形で変更することができることを理解されたい。例えば、本発明を主に無線遠隔通信システムの移動端末用の特定プラットフォーム・システム中でのメッセージ伝送に関して述べたが、本発明は、移動端末用の他のプラットフォーム中での、および他の製品用のプラットフォーム中でのメッセージ伝送について使用することもできる。本発明は多くの形で変更することができるので、本発明は、添付の特許請求の範囲によって必要とされる範囲内でのみ限定されるべきであると理解されたい。

本発明の原理の説明を助けるための、無線遠隔通信システムの移動端末用のプラットフォーム・システムを概略的に示すブロック図である。 本発明の原理の説明をさらに助けるための、図１のプラットフォーム・システムの移動端末プラットフォーム・アセンブリの展開図を概略的に示すブロック図である。 本発明の原理の説明をさらに助けるための、図１および２の移動端末プラットフォーム・アセンブリのソフトウェア・アーキテクチャを概略的に示すブロック図である。 本発明の原理の説明をさらに助けるための、図１〜３のミドルウェア・サービス・レイヤの詳細を概略的に示すブロック図である。 本発明の原理による、図４のミドルウェア・サービス・レイヤのＯＰＡ領域の詳細を概略的に示すブロック図である。 本発明の原理による、完全メッセージ・モードまたはコールバック・モードを制御する際に利用されるシグナリングおよびコンポーネントを概略的に示すブロック図である。 本発明の原理による、完全メッセージ・モードまたはコールバック・モードの呼出しを示す流れ図である。

Claims (7)

1. 製品のプラットフォーム領域とアプリケーション領域の間でメッセージを伝送するためのシステムであって、
   プロセッサとソフトウェア・コンポーネントとインターフェース・コンポーネントとを有するプラットフォーム領域を備え、前記インターフェース・コンポーネントは、前記ソフトウェア・コンポーネントへのアクセスを前記アプリケーション領域中のアプリケーションまたはモジュールに提供するための少なくとも１つのインターフェースを有し、
   前記プロセッサが前記ソフトウェア・コンポーネントと前記インターフェース・コンポーネントと前記アプリケーションまたはモジュールとを実行することにより、
   前記アプリケーションまたはモジュールが自己の主要スレッドに対して制御を取得し、
   前記アプリケーションまたはモジュールがコールバック・モードまたは完全メッセージ・モードを選択し、
   前記コールバック・モードが選択された場合、前記アプリケーションまたはモジュールが、前記プラットフォーム領域からのメッセージを処理するコールバック関数をメッセージ・ハンドラに対して指定し、リターン文を実行することにより前記制御を前記メッセージ・ハンドラへ移し、前記完全メッセージ・モードが選択された場合、前記アプリケーションまたはモジュールが、前記メッセージ・ハンドラに対して前記メッセージを要求することにより前記制御を前記メッセージ・ハンドラへ移し、
   前記メッセージ・ハンドラがメッセージをポーリングし、
   前記メッセージが発見されると、前記コールバック・モードの場合は、前記メッセージ・ハンドラが、前記メッセージを伴って前記コールバック関数を呼び出すことにより前記制御を前記アプリケーションまたはモジュールへ移し、前記完全メッセージ・モードの場合は、前記メッセージ・ハンドラが、前記要求に対する応答として前記メッセージを前記アプリケーションまたはモジュールへ返すことにより前記制御を前記アプリケーションまたはモジュールへ移す
   ことを特徴とするシステム。
2. 前記メッセージ・ハンドラは前記プラットフォーム領域に含まれることを特徴とする請求項１に記載のシステム。
3. 前記インターフェースはミドルウェア・サービス・レイヤを備え、
   前記メッセージ・ハンドラは、前記ミドルウェア・サービス・レイヤに含まれるルータとして働くネイティブ・アプリケーション・コア・モジュールを備えることを特徴とする請求項２に記載のシステム。
4. 前記ネイティブ・アプリケーション・コア・モジュールは前記ミドルウェア・サービス・レイヤのオープン・プラットフォームＡＰＩ（ＯＰＡ）領域に含まれることを特徴とする請求項３に記載のシステム。
5. 前記プラットフォーム領域は無線遠隔通信システムの移動端末用のプラットフォームを備えることを特徴とする請求項１に記載のシステム。
6. アプリケーション領域とプラットフォーム領域の間でメッセージを伝送する方法であって、前記プラットフォーム領域はソフトウェア・コンポーネントおよびインターフェース・コンポーネントを有し、前記インターフェース・コンポーネントは前記ソフトウェア・コンポーネントへのアクセスを前記アプリケーション領域中のアプリケーションまたはモジュールに提供するための少なくとも１つのインターフェースを有し、前記ソフトウェア・コンポーネントと前記インターフェース・コンポーネントと前記アプリケーションまたはモジュールは、プロセッサによって実行され、前記方法は、
   前記アプリケーションまたはモジュールが自己の主要スレッドに対して制御を取得するステップと、
   前記アプリケーションまたはモジュールがコールバック・モードまたは完全メッセージ・モードを選択するステップと、
   前記コールバック・モードが選択された場合、前記アプリケーションまたはモジュールが、前記プラットフォーム領域からのメッセージを処理するコールバック関数をメッセージ・ハンドラに対して指定し、リターン文を実行することにより前記制御を前記メッセージ・ハンドラへ移し、前記完全メッセージ・モードが選択された場合、前記アプリケーションまたはモジュールが、前記メッセージ・ハンドラに対して前記メッセージを要求することにより前記制御を前記メッセージ・ハンドラへ移すステップと、
   前記メッセージ・ハンドラがメッセージをポーリングするステップと、
   前記メッセージが発見されると、前記コールバック・モードの場合は、前記メッセージ・ハンドラが、前記メッセージを伴って前記コールバック関数を呼び出すことにより前記制御を前記アプリケーションまたはモジュールへ移し、前記完全メッセージ・モードの場合は、前記メッセージ・ハンドラが、前記要求に対する応答として前記メッセージを前記アプリケーションまたはモジュールへ返すことにより前記制御を前記アプリケーションまたはモジュールへ移すステップと、
   を含むことを特徴とする方法。
7. 前記プラットフォーム領域は無線遠隔通信システムの移動端末用のプラットフォームを備えることを特徴とする請求項６に記載の方法。

Images