概要：Universal Network Objects (UNO)

Overview

UNO は、異なるプログラミング言語、異なるオブジェクト モデル、異なるマシン アーキテクチャ、および異なるプロセス間の、LAN またはインターネット経由のどちらでも相互運用性を提供するコンポーネント モデルです。

StarOffice および Sun ONE Webtop 製品は、複雑な実際のアプリケーションにおける UNO の有用性を実証しました。いずれかの製品の機能を使用、拡張、または変更したい開発者は、UNO を使用して、これを実行します。

UNOは、上記のアプリケーションに限定されていません。UNOのベース・ライブラリは、StarOfficeから独立していて、他のアプリケーションに対するフレームワークとして使用されることができます。

UNO は、無料で利用可能 (ALv2 で配布) で、現在、Java、C、C++ (Windows、Linux、Solaris 上) をサポートしています。COM OLE オートメーション用のブリッジは、既に存在します。

UNO は、Sun Microsystems 開発ラボを含む OpenOffice.org コミュニティによって開発されています。

Some technical details

UNOは、COMとCORBAと同様に、基盤インターフェイスです。コンポーネントは、インターフェイス仕様に準拠したインターフェイスを実装します。複数のコンポーネントは、それらのインターフェイスによってのみ通信します。これにより、他のコンポーネントを変更することなく、1 つのコンポーネントを別の言語で実装したり、実装を別のマシンに移動したりできるようになります。これは、あなたは、大きな柔軟性が得られ、以前に投資した努力が保存されます。

それぞれのコンポーネントは、Uno ランタイム環境 (URE) 内に存在します。UREは、(C++、Java、Perl などのような) 実装言語と現在のプロセスによって識別されます。同じ URE 内でインスタンス化されるコンポーネントには、パフォーマンスのオーバーヘッドはなく、たとえば、C++ では、コンポーネント A から B への呼び出しは単なる仮想呼び出しです。異なる URE からのコンポーネント間の呼び出しは、UNO によってブリッジされます。

一般には、呼び出しは、単一のディスパッチ・メソッドを通じてブリッジされます。この方法は、一般に、プロセス間ブリッジやインタープリタ言語へのブリッジでは、簡単に実装できます。スタブまたはプロキシ用のコードは、生成されません。必要な変換は、すべて汎用ディスパッチ・メソッドによって実行されます。メソッド・シグネチャに関する情報は、型ライブラリから動的に取得されます。この型ライブラリは、すべてのブリッジで再利用されるため、型の数が増えると、型ライブラリ内のエントリの数のみが増加します。これは、ビルド時間と実行時のメモリ消費が削減されます; それにもかかわらず、ブリッジは、生成されたコードと同じくらい高速です。

UNOインターフェイスは、IDLで指定されています。すべての UNO インターフェイスは、取得、解放、および queryInterface メソッド (COM に相当) を提供するスーパーインターフェイスから派生する必要があります。UNOオブジェクトの寿命は、グローバル参照カウントによって制御されます。例外は、エラー処理のために使用されます。

UNOは、オブジェクトの ID、スレッドの ID、および呼び出しのシーケンスを保証します。

• オブジェクトID

  2つのインターフェイスの参照が、等しいかどうかを比較できます。UNO は、結果が、trueかfalseかに関係なく、結果が正しいことを保証します。

• スレッド識別

  UNO では、すべてのスレッドは、グローバルに一意のスレッド識別子によって名前が付けられます。 プロセス間ブリッジを介して、プロセスを離れるスレッドは、プロセスに入るときに識別されますが、この場合も、いくつかのコールスタック レベルが高くなります。同じスレッドが、新しい呼び出しを実行するため、スレッドに依存するリソース (スレッド ローカル ストレージ、ミューテックスのロックなど) は、同じままであることが保証されます。

• 呼び出しのシーケンス

  UNOは、メソッドを一方向 (または非同期) で宣言できます。複数の一方向呼び出しは、呼び出されたときと同じ順序で実行されることが保証されます。

一方向呼び出しのシーケンスは、プロセス間接続を介して、非常に高速に転送および実行できます。

UNO インタープロセス・プロトコルは、低帯域幅接続用に最適化されています。

詳細な技術情報については、この文書「Uno Intro」を参照してください。

Applications built on UNO

この章では、UNO の実際の使用例と、アプリケーションが、UNO から得る利点について説明します。

StarOffice（またはOpenOffice.org）

StarOfficeは、完全な機能を備えたオフィス生産性スイートです。

StarOffice は、主に UNO の C++ インプロセス機能を使用します。UNO 以前は、StarOffice の開発では、基本ライブラリの 1 つに互換性のない変更 (新しい仮想メソッドやクラスへの新しいメンバーの追加など) が頻繁に発生していました。このため、製品を完全に再構築する必要があり、これには、約 2 日かかり、週に 1 回しか実行されませんでした。UNO を使用することで、これらの互換性のない更新が大幅に削減され、結果として作業全体がより効率的になりました。より詳しい説明については、この文書「Uno the Idea」をご覧ください。

StarOffice の Java コンポーネント (pgp 統合など) は、Java-C++ ブリッジを使用して StarOffice API にアクセスします。外部開発者は、このブリッジを使用して、必要な機能を StarOffice に簡単に統合できます。

外部開発者は、UNO インタープロセス ブリッジを使用して、別のプロセスから StarOffice-API にアクセスし、リモート オフィスを制御できます。

Sun ONE Webtop

Sun ONE Webtopは、高度に分散されたアプリケーションです。インターネット経由で、フル機能のオフィス生産性スイートを提供します。Office ドキュメントには、さまざまなクライアント (Web ブラウザ プラグイン、PDA、HTML クライアントなど) を介してアクセスできます。

UNO は、WebBrowserプラグインとオフィス・アプリケーション・サーバー間の通信に使用されます。シーンをペイントするために必要なすべての出力デバイス呼び出し (DrawRect、DrawLine、SetColor など) は、インターネット接続を介して送信されます (これらの呼び出しを一方向に宣言することで必要なパフォーマンスが達成されます)。

UNO は、Java Server Pages (Web サーバー内で実行) と Universal Content Broker (データ アクセスを担当する C++ プロセス) 間のブリッジとして使用されます。

UNO, COM, CORBA, and Java RMI

既存のコンポーネント モデル (COM/DCOM、CORBA、Java RMI など) を使用する代わりに、新しいコンポーネント モデル (UNO) が開発されたのはなぜかとよく尋ねられます。主な理由は、他のオブジェクト モデルでは、StarOffice や Sun ONE Webtop などのアプリケーションに必要な機能が提供されていないためです。

• COM/DCOMは、高度なエラー処理に非常に重要な例外の使用は許可されません。
• CORBAは、リモート通信の標準であり、インプロセス通信 (IIOP インプロセス) のサポートは非常に貧弱で、ほとんどのアプリケーションでは、遅すぎます。CORBA-UNOの比較ドキュメントも参照してください。
• Java RMIは、Java環境内でのみ役立ちますが、異なる言語間の橋渡しをする技術が必要です。

加えて、必要なコード生成、例えば、COMまたはCORBAでは、多くの型がある場合、ライブラリが、巨大になります。新しいブリッジごとに、新しく生成されたグルーコードが必要になりますが、扱いが非常に困難になります。

• COMの基礎

COMは、オブジェクトの公開方法や、オブジェクト自身の寿命の管理方法などを定義しています。また、COMはプロセスやネットワークを越えた動作方法も定義しています。COMが定めるこれらの定義に基づいて、オブジェクトの機能が他のコンポーネントやアプリケーションに公開されるのです。

まあ、簡単に言えば、コンポーネントを作成・使用してプログラムをするときの仕様、あるいは取り決めみたいなものです。つまり、

「新しく独自のCOMコンポーネントを実装するプログラマはここに示す仕様にしたがってコンポーネントを作成してね。」

そして、

「既存の（自分あるいは他の誰かが作った）COMコンポーネントを使用するときにはこの仕様にしたがってね。」

ということだと思ってください。