JP2003177948A - データの変換・流通を行うデータ管理機構 - Google Patents

Abstract

(57)【要約】 【課題】 ファイルシステム内のデータを含むデータの
変換・流通などのデータ管理と業務アプリケーションと
を分離、独立化させる。 【解決手段】 データ変換ポリシーを含むデータ属性を
管理する手段２と、データ変換および／または流通を行
うべきタイミングをトリガとして検出する手段３と、ト
リガが検出された時、手段２によって管理されているデ
ータ属性に対応して、データ変換および／または流通の
処理を行う手段４とを備え、ファイルシステムを管理す
るオペレーティングシステムによって管理され、アプリ
ケーションプログラムと独立に動作する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する利用分野】本発明はデータの管理方式に
係り、更に詳しくはデータの属性と共に、データ変換の
論理、データ変換のタイミングをファイルの属性、すな
わちポリシーとして管理することによって、業務アプリ
ケーションとデータとを独立させることができるデータ
管理機構に関する。

【０００２】

【従来の技術と発明が解決しようとする課題】従来のデ
ータ管理機構の１つとしてのファイルシステムでは、フ
ァイルとしてのデータの所在管理と、データへのアクセ
ス法が提供されるが、データの内容や構造についてはフ
ァイルシステムは基本的に無関係であり、データ処理の
論理はユーザがアプリケーションプログラムによって定
義してきた。

【０００３】図１８は従来のファイルシステムの説明図
である。ファイルシステム側ではデータの物理的な属性
が管理されているにすぎず、データ構造、ファイルに対
する処理の起動タイミング、および処理の論理について
は、全てアプリケーションプログラム（業務アプリ）側
で管理されている。

【０００４】図１９は従来のデータベースマネージメン
トシステム（ＤＢＭＳ）の説明図である。同図において
ＤＢＭＳ側では、データの物理的な属性と共にデータ構
造についても管理しており、アプリケーションプログラ
ムの作成労力はある程度削減されるが、データ入出力の
起動タイミングやデータ処理の論理についてはアプリケ
ーションプログラム側で管理されている。また一般のこ
れらのシステムでは、データの管理は業務アプリ（ケー
ション）が動作しているシステムによって行われてい
る。

【０００５】以上説明したような従来のデータ管理方式
では、業務アプリケーション側でデータの入出力だけで
なく、データ処理の起動のタイミングや、その処理の論
理の全てをプログラムとして記述しなければならず、業
務アプリケーションの開発に手間がかかるという問題点
があった。

【０００６】またデータ自体を含むデータ処理の全てが
業務アプリケーションが動作しているシステムのサーバ
に従属しているために、サーバの負荷が増加した場合に
も業務アプリケーションを別のサーバに単純に移行する
ことができず、負荷のバランス制御が困難であるという
問題点があった。

【０００７】更に業務アプリケーションを追加したい場
合にも、業務アプリケーションが動作しているシステム
の資源の状況を考えながら行われなければならないとい
う問題点があった。

【０００８】本発明の課題は、上述の問題点に鑑み、業
務アプリケーションとデータの変換・流通などの管理と
を独立化させることができるデータ管理機構を提供する
ことである。

【０００９】

【課題を解決するための手段】図１は本発明のデータ管
理機構１の原理構成ブロック図である。同図はファイル
システム内のデータを含むデータの管理を行うデータ管
理機構、すなわちデータの変換・流通を行うデータ管理
機構の原理構成ブロック図である。

【００１０】図１において属性管理手段２は、データの
変換ポリシー、例えば変換元と変換先の対応関係や、変
換の開始から終了までの一連の処理などの変換ポリシー
を含むデータ属性を管理するものである。

【００１１】トリガ検出手段３は、データの変換および
／または流通を行うべきタイミングをトリガとして検出
するものであり、このトリガを検出すべき条件として
は、例えばファイルに関してはオープン、クローズ、作
成、削除など、ディレクトリについては作成、削除など
の条件があり、更にファイル属性の変更などの条件があ
る。

【００１２】データ変換・流通手段４はトリガが検出さ
れた時、属性管理手段２によって管理されているデータ
属性に対応して、データの変換および／または流通の処
理を行うものである。

【００１３】本発明においては、このデータ管理機構１
はファイルシステムを管理するオペレーティングシステ
ムによって管理され、アプリケーションプログラムとは
独立に動作するものである。

【００１４】発明の実施の形態においてはデータ管理機
構はファイルシステム内に組み込まれることもでき、ま
たこのファイルシステムはアプリケーションプログラム
が動作するシステム内に組み込まれることもできる。こ
の場合、データ管理機構がアプリケーションプログラム
が動作するシステム上のミドルウエアとの間での処理の
連携のための情報交換を行う操作インタフェース手段を
更に備えることもできる。

【００１５】また実施の形態においては、データ管理機
構はアプリケーションプログラムが動作する１つ以上の
システムとの間で、ネットワークを介したストレージの
集中管理を実現するネットワークアタッチドストレージ
システム内に組み込まれることもできる。

【００１６】この場合、データ管理機構はネットワーク
アタッチドストレージシステム上のファイルシステムレ
イヤに実装されることもでき、あるいはネットワークア
タッチドストレージシステム上のアプリケーションレイ
ヤに実装されると共に、ファイルのオープン、クロー
ズ、リネーム、クリエイト、リムーブ、リンクなどを含
み、前記データの変換および／または流通を行うための
システムコールの実行前に呼び出されるシステムコール
を監視し、その呼び出されるシステムコールの検出をト
リガとしてトリガ検出手段３に与えるシステムコール監
視手段を更に備えることもできる。

【００１７】次にファイルシステム内のデータを含むデ
ータの管理を行うデータ管理システムにおいて、データ
の変換ポリシーを含むデータ属性を管理する属性管理手
段と、データの変換および／または流通を行うべきタイ
ミングをトリガとして検出するトリガ検出手段と、該ト
リガが検出された時、前記属性管理手段によって管理さ
れているデータ属性に対応して、データの変換および／
または流通の処理を行うデータ変換・流通手段とが２つ
以上のサーバに分散して備えられ、アプリケーションプ
ログラムと独立に動作する。

【００１８】なお、発明の実施の形態においては、以上
に述べたデータ管理機構１、属性管理手段２、トリガ検
出手段３、データ変換・流通手段４、操作インタフェー
ス手段、およびシステムコール監視手段はいずれもソフ
トウェアとして実現される。

【００１９】また本発明において、データの変換および
／または流通を行うデータ管理機構を備える計算機によ
って使用されるプログラムとして、データの変換および
／または流通を行うべきタイミングとしてのトリガを検
出する手順と、該トリガが検出された時、データの変換
および／または流通のポリシーを参照する手順と、該ポ
リシーの内容に対応してデータの変換および／または流
通の処理を行う手順とを計算機に実行させるためのプロ
グラムが用いられる。

【００２０】また本発明において、データの変換および
／または流通を行うデータ管理機構を備える計算機によ
って使用される記憶媒体として、データの変換および／
または流通を行うべきタイミングとしてのトリガを検出
するステップと、該トリガが検出された時、データの変
換および／または流通のポリシーを参照するステップ
と、該ポリシーの内容に対応してデータの変換および／
または流通の処理を行うステップとを計算機に実行させ
るためのプログラムを格納した計算機読み出し可能可搬
型記憶媒体が用いられる。

【００２１】以上のように本発明によればデータの変換
および流通がアプリケーションプログラムと独立に実行
可能となり、業務アプリケーションとデータ管理との分
離が実現される。

【００２２】

【発明の実施の形態】図２は本発明の原理的な概念の説
明図である。同図において業務アプリケーション１０と
ファイルシステム１１とは、例えば図１８におけると同
様のインタフェースによって接続されているが、図１８
と異なってデータの物理的な属性、データ構造、ファイ
ルの起動タイミング、および処理論理などは全てファイ
ルシステム１１側で管理される。

【００２３】図３は本発明の実施形態におけるデータ変
換動作の基本的な説明図である。同図において、業務ア
プリ（ケーション）１２によって作成されたデータが変
換されて、業務アプリ（ケーション）１９に与えられる
ものとする。

【００２４】業務アプリケーション１２から与えられ
た、例えばファイル名“ａ．ｘｍｌ”のデータ１３に対
するデータ変換の起動条件がトリガ管理部１４によって
検出されると、その検出結果は変換管理部１５に与えら
れる。変換管理部１５は、ポリシー管理部１６によって
管理されているファイルに対する変換ポリシーを参照
し、与えられたトリガに対応してデータ変換とコピーを
行うべきことを検出すると、変換部品１７を駆動する。
変換部品１７はデータ１３に対する変換を行い、その処
理結果としてのファイル名“ａ．ｈｔｍｌ”のデータ１
８を業務アプリケーション１９に与える。

【００２５】ここで図３のトリガ管理部１４、変換管理
部１５、ポリシ管理部１６、および変換部品１７はいず
れもソフトウェアである。図４は図３のポリシー管理部
１６によって管理されているファイルに対するポリシー
の説明図である。同図においてポリシーは制約条件、関
係、手続き、例外処理、およびスキーマ定義の５つに分
類されるが、これらのうち制約条件は図２で説明した起
動タイミングに、関係、手続き、例外処理の３つは処理
論理に、スキーマ定義はデータ構造に相当する。

【００２６】まず起動タイミングに対応する制約条件
は、変換処理を起動するためにファイルが満たすべき条
件であり、その項目はファイルの状態に対応するトリガ
ＩＤである。

【００２７】変換が起動されるためのトリガ指定条件と
してはファイルに対してはオープン、クローズ、名称変
更（リネーム）、作成（クリエイト）、削除（リムー
ブ）、リンクなどがディレクトリに対しては作成、削除
などがある。さらにファイル属性、すなわちスキーマ定
義の変更などの他に、一般的なトリガ条件として、例え
ば毎日定められた時刻や、ファイルそのものの存在など
についても指定可能である。

【００２８】処理論理、すなわち変換論理としての関係
は変換元と変換先の対応関係を示すものであり、変換先
は複数であることもできる。その項目はパス名や、手続
きＩＤに対応する関係ＩＤである。

【００２９】手続きは変換の開始から終了までの一連の
処理の手続きを示し、アダプタの指定や、ＸＭＬ（エク
ステンシブルマークアップランゲージ）文書の構造を別
の形式に変換するための変換ルールを記述するＸＳＬＴ
（ＸＭＬスタイルシートランゲージトランスフォーム）
などに相当する手続きＩＤである。

【００３０】例外処理はファイルの変換などでエラーが
発生した場合のエラー通知方法を示し、その項目はエラ
ーの通知先を示すＥメールアドレスや、エラーの記録を
残すためのログファイル名などである。

【００３１】スキーマ定義は変換元と変換先のデータ構
造であり、例えばＸＭＬスキーマ言語でシンタックス／
セマンティクスが記述されるものであり、その項目はＸ
ＭＬスキーマ、またはノンＸＭＬファイル情報である。
このノンＸＭＬファイル情報は、変換後のＸＭＬ文書の
スキーマ定義としても使用され、独自のボキャブラリを
提供するものである。

【００３２】図５は本実施形態におけるデータ管理機構
のコンポーネント構成を示すブロック図である。同図に
おいてデータ管理機構は全体制御部２０、トリガ制御部
２１、ポリシー管理部２２、ファイルポリシー２３、変
換処理制御部２４、変換機能部品２５、例外処理部２
６、および操作インタフェース２７によって構成されて
いる。

【００３３】ここで全体制御部２０、トリガ制御部２
１、ポリシ管理部２２、変換処理制御部２４、変換機能
部品２５、例外処理部２６、および操作インタフェース
２７はいずれも基本的にソフトウェアによって実現され
る。

【００３４】全体制御部２０は、データ管理機構全体を
制御するために処理の振り分けを行うものであり、必要
情報のコーディネイトと、対称コンポーネントの呼び出
しを行うものである。

【００３５】ポリシー管理部２２は、ファイルに対して
指定されたポリシー情報の管理を行うものであり、図４
で説明したポリシーの登録、削除、参照、および更新を
制御するものである。

【００３６】変換処理制御部２４は、ファイルに対して
指定されたポリシー情報をもとにして必要な変換機能部
品２５を選択し、処理に必要なパラメータを設定して変
換機能部品２５を起動し、その処理完了を待ち合わせて
完了状態を判断し、必要な後処理、例えば例外処理など
を行わせるものである。

【００３７】トリガ制御部２１は、ポリシーによって指
定されたトリガ条件、すなわち前述の制約条件を検出
し、その結果を全体制御部２０に通知する。トリガ制御
部２１の実装方法としては、第１にファイルシステム内
部に組み込むパターン、すなわちファイルシステムから
トリガに関する情報を獲得するパターンと、第２のパタ
ーンとしてファイルのオープンやクローズなどのシステ
ムコールの実行前に呼び出されるシステムコールとして
のフック、第３のパターンとして一般アプリケーション
として一定時間間隔で起動され、システムの状態を調査
するパターンなどが考えられる。

【００３８】操作インタフェース２７は、ポリシー情報
に対するユーザとのインタフェースを受け持つものであ
る。コマンドレベルのインタフェースとウェブインタフ
ェースが装備され、また手動でのユーザからのデータ変
換依頼や、ミドルウエアとの個別インタフェースについ
ても、ここで受付処理が行われる。

【００３９】変換機能部品（群）２５は、実際にファイ
ル内のデータの変換を行う部品であり、ＸＭＬであれば
ＸＳＬＴプロセッサなどである。ノンＸＭＬの場合に
は、一般のＥＴＬツール、すなわち分散してしまったデ
ータを統合するためのエクストラクト、トランスフォー
ム、およびローディングを行うツールなどのように既存
のファイル変換機能である。

【００４０】例外処理部２６は、データ変換処理など様
々な処理の後処理を受け持つものである。処理結果のロ
ギングやエラーなどの例外に対するメッセージ出力や、
メール通知などを行うものである。

【００４１】図６、および図７は本実施形態における処
理のフローチャートである。これらのフローチャート
は、本発明に直接関係のある処理のみについて説明する
ものであり、例えば処理結果の業務アプリケーションへ
の受渡しなど、後述するようにファイルシステムとして
の従来処理についてはその説明を省略する。

【００４２】図６はユーザからのポリシー操作、すなわ
ちポリシーの登録、更新、削除、または参照などの要求
などに対する処理のフローチャートである。同図におい
て、まず操作インタフェース２７がステップＳ１でユー
ザからの操作を受付け、ステップＳ２で全体制御部２０
にその処理を依頼する。

【００４３】全体制御部２０はステップＳ３で処理の依
頼を受付け、ステップＳ４で処理内容をチェックし、ポ
リシー操作の処理であると判定した場合には、ステップ
Ｓ５でポリシー管理部２２に処理を依頼する。ポリシー
操作の処理でない場合には、その他の処理に移行する。

【００４４】ポリシー管理部２２は、ステップＳ６で依
頼された処理を受付け、ステップＳ７で処理内容をチェ
ックし、ステップＳ８でポリシーの参照、登録、または
削除を行い、ステップＳ９で全体制御部１０に対して処
理結果を通知する。

【００４５】全体制御部２０はこの結果を受け取り、ス
テップＳ１０で処理結果が例外か否かをチェックし、例
外でないときはデータの変換処理が必要となったか否か
を判定するためにステップＳ１１で変換条件をチェック
し、変換条件が満足されている場合には、再帰的な呼び
出しとして、ステップＳ３において変換処理制御部２４
を呼び出すための処理が受付けられ、ステップＳ４以降
の処理が行われる。ここではその他の処理としてデータ
の変換処理が依頼されることになる。

【００４６】全体制御部２０によるステップＳ１０の処
理において処理結果がチェックされ、例外処理を行うべ
きものと判定されると、ステップＳ１２で例外処理部２
６に処理が依頼される。

【００４７】例外処理部２６はステップＳ１３でこの依
頼を受付け、ステップＳ１４で例外処理を実行し、ステ
ップＳ１５で全体制御部２０に対して処理結果を通知す
る。全体制御部２０はこの処理結果をステップＳ１６で
受け取り、またステップＳ１１で変換条件が満足されて
いない時には、ステップＳ１７で操作インタフェース２
７に対して処理結果を通知する。

【００４８】操作インタフェース部２７はステップＳ１
８でその処理結果を受け取り、ステップＳ１９でその結
果をユーザに通知する。図７はデータの変換・流通の自
動処理のフローチャートである。同図において、トリガ
制御部２１がデータ変換を行うためのトリガをステップ
Ｓ２１で検出すると、トリガ制御部２１は全体制御部２
０にステップＳ２２で処理を依頼する。

【００４９】全体制御部２０はステップＳ２３この依頼
を受付け、ステップＳ２４で処理内容をチェックし、変
換のためのトリガに対する処理であると判定すると、ス
テップＳ２５でポリシー管理部２２に対して処理を依頼
する。

【００５０】ポリシー管理部２２はステップＳ２６でこ
の依頼を受付け、ステップＳ２７で処理内容をチェック
し、ステップＳ２８でファイルポリシー（ポリシー格納
ファイル）２３の内容を参照し、ステップＳ２９で全体
制御部２０に対して処理結果を通知する。

【００５１】全体制御部２０はステップＳ３０でこの処
理結果を受け取り、ステップＳ３１でデータ変換条件が
満足されているか否かを判定し、満足されている時には
ステップＳ３２で変換処理制御部２４に処理を依頼した
後に、変換条件が満足されていない場合には直ちに、ス
テップＳ３３でトリガ制御部２１に処理結果を通知す
る。変換処理制御部２４にデータ変換処理を依頼した場
合には、一般的に変換に時間がかかるため、処理を依頼
したことだけがトリガ制御部２１に通知される。

【００５２】トリガ制御部２１はステップＳ３４でこの
処理結果を受け取り、ステップＳ３５でトリガ検出待ち
の状態に復帰する。変換処理制御部２４はステップＳ３
６で全体制御部２０からのデータ変換処理依頼を受付
け、ステップＳ３７で変換に必要なパラメータを組み立
て、ステップＳ３８で変換機能部品２５を呼び出して処
理を行わせ、その結果を受け取り、ステップＳ３９で全
体制御部２０に処理結果を通知する。

【００５３】全体制御部２０はこのデータ変換の処理結
果をステップＳ２３で受付け、例えば図３で説明したよ
うにその変換結果のデータ１８を業務アプリ１９に渡す
ことになるが、その処理の説明は省略する。また全体制
御部２０はこのデータ変換結果をステップＳ２４でチェ
ックした時、データ変換結果の通知であると判定した場
合にはステップＳ４０で処理結果をチェックするが、そ
のチェックの結果例えば変換エラーが生じた場合には、
ステップＳ４１で例外処理部２６を呼び出して処理を終
了する。

【００５４】ユーザから手動でデータの変換・流通処理
が要求される場合には図７のトリガが制御部２１に代わ
って、その要求は操作インタフェース２７に入力され、
操作インタフェース２７から全体制御部２０に処理が依
頼され、ステップＳ２３以降の処理が実行される。最終
的な変換結果などは操作インタフェース２７を介してユ
ーザに与えられる。

【００５５】次に本実施形態のデータ管理機構が組み込
まれたデータ処理システムの構成例について説明する。
図８はそのようなシステムの第１の構成例である。この
第１の構成例においては図５で説明したデータ管理機構
がファイルシステムレイヤに実装され、業務アプリケー
ションが動作する１つのシステム内に組み込まれた例で
ある。同図においては、ファイルシステム３０の内部
に、従来の処理としてのファイルの入出力制御などを行
うファイルシステム３１に加えて、データ管理機構を構
成する全体制御部２０から例外処理部２６までの各コン
ポーネントが実装されている。すなわち、データ管理機
構はファイルシステムを管理するオペレーティングシス
テムによって管理されるが、同一システム内であっても
アプリケーションプログラムとは独立して動作する。な
おファイルシステム３１も基本的にはソフトウェアによ
って実現されている。

【００５６】図８においては、例えば業務アプリ１２に
よって作成されたファイルが、従来の処理としてファイ
ルの入出力制御などを行うファイルシステム３１を介し
て入力され、変換結果はファイルシステム３１を介して
業務アプリ１９に与えられる。このように業務アプリケ
ーションが動作するシステム上に組み込むことによっ
て、データとアプリケーションとの独立化が達成され
る。

【００５７】また図８においてミドルウエア３２は、直
接に操作インタフェース２７との間でデータ交換が可能
なものである。すなわち従来処理を行うファイルシステ
ム３１を介することなく、業務システム上のミドルウエ
アとの連携によって、ミドルウエアによって行われる処
理の一部をデータ管理機構が代行することが可能とな
る。

【００５８】例えばミドルウエア３２側で行われるべき
ＸＭＬ処理機能との連携として、ウェブページの内容お
よびそれらの配置やスタイルをオブジェクトとして扱
い、スクリプト言語を使って制御するためのドキュメン
トオブジェクトモデル（ＤＯＭ）展開ファイル化、シリ
アライズ化、部分参照機能、およびＸＭＬとＨＴＴＰな
どをベースとした他のコンピュータにあるデータやサー
ビスを呼び出すための通信規約であるシンプル・オブジ
ェクト・アクセス・プロトコル（ＳＯＡＰ）複合ドキュ
メントの展開・合成（封筒の出し入れ）などを代行する
ことが可能となる。

【００５９】またミドルウエア側で動作するパッケージ
との連携処理として、クリックログ分析、企業内で業務
に使用される複数のコンピュータシステムを有機的に連
携させ、データやプロセスの効率的な統合を図るエンタ
ープライズ・アプリケーション・インテグレーション
（ＥＡＩ）の性能管理、ポイント・オブ・セールス（Ｐ
ＯＳ）のデータ解析、ＳＯＡＰ利用パッケージの処理な
どが代行可能となる。

【００６０】図９は本実施形態のデータ処理機構を用い
るシステムの第２の例の構成ブロック図である。この例
はネットワーク経由でサーバとストレージ機器とを通信
させて、ストレージの集中管理を実現するネットワーク
・アタッチド・ストレージ（ＮＡＳ）サーバのファイル
システムレイヤにデータ管理機構を実装した例であり、
業務アプリケーションが動作するシステムとは別のシス
テムにデータ管理機構が組み込まれる。

【００６１】すなわち、この第２の例ではデータ管理機
構はファイルシステムを管理するオペレーティングシス
テムによって管理されるが、別のシステム上のアプリケ
ーションプログラムとは当然独立して動作する。

【００６２】図９においてＮＡＳサーバ内で、ファイル
システム３０の内部に、従来処理を行うファイルシステ
ム３１に加えて、全体制御部２０から操作インタフェー
ス２７までのコンポーネントが実装されている。そして
ストレージに対するアクセス要求の仲介を行うＮＡＳヘ
ッド３７を介して、業務システム３６によって作成され
たファイルが入力され、変換結果はＮＡＳヘッド３７か
ら他の業務システム３８内の業務アプリケーションに与
えられる。

【００６３】この例ではデータ管理と業務アプリケーシ
ョンの独立化と共に、業務システム側でのメモリやＣＰ
Ｕなどの使用資源の削減が実現される。図１０はデータ
管理機構が組み込まれるシステムの第３の例である。本
実施形態のデータ管理機構が、ＮＡＳサーバ３５上の一
般アプリケーションレイヤに実装される。

【００６４】図８，図９で説明した第１、第２の例で
は、前述のトリガ制御の実装方法として、従来処理を行
うファイルシステム３１の内部に組み込むパターンが使
用されるが、第３の例においてはデータ管理機構が一般
アプリケーションレイヤに実装されるため、前述の第２
のパターン、すなわちシステムコールとしてのフックが
利用され、その監視を行うためにシステムコールフック
自前監視部４０が追加されている。

【００６５】なお図９、図１０におけるＮＡＳヘッド３
７、およびシステムコールフック自前監視部４０もソフ
トウェアとして実現される。図１１は本実施形態のデー
タ管理機構を用いるシステムの第４の例の構成ブロック
図である。この例においては１つのシステム、または１
つのサーバ内にデータ管理機構全体が組み込まれるので
はなく、図５で説明した各コンポーネントが各種のサー
バに分散して組み込まれる点に特徴がある。

【００６６】すなわちＮＡＳヘッド３７、およびトリガ
制御部２１はＮＡＳサーバ４５に、全体制御部２０、お
よび例外処理部２６は制御サーバ４６に、ポリシー管理
部２２、操作インタフェース２７、およびファイルポリ
シー２３はポリシーサーバ４７に、変換処理制御部２
４、および変換機能部品２５は変換サーバ４８に、また
ファイルシステム３１はディスクサーバ４９にそれぞれ
組み込まれる。

【００６７】ＮＡＳサーバ４５、ポリシーサーバ４７は
それぞれ故障に備えて二重化構成とされ、片方はスタン
バイとして用いられる。制御サーバ４６、変換サーバ４
８、およびディスクサーバ４９はそれぞれｎ個備えら
れ、並列実行のためのロードシェア、およびファイルシ
ステム全体としての容量確保が実現される。

【００６８】次に本実施形態のデータ管理機構の適用例
について、従来方式と比較しながら図１２〜図１６を用
いて説明する。図１２および図１３は複数の業務サーバ
の間でデータを交換する業務への適用例であり、図１２
は従来方式、図１３は本発明の方式の説明図である。

【００６９】このデータ交換業務において本発明を用い
る場合には、利用者が作成したデータはそのまま保存さ
れると共にそのデータから変換されるデータは自動的
に、かつ最初にデータを作成した業務サーバの資源を利
用せずに作成される。この例では全社のデータから各部
門単位のデータが作成され、各部門のサーバに公開され
る業務が実行される。

【００７０】図１２において、まず本社サーバにおいて
アプリケーションプログラムを用いて会社データの作
成、およびそのデータの分割が行われ、各部門のデー
タ、すなわち部門１から部門３のデータが作成される。
その結果はファイル転送によって部門１から部門３まで
の各サーバに付属するそれぞれのファイルに転送され
る。

【００７１】図１３においては本社サーバ５１によって
作成された全社データは、例えばＮＡＳサーバ５２に送
られ、ＮＡＳサーバ５２内のデータ管理機構によって部
門１から部門３のデータに分割され、ネットワークスト
レージを利用して部門１から部門３の各サーバ５３に提
供される。これによって全社データファイルの作成完了
をトリガとして、各部門のデータへの分割を行うことが
できる。

【００７２】図１３においてＮＡＳサーバ５２に接続さ
れている各サーバの間で、オペレーティングシステム
（ＯＳ）が異なる場合が考えられる。例えば本社サーバ
５１のＯＳはＵＮＩＸ（登録商標）系であり、各部門サ
−バ５３のＯＳはＷｉｎｄｏｗｓＮＴ（登録商標）とな
っているような場合が考えられる。このようにＯＳの異
なる各サーバがＮＡＳサーバ５２を利用するシステム構
成も可能であり、この場合にはＮＡＳサーバ５２に対す
るＵＮＩＸ（登録商標）系サーバと、Ｗｉｎｄｏｗｓ
（登録商標）系サーバとの間ではアクセス方法が異なっ
てくる。

【００７３】図１４は上述のように本社サーバ５１がＵ
ＮＩＸ（登録商標）系であり、部門サーバ５３がＷｉｎ
ｄｏｗｓ（登録商標）系である場合のシステム構成を示
す。ＵＮＩＸ（登録商標）系のサーバは、ネットワーク
・ファイル・システム（ＮＦＳ）プロトコルによってフ
ァイルに対するリモートアクセスを行い、Ｗｉｎｄｏｗ
ｓ（登録商標）系のサーバはコモン・インターネット・
ファイル・システム（ＣＩＦＳ）プロトコルによってフ
ァイルに対するリモートアクセスを行う。そこでＮＡＳ
ヘッドの中にＮＦＳプロトコルに対するサーバとＣＩＦ
Ｓプロトコルに対するサーバとの両方を用意しておく必
要がある。

【００７４】またＵＮＩＸ（登録商標）系のシステムと
Ｗｉｎｄｏｗｓ（登録商標）系システムでは、文字のコ
ードや、データ表現も異なってくる。ＵＮＩＸ（登録商
標）系で扱われるデータの文字コードは拡張ＵＮＩＸ
（登録商標）コード（ＥＵＣ）が標準であり、Ｗｉｎｄ
ｏｗｓ（登録商標）系ではシフトＪＩＳ（ＳＪＩＳ）が
標準として用いられる。

【００７５】図１４のシステムでは、これらの文字コー
ド情報、データ表現情報もスキーマ定義（ポリシーの１
つ）として扱われ、文字コードやデータ表現形式の変換
もあわせて行うことができる。そこでユーザは文字コー
ドやデータ表現の違いを意識することなく、変換結果を
利用することが可能となる。

【００７６】図１５および、図１６は、複数のウェブサ
ーバを利用してコンテンツの提供業務を行うインターネ
ットサービスプロバイダにおいて、ウェブコンテンツに
対するクリックログをコンテンツの提供者単位に集計し
て、その集計結果をそれぞれのコンテンツ提供者に報告
する業務に対して適用した例である。

【００７７】図１５の従来方式では、ウェブサーバ１か
らウェブサーバ３のそれぞれにおいて記録されたクリッ
クログがファイル転送によって収集・分析サーバに与え
られ、アプリケーションプログラムを用いて収集・分析
サーバ内でデータが集計されて全ログデータが得られた
後に、データ振り分けが行われ、コンテンツ１からコン
テンツ４にそれぞれ対応するクリックログの集計結果が
得られ、それぞれのコンテンツ提供者に報告される。

【００７８】図１６においてはネットワークストレージ
形態が用いられ、それぞれのウェブサーバ１からウェブ
サーバ３までのクリックログはＮＡＳサーバ５５内のそ
れぞれのログファイルに格納され、データ管理機構によ
って全ログデータとして集計され、コンテンツ毎に振り
分けが行われて各コンテンツ提供者５６に報告される。

【００７９】以上において本発明のデータ管理機構につ
いてその詳細を説明したが、このデータ管理機構を備え
るシステムは当然一般的なコンピュータシステムとして
構成することが可能である。図１７はそのようなコンピ
ュータシステム、すなわちハードウェア環境の構成ブロ
ック図である。

【００８０】図１７においてコンピュータシステムは中
央処理装置（ＣＰＵ）７０、リードオンリメモリ（ＲＯ
Ｍ）７１、ランダムアクセスメモリ（ＲＡＭ）７２、通
信インタフェース７３、記憶装置７４、入出力装置７
５、可搬型記憶媒体の読取り装置７６、およびこれらの
全てが接続されたバス７７によって構成されている。

【００８１】記憶装置７４としてはハードディスク、磁
気ディスクなど様々な形式の記憶装置を使用することが
でき、このような記憶装置７４、またはＲＯＭ７１に図
６，図７のフローチャートに示されたプログラムや、本
発明の特許請求の範囲の請求項９，１０のプログラムな
どが格納され、そのようなプログラムがＣＰＵ７０によ
って実行されることにより、本実施形態におけるデータ
管理、データとアプリケーションとの独立化などが可能
となる。

【００８２】このようなプログラムは、プログラム提供
者７８側からネットワーク７９、および通信インタフェ
ース７３を介して、例えば記憶装置７４に格納されるこ
とも、また市販され、流通している可搬型記憶媒体８０
に格納され、読取り装置７６にセットされて、ＣＰＵ７
０によって実行されることも可能である。可搬型記憶媒
体８０としてはＣＤ−ＲＯＭ、フレキシブルディスク、
光ディスク、光磁気ディスクなど様々な形式の記憶媒体
を使用することができ、このような記憶媒体に格納され
たプログラムが読取り装置７６によって読取られること
により、本実施形態におけるデータの変換や流通などが
可能となる。

【００８３】

【発明の効果】以上詳細に説明したように本発明によれ
ば、データの変換をデータ管理機構側で管理・実行する
ことにより、業務アプリケーションが動作するシステム
におけるメモリやＣＰＵ資源などが削減され、またデー
タの変換・流通処理と業務アプリケーションとを同期化
することなく、独立して実行することが可能となる。

【００８４】すなわち本発明によれば、業務アプリケー
ションとデータ管理との真の独立化が可能となる。第１
に業務アプリケーションはどのシステムでも実行可能と
なり、業務アプリケーションの配置の自由度が拡大し、
システムの負荷に応じて業務アプリケーションを自由に
配置することが可能となる。

【００８５】第２にデータの変換や流通を意識する必要
がなくなり、業務システム毎に独立した運用が可能とな
る。第３に業務アプリケーション側ではどんなデータが
欲しいかというデータ構造の設計を行い、データ入出力
処理を行うだけであり、データの変換や流通の論理をア
プリケーションに組み込む必要がなくなり、業務アプリ
ケーションの設計が容易となる。

【図面の簡単な説明】

【図１】本発明の原理構成ブロック図である。

【図２】本発明におけるデータ管理の概念の説明図であ
る。

【図３】本発明の実施形態におけるデータ変換動作の基
本的説明図である。

【図４】ファイルに対するポリシーの説明図である。

【図５】データ管理機構のコンポーネント構成を示すブ
ロック図である。

【図６】ユーザからのポリシー操作に対する処理のフロ
ーチャートである。

【図７】データの変換・流通の自動処理のフローチャー
トである。

【図８】データ管理機構が組み込まれたシステムの第１
の構成例である。

【図９】データ管理機構が組み込まれたシステムの第２
の構成例である。

【図１０】データ管理機構が組み込まれたシステムの第
３の構成例である。

【図１１】データ管理機構が組み込まれたシステムの第
４の構成例である。

【図１２】複数の業務サーバの間におけるデータ交換の
従来方式の説明図である。

【図１３】複数の業務サーバの間における本発明の方式
の説明図である。

【図１４】本社サーバ５１がＵＮＩＸ（登録商標）系で
あり、部門サーバ５３がＷｉｎｄｏｗｓ（登録商標）系
である場合のシステム構成図である。

【図１５】コンテンツに対するクリックログの集計結果
の報告業務の従来方式の説明図である。

【図１６】コンテンツに対するクリックログの本発明の
方式の説明図である。

【図１７】本発明を実現するためのプログラムのコンピ
ュータへのローディングを説明する図である。

【図１８】ファイルシステムの従来例の説明図である。

【図１９】データベースマネージメントシステムの従来
例の説明図である。

【符号の説明】

１ データ管理機構 ２ 属性管理手段 ３ トリガ検出手段 ４ データ変換・流通手段 １２，１９ 業務アプリケーション １３，１８ データ １４ トリガ管理部 １５ 変換管理部 １６，２２ ポリシー管理部 １７ 変換部品 ２０ 全体制御部 ２１ トリガ制御部 ２３ ファイルポリシー ２４ 変換処理制御部 ２５ 変換機能部品 ２６ 例外処理部 ２７ 操作インタフェース ３０ ファイルシステム ３１ 従来処理を行うファイルシステム ３２ ミドルウエア ３５ ＮＡＳサーバ ３６，３８ 業務システム ３７ ＮＡＳヘッド ４０ システムコールフック自前監視部

Claims (10)

【特許請求の範囲】
1. 【請求項１】 ファイルシステム内のデータを含むデー
   タの管理を行うデータ管理機構において、 データの変換ポリシーを含むデータ属性を管理する属性
   管理手段と、 データの変換および／または流通を行うべきタイミング
   をトリガとして検出するトリガ検出手段と、 該トリガが検出された時、前記属性管理手段によって管
   理されているデータ属性に対応して、データの変換およ
   び／または流通の処理を行うデータ変換・流通手段とを
   備え、 前記ファイルシステムを管理するオペレーティングシス
   テムによって管理され、アプリケーションプログラムと
   独立に動作することを特徴とするデータの変換・流通を
   行うデータ管理機構。
2. 【請求項２】 前記データ管理機構が、前記ファイルシ
   ステム内に組み込まれることを特徴とする請求項１記載
   のデータの変換・流通を行うデータ管理機構。
3. 【請求項３】 前記データ管理機構が組み込まれたファ
   イルシステムが、アプリケーションプログラムが動作す
   るシステム内に組み込まれることを特徴とする請求項２
   記載のデータの変換・流通を行うデータ管理機構。
4. 【請求項４】 前記データ管理機構が、前記アプリケー
   ションプログラムが動作するシステム上のミドルウエア
   との間での処理の連携のための情報交換を行う操作イン
   タフェース手段を更に備えることを特徴とする請求項１
   記載のデータの変換・流通を行うデータ管理機構。
5. 【請求項５】 前記データ管理機構が、前記アプリケー
   ションプログラムが動作する１つ以上のシステムとの間
   でネットワークを介したストレージの集中管理を実現す
   るネットワークアタッチドストレージシステム内に組み
   込まれることを特徴とする請求項１記載のデータの変換
   ・流通を行うデータ管理装置。
6. 【請求項６】 前記データ管理機構が、前記ネットワー
   クアタッチドストレージシステム上のファイルシステム
   レイヤに実装されることを特徴とする請求項５記載のデ
   ータの変換・流通を行うデータ管理機構。
7. 【請求項７】 前記データ管理機構が、前記ネットワー
   クアタッチドストレージシステム上のアプリケーション
   レイヤに実装されると共に、ファイルのオープン、クロ
   ーズ、リネーム、クリエイト、リムーブ、リンクを含む
   前記データの変換および／または流通を行うためのシス
   テムコールの実行前に呼び出されるシステムコールを監
   視し、該呼び出されるシステムコールの検出を前記トリ
   ガとしてトリガ検出手段に与えるシステムコール監視手
   段を更に備えることを特徴とする請求項５記載のデータ
   の変換・流通を行うデータ管理機構。
8. 【請求項８】 ファイルシステム内のデータを含むデー
   タの管理を行うデータ管理機構を構成し、 データの変換ポリシーを含むデータ属性を管理する属性
   管理手段と、 データの変換および／または流通を行うべきタイミング
   をトリガとして検出するトリガ検出手段と、 該トリガが検出された時、前記属性管理手段によって管
   理されている属性に対応して、データの変換および／ま
   たは流通の処理を行うデータ変換・流通手段とが２つ以
   上のサーバに分散して備えられ、アプリケーションプロ
   グラムと独立に動作することを特徴とするデータ管理シ
   ステム。
9. 【請求項９】 データの変換および／または流通を行う
   データ管理機構を備える計算機によって使用されるプロ
   グラムにおいて、 前記データの変換および／または流通を行うべきタイミ
   ングとしてのトリガを検出する手順と、 該トリガが検出された時、データの変換および／または
   流通のポリシーを参照する手順と、 該ポリシーの内容に対応して、データの変換および／ま
   たは流通の処理を行う手順とを計算機に実行させるため
   のプログラム。
10. 【請求項１０】 データの変換および／または流通を行
    うデータ管理機構を備える計算機によって使用される記
    憶媒体において、 前記データの変換および／または流通を行うべきタイミ
    ングとしてのトリガを検出するステップと、 該トリガが検出された時、データの変換および／または
    流通のポリシーを参照するステップと、 該ポリシーの内容に対応して、データの変換および／ま
    たは流通の処理を行うステップとを計算機に実行させる
    ためのプログラムを格納した計算機読み出し可能可搬型
    記憶媒体。