(57)【要約】【課題】  コンピュータシステムが、クライアントプロセス（５２、５４）がサーバプロセス（５０）を介してデータ（５６）にアクセスすることができるようにすること。【解決手段】  アプリケーション（５８）は、オブジェクトをインスタンス化し、データ（５６）に基づいて、インスタンス化されたオブジェクトのプロパティを評価し、イベントに反応する。モータ（６０）は、アプリケーションがインスタンス化したオブジェクトおよびそれらのプロパティに従って、クライアントプロセス（５２）に第１の言語で応答を発行する。モータはまた、クライアントプロセス（５２）から第１の言語で受け取った要求に従って、更新されたプロパティおよびイベントを、第２の言語でアプリケーション（５８）に供給する。したがって、全てのクライアントプロセスが同時にデータにアクセスすることができ、そのデータを共有することができる。【選択図】  図３
2004342085.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも２つのクライアントプロセス（５２、５４、６８、７６、７８）が、アプリケーション（５８）とモータ（６０）とを含むサーバプロセス（５０）を介してデータ（５６）にアクセスできるようにするコンピュータシステムであって、
前記モータ（６０）は、クライアントプロセスの１つ（５２）から第１の言語で要求を受け取り、前記クライアントプロセスの１つに前記第１の言語で応答を発行するようになされており、
前記モータ（６０）は、前記第１の言語とは異なる第２の言語で前記アプリケーション（５８）と通信を行うようになされており、前記第２の言語は、プロパティを備え、イベントに関連付けられたオブジェクトを有するオブジェクト指向言語であり、
前記アプリケーション（５８）は、オブジェクトをインスタンス化し、インスタンス化されたオブジェクトのプロパティをデータ（５６）に基づいて評価して、イベントに反応するようになされており、さらに、
前記モータ（６０）は、前記アプリケーションによってインスタンス化されたオブジェクトおよびそれらのプロパティに従って、前記クライアントプロセスの１つ（５２）に前記第１の言語で応答を発行するようになされており、
前記モータ（６０）は、前記クライアントプロセスの１つ（５２）から前記第１の言語で受け取った要求に従って、更新されたプロパティおよびイベントを前記第２の言語で前記アプリケーション（５８）に供給するようになされていることを特徴とするコンピュータシステム。
【請求項２】
前記モータ（６０）は、別のクライアントプロセス（５４）から前記第１の言語で要求を受け取り、前記別のクライアントプロセス（５４）に前記第１の言語で応答を発行するようになされており、
前記モータ（６０）は、前記アプリケーション（５８）によってインスタンス化されたオブジェクトおよびそれらのプロパティに従って、前記別のクライアントプロセス（５４）に前記第１の言語で応答を発行するようになされており、
前記モータ（６０）は、前記別のクライアントプロセス（５４）から前記第１の言語で受け取った要求に従って、更新されたプロパティおよびイベントを前記第２の言語で前記アプリケーション（５８）に供給するようになされていることを特徴とする請求項１に記載のシステム。
【請求項３】
前記モータ（６０）は、別のクライアントプロセス（６８）から第３の言語で要求を受け取り、前記別のクライアントプロセス（６８）に前記第３の言語で応答を発行するようになされており、前記第３の言語は、前記第１の言語とは異なり、前記第２の言語とも異なる言語であり、
前記モータ（６０）は、前記アプリケーション（５８）によってインスタンス化されたオブジェクトおよびそれらのプロパティに従って、前記別のクライアントプロセス（６８）に前記第３の言語で応答を発行するようになされており、
前記モータ（６０）は、前記別のクライアントプロセス（６８）から前記第３の言語で受け取った要求に従って、更新されたプロパティおよびイベントを前記アプリケーション（５８）に前記第２の言語で供給するようになされていることを特徴とする請求項１または２に記載のシステム。
【請求項４】
前記モータは、前記クライアントプロセス（５２、５４）と前記第１の言語で通信を行うための第１のレンダラ（７２）と、前記別のクライアントプロセス（６８）と前記第３の言語で通信を行うための第２のレンダラ（７４）とを備えることを特徴とする請求項３に記載のシステム。
【請求項５】
クライアントプロセス（７６、７８）は、アプリケーションプロセス（８０、８２）を介して前記サーバプロセス（５０）の前記モータ（６０）と通信を行い、前記アプリケーションプロセスは、
前記クライアントプロセス（７６、７８）と通信を行うようになされた第２のモータ（８４、８６）と、
前記第２のモータ（８４、８６）と通信を行うようになされた第２のアプリケーション（８８、９０）と、
前記モータ（６０）と前記第１の言語で通信を行うようになされ、前記第２のアプリケーション（８８、９０）および／または前記第２のモータ（８４、８６）と通信を行うようになされたクライアントインターフェース（９２、９４）とを含むことを特徴とする請求項１から４のいずれか１つに記載のシステム。
【請求項６】
前記第１の言語はＨＴＭＬを含むことを特徴とする請求項１から５のいずれか１つに記載のシステム。
【請求項７】
クライアントプロセス（５２、５４、６８、７６、７８）にサービスし、前記クライアントプロセスがアプリケーション（５８）によって管理されているデータ（５６）にアクセスできるようにするモータであって、
クライアントプロセスから第１の言語で要求を受け取り、前記第１の言語で応答を発行するようになされた第１のレンダラ（７２）と、
クライアントプロセスから、前記第１の言語とは異なる第３の言語で要求を受け取り、前記第３の言語で応答を発行するようになされた第２のレンダラ（７４）と、
前記第１の言語および前記第３の言語とは異なる第２の言語でメッセージを発行し、受け取るようになされたアプリケーションインターフェース（７５）であって、前記第２の言語が、プロパティを備え、イベントに関連付けられたオブジェクトを有するオブジェクト指向言語であるアプリケーションインターフェースとを含み、
前記モータは、前記アプリケーションインターフェース（７５）で受信された前記メッセージに含まれる前記オブジェクトおよびプロパティに従って、前記第１のレンダラ（７２）を介して前記第１の言語で応答を発行し、前記第２のレンダラ（７４）を介して前記第３の言語で応答を発行するようになされており、
前記モータは、前記第１および第２のレンダラ（７２、７４）が受け取った要求に従って、更新されたプロパティおよびイベントを含むメッセージを前記アプリケーションインターフェースを介して発行するようになされていることを特徴とするモータ。
【請求項８】
前記第１の言語はＨＴＭＬを含むことを特徴とする請求項７に記載のモータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムの分野に関し、より詳細には、クライアントプロセスがデータにアクセスできるようにするためのサーバプロセスに関する。
【背景技術】
【０００２】
コンピュータシステムでは、クライアントプロセスが、サーバプロセスを介してデータにアクセスできるようにする必要がある。例えば、ＨＴＭＬ言語でクエリを発行しているクライアントに対して、サーバがインターネットを介して情報を提供する場合にこの必要が生じる。サーバ上でホストされているサーバプロセスは、クライアントプロセスが要求した情報にアクセスすることができるようにする必要がある。図１は、このようなシステムのアーキテクチャの概略図である。サーバプロセス２はデータ４を含み、このデータ４にアクセスできるようにする必要がある。サーバプロセスは、さらに、アプリケーション６およびモータ８を含む。モータは、アパッチソフトウェア財団のＰＨＰという商標、マイクロソフト社のＡＳＰという商標、サンマイクロシステムズ社のＪＳＰという商標で提供されている製品など、市販されているいくつかの製品のうちの１つであってよい。
【０００３】
図１は、さらに、２つのクライアントプロセス１０、１２を示す。一般的に、サーバプロセスは、１つまたは複数のサーバマシンによってホストされ、一方、各クライアントプロセスは、別個のクライアントマシンによってホストされる。クライアントプロセスは、ネットスケープ社がＮａｖｉｇａｔｏｒという商標で提供しているもの、またはマイクロソフト社がＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒという商標で提供しているもののようなウェブブラウザである。クライアントプロセスおよびサーバプロセスは、例えば、ＩＰファミリのプロトコルを使ったネットワークを介して接続されている。クライアントプロセス１０、１２は、ＨＴＭＬ、ダイナミックＨＴＭＬ、あるいは、アクティブＸ、Ｊａｖａ（登録商標）アプレット、ＪａｖａＳｃｒｉｐｔ（サンマイクロシステムズ社の商標であり、マイクロソフト社のＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒやネットスケープ社のＮａｖｉｇａｔｏｒなどのウェブブラウザによって提供される）などのその他の技術を使って、サーバプロセスのモータと通信を行う。わかり易いように、本明細書におけるさらなる説明においては、一般的な例としてＨＴＭＬを取り上げる。
【０００４】
アプリケーション６は、同じ言語を使ってモータと通信を行う。さらに、モータが提供する機能を使用する。
【０００５】
システムの動作は以下の通りである。クライアントプロセス１０、１２が、ＨＴＭＬ言語でモータ８に要求を発行する。様々なクライアントからの要求は、ＨＴＭＬ言語で、また、おそらくはモータに特有の追加機能を使って、モータ８がアプリケーション６に渡す。モータからの要求はアプリケーション６によって処理され、アプリケーション６は、必要に応じてデータ４にアクセスする。アプリケーションからの応答は、ＨＴＭＬ言語でモータに供給され、クライアントプロセスに転送される。
【０００６】
このタイプのアーキテクチャでは、アプリケーションが移植性があることはほとんどなく、ＨＴＭＬクライアント専用である。上記に挙げたようなモータは、アプリケーションの開発を容易にするためのさらなる機能またはライブラリを提供する。しかし、アプリケーションとモータの間の通信のための基盤はＨＴＭＬのままである。したがって、アプリケーションは、必然的にＨＴＭＬクライアント特有になり、容易に他のタイプのクライアントに適合させることができない。したがって、ＪＳＰ、ＡＳＰ、またはＰＨＰなどの言語はＨＴＭＬベースであり、これらの言語で書かれたアプリケーションはどれもＨＴＭＬ部分を含んでいる。
【０００７】
ＨＴＭＬクライアント以外のクライアントの場合でも、サーバプロセスを介してデータにアクセスできるようにする必要性はある。ダッソーシステムズ社（Ｄａｓｓａｕｌｔ  Ｓｙｓｔｅｍｅｓ）は、ＣＡＴＩＡという商標のＣＡＤ製品を販売している。この製品のアーキテクチャの概略図を、２つのクライアント２０、２２にこの製品を実装することが可能な一例として図２に示す。図２は、データ２６、および、クライアントプロセス２０、２２それぞれに１つずつのＣＡＴＩＡプロセス２８、３０をホストしているマシン２４を示す。各ＣＡＴＩＡプロセスは、アプリケーションのコピー３２、３４、およびモータ３６、３８を含む。ＣＡＴＩＡ製品ラインは、ＣＡＴＩＡ標準のもとで開発されたアプリケーションが、いくつかのモータのうち１つと共に動作できるように設計されている。各モータは、例えばＵｎｉｘ（登録商標）クライアントまたはＷｉｎｄｏｗｓ（登録商標）クライアントなど、あるタイプのクライアントプロセスに合わせて設計されている。これによって、同じアプリケーションを使って、異なるオぺレーティングシステムを実行している複数のクライアントプロセスにサービスすることができる。より詳細には、図２に示すように、同じアプリケーションの１つのコピーを、各プロセスにサービスするために使用することができる。
【０００８】
様々なタイプのマシン上で実行している様々なクライアントのために使用できるのであるから、このアプリケーションは移植可能である。図２に示すように、両方のクライアントプロセスが同じデータにアクセスできるにもかかわらず、各クライアントプロセスに１つのＣＡＴＩＡプロセスが使用されている。各ＣＡＴＩＡプロセス２８、３０は、一般に、データの独自のコピーを作成し、そのデータに対してクライアントプロセスが加えた修正に従って、データ２６の更新を行う。これは、所与のＣＡＴＩＡプロセス２８中の、あるクライアントがローカルに修正したデータには、その所与のプロセス２８中のアプリケーション３２がデータ２６の更新を管理するまでは他のクライアントプロセス２２がアクセスできないため、クライアント間のデータのリアルタイム共有を制限する場合がある。図２の例では、両方のＣＡＴＩＡプロセス２８、３０がデータと同じマシン２４上でホストされている。別個のマシンを使用することも可能であり、その場合も、各クライアントに１つのＣＡＴＩＡプロセスを設ける。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
したがって、様々なクライアントがデータに簡単にアクセスすることを可能にし、しかもあるタイプのクライアントから別のタイプのクライアントにアプリケーションを移植することが可能なコンピュータシステムが求められている。
【課題を解決するための手段】
【００１０】
本発明の一実施形態によれば、少なくとも２つのクライアントプロセスが、アプリケーションとモータとを含むサーバプロセスを介してデータにアクセスできるようにするコンピュータシステムが提供される。モータは、クライアントプロセスの１つから第１の言語で要求を受け取り、前記クライアントプロセスの１つに前記第１の言語で応答を発行するようになされており、前記モータは、前記第１の言語とは異なる第２の言語で前記アプリケーションと通信を行うようになされており、前記第２の言語が、プロパティを備え、イベントに関連付けられたオブジェクトを有するオブジェクト指向言語である。前記アプリケーションは、オブジェクトをインスタンス化し、インスタンス化されたオブジェクトのプロパティをデータに基づいて評価して、イベントに反応するようになされている。前記モータは、前記アプリケーションによってインスタンス化されたオブジェクトおよびそれらのプロパティに従って、前記クライアントプロセスの１つに前記第１の言語で応答を発行するようになされている。前記モータは、前記クライアントプロセスの１つから前記第１の言語で受け取った要求に従って、更新されたプロパティおよびイベントを前記第２の言語で前記アプリケーションに供給するようになされている。
【００１１】
好ましくは、前記モータは、さらに、別のクライアントプロセスから前記第１の言語で要求を受け取り、前記別のクライアントプロセスに前記第１の言語で応答を発行するように、また、前記アプリケーションによってインスタンス化されたオブジェクトおよびそれらのプロパティに従って、前記別のクライアントプロセスに前記第１の言語で応答を発行するようになされており、前記モータは、前記別のクライアントプロセスから前記第１の言語で受け取った要求に従って、更新されたプロパティおよびイベントを前記第２の言語で前記アプリケーションに供給するようになされている。
【００１２】
また、以下のように定めることも可能である。すなわち、前記モータは、別のクライアントプロセスから第３の言語で要求を受け取り、前記別のクライアントプロセスに前記第３の言語で応答を発行するようになされており、前記第３の言語が、前記第１の言語とは異なり、また前記第２の言語とも異なる言語であり、前記モータは、前記アプリケーションによってインスタンス化されたオブジェクトおよびそれらのプロパティに従って、前記別のクライアントプロセスに前記第３の言語で応答を発行するようになされており、前記モータは、前記別のクライアントプロセスから第３の言語で受け取った要求に従って、更新されたプロパティおよびイベントを前記第２の言語で前記アプリケーションに供給するようになされている。
【００１３】
この場合、前記モータには、前記クライアントプロセスと前記第１の言語で通信を行うための第１のレンダラと、前記別のクライアントプロセスと前記第３の言語で通信を行うための第２のレンダラとを備える。
【００１４】
別の実施形態では、クライアントプロセスは、アプリケーションプロセスを介して前記サーバプロセスの前記モータと通信を行う。前記アプリケーションプロセスは、前記クライアントプロセスと通信を行うようになされた第２のモータと、前記第２のモータと通信を行うようになされた第２のアプリケーションと、前記モータと前記第１の言語で通信を行うようになされ、また、前記第２のアプリケーションおよび／または前記第２のモータと通信を行うようになされたクライアントインターフェースとを含む。  
好ましくは、第１の言語はＨＴＭＬを含む。
【００１５】
本発明はまた、別の実施形態において、クライアントプロセスにサービスし、前記クライアントプロセスがアプリケーションによって管理されているデータにアクセスできるようにするモータであって、クライアントプロセスから第１の言語で要求を受け取り、前記第１の言語で応答を発行するようになされた第１のレンダラと、クライアントプロセスから、前記第１の言語とは異なる第３の言語で要求を受け取り、前記第３の言語で応答を発行するようになされた第２のレンダラと、前記第１の言語および前記第３の言語とは異なる第２の言語でメッセージを発行し、受け取るようになされたアプリケーションインターフェースであって、前記第２の言語が、プロパティを備え、イベントに関連付けられたオブジェクトを有するオブジェクト指向言語であるアプリケーションインターフェースとを含むモータを提案する。
【００１６】
前記モータは、前記アプリケーションインターフェースで受信された前記メッセージに含まれる前記オブジェクトおよびプロパティに従って、前記第１のレンダラを介して前記第１の言語で応答を発行し、また前記第２のレンダラを介して前記第３の言語で応答を発行するようになされている。前記モータは、前記第１および第２のレンダラが受け取った要求に従って、更新されたプロパティおよびイベントを含むメッセージを前記アプリケーションインターフェースを介して発行するようになされている。  
この場合も、第１の言語はＨＴＭＬを含むことができる。
【００１７】
次に、限定されない一例として、添付の図面を参照しながら本発明を実施するコンピュータシステムについて説明する。
【発明を実施するための最良の形態】
【００１８】
本発明は、少なくとも２つのクライアントプロセスがサーバプロセスを介してデータにアクセスできるようにするコンピュータシステムを提案する。このコンピュータシステムは、様々なクライアントプロセスによってデータを共有することを可能にする。言い換えれば、様々なクライアントプロセスが、同時に同じデータにアクセスすることができる。さらに、このコンピュータシステムは、サーバプロセスが様々なタイプのクライアントにデータを供給することを可能にする。
【００１９】
図３は、同様のクライアントプロセスを備えた実施形態における、本発明によるシステムのアーキテクチャの概略図である。図３には、サーバプロセス５０およびクライアントプロセス５２、５４を示してある。わかり易いように、クライアントプロセスを２つだけ示してある。物理的な実装の観点から言えば、サーバプロセスおよびクライアントプロセスは異なるマシン上で実行していてもよい。また、同じマシン上でも実行していてもよい。これは、本発明の動作とは関係がないため、本明細書の残りの部分においては物理的実装についての説明は行わない。
【００２０】
図３に示すように、サーバプロセス５０を使ってデータ５６にアクセスする。サーバプロセス５０は、アプリケーション５８およびモータ６０を含む。モータ６０は、クライアントプロセス５２、５４の１つから第１の言語で要求を受け取るようになされている。図３は、モータとプロセスの間の通信リンク６２、６４を示す。この図１のクライアントプロセスと同様のクライアントプロセスの例では、第１の言語が、一般に、ＨＴＭＬおよび関連拡張部分を含む。モータはまた、クライアントプロセスの一方またはもう一方に、第１の言語で応答を発行する。この例では、プロセス５２、５４は、同じ言語−例えばＨＴＭＬおよび関連技術−を使ってモータ６０と通信を行う。これを、各リンク６２、６４上の一重ダッシュで表している。
【００２１】
モータは、さらに、第１の言語とは異なる第２の言語でアプリケーションと通信を行う。図３では、これを、モータ６０とアプリケーション５８の間の通信リンク６６上の二重ダッシュで表している。第２の言語は、その構文が第１の言語の構文に依存していないという点において、第１の言語とは異なっている。特に、第２の言語は、第１の言語の構文要素を使用しない。したがって、第１の言語に変更を施しても、第２の言語には反映されない。第２の言語が第１の言語と異なっていることによって、モータがサービスするプロセスとは無関係にアプリケーションを開発することができる。図４および５を参照しながら以下に説明するように、様々なタイプのクライアントプロセスに対して、そのクライアントプロセスのタイプのためのアプリケーションを再び開発する必要なくサービスすることができ、あるいは、アプリケーションをクライアントプロセスに適合させることができる。
【００２２】
これは、図１を参照しながら説明した従来技術の解決策に比べて大きな利点である。例えば、アプリケーションをＪＳＰやＡＳＰで開発した場合、それは、当然、ＨＴＭＬ部分を含み、ＨＴＭＬブラウザであるクライアントにサービスするようにのみ適合される。別のタイプのクライアントプロセスが同じデータにアクセスする必要が生じた場合、アプリケーションを、別のモータを使って新しく開発しなければならない。
【００２３】
図３の例では、第２の言語も、プロパティを備え、イベントに関連付けられたオブジェクトを有するオブジェクト指向言語である。オブジェクト言語固有の利点は別として、オブジェクト指向言語を選択することにより、第１の言語とは異なる第２の言語を提供することが容易になる。実際、モータ６０は、クライアントプロセス５２、５４の一方から第１の言語で要求を受け取り、その要求の内容に従って、更新されたプロパティまたはイベントをアプリケーション５８に供給し、または、プロパティおよびイベントについてアプリケーションに問い合わせる。アプリケーションは、次いで、単に、更新されたプロパティおよび／またはイベント、あるいはオブジェクトのプロパティの要求をモータから受け取る。要求に従って、アプリケーションは、オブジェクトをインスタンス化し、データに基づいてインスタンス化したオブジェクトのプロパティを評価し、かつ／またはイベントに反応する。更新されたプロパティ、またはイベントへの反応は、アプリケーションによってモータに転送される。モータは、次いで、アプリケーションによって供給された情報に基づいて、関連するプロセスに第１の言語で応答を供給する。
【００２４】
これは、サーバプロセスがクライアントプロセスに提供するサービスの様々な側面を、アプリケーション５８とモータ６０の間で分割することに等しい。サービスを受けているクライアントのタイプに特有の特徴はモータが取り扱い、アプリケーションには渡されない。これには、例えば、サービスによって提供される「ルックアンドフィール」が含まれ得る。データおよび動作は、一般に、アプリケーションが取り扱う。図４は、異なるクライアントプロセスを備えた、本発明によるシステムのアーキテクチャの概略図である。図４は図３と同様であり、可能な場合には同じ参照符号を使用してある。図４では、クライアントプロセス５４の代わりに、クライアントプロセス５２とは異なるタイプのクライアントプロセス６８を示してある。クライアントプロセス６８は、通信リンク７０を介してモータ６０と通信を行う。リンク７０上の三重ダッシュによって示してあるように、クライアントプロセス６８は、第１の言語とは異なる第３の言語を使って、モータ６０と通信を行う。例えば、第１の言語はＨＴＭＬであってよい。第３の言語は、ＨＴＭＬを理解するように適合されたウェブブラウザを使用する必要はなく、Ｗｉｎｄｏｗｓ（登録商標）クライアントやＵｎｉｘ（登録商標）クライアントに適合させることができる。また、以下に説明するように、いずれかの専用言語であってもよい。第３の言語は第１の言語とは異なるが、類似点があってもよく、あるいは、第１の言語と共通の項目をいくつか備えていてもよい。第３の言語は、第１の言語と第２の言語の間の相違に関して図３を参照しながら説明した理由により、第２の言語とは異なる。
【００２５】
図４のモータ６０は２つの異なるレンダラ７２、７４を備えている。レンダラ７２または７４は、第１または第３の言語で要求を受け取り、それぞれの言語で関連するクライアントに応答を発行するようになされている。別個のレンダラが存在するおかげで、クライアントプロセスをアドレス指定するために使用される言語に依存しないモータ６０の機能−例えば、アプリケーションとの通信、クライアントプロセスからの要求の待機など−を、異なるクライアントプロセスにサービスするように複製する必要がない。レンダラは、クライアントの要求を変換して、１つまたは１組のクライアント言語に対応する応答を生成する。したがって、レンダラは、モータ内でその１つまたは１組のクライアント言語に特有な全てのものを含んでいる。図４は、モータが、メッセージを第２の言語で受け取り、発行するために使用する、アプリケーションインターフェース７５をさらに示している。
【００２６】
図３と図４を比較すると、例示のアーキテクチャでは、異なるタイプのクライアントプロセスにサービスするためにアプリケーションを適合する必要がないことがわかる。図４の例では、単にモータ中に追加レンダラを備えることによって、異なるクライアントプロセスにサービスすることが可能になる。これは、アプリケーションを再開発することを意味しているわけではない。図４と図２を比較すると、例示のアーキテクチャでは、異なるクライアントプロセスが同じデータを、リアルタイムでアドレス指定できることがわかる。アプリケーションにおいてデータのコピーを管理する必要はない。全てのクライアントプロセスが同じデータにアクセスし、このデータを、様々なクライアントプロセスが同時に更新することが可能である。
【００２７】
図５は、本発明によるシステムの別の実施形態のアーキテクチャを示す概略図である。クライアントプロセスがアプリケーションプロセスを介してデータにアクセスできるようにするために、図４のアーキテクチャも使用できることを示している。
【００２８】
図５では、サーバプロセス５０およびクライアントプロセス５２は、図４の対応する要素と同一であるため、再び十分に説明することはしない。わかり易くするために、アプリケーション５８は、例えば、ダッソーシステムズ社がＥＮＯＶＩＡという商標で販売しているタイプの製品ライフサイクル管理アプリケーションである。モータの第１のレンダラ７２はＨＴＭＬレンダラであり、ウェブブラウザを実行しているクライアントプロセス５２が使用するようになされて。図５は１つのウェブクライアントを示しているが、２つ以上の場合もあり得る。これによって、ＨＴＭＬクライアントはアプリケーション５８を介してデータ５６にアクセスすることができる。したがって、この例では、ＨＴＭＬクライアントは製品ライフサイクル管理を使用することができる。
【００２９】
図５は、さらに、２つのクライアントプロセス７６、７８を示す。わかり易くするために、これらのプロセッサが異なるプラットフォーム上で実行しているとする。プロセス７６は、Ｗｉｎｄｏｗｓ（登録商標）プロセスであり、プロセス７８はＵｎｉｘ（登録商標）プロセスである。クライアントプロセス７６、７８は、直接ではなく、それぞれＣＡＴＩＡプロセス８０、８２を介してモータ６０にアクセスする。プロセス８０は、Ｗｉｎｄｏｗｓ（登録商標）クライアントプロセス７６と通信を行うようになされたＷｉｎｄｏｗｓ（登録商標）モータ８４を含み、一方、プロセス８２は、Ｕｎｉｘ（登録商標）クライアントプロセス７８と通信を行うようになされたＵｎｉｘ（登録商標）モータ８６を含む。各プロセス８０、８２は、ＣＡＴＩＡアプリケーション８８、９０をさらに含む。関連するデータは示していない。両アプリケーションは同一であってよい。各ＣＡＴＩＡプロセス８０、８２は、通信リンク９６を介して第３の言語でモータ６０の第２のレンダラ７４と通信を行うようになされたクライアントインターフェース９２、９４をさらに備えている。クライアントインターフェース９２，９４は、アプリケーション８８、９０とモータ８４、８６の間で使用されているのと同じ言語、すなわちこの例ではＣＡＴＩＡで、関連するモータ８４、８６と通信を行う。
【００３０】
図２のように、各クライアントプロセス７６、７８は、ＣＡＴＩＡアプリケーション８８、９０にアクセスすることができる。さらに、各クライアントプロセスは、ＥＮＯＶＩＡアプリケーション５８にアクセスして、対応するデータ５６を使用することができる。ＥＮＯＶＩＡアプリケーションへのアクセスを可能にするために、クライアントプロセスに追加の環境（例えば、ＨＴＭＬ）を提供する必要はない。ユーザにとっては、ＥＮＯＶＩＡアプリケーションは、自分の通常のＣＡＴＩＡクライアントの環境内で使用可能である。ＣＡＴＩＡまたはＥＮＯＶＩＡアプリケーションのいずれかに対するアクセスは、クライアントプロセス７６、７８にとってはトランスペアレントである。しかし、クライアントプロセス７６、７８に、ＣＡＴＩＡおよびＥＮＯＶＩＡアプリケーションに対する別個のアクセスを提供する必要はない。
【００３１】
図５の例では、図４の例の場合のように、様々なタイプのクライアントをアドレス指定することが可能になる。さらに、以前に開発したアプリケーション（例示のＣＡＴＩＡアプリケーションなど）の再使用が可能になる。アプリケーション８８、９０を適合する必要はない。すなわち、モータ６０をアドレス指定するためには、単にプロセス８０、８２にクライアントインターフェース９２、９４を備えればよい。クライアントプロセス７６、７８の両方が、同時に同じデータ５６にアクセスすることができる。
【００３２】
図５の解決策の別の利点は、クライアントプロセス７６、７８が異なるプロセスであっても、それらのクライアントプロセスをアドレス指定するために、サーバプロセス５０のモータ６０にレンダラ７４を１つだけ備えればよいことである。実際、モータ８４、８６は、クライアントプロセス７６と７８の相違をすでに考慮に入れているため、同じクライアントインターフェース９２、９４をＣＡＴＩＡプロセス８０、８２で使用することができる。図５の例は、新しい開発の必要性を制限するために、既存のモータを利用している。
【００３３】
図６は、本発明によるシステムのより詳細な概略図である。図６は、ＨＴＭＬクライアントの例を示す。クライアントプロセス５２はウェブブラウザ１００を含む。サーバアプリケーションユーザインターフェース１０４を使って、ブラウザフレーム１０２がＨＴＭＬでクライアントに表示される。サーバプロセス５０中のモータ６０は、ＨＴＭＬレンダラ７２および抽象化層１０６を含む。ユーザインターフェース１０４へのユーザの入力に反応して、ウェブブラウザ１００は、例えば、インターネットなどのＨＴＴＰネットワーク上にあるサーバプロセスへ転送されるＵＲＬを生成する。モータのＨＴＭＬレンダラ７２がこのＵＲＬを受け取り、そしてそのＵＲＬは抽象化層１０６中の通知に変換される。これを、図６の矢印１０８によって示す。抽象化層１０６は、受け取ったＵＲＬ、または更新されたプロパティの要求に基づいて、更新されたオブジェクトのプロパティまたはイベントをアプリケーションに渡す。これを、図６の矢印１１０によって示す。上述のように、モータの抽象化層１０６とアプリケーション５８の間の通信はＨＴＭＬ要素を含まない。
【００３４】
図６の矢印１１２で示すように、アプリケーションは、オブジェクトをインスタンス化して、抽象化層１０６にプロパティを供給する。これらは、ウェブブラウザにＨＴＭＬページを供給するために、ＨＴＭＬレンダラで使用される。図６の矢印１１４で示すように、そのページがユーザインターフェース１０４上に表示される。
【００３５】
サンプルユーザディスプレイが、項目リスト、リストに新しい値を入力するためのテキストエリア、およびその新しい値の妥当性を確認するためのボタンを含むとする。アプリケーションから見ると、項目リストの内容は１組のデータであり、テキストエリアはオブジェクトであり、テキストはオブジェクトのプロパティであり、妥当性確認用のボタンは、ユーザがそのボタンで妥当性を確認するとイベントに関連付けられる、第２のオブジェクトである。
【００３６】
生成されたＨＴＭＬページは、リストの一部（例えば、項目２００のうちの１から２０）を表示するためのＨＴＭＬテーブルを含み、項目をこのテーブルのセルとして有する。ＨＴＭＬテーブルのヘッダは、リストの次の部分に移動するためのリストヘッダハイパーリンクを含む。また、ＨＴＭＬページは、ボタンおよびテキスト入力を備えたＨＴＭＬフォームも含む。ＨＴＭＬページは、モータが、アプリケーションによって供給された項目に基づいて、また、オブジェクトの現在のプロパティに基づいて生成する。生成されたＨＴＭＬページは、クライアントプロセスに供給される。
【００３７】
ユーザがリストヘッダハイパーリンクをクリックして項目リストの次の部分を表示させると、ウェブブラウザは、第１のＨＴＭＬページの生成の間にモータによって生成されたＵＲＬを使って、新しいＨＴＴＰ要求を開始する。この要求は、モータに渡される。モータは、次いで、項目リストの次の部分（例えば、項目２１〜４０）をアプリケーションから取得する。モータは、項目リストの次の部分を含む新しいＨＴＭＬページを生成する。オブジェクトのプロパティは更新されない。
【００３８】
ユーザが、テキストエリアの内容を修正して新しい項目をリストに入力し、次いでボタンを起動すると仮定する。ウェブブラウザは新しいＨＴＴＰ要求を開始する。モータはその要求を受け取り、テキストエリアの修正された内容、およびボタンの起動を識別する。テキストエリアオブジェクトの更新されたプロパティは、そのボタンに関連付けられたイベントと共にアプリケーションに渡される。これはユーザディスプレイ上のテキストエリアのＨＴＭＬ符号化およびボタンとは全く関係がないことに留意されたい。
【００３９】
イベントに応答して、アプリケーションは、テキストオブジェクトの修正されたプロパティを読み取り、それに応じてデータを修正して新しい項目をリストに追加することができる。アプリケーションは、項目リストの新しい部分をモータに供給し、モータは、再びＨＴＭＬページを生成する。
【００４０】
この例は、ＨＴＭＬ依存の符号化は全てモータが実行するため、クライアントプロセスのタイプ−ＨＴＭＬ−がアプリケーションに影響しないことを示している。
【００４１】
図６は、ユーザインターフェースの「ルックアンドフィール」が、実際には、抽象化層によって提供される情報に基づいてＨＴＭＬページを作成する、ＨＴＭＬレンダラ７２によって提供されることを明示している。これは、そのモータを使用しているアプリケーションが全て、エンドユーザに対して同じ「ルックアンドフィール」を与えるユーザインターフェースを、ウェブブラウザ上に提供することを保証する。アプリケーションに携わっている開発者は、ブラウザのユーザインターフェースを気にかける必要なく、実際のアプリケーションに集中することができる。また、レンダラを使用することによって、ユーザインターフェースの「ルックアンドフィール」を変更することが可能になる。レンダラを変更しさえすればユーザインターフェースを変更できる。例えば、色、フォント、その他同様のユーザインターフェースの特徴は、レンダラで定義される。これらを、アプリケーション自体を修正または変更することなく、レンダラを修正することによって、または新しいレンダラを備えることによって変更することができる。ユーザインターフェースをカスタマイズする別の方法としては、レンダラにＨＴＭＬ静的リソースの異なるセット−ＣＳＳまたは画像−を備えることが挙げられる。静的リソースを変更することによって、レンダラを再開発する必要なく、ユーザインターフェースの見た目が変更される。
【００４２】
当業者であれば、プログラミングの技術分野において知られている技術を使って、本発明を再現することができる。上述のように、モータとクライアントプロセスの間の通信に使用される言語は、ＨＴＭＬおよび関連技術を含むことができる。図５の例においてモータとアプリケーションプロセスの間の通信に使用される言語は、サーバ内で、モータとアプリケーションの間の通信に使用される言語と同様の専用言語であってよい。この専用言語は、Ｊａｖａ（登録商標）言語で定義された１組のクラス、およびＸＭＬ文法で成り立つものであってよい。
【００４３】
本発明は、図を参照しながら説明した様々なステップを実行するためのルーチンを備えたプログラムで実施することができる。
【００４４】
本発明は、図を参照しながら説明した例および実施形態に限定されるものではない。「サーバ」は、データを含み、アプリケーションおよびモータを実行するコンピュータシステムとして、論理的な意味で理解すべきである。サーバは、様々なマシン−例えば、データを含むための別個のマシン−で、あるいは単一のコンピュータで具体化することができる。要求および応答は、ＵＲＬ要求およびＨＴＭＬ応答を表すものではなく、単に、サーバへの、およびサーバからのメッセージの流れを表すものである。「要求」は、ユーザマシンまたはプロセスがサーバに対して行うものであり、「応答」は、ユーザマシンまたはプロセスがサーバから受け取るものである。図中、わかり易くするために、サーバプロセス内にデータ５６を示してある。しかし、データがサーバプロセスの一部ではないと考えることもできる。これは、本発明の動作には関係がない。
【００４５】
図３および図４の例では、わかり易くするために２つのクライアントプロセスのみを示してあるが、システムは、様々な、または同じタイプの、より多くのクライアントプロセスを備えることができる。図３から図５では、実装については詳細に説明していない。実際、システムのプロセスを具体化するために、多くの様々な解決策が使用できる。同様に、様々なプロセス間のリンクの物理的実装も様々である。図５の例では、イントラネットまたはインターネットネットワークを介して、リンク６２および９６を確立することができる。アプリケーションプロセス８０、８２は、同じマシン上で実行することができる。クライアントプロセスは、マシンに接続された遠距離に位置する端末上で実行することができる。モータは、別個の製品として、または一式のシステムの一部として販売することができる。
【図面の簡単な説明】
【００４６】
【図１】ＨＴＭＬクライアントのための従来のサーバのアーキテクチャを示す概略図である。
【図２】ＣＡＴＩＡシステムのアーキテクチャを示す概略図である。
【図３】同様のクライアントプロセスを備えた、本発明によるシステムのアーキテクチャを示す概略図である。
【図４】異なるクライアントプロセスを備えた、本発明によるシステムのアーキテクチャを示す概略図である。
【図５】本発明によるシステムの別の実施形態のアーキテクチャを示す概略図である。
【図６】本発明によるシステムのより詳細な概略図である。
【符号の説明】
【００４７】
２  サーバプロセス
４  データ
６  アプリケーション
８、３６、３８、６０、８４、８６  モータ
１０、１２、２０、２２、５２、５４、６８、７６、７８  クライアントプロセス
２４  マシン
２６、５６  データ
２８、３０  ＣＡＴＩＡプロセス
３２、３４、５８  アプリケーション
５０  サーバプロセス
６２、６４、６６、７０、９６  通信リンク
７２、７４  レンダラ
７５  アプリケーションインターフェース
８０、８２  ＣＡＴＩＡプロセス
８８、９０  ＣＡＴＩＡアプリケーション
９２、９４  クライアントインターフェース
１００  ウェブブラウザ
１０２  ブラウザフレーム
１０４  サーバアプリケーションユーザインターフェース
１０６  抽象化層
１０８、１１０、１１２、１１４  矢印
【図１】
2004342085.tif 000003
【図２】
2004342085.tif 000004
【図３】
2004342085.tif 000005
【図４】
2004342085.tif 000006
【図５】
2004342085.tif 000007
【図６】
2004342085.tif 000008