RPC와 SOAP에 관하여

1. RPC 

 보통의 procedure call 은 caller->callee->caller 흐름으로 compile time에 진행된다.
하지만 RPC는 Caller가 호출하는 사항(아규먼트, call trap등)을 Kernal에 두고, 서버는 실행할 때 커널에 있는 스택을 참조해서 실행한다.

 Kernal엔 각각 call trap, return trap이 있는데 client가 호출하는 call stack은 call trap에, 서버가 반환하는 결과값은 return trap에 저장되고 커널은 여기에 저장 된 정보들을 복사해서 양쪽으로 중개해주는 것이다. 

프로시져콜은 모두 컴파일타임에 실행이 되지만 RPC는 '런타임중에' 호출이 되면 실행하기 때문에 성능면에서 좋다.

 이 흐름에서 kernal이 하는 역할을 보자면

1) Caller의 호출을 validate한다. 권한은 있는지, call을 잘 보낸건지..
2) caller의 스택(아규먼트들)을 kernal의 calltrap으로 복사한다.
3) Server로 컨텍스트를 바꾸고 일을 처리하고.


 2. SOAP 

- 어플리케이션들의 커뮤니케이션 프로토콜이다.
- XML 기반으로 메시지 송수신 프로토콜이며, 플랫폼/언어등에 독립적이다.
- Envelope, Header, Body, Fault 로 구성된 XML이다.
- 서버<->서버간의 통신에는 데이터 정합성이 중요하기 때문에 REST방식 보다는 무겁더라도 SOAP로 통신하는게 좋은 경우도 있다.
<->
장점

- XML이기 때문에 extensible하다
- 다양한 프로토콜에서 사용할 수 있다 (HTTP뿐만 아니라 SMTP FTP등등)

단점

- 늘 SOAP 방식의 스키마를 쓰도록 강요한다. 어떤 스키마가 있다는 것은 형식이 일정하다는 장점도 있지만 스키마 때문에 익히거나 채택하기 어려운 경우도 있다.
<->
- XML이기 때문에 파싱하는데 꽤 오래 걸려서 네트워크의 bandwidth를 쓴다
- SOAP Client, SOAP Server가 있어야 한다. 왜 내 클라이언트를 못 쓰고 Fake Client를 써야하는가!
- 매 번 클라이언트와 서버의 Compatibility를 맞춰줘야 한다. 만약 클라이언트에서 새로운 메시지를 보내고 싶으면 클라이언트 뿐만 아니라 서버도 이를 이해할 수 있도록 버전업을 해야한다.


댓글

이 블로그의 인기 게시물

로컬 Tomcat 서버 실행속도 개선

2019.05.23 - SQLAlchemy 의 객체 상태 관리 (expire, refresh, flush, commit) 에 관한 이해

2020.02.17 Python의 multiprocessing 중 Pool.map(), chunksize에 관한 내용