-
コンポーネント指向と3階層
アーキテクチャー
身近に体験するリモートOLEの可能性
秋月 巌 AKIZUKI, Iwao
首都圏コンピューター技術者協同組合
Visual Basic Enterprise Editionに搭載されるリモートOLEツールは，ネットワーク上に散在するコンポーネントの透過的な使用を実現する． さらにパフォーマンスのチューニングが進めば，ネットワークをデータとプログラムが巨大な融合体にするだけの可能性を持っている． ここでは3階層アーキテクチャにおけるコンポーネントの配置について取り上げてみた．
■ リモートOLE
-
Visual Basic Entarprise Editionには，3階層アーキテクチャーを採用したシステム（3階層システム）を有効に実現するための機能が用意されている．
WindowsNTの次期メジャーバージョンアップモデル“Cairo（開発コード名）”で実現されるはずだったリモートOLEである．
OLEは別プロセスで動作するコンポーネントを制御するテクノロージーであり，リモートOLEは制御範囲を別のネットワークコンピュータにまで拡張することを可能とする（図1・図2）．
図1：OLE |
図2：リモートOLE |
これにより，ネットワーク上に分散したマシンにジョブを割り振り，各マシンにかかる負荷を分散，あるいは集中させることができる．
あるクライアントマシンは，要求を別のマシンに回すことにより，結果だけを受けとることが可能となる．
リモートOLEではないが，このメカニズムをすでに実用的なサービスとして提供しているのが，SQLデータベースサーバーである．
クライアントマシンはメッセージ（SQL）をサーバーに送信することで，結果セットを受けとる．
この基本構造がクライアントサーバーシステムの基礎になっていることは周知の通りである．
ただ，SQLデータベースの場合はクライアントがジョブを依頼するときに，サーバーアプリケーションが起動していることを前提としているのに対し，リモートOLEはオブジェクトの生成を動的におこなうことを前提とする．
マシンの接続されているネットワーク全体が有機的に結合しながら，処理を進める時代がすでに始まっているのである．
-
汎用機によるシステムではホストマシンが全体を統括していたが，各々のマシンパワーに依存するオープンシステムでは，マシンの連携を取る技術の実用化が必要とされるようになったた．
リモートOLEは，本来OSに所属すべきメカニズムであるが，それがいち早く開発ツールであるVisual Basicに同梱されたことに，MicrosoftのVisual Basicに対する期待が感じられる．
Visual Basic Enterprise Editionに付属するリモートOLEツールを使うことで，技術的にはMS ACCESS95や，DELPHI2などOLEオートメーションクライアント機能をサポートした他のツールで開発されたプログラムでも，リモートOLEを利用することができるはずである（実際にはライセンスの制限で，リモートプロシージャを呼び出すことはできないのだが）． Enterprise Editionの拡張機能はVisual Basicに特化した機能ではなく，OSの機能を拡張するためのツールなのである．
実際，リモートOLEツールである「リモート接続マネージャ」などは，現場のVisual Basicデベロッパーが操作する類のツールではない． システム管理者や設計者が，実機上に載せるときに使うべきものである． OLEを使ったシステムの開発はスタンドアローンマシン上で済ませられ，環境の設定を変更するだけで，リモートシステムに移行できる事実には，改めて驚いていただきたい．
ネットワークのパフォーマンスが向上すれば，どのタスクをどのマシンに配置するかは，単にCPUリソースの配分，あるいは運用管理のしやすさというだけの問題である． 開発のプロセスとは完全に切り離され，運用開始後，一旦，決定した配置を変更することも容易である．
-
Visual Basic4.0の雑誌広告で，3階層システムの説明を初めてご覧になった方も多いことだろう．
しかし，あの抽象的かつ舌足らずの説明で3階層アーキテクチャの意味を理解することは難しい．
広告ではリモートOLEを用いて運用するシステムを扱っており，3階層システムが新しい「運用の手段」であるかのように説明されている．
しかし，3階層アーキテクチャとは新しいシステム設計のパラダイムであり，運用形態に限定される方法論ではない．
3階層システムに対して，従来のクライアント／サーバーシステムを2階層システムと呼ぶことができる． SQLデータベースサーバーとクライアントアプリケーションの2つの階層を持つシステムという意味である． この場合も，ポイントは2つの階層によってシステムが構成されているということであり，それぞれのコンポーネントがどのマシンにのっているかは運用の問題にすぎない． 3階層アーキテクチャとはアプリケーションのロジックを，ユーザーサービス，ビジネスサービス，データサービスの3つの階層に分解し，別々のコンポーネントに分担させるものである（図3）． この場合，データサービスは現実的にはSQLデータベースサーバーを指すことが多いが，概念的にはそれに限定されるわけでない． 3階層システムは複合分散処理システムの一種であり，Visual Basicアプリケーションの複合分散処理は，OLEによって実装されるのが一般的である（図4）．
図3：3階層アーキテクチャ |
図4：OLEを使った分散処理モデル |
それぞれのサービスはクライアントに依存せず独立して機能し，各コンポーネントは特化した機能を別々のクライアントに提供することができる．
SQLデータベースが，多種類のクライアントアプリケーションに対応できるのと同様である．
これまでクライアントアプリケーションに搭載されていた機能（それにSQLデータベースのストアドプロシージャの一部）をSQLユーザーサービスとビジネスサービスに分離させるのが3階層アーキテキクチャだといえる．
今までのシステムの開発においても，保守性を上げるために，ビジネスロジックに属する部分を，専用の関数やライブラリに集中させてきた方も多いのではないだろうか．
それらを独自のコンポーネントとして公開し，構築していくのが3階層アーキテクチャだといえばわかりやすいかもしれない．
Microsoftでは，それらのコンポーネントをバインドするのにOLEを用いることを提唱している．
そして，リモートOLEを活用することによって，コンポーネントをネットワーク上に分散させることが可能となる．
あるいは，コンポーネントを一台のコンピュータに集中させることで，アプリケーションを変更した場合のインストール作業を一元して管理したり，逆に分散させることでパフォーマンスのチューニングをおこなえるようになる．
もちろん，そのために綿密な運用計画と，安定したネットワークの保守が要求されるのは当然であるが．
-
サービスモデルは3階層アーキテクチャの各階層の役割を表し，各サービスは共通の目的をサポートするコンポーネントによって提供される．
3階層アーキテクチャのシステムでは次の3つのサービスによって構成されている．
サービスモデルの構成
1. ユーザーサービス
- データの入出力など，インターフェイス部分に関する制御を担当する．プレゼンテーション層とも呼ばれる
- ビジネスロジックを処理するコンポーネントによって提供されるサービス．ユーザーサービスとデータサービスの中間に存在し，ビジネス固有の処理をおこなう
- データの検索や更新など，データに依存した処理を実行する
現在，稼動している代表的な3階層システムはデータベースに連結したWWWシステムである．
ブラウザをユーザーサービス，CGIを通して呼び出されるプログラムをビジネスサービス，バックエンドのデータベースをデータサービスと考えれば，3階層システムにおけるサービスの役割がわかるだろう．
WWWのケースでは，リモート制御はWWWサーバーとCGIの連携によって実現される．
JAVAや，ActiveXの開発環境がととのっていない現状では，WWW上で高度な制御をおこなうことは難しい．
しかし，多数のベンダーがJAVAのビジュアル開発ツールを発表する他，Visual BasicのようなメジャーなツールがWWWへの対応を表明している．
いずれクライアントサーバーの主戦場は，情報系のシステムを中心にイントラネットへと移行するはずである．
そうなると3階層アーキテクチャはコンピュータシステムの標準的なスタイルになるだろう．
3階層システムではそれぞれのサービスは，他のサービスの要求により呼び出される．
コンポーネントはサービスの要求や提供をOLEなどのインターフェイス規約に従ってやりとりする．
図5 コンポーネントの配置（アプリケーションパーティション） |
モデル1：モデル1は典型的な3階層システムのコンポーネント配置図である．
それぞれのコンポーネントは専用のコンピュータを与えられている．
コンポーネント間の通信はすべてネットワーク上のやりとりであり，独立性はもっとも高い．
アプリケーションサーバーに高速のマシンを使うことにより，クライアントのメモリー不足やマシンパワーを補うことも可能である．
ただ，ネットワークやOLEのオーバーヘッド増加の影響を全コンポーネント間で受けるので，総体的にパフォーマンスは不利になる．
モデル2：モデル2はビジネスサービスをデータサービスのマシンに搭載する方法である．
この方法はデータとビジネスサービスが同一のコンピュータ上にあるため，ビジネスサービスが大量のデータ要求をするようなケースで，ネットワークトラフィックを軽減できる．
ビジネスロジックによって，大量のトランザクションを実行しなければいけないようなときに有効だろう．
このような処理は従来データベースサーバーのストアドプロシージャでおこなってきた．
しかし，ストアドプロシージャを用いると移植性が低くなる上，習得のために改めて別の言語を学習する必要があった．
これがVisual Basicで一元的に開発できるようになったメリットは大きい．
また，ビジネスサービスシステムのバ―ジョン管理をサーバー側でおこなえることも利点である．
欠点としてはデータベースサーバーに負荷がかかるような使用状況下だと，データベースのパフォーマンスが劣化することである．
また，ビジネスサービスのために，Excelのようなサイズの大きなアプリケーションがいくつも起動すると，データベースがキャッシングするためのメモリーが確保できなくなることも考えられる．
モデル3：モデル3は普通のクライアントサーバーシステムのクライアントサイドを，3階層アーキテクチャで設計したものである．
マシン状況がよくなった今日，この方法のようにクライアントマシンに負荷を分散する方が有利な場合が少なくない．
この方法は3階層システムの運用上のメリットは受けられないが，コンポーネント指向特有の保守性の高さは維持している．
また，システムの運用形態が変更になったとき， 容易にアプリケーションサーバーにビジネスサービスを移植できる．
結局，どのモデルを選択するにせよ，実際に運用してから各コンポーネントの配置を変更できる点がOLEを用いた複合分散処理の強みである．
この融通性は，実際に運用したときのパフォーマンスを予測しにくいオープンシステムでは大きな意味を持っている．
-
現時点ではまだ，リモートOLEを採用した3階層システムの実用性は高くない．
問題の一つはオーバーヘッドの問題であり，もう一つは安定性の問題である．
現在のネットワークパフォーマンスや，OLE自身のオーバーヘッドなどを考えると，3階層アーキテクチャを採用することによって，パフォーマンスが向上するとは考えにくい．
データと切り離されているビジネスロジックは，他のコンポーネントとのデータのやり取りを必要とするため，そこにオーバーヘッドが生じるからである．
ビジネスロジックモデルを専用のサーバーマシンに集中して配置し，アプリケーションサーバーとして利用する運用形態をとれば，サーバーマシンとクライアントマシンの性能やメモリーの差が大きい場合はクライアント側からみてパフォーマンスの向上がはかれる． しかし，その場合もアプリケーションサーバー処理が集中するようなケースでは，どれだけサービスが追従できるかはネットワークやサーバーの設定次第である．
結局，現実的なメリットは保守性の向上だけということになる． しかし，すでに可能な範囲で3階層アーキテクチャのシステムを導入すべき時期はきている． それは，3階層アーキテクチャが，これからのシステム開発や，運用の形態を変えていく可能性があるからである． それはコンポーネント指向の未来であるといってもいい．
従来の“SE-プログラマ”というトップダウン式の開発形態は，コンポーネントビルダとコンポーネントアセンブラという並列の開発へと変化していく（図6・図7）． 汎用機やオフコンの設計手法をそのまま踏襲しているソフトハウスが，Visual BasicなどのRADツールの特性を考えずにオープンシステムの開発を手がけ，手痛い目にあった例は多い． 今まで一線にいたプログラマーが管理に回され，直接手がけたことのないツールを，プロジェクトで扱わなくてはならないのも原因の一つである． しかも，パソコンと汎用機では背景にあるカルチャーが違うので，余計に戸惑うことになる．
3階層アーキテクチャーの導入は，単にコンピュータの負荷を分散させるためだけのものでなく，プロジェクトの運営から変えていくことを要求する． 導入できる部分から，徹底したコンポーネント指向を導入していくことが，今後，システムへの要求がダイナミックに変化していく時代に対応する，おそらく唯一の方法である．
図6：従来の開発の流れ |
図7：分散オブジェクトシステム開発の図式 |
-
コンポーネント指向開発の時代になると，システム設計者の役割も変わってくる．
顧客の要望をシステム化するロジックを組み立てるのは，今までと同様である．
しかし，各処理をどのコンポーネントに配置するか，あるいは，どのようにクラス設計をするかで作り込みに大きな差が生じる．
優れたコンポーネント設計を持つプログラムは保守性に優れ，保守性の高いプログラムは堅牢である． どこに障害発生の原因が潜んでいるか予測が難しいオープンシステムでは，システムの堅牢性を高めることは特に重要な課題となる．
コンポーネントはExcelのように既存のものを使用する場合もあれば，Visual Basicや，C言語などで，必要なものを作成するケースもある． あるいは，Excelのワークシートのように，既存のコンポーネントに，プログラミングされたオブジェクトを加えたものを用いる例も考えられる． 大切なのは，それぞれに適切なリソースを確保することである． 一般的にコンポーネントは複雑なものほど，障害の回避が困難となるため，設計者はコンポーネントのふるまいについて，十分に把握しておく必要がある．
言語やツールの習得が容易になった今日，設計者に要求される能力とは，各ツールやコンポーネントの特性を熟知した上で，見積もりや提案ができることである． もっとも，バージョンアップのサイクルが短く，その度にいくつかのバグがフィックスされ，新しいバグが創造されている今日の状況では，それらを正確に把握することは難しい．
-
3階層アーキテクチャは，データサービスとユーザーサービスの中間にビジネスサービスを配置する．
これはデータベースのデータを直接ユーザーに反映させずに，ビジネスロジックによって，隠蔽するアーキテクチャである．
このアーキテクチャに準拠するには，ユーザーサービスを受け持つクライアントはユーザーインターフェイス処理に徹する必要がある． そのためにはクライアントマシンはOLEコンテナ機能だけを実装し，そこにビジネスサービスが提供するOLEオブジェクトを埋め込むのが，もっともスマートな解決法だろう． だが，Visual Basicでは埋め込みOLEサーバーを作成することはできない（OLEオートメーションサーバーは可能）． 現在のところ埋め込みのOLEサーバーを作成可能な開発ツールは数少なく，C++のような開発効率の低い言語でしか作成できない． やはり，開発はVisual Basicのような生産性の高いツールでおこないたい． そうなるとクライアントのインターフェースはVisual Basicで作成し，OLEオートメーションでビジネスサービスを受けるという形態が妥当なスタイルということになる また，Visual Basicでデータベースアプリケーションを作成するには，DBグリッドやDBリストなど，データ連結コントロールを使うのが生産性のうえで有利である． しかし，これらはデータベースの内容を直接反映させるため，中間に別のコンポーネントが介在するのを認めない． 無論，データ関連のコントロールやオブジェクトをコントロールに連結せずにコーディングすることはできるが，それではVisual BasicのRADツールとしての一面を台無しにすることになる．
結局，Visual Basicによる現実的な3階層アーキテクチャは図8のようなものになるだろう． このスタイルでは階層という特徴は薄れるが，それぞれのサービスを別々のコンポーネントが担当するという構成は同様である． かえって，ユーザーサービスとデータサービスがお互いのサーバーとなることができるという点で，自由度が大きい長所を持つ．
図8：Visual Basicによる現実的な３階層モデル |
-
さて，例示だけではものたりないという読者のために，本誌前号で紹介した給料管理システム（図9）を用いて，リモート3階層システムの実験をおこなってみよう．
リモートOLEの動作やパフォーマンス（の低さ），設定の容易さが理解できるだろう．
この実験をおこなうためにはネットワーク上に接続された2台のコンピュータ（ Windows NTかWindows95）と，MS Excel（ver5.0かver7.0 ）が必要である．
図9：給料管理システムのサービス構成
図9が給料管理システムのサービス構成である．
ユーザーサービスはVisual Basicプログラム，データサービスはJETデータベースエンジン，ビジネスロジックはExcelの「Kyuryo」ワークシートがそれぞれ受け持つ．
この例ではデータサービスにVisual Basicの内蔵エンジンを使っているが，データサービス要求にはSQLを使用しているので，エンジンをSQLデータベースサーバーに換装することは容易である．
プログラムの詳細は前号を参照してもらうとして，重要なのはリスト1のメインフォームのLoadイベントプロシージャである．
リスト1：Form_Loadプロシージャ
Private Sub Form_Load()
Dim pathname As String
'アプリケーションのあるディレクトリ名を取得
pathname = App.Path
DATA_Jugyoin.DatabaseName = pathname + "\Admin.mdb"
DATA_kyuryo.DatabaseName = pathname + "\Admin.mdb"
'Excelのアプリケーションオブシェクトを作成
Set excelapp = CreateObject("excel.application")
'Excelの「給料計算表」ワークシートをオープン
excelapp.Workbooks.Open filename:= "kyuryo.XLS"
End Sub
|
標準の設定では上のコードを実行することで，ローカルにあるExcelを起動する．
リモートOLEを実現するための環境設定をおこなうことで，プログラムのコードの変更をすることなく，Excelをリモートマシンで起動することができる．
その設定をおこなうツールがリモート接続マネージャである．
また，リモートOLEを使用するためには，OLEサーバーマシンにオートメーションマネージャを予め起動しておく必要がある．
-
アプリケーションサーバーマシンでは，Excelが正常にインストールされていれば，オートメーションマネージャを起動しておくだけで，特に設定をおこなう必要はない．
オートメーションマネージャがデスクトップに現れてから，タスクバーにおさまったら，起動は終了である(図10）．
タスクバーをクリックして，図10に示したようなフォームが現れればOLEの接続待ちであることを確認できる．
アプリケーションサーバーマシンとして，恒常的に使用するならばスタートアップグループにアイコンを登録しておくべきだろう．
将来的にはOSの起動時に読み込まれるものになるはずである．
図10：オートメーションマネージャの起動方法（サーバー側）
|
オートメーションマネージャが起動したら，次はクライアントの設定である（図11）．
図11：リモート接続マネージャの設定方法（クライアント側）
3. オプションボタンより「すべてのクラスのリモート作成を許可」を選択する． （NTをサーバーに使う場合，一旦，「ACLに基づいてリモート作成を許可」を選択し，アクセス権を設定した後で，「すべてのクラスのリモート作成を許可」を選択する必要がある）
5. 「登録」メニューより，「リモート」を選択する（この操作はメニューからしかおこなえない）． 6. ネットワークアドレスに，アプリケーションサーバーとなるマシン名を入力する． 7. ネットワークプロトコルに使用しているプロトコルを入力する． 8. 「更新」ボタンをクリックする． |
サーバー，クライアント両機の設定が正しく完了していれば，クライアントマシンから「給料管理」システムを起動するとサーバーマシンでExcelが起動するはずである．
このアプリケーションはExcelのワークシートを直接ユーザーが操作することはないため，非表示のままExcelはオープンする．
メインフォームにある「Excelを表示」ボタンをクリックすることで，リモートマシンにExcelのワークシートが現れる．
給料計算のビジネスロジックは全て，この表が受け持っている．
アプリケーションの動作は，かなり高速なマシンでも緩慢なはずである．
リモート接続マネージャの設定をローカルに戻して動作を確認すれば，リモートOLEのオーバーヘッドの大きさを実感できるだろう．
ただ，アプリケーションをインストールさえしてあれば，このようにビジネスモデルの再配置を，簡単にリモート接続マネージャによっておこなえることに注目すべきだろう．
-
コンポーネント指向は，構造化プログラミングの発展したものと考えることができる．
アプリケーションを作成するための部品を作成し，それらを組み合わせていくことで，システムを構築するため，要求されているシステムの各要素をいかに分割していくかがポイントとなる．
オブジェクト指向開発のためのクラス設計との決定的な違いは，コンポーネントには継承がないことである．
コンポーネントの分割は横割りであるのに加え，クラス設計には各クラス階層の決定という縦割りの作業が必要となる．
これは経験の少ない設計者にとってはけっこうな負担であり，また，コードを再利用するためには開発者間で緻密なドキュメントをやりとりする必要がある．
それに比べればコンポーネント指向開発はシンプルである． 各コンポーネントの役割は具象的であり，直感的である． 大体，オブジェクト指向にある抽象クラスみたいな，そのままでは何にも使えないようなものはない． ただ，今回のサンプルプログラムで用いたExclelのように，ブログラミング可能なコンポーネントを用いた場合，Excelを抽象的な親クラス，Excelとワークシートをセットで，継承された子クラスととらえることも可能である． 複数のワークシートを使うことでExcelを再利用するわけである．
効率的なコンポーネントを作成するためには，ユーザーの要望を画面単位で分割するばかりでなく，ジョブの単位で分けることが大切である．
例えば，「納品」「仕入れ」「売り上げ」「支払い」「経費」といった業務の動きを，それぞれの対応するコンポーネントに割りあてる． おそらく「仕入れ」コンポーネントは「支払い」コンポーネントを呼び出すことになるだろう． また「経費」コンポーネントも「支払い」コンポーネントを呼び出すはずである． そうなると「支払い」コンポーネントは，どれかのコンポーネントに依存せずに汎用的である必要がでてくる． コンポーネントを汎用的に利用するには，コンポーネントの入出力を明快にしておかないと，複数のコンポーネントから参照するのは難しくなる．
今あげた例は，すべてビジネスサービスに属するコンポーネントである． これらのロジックが他のサービスと協調して動作することで，3階層システムを構築する． 実際には現在の環境では，これほど明快に3階層を分離させることは不可能である． マシンやOS，開発ツール，それに技術者といった条件が整っていくことで，3階層システムはより具体的な形をもっていくだろう．
-
リモートOLEの現時点での実用性はともかく，3階層アーキテクチャが注目すべき概念であることは確かである．
活用法は無限であり，巧みに設計されていれば，システムは美しく堅牢なものになるだろう．
今まで登場した新技術がそうであったように，パフォーマンスの問題は時が解決してくれるはずだ．
つまり，時が解決するまで待つ，という選択肢もあるわけである．
しかし，新しいもの好きの技術者ならば，（オブジェクト指向がそうであるように）3階層アーキテクチャの誘惑から逃れることは難しいに違いない．
誰かが，どこかのシステムを実験台にしながら，新しいパラダイムは普及していくのである．
技術者にとって，まだ安定していないリモートOLEを使ったシステム構築を成功させることは，名誉なことであるに違いない． しかし，当然ともいえるリスクは払わなければならない．
選択は迫られている． しかし，日進月歩のこの世界で選択を迫られなかった時期があっただろうか． 新しいものに飛び乗った者と，古いものに固執した者，どちらがより多くの利を得たのか，これを機会に考えなおしてみるのもいいかもしれない．
|
サンプルプログラムについて
添付のプログラムは本誌Vol.6にて添付したものの再録です．
Visual Basic4.0をインストールしてある環境ならば，CDROMより直接Kyuryo.EXEを実行することが可能です．
他に正常にインストールされたMicrosoft Excelが必要となります． |
Visual Basicライブラリ | Visual Basicコースホームページ
int21 ホームページ | PCDN ホームページ
