連載
スキルアップのための分散オブジェクト入門
| 日本アイオナテクノロジーズ 主席 コンサルタント 小野沢 博文 2002/3/19 |
本連載について |
 |
分散オブジェクトとは |
|
今回の内容
|
 分散オブジェクトとはなぜ分散オブジェクト技術が必要なのか(1)システムの機能分割と分散配置(2)コンポーネント化と再利用(3)標準技術の採用と相互運用性
|
今日、情報システムはますます肥大化し複雑化する方向にあります。ただでさえ複雑なシステムが有機的に結び付き、さらに巨大な複合システムを構成しています。このような複雑なシステムの開発コストを最小化し、しかも後々の保守を容易にするためには、
（1）システムの機能分割と分散配置
（2）コンポーネント化と再利用
（3）標準技術の採用と相互運用性
などを実現することが重要になります。そして、これらのすべてに密接に関係するのが本連載のテーマである分散オブジェクト技術なのです。
分散オブジェクトには、CORBA（Common Object Request Broker）、JavaRMI（Java Remote Method Invocation）とEJB（Enterprise JavaBeans）、COM+（Component Object Model Plus）、HORBなどの代表的な技術があります。これらは、見かけ上は違うにもかかわらず、その仕組みや考え方において多くの共通点を持っています。本連載では、第1回でなぜ分散オブジェクト技術が必要なのかを、第2回ですべての分散オブジェクト技術に共通する仕組みについて解説します。そして、第3回以降で、上記の中から毎回1つの分散オブジェクト技術を取り上げて、それぞれの技術に固有な点を解説していくことにします。最終回では、分散オブジェクト技術と付き合っていくための実用的なTIPSをまとめて紹介します。
|
なぜ分散オブジェクト技術が必要なのか |
分散オブジェクト技術でなければシステムの複雑化や肥大化に対処できない、というわけではもちろんありません。分散オブジェクト技術の基盤上に独自にアプリケーションを構築するよりも、ERPやCRMのパッケージ製品をうまく使いこなすことで、多くの場合、それぞれの分野のニーズに合ったシステムを安価で短期間のうちに構築することが可能です。しかし、多くの組織では、顧客管理システム、在庫システム、財務システムなどの各システムが互いに独立に存在するわけではありません。また、すべてのニーズがパッケージ製品で補えるわけでもありません。このような場合、異なるパッケージ製品や既存システムを相互に接続したり、パッケージ製品では補えない部分を独自開発するための基盤を提供するのが分散オブジェクト技術なのです。実際に、代表的なパッケージ製品のいくつかは、機能拡張や外部接続のためにCORBAやCOM+などの分散オブジェクト技術をサポートしています。
以下では、冒頭に挙げた3つのキーワード「（1）システムの機能分割と分散配置」「（2）コンポーネント化と再利用」および「（3）標準技術の採用と相互運用性」を中心に、分散オブジェクト技術の必要性を解説していきます。
|
（1）システムの機能分割と分散配置 |
肥大化する一方の情報システムに対処する1つの方法が、システムの機能分割です。システム全体を一枚岩で作成してしまうと、1カ所に変更を加えた場合、その影響が至るところに現れてしまいます。これを避けるため、全体のシステムを独立性の高いいくつかの機能単位に分割して開発する手法が一般的にとられます。プレゼンテーション層、ビジネス・ロジック層、データ層、といった3層システムがこの代表的な例です。そして、それぞれの機能単位を最適なマシンに分散させて配置することになります。例えば、クライアントとのインタラクションやセッション管理はフロントエンドのマシンに行わせ、ビジネス・ロジックの実行はより高性能なサーバ・マシンに行わせる、といった具合です。
ここで重要になるのは、アプリケーションにお互いの相手の物理的な位置を意識させずに通信させることです。これを位置の透過性と呼んでいます。また、セキュリティ・メカニズム、マシン・アーキテクチャやプログラミング言語の違いをアプリケーションに意識させないようにすることも重要です。これらによりメンテナンス性や移植性が格段に向上します。技術的な仕組みは次回以降で説明しますが、分散オブジェクト技術を利用することにより、このような位置の透過性や実装の詳細の隠ぺいを、自然な形で実現することができます。
 |
| 図1 分散オブジェクト技術はネットワークや実装の詳細を隠ぺいしてくれる |
分散オブジェクト技術を使うことで、ネットワーク・プログラミングやセキュリティ・メカニズムなどの詳細を気にせずに、あたかもローカルのJavaやC++のオブジェクトのメソッドを呼び出すのと同じ感覚で、リモート・マシンに存在するオブジェクトを呼び出すことが可能になります。
ただし、分散オブジェクト技術を採用したからといって、巨大システムの機能分割が魔法のように成功するわけではありません。当然ながら、ある層への変更がほかの層に及ぼす影響を最小限にするような設計を行う必要があるわけです。
|
（2）コンポーネント化と再利用 |
システム開発においては、そのシステムだけに完全に特有な部分というのは意外と少ないもので、かなりの部分をプロジェクトにまたがって再利用することができます。それは、マクロなところでは、プロジェクト管理の進め方や分析あるいは設計パターンの再利用だったり、よりミクロなところでは、ソース・レベルあるいはバイナリ・レベルでのコードの再利用だったりします。これらの再利用により二度手間を省き、生産性を向上させることができます。
分散オブジェクト技術は、コードの再利用性を向上させるための仕組み、つまりコンポーネント化の仕組みを提供しています。ここで、コンポーネント化を考えるうえで重要な点が２つあります。
１つ目は、利用する側がそのコンポーネントの内部実装を意識しなくてもよいようにするという点です。コンポーネントの内部実装を意識した使い方をしてしまうと、その特定のコンポーネントしか利用できず、同じインターフェイスを提供するさらに優れたコンポーネントが登場しても、交換がきかなくなってしまいます。
 |
TIPS1 インターフェイスと実装の分離
|
|
コンポーネントの内部実装を利用者に意識させないためには、コンポーネントが提供する外部インターフェイスと、それを実現する内部実装を完全に分離するメカニズムが必要になります。そして、コンポーネントを利用する側は、外部インターフェイスだけに従ってプログラミングすることが重要です。こうすることで、同じインターフェイスをサポートするさまざまなコンポーネントを、プラグインとして利用することが可能になります。技術的な詳細は次回説明しますが、分散オブジェクト技術の開発では、通常最初にオブジェクトのインターフェイスを決定し、このインターフェイスに基づいてクライアントとサーバを開発するという手順をとります。これにより、自然にインターフェイスと実装が分離されることになります。 |
|
2つ目は、バイナリ・レベルで（つまりコンパイル済みの）コンポーネントを再利用できるようにすることです。1つの開発プロジェクトや企業の内部に閉じた場合には、ソースコード・レベルでの再利用も可能ですが、コンポーネントの流通をビジネスとして成立させるためには、ソース・コードでの配布は困難です。バイナリ・レベルのコンポーネントを提供し、しかも利用者のさまざまなニーズに応じてカスタマイズできることが必要になります。
| COLUMN 分散オブジェクト技術とコンポーネント COM+では、バイナリ・コンポーネントの流通性を確保するために、クライアントとコンポーネント間のバイナリ・レベルでのインターフェイスを定めています（第5回で詳しく説明する予定です）。EJBでは、コンポーネント（Enterprise Bean）を実装や製品に依存せずにパッケージ化し、アプリケーション・サーバにデプロイすることで、同様にバイナリ・コンポーネントの流通を可能にしています（第4回で詳しく説明する予定です）。 これに対して、CORBAはOSやプログラミング言語に依存しない分散オブジェクト技術で、しかも、バイナリ・レベルではなくインターフェイス・レベル（つまりAPIレベル）で仕様を決めているため、COM+やEJBのように単純にはいきません（このあたりの詳細は第3回に説明します）。OMG（Object Management Group）では、CORBAのコンポーネント・モデルであるCCM（CORBA Component Model）を標準化していますが、これは、プラットフォームを超えたバイナリ・コンポーネントを実現するためというよりは、ソースコード・レベルでのコンポーネント化、あるいは特定のOSプラットフォームやプログラミング言語に依存したバイナリ・コンポーネントを実現するためのものです。 |
|
（3）標準技術の採用と相互運用性 |
分散オブジェクト技術を採用する利点の1つは、これらの技術が標準化されているため、アプリケーションの移植性と相互運用性が保たれるという点です。ただし、一点だけ注意が必要です。移植性を確保するためには、製品の固有機能や固有APIの使用を極力控えなければならない、ということです。この問題については、TIPS2を参照ください。
 |
| 図2 分散オブジェクト技術の移植性 |
|
TIPS2 分散オブジェクト技術の移植性
|
|
ここでは、CORBAを例に説明することにします。こんなことを書くと不安に思われるかもしれませんが、初期のCORBAではアプリケーションの移植性は保証されていませんでした。これは、APIやその振る舞いが細部にわたって具体的に記述されていなかったために、各ベンダが独自の解釈で製品を開発せざるを得なかったからです。このため以前は、あるCORBA製品で開発したアプリケーションを別のCORBA製品に移植するのは、一苦労でした。でも、安心してください。この問題は、1998年のCORBA 2.2で解決され、現在ほとんどのベンダがリリースしている最新の製品では、ほぼ完全な移植性が保証されています。さらに、CORBA 2.2で導入された新仕様は、移植性だけではなく拡張性という点でも大変優れた仕様だったため、その後CORBAは2.3、2.4、2.5、2.6と機能強化を重ねていきますが、基本的には2.2当時のアプリケーションの移植性を守りながら、新機能を順次追加することに成功しています。これは、バージョン2.2以降のCORBA仕様は十分に成熟しており、その上で安心してアプリケーションを開発できることを意味しています。 さて、このTIPSの主題に入ります。現在、多くのCORBA製品では、標準仕様で不足している部分を各ベンダが独自に拡張しています。例えば、負荷分散やフェールオーバーを実現するためのクラスタリング機能、あるいは標準のセキュリティ・サービスを補完するための機能などがこれに当たります。こうした場合、各ベンダは、APIの追加ではなくコンフィグレーションでこれらの設定が行えるように配慮し、移植性への影響を最小限にとどめる努力を行います（少なくとも筆者はそうすべきだと考えています）。しかし、ときには、これらの機能を使うためにベンダの独自APIを使わざるを得ない事態が発生してしまいます。この場合、ベンダの独自機能を使うか、あるいは移植性を優先するかはユーザーの判断にゆだねられることになります。また、仮に独自機能を使用する場合でも、ベンダの独自APIの使用を特定のソース・ファイルに局所化しておくことが重要です。これは、必ずしも別のベンダ製品に移行できる可能性を残しておくというだけではなく、製品の将来のリリースでそのAPIがサポートされなくなった場合の影響を最小限にするためにも必要な自衛措置です。 |
|
次に相互運用性についてです。COM+、JavaRMI、CORBAなどの通信プロトコルはそれぞれ標準化されているため、それらの内部では異なる製品間でも相互運用性が保証されています。ただし、JavaRMIやCORBAでベンダ固有のプロトコルや標準プロトコルへの拡張機能を使っている場合には、この限りではありません。それでは、COM+、JavaRMI、HORB、そしてCORBAをまたがって相互接続を実現したい場合にはどうしたらよいでしょうか。現在、このような場合には2つの解決策があります。
1つは、CORBAの標準プロトコルであるIIOP（Internet Inter-ORB Protocol）を介して接続する方法です（図3）。まず、COM+とCORBAの接続には、CORBA標準の一部であるCOM-CORBA相互接続仕様に準拠したゲートウェイ製品を利用します。
次に、JavaRMIですが、ここでは、RMI over IIOPというプロトコルを使用してCORBAと接続します。RMI over IIOPは、JavaRMIをIIOPにマッピングしたプロトコルで、J2EE(Java 2 Enterprise Edition) 1.3ではRMIの必須プロトコルになっています。現在、J2EEに準拠するほとんどの製品がRMI over IIOPをサポートしています。HORBを使用する場合にも、IIOPを介してほかの分散オブジェクト技術と接続することができます。このように、IIOPを中心にして、異なる分散オブジェクト技術間での相互運用性が実現されています。
 |
| 図3 IIOPを介した分散オブジェクト技術間の相互接続 |
|
TIPS3 RMI over
IIOPによるJavaRMIとCORBAの相互接続
|
|
RMI over IIOPはIIOPのサブセットです。つまり、プロトコル的には、IIOPを拡張した特殊なものではなく、IIOPの一部です。従って、このプロトコルを使用することで、CORBA側からJavaRMIのオブジェクトを制限なく呼び出すことができますが、逆は必ずしも成り立ちません。つまり、JavaRMI側からCORBAのオブジェクトを呼び出す場合には、そのインターフェイスはRMI over IIOPがサポートしている範囲に限定する必要があります。別のいい方をすると、JavaRMIからCORBAオブジェクトを呼び出すには、CORBAオブジェクトを、JavaRMI側が理解できるように最初から作成しておく必要があるということです。 このような制限は、JavaRMIとCORBAのメソッド呼び出しの形式的な違いに由来しています。例えば、JavaRMIではローカル・オブジェクトを引数にしてメソッドを呼び出すと、そのオブジェクトのコピーがサーバに送られます（値渡し）。これに対してCORBAでは、もともとローカル・オブジェクトを引数として渡すという芸当ができなかったため、JavaRMIとの接続のために値オブジェクトと呼ばれる概念が導入されました。これは1つの例ですが、このような違いがJavaRMIとCORBAの間には少なからず存在します。 |
|
2つ目の方法は、SOAP（Simple Object Access Protocol）を使用して異なるテクノロジ間を接続する方法です。SOAPは、XMLベースのメッセージング・プロトコルで、特定のプログラミング言語やOSプラットフォーム、あるいは分散オブジェクト・モデルに依存せずにRPCを実現することができます。現在、COM+、EJB、CORBA、HORBなどで作成したオブジェクトをSOAPでラッピングするための製品やプロトコル・プラグインが多数登場しています。使用できるデータ型やオブジェクトの種類などに制限がある場合がありますが、これらを活用することにより、比較的簡単に異なる分散オブジェクト技術間の接続を実現することができます。
| INDEX | |
| スキルアップのための分散オブジェクト入門 | |
 |
第1回 分散オブジェクト技術が必要なわけ（2002/3/19) |
| 第2回 分散オブジェクトのしくみを理解する（2002/4/4） | |
|
第3回 開発手順からCORBAを理解する（2002/4/25） |
|
| 第4回 開発手順から分かるEJBとJavaRMI（2002/6/25） | |
| 第5回 分散オブジェクト技術としてのHORBとCOM+（2002/8/21） | |
| 第6回 現実モデルはWebサービスとの共存（2002/10/4） | |
 |
Java Solution全記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
