• リアルタイム処理
通信システムは数十万BHC(busy hour call)の呼処理を行なえる必要がある。分散型ソフト ウェア構造や分散OSは、処理能力の低下を引き起こすべきではない。
ソフトウェアを1つのモジュールに縮退配置したとしても、最初から1つのモジュール向けに 設計されていたのと同等の性能を実現すべきである。同じソフトウェアを用いて、1モジュー ルでも複数モジュールでも処理性能の劣化のない機構が必要である。
• 高信頼
システムがダウンしても、実行中のサービスは継続できる必要がある。呼に関連するオブジェ クトやデータは、初期化の際にも保持されなければならない。
さらに、基本的なCORBAの機構においても、オブジェクトの救済を行なえるソフトウェア 構造である必要がある。
3.3 オブジェクトのモデル化
3.3.1 ソフトウェアコンポーネントのCORBA機能要素へのマッピング
本ソフトウェア機能を、第3.2.6章で示したCORBA機能にマッピングしてみる。
(1) ORB (object request broker)コア
この機能は、実行制御レイヤに含まれ、分散OS環境を上位レイヤに提供する。
(2) クライアント
この機能は、別モジュールにあるクライアントを呼び出すソフトウェア機能にマッピングさ れる。
(3) オブジェクトインプリメンテーション(object implementation)
この機能は、呼出元(クライアント)に対して、特定の機能を提供する実体にマッピングされる。
(4) オブジェクトリファレンス(object reference)
ORB上のソフトウェアコンポーネントを識別するパラメータである。
ここで示す構造では、ソフトウェアコンポーネントが同じモジュール存在するか、別モジュー ルに存在するかを識別することができる。
(5) IDL (Interface Definition Language)
CORBAのフレームワークでは、オブジェクトのインタフェース定義を表す言語である。
呼び出されるオブジェクトのインタフェースはIDLを用いて定義される。IDL の定義から、
スタブとスケルトンが生成される。
(6) プログラム言語マッピング(program language mapping)
第3.2.3章で述べたように、ソフトウェアコンポーネントは一つのC++クラスのように振舞う。
従って、そのまめプログラミング言語にマッピング可能である。
(7) クライアントスタブ(client stub)、あるいは、IDLスタブ(IDL stub) これは、クライアントから見えるインタフェースである。
呼ばれたオブジェクト(ソフトウェアコンポーネント)のインタフェースルーチンの片側に対 応する。
インプリメンテーションスケルトンとともに、ORBによるモジュール間通信における仲介役 を果たす。
(8) ダイナミックインボケーションインタフェース(dynamic invocation interface)
このインタフェースは、新しいオブジェクトインプリメンテーション(コンポーネント)が追 加されたり位置が変えられた時に使われる。
本論文ではこのインタフェースについては言及しない。
(9) インプリメンテーションスケルトン(implementation skeleton)
このスケルトンは、呼ばれたソフトウェアコンポーネントのインタフェースルーチンのもう一 方の側と一致する。
スケルトンは、呼ばれたソフトウェアコンポーネントの側のモジュールに存在し、ORBと呼 ばれたソフトウェアコンポーネント間の仲介を行なう。
(10) オブジェクトアダプタ(object adaptor)
CORBAで規定されたBOA(basic object adaptor)を元に、呼出元と呼出先のコンポーネント 間のやりとりに適合したオブジェクトアダプタを定義する必要がある。
オブジェクトアダプタは次の機能を持たなければならない。オブジェクトリファレンスの生 成、メソッド呼出、ソフトウェアコンポーネントの有効化/無効化、オブジェクトリファレン スと対応するコンポーネントとの対応付け、そして、コンポーネントの登録である。
(11) ORBインタフェース
オブジェクトリファレンスの文字列への変換、初期化など、ORBの共通機能を利用するため の直接のインタフェースである。
(12) インタフェースリポジトリ(interface repository)
インタフェースに関する情報を保持するリポジトリである。
システム構築の際、この情報は利用されない。なぜなら、全てのインタフェースははオフライ ンでリンク可能であるからである。
しかし、コンポーネントの追加や変更があると、その情報はこのリポジトリに登録される。
3.3. オブジェクトのモデル化 27 (13) インプリメンテーションリポジトリ(implementation repository)
このリポジトリは、アクティブなコンポーネントの位置を保持する。
リソースの割り付け情報、デバッグ情報などである。
ORBやOS環境に固有の情報もここに保持される。
3.3.2 リアルタイム通信システムの観点からのマッピング
第3.2.6章で示したように、リアルタイム通信システムの特性に応じた機能マッピングが必要で
ある。
(1) ソフトウェアの、高い生産性、低い維持管理コストのため、オブジェクトの追加修正は容易で なくてはならない。
従って、ソフトウェアは、CORBAの使用とは無関係に、オブジェクト指向のパラダイムに基 づいて構造化されなければならない。
非分散環境向けに確立されたオブジェクト指向のソフトウェア構造[10, 15, 38]を拡張するこ とによって、CORBAベースのオブジェクトを定義する。
(2) ソフトウェアコンポーネントをさまざまなサイズのシステムに適用するため、オブジェクト
(ソフトウェアコンポーネント)は偏在可能である必要がある。
これは、同じ種類のコンポーネントが負荷分散のために複数のモジュールに存在できることを 意味する。
また、特定の機能を持つコンポーネントが、任意のハードモジュールに配置できることも意味 する。
さらに、同じソースコードのまま、シングルモジュール構成からマルチモジュール構成まで対 応できる必要がある。
(3) リアルタイム処理のため、モジュール間の通信処理は、最小のダイナミックステップで実行さ れなければならない。
ORBコアにおけるIDLスタブとスケルトンの変換処理は、できる限り軽くなければならない。
シングルモジュール構成であってもマルチモジュール構成であってもソースコードは一つであ るため、IDLスタブとスケルトンは、シングルモジュール構成の場合、取り除かれなければな らない。
IDLスタブとスケルトンの挿入/除去は、オフラインのツールによって自動的に判断されるべ きである。
(4) 高い信頼性を確保するため、呼救済の機構が必要である。
呼処理や保守運用処理のプロセスやスレッドはORBによって生成/消去されるわけではない ので、呼救済自体は各ソフトウェアコンポーネントにおいて実行されなければならない。
システムの初期化やモジュール間通信の停止についての情報は、ソフトウェアコンポーネント 間で伝達され、その情報に基づき、各ソフトウェアコンポーネントは生存を続けるか初期化を 行なうかを判断する。
! " # $ % & '
% ( ) * + , - . /0 1 & # $ % & '
2 3
4 54
4 4
4 4
67 8 9 6:;< = 7 ><
?@ A B = < C > 8 7 = D 7 C < C > E E FG 7 A H
67 8 9 6 = 7 A @6< ;< = 7 >< = 7 A @ 6<
I J < 6<>7 C E
K L E
M67 8 9 6N K L E
M;< = 7 >< N
8 7 = D 7 C < C > E
E FG 7 A H 8 7 = D 7 C < C > O
O FG 7 A H
PL E QR E
S TU V WX Y Z [ \ WX X U ] T^Z U Y X U _ Y \ W_T`Y Z [ \ WX X U ] T^Z U Y X U _ ab c >7 7 6
>7 7 6
ad c ad `e c
ad `f c
図9: オブジェクト間通信