Common Object Request Broker Architecture

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

Common Object Request Broker Architecture
状態公開済み
年が始まった1991 ; 30年前 (1991
最新バージョン3.4
2021年2月; 9ヶ月前 (2021-02
組織オブジェクト管理グループ
略語CORBA
Webサイトcorba .org

共通オブジェクト・リクエスト・ブローカ・アーキテクチャCORBAは)あり、標準で定義されたオブジェクト管理グループの多様なプラットフォーム上で展開されているシステムの通信を容易にするために設計された(OMG)。CORBAは、異なるオペレーティングシステム、プログラミング言語、およびコンピューティングハードウェア上のシステム間のコラボレーションを可能にします。CORBAはオブジェクト指向モデルを使用しますが、CORBAを使用するシステムはオブジェクト指向である必要はありません。CORBAは、分散オブジェクトパラダイムの例です

概要

CORBAは、異なる言語で記述され、異なるコンピューターで実行されているソフトウェア間の通信を可能にします。特定のオペレーティングシステム、プログラミング言語、およびハードウェアプラットフォームからの実装の詳細はすべて、CORBAを使用する開発者の責任から除外されます。CORBAは、同じアドレス空間(アプリケーション)またはリモートアドレス空間(同じホスト、またはネットワーク上のリモートホスト)に存在するアプリケーションオブジェクト間のメソッド呼び出しセマンティクスを正規化します。バージョン1.0は1991年10月にリリースされました。

CORBAは、インターフェイス定義言語(IDL)を使用して、オブジェクトが外界に提示するインターフェイスを指定します。次に、CORBAは、IDLからC ++Javaなどの特定の実装言語へのマッピング指定しますAdaCC ++C ++ 11COBOLJavaLispPL / IObject PascalPythonRubySmalltalkの標準マッピングが存在します。非標準のマッピングがC#ErlangPerlTcl、およびVisual Basicは、これらの言語用に作成されたオブジェクトリクエストブローカー(ORB)によって実装されます

CORBA仕様では、アプリケーションが他のオブジェクトと対話するためのORBが存在する必要があります。これが実際の実装方法です。

  1. アプリケーションはORBを初期化し、内部オブジェクトアダプターにアクセスします。このアダプターは参照カウント、オブジェクト(および参照)インスタンス化ポリシー、オブジェクト存続期間ポリシーなどを維持します。
  2. オブジェクトアダプタは、生成されたコードクラスのインスタンスを登録するために使用されます。生成されたコードクラスは、ユーザーIDLコードをコンパイルした結果です。これにより、高レベルのインターフェイス定義が、ユーザーアプリケーションで使用できるようにOSおよび言語固有のクラスベースに変換されます。この手順は、CORBAセマンティクスを適用し、CORBAインフラストラクチャとインターフェイスするためのクリーンなユーザープロセスを提供するために必要です。

一部のIDLマッピングは、他のマッピングよりも使用が困難です。たとえば、Javaの性質上、IDL-Javaマッピングはかなり単純であり、JavaアプリケーションでのCORBAの使用が非常に簡単になります。これは、IDLからPythonへのマッピングにも当てはまります。 C ++マッピングでは、プログラマーはC ++標準テンプレートライブラリ(STL)より前のデータ型を学習する必要があります。対照的に、C ++ 11マッピングは使いやすいですが、STLを多用する必要があります。 C言語はオブジェクト指向ではないため、IDLからCへのマッピングでは、Cプログラマーがオブジェクト指向機能を手動でエミュレートする必要があります。

CORBAベースの分散オブジェクトインターフェイスを使用または実装するシステムを構築するには、開発者は、システムが使用または実装するロジックへのオブジェクト指向インターフェイスを定義するIDLコードを取得または作成する必要があります。通常、ORB実装には、IDLインターフェースをシステムのその部分で使用するためのターゲット言語に変換するIDLコンパイラーと呼ばれるツールが含まれています。次に、従来のコンパイラは、生成されたコードをコンパイルして、アプリケーションで使用するためのリンク可能なオブジェクトファイルを作成します。この図は、生成されたコードがCORBAインフラストラクチャ内でどのように使用されるかを示しています。

CORBAIDLを使用して定義されたインターフェイスからのインフラストラクチャコードの自動生成の図

この図は、CORBAを使用したリモートプロセス間通信の高レベルのパラダイムを示しています。 CORBA仕様では、データの入力、例外、ネットワークプロトコル、通信タイムアウトなどにさらに対応しています。例:通常、サーバー側には、呼び出しをローカルサーバントまたは(負荷のバランスを取るために)にリダイレクトするポータブルオブジェクトアダプター(POA)があります。他のサーバー。 CORBA仕様(したがってこの図)は、分散システムのさまざまな側面をアプリケーションに任せて、オブジェクトの存続期間(参照カウントのセマンティクスはアプリケーションで使用できます)、冗長性/フェイルオーバー、メモリ管理、動的負荷分散、アプリケーションなどを定義します。表示/データ/制御セマンティクス間の分離などの指向モデル(例:を参照)Model-view-controller)など。

CORBAは、言語とプラットフォームに依存しないリモートプロシージャコール(RPC)仕様をユーザーに提供することに加えて、トランザクションとセキュリティ、イベント、時間、その他のドメイン固有のインターフェイスモデルなどの一般的に必要なサービスを定義します。

バージョン履歴

この表は、CORBA標準バージョンの履歴を示しています。[1] [2]

バージョン バージョン日付 ハイライト
1.0 1991年10月 最初のバージョン、Cマッピング
1.1 1992年2月 相互運用性、C ++マッピング
1.2 1993年12月 -
2.0 1996年8月 また、吹き替え標準の最初のメジャーアップデート、CORBA 2
2.1 1997年8月 -
2.2 1998年2月 Javaマッピング
2.3 1999年6月 -
2.4 2000年8月 -
2.5 2001年9月 -
2.62.6 2001年12月 -
3.0 2002年7月 標準の2番目のメジャーアップデートで、CORBA 3
CORBAコンポーネントモデル(CCM)とも呼ばれます。
3.0.1 2002年11月 -
3.0.2 2002年12月 -
3.0.3 2004年3月 -
3.1 2008年1月 -
3.1.1 2011年8月 ISO / IEC19500の2012年版として採用
3.2 2011年11月 -
3.3 2012年11月 ZIOPの追加
3.43.4 2021年2月

使用人

サーバントは、処理するための方法を含む、呼び出し対象となるリモート・メソッド呼び出しを。新しいCORBAバージョンでは、リモートオブジェクト(サーバー側)は、オブジェクト (リモート呼び出しに公開される)サーバント (前の部分メソッド呼び出しを転送する)に分割されますリモートオブジェクトごとに1つのサーバントにすることも、同じサーバントが特定のポータブルオブジェクトアダプタに関連付けられた複数の(場合によってはすべての)オブジェクトをサポートすることもできますオブジェクト使用人「一度限り」(サーバントのアクティブ化)に設定または検出するか、そのオブジェクトのメソッドが呼び出されるたびに動的に選択することができます(サーバントの場所)。使用人ロケーターと使用人アクティベーターの両方が、呼び出しを別のサーバーに転送できます。全体として、このシステムは、負荷を分散し、複数のマシン間で要求を分散するための非常に強力な手段を提供します。オブジェクト指向言語では、リモートオブジェクトとそのサーバントの両方がオブジェクト指向プログラミングの観点からのオブジェクトです。

インカネーションとは、使用人をCORBAオブジェクトに関連付けて、要求を処理できるようにする行為です。Incarnationは、仮想CORBAオブジェクトの具体的なサーバントフォームを提供します。アクティブ化と非アクティブ化はCORBAオブジェクトのみを指し、化身とエーテル化という用語は使用人を指します。ただし、オブジェクトと使用人の寿命は独立しています。activate_object()を呼び出す前に、常にサーバントをインカネートしますが、その逆も可能です。create_reference()は、サーヴァントをインカネートせずにオブジェクトをアクティブ化し、サーヴァントのインカネーションは、後でサーバントマネージャを使用してオンデマンドで実行されます。

NS Portable Object Adapter(POA)は、サーバー側のリモート呼び出しハンドラーをリモートオブジェクトとそのサーバントに分割するCORBAオブジェクトです。オブジェクトはリモート呼び出しに対して公開されますが、サーバントには実際に要求を処理しているメソッドが含まれています。各オブジェクトのサーバントは、静的(1回)または動的(リモート呼び出しごと)のいずれかで選択でき、どちらの場合も、別のサーバーへのコール転送が可能です。

サーバー側では、POAはツリーのような構造を形成し、各POAは提供される1つ以上のオブジェクトを担当します。このツリーのブランチは、個別にアクティブ化/非アクティブ化でき、サーバントの場所またはアクティブ化のコードが異なり、リクエスト処理ポリシーも異なります。

機能

以下では、CORBAを使用して分散オブジェクト間の通信を容易にする最も重要な方法のいくつかについて説明します。

参照によるオブジェクト

この参照は、文字列化されたURL(Uniform Resource Locator)、NameServiceルックアップ(ドメインネームシステム(DNS)と同様)を介して取得されるか、呼び出し中にメソッドパラメーターとして渡されます。

オブジェクト参照は、実際のオブジェクト(リモートまたはローカル)のインターフェイスに一致する軽量オブジェクトです。参照に対するメソッド呼び出しは、ORBへの後続の呼び出しを引き起こし、応答、成功、または失敗を待つ間、スレッドをブロックします。パラメータ、戻りデータ(存在する場合)、および例外データは、ローカル言語とOSマッピングに従ってORBによって内部的にマーシャリングされます。

値によるデータ

CORBAインターフェイス定義言語は、言語およびOSに依存しないオブジェクト間通信定義を提供します。CORBAオブジェクトは参照によって渡されますが、データ(整数、倍精度浮動小数点数、構造体、列挙型など)は値によって渡されます。参照によるオブジェクトと値によるデータの組み合わせは、クライアントとサーバーのコンパイル中に優れたデータ入力を強制する手段を提供しますが、CORBA問題空間に固有の柔軟性を維持します。

値によるオブジェクト(OBV)

リモートオブジェクトとは別に、CORBAとRMI-IIOPはOBVとValuetypesの概念を定義します。Valuetypeオブジェクトのメソッド内のコードは、デフォルトでローカルで実行されます。OBVがリモート側から受信された場合、必要なコードは、両方の側で事前に認識されているか、送信者から動的にダウンロードされている必要がありますこれを可能にするために、OBVを定義するレコードには、このコードをダウンロードする必要があるURLのスペースで区切られたリストであるコードベースが含まれています。OBVはリモートメソッドを持つこともできます。

CORBAコンポーネントモデル(CCM)

CORBAコンポーネントモデル(CCM)は、CORBA定義のファミリーに追加されたものです。[3] CORBA 3で導入され、CORBAコンポーネントの標準アプリケーションフレームワークについて説明しています。 「言語依存のEnterpriseJava Beans(EJB)」には依存しませんが、EJBのより一般的な形式であり、EJBが定義する2つではなく4つのコンポーネントタイプを提供します。これは、ポートと呼ばれる明確に定義された名前付きインターフェイスを介してサービスを提供および受け入れることができるエンティティの抽象化を提供します

CCMには、ソフトウェアコンポーネントを展開できるコンポーネントコンテナがあります。コンテナは、コンポーネントが使用できる一連のサービスを提供します。これらのサービスには通知認証永続性トランザクション処理が含まれます(ただし、これらに限定されません)これらは、分散システムが必要とする最も使用されているサービスであり、これらのサービスの実装をソフトウェアコンポーネントからコンポーネントコンテナに移動することにより、コンポーネントの複雑さが劇的に軽減されます。

ポータブル迎撃機

ポータブルインターセプターは「フック」であり、CORBAおよびRMI-IIOPがCORBAシステムの最も重要な機能を仲介するために使用します。CORBA標準では、次のタイプのインターセプターが定義されています。

  1. IORインターセプターは、現在のサーバーによって提示されるリモートオブジェクトへの新しい参照の作成を仲介します。
  2. クライアントインターセプターは通常、クライアント(呼び出し元)側でリモートメソッド呼び出しを仲介します。オブジェクトServantがメソッドが呼び出されるのと同じサーバーに存在する場合、それらはローカル呼び出しも仲介します。
  3. サーバーインターセプターは、サーバー(ハンドラー)側でのリモートメソッド呼び出しの処理を仲介します。

インターセプターは、送信されるメッセージと作成されるIORに特定の情報を添付できます。この情報は、後でリモート側の対応するインターセプターで読み取ることができます。インターセプターは、転送例外をスローして、要求を別のターゲットにリダイレクトすることもできます。

General InterORB Protocol(GIOP)

GIOPは、それによって抽象プロトコルであるオブジェクト・リクエスト・ブローカー(ORBには)通信します。プロトコルに関連付けられている標準は、Object Management Group(OMG)によって維持されています。GIOPアーキテクチャは、次のようないくつかの具体的なプロトコルを提供します。

  1. インターネットInterORBプロトコル(IIOP)–インターネットInter-Orbプロトコルは、インターネット上使用するためのGIOPの実装であり、GIOPメッセージとTCP / IP層の間のマッピングを提供します
  2. SSL InterORBプロトコル(SSLIOP)– SSLIOPはSSLを介したIIOPであり暗号化認証を提供します
  3. HyperText InterORBプロトコル(HTIOP)–HTIOPはIIOPover HTTPであり、透過的なプロキシバイパスを提供します。
  4. 圧縮IOP(ZIOP)–帯域幅の使用量を削減する圧縮バージョンのGIOP。

VMCID(ベンダーマイナーコードセットID)

各標準CORBA例外には、例外のサブカテゴリを指定するためのマイナーコードが含まれています。マイナー例外コードはunsignedlong型であり、上位20ビットを占める20ビットの「ベンダーマイナーコードセットID」(VMCID)と、下位12ビットを占める適切なマイナーコードで構成されます。

標準例外のマイナーコードの前には、OMGに割り当てられたVMCIDがあります。これは、符号なしの長い定数CORBA :: OMGVMCIDとして定義され、OMGに割り当てられたVMCIDが上位20ビットを占めます。 3-58ページの表3–13にある標準例外に関連付けられたマイナー例外コードは、OMGVMCIDと組み合わせて、ex_body構造体で返されるマイナーコード値を取得します(セクション3.17.1「標準」を参照)。例外の定義」(3-52ページ)およびセクション3.17.2「標準のマイナー例外コード」(3-58ページ)。

ベンダーが割り当てたスペース内では、マイナーコードへの値の割り当てはベンダーに任されています。ベンダーは、tagrequest @ omg.orgに電子メールを送信してVMCIDの割り当てを要求できます。現在割り当てられているVMCIDのリストは、OMG Webサイト(http://www.omg.org/cgi-bin/doc?vendor-tags)にあります。

VMCID 0および0xfffffは、実験用に予約されています。VMCID OMGVMCID(セクション3.17.1、「標準例外定義」、(3-52ページ))および1から0xfは、OMGで使用するために予約されています。

Common Object Request Broker:アーキテクチャと仕様(CORBA 2.3)

チョルバの場所(CorbaLoc)

Corba Location(CorbaLoc)は、URLに似たCORBAオブジェクトの文字列化されたオブジェクト参照を参照します。

すべてのCORBA製品は、OMGで定義された2つのURL「corbaloc:」と「corbaname:」をサポートする必要がありますこれらの目的は、IORを取得できる場所を指定するための人間が読める形式と編集可能な方法を提供することです。

corbalocの例を以下に示します。

corbaloc :: 160.45.110.41:38693 / StandardNS / NameServer-POA / _root

CORBA製品は、オプションで「http:」、「ftp:」、および「file:」形式をサポートする場合があります。これらのセマンティクスは、文字列化されたIORをダウンロードする方法の詳細を提供することです(または、再帰的に、最終的に文字化されたIORを提供する別のURLをダウンロードします)。一部のORBは、そのORB独自の追加フォーマットを提供します。

メリット

CORBAの利点には、言語とOSに依存しないこと、テクノロジーにリンクされた実装から解放されること、強力なデータ入力、高レベルの調整可能性、分散データ転送の詳細から解放されることが含まれます。

言語の独立性
CORBAは、エンジニアが設計を特定のソフトウェア言語に結合するという制限から解放されるように設計されました。現在、さまざまなCORBAプロバイダーによってサポートされている多くの言語があり、最も一般的なのはJavaとC ++です。ほんの数例を挙げると、C ++ 11、Cのみ、Smalltalk、Perl、Ada、Ruby、Pythonの実装もあります。
OSに依存しない
CORBAの設計は、OSに依存しないことを目的としています。CORBAは、Java(OSに依存しない)で利用できるほか、Linux / Unix、Windows、Solaris、OS X、OpenVMS、HPUX、Android、LynxOS、VxWorks、ThreadX、INTEGRITYなどでネイティブに利用できます。
テクノロジーからの解放
主な暗黙の利点の1つは、CORBAが、エンジニアがさまざまな新しいシステムとレガシーシステム間のインターフェイスを正規化できるようにするための中立的な競争の場を提供することです。 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実装)[4]およびOmniORB(オープンソースC ++およびPython実装))[5]には、スレッド化および接続管理機能を調整するためのオプションがあります。すべてのORB実装が同じ機能を提供するわけではありません。
データ転送の詳細からの解放
低レベルの接続とスレッド化を処理する場合、CORBAはエラー状態で高レベルの詳細を提供します。これは、CORBA定義の標準例外セットおよび実装固有の拡張例外セットで定義されています。例外を通じて、アプリケーションは、「小さな問題なので、再試行してください」、「サーバーが停止している」、「参照が意味をなさない」などの理由で呼び出しが失敗したかどうかを判断できます。一般的なルールは次のとおりです。例外を受け取らないということは、メソッド呼び出しが正常に完了したことを意味します。これは非常に強力な設計機能です。
圧縮
CORBAは、データをバイナリ形式でマーシャリングし、圧縮をサポートします。IONA、Remedy IT、およびTelefónica圧縮を提供するCORBA標準の拡張に取り組んできました。この拡張機能はZIOPと呼ばれ、正式なOMG標準になりました。

問題と批判

CORBAは、コードの記述とソフトウェアの構築の方法で多くのことを実現しましたが、批判の対象となってきました。[6]

CORBAに対する批判の多​​くは、標準の実装が不十分であることに起因しており、標準自体の欠陥ではありません。標準自体の失敗のいくつかは、CORBA仕様が作成されたプロセスと、多くの競合する実装者によって提供された共通の標準を作成するという政治とビジネスに固有の妥協によるものでした。

初期実装の非互換性
CORBAの初期仕様では、IDLのみが定義されており、オンザワイヤ形式は定義されていません。これは、ソースコードの互換性が数年間利用可能な最高のものであることを意味しました。CORBA 2以降では、この問題は解決されました。
場所の透明性
CORBAの場所の透明性の概念は批判されています。つまり、同じアドレススペースにあり、単純な関数呼び出しでアクセスできるオブジェクトは、他の場所にあるオブジェクト(同じマシン上の異なるプロセス、または異なるマシン)と同じように扱われます。これは基本的な設計上の欠陥であり[7] [検証の失敗]、すべてのオブジェクトアクセスが最も複雑なケース(つまり、ローカルコールでは不可能な幅広いクラスの障害を伴うリモートネットワークコール)と同じくらい複雑になります。また、2つのクラス間の避けられない違いを隠し、アプリケーションが適切な使用戦略(つまり、1 µsの呼び出し)を選択できないようにします。 遅延と保証されたリターンは、配信ステータスが不明である可能性があり、タイムアウトに30秒かかる可能性がある、トランスポート障害の可能性がある1秒の遅延のあるコールとは非常に異なる方法で使用されます。
設計とプロセスの欠陥
CORBA標準の作成は、委員会による設計プロセスでもよく引用されます。相反する提案間で調停したり、取り組むべき問題の階層を決定したりするプロセスはありませんでした。したがって、この標準は、一貫性に関係なく、すべての提案の機能を結合することによって作成されました。[8]これにより、仕様が複雑になり、完全に実装するにはコストがかかり、多くの場合あいまいになりました。
実装ベンダーと顧客が混在する設計委員会は、さまざまな関心事を生み出しました。この多様性は、まとまりのある基準を難しくしました。標準と相互運用性により、競争が激化し、代替実装間の顧客の移動が容易になりました。これにより、委員会内で多くの政治的争いが発生し、CORBA標準の改訂版が頻繁にリリースされ、一部のORB実装者は独自の拡張なしでは使用が困難であることが保証されました。[6]倫理性の低いCORBAベンダーは、顧客のロックインを奨励し、強力な短期的な結果を達成しました。時間の経過とともに、移植性を促進するORBベンダーが市場シェアを引き継ぎました。[要出典]
実装に関する問題
その歴史を通じて、CORBAは不十分なORB実装の欠点に悩まされてきました。残念ながら、CORBAを標準として批判している論文の多くは、特に悪いCORBAORBの実装に対する批判にすぎません。
CORBAは、多くの機能を備えた包括的な標準です。すべての仕様を実装しようとする実装はほとんどなく[8]、最初の実装は不完全または不十分でした。リファレンス実装を提供するための要件が​​なかったため、メンバーは、有用性や実装可能性についてテストされたことのない機能を自由に提案できました。実装は、標準が冗長になるという一般的な傾向と、提出されたすべての提案の合計を採用することによる妥協の一般的な慣行によってさらに妨げられました。これにより、個々の提案が完全に合理的であったとしても、一貫性がなく使用が困難なAPIが作成されることがよくありました。 。[要出典]
CORBAの堅牢な実装は、これまで取得するのが非常に困難でしたが、今では見つけるのがはるかに簡単になっています。SUN Java SDKには、CORBAが組み込まれています。設計が不十分な実装の中には、複雑で、遅く、互換性がなく、不完全なものもあります。堅牢な商用バージョンが登場し始めましたが、かなりのコストがかかりました。質の高い無料の実装が利用可能になると、悪い商用実装はすぐに消滅しました。
ファイアウォール
CORBA(より正確にはGIOP)は、特定の通信トランスポートに関連付けられていません。GIOPの専門分野は、インターネットInter-ORBプロトコルまたはIIOPです。IIOPは、データを送信するために生のTCP / IP接続を使用します。
クライアントが非常に制限されたファイアウォールまたはポート80を介した外部へのHTTP接続のみを許可する透過プロキシサーバー環境の背後にある場合、問題のプロキシサーバーがHTTP CONNECTメソッドまたはSOCKS接続も許可しない限り、通信が不可能になる可能性があります。かつては、実装に単一の標準ポートを使用させることさえ困難でした。代わりに、複数のランダムなポートを選択する傾向がありました。今日の時点で、現在のORBにはこれらの欠陥があります。このような問題のために、一部のユーザーはCORBAの代わりにWebサービスの使用を増やしています。これらはXML / SOAPを使用して通信しますポート80を介して、通常は開いたままにするか、組織内のHTTPプロキシを介してフィルタリングし、HTTPを介したWebブラウジングを行います。ただし、最近のCORBA実装はSSLサポートしており、単一のポートで動作するように簡単に構成できます。TAO、omniORB、JacORBなどの一部のORBSは、双方向GIOPもサポートします。これにより、CORBAは、Webサービス実装に特徴的なポーリングアプローチではなく、コールバック通信を使用できるという利点が得られます。また、最新のファイアウォールのほとんどはGIOPとIIOPをサポートしているため、CORBAに適したファイアウォールです。

も参照してください

ソフトウェア工学

コンポーネントベースのソフトウェアテクノロジー

言語バインディング

参考文献

  1. ^ 「CORBAの歴史」Object ManagementGroup 2017年3月12日取得
  2. ^ 「CORBAの歴史」Object ManagementGroup 2017年6月4日取得
  3. ^ 「CORBAコンポーネントモデル」ドブ博士の日記2004年9月1日2017年3月13日取得
  4. ^ 「ORBexpress:リアルタイムCORBAORB」
  5. ^ "omniORB:無料のCORBAORB"sourceforge.net 取り出さ年1月9 2014
  6. ^ a b Chappel、David(1998年5月)。「CORBAのトラブル」davidchappel.com。2012年12月3日にオリジナルからアーカイブされまし取得した3月15日に2010
  7. ^ ウォルド、ジム; ジェフワイアント; アン・ウォルラス; サムケンダル(1994年11月)。「分散コンピューティングに関する注記」(PDF)サンマイクロシステムズラボラトリーズ検索された4年11月2013
  8. ^ a b ヘニング、ミチ(2006年6月30日)。「CORBAの興亡」ACMキューコンピューティングマシナリー協会4(5)取得した3月15日に2010

さらに読む

外部リンク