<このシリーズの、前の記事 | このシリーズの目次 | このシリーズの、次の記事>
既に学んだように、UNOオブジェクトは、別のプログラミング言語環境から操作することができる。しかし、どのようにすればそうできるだろうか?別のプログラミング言語環境に生存するUNOオブジェクトをただ操作するというわけにはいかない。. . . だから、我々は、リモートにあるUNOオブジェクトへのプロキシを取得する。
もっと明確にしよう。プログラミング言語環境、PLE-A、があり、UNOオブジェクト、UO-A-A、がPLE-Aに生存している。別のプログラミング言語環境、PLE-B、があり、UO-A-AをPLE-Bから操作したいとする。
そう。その場合、我々は、PLE-BにUNOプロキシ、UP-B-Aを得る。我々は、PLE-BでUP-B-Aを操作し、UP-B-AがUO-A-Aを操作する。
我々はどのようにしてUNOプロキシを得るのか?
えーと、PLE-AにUNOオブジェクト、UO-A-A0、がすでに存在し、我々は既に、PLE-BにUNOプロキシ、UP-B-A0を持っているものと仮定しよう。. . . どのようにUP-B-A0を得たのかは聞かないでくれ、今のところ。それは後で説明する。
. . . オーケー。
UO-A-A0のあるメソッドがUNOオブジェクト、UO-A-A、を生成し戻り値として戻すと仮定しよう。
いいだろう。
PLE-BのUP-B-A0の対応するメソッドを呼び出すとき、ブリッジがその呼び出しを伝播し、PLE-AのUO-A-A0の先ほどのメソッドが呼びだされ、PLE-AにUO-A-Aが生成され、ブリッジがリターン操作を伝播して、PLE-BでUP-B-Aが生成され、我々に戻される。
すると、ブリッジがPLE-Bにプロキシ、UP-B-A、を生成し、UP-B-Aへのリファレンスを我々に戻すわけだ。.
ブリッジがプロキシ、UP-B-A、を生成すると言うべきか、プロキシ、UP-B-A0、がプロキシ、UP-B-A、を生成するというべきか、はっきりとは分からないが、我々は、プロキシ、UP-B-A、をブリッジとプロキシ、UP-B-A0、の協同作業を通して得る。
なるほど。. . . それではもう、どうやってUP-B-A0を得るかを聞いてもいいか?
PLE-BからPLE-AへUNOブリッジを確立する際、我々は、UNOコンポーネントコンテキストと呼ばれるものを受け取る。このUNOコンポーネントコンテキストには、そのメンバーとして、PLE-Aの「グローバルUNOサービスマネージャー」と呼ばれるものへのUNOプロキシが、格納されている。
すると、そのグローバルUNOサービスマネージャーへのそのUNOプロキシが、最初のUNOプロキシとなり、それから始めて、他のUNOプロキシを次々と取得できるわけだ。
そう。
予測できるだろうが、グローバルUNOサービスマネージャーとは何かを問わなければならない。
えーと、それは、UNOオブジェクトをどのように生成するかに関係している。. . . 我々は、UNOオブジェクトをUNOコンポーネントから生成するが、Javaでクラスインスタンスをクラスから生成する基本的な方法は、「new」オペレーターを呼ぶことだ。
そう。
しかし、「new」オペレーターを呼ぶ際は、我々は、クラスインスタンスを生成する元のクラスの名前をハードコーディングすることになる。. . . このハードコーディングを避けるために、ファクトリーと呼ばれるコンセプトが使われることがある。グローバルUNOサービスマネージャーは、UNOオブジェクトのファクトリーだ。
すると、我々は、グローバルUNOサービスマネージャーに、実装クラスそのものを指定することなく、ある種のUNOオブジェクトをくれるように依頼するわけだ。グローバルUNOサービスマネージャーは、どの実装クラスを使用するかを決定し、その実装クラスからUNOオブジェクトを生成し、そのUNOオブジェクトを我々に戻す。
そう。
君は、「UNOサービス」という用語を説明無しに使った。
そう。. . . 君は「ある種のUNOオブジェクト」と言ったが、その種類がUNOサービスだ。. . . 我々はあるUNOオブジェクトが欲しいのだが、どのUNOオブジェクトでもいいのではない。ある特定の種類のUNOオブジェクトが必要なのだ。
ははあ、実装クラスそのものを指定するのは、その種類を指定する一つの方法だが、それはハードコーディングだ。そこで、我々は、ある名称を定義し、実装クラスをその名称に関連付け、UNOオブジェクトのユーザーは、実装クラスではなく、その名称を指定する。. . . その後、その名称に別の実装クラスを関連付けることができるが、UNOオブジェクトのユーザーは自らのコードを変更する必要がない。
そうだ。その名称がサービス名だ。そして、場合によっては、複数の実装クラスが同時に同じサービス名に関連付けられ、使用される実装クラスは、UNOオブジェクトへのリクエストのコンテキストに基づいて決定される。
「グローバル」という形容詞は何を意味しているのだろうか。グローバルでないUNOサービスマネージャーもあるのか?
そう、グローバルUNOサービスマネージャー以外にもサービスマネージャーはある。そうしたUNOサービスマネージャーの各々は、すべてのUNOサービスではなく、特定のUNOサービス群のインスタンスを生成する。
すると、あるUNOサービスマネージャーはUNOサービス、US-A、US-B、のインスタンスを生成でき、別のUNOサービスマネージャーは、UNOサービス、US-C、US-D、US-E、のインスタンスを生成できるということか?
そう。
グローバルサービスマネージャーは、すべてのUNOサービスのインスタンスを生成できるのか?
UNOサービスマネージャーというのは、単にあるUNOインターフェースを実装するクラスであって、あるUNOサービスマネージャーが、グローバルUNOサービスマネージャーに登録されていないUNOサービスのインスタンスを生成できるように実装されていれば、そのUNOサービスは、グローバルUNOサービスマネージャーからはインスタンス化できない。そういうUNOサービスマネージャーが実際にあるかどうかは、また別の問題だ。
我々の用語を明確にしよう。どのUNOサービスマネージャーからであっても、UNOサービスマネージャーからインスタンス化できるものを、グローバルUNOサービスマネージャーに登録されているかどうかにかかわらず「UNOサービス」と呼ぶ。グローバルUNOサービスマネージャーに登録されているUNOサービスを特に「グローバルUNOサービス」と呼ぶ。
いいだろう。
先のサンプルUNO拡張機能では、我々は、UNOコンポーネント、HiUnoExtensionsImplementation、を'thebiasplanet.uno.hiunoextensionsunoextension.HiUnoExtensions'という名前でグローバルUNOサービスとして登録した。. 注意として、前に述べたことだが、この名前は、'HiUnoExtensions.idl'で定義された構造物の名前と同じだが、この構造物は、UNOサービスそのものではなく、「特定のUNOサービス専用UNOサービスインスタンスファクトリー」だ。
それでは、「特定のUNOサービス専用UNOサービスインスタンスファクトリー」は、UNOサービスマネージャーではないということか?
そう、違う。これは、グローバルUNOサービスマネージャーへのフロントエンドだ。
なるほど。
- Apache OpenOffice Wiki. (2014/01/02). Apache OpenOffice Developer's Guide. Retrieved from https://wiki.openoffice.org/wiki/Documentation/DevGuide/OpenOffice.org_Developers_Guide