(57)【要約】【課題】  ネットワークベースの処理システムであって、該システムは、アプリケーションのコンパイル、配備並びに実行を自動化、単純化並びに最適化する。これは、任意の種類のクライアント・マシンにより行われ、該クライアント・マシンは任意の種類のネットワーク接続を介してサーバに接続する。システムは、クライアント・ランタイム環境、サーバ・ランタイム環境並びにオブジェクト指向マークアップ・ビジネス・ロジック・バインディング機構を備える。クライアント・ランタイム環境はクライアント・サイド・コードとスクリーン定義を管理する。サーバ・ランタイム環境は動的にコードをコンパイルし、クライアント・プラットフォームのコンパティビリティを保証する。システムは、ネットワーク・アプリケーションを要求に応じて配信し、これは、ネットワーク・アプリケーションを軽いモジュールに分割するとともにこれらモジュールを配信することにより行われる。【選択図】  図１０
2007524875.tif 000002
【特許請求の範囲】
【請求項１】
複数の入力ファイルを受信するとともに、該複数の入力ファイルのうち任意の入力ファイルを出力ファイルに変換する汎用コンパイラであって、
前記複数の入力ファイルがアプリケーションのソース・コードを備え、
該ソース・コードは、複数の異なるプログラム言語でそれぞれ書かれ、
前記出力ファイルは前記アプリケーションの実行コードを備え、
該実行コードが実行エンジンにより実行可能であることを特徴とする汎用コンパイラ。
【請求項２】
複数の特定のプログラム言語コンパイラを備え、
前記複数の特定のプログラム言語コンパイラそれぞれが、前記複数の入力ファイルから１つの入力ファイルを受信し、
前記複数の入力ファイルは、前記アプリケーションの前記ソース・コードを備え、
該ソース・コードは特定のプログラム言語で書かれ、
更に、前記複数の特定のプログラム言語コンパイラそれぞれが、前記１つの入力ファイルを前記アプリケーションの特定の実行コードに変換し、
該特定の実行コードが特定の実行エンジンにより実行可能とされることを特徴とする請求項１記載の汎用コンパイラ。
【請求項３】
制御ロジックを更に備え、
該制御ロジックは、前記複数の特定のプログラム言語コンパイラから１つの特定のプログラム言語コンパイラを選択することを特徴とする請求項２記載の汎用コンパイラ。
【請求項４】
前記プログラム言語が、Java、JavaScript、C#、C+、C++、Visual Basic、J#、ActionScript、XSL、XQuery及びXPathからなる群から選択されることを特徴とする請求項１記載の汎用コンパイラ。
【請求項５】
前記実行コードが、Java仮想マシン・バイトコードを備え、
前記実行エンジンが、Java仮想マシンを備えることを特徴とする請求項１記載の汎用コンピュータ。
【請求項６】
前記実行コードが、.Net Common Language Runtime（CLR）バイトコードを備え、
前記実行エンジンが、.Net CLRエンジンを備えることを特徴とする請求項１記載の汎用コンパイラ。
【請求項７】
前記実行コードがFlashプレイヤ・バイトコードを備え、
前記実行エンジンが、Flashプレイヤを備えることを特徴とする請求項１記載の汎用コンパイラ。
【請求項８】
複数の入力ファイルを受信するとともに、前記複数の入力ファイルのうち任意の入力ファイルを複数の出力ファイルに変換するコンパイラ・システムであって、
前記複数の入力ファイルが、アプリケーションのソース・コードを備え、
該ソース・コードは、複数の異なるプログラム言語でそれぞれ書かれ、
前記複数の出力ファイルは、前記アプリケーションの複数の実行コードをそれぞれ備え、
前記複数の実行コードが複数の実行エンジンそれぞれにより実行可能であることを特徴とするコンパイラ・システム。
【請求項９】
複数の汎用コンパイラを備え、
各汎用コンパイラは、複数の特定のプログラム言語コンパイラを備え、
前記複数の特定のプログラム言語コンパイラが、前記複数の入力ファイルから１つの入力ファイルを受信し、
該複数の入力ファイルは前記アプリケーションの前記ソース・コードを備え、
該ソース・コードは、特定のプログラム言語で書かれ、
前記複数の特定のプログラム言語コンパイラは、前記入力ファイルを前記アプリケーションの特定の実行コードに変換し、
前記特定の実行コードが特定の実行エンジンにより実行可能であることを特徴とする請求項８記載のコンパイラ・システム。
【請求項１０】
第１制御ロジックを更に備え、
該第１制御ロジックが、前記複数の汎用プログラム言語コンパイラから、１つの汎用プログラム言語コンパイラを選択することを特徴とする請求項９記載のコンパイラ・システム。
【請求項１１】
第２制御ロジックを更に備え、
該第２制御ロジックが、前記複数の実行コードをキャッシュすることを特徴とする請求項９記載のコンパイラ・システム。
【請求項１２】
前記プログラム言語が、Java、JavaScript、C#、C+、C++、Visual Basic、J#、ActionScript、XSL、XQuery及びXPathからなる群から選択されることを特徴とする請求項８記載のコンパイラ・システム。
【請求項１３】
前記実行コードが、Java仮想マシン・バイトコード、.Net CLRバイトコード、Flashプレイヤ・バイトコード、Palm OSバイトコード、Symbian OSバイトコード及びQualcomm Brewバイトコードからなる群から選択され、
前記対応する実行エンジンそれぞれが、Java仮想マシン、.Net CLRエンジン、Flashプレイヤ、Palm OS、Symbian OS、Qualcomm Brewエンジンからなる群から選択されることを特徴とする請求項８記載のコンパイラ・システム。
【請求項１４】
分散処理を実行するコンピュータ・システムであって、
該コンピュータ・システムは、
汎用コンパイラを備えるサーバを備え、
該汎用コンパイラは、複数の入力ファイルを受信するとともに前記複数の入力ファイルのうち任意の入力ファイルを１つの出力ファイルに変換し、
前記複数の入力ファイルは、アプリケーションのソース・コードを備え、
該ソース・コードは、複数のプログラム言語でそれぞれ書かれ、
前記出力ファイルは、前記アプリケーションの実行コードを備え、
更に、少なくとも１つのクライアント・マシンを備え、
該クライアント・マシンは、ネットワークを介して前記サーバと接続するとともに実行エンジンを備え、
該実行エンジンが、前記出力ファイルを前記ネットワーク上で受信するとともに前記実行コードを実行することを特徴とするコンピュータ・システム。
【請求項１５】
分散処理を実行するコンピュータ・システムであって、
該コンピュータ・システムは、
コンパイラ・システムを備えるサーバを備え、
該コンパイラ・システムは、複数の入力ファイルを受信するとともに、前記複数の入力ファイルのうち任意の入力ファイルを複数の出力ファイルに変換し、
前記複数の入力ファイルは、アプリケーションのソース・コードを備え、
該ソース・コードはそれぞれ複数の異なるプログラム言語で書かれ、
前記複数の出力ファイルは、複数の対応する前記アプリケーションの実行コードをそれぞれ備え、
更に、複数のクライアント・マシンを備え、
前記複数のクライアント・マシンのそれぞれが、前記サーバにネットワークを介して接続し、
前記複数のクライアント・マシンのそれぞれが、実行エンジンを備え、
該実行エンジンが、前記出力ファイルのうち１つを受信するとともに、対応する実行コードを実行することを特徴とする分散処理を実行するコンピュータ・システム。
【請求項１６】
複数の入力ファイルを受信するとともに、該複数の入力ファイルのうち任意の入力ファイルを１つの出力ファイルに変換する汎用XMLコンパイラであって、
前記複数の入力ファイルは、複数のマークアップ・ドキュメントを備え、
該マークアップ・ドキュメントは、複数の異なるXML言語で書かれ、
前記出力ファイルは実行コードを備え、
該実行コードが特定の実行エンジンにより実行可能であることを特徴とする汎用XMLコンパイラ。
【請求項１７】
前記XML言語が、XML、XUL、SVG、Xforms、XAML、HTML、XHTML、HTMLに関連する言語及びこれらの組み合わせからなる群から選択されることを特徴とする請求項１６記載の汎用コンパイラ。
【請求項１８】
前記実行コードが、XML言語フォーマットを備え、
前記特定の実行エンジンが、XML実行エンジンを備えることを特徴とする請求項１６記載の汎用コンパイラ。
【請求項１９】
前記実行コードがバイナリ・フォーマットを備え、
前記特定の実行エンジンが、前記バイナリ・フォーマットを実行するエンジンを備えることを特徴とする請求項１６記載の汎用コンパイラ。
【請求項２０】
前記バイナリ・フォーマットが、Java仮想マシン・バイトコード、.Net CLRバイトコード、Flashプレイヤ・バイトコード、Palm OSバイトコード、Symbian OSバイトコード及びQualcomm Brewバイトコードからなる群から選択されることを特徴とする請求項１９記載の汎用コンパイラ。
【請求項２１】
前記特定の実行エンジンが、Java仮想マシン、.Net CLR、Palm OS 、Flashプレイヤ、Symbian OS、Qualcomm Brewからなる群から選択されることを特徴とする請求項２０記載の汎用コンパイラ。
【請求項２２】
ネットワーク・コンピュータ・システム内においてアプリケーションを配備する方法であって、
前記ネットワーク・コンピュータ・システムは、１つのサーバと、１若しくはそれ以上のクライアント・マシンを備え、
該クライアント・マシンのそれぞれが、ネットワーク接続を介して、前記サーバに接続するとともに実行エンジンを備え、
前記方法は、
前記クライアント・マシンのうち１つによる要求を前記サーバに送信し、前記アプリケーションの１若しくはそれ以上のファイルをダウンロードする段階と、
前記サーバにより前記要求を受信するとともに前記クライアント・マシンの実行エンジンを特徴付ける段階と、
前記アプリケーション・コードの前記１若しくはそれ以上のファイルの１若しくはそれ以上の実行コードがそれぞれ、サーバ・ストレージ内で既に利用可能であるか否か検査する段階を備え、
前記１若しくはそれ以上の実行コードが前記クライアント・マシンの実行エンジンにより実行可能であり、
前記１若しくはそれ以上の実行コードが利用可能であるならば、前記１若しくはそれ以上の実行コードを前記クライアント・マシンにダウンロードする段階を備えることを特徴とする方法。
【請求項２３】
クライアント・マシン内のストレージへ前記ダウンロードされた１若しくはそれ以上の実行コードをキャッシュする段階を更に備えることを特徴とする請求項２２記載の方法。
【請求項２４】
前記１若しくはそれ以上の実行コードを前記クライアント・マシン・ストレージからダウンロードする段階を更に備えることを特徴とする請求項２３記載の方法。
【請求項２５】
前記１若しくはそれ以上の実行コードが前記サーバ・ストレージ内で利用可能でない場合、前記アプリケーションの前記１若しくはそれ以上のファイルを前記１若しくはそれ以上の実行コードにそれぞれコンパイルする段階と、
その後、前記１若しくはそれ以上の実行コードを前記クライアント・マシンへダウンロードする段階を備えることを特徴とする請求項２２記載の方法。
【請求項２６】
汎用コンパイラにより１つのアプリケーションの１つのソース・コードをコンパイルする方法であって、
該方法は、
複数の入力ファイルを提供する段階を備え、
該複数の入力ファイルは、前記ソース・コードを備え、
該ソース・コードは、それぞれ複数の異なるプログラム言語で書かれ、
更に、前記複数の入力ファイルを実行コードにコンパイルする段階を備え、
該実行コードが１つの実行エンジンにより実行可能であることを特徴とする方法。
【請求項２７】
前記プログラム言語が、Java、JavaScript、C#、C+、C++、Visual Basic、J#、ActionScript、XSL、XQuery及びXPathからなる群から選択されることを特徴とする請求項２６記載の方法。
【請求項２８】
前記実行コードが、Javaバイトコードを備え、
前記実行エンジンが、Java仮想マシンを備えることを特徴とする請求項２６記載の方法。
【請求項２９】
前記実行コードが、.Net CLRバイトコードを備え、
前記実行エンジンが、.Net CLRエンジンを備えることを特徴とする請求項２６記載の方法。
【請求項３０】
前記実行コードがFlashプレイヤ・バイトコードを備え、
前記実行エンジンが、Flashプレイヤを備えることを特徴とする請求項２６記載の方法。
【請求項３１】
前記汎用コンパイラが、複数の特定のプログラム言語コンパイラを備え、
前記複数の特定のプログラム言語コンパイラそれぞれが、１つの入力ファイルを受信し、
該入力ファイルが、１つの特定のプログラム言語で書かれ、
前記複数の特定のプログラム言語コンパイラそれぞれが、前記入力ファイルを１つの特定の前記アプリケーションの実行コードに変換し、
前記特定の実行コードが１つの特定の実行エンジンにより実行可能であることを特徴とする請求項２６記載の方法。
【請求項３２】
前記汎用コンパイラが更に、制御ロジックを備え、
該制御ロジックは、前記複数の特定のプログラム言語コンパイラから１つの特定のプログラム言語コンパイラを選択することを特徴とする請求項３１記載の方法。
【請求項３３】
コンパイラ・システムにより、アプリケーションのソース・コードをコンパイルする方法であって、
該方法は、
複数の入力ファイルを提供する段階を備え、
該入力ファイルは、前記ソース・コードを備え、
該ソース・コードは複数の異なるプログラム言語でそれぞれ書かれ、
更に、前記複数の入力ファイルを複数の出力ファイルにコンパイルする段階を備え、
前記複数の出力ファイルは、前記ソース・コードの複数の実行コードをそれぞれ備え、
前記実行コードは複数の対応する実行エンジンそれぞれにより実行可能であることを特徴とする方法。
【請求項３４】
前記プログラム言語が、Java、JavaScript、C#、C+、C++、Visual Basic、J#、ActionScript、XSL、XQuery及びXPathからなる群から選択されることを特徴とする請求項３３記載の方法。
【請求項３５】
前記実行コードが、Java仮想マシン・バイトコード、.Net CLRバイトコード、Palm OSバイトコード、Flashプレイヤ・バイトコード、Symbian OSバイトコード及びQualcomm Brewバイトコードからなる群から選択され、
前記対応する実行エンジンが、Java仮想マシン、.Net CLR、Palm OS、Flashプレイヤ、Symbian OS、Qualcomm Brewからなる群から選択されることを特徴とする請求項３３記載の方法。
【請求項３６】
少なくとも１つのマークアップ・ドキュメントと、
該少なくとも１つのマークアップ・ドキュメントに関連する少なくとも１つのビジネス・ロジック要素と、
前記少なくとも１つのマークアップ・ドキュメントを前記少なくとも１つのビジネス・ロジック要素にバインディングする或いはその逆を行うオブジェクト指向バインディング機構からなることを特徴とするコンピュータ・アプリケーション・プログラム。
【請求項３７】
クライアント・ランタイム環境（ＣＲＥ）が前記少なくとも１つのマークアップ・ドキュメントを受信するとともに１つのオブジェクト指向表現へ変換することを特徴とする請求項３６記載のコンピュータ・アプリケーション・プログラム。
【請求項３８】
前記オブジェクト指向表現が、１若しくはそれ以上のマークアップ・オブジェクト、１若しくはそれ以上のユーザ・インターフェース及び１若しくはそれ以上のデータ・セットを備えることを特徴とする請求項３７記載のコンピュータ・アプリケーション・プログラム。
【請求項３９】
前記少なくとも１つのビジネス・ロジック要素が、１つのマークアップ・オブジェクト・イベントに対するイベント・ハンドラとして用いられる１若しくはそれ以上の手段を備えることを特徴とする請求項３８記載のコンピュータ・アプリケーション・プログラム。
【請求項４０】
前記オブジェクト指向バインディング機構が、マークアップ・オブジェクト・イベントを発火させることにより、前記１若しくはそれ以上のマークアップ・オブジェクトによって、前記１若しくはそれ以上の手段を起動することを備えることを特徴とする請求項３８記載のコンピュータ・アプリケーション・プログラム。
【請求項４１】
前記オブジェクト指向バインディング機構が、更に、前記少なくとも１つのビジネス・ロジック要素によって、アプリケーション・プログラム・インターフェース（ＡＰＩ）を介して前記１若しくはそれ以上のマークアップ・オブジェクトにアクセスするとともに変更することを備えることを特徴とする請求項４０記載のコンピュータ・アプリケーション・プログラム。
【請求項４２】
前記ＡＰＩが、マークアップ・オブジェクトＡＰＩとドキュメント・オブジェクト・モデル（ＤＯＭ）ＡＰＩからなる群から選択されることを特徴とする請求項４１記載のコンピュータ・アプリケーション・プログラム。
【請求項４３】
前記１若しくはそれ以上のマークアップ・ドキュメントが、親マークアップ・オブジェクトと子マークアップ・オブジェクトを備え、
該子マークアップ・オブジェクトが１若しくはそれ以上のマークアップ・オブジェクトプロパティを備え、
該マークアップ・オブジェクト・プロパティが、前記親マークアップ・オブジェクトから継承されることを特徴とする請求項３８記載のコンピュータ・アプリケーション・プログラム。
【請求項４４】
前記１若しくはそれ以上のマークアップ・オブジェクト・プロパティが、ユーザ・インターフェース定義、データ・セット定義及びイベント・ハンドラ定義からなる群から選択されることを特徴とする請求項４３記載のコンピュータ・アプリケーション・プログラム。
【請求項４５】
前記親マークアップ・オブジェクトが、１若しくはそれ以上のユーザ・インターフェース定義、１若しくはそれ以上のデータ定義及び１若しくはそれ以上のイベント・ハンドラを備え、
前記子マークアップ・オブジェクトが前記１若しくはそれ以上のユーザ・インターフェース定義、前記１若しくはそれ以上のデータ定義及び前記１若しくはそれ以上のイベント・ハンドラを前記親マークアップ・ドキュメントから継承することを特徴とする請求項４４記載のコンピュータ・アプリケーション・プログラム。
【請求項４６】
前記１若しくはそれ以上のマークアップ・オブジェクトが、親マークアップ・オブジェクトと子マークアップ・オブジェクトを備え、
前記子マークアップ・オブジェクトが、前記親マークアップ・オブジェクトの１若しくはそれ以上のマークアップ・オブジェクト・プロパティを上書きし、
該上書きされたマークアップ・オブジェクト・プロパティを、前記子マークアップ・オブジェクトの１若しくはそれ以上のマークアップ・オブジェクト・プロパティと置換することを特徴とする請求項４３記載のコンピュータ・アプリケーション・プログラム。
【請求項４７】
前記少なくとも１つのマークアップ・ドキュメントが、マークアップ言語で書かれ、
該マークアップ言語は、XML、XUL、SVG、Xforms、XAML、HTML、XHTML、HTMLに関連する言語、テキスト及びこれらの組み合わせからなる群から選択されることを特徴とする請求項３６記載のコンピュータ・アプリケーション・プログラム。
【請求項４８】
前記少なくとも１つのビジネス・ロジック要素が、プログラム言語で書かれ、
該プログラム言語が、Java、JavaScript、J#、C#、C+、C++、Visual Basic、ActionScript、XSL、XQuery及びXPathからなる群から選択されることを特徴とする請求項３６記載のコンピュータ・アプリケーション・プログラム。
【請求項４９】
コンピュータ・アプリケーション・プログラムを開発する方法であって、
少なくとも１つのマークアップ・ドキュメントを提供する段階と、
該少なくとも１つのマークアップ・ドキュメントに関連する少なくとも１つのビジネス・ロジック要素を提供する段階と、
オブジェクト指向バインディング機構を提供する段階を備え、
該オブジェクト指向バインディング機構が前記少なくとも１つのマークアップ・ドキュメントを前記少なくとも１つのビジネス・ロジック要素にバインディングをし、またその逆を行うことを特徴とする方法。
【請求項５０】
前記少なくとも１つのマークアップ・ドキュメントを受信する段階と、
該少なくとも１つのマークアップ・ドキュメントをクライアント・ランタイム環境（ＣＲＥ）によりオブジェクト指向表現に変換する段階を更に備えることを特徴とする請求項４９記載の方法。
【請求項５１】
前記オブジェクト指向表現が、１若しくはそれ以上のマークアップ・オブジェクト、１若しくはそれ以上のユーザ・インターフェース及び１若しくはそれ以上のデータ・セットを備えることを特徴とする請求項５０記載の方法。
【請求項５２】
前記少なくとも１つのビジネス・ロジック要素が、１若しくはそれ以上の手段を備え、
該手段が、マークアップ・オブジェクト・イベントに対するイベント・ハンドラとして用いられることを特徴とする請求項５１記載の方法。
【請求項５３】
前記オブジェクト指向バインディング機構が、マークアップ・オブジェクト・イベントを発火させることにより、前記１若しくはそれ以上のマークアップ・オブジェクトによって、前記１若しくはそれ以上の手段を起動することを備えることを特徴とする請求項５２記載の方法。
【請求項５４】
前記オブジェクト指向バインディング機構が、更に、前記少なくとも１つのビジネス・ロジック要素によって、アプリケーション・プログラム・インターフェース（ＡＰＩ）を介して前記１若しくはそれ以上のマークアップ・オブジェクトにアクセスするとともに変更することを備えることを特徴とする請求項５３記載の方法。
【請求項５５】
前記ＡＰＩが、マークアップ・オブジェクトＡＰＩとドキュメント・オブジェクト・モデル（ＤＯＭ）ＡＰＩからなる群から選択されることを特徴とする請求項５４記載の方法。
【請求項５６】
前記１若しくはそれ以上のマークアップ・ドキュメントが、親マークアップ・オブジェクトと子マークアップ・オブジェクトを備え、
該子マークアップ・オブジェクトが１若しくはそれ以上のマークアップ・オブジェクトプロパティを備え、
該マークアップ・オブジェクト・プロパティが、前記親マークアップ・オブジェクトから継承されることを特徴とする請求項５１記載の方法。
【請求項５７】
前記１若しくはそれ以上のマークアップ・オブジェクト・プロパティが、ユーザ・インターフェース、データ・セット定義及びイベント・ハンドラ定義からなる群から選択されることを特徴とする請求項５６記載の方法。
【請求項５８】
前記親マークアップ・オブジェクトが、１若しくはそれ以上のユーザ・インターフェース定義、１若しくはそれ以上のデータ定義及び１若しくはそれ以上のイベント・ハンドラを備え、
前記子マークアップ・オブジェクトが前記１若しくはそれ以上のユーザ・インターフェース定義、前記１若しくはそれ以上のデータ定義及び前記１若しくはそれ以上のイベント・ハンドラを前記親マークアップ・ドキュメントから継承することを特徴とする請求項５７記載の方法。
【請求項５９】
前記１若しくはそれ以上のマークアップ・オブジェクトが、親マークアップ・オブジェクトと子マークアップ・オブジェクトを備え、
前記子マークアップ・オブジェクトが、前記親マークアップ・オブジェクトの１若しくはそれ以上のマークアップ・オブジェクト・プロパティを上書きし、
該上書きされたマークアップ・オブジェクト・プロパティを、前記子マークアップ・オブジェクトの１若しくはそれ以上のマークアップ・オブジェクト・プロパティと置換することを特徴とする請求項５１記載の方法。
【請求項６０】
前記少なくとも１つのマークアップ・ドキュメントが、マークアップ言語で書かれ、
該マークアップ言語は、XML、XUL、SVG、Xforms、XAML、HTML、XHTML、HTMLに関連する言語、テキスト及びこれらの組み合わせからなる群から選択されることを特徴とする請求項４９記載の方法。
【請求項６１】
前記少なくとも１つのビジネス・ロジック要素が、プログラム言語で書かれ、
該プログラム言語が、Java、JavaScript、J#、C#、C+、C++、Visual Basic、ActionScript、XSL、XQuery及びXPathからなる群から選択されることを特徴とする請求項４９記載の方法。
【請求項６２】
１若しくはそれ以上のモジュールを備えるネットワーク・アプリケーション・プログラムであって、
各モジュールが、少なくとも１つのマークアップ・ドキュメント、該マークアップ・ドキュメントに関連する少なくとも１つのビジネス・ロジック及びオブジェクト指向バインディング機構を備え、
該オブジェクト指向バインディング機構が、前記少なくとも１つのマークアップ・ドキュメントを前記少なくとも１つのビジネス・ロジック要素にバインディングし、またその逆を行うことを特徴とするネットワーク・アプリケーション・プログラム。
【請求項６３】
サーバ・ランタイム環境（ＳＲＥ）とネットワーク・アプリケーション・プログラムを備えるサーバと、
１若しくはそれ以上のクライアント・マシンであって、各クライアント・マシンがクライアント・ランタイム環境（ＣＲＥ）を備えるとともに、ネットワーク接続を介して前記サーバに接続可能なクライアント・マシンを備え、
前記ＳＲＥが前記ネットワーク・アプリケーション・プログラムを前記１若しくはそれ以上のクライアント・マシンに前記ネットワークを介して配備し、
該配備が、
前記ネットワーク・アプリケーションを１若しくはそれ以上のモジュールに分割する段階であって、該各モジュールが少なくとも１つのマークアップ・ドキュメントを備えるようにする段階と、
前記１若しくはそれ以上のモジュールそれぞれを別個に前記１若しくはそれ以上のクライアント・マシンにダウンロードする段階からなることを特徴とするネットワーク・コンピュータ・システム。
【請求項６４】
更に、前記少なくとも１つのマークアップ・ドキュメントに関連する少なくとも１つのビジネス・ロジックと、
オブジェクト指向バインディング機構を備え、
該オブジェクト指向バインディング機構が、前記少なくとも１つのマークアップ・ドキュメントを前記少なくとも１つのビジネス・ロジック要素にバインディングするとともにその逆を行うことが可能であることを特徴とする請求項６３記載のネットワーク・コンピュータ・システム。
【請求項６５】
前記ＣＲＥが更に、ストレージを備え、
該ストレージが前記ダウンロードされた１若しくはそれ以上のモジュールをキャッシュすることを特徴とする請求項６３記載のネットワーク・コンピュータ・システム。
【請求項６６】
前記ＣＲＥが前記ネットワーク・アプリケーション・プログラムの前記ダウンロードされた１若しくはそれ以上のモジュールそれぞれを互いに独立に実行することを特徴とする請求項６３記載のネットワーク・コンピュータ・システム。
【請求項６７】
前記ＣＲＥが前記ネットワーク・アプリケーション・プログラムの前記ダウンロードされた１若しくはそれ以上のモジュールをオフラインで実行することを特徴とする請求項６３記載のネットワーク・コンピュータ・システム。
【請求項６８】
前記サーバが更に、コンパイラ・システムを備え、
該コンパイラ・システムが、複数の入力ファイルを受信するとともに、該複数の入力ファイルのうち任意の入力ファイルを複数の出力ファイルにそれぞれ変換し、
前記複数の入力ファイルが前記ネットワーク・アプリケーションを備え、
該ネットワーク・アプリケーションは、複数のそれぞれ異なるプログラム言語で書かれ、
前記複数の出力ファイルは、前記ネットワーク・アプリケーションの複数のそれぞれ対応する実行コードを備えることを特徴とする請求項６３記載のネットワーク・コンピュータ・システム。
【請求項６９】
前記１若しくはそれ以上のクライアント・マシンのそれぞれが、１つの実行エンジンを備え、
該実行エンジンが、前記出力ファイルのうち１つを受信するとともに前記対応する実行コードを実行することを特徴とする請求項６８記載のネットワーク・コンピュータ・システム。
【請求項７０】
前記ネットワーク接続が、低い帯域幅を備えることを特徴とする請求項６３記載のネットワーク・コンピュータ・システム。
【請求項７１】
ネットワーク・コンピュータ・システム内で処理を実行する方法であって、
該ネットワーク・コンピュータ・システムは、サーバと１若しくはそれ以上のクライアント・マシンを備え、
該クライアント・マシンは、ネットワーク接続を介して、前記サーバと接続し、
前記方法は、
サーバ・ストレージ内に格納されたネットワーク・アプリケーションを１若しくはそれ以上のモジュールに分割し、該モジュールそれぞれが少なくとも１つのマークアップ・ドキュメントを備える段階と、
前記１若しくはそれ以上のモジュールそれぞれを別個に前記１若しくはそれ以上のクライアント・マシンに前記ネットワーク接続を介してダウンロードする段階を備えることを特徴とする方法。
【請求項７２】
各モジュールが更に少なくとも１つのビジネス・ロジック要素を備え、
該ビジネス・ロジック要素は前記少なくとも１つのマークアップ・ドキュメントと関連し、
各モジュールは更に、オブジェクト指向バインディング機構を備え、
該オブジェクト指向バインディング機構は、前記少なくとも１つのマークアップ・ドキュメントを前記少なくとも１つのビジネス・ロジック要素にバインディングするとともにその逆を行うことを特徴とする請求項７１記載の方法。
【請求項７３】
クライアント・マシン・ストレージ内にダウンロードされた１若しくはそれ以上のモジュールをキャッシュする段階を更に備えることを特徴とする請求項７１記載の方法。
【請求項７４】
更に、前記１若しくはそれ以上のクライアント・マシンにより、互いに独立に前記ネットワーク・アプリケーション・プログラムの前記ダウンロードされた１若しくはそれ以上のモジュールを実行する段階を備えることを特徴とする請求項７１記載の方法。
【請求項７５】
更に、オフラインで、前記１若しくはそれ以上のクライアント・マシンにより前記ネットワーク・アプリケーション・プログラムの前記ダウンロードされた１若しくはそれ以上のモジュールを実行する段階を備えることを特徴とする請求項７１記載の方法。
【請求項７６】
前記サーバが更に、コンパイラ・システムを備え、
該コンパイラ・システムが、複数の入力ファイルを受信するとともに、前記複数の入力ファイルのうち任意のファイルを複数の出力ファイルにそれぞれ変換し、
前記複数の入力ファイルが、前記ネットワーク・アプリケーションを備え、
該ネットワーク・アプリケーションが、複数のそれぞれ異なるプログラム言語で書かれ、
前記複数の出力ファイルが前記ネットワーク・アプリケーションの複数の対応する実行コードをそれぞれ備えることを特徴とする請求項７１記載の方法。
【請求項７７】
前記１若しくはそれ以上のクライアント・マシンそれぞれが、実行エンジンを備え、
該実行エンジンは、前記出力ファイルのうち１つを受信するとともに、前記ネットワーク・アプリケーションの前記対応する実行コードを実行することを特徴とする請求項７６記載の方法。
【請求項７８】
前記ネットワーク接続が、低い帯域幅を備えることを特徴とする請求項７１記載の方法。
【請求項７９】
ネットワーク・コンピュータ・システム内で処理を実行する方法であって、
該ネットワーク・コンピュータ・システムは、サーバと１若しくはそれ以上のクライアント・マシンを備え、
該クライアント・マシンは、ネットワーク接続を介して、前記サーバと接続し、
前記方法は、
サーバ・ストレージ内に格納されたネットワーク・アプリケーションを１若しくはそれ以上のモジュールに分割し、該モジュールそれぞれが少なくとも１つのマークアップ・ドキュメントを備える段階と、
ユーザによる要求を、前記１若しくはそれ以上のクライアント・マシンのうち１つを介して配置し、前記１若しくはそれ以上のモジュールのうち１つをダウンロードする段階と、
前記クライアント・マシンのＣＲＥにより、前記１つのモジュールが前記クライアント・マシンのストレージ内で利用可能であるか否かをチェックする段階と、
もし利用可能であるならば、前記モジュールをダウンロード並びに実行する段階を備えることを特徴とする方法。
【請求項８０】
前記モジュールが更に少なくとも１つのビジネス・ロジックを備え、
該ビジネス・ロジックは、前記少なくとも１つのマークアップ・ドキュメントに関連し、
更に、前記モジュールは、１つのオブジェクト指向バインディング機構を備え、
該オブジェクト指向バインディング機構は、前記少なくとも１つのマークアップ・ドキュメントを前記少なくとも１つのビジネス・ロジック要素にバインディングするとともにその逆を行うことを特徴とする請求項７９記載の方法。
【請求項８１】
前記クライアント・マシンのストレージ内で前記モジュールが利用可能でないならば、前記サーバへ要求を送信し、前記モジュールをダウンロードする段階と、
前記サーバにより前記要求を受信するとともに、前記クライアント・マシンの実行エンジンを特徴付ける段階と、
前記クライアント・マシンにより実行可能な前記モジュールの実行コード・ファイルが既に前記サーバ・ストレージ内で利用可能か否かチェックする段階と、
もし前記実行コード・ファイルが利用可能であるならば、前記実行コード・ファイルを前記クライアント・マシンにダウンロードする段階を備えることを特徴とする請求項７９記載の方法。
【請求項８２】
クライアント・マシン・ストレージ内の前記ダウンロードされた実行コード・ファイルをキャッシュする段階を更に備えることを特徴とする請求項８１記載の方法。
【請求項８３】
更に前記クライアント・マシンにより前記モジュールを実行する段階を備えることを特徴とする請求項８１記載の方法。
【請求項８４】
前記実行コード・ファイルが前記サーバ・ストレージ内で利用可能でないならば、前記モジュールを前記実行コードにコンパイルする段階と、
前記実行コード・ファイルを前記クライアント・マシンにダウンロードする段階を備えることを特徴とする請求項８１記載の方法。
【請求項８５】
コンピュータ・アプリケーション・プログラム内で、クライアント・イベントを取扱う方法であって、
前記コンピュータ・アプリケーション・プログラムは、クライアント・サイド要素を備え、
該クライアント・サイド要素はクライアント・マシン内で動作し、
前記コンピュータ・アプリケーション・プログラムは、更に、サーバ・サイド要素を備え、
該サーバ・サイド要素はサーバ内で動作し、
前記クライアント・マシンは、ネットワーク接続を介して、前記サーバに接続し、
前記方法は、
前記イベントを傾聴するリスナの有無をチェックするとともに、該リスナが前記クライアント・サイド要素或いはサーバ・サイド要素のいずれに存在するかを決定する段階と、
前記リスナが、前記クライアント・サイド要素に存在するならば、前記リスナを具体化するとともに登録されたリスナ手段を起動し、前記イベントを処理し、これにより結果を作成する段階と、
前記結果がマークアップ・ドキュメントであるか、直接的なクライアント・ドキュメント・オブジェクト・モデル（ＤＯＭ）アプリケーション・プログラム・インターフェース（ＡＰＩ）操作であるかをチェックする段階と、
前記結果が、マークアップ・ドキュメントであるならば、前記マークアップ・ドキュメントを表示する段階を備えることを特徴とする方法。
【請求項８６】
前記結果が直接のクライアントＤＯＭ  ＡＰＩ操作であるならば、更に、ＡＰＩコールを実行するとともに前記結果を表示する段階を備えることを特徴とする請求項８５記載の方法。
【請求項８７】
前記リスナが、前記サーバ・サイド要素に存在するならば、
前記イベントを前記サーバに送信し、前記イベントを処理する段階と、
サーバ・サイド・ハンドラを動作させ、前記イベントを処理し、これによりサーバ結果を作成する段階と、
前記サーバ結果を前記クライアント・マシンに送信する段階と、
前記サーバ結果を表示する段階を備えることを特徴とする請求項８５記載の方法。
【請求項８８】
１つのマークアップ・ドキュメントを１若しくはそれ以上のビジネス・ロジック・オブジェクトにバインディングする方法であって、
マークアップ言語を用いて、前記マークアップ・ドキュメントをコード化する段階と、
オブジェクト指向プログラム言語を用いて、１若しくはそれ以上のビジネス・ロジック・オブジェクトをコード化する段階と、
前記マークアップ・ドキュメントを前記１若しくはそれ以上のビジネス・ロジック・オブジェクトと関連付ける段階と、
前記マークアップ・ドキュメントのオブジェクト指向表現を構築し、これにより１若しくはそれ以上のマークアップ・オブジェクトを作成する段階と、
前記オブジェクト指向表現により１若しくはそれ以上のマークアップ・オブジェクト・イベントを発火し、これにより、前記１若しくはそれ以上のビジネス・ロジック・オブジェクトを動作させ、前記イベントを処理する段階と、
前記１若しくはそれ以上のビジネス・ロジック・オブジェクトにより前記マークアップ・オブジェクトを操作する段階からなることを特徴とする方法。
【請求項８９】
前記１若しくはそれ以上のビジネス・ロジック・オブジェクトがマークアップ・オブジェクトＡＰＩを介して前記マークアップ・オブジェクトを操作することを特徴とする請求項８８記載の方法。
【請求項９０】
前記１若しくはそれ以上のビジネス・ロジック・オブジェクトがドキュメント・オブジェクト・モデル（ＤＯＭ）ＡＰＩを介して、前記マークアップ・オブジェクトを操作する段階を備えることを特徴とする請求項８８記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク・ベースの処理のためのシステムおよび方法に関する。より詳しくは、任意のネットワーク接続を介して、サーバと接続するクライアント・マシンにより、自動的に配備、コンパイル、そして実行を行うアプリケーションを提供するネットワーク・ベースの処理に関する。
本出願は、2003年1月10日に出願した米国特許仮出願番号第60／439,394号「帯域幅およびクライアント・インディペンデント・ネットワーク処理を実現するために、コードのコンパイル、配備、そして実行を自動的に行うシステムおよび方法」に係る優先権を主張するものである。また、米国特許仮出願番号第60/439,394号に係る特許を受ける権利は、本発明の譲受人に譲渡されており、当該発明内容は、本発明に明確に含まれている。
【背景技術】
【０００２】
一般的なコンピュータ・システムは、ハードウェア要素及びソフトウェア要素を備える。
ハードウェア要素には、とりわけ個人用コンピュータ、メインフレーム・コンピュータ、コンピュータ回路などのコンピュータ・デバイスが含まれる。コンピュータ・デバイスの基本構造には、プログラムの命令を実行する中央処理ユニット（Central Processing Unit, CPU）及びデータやプログラムの命令を記憶するメモリ・ユニットが含まれる。
命令やデータは、メモリ・ユニットからCPUに伝送され、CPU操作の結果は、メモリ・ユニットに返送される。
【０００３】
ソフトウェア要素とは、アプリケーション・プログラムであり、CPUユニットによって実行される命令を含む。アプリケーション・プログラムとして、とりわけシステム・プログラミング・ソフトウェア、ドローイング・ソフトウェア、文書作成ソフト、表計算ソフトウェア、経営資源管理ソフトウェア、顧客関係管理ソフトウェア、データ解析ソフトウェア、顧客用セルフヘルプ・ソフトウェア、ネットワーク／ストレージ管理ソフトウェア、数値計算及び科学技術ソフトウェアが挙げられる。
【０００４】
コンピュータ・プログラマーは、プログラミング言語の文法規則を用いるソース・ファイル中の命令のセットを、まずコード化することにより、アプリケーション・プログラムを開発する。図１の例では、プログラマは、Javaプログラミング言語（８２）の文法規則とシンタックスを用いるソース・ファイルを作成する。Javaソース・ファイルは、Javaコンパイラ（８４）を通り、そこで分析および解析され、Javaバイトコード・ファイル（８６）を生成させるために用いられる（つまり、Java仮想マシン（Java Virtual Machine, JVM）により理解されるコードのこと）。そして、コンパイルされたJava バイトコード・ファイル（８６）は、コンピュータ・デバイス内のメモリに記憶される。
【０００５】
ユーザが、特定のアプリケーション・プログラムを実行させたいときは、コンピュータ・デバイスは、コンパイルされたJavaバイトコード・ファイル（８６）をメモリから読み込む。尚、この操作はJava仮想マシン（８８）により実行され、この処理結果は表示される（８９）。コンパイルされたJavaバイトコード・ファイル（８６）は、CD、フロッピーディスク、またはテープなどのコンピュータが読み込める記憶媒体に記憶することも可能である。これらの記憶媒体は、アプリケーション・プログラム（すなわちコンパイルされたJavaバイトコード・ファイル）を他のコンピュータ・デバイスに、分散したりインストールするために用いることも可能である。この処理システムは、インディペンデント・コンピュータ・デバイスは十分なシステムである。
【０００６】
ネットワーク・ベースのコンピュータ・システムには、中央サーバと複数のコンピュータ・デバイス（すなわち、ネットワークを介し、互いとまたはサーバと接続するクライアント・マシンのこと）が含まれる。アプリケーション・プログラムは、中央サーバに記憶され、ネットワークを介してクライアント・マシンに配置することができる。あるいは、アプリケーション・プログラムは、クライアント・マシンにインストールすることも可能である。このインストールは、コンパイルされたアプリケーション・コードを含む記憶媒体（例えばCDやフロッピーディスク）を手動で分配することにより行うことができる。
【０００７】
多数の場所にあって、ネットワーク接続を介して、互いとまたはサーバと交信する多数のコンピュータ・デバイスを有する大企業が、ネットワーク・ベースの処理を利用する。
ネットワーク・ベースのコンピュータ・システムにおけるアプリケーション・プログラムには、サーバに記憶されるサーバ・プログラム、クライアント・マシンのメモリに記憶されるクライアント・プログラムが含まれる。サーバ・プログラムはサーバ上で作動し、クライアント・プログラムは、クライアント・マシンのうちの1つで作動する。
【０００８】
大企業は、SAP社の企業資源計画ソフトウェアや顧客内部アプリケーションのような企業アプリケーションを利用するために、ネットワーク・ベースの処理を利用する。
例えば、金融サービス企業では、投資ポートフォリオ・マネジメント・アプリケーションを使用することにより、株分析を行うことができる。資産管理担当者が特定の株分析を行いたいときには、クライアント・マシンの投資ポートフォリオ・マネジメント・アプリケーションを実行させるために、クライアント・プログラムを起動させる。このクライアント・マシンは、多メガバイトのクライアント・プログラムのデータを読み込み、管理担当者の要求を受け処理する。クライアント・マシンは、必要なデータを得るために、ネットワークを介して更なる要求をサーバ・プログラムに伝送することができる。そして、クライアント・プログラムが必要データを受け取った後データ分析し、その分析結果を適切なフォーマットで管理担当者に示す。
【０００９】
ネットワーク・ベースの処理過程には、とりわけ、アプリケーション開発、アプリケーション配備、アプリケーション実行が含まれる。アプリケーション開発は、サーバ上のコーディング、コンパイルおよびデバッグ、サーバにより作動可能であるクライアント・プログラム、クライアント・マシンの多様なコンフィギュレーションおよびオペレーティング・システムをそれぞれ意味する。アプリケーション配備は、多様なクライアント・マシンに組み込まれている様々なクライアント・プログラムの分配およびインストールを意味する。アプリケーション実行は、コンパイルされたサーバ・プログラムおよびクライアント・プログラムのサーバおよびネットワーク上の様々なクライアント・マシンそれぞれを意味する。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
ネットワーク・ベースのコンピュータ・システムのためのアプリケーション開発の主な問題点は、クライアント・プラットフォームおよびデバイス・コンフィギュレーションには互換性がない点である。クライアント・プラットフォームの互換性の無さは、異なるオペレーティング・システムや異なるハードウェアにより生じる。オペレーティング・システムには、様々なバージョンのWindows、 Mainframe、 Macintosh、 Unix、Linux、そしてPalmが挙げられ、ハードウェアには、Pocket PC、デスクトップ、ラップトップ、ワークステーション、電話システム、携帯情報端末（personal digital assistant，PDA）、および多機能テレビ等様々な異なる種類が含まれる。デバイス・コンフィギュレーションには、規定のアプリケーションが要求する特定の設定を含む。 尚、この特定の設定には、ダイナミック・リンク・ライブラリ（Dynamic Link Library，DLL）バージョンおよび一般的なWindowsのアプリケーションのレジストリが挙げられる。数千のユーザやクライアント・マシンを持つ企業にとって、クライアント・プラットフォームおよびデバイス・コンフィギュレーションの互換性の無さは、かなりの複雑さやネットワーク・アプリケーションの開発に有する費用の増大を生じさせる。
【００１１】
ネットワーク・ベースのシステムにおけるアプリケーション配備の主な問題点は、何千、もしくは何十万ものクライアント・マシンへクライアント・プログラムを分散することである。また、各々のクライアント・マシンが、最も適したバージョンのアプリケーションを常に含んでいるかという確認も、アプリケーション配備の主な問題点である。以下は、コード分散やコードコンフィギュレーションを処理するために、今日最も良く使用されている方法である。
CDもしくはフロッピーディスクの分散、手動インストール、および設定
情報システム（Information System, IS）上の個人は、CDもしくはフロッピーディスクからコンパイルされたクライアント・プログラムを直接クライアント・コンピュータにインストールし、アプリケーションを個々のクライアント・コンピュータに手動で設定する。コードがアップグレードされる度に、この手動での手順は繰り返される。多くの異なる場所に配される何千というデスクトップ・コンピュータを有する企業を考慮すると、この方法はあまりに時間や費用がかかり、効率的ではない。
手動によるダウンロード、インストールおよび設定
この方法により、エンドユーザが、ローカル・エリア・ネットワーク（Local Area Network，LAN）、広域ネットワーク（Wide Area Network，WAN）、そしてインターネットを介しクライアント・プログラムを各自のコンピュータにダウンロードおよびインストールすることができる。しかし、クライアント・プログラムが、数十メガバイトを容易に有することを考慮すると、ユーザは、このように大きなファイルをダウンロードしたり、アプリケーションを設定するのに、数時間をかけなければならない。また、何千というユーザを有する企業では、手動ダウンロードによる生産性の損失は重大な問題である。更に、ネットワーク接続が遅く帯域幅が限られている場合（すなわちダイアルアップやワイヤレス接続）は、手動による操作は実行不可能である。
【００１２】
クライアント・プログラム実行による問題点は、今日のプログラム実行モデルが、ユーザがアプリケーションを実行する前に、ほとんど全てのプログラムをメモリに移さなければならないという点である。上記のごとく、クライアント・プログラムは一般的に多メガバイトのファイルであり、このような大きな容量のファイルをメモリに移すには、非常に多くの時間を要する。更に、この実行モデルは、より早いCPU、大容量のメモリやストレージ、そしてより早いネットワークを要求するため、ハードウェア上に更なる要求を生み出す。それゆえ、これら全ての要求はコストパフォーマンスの問題につながる。
【００１３】
スタティック・ネットワーク・ベースのコンピュータ・システムに対する他の方法には、Javaアプレット方法やハイパー・テキスト・マークアップ・ランゲージ（Hyper Text Markup Language，HTML）形式によるウェブページ方法が含まれる。Javaアプレット方法では、ネットワーク・アプリケーションのクライアント要素が、Javaアプレットとして書き込まれ、予めアプリケーションをインストールしなくても、エンドユーザがこのアプリケーションにアクセスすることが可能となる。
しかし、Javaアプレットの実際の使用は、技術上において深刻な問題を有し、簡単なアプリケーションのみに限定される。複雑なエンタープライズ・アプリケーションでは、Javaアプレットは、うまく作動しないだけでなく、1MGを超えるフットプリントを容易に備える。つまり、このフットプリントにより、ダウンロードに長い時間を要し、ユーザがインターネットやワイド・エリア・ネットワーク上で、Javaアプレットを効果的に使用することができない。更に、Javaアプレットは、クライアント・マシン上でJava仮想マシン（Java Virtual Machine，JVM）を必要とする。Java仮想マシンの互換性の無さとクライアント・マシン上JVMが欠如することによって、エンタープライズ・アプリケーションにおけるJavaアプレットを幅広く普及することは不可能となる。
【００１４】
HTML方式のウェブページにおける方法では、企業は、簡単なアプリケーションの画面を公開するために、HTMLを使用する。この方法では、全てのアプリケーションがサーバ上で作動する。各々の画面は、HTML方式のウェブページにフォーマットされ、ウェブ・ブラウザに表示される。ある簡単なクライアント・サイドのロジックは、Javaスクリプトのような技術を用いたHTMLページに加えられることが可能である。
しかし、この方法は、最小限の双方向性と機能性しかユーザに要求しないアプリケーションに限定される。この方法を用いたネットワーク・アプリケーションは、クライアント・サイドの処理と関与する多くの特徴と機能性を犠牲にしてしまう。この処理には、とりわけオフライン処理、ドラッグ&ドロップ、マルチ・ウィンドウ、表計算が挙げられる。インターネット・ブラウザと関与する「クリックと更新」ユーザ相互作用モデルは、ネットワーク・アプリケーションには最適でない。なぜならば、このモデルは、重複する情報を送信したり再送信することにより、かなりの帯域幅を浪費するだけでなく、一回のクリックごとに時間がかかるので、ユーザ効率をかなり下げる。
また、このシナリオでは、クライアントサイド・ビジネス・ロジックを制限することとなる。なぜならば、JavaやC＋＋のような、より頑強なオブジェクト指向プログラミング（Object-oriented programming，OOP）言語とは異なり、Javaスクリプトのようなスクリプト言語は、開発者の大編成チームによって開発されるような複雑なプログラムには上手く適合できないからである。その結果、HTML方式は、簡単なアプリケーションのみに使用されている。重要なアプリケーションは、OOP言語を使用する旧来のクライアント／サーバ・アプリケーションとして、未だに書き込まれている。
【００１５】
つまり、ネットワーク・ベースの処理における今日の方法は、開発者にとって費用がかかり、非効率で複雑である。ユーザがアプリケーションを実行するためには、ダウンロード、設定、そして読込みを、時間をかけて行わなければならない。また、新しいバージョンのアプリケーションが利用可能となれば、ユーザは同じ工程を繰り返し行わなければならない。
プラットフォームの互換性の無さによって、多くのユーザは、しばしば、アプリケーションを全く作動することができなくなる。また、企業は、アプリケーション・コンフィグレーションと管理を行うための、大規模な技術サポートチームを維持しなければならない。
デスクトップは、ますます大きくなるクライアントのプログラムから発せられる要求を満たすために、常にアップグレードする必要がある。ワイド・エリア・ネットワーク（WAN）や公共用途向けインターネットなど、帯域幅が限られているネットワークを利用するユーザにとっては、今日の方法は、単に実行不可能である。HTML方式のように、クライアントのフットプリントや互換性の無さの問題を大幅に低減できる別の方法も存在する。しかし、このような方法では、ほとんどのビジネス・アプリケーションに要求される機能性やパフォーマンスを提供することはできない。
すなわち、任意のネットワーク接続を介してサーバと接続するクライアント・マシンによるアプリケーションのコンパイル、展開、実行を自動化し、簡略化し、最適化するネットワーク・ベースのコンピュータ・システムの必要性がある。
【課題を解決するための手段】
【００１６】
本発明の一形態において、総じて、本発明は、汎用コンパイラを提供する。該汎用コンパイラは、複数の入力ファイルを受信する。この入力ファイルはアプリケーションのソース・コードを備える。該ソース・コードは、複数のそれぞれ異なるプログラム言語のうちいずれかにて記載される。そして、汎用コンパイラは、入力ファイルのうち任意の入力ファイルを出力ファイルに変換する。出力ファイルは、アプリケーションの実行コードを備え、該実行コードは、実行エンジンにより実行される。
【００１７】
本発明の上記形態の実施例は、以下の１若しくはそれ以上の特徴を備えるものであってもよい。
汎用コンパイラが複数の特定のプログラム言語コンパイラを備えるものであってもよい。各特定のプログラム言語コンパイラは、入力ファイルを受信する。入力ファイルはアプリケーションのソース・コードを備え、該ソース・コードは、特定のプログラム言語で書かれる。そして各特定のプログラム言語コンパイラは、入力ファイルをアプリケーションの特定の実行コードに変換する。この実行コードは特定の実行エンジンにより実行される。
汎用コンパイラは、更に、制御ロジックを備えるものであってもよい。制御ロジックは、複数の特定のプログラム言語コンパイラから、特定のプログラム言語コンパイラを選択する。
プログラム言語は、Java、JavaScript、C#、C+、C++、Visual Basic、J#、ActionScript、XSL、XQuery、XPath及びその他の言語であってもよい。実行コードは、Java仮想マシン・バイトコード、.Net Common Language Runtime（ドット・ネット・コモン・ランゲージ・ランタイム：CLR）バイトコード或いはFlashプレイヤ・バイトコードであってもよい。
実行エンジンは、それぞれ、Java仮想マシン、.Net CLRエンジン或いはFlashプレイヤであってもよい。
【００１８】
本発明の他の形態において、総じて、本発明はコンパイラ・システムを提供する。コンパイラ・システムは複数の入力ファイルを受信し、これら複数の入力ファイルのうち任意のファイルを複数の出力ファイルに変換する。
入力ファイルそれぞれは、アプリケーションのソース・コードを備え、該ソース・コードは、複数の異なるプログラム言語のうちいずれかで書かれている。複数の出力ファイルは、アプリケーションの複数の実行コードをそれぞれ備える。この実行コードは、複数の実行エンジンそれぞれにより実行可能である。
【００１９】
本発明の上記形態の実施例は、以下の１若しくはそれ以上の特徴を備えるものであってもよい。
コンパイラ・システムは、複数の汎用コンパイラを備え、該汎用コンパイラそれぞれが、複数の特定のプログラム言語コンパイラを備えるものであってもよい。特定のプログラム言語コンパイラは、１つの入力ファイルを受信する。入力ファイルは、アプリケーションのソース・コードを備え、該ソース・コードは、特定のプログラム言語で書かれている。そして、特定のプログラム言語コンパイラは、この入力ファイルをアプリケーションの１つの特定の実行コードに変換する。この実行コードは、特定の実行エンジンにより実行される。
コンパイラ・システムは、更に第１制御ロジックを備えてもよい。該第１制御ロジックは、複数の汎用プログラム言語コンパイラから１つの汎用プログラム言語コンパイラを選択する。また、コンパイラ・システムは更に第２制御ロジックを備えてもよい。第２制御ロジックは複数の実行コードをキャッシュする。
プログラム言語は、Java、JavaScript、C#、C+、C++、Visual Basic、J#、ActionScript、XSL、XQuery、XPath及びその他から選択されてもよい。また実行コードは、Java仮想マシン・バイトコード、.Net CLRバイトコード、Flashプレイヤ・バイトコード、Palm OSバイトコード、Symbian OSバイトコード及びQualcomm Brewバイトコードであってもよい。また対応する実行エンジンがそれぞれ、Java仮想マシン、.Net CLRエンジン、Flashプレイヤ、Palm OS、Symbian OS、Qualcomm Brewエンジンであってもよい。
【００２０】
本発明の他の形態において、総じて、本発明は分散処理を実行するコンピュータ・システムを提供する。該コンピュータ・システムは、１つの汎用コンパイラを備えるサーバと、１つの実行エンジンを備える少なくとも１つのクライアント・マシンを備える。クライアント・マシンは、ネットワークを介して、サーバと接続する。汎用コンパイラは、複数の入力ファイルを受信し、該複数の入力ファイルのうち任意のファイルを出力ファイルに変換する。複数の入力ファイルは、アプリケーションのソース・コードを備え、該ソース・コードは、複数のプログラム言語でそれぞれ書かれる。出力ファイルは、アプリケーションの実行コードを備える。実行エンジンはネットワーク上で出力ファイルを受信するとともに、実行コードを実行する。
【００２１】
本発明の他の形態において、総じて、本発明は分散処理を実行するコンピュータ・システムを提供する。該コンピュータ・システムは、１つのサーバを備える。該サーバは、１つのコンパイラ・システムと、複数のクライアント・マシンを備える。該クライアント・マシンは、複数の実行エンジンをそれぞれ備える。また、クライアント・マシンはネットワークを介してサーバと接続する。
コンパイラ・システムは、複数の入力ファイルを受信し、この入力ファイルのうち任意のファイルを複数の出力ファイルに変換する。複数の入力ファイルは、アプリケーションのソース・コードを備え、該ソース・コードは、複数の異なるプログラム言語でそれぞれ書かれている。そして、複数の出力ファイルはそれぞれ、アプリケーションの複数の実行コードを備える。実行エンジンは、ネットワーク上で出力ファイルを受信し、対応する実行コードを実行する。
【００２２】
本発明の他の形態において、総じて、本発明は汎用XMLコンパイラを提供する。この汎用XMLコンパイラは、複数の入力ファイルを受信するとともに、この複数の入力ファイルのうち任意のファイルを１つの出力ファイルに変換する。複数の入力ファイルは複数のマークアップ・ドキュメントを備え、該マークアップ・ドキュメントは複数の異なるXML言語でそれぞれ書かれる。出力ファイルは、実行コードを備え、該実行コードは所定の実行エンジンにより実行される。
【００２３】
本発明の上記形態の実施例は、以下の１若しくはそれ以上の特徴を備えるものであってもよい。
XML言語が、XML、XUL、SVG、Xforms、XAML、HTML、XHTML、HTMLに関連する言語及びこれらの組み合わせであってもよい。実行コードは、XML言語フォーマットを備えていてもよく、また所定の実行エンジンが、XML実行エンジンを備えるものであってもよい。実行コードがバイナリ・フォーマットであってもよく、所定の実行エンジンが、このバイナリ・フォーマットを実行するエンジンであってもよい。
バイナリ・フォーマットは、Java仮想マシン・バイトコード、.Net CLRバイトコード、Palm OSバイトコード、Flashプレイヤ・バイトコード、Symbian OSバイトコード及びQualcomm Brewバイトコードであってもよく、実行エンジンがそれぞれ、Java仮想マシン、.Net CLR、Palm OS 、Flashプレイヤ、Symbian OS、Qualcomm Brewであってもよい。
【００２４】
本発明の他の形態において、総じて、本発明は、ネットワーク・コンピュータ・システム内でアプリケーションを配備する方法を提供する。ネットワーク・コンピュータ・システムは、サーバと、１若しくはそれ以上のクライアント・マシンを備える。クライアント・マシンは、ネットワーク接続を介して、サーバと接続する。またクライアント・マシンそれぞれが実行エンジンを備える。
上記方法は、クライアント・マシンのうち１つによる要求をサーバへ送信し、アプリケーションの１若しくはそれ以上のファイルをダウンロードする段階を備える。次に、サーバにより要求を受信し、クライアント・マシンの実行エンジンを特徴付ける。その後、アプリケーション・コードの１若しくはそれ以上のファイルの１若しくはそれ以上の実行コードがそれぞれサーバ・ストレージ内で利用可能か否かをチェックする。１若しくはそれ以上の実行コードは、クライアント・マシンの実行エンジンにより実行可能である。最後に、１若しくはそれ以上の実行コードが利用可能であるならば、これら実行コードはクライアント・マシンへダウンロードされる。
【００２５】
本発明の上記形態の実施例は、以下の１若しくはそれ以上の特徴を備えるものであってもよい。
ダウンロードされた１若しくはそれ以上の実行コードは、クライアント・ストレージ内でキャッシュされる。１若しくはそれ以上の実行コードは、クライアント・マシンのストレージからダウンロードされてもよい。もし１若しくはそれ以上の実行コードがサーバ・ストレージ内で利用可能でないならば、上記方法はアプリケーションの１若しくはそれ以上のファイルを１若しくはそれ以上の実行コードにそれぞれコンパイルする段階を備えてもよい。そして、これら実行コードがクライアント・マシンにダウンロードされる。
【００２６】
本発明の他の形態において、総じて、本発明は、コンピュータ・アプリケーション・プログラムを提供する。該コンピュータ・アプリケーション・プログラムは、少なくとも１つのマークアップ・ドキュメント、該少なくとも１つのマークアップ・ドキュメントに関連する少なくとも１つのビジネス・ロジック要素及びオブジェクト指向バインディング機構を備える。該オブジェクト指向バインディング機構は、少なくとも１つのマークアップ・ドキュメントを少なくとも１つのビジネス・ロジック要素にバインディングする。或いは、少なくとも１つのビジネス・ロジック要素を、少なくとも１つのマークアップ・ドキュメントにバインディングする。
【００２７】
本発明の上記形態の実施例は、以下の１若しくはそれ以上の特徴を備えるものであってもよい。
クライアント・ランタイム環境（Client Runtime Environment: CRE）が少なくとも１つのマークアップ・ドキュメントを受信するとともに、これを１つのオブジェクト指向表現に変換してもよい。オブジェクト指向表現は、１若しくはそれ以上のマークアップ・オブジェクト、１若しくはそれ以上のユーザ・インターフェース及び１若しくはそれ以上のデータ・セットを備えてもよい。少なくとも１つのビジネス・ロジック要素は、１若しくはそれ以上の手段を備え、該手段が、マークアップ・オブジェクト・イベントに対するイベント・ハンドラとして用いられる。オブジェクト指向バインディング機構は、マークアップ・オブジェクト・イベントを発火することにより、１若しくはそれ以上のマークアップ・オブジェクトにより、１若しくはそれ以上の手段を動作させてもよい。
オブジェクト指向バインディング機構は、更に、アプリケーション・プログラム・インターフェース（Application Program Interface: API）を介して、少なくとも１つのビジネス・ロジック要素により、１若しくはそれ以上のマークアップ・オブジェクトにアクセスするとともにマークアップ・オブジェクトを変更してもよい。ＡＰＩは、マークアップ・オブジェクトＡＰＩ或いはドキュメント・オブジェクト・モデル（Document Object Model: DOM）ＡＰＩであってもよい。
１若しくはそれ以上のマークアップ・オブジェクトは、親マークアップ・オブジェクトと子マークアップ・オブジェクトであってもよい。子マークアップ・オブジェクトは１若しくはそれ以上のマークアップ・オブジェクト・プロパティを備え、該マークアップ・オブジェクト・プロパティは、親マークアップ・オブジェクトから継承される。
１若しくはそれ以上のマークアップ・オブジェクト・プロパティは、ユーザ・インターフェース定義、データ・セット定義或いはイベント・ハンドラ定義であってもよい。
親マークアップ・オブジェクトは、１若しくはそれ以上のユーザ・インターフェース定義、１若しくはそれ以上のデータ定義及び１若しくはそれ以上のイベント・ハンドラを備えてもよく、子マークアップ・オブジェクトは、１若しくはそれ以上のユーザ・インターフェース定義、１若しくはそれ以上のデータ定義及び１若しくはそれ以上のイベント・ハンドラを親マークアップ・オブジェクトから継承してもよい。
１若しくはそれ以上のマークアップ・オブジェクトは、親マークアップ・オブジェクト及び子マークアップ・オブジェクトを備え、該子マークアップ・オブジェクトが親マークアップ・オブジェクトの１若しくはそれ以上のマークアップ・オブジェクト・プロパティを上書きし、これらを子マークアップ・オブジェクトの１若しくはそれ以上のマークアップ・オブジェクト・プロパティに置換してもよい。
少なくとも１つのマークアップ・ドキュメントがマークアップ言語で書かれてもよい。該マークアップ言語は、XML、XUL、SVG、Xforms、XAML、HTML、HTMLに関連する言語、テキスト、これらの組み合わせ及びその他であってもよい。１若しくはそれ以上のビジネス・ロジック要素は、プログラム言語で書かれてもよい。該プログラム言語は、Java、JavaScript、J#、C#、C+、C++、Visual Basic、ActionScript、XSL、XQuery及びXPathであってもよい。
【００２８】
本発明の他の形態において、総じて、本発明は、ネットワーク・アプリケーション・プログラムを提供する。
該ネットワーク・アプリケーション・プログラムは、１若しくはそれ以上のモジュールを備える。各モジュールは、少なくとも１つのマークアップ・ドキュメント、少なくとも１つのマークアップ・ドキュメントに関連する少なくとも１つのビジネス・ロジック及びオブジェクト指向バインディング機構を備える。該オブジェクト指向バインディング機構は、少なくとも１つのマークアップ・ドキュメントを少なくとも１つのビジネス・ロジック要素にバインディングし、また、少なくとも１つのビジネス・ロジック要素を少なくとも１つのマークアップ・ドキュメントにバインディングする。
【００２９】
本発明の他の形態において、総じて、本発明は、ネットワーク・コンピュータ・システムを提供する。
該ネットワーク・コンピュータ・システムは、サーバ・ランタイム環境（Server Runtime Environment: CRE）を備える１つのサーバと、ネットワーク・アプリケーション・プログラムと、１若しくはそれ以上のクライアント・マシンを備える。各クライアント・マシンは、クライアント・ランタイム環境（Client Runtime Environment: CRE）を備え、また、ネットワーク接続を介して、サーバに接続する。
ＳＲＥは、ネットワーク・アプリケーション・プログラムを１若しくはそれ以上のクライアント・マシンに、ネットワーク接続を介して配備する。この配備は、まずネットワーク・アプリケーションを１若しくはそれ以上のモジュールに分割し、その後、個別に１若しくはそれ以上のモジュールをクライアント・マシンにダウンロードすることにより行われる。各モジュールは、少なくとも１つのマークアップ・ドキュメントを備える。
【００３０】
本発明の上記形態の実施例は、以下の１若しくはそれ以上の特徴を備えるものであってもよい。
ネットワーク・コンピュータ・システムは、更に少なくとも１つのビジネス・ロジックを備え、該ビジネス・ロジックは少なくとも１つのマークアップ・ドキュメントに関連する。また、ネットワーク・コンピュータ・システムは、オブジェクト指向バインディング機構を備え、該オブジェクト指向バインディング機構は、少なくとも１つのマークアップ・ドキュメントを少なくとも１つのビジネス・ロジック要素にバインディングし、また、少なくとも１つのビジネス・ロジック要素を少なくとも１つのマークアップ・ドキュメントにバインディングする。
ＣＲＥは、ストレージを備え、該ストレージがダウンロードされた１若しくはそれ以上のモジュールを格納してもよい。ＣＲＥは、ネットワーク・アプリケーション・プログラムのダウンロードされた１若しくはそれ以上のモジュールを互いに独立に実行してもよい。ＣＲＥは、オフラインで、ネットワーク・アプリケーション・プログラムのダウンロードされた１若しくはそれ以上のモジュールを実行してもよい。
サーバが、コンパイラ・システムを備え、該コンパイラ・システムが、複数の入力ファイルを受信するとともに、該複数の入力ファイルのうち任意のファイルを複数の出力ファイルにそれぞれ変換してもよい。複数の入力ファイルが、ネットワーク・アプリケーションを備え、該ネットワーク・アプリケーションが、複数の異なるプログラム言語でそれぞれ書かれてもよい。複数の出力ファイルが、ネットワーク・アプリケーションの複数の対応する実行コードをそれぞれ備えてもよい。
１若しくはそれ以上のクライアント・マシンそれぞれが、実行エンジンを備え、該実行エンジンが出力ファイルのうち１つを受信し、対応する実行コードを実行してもよい。ネットワーク接続が、低い帯域幅を有してもよい。
【００３１】
本発明の他の形態において、総じて、本発明は、ネットワーク・コンピュータ・システム内で処理を実行する方法を提供する。該ネットワーク・コンピュータ・システムは、１つのサーバと、１若しくはそれ以上のクライアント・マシンを備える。クライアント・マシンは、ネットワーク接続を介して、サーバに接続する。
上記方法は、サーバ・ストレージ内に格納されたネットワーク・アプリケーションを、１若しくはそれ以上のモジュールに分割する段階を備える。各モジュールは、少なくとも１つのマークアップ・ドキュメントを備える。続いて、１若しくはそれ以上のクライアント・マシンのうち１つを介してユーザによる要求が配置され、１若しくはそれ以上のモジュールがダウンロードされる。次に、クライアント・マシンのＣＲＥにより、１つのモジュールが、クライアント・マシンのストレージ内で利用可能であるかチェックされる。そして、利用可能であるならば、モジュールがダウンロードされ、実行される。
【００３２】
本発明の上記形態の実施例は、以下の１若しくはそれ以上の特徴を備えるものであってもよい。
モジュールが更に、少なくとも１つのマークアップ・ドキュメントに関連する少なくとも１つのビジネス・ロジックと、オブジェクト指向バインディング機構を備えてもよい。該オブジェクト指向バインディング機構は、少なくとも１つのマークアップ・ドキュメントを少なくとも１つのビジネス・ロジック要素にバインディングし、また、少なくとも１つのビジネス・ロジック要素を少なくとも１つのマークアップ・ドキュメントにバインディングする。
上記方法は、以下の段階を備えてもよい。
もし、モジュールがクライアント・マシンのストレージ内で利用可能でないならば、サーバへの要求を送信し、モジュールをダウンロードする。続いて、サーバにより要求を受信し、クライアント・マシンの実行エンジンを特徴付ける。そして、クライアント・マシンの実行エンジンにより実行可能なモジュールの実行コード・ファイルが既にサーバ・ストレージ内で既に利用可能であるか否かをチェックする。もし、実行コード・ファイルが利用可能であるならば、該実行コード・ファイルをクライアント・マシンへダウンロードする。
上記方法が更に、クライアント・マシン・ストレージ内にダウンロードされた実行コード・ファイルをキャッシュし、クライアント・マシンによりモジュールを実行する段階を備えてもよい。もし、実行コード・ファイルがサーバ・ストレージ内で利用可能でないならば、モジュールを実行コード・ファイルにコンパイルし、その後実行コード・ファイルをクライアント・マシンにダウンロードする段階を備えてもよい。
【００３３】
本発明の他の形態において、総じて、本発明は、コンピュータ・アプリケーション・プログラム内でクライアント・イベントを取扱う方法を提供する。
該コンピュータ・アプリケーション・プログラムは、クライアント・サイド要素を備える。該クライアント・サイド要素は、クライアント・マシン内で動作する。またコンピュータ・アプリケーション・プログラムは、サーバ内で動作するサーバ・サイド要素を備える。クライアント・マシンは、ネットワーク接続を介して、サーバと接続する。
上記方法は、イベントを傾聴するリスナの存在の有無をチェックし、リスナがクライアント・サイド要素或いはサーバ・サイド要素にいるかを決定する。もしリスナが、クライアント・サイド要素にいるならば、リスナを具体化するとともに登録されたリスナ手段を動作させ、イベントを処理する。これにより、結果を作成する。続いて、該結果がマークアップ・ドキュメントであるか直接のクライアント・ドキュメント・オブジェクト・モデル（Document Object Model: DOM）アプリケーション・プログラム・インターフェース（Application Program Interface: API）操作であるかをチェックし、もし結果が、マークアップ・ドキュメントであるならば、該マークアップ・ドキュメントを表示する。
【００３４】
本発明の上記形態の実施例は、以下の１若しくはそれ以上の特徴を備えるものであってもよい。
もし結果が直接のクライアントＤＯＭ  ＡＰＩ操作であるならば、上記方法が、ＡＰＩコールを実行し、結果を表示する段階を備えてもよい。もしリスナが、サーバ・サイド要素に存在するならば、該方法が更に、イベントをサーバに送信し、イベントを処理し、サーバ・サイド・ハンドラを動作させる段階を備えてもよい。サーバ・サイド・ハンドラは、イベントを処理する。これによりサーバ結果を作成する。続いて、サーバ結果をクライアント・マシンに送信し、サーバ結果を表示する。
【００３５】
本発明の他の形態において、総じて、本発明は、マークアップ・ドキュメントを１若しくはそれ以上のビジネス・ロジック・オブジェクトにバインディングする方法を提供する。
上記方法は、マークアップ言語を用いて、マークアップ・ドキュメントをコード化し、オブジェクト指向プログラム言語を用いて１若しくはそれ以上のビジネス・ロジック・オブジェクトをコード化し、マークアップ・ドキュメントを１若しくはそれ以上のビジネス・ロジックに関連付ける段階を備える。
続いて、マークアップ・ドキュメントのオブジェクト指向表現を構築し、これにより、１若しくはそれ以上のマークアップ・ドキュメントを作成する。そして、オブジェクト指向表現により、１若しくはそれ以上のマークアップ・オブジェクト・イベントを発火させ、これによりビジネス・ロジック・オブジェクトを動作させ、ビジネス・ロジック・オブジェクトは、イベントを処理する。最後に、１若しくはそれ以上のビジネス・ロジック・オブジェクトによりマークアップ・オブジェクトを操作する。ビジネス・ロジック・オブジェクトは、マークアップ・オブジェクトＡＰＩやドキュメント・オブジェクト・モデル（Document Object Model: DOM）ＡＰＩを介してマークアップ・オブジェクトの操作を行ってもよい。
【発明の効果】
【００３６】
本発明の効果のうち１若しくはそれ以上が以下に示される。
コンピュータ・システムは、中央サーバから、ネットワーク接続を介してサーバに接続された任意のクライアント・マシンへのネットワーク・アプリケーションの区割された引渡し並びに実行を可能とする。ネットワーク接続は低い帯域幅ネットワークであってもよい。クライアント・マシンが処理プラットフォームとデバイスの任意の種類を備えるものであってもよい。ネットワーク・アプリケーションが、マークアップ・ドキュメント、ビジネス・ロジック要素及びオブジェクト指向バインディング機構を備え、該オブジェクト指向バインディング機構がマークアップ・ドキュメントをビジネス・ロジック要素にバインディングし、また、ビジネス・ロジック要素をマークアップ・ドキュメントにバインディングしてもよい。
マークアップ・ドキュメントは、任意の種類のマークアップ言語で書かれてもよい。該マークアップ言語は、XML、XUL、SVG、Xforms、XMLに関連する言語、HTML、HTMLに関連する言語、テキスト、これらの組み合わせ及びその他であってもよい。
ビジネス・ロジック要素は、ソース・コードを備え、該ソース・コードが任意のプログラム言語で書かれてもよい。該プログラム言語が、Java、JavaScript、J#、C#、C+、C++、Visual Basic、ActionScript、XSL、XQuery、XPath及びその他を備えるものであってもよい。
コンパイラ・システムはソース・コードを任意の種類の実行可能なバイト・コードに変換する。このコンパイラ・システム・コンフィギュレーションは、アプリケーションのプログラム側とアプリケーションの実行側両面における自在性を提供する。
【００３７】
本発明の１若しくはそれ以上の実施形態は、以下に図面並びに記載にて説明される。本発明の他の特徴、目的並びに優位点は、以下の好適な実施形態に係る説明、図面及び請求の範囲から明らかになる。
【発明を実施するための最良の形態】
【００３８】
図２を参照する。ネットワーク・ベース・コンピュータ・システム（７０）は、サーバ（７２）と、クライアント・マシン（７３）、（７４）、（７５）及び（７６）を備える。該クライアント・マシンには、パーソナル・コンピュータ（７３）、ノート・パソコン（７４）、その他のコンピュータ・デバイス（７５）、及びワイヤレス通信デバイス（７６）が含まれる。クライアント・マシン（７３）、（７４）、及び（７５）は、サーバ（７２）にネットワーク接続（７８）を介して接続されている。クライアント・マシン（７６）は、ワイヤレス・ネットワーク接続（７９）を介してサーバ（７２）に接続されている。追加的なクライアント・マシンをいくつか用いてもよい。これらの追加的なクライアント・マシンとしては、パーソナル・コンピュータ、ノート・パソコン、リナックス・マシン、ワークステーション、コンピューティング回路、有線通信デバイスなどが挙げられる。該有線通信デバイスとしては、電話やテレビなどが挙げられる。ネットワーク接続（７８）としては、インターネット、World Wide Web (WWW)、 Wide Area Network (WAN)、 Local Area Network (LAN)、 Personal Area Network (PAN)、電気通信ネットワークが挙げられる。ワイヤレス通信デバイス（７６）としては、携帯電話、personal digital assistant (PDA)、ポケットベル、ワイヤレスノートパソコン、パーソナル・コンピュータ、テレビ、及びそれらのプログラマブル・バージョン又はそれらを組み合わせたものが挙げられる。ワイヤレス・ネットワーク（７９）としては、wireless wide area network (WWAN)、wireless local area network (WLAN)、wireless personal area network (WPAN)、或いは専用通信網が挙げられる。
【００３９】
図３を参照する。図３はブロック線図であり、単純なネットワーク・コンピュータ・システム（２００）のソフトウェア要素及びハードウェア要素を表す。該ネットワーク・コンピュータ・システム（２００）は、アプリケーション・サーバ（２１０）、クライアント・マシン（２２０）、ウェブ・サーバ（２１９）を備える。アプリケーション・サーバ（２１０）は、ウェブ・サーバ（２１９）後方で動作するとともに、サーバ・アプリケーション・コード（或いはサーバサイド・ビジネス・ロジック）（２１２）を実行する。ウェブ・サーバ（２１９）は、マークアップ・ドキュメント或いはサーバサイド・アプリケーション・コード（２１２）により生成された電子メッセージを、クライアント・ウェブ・ブラウザ（２３０）に伝達する。該クライアント・ウェブ・ブラウザ（２３０）は、クライアント・マシン（２２０）内に常駐する。電子メッセージとは、情報交換のために電子的に伝達されるコミュニケーション・メッセージである。マークアップ・ドキュメントとは、電子ドキュメント、つまりＸＭＬ或いはＨＴＭＬなどのマークアップ言語を用いて書かれたファイルのことをいう。マークアップ言語とは電子ドキュメントのコンテンツを記述するための慣例的な言語である。該電子ドキュメントは、コンピュータ・アウトプット・デバイス（例えば、コンピュータ・モニターなど）上でみたり、該デバイス上に印刷したりするためのものである。マークアップ言語ドキュメントは、特に、テキスト、イメージ、JavaScript、ハイパーリンクなどを含んでもよい。リアルタイム双方向性高信頼性メッセージング・システム（２４０）は、クライアント・ウェブ・ブラウザ（２３０）とウェブ・サーバ（２１９）の間で、ＨＴＴＰウェブ接続を介して、メッセージを伝達する。アプリケーション・サーバは、サーバサイド・アプリケーション・コード（２１２）に加えて、サーバ・ランタイム環境(Server Runtime Environment, SRE)（２１４）を備える。ＳＲＥ（２１４）は、ＨＴＴＰウェブ・サーバ（２１９）の後方、且つアプリケーション・サーバ（２１０）内で動作する。ＳＲＥ（２１４）はサーバ・コンパイラ（２１６）、サーバ・キャッシュ（２１８）、通信モジュール（２１５）、及びその他の機能的モジュール（２１７）を備える。機能的モジュール（２１７）は、アプリケーション・サーバ・インターフェース、ＸＭＬパーサ、クラスタリング、ストレージ、及び実行エンジンを備える。アプリケーション・サーバ・インターフェース・モジュールは、ＳＲＥ（２１４）がアプリケーション・サーバ（２１０）内で動作することを可能にするとともに、アプリケーション・サーバ（２１０）内のアプリケーションがＳＲＥの機能性（ファンクショナリティ：functionality）にアクセスすることを可能にする。ＸＭＬパーサ・モジュールは、様々なクライアント・マシン或いはその他の情報ソース（例えば、その他のバックエンド接続）からのＸＭＬドキュメントをパースする。パースの結果は、ストレージ・モジュール内に記憶される。クラスタリング・モジュールは、ＳＲＥのクラスタリングを補助する。実行エンジン・モジュールは、コンパイルされたサーバエンド・アプリケーション・コード（２１２）を実行する���
【００４０】
クライアント・マシン（２２０）は、クライアント・ランタイム環境（ＣＲＥ）（２２４）を備える。ＣＲＥ（２２４）は、クライアント・ウェブ・ブラウザ（２３０）及びクライアントサイド・アプリケーション・コード（又はクライアントサイド・ビジネス・ロジック）（２２２）外部で動作する。他の実施例では、ＣＲＥは、クライアント・ウェブ・ブラウザ（２３０）内で動作する。クライアントサイド・アプリケーション・コード（２２２）は、エクステンシブル・マークアップ言語（Extensible Markup Language、ＸＭＬ）ドキュメント及び手続コードからなる。クライアント・マシン（２２０）は、クライアント・サイド・ファイアウォール（２４４）により保護されており、ウェブ・サーバ（２１９）は、サーバサイド・ファイアウォール（２４２）により保護されている。ＣＲＥ（２２４）は、マークアップ・ドキュメントを処理するとともに、クライアントサイド・アプリケーション・コード（２２２）を実行する。ＣＲＥ（２２４）は、クライアント・キャッシュ（２２６）、通信モジュール（２２５）、状態同期及び継続化モジュール（２２８）、及びその他の機能的モジュール（２２７）を備える。その他の機能的モジュール（２２７）としては、ＸＭＬパーサ、ユーザ・インターフェース、ストレージ、セキュリティ、及び実行エンジンが挙げられる。ＸＭＬパーサは、アプリケーション・サーバ（２１０）からのＸＭＬドキュメントをパースする。パース結果は、アプリケーションのクライアント・サイドの状態の一部としてクライアント・キャッシュ（２２６）内に記憶されてもよい。ユーザ・インターフェース・モジュールは、ユーザ・インターフェースを表示するとともに、アプリケーションのＸＭＬ記述に従ってユーザと情報のやりとりを行う。実行エンジン・モジュールは、クライアントサイド・アプリケーション・コード（２２２）を動作させることが可能である。クライアント・キャッシュ（２２６）は、アプリケーションのクライアント・サイドの状態を保守するとともに、該ＣＲＥにより自動的に更新される。同期及び継続化モジュール（２２８）は、クライアント・キャッシュ（２２６）を、アプリケーション・サーバ（２１０）と同期させるとともに、クライアント・キャッシュ（２２６）を継続的ストレージに保存及び／又は継続的ストレージから検索する。
【００４１】
ＣＲＥ（２２４）は、ＳＲＥ（２１４）により集中管理される。ＣＲＥ（２２４）は、自動的にアプリケーション・サーバ（２１０）からダウンロードされ、ユーザが最初にクライアント・アプリケーションにアクセスしたときに、クライアント・マシン（２２０）にインストールされる。初期インストールの後は、ＳＲＥ（２１４）が自動的にＣＲＥ（２２４）のヴァージョンアップ並びに更新を管理する。異なるクライアント・プラットフォームに対しては、異なるＣＲＥ（２２４）が用いられる。例えば、Java仮想マシン、 .NET CLR、 或いはFlashプレイヤには、それぞれ異なるＣＲＥが用いられる。これら３つのクライアント・プラットフォームの実行アプリケーション・コード・フォーマットはそれぞれ、Java バイトコード、.NET CLR バイトコード、Flash バイトコードである。アプリケーション・コード（２２２）は、これら３つのクライアント・プラットフォームのための、３つの異なる実行コード・フォーマット内に適宜伝達される。
【００４２】
図４を参照する。サーバ・コンパイラ（２１６）は、ソフトウェア・プログラムを備える。該ソフトウェア・プログラムは、何らかのサポートされたプログラム言語で書かれたソース・コードを、適宜サポートされた実行フォーマットに変換する。図４に示すとおり、ソース・コードは、プログラム言語の中でも特にJava、C#、JavaScript、及びＸＭＬなどで書かれる。サポートされた実行フォーマットとしては、クライアント・プラットフォームによるが、特にJava バイトコード、.NET CLR バイトコード、Flash バイトコードが挙げられる。例えば、クライアント・プラットフォームがJava仮想マシン（３６０）を動作させているとき、入力ソース・ファイルは全て、書かれている言語に関わらず、サーバ・コンパイラ（２１６）によってJava バイトコード実行ファイルにコンパイルされる。同様に、クライアント・プラットフォームが、.NET CLRを動作させるときは、全てのソース・コード・ファイルは.NET CLR バイトコードにコンパイルされる。
【００４３】
サーバ・コンパイラ（２１６）は、複数の特定の汎用コンパイラ、特に、汎用Java バイトコード・コンパイラ（３１２）、汎用.NET CLR(Common Language Runtime )コンパイラ（３１４）、汎用JavaScriptコンパイラ（３１６）、汎用Flash SWFコンパイラ（３１８）、汎用XMLコンパイラ（３２０）を備える。サーバ・コンパイラ（２１６）はまた、サーバ・コンパイラ・制御ロジック（３１０）を備える。サーバ・コンパイラ制御ロジック（３１０）は、クライアント・プラットフォームの種類を検知するとともに、クライアント・プラットフォームの適切な実行コードへのコンパイル並びにキャッシングを実施し、また適切な実行コードを対応するクライアント・プラットフォームに伝達する。サーバ・コンパイラ（２１６）が任意のクライアント・マシンから要求を受け取ると、制御ロジック（３１０）は、まず該クライアント・マシンを特徴付けて、どのJava仮想マシンフォーマットが該クライアント・マシンによりサポートされているかを特定する。サポートされたフォーマットのコンパイルされた実行コードが、サーバ・キャッシュ（２１８）で利用可能であって、且つソース・ファイルが最新のコンパイルから変更されていない場合は、サーバ・コンパイラ制御ロジック（３１０）は、キャッシュされた実行コードを、直接クライアント・マシンに送る。ソース・ファイルが、最新のコンパイルから変更されている場合は、制御ロジック（３１０）は、サーバ・コンパイラ（２１６）にプロンプトする。これにより、制御ロジック（３１０）は、該ソース・ファイルを検索するとともに、該ソース・ファイルを適切な実行コードにコンパイルし、該実行コードをサーバ・キャッシュ（２１８）内にキャッシュし、また実行コードを該クライアント・マシンに送信する。
【００４４】
各汎用コンパイラは、任意のプログラム言語で書かれた入力ファイルを受信する。該プログラム言語としては、Java、C#、JavaScript、C+、C++、Visual Basicが挙げられる。各汎用コンパイラはまた、クライアント・プラットフォーム固有の実行フォーマットで書かれた出力ファイルを伝達する。入力ファイル（３０２）、（３０４）、（３０６）及び出力ファイル（３３２）、（３３４）、（３３６）、（３４０）は、ＸＭＬで書かれたマークアップ・ドキュメントを更に備えてもよい。
【００４５】
図４Ａの例を参照する。汎用Javaバイトコード・コンパイラ（３１２）は、ソース・コード・ファイルを受信する。該ソース・コード・ファイルは、Java（３０２）、C#（３０４）、JavaScript（３０６）などのプログラム言語で書かれている。該ソース・コード・ファイルはまた、Java仮想マシンで実行可能なJavaバイトコード・ファイル（３３２）を伝達する。汎用Javaバイトコード・コンパイラ（３１２）は、複数のカスタム開発の言語コンパイラ（例えばJavaScriptコンパイラ（３５３））、複数の市販の言語固有コンパイラ（例えばJavaコンパイラ（３５１）、J#コンパイラ（３５２）、C#コンパイラなど）、及び制御ロジック（３５５）を含む。Javaコンパイラ（３５１）はカリフォルニア州Santa ClaraのSun Microsystems社から購入可能であり、J#コンパイラ（３５２）はワシントン州Redmondのマイクロソフト社から購入可能である。JavaScriptコンパイラ（３５３）は、Nexaweb社によりカスタム開発される。JavaScriptコンパイラ（３５３）はJavaScriptファイルをJavaバイトコードにコンパイルする。同様に、汎用.NET CLRコンパイラ（３１４）、汎用JavaScriptコンパイラ（３１６）、汎用Flash SWFコンパイラ（３１８）は、プログラム言語で書かれた入力ファイルを受信するとともに、バイトコード・ファイルを伝達する。該バイトコード・ファイルは、それぞれ.NET CLRエンジン、JavaScriptエンジン、Flashプレイヤで書かれている。制御ロジック・モジュール（３５５）は様々なプログラム言語コードを取り扱うためのルールを含むとともに、入力ファイルを処理する。入力ファイルが受信されると、制御ロジック・モジュール（３５５）はソース・コードがどの言語で書かれているかをチェックし、適切な言語固有コンパイラを選択する。該言語固有コンパイラは、ソース・コード・ファイルを、所望の実行フォーマットの実行コードにコンパイルする。例えば、汎用Javaバイトコード・コンパイラ（３１２）の制御ロジック（３５５）ならば、JavaScriptコンパイラ（３５３）を選択してJavaScriptソース・ファイルをコンパイルし、Javaコンパイラ（３５１）を選択してJavaソース・ファイルをコンパイルする。
【００４６】
図４Ｂを参照する。汎用ＸＭＬコンパイラ（３２０）は様々なマークアップ言語を用いて書かれたファイルを受信する。このマークアップ言語としては例えば、XHTML（３６２）、x-Forms（３６４）、HTML（３６５）、XAML（３７０）、SVG（３６８）が挙げられる。汎用ＸＭＬコンパイラは（３２０）はまた、XMLコード（３４０）を伝達する。XMLコード（３４０）は、XML実行エンジン（３６６）により実行される。汎用ＸＭＬコンパイラ（３２０）は、複数のマークアップ言語固有コンパイラ及び制御ロジック（３５５）を備える。このマークアップ言語固有コンパイラとしては例えば、XHTMLコンパイラ（３７１）、XAMLコンパイラ（３７２）、SVGコンパイラ（３７３）、制御ロジック（３５５）が挙げられる。制御ロジック（３５５）は、マークアップ言語固有コンパイラを選択並びに起動するとともに、ソース・ファイルをコンパイルする。該ソース・ファイルは特定のマークアップ言語で書かれている。該言語固有コンパイラは、マークアップ・ドキュメントを取得するとともに、該マークアップ・ドキュメントを新たなマークアップ・ドキュメントに変換する。この新たなマークアップ・ドキュメントは、該実行エンジンが要求する実行フォーマットで書かれている。例えば、もし実行エンジンがＳＶＧレンダリング・エンジン（どのようにSVGをレンダリングするかを知っている）であり、且つソース・コード・ファイルがXAMLを用いて書かれているならば、XAMLコンパイラはXAML入力を取得し、これをＳＶＧフォーマットに変換する。このコンパイル工程は、ＸＭＬスタイルシート変換（XML Stylesheet Transformation、XSLT）或いは他の字句分析及び変換を用いて可能になる。
【００４７】
図４に示すごとく、コンパイルされたバイトコード・ファイル（３３２）、（３３４）、（３３６）、（３４０）が、サーバ・キャッシュ（２１８）内に記憶されてもよい。クライアント・マシン（２２０）のＣＲＥ（２２４）が特定のファイルを要求すると、ＳＲＥ（２１４）はＣＲＥ（２２４）の特定の実行フォーマットを決定する。この特定のフォーマットが、既にコンパイルされて、サーバ・キャッシュ（２１８）内に記憶されているか否かをチェックする。該特定のコンパイルされたバイトコードが、サーバ・キャッシュ（２１８）内に存在し、且つ該コードが最後にコンパイルされてから変更されていないならば、ＳＲＥ（２１４）は、該実行ファイルをＣＲＥ（２２０）にダウンロードし、これをクライアント・キャッシュ（２２６）内に記憶させる。もしそうでない場合は、ＳＲＥ（２１４）は、サーバ・コンパイラ（２１６）を動作させ、まず特定の実行フォーマットの要求されたコードをコンパイルし、その後これをＣＲＥ（２２４）にダウンロードするとともに、クライアント・キャッシュ（２２６）内に記憶させる。
【００４８】
本発明は、オブジェクト指向のプログラミング方法論を利用して、オブジェクト指向のアプリケーション・プログラムを開発するものである。オブジェクト指向のアプリケーション・プログラムは通常、「オブジェクト・モデル」を用いて、問題をモデル化する。オブジェクト・モデルは、該問題の要素を表現するオブジェクトのクラスを定義する。オブジェクトのクラスは、該クラスと、その他のクラス、該クラスのオブジェクトと関連するデータとプロパティ（或いは属性）、及び該クラスのオブジェクト上で実行可能なオペレーション（或いはタスク）との関連で定義される。オブジェクト指向のアプリケーション・プログラムの実行中に、該オブジェクト・モデル内のクラスのインスタンス（実際のオブジェクト）（以下「オブジェクト」という）が作られるとともに操作される。これら「オブジェクト」についての処理は、これら「オブジェクト」と関連するビジネス・ロジック要素内に定義される「メソッド」を要求することにより行われる。例えば、口座管理プログラムでは、様々な口座がプログラム・オブジェクトとして定義される。各オブジェクト、すなわち口座は、口座名、口座番号、該口座の預金量などの属性を備える。これらの口座オブジェクトと関連するタスクを、「get account number」、「set account name」、「set account amount」などとしてもよい。オブジェクトは、イベント或いはメッセージを介して、互いと相互作用するとともに、また該ビジネス・ロジック・コードと相互作用する。オブジェクトは、イベントを発火（或いはメッセージを送信）してもよい。これにより、該オブジェクトは自身のプロパティ或いは状態を変更する。イベントは、これらオブジェクトと関連する、サブプログラム或いはビジネス・ロジック要素により、受信並びに処理される。オブジェクト指向のプログラム言語は、当技術分野ではよく知られている。また、「Programming languages」（第１１章、４３５−４８３ページ、Robert W. Sebesta編集）に記述されている。
【００４９】
図５を参照する。オブジェクト指向アプリケーション・コード（４００）は、１つ若しくはそれ以上のマークアップ・ドキュメント（４０２）及び１つ若しくはそれ以上のビジネス・ロジック要素（４０６）を備える。マークアップ・ドキュメント（４０２）は、ＸＭＬマークアップ言語を用いて書かれたファイルである。ビジネス・ロジック要素（４０６）はプログラム・オブジェクト上でタスクを実行するための指示を含む。これら指示は、プログラム言語（例えばJava、JavaScript、C#、Visual Basic(VB)、J#など）で書かれたソース・コード・ファイルとして形成される。ビジネス・ロジック要素（４０６）もまたプログラム・オブジェクトである。クライアント・ランタイム環境（Client Runtime Environment, CRE）（２２４）は、マークアップ・ドキュメント（４０２）を受信するとともに、これらをオブジェクト指向表現、すなわちマークアップ・オブジェクト（４０４）に変換する。マークアップ・オブジェクト（４０４）は、ユーザ・インターフェース（User Interface、ＵＩ）（４０１）或いはデータ（４０３）であってもよい。マークアップ・オブジェクト（４０４）それぞれが、該オブジェクトと関連するイベントを備えてもよい。例えば、入力フィールド又はボタンを備えるＵＩマークアップ・オブジェクトの場合のイベントとしては、ボタン若しくは入力フィールドをハイライトする、該フィールドにテキストを入力する、或いは該ボタンをクリックするなどが挙げられる。該イベントは、該ビジネス・ロジック要素により受信されるとともに処理される。これにより、該オブジェクトの状態が変更される。ユーザ・インターフェースが入力フィールドを備えて、テキストが該入力フィールドに入力される例では、ビジネス・ロジック要素は該ＵＩを変更して入力されたテキストを表示する。マークアップ・ドキュメント（４０５）及びビジネス・ロジック要素（４０６）のオブジェクト指向表現は、マークアップ・ビジネス・ロジック・バインディング機構を介してバインディングされている。
【００５０】
図６を参照する。マークアップ・ビジネス・ロジック・バインディング機構（５００）は、マークアップ・オブジェクトをビジネス・ロジック要素にバインディングする段階（５２０）と、該ビジネス・ロジック要素をマークアップ・オブジェクトにバインディングする段階（５３０）を備える。マークアップ・オブジェクトをビジネス・ロジック要素にバインディングする段階（５２０）では、マークアップ・ドキュメント（５５０）内に定義されたマークアップ・オブジェクト（５１０）は、ビジネス・ロジック要素（５４０）を動作させる。該動作は、マークアップ・オブジェクト・イベント（５２１）を発火することにより行われる。ビジネス・ロジック要素（５４０）は、マークアップ・オブジェクト・イベントのためのイベント・ハンドラとして用いられるメソッドの定義を含む。イベントを発火すると同時に、ＣＲＥは対応するビジネス・ロジック要素内の、関連するメソッドを起動させるとともに、該イベントに関する必要な情報を該メソッドに受け渡し、また該メソッドを実行する。いくつかの入力フィールドを備えるユーザ・インターフェース・マークアップ・オブジェクトの前記の例では、イベントの発火は、ユーザの電話番号を適切な入力フィールドに入力することにより行われてもよい。該ビジネス・ロジック要素は、このマークアップ・オブジェクト・イベントを受信するとともに、その妥当性を検査し、そして該電話番号を表示に適するように整形する。
【００５１】
ビジネス要素をマークアップ・オブジェクトにバインディングする段階（５３０）では、ビジネス・ロジック要素（５４０）は、マークアップ・オブジェクト・アプリケーション・プログラム・インターフェース（Application Program Interface、API）或いはドキュメント・オブジェクト・モデル（Document Object Model、DOM）ＡＰＩを介して、マークアップ・オブジェクト（５１０）にアクセス可能であり、また該マークアップ・オブジェクト（５１０）を変更可能である。一つの実施形態では、ＣＲＥ（２２４）は、マークアップ・ドキュメント（５５０）をパースするとともに、ＤＯＭ内に記憶させる。ＣＲＥ（２２４）はまた、このＤＯＭをビジネス・ロジック要素（５４０）により動作可能な一連のＡＰＩとして公開する。ビジネス・ロジック要素（５４０）はこのＤＯＭ  ＡＰＩを動作させて、該ＤＯＭ内に記憶されたマークアップ・ドキュメント（５５０）をプログラムで操作する。このマークアップ・オブジェクトＡＰＩ（５３１）を介したフィードバック機構は、「フォームの妥当性検査」段階、或いはマークアップ・オブジェクト（５１０）の変更に至る内部処理段階であってもよい。「フォームの妥当性検査」段階の例では、ユーザは該ＵＩに３桁の電話番号を入力する。ビジネス・ロジック要素がこの３桁の電話番号が妥当でないと認識すると、入力を受け入れないとともに該ＵＩ内にエラーを表示する。該ビジネス・ロジック要素はまた、妥当な電話番号を要求する。
【００５２】
双方向バインディング機構（５００）は、ビジネス・ロジック、表現、及びデータを明確に分離することを可能にする。ウェブ・ブラウザでのＨＴＭＬとJavaScriptの双方向モデルは、同様の構造を共有する。しかしながら、本発明は、オブジェクト指向バインディングを可能にするという点で、これら先行技術のモデルと異なる。マークアップ・ドキュメントはオブジェクト指向表現（マークアップ・オブジェクト）に変換され、またビジネス・ロジック要素もプログラム・オブジェクトとなる。オブジェクト指向バインディングは、その後、これらオブジェクト（すなわちマークアップ・オブジェクト及びプログラム・オブジェクト）間でバインディングを行う。先行技術の例では、ビジネス・ロジックは、スクリプトとして書かれている。該スクリプトはオブジェクト指向ではない。また、バインディングはＨＴＭＬオブジェクトに対するプログラム・メソッド間で行われる。本発明においては、このオブジェクト指向バインディングは、複雑なアプリケーションの開発を可能にするとともに、プログラム言語及び実行フォーマットの独立性を提供する。換言すると、ビジネス・ロジック・コードは任意のプログラム言語で書かれてよい。該プログラム言語としては、Java、JavaScript、C#、J#、VB、C+などが挙げられる。マークアップ・ドキュメントは任意のマークアップ言語で書かれてよい。該マークアップ言語としてはXML、テキスト、HTML及びその他が挙げられる。プログラム言語がオブジェクト指向でない場合は、ソース・コードが、汎用コンパイラによってオブジェクト指向実行コードにコンパイルされてもよい。いくつかのＸＭＬ仕様（XUL（XML User Interface Lnaugage）、SVG（Scalable Vector Graphics）、XFromsなど）を用いてもよい。これらＸＭＬ言語の組み合わせによって、全てのネットワーク・アプリケーションの全ての機能をサポートする機能性に富んだ環境が作られる。これらネットワーク・アプリケーションとしては、通常のWindows グラフィカル・ユーザ・インターフェース、フォーム、２Ｄグラフィックス、及びアニメーションなどが挙げられる。
【００５３】
図７に、マークアップ・ビジネス・ロジック・バインディング機構（５００）のコード例（６００）を示す。マークアップ・ドキュメント（６１０）はＸＭＬを用いて書かれている。マークアップ・ドキュメント（６１０）はクライアントサイド・ロジック・オブジェクト「bean1」（６２１）、親ボタン「parentBtn」（６３２）、子ボタン「childBtn」（６３５）、データ・オブジェクト「companyInfo」（６４１）を定義する。クライアントサイド・ロジック・オブジェクト「bean1」（６２１）はクライアントサイド・プログラム・オブジェクトを定義する。該クライアントサイド・プログラム・オブジェクトのソース・コードは「com.nexaweb.clientbean.DemoBean」である。該ソース・コードは、ビジネス・ロジック要素（６５０）とこのマークアップ・ドキュメントを効果的に関連付ける。ビジネス・ロジック要素（６５０）のためのソース・コードはJavaプログラム言語を用いて書かれているとともに、Javaクラスを３つの異なるメソッド（「init」（６６０）「doClick」（６７０）「doOver」（６８０））で定義する。マークアップ・オブジェクトをビジネス・ロジック要素にバインディングする段階（５２０）は、ビジネス・ロジック要素（６５０）の３つのメソッド（６６０）、（６７０）、（６８０）を、３つのマークアップ・オブジェクト（６２１）、（６３２）、（６３５）により発火されるイベントのためのイベント・ハンドラとして用いることにより、実現される。メソッド（６６０）は、マークアップ・オブジェクト（６２１）のためのイベント「onload」を処理する。メソッド（６７０）は、親ボタン（６３３）のためのイベント「oncommand」を処理する。メソッド（６８０）は、子ボタン（６３５）のためのイベント「onmouseover」を処理する。これらのイベントが起こると常に、ＣＲＥは、該ビジネス・ロジック要素内の対応するメソッドを動作させて、これを処理する。該ビジネス・ロジック要素をマークアップ・オブジェクトにバインディングする段階（５３０）の例を、ビジネス・ロジック要素（６５０）内の、該３つのメソッド（６６０）、（６７０）、（６８０）の実施例として示す。例えば、ＣＲＥにより公開されるＤＯＭ  ＡＰＩを用いて、「doClick」メソッド（６７０）はイベント情報を検査するとともに、イベント・ソース（ユーザがクリックしたマークアップ・オブジェクトでなければならない）を検索し、そしてこのマークアップ・オブジェクトの属性「text」を処理結果として設定する。例えば、親ボタン・オブジェクト（６３２）をクリックすると、テキスト「You clicked button: parentBtn」がＵＩスクリーン（６３３）に表示される（図７Ａ参照）。同様に、子ボタン・オブジェクト（６３５）をクリックすると、テキスト「You clicked butoon:childBtn」がＵＩスクリーン（６３６）に表示される（図７Ｂ参照）。
【００５４】
図８に、本発明がどのようにしてオブジェクト指向マークアップ・オブジェクト継承を実現するかを示す。この処理は、マークアップ・ドキュメントの作成及び管理を大幅に簡略化するとともに、マークアップ・ドキュメントの自由度を向上させる。親マークアップ・オブジェクト（７１０）は、ユーザ・インターフェース定義（７２０）、オブジェクト固有データ定義（７３０）、及びオブジェクト動作（或いはイベント・ハンドラ）定義（７４０）を含む。子マークアップ・ドキュメント（７５０）はユーザ・インターフェース定義（７６０）、オブジェクト固有データ定義（７７０）、及びオブジェクト動作（或いはイベント・ハンドラ）定義（７８０）を含む。子マークアップ・オブジェクト（７５０）は、親マークアップ・オブジェクトから、これらＵＩの全てと、データ、動作定義（７６０）、（７７０）、（７８０）それぞれを継承する。若しくは、子マークアップ・オブジェクト（７５０）は対応する親定義を上書きして新たな定義を追加してもよい。このオブジェクト指向アプローチは、オブジェクト属性の継承並びに変更を可能にするだけでなく、全く異なるオブジェクト動作を可能にする。これは、親オブジェクトのイベント・ハンドラ定義を子固有イベント・ハンドラに置換することにより行われる。図７のコード例に戻る。「childBtn」（６３５）は「parentBtn」（６３２）から、全ての定義（ＵＩ，データ、及び動作）を継承する。しかしながら、マークアップ・オブジェクト固有データは変更される。すなわち、「id」が「parentBtn」から「chileBtn」に変更される。同様に該ユーザ・インターフェース定義が変更される。すなわち属性「text」の値が変更されて、「You clicked button: parentBtn」に替わって「You clicked button: childBtn」が表示される。「childBtn」は「parentBtn」からオブジェクト動作を継承する。また、イベント「oncommand」は、子マークアップ・オブジェクトのためのメソッド「bean1.doClick ()」（６７０）を動作させる。子マークアップ・オブジェクト（７５０）もまた、親マークアップ・オブジェクト（７１０）の動作定義を変更する。該変更は、イベント「onmouseover」に対するメソッド「bean1.doOver ()」（６８０）をバインディングすることにより行われる。また該バインディングにより、イベント「onmouseover」は親マークアップ・オブジェクトのためのメソッド「bean1.doOver ()」（６８０）を動作させる。
【００５５】
アプリケーション・プログラムは通常、多ギガバイトファイルである。このような容量の大きいファイルをメモリにロードすると、長時間の遅滞を招くとともに、ハードウェア要素に多大な負担をかける。これは高速のＣＰＵ、大きなメモリ、大きなストレージ、及び高速のネットワークが必要となるからである。これら全てはコストがかかるのに加えて、性能の問題がある。本発明はこれら問題を、アプリケーション・コードを独立した小さなモジュールに分離することにより解決する。独立した小さなモジュールそれぞれは、別個にダウンロード並びに実行可能である。図９を参照する。アプリケーション・コード（４００）はＮ個のモジュール（モジュール１（４１０）、モジュール２（４５０）、モジュール３（４８０）、...モジュールＮ（図示せず））を備える。各モジュールは、１つ若しくはそれ以上のマークアップ・ドキュメントを備えるとともに、選択的に１つ若しくはそれ以上のビジネス・ロジック要素を備える。図９の例においては、モジュール１（４１０）はマークアップ・ドキュメント（４２０）とビジネス・ロジック要素Ａ（４３０）及びビジネス・ロジック要素Ｂ（４４０）を備える。マークアップ・ドキュメント（４２０）は２つのマークアップ・オブジェクト（すなわちユーザ・インターフェース（ＵＩ）（４２２）及びデータ・ファイル（４２４））を定義する。モジュール２（４５０）はビジネス・ロジック要素Ｃ（４７０）及びマークアップ・ドキュメント（４６０）を備える。マークアップ・ドキュメント（４６０）は、ユーザ・インターフェース（４６２）及びデータ・ファイル（４６４）を定義する。モジュール３（４８０）は、ビジネス・ロジック要素Ａ（４３０）、ビジネス・ロジック要素Ｅ（４９４）、及びマークアップ・ドキュメント（４９０）を備える。マークアップ・ドキュメント（４９０）は、ユーザ・インターフェース（４９２）及びデータ・ファイル（４９３）を定義する。複数の異なるモジュールがビジネス・ロジック要素を共有してもよい。例えば、モジュール３（４８０）は、モジュール１（４１０）と同じビジネス・ロジック要素Ａ（４３０）を用いる。この場合、図３のシステム（２００）は、サーバサイド・キャッシング（２１６）に加えて、クライアント・サイド・キャッシング（２２６）を用いる。これにより、同一のモジュール或いは要素を２度以上ロードすることを防止する。以上のように、アプリケーション・コード（４００）全体が、多数のＸＭＬドキュメント及び多数のビジネス・ロジック要素からなるが、各モジュールは１つのＸＭＬドキュメントと、数個のコンパイルされたビジネス・ロジック要素しか必要としない。したがって、各モジュールには小さな領域しか必要としない。各モジュールが小さな領域しか必要としないことで、アプリケーション・コードを高速でダウンロードすることが可能となる。更に、一度モジュールがクライアント・マシンにダウンロードされると、該モジュールは該クライアント・キャッシングに記憶されるので、以降新たなダウンロードなしに再利用可能である。サーバはまた、既にクライアント・マシンにダウンロードされるとともにクライアント・キャッシュに記憶されていたモジュールの自動更新を行う。
【００５６】
図１０を参照する。クライアント・マシンを介してアプリケーションを動作する段階（８００）は、以下の段階からなる。ユーザがネットワーク・アプリケーションを使おうとすると、ユーザはＣＲＥを開始して、クライアント・プログラムを開始するという要求を入力する（８０２）。ＣＲＥは、要求を受信して（８０４）、初期モジュールが、ローカル・クライアント・キャッシュ内で利用可能であるか否かをチェックする（８０６）。モジュールがローカル・キャッシュ内で利用可能である場合（８０７）は、ＣＲＥはサーバ（ＳＲＥ）に要求を送信して、特定のモジュールをダウンロードさせる（８０８）。サーバは、ＣＲＥに対する特定のモジュールを記述するマークアップ・ドキュメントを伝達する（８１０）。ＣＲＥはこのマークアップ・ドキュメントがキャッシュされる必要があるか否かを問い合わせる（８１２）。この問い合わせは、ドキュメント・プロパティ或いはコンフィギュレーション情報をチェックすることにより行われる。このマークアップ・ドキュメントがキャッシュされる必要がある場合（８１３）は、ＣＲＥはこれをローカル・クライアント・キャッシュ内にキャッシュ（８１４）した後、次の質問に進む（８１５）。同様に、マークアップ・ドキュメントがローカル・クライアント・キャッシュ内にキャッシュされる必要がない場合（８１１）も、ＣＲＥは次の質問に進む（８１５）。モジュールがローカル・キャッシュ内で利用可能である場合（８０９）も、ＣＲＥは、ダウンロードする段階を省略して、次の質問に進む（８１５）。次に、ＣＲＥはモジュール・プロパティ或いはコンフィギュレーション情報をチェックして、このモジュールがビジネス・ロジック要素を必要とするか否かを確認する（８１６）。ビジネス・ロジック要素が必要でない場合（８１５）は、ＣＲＥはユーザにモジュールを表示して（８１８）、ユーザ入力を待つ（８２０）。モジュールがビジネス・ロジック要素を必要とする場合（８１７）は、段階（８４０）が行われる。段階（８４０）では、ＣＲＥは、ビジネス・ロジック要素がローカル・キャッシュ内で利用可能であるか否かをチェックする（８２４）。ビジネス・ロジック要素が、ローカル・キャッシュ内で利用可能である場合（８２１）は、ビジネス・ロジック要素がローカル・キャッシュからアクティブ・メモリにロードされる（８２６）。ビジネス・ロジック要素がローカル・キャッシュ内で利用可能でない場合（８２３）は、ＣＲＥはサーバに要求を送信し、ビジネス・ロジック要素をダウンロードさせる（８２８）。サーバはこのビジネス・ロジック要素が予めこの特定のクライアント・マシンの実行フォーマットに合わせてコンパイルされているか否かをチェックする（８３０）。既にコンパイルされている場合（８３１）は、サーバはサーバ・キャッシュからクライアント・キャッシュに実行コードをダウンロードする。次に、ＣＲＥはクライアント・マシン・キャッシュ内に実行コードを記憶させる（８３６）とともに、該実行コードをアクティブ・メモリ内にロードする（８２６）。ビジネス・ロジック要素が予め特定のクライアント・マシンの実行フォーマットに合わせてコンパイルされていない場合（８２９）は、サーバはまず該実行フォーマットを、該特定のクライアント・マシン実行エンジンにより実行可能なコードにコンパイルするとともに、該実行フォーマットをサーバ・キャッシュ内に記憶させる（８３２）。次に、サーバは、サーバ・キャッシュからクライアント・キャッシュに、実行コードをダウンロードする（８３４）。該クライアント・キャッシュにおいて、ＣＲＥが該実行コードをクライアント・キャッシュにキャッシュ（８３６）した後、該実行コードをアクティブ・メモリにロードする（８２６）。最後に、マークアップ・ドキュメント及びビジネス・ロジック要素（８３７）がアクティブ・メモリ内に存在しており、ユーザからの入力を待つ（８２０）。特定のモジュールに関連するビジネス・ロジック要素が１つより多い場合は、段階（８４０）は個別のビジネス・ロジック要素それぞれについて繰り返される（８４１）。段階（８００）が繰り返されて、次のモジュール及びこれに関連するビジネス・ロジック要素がダウンロードされる。一度ＣＲＥがマークアップ言語ドキュメントを受信すると、該ＣＲＥは直ちに該ドキュメントを処理するとともに、関連するビジネス・ロジックを実行し、そして結果をユーザに表示する。このようにモジュール・タイプにしたがってネットワーク・アプリケーションをダウンロード及び実行する利点は、処理速度が速いことと、低い帯域幅しか必要としないことにある。予めダウンロードされたモジュール及び関連するビジネス・ロジックを、クライアントサイド・キャッシュ及びサーバ・キャッシュ内に記憶させて、クライアントサイド・キャッシュとサーバ・キャッシュを同期化することにより、クライアント・マシンがネットワーク・アプリケーションをオフラインで実行することが可能となる。該実行はネットワーク接続が利用できない場合でも可能である。
【００５７】
一度適切なモジュールがクライアント・マシンのアクティブ・メモリ内に導入されると、ユーザは、クライアント・イベントを介して、アプリケーションと直接にやり取りを行う。クライアント・イベントとしては、スクリーン・フィールドにテキストを入力する、マウスをテキスト上或いはスクリーン・ボタン上で動かす、マウスをクリックする、スクリーン内のボタンをハイライトする、ドラッグ・アンド・ドロップ、ウィンドウを隠す、新規データが利用可能などを挙げることができる。図１１は、システムがどのようにしてクライアント・イベントを取り扱うか（９００）を表す。クライアント・イベントが実行されると（９０２）ＣＲＥは、このイベントを傾聴しているリスナがあるか否かをチェックする（９０４）。このイベントを傾聴しているリスナがない場合（９０７）は、ＣＲＥは新たなクライアント・イベントを待つ（９１０）。このイベントを傾聴しているリスナがある場合（９０５）は、ＣＲＥは該リスナがクライアント・サイドのビジネス・ロジック要素であるのか、サーバサイド・イベント・ハンドラであるのかを決定する（９０６）。該リスナがクライアントサイド・ビジネス・ロジック要素である場合（９１１）は、ＣＲＥはこのクライアントサイド・ビジネス・ロジック要素のインスタンスが生成されているか否か、すなわち該ビジネス・ロジック要素がメモリ内で作り出されるとともに初期化されているか否かをチェックする。クライア（９１２）ントサイド・ビジネス要素のインスタンスが生成されていない場合（９１５）は、ＣＲＥは該ビジネス要素をキャッシュからロードして、このインスタンスを生成する（９２２）。クライアントサイド・ビジネス要素のインスタンスが生成されている場合は、ＣＲＥは該インスタンスを配置するとともに、登録されたリスナ・メソッドを動作させる（９２６）。該メソッドはこのイベントを取り扱う。ＣＲＥはクライアントサイド・ビジネス要素リスナ・メソッドにしたがってイベントを処理するとともに、結果を出す（９２８）。次に、ＣＲＥは、該結果がマークアップ・ドキュメントであるのか、或いはＡＰＩを介しての直接のクライアントＤＯＭ操作であるのかをチェックする（９３０）。該結果がマークアップ・ドキュメントである場合（９３３）は、ＣＲＥはマークアップ・ドキュメントを処理（９１８）するとともに、結果を表示する（９２０）。該結果がＡＰＩを介しての直接のクライアントＤＯＭ操作である場合（９３１）は、ＣＲＥはＡＰＩコールを実行（９３２）するとともに、結果を表示する（９２０）。ＤＯＭの変更は、アプリケーション状態の変更につながる。該変化は、ユーザ・インターフェースを介して入力された変更であっても、内部でのデータの変更であってもよい。システムはその後、新たなクライアント・イベントを待つ（９１０）。クライアントサイド・リスニング要素としては例えば、クライアントサイド・ビジネス・ロジック要素、マークアップ・ドキュメントで定義されたマクロ・ステートメント、ローカルＵＲＬの呼び出しが挙げられる。サーバサイド・イベント・ハンドラとしては例えば、Java server page（Javaサーバ・ページ）、ウェブ・サービス要求、servelet、Active Server Pageが挙げられる。一��の例では、アプリケーションの状態は、ＸＭＬドキュメント・オブジェクト・モデル（Document Object Model、DOM）で維持される。このＤＯＭはＣＲＥ及びサーバによってクライアント・サイドに維持される。ユーザがアプリケーションとやり取りをすると、ＣＲＥは、ユーザの入力にしたがってクライアント・サイドＤＯＭを更新する。アプリケーションのサーバサイド・ビジネス・ロジックが、アプリケーションの状態の変更（例えばウィンドウを隠す）を命令すると、サーバは自動的にサーバサイドＤＯＭを更新する。クライアント・サイドＤＯＭ或いはサーバサイドＤＯＭのいずれかが更新されるといつも、ＣＲＥ或いはサーバのいずれかが対応する相手にメッセージを送信して、そのＤＯＭをそれぞれ同期化する。ネットワークの接続が切断されても、ビジネス・ロジック・コード及びマークアップ・ドキュメントがクライアント・サイドにキャッシュされているため、アプリケーションは利用可能なままとなる。また、アプリケーションの状態もクライアント・サイドで利用可能である。アプリケーションの状態の変更は、ＤＯＭ内に維持される。ネットワーク接続が利用可能になると、クライアント・ランタイム及びサーバ・ランタイムは自動的にＤＯＭを同期化する。
【００５８】
他の実施形態もまた以下の請求の範囲内にあるものとする。例えば、一度に１つのモジュールをダウンロードするかわりに、サーバはモジュールの群を一まとめにするか、或いは全てのモジュールを一まとめにするかして、１つの配備モジュールにパッケージして、この配備モジュールをクライアント・マシンにダウンロードしてもよい。これは特に、オフラインでのコンピュータの利用において有用である。オフラインでの利用では、要求された全てのオフラインでのコンピュータ利用の機能性及びデータが１つの配備モジュールにパッケージ可能であるとともに、直ちにクライアント・マシンにダウンロード可能である。このようなダウンロードの後は、更なるモジュール或いはデータが要求されるまでは、該配備モジュールは、接続なしにクライアント・マシン上で動作可能となる。
【００５９】
本発明のいくつかの実施形態を説明してきた。しかしながら、本発明の本質及び範囲を離れることなく、様々な変更が可能であることが理解されるであろう。したがって、他の実施形態も以下の請求の範囲内にある。
【図面の簡単な説明】
【００６０】
【図１】アプリケーションの書き込み、コンパイル及び実行の従来の処理のブロック線図である。
【図２】ネットワーク・ベースの処理システムの例である。
【図３】単純なネットワーク・ベースの処理システムのソフトウェア並びにハードウェア要素のブロック線図である。
【図４】図３のアプリケーション・サーバのサーバ・コンパイラの概略的な線図である。
【図４Ａ】図４の汎用Javaバイトコード・コンパイラの詳細なブロック線図である。
【図４Ｂ】図４の汎用XMLコンパイラの詳細なブロック線図である。
【図５】本発明に係るオブジェクト指向アプリケーションのブロック線図である。
【図６】本発明のマークアップ・ビジネス・ロジック・バインディング機構の概略的な線図である。
【図７】マークアップ・ビジネス・ロジック・バインディング機構のコード例である。
【図７Ａ】図７の例のスクリーン・ショットである。
【図７Ｂ】図７の例の他のスクリーン・ショットである。
【図８】オブジェクト指向マークアップ・オブジェクト宣言及び具体化の概略的な線図である。
【図９】本発明に係るネットワーク・ベースのアプリケーションのモジュール構造の概略的な線図である。
【図１０】本発明に係るネットワーク・ベースのアプリケーションの配備、コンパイル並びに実行のプロセスのフロー線図である。
【図１１】本発明の、イベント取扱い処理のフロー線図である。
【図１】
2007524875.tif 000003
【図２】
2007524875.tif 000004
【図３】
2007524875.tif 000005
【図４】
2007524875.tif 000006
2007524875.tif 000007
2007524875.tif 000008
【図５】
2007524875.tif 000009
【図６】
2007524875.tif 000010
【図７】
2007524875.tif 000011
2007524875.tif 000012
【図８】
2007524875.tif 000013
【図９】
2007524875.tif 000014
【図１０】
2007524875.tif 000015
【図１１】
2007524875.tif 000016