(57)【特許請求の範囲】
【請求項１】
プログラムを記憶したコンピュータ読み取り可能な媒体であって、
スクリプト言語で記述され且つエンドユーザにより修正可能なラッパーコンポーネントをメモリにロードし、複数の所望の機能を実現し得る複数のソフトウエアコンポーネントをメモリにロードするステップであって、上記ラッパーコンポーネントは上記ソフトウエアコンポーネントの１つに関連付けられ、上記ラッパーコンポーネントは外部アプリケーションによって呼び出されるよう構成され且つ関連するソフトウエアコンポーネントを呼び出すように構成され、上記関連するソフトウエアコンポーネントは、上記外部アプリケーションによって使用可能なアプリケーションプログラムインターフェース(API)を有していないステップと、
上記ラッパーコンポーネントを呼び出し、関連するソフトウエアコンポーネントを呼び出すステップと、
を有し、該関連するソフトウエアコンポーネント及び他のソフトウエアコンポーネント間では、データ又は文書は実際には転送されないが、該データ又は文書へのリンクを含むコンテンツテーブルが転送され、
上記関連する又は他のソフトウエアコンポーネントは、上記コンテンツテーブルを受信し上記リンクを介して上記データ又は文書データにアクセスし、
上記データ又は文書と上記コンテンツテーブルとは別個のファイルに含まれるようにした方法をコンピュータに実行させるプログラムを記憶した媒体。
【請求項２】
上記複数のソフトウエアコンポーネントの外部アプリケーションにより、所望のシーケンスにおけるソフトウエアコンポーネント及び上記ラッパーコンポーネントが呼び出される請求項１記載のコンピュータ読み取り可能な媒体。
【請求項３】
上記コンテンツテーブルが、上記データ又は文書の属性と関連した属性データも含む請求項１記載のコンピュータ読み取り可能な媒体。
【請求項４】
上記スクリプト言語はHTML文書に組み込まれるものである請求項１記載のコンピュータ読み取り可能な媒体。
【請求項５】
複数のタスクを実行可能であり且つコンピュータで実行可能な以下のステップを有する方法であって、
複数のラッパーコンポーネントをメモリにロードし、複数のソフトウエアコンポーネントをメモリにロードするステップであって、各ソフトウエアコンポーネントはタスクの１つを実行するよう構成されており、各ラッパーコンポーネントは、各自のソフトウエアコンポーネントに関連し且つスクリプト言語で記述されエンドユーザによって修正可能であり、各ラッパーコンポーネントは外部アプリケーションによって呼び出され且つ関連するソフトウエアコンポーネントを呼び出すように構成され、上記関連するソフトウエアコンポーネントは上記ラッパーコンポーネントによって使用可能なアプリケーションプログラムインターフェース(API)を有していないステップと、
上記複数のタスクのシーケンスを決めるステップと、
上記シーケンス内の各タスクに対応するソフトウエアコンポーネントに関連する上記ラッパーコンポーネントを呼び出し、該ラッパーコンポーネントに対応するソフトウエアコンポーネントを起動し、関連するタスクを実行するステップと、
を有し、第１のソフトウエアコンポーネント及び第２のソフトウエアコンポーネントの間では、データ又は文書は実際には転送されないが、該データ又は文書へのリンクを含むコンテンツテーブルが転送され、
上記第１又は第２のソフトウエアコンポーネントは、上記コンテンツテーブルを受信し上記リンクを介して上記データ又は文書データにアクセスするようにした方法。
【請求項６】
上記ラッパーコンポーネントをロードするステップが、HTML文書中にあるスクリプト言語で記述された上記ラッパーコンポーネントをロードするステップを更に有する請求項５記載の方法。
【請求項７】
上記コンテンツテーブルが、上記データ又は文書の属性に関連する属性データも含む請求項５記載の方法。
【請求項８】
複数のタスクを実行するソフトウエアプリケーションを動作させ且つコンピュータによって実行される以下のステップを有する方法であって、
上記ソフトウエアコンポーネント各々に関連したラッパー構造をメモリにロードし、複数のソフトウエアコンポーネントをメモリにロードするステップであって、各ソフトウエアコンポーネントは対応するタスクを実行可能であるステップと、
アプリケーションの一部として制御構造をメモリにロードするステップであって、上記制御構造は、ユーザによって生起されるイベントに対応する動作を規定し、上記制御構造により、所望のタスクを実行するため上記ソフトウエアコンポーネントのシーケンスの呼び出しを行うステップと、
を有し、上記ラッパー構造はスクリプト言語で記述され、エンドユーザによって修正可能であり、
上記制御構造によって設定される呼び出しシーケンスにおけるソフトウエアコンポーネント各々の呼び出しは、各ソフトウエアコンポーネントに関連した上記ラッパー構造を呼び出し、該ラッパー構造により所望のソフトウエアコンポーネントを呼び出すことで行われ、
上記タスクを実行する際に、データ又は文書自体ではなく、上記データ又は文書へのリンクを含むコンテンツテーブルが、第１及び第２のソフトウエアコンポーネントの間で転送され、上記第１又は第２のソフトウエアコンポーネントは、上記コンテンツテーブルを受信し上記リンクを介して上記データ又は文書へアクセスするようにした方法。
【請求項９】
上記コンテンツテーブルが、上記データ若しくは文書の属性と関連したデータも含む請求項８記載の方法。
【請求項１０】
上記ラッパー構造をロードするステップが、HTML文書中にあるスクリプト言語で記述された上記ラッパー構造をロードするステップを更に有する請求項８記載の方法。
【請求項１１】
タスク指向アプリケーションを実行する装置であって、
所望の第１機能、所望の第２機能、スクリプト言語で記述されたラッパーコンポーネントの機能を実行するための命令を有する記憶媒体と、
上記記憶媒体にエンコードされた命令を実行する処理ユニットであって、上記命令は上記処理ユニットにより読み出し可能である処理ユニットと、
を有し、上記ラッパーコンポーネントは、外部アプリケーションによって呼び出され、上記所望の第１機能を実行する命令を呼び出すよう構成され、上記所望の第１機能のための命令は、上記外部アプリケーションによって使用可能なアプリケーションプログラムインターフェース(API)を備えておらず、
上記外部アプリケーションから呼び出された場合に上記ラッパーコンポーネントは起動し、
上記第１及び第２機能を実行するモジュール間では、データ又は文書へのリンクを含むコンテンツテーブルが転送され、上記第１又は第２機能を実行するモジュールは、上記コンテンツテーブルを受信し上記リンクを介して上記データ又は文書へアクセスし、
上記コンテンツテーブル及び上記データ又は文書はコンピュータ読取可能な媒体上で上別個のファイルに格納されるようにした装置。
【請求項１２】
上記ラッパーコンポーネントは、スクリプト言語で記述され、ユーザにより修正可能である請求項１１記載の装置。
【請求項１３】
上記コンテンツテーブルが、上記データ又は文書の属性に関連する属性データも含む請求項１１記載の装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータソフトウェアアーキテクチャに係わり、特に、特定のタスクを実行する複数のソフトウェアコンポーネントにより構成されたアプリケーションのためのソフトウェアアーキテクチャに関する。本発明のソフトウェアアーキテクチャは、ソフトウェアコンポーネントを異なる順序で実行し、データ又は文書をコンポーネントの間で効率的に転送することを支援する。
【０００２】
本発明は、また、本発明のソフトウェアアーキテクチャに従ってタスク指向アプリケーションを実現するコンピュータハードウェア及び方法に関する。
【０００３】
【従来の技術】
コンピュータソフトウェアエンジニアリングの分野には、構造化された設計とソフトウェアアプリケーションの実現を導くように意図された設計原理の開発が含まれる。このような設計原理の一つは、アプリケーションのためのタスク指向アーキテクチャである。タスク指向アーキテクチャにおいて、アプリケーションによって実行される機能（例えば、スペルチェック、指定されたロケーションへのデータの転送、データ変換など）は、別々のタスクとして表現され、各タスクはアプリケーションプログラムの専用コンポーネント若しくはモジュールによって実行される。コンポーネント若しくはモジュールは、典型的に、ユーザからの入力を必要とすることなく特定の手順で呼び出される。呼び出されたコンポーネントは、ユーザが望む全体的な機能を実行する一連のタスクを実行する。
【０００４】
アプリケーションが一連のタスクを実行する際の統一性が増加するという観点、並びに、ソフトウェアプログラムのサイズを縮小するという観点でより高い効率を達成するため、コンポーネント若しくはモジュールが多数のアプリケーションの間で共用されることが望ましい。これにより、所望の機能の組を実行するため、汎用的なタスク実行用のコンポーネントの組を特定の順序で組み合わせることが可能になる。コンポーネント若しくはモジュールベースのソフトウェアアーキテクチャは、各コンポーネントを実質的に自己充足的に設計することができるので、この特定の順序の組合せが容易に実現される。
【０００５】
しかし、特定のタスク用のコンポーネントを、他のコンポーネント共に、或いは、多数のアプリケーションの一部として種々の順序で利用しようとするとき、そのタスクのインタフェースがアプリケーションの呼び出し側コンポーネントのインタフェース、或いは、そのタスクコンポーネントによって呼び出されたアプリケーションコンポーネントのインタフェースと完全には適合しないという問題点が生じる。この問題点は、多種のタスクを新しいアプリケーションに実現すべく設計されたコンポーネントを再配置する能力を制限する。
【０００６】
あらゆるアプリケーションのあらゆるソフトウェアコンポーネントが共通のインタフェースを備えるように設計することは可能であるが、これには膨大な作業を要する。このような解決法は、互換性のないインタフェースを用いて記述された既存のソフトウェアコンポーネント（「遺産的」ソフトウェアと呼ばれる場合がある）にどうやってアクセスするかという問題を取り扱わない。
【０００７】
異なるインタフェースを具備したソフトウェアコンポーネントが一体的に動作できるようにする一つの解決法は、「ラッパー」と呼ばれる。ラッパーとは、特定のアプリケーション若しくはコンポーネントの（階層的な意味で）上部或いは外部に設けられたソフトウェア構造体である。ラッパーは、ラップされたアプリケーション若しくはコンポーネントと、外部アプリケーション若しくはコンポーネントの間の仲介役として機能する。ラッパーは、外部（呼び出し側）アプリケーション若しくはコンポーネントからの入力命令を受理し、ラップされたアプリケーション若しくはコンポーネントと共通インタフェースを設けることにより、所望のタスクを行うため包み込まれたアプリケーション若しくはコンポーネントを実行させることができる。これは、典型的に、ラップされたソフトウェアからの文字ストリームを手続的或いはオブジェクト指向ＡＰＩ（アプリケーション・プログラム・インタフェース）に変換することにより実現される。外部ソフトウェアアプリケーション若しくはコンポーネントは、ＡＰＩを介してラップされたソフトウェアと相互作用する。このように、ラッパーは、呼び出し元と呼び出し先のアプリケーション若しくはコンポーネントの間の互換性インタフェースの必要性を取り除く。したがって、ラッパーは、汎用的インタフェースと、ラップされたコンポーネントの専用インタフェースとの間で変換機能を実現しているとみなされる。
【０００８】
【発明が解決しようとする課題】
しかし、ラッパーの使用によって、ソフトウェアアプリケーション及び／又はコンポーネントインタフェースの不適合の問題は解決されるとしても、従来のラッパー方式には制限がある。従来のラッパー方式の主な欠点は、ラッパーは、ラップされたソフトウェアに専用に合わせて作られることである。すなわち、ラッパーのコードは、ラップされたコンポーネントと同じ言語、Ｃ若しくはＣＯＢＯＬに対する手続的インタフェースの形式、或いは、Ｃ＋＋若しくはＳｍａｌｌｔａｌｋに対するオブジェクト指向インタフェースの形式で記述される。その結果として、新しいラッパーは、新たにラップされるアプリケーション若しくはコンポーネント毎に記述される必要がある。その上、そのような言語で記述されたラッパーは、ラップされたコンポーネントの変化を受け容れるためユーザが変更できない。このため、ユーザがラッパーをカスタム化し、拡張する能力に重大な制限が生じ、その結果として、ソフトウェアアーキテクチャ自体の柔軟性が制限される。
【０００９】
従来のタスク指向アーキテクチャの別の欠点は、データ若しくは文書がアプリケーションの中の異なるコンポーネントの間、又は、異なるアプリケーションのコンポーネントの間で転送される方式に関係する。従来のアーキテクチャの場合、実際のデータ若しくは文書は、コンポーネント間の専用フォーマットで転送される。これにより、交換されるデータ若しくは文書のタイプが制限される。その理由は、交換されるタイプは専用フォーマットに従う必要があり、そのフォーマットに確実にコード化されていないデータタイプが認識されないからである。また、この専用フォーマットによる転送は、コンポーネントが交換されるデータの属性を変えることを許さない。また、これにより、コンポーネントが、そのフォーマットによって定義されたデータ属性以外のデータ属性を操作する必要があるタスクを実行する能力は制限される。
【００１０】
したがって、本発明は、異なるインタフェースを有するコンポーネント若しくはアプリケーションへのアクセスを許すためユーザによってカスタム化可能なタスク指向アプリケーションのためのコンピュータソフトウェアアーキテクチャの提供を目的とする。
また、本発明は、このようなコンピュータソフトウェアアーキテクチャを実現するコンピュータハードウェア及び方法の提供を目的とする。
【００１１】
【課題を解決するための手段】
本発明のタスク指向アプリケーションのためのソフトウェアアーキテクチャは、外部の呼び出し元アプリケーションと、ラップされたコンポーネント若しくはモジュールとの間に仲介構造としてラッパーを利用する。ラッパーは、スクリプト言語で記述され、外部アプリケーションとラップされたコンポーネントとの間に橋渡し用のインタフェースを提供するため作用する。データは、データ属性情報及び実際のデータへのハイパーリンクを含むコンテンツテーブル（ＴＯＣ）ファイルの仲介によってコンポーネント間で転送される。
【００１２】
また、本発明のコンピュータハードウェア及び方法は、上記本発明のソフトウェアアーキテクチャを実現する。
【００１３】
【発明の実施の形態】
本発明の一実施例は、多数のアプリケーションの一部としてのソフトウェアコンポーネント若しくはモジュールの使用を促進するソフトウェアアーキテクチャである。各コンポーネントは指定されたタスク又は機能を実現し、このとき、実行されるコンポーネントの順序及びタイプは実現されるアプリケーションの全体的な機能を決める。個別のコンポーネントはラッパー（又は、ラップ）と呼ばれるソフトウェア構造に包み込まれ、このラッパーは外部ソフトウェアコンポーネントのインタフェースと、包み込まれたコンポーネントのインタフェースとの間の橋渡しを行う。ラッパーは、種々の外部ソフトウェアアプリケーションに包み込まれたコンポーネントを実行させることができる。データ若しくは文書は、従来技術のように実際のデータ若しくは文書を専用フォーマットで転送するのではなく、データ若しくは文書へのハイパーリンクを含むファイルの転送を用いて、二つのソフトウェアコンポーネントの間で転送される。本発明によるラッパーとファイル転送機構の組合せによって、構造化された効率的な形でソフトウェアアプリケーションを実行する柔軟なアーキテクチャが得られる。
【００１４】
図１の（Ａ）及び（Ｂ）は、呼び出し元プログラムと、ラップされたコンポーネントとの間で橋渡しを行う本発明のラッパーが使用される形態を示すブロック図である。同図の（Ａ）に示されるように、従来のアーキテクチャの場合、呼び出し元プログラム若しくはルーチン（同図の「呼び出し元」）１０は、特定のタスクを実現させるためソフトウェアコンポーネント１２を呼び出す。呼び出し元１０及びコンポーネント１２は、典型的に両者間だけに使用される共通インタフェースを有する。この専用性のため、ソフトウェアコンポーネント１２にそのタスク又は機能を実行させる呼び出し元アプリケーションの範囲は制限される。
【００１５】
図１の（Ｂ）には、ラッパー１４が呼び出し元プログラム若しくはルーチン１０とソフトウェアコンポーネント１２の間で橋渡しを行うため使用される形態が示されている。ラッパー１４は、コンポーネント１２の専用インタフェースを用いてコンポーネント１２にアクセスすることが可能であり、また、呼び出し側１０との共通インタフェース（同図の「汎用インタフェース」）を介して呼び出し元１０と通信を行うことができる。動作中、呼び出し元プログラムはラッパーを呼び出し、ラッパーは包み込まれたコンポーネントを呼び出すため作用する。
【００１６】
異なるアプリケーション間でソフトウェアコンポーネントを交換可能にさせるため（すなわち、呼び出させるようにするため）、コンポーネント間で交換されたデータは共通フォーマットを必要とする。この標準フォーマットは汎用インタフェースの要素である。個々のコンポーネントによって処理されるデータのタイプとは無関係に、ラッパーは専用データフォーマットを包み込み、本発明のタスク試行アプリケーションアーキテクチャにかかる汎用インタフェースを設けるため使用され得る。
【００１７】
ラッパー１４は、専用インタフェースを包み込む上位レベルのソフトウェア構造を提供し、より広い範囲の呼び出し元プログラムがコンポーネント１２を実行させることを可能にする。しかし、従来のラッパーに対し、本発明によるラッパーは、ユーザの要求に応じてカスタマイズと拡張を行うことができる。これにより、ラッパーは、呼び出されるコンポーネントの変化、或いは、コンポーネントを呼び出す望ましい順序の変化を反映させるためエンドユーザの要求に応じて変更され得る。
【００１８】
これらの本発明の特徴は、従来のラッパーのようなコンパイル言語ではなく、スクリプト言語の形式でラッパーを記述することにより実現される。図２には、本発明を実現するためスクリプト言語で記述されたラッパーが組み込まれたＨＴＭＬ文書のフォーマットが示されている。
ＨＴＭＬ文書の場合、スクリプト言語は、文書によって定義された制御構造がユーザによって生成されたイベントの生起に応じて反応する態様（例えば、ボタンの押下、データの選択、別のページからの移動、或いは、別のページへの移動）を記述する。例えば、テキスト「ＯＫ」が示され、「ＯＫボタン」と呼ばれるボタンが与えられた場合に、ユーザがこのボタンを選択したときにある動作を実行することが望ましいならば、そのイベントを処理する手続（例えば、サーバーにデータを送信、或いは、指定されたメッセージをユーザに提示）を記述するように関数を作成することが可能である。
【００１９】
図２に示されるように、スクリプトは、以下のような形でＨＴＭＬ文書に組み込まれる。
＜本文＞
任意のＨＴＭＬ
＜スクリプト＞
スクリプト言語の挿入箇所
＜スクリプトの終わり＞
任意のＨＴＭＬ
＜本文の終わり＞
スクリプト言語は、通常ＨＴＭＬ自体では実行されない機能を実現する外部コンポーネントをロードし実行させるため使用できる点に注意する必要がある。
【００２０】
ラッパーは、インターネットのウェブページのためのＨＴＭＬ文書の作成と同じように作成することができる。しかし、通常のウェブ文書との相違点は、ラッパーが典型的にユーザインタフェース若しくはグラフィックスのためのスクリプトを含まない点である。本発明のラッパー構造は、典型的に、サブルーチンとして機能するスクリプトプログラムを含む。そのため、本発明のラッパーを作成するためテキストエディタを使用してもよい。これにより、ラッパーを簡便に編集、実行することができるので、ラッパーのプロトタイプを素早く作成するために役立つ。
【００２１】
図２に示されたコードは、典型的なＨＴＭＬ文書の骨格だけを表している。本発明のラッパーのために以下の二つの特徴が要求されることに注意する必要がある。
（１）呼び出し先のコンポーネントは＜Ｏｂｊｅｃｔ＞タグで宣言される。このスクリプトは、コンポーネントをロードし、実行する。
【００２２】
（２）関数は、＜Ｓｃｒｉｐｔ＞タグの後に置かれる。この関数は、呼び出し元アプリケーションとコンポーネントの間を仲介し、図２の「スクリプトプログラムが挿入される箇所」に置かれる。
ラッパーの関数部は、スクリプト言語仕様に準拠して記述される。例えば、ＪａｖａＳｃｒｉｐｔの場合、関数は以下のフォーマットで指定される。
【００２３】
function  public＿AnyName()
｛
//  任意の手続の挿入箇所
｝
ここで、ｐｕｂｌｉｃ＿の形の接頭辞は、他のプログラムがラッパーの外部からこのスクリプトにアクセスするため必要である。
【００２４】
ラッパーをスクリプト言語で記述する利点は、エンドユーザが書き換えることができる点である。これは、エンドユーザがソースコードを利用できないコンパイラベースの言語（例えば、Ｃ＋＋）によって記述されたラッパーの場合には実現できない点である。従来のラッパーはコンパイラベースであるため、多数の開発者が使用することができず、コンポーネントインタフェース又はコンテンツの変更に適合するようにラッパーによって呼び出されるコンポーネントを変更したいエンドユーザの希望を打ち破っている。
【００２５】
上記の通り、本発明のラッパーは、アプリケーションの拡張及びカスタマイズを行うためエンドユーザによって容易に変更することができる。例えば、ラッパーのコンテンツに対する変更は、以下のような状況で求められる。
（１）ラッパーによって呼び出されたコンポーネントのインタフェースが変更されたとき。この状況では、本発明のラッパーは新しいインタフェースに適合するように変更される。
【００２６】
（２）呼び出し先のコンポーネントを変更したいとき。一般的にラッパーのスクリプトには、コンポーネントの名前若しくは他の形式の識別情報が含まれる。編集できないラッパーの場合、開発者だけが呼び出し先のコンポーネントを変更することができる。本発明の場合、編集可能なラッパーによって、エンドユーザは、呼び出し先のコンポーネントが変更できるように、ラッパーのコンテンツを変更することが可能である。
【００２７】
一例として、呼び出し先のコンポーネントがスペルチェッカーである場合を考える。異なる辞書を必要とするため、異なるインタフェースをもつ改良型のスペルチェッカーが後で開発されたとする。この状況では、ラッパーは新しいコンポーネントと適合するように変更することが可能である。次に、アプリケーションは、別の言語のためのスペルチェッカーを実装することを要求する。このとき、ラッパーは、スペルチェッカーの名前を「コンポーネント１」から「コンポーネント２」に変更するだけで済むので、僅かな変更しか必要とされない。
【００２８】
図３は、外部の呼び出し元プログラムが、本発明のアーキテクチャのラッパーを仲介として、ラップされたコンポーネントを実行させるときの主要なステップを示すフローチャートである。同図に示されるように、呼び出し元アプリケーション（呼び出し元）は、通常の関数を呼び出す場合と同様に、ラッパーのスクリプトに指定された関数ｆ（ｘ，ｙ）を呼び出す。呼び出し元は、通常の関数呼び出しで使用される方法であらゆる引数（すなわち、ｘ、ｙのようなパラメータ）を渡す。コンポーネントに含まれる目的関数ｇ（ｕ，ｖ，ｗ）を呼び出すため、ブロック図の中程に示されるように、入力パラメータ（ｘ，ｙ）を呼び出し元フォーマットからコンポーネント固有のフォーマットに変換する手続が要求される。このスクリプトの箇所は、ロジックを関数ｇ（ｕ，ｖ，ｗ）の仕様に適合させるため必要に応じて変更される。
【００２９】
例えば、関数ｆ（ｘ，ｙ）は、（例えば）引数ｘのようなスプレッドシートファイル名を許容し、関数ｇが引数ｕのようなデータベースファイル名だけを許容する場合、ラッパーは、調整若しくは変更ステップにおいて、要求に応じてデータを変換する。データベースのデータフォーマット若しくは仕様が変更された場合、このラッパーの箇所は変更され、図３の下部に示されたコンポーネント呼び出しは新しい関数、例えば、ｈ（ｓ，ｔ）によって置き換えられる。
【００３０】
図４は、本発明のアーキテクチャに従って構成されたラッパーと関連したタスク実現用コンポーネントのアーキテクチャ及び疑似コードの一例を示すブロック図である。同図では、呼び出し元は、タスク指向アプリケーションを表現し、そこから関数ＲｅｎｄｅｒＴｅｘｔが呼び出される場合を想定する。この関数ＲｅｎｄｅｒＴｅｘｔを含むコンポーネントを包み込むラッパーは、呼び出し元コードの１行目にラッパー名を宣言することによって呼び出し元と関連付けられる。遂行されるべきタスクに依存して、呼び出し元は、例えば、音声ラッパー若しくは翻訳ラッパーを呼び出す。図示した例の場合、音声ラッパーが所望の関数と関連付けられている場合、この関数はテキスト文字列をコンピュータ合成音声を用いて読ませる。この場合、音声ラッパーから呼び出された音声コンポーネントがこのタスクを実行する。本発明のラッパー機構の重要な利点は、ラッパースクリプトを変更するだけでアプリケーションの特徴を変更できる点である。音声コンポーネントの変わりに、テキスト部を翻訳することが望ましいならば、本例の場合に、ラッパースクリプトの数行と、アプリケーションの最初の行とを変更するだけでよい。本例の場合、翻訳ラッパーは選択されたテキストを用いて翻訳コンポーネントを実行させるため呼び出される。ラッパーはスクリプトで記述されているため、新しいソースコードを生成し、コンパイルし、デバッグする必要がない。また、コンパイル形式の言語で記述されたラッパーは、屡々、コンポーネントの名前若しくは識別情報がソースコードに確実にコード化されることを要求するので、特定のコンポーネントに依存する。このため、新しいコンポーネント若しくは既存のコンポーネントの新しい使い方に適合するよう変更することに関してラッパーの柔軟性が制限される。
【００３１】
本発明のアーキテクチャの第２の重要な面は、ソフトウェアコンポーネント間でデータ若しくは文書転送を容易に行うため、特定のデータフォーマットを使用することである。このデータフォーマットは、異なるタイプ及びフォーマットの文書の取扱を簡単化し、ソフトウェアコンポーネントによって関心のある上記データ若しくは文書属性を識別し、コンポーネントに転送できるようにする。
【００３２】
図５の（Ａ）は、データが従来のアーキテクチャで２個のコンポーネントの間で伝達される態様を示し、（Ｂ）は、本発明のアーキテクチャに従ってデータがコンテンツテーブルのフォーマットを使用して伝達される態様を示す図である。同図の（Ａ）に示されるように、従来のアーキテクチャの場合、コンポーネントＡは、コンポーネントＢへの入力としてデータ若しくは文書を専用フォーマットで転送する。これにより、実施できる転送は、予め認識された専用フォーマットでフォーマット済みのデータに限定される。
【００３３】
同図の（Ｂ）に示されるように、本発明のアーキテクチャの場合、ＨＴＭＬファイルフォーマット（若しくは、別の適当なマークアップ言語）が、コンテンツテーブル（ＴＯＣ）ファイルを生成するため使用される。本発明によるＴＯＣファイルは、データベースファイルと類似したデータレコードを収容する。かかるＴＯＣレコードの重要なフィールドは、文書へのハイパーリンクである。連結された文書は、このアーキテクチャのソフトウェアコンポーネントによって入力ファイルとして取り扱われる。本発明のアーキテクチャの場合に、コンポーネントが文書をそのまま受信することはない。その代わりに、ＴＯＣファイルが伝達され、コンポーネントはファイル内のリンクを介して文書にアクセスする。コンポーネントはデータファイルを作成する場合があるが、コンポーネントは、ファイルをそのまま他のコンポーネントに送信することがない。その代わりに、コンポーネントは、ＴＯＣファイルを作成、若しくは、更新し、更新されたＴＯＣフィル内の文書にリンクを張る。
【００３４】
ハイパーリンクと共に、各レコードはデフォルトとして以下の属性データを収容する。
（１）情報タイプＩｎｆｏｔｙｐｅ：ブラウジングツール等で使用される情報のタイプ
（２）ＩｓＲｅａｄ：レコードが開かれたかどうかを示すため、メッセージボードのようなリストブラウジングツールで使用される属性
（３）主題Ｓｕｂｊｅｃｔ：レコードにリンクされたコンテンツの主題若しくはタイトル
（４）送信者Ｓｅｎｄｅｒ：メッセージ源のアドレス
（５）日付Ｄａｔｅ：メッセージが取得された日付
ＨＴＭＬ若しくは他の類似したマークアップ言語フォーマットを使用することにより、幾つかの重大な利点が得られる。このフォーマットは、公開され、かつ、標準化されている。すなわち、標準的な方法を用いて容易に構文解析できることを意味する。また、インターネットを支援するあらゆるプラットフォームでも利用できる。
【００３５】
データを間接的に（ハイパーリンク若しくは別の形式のリンクの媒体を介して）参照するためＴＯＣを使用することによって、本発明のアーキテクチャは、あらゆるタイプの文書を許容できるようになる。文書の付加的な特性（属性）は、ＨＴＭＬ若しくは他のマークアップ言語を用いて一方のコンポーネントから他方のコンポーネントに伝達され得る。コンポーネントは、属性をＴＯＣに追加しても構わない。例えば、コンポーネントは、「要約」のような属性を追加する。また、コンポーネントは、実行の際に不要な属性を無視することが可能である。例えば、コンポーネントは、実行時には、属性ＩｓＲｅａｄの値に依存しない。しかし、コンポーネントに入力されたＴＯＣに含まれるすべての属性は、そのコンポーネントから出力されるＴＯＣに保存されていなければならないことに注意する必要がある。
【００３６】
上述の通り、ＴＯＣファイルは、ＨＴＭＬ若しくはＸＭＬのようなマークアップ言語で記述できる。尚、ＨＴＭＬはインターネット上のウェブページを記述するため普及している言語であり、ＸＭＬはデータ構造を記述するため使用される言語である。ＴＯＣファイルは、文書ファイルにアクセスするためのハイパーリンクを含む。ハイパーリンクは、（例えば）ハードディスクドライブ上のメモリに記憶された文書のファイル名を含んでもよく、或いは、インターネット上の文書のアドレスを表してもよい。
【００３７】
上述の通り、ＴＯＣは、連結された文書毎に情報、例えば、連結された文書の作成日付、連結された文書のタイトル、或いは、連結された文書の要約を格納する。一例として、ＸＭＬで記述されたＴＯＣファイルは、以下の通りである。
<DateSent>00/00/0000</DateSent>
<Title>Patent Application</Title>
<Summary>This document is a patent application for ... </Summary>
上記の通り、他のデータをＴＯＣに追加してもよい。例えば、呼び出し先のソフトウェアコンポーネントが「文書が読まれたとき」に関するデータを必要とする場合、この情報を表現するタグがＴＯＣファイルに追加され得る。
【００３８】
<DateRead>00/00/0000</DateRead>
ＴＯＣファイルの一般的な構造を以下に示す。
・データフィールド定義
・ヘッダ（オプション）
・レコード番号１（内部に数フィールドを含む）
・レコード番号２（内部に数フィールドを含む）
・レコード番号ｎ（内部に数フィールドを含む）
図６は、本発明のアーキテクチャと共に使用するのに適したＨＴＭＬで記述されたＴＯＣファイルの一例を示すリストである。ＴＯＣファイルのスタイルＳｔｙｌｅ部は、ファイル内のデータフィールドを定義する。図６に示されたＴＯＣファイルの例は、データレコードに５個のフィールド（例えば、ｉｎｆｏｔｙｐｅ、ＩｓＲｅａｄ等）を有する。ＴＯＣファイルのＴａｂｌｅ部は、テーブルのヘッダ（スレッドｔｈｒｅａｄ）と、３個のデータレコードとを含む。各データレコードは、スタイル部に定義されたフィールド毎に対応したデータを含む。本例のＴＯＣファイルはデータ構造を記述するためテーブルタグＴａｂｌｅを使用しているが、他のタグを使用しても構わない。
【００３９】
本発明によるタスク指向アプリケーション用のアーキテクチャ及びファイル転送フォーマットについての説明を行った。このアーキテクチャには、複数のソフトウェアコンポーネントが含まれ、各コンポーネントは所望のタスク若しくは機能を実行できる。各コンポーネントはラッパー構造によって包み込まれ、これにより、呼び出し元アプリケーションとコンポーネントとの間に仲介が得られる。ラッパーは、スクリプト言語で記述され、新しいコンポーネントに適合し、或いは、既存のコンポーネントの変更に適合するようテキストエディタによって簡単に変更することができる。データ若しくは文書は、実際のデータ若しくは文書を専用フォーマットで転送する代わりに、データファイル若しくは文書へのリンクを含むファイルを転送することによって、コンポーネント間で転送される。本発明のアーキテクチャ及びファイル転送機構は、エンドユーザが実行されるソフトウェアコンポーネントの順序及びタイプをカスタマイズ、並びに、拡張することを許容する。
【００４０】
本発明のアーキテクチャは、コンピュータのコントローラ若しくは中央処理ユニット（ＣＰＵ）によって実行されるソフトウェアの形式で実現され、ソフトウェアはＣＰＵと関連したメモリ（例えば、ＲＯＭ）、或いは、ＣＰＵによってアクセスされる他のタイプの記憶媒体に記憶される。本発明のアーキテクチャは、コンピューティング装置へのコネクション（例えば、インターネット）を介してダウンロードされ得るプログラムとしても提供され、そのコンピューティング装置によって実行される構成でもよい。
【００４１】
上記の説明で使用された用語及び表現は説明のために使用されたものであり、本発明を制限するものではなく、また、これらの用語及び表現を使用することにより、図面及び明細書に開示された特徴若しくはその一部の等価物を除外することを意図するものではない。上記実施例は、特許請求の範囲に記載された本発明の範囲を逸脱することなく、種々の変形をなし得ることが認められるべきである。
【図面の簡単な説明】
【図１】（Ａ）及び（Ｂ）は、本発明のラッパーが呼び出し元のプログラムとラップされたコンポーネントとの間で橋渡しを行うため使用される態様を説明するブロック図である。
【図２】本発明を実現するためスクリプトで記述されたラッパーが組み込まれたＨＴＭＬ文書のフォーマットを示す図である。
【図３】外部の呼び出し元プログラムが本発明のアーキテクチャのラッパーを介してラップされたコンポーネントを実行させるときの主要なステップを示すフローチャートである。
【図４】本発明のアーキテクチャに従って構築されたラッパー及び関連したタスク実現用コンポーネントのアーキテクチャ及び疑似コードの一例を示す図である。
【図５】（Ａ）及び（Ｂ）は、従来のアーキテクチャにおいて２個のコンポーネントの間でデータが伝達される態様、及び、本発明のアーキテクチャに従ってコンテンツテーブルのフォーマットを使用して２個のコンポーネントの間でデータが伝達される態様を表す図である。
【図６】本発明のアーキテクチャと共に使用するため適したＨＴＭＬで記述されたコンテンツテーブルファイルの一例を示すリストである。
【符号の説明】
１０    呼び出し元プログラム
１２    ソフトウェアコンポーネント
１４    ラッパー
【図１】
0004146590.tif 000002
【図２】
0004146590.tif 000003
【図３】
0004146590.tif 000004
【図４】
0004146590.tif 000005
【図５】
0004146590.tif 000006
【図６】
0004146590.tif 000007