RPC と COM のバージョン管理理論

ワイヤ互換性の問題のリスクなしに新しい機能をサポートする完全に確実な方法は 2 つだけです。

• 規則に従ってインターフェイスのバージョンを変更します。これにより、新しいクライアントが古いサーバーと通信できなくなる可能性があり、古いクライアントが新しいサーバーと通信できなくなる可能性があります。 これについては、このセクションで後述します。
• 新しい機能を扱う別のインターフェイスを導入します。

標準 RPC インターフェイスは、GUID とバージョン番号の組み合わせによって識別されます。COM インターフェイスは、その GUID によって識別されます。 このバージョンは、メジャー パーツとマイナー パーツで構成されます。 同じ GUID と異なるバージョン番号を持つ標準インターフェイスの場合、接続はメジャー バージョンが同じで、クライアントがサーバーのマイナー バージョンよりも高くない場合にのみ可能です。

その結果、RPC インターフェイス GUID を変更するとワイヤの互換性が切断されますが、インターフェイス名を変更しても互換性が保たれてしまいます。

標準 RPC では、アップグレードと拡張機能のパスが明確に定義されており、基本的にはインターフェイスの最後にのみ新しいメソッドを追加し、新しいメソッドでのみ新しい型を使用する必要があります。 このような追加が必要な場合は、マイナー バージョンを増やす必要があります。 その他の変更では、クライアントとサーバー ソフトウェアがネットワーク上で互換性がないため、メジャー バージョンを変更する必要があります。 これらの規則に従うと、新しいクライアントと古いサーバーの間に接続がある場合、またはその逆の場合、両方の側が完全に互換性を持ちます。

COM インターフェイスの場合、version 属性は使用できません。 新しいインターフェイスを作成し、古いインターフェイスから継承することは、RPC でバージョンを操作することと同じです。 通常、COM の最適な方法は、拡張された機能用の新しいインターフェイスを作成することです。 マイナー バージョンに相当するのは、古いインターフェイスから継承する新しいインターフェイスです。 古いメソッドまたは古いデータ型を変更するには、まったく新しい COM インターフェイス (古いメソッドから継承されないインターフェイス) が必要です。

COM の場合、 QueryInterface 関数は、サーバーがインターフェイスをサポートしているかどうかを確認する確立されたメソッドです。そのため、クライアントが古いバージョンまたは新しいバージョンのインターフェイスと通信できる状況を簡単に解決できます。