問題タブ [corba]

既存のサーバーのCORBAインターフェイスにメソッドを追加したいと思います。すべてのクライアントを再コンパイルする必要がありますか？

TAOを使用しています。

Excel からいくつかの EJB にアクセスできるようにしたいと考えています。目標は、VBA から使用できる API を提供することです。

私たちの EJB はほとんどが、POJO で単純な CRUD 操作を行うステートレス セッション Bean です。

考えられる解決策:

• EJB を Web サービスとして公開し、それらをラップする VB/C# dll を作成します。
• Corba を使用して C# から EJB にアクセスし、
• Java を使用して EJB にアクセスする COM ライブラリを作成します。

これらのソリューションやその他のアイデアのフレームワークへのポインタは大歓迎です。

AS3 や Flex/AIR アプリケーションを CORBA アプリケーションと通信させるにはどうすればよいですか?

私は、さまざまな宛先固有のプロトコルを使用して、一連の宛先（具体的には、株式オプション交換）と通信する.NETベースのサーバーコンポーネントに取り組んでいます。次に追加する予定の宛先はCORBAを使用しているため、CORBAを話すことができる.NETライブラリを調査しています。

これまでのところ、私は3つの可能性を見つけました。

• IIOP.NETは、成熟していてかなり活発なように見えるオープンソースプロジェクトです。
• J-Integra Espressoは、IntrinsycのMicrosoft<->Java相互運用性ツールスイートの1つです。
• VisiBroker for .NET（以前の名前は「Janeva」）は、BorlandのVisiBrokerCORBAパッケージのモジュールです。

良いか悪いかにかかわらず、誰かがこれらのいずれかを経験したことがありますか？

他に選択肢はありますか？

ネイティブ管理のC++/ CLIコードを組み合わせて、C ++ベースのCORBAライブラリの1つ（omniORBとTAOが上位2つに見えますが、他にもあります）を使用できますが、データはの管理コアとの間でやり取りする必要があります。ある時点でサーバーがマーシャリングのパフォーマンスコストを追加し、混合コードシナリオでネイティブC++ライブラリを使用するのはかなり苦痛になる傾向があります。

更新-IIOP.NETの使用を開始しましたが、これまでのところかなり良好に見えています。最新バージョン（1.9 sp1）のパフォーマンスは許容範囲内のようであり、APIはかなり使いやすいです。Todd Stoutが提案したIKVMを間違いなく見ていきます。これは、IIOP.NETがうまく機能しない場合、非常に興味深い可能性のように見えます。

アップデート＃2（2010年7月）-しばらくの間、本番環境でIIOP.NETを使用しており、良好な結果が得られています。IIOP.NETプロジェクトは、私がアクティブと呼ぶものとは正確には異なりますが、CORBAでもないため、これ以上の開発はそれほど必要ではないようです。

CORBA を介して対話する C++ および Java モジュールを含む分散アプリケーションがあります。

「変数」と「メソッド」を JMX ツールに公開する (統合管理を作成する) ための C++ ライブラリ/ツールはありますか?

開発マシンとラボ システムで完全に動作する Java アプリを作成したところ、問題が発生しましたが、クライアント マシンにインストールすると、次のエラーが表示されます。

org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0

誰が何が間違っているのか考えていますか? Jar ファイルがありませんか? または、クライアントに間違ったバージョンの Java がインストールされている可能性がありますか?

通信に CORBA を使用して Java で記述されたクライアント/サーバー アプリケーションがあります。使用される ORB は、Java6 プラットフォームによって提供される orbd です。Java サーバーの実装を C++ で記述された別のものに置き換える必要があります。問題は、CORBA ライブラリのフリー ソース実装のうち、どれがこの ORB とより適切に相互運用できるかということです。Java ORB を置き換えて、C++ ライブラリが提供する ORB も使用する必要がありますか?

目的は、すでに機能しているサーバーを新しい C++ 実装に置き換えるときに、簡単かつスムーズに移行できるようにすることです。他に考慮すべきことはありますか？

比較的粗粒度の並列処理 (データ転送は 100 Mbit イーサネット ネットワークで実行できます) の場合、Windows と Linux で利用できるミドルウェアはどれが最適だと思いますか? コルバ？MPI1? MPI2? XML-RPC/SOA/WSDL? カスタム ネットワーク プロトコル? ジャバRPC？パイソン RPC? その他？

私は、コンポーネント ベースのプログラミング (COM、別のシステム、または単純な C++ のパラダイムを使用するもの) に夢中になっています。「伝統的な」OOPモデルに通常慣れている場合は、少し慣れる必要がありますが、それだけの価値はあります。コードの保守性と拡張性が向上しました。

私が現在取り組んでいるプロジェクトは、パラダイムを使用していますが、セットのシステムはありません。ただし、次の要件で使用できる何らかのシステムを見つけたいと思っています。現在使用しているシステムから新しいシステムに切り替えるには少し時間がかかりますが、後でその時間を何倍も節約できます。

要求事項：

1. クロスプラットフォーム
2. 速い
3. C++ でうまく動作する
4. プロセス間のマーシャリングをサポート

これらの要件について詳しく説明しましょう。

クロスプラットフォーム

基本的に、Windows と Mac で動作する必要があります。Linux は便利ですが、必須ではありません。また、すべてのプラットフォームの他の要件を満たす必要があります。Mac 用の COM があります。これは理想的ですが、要件 4 をサポートしていません。さらに、GCC と MSVC の両方をサポートする必要があります。

速い

CORBA は他の 3 つの要件を満たしていますが、残念ながらここで不利になります。一部のルーチンはオーディオ割り込みからも呼び出される可能性があるため、インプロセス メソッド呼び出しは (理想的には COM のように) できるだけ高速である必要があります。

C++ でうまく動作する

...これはほとんど明らかだと思います。コンポーネントを実装するために C++ クラスを使用しなくてもかまいませんが、それは間違いなく役に立ちます。また、最終的にはサードパーティの拡張機能用の API をリリースする予定であるため、代替手段は依然として使いやすいものでなければなりません。

プロセス間のマーシャリングをサポート

つまり、少なくとも呼び出しをシリアル化できるということです。これが IDL から生成されたコードを介して行われる場合、それは私にとってまったく問題ありません。また、クロスプロセス通信自体を実装することも気にしません。

COM は優れていますが、要件 1 を完全には満たしていません。CORBA も優れていますが、要件 2 を満たしていません (最速の ORB を使用しても)。XPCOM は要件 2 を満たしていない可能性があり、MSVC では動作しないため、要件 1 を満たしていません。

他に何がありますか？私の次のステップは、protobufs などを使用して自分で作成することですが、もちろんそれは避けたいと思います。

アップデート

詳しく説明すると、このコンテキストでの音声割り込みは 2 ～ 3 ミリ秒まで低くなる可能性があります。他のコンポーネントはその時間内に処理する必要があり、私のソフトウェア自体は、その時間内に処理する必要がある別のソフトウェアをラップしているため、その時間は完全には利用できません。これが、インプロセス マーシャリングとクロスプロセス マーシャリングの両方が非常に高速である必要がある理由です。

私はしばらくCorbaクライアントに取り組んでいます。私が遭遇した問題の 1 つは、タイムアウト構成を実際に定義できないことです。

私は Mico C++ orb を使用していますが、要求タイムアウトを構成する Corba 定義のメソッドがあるかどうかを説明できる人が誰もいないため、これはグローバルな問題のようです。

そのようなインターフェースまたはオーブの初期化を知っている人はいますか?