[19] アプリケーションアーキテクチャ
(Part of the CORBA FAQ, Copyright (C) 1996)

[19.1] CORBAはハイレベルのアプリケーションアーキテクチャを定義するのですか？

[Recently created (10/1996). Click here to go to the next FAQ in the "chain" of recent changes]

CORBAはローレベルのリクエスト／レスポンス通信を提供します。また、CORBAはリクエスト／レスポンス通信の上に実装される一般的なサービスも提供します。あるアプリケーションで用いられる実際のアーキテクチャは、CORBAでは定義されてません。CORBAでは、アーキテクチャの決定は、アーキテクチャ設計者に委ねています。

Back to the top of section [19]

[19.2] 共通アプリケーションアーキテクチャは存在するのですか？

[Recently created (10/1996). Click here to go to the next FAQ in the "chain" of recent changes]

CORBAベースのアプリケーションで用いることのできる共通のアプリケーションアーキテクチャは数多くあります。あるアーキテクチャは、CORBAオブジェクトがどのように参照されるかに関連したアーキテクチャです。その中の幾つかを以下に列挙します。

非排他的オブジェクトと排他的オブジェクト：

非排他的オブジェクト： 非排他的オブジェクトは典型的には多くのクライアントアプリケーションに共通のサービスを提供するのに用いられます。サーバプロセスは1個の分散オブジェクトのインスタンスを作ります。このオブジェクトは名前づけされるか、初期サービスで定義されます。クライアントは CORBAネームサービスを用いるかORB::resolve_initial_references()を呼ぶことにより、このCORBAオブジェクトのオブジェクトリファレンスを得ることができます。非排他的オブジェクトは結合されたクライアント間でのデータや情報の共有のための優れたメカニズムも提供することができます。
排他的オブジェクト：排他的オブジェクトはただ一つのクライアントアプリケーションからのみ参照されるオブジェクトです。排他的オブジェクトはそれ自身のサーバプロセスの中でのみ生きるか、多くの排他的オブジェクトが同じサーバプロセスの中で生きるかのどちらかです。BOAの非共有活性化方針によって、各排他的オブジェクトはそれ自身のプロセスの中で生きることができます。排他的オブジェクトは、クライアント間でデータやイベントの衝突が存在しないことを保証することができます。例えば、あるCORBAオブジェクトが長時間のデータベース検索を実行すると仮定しましょう。排他的オブジェクトをそれ自身のプロセス内に展開することにより、クライアントアプリケーションはそのサーバの振る舞いを完全にコントロールするでしょう。排他的オブジェクトと非共有活性化方針を組み合わせることにより、そのクライアントはそのサーバに対する注意をすべて引き受けます。CORBAオブジェクトはサーバサイドの処理を他のCORBAオブジェクトと共有することはありません。アプリケーションの責任で、排他的オブジェクトが唯一のクライアントアプリケーションからのみ参照されるようにしなければなりません。

注釈：“非排他的”や“排他的”といったオブジェクトレベルの性質はBOAの活性化方針と直交する概念です。

他のオブジェクトレベルでのアーキテクチャ的な相違

状態を持つオブジェクト：状態を持つオブジェクトは、内部状態を保ち、変化させるオブジェクトです。オブジェクトがデータとメソッドから構成されるなら、状態を持つオブジェクトはそのメソッドを起動している間に、そのデータを保持し変化させるオブジェクトです。状態を持つオブジェクトは、そのオブジェクトがすでに何をしたかによって違った振舞いをすることができます。例えば、get_next_item()メソッドは、そのメソッドが呼ばれる度に次の項目を返します。この振舞いは現在の記録に関連付けられた状態を保存することによって可能になるのです。状態は各オブジェクトに依存するものです。同じサーバプロセス内であっても、異なるオブジェクトはそれぞれ独自の状態を持ちます。排他的な状態を持つオブジェクトの場合、状態は各クライアントアプリケーションに依存するものとなります。非排他的な状態を持つオブジェクトの場合、複数のクライアントアプリケーションに渡って共通の状態を保持します。状態を持つオブジェクトは大変強力ですが、サーバサイドで失敗すると問題が発生します。例えば、クライアントがあるCORBAオブジェクトが保持する一組のレコードを順になめていくと仮定しましょう。もしCORBAサーバが失敗すると、その状態は失われ得ます。CORBAオブジェクトは再度活性化されることは可能ですが、get_next_item()オペレーションが次に呼ばれても適切なレコードは返されません。クライアントアプリケーションは、新しいオブジェクト内にその状態を再度作らなければなりません。代替案として、オブジェクトがその状態を保存し、最活性の時に保存した状態を回復するかもしれません。
状態を持たないオブジェクト：状態を持たないオブジェクトはメソッドの呼出しに依存する内部状態を一切保持しないオブジェクトです。状態を持たないオブジェクトは全てのアプリケーションに適している訳ではありません。状態を持たないオブジェクトは、状態を持つオブジェクトと同じ機能を果たすかもしれません。そのオブジェクトは“状態”を必要としますが、それはパラメータとして渡されます。状態を持たないオブジェクトは、失敗やサーバをまたがった測定や動的負荷分散などに関して高い柔軟性を許します。失敗した場合、サーバとオブジェクトはそれまでの状態の変化を気にすることなく、簡単に再実行が可能です。状態を持たないオブジェクトによって、クライアントは正しい型の全てのオブジェクトに対しオペレーションを実行することができるのです。このことは、同じインターフェイスを持つサーバはどれでも、クライアントにサービスすることが可能なことをあらわします。このことは、システム規模を劇的に大きくすることが可能だということです。