(57)【特許請求の範囲】
【請求項１】
１台または複数のコンピュータ間でアプリケーションを連携させて動作させる情報処理システムであって、
当該システムの各コンピュータにて所有されるアプリケーションを所定の階層構造に割り当てたパスをアプリケーションの識別情報として用いて、第１のアプリケーションから連携すべき第２のアプリケーションを指定する指定手段と、
前記指定手段の用いたパスにおいて、階層の要素が要素名によらずに当該要素と前記第１のアプリケーションにおける当該階層の要素との関係により指定された表現を、当該第１のアプリケーションにおける当該階層の要素名に基づいて実際の要素名に展開する展開手段と、
前記展開手段による展開後のパスにより前記第２のアプリケーションを特定する特定手段とを備えることを特徴とする情報処理システム。
【請求項２】
前記指定手段は、連携すべき前記第２のアプリケーションのアプリケーション名を含んだ前記所定の階層構造のパスにより当該第２のアプリケーションの指定を行うことを特徴とする請求項１に記載の情報処理システム。
【請求項３】
前記指定手段は、前記階層の要素が要素名によらずに指定された表現を用いて複数の前記第２のアプリケーションを一括して指定することを特徴とする請求項１に記載の情報処理システム。
【請求項４】
前記指定手段は、階層を示すパスに、該階層に位置付けられた複数のアプリケーションのアプリケーション名を組み合わせて、複数の前記第２のアプリケーションを指定することを特徴とする請求項１に記載の情報処理システム。
【請求項５】
前記所定の階層構造は、当該情報処理システムにおける複数のユーザによる共同作業をルートとすることを特徴とする請求項１に記載の情報処理システム。
【請求項６】
前記特定手段によって特定された前記第２のアプリケーションに対してコマンドを配送する配送手段を更に備えることを特徴とする請求項１に記載の情報処理システム。
【請求項７】
前記配送手段によるコマンドの配送先である前記第２のアプリケーションが動作していない場合に、該アプリケーションの起動を行う起動手段を更に備えることを特徴とする請求項６に記載の情報処理システム。
【請求項８】
他のコンピュータと連携して構成されるシステム、或は自装置内で構成されるシステムにおいて、アプリケーションを連携させて動作させることが可能な情報処理装置であって、
当該情報処理装置が所有するアプリケーションを所定の階層構造に割り当てたパスをアプリケーションの識別情報として用いて、第１のアプリケーションから連携すべき第２のアプリケーションを指定する指定手段と、
前記指定手段の用いたパスにおいて、階層の要素が要素名によらずに当該要素と前記第１のアプリケーションにおける当該階層の要素との関係により指定された表現を、当該第１のアプリケーションにおける当該階層の要素名に基づいて実際の要素名に展開する展開手段と、
前記展開手段による展開後のパスにより前記第２のアプリケーションを特定する特定手段とを備えることを特徴とする情報処理装置。
【請求項９】
１または複数の情報処理装置で構成されるシステムにおいて、アプリケーションを連携させて動作させるための情報処理方法であって、
各情報処理装置が所有するアプリケーションを所定の階層構造に割り当てたパスをアプリケーションの識別情報として用いて、第１のアプリケーションから連携すべき第２のアプリケーションを指定する指定工程と、
前記指定手段の用いたパスにおいて、階層の要素が要素名によらずに当該要素と前記第１のアプリケーションにおける当該階層の要素との関係により指定された表現を、当該第１のアプリケーションにおける当該階層の要素名に基づいて実際の要素名に展開する展開工程と、
前記展開工程による展開後のパスによりアプリケーションを特定する特定工程とを備えることを特徴とする情報処理方法。
【発明の詳細な説明】
【０００１】
【産業上の利用分野】
本発明は、1台または複数のコンピュータ上で、複数のアプリケーションを連係させて動作させることが可能な情報処理方法及び装置及びシステムに関するものである。
【０００２】
【従来の技術】
近年、パーソナル・コンピュータやワークステーション上で、ウィンドウ・システムを利用したGUI(グラフィカル・ユーザ・インタフェース)の普及がめざましい。それに伴い、ユーザに提供されるアプリケーションも、かつてのGUI以前のプログラム環境におけるアプリケーションにくらべ、より複雑かつ多様な機能をより洗練された形で提供することを要求される様になってきた。
【０００３】
このような要求に対し単独のアプリケーションの拡張を繰り返すことにより対応するのではなく、アプリケーション間の協調動作メカニズムの提供により比較的単純なアプリケーションを複数組み合わせることを可能にして、さまざまな状況に対応しようという試みが広くおこなわれるようになってきている。このようなアプリケーション間の協調動作のための基本メカニズムとして、一般的にプロセス間通信によるデータ交換機構が使用されている。
【０００４】
データ交換機構の代表的なものとしては、Unixオペレーティング・システム（商標）が提供するソケット（商標）やMachオペレーティング・システム（商標）が提供するポート（商標）などが基本メカニズムとして利用されている。また、これらの基本メカニズム上に適当なプログラムを付加することにより、よりアプリケーション開発者にとって利用しやすいインタフェースを提供しているシステムもある。このようなシステムの代表例としては、Sunオペレーティング・システム（商標）のSun RPC（商標）やSolarisオペレーティング・システム（商標）のToolTalk（商標）などが存在する。
【０００５】
上記のようなユーザ環境の高度化といえる現象と並行するような形で、ユーザ間の協調作業サポートをおこなうグループウェア・システムが注目を集めている。
【０００６】
このグループウェア・システムは、複数の人間による共同作業を支援することを目的としたコンピュータ・ソフトウェアであり、特に近年ネットワークを介した共同作業の支援に大きなウエイトを置いている。一般的なグループウェア・システムはビデオ映像を利用したテレビ会議機能や共同執筆エディタなどを提供し、ネットワークを介した遠隔地との共同作業や会議を可能にしている。このようなグループウェア実現のアプローチとして、前述のユーザ環境を複数のコンピュータを包括する形で利用されるような環境に拡張することが考えられる。そのためには、アプリケーション間の協調動作のための基本メカニズムをグループウェアで要求される協調動作に対応できるように拡張する必要が生じる。
【０００７】
【発明が解決しようとする課題】
アプリケーション間通信のメカニズムを、ユーザ間の協調作業環境にまで拡張するためには、次のような制約を解消ないし緩和する必要がある。即ち、各ユーザの作業環境であるユーザ環境は、そこで動作するアプリケーション群によって構成され特徴づけられる。したがって、ユーザ間の協調作業環境の実現はユーザ環境間の協調、ひいてはユーザ環境を構成するアプリケーション群の協調によって実現される。ここで、あるアプリケーションが他のユーザ環境のアプリケーション群との協調動作を実現するためには、そのアプリケーションは他のユーザ環境がどのようなアプリケーション群から構成され、それぞれがどのような役割を担っているのかという情報を、知っていなければならない。
【０００８】
例えば、ユーザ環境Aで動作するアプリケーションaがユーザ環境Bで動作しているアプリケーションbと通信をおこなうような状況を想定すると、アプリケーションaは通信相手がアプリケーションbであるという情報を知っていなければならない。
【０００９】
しかしながらグループウェア環境では、通信相手がアプリケーションbであることは、この時点でたまたまそうなっただけであり、別の時点ではアプリケーションbがユーザ環境B'で動作しているかもしれないし、また、別の時点においてはユーザ環境Cで動作するアプリケーションcと通信をおこなう必要があるかもしれない。
【００１０】
通信相手の管理の一般的手法としては、ユーザないしグループ環境上で動作するプロセスに一意な名前をつけることがおこなわれる。しかしながら、名前の重複を回避する責任はアプリケーション開発者の責任となっているため、上記のように動的にアプリケーションやユーザの構成が頻繁に変化するような環境に対応することが困難であるという問題が発生している。
【００１１】
本発明は上記の問題点に鑑みてなされたものであり、１台又は複数のコンピュータで構成されるシステムにおいて、動的に構成要素が変動しうる複雑な環境に対応可能な、柔軟なアプリケーション間協調システムを提供できる情報処理方法及び装置及びシステムを提供することを目的とする。
【００１２】
また、本発明の他の目的は、１台又は複数のコンピュータで構成されるシステムにおいて、動的に構成要素が変動しうる複雑な環境におけるアプリケーション管理を、高い抽象度で扱うことを可能とする情報処理方法及び装置及びシステムを提供することを目的とする。
【００１３】
また、本発明の他の目的は、１台又は複数のコンピュータで構成されるシステムにおいて、動的に構成要素が変動しうる複雑な環境を特に意識することなく、その環境で動作するアプリケーションを構築することを可能とする情報処理方法及び装置及びシステムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
上記の目的を達成するための本発明の情報処理システムは以下の構成を備えている。即ち、
１台または複数のコンピュータ間でアプリケーションを連携させて動作させる情報処理システムであって、
当該システムの各コンピュータにて所有されるアプリケーションを所定の階層構造に割り当てたパスをアプリケーションの識別情報として用いて、第１のアプリケーションから連携すべき第２のアプリケーションを指定する指定手段と、
前記指定手段の用いたパスにおいて、階層の要素が要素名によらずに当該要素と前記第１のアプリケーションにおける当該階層の要素との関係により指定された表現を、当該第１のアプリケーションにおける当該階層の要素名に基づいて実際の要素名に展開する展開手段と、
前記展開手段による展開後のパスにより前記第２のアプリケーションを特定する特定手段とを備える。
【００１５】
また、好ましくは、前記指定手段は、連携すべき前記第２のアプリケーションのアプリケーション名を含んだ前記所定の階層構造のパスにより当該第２のアプリケーションの指定を行う。アプリケーション名に階層構造のパスが付加されるので、その環境で動作すべきアプリケーションを容易に指定できるからである。
【００１６】
また、好ましくは、前記指定手段は、前記階層の要素が要素名によらずに指定された表現を用いて複数の前記第２のアプリケーションを一括して指定する。複数のアプリケーションを抽象的に指定することが可能となるからである。
【００１７】
【作用】
上記の構成によれば、１台または複数のコンピュータ間でアプリケーションを連携させて動作させる情報処理システムにおいて、当該システムの各コンピュータにて所有されるアプリケーションを所定の階層構造に割り当てたパスをアプリケーションの識別情報として用いて、第１のアプリケーションから連携すべき第２のアプリケーションを指定し、この指定で用いたパスにおいて、階層の要素が要素名によらずに、当該要素と第１のアプリケーションにおける当該階層の要素との関係により指定された表現を、当該第１のアプリケーションにおける当該階層の要素名に基づいて実際の要素名に展開し、展開後のパスにより連携すべきアプリケーションの特定が行われる。
【００１８】
【実施例】
以下に添付の図面を参照して本発明の好適な実施例について説明する。
【００１９】
＜実施例１＞
図１は、実施例１による協調型グループウェア・システムの概要を説明する図図である。このグループウェア・システムは、複数のユーザが各ユーザ環境で複数のアプリケーションを駆使しつつ、これらのユーザおよびアプリケーション間でさなざまなデータのやり取りをおこなわせることにより、グループ共同作業環境を提供するものである。
【００２０】
図1において、パーソナル・コンピュータ１０１，１０２，１０３がイーサ・ケーブル１０４で結合され、１つのＬＡＮを形成している。実際にはさらに数台のワークステーションが結合される。また、本実施例はＷＡＮを中心としたコンピュータ・ネットワークにも適用可能なものである。さらにイーサ・ケーブルより高速なFDDIなどから構成されるＬＡＮにおいても適用可能である。
【００２１】
図１では、各パーソナル・コンピュータ(以降ＰＣとよぶ)は１人づつのユーザ１０５，１０６，１０７によって使用されている。各ユーザがどのＰＣを使用するかは固定されておらず、ユーザ１０５がＰＣ１０２を利用する場合も考えられる。また、ユーザ１０５がＰＣ１０１と１０２の両方を同時に使用するような場合も想定することができる。
【００２２】
各ＰＣ上では、このグループウェア・システムを管理しサービスの提供をおこなう基本ソフトウェアDesktopMgr１０８、１０９と、そのサービスを利用するアプリケーション(以降ツールプロセスないしツールとよぶ)群が動作している。ここで、DesktopMgr１０８，１０９は、各ユーザごとに１つ存在する基本ソフトウェアであり、ユーザ環境で動作しているツール群の起動，停止，通信などの制御のサポートを含めたユーザ環境の管理と、ユーザ間ないしネッワーク全体での情報交換の管理をおこなう。
【００２３】
DesktopMgr自身は、展開モジュール１１０、ツール管理モジュール１１１及びユーザ情報管理モジュール１１２の３種類のモジュールから構成される。
【００２４】
展開モジュール１１０は、ユーザによっておこなわれたツール指定をDesktopMgrが解釈可能な形に展開する。この展開は、従来正規表現の展開などでおこなわれているように、ある特殊表現をあらわす文字列を、実際のツールの名前などで置換することによって実現される。
【００２５】
ツール管理モジュール１１１は、ユーザ環境で動作しているツールが動作中か否かなどのツール群に関する情報を管理する。ツール情報はこのモジュールにより、ツールの名前をキーとするハッシュ・テーブルを使用して管理される。また、ツール管理モジュール１１１では、ツール情報に基づきツールの起動をおこなう。ツールの起動自体は、このシステムが動作しているオペレーティングシステムの機構を利用する。
【００２６】
ユーザ情報管理モジュール１１２はユーザ情報の管理をおこなう。ユーザ情報はユーザ情報管理モジュール１１２により、ユーザの名前をキーとするハッシュ・テーブルを使用して管理される。各ユーザ環境のDesktopMgrの通信ポートもユーザ情報に含まれており、他のユーザ環境を管理しているDesktopMgrとの通信をおこなうためなどに使用される。
【００２７】
各ユーザ環境で動作するツール群は、上述のDesktopMgr１０８，１０９の提供するサービスを利用して他のユーザ環境に存在するツールとの協調動作をおこなうことが可能である。
【００２８】
図２は、このようにして構成されているグループウェア・システムの利用形態の一例を示す図である。ここでは、２つのＰＣで２人のユーザが共同作業をおこなっており、ディスプレイ２０１，２０２上にいくつかのツールのインタフェースが表示されている。
【００２９】
図２では、データベース・アクセスツール２０３，２０４、テキストエディタ・ツール２０５，２０６、ドロー・ツール２０７，２０８が各ユーザ環境で使用されている。ユーザ間で形成されている上記のツールのペアは、各ユーザに同じ情報を表示している。たとえば、テキストエディタ・ツール２０５と２０６は同じ文書を表示している。ただし、テキストエディタ・ツール２０５と２０６はまったく同じツールとは限らないし、また同じ文章を表示していたとしても表示の方式は異なるかもしれない。このグループウェア・システムでは、同じ情報を同等に処理する能力があるツールならばユーザの好みに合わせて使用することが可能である。
【００３０】
次に、図２に示すようなグループ共同作業環境におけるユーザおよびツール群の管理方式について図３を用いて説明する。
【００３１】
図３において、３人のユーザA,B,Cが存在し、それぞれユーザ環境３０１，３０２，３０３上で作業をおこなっていると仮定する。さらに、ユーザA,B,Cの3人が共同しておこなっている作業３０４と、またそれと同時に進行しているユーザAとBの共同作業３０５が存在しているものとする。共同作業３０４，３０５はユーザ環境にまたがるグループ環境とみなすことも可能である。
【００３２】
本実施例では、この共同作業(ないしグループ環境)をセッションとよび、図３における２つの共同作業をそれぞれセッション３０４，セッション３０５とよぶことにする。図３から明らかな様に、1人のユーザが同時に複数のセッションに参加することも可能である（ユーザA及びユーザB）。
【００３３】
また、各セッション内の実際の作業にはセッションによって指定されたツール群が利用される。図中の３０６，３０７は、セッション３０４におけるユーザ環境３０１で利用されているツールを表現している。
【００３４】
図４は、あるセッションに参加している1ユーザのユーザ環境の様子をあらわした図である。図４では、ユーザ環境４０１が1つのセッション４０２に属している。このセッション４０１では、３つのツール４０３，４０４，４０５が共同作業に使用されている。ただし、そのうちツール４０３とツール４０４はいくつかの小さなツール(サブツールとよぶ)の集まりで形成されている。サブツール自身も単独のツールとして機能することもできる能力を持っている。図４においては、ツール４０３はツール４０６とツール４０７の2つのサブツールで構成されている。また、ツール４０４は、ツール４０８，ツール４０９，ツール４１０の３つのサブツールで構成されている。さらにサブツールであるツール４０８自身もサブツール４１１で構成されている。
【００３５】
本実施例では複数のサブツールの集まりとして構成されているツールのことを統合ツールとよぶ。また、サブツールに分割できない(統合ツール以外の)ツールのことを要素ツールとよぶ。以降ツールとよぶときは、統合ツールと要素ツールを総括して指示するときや特に区別する必要がないときとする。なお、実際には統合ツールは管理上の仮想的な存在に過ぎず、その機能は要素ツールが協力することにより実現される。
【００３６】
図４において、ツール４０７，４１１，４０９，４１０，４０５は要素ツールであり、ツール４０３，４０４，４０６，４０８は統合ツールであることをあらわしている。図４で示した、ユーザ環境におけるセッション，ユーザ，ツール群の関連をまとめると図５に示す階層構造となる。
【００３７】
図５は、図４に示したユーザ環境におけるセッション/ユーザ/ツール群の関連を表す図である。
【００３８】
セッション５０１を階層構造の根(ルート)として、その下にセッション５０１に参加しているユーザ５０２，５０３，５０４が存在し、さらに各ユーザの下には５０５，５０６，５０７のようなツールが存在する。これらのツールの内、そのツール５０６のような統合ツールについては、５０８や５０９のようなサブ・ツールが付加され、最終的に要素ツールに行き着くまで階層構造が続くことになる。本実施例では、セッションが入れ子になるような場合を禁止しているが、ここで述べる事項はセッションの入れ子を許すシステムにおいても適用可能である。
【００３９】
図５と図４の関連を説明すると、セッション５０１は、図４のセッション４０２に相当する。また、ユーザＡ５０２はユーザ環境４０１に対応する。ツールＡ５０５は、ツールＡ４０３に、ツールＢ５０６はツールＢ４０４に、ツールＣ５０７はツールＣ４０６に夫々対応している。
【００４０】
本実施例では、この階層構造を基に名前空間を形成し、セッションの管理下にあるすべてのツールを指示することを可能にする。すなわち、図５の階層構造をセッションから辿った名前の道筋をツール・パスとよび、これを各ツールを指定する手段として使用する。
【００４１】
本実施例におけるツール・パスは、以下に示すようにセッション名，ユーザ名，ツール名の各階層の名前を'&'でつなげた文字列となる。即ち、
&セッション名&ユーザ名&ツール名&サブ・ツール名...
となる。たとえば、図５におけるツール５０９をあらわすツール・パスは、
&セッション&ユーザA&ツールB&サブ・ツール#2
となる。ここで、セッション名,ユーザ名,ツール名などのツール・パスの構成要素となる各階層の名前をノード名とよぶ。ツール・パスをツールの識別子として使用するためにノード名は各階層において一意でなければならない。
【００４２】
また、ツール・パスでは、［と］の中に複数のノード名を”，”で区切って列挙することにより、ノード名を複数指定することも可能である。たとえば、「&セッション&ユーザA&ツールB&サブ・ツール#2」と「&セッション&ユーザB&ツールB&サブ・ツール#2」をまとめて、
&セッション&[ユーザA, ユーザB]&ツールB&サブ・ツール#2
と表記することが可能である。
【００４３】
更に、ノード名指定において何種類かの特殊表現を使用することが可能である。特殊表現はノード名の抽象的な指示を可能にするものである。以下に、特殊表現について説明をしておく。
【００４４】
まず、セッション名の階層では、
・%current
・%all
・%none
・%ignore
が指定可能である。夫々の特殊表現について詳細を説明すると、
%current  …  「%current」を指定すると、その指定がおこなわれたツールがその時点で属しているセッション名と解釈される．
%all  …  「%all」を指定すると、その時点で稼働中の全てのセッションの名前と解釈される．
%none  …  「%none」を指定すると、特定のセッションに属していないことをあらわす。各ユーザ環境で動作しているプロセスには、セッションとは無関係のものも存在しうる．
%ignore  …  「%ignore」は、セッションの有無やその名前が無視できることを表現する．意味的には[%all, %none]を指定することと等価である。
【００４５】
次に、ユーザ名の階層では、
・%self
・%all
・%allbutself
が指定できる。夫々の特殊表現の詳細を説明すると、
%self  …  「%self」を指定すると、その指定がおこなわれたツールが属しているユーザ環境を利用しているユーザの名前と解釈される．
%all  …  「%all」を指定すると、その直前で指定されたセッションに属している全ユーザと解釈される．
%allbutself  …  「%allbutself」を指定すると、その直前で指定されたセッションに属しているユーザから、%selfをのぞいた全ユーザと解釈される。したがって、[%self, %allbutself]は%allと同じ意味となる。
【００４６】
最後に、ツール名の階層では、
・%self
・%selfonly
・%super
・%parent
・%all
が指定可能となる。夫々の特殊表現の詳細を説明すると、
%self  …  「%self」を指定すると、その指定がおこなわれたツール自身のツール名が補われる。そのツールが実は、あるツールのサブ・ツールになっていた場合は、そのツールのユーザ名以降の階層構造がそのまま追加される．
%selfonly  …  「%selfonly」を指定すると、その指定がおこなわれたツール自身のツール名が補われる。そのツールがあるツールのサブ・ツールになっていた場合でもツールの階層関係は無視される．
%super  …  「%super」を指定すると、その指定がおこなわれたツール自身の1つ上の階層までのツール階層が補われる。このため&%super&%selfonlyと指定することは&%selfと指定したことと同じことになる．
%parent  …  「%parent」を指定すると、その直前までのツールパスで指定されたツール階層から1つ上の階層に遡ることになる。%superが直前までで指定されたパスをまったく無視するのに対し、%parentは直前までで指定されたパスに依存した意味をもつ．
%all  …  「%all」を指定すると、その直前までのツールパスで指定されたツール階層に属する全てのツールを指定することになる。
【００４７】
以上のような特殊表現を組み合わせると、例えば、以下のようなツールパスを表現することが可能となる。
【００４８】
例１．  &%current&%all&%self
これは、このツールパスの指定をおこなったツールが、その時点で属しているセッションの全ユーザ環境における、指定をおこなったツール自身のコピーをあらわす。ここで"ツールのコピー"とは、ユーザ名をのぞいて全てが同じツール・パスをもつツールのことである。まったく同じ種類のツールを使用していることが多いので、"ツールのコピー"とよぶ。
【００４９】
例２．  &%current&%all&%super&%all
このツールパスの指定をおこなったツールが、その時点で属しているセッションの全ユーザ環境における、指定をおこなったツールと同一階層に存在するすべてのツールをあらわす。
【００５０】
例３．  &%none&ユーザC&%super&ツールX
これは、ユーザCのユーザ環境において、指定をおこなったツールと同じ階層に存在するツールXというツール名のツールをあらわす。
【００５１】
以上のようにして導入されたツール・パスを本実施例においてはツールの制御に利用している。図６，７はこの様子をあらわした図である。
【００５２】
図６は、セッションの起動にともなうツールの起動の様子をあらわした図である。また、そのときのDesktopMgrの振る舞いをあらわしたフローチャートが図８である。
【００５３】
２人のユーザA６０１とユーザB６０２がそれぞれユーザ環境６０３，６０４上で共同作業を開始しようとしているものとする。共同作業の開始は、それを表現するセッションの起動によっておこなわれる。ここでは、ユーザA６０１がセッションの起動をおこなうものとする。
【００５４】
ユーザA６０１のセッション起動要求６０５は、ＰＣ６０３上のユーザ環境を管理しているDesktopMgr６０６に通知される。セッション起動要求６０５をうけとったDesktopMgr６０６は（ステップＳ８０１）、その要求がユーザから要求されたものか、それとも他のDesktopMgrから転送されてきたものかをチェックする(ステップＳ８０２)。この場合はユーザから要求されたものなので、セッション起動要求６０５を他のDesktopMgrにも転送する（ステップＳ８０３）。他のユーザ環境のDesktopMgrと通信を行うために必要な情報は、DesktopMgr６０６内のユーザ情報管理モジュール６１２で管理されている。
【００５５】
その後DesktopMgr６０６は、ツール管理モジュール６１３で管理されているツール情報から、セッション内で使用されるツールA６０９がすでに起動されているか調べる（ステップＳ８０４）。まだ起動されていなかったらツールA６０９を起動する（ステップＳ８０５）。
【００５６】
一方、ユーザB６０２のユーザ環境を管理しているDesktopManager６０７では、DesktopMgr６０６から転送されたセッション起動要求６０８をうけとると、当該起動要求はユーザＢ６０２から直接発行されたものではないので、ステップＳ８０２からステップＳ８０４へ進み、直ちにセッション内で使用されるツールA６１０を起動する（ステップＳ８０４、ステップＳ８０５）。
【００５７】
ここで、ツールA６０９の起動は以下のコマンドで実行される。即ち、
launchTool "ツールA" "&セッション&ユーザA&ツールA"
となる。これは、ツールAを起動し、その起動されたプロセスに「&セッション&ユーザA&ツールA」と名前づけせよ、というコマンドである。このようにして起動されたツールA６０９のプロセスは、以降「&セッション&ユーザA&ツールA」というツール・パスで指定することが可能になる。
【００５８】
また、DesktopManager６０７もセッション起動要求６０８を受け取ると、
launchTool "ツールA" "&セッション&ユーザB&ツールA"
なるコマンドを実行してツールA６１０を起動する。起動されたツールA６１０のプロセスは、以降、"&セッション&ユーザB&ツールA"というツール・パスで指定することが可能になる。
【００５９】
図７は、本実施例におけるツール・パスを利用したメッセージ配送の機構を説明する図である。同図は、図６で起動されたセッションでの共同作業の途中の状態をあらわしている。また、図９は、この状況におけるDesktopMgrの振る舞いをフローチャートで表現したものである。図７において、ユーザA６０１が以下のメッセージ転送コマンド７０５をDesktopMgr６０６に発行したと仮定する。
【００６０】
メッセージ転送コマンドは、
forwardMessage "&セッション&%all&ツールA" "do-something"
で表わされる。このコマンドは、「セッションに属する全ユーザのツールAに"do-something"というメッセージを転送せよ」、という意味である。
【００６１】
DesktopMgr６０６がこのメッセージ転送コマンド７０５を受け取ると(ステップＳ９０１)、その第１引数であるツール・パス、「&セッション&%all&ツールA」内の特殊表現「%all」を展開モジュール６１３で具体的なユーザ名に展開する(ステップＳ９０２)。この例における展開結果は、
"&セッション&ユーザA&ツールA"
"&セッション&ユーザB&ツールA"
となる。
【００６２】
DesktopMgr６０６は、上記の展開をおこなうと、その結果に基づきメッセージ転送コマンドを再構成する(ステップＳ９０３）。ここで再構成されるコマンドは、
forwardMessage "&セッション&ユーザA&ツールA" "do-something"
forwardMessage "&セッション&ユーザB&ツールA" "do-something"
の２つである。
【００６３】
このように１つのコマンドがツール・パスの展開により複数のコマンドに変換されうる。本実施例におけるDesktopMgrではこれらのコマンドを順番に処理していくが、同時に処理することも可能である。
【００６４】
DesktopMgr６０６は、再構成されたコマンドを1つ取り出し（ステップＳ９０４）、そのコマンドで指定されているツール・パスのセッション名とユーザ名を抜き出して、そのセッションとユーザの組み合わせがDesktopMgr６０６自身の管理下にあるか確認する（ステップＳ９０５）。
【００６５】
セッションとユーザの組み合わせがDesktopMgr６０６自身の管理下に無い場合は、ユーザ情報管理モジュール６１２で管理されているユーザ情報から、ツール・パスで指定されたユーザの環境を管理しているDesktopMgrとの通信ポートを取り出し（ステップＳ９０６）、そのDesktopMgrにコマンドを転送する（ステップＳ９０７）。
【００６６】
一方、指定されたツールがDesktopMgr６０６自身の管理下に存在するならば、ツール・パスから指定されたツール・プロセスを特定し（ステップＳ９０８）、メッセージを配送する（ステップＳ９０９）。
【００６７】
以上の処理を、コマンドがなくなるまで繰り返す（ステップＳ９１０）。なお、ステップＳ９０６、ステップＳ９０７の処理によってコマンドを転送される側のDesktopMgr（本例ではDesktopMgr６０７）においても、転送元と同じく上記の処理をおこなう。
【００６８】
なお、図９に示したアルゴリズムでは、最初に要求をうけとったDesktopMgrがツール・パス内の特殊表現をすべて展開するが、別の展開手順としてステップＳ９０２における展開をセッション名とユーザ名のみにとどめ、残りのツール名の展開を各ユーザ環境を管理しているDesktopMgrに実行させるというアルゴリズムによっても本実施例を実現することが可能である。
【００６９】
図７の例では、１つ目のコマンドのツール・パスがユーザAのユーザ環境に関連することから、1つ目のコマンドはDesktopMgr６０６自身によって処理される。２つ目のコマンドは、ツール・パスがユーザBのユーザ環境に関連することから、当該コマンドはDesktopMgr６０７に転送され、DesktopMgr６０７によって処理される。
【００７０】
DesktopMgr６０６はメッセージ転送コマンド６０８を送ると、「&セッション&ユーザA&ツールA」で特定されるプロセス６０９（即ちツールA６０９）にメッセージ「do-something」を転送する。また、DesktopMgr６０７においても、メッセージ転送コマンド７０８が受け取られると、「&セッション&ユーザB&ツールA」で特定されるプロセス６１０（即ちツールA６１０）にメッセージ「do-something」が転送される。
【００７１】
図７では、たまたまツールＡがもう一つ（ツールＡ７１１）起動されているが、図６で述べた起動コマンドlaunchToolにより、ツールＡ７１１にはツールＡ６１０とは異なるツール・パスが指定されているため、ツールＡ７１１に当該メッセージが転送されることはない。
【００７２】
以上をまとめると、本実施例はグループウェア・システムにおけるアプリケーション間通信機構に本発明を適用した例を示すものである。本実施例において、セッション，ユーザ環境，ツール，サブ・ツールの階層構造を利用したツール・パスと、ツール・パス上における特殊表現を導入した。また、ツール・パスを利用してツールの制御をおこなうDesktopMgrを導入した。
【００７３】
また、本実施例では、グループウェア・システムにおけるセッションの構造に則した階層構造の利用により、ツール指示の一意性が管理しやすくなる。また、特殊表現を導入することにより各ツールが通信相手を指定する場合により抽象的な指定が可能となる。このため、グループウェア・システムにおける頻繁なユーザの参加・退席などによる動的な作業環境の変化にも対応することが可能となる。
なお、上記実施例１では、階層構造を管理するためのデータ構造を特に設けず、ツールパスを表す文字列で図５に示すような階層構造を実質的に管理している。しかしながら、図５のような階層構造を、内部的に別のデータ構造で表現して管理することも可能であることはいうまでもない。
【００７４】
＜実施例２＞
上述の実施例１においてグループウェア・システムにおける本発明の適用例を説明したが、本発明はデータベースを中心とした非同期型データ共有システムに対しても適用可能である。ここではデータベースを利用したマルチメディア・データ検索システムへの実施例について説明する。
【００７５】
図１０は実施例２におけるマルチメディア・データ検索システムの概要を表す図である。同図によれば、データベース１００１が存在し、そこでは画像・音声などのマルチメディア・データ１００２〜１００６が管理されている。このデータベース１００１にはクライアントとしてＰＣ１００７が結合されており、ユーザ１００８によって利用されている。なお、この図では１台のＰＣのみがデータベース１００１のクライアントとなっているが、実際には複数のＰＣやワークステーションをクライアントとすることが可能である。また、データベース１００１自身がネットワーク１００９上に分散しているような構成を取ることもありうる。
【００７６】
ＰＣ１００７上では、３種類のデータ・ビューアが起動されており、それぞれ対応するマルチメディア・データの参照に使用される。画像ビューア１０１０はデータベース１００１中の画像データ１００２と１００５の参照に使用され、動画ビューア１０１１は動画データ１００４と１００６、文書ビューア１０１２は文書データ１００３の参照に使用される。これらの対応関係は、図１０においては、ビューアとデータにつけられた背景模様（網掛け）の対応関係で示されている。
【００７７】
図１１は、本実施例をユーザの視点からはどのように見えるかを示したものである。図１１では、ユーザ１１０１がディスプレイ１１０２上で作業をおこなっている。このディスプレイ１１０２は、図１０で示したデータベースのクライアントとなっているＰＣ１００７の表示装置である。
【００７８】
ディスプレイ１１０２上には４つのウィンドウ１１０３，１１０４，１１０５，１１０６が表示されており、それぞれ対応したマルチメディア・データを表示している。ウィンドウ１１０３は、データベース内を検索するためのアプリケーション（データベース検索アプリ）のユーザインタフェースを提供する。また、ウィンドウ１１０４，１１０５，１１０６は夫々、静止画像，動画，文書などのビューアのユーザ・インタフェースを提供する。
【００７９】
データベース検索アプリはウィンドウ１１０３上に、データベースで管理されているマルチメディア・データのカタログ１１０７を表示する。このカタログは、データベース検索アプリから参照することが可能なデータをあらわすアイコンと、そのデータの名前のリストで構成される。カタログには若干の付加情報として、データサイズや作成された日付などの情報も付加される。ユーザがカタログから適当なデータのアイコンを選択すると、そのデータに適したビューアにデータを表示させる（１１０８，１１０９，１１１０）。
【００８０】
このようなマルチメディア・データ検索システムを、さまざまなクライアントからアクセス可能な分散システムとして実現するに当たり、各クライアントがまったく同じ環境(すなわちデータ・ビューア)をもっていると仮定することはできない。
【００８１】
図１２においては、２人のユーザ１２０１と１２０２がそれぞれＰＣ１２０３，１２０４を使用してデータベース１２０５にアクセスしている。２人ともデータベース検索アプリ１２０６，１２０７を使用し、同じデータのカタログを参照しているが、各データを参照するためのデータ・ビューアには異なるものを使用している。図１２においては、ユーザ１２０１の環境では３つのデータ・ビューア１２０８，１２０９，１２１０でカタログ上のデータが参照されているが、ユーザ１２０２の環境では２つのデータ・ビューア１２１１，１２１２でデータ参照が可能である。
【００８２】
次に、図１２で示したような状況に対応するための本発明の適用例を以下に説明する。
【００８３】
まず、各ユーザ環境におけるデータビューアを実施例１と同様にカタログ名，ユーザ名，ビューア名の階層構造に基づいて名前づけをおこなう。その結果導きだされるパス表現をビューア・パスとよび以下の様に表記する。即ち、
&カタログ名&ユーザ名&データビューア名&サブ・データビューア名...
となる。このように、本実施例２においても、実施例１で述べたようなデータ・ビューアの統合ツール化に対応すべく、データ・ビューア名の階層化をおこなっている。
【００８４】
次にパス表記における特殊表現を導入する。本実施例２ではカタログ名とユーザ名の特殊表現が導入される。以下に、各階層毎の特殊表現について詳細に説明する。
【００８５】
まず、カタログ名の階層では:
・%all
が指定可能である。「%all」を指定すると、そのデータベース内に存在する全てのカタログの名前と解釈される。
【００８６】
また、ユーザ名の階層で指定可能なものは:
・%ignore
・%group
である。各特殊表現を以下に説明すると、
%ignore  …  「%ignore」を指定するとユーザ名を無視する．
%group  …  「%group」は%group(グループ名)という使い方をする。この場合カッコ内の名前をグループの名前として解釈する。ここでグループはユーザ名のリストとして定義されている。
【００８７】
本実施例では、このビューア・パスをデータベース１２０５中の各データに対するデータ・ビューア指定情報として使用する。ビューア・パスはデータベース１２０５の各データに付加され、データベース１２０５で管理される。一般的なデータ用のビューアは、
&%all&%ignore&データビューア名
と指定されている。
【００８８】
ここで、ビューア・パスと実際のビューアとの対応関係を管理するサーバとして、DesktopMgrを導入する。DesktopMgrはユーザ環境ごとに１つずつ存在する。これは実施例1におけるDesktopMgrと同名であり、役割も良く似ているため、この２種類のDesktopMgrを統合することも可能である。
【００８９】
図１３は、ビューア・パスとDesktopMgrを用いた、本実施例２におけるデータ参照処理の様子を示した図である。また、図１４は、この処理の中心となるDesktopMgrの動作を示すフローチャートである。
【００９０】
図１３では、ユーザ１３０１がデータベース検索アプリ１３０２において、アイコン１３０３を指定してデータの参照を要求したという状況での処理をあらわしている。ユーザ１３０１によるディスプレイ上での操作は、イベント１３０４としてデータベース検索アプリの本体１３０５に通知される。データベース検索アプリ１３０５はイベント１３０４を解釈し、アイコン１３０３が指定されたことを検知すると、DesktopMgr１３０８にアイコン１３０３の本体であるデータ１３０７の表示要求を適切なビューアに配送する要求を発行する。
【００９１】
DesktopMgr１３０８は、この要求を受け取ると（ステップＳ１４０１）、データ１３０７に付加されているビューア・パスをデータベース１３０６から取り出す（ステップＳ１４０２）。DesktopMgr１３０８は、次に、ビューア・パスに対応するデータ・ビューアが既に起動されているかを調べ（ステップＳ１４０３）、起動されていないか使用不能状態ならば当該データ・ビューアを起動する(ステップＳ１４０４）。図１３においては、データ・ビューア１３０９が起動される。一方、データ・ビューア１３０９が既に起動されていて、データを表示できる状態ならば、データ１３０７の表示要求１３１０をデータ・ビューア１３０９に配送する（ステップＳ１４０５）。データ・ビューア１３０９が要求された表示要求を実行することにより、ユーザの要求通りデータの参照が可能になる。
【００９２】
本実施例２では、以上のように、クライアントごとのカスタマイズを許すマルチメディア・データ検索システムにおける本発明の実施例である。本実施例において、カタログ，ユーザ環境，ビューア，サブ・ビューアの階層構造を利用したビューア・パスと、ビューア・パス上における特殊表現を導入した。また、ビューア・パスを利用してビューアの制御をおこなうDesktopMgrを導入した。
【００９３】
以上のように、本実施例２によれば、ビューア・パス上の階層におけるさまざまなレベルで、ユーザ環境ごとに適したデータ・ビューアの指定をおこなうことが可能となる。たとえばビューア・パスのユーザ名を制限することなどにより、特定のユーザのみ参照可能にしたり、部分的な参照を可能にするなどの制御をおこなうことも可能である。また、ユーザ環境におけるビューアの管理をDesktopMgrが肩代わりするので、データベース検索アプリや、さまざまなデータ・ビューアの開発や導入のコストを軽減することが可能となる。
【００９４】
尚、本発明は、複数の機器から構成されるシステムに適用しても１つの機器からなる装置に適用しても良い。また、本発明はシステム或いは装置に本発明により規定される処理を実行させるプログラムを供給することによって達成される場合にも適用できることはいうまでもない。
【００９５】
【発明の効果】
以上説明したように本発明によれば、複数のコンピュータで構成されるシステムにおいて、動的に構成要素が変動しうる複雑な環境に対応可能な、柔軟なアプリケーション間協調システムを提供できる。
【００９６】
また、本発明によれば、動的に構成要素が変動しうる複雑な環境におけるアプリケーション管理を、高い抽象度で扱うことが可能となる、
また、本発明によれば、動的に構成要素が変動しうる複雑な環境を特に意識することなく、その環境で動作するアプリケーションを構築することが可能となる。
【００９７】
【図面の簡単な説明】
【図１】実施例１による協調型グループウェア・システムの概要を説明する図図である。
【図２】グループウェア・システムの利用形態の一例を示す図である。
【図３】図２に示すようなグループ共同作業環境におけるユーザおよびツール群の管理方式の一例を説明する図である。
【図４】あるセッションに参加している１ユーザのユーザ環境の様子をあらわした図である。
【図５】図４に示したユーザ環境におけるセッション/ユーザ/ツール群の関連を表す図である。
【図６】セッションの起動にともなうツールの起動の様子をあらわした図である。
【図７】本実施例におけるツール・パスを利用したメッセージ配送の機構を説明する図である。
【図８】セッション起動時のDesktopMgrの動作を表すフローチャートである。
【図９】メッセージ配送時のDesktopMgrの動作を表すフローチャートである。
【図１０】実施例２におけるマルチメディア・データ検索システムの概要を表す図である。
【図１１】実施例２における表示例を表す図である。
【図１２】２人のユーザによるデータベースへのアクセス状態を表す図である。
【図１３】実施例２におけるデータ参照処理の様子を説明する図である。
【図１４】実施例２におけるDesktopMgrの動作を示すフローチャートである。
【符号の説明】
１０１，１０２，１０３  パーソナル・コンピュータ
１０４  ネットワークケーブル
１０５，１０６，１０７  ユーザ
１０８，１０９  DesktopMgr
１１０  展開モジュール
１１１  ツール管理モジュール
１１２  ユーザ情報管理モジュール
【図１】
0003673540.tif 000002
【図２】
0003673540.tif 000003
【図３】
0003673540.tif 000004
【図４】
0003673540.tif 000005
【図５】
0003673540.tif 000006
【図６】
0003673540.tif 000007
【図７】
0003673540.tif 000008
【図８】
0003673540.tif 000009
【図９】
0003673540.tif 000010
【図１０】
0003673540.tif 000011
【図１１】
0003673540.tif 000012
【図１２】
0003673540.tif 000013
【図１３】
0003673540.tif 000014
【図１４】
0003673540.tif 000015