Loading article…
共通オブジェクトリクエストブローカーアーキテクチャ（CORBA）は、オブジェクト管理グループ（OMG）によって定義された標準規格であり、多様なプラットフォームに展開されたシステム間の通信を容易にするように設計されています。CORBAは、異なるオペレーティングシステム、プログラミング言語、およびコンピューティングハードウェア上のシステム間の連携を可能にします。CORBAはオブジェクト指向モデルを使用しますが、CORBAを使用するシステム自体がオブジェクト指向である必要はありません。CORBAは分散オブジェクトパラダイムの一例です。
1990年代半ばから後半にかけて一時的に人気を博したCORBAだが、その複雑さ、一貫性のなさ、高額なライセンス費用により、ニッチな技術に留まっている。[ 1 ]
CORBAは、異なる言語で記述され、異なるコンピュータ上で動作するソフトウェア間の通信を可能にします。CORBAを使用する開発者は、特定のオペレーティングシステム、プログラミング言語、ハードウェアプラットフォームの実装の詳細を気にする必要がありません。CORBAは、同一アドレス空間（アプリケーション）内、またはリモートアドレス空間（同一ホスト、あるいはネットワーク上のリモートホスト）に存在するアプリケーションオブジェクト間のメソッド呼び出しのセマンティクスを標準化します。バージョン1.0は1991年10月にリリースされました。
CORBAは、オブジェクトが外部に提示するインターフェースを指定するために、インターフェース定義言語（IDL）を使用します。CORBAは、IDLからC++やJavaなどの特定の実装言語へのマッピングを指定します。Ada、C、C ++、C ++ 11、COBOL、Java、Lisp、PL/I、Object Pascal、Python、Ruby、およびSmalltalkには標準のマッピングが存在します。C # 、Erlang 、 Perl 、 Tcl 、およびVisual Basicには、これらの言語用に作成されたオブジェクト要求ブローカー（ ORB ）によって実装された非標準のマッピングが存在します。IDLのバージョンは大きく変更されており、一部のプラグマがアノテーションに置き換えられています。
CORBA仕様では、アプリケーションが他のオブジェクトとやり取りするためのORB（オブジェクト参照ブロック）が必要であると規定されています。実際の実装方法は以下のとおりです。
IDL マッピングの中には、他のものよりも使いにくいものがあります。例えば、Java の特性上、IDL-Java マッピングは非常に簡単で、Java アプリケーションで CORBA を非常に簡単に使用できます。これは、IDL-Python マッピングにも当てはまります。C++ マッピングでは、プログラマーは C++標準テンプレートライブラリ(STL) より前のデータ型を学習する必要があります。対照的に、C++11 マッピングは使いやすいですが、STL を多用する必要があります。C 言語はオブジェクト指向ではないため、IDL-C マッピングでは、C プログラマーがオブジェクト指向機能を手動でエミュレートする必要があります。
CORBAベースの分散オブジェクトインターフェースを使用または実装するシステムを構築するには、開発者は、システムが使用または実装するロジックへのオブジェクト指向インターフェースを定義するIDLコードを取得するか、または作成する必要があります。通常、ORB実装には、IDLインターフェースをシステムの一部で使用するターゲット言語に変換するIDLコンパイラと呼ばれるツールが含まれています。次に、従来のコンパイラが生成されたコードをコンパイルして、アプリケーションで使用するリンク可能なオブジェクトファイルを作成します。この図は、生成されたコードがCORBAインフラストラクチャ内でどのように使用されるかを示しています。
この図は、CORBA を使用したリモート プロセス間通信の高レベルなパラダイムを示しています。CORBA 仕様では、データ型、例外、ネットワーク プロトコル、通信タイムアウトなどについてもさらに詳しく説明しています。たとえば、通常、サーバー側には、呼び出しをローカルサーバントまたは (負荷分散のため) 他のサーバーにリダイレクトするポータブル オブジェクト アダプタ(POA)があります。CORBA 仕様 (したがってこの図) では、オブジェクトのライフタイム (参照カウント セマンティクスはアプリケーションで使用可能)、冗長性/フェイルオーバー、メモリ管理、動的負荷分散、表示/データ/制御セマンティクスの分離 (たとえば、モデル-ビュー-コントローラを参照) などのアプリケーション指向モデルなど、分散システムのさまざまな側面をアプリケーションに定義させています。
CORBAは、ユーザーに言語とプラットフォームに依存しないリモートプロシージャコール（RPC）仕様を提供するだけでなく、トランザクションやセキュリティ、イベント、時間、その他のドメイン固有のインターフェースモデルなど、一般的に必要とされるサービスも定義しています。
この表は、CORBA標準バージョンの履歴を示しています。[ 2 ] [ 3 ] [ 4 ]
IDLの変更は進んでおり、一部のプラグマがアノテーション（例：@unit、@topic）に置き換えられています。
サーバントとは、リモートメソッド呼び出しを処理するメソッドを含む呼び出しターゲットです。新しいCORBAバージョンでは、リモートオブジェクト（サーバ側）は、オブジェクト（リモート呼び出しに公開されるオブジェクト）とサーバント（前者がメソッド呼び出しを転送するオブジェクト）に分割されます。サーバントはリモートオブジェクトごとに1つ、または同じサーバントが、指定されたポータブルオブジェクトアダプタに関連付けられた複数の（場合によってはすべての）オブジェクトをサポートできます。各オブジェクトのサーバントは、「一度設定すれば永久に」設定または検索（サーバントのアクティベーション）することも、そのオブジェクトのメソッドが呼び出されるたびに動的に選択（サーバントのロケーション）することもできます。サーバントのロケータとサーバントのアクティベーターの両方が、呼び出しを別のサーバに転送できます。全体として、このシステムは、複数のマシン間でリクエストを分散し、負荷をバランスさせるための非常に強力な手段を提供します。オブジェクト指向言語では、リモートオブジェクトとそのサーバントの両方が、オブジェクト指向プログラミングの観点からオブジェクトです。
インカーネーションとは、サーヴァントを CORBA オブジェクトに関連付けて、リクエストを処理できるようにする行為です。インカーネーションは、仮想 CORBA オブジェクトに具体的なサーヴァント形式を提供します。アクティベーションと非アクティベーションは CORBA オブジェクトのみに関係し、インカーネーションとエセリアル化という用語はサーヴァントに関係します。ただし、オブジェクトとサーヴァントのライフタイムは独立しています。 を呼び出す前に必ずサーヴァントをインカーネーションしますactivate_object()が、その逆も可能です。 はcreate_reference()サーヴァントをインカーネーションせずにオブジェクトをアクティブ化し、サーヴァントのインカーネーションは後でサーヴァントマネージャを使用してオンデマンドで行われます。
のポータブルオブジェクトアダプタ（POA）は、サーバー側のリモート呼び出しハンドラをリモートオブジェクトとそのサーヴァント。リモートオブジェクトはリモート呼び出しに対して公開され、サーヴァントには実際にリクエストを処理するメソッドが含まれています。各オブジェクトのサーヴァントは、静的（一度だけ）または動的（リモート呼び出しごとに）に選択でき、どちらの場合も呼び出しを別のサーバーに転送できます。
サーバー側では、POAはツリー状の構造を形成し、各POAは1つ以上の対象オブジェクトの処理を担当します。このツリーの各ブランチは個別に有効化/無効化でき、サーバの位置や有効化のための異なるコード、および異なるリクエスト処理ポリシーを持つことができます。
以下では、CORBAを使用して分散オブジェクト間の通信を円滑化するための最も重要な方法のいくつかについて説明します。
この参照は、文字列化されたUniform Resource Locator （URL）、NameServiceルックアップ（ドメインネームシステム（DNS）と同様）、または呼び出し時にメソッドパラメータとして渡されることによって取得されます。
オブジェクト参照は、実際のオブジェクト（リモートまたはローカル）のインターフェースに一致する軽量オブジェクトです。参照に対するメソッド呼び出しは、ORBへの後続呼び出しを引き起こし、応答、成功、または失敗を待つ間、スレッドをブロックします。パラメータ、戻りデータ（存在する場合）、および例外データは、ローカル言語とOSのマッピングに従って、ORBによって内部的にマーシャリングされます。
CORBAインターフェース定義言語は、言語やOSに依存しないオブジェクト間通信の定義を提供します。CORBAオブジェクトは参照渡しされ、データ（整数、倍精度浮動小数点数、構造体、列挙型など）は値渡しされます。オブジェクト参照渡しとデータ値渡しの組み合わせにより、クライアントとサーバーのコンパイル時に優れたデータ型を強制しつつ、CORBA特有の柔軟性を維持することができます。
リモートオブジェクトとは別に、CORBAとRMI-IIOPはOBVと値型の概念を定義しています。値型オブジェクトのメソッド内のコードは、デフォルトではローカルで実行されます。OBVがリモート側から受信された場合、必要なコードは、両側で事前にわかっているか、送信側から動的にダウンロードされる必要があります。これを可能にするため、OBVを定義するレコードには、コードベースが含まれています。コードベースとは、このコードをダウンロードするURLをスペースで区切ったリストです。OBVにはリモートメソッドを含めることもできます。
CORBA コンポーネント モデル (CCM) は、CORBA 定義ファミリーに追加されるものです。[ 5 ]これは CORBA 3 で導入され、CORBA コンポーネントの標準アプリケーション フレームワークを記述します。「言語依存のEnterprise Java Beans (EJB)」には依存しませんが、EJB のより一般的な形式であり、EJB で定義されている 2 つのコンポーネント タイプの代わりに 4 つのコンポーネント タイプを提供します。これは、ポートと呼ばれる明確に定義された名前付きインターフェイスを介してサービスを提供および受け入れることができるエンティティの抽象化を提供します。
CCMには、ソフトウェアコンポーネントをデプロイできるコンポーネントコンテナがあります。このコンテナは、コンポーネントが利用できる一連のサービスを提供します。これらのサービスには、通知、認証、永続化、トランザクション処理などが含まれます（ただし、これらに限定されません） 。これらは、あらゆる分散システムで必要とされる最もよく使用されるサービスであり、これらのサービスの実装をソフトウェアコンポーネントからコンポーネントコンテナに移行することで、コンポーネントの複雑さを大幅に軽減できます。
ポータブルインターセプターは、CORBAおよびRMI-IIOPがCORBAシステムの最も重要な機能を仲介するために使用する「フック」です。CORBA規格では、以下の種類のインターセプターが定義されています。
インターセプターは、送信されるメッセージや作成されるIORに特定の情報を付加することができます。この情報は、リモート側の対応するインターセプターによって後で読み取ることができます。インターセプターは、転送例外をスローして、リクエストを別のターゲットにリダイレクトすることもできます。
GIOPは、オブジェクトリクエストブローカー（ORB）間の通信を行うための抽象プロトコルです。このプロトコルに関連する標準規格は、オブジェクト管理グループ（OMG）によって維持されています。GIOPアーキテクチャは、以下のような具体的なプロトコルを提供します。
各標準CORBA例外には、例外のサブカテゴリを指定するためのマイナーコードが含まれています。マイナー例外コードは符号なしロング型で、上位20ビットを占める20ビットの「ベンダーマイナーコードセットID」（VMCID）と、下位12ビットを占めるマイナーコード本体で構成されます。
標準例外のマイナーコードには、OMG に割り当てられた VMCID が先頭に付きます。これは、符号なし long 定数 CORBA::OMGVMCID として定義され、OMG に割り当てられた VMCID が上位 20 ビットを占めます。3-58 ページの表 3-13 に記載されている標準例外に関連付けられたマイナー例外コードは、OMGVMCID と OR 演算され、ex_body 構造体で返されるマイナーコード値を取得します。[ 6 ]
ベンダーが割り当てたスペース内では、マイナーコードへの値の割り当てはベンダーに委ねられています。[ 7 ] [ 8 ]
VMCID 0 と0xfffffは実験用に予約されています。VMCID OMGVMCID [ 9 ]と 1 ～0xfは OMG 用に予約されています。[ 10 ]
Corba Location (CorbaLoc) は、URL に似た、CORBA オブジェクトの文字列化されたオブジェクト参照を指します。
すべてのCORBA製品は、OMGで定義された2つのURL、「corbaloc:」と「corbaname:」をサポートする必要があります。これらの目的は、IORを取得できる場所を人間が読みやすく編集しやすい方法で指定できるようにすることです。
以下に、コルバロックの例を示します。
CORBA製品は、オプションで「http:」、「ftp:」、「file:」形式をサポートする場合があります。これらの形式は、文字列化されたIORをダウンロードする方法（または、再帰的に、最終的に文字列化されたIORを提供する別のURLをダウンロードする方法）の詳細を提供します。一部のORBは、そのORB独自の追加形式を提供します。
CORBAの利点としては、言語やOSに依存しないこと、技術に依存した実装から解放されること、強力なデータ型定義、高いレベルの調整可能性、分散データ転送の詳細から解放されることなどが挙げられます。
CORBAは、エンジニアが設計を特定のソフトウェア言語に縛られるという制約から解放されるために設計されました。現在、様々なCORBAプロバイダーが多くの言語をサポートしており、中でもJavaとC++が最も人気があります。その他にも、C++11、C言語のみ、Smalltalk、Perl、Ada、Ruby、Pythonなどの実装が存在します。
歴史的に、Java は標準ライブラリの一部として、パッケージでCORBA をサポートしていましたorg.omg.CORBA.*。これらはその後、Java 9 で非推奨となり、Java 11 で削除されました。[ 11 ]
CORBAはOSに依存しないように設計されています。CORBAはJava（OS非依存）で利用できるほか、Linux/Unix、Windows、Solaris、OS X、OpenVMS、HPUX、Android、LynxOS、VxWorks、ThreadX、INTEGRITYなど、様々なOS向けにネイティブで提供されています。
CORBAの主な利点の1つは、エンジニアがさまざまな新規システムと既存システム間のインターフェースを標準化できる中立的な環境を提供することです。C、C++、Object Pascal、Java、Fortran、Python、その他あらゆる言語やOSを単一の統合されたシステム設計モデルに統合する場合、CORBAは公平な環境を提供し、異なるチームがシステムと単体テストを開発し、それらを後で統合してシステム全体を構築できるようにします。これは、スレッド処理、タイミング、オブジェクトのライフサイクルなど、基本的なシステムエンジニアリング上の決定の必要性を排除するものではありません。これらの問題は、テクノロジーに関係なく、あらゆるシステムの一部です。CORBAは、システム要素を単一の統合されたシステムモデルに標準化することを可能にします。
例えば、 WebサーバーにJavaサーブレットを使用し、ビジネスロジックを格納してデータベースアクセスをラップする様々なCORBAサーバーを用いることで、マルチティアアーキテクチャの設計が簡素化されます。これにより、ビジネスロジックの実装は変更可能になりますが、インターフェースの変更は他のテクノロジーと同様に処理する必要があります。例えば、サーバーでラップされたデータベースは、ディスク使用量やパフォーマンスの向上（あるいはデータベースベンダー全体の変更）のためにデータベーススキーマを変更しても、外部インターフェースには影響を与えません。同時に、C++のレガシーコードはC/FortranのレガシーコードやJavaデータベースコードと通信でき、Webインターフェースにデータを提供できます。
CORBAは、例えば「ANY」データ型のような柔軟なデータ型定義機能を提供します。また、CORBAは密結合なデータ型定義を強制することで、人為的なミスを減らします。名前と値のペアがやり取りされる状況では、サーバーが文字列を期待していた箇所に数値を返すといったことが考えられます。CORBAインターフェース定義言語は、ユーザーコードがメソッド名、戻り値、パラメータの型、および例外に準拠していることを保証するメカニズムを提供します。
多くの実装（例えば、ORBexpress（Ada、C++、Javaによる実装）[ 12 ]やOmniORB（オープンソースのC++およびPythonによる実装）[ 13 ]）には、スレッド処理や接続管理機能を調整するためのオプションがあります。すべてのORB実装が同じ機能を提供するわけではありません。
低レベルの接続とスレッド処理を扱う際、CORBAはエラー状態に関する詳細な情報を提供します。これは、CORBAで定義された標準例外セットと、実装固有の拡張例外セットによって定義されます。例外を通じて、アプリケーションは呼び出しが「小さな問題なので再試行してください」、「サーバーがダウンしています」、「参照が意味をなしません」などの理由で失敗したかどうかを判断できます。一般的なルールは、例外が発生しない場合はメソッド呼び出しが正常に完了したということです。これは非常に強力な設計機能です。
CORBAはデータをバイナリ形式でマーシャリングし、圧縮をサポートしています。IONA、Remedy IT、およびTelefónicaは、圧縮機能を提供するCORBA標準の拡張機能の開発に取り組んできました。この拡張機能はZIOPと呼ばれ、現在では正式なOMG標準となっています。
CORBAはコードの書き方やソフトウェアの構築方法において多くの成果をもたらしたが、批判の対象にもなってきた。[ 14 ]
CORBAに対する批判の多くは、標準規格自体の欠陥というよりも、標準規格の実装の不備に起因している。標準規格自体の失敗の一部は、CORBA仕様が作成されたプロセス、そして多くの競合する実装者によって作成された共通標準規格の策定に伴う政治的・ビジネス的な妥協に起因している。
CORBAの初期仕様では、IDLのみが定義されており、ネットワーク上のフォーマットは定義されていませんでした。そのため、ソースコードの互換性に関しては、数年間は現状では最高レベルにとどまっていました。CORBA 2以降では、この問題は解決されました。
CORBAのロケーション透過性の概念は批判されてきました。つまり、同じアドレス空間に存在し、単純な関数呼び出しでアクセスできるオブジェクトは、他の場所に存在するオブジェクト（同じマシン上の異なるプロセス、または異なるマシン）と同じように扱われるということです。これは根本的な設計上の欠陥です[ 15 ]。なぜなら、すべてのオブジェクトアクセスが最も複雑なケース（つまり、ローカル呼び出しでは発生しない広範なクラスの障害を伴うリモートネットワーク呼び出し）と同じくらい複雑になるからです。また、2つのクラス間の避けられない違いを隠蔽し、アプリケーションが適切な使用戦略（つまり、呼び出しと1μsのレイテンシ と保証されたリターンは、呼び出しとは全く異なる方法で使用されます。1 秒の遅延があり、輸送障害が発生する可能性があり、その場合、配送状況は不明で、30 秒でタイムアウト）。
CORBA標準の作成は、委員会による設計プロセスでもよく言及される。相反する提案を仲裁したり、取り組むべき問題の階層を決定したりするプロセスはなかった。そのため、標準はすべての提案の機能を統合することによって作成され、それらの整合性は考慮されなかった。[ 16 ]このため、仕様は複雑になり、完全に実装するにはコストがかかり、しばしば曖昧になった。
実装ベンダーと顧客が混在する設計委員会は、多様な利害関係を生み出した。この多様性により、統一された標準の策定が困難になった。標準と相互運用性により競争が激化し、顧客が代替実装間を移動しやすくなった。これにより、委員会内で多くの政治的な争いが起こり、CORBA標準の改訂版が頻繁にリリースされたが、一部のORB実装者は、独自の拡張機能なしでは使用しにくいようにした。[ 14 ]倫理観に欠けるCORBAベンダーは顧客の囲い込みを奨励し、短期的に大きな成果を上げた。時間の経過とともに、移植性を奨励するORBベンダーが市場シェアを獲得した。
CORBAは、その歴史を通じて、ORB実装の不備に悩まされてきた。残念ながら、CORBAを標準規格として批判する論文の多くは、単に特定のCORBA ORB実装の不備を批判しているに過ぎない。
CORBAは多くの機能を備えた包括的な標準規格です。仕様のすべてを実装しようとする実装はほとんどなく、[ 16 ]初期の実装は不完全または不十分でした。参照実装を提供する義務がなかったため、メンバーは有用性や実装可能性がテストされないまま、自由に機能を提案できました。標準規格が冗長になりがちであることや、提出されたすべての提案をまとめて採用するという一般的な慣行によって、実装はさらに阻害されました。その結果、個々の提案が完全に合理的であっても、一貫性がなく使いにくいAPIが作成されることがよくあります。
かつては堅牢なCORBA実装を入手するのは非常に困難でしたが、現在でははるかに容易に入手できるようになりました。しかし、設計の不十分な実装の中には、複雑で動作が遅く、互換性がなく、不完全なものもありました。堅牢な商用版も登場しましたが、高額でした。質の高い無料の実装が利用可能になると、質の低い商用実装は急速に姿を消しました。
CORBA（より正確にはGIOP）は、特定の通信トランスポートに縛られるものではありません。GIOPの特殊な形態として、インターネットインターORBプロトコル（IIOP）があります。IIOPは、生のTCP/IP接続を使用してデータを送信します。
クライアントが非常に制限の厳しいファイアウォールまたは透過型プロキシサーバー環境の背後にあり、外部へのHTTP接続をポート 80 経由でのみ許可している場合、問題のプロキシサーバーがHTTP CONNECTメソッドまたはSOCKS接続も許可しない限り、通信は不可能になる可能性があります。かつては、実装に単一の標準ポートを使用させることさえ困難で、代わりに複数のランダムなポートを選択する傾向がありました。現在、最新の ORB にはこれらの欠点があります。このような困難のため、一部のユーザーはCORBA の代わりにWeb サービスの使用を増やしています。これらのサービスは、通常組織内で HTTP による Web ブラウジングのために開いているか、HTTP プロキシを介してフィルタリングされているポート 80 を介してXML / SOAP を使用して通信します。ただし、最近の CORBA 実装はSSL をサポートしており、単一のポートで動作するように簡単に構成できます。TAO、omniORB、JacORB などの一部の ORB は双方向GIOPもサポートしており、Web サービス実装の特徴であるポーリング方式ではなく、コールバック通信を使用できるという利点を CORBA にもたらします。また、最新のファイアウォールのほとんどはGIOPとIIOPをサポートしており、CORBAに対応したファイアウォールとなっています。
