Web Structured Data Management System

このシステムは、Perl 5をベースとしたプロトタイプとして サーバ開発を進めている。 次期メジャーバージョンにおいては、 すべてのコードをJavaに移植する予定である。

以下、Perl 5によるプロトタイプシステムをversion 1, Javaによる次期システムをversion 2とする。

• version 1 システム概要：httpサーバとデータベースシステムの統合
  • スリム化・高速化の実現：
    一般に、Webクライアントをユーザーインターフェイスとして用いる データベースアプリケーションは、httpd起動され、 RDBMSと連携して動作するCGIプログラムとして記述されることが多い。 しかし、そもそもCGIとはオーバーヘッドの大きな処理であり、 httpdやDBMSなど複数のネットワークサーバを用いる構成も冗長な ものであるため、全体として応答性の悪いシステムとなる場合が 多々ある。

    そこで今回は、httpdとcgiとDBMSを単一のプログラムとして統合した。 これによりシステム構成の冗長性が解消でき、 応答性の飛躍的な向上が実現できた。

  • 導入コスト・リスクの軽減：
    CGIを利用するシステムは、管理者に対して Webサーバなど他のシステムの管理・設定のスキルを要求する。 だが、このversion 1システムは、完全に独立したプログラムであるため、 基本的にWebサーバ管理のスキルを要求しない。 またCGIなど設定次第でサーバ側のセキュリティホールになってしまったり、 httpdバージョンアップなどの際の再設定の手間をかけることもない。 このため、CGIスクリプトの導入と比べて、リスクやコストが少ないため、 運用面での心配がより少ないものであると言える。 また、一般ユーザープロセスとして、 独立したネットワークサーバとして起動できるため、 動作権限やセキュリティについてOSの機能を利用して 運用上の制限を付与することができる。

  • 対応クライアントソフトの多様化：
    version 1システムは、 ブラウザ側では単純なHTML2.0の処理をさせるため、JavaやActiveX を利用する必要がない。そのため、旧バージョンのものも含む、 大多数のWebブラウザをクライアントとして利用できる。 また、「枯れた」技術であるHTTP1.0、HTML2.0は、応用範囲が広く、 トラブルの際の原因特定がしやすいため、安心感がある。

  • 実行環境となるOSがUNIXであること：
    当システムはUNIX(PC-UNIXでも可)上での実行を前提としている。 このため、当システムの運用のためには、その動作環境である UNIXマシンに対して、日常的なシステムメンテナンスを行うことを 必要とする。一般に、UNIXの管理は、WindowsNTでの管理に比べて ハードルが高いと考えられており、ある程度熟練した管理者の確保が 必要条件となる。
    なお、WindowsNT上での当システムの動作は、 OSの構造上、機能が著しく制限されるため、基本的に対応不可能である。

  • マシン・ソフトウェアが低価格であること：
    version 1システムのためのOSなど、動作に必要なソフトウェアは 全てフリーのものを採用できる。この場合、 PC-UNIXを動作させるマシンを新規に導入するのであれば、 動作をさせるのに十分な環境を構築するために必要なハードの 価格は、合計で20〜30万円程度である。 (UNIXシステムの保守管理に要するコストは含めない場合)
    仮に、WindowsNT用に当システムを移植したとする場合、 同程度のパフォーマンスを得るために必要なハードウェアの価格と OSのライセンス代の合計は、およそ40万円〜60万円であり、 およそ半額で済む。 (移植作業の新規の工賃は含めない場合)
    また、version 2の実行環境であるSUN Ultra1とObjectStoreなどを 新規に購入する場合の合計は150〜400万円であり、 およそ10分の1で済む。

• version 2 システム概要：Java関連技術の採用による将来性の確保
  • Servletへの移植：
    version 2システムは、JavaSoft社のJavaServer上で動作する servletの形態で開発することを予定する。 servlet技術の利用により、サーバでの設定作業の多くが不要となり、 将来の移植の手間もなく、CORBAなど分散コンピューティング環境への 移行にも柔軟に対応できることが期待される。 また、業界標準となるJava言語を用いることで、 将来のプログラムのメンテナンスなどの負担を軽減することが期待される。
    ただし、JavaServerやservletの速度・応答性については未知数であり、 version 1を単純に移植しただけのシステムであっても、 version 1の速度に劣ってしまうという可能性がある。 また、version 2への移植作業は新規・別工程のものであり、 現時点で準完成段階にあるversion 1を引き続き開発する場合に比べると、 新たなコストやリスクが発生するかもしれない。

  • Appletへの移植：
    version 2システムのクライアント側の機能の一部は、 JavaAppletやJavaScriptを用いて実装することを予定している。 これは、よりインタラクティブで グラフィカルな操作環境を実現させるためのものである。 反面、この機能を用いる場合には、旧バージョンのブラウザでは、 JavaAppletやJavaScriptが実行できなかったり、 不安定になってしまうなどのデメリットが懸念される。 このリスクやコストがどの程度になるかは 世間でのJava環境の開発状況がどれだけ進展するかにかかっている。
    特に、Javaの安定した日本語実行環境が実現する次期は早くても 今年(1997年)の第4四半期に出荷されるバージョンのソフトウェアによる と言われており、この時期にクライアントソフトウェアの新バージョンを 一斉導入することが現実的かどうかを検討しておく必要がある。

  • ObjectStoreの利用：
    データベースシステムとして利用を想定しているソフトウェア、 ObjectDesign社のObjectStoreは、ライセンス料が高額(100〜300万)である。 とはいえ、 この簡易版でありフリーで利用できるObjectStorePSEを利用することで、 当面のコスト発生を回避できる。ObjectStoreとPSEはAPI互換であるため、 もしもObjectStoreを将来購入することが出来るのであれば、 開発したプログラムを、変更なしに継続的に運用できる。 このように、将来本格的な運用を行うという選択肢があるのであれば、 ObjectStore関連の技術を用いて開発をしておくことには大いに意義がある。

  • 実行環境となるOSがUNIXであること：
    version 1と同様、運用環境となるOSはUNIXである。 特にJavaServerやObjectStoreを利用する都合上から、 SUN microsystems社のSolaris2.5.1以上を採用したい。 WindowsNTによる運用は対象外とする。

  • マシン・ソフトウェアが高価格であること：
    version 2の環境は、JavaServerやObjectStoreをストレス無く 実行できる環境としては、SUN Ultra1以上が理想的である。 これを新規に購入する場合の費用はおよそ150〜400万円であるが、 これだけのハードウェアが用意できれば、他の多くの用途でも サーバマシンとして運用が可能であるだろう。この場合の 投資コストは、CONEプロジェクト以外からも回収できると思われる。

• オブジェクト指向データベースとしての性質
  • オブジェクト指向パラダイムの採用：
    一般にリレーショナルデータベースは、 内部スキーマの設計や修正、また理解しやすく表示するための アプリケーション実装が非常に困難である。 そこで、オブジェクト指向パラダイムによるデータ構造を 当データベース開発上の要件とした。

  • version 1とversion 2でのデータ構造の共通性の確保：
    当システムは将来的にはJava言語への移植を予定している。 そのため、データベース上で取り扱うデータ構造については、 Java言語の仕様にできる限り準拠した形で実装した。
    version 2では、ObjectStore for Javaの仕様に従って Javaのクラスファイルと、オブジェクトをシリアライズしたものの セットによって永続性を実現する予定である。
    この完成形をふまえ、version 1からversion 2へのへの スムースな移行を重視するために、 version 1サーバは、 内部のオブジェクト指向データベースにデータ構造(クラス定義)を 与えるための方式として、Java言語のソースファイルを読み込み、 その構文解析を行うことで、データベースの構造を設定する 機能を実現した。
    また、データベーススキーマ実装上の必要な項目の設定については、 Java言語ソースファイル中のコメント内部で、 javadoc用のパラメータ記述形式として標準化されている構文を応用した。

  • オブジェクト実装上の内部表現について：
    Perl5は、オブジェクト指向的な利用を可能としていると言われるが、 実際には「型」が存在しない言語体系であるため、 Java言語のエミュレーションを行うには適さない言語である。 そこでversion 1開発においては、Perl5のオブジェクト指向的な 機能は一切利用せず、連想配列とオブジェクトIDをキーワードとし自前の ポインタを利用してオブジェクトの参照構造を実装した。
    インスタンスの情報は、gdbmを利用したデータファイルを利用 する方式と、tab区切りのテキストファイルとして入出力する 方式の2通りを装備した。後者のテキスト形式データを利用することで、 ExcelやファイルメーカーProなどの外部の表計算・データベースソフト によってデータを融通する方策を確保した。

  • version 1におけるデータ永続化：
    データストレージングシステムとして、version 1ではgdbmを利用している。 これにより、データのキャッシングによる高速化とファイルへの自動的な 書き込みを両立させることができた。 また、サーバは、システムコールSIGINTをキャッチして同期化 (メモリ内のデータのファイルへの書き出し)・終了を行う機能を持つため、 サーバ停止の際などに、手作業による特別な終了処理の必要がない。 このように、システム保守の手間を最大限省くように配慮している。

  • version 2におけるデータ永続化：
    データストレージングシステムとして、version 2では、 オブジェクト指向データベースであるObjectDesign社のObjectStoreの利用 を想定している。これにより、プログラム側ではデータベースの存在を 意識しない透過的なデータ利用が可能となる。また、データベースとしての 並列動作、障害復旧、複雑なトランザクション処理、デッドロック検知などが 利用できるようになる。

• 今後のシステム開発上の制約と課題
  • システム異常終了時の対応：
    version 1においては、下部スキーマとしてのデータベースシステムに gdbmを利用し、SIGINTをキャッチして同期化・終了を行うことで データ構造の永続化を実現している。反面、この仕組みの性質上、 プロセスがSIGINTを呼ばずに異常終了した場合についての データの保証がされていない。このため、cronなどの別プロセスから 定期的にシステムコールを打ち、データファイルのバックアップを行うなどの 対応が必要である。

  • アクセス権限について：
    データベースへのアクセス権限について、 システムにloginする際の「入口」におけるチェックのみを行っている。 個々のオブジェクトの読み出しや新規作成・更新についての権限 チェックのコードは未実装である。 ユーザー、グループ、時間などのリソースから アクセス権限をチェックするSecurityManagerの機能を 次期バージョンで実装することを予定する。

  • オブジェクトの選択インターフェイス：
    静的なHTMLをユーザーインターフェイスとして利用しているため、 オブジェクトの選択などの際の選択肢の表示に工夫がない。 このため、選択肢の候補となるオブジェクトの表示範囲や表示順序を インタラクティブに指定できず、表示される選択肢の総数が膨大になるなど、 操作面での問題が発生することが予想される。 これは次期バージョンでappletやHTML3.0による ダイナミックインターフェイス生成の機能を活用することを検討する。

  • データの内部スキーマ表現：
    version 1システムが利用するデータの内部スキーマ表現は、 独自フォーマットによるもののため一般性に乏しく、他システムとの共有の 必要が生じた際には、フォーマット変換作業を行う必要がある。 このようなフォーマット変換作業は当システム内部に関する 知識を必要とするため、一般的でない。
    このような懸念から、 データの内部スキーマとして、 独自システムではなくRDBMSを利用することによって、 少なくともデータの利用・編集手続きの業界標準言語であるSQLを 利用できるようにするという案も考えられる。 しかし、RDBMSの利用は、 オブジェクト指向によって設計されたデータベースを格納する対象としては、 そのデータ表現力に限界があり、変換工程が煩雑になるなど、 開発に困難をきたすことが想定される。 そこでversion 2システムでは、ObjectDesign社のObjectStoreの導入により、 オブジェクト指向言語から透過的なデータベース利用が可能な環境を 実現することが、開発・運用の負担軽減と、 データの他システムとの共有・再利用を実現できると考えられる。

  • Secured HTTPへの移行：
    version 1のサーバではSSLなどの暗号化httpは利用していない。 またその実装は、事実上不可能であると言って良い。 このためイントラネット外に渡る利用にはリスクが伴うことを 注意しておく必要がある。 これは、version2システムにおいてJavaSoft社のJavaServer上の servletとして実装する際に、暗号化に関する実装の余地が生じるので、 この段階で検討する。

  • マルチスレッド化、高速化のためのインプリメント：
    version 1では、データベースは単一のプロセス構成であり、 フォークによるアクセスの並列化など、 「高速化のためのインプリメント」をしていない。 これはversion 2でJavaによるマルチスレッド化により、 実装の余地が生じる。

  • オブジェクト構造の表現の不十分さ：
    定義・格納される個々のオブジェクトは クラス階層を持たない、メソッド定義がされないなど、 「オブジェクト指向」を冠するには不十分なものである。 しかしこれは、version 2において、プログラムをJava言語によって 記述し直すことで自動的に解消することが予想される。 version 1においてこの問題に対処することは不可能ではないが、 処理が複雑になることから、プログラムやデータの保守性を損なう 結果となることが懸念される。

  • トランザクション概念の不備：
    複数のhttpセッションにわたるトランザクション処理の概念がないため、 将来、より複雑な登録処理を行う際の対応をするための仕組みを持たない。 これは次期バージョンでJavaオブジェクトのlock機能(synchronize)を 利用することで実装できる。 シングルプロセスシステムであるversion 1においてこの問題に対処することは、 システムのパフォーマンスを損なったりデッドロックに陥る危険を生じるという ソフトウェア工学上の問題に直面するため、コストが大きい。

  • 値域・定義域などのチェックシステムの不備：
    データベース内オブジェクトの各要素について、値の定義域制限や、 not nullの指定などができていない。これは version 2においてJavaオブジェクトのコンストラクタや メソッドの部分の例外処理として実装を行うことで対応したい。 version 1においてこの問題に対処することは、 「データベースシステム自体のプログラムと、データ構造の分離」という データベースシステムの開発と運用における大原則に抵触してしまうので、 実装は困難である。