Corba -Speedylook Encyclopedia
一般的なオブジェクト要求ブローカーアーキテクチャ （CORBA）は、複数のプログラミング言語で記述され、異なるコンピューターで実行されるさまざまなソフトウェアコンポーネントを許可するオブジェクト管理グループ（OMG）によって定義された標準です。つまり、不均一環境で分布したアプリケーションの開発を促進します。 [ 必要な予約 ]
序章 [ 編集します ]
CorbaはOMGによって提案された最初の製品でした。その目的は、複雑さを削減し、コストを削減し、新しいコンピューターアプリケーションの導入を加速し、分散システムにおけるオブジェクトテクノロジーの理論と実践を促進することです。
これは、分散アプリケーションの低レベルでプログラミングを隠す技術です。ただし、プログラマーにオブジェクトに向けたテクノロジーを提供します。オブジェクト機能とこれらのオブジェクトは異なるマシンにある場合がありますが、プログラマーはプログラム内の通常の関数を介してアクセスします。
Corbaはマルチプラットフォーム仕様以上のものであり、安全や取引などの通常の必要なサービスも定義しています。したがって、これはオペレーティングシステム自体ではなく、実際にはミドルウェアです。
彼の最初のバージョンは1991年に発売されました。
1995年には、CORBA 2が登場し、新しい標準が可能になります。さまざまなメーカーの実装を協力することができ、あらゆるレベルの輸送で実装でき、TCP/IPでインターネットで動作し、プロトコル：IIOP（IOPインターネット）を作成できます。
Corba 3は、MicrosoftとそのDCOM分散オブジェクトプログラミングモデルに立ち向かう試みとして2002年に示されています。とりわけ、Corbaコンポーネントモデル（CCM）が導入され、分散オブジェクトのモデル（EJB、Javaに制限）がコンポーネントに向けられた分布モデルに渡されました。
特性 [ 編集します ]
Corbaの主な特徴の中で、私たちは見つけます：
- プログラミング言語とオペレーティングシステムの独立性：Corbaは、ソフトウェア設計に関する制限からエンジニアを解放するように設計されています。現在、AD、C、C ++、C ++ 11、LISP、Ruby、SmallTalk、Java、Cobol、PL/I、Pythonを認めています。
- 異なるテクノロジー間の相互作用の可能性：CORBAの使用の主な利点の1つは、さまざまなテクノロジー間のインターフェイスを正規化し、それらを組み合わせる可能性です。
- 配布透明性：システムがすべてを扱っているため、顧客もサーバーもアプリケーションが分散または集中化されているかどうかを知る必要はありません。
- 場所の透明性：クライアントは、サービスとサービスがクライアントがどこで実行するかを知る必要がない場所を知る必要はありません。
- 既存のソフトウェアの統合：以前の投資は、継承されたシステムであっても、それが機能するソフトウェアを再利用することを償却します。
- オブジェクトのアクティベーション：リモートオブジェクトは永続的にメモリ内にある必要はなく、クライアントには見えません。
- その他：強力なデータ型、高設定、データ転送の詳細を選択する自由、またはデータ圧縮。
Corbaアーキテクチャはオブジェクト指向です。 Corbaでは、オブジェクトには、インターフェースや多型の観点からの継承など、他のオブジェクト指向システムの特性の多くがあります。しかし、この側面について最も興味深いことは、CorbaがJavaやC ++などのオブジェクト指向の言語でより効率的に動作するものの、CやCOBOLなどのオブジェクトに向けられていない言語にこれらの特性を提供する可能性です。
オブジェクトリクエストブローカー（ORB） [ 編集します ]
Object Request Broker（ORB）は、Corba Architectureの基本的なコンポーネントであり、その使命はオブジェクト間のコミュニケーションを促進することです。これは、リクエストをオブジェクトに送信し、シリアル化プロセスのためにそれらを呼び出すクライアントへの応答を返す責任があります。
ORBには、その主な特徴的な透明性があります。クライアントとサーバーの隠れ家との間の通信を促進します。
- オブジェクトの場所：クライアントは、宛先オブジェクトがどこにあるかを知る必要がありません。自分のマシンまたはリモートマシンのプロセスにあります。
- オブジェクトの実装：クライアントは、リモートオブジェクト、その実装、または発見されたオペレーティングシステムが書かれているプログラミング言語を無視しています。
- オブジェクト実行状態：リモートオブジェクトにリクエストを送信する場合、ORBは請願を送信する前に、必要に応じてオブジェクトを初期化する責任があります。
- オブジェクト通信メカニズム：クライアントは、どの通信メカニズムがORBを使用してリクエストを送信し、結果を返すかを知りません。
インターフェイス定義言語（IDL） [ 編集します ]
インターフェイス定義言語またはIDL（インターフェイス定義言語）は、アプリケーションのコンポーネント間のインターフェイスを定義するために使用される言語であり、テクノロジーの相互運用性をサポートする要素です。 IDLは、実装ではなくインターフェイスのみを定義できます。 Corbaのオブジェクト間のインターフェイスを指定することにより、IDLは使用されるプログラミング言語の独立性を確保する責任があります。
これを可能にするためには、データが2つの異なる言語間で正しく交換されるようにする必要があります。これにより、IDLは言語とは独立したデータ型を必要な通信と定義します。たとえば、男 長さ 32ビットC ++では、aに対応できます int Javaの。
OMGは、C、C ++、Cool、Java、Smalltall、DAなどの一般的なプログラムとの通信のbastant剤を定義しました。
主にCorbaには2つの異なるタイプのIDLがあります。
- スタブ IDL：IDLインターフェイスで宣言されたサービスへの静的インターフェイスであり、クライアントはすべての呼び出しがローカルに見えます。これは、リモートオブジェクトのプロキシとして機能し、シリアル化、応答の受信、極化などのリモートメソッドの呼び出しを行います。クライアントは、IDLインターフェイスが存在するのと同じくらい多くのスタブを持つことができます。 IDLコンパイラによって、クライアントプログラミング言語（C、C ++ Java、SmallTalk、ADA、…）のIDLから生成されます。
- スケルトン IDL：彼はサーバー上の顧客の静的な代表です。サーバーの場合、すべての呼び出しがローカルに見えます。 IDLからIDLコンパイラによって生成され、顧客の呼び出しの虚外化を実行します。
次の図は、Hello Worldを実行するオブジェクトのIDL例を示しています。 一方通行 通信は一方向であり、したがって方法の応答が予想されないことを示しています。
モジュールhelloapp {
インターフェイスこんにちは{
string sayhello（）;
ワンウェイボイドシャットダウン（）;
}
}
参照によるオブジェクト [ 編集します ]
オブジェクトの参照は、チェーン形式の均一なリソース識別子（URI）フィールド、名前サーバー検索（ドメイン名システム（DNS）のものと同様）を介して取得されるか、メソッドの呼び出し中に引数として渡されます。
参照オブジェクトは、リモートであろうとローカルであろうと、実際のオブジェクトのインターフェイスを実装するはるかに軽いオブジェクトです。参照によるメソッドへの呼び出しは、スレッドをブロックし、成功または失敗のいずれかの回答を待つ責任があるオーブへの一連の呼び出しで構成されています。パラメーター、返品情報（ある場合）、および例外は、プログラミングおよびオペレーティングシステムの言語に従って、ORBによって内部的にシリアル化されます。
値によるデータ [ 編集します ]
IDLは、オブジェクトまたはオペレーティングシステム間のインターコム定義言語を提供します。 Corbaオブジェクトは参照によって渡されますが、データ（ 整数 、 ダブル 、 構造体 、 酵素 、など…）は価値で渡されます。この組み合わせにより、顧客とサーバーを編集するときに強く並べられたデータを補完しますが、Corbaが私たちを促進する柔軟性を維持します。
値によるオブジェクト（obv） [ 編集します ]
リモートオブジェクトに加えて、corbaとrmi-iiopはの概念を定義します 値によるオブジェクト またはobv（価値によるオブジェクト）および ValueTypes 。オブジェクトメソッドのコード ValueType 省略によってローカルに実行されます。 obvがリモート側から受信された場合、必要なコードは両方の当事者によって先験的に既知であるか、発行者によって動的に排出される必要があります。これをすべて可能にするために、obvを定義する登録には、このコードをダウンロードする必要があるURLSスペースによる個別のリストを含むコードベースが含まれています。さらに、obvにはリモートメソッドを持つことができます。
obvsは、obvが転送されるときに転送されるフィールドを持つことができます。これらのフィールドは、リスト、ツリー、または任意のグラフィックを形成することができます。 obvsには、複数の継承や抽象クラスを含むクラス階層があります。
Corbaコンポーネントモデル（CCM） [ 編集します ]
CorbaコンポーネントモデルまたはCCM（Corbaコンポーネントモデル）は、Corbaの定義ファミリーに追加されています。 Corba 3バージョンで導入され、Corbaコンポーネントのフレームワークについて説明します。言語依存企業に依存するものではありませんが、Java Beans（EJB）はこれのより一般的な形式であり、EJBが定義する2つではなく4つの異なるタイプのコンポーネントを提供します。また、ポート（ポート）と呼ばれる明確に定義された独自のインターフェイスを通じてサービスを提供および受け入れることができるエンティティの抽象化を提供します。
CCMには、ソフトウェアコンポーネントを堆積できるコンポーネントコンテナがあります。コンテナは、コンポーネントが使用できる一連のサービスを提供します。これらのサービスには、通知、認証、永続性、およびトランザクションプロセスが含まれます（これらだけに限定されていませんが）。これらは、分散システムが必要とする最も使用されているサービスであり、コンポーネントコンポーネントのこれらのサービスの実装をコンポーネントコンテナに移動すると、コンポーネントの複雑さが大幅に削減されます。
ポータブルを挿入します [ 編集します ]
ポータブルインターセプター（ポータブルインターセプター）は、CORBAとRMI-IIOPが使用するフックであり、CORBAシステムの最も重要な機能の1つを提供します。これは、次のタイプのインターセプターを定義します。
- リモートオブジェクト（IOR）の参照インターセプターを使用すると、現在のサーバーに存在するリモートオブジェクトの新しい参照を作成できます。
- 顧客インターセプターは、クライアント側からのリモートメソッドへの呼び出しを提供します。メソッドが呼び出された同じサーバーにサービスオブジェクトが存在する場合、ローカルコールも許可します。
- サーバーインターセプターは、サーバー側でリモートメソッド呼び出しの処理を提供します。
インターセプターには、送信時にメッセージの特定の情報と作成時にIORが含まれる場合があります。この情報は、リモート側の対応するインターセプターによって後で読むことができます。インターセプターは、転送の例外を起動し、要求を別の目的にリダイレクトできます。
一般的なInterOBプロトコル（GIOP） [ 編集します ]
GIOPは、オーブが通信する抽象的なプロトコルです。プロトコルに関連する標準は、OMGによって維持されます。 GIOPのアーキテクチャは、次のような一連のプロトコルを提供します。
- InterORBプロトコル（IIOP）：インターネット使用のためのGIOP実装。GIOPメッセージとTCP/IPレイヤー間のインターフェイスを提供します。
- SSL InterORBプロトコル（SSLIOP）：SSLのIIOPプロトコル、暗号化と認証を提供します。
- HyperText InterORBプロトコル（HTIOP）：HTTPのIIOPプロトコル、リモート透明性を提供します。
- Zipped IAP（ZIOP）：帯域幅の使用を削減する圧縮GIOPバージョン。
Corbaの場所（Corbaloc） [ 編集します ]
Corbaの場所（Corbaloc）は、URLの構造と同様の構造を持つ参照されたCorbaオブジェクトを参照しています。
すべてのCorba製品は、CorbalocとCorbanameの2つの定義されたURLをサポートする必要があります。両方の目的は、IORを取得できる場所を指定するために、人間が読んで編集できる方法を提供することです。
Corbalocの例を以下に示します。
Corbaloc :: 160.45.110.41：38693/Standardns/nameserver-poa/_root
CORBA製品は、オプションでHTTP、FTP、およびファイル形式の使用をサポートできます。これらの目的は、フィールドIORのダウンロード方法に関する詳細を提供することです。
それはどのように機能しますか [ 編集します ]
すべてのcorbaコンポーネントはオブジェクトであり、それぞれにインターフェイスと一意のアイデンティティがあり、各オブジェクトは別のプログラミング言語で実装し、任意のオペレーティングシステムで実行できます。
サーバーは、リモートオブジェクトを作成し、それらのリモートオブジェクトに参照し、顧客がこれらのオブジェクトまたはメソッドを呼び出すのを待ちます。一方、クライアントは、サーバー上の1つ以上のリモートオブジェクトの参照を取得し、メソッドを呼び出します。
クライアントの呼び出しを作成する方法は、IDLから生成されたサーバーとの通信インターフェイスであるStubを使用して、動的呼び出しを使用してサーバーオブジェクトにアクセスして、通話によって生成された例外を管理します。
リモートオブジェクトまたはior（相互運用可能なオブジェクト参照）の参照、オブジェクトのタイプ、および呼び出したい操作の名前が必要です。
IDLインターフェイスを説明すると、ORBは選択した言語でコードを自動的に生成して、分散アプリケーションを統合します。明らかに、インターフェイスのみを記述するため、フロー制御、メモリ管理、機能構成など、プログラミング言語に関連するすべての複雑なタスクはIDLには表示されません。
ORBは、顧客リクエストから適切な実装コードを見つけ、パラメーターを送信します。 スケルトン プロセス内のIDLおよびレポートの例外（IORまたはIDL参照など）。
リクエストを受信するために、そのメソッドの1つがORBからインターフェイスの実装への呼び出しとしての呼び出しを受信すると、IDLスタブを使用したクライアントから呼び出しが届くことがあります。インターフェイスのスケルトンは、各インターフェイスとCorbaの実装に存在するオブジェクトアダプターに固有です。呼び出し、コントロール、返品値が完了すると、クライアントに返されます。
オブジェクトアダプターが提供するサービスを使用することも、ORBが提供することもできますが、クライアントが受け取ったリクエストは、その場合、それらのセット間のオブジェクトアダプターを選択して、インターフェイスの実装を必要とするサービスのクラスに基づいています。
問題と重要 [ 編集します ]
Corbaはソフトウェアのコーディングと構築の方法について多くを約束しましたが、それは多くの批判の主題でした。
障害の一部は、標準化されたソフトウェアを実装することにより、Corbaが標準として考案されたプロセス、およびビジネスポリシーに関連して発生した問題によるものです。これらは、新しいプロジェクトや分野でのCorbaの使用と採用の拒否をもたらしました。
実装と非互換性 [ 編集します ]
Corbaの最初の仕様は、言語間の相互運用性ではなく、IDLのみを定義しました。これは、ソースコードの互換性が当時利用可能なコードよりも優れていなかったことを意味します。 Corba 2以降では、この問題が解決しました。
場所の透明性 [ 編集します ]
透明性の観点からのCorbaの概念は批判の理由であり、これは同じ方向空間に存在し、関数への単純な呼び出しでアクセスできるオブジェクトが、分散システムのどこにでもあるオブジェクトとして扱われるためです。これにより、ローカルアクセスは、最も複雑なリモートステージにあるのと同じくらい複雑になります。ただし、Corbaはコールの複雑さに制限を提供していないと言えます。
設計および処理の欠陥 [ 編集します ]
Corba標準の作成は、委員会による設計プロセスによってしばしば引用されます。解決すべき問題の階層の競合または決定の提案の間に仲裁プロセスはありませんでした。したがって、基準は、それらの間の一貫性に関係なく、すべての提案を考慮して作成されました。これにより、仕様は非常に複雑で、実装する顔があり、しばしば曖昧になりました。
実装の問題 [ 編集します ]
その歴史を通じて、Corbaはその実装における欠陥の影響を受けてきました。仕様のすべての重要な要素を含む実装はほとんどなく、既存の実装は不完全または不十分でした。新しい特性を提案する際に要件がないため、メンバーには、使いやすさまたは実装の観点からテストされたことのないプロパティが含まれていました。次に、実装は一般的な傾向によって妨げられ、それらすべてを採用することを約束する規範と一般的な慣行が妨げられました。
現在、この時点でより良く変化しており、より良い品質のCorbaの実装を見つけることができます。
ファイアウォール [ 編集します ]
Corba（より正確には、IIOP）は、データを送信するためにCrudas TCP/IP接続を使用します。ただし、クライアントが非常に制限的なファイアウォールまたは透明なプロキシサーバーを備えた環境の背後にいる場合、ポート80の外側のHTTP接続のみを許可する環境は、問題のプロキシサーバーがソケットとの接続HTTPメソッドまたは接続を許可しない限り、通信を不可能にすることができます。瞬間がありましたが、実装が単一の標準ポートを使用することを強制するまで困難でしたが、代わりにいくつかのランダムポートを選択する必要がありました。今日、現在のオーブにはこれらの欠陥がありません。これらの困難により、一部のユーザーは、Corbaの代わりにWebサービスの使用を好んでいます。これらは、HTTPを介したWebナビゲーションのために、通常、組織内のプロキシHTTPを介して開いたまままたはフィルタリングされたポート80を介してXML/SOAPを使用して通信されます。ただし、最近のCORBAの実装はSSLをサポートしており、単一のポートで動作するように簡単に構成できます。 TaoやJacorbなどの最も人気のあるオープンソースオーブのほとんどは、双方向GIOPもサポートしています。これにより、Corbaは、Webサービスの実装に特徴的な特徴的なポーリングアプローチの代わりにコールリターンコミュニケーションを使用できるという利点を提供します。同時に、問題なくCORBAをサポートするより多くのfireが販売されています。
参照してください [ 編集します ]
参照 [ 編集します ]
外部リンク [ 編集します ]
Recent Comments