퍼온글입니다.
URL : http://hoidooly.tistory.com/15
Web services vs JMS
서비스간 메시징을 위해서 Web services와 JMS를 많이 사용하고있다.
---------------------------------------------------------------------------------------------------JMS
---------------------------------------------------------------------------------------------------
queue를 이용해서 one to one 으로 메시지를 주고 받을 때 사용하거나 Produce and Consummer 를 통해서 one to many로 메시지를 주고 받을수있다.
JMS를 사용하여 메시지 전달을 보장하고 이벤트 통지등을 간편히 할수있다.
그러나 ActiveMQ를 이용해 본봐로는 메시지 전달이 보장되지 않고있다.
대량으로 데이터를 주고 받다보면 전달해준 쪽은 전달했다하고 받는 쪽은 못받았다 하는 상황이 발생한다.
결국 우리가 손쉽게 사용할수있는 ActiveMQ를 통해서는 메시지 전달 보장을 위해서 별도의 프로세스를 개발해야 한다.
주기적으로 싱크를 맞춘다거나 메시지 id를 통해서 처리 된 이력을 다시 전달을 받거나 해야한다.
JMS를 쓰면서 불편한 점이라 한다면 클라이언트가 자바 플랫폼이어야 한다는 것과 JMS를 알아야 한다는 부담이있다.
그러나 사실 가장 큰 문제는 서로간에 메시지 포맷을 통일 시키기가 어렵다는 점이다.
xml로 메시지를 보낼것인가?
map형태로 보낼것인가?
serialize를 해서 보낼 것인가?
그렇다면 포맷은 어떻게 할것인가?
포맷이 변경 되면 어떻게 대응해야 할까?
그렇다 결국 JMS를 통해서 타 시스템/본부/회사와 메시징을 한다는 것은 넌센스다.
동일 플랫폼에서 모든 노드에 대해서 제어 할수 있는 상황이 아니고서는 사용의 제약이 매우 심하다.
JMS를 통해서 이벤트 통지와 노드간 비동기로 싱크를 맞춰야 할경우에는 매우 유용하다.
수백대의 서버가 동일한 이벤트를 받아서 작업을 하고 중간에 작업이 끝난 노드는
다음 작업을 할수도있고 처리하다 죽었을 수도있을 경우?
중간에 노드가 받아서 처리한 메시지를 저장할수있는 큐가 있어줘야한다.
이러한 경우라면 위에서 이야기한 모든 JMS의 이점이 적용된다.
---------------------------------------------------------------------------------------------------
Web services
---------------------------------------------------------------------------------------------------
다수의 클라이언트와 데이터를 주고 받아야 할경우? 일일이 메시지 포맷을 설명하고 api를 설명한다는 것은 참 지루하고 피곤하다.
WSDL이라는 훌륭한 언어의 도움으로 이 모든 귀찮음을 해결할수있다.
물론 Web services를 이용할 때 귀찮음 역시 만만치 않다.
가장 큰 골치 거리가 서비스의 버전 관리다.
기존 서비스를 업그래이드 할 경우 과거 서비스와 새로 오픈한 서비스간 버전을 어떻게 관리 할것인가?
//리팩토링 필요하다. 페이지 나눠야 겟다.