JP2006195979A - ウェブアプリケーションアーキテクチャ - Google Patents

Abstract

【課題】第１のコンピュータと第２のコンピュータとの間の通信方法および通信プロトコルを提供する。
【解決手段】プロトコルは、第１のコンピュータから第２のコンピュータへのリクエストを含み、リクエストは、第２のコンピュータ上にある関数用の関数識別子と、関数用の引数とを含む。引数は、関数識別子により呼び出される関数用の型によって定義される。プロトコルはまた、第２のコンピュータから第１のコンピュータへのレスポンスを含み、レスポンスは、関数の結果を含むものであって、第１のコンピュータのためのスクリプト入力として定義される。
【選択図】図４

Description

本発明は、ネットワークベースアプリケーションを提供することに関し、特にインターネットおよびウェブベースアプリケーションを提供することに適用できる。

インターネットベースアプリケーションがより強力になりつつあり、シームレスで反応の早いユーザ経験を維持することが開発者にとって重要な特徴となってきている。ウェブベースアプリケーションは一般に、クライアントコンピュータ上で実行されているウェブブラウザを使用してアクセスされ、サーバ上で提供される１つまたは複数の関数を含む。クライアント（ウェブブラウザ）およびサーバが高速で通信するために、これらの間で効率的な通信プロトコル（一般には、ＨＴＴＰ）を使用することが必要とされる。

通常、ウェブブラウザは、サーバからページおよび関数（通常はＨＴＭＬなどのマークアップ言語という形で）を受け取ることにより、アプリケーション、または、そのアプリケーションの機能的要素にインターフェースを提供する。場合によっては、ブラウザは、サーバに配置されたページに対するリクエストに各々応答して、受信したデータの新しいページを表示しなければならない。そのような情報を提供するための１つの一般的なフォーマットは、ＨＴＴＰ（Hyper Text Transfer Protocol）である。通常、ウェブブラウザは、ＨＴＴＰにおいて「ＧＥＴ」または「ＰＯＳＴ」コマンドを使用してウェブページをリクエストし、ページを表示するために必要とされる情報のすべてがウェブブラウザに返される。ユーザがページの一部分を更新しているだけであっても、ページを表示するために必要とされる情報などの一部のデータは何回も繰り返し受信される。ウェブブラウザからの単純なデータリクエストを更新することにより、ページの一部分のみのデータを更新する技術が開発されてきてはいるが、このようなプロトコルは、ウェブアプリケーション内で利用可能な内在的メソッドに対して開発者がフルアクセスできるようにする上で、完全に柔軟性があるとはいえない。

ブラウザが、リモートサーバ上のクラスおよびオブジェクトのメソッドをリモートで呼び出すことを可能にする現行のクライアント−サーバプロトコルの例には、ＳＯＡＰ（Simple Object Access Protocol）およびＸＭＬ−ＲＰＣが含まれる。ＳＯＡＰおよびＸＭＬ−ＲＰＣの双方が、クライアントが伝送データ型（transport data type）を理解するよう要求する。双方とも、ＸＭＬ形式でパラメータを符号化し、ＸＭＬ形式で値を返す標準方式を規定しており、共通ネットワークプロトコルを介してそれらの値を渡す。ＳＯＡＰおよびＸＭＬ−ＲＰＣは、サーバからサーバへの通信およびシッククライアントからサーバへの通信のために主に使用される。これらは、いずれも冗長なプロトコルであり、必ずしも効率的であるとはいえない。特に、ＳＯＡＰは、サーバから受信したデータを理解してクライアントで利用できるようにするため、クライアント上に比較的複雑なメカニズムを要求する。これは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔなどの単純なスクリプト言語で実現するのは難しい場合がある。ウェブブラウザにおいてＪａｖａ（登録商標）Ｓｃｒｉｐｔを使用する利点の１つは、ほとんどすべてのウェブブラウザアプリケーションが、スクリプトを実行することができるスクリプトエンジンを含んでいることである。ウェブブラウザのスクリプトエンジンを使用することにより、アーキテクチャのクライアント側でのカスタマイズをそれほど必要としない。

したがって、ウェブベースアプリケーションを起動するためのウェブブラウザとクライアントと間の通信を改善する方法があれば効果的である。

第１のコンピュータと第２のコンピュータとの間の通信方法および通信プロトコルが、クライアント−サーバ環境においてネットワークアプリケーションを提供するシステムとともに、開示されている。

一側面においては、概説すると、本発明はクライアント−サーバ環境においてネットワークアプリケーションを提供するためのシステムを含む。一実施形態において、そのシステムは、サーバ上に一連のアプリケーション関数と、スクリプティング環境内に定義された一連のクライアント関数とを含み、そのアプリケーション関数はデータ型定義を含む。独自の特徴として、クライアント関数は、その一連のアプリケーション関数の中の各々のアプリケーション関数に合致する型を含むように定義される。

別の実施形態においては、本発明は、インターネット上でウェブアプリケーションを提供するための方法である。この方法は、定義型（defined type）を有する関数およびオブジェクトをサーバ上に含むサーバ環境を提供するステップ、サーバ環境内の対応する関数およびオブジェクトにマッピングする型を有する関数およびオブジェクトをスクリプティング環境内に含むクライアント環境を生成するステップ、および、そのサーバにそのクライアント環境を提供するステップを含むことができる。

さらに別の実施形態においては、本発明は、サーバおよびクライアントコンポーネントを初期化およびインストールして、ウェブベースアプリケーションを提供するためのシステムである。このシステムは、属性を有するオブジェクトおよびメソッドを含む一連のサーバアプリケーションを含む。コード生成器（code generator）は、前記オブジェクトおよびメソッドの各々のために、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔクライアントサイドライブラリおよびサーバサイドライブラリを提供する。サーバサイドサービスは、クライアントからのデータをサーバ上の対応するオブジェクトおよび関数に送信する、ディスパッチャ（dispatcher）およびマーシャラ（marshaler）を含む。

さらなる実施形態においては、本発明は、インターネットアプリケーションを実装するシステムである。このシステムは、各々が定義型を有する一連のアプリケーションオブジェクトおよびメソッドを含むサーバを含む。さらに、前記オブジェクトおよびメソッドを呼び出すクライアント側の一連のスクリプトを生成する生成エンジンが提供され、各スクリプトは前記一連のアプリケーションオブジェクトおよびメソッドのうち少なくとも１つのオブジェクトまたはメソッドに合致する型定義を有する。レスポンスエンジンが、クライアント処理デバイス上の１つまたは複数のスクリプトからのリクエストを受け取るために提供され、前記リクエストを前記アプリケーションオブジェクトおよびメソッドの１つに送信する。

別の側面においては、概説すると、本発明はネットワーク上で動作しているコンピュータ間で非対称に動作する通信プロトコルおよび通信方法を備える。クライアントからサーバへの通信は、データ効率性、およびサーバによる解釈のために最適化される。サーバからクライアントへの通信は、既存のクライアントアプリケーション資源を使用するクライアントによる解釈のために最適化される。

一実施形態において、本発明は、分散処理システムにおけるクライアントプロセスとサーバプロセスとの間の通信方法である。この方法は、そのクライアントプロセスによってサーバに関数リクエストを送信するステップであって、その関数リクエストはリクエストされたサーバ関数の型によって定義されたフォーマットを有するデータ列を含むステップ、そのサーバプロセスによってその関数呼び出しを受け取り、そのデータ列に基づいてそのリクエストされた関数を実行するステップ、および、そのサーバプロセスによってその関数リクエストに対するレスポンスを送信するステップであって、そのレスポンスはサーバオブジェクトにより定義されたクライアントサイド処理フォーマットの形をとるステップを含むことができる。

別の実施形態においては、本発明は、第１のコンピュータと第２のコンピュータとの間の通信プロトコルを備えることができる。このプロトコルは、第２のコンピュータ上の関数のための関数識別子と、その関数のための引数とを含む第１のコンピュータから第２のコンピュータへのリクエストを含むことができる。その引数は、その関数識別子によって呼び出される関数用の型によって定義することができる。このプロトコルはまた、その関数の結果を含む、第２のコンピュータから第１のコンピュータへのレスポンスも含むが、そのレスポンスはスクリプト入力（script input）として定義されたものでる。

別の実施形態においては、本発明は、クライアントとサーバとの間の通信方法である。この実施形態では、この方法は、サーバ上のデータ型にしたがって並べられたパラメータ列を含むリクエスト内のデータをフォーマットするステップ、ネットワークを介してそのリクエスト内のそのデータを送信するステップ、および、スクリプト入力レスポンスフォーマットにしたがってレスポンスデータをフォーマットすることによりそのデータに対するレスポンスを生成するステップを含むことができる。

ネットワーク環境におけるウェブベースアプリケーションを実装する独自のアーキテクチャが提供される。このアーキテクチャは、クライアントおよびサーバの双方に、サーバ上で利用可能なプログラミングインターフェース、関数、およびオブジェクトの一式を提供し、「プロトコル」と呼ばれる独自の通信方法で、クライアントとサーバとの間のデータ通信を最小限に抑える。この通信方法は、提供されたアプリケーションの関数を実行するためのデータを含むように最適化される。本発明を、インターネットを介して提供されるウェブベースアプリケーションへの適用性の観点から、本明細書で説明する。このアーキテクチャの適用性は、インターネット、本明細書で説明される特定の動作環境、または本明細書で説明されるコンピュータ言語に限定されるものではないことは認識されるであろう。

本発明は、本発明の実装の一実施形態として、ウェブベース電子メールサービス、および、ウェブベース電子メールサービスにおいて使用できるスペルチェック関数の提供というコンテキストにおいて例示される。例示的なアプリケーションおよび関数を有する特定の例示的なアーキテクチャによって、本発明のアーキテクチャおよびプロトコルを使用して実装することができるアプリケーションおよび関数の範囲が限定されるものではない。

このアーキテクチャは、独自の非対称なポストプロトコルおよびレスポンスプロトコルを利用する。このポストプロトコルは、型無し（non-typed）データをサーバに提供する一方で、レスポンスプロトコルは、型付きの（typed）スクリプトフォーマットの形でデータを含む。サーバ上に存在するオブジェクトおよびメソッドの各々に対応する、自動生成されたクライアントサイドライブラリが提供される。さらに独自の特徴として、軽量プロトコル（lightweight protocol）が、クライアントとサーバとの間でデータを移動させる。例示的なプロトコルが図８および１１に示されている。独自の特徴として、クライアントはサーバに送信されるデータを型付けし、サーバはそのデータのために要求された処理を行う。サーバはスクリプトの形でレスポンスを送信するが、これはデータ構造が既知であるものとして「型付けされている」。

一般に、サーバサイドおよびクライアントサイドコンポーネントを初期化し、インストールするプロセスは、サーバ上で開発され、属性を有するクラスおよびメソッドを含むアプリケーションを必要とし、そのプロセスはクライアント環境およびサーバ環境を生成する。コード生成器（本明細書では、「ＣｏｄｅＧｅｎ」と呼ばれる）は、開発されたアプリケーション内のオブジェクトおよびコンポーネントの各々のためのサーバサイドコード「プロキシ（proxy）」に加えて、本明細書ではしばしばクライアントサイドプロキシと呼ばれる、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔクライアントサイドライブラリオブジェクトおよびスタブコンポーネントを生成する。これらの環境が生成され、クライアント環境がインストールされると、ディスパッチャおよびマーシャラを含むサーバサイドサービスは、クライアント上の関数からのデータを、サーバ上の対応するオブジェクトおよび関数に送信する。本発明は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔを使用する適用例に関して本明細書では説明されるが、このアーキテクチャは他のスクリプティング環境を組み込むことができることは理解されるであろう。

本発明にしたがうと、開発者は、複数のクラスおよびメソッドを生じさせるアプリケーションをサーバ上に作成する。このアプリケーションがコンパイルされると、例えば、ダイナミックリンクライブラリ（ＤＬＬ）または実行可能スクリプトオブジェクト（．ＥＸＥファイル）が作成される。このアプリケーションのコンパイルに続いて、エクスポートのために開発者によって印を付けられたオブジェクトおよびメソッドについて、ＣｏｄｅＧｅｎプロセスは、印を付けられたクラス用にＪａｖａ（登録商標）Ｓｃｒｉｐｔによるオブジェクト、および、印を付けられたメソッド用にＪａｖａ（登録商標）Ｓｃｒｉｐｔによるスタブを生成する。これらのＪａｖａ（登録商標）Ｓｃｒｉｐｔは、ウェブブラウザが使用できる１つまたは複数のＪａｖａ（登録商標）Ｓｃｒｉｐｔファイルにまとめられ、ウェブベースアプリケーションを実装するために、サーバと接続しているクライアントに送信される。

ＣｏｄｅＧｅｎプロセスはまた、サーバサイドプロキシ要素を生成する。一実施形態において、ＣｏｄｅＧｅｎプロセスはサーバ上で実行されるＣ＃コードを生成するが、これは、サーバ上のオブジェクトおよび関数をクライアント上のオブジェクトおよびスタブに直接マッピングする。ＣｏｄｅＧｅｎプロセスはまた、マーシャラ、ディスパッチャ、およびプロキシを生成し、これらによって、クライアント上での呼び出しがサーバサイドコンポーネントを起動できるようになる。サーバで使用するために、この一連のサーバアプリケーションコードが、次いでコンパイルされる。Ｃ＃の使用も例示的であることに留意されたい。本発明にしたがえば、任意のオブジェクト指向プログラミング言語を利用することができる。

ＣｏｄｅＧｅｎプロセスが完了すると、サービスサイドライブラリに対応するクライアントライブラリが生成される。サーバ上に配置されたサービスを呼び出そうとするクライアント開発者は、サービスサイド開発者と同じ方法で、クライアントサイドコンポーネントを直ちに使用することができる。この側面では、サーバ上で利用可能なすべてのオブジェクト、プロトコル、インターフェース、およびＡＰＩがクライアント上で利用できる。

自動生成されたクライアントおよびサーバコードはプロトコル自体を含む。クライアントがローカルクライアントライブラリにあるメソッドを呼び出すと、生成されたローカルＪａｖａ（登録商標）Ｓｃｒｉｐｔスタブが実行される。「代理」として、サーバ要素との相互作用は、実行中透過的である。スタブが実行されると、サーバに存在するアプリケーションにより必要とされる関数内の任意のデータによって、リクエストがサーバに送信されることになる。サーバに送信されるリクエスト内のデータはマーシャリングされる。すなわち、データを収集し、特定の関数またはオブジェクトのために規定されているフォーマットにデータを変換する。この場合、このデータは、サーバ上のマーシャラ（または、この場合では「デマーシャラ（de-marshaler）」）によって理解される、リクエストされたオブジェクトまたはメソッドの型により定義された伝送フォーマットにマーシャリングされる。

サーバ上のマーシャラおよびディスパッチャはリクエストを受け取ると、リクエスト内のデータをアンマーシャリングし、そのリクエストを実際のサーバサイドのオブジェクトまたはメソッドに振り分ける。サービスサイドコードは、次いで、そのリクエストとコンポーネント内に存在する関数とに基づいてレスポンスを生成し、結果データをクライアント上のスクリプトライブラリが解釈できるレスポンスフォーマットの形で、例えば、１つの配列または１つの要素として、クライアントに渡す。クライアント上では、自動生成されたクライアントサイドＪａｖａ（登録商標）Ｓｃｒｉｐｔエンジンがそのレスポンスをアンマーシャリングし、処理を行うクライアントに再び渡す。

クライアントとサーバとの間で使用されるプロトコルは、ＨＴＴＰプロトコルに基づいていて、ＸＭＬＨＴＴＰなどのクライアントサイドオブジェクトを使用して制御される。ＸＭＬＨＴＴＰ（Extensible Markup Language Hypertext Transfer Protocol）は、ＸＭＬ、ＨＴＭＬまたはバイナリデータが、ＨＴＴＰを使用するインターネットを介してウェブサーバに、およびウェブサーバから伝送されることを可能にする一連のＡＰＩである。ＸＭＬＨＴＴＰの利点は、ＡＳＰまたはＣＧＩプログラムであるファイルに対してクライアントから問い合わせがある場合に、ユーザが繰り返しブラウザを更新することなく、クライアントが透過的に最新の情報を取得するようにＸＭＬＨＴＴＰを使用することができることである。このサービスを提供するために、他の種類のオブジェクトを利用することもできる。

クライアントは、呼び出すべきメソッドに関する情報を有する符号化されたＵＲＬに対して、ＨＴＴＰリクエストを送信することにより、サーバ上のメソッドを呼び出す。このＵＲＬはサーバサイドで復号化されて、リクエストされたサービスがそのリクエストにアクセスし、要求されたメソッドが呼び出されることを確実にする。このＵＲＬ自体がリクエストスキーマを符号化する。レスポンスを完了するのに必要なデータは、ＨＴＴＰリクエストのボディ内で符号化される。

本明細書で説明されるアーキテクチャおよび方法は、複数の処理システム上で実施することができる。本発明を実施するのに適した例示的な処理システムは、図１に示されている。図１は、本発明を実施することができる好適な例示的汎用コンピューティングシステム環境１００を示している。コンピューティングシステム環境１００は、好適なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲に関して何らの制限を示唆するものではない。例示的な動作環境１００に示される構成要素のうちのいずれか１つ、あるいはそれらの組合せに関して何らかの依存関係または要件をコンピューティング環境１００が有するものと解釈すべきではない。

本発明は、他の多数の汎用または専用コンピューティングシステム環境または構成で動作可能である。本発明とともに使用するのに適した周知のコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、および上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが挙げられるが、これらに限定されるものではない。

本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的コンテキストで説明することができる。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介して接続されるリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含む、ローカルおよびリモートコンピュータ記憶媒体のどちらにも配置することができる。

図１を参照すると、本発明を実施する例示的なシステムは、コンピュータ１１０の形態の汎用コンピューティング装置を備える。コンピュータ１１０のコンポーネントには、処理装置１２０、システムメモリ１３０、システムメモリを含む様々なシステムコンポーネントを処理装置１２０に連結するシステムバス１２１を含めることができるが、これらに限定されるものではない。システムバス１２１は、様々なバスアーキテクチャのいずれかを用いるメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含む複数の種類のバス構造のうちのいずれでもよい。例えば、そのようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格協会（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られる周辺コンポーネント相互接続（ＰＣＩ）バスが含まれるが、これらに限定されるものではない。

コンピュータ１１０は通常、各種のコンピュータ読取り可能媒体を備える。コンピュータ読取り可能媒体は、コンピュータ１１０によってアクセス可能な任意の利用可能媒体とすることができ、揮発性および不揮発性媒体、着脱可能および着脱不能媒体を含む。例えば、コンピュータ読取り可能媒体として、コンピュータ記憶媒体と通信媒体を挙げることができるが、これらに限定されるものではない。コンピュータ記憶媒体には、コンピュータ読取り可能命令、データ構造、プログラムモジュール、あるいは他のデータなどの情報を記憶するための任意の方法または技法で実施される揮発性および不揮発性媒体、着脱可能および着脱不能媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、または他の光学ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶、または他の磁気記憶装置、あるいは、所望の情報を記憶するために使用できコンピュータ１１０によってアクセスできる他の任意の媒体が含まれるが、これらに限定されるものではない。通信媒体は通常、コンピュータ読取り可能命令、データ構造、プログラムモジュール、または他のデータを、搬送波や他の移送機構などの被変調データ信号として表現したものであり、任意の情報伝達媒体を含む。「被変調データ信号」という用語は、信号中の情報を符号化するような方式で設定または変更された特性の１つまたは複数を有する信号を意味する。例えば、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体と、音波、ＲＦ、赤外線および他の無線媒体などの無線媒体とが含まれる。上記の媒体の任意の組合せもコンピュータ読取り可能媒体の範囲に含まれるべきである。

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形態をとるコンピュータ記憶媒体を備える。起動時などにコンピュータ１１０内の要素間の情報転送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３は、通常ＲＯＭ１３１に格納される。ＲＡＭ１３２は通常、処理装置１２０が直ちにアクセス可能であり、および／または現在処理装置１２０に基づいて動作しているデータおよび／またはプログラムモジュールを含む。例えば、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７が示されているが、これらに限定されるものではない。

コンピュータ１１０は、他の着脱可能／着脱不能、揮発性／不揮発性のコンピュータ記憶媒体も備えることができる。図１には、着脱不能な不揮発性の磁気媒体に対して読み書きを行うハードディスクドライブ１４０、着脱可能な不揮発性の磁気ディスク１５２に対して読み書きを行う磁気ディスクドライブ１５１、および、ＣＤ−ＲＯＭまたは他の光学媒体などの着脱可能な不揮発性の光ディスク１５６に対して読み書きを行う光ディスクドライブ１５５が例として示されている。例示的な動作環境で使用することができる他の着脱可能／着脱不能、揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体素子ＲＡＭ、固体素子ＲＯＭなどが含まれるが、これらに限定されるものではない。ハードディスクドライブ１４１は通常、インターフェース１４０などの着脱不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インターフェース１５０などの着脱可能メモリインターフェースを介してシステムバス１２１に接続される。

上述した、図１に示すドライブおよびそれに関連するコンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、および他のデータの記憶保持をコンピュータ１１０に提供する。例えば、図１には、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するハードディスクドライブ１４１が示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであっても異なってもよいことに留意されたい。図１ではそれらが少なくとも異なるコピーであることを示すために、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には異なる参照符号を付している。ユーザは、キーボード１６２、および、一般にはマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力装置を介してコンピュータ２０にコマンドと情報を入力することができる。他の入力装置（図示せず）として、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが挙げられる。これらおよび他の入力装置は、多くの場合、システムバスに連結されたユーザ入力インターフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）など他のインターフェースおよびバス構造によって接続することもできる。モニタ１９１または他のタイプの表示装置も、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、スピーカ１９７およびプリンタ１９６などの他の周辺出力装置も備えることができ、それらの装置は、出力周辺インターフェース１９０を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータとの論理接続を使用するネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、あるいは他の共通ネットワークノードとすることができ、図１にはメモリ記憶装置１８１のみが示されているが、通常、コンピュータ１１０と関連して上述した多くの要素またはすべての要素を備える。図１に示された論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的である。

ＬＡＮネットワーキング環境で使用される場合、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２または他の手段を備える。モデム１７２は、内蔵型でも外付け型でもよく、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関連して示されたプログラムモジュール、またはその一部は、リモートメモリ記憶装置に格納することができる。例えば、図１には、メモリ装置１８１に存在するリモートアプリケーションプログラム１８５が示されているが、これに限定されるものではない。図示したネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段も使用できることは理解されるであろう。

本発明のアーキテクチャを利用するアプリケーションを実装するために、このアーキテクチャのクライアントおよびサーバサイドコンポーネントをインストールしなければならない。図２Ａには、本発明にしたがってクライアントサイド環境を生成する最初の方法が示されている。図２Ｂは、このアーキテクチャの論理的な透視図を示している。

図２Ａにおいて、ステップ２０２で、ウェブアプリケーションの開発者は、サーバ上のツールを使用してウェブベースアプリケーションを作成する。作成されたアプリケーションは、属性を有するメソッドおよびクラスを使用する関数および機能を含む。一実施形態においては、任意の複数のアプリケーションプログラミング言語を使用して開発することができる。図２Ａに示される例では、Ｃ＃プログラミング言語を使用して開発しているが、Ｃ＃プログラミング言語は、．ＮＥＴプラットフォームと連動するように設計されたマイクロソフト社製のオブジェクト指向プログラミング言語である。．ＮＥＴプラットフォームは、分散コンピューティング環境におけるウェブサービスおよびウェブアプリケーションのためのソフトウェアプラットフォームである。アプリケーションおよび機能がステップ２０２で開発されると、メソッドおよびクラスがサーバ上に配置される。ステップ２０４で、開発者は、クライアントサイドアプリケーション開発者が利用できるように、エクスポート可能なオブジェクトおよびメソッドとして印を付けることができる。一実施形態においては、サーバサイドで利用可能なすべてのメソッドにエクスポートのための印を付けることができる。ステップ２０６で、アプリケーションはコンパイルされ、ダイナミックリンクライブラリおよび実行可能ファイルが生成される。アプリケーションがコンパイルされた後、ステップ２０８で、コード生成（ＣｏｄｅＧｅｎ）プロセスは、生成されたダイナミックリンクライブラリおよび実行可能ファイルを検証し、ステップ２０４で印を付けられたクラス用のスクリプトオブジェクトに加え、スクリプトスタブおよびオブジェクトに正確にマッピングし、サーバ上で実行される、対応するサーバコードを生成する。

一実施形態においては、クライアントオブジェクトはＪａｖａ（登録商標）Ｓｃｒｉｐｔの形で生成されるが、他のスクリプト言語を使用することもできる。本発明の１つの独自の特徴は、クライアントデバイスのために、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔなどのスクリプティング環境内にこのようなオブジェクトを生成することである。スクリプトオブジェクトを使用することによって、クライアント上のウェブブラウザソフトウェアにおける固有のスクリプティングエンジンのユーザが、本明細書で説明されるアーキテクチャを実装できるようになる。ステップ２１０で、スクリプトクラスは、次いで、１つまたは複数のファイルにまとめられ、その後、ステップ２１０でクライアントに送信される。

アプリケーションのために開発される新たな関数は、新たなメソッドまたは新たなクラスを生成することができる。その結果、プロセスは一巡してステップ２０２に戻ることができるので、プロセスは新たな機能が開発されると、サーバ上に実装された新たな機能がクライアント環境に渡されるように、ステップ２０４から２１０まで繰り返される。

図２Ｂは、本発明のアーキテクチャの論理図を例示している。クライアントデバイス上の特定のユーザに対して、環境は比較的に透過的である。クライアントデバイス上では、ユーザは、ウェブベースアプリケーションの形態をとるエンドユーザ機能を利用することになる。一例では、これはマイクロソフト社のホットメールなどのウェブベース電子メールとすることができ、これには、電子メールメッセージングサービス、カレンダ機能および電話帳機能２１２が含まれる。クライアントサイドレンダリング２１４は、サーバにより提供されるデータを使用するコンテンツおよびスクリプトスタブ２１８によって提供される。クライアントサイドおよびサーバサイドの双方のＨＴＴＰハンドラ２２０が、クライアントデバイスとサーバデバイスとの間の通信を処理する。マーシャラ２２２およびディスパッチャ２２４が、リクエストを、ＨＴＴＰハンドラから、ＣｏｄｅＧｅｎプロセスによって生成されるオブジェクトモデルコード２２６へ渡すよう調整する。例えば、クライアントがサーバ上のスペルチェック関数を呼び出す場合、クライアントインターフェースは、実際には、スクリプト配列を受け取るＪａｖａ（登録商標）Ｓｃｒｉｐｔ関数である。クライアント上のマーシャリングプロセス（スタブ２１４に組み込まれたオブジェクトモデル２１６により実装される）は、各配列（すなわち、要素または配列群もしくは要素群の組合せ）を受け取り、それを伝送フォーマットに組み立てる。一般に、１つの配列は、コンマ区切りの要素列の形態をとり、各要素は、配列、整数列、または何らかの他の構造とすることができる。サーバ上のマーシャリングプロセスは再帰的であり、配列内の要素を評価する。オブジェクトモデル２２６およびＪａｖａ（登録商標）Ｓｃｒｉｐｔオブジェクトモデル２１６は双方とも強く型付けされている（strongly typed）ので、所与のオブジェクトのために送信される配列はその配列内に明確に定義された複数の要素を有し、複数の要素は適切な型を有し、複合型（compound type）の場合は、複合型の適切なフォーマットを有する。オブジェクトモデルは、データ層２３０およびストアマネージャ２２８を介して実データ２３２とやりとりを行う。スタブはサーバオブジェクトモデル２２６に基づいて生成されるので、スタブはデータ層２３０に対して型および属性を直接的にマッピングする。

ユーザシステム上のクライアントサイド環境を提供するために、上述したように、１つまたは複数のスクリプトファイルがクライアントコンピューティングデバイスに送信され、そのデバイス上に格納される必要がある。ウェブベースアプリケーションに関して、通常、このようなアプリケーションはサービスプロバイダによって提供される。本発明を構成するアーキテクチャを使用するアプリケーションを提供するサービスプロバイダは、サービスにアクセスするためのログイン名またはアカウントを作成するよう、ユーザに対して要求することができ、そのログイン名またはアカウントの作成ステップを使用してクライアント環境をインストールすることができる。この場合、サービスプロバイダは、ウェブベースサービスもしくはアプリケーションの提供を制御するプロセスを実装するコンピュータ、または、人間と考えることができる。

図３に示されるように、ユーザは、ステップ３０２で、アカウントまたはログイン名を作成する。ユーザがログイン名の初期設定をすると、ユーザはまず、ステップ３０４でユーザコンピュータにダウンロードされるアプリケーションＪａｖａ（登録商標）Ｓｃｒｉｐｔファイルをダウンロードすることになる。ステップ３０６で、ユーザがアプリケーションサーバにより提供されるウェブサービスと対話を始めると、スクリプトエンジンはユーザコンピュータ上のオブジェクトを使用して、本発明のプロトコルを介しサーバサイドアプリケーションのクラスおよびメソッドと通信する。サーバ上で対応するプロセスが実行され、そのプロセスは、ユーザからの特定のサービスまたはアプリケーションのリクエストを受け取り、そのアプリケーションのためのクライアント環境のダウンロードプロセスを開始することが理解されるであろう。

図４は、本発明のアーキテクチャおよびプロトコルを実装する１つの好適なシステムのブロック図である。図４は、図１に示されたコンピューティングデバイス１００とすることができるクライアントデバイス４６０、およびアプリケーションサーバ４２０を示している。本明細書で使用されるように、「サーバ」または「ネットワークサーバ」には、内部にデータおよびアプリケーションを格納する任意のマシン、もしくは、マシンの組合せが含まれ、すなわち、図４にブロック４８０として示されているものが含まれる。

クライアントマシンにおいて実行される閲覧ソフトウェア３００は、ネットワークインターフェース４０２を介してアプリケーションサーバ４８０と通信する。クライアントデバイス４６０とサーバ４８０との間の通信は、１つまたは複数のリクエスト４０２およびレスポンス４０４に対して、インターネットなどのネットワーク、または、公衆網（public network）と私的ネットワーク（private network）の組合せを介して行われる。クライアントデバイス４６０とサーバ４８０との間の通信は通常、ＨＴＴＰプロトコルを使用するが、本発明は、伝送プロトコルとしてＨＴＴＰを使用することに限定されるものではない。

クライアントデバイス４８０は、レスポンス４０４の処理の一部を取り扱う伝送コンポーネント４１０を含む。コンテンツデータが返されると、データは、伝送コンポーネント４１０から、他のコードレイヤ４２０を介して、スクリプティングエンジン４２６およびパーサ（parser）／インタープリタ（interpreter）４２２に渡される。パーサは、次いで、ユーザインターフェース４２４を介してユーザに表示するため、コンテンツを解析し、解釈する。パーサ４２２は、コンテンツがリファレンスの中に組み込まれたいずれかのスクリプトを解釈する必要があるときに、スクリプトエンジン４２６を呼び出すことができる。コンテンツはまた、伝送コンポーネント内に含まれている、あるいは伝送コンポーネント４１０と連動する、ストレージマネージャ４５５を介してアクセスされるローカルストレージ４３６に格納することができる。

ストレージ４３６はまた、キャッシュテーブル、データキャッシュ、クッキー、および、上述したＪａｖａ（登録商標）Ｓｃｒｉｐｔファイルを含むＪａｖａ（登録商標）Ｓｃｒｉｐｔコンテナを含むことができる。伝送コンポーネント４１０は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイル、および、クッキーなどの他の情報を、例えばクッキーコンテナの中に格納し、および、クッキーコンテナの中から取得するストレージマネージャ４５５を含むか、もしくは、そのストレージマネージャと連動する。スクリプトマネージャ４５０は、このアーキテクチャにより提供されるクライアントサイドスクリプトのスタブおよびオブジェクトを実行するスクリプトエンジンからのリクエストを処理する。以下で説明するように、スクリプトマネージャ４５０は、サーバ４８０に対する２種類の呼び出し、すなわち、サーバ４８０上の関数およびオブジェクトを対象とする同期呼び出しおよび非同期呼び出しを処理する。これらのリクエストについては、図１３に関連して以下で説明する。

サーバ４８０は、本発明を実施することができる好適な動作環境４９２を含むことができる。その動作形態４９２は、好適な動作環境の一例に過ぎず、本発明のユーザ機能の範囲に関して何らの限定を示唆するものではない。動作環境の一例は、マイクロソフト社から入手できるウィンドウズ（登録商標）群のオペレーティングシステムである。この環境は、デザインおよびランタイムオブジェクトを含むプラットフォームであるアプリケーションフレームワーク４６０を含むことができ、ウェブサーバ上でアプリケーションが実行されることを可能にするよう制御することができる。このフレームワークは必須ではないが、本明細書で説明される特定のサービスは、フレームワークのコンポーネントとして含まれてもよいし、またはオペレーティングシステムに組み込まれてもよいし、またはオペレーティングシステム内で実行される個別のアプリケーションとして提供されてもよい。アプリケーションフレームワークは、上記で説明されている、マイクロソフト社から入手可能な．ＮＥＴアプリケーションフレームワークとしてもよい。アプリケーションフレームワークは、本発明と併せて利用することができる暗号化、圧縮および認証などの機能を実装するリソースクラスを含むことができる。

開発されたアプリケーションコンテンツ４８２、オブジェクト４８４、およびメソッド４８６は、アプリケーションフレームワーク内に提供される。アプリケーション４８９は、１つまたは複数のクラスおよびメソッドから構成される。コンパイラ４８７は、アプリケーション４８９用のダイナミックリンクライブラリおよび実行可能ファイルを生成する。ＣｏｄｅＧｅｎエンジン４９５もまたアプリケーションフレームワーク４６０内に示されている。上述したように、オブジェクトおよびクラスが特定のアプリケーション４８９のために生成され、コンピュータ４８７によりコンパイルされると、ＣｏｄｅＧｅｎエンジン４９５は、クライアントサイドスクリプティングオブジェクト、マーシャラ４９４、ディスパッチャ４９２およびサーバアプリケーションコード４９０のいずれも生成することになる。

サーバ上のアプリケーションにおけるメソッドとクラスとの間の相互作用は、サーバサイドオブジェクトとともに生じる。レスポンスがサーバサイド「プロキシ」オブジェクト４９０に提供され、その後、サーバサイド「プロキシ」オブジェクトは、クライアントサイドプロキシからの呼び出しに基づいてクライアントデバイスにレスポンスを提供する。

ＣｏｄｅＧｅｎエンジン４９５は、「リフレクション」と呼ばれる技術により処理されるよう動作し、ソフトウェアのコンパイルされた部分を分析して、マーシャリング、アンマーシャリング、およびディスパッチングを実行する一連のパーサ、コンバータ、フォーマッタおよびテキストライタ（まとめて「スタブ」）を自動的に生成する。リフレクションメカニズムはアプリケーションフレームワーク内に提供されるものであり、実行時にクラス定義およびオブジェクト定義を発見する技術である。実際には、ＣｏｄｅＧｅｎエンジンは、コンパイルされたコードを再コンパイルするコンパイラである。ＣｏｄｅＧｅｎエンジンは、ＣｏｄｅＧｅｎエンジン固有の状態などの変数およびコンテキスト情報を考慮に入れる。ＣｏｄｅＧｅｎのスタブは、自動生成されるフレームワークの一部として、関数を非同期に振り分ける。ハッシュテーブルなどのコレクション型を代理することも可能であるが、この機能は、ＳＯＡＰでは利用できない。最終的に、ＣｏｄｅＧｅｎは、サーバの例外をシームレスにクライアントに反映することができる。結果として得られるＪａｖａ（登録商標）Ｓｃｒｉｐｔスタブは、サーバのアプリケーションクラスおよびオブジェクトの実行時属性定義に合致する定義を含むことになる。

サーバアプリケーションコード４９０が生成されると、そのコードはサーバ４８０上のストレージマネージャ４５５と連動して、データ４９８にアクセスする。クライアントデバイス４６０からのリクエストがマーシャラ４９４により受け取られ、ディスパッチャ４９２により分配される。リクエストがサーバ４８０により受け取られると、ディスパッチャは、どの関数をクライアントは実行しようとしているかサーバに伝える。その起動呼び出しは、リクエスト４０４の一部として、クライアントからの受信リクエストＵＲＬの中に組み込まれている。１つの特徴として、ＵＲＬは．Ｎｅｔネームスペース表現を含む。特定のアプリケーション用のすべてのアプリケーションコードは、ネームスペース「ａｐｐｌｉｃａｔｉｏｎ．ｎａｍｅｓｐａｃｅ」内に存在する。ディスパッチャ４９２は、その情報を解読する。マーシャラ４９４は、ＵＲＬのコンポーネントを分離して各要素を調べ、それが合致したときに、ディスパッチャは、リクエスト内の情報をアプリケーションコード４９０内の関数に委任する。

図５は、サーバ上で実行されるメソッドを呼び出し、サーバ上からのレスポンスを受け取る、クライアント上で実行されるスペルチェックアプリケーションのための全般的なプロセスを例示するフローチャートである。一般に、クライアントがサーバ上のスペルチェック関数を呼び出す際、クライアントインターフェースは、実際には入力としてスクリプト配列を受け取るスクリプト関数である。スクリプトマネージャは、各配列を受け取って、これをアップストリーム伝送フォーマット（upstream transport format）に組み立てるマーシャリングプロセスを含む。一実施形態においては、そのフォーマットは、対になるブレースの間にコンマ区切りの要素リストが並べられる配列である。

図５に示されるように、スペルチェック関数は、一般に、何らかのユーザとの相互作用によって、ステップ５０５で起動される。ユーザとの相互作用は、電子メールアプリケーションまたはテキストエディタなどの他のアプリケーションプログラムにおけるその関数の特定の呼び出しとすることができるし、あるいは、ユーザが電子メールメッセージに対して「送信」命令を押す際に、その関数が自動的に呼び出される場合もある。ステップ５１０で、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔアプリケーション「ｃｈｅｃｋ ｓｐｅｌｌｉｎｇ」が、そのアプリケーション内に定義された関数にしたがって、データまたは属性を含むリクエストをサーバサイド関数「ｃｈｅｃｋ ｓｐｅｌｌｉｎｇ」に対して送信する。ステップ５１５で、そのデータは、サーバ上の「ｃｈｅｃｋ ｓｐｅｌｌｉｎｇ」関数用の型付きのフォーマットにマーシャリングされ、ステップ５２０で、ＸＭＬＨＴＴＰリクエストが、伝送コンポーネントを介してサーバサイドメソッドに送信される。例示的なリクエストを、図７〜１０に関連して以下に示す。

サーバサイドでは、リクエストがアンマーシャリングされ、型付きのオブジェクトに変換される。ステップ５２５、５３０、５３５および５４０は、アプリケーションサーバ４８０上で実行される。ステップ５２５で、リクエストが受け取られると、マーシャラ４９４およびディスパッチャ４９２によって操作され、ステップ５２５で、オブジェクトをサーバ上の特定の関数に振り分ける。次いでステップ５３０で、呼び出されたメソッドが、リクエストデータを操作して、何らかのレスポンスを返す。ステップ５３５で、そのレスポンスはＪａｖａ（登録商標）Ｓｃｒｉｐｔレスポンスに変換され、アプリケーションサーバコード４９０によって、ダウンストリームフォーマット（downstream format）の形でクライアントに伝送される。サーバサイドプロキシが、サーバサイドの関数呼び出しの結果をＪａｖａ（登録商標）Ｓｃｒｉｐｔに変換し、そのスクリプトがクライアントに再び送信され、スクリプトマネージャによって解釈される。スクリプトエンジンが、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔレスポンス全体を解析し、これを評価する。このような方式では、「デマーシャラ」はクライアント上に必要なく、ＥＶＡＬ関数がアンマーシャリングと同等の処理を行う。

ステップ５４５および５５０は、クライアント上で行う。ステップ５４５でクライアントサイドスクリプトがレスポンスを受信した際、ＥＶＡＬ動作がレスポンスに対して実行されることになる。ＥＶＡＬ関数は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ表現、ステートメント、またはステートメントの連続を表す文字列を受け取る。その表現は、変数および既存のオブジェクトのプロパティを含むことができる。引数が表現を表す場合、ＥＶＡＬはその表現を評価する。引数が１つまたは複数のＪａｖａ（登録商標）Ｓｃｒｉｐｔステートメントを表す場合、ＥＶＡＬはそのステートメントを実行する。ステップ５５０で、ＥＶＡＬ関数の結果はリクエスト元のスタブに送信される。

図６は、クラス「ｍｅｓｓａｇｅ ｈｅａｄｅｒ」に対するＣｏｄｅＧｅｎプロセスの出力を例示している。このメッセージヘッダクラスは、電子メールメッセージ内に提供される情報を含むことができる。図６に示されるように、典型的な電子メールメッセージヘッダは、件名、送信元アドレス、送信元の名前、日付、サイズ、メッセージリンクおよびステータスアイコンを含むことができる。Ｃ＃オブジェクト定義６２０がサーバ上で生成されるのに対し、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔオブジェクト定義６１０はＣｏｄｅＧｅｎプロセスによってクライアント用に生成される。Ｃ＃オブジェクト定義は、「subject = strSubject, fromAddr = strFromAddr, fromName = strFromName, date = dDate, size = iSize, msgLink = strMsgLink, theIcon = oIcon」という文字列を定義するスクリプトコンストラクタ６２４に先立って、上記オブジェクトの属性のための属性宣言６２２を含む。対応するＪａｖａ（登録商標）Ｓｃｒｉｐｔオブジェクト定義は、そのＣ＃オブジェクト定義に対応する要素６１２に加え、Ｃ＃オブジェクトを含むサーバ上のネームスペース「ｓｅｒｖｅｒＮａｍｅｓｐａｃｅ」およびメッセージヘッダ関数「ｍｅｓｓａｇｅｈｄｒ」に対応する関数定義を含む。

図７は、関数「ＧｅｔＭｅｓｓａｇｅｓ」用の例示的Ｃ＃インターフェース７１０および、これに関連するＪａｖａ（登録商標）Ｓｃｒｉｐｔスタブ７２０を示している。関数ＧｅｔＭｅｓｓａｇｅｓは、引数として、上記で定義されたＭｅｓｓａｇｅＨｄｒオブジェクトを受け取る。サーバサイドＣ＃インターフェース「ｇｅｔ ｍｅｓｓａｇｅｓ」は、サーバ２８０上にメールボックスを有するユーザ用の特定のユーザフォルダという定義入力を必要とする。クライアントＪａｖａ（登録商標）Ｓｃｒｉｐｔスタブ７２０は、サーバに対する非同期および同期ＸＭＬＨＴＴＰリクエストを調整する「ｇＸＭＬＨＴＴＰＰｒｏｘｙ」として知られるオブジェクトを呼び出す関数を含む。ｇＸＭＬＨＴＴＰＰｒｏｘｙの機能は、図１３に関連して以下で説明する。図７に示される例では、関数「ＧｅｔＭｅｓｓａｇｅｓ」は、同期リクエストである。

上述したように、サーバに対するリクエストを形成する際、スクリプトマネージャ２５５は同期または非同期リクエストを処理することができる。同期リクエストでは、以下でさらに詳しく説明するように、クライアントは、ＨＴＴＰにおける「ＰＯＳＴ」関数と非常に類似した方式で処理を行う。すなわち、クライアントはサーバサイドメソッドから何らかのデータをリクエストし、レスポンスを待っているが、サーバからのデータが受け取られるまで、クライアントはアプリケーションを中断したままにする。同期リクエストでは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔがデータを取得するためにサーバに対して呼び出しを行い、ウェブブラウザ内のＪａｖａ（登録商標）Ｓｃｒｉｐｔに結果が提供されるまで、サーバがレスポンスを返すのを待つ。同期リクエストは原則的にブロッキング呼び出しであり、この場合、サーバがレスポンスを返すまでブラウザは停止している。

非同期リクエストは、すぐにはデータに対して呼び出しを行わない。非同期リクエストはキュー内に配置され、リクエストは、非ブロッキング呼び出しの形で、ＸＭＬＨＴＴＰオブジェクトを通じてサーバに送信される。例えば、ユーザがウェブブラウザ内に実装されたスペルチェック関数をリクエストする場合、ユーザは、スペルチェック関数がサーバ上で実行されている間に、電子メールをタイプし続けることができる。データが戻ってくると、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔが呼び出しを受け取り、スペルチェック関数を再び起動する。

図８は、ＧｅｔＭｅｓｓａｇｅｓスクリプトおよび関数により生成される例示的リクエスト８１０およびレスポンス８２０を示している。アップストリームリクエストは次のようなＵＲＬの一般的なフォーマットを必要とする：サーバ ＋ バージョン ＋ サーバネームスペース ＋ クラスＩＤ ＋ メソッドＩＤ。図８に示される例では、ＰＯＳＴ動作は、所与のフォルダＦ００００００００１に対するＧｅｔＭｅｓｓａｇｅｓ関数用のリクエストを含む。ＰＯＳＴに対するレスポンスは、スクリプト定義６１０に直接マップされるＭｅｓｓａｇｅＨｄｒのＣ＃オブジェクト定義において定義された要素を含む新たな配列である。例示的なレスポンス８２０は、アプリケーションサーバから取得したＭｅｓｓａｇｅＨＤＲオブジェクトの配列を示している。

そのようなものとして、レスポンスフォーマット（この場合は配列であるが、他のフォーマットを含むこともある）は、クライアント上のスクリプトオブジェクトにとってまさしく既知であり、この場合、そのスクリプトオブジェクトは、配列内の受信データを解析し、クライアント処理デバイスのユーザインターフェースに表示するために、これをいずれかのレンダリングスクリプトに提供する。

図９および１０は、アプリケーションフレームワーク４６０内で実行されているＣｏｄｅＧｅｎプロセス２９０により生成される追加のオブジェクトおよび関数を例示している。図９および１０に示される例は、スペルチェックアプリケーションで利用することができる２つのスペルチェッキングメソッドに関するものである。図９は、関数「ｃｈｅｃｋｓｐｅｌｌｉｎｇｏｆｗｏｒｄ」を例示しているが、これは入力として一単語を受け取り、その綴りをチェックして、綴りが正しいか、または正しくないかの指示を返す。この関数は、真／偽の結果を返す。スクリプトスタブ９１０は、ｇＸＭＬＨＴＴＰオブジェクトに対する同期呼び出し「ＥＸＡＭＰＬＥＩｎｖｏｋｅＳｙｎｃ」を例示している。その結果、スクリプト９１０は、クライアント上のアプリケーションを解放することなく、メソッド９２０の応答結果を待つ。

図１０は、入力として複数の単語を受け取り、文字列をもって応答するインターフェース「ｃｈｅｃｋｓｐｅｌｌｉｎｇ」１０１０を例示している。スクリプト関数１０２０は、追加のフィルタ「ｄｉｍｅｎｓｉｏｎＦｉｌｔｅｒ＿ｗｏｒｄｓ」を含むが、これは、呼び出しをプロトコルフォーマットにマーシャリングするスクリプトである。スクリプト１０２０は、ｇＸＭＬＨＴＴＰオブジェクトに対する例示的な非同期リクエスト呼び出し「ＥＸＡＭＰＬＥＩｎｖｏｋｅＡｓｙｎｃ」である。その結果、スクリプト１０２０は処理するリクエストをキューに入れ、ブラウザのスクリプティングエンジンを固まらせることなく、結果を待つことになる。スクリプト１０２０はまた、コールバック関数を備えるスクリプトを含み、これによって、ｇＸＭＬＨＴＴＰプロキシは、クライアントが他の関数を実行させている間に、処理されている、サーバからのレスポンスを待つことができる。

図１１は、さらなるインターフェース／スタブ関係を例示している。図１２は、図１１に示されるインターフェース／スタブ関係に対する例示的なリクエスト／レスポンスを示している。図１１には、関数「ｃｈｅｃｋｓｐｅｌｌｉｎｇｗｉｔｈｓｕｇｇｅｓｔｉｏｎｓ」に対するインターフェースが示され、このインターフェースは、入力として１つの文（または、文の連続）を受け取り、「ｓｕｇｇｅｓｔｉｏｎｓ」という文字列をもって応答する。ｇＸＭＬＨＴＴＰオブジェクトの呼び出しは、この例では非同期である。

図１１に示された「ｃｈｅｃｋｓｐｅｌｌｉｎｇｗｉｔｈｓｕｇｇｅｓｔｉｏｎｓ」関数用の例示的なＰＯＳＴリクエストが、図１２に示されている。ＰＯＳＴ関数は、再度、「サーバ ＋ サーバネームスペース ＋ バージョン ＋ クラスＩＤ ＋ メソッドＩＤ」というフォーマットで提供され、この例では、定義されたプロトコルは、ｃｈｅｃｋＳｐｅｌｌｉｎｇＷｉｔｈＳｕｇｇｅｓｔｉｏｎｓ関数にアクセスできる文字列定義を含む。レスポンスは、２つのネストされた配列からなる新たな配列の形態で提供される。

この配列は、クライアント上のＪａｖａ（登録商標）Ｓｃｒｉｐｔエンジンおよびスクリプティング環境が解釈できる標準的なＪａｖａ（登録商標）Ｓｃｒｉｐｔ配列である。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ関数チェックスペリング１１２０は文字列配列を予想しているので、配列をスクリプティング環境に直接提供することができ、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ仮想マシンはその配列を操作することができる。したがって、ブラウザからサーバへ伝送するために、プロトコルは高度に最適化されている。クライアントサイド関数はサーバオブジェクトの型定義を含むので、サーバサイドオブジェクトおよびメソッドに対する呼び出しは、強く型付けされているフォーマットで提供される。データはＪａｖａ（登録商標）Ｓｃｒｉｐｔの形でクライアントに返され、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ言語における標準的なＥＶＡＬ関数によってクライアントサイドで処理することができる。ＥＶＡＬ関数は、そのＪａｖａ（登録商標）Ｓｃｒｉｐｔが関数であるか、配列の生成であるか、またはオブジェクトの生成であるかを判定するので、その評価プロセスの後、そのＪａｖａ（登録商標）ＳｃｒｉｐｔはＪａｖａ（登録商標）Ｓｃｒｉｐｔオブジェクトモデルにおけるオブジェクトにもなる。

図１３は、サーバに対する非同期および同期ＸＭＬＨＴＴＰリクエストを制御するｇＸＭＬＨＴＴＰオブジェクトを例示している。まず、ステップ１３１０で、プロセスは、適切なブラウザ設定であるかどうか、および、ブラウザが本発明のアーキテクチャにおいて使用するのに好適であるかどうかを判定する。ステップ１３１２で、初期化変数がバージョン、サーバおよびネームスペース識別子を含むオブジェクトに渡される。

そのＸＭＬＨＴＴＰオブジェクトは、同期ＸＭＬＨＴＴＰ関数、非同期ＸＭＬＨＴＴＰ関数、ワークアイテムまたはリクエストブロックのスタック、伝送中の現行のリクエストブロック、タイマ、および関数を処理するクッキーをインスタンス化するコンストラクタを含む。

ステップ１３１４で、メソッドがブラウザの伝送コンポーネント４１０のＨＴＴＰサービスを使用するＨＴＴＰ通信用のＸＭＬＨＴＴＰプロキシをインスタンス化しようとする。次に、ステップ１３１５で、呼び出しスクリプトの定義に応じて、メソッドは同期または非同期関数を呼び出す。

メソッドが同期ＸＭＬＨＴＴＰリクエストを呼び出す場合、ＸＭＬＨＴＴＰメソッドを呼び出すスクリプトスレッドは中断され、ＸＭＬＨＴＴＰが成功するか、または時間切れになるまでデータを返さない。ステップ１３１６で、同期ＸＭＬＨＴＴＰリクエストが、サーバに対するＵＲＬ呼び出しを生成することにより開始することになるが、この例は、上述したものである。ＵＲＬが生成されると、ステップ１３１８で、同期接続が開かれ、ステップ１３２０で、ＵＲＬはサーバにポストされる。次いで、メソッドは、単一のパラメータ（レスポンステキスト）とすることができるレスポンスを待つ。レスポンスが受け取られ、または時間切れになると、ステップ１３２４で、それが呼び出しスクリプトに提供され、スクリプトスレッドは解放される。その後、クライアント上のＥＶＡＬ関数を使用する上記の説明にしたがって、そのレスポンスを評価することができる。

ステップ１３１５で、リクエストが非同期ＸＭＬＨＴＴＰリクエストに関するものである場合、ステップ１３３０で、非同期ＸＭＬＨＴＴＰリクエストが、同様にしてＵＲＬを生成することにより開始する。この場合、そのＵＲＬは、上記の識別コンポーネントに加えて、コールバック関数を含む。このコールバック関数は、非同期呼び出しが完了した後にＸＭＬＨＴＴＰプロキシが呼び出すユーザ定義関数である。これは１つのパラメータ（レスポンステキスト）を必要とする。ＵＲＬが生成された後、ステップ１３３４で、システムは非同期呼び出しをキューに入れ、ステップ１３３６で時間切れタイマを設定する。キューに入れるステップ１３３４は、ステップ１３３８でサーバにおいて現在実行されているブロックがあるかどうかを判定するディスパッチャ関数を呼び出す。サーバで実行されているブロックがある場合は、関数はステップ１３３６を監視することにより、スリープ状態に戻る。

キューのスタックが空でない限り、このプロセスにおいてリクエストは存在し、ディスパッチャが処理を完了すると、そのリクエストはディスパッチャを呼び出すという処理を行うことになる。したがって、スタックがすでに空であったとディスパッチャが感知するときは、時間切れウィンドウが呼び出されるだけである。ステップ１３３８でブロックが空である場合、非同期接続が開かれ、ＵＲＬがステップ１３４０でポストされる。その呼び出しがステップ１３４２でキューに入れられると、コールバックハンドラがステップ１３４４で開始される。

コールバックハンドラはＸＭＬＨＴＴＰ動作が完了するのを待ち、コールバックは実行される。ステップ１３４４でレスポンスが受け取られると、現行のリクエストは、ステップ１３４６でディスパッチキューから取り除かれ、ステップ１３４８で、さらにキュー内の待機を解除するように、ディスパッチャが設定される。レスポンスはステップ１３５０で呼び出しスクリプトに渡される。

上記の本発明の詳細な記載は、例示および説明の目的で提示されたものである。この記載は、網羅的なものではなく、開示した正確な形態に本発明を限定するものでもない。上記の教示に鑑みると、多数の変更形態および変形形態が可能である。本明細書に記載したように、本発明の範囲および内容から逸脱することなく、本発明のアーキテクチャに基づく複数の変形形態が可能である。一実施形態においては、リクエストおよびレスポンスを圧縮および暗号化することができる。

本発明の原理およびその実際的な適用例を最も適切に説明して、それにより、企図される特定の使用に適する様々な実施形態および様々な変更形態において当業者が本発明を最もよく利用できるようにするために、記載された実施形態は選択されている。本発明の範囲は、添付の特許請求の範囲により明確になるであろう。

本発明を実施するための好適なコンピュータハードウェアを示すブロック図である。 本発明の一側面にしたがう、サーバ開発環境のクライアントサイドプロキシを生成する本発明の一般的方法を示すフローチャートである。 本発明のアーキテクチャを示す論理図である。 図２において生成されるプロキシ環境を得るためのクライアントサイドの方法を示す図である。 本発明のアーキテクチャを実装するための好適なシステムの一実施形態を示すブロック図である。 本発明を構成するアーキテクチャを利用して動作するウェブベースアプリケーションのためのクライアントとサーバとの相互作用に関する一実施形態を示すフローチャートである。 サーバサイドオブジェクト定義とクライアントサイドプロキシオブジェクト定義とを比較した図である。 第１の例示的なサーバインターフェースと、メソッドに関連する対応するＪａｖａ（登録商標）Ｓｃｒｉｐｔスタブとを示す図である。 本発明の方法を実施するためのプロトコルを利用する、例示的なサーバに対するクライアントリクエストと、サーバからのレスポンスとを示す図である。 第２の例示的なサーバインターフェースと、メソッドに関連する対応するＪａｖａ（登録商標）Ｓｃｒｉｐｔスタブとを示す図である。 第３の例示的なサーバインターフェースと、メソッドに関連する対応するＪａｖａ（登録商標）Ｓｃｒｉｐｔスタブとを示す図である。 第４の例示的なサーバインターフェースと、メソッドに関連する対応するＪａｖａ（登録商標）Ｓｃｒｉｐｔスタブとを示す図である。 本発明にしたがう、第２の例示的なレスポンスプロトコルにおけるポストを示す図である。 本発明にしたがう、クライアントによる同期および非同期プロキシ呼び出しをクライアントが制御する方法を例示するフローチャートである。

符号の説明

４０４ アップストリームフォーマット
４０６ ダウンストリームフォーマット
４２６ スクリプトエンジン
４３６ ストレージ
４５０ スクリプトマネージャ
４６０ クライアントデバイス
４８０ サーバ
４８４ オブジェクト
４８６ メソッド
４８９ アプリケーション
４９０ サーバアプリケーションコード
４９２ ディスパッチャ
４９４ マーシャラ
４９５ ＣｏｄｅＧｅｎ
６１０ Ｊａｖａ（登録商標）Ｓｃｒｉｐｔオブジェクト定義
６２０ Ｃ＃オブジェクト定義
７１０ Ｃ＃インターフェース
７２０ Ｊａｖａ（登録商標）Ｓｃｒｉｐｔスタブ
８１０、１２１０ リクエスト
８２０、１２２０ レスポンス

Claims (40)

1. クライアント−サーバ環境におけるネットワークアプリケーションを提供するためのシステムであって、
   サーバ上の一連のアプリケーション関数であって、型定義を含む一連のアプリケーション関数（４８９）、および、
   スクリプティング環境を定義する一連のクライアント関数であって、前記クライアント関数は前記一連のアプリケーション関数における前記アプリケーション関数の各々に合致する型を含むように定義されている一連のクライアント関数（４３６）
   を備えたことを特徴とするシステム。
2. クライアント上に、クライアント関数からサーバ関数へのリクエストを処理するリクエストエンジン（４５０）をさらに含むことを特徴とする請求項１に記載のシステム。
3. 前記リクエストエンジン（４５０）は、リクエストされた前記サーバ関数用の前記型定義に対応するクライアント関数の前記型フォーマットでリクエストを送信することを特徴とする請求項２に記載のシステム。
4. 前記エンジンは、リクエスト元クライアント関数（４２６、４３６）に応答し、前記型定義は、前記クライアント関数内に含まれることを特徴とする請求項２に記載のシステム。
5. 前記リクエストエンジン（４５０）は、同期および非同期リクエストを処理するスケジューラを含むことを特徴とする請求項２に記載のシステム。
6. 前記リクエストエンジン（４５０）は、前記サーバ関数からレスポンスコールバックを受け取るレスポンスリスナを含むことを特徴とする請求項２に記載のシステム。
7. １つまたは複数の型定義（４５０）は、一連の属性を含むことを特徴とする請求項１に記載のシステム。
8. 前記一連のクライアント関数（４３６）は、ＪａｖａＳｃｒｉｐｔ（登録商標）（２１０）の形で提供されることを特徴とする請求項１に記載のシステム。
9. 前記サーバ上に、クライアントリクエストに対するレスポンスを提供するコード（４９０）をさらに含むことを特徴とする請求項１に記載のシステム。
10. 前記コード（４９０）は、スクリプトが解析できるフォーマット（４０６）で前記レスポンスを提供することを特徴とする請求項９に記載のシステム。
11. 前記コードは、マーシャラ（４９４）を含むことを特徴とする請求項９に記載のシステム。
12. 前記コードは、ディスパッチャ（４９２）を含むことを特徴とする請求項９に記載のシステム。
13. エクスポートのために特に印の付けられた関数からクライアントサイド関数を生成する生成エンジン（４２６）をさらに含むことを特徴とする請求項１に記載のシステム。
14. 前記サーバのためにマーシャラ（４９４）を生成する生成エンジン（４２６）をさらに含むことを特徴とする請求項１に記載のシステム。
15. 前記サーバのためにディスパッチャ（４９２）を生成する生成エンジン（４２６）をさらに含むことを特徴とする請求項１に記載のシステム。
16. インターネット上でウェブアプリケーションを提供するための方法であって、
    定義型を有する関数およびオブジェクトを含むサーバ環境をサーバ上に提供するステップ（２０２）、
    前記サーバ環境内の対応する関数およびオブジェクトにマッピングする型を有する関数およびオブジェクトをスクリプティング環境（４２６）に含むクライアント環境を生成するステップ（２０８）、および、
    前記サーバに前記クライアント環境（４２６）を提供するステップ（２１０）
    を備えたことを特徴とする方法。
17. 前記生成するステップは、スクリプティング言語で前記関数およびオブジェクトを出力するステップ（２１０）を含むことを特徴とする請求項１６に記載の方法。
18. インターネットアプリケーションを実装するシステムであって、
    各々が定義型を有する一連のアプリケーションオブジェクト（４８６）およびメソッド（４８４）を含むサーバ（４８０）、
    前記オブジェクトおよびメソッドを呼び出すクライアントの一連のスクリプトを生成する生成エンジン（４９５）であって、各スクリプトは前記一連のアプリケーションオブジェクトおよびメソッドのうちの少なくとも１つのオブジェクトまたはメソッドに合致する型定義を有する生成エンジン、および、
    クライアント処理デバイス上の１つまたは複数のクライアントスクリプトからのリクエストを受け取り、前記リクエストを前記アプリケーションオブジェクトおよびメソッドの１つに送信するレスポンスエンジン（４９４）
    を備えたことを特徴とするシステム。
19. 各クライアントスクリプトは、対応するサーバオブジェクトまたはメソッドにマップする定義属性（７２０）を含むことを特徴とする請求項１８に記載のシステム。
20. 前記生成エンジン（４９５）は、リフレクティブプロセスであることを特徴とする請求項１８に記載のシステム。
21. 分散処理システムにおけるクライアントプロセスとサーバプロセスとの間の通信方法であって、
    （ａ）前記クライアントプロセスによって前記サーバに関数リクエストを送信するステップであって、前記関数リクエストはリクエストされたサーバ関数の型によって定義されたフォーマットを有するデータ列を含むステップ（５２０）、
    （ｂ）前記サーバプロセスによって前記関数呼び出しを受け取り、前記データ列に基づいて前記リクエストされた関数を実行するステップ（５３０）、および、
    （ｃ）前記サーバプロセスによって前記関数リクエストに対するレスポンスを送信するステップであって、前記レスポンスはオブジェクトにより定義されたクライアントサイド処理フォーマットの形をとるステップ
    を備えたことを特徴とする方法。
22. 前記クライアントプロセスは、リクエストされた前記関数に対応する型定義（５１５）を含むことを特徴とする請求項２１に記載の通信方法。
23. 前記送信するステップおよび前記受け取るステップは、ＨＴＴＰプロトコルを使用して実行されることを特徴とする請求項２１に記載の通信方法。
24. 前記送信するステップ（ａ）は、ＵＲＬ（８１０、１２１０）内の前記関数リクエストを送信するステップを備えたことを特徴とする請求項２３に記載の通信方法。
25. 前記送信するステップ（ａ）は、関数識別子を含むＵＲＬ（８１０）を生成するステップを備えたことを特徴とする請求項２４に記載の通信方法。
26. 前記送信するステップ（ａ）は、リクエストされた前記関数の型定義にしたがってコンマ区切りで並べられたリストの形をとる前記データ列を含むＵＲＬ（１２１０）を生成するステップを備えたことを特徴とする請求項２４に記載の通信方法。
27. 前記ＵＲＬ（８１０）は、前記プロトコルのバージョン番号を含むことを特徴とする請求項２４に記載の通信方法。
28. 前記送信するステップ（ｃ）は、スクリプトが解釈できるフォーマット（８２０、１２２０）で前記レスポンスを送信するステップを備えたことを特徴とする請求項２１に記載の通信方法。
29. 前記送信するステップ（ｃ）は、ＪａｖａＳｃｒｉｐｔのフォーマット（７１０）で前記レスポンスを送信するステップを備えたことを特徴とする請求項２８に記載の通信方法。
30. 前記送信するステップ（ｃ）は、配列（１２２０）で前記レスポンスを送信するステップを備えたことを特徴とする請求項２８に記載の通信方法。
31. 前記送信するステップ（ｃ）は、ネストされた配列（１２２０）で前記レスポンスを送信するステップを備えたことを特徴とする請求項２８に記載の通信方法。
32. 前記方法は１つのオブジェクト（６１０）であることを特徴とする請求項２８に記載の通信方法。
33. 前記方法は複数のオブジェクト（６２０）のうちの１つのオブジェクトであることを特徴とする請求項３２に記載の通信方法。
34. 前記方法は複数の配列（６２０）のうちの１つのオブジェクトであることを特徴とする請求項３２に記載の通信方法。
35. 前記方法は複数のプリミティブデータ型（６２０）のうちの１つのオブジェクトであることを特徴とする請求項３２に記載の通信方法。
36. 前記レスポンスはプリミティブデータ型（６２０）であることを特徴とする請求項２８に記載の通信方法。
37. 第１のコンピュータと第２のコンピュータとの間の通信プロトコルであって、
    前記第２のコンピュータ上の関数用の関数識別子と、前記関数用の引数とを含む、前記第１のコンピュータから前記第２のコンピュータへのリクエストであって、前記引数は前記関数識別子によって呼び出される関数用の型によって定義されるリクエスト（４０４、８１０）、および、
    前記関数の結果を含む、前記第２のコンピュータから前記第１のコンピュータへのレスポンスであって、スクリプト入力として定義されるレスポンス（４０６、８２０）
    を備えたことを特徴とする通信プロトコル。
38. 前記引数（８２０）は、前記型に基づいて編成されるデータを含むことを特徴とする請求項３７に記載のプロトコル。
39. 前記引数（８２０）は、呼び出される前記関数の前記型定義にしたがってコンマ区切りで並べられたリストの形をとるデータ列を含むことを特徴とする請求項３７に記載のプロトコル。
40. 前記スクリプト入力（７２０）は、ＪａｖａＳｃｒｉｐｔフォーマットの形をとることを特徴とする請求項３７に記載のプロトコル。
    

Images