(57)【特許請求の範囲】
【請求項１】
コンピュータ・システムであって、
（ａ）少なくとも１つのアプリケーションをサポートするアプリケーション層であって、前記各アプリケーションはユーザ・インタフェースとビジネス・ロジックとを少なくとも含み、前記各アプリケーションは各アプリケーションによって共通に使用される共用サービスを使用する、前記アプリケーション層と、
（ｂ）前記各アプリケーションとインタフェースするサービス層であって、前記サービス層は前記各アプリケーションに使用される少なくとも１つの共用サービスをサポートし、前記サービス層は前記各共用サービスについての固有のアプリケーション・プログラミング・インターフェースを含み、当該アプリケーション・プログラミング・インターフェースは、前記各アプリケーションが前記共用サービスへ割り当てられたアプリケーション・プログラミング・インターフェースを介して要求を行うことを可能にし、前記共用サービスはレポジトリ・サービスを少なくとも含み、前記レポジトリ・サービスにおいて、前記アプリケーションのオブジェクトを関連付けてモデリングする為に使用される構造が階層木構造であり、前記オブジェクトは前記アプリケーションをモデリングするオブジェクト・タイプを属性として持ち、前記オブジェクト・タイプは、前記階層木構造に関連付けられたコンテンツを有し、前記階層木構造が検索クエリを実行する能力を提供し、及び、前記各アプリケーションの前記ユーザ・インタフェース及び前記ビジネス・ロジックと前記サービス層によって提供される共用サービスとを結合することによって、前記共用サービスを共用しないスタンドアロン独立型アプリケーションによって提供されるサービスを前記各アプリケーションが包含する必要なしにエミュレートすることが可能である、前記サービス層と、
（ｃ）前記サービス層とインタフェースするデータ層であって、前記コンテンツを含み、前記レポジトリ・サービスは前記データ層を介してアクセスされるリレーショナル・データベースと共に動作する、前記データ層と
を実装する、前記コンピュータ・システム。
【請求項２】
前記サービス層及び前記データ層とインタフェースするソフトウェア・インフラ層をさらに実装する、請求項１に記載のコンピュータ・システム。
【請求項３】
前記データ層とインタフェースするＯＳ層をさらに実装する、請求項１又は２に記載のコンピュータ・システム。
【請求項４】
前記アプリケーション層とインタフェースするウェブサーバ層をさらに実装する、請求項１〜３のいずれか一項に記載のコンピュータ・システム。
【請求項５】
コンピュータ・システムが実行する方法であって、
少なくとも１つのアプリケーションをサポートするアプリケーション層であって、前記各アプリケーションはユーザ・インタフェースとビジネス・ロジックとを少なくとも含み、前記各アプリケーションは各アプリケーションによって共通に使用される共用サービスを使用する、前記アプリケーション層と、
前記アプリケーションと通信可能であるサービス層であって、前記サービス層は前記各アプリケーションに使用される少なくとも１つの共用サービスをサポートし、前記サービス層は前記各共用サービスについての固有のアプリケーション・プログラミング・インターフェースを含み、当該アプリケーション・プログラミング・インターフェースは、前記各アプリケーションが前記共用サービスへ割り当てられたアプリケーション・プログラミング・インターフェースを介して要求を行うことを可能にし、前記共用サービスはレポジトリ・サービスを少なくとも含み、及び、前記各アプリケーションの前記ユーザ・インタフェース及び前記ビジネス・ロジックと前記サービス層によって提供される共用サービスとを結合することによって、前記共用サービスを共用しないスタンドアロン独立型アプリケーションによって提供されるサービスを前記各アプリケーションが包含する必要なしにエミュレートすることが可能である、前記サービス層と、
前記サービス層と通信可能なデータ層であって、コンテンツを含み、前記レポジトリ・サービスは前記データ層を介してアクセスされるリレーショナル・データベースと共に動作する、前記データ層と
を用意するステップと、
前記レポジトリ・サービスにおいて、前記アプリケーションのオブジェクトを関連付けてモデリングする為に使用される階層木構造を前記レポジトリ・サービスに記憶するステップであって、前記オブジェクトは前記アプリケーションをモデリングするオブジェクト・タイプを属性として持ち、前記オブジェクト・タイプは、前記階層木構造に関連付けられた前記コンテンツを有し、前記階層木構造が検索クエリを実行する能力を提供する、前記記憶するステップと、
前記各アプリケーションを、前記共用サービスを使用するそのプログラミングに従って動作させるステップと
を含む、前記方法。
【請求項６】
前記用意するステップが、前記サービス層及び前記データ層とインタフェースするソフトウェア・インフラ層をさらに用意するステップを含む、請求項５に記載の方法。
【請求項７】
前記用意するステップが、前記データ層とインタフェースするＯＳ層をさらに用意するステップを含む、請求項５又は６に記載の方法。
【請求項８】
前記アプリケーション層とインタフェースするウェブサーバ層をさらに実装する、請求項５〜７のいずれか一項に記載の方法。
【請求項９】
前記レポジトリ・サービスは、前記少なくとも１つのアプリケーションにより生成される情報またはデータの公開する公開サービスと通信可能である、請求項５〜８のいずれか一項に記載の方法。
【請求項１０】
前記階層構造の展開及び保存に続いて、前記オブジェクト・タイプの数を増やすステップをさらに含む、請求項５に記載の方法。
【請求項１１】
少なくとも１つのオブジェクト・サブタイプを包含するように前記オブジェクト・タイプを構成するステップをさらに含む、請求項５に記載の方法。
【請求項１２】
前記オブジェクト・タイプに関連付けられる各サブタイプが前記オブジェクト・タイプに関連付けられる他のサブタイプをオフにする能力を有することを含む、請求項１１に記載の方法。
【請求項１３】
前記オブジェクト・タイプ及び関連のサブタイプを再帰的に検索するステップをさらに含む、請求項１１又は１２に記載の方法。
【請求項１４】
前記各アプリケーションの前記ユーザ・インタフェース及び前記ビジネス・ロジックと前記サービス層によって提供されるサービスとを組み合わせることは、少なくとも１つのフィールドを１つのオブジェクト・タイプに関連付けることをさらに含み、前記フィールドはコンテンツを含む、請求項５に記載の方法。
【請求項１５】
少なくとも２つのフィールドを特定の１つのオブジェクト・タイプに関連付けるステップをさらに含む、請求項１４に記載の方法。
【請求項１６】
実質的に無限数のフィールドを特定の１つのオブジェクト・タイプに関連付けるステップをさらに含む、請求項１５に記載の方法。
【請求項１７】
前記オブジェクト・タイプにコンテンツが関連付けられており、前記データ層がコンテンツ・ストアを含む、請求項５に記載の方法。
【請求項１８】
前記アプリケーションの状態を特定の時点でスナップショットするステップをさらに含む、請求項５〜１７のいずれか一項に記載の方法。
【請求項１９】
前記アプリケーションに関するスナップショット状態を、それがスナップショットされた時点に続く時点で検索するステップをさらに含む、請求項１８に記載の方法。
【請求項２０】
前記アプリケーションに関するスナップショット状態を、それがスナップショットされた時点に続く時点で検索するステップと、
前記検索されるスナップショット状態を、前記アプリケーションのカレント状態にするステップと
をさらに含む、請求項１９に記載の方法。
【請求項２１】
前記アプリケーションのスナップショット状態を前記コンテンツ対応依存型アプリケーションの検索可能バージョンとして保存するステップをさらに含む、請求項５〜２０のいずれか一項に記載の方法。
【請求項２２】
コンピュータ・システムに、請求項５〜２１のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はソフトウェア開発に関し、より具体的には、ソフトウェア開発プラットフォーム及びこのようなプラットフォームとのアプリケーション統合に関する。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
共通するソフトウェア・プラットフォーム（例えば、アプリケーション・サーバ・プラットフォーム）用に開発されるアプリケーション・スイートの場合、スイート内の各アプリケーションは、典型的には、そのスイート内のアプリケーション間に共通するサービス（例えば、コンテンツ管理サービス、ワークフロー・サービス、公開サービス、検索及び問合せサービス）のグループを含む。
【０００３】
ソフトウェア・プラットフォームは１つのアプリケーションのサービスが別のアプリケーションによって共用されることを許容しないことから、これらのサービスは、複数のアプリケーションが共通のサービスを利用するとしても、そのソフトウェア・プラットフォーム用に書かれるアプリケーション毎にコード化されて上記各アプリケーション内に包含されなければならない。よって、任意の特定のアプリケーションのエレメント間に所定のサービスを共用する能力及びダイナミック・アソシエーションを有する能力が存在すれば極めて有益であろう。
【０００４】
図１の独立アプリケーション４８のようにサービスを共用しないアプリケーションは、そのアプリケーションの実装及びオペレーションのためだけに、これらのサービスが幾つかのアプリケーション間で共用されていれば発生する困難を伴うことなく捕獲される、先に列挙したサービスを有することになる。よって、幾つかのアプリケーションがこのようなサービスを共用することができるが、各アプリケーションは他のアプリケーションと区別されることが可能であって、しかもサービス共用における既存の問題点が存在しなければ、かなり有益であるであろう。
【課題を解決するための手段】
【０００５】
本発明のある態様によれば、アダプティブ・コンテンツ・プラットフォームは、各々がユーザ・インタフェースとビジネス・ロジックとを含む１つまたは複数のコンテンツ対応依存型アプリケーションを含む（よってアプリケーション層を形成する）。コンテンツ対応依存型アプリケーション及びソフトウェア・インフラ（例えば、アプリケーション・サーバ）にインタフェースされるサービス層は、このコンテンツ対応依存型アプリケーションにより使用可能な１つまたは複数のサービスを提供する。
【０００６】
アダプティブ・コンテンツ・プラットフォームには、下記の特徴のうちの１つまたは複数が包含されてもよい。サービス層は、１つまたは複数のサービスの各々について固有のアプリケーション・プログラミング・インタフェースを含み、よって、特有のサービスを使用する依存型アプリケーションは、そのサービスへ割り当てられたアプリケーション・プログラミング・インタフェースを介して要求を行う。
【０００７】
サービスにはコンテンツ管理サービス（コンテンツ及びファイルを格納／管理するためのもの）が含まれるが、これは、例えば、ファイルを格納するためのレポジトリ・サービス、及びユーザがレポジトリ・サービスによって格納されているファイルを検索できるようにするための検索サービスを含む。
【０００８】
これらのサービスにはワークフロー／コラボレーション・サービス（プロジェクト及びユーザを管理するためのもの）が含まれ、これは、例えば、ファイルのワークフローを管理するためのワークフロー・サービスと、ユーザ及びユーザ・グループを管理するためのユーザ管理／認証サービスと、サービスにより発生される通知を管理してユーザへ同報通信するためのイベント／通知サービスとを含む。
【０００９】
さらにこれらのサービスにはマルチモード・コンテンツ生成サービス（ファイルの手動生成及び自動インポート／変換用）も含まれ、これは、例えば、ファイルのフォーマットを変換するための変換／コンテンツ処理サービス、コンテンツ手動寄稿のためのデスクトップ統合サービス及び外部システムからのファイルのインポートを容易にするためのインポート・サービスを含む。
【００１０】
サービスにはさらに、マルチチャネル配備サービス（１つまたは複数の公開チャネルへファイルを公開するためのもの）が含まれ、これは、例えば、１つまたは複数の公開チャネル（例えば、ウェブ・サイト、ｅメール同報通信、無線放送、シンジケーション・ストリームまたは印刷出版物等）へファイルを公開するための公開サービス、動的公開サービス及び静的公開サービスを含む。
【００１１】
上述のアダプティブ・コンテンツ・プラットフォーム及び分散コンピューティング・システムは、プロセッサによって実行される方法または命令シーケンスとして実装されてもよい。
【００１２】
上述のアダプティブ・コンテンツ・プラットフォームからは、１つまたは複数の優位点を引き出すことができる。プログラマに再使用可能な共通のサービス・セットを提供することにより、アプリケーションは、もはや図１の４５に示すようなスタンドアロン・サービスを包含する必要がなくなる。これらのアプリケーションはサービスを包含する必要がなくなることから、アプリケーション開発は大幅に促進され、配備は単純化される。さらに、共通のサービス・セットの使用により、互換性問題は最小限に抑えられる。さらに、アプリケーションは共通のサービス・セットを共用することから、アプリケーション・サイズが縮小される。加えて、アプリケーションのサービスをアプリケーションのビジネス・ロジック／ユーザ・インタフェースから分離することにより、分散コンピューティングが可能になり、卓越したスケーラビリティ及び利用可能性がもたらされる。
【００１３】
好適には、プラットフォーム・ベースの全てのアプリケーションと共用するための共通のサービス・セットは、ワークフロー、レポジトリ及び公開の各サービスである。これらのサービスは、様々にサポートされるアプリケーションのオペレーションを実行するために協働して動作する。本発明によるシステムは、様々な依存型アプリケーションがレポジトリ・サービスにおいてオブジェクトモデリングされることを許容し、ワークフロー及び公開サービスは、そのレポジトリ・サービスとの関連づけによって活用される。
【００１４】
本発明によれば、アプリケーションはレポジトリ・サービスにおいて、上記アプリケーションの階層構造を基礎としてオブジェクトモデリングされてもよい。レポジトリにおいてアプリケーションがオブジェクトモデリングされると、指定されたコンテンツだけでなく、階層構造またはエンティティにより実行されるべきアクション・アイテム等のより豊富な結果をも返すことがクエリ検索されてもよい。
【００１５】
特定のアプリケーション・オブジェクトの詳細は、システム・ユーザが上記オブジェクト及びそのコンテンツへのアクセス認証を有しかつ上記オブジェクトへアクセスした上で変更する認証を有する限り、いつ変更されてもよい。また本発明は、アプリケーション・オブジェクト及び／または階層構造全体が特定の時間ポイントでラベリングされかつタイム・スタンプを付されることも許容する。アプリケーション・オブジェクトのアソシエーションは、オブジェクトの関連性の変化または特定のアプリケーション・オブジェクトのコンテンツの変化の認識が存在するようにして追跡されてもよい。
【００１６】
さらに、特定のアプリケーション・オブジェクトに関連する可能性のあるワークフロー・ルーティングは、そのアプリケーション・オブジェクトに関連づけられるコンテンツによって制御されてもよい。
【００１７】
以下、添付の図面及びその説明により、本発明の１つまたは複数の実施形態について詳述する。本発明の他の特徴、目的及び優位点は、下記の説明及び図面から、かつ請求の範囲から明らかとなるであろう。
【発明を実施するための最良の形態】
【００１８】
アダプティブ・コンテンツ・プラットフォーム１０は、アプリケーション層２２及びソフトウェア・インフラ２６とインタフェースするためのサービス層２４を含む多層構成ソフトウェア・アーキテクチャである。ソフトウェア・インフラ２６の一例は、アプリケーション・サーバである。アプリケーション・サーバの例はＢＥＡ  Ｗｅｂｌｏｇｉｃ（登録商標）及びＩＢＭ  Ｗｅｂｓｐｈｅｒｅ（登録商標）であり、これらは共にＪａｖａ（登録商標）２  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ規格（「Ｊ２ＥＥ」）を実装している。
【００１９】
依存型アプリケーション１２、１４及び１６はバージョン１．３規格に従ったＪ２ＥＥ準拠の依存型アプリケーションであってもよく、Ｊ２ＥＥアプリケーション・サーバと互換性がありかつ上記サーバ上で実行される。
【００２０】
サービス層２４は、依存型アプリケーション１２、１４、１６による使用が可能なサービス２８、３０、３２より成るグループを提供する。これらのサービスの例には、例えば、コンテンツ管理サービス、検索サービス及びファイル変換サービスが含まれる。これらのサービスは依存型アプリケーションに共通する共用サービスであり、後に詳述する。
【００２１】
データ層３４はソフトウェア・インフラ２６へインタフェースされ、アダプティブ・コンテンツ・プラットフォーム１０のためのデータ・サービスを提供する。データ層３４は、Ｏｒａｃｌｅ（登録商標）、ＩＢＭ  ＤＢ２（登録商標）及びＭｉｃｒｏｓｏｆｔ  ＳＱＬ  Ｓｅｒｖｅｒ（登録商標）等のデータベース・サーバ３６へのアクセスを提供してもよい。さらに、データ層３４は、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  ２０００  Ｓｅｒｖｅｒｓ（登録商標）、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  ＮＴ  Ｓｅｒｖｅｒｓ（登録商標）及びＵｎｉｘ  Ｓｅｒｖｅｒｓ（登録商標）等のファイル・サーバ３８へのアクセスを提供してもよい。さらにデータ層３４は、現行のシステム・テクノロジーより以前の言語、プラットフォーム及び技術から受け継がれているアプリケーション及びデータであるレガシ・システム４０へのアクセスを提供してもよい。
【００２２】
典型的には、データ層３４は、上述の層、インフラ及び依存型アプリケーションを管理するオペレーティング・システムを含むオペレーティング・システム（ＯＳ）層４２とインタフェースされる。互換性のあるオペレーティング・システムの例は、Ｗｉｎｄｏｗｓ（登録商標）、Ｓｏｌａｒｉｓ（登録商標）及びＬｉｎｕｘ（登録商標）である。
【００２３】
ウェブサーバ層４４は、図に示すように、依存型アプリケーション１２、１４、１６を含むアプリケーション層２２とインタフェースされる。ウェブサーバ層４４は、システム・ユーザがウェブ・ブラウザ４６によって個々の依存型アプリケーションの機能を使用しかつこれにアクセスすることを許容する。ウェブ・ブラウザの例は、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）及びＮｅｔｓｃａｐｅ  Ｎａｖｉｇａｔｏｒ（登録商標）である。さらに、ウェブサーバ層４４の例として、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｔｅｒｎｅｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｅｒ（登録商標）及びＡｐａｃｈｅ  ｗｅｂ  ｓｅｒｖｅｒ（登録商標）がある。
【００２４】
依存型アプリケーション１２のユーザ・インタフェース１８及びビジネス・ロジック２０と、サービス層２４により提供されるサービス２８、３０、３２のうちの１つまたはそれ以上とを結合することにより、「スタンドアロン」独立型アプリケーション４８の機能は、上記アプリケーションが専用のサービス５０、５２及び５４を包含する必要なしにエミュレートされることが可能である。
【００２５】
サービス層２４により提供されるサービス２８、３０及び３２に関しては、これらのサービスは、典型的には、おおまかにコンテンツ管理、ワークフロー／コラボレーション、マルチモード・コンテンツ生成及びマルチチャネル配備という４つのサービス・グループとして記述することができる。以下、これらの各々について論じる。
【００２６】
図２を参照すると、アダプティブ・コンテンツ・プラットフォームによって使用されるファイル及びコンテンツを格納しかつ管理するコンテンツ管理グループ１００は、レポジトリ・サービス１０２及び検索サービス１０４を含んでもよい。レポジトリ・サービス１０２は、（総じて）データ層と共に動作し、かつ（具体的には）データベース・サーバ、ファイル・サーバ及びレガシ・システムと共に動作してファイル及びコンテンツ（「ファイル」）を格納し、編成しかつ管理する。
【００２７】
レポジトリ・サービス１０２は、生成されて管理される特定のタイプのファイルを定義する多くのコンテンツ・タイプの生成、編成及び管理を可能にする。さらに、レポジトリ・サービス１０２は、ユーザ／管理者が、データ層により格納されるファイルを定義して絞り込む多くのプロパティ・フィールドまたはメタデータ・フィールド（例えば、公開日、改訂番号、生成日、改訂日及び承認日）を定義することを許容する。レポジトリ・サービス１０２によって管理されるファイルへのアクセスは、例えば特定のファイルを見て、チェックし、編集し、印刷しかつ保存することのできるユーザを規制することによって制御されてもよい。さらに、ファイルが格納されるデータ構造は、レポジトリ・サービス１０２を使用して定義され、かつ制御される。典型的には、レポジトリ・サービス１０２は、データ層３４（図１）を介してアクセスされる、例えばデータベース３６（図１）であるリレーショナル・データベースと共に動作する。
【００２８】
後述するように、レポジトリ・サービス１０２において依存型アプリケーションをオブジェクトモデリングするために使用される好適な構造は、階層木構造である。依存型アプリケーションをモデリングするオブジェクト・タイプ（object types）は、この構造に関連づけられるコンテンツを有することになる。
【００２９】
検索サービス１０４は、ユーザがレポジトリ・サービス１０２によって格納されるファイルを検索できるようにする。検索は、ファイルのプロパティまたはコンテンツの何れかに関して実行されてもよい。ファイルが（上述のような）構造化されたデータベースに格納されていれば、検索サービス１０４はＳＱＬ（「構造化問合せ言語」）データベース問合せエンジンであってもよい。或いは、ファイルがＨＴＭＬまたはＸＭＬ（「拡張可能マークアップ言語」）ベース文書として格納されていれば、検索サービス１０４は検索エンジン技術を使用して関連文書リストを生成してもよい。
【００３０】
上述の依存型アプリケーション１２、１４及び１６（図１）は、コンテンツ管理グループ１００、レポジトリ・サービス１０２及び検索サービス１０４により提供される各サービスへ、その特定のサービスへ割り当てられたＡＰＩ（「アプリケーション・プログラミング・インタフェース」）を適切に要求しかつこれを介して接続を確立することによってアクセスしてもよい。例えば、ＡＰＩ１０６はレポジトリ・サービス１０２へ割り当てられ、ＡＰＩ１０８は検索サービス１０４へ割り当てられている。従って、ある依存型アプリケーションのシステム・ユーザが特定のファイルの検索実行を希望すれば、そのエンティティの依存型アプリケーション１２がＡＰＩ１０８を介して適切な要求を行うことになる。
【００３１】
図３を参照すると、アダプティブ・コンテンツ・プラットフォームのプロジェクト及びユーザを管理するワークフロー／コラボレーション・グループ１５０は、ワークフロー・サービス１５２と、ユーザ管理／認証サービス１５４と、イベント／通知サービス１５６とを含んでもよい。続いて、これらのサービスの各々について論じる。
【００３２】
ワークフロー・サービス１５２は、管理者またはシステム・ユーザがアダプティブ・コンテンツ・プラットフォーム１０を介してファイルのワークフローを制御できるようにする。例えば、あるファイルが公開を目的として生成されていれば、そのファイルは、上位レベルのマネージャへ送られる前に中間レベルのマネージャによって承認される必要がある場合がある。さらに、上位レベルのマネージャは、それが公開される、または他の方法で普及される前にそのファイルを承認しなければならない場合がある。従って、ワークフロー・サービス１５２は、そのファイルが、公開に先立って承認を行う上位レベルのマネージャへ送られる前に中間レベルのマネージャによって承認されるように命じることもできる。さらに、ワークフロー・サービス１５２は、中間レベルまたは上位レベルによる精査及び承認プロセス等の所定のタスクを完了するための時間制限を割り当ててもよい。
【００３３】
ユーザ管理／認証サービス１５４は、システム・ユーザ／管理者に彼らがユーザ及びユーザ・グループを管理できるようにするツール・セットを提供する。個々のユーザは、ユーザ管理／認証サービス１５４を使用して生成されかつ削除されることが可能である。さらに、これらの個々のユーザの権利及び特権を制御しかつ規制することもできる。さらに、これらのユーザは、同じくユーザ管理／認証サービス１５４を使用して維持される様々なユーザ・グループへ割り当てられ、これらのグループ間で移動されかつこれらのグループから削除されることが可能である。さらに、権利及び権限はユーザ・グループへ割り当てられることが可能であることから、個々のユーザをあるユーザ・グループへ追加することにより、個々のユーザの権利または権限を効率的に定義することができる。
【００３４】
イベント／通知サービス１５６は、サービス層２４（図１）により提供されるサービスによって生成される通知イベントの配信を見込んでいる。これらのメッセージは、システムの個々のユーザへ配信され、ユーザ・グループ全体へ同報通信されかつサービス層２４（図１）により提供される様々なサービスへ配信されてもよい。
【００３５】
先に述べたように、依存型アプリケーション１２、１４及び１６（図１）は、ワークフロー・サービス１５２、ユーザ管理／認証サービス１５４及びイベント／通知サービス１５６を含むワークフロー／コラボレーション・グループ１５０により提供される各サービスへ、その特定のサービスへ割り当てられたＡＰＩを適切に要求しかつこれを介して接続を確立することによってアクセスしてもよい。この特定のグループの場合、ＡＰＩ１５８はワークフロー・サービス１５２へ割り当てられ、ＡＰＩ１６０はユーザ管理／認証サービス１５４へ割り当てられ、ＡＰＩ１６２はイベント／通知サービス１５６へ割り当てられている。
【００３６】
図４を参照すると、アダプティブ・コンテンツ・プラットフォームのためにファイルをインポートして変換するマルチモード・コンテンツ生成グループ２００は、変換／コンテンツ処理サービス２０２と、インポート・サービス２０４と、デスクトップ統合サービス２１０とを含んでもよい。次に、これらのサービスについて個々に論じる。
【００３７】
変換／コンテンツ処理サービス２０２は、システム・ユーザまたは管理者が様々なタイプのファイルをインポートしかつこれらをＸＭＬ及びＨＴＭＬ等の共通フォーマットに変換することを許容するファイル・フォーマット変換サービスを提供する。Ｍｉｃｒｏｓｏｆｔ  Ｗｏｒｄ（登録商標）、Ｍｉｃｒｏｓｏｆｔ  Ｅｘｃｅｌ（登録商標）、Ａｄｏｂｅ  ＰＤＦ（登録商標）及びＭｉｃｒｏｓｏｆｔ  ＰｏｗｅｒＰｏｉｎｔ（登録商標）等の普及したアプリケーションには、変換テンプレートを使用可能である。
【００３８】
インポート・サービス２０４は、外部システムからのファイルの自動インポートを許可する。インポート・サービス２０４は、ネットワーク・ドライブ、ＦＴＰ（「ファイル転送プロトコル」）サイト及びＨＴＴＰサイトに位置づけられるファイルを周期的に監視するように構成される。これらのリソースのうちの１つに新しいファイルが検出されると、これらのファイルは自動的にシステムへインポートされる。さらに、フォーマットの変換が必要であれば、インポート・サービス２０４は、変換サービス２０２と共働してそのファイルをインポートしかつ変換する。
【００３９】
デスクトップ統合サービス２１０は、コンテンツがユーザにより規格デスクトップ生成ツールを介して寄稿されることを許可する。これらのツールには、Ｍｉｃｒｏｓｏｆｔ  Ｏｆｆｉｃｅ（登録商標）スイート、Ａｄｏｂｅ（登録商標）及びＭａｃｒｏｍｅｄｉａ（登録商標）の各アプリケーションが含まれる。好適には、本サービスは、ＨＴＴＰプロトコルの拡張型であるＷＥＢＤＡＶプロトコル（ＷＥＢベースの分散オーサリング／バージョン管理）を使用してこれらのデスクトップ・ツールと通信する。
【００４０】
先に述べたように、依存型アプリケーション１２、１４及び１６（図１）は、変換サービス２０２、インポート・サービス２０４及びデスクトップ統合サービス２１０を含むマルチモード・コンテンツ生成グループ２００により提供される各サービスへ、その特定のサービスへ割り当てられたＡＰＩを適切に要求しかつこれを介して接続を確立することによってアクセスしてもよい。この特定のグループの場合、ＡＰＩ２０６は変換サービス２０２へ割り当てられ、ＡＰＩ２０８はインポート・サービス２０４へ割り当てられ、ＡＰＩ２１２はデスクトップ統合サービス２１０へ割り当てられている。
【００４１】
図５を参照すると、１つまたは複数の公開チャネルへファイル及びレポートを公開するマルチチャネル配備グループ２５０は、静的公開サービス２５２と、動的公開サービス２５４とを含んでもよい。静的公開サービス２５２は、予め定義されたテンプレートを基礎とするファイル及びレポートのプロアクティブな公開を見込んでいる。従って、公開されるファイル（及び生成される文書）の構成及びフォーマットは、文書のコンテンツに依存して予め定義され、変更されない。さらに、コンテンツ自体は、周期的に（例えば、週に数回）変わることにおいて半動的である。静的公開サービスを使用して生成される静的文書の例は、現時点で１００ものプレス・リリースが表示されている企業ウェブサイトのニュースルーム・ホームページである。このホームページは１００個の集約リンクの集合体であり、各リンクはプレス・リリースの１つの詳細ページへ繋がっている。企業の通信担当者は、適切なプレス・リリース・コンテンツを詳細ページ・テンプレートとマージしてＨＴＭＬを生成する静的公開サービスを呼び出すことによって、そのホームページ及び１００もの詳細ページを公開することができる。静的公開を使用してページを生成することにより、通信担当者はウェブサイトの訪問者が高速なページ検索を得ることを確信するが、これは、コンテンツが既にＨＴＭＬフォーマットであり、ウェブサイトの訪問者毎に生成し直す必要がないためである。
【００４２】
動的公開サービス２５４は、例えばカレント状況、ユーザ選好及び問合せ結果を基礎として動的に変更されるファイル及びレポートのリアクティブな公開を見込んでいる。１００個の販売アイテムを有するオンライン・オークション・ハウスは、システム・ユーザの問合せに応答して動的文書を生成してもよい。例えば、１００のアイテムが提供されてもよいが、システム・ユーザが熱烈な第二次世界大戦マニアであれば、第二次世界大戦に関連するアイテムにしか興味を持たないかもしれない。従って、システム・ユーザがその検索基準を入力すれば、各々が第二次世界大戦に関連する１４アイテムを包含する動的な文書またはレポートが生成されることになる。また、これらの１４アイテムを箇条書きにするこの動的に生成されるリストは、アイテム毎の入札の始値、現行付け値及びオークション終了時間を明記してもよい。この文書を動的公開サービス２５４を使用して生成することにより、カレント状況をより正確に反映する文書を生成することができる。
【００４３】
ファイルまたはレポートが静的公開サービス２５２または動的公開サービス２５４を使用して生成されるかどうかに関わらず、そのファイルまたはレポートは様々なチャネル上で公開されてもよい。これらのチャネルには、例えば、ウェブサイト、ｅメール同報通信、無線放送、シンジケーション・ストリーム及び印刷出版が含まれるが、この限りではない。また、ファイルまたはレポートは、ＨＴＭＬ、ＸＭＬ及びＰＤＦ等の様々なフォーマットで公開されてもよい。
【００４４】
ウェブサイト公開の場合、公開されるファイルは、様々なシステム・ユーザ及びゲストがそのファイルまたはレポートにアクセスできるようにウェブサイトへポスティングされてもよい。セキュリティまたはアクセスが懸念材料であれば、ファイルは、イントラネット（遠隔からのアクセスは不可）上で、またはウェブサイトの限定されたアクセス・ユーザ・セクション内で公開されてもよい。
【００４５】
ｅメール同報通信の場合、ファイルまたはレポートは配信されるｅメールへの添付として公開されてもよい。或いは、ファイルまたはレポートはまずＡＳＣＩＩテキスト及びＨＴＭＬ等のフォーマットに変換され、次にｅメールの本体へ組み込まれてもよい。
【００４６】
無線放送の場合、ファイルまたはレポートは無線ネットワーク上で送信されてもよい。このファイルまたはレポートは、無線ｅメール・デバイスへ送信されるｅメール添付等のテキスト・ベースであっても、携帯電話へ送信される音声ファイル等のマルチメディア・ベースであってもよい。
【００４７】
シンジケーション・ストリームの場合、ファイルまたはレポートは、ストリーミング・メッセージ等のテキスト・ベース、ストリーミング・オーディオ等のオーディオ・ベース、ストリーミング・ビデオ等のビデオ・ベースまたはストリーミング・オーディオ／ビデオ等のマルチメディア・ベースであるデータ・ストリーム上で公開されてもよい。
【００４８】
印刷出版の場合、公開されるファイルまたはレポートは伝統的な印刷システム上で印刷され、従来の配布経路、社内便、国際配達便または郵便制度を使用して配布されてもよい。
【００４９】
先に述べたように、依存型アプリケーション１２、１４及び１６（図１）は、マルチチャネル配備グループ２５０、静的公開サービス２５２及び動的公開サービス２５４により提供される各サービスへ、その特定のサービスへ割り当てられたＡＰＩを適切に要求しかつこれを介して接続を確立することによってアクセスする。この特定のグループの場合、ＡＰＩ２５６は静的公開サービス２５２へ割り当てられ、ＡＰＩ２５８は動的公開サービス２５４へ割り当てられている。
【００５０】
図６を参照すると、アダプティブ・コンテンツ・プラットフォーム１０を組み込む分散コンピューティング・システム３００が示されている。分散コンピューティング・システム３００は、ビジネス・ロジック及びユーザ・インタフェースを含む１つまたは複数の有効化された依存型アプリケーション１２及び１４（図１）を実行するローカル（または第１の）コンピューティング・デバイス３０２を含む。
【００５１】
格納デバイス３０４は、依存型アプリケーション１２及び１４のための個々の命令セット及びサブルーチンを格納する。格納デバイス３０４は、例えば、ハードディスク・ドライブ、テープ・ドライブ、光学ドライブ、ＲＡＩＤアレイ、ランダム・アクセス・メモリ（ＲＡＭ）または読取り専用メモリ（ＲＯＭ）であってもよい。ローカル・コンピューティング・デバイス３０２は、少なくとも１つの処理ユニットと、メイン・メモリ・システムと（共に図示されていない）を含む。
【００５２】
ウェブ・ブラウザであってもよいリモート（または第２の）コンピューティング・デバイス３０６は、上述のようなサービス層２４を実行する。典型的には、サービス層２４はソフトウェア・インフラ（図示されていない）とインタフェースされ、上記ソフトウェア・インフラはデータ層（図示されていない）とインタフェースされ、上記データ層はＯＳ層（図示されていない）とインタフェースされる。
【００５３】
格納デバイス３０８は、サービス層２４及び必要な任意の追加的な層またはインフラの個々の命令セット及びサブルーチンを格納する。格納デバイス３０８は、例えば、ハードディスク・ドライブ、テープ・ドライブ、光学ドライブ、ＲＡＩＤアレイ、ランダム・アクセス・メモリ（ＲＡＭ）または読取り専用メモリ（ＲＯＭ）であってもよい。リモート・コンピューティング・デバイス３０６は、少なくとも１つの処理ユニット（図示されていない）と、メイン・メモリ・システム（図示されていない）とを含む。
【００５４】
ローカル・コンピューティング・デバイス３０２とリモート・コンピューティング・デバイス３０６は、例えばＬＡＮ、ＷＡＮ、インターネット、ワールド・ワイド・ウェブまたはイントラネット等のネットワーク３１０で相互に接続される。
【００５５】
上述の実施形態は、単一の第２のコンピュータ上のサービス層の配備について論じているが、本発明の範囲内で他の構成も可能である。例えば、上記システム構成は、各サービスまたはサービス・グループがその固有の専用コンピュータ上に配備されるようなものであってもよい。
【００５６】
さらに、上述の実施形態はローカル及びリモート・コンピューティング・デバイスについて記述しているが、これは、何れかのコンピューティング・デバイスの物理的位置を画定することを意図するものではなく、単に、第２のコンピューティング・デバイスが第１のコンピューティング・デバイスから遠隔である、または分離されていることを示すためのものである。
【００５７】
またさらに、上述の実施形態は、コンテンツ対応依存型アプリケーションの使用について論じているが、本発明の範囲内で他の構成も可能である。例えば、上記システムは、コンテンツではなくデータを管理すべく設計されるものであるデータ対応依存型アプリケーションを使用するように構成されてもよい。
【００５８】
またさらに、上述の実施形態は、ソフトウェア・インフラ２４がアプリケーション・サーバであると指摘しているが、本発明の範囲内で他の構成も可能である。例えば、上記システムは、ソフトウェア・インフラがＵＮＩＸ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）２０００等の汎用オペレーティング・システム、または専用オペレーティング・システム、組込みＯＳまたはリアルタイムＯＳであるように構成されてもよい。
【００５９】
またさらに、上述の実施形態は、３つのサービス及び３つの依存型アプリケーションの利用可能性を示しているが、サービス及び依存型アプリケーションの実際の数はシステム要件を基礎として調整することができる。
【００６０】
図７を参照すると、分散コンピューティング方法３５０が示されている。１つまたは複数のコンテンツ対応依存型アプリケーションは、３５２においてローカル・コンピューティング・デバイス上で実行される。各依存型アプリケーションは、ユーザ・インタフェースと、ビジネス・ロジックとを含む。依存型アプリケーション及びソフトウェア・インフラとインタフェースされるサービス層は、３５４においてリモート・コンピューティング・デバイス上で実行される。サービス層は、コンテンツ対応依存型アプリケーションによって使用可能な１つまたは複数のサービスを提供する。
【００６１】
１つまたは複数のデータベースを含むデータ層は、３５６においてソフトウェア・インフラとインタフェースされる。サービスの各々には、３５８において一意のアプリケーション・プログラミング・インタフェースが割り当てられる。特定のサービスを使用する依存型アプリケーションは、そのサービスに割り当てられたＡＰＩを介して要求を行ってもよい。
【００６２】
第１及び第２のコンピューティング・デバイスは、３６０においてネットワークにより相互に接続される。
【００６３】
図８を参照すると、多層構成ソフトウェアの開発方法４００が示されている。４０２では、各々がユーザ・インタフェースとビジネス・ロジックとを含む１つまたは複数のコンテンツ対応依存型アプリケーションが提供される。４０４では、１つまたは複数のコンテンツ対応依存型アプリケーションとインタフェースされかつコンテンツ対応依存型アプリケーションによって使用可能な１つまたは複数のサービスを提供するサービス層が提供される。サービス層は、４０６においてソフトウェア・インフラとインタフェースされる。ソフトウェア・インフラは、４０８においてデータ層とインタフェースされる。データ層は、１つまたは複数のデータベースを含む。
【００６４】
次に、概して図９から１５を参照しながら、依存型アプリケーションによって共用される共通サービス及び依存型アプリケーションとこれらのサービス及び他のプラットフォーム・コンポーネントとの統合について説明する。
【００６５】
図１では、アプリケーション層２２が依存型アプリケーション１２、１４及び１６を含んでいた。先に述べたように、好適には、これらのアプリケーションはコンテンツ対応依存型アプリケーションである。これらの依存型アプリケーションは、コンテンツを管理しかつ処理する。サービス層の３つのサービス、即ちワークフロー、レポジトリ及び公開の各サービスは、後述するように、依存型アプリケーションと本発明によるシステムとの統合の主たる実現要因である。
【００６６】
図９は、概して５００において、コンテンツ対応依存型アプリケーションの統合を促進する３つの共用サービスを示している。これらは、ワークフロー・サービス５０２、レポジトリ・サービス５０４及び公開サービス５０６である。各依存型アプリケーションは、これらのサービスを介して、サービス層のこれらのファイル、フォルダまたは他の構造体がデータ層に格納されているコンテンツへ接続する程度までデータ層３４及びデータベース３６、３８及び４０へ接続する。
【００６７】
ワークフロー・サービス５０２は、システム・ユーザがアダプティブ・コンテンツ・プラットフォーム１０を介してファイル及びフォルダのワークフローを制御することを許可する。レポジトリ・サービス５０４は、アプリケーション・オブジェクト及びオブジェクトに関連づけられるコンテンツの生成、編成及び管理を許可する。公開サービス５０６は、予め定義されたテンプレートを基礎とするファイル及びレポートのプロアクティブな公開（静的公開）、及びカレント状況、ユーザ選好及び問合せ結果を基礎として動的に変更されるファイル及びレポートのリアクティブな公開（動的公開）を許可する。
【００６８】
本発明によれば、依存型アプリケーション１２、１４または１６（図１）を有効化するために、好適には共用サービスの環境において、各依存型アプリケーションはレポジトリ・サービス５０４においてオブジェクトモデリングされる。これは、当該依存型アプリケーションの特徴を捕捉するオブジェクト・タイプを開発すること、そしてこれらのオブジェクト・タイプをレポジトリ・サービスにおいてモデリングすることによって実行される。各依存型アプリケーションは、レポジトリ・サービスにおいてその固有の区別的なオブジェクト・モデルを有することになる。レポジトリ・サービス５０４においてモデリングされる依存型アプリケーションのオブジェクト・タイプの一例を、図１０に示す。
【００６９】
図１０を参照すると、概して５５０において、好適には、レポジトリ・サービスにおいてオブジェクトモデリングされる依存型アプリケーションは、木構造に編成される階層構造を有する。例えば、レポジトリ・サービス５０４においてモデリングされる依存型アプリケーションは、代表的なビジネス評価アプリケーション５５２である。ビジネス評価アプリケーション５５２は、ここではアダプティブ・コンテンツ・プラットフォーム１０によってサポートされる任意のアプリケーションを代表することが意図されている。
【００７０】
ビジネス評価アプリケーション５５２のこの木構造は、アプリケーションのオブジェクト・タイプをモデリングする一形式である。他のモデリング方法も使用可能であって、やはり本発明の範囲に含まれることは理解される。
【００７１】
図１０において、ビジネス評価アプリケーション５５２は、上記アプリケーションのモデリングに使用される６つのオブジェクト・タイプの階層関係を示す。この階層構造における６つの関連するオブジェクト・タイプは、ビジネス・エンティティ・オブジェクト５５４、プロセス・オブジェクト・タイプ５５６、リスク・オブジェクト・タイプ５５８、コンテンツ・オブジェクト・タイプ５６０、検査オブジェクト・タイプ５６２及び検査結果オブジェクト・タイプ５６９である。
【００７２】
モデリングされる第１のオブジェクト・タイプは、部門、子会社、他等の企業のビジネス・エンティティの全てに関連するビジネス・エンティティ・オブジェクト５５４である。モデリングされる第２のオブジェクト・タイプは、特定のリスクに関して査定されつつある企業プロセスに関連するビジネス・プロセス・オブジェクト５５６である。モデリングされる第３のオブジェクト・タイプは、企業が直面するリスク及びこれらのリスクの特徴に関連するリスク・オブジェクト５５８である。モデリングされる第４のオブジェクト・タイプは、企業がそのリスクを最小限に抑えるために使用する手順に関連する制御オブジェクト５６０である。モデリングされる第５のオブジェクト・タイプは、この制御の検査に使用されかつそのための検査プランから成る検査オブジェクト５６２である。そして最後に、モデリングされる第６のオブジェクト・タイプは、上記制御の検査結果である検査結果オブジェクト５６４である。但し、依存型アプリケーションが６個より多い、または少ないオブジェクト・タイプを含んでもよく、これらのタイプが関連する階層である必要はなく、オブジェクト・タイプが図１０に示す例が示すようにモデリングされる必要はないことは理解されるべきであり、これらもやはり本発明の範囲に含まれる。
【００７３】
レポジトリ・サービス５０４においてモデリングされる依存型アプリケーションのオブジェクト・タイプは、互いに関連づけられるデータ・エレメント形式のコンテンツを有する。これらのデータ・エレメントは、先に述べたように、データ層３４（図１）において格納されかつサービス層によってアクセスされてもよい。
【００７４】
レポジトリ・サービスにおいて依存型アプリケーションのオブジェクト・タイプが決定されかつモデリングされると、各オブジェクト・タイプに関連づけられるコンテンツは変更されてもよい。即ち、システム・ユーザは既存のコンテンツへ追加し、または既存のコンテンツから引出し、新しいコンテンツを追加し、既存のコンテンツを削除し、またはコンテンツの外観を変更することができるが、これらは本発明の範囲に含まれる。
【００７５】
ビジネス・アプリケーション５５２が企業の評価に使用されていれば、各部門または子会社が評価用にこの同じアプリケーションを使用しかつ上述の同じ６つのオブジェクト・タイプを使用しているとしても、オブジェクト・タイプは、例えば製造または研究開発である特定の部門または子会社のニーズを基礎として異なるコンテンツを有してもよい。しかしながら、これが異なるコンテンツを使用していたとしても、レポジトリ・サービスにおいてモデリングされているアプリケーションのオブジェクト・タイプが部門または子会社のニーズに対応していなければ、その部門または子会社は、その特定のニーズに合う異なるオブジェクト・タイプ・セットを含む異なる依存型アプリケーションを使用する必要がある可能性がある。この新しいアプリケーションは、オブジェクト・タイプの異なる階層及び関連性を有してもよい。従って、新しいオブジェクト・タイプは図１０に示されているものに関連してモデリングされてもよく、かつオブジェクト・タイプはアプリケーションのオブジェクト・タイプがシステム・ユーザのニーズに最も適合するように削除されてもよいことは理解される。またシステム・ユーザは、オブジェクト・タイプ間のアソシエーションの関係性を定義し直すことのできるオブジェクト・タイプ及びコンテンツのためのフィールド値を変更してもよい。
【００７６】
レポジトリ・サービスにおいてアプリケーションのオブジェクト・タイプが決定されかつモデリングされると、システムは、１つまたは複数のオブジェクト・タイプに関連づけられるサブタイプが存在し得ることを予期する。これらのサブタイプもまた、データ・エレメント形式のコンテンツでポピュレートされてもよい。特定のオブジェクト・タイプに属するサブタイプは、特定のオブジェクト・タイプに属するコンテンツをより良く編成しかつ分類する手段を提供する。
【００７７】
好適には、レポジトリ・サービス５０４においてモデリングされるアプリケーション内に存在するアソシエーションには２つのタイプがある。その第１は、オブジェクト／オブジェクト・アソシエーションである。オブジェクト・タイプ間のこれらの関連性は、１対１、１対多数または多数対多数であってもよい。これは、例えば、図１０に示す階層構造に見られるものである。第２は、オブジェクト／アタッチメント・アソシエーションである。この場合は、特定の１つのオブジェクト・タイプに複数のアタッチメントが関連づけられる。続いて、これらの双方について詳述する。
【００７８】
レポジトリ・サービス５０４においてモデリングされるオブジェクト・タイプは、アタッチメント・アソシエーションを有してもよい。これらのアタッチメントは、ファイル、リンク及び「フォーム」の各アタッチメントであってもよい。ファイル・アタッチメントは、コンテンツを含むことになるオブジェクト・タイプへ添付される実際のファイルであろう。リンク・アタッチメントは、コンテンツの一部であるＵＲＬ（統一リソース・ロケータ）となり、インターネット、ワールド・ワイド・ウェブまたは他の類似するグローバル通信システム上のリソースをポイントする。「フォーム」アタッチメントは、階層構造を定義し、タイプを定義し、またはレポジトリ・サービスにおいてモデリングされるオブジェクト・タイプになる新しいオブジェクトを定義する形式であってもよい。
【００７９】
レポジトリ・サービス５０４においてモデリングされるオブジェクト・タイプに関連づけられるデータ・エレメント（コンテンツ）は、様々なタイプであってもよい。これには、リッチテキスト型データ、グループ・セレクタ型データ、通貨型データ、日付け型データ及び整数型データが含まれる。リッチテキスト型データは、例えば、ＨＴＭＬタグを介するデータ・フォーマットを含む。グループ・セレクタ型データは、例えば、セキュリティ・サブシステムを介して管理上定義されるようなグループ名またはユーザ名を含む。通貨型データは、例えば、通貨のようにフォーマットされる１０進数を含む。日付け型データは、例えば、「２００５年１月２１日」、「０１／２１／２００５」または「２１／０１／２００５」（欧州式）のような日付け形式のデータを含む。整数型データは、例えば、小数、分数、負数及び式アラビア数字、ローマ数字または他の数値表現を含む数字形式のデータを含む。
【００８０】
先に述べたように、本発明によるシステムへのアクセスは、アクセス機構によって制御されてもよい。このアクセス機構は、ワークフロー／コラボレーション・グループ・サービス１５０（図３）におけるユーザ管理／認証サービス１５４に関連づけられる。この機構は、認証が与えられているレベルのアプリケーション・オブジェクト・タイプ及び関連コンテンツ、またはアクセス・レベルを基礎としてシステム・ユーザに見えるようにされるコンテンツへのアクセスのみ許可する。従って、システム・ユーザが、指定された所定のレベルのオブジェクト・タイプへ問い合わせるためのアクセスしか与えられていなければ、そのシステム・ユーザは、そのレベルまでのオブジェクト・タイプ及びコンテンツにアクセスすることはできるが、それ以上へは高位のアクセス認証を与えられなければアクセスすることができない。このアクセス認証は、そのオブジェクト・タイプに関連づけられる読取り／書込み許可へも拡張される。
【００８１】
図１１を参照すると、概して５７０において、図１０の階層構造の一部が示されている。この図は、ビジネス・エンティティ５５４に関連づけられるサブタイプを示す。図１１に示すように、ビジネス・エンティティ・オブジェクト・タイプ５５４は、例えば、ビジネス・エンティティ・オブジェクト・タイプ５５４に関連づけられるデータ・エレメントの定義をアシストする３つのサブタイプを有する。第１のサブタイプは５５４Ａにおけるビジネス・エンティティ−ヨーロッパであり、第２のサブタイプはビジネス・エンティティ−日本であり、第３のサブタイプはビジネス・エンティティ−米国である。これは、例えば、ヨーロッパのファシリティがビジネス・エンティティ−ヨーロッパのサブタイプの下で上記ファシリティにとって必要なものを使用し、かつ他の２つの地域である日本と米国に関するアプリケーションを無関係であるという理由でオフにすることを可能にする。
【００８２】
これらのサブタイプの各々は、自らに関連するデータ・エレメントを有し、かつ列挙されている他の５つのオブジェクト・タイプとの関連性を有する。さらに、他の５タイプは何れも、同様にして下に形成されるサブタイプを有してもよく、これも本発明の範囲に含まれる。この特徴により、依存型アプリケーションの使用における効率及び速度は追加され、かつシステムのフレキシブルさが追加される。
【００８３】
レポジトリ・サービス５０４においてモデリングされる依存型アプリケーション・オブジェクトの階層構造は、単なる隔離されたコンテンツの検索を超えるレベルで検索クエリを実行する能力を提供する。従って、検索クエリは、より豊富な検索結果を得るために異なる文字を取り込んでもよい。これは、２例を挙げると階層構造のサブセットを返すこと、またはアクション・アイテムを返すことを含む。例えば、「効果のない制御に基づく高インパクトのリスク」を問い合わせることのできるクエリ検索を定式化することは可能である。これは、純粋なコンテンツ応答以外のものを返す。これについては、図１２を参照して説明する。
【００８４】
図１２は、概して５８０において、図１０に示すものに類似するレポジトリ・サービスにおいてモデリングされるアプリケーションの階層構造を示しているが、制御オブジェクト・タイプにアソシエーションが追加されている。ビジネス評価アプリケーション５５２は、図１０と同じくアプリケーションを定義するための６つのオブジェクト・タイプ、即ち、ビジネス・エンティティ・オブジェクト・タイプ５５４、ビジネス・プロセス・オブジェクト・タイプ５５６、リスク・オブジェクト・タイプ５５８、制御オブジェクト・タイプ５６０、検査オブジェクト・タイプ５６２及び検査結果オブジェクト・タイプ５６４を有する。これは、制御オブジェクト・タイプから分岐する「問題点」及び「問題点」から分岐する「アクション・アイテム」も示している。
【００８５】
提案しているクエリ検索は、要求「効果のない制御による高インパクトのリスク」を処理する際に、５８２の「問題点」における決定及び５８４の「アクション・アイテム」における関連アクションを包含してもよい。次に、クエリによって提起される問題点は、検索により返される特定のアクション・アイテムによって対処される。これらの問題点及びアクション・アイテムには検査結果が存在しないことから、検査オブジェクト・タイプ及び検査結果オブジェクト・タイプにおける次の２つの下位レベル・アソシエーションへの移行は発生しない。
【００８６】
図１及び１２に示される、任意の特定の時点における階層構造は、様々なオブジェクト・タイプの極めて特殊なコンテンツを含む。所定の状況下では、オブジェクト・タイプ及びそのコンテンツのこの特殊な状態を認識しかつ持続することが重要である可能性がある。この状態の持続は、本発明によるシステムのスナップショット機能によって実行されてもよい。この機能は、オブジェクト・タイプ及びそのコンテンツを介して依存型アプリケーション全体をスナップショットする。またこのスナップショットは、ラベリングされかつタイム・スタンプを付されてもよい。
【００８７】
オブジェクト・タイプを介する依存型アプリケーションの状態のラベリング及びタイムスタンピングは、如何様にも変更または改変され得ないようなものであってもよい。これには、コンテンツとリソースの関係性の変更が含まれるが、この限りではない。スナップショット・イベントにおける依存型アプリケーションの状態は、多くの目的で後日再検討されてもよいが、その目的の１つは、このスナップショットの状態とアプリケーション・オブジェクト・タイプの後の状態との比較であってもよい。
【００８８】
ラベリングは、システムの変化を高速かつ効率的に追跡する方法も提供している。システム・リソースの関係性及びコンテンツの変化を追跡するこの能力は、誰かがこれらのリソース関連性及びコンテンツを無断で改竄したかどうかの決定も可能にする。
【００８９】
スナップショット、ラベリング及びタイムスタンピングは、追加の利点も提供する。システム・ユーザが、何らかの時点でオブジェクト・タイプの特定のスナップショット状態へ戻ることを希望する場合、認証されていればそうすることもできる。その後、アプリケーションはその時点から前進する。アプリケーション・オブジェクト・タイプ及びコンテンツの、このスナップショットの時間とオブジェクト・タイプの現行状態との間に介在する状態は、その後のアプリケーションに影響しない。これはまさに、こうした状態が全く存在したことがないかのようである。しかしながら、これらは、上記期間の間オブジェクト・タイプのこれらの状態がラベリングされかつスナップショットされた程度にはシステムにより保存されていたはずであり、後に、オブジェクト・タイプをカレント状態にするために選択されることは可能である。
【００９０】
アプリケーション・オブジェクト・タイプが本発明によるシステムに従って保存される度に、モデリングされたアプリケーションの新バージョンが保存されて存在することになる。保存されたバージョンは各々、先に論じたようにラベリングされかつタイム・スタンプを付されてもよい。保存されたバージョンは、システム・ユーザの希望通りに検索されかつ見られてもよい。保存されたこれらのバージョンは、オブジェクト・タイプの状態に関する所望されるレポートの生成及び配布のための公開サービス５０６との統合に使用可能である。
【００９１】
任意の所定時間においてオブジェクト・タイプの状態のバージョンを基礎として生成されるレポートは、これらの異なる時間における状態間の比較の実行を可能にする。これは、例えば企業の経時的評価を目的とするこれらの比較の実行に際して、システム・ユーザがオブジェクト・タイプの変更を監査できるようにする。
【００９２】
レポジトリにおいてモデリングされるアプリケーションのオブジェクト・タイプは、システム・ユーザである一人または複数の人にオブジェクト・タイプまたはモデリングされるアプリケーションのタイプのコンテンツの状態変化を通知するコンテンツを含んでもよい。例えば、検査期限が過ぎていれば、検査担当者はｅメールを介して検査を完了するように通知されることになり、または、その個人は、検査完了に向けたアクション・アイテムを割り当てられてもよい。この特徴は、ワークフロー／コラボレーション・グループ・サービス１５０のイベント／通知サービス１５６（図３）を介して実装される。
【００９３】
本発明によるシステムは、システム・ユーザがアプリケーション・オブジェクト・タイプをコード化する事前行為なしにシステムを構成することができる方法を提供する。これは、オブジェクト・タイプの各々に関連するデータ・エレメント及びこれらの関係性を定義する一連の入力媒体を使用するシステムによって達成されてもよい。これらの入力媒体は、レポジトリ・サービスにおいてモデリングされるべきオブジェクト・タイプを具現するために特別に生成される「フォーム」であってもよい。これらのフォームは、新しいオブジェクト・タイプを定義してもよく、または、レポジトリ・サービスにおいてモデリングされているオブジェクト・タイプのために存在するコンテンツを増すことに関連するものであってもよい。これらのフォームは、モデリングされるこれらのオブジェクトを事前にコード化する必要なしに自動的に具現する能力を提供する。
【００９４】
上記フォームは、幾つかの方法で構成されてもよい。
【００９５】
「調査」は、レポジトリ・サービス５０４においてモデリングされる既存の階層構造へオブジェクト・タイプを追加すべく添付されてもよい「フォーム」の１タイプである。これは、図１３に示されている。このフォーム・タイプは、実際には、既存の階層構造に新しいオブジェクト・タイプを生成してもよい。上記調査は、適切なエンティティによって応答されてもよい。
【００９６】
図１３を参照すると、概して５８６において、レポジトリ・サービス５０４においてモデリングされる階層構造が示されているが、この階層構造は、フォームのタイプである「調査」をリスク・オブジェクト・タイプ５５８に関連づけられるファイル・アタッチメントとして示している。調査オブジェクト・タイプ５８８は、リスク・オブジェクト・タイプ５５８とのその関連性において制御オブジェクト５６０と同レベルにあり、かつ並行関係にある。
【００９７】
ファイル・アタッチメント・タイプ（「調査」オブジェクト・タイプ５８８（図１３））であれ、コア・オブジェクト・タイプ（例えば、リスク、制御オブジェクト・タイプ、他）であれ、「フォーム・ベース」のコンテンツ・タイプは、そのレンダリングを独立して構成させてもよい。「フォーム・ベース」のコンテンツ・タイプをレンダリングするための命令シーケンスは、Ｊ２ＥＥプラットフォームからのＪａｖａ（登録商標）Ｓｅｒｖｅｒ  Ｐａｇｅｓ（ＪＳＰ）テクノロジーを使用して実装されてもよい。「フォーム・ベース」のコンテンツ・タイプの各々について、管理者は、このタイプのインスタンスを実行しかつレンダリングする異なるＪＳＰ（ＪＳＰ命令を含むファイル）を構成してもよい。ＪＳＰ命令は、あるオブジェクトのためにレンダリングされるフィールドの配置及びフォーマットを制御する。
【００９８】
各オブジェクト・タイプに関連づけられるデータ・エレメントを含むアプリケーション・オブジェクト・タイプの状態のスナップショットは、公開サービス５０６を使用して公開されてもよい。例えば、公開サービス５０６においては、この状態のアプリケーション・オブジェクト・タイプ及びコンテンツに関連するレポートを公開することも可能である。これは、システム・ユーザに、例えば所定の時点における企業のビジネス・プロセスの状態に関する情報を希望するときに検索する手段を提供する。報告は、特定のオブジェクト・タイプ、そのオブジェクト・タイプによって代表されるアプリケーション全体、オブジェクト・タイプのサブセット、または例えば生成されてオブジェクト・タイプに添付された調査であるフォームに関連づけられるものであってもよい。
【００９９】
任意のオブジェクト・タイプに関連づけられるデータ・エレメントの形式のコンテンツは、ワークフロー・サービス５０２において直接的な関係性を有してもよい。即ち、ワークフロー・サービスは、その経路を、例えばコンテンツに含まれるフィールド値のコンテンツによって決定させてもよい。特定のオブジェクト・タイプのコンテンツには、関連づけられる無限数のフィールドが存在してもよい。コンテンツ内のフィールドに含まれてもよいコンテンツの例には、列挙される定格の値（効果的、無効果、未決定）または優先性（高、中、低）もしくはレポジトリ・サービス５０４によってサポートされる他の任意のデータ・タイプが含まれる。
【０１００】
図１４を参照すると、概して５９０において、あるオブジェクト・タイプとその関連フィールドが表現されている。オブジェクト・タイプ５９２は、図１０に示すオブジェクト・タイプの何れであってもよく、または調査から生成されるものであってもよい。オブジェクト・タイプ５９２は、自らに関連づけられる１からＮまでのフィールドを有してもよく、本発明の範囲に含まれる。図１４は、オブジェクト・タイプとフィールドとの関係性を示している。図１４を参照すると、５９４におけるフィールド１、５９６におけるフィールド２及び５９８におけるフィールドＮはオブジェクト・タイプ５９２に関連づけられる。オブジェクト５９２が図１０におけるプロセス・オブジェクト５５６であれば、これらのフィールドが何を包含し得るかといえば、例えば、フィールド１は「名前」を含み、フィールド２は「説明」を含み、フィールド３は「所有者」を含むことが可能である。
【０１０１】
ワークフロー・サービスを制御するコンテンツの例は、次のような条件、即ち、特定のリスク・オブジェクト・タイプ５５８（図１０、１２または１３）に関して制御オブジェクト・タイプ５６０に関連する調査が存在した、調査に答えるタスクが存在した、という条件が存在すれば発見することができる。このタスクの完了後は、調査が再検討される。この調査が、リスクに対する制御の効果に関して１０点中１から５までの定格を付ければ、第１のアクションが講じられるが、定格が６から１０までであれば、第２のアクションが講じられる。ワークフローのこの選択的なルーティングは、そのオブジェクト・タイプのフィールド値に包含されることになる。従って、調査のコンテンツはワークフロー・サービス５０２に影響を与える。この例をグラフにしたものが図１４であり、後に説明する。
【０１０２】
図１５を参照すると、概して６００において、調査に答えるための制御オブジェクト・タイプに基づくタスクが存在した。このタスクは、６０２に示されている。この調査の目的は、特定のリスクに対する制御の効果を評価することである。このタスクは、組織においてその責任を負っている特定の一人または多数によって完了されるべきものである。後続タスクは、上記調査の結果に依存する、組織内のエンティティに関する偶発的なタスクである。図１５に示すように、調査の結果は決定ブロック６０４へ適用される。決定ブロックにおいて、調査の全体的な定格が６から１０の間であって、そのリスクに対する制御が効果的であることが示されると、結果を再検討するタスクは６０８におけるＣＦＯへ進む。これに対して、定格がリスクに対する制御の無効果を示す１から５であれば、結果を再検討するタスクは６０６におけるＣＥＯへ進む。従って、調査のコンテンツは、上述の選択的なルーティングを決定づけるこれらのフィールド値に従ってアプリケーションのワークフローを制御する。
【０１０３】
図１６を参照すると、概して６５０において、コンテンツにより制御されているワークフローの別の例が示されている。６５２では、特定のリスク・オブジェクト・タイプがその特定のリスクに関連づけられる「リスクの重大度」フィールド及び「リスクの尤度」フィールドによって特徴づけられる。これらのフィールドは各々、数値基準、単純なＨＩＧＨ／ＬＯＷ基準またはシステム・ユーザにより決定される他の基準に基づいて査定されることも可能である。この査定は、調査によって実装されてもよい。リスク・オブジェクト・タイプ６５４のフィールドの評価は、決定ブロック６５６への移行を引き起こす。これらのフィールドの条件は、ワークフローの分岐及びタスクを割り当てられるエンティティを決定する。図１６には、各フィールドについて、その評価がＨＩＧＨまたはＬＯＷの何れかであってもよい場合にタスクを割り当てられるエンティティがグラフで示されている。リスクの重大度／尤度がＨＩＧＨ／ＨＩＧＨであるという評価であれば、６５８におけるマネージャにリスクを検索するタスクが割り当てられる。リスク評価がＬＯＷ／ＬＯＷであれば、６７０においてリスク検索のタスクを割り当てられるマネージャは存在しない。最後に、評価結果が混合的なＨＩＧＨ／ＬＯＷまたはＬＯＷ／ＨＩＧＨであれば、６７２における中間マネージャにリスク検索のタスクが割り当てられる。何れの場合も、リスク・フィールドの評価によって生成されたコンテンツがワークフローを制御している。
【０１０４】
本発明がコンテンツを使用してワークフロー・サービスを制御するために採用する別の方法は、コンテンツ自体においてルーティングが方向づけられるべき場所を指定することである。例えば、組織内の特定の一人または複数の人がプロセス・オブジェクト・タイプのコンテンツにおいてそのプロセスの「所有者」として指名されてもよい。これは、その人または複数の人がこのビジネス・プロセスを評価する過程でプロセスの異なる態様を再検査するタスクに自動的に割り当てられることを意味する。
【０１０５】
本発明によるシステムがコンテンツを使用してワークフローを制御するさらなる方法は、特定のオブジェクト・タイプ内のタスクをそのアソシエーションのコンテンツを使用して再帰的に割り当てるその能力にある。これは、システムが１つのオブジェクト・タイプをサブエレメント、サブ・サブエレメント、他に分割することを許容する。
【０１０６】
一例として、各企業レベルでサインオフされなければならない企業プロセスが存在する場合がある。これには、本社、支社、地域事務所、グループ事務所及び最後に上記プロセスを採用する製造施設が含まれる。本社は、全ての企業レベルに関して、上記プロセス上でサインオフするための要件アクションを開始する。ビジネス・エンティティ間の関連性は、先に述べたビジネス・エンティティの再帰的階層を基礎として再帰的に誘導される。ワークフローは、この再帰的制御に従う。従って、本社はそのアクションを、同じアクションを呼び出してこの次のレベルにおける各ビジネス・エンティティを「通す」ことにより、階層構造におけるその下のレベルへ送る。この次のレベルである地域事務所は、このプロセスを各グループ事務所について反復する。この時点で、グループ事務所レベルのタスクは再検査及びサインオフを進め、制御を再検査及びサインオフのために次の上位レベルへ送り戻す。これは、再検査及びサインオフが本社によって完了されるまで続く。このワークフローは、オブジェクトのアソシエーションの再帰的誘導によって制御されている。
【０１０７】
公開サービス５０６を介するレポートの公開は、好適には、動的に公開されるページを包含する。公開サービス５０６は、マルチチャネル配備グループ２５０（図５）のパラメータ内で動作する。これらのページは、そのコードによりサポートされる任意のプラットフォームに適合するようにコード・ベース式である。例えば、上記ページはＪＡＶＡ（登録商標）を基礎とする可能性があり、よって、これらのページはＪＡＶＡ（登録商標）によりサポートされる任意のシステムに統合されることが可能である。
【０１０８】
生成されるページは、基本テンプレートの周囲でパラメータ化されてもよい。よって、テンプレートは、パラメータを定義し直して修正することにより、他のページを生成するために繰返し使用されてもよい。
【０１０９】
公開されるページ及びテンプレートは、アプリケーション・オブジェクト・タイプから構成される。従って、これらは、先に述べたアクセス制御機構の対象となる。
【０１１０】
好適には、公開されるレポートのページ・コンテンツはＨＴＭＬで生成され、レポジトリ・サービスにおいてモデリングされるアプリケーションの任意のオブジェクト・タイプへリンクすることができる。従って、モデリングされるオブジェクト・タイプ内の詳細ページへのこれらのリンクを、レポートの一部として生成することができる。従って、システム・ユーザはディスプレイ上でレポートを実行することができ、これをレポート内でリンクによりポイントされている詳細への誘導に使用する。システム・ユーザは、リンクへアクセスした時点で、アクセスされた詳細を変更し、次いでレポートへ戻ることも可能であり、よってレポートは新しい情報でリフレッシュされることが可能である。
【０１１１】
本発明によれば、レポートのページ及びページ・テンプレートは、オブジェクト・タイプ自体から構成されてもよい。これは、モデリングされるアプリケーションの階層構造に従ったレポートの編成を可能にする。これを実行する方法は、好適には、レポートを様々なオブジェクト・タイプに対応するフォルダに編成するものであろう。この編成モデルもやはり、先に論じたアクセス制御の容易な使用を可能にする。
【０１１２】
以上の内容について説明している本発明の実施形態は、上述の実施形態にのみ限定されるものではない。上記説明は、任意のコンピューティング環境または処理環境に適用可能である。これらの実施形態は、ハードウェア、ソフトウェアまたは両者の組合せにおいて実装されてもよい。例えば、これらの実施形態は、プログラマブル論理（例えば、ＡＳＩＣ）、論理ゲート、プロセッサ及びメモリのうちの１つまたはそれ以上等の回路を使用して実装されてもよい。
【０１１３】
これらの実施形態は、各々がプロセッサと上記プロセッサによる読取り可能な格納媒体（揮発性及び不揮発性メモリ及び／または格納エレメントを含む）とを含むプログラマブル・コンピュータ上で実行されるコンピュータ・プログラムにおいて実装されてもよい。このようなプログラムは各々、コンピュータ・システムと通信する高レベル手続き言語またはオブジェクト指向プログラミング言語において実装されてもよい。しかしながら、プログラムはアセンブリ言語または機械語に実装されてもよい。言語は、コンパイラ型言語またはインタープリタ型言語であってもよい。
【０１１４】
各コンピュータ・プログラムは、コンピュータを構成しかつ格納媒体またはデバイスが上記実施形態の機能を実行すべくコンピュータにより読み取られる際にコンピュータを動作させるために、汎用または専用プログラマブル・コンピュータによる読取りが可能な格納媒体（例えば、ＣＤ−ＲＯＭ、ハードディスクまたは磁気ディスク）またはデバイス（例えば、コンピュータ周辺機器）等の製品に格納されてもよい。また、これらの実施形態はコンピュータ・プログラムで構成される機械読取り可能格納媒体として実装されてもよく、この場合は、実行されると、コンピュータ・プログラム内の命令によってマシンは上述の実施形態の機能を実行すべく動作される。
【０１１５】
上述の実施形態は、様々なアプリケーションに使用されてもよい。これらの実施形態は下記に限定されるものではないが、他の電子コンポーネントのなかでもとりわけ、マイクロコントローラ内のメモリ・デバイス、汎用マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、縮小命令セット・コンピューティング（ＲＩＳＣ）及び複合命令セット・コンピューティング（ＣＩＳＣ）によって実装されてもよい。またさらに、上述の実施形態は、メイン・メモリ、キャッシュ・メモリ、またはマイクロプロセッサにより実行されるべき電子命令を格納する、または算術演算に使用されてもよいデータを格納する他のタイプのメモリとして言及される集積回路ブロックを使用して実装されてもよい。
【０１１６】
本明細書で使用している用語及び表現は説明のためものであり、限定的なものではない。このような用語及び表現の使用に、本明細書において示された、または記述された特徴またはその一部の等価物を除外する意図はなく、様々な修正が特許請求の範囲に記載された本発明の範囲内で可能であることは認識される。
【図面の簡単な説明】
【０１１７】
【図１】アダプティブ・コンテンツ・プラットフォームを示すブロック図である。
【図２】上記アダプティブ・コンテンツ・プラットフォームのコンテンツ管理グループを示すブロック図である。
【図３】上記アダプティブ・コンテンツ・プラットフォームのワークフロー及びコラボレーション・グループを示すブロック図である。
【図４】上記アダプティブ・コンテンツ・プラットフォームのマルチモード・コンテンツ生成グループを示すブロック図である。
【図５】上記アダプティブ・コンテンツ・プラットフォームのマルチチャネル配備グループを示すブロック図である。
【図６】分散コンピューティング・システムに組み込まれた上記アダプティブ・コンテンツ・プラットフォームを示すブロック図である。
【図７】分散コンピューティング方法を示すフローチャートである。
【図８】多層構成ソフトウェアの開発方法を示すフローチャートである。
【図９】レポジトリ・サービスにおけるアプリケーション・オブジェクト・モデリング及びワークフロー／公開サービスの活用をサポートする、ワークフロー、レポジトリ及び公開サービスより成るサービス層の共通セットを示す。
【図１０】レポジトリ・サービスにおいてオブジェクト・タイプによりモデリングされる依存型アプリケーションの階層構造を示す。
【図１１】モデリングされるオブジェクトのサブタイプの例をさらに示す、依存型アプリケーションの階層構造の一部を示す。
【図１２】制御オブジェクトのアソシエーションを追加した、図１０に示すものに類似する依存型アプリケーションの階層構造を示す。
【図１３】レポジトリ・サービスにおいてオブジェクト・タイプによりモデリングされた、「フォーム」を使用してオブジェクト・タイプが追加されている依存型アプリケーションの階層構造を示す。
【図１４】オブジェクトと関連フィールドを表現したものである。
【図１５】ワークフロー・サービスに影響するオブジェクト・コンテンツの第１の例を示す。
【図１６】ワークフロー・サービスに影響するオブジェクト・コンテンツの第２の例を示す。
【図１】
0005710102.tif 000002
【図２】
0005710102.tif 000003
【図３】
0005710102.tif 000004
【図４】
0005710102.tif 000005
【図５】
0005710102.tif 000006
【図６】
0005710102.tif 000007
【図７】
0005710102.tif 000008
【図８】
0005710102.tif 000009
【図９】
0005710102.tif 000010
【図１０】
0005710102.tif 000011
【図１１】
0005710102.tif 000012
【図１２】
0005710102.tif 000013
【図１３】
0005710102.tif 000014
【図１４】
0005710102.tif 000015
【図１５】
0005710102.tif 000016
【図１６】
0005710102.tif 000017