その上にある分散オブジェクトに名前付けがされる。自動的に無機質な名前が与えられる。HORBサーバにそのオブジェクトの所在を問い合わせる。そのHORBサーバが管理する名前を加えたものになる。各ユーザによってディレクトリ管理される。生成時に名前が与えられる。同一ユーザの範囲(OZホームと呼ぶ。アドレス解決はファイルを用いて行える。ユーザ名にそのユーザの与えた名前を加えたものになる。DNS_name:user_name:object_nameの形式の識別子(GOLと呼ぶ。ユーザの識別を容易にしている。次のことを何らかの形で行わなければならない。呼び出される分散オブジェクトのある仮想計算機(JavaVM)に送る。通常の呼出しによってメソッド実行する。呼び出した側に送り返す。メソッド起動の代行を行う機能をもつオブジェクトを用意する。それがメソッド起動の値であるかのように返す。Java-RMI及びHORBではその用語を用いている。リモートメソッド起動を行う。マルチプレクスしている。proxy及びskeletonのクラスがサーバのクラスのコンパイル時に生成される。Server_Skeleton.classが生成される。リモートオブジェクト化するための変更は必要ない。リモートオブジェクトを生成する。通常のJavaオブジェクトと同様のアクセスが可能である。proxy-skeleton間にはコネクションが張られる。proxyクラス(Java)がサーバのコンパイル時に生成される。proxy及びskeletonの形態には変わりはない。オブジェクト間のコネクションは仮想的なものとなる。きめ細かな同期・相互排除の記述及び実行ができなければならない。同期メソッド起動だけを備えている。リモートオブジェクトのメソッドを呼び出した直後にクライアントに制御が戻ってくる非同期メソッド起動を備えている。同期・相互排除用の変数を複数定義することができ,これを使ってスレッド間のきめ細かな同期・相互排除を行う。その際には原因の究明が難しい。分散オブジェクトにまたがった例外処理をグローバル例外処理という。OZではそれが不要な点を除くと両者の違いはない。摸式的に図3.1に示す。オブジェクトが計算機間を移動する。そのサブクラスのものである可能性がある。受信側に常にそのオブジェクトのクラスが存在する保証はない。これを実現するには,必要なクラスの識別方法及びクラス配送の機構が必要となる。OZではワールドワイドに一意な識別方法をとる。nameによって識別される。nameをもつクラスは同一であると判断される。その中でJava-VMにロードされるのは高々一つに限られる。デシリアライズに失敗する。nameによってクラスを一意に決定可能にする必要がある。クラス及びそのインスタンスが転送される範囲において,プログラマがその一意性を保証しなければならない。その連鎖の範囲内で一意性を保証しなければならない。一意性は一つのアプレットの記述の範囲で保証すれば十分である。クラスの一意性をシステムが保証する。クラスを配送できる公開クラス及び配送されないローカルクラスの2種類に分けて管理している。その名前の一意性はプログラマが与える。続かないパッケージ名をもつ。ローカルクラスを公開クラス用に再コンパイルすることによって行われる。nameのjp.go.ipa.oz.user.以降を続けたものに変更される。nameも一意なものとなる。クラスの配送方法Javaアプレットは,WebサーバからWebのブラウザにダウンロードできるプログラム片とする。Javaのクラスがネットワーク上で配送されるという意味では,クラス配送であるが,配送されたアプレットはブラウザ上でローカルにしか動作しない。ダイナミッククラスローディングによってクラスを実行時にダウンロードできる。メソッド起動の引数として送られるオブジェクトのクラスをクライアントからサーバに配送する機能は備えていない。勝手に作ることはできる。クラス配送の手段を提供していない。ネットワーク経由でクラスの配送を受ける機構を備えている。OZのセルであるクラス配送エージェントが行う。逆に他のクラス配送エージェントからの要求によってローカルディスク上のクラスを配送する機能とをもつ。問い合わせなければならないクラス配送エージェントを順に記した検索リストをもつ。そのOZホームのクラス配送エージェントにクラス配送要求を出す。検索リストにあるクラス配送エージェントに順に問合わせを行う。それをローカルディスクに保管してエグゼキュータにその旨を伝える。クラスをロードして実行を継続する。サーバProxyを指定する形式が違うだけである。Javaとは違っている。skeletonを生成するためのコンパイラとを併用する。独自のコンパイラとjavacコンパイラとを併用する。バージョンの扱い複数のサーバからクラスを取り寄せることが必要になる。クラスに同じ名前をつけることが多い。分散環境では極めて難しい。同じクラスでも複数のバージョンが混在して動作する機構を備えておかなければならない。OZでは次の方法によってこれが可能となる。その他の定義をすべて実装として扱う。スクールという名前表によって指定する。そのインタフェース及び実装のJavaのクラス名をそれぞれA_if及びA1_clとしてスクールで指定してコンパイルを行うとする。それ以降Aから生成するインスタンスの実装にはA2_clを利用することになる。Aの変更の影響を受けることなく実行できる。クラスの実装の旧バージョン及び新バージョンのコードが互いに影響を受けることなく混在して動作可能な機構を実現している(図3.2参照)。JavaJava言語で実現したコンポーネントフレームワーク及びAPIをJavaBeansと呼ぶ。GUI機能などを生かす。JavaBeansでのコンポーネントをBeanと呼ぶ。JavaBeansをサポートするコンテナに自由に貼り付けられる。開発ツールなどがコンテナの例である。イベントなどの定義情報)を調べられる。Javaのリフレクション(refrection)APIを使って実装されている。これを可能にしている。Beanのプロパティを変更することをカスタマイゼーションという。カスタマイゼーションを行うためのコードをBean毎に個別に用意する必要はない。イントロスペクションを利用してアプリケーション独自のフォーマットで状態を保存する方法とがある。マイクロソフトのDCOM上のコンポーネント技術としてActiveXがある。プログラミング言語は規定しない。Java言語でなければ開発と利用ができない。これら二つのコンポーネントを相互に利用するための技術も開発されている。Javaのコンポーネント技術であるJavaBeans間でオブジェクト間通信を行う機能とをもつ。ActiveXコンポーネントとして動作する。COM(DCOM)というミドルウェアを利用することが多い。NTには標準的に組み込まれている。それらのOSの上で利用可能なDCOMをインストールしておく必要がある。Windows上のActiveXコンポーネントを利用できる。タイプライブラリtlbファイルに記録されている。DCOM用のスタブファイルのJavaソースコードが生成される。スタブファイルのJavaクラスが得られる。Skeletonクラスを得ることができる。ActiveXコンポーネントのメソッドをリモートに実行することができる。コンポーネント間での通信が必要となる。通常のHORBのリモートオブジェクト通信を行えばよい。サーバマシンを介してアプレット間でリモートオブジェクト通信を行う。通常のHORBのリモートオブジェクト呼出しとする。HORBのInvitation機能を用いる。通常はセキュリティの制限によってコネクションを受付けることができないアプレットのメソッドをサーバから呼び出すことを可能にする。双方向に呼び出すことが可能となる。クラスは必要に応じてクラス配送機構を使って配送する。エンドユーザによる相互利用である。catalogというサーバが用意されている。catalogにはサブジェクトが登録される。コンパイル時に用いるスクールにマージして使われる。そのサブジェクトに含まれるクラスがプログラム開発で利用可能となる。ネットワーク上でのクラスの相互利用・再利用が進む。catalogというサーバが用意されている。catalogにはアプリケーションを生成するクラスのクラス識別子が登録される。アプリケーションのオブジェクトを生成できる。必要に応じて,アプリケーションの実行に必要なクラスが転送される。そのサーバの機能(クラス)及び名前(GOL)を知ればよい。Traderというサーバが用意されている。そのサーバにアクセスするためのオブジェクトであるアクセススタブを返す。アクセススタブによって提供される。