요약

  • RFC 3529는 XML-RPCmethodResponse를 fault 포함 전부 BEEPRPY로 전달했으며, BEEPERR는 애플리케이션 오류 채널이 아니었다.
  • 완료된 BEEP 교환, ready 프로필, 프라이버시 튜닝, 피어 인증은 메서드 승인, 프로시저 성공, 지속적 외부 효과와 구별되었다.

RFC 3529에서 가장 계몽적인 부분은 새 XML 태그가 아니라 어떤 BEEP 프레임이 나쁜 소식을 전달하는지에 대한 규칙이었다. 클라이언트는MSG에 XML-RPCmethodCall을 보내고, 서버는 그에 대응하는methodResponse를RPY로 돌려보냈다. XML-RPC 메서드가 fault를 생성하더라도 그 fault는 여전히RPY로 전달되었고, 프로필은 명시적으로 이를 위해 BEEPERR를 사용하지 않았다.

이 선택은 계층을 드러냈다.RPY는 일대일 BEEP 교환에 대해 긍정적이었다. 즉, 응답이 생성되어 요청과 연결되었다는 뜻이다. 그것은 원격 프로시저에 대한 판정이 아니었다. 애플리케이션 판정은 XML 문서 안에 있었다. 모든RPY를 성공한 RPC로 계산하는 관찰자는 정확히 보고된 실패를 허위 성공으로 바꾸게 된다.

이 구분은 호출 전에 시작되었다. RFC 3529는 두 상태 프로필을 정의했다. 채널은boot상태로 시작한다. 개시자가 리소스 경로와 함께bootmsg를 보내면, 서버가 그 리소스를 인식할 경우bootrpy로 응답하고 프로필은ready상태가 된다. 메시지가 잘못되었거나 리소스를 알 수 없으면 BEEPerror또는ERR로 응답하며 상태는 진전되지 않는다.

ready조차도 좁은 근거였다. 그것은 이 채널이 인식된 리소스에 결합되었다는 의미일 뿐, 모든 메서드 이름이 존재하는지, 호출자가 그것을 호출할 수 있는지, 매개변수가 유효한지, 요청된 동작이 완료될지는 증명하지 못했다. 이 질문들은 채널을 통해 도달하는 XML-RPC 애플리케이션의 몫이었다.

URL 스킴은 또 다른 근거 사슬을 조립했다.xmlrpc.beep와xmlrpc.beeps는 authority와 경로를 제공했다. authority는 BEEPserverName이 되고, 경로는 boot 리소스가 되었다. 명시적 포트가 없으면 DNS SRV가_xmlrpc-beep._tcp를 찾고, 적절한 SRV 레코드가 없으면 주소 조회와 할당된 서비스 포트가 이어졌다. 각 단계는 다음 단계가 실패하더라도 성공할 수 있었다. 등록된 이름이 주소로 해석되고, TCP가 열리고, BEEP가 인사하고, 채널이 시작되고, 리소스가ready에 들어갔어도 최종 메서드는 여전히 fault를 반환할 수 있었다.

보안 스킴은 마법이 아니라 프라이버시를 더했다. XML-RPC 프로필이 시작되기 전에xmlrpc.beeps는 BEEP 세션이 전송 보안 프로필 또는 전송 보안을 함께 제공하는 인증 프로필을 통해 프라이버시용으로 튜닝되어야 했다. TLS를 사용할 때 클라이언트는 URL authority와 서버 인증서 신원을 비교해야 했다. 이는 "어떤 보호된 피어에 도달했는가"에 대한 답을 강화했다. 그러나 "이 메서드는 승인되었는가"나 "비즈니스 효과가 지속되었는가"에는 답하지 않았다.

보안 절은 이 실험의 연대를 보여준다. 구현은 DIGEST-MD5와 RSA/3DES 암호 스위트를 사용하는 TLS 프로필을 제공해야 했고, 기밀성과 인증을 함께 위해 클라이언트 인증서를 사용했다. 이 선택은 2003년의 것이었다. 이후의 SASL 및 TLS 문서는 보안 환경을 바꾸었다. 이 역사적 RFC는 프로토콜 계층화 기록으로 읽어야 하지, 현재의 암호 배포 권고로 읽어서는 안 된다.

레지스트리 요청도 마찬가지로 한정되어 있었다. RFC 3529는 BEEP 프로필 식별자, 두 개의 URI 스킴, TCP 포트 602의xmlrpc-beep서비스를 요청했다. 현재 레지스트리는 조율된 심볼이 존재함을 보여줄 수 있다. 그러나 리스너가 실행 중인지, 어떤 제품이 프로필을 구현하는지, 트래픽이 그것을 사용하는지, 원격 호출이 성공했는지는 보여줄 수 없다.

당대의 가장 가까운 비교인 SOAP over BEEP은 아키텍처적 유행을 설명해 준다. 애플리케이션 봉투는 모든 작업을 새 전송 대화로 취급하는 대신 재사용 가능한 세션 프로토콜을 탈 수 있었다. 그러나 재사용 가능한 기반은 계층화된 수신 확인을 덜 중요하게 만드는 것이 아니라 더 중요하게 만들었다. 채널 성공, 메시지 성공, 애플리케이션 성공을 하나의 녹색 불로 안전하게 축소할 수는 없게 된 것이다.

따라서 한 번의 호출을 재구성하는 운영자에게는 여러 기록이 필요했다. 선택된 authority, 해석된 엔드포인트, 보호된 피어 신원, 채널과 리소스, BEEP 메시지 번호, 응답 프레임이RPY인지ERR인지, XML-RPC 본문에 정상 매개변수가 있었는지 fault가 있었는지. 상태 변경 메서드의 경우 또 하나의 기록이 필요했다. 애플리케이션 자체의 지속적 식별자, 버전, 감사 항목 또는 이후의 재조회였다.

재시도는 잘못된 판단의 비용을 드러냈다.RPY이전의 타임아웃은 메서드가 실행되었는지 밝혀주지 못했다. fault를 담아 받은RPY는 애플리케이션 수준의 거절을 밝혔지만, 메서드 계약이 그렇게 말하지 않는 한 부분적 부작용이 발생했는지까지는 보증하지 않았다. 일반 대시보드가 본문을 놓쳤다는 이유만으로 비멱등 메서드를 반복하면 작업이 중복될 수 있었다.

RFC 3529는 Experimental이었다. 따라서 그 지속적 기여는 BEEP 위의 XML-RPC가 승리했다는 주장이 아니다. 성공은 계층이 소유한다는 간결한 실증이다. 외부 프로토콜은 내부의 부정적 판정을 성공적으로 전달할 수 있다. 좋은 근거는 두 진실을 모두 보존한다.

출처