RPC 및 COM에 대한 버전 관리 이론

완전히 완벽한 두 가지 방법만이 유선 호환성 문제의 위험 없이 새로운 기능을 지원합니다.

• 규칙에 따라 인터페이스 버전을 변경합니다. 이렇게 하면 새 클라이언트가 이전 서버와 통신할 수 없으며 이전 클라이언트가 새 서버와 통신하는 것을 방지할 수도 있고 그렇지 않을 수도 있습니다. 이 내용은 이 섹션의 뒷부분에서 설명합니다.
• 새 기능을 다루는 다른 인터페이스를 소개합니다.

표준 RPC 인터페이스는 GUID 및 버전 번호 조합으로 식별됩니다. COM 인터페이스는 GUID로 식별됩니다. 버전은 주 부분과 부 부분으로 구성됩니다. GUID가 동일하고 버전 번호가 다른 표준 인터페이스의 경우 주 버전이 동일하고 클라이언트가 서버의 부 버전보다 높지 않은 경우에만 연결이 가능합니다.

그 결과 RPC 인터페이스 GUID를 변경하면 유선 호환성이 중단되고 인터페이스 이름을 변경하지 않습니다.

표준 RPC에서 업그레이드 및 확장에 대한 경로가 잘 정의되어 있으며 기본적으로 인터페이스 끝에만 새 메서드를 추가하고 새 형식을 새 메서드에서만 사용해야 합니다. 이러한 추가가 필요한 경우 부 버전을 늘려야 합니다. 클라이언트 및 서버 소프트웨어가 유선에서 호환되지 않으므로 다른 모든 변경은 주 버전을 변경해야 합니다. 이러한 규칙을 준수하면 새 클라이언트와 이전 서버 간에 연결되거나 그 반대의 경우도 마찬가지일 때마다 양쪽이 완전히 호환됩니다.

COM 인터페이스의 경우 버전 특성을 사용할 수 없습니다. 새 인터페이스를 만들고 이전 인터페이스에서 상속하는 것은 RPC에서 버전을 조작하는 것과 같습니다. 일반적으로 COM에서 가장 좋은 방법은 확장된 기능에 대한 새 인터페이스를 만드는 것입니다. 부 버전과 동등한 것은 이전 인터페이스에서 상속되는 새 인터페이스입니다. 이전 메서드 또는 이전 데이터 형식을 변경하려면 완전히 새로운 COM 인터페이스(이전 인터페이스에서 상속되지 않는 인터페이스)가 필요합니다.

COM의 경우 QueryInterface 함수는 서버가 인터페이스를 지원하는지 여부를 확인하는 설정된 메서드입니다. 따라서 클라이언트가 이전 또는 새 버전의 인터페이스와 통신할 수 있는 상황을 쉽게 해결할 수 있습니다.