3

これまで私が知っていると思うのは、CORBA仕様自体では、サーバープログラムが使用するIDLとクライアントプログラムが使用するIDLの違いは認められていないということです。

ただし、実際には、基礎となる通信メカニズムはおそらくGIOP（少なくともIIOP）であり、一部の違いはIIOPを介して検出できないため、特定の違いは（かなり）普遍的に機能します。

私が確立したいのは、GIOP / IIOPが使用されている限り、サーバーとクライアントのIDL間で任意のORB間で普遍的にどのような違いが許容されるかということです。

例：これまでのところ、次のように機能すると思います。

  • クライアントIDLが認識しているタイプが変更されていないか、不明な新しいタイプがクライアントに返送されない限り、サーバーIDLにタイプ/インターフェイスを追加します。
  • サーバー側の既存のインターフェースにメソッドを追加します。クライアントは、IDLにメソッドがリストされていなくても、このインターフェースを使用してオブジェクトの呼び出しを続行できる必要があります。（これはここでyesで答えられるようです。）
  • クライアントがこの新しい値を決して見ない限り、列挙型の最後にメンバーを追加します。
  • 識別子が新しい値に設定されたこのUnionタイプがクライアントに表示されない限り、メンバーをユニオンに追加します。

私の目的は、既存のIDLで実行できるものの短いリストのようなものに到達し、変更されたIDLを使用して既存のクライアントを再コンパイルすることなく「サーバー」を新しいもので拡張することです。

4

1 に答える 1

1

  • はい、サーバーとクライアントのメソッドセットは、メソッドが名前（GIOPメッセージの操作フィールド）によって独立してアクセスされるため、完全に一致する必要はありません。つまり、GIOP呼び出しにはメソッド名が文字列として含まれ、後でパラメーターはこのパラメーターで期待されるとおりにエンコードされます。CORBAタイとCORBAスタブの例を参照してください。

  • はい、新しいインターフェイスを作成してエクスポートする場合、それは単なる新しいインターフェイスです。他の名前サービスとは独立して任意のネームサービスにバインドでき、この新しいインターフェイスを認識していないクライアントはそれを使用できなくなります。は、同じネームサービスにバインドされた既知のタイプを使用できるようになります。

  • はい、GIOPは列挙型をunsigned longとして書き込みます。最初の値は常にゼロとしてエンコードされ、連続する識別子は左から右への宣言の順に昇順の数値を取ります。したがって、新しい列挙型IDを追加することは完全に安全ですが、削除したり、並べ替えたりすることはできません。

GIOP仕様を読んで、大いに役立ちます。また、IDLコンパイラによって生成されたコードと、IDLで何かが変更されたときにどのように変更されるかを調べることも非常に良いことです。

互換性のない変更を導入するのも簡単であるため、注意が不足しているという理由だけで、不一致のIDLを使用することは確かに良い習慣ではありません。これは、クライアントがユーザーにリリースされたためにクライアントに到達して更新できなくなった場合にのみ意味があります。

于 2013-01-13T13:13:10.267 に答える