달력

32024  이전 다음

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
JMS는 Java Messaging System의 약자로 Java에서 Messaging System을 사용하기 위한 API들의 정의 이다.

Messaging System


먼저 Messaging System에 대해서 알아보도록 하자. Messagign System이란, Application과 Application이 서로 통신을 하도록 지원해주는 시스템을 이야기 한다.

예를 들어서 설명해보자. 각 지점에 설치된 매출 관리 시스템 A라는 AP(※ Application의 약자, 이하 AP)와 본점에 설치된 B라는 AP가 있다고 하자, A라는 AP는 매출이 발생할때마다, 그 내용을 매장에 있는 PC에도 저장하지만, 그 내용을 본사의 Unix Machine에 전송해서 추후에 총합하도록 하게 한다고 하자.

일반적으로 Messaging System이 만들어지기 전에는 이런 업무를 A와 B 시스템간에 Socket을 직접 연결해서 Packet을 정의하고 그 Packet에 따라서 통신을 했다. 이 통신을 위해서, Packet에 대한 flow control이나, 네트워크에 문제가 발생했을때의 예외처리등을 다 직접 프로그래밍을 해야 했다. 그러나 Messaging System은 이런 모든 AP간의 통신에 대한 여러 기능들을 제공하여 통신에 대한 부분을 간결화 시켜준다

Messaging System에는 이외에도, 하나의 Publisher(방송者)가 여러 Subscriber(구독者) 에게 메세지를 전송하는 모델이라던지, P2P모델 그리고, 메세지가 중간에 유실되지 않게 하는 Reliable Messaging, 비동기방식으로 메세지를 전달하는 방법, 분산 트렌젝션, 클러스터링등을 지원한다. 이 내용에 대해서는 뒤에서 좀 더 자세하게 알아보도록 하자.


What is JMS?


그렇다면 JMS는 무엇인가? JMS는 이런 메세징 시스템을 Java에서 사용하기 위한 표준 API이다. 우리가 DBMS를 사용하면서 JDBC를 사용하는것처럼, JMS는 Messaging 시스템을 사용하기 위한 API의 집합이다.


<그림 1. jms 시스템 개념도>


그림을 살펴보자, Java Application은 표준화된 JMS API를 이용해서 Messaging System을 사용하게 된다. 이 JMS API는 각각 Messaing System Vendor에서 제공되는 Provider Code를 이용해서 Implementation되어 있기 때문에, Java Application 개발자는 JMS라는 표준 API만 사용하면 대부분의 Messanging System을 사용할 수 있다.

※ Notice !! - JMS라는 표준이 있기는 하지만 각각의 Messaging System의 특성에 따라 달라질 수 있다. 작동구조나 성능 역시 각각의 Messaging System 마다 차이가 있기 때문에. 이를 충분히 고려해서 사용해야한다.


<그림 2. jms 시스템 개념도>


Messaging System의 경우 JMS API뿐 아니라 C와 같은 Non-Java AP를 위한 Lib Code를 제공하는 경우가 있는 데 이런 경우에는 Java Application이 아닌 다른 언어로 개발된 Application과도 호환이 되기 때문에, JMS기반의 Messaging 시스템은 Mainframe이나 다른 Application들과 Java Application을 연동하는데 많이 사용이 되며, 근래에 많이 출시되는 EAI솔루션도 JMS를 이용하는 경우가 많다.

우리가 흔히 이야기하는 JMS Product는 이 Messaging System과 JMS API 가 함께 제공되는 Product를 이야기 한다. (Sonic MQ,WebLogic JMS,Oracle Advanced Queing.. etc.)


Feature of JMS


지금까지 JMS에 대한 간단한 개념을 알아봤다. 그럼 JMS API에는 어떤 특징이 있는지 하나씩 살펴 보기로 하자.
AP A와 AP B가 통신을 한다고 했을때, 통신하는 방법은 방식에 따라 data-centric이냐, interface-centric이냐로 분리될 수 있다.

RMI,IIOP,SOAP 또는 직접 TCP Packet을 정의하여 socket으로 통신하는 방식은 interface-centric이라고 한다. 데이타를 보내는 Sender에서 데이타를 보내게 되고, receiver는 어떤 데이타 형이 올지를 알고 있다. (데이타 타입이 서로 약속되어 있다.) 그리고 sender는 recevier로 부터 어떤 데이타를 받을것인지를 알고 있고, 그 데이타가 올때까지 기다리는게 일반적인 흐름이다. 즉 서로 통신을 하는 AP들이 데이타형이나 동작 방법에 대해서 알고 있는 경우가 된다.

그러나 JMS의 경우 data-centric 모델로, sender는 데이타를 보내기만 한다. Receiver가 data를 받았건 말건, 내지는 receiver의 수가 얼마가 되었는지는 상관하지 않는다. JMS에서는 sender는 JMS의 Messaging System에 데이타를 보내기만 한다. Receiver는 이렇게 Messaing System에 보내진 데이타를 중계해서 받는다. 이때 데이타 형은 미리 정해져 있지 않다. (물론 데이타를 받은 다음에는 알맞은 형으로 casting해야 된다. 그러나 데이타형을 몰라도 데이타를 받는것 자체에는 문제가 없다.) 즉 메세지를 주고 받는데에 sender와 receiver간의 약속이 필요하지 않다.


Asynchronous messaging


기본적으로 JMS Messaging 시스템은 Async 방식의 Messaging을 지원한다. Interface-centric의경우, data 를 send하면 ack를 받거나 return 값을 받을때까지 sender는 waiting을 하게 된다. Receiver역시, 계속 sender로 부터 데이타가 오기를 기다린다. 이런 통신 방식은 sync 방식이라 한다.

그러나 Async방식은 sender는 일단 message 시스템에 데이타를 보내논다. Receiver가 받았는지 여부를 확인할 필요 없이, sender는 계속해서 메세지를 보내고, 메세지를 다 보냈으면 작업을 중단한다. Receiver는 sender로 부터 데이타가 오기만을 기다리는게 아니라, 필요할때, message 시스템에 저장되어 있는 (sender로 부터 보내진) 메세지만 꺼내서 바로 사용하면 된다. 즉 sender와 receiver의 message 전송작업이 동시에 일어나지 않게 된다.


Reliable and unreliable messaging


앞에서 설명했듯이 JMS는 sender가 receiver의 상태에 상관없이 message를 무조건 보낸다고 설명했다. 여기서 집고 넘어가야할것이 그럼 어떻게 sender가 보낸 메시지가 receiver에 도착했는지를 보장할 수 있느냐는 것이다. (네트워크 문제나 기타 문제로 메세지가 유실 될 수 있다. ) 이건 JMS Messaging 시스템이 보장해준다. Reliable Messaging의 경우, sender가 데이타를 보냈으면 시스템이 중간에 다운되더라도, sender가 보낸 메세지는 receiver에게 도착할 수 있도록 보장한다. 이런 Reliable Messaging은 회사간 거래에서 중요한 데이타를 전송하는 모델 등에 유용하게 사용될 수 있다.

그 밖에 실시간 데이타 처럼 신뢰성이 중요하지 않고 메세지가 전송되는 것이 중요하다면 unreliable Messaging을 이용하여, 별도의 보장 없이 메세지를 빨리 전송하는데만 초점을 맞출 수 있다.


Publish/Subscribe model


JMS Messaging System은 sender와 receiver를 지원하는 모델에서도 다소 차이가 있다. Interface centric model의 경우(IIOP,RMI. Etc)의 경우 하나의 sender는 하나의 connect된 recevier에만 message를 보내는 1:1 (peer-to-peer) model이다. JMS는 이런 peer-to-peer 모델이외에 1:N (publish/subscriber model)과 , 특정 메세지그룹의 메세지만을 특정 그룹이 받을 수 있게 할 수 도 있다.


Queue/Bus


JMS Messaging 시스템에서 sender가 메세지를 보내는 destination이 되고, reciever가 메세지를 읽어오게 되는 부분을 우리는 Queue 또는 Bus라고 이야기한다.


<그림 3. JMS Queue의 개념>


그림 3을 보면 좀더 쉽게 이해를 할 수 있다. 포탈 쇼핑몰에 입점한 여러개의 쇼핑몰이 있다고 하자. 포탈쇼핑몰에서는 주문 내용을 메세지로 만들어서 보내고, 이 메세지를 컴퓨터에 대한 주문은 QueueA로, 전자제품에 대한 주문은 Queue B로 보낸다고 한다. 컴퓨터 판매 쇼핑몰은 QueueA에서만 주문 정보를 받고, 전자제품 쇼핑몰을 QueueB에서 주문을 받는다. Queue는 이처럼 Sender와 Receiver간에 Message를 주고 받는 채널의 역할을 한다.

여기서 만약 포탈 쇼핑몰이 하나 더 늘어 났다고 하자. 그러면 주문 연동은 어떻게 할것인가? 답은 간단하다. 새로운 포탈 쇼핑몰 B가 컴퓨터 판매 쇼핑몰에 주문을 넘기기 위해서는 Queue A에 주문 Message를 보내기만하면 된다 < 그림 3-1. 포탈 쇼핑몰이 늘어난 경우 >


<그림 3-1. 포탈 쇼핑몰이 늘어난 경우>


마찬 가지 방법으로, 포탈 쇼핑몰 A가 컴퓨터 판매에 대한 주문을 컴퓨터 판매 쇼핑몰이 아니라, 전자 제품 판매 쇼핑몰에 하고자 할때는 컴퓨터 판매에 대한 주문을 Queue B에만 넣어주면 된다.

이처럼 JMS Messaging 시스템에는 Queue의 개념을 이용하면, Message의 경로 배정( Routing)을 매우 유연적으로할 수 있으며, 이런 유연성은 업무 흐름 (Work flow)를 구현하는데 큰 강점으로 작용한다.

그럼 이렇게 기능이 좋은 JMS를 통신에는 다 사용하면 될것인가? 당연히 대답은 NO다. 이메일을 위해서는 이미 SNMP라는 좋은 프로토콜이 개발되어 있고, 이를 이용하기 위한 JavaMail API가 있다. Audio나 Video Streaming 같은 경우에는 Real Time이 중요하다, JMS는 오히려 Async 메세징에 더 유리하다고 볼 수 있다. JMS Messaging 시스템의 특성에 대해서 제대로 파악하고, 적재 적소에 사용한다면 좀더 뛰어나고 안정된 상호 운영성을 확보할 수 있을 것이다.

지금까지 JMS 시스템의 대략적인 구조에 대해서 살펴보았다.. 처음 접하는 사람은 쉬운 개념이 아니었을지도 모르지만, JMS 시스템이 대략 어떤 개념인지만 이해한다면 충분히 성공한것이다. 좀 더 구체적인 내용과 구현방법은 JMS 시스템에 대한 서적을 참고하기 바란다.

※ 참고 자료 Enterprise JMS Programmin / Shaun Terry - M Books
Posted by tornado
|