기존 인터페이스 변경

가능하면 기존 인터페이스를 변경하는 대신 애플리케이션에 대한 새 인터페이스를 구현합니다. 기존 인터페이스를 변경하지 않는 경우 새 메서드에서만 새 데이터 형식을 사용합니다. 새 데이터 형식을 도입하거나 기존 형식을 수정하는 것은 비호환성 문제의 가장 일반적인 소스입니다. RPC 런타임 모델은 수신 애플리케이션이 수신하는 데이터 형식에 대해 알고 있다고 가정하므로 일반 데이터 설명 없이 데이터가 연결에 배치됩니다. 받는 사람이 발신자가 유선에 넣은 것과 다른 데이터 형식을 예상하는 경우 스텁은 예외를 발생합니다(또는 전송이 다른 덜 정상적인 방식으로 실패함).

RPC 인터페이스는 UUID 및 주 버전 및 부 버전 번호로 정의됩니다. 기존 인터페이스를 변경하는 경우 인터페이스 끝에 새 메서드를 추가하고 부 버전 번호를 변경해야 합니다. 다른 곳에 메서드를 추가하거나 인터페이스를 다른 방식으로 변경하는 경우 주 버전 번호도 변경해야 합니다.

현실적으로 새 클라이언트가 이전 서버와 통신할 수 없고 서버를 업데이트할 수 없으므로 부 버전 번호도 변경할 수 없는 경우가 있습니다. RPC 런타임은 클라이언트가 서버와의 인터페이스에 대해 지정된 메서드를 초과하는 메서드를 호출할 때 예외를 발생합니다( RPC_S_PROCNUM_OUT_OF_RANGE). 해결 방법은 버전 번호를 변경하지 않고 클라이언트 코드를 작성하여 이 예외를 정상적으로 처리하는 것입니다. 예를 들어 클라이언트의 성능이 저하되거나 애플리케이션에 적합한 방법이 무엇이든 간에.

기존 메서드에서 데이터 형식을 변경하는 특별한 경우와 비슷한 해결 방법이 있습니다. 분기가 포인터이고 인식할 수 없는 형식에 대한 기본 분기 없는 공용 구조체가 있는 경우 새 데이터 형식을 사용하는 새 분기를 추가할 수 있습니다. 이렇게 하면 데이터 구조의 크기가 변경되지 않습니다. 클라이언트가 새 서버와 대화할 때 새 데이터 형식을 사용할 수 있습니다. 그러나 클라이언트가 이전 서버와 대화할 때 런타임에 예외 RPC_S_INVALID_TAG 발생합니다. 이 예외를 적절하게 처리하려면 클라이언트 코드를 작성해야 합니다.

DCOM 인터페이스는 GUID로 식별됩니다. DCOM에서 인터페이스는 변경할 수 없는 것으로 간주되며 이전 인터페이스에서 상속되는 새 인터페이스를 만들어야만 변경할 수 있습니다. 이러한 규칙은 클라이언트와 서버가 호환성을 유지하도록 합니다.