JMS with spring - 1
Java2011. 6. 17. 17:47
1. JMS
수년간 시스템들은 복잡도가 올라가고 더 세련되어져 갔습니다. 시스템들은 과거의 시스템들에 비해 믿을 수 있고, 확장성이 증가하고, 더 많은 유연성이 필요하게 되었습니다. 이러한 요구들의 증가에 대응하여 이 빠른 시스템, 아키텍쳐, 디자이너 및 개발자들은 이들 복잡성을 해결하는 한가지 방법으로 메시징을 활용했습니다.
메시징이 사용되고 나서 Java Message Service(JMS) API 는 1999년 도입 이후 크게 변경되지 않았습니다. 메시징은 유연성과 확장성 문제의 해결을 위해 폭넓게 사용되었지만 많은 비지니스적 문제와 다른 애플리케이션의 문제에서도 사용 되었습니다.
이기종간의 통합은 메시징이 중요한 역할을 하는 기본 영역중 하나 입니다.
또한 메시징은 비동기 요청을 처리할 수 있는 기능 및 아키텍쳐 와 개발자들이 시스템 병목 현상을 감소 또는 제거를 위한 솔루션을 제공하고, 최종 사용자의 생산성 및 전반적인 시스템 확장성을 제공 합니다. 이기종 시스템 간에 높은 수준의 약한 결합 및 메시징을 활용하는 시스템에 높은 수준의 구조적인 유연성과 민첩성을 제공 합니다.
비즈니스 시스템에 사용되는 애플리케이션간의 메시징 시스템은 엔터프라이즈 메시징 시스템이나 메시지 지향 미들웨어(Message-Oriented Middleware, MOM)이라고 합니다.
엔터프라이즈 메시징 업체들은 서로 다른 메시지 포맷과 네트워크 프로토콜을 사용하여 메시지를 교환하지만, 기본적인 의미는 동일합니다. API는 새 메시지 생성, 애플리케이션데이터로딩, 라우팅 정보 지정과 메시지를 보냅니다. 이 동일한 API를 사용하여 다른 애플리케이션에서 만든 메시지를 수신합니다.
대부분 기업들이 메시징 시스템, 응용 프로그램 교환을 destinations라 부르는 가상 채널을 사용합니다. 메시지가 전송되면, 그것은 특정 애플리케이션이 아닌 대상 destination으로(queue or topic) 기록 됩니다. 아무 애플리케이션이나 관심있는 destination에 등록을 하여 메시지를 받아 볼 수 있습니다. 이러한 방법으로 메시지를 주고 받는 애플리케이션의 약한 관계가 성립됩니다. 메시지를 보내는 쪽이나 받는 쪽이나 어떤식으로든 서로 얽매이지 되지 않고 메세지를 주고 받을 수 있습니다.
JMS는 애플리케이션 개발자가 같은 API로 다른 시스템들에 사용할 수 있는 JDBC와 유사하다. 만약 JMS를 준수하여 서비스를 할 경우, JMS API를 통해 공급자가 해당 업체에 메시지를 주고 받을 수 있다. 예를 들어 SonicMQ를 사용하여 메시지를 보내고 IBM WebSphere MQ를 통해 메시지를 처리 할 수 있다.
2. The advantages of Messaging
이기종 시스템간의 통합
이기종 플랫폼의 커뮤니케이션과 통합은 아마도 메시징을 위한 오래된 유스케이스입니다. 메시징을 사용하여 애플리케이션의 서비스를 호출할 수 있고 완전히 다른 플랫폼에서 구현하는 시스템으로 사용할 수 있습니다. 많은 오픈 소스 및 상용 메시징 시스템은 자바 사이의 매끄러운 연결을 제공하고 다른 언어 및 다른 플랫폼에도 제공 합니다. 예를 들어 ActiveMQ(open source) 와 IBM WebSphere MQ(commercial)이 있습니다. 이 두 메시징 시스템은 JMS를 지원 하고 또한 자바 메시징 클라이언트가 사용하는 기본 API를 지원 합니다(C, C++). 벤더에 의존하지 않고 non-java 시스템과 non-jms 메시징 클라이언트를 사용할 수 있습니다.
역사적으로, 이기종 시스템간의 통합 작업은 많은 방법이 존재 하였습니다. 정보를 공유하는 데이터베이스를 사용하여 두 이기종 시스템 또는 응용 프로그램간에 접근하는 방식이 아직 까지 널리 사용되고 있는 방법입니다. Remote Procedure Call, or RPC 는 이종 분산 시스템간의 데이터 및 기능 공유의 또 다른 방법입니다. 이러한 해결책은 각각 장점과 단점을 가지고 있고 메시징은 데이터 및 기능을 애플리케이션이나 서브 시스템을 통해 굥유할수 있는 진정한 결합도가 낮은 방법입니다. 최근 웹 서비스가 또 다른 이기종 시스템 통합을 위한 솔루션으로 등장했습니다. 그러나 웹서비스는 아직 신뢰성이 부족하므로 메시징이 더 좋은 선택 입니다.
시스템 병목 현상을 감소
많은 수의 프로세스를 만들고 해당 프로세스의 요청 속도를 유지 하기 위해 시스템과 애플리케이션의 병목현상이 발생 합니다. 고전적인 시스템 병목현상의 예는 저조한 튜딩이된 데이터 베이스에 연결될 때 까지 기다리는 애플리케이션과 프로세스를 들 수 있습니다. 시스템이 백업되는 시점에서 응답시간은 악화되고 결국 타이밍이 어긋 납니다.
시스템 병목 현상의 좋은 비유는 깔때기에 물을 붓는 것입니다. 한정된 시간내에 처리 할 수 있는 용량은 제한되어 있으므로 이를 처리 하기 위해서는 많은 시간이 추가 됩니다. 하지만 깔때기에 입구를 추가 하게 되면 이것을 해결 할 수 있습니다. 이 예는 Point -to-Point 모델로 해결이 가능하고, 병목현상이 감소 또는 어떤 경우에는 완전히 제거 됩니다.
확장성을 향상
많은 메시징 시스템 병목 현상을 감소하는 것과 같은 방법으로, 시스템의 전반적인 확장성 및 처리량을 증가 시킬수 있을 뿐만 아니라 효과적으로 응답시간을 감소 시킬수 있습니다.
최종 사용자의 생산성을 높임
비동기 메시징의 사용은 최종 사용자의 생산성 역시 향상시킬 수 있습니다.
아키텍쳐의 유연성 및 민첩성
아키텍쳐의 민첩성은 끊임없이 변화하는 환경에 신속하게 대응하는 능력입니다. 추상화되고 연결성이 낮은 컴포넌트들에 메시징을 사용하게 되면 소프트웨어, 하드웨어, 비즈니스로직의 변경에 까지 빠른시간에 대응할 수 있습니다. 메시징을 통해 메시지 공급자나 클라이언트 콤포넌트는 프로그래밍 언어나 플랫폼에 종속적이지 않기 때문에 유연하고 민첩한 대응응 할 수 있습니다.
엔터프라이즈 메시징
엔터프라이즈 메시징은 새로은 컨셉이 아닙니다. 메시징은 IBM Web-Sphere MQ, SonicMQ, Microsoft Message Queuing(MSMQ), and TIBCO Rendezvous 등이 수년간 존재해 왔습니다. 최근에 오픈 소스인 ActiveMQ가 참여하였습니다.
엔터프라이즈 메시징의 핵심 컨셉은 메시지가 비동기적으로 한시스템에서 네트워크를 통해 다른 시스템으로 전달 되는 구조이다. 메시지가 비동기적으로 전달 된다는 말은 수신하는 쪽에서 메시지를 받기위해 대기하거나 처리를 하기 위해서 대기할 필요가 없다는 뜻이다.
client 라든 용어에 대해서 정의해 보면, 메시징 시스템은 메시징 클라이언트와 몇몇 종류의 메시징 미들웨어 서버로 구성되어 있다. 클라이언트들은 메시징을 메시징 서버로 보낸 다음 메시지들은 다른 클라이언트들에 배포 된다. 클라이언트 비즈니스 애플리케이션이나 컴포넌트들이 이를 위해 메시징 API를 사용한다(우리의 경우엔 JMS)
중앙 아키텍쳐
엔터프라이즈 메시징 시스템들은 중앙 아키텍처를 사용하는 메시지 서버에 의존하는 하고 사용한다. 메시지 서버는 메시지 라우터나 브로커로 블리우고 메시지들을 메시징 클라이언트로 부터 다른 메시징 클라이언트로 전달하는 책임을 가지고 있다. 메시징 서버는 메시지를 보내는 클라이언트와 받는 클라이언트들로부터 분리되어 있다. 클라이언트들은 오직 메시징 서버만 바라보고 다른 클라이언트들은 신경쓰지 않는다. 전체 시스템에 영향을 미치지 않고 클라이언트들을 추가 및 수정할 수 있습니다.
요약하면, 중앙 아키텍쳐는 hub-and-spoke topology에 사용된다. 간단한 예를 들면, 중앙 메시지 서버가 있고 모든 클랑이언트들은 이곳에 연결한다. 아래의 그림처럼, hub-and-spoke 아키텍쳐는 네트워크의 최소한 연결을 허용하고 다른 파트의 시스템간 최소한의 커뮤니케이션을 허용합니다.
분산 아키텍쳐
모든 분산 아키텍쳐는 현재의 네트워크 레벨에서 IP 멀티 캐스트를 사용합니다. 메시징 시스템은 멀티캐스팅을 바탕으로 중앙서버가 없습니다. 몇몇 서버들은 기능적으로 클라이언트 내의 일부로 내장 되어 있는 동안 메시지 라우팅은 IP 멀티 캐스트 프로토콜을 사용하여 네트워크 계층에 위임합니다.
IP 멀티캐스트는 애플리케이션이 한개 이상의 IP 멀티캐스트 그룹에 참여 하도록 허락합니다. 각 그룹은 IP 네트워크 주소를 사용하고 모든 회원들은 어떤 메시지든 간에 그 그룹안에서 재배포를 받습니다. 이러한 방법으로, 애플리케이션은 IP 멀티케스트 주소로 메시지를 전송할 수 있고 네트워크 레이어에서 메시지가 적절하게 재배포되는것을 기대할 수 있습니다(Figure 1-3 참조)
중앙 아키텍처와는 달리, 분산 아키텍쳐는 메시지 라우팅을 목적으로한 서버를 필요로 하지 않는다.(네트워크가 자동적으로 라우팅을 해줌). 그러나 기능적으로 각 클라이언트에 포함되어 , 이러한 메시지의 영속성 및 메시지 배달의 의미는 once-and-only-once 배달과 같습니다.
메시징 모델
JMS는 두가지 타입의 메시징 모델을 지원한다: point-to-point 와 publish-and-subscribe.
이 메시지 모델은 때로는 메시징 도메인이라고 한다. Point-to-point 메시징과 publish-and-subscribe 메시징은 줄여서 p2p 와 pub/sub로 각각 불리웁니다.
가장 간단한 의미로 publish-and-subscribe는 one-to-many 브로드 캐스트 메시징을 위한거고 point-to-point 는 one-to-one 딜리버리 메시징입니다.
JMS 관점에서 메시징 클라이언들은 JMS 클라이언트라고 부르고 메시징 시스템은 JMS 프로바이더로 불리웁니다. JMS 애플리케이션은 많은 수의 JMS 클라이언트와 일반적으로는 하나의 JMS 프로바이더로 구성됩니다.
추가로, 메시지를 제공하는 JMS 클라이언는 message consumer로 불리웁니다. JMS 클라이언트는 message producer 와 message consumer가 될 수 있습니다. consumer 와 producer라는 용어를 사용할 때 JMS 클라이언트가 각각 consumes messages 나 produces message 하는걸 의미 합니다.
Point-to-Point
Point-to-Point 메시징 모델은 JMS 클라이언트가 메시지를 동기 및 비동기 방식으로 queue라고 부르는 가상 채널을 경유하여 전송하거나 받을 수 있습니다. point-to-point 모델에서, message producers 는 sender(보내는사람), message consumers 는 receivers(받는사람)으로 불립니다.
