|
Korea
|
| |
| IBM 홈 | 제품 & 서비스 | 고객지원 & 다운로드 | 회원가입 | |||
|
|
|
|
|
| |||
|
Java theory and practice: 차세대 기업 애플리케이션에 JMS를 사용해야 한다면? |
 |
|
| |||
| |||
|
메시지 큐잉 (MQ) 툴은 관계형 (SQL) 데이터베이스와 같은 데이터베이스 툴만큼 잘 알려지거나 이해되지 않고 않다. 데이터베이스 툴은 거의 모든 기업 애플리케이션과 수많은 보다 간단한 애플리케이션의 핵심 요소이다. 개발자들은 저렴한 데스크탑용 데이터베이스 (dBase나 Microsoft Access)에서 웍그룹 데이터베이스 서버 (Sybase SQL/Anywhere), 그리고 기업 데이터베이스 서버 (DB2나 Oracle)에 이르기까지 광범위한 데이터베이스 제품에 항시 접근한다. 여러분의 프로젝트가 무엇이든 간에 여러분이 필요로 하는 기능, 가격 및 성능이 결합된 데이터베이스 제품이 있다. 데이터베이스와 마찬가지로, 메시지 중심 미들웨어(MOM)라고도 불리는 MQ 제품은 꽤 오랫 동안 존재해 왔다. 그러나 최근까지 MQ 서버는 아주 자금력이 있는 기업 개발자만 사용할 수 있는 비싼 고급 제품이었다. 그 결과 자신의 애플리케이션에 메시징을 사용할 때의 이점을 아는 개발자가 드물었다. 다행히도 이런 상황이 변하기 시작하고 있다.: 현재 몇 개의 보다 저렴한 MQ 서버가 시장에 나와있다. 1997년 마이크로소프트는 트랜잭션 메시지 큐잉 제품인 MSMQ를 추가적인 라이선스 비용 없이 Windows NT 서버의 핵심 부분으로 출시했다. Sun은 초기 J2EE 사양에 JMS API를 포함시키면서 메시징을 크게 후원하였다. 그리고 J2EE 사양 1.3 버전에서는 모든 J2EE 컨테이너가 JMS provider를 포함하고 있어야 한다. 자바 메시지 서비스인 JMS는 자바 애플리케이션이 광범위한 MQ 서버 (JMS 전문 용어로는 provider)에 표준화된 인터페이스를 통해 접근할 수 있도록 하는 API이다. JDBC가 공통 인터페이스를 통해 프로그램들이 여러 다른 데이터베이스에 접근하도록 하는 것과 마찬가지이다. 대부분의 J2EE 컨테이너는 JSM provider를 포함하고 있다.; 앞으로는 모든 J2EE 컨테이너가 그러할 것이다. JMS는 또한 J2EE 컨테이너 없이도 사용될 수 있다.; 몇 개의 독립형 JMS provider 구현 제품이 시장에 나와 있다. 또한 EJB 2.0 사양은 새로운 유형의 EJB (메시지 구동 방식의 빈)를 소개하는데, 이는 엔터티와 세션 빈을 이용하는 메시지 구동 방식의 컴포넌트를 아주 쉽게 만들 수 있도록 해준다. 우리 모두 JMS 서비스에 접근할 수 있으므로, 애플리케이션에 메시징의 힘을 응용하는 방법을 배워야 한다. IBM의 e-비즈니스 설계자인 Willy Farrel은 JMS 사용에 관한 훌륭한 소개서(참고 자료)를 작성했는데, 메시지와 큐를 생성하기 위한 기초적인 사항들과 메시지에 우선순위를 매기고, 검색하고, 인코딩하기 위한 모든 옵션들을 다루고 있다. 메시징과 데이터베이스는 서로 보완적이며, 많은 경우 메시징과 관계형 데이터베이스를 함께 사용하면 각자 사용하는 것보다 훨씬 훌륭한 솔루션이 만들어진다. 지금까지 MQ 서버는 금융 서비스 애플리케이션과 같은 이벤트 중심 애플리케이션에서 사용되거나, 이기종 시스템을 연결하는 방법(이기종 데이터베이스 애플리케이션을 연결시키거나 공급 체인 네트워크에서 한 기업을 다른 기업과 연결시키는 등)으로 사용되어 왔다. "메시지 지향 미들웨어"라는 용어가 종종 MQ 서버에 적용되었고 이기종 시스템을 연결시키는 것이 MQ 기술의 주요 용도라는 인식이 강조되었다. 그러나 MQ 제품의 가격이 하락함에 따라 이제 많은 다른 애플리케이션도 메시지 큐잉의 장점을 이용할 수 있게 되었다. MQ 전문 용어에서 메시지는 단순히 바이트 스트림으로 정의된다 (이는 XML 문서, 직렬화된 자바 객체, 텍스트 문자열, 혹은 심지어는 빈 메시지가 될 수도 있다). 메시지의 해석은 애플리케이션의 영역으로 남겨진다.; MQ 인프라는 메시지에 어떤 의미론이나 구조도 부여하지 않는다. 메시지는 큐에 저장되고, MQ 서버는 큐에 메시지를 넣고 빼낼 수 있도록 해준다. 지금까지, 메시지 큐는 간단한 연결 리스트와 아주 유사한 것 같았다. 가장 간단한 형태에서는 정확히 연결 리스트라 할 수 있지만, 기업 MQ 서버는 이러한 연결 리스트 관리에 많은 기능을 씌워서 기능을 향상시킨다.:
MQ 의 강점은 메시지 프로세싱의 비동기적인 특성에 의해 제공되는 고유의 느슨한 결합에서 나온다. 한 엔터티가 메시지를 큐에 게시하고 삭제하고 다른 엔터티가 이를 처리하는 절차는 완전히 분리되어 있다. 두개의 엔터티가 동시에 실행되지 않아도 되며 같은 시스템에 있지 않아도 되고 심지어는 서로의 신원을 몰라도 된다. ; 이들 각각은 각자의 스케쥴에 따라 큐하고만 상호작용하며, 서로 주고받을 메시지의 형식만 합의하면 된다. 즉 서로에 대해 아무 것도 몰라도 된다. 느슨한 결합은 많은 장점을 가지고 있다. 한 단위의 작업을 보다 작은 독립적인 컴포넌트로 나누는 자연스러운 메커니즘을 제공하는데, 이는 결과를 처리하는 단계들간에 은연중에 추상화를 생성한다. 이러한 세분화는 각 컴포넌트의 구현을 서로 쉽게 추상화하도록 해주며 각 컴포넌트별 자원 활용도를 보다 잘 측정하고 관리하도록 하고, 다른 컴포넌트들을 변경하지 않고도 한 컴포넌트를 유사한 기능을 제공하는 다른 컴포넌트로 바꿀 수 있도록 한다. JMS 사양은 JMS provider가 또한 publish and subscribe 기능을 구현할 것을 요구한다. 이 기능은 topics라고 불리는, 애플리케이션이 정의한 별개의 채널을 만들 수 있도록 하며 각 엔터티가 topics을 구독할 수 있도록 한다. 한 topic에 큐잉되는 메시지는 그 topic에게 구독 신청을 한 엔터티의 private 큐에 자동으로 놓여진다. Topics는 금융 서비스나 뉴스 배달 애플리케이션에서 유익한 정렬(Sorting) 기능을 수행하다. 예를 들어, 미 증권거래소에서 거래되는 주식은 5000개가 넘지만 각 투자자가 30개에만 관심이 있다고 하자. 그러면 여러분은 각 ticker symbol에 대한 topic을 만들고 사용자들이 흥미를 가지고 있는 symbol을 구독하도록 하여, MQ 엔진이 중복되는 항목 없이 각 투자자가 원하는 주가만 보여주는 작업을 수행하도록 할 수 있다. 이 절차는 SQL 데이터베이스로 구현하려면 훨씬 어렵다. 메시지 큐잉을 사용하기에 아주 적합한 일반적인 사용 패턴이 많이 있다. 여러분의 애플리케이션에서 이들 중 하나를 보게 된다면 여러분은 메시징 사용을 고려해야 한다. 이벤트 중심 애플리케이션은 MQ 기술을 사용하기에 아주 적합하다. 여기에는 금융 서비스 애플리케이션 (주가 변동 사항이 표시되고 가격 변동이나 다른 주문의 처리에 근거하여 거래를 시작하고 주문의 상태를 보고하는 등의 작업을 하는 거래 단말기를 생각해보라), 뉴스 서비스 애플리케이션 및 공급 체인 애플리케이션이 포함된다. 금융 시장에서는 이벤트에 신속하게 대응해야 한다. 여러분은 중요한 일이 발생했을 때 그 일이 발생하자마자 알 수 있기를 바랄 것이다. 데이터베이스 폴링하기 (주기적 자동 조회) 비효율적이긴 하지만 데이터베이스를 폴링하는 방법이 일반적이다. 각 공항의 모니터는 출력되는 정보를 업데이트하기 위해 데이터베이스를 지속적으로 폴링한다. 출납 창구가 많은 은행은 한가한 다음 창구를 가리키기 위해 종종 전자적 표시를 사용한다. 전자 상거래 사이트의 주문 처리 시스템은 처리해야 할 신규 주문이 있는지 알아 보기 위해 데이터베이스를 폴링할 수 있다. 보험 클레임 워크플로우 시스템은 새로운 보험금 지급 요구가 있는지 알아보고 적절한 클레임 조정자에게 일을 맡길 수 있도록 주기적으로 데이터베이스를 조회할 수 있다. 이러한 폴링은 모두 수많은 추가 작업을 만든다. 빈번하게 폴링하는 엔터티가 많을 경우 (데이터 변동을 즉시 반영해야 하는 경우 폴링을 자주 해야 할 것이다.) 이는 데이터베이스 서버와 네트워크에 상당한 부하를 가져올 수 있다. 대부분의 경우 폴링은 아무런 데이터를 반환하지 않거나 혹은 더 나쁜 경우 이미 본 데이터를 반환하여 다시 조회해야 하거나 이미 처리된 것인지를 확인해야 한다. 데이터베이스는 폴링이나 이벤트를 위해 설계되지 않았다. 여러분이 한 이벤트가 발생하거나 데이터가 변경된 후 비교적 신속하게 조치를 취해야 한다면 비동기 메시징이 훨씬 더 쉽고 효과적인 방법이 될 것이다. 업데이트된 정보가 있는지 알아보기 위해 데이터베이스를 폴링할 때마다 대신 JMS 사용을 고려해보기 바란다.. 워크플로우 포탈 (Workflow Management Coalition과 Workflow And Reengineering International Association의 공동 작업)에 따르면, 워크플로우는 "문서와 정보 혹은 타스크가 절차화된 규칙에 따라 한 참여자에서 다른 참여자로 전달되어 실행이 일어나도록 하는 업무 프로세스를 전체적으로 혹은 부분적으로 자동화시키는 것"이다. 워크플로우 애플리케이션 (문서 전달과 승인, 보험 클레임 처리 등)은 MQ 솔루션에 특히 적합하다. MQ 기술이 각 참여자가 수신함과 발신함을 가지고 있는 서류 중심의 사무실에서 워크플로우 문제를 어떻게 해결하는지를 면밀하게 모델링하고 있기 때문이다. 워크플로우 애플리케이션은 많은 agent (agent는 사람이 될 수도 있고 자동화된 처리 단계, 혹은 심지어는 기계나 프린터 같은 물리적 장비가 될 수도 있다.)를 가지는 것으로 특징지을 수 있다. 각 agent는 태스크의 작은 부분을 수행하고, 이를 업무 규칙에 따라 다음 agent에게 전달한다. 전자식 경비 보고서를 승인하고 지불하는 절차를 생각해 보자. 종업원은 보고서를 만들어 제출하고, 이 보고서는 종업원의 관리자에 의해 승인되어야 한다 (그리고 일정 금액을 초과할 경우 아마 보다 상위 경영진이 승인해야 할 것이다). 그 후 이 보고서는 인사 부서로 가는데, 인사 부서에서는 이 보고서가 정확한지를 검토하고 그 경비가 정당한 업무상 경비가 맞는지와 회사의 규정에 맞는지를 확인하기 위해 조사한다. 인사부서의 승인을 받으면 지불 요청이 만들어지고 수표 발행이 예정될 것이다. 그 후 이 보고서는 회계 부서로 가서 각각의 경비가 적절한 계좌와 비용 센터로 이체될 것이다. 각 단계에서 경비 보고서는 종업원이나 종업원의 관리자에게 다시 돌아갈 수도 있다. 워크플로우 애플리케이션 구축시 설계의 주요 목표는 한 agent에서 다른 agent로 작업이 신속하게 도달하도록 하고 태스크간에 헛점이 생기지 않도록 하는 것이다. MQ 서버는 데이터베이스와 협력하여 작업하므로 유연하고 확장성 있는 워크플로우 처리 기능을 여러분 애플리케이션에 쉽게 구축하도록 해준다. 전자 상거래나 공급 체인 애플리케이션에서 주문을 접수하고 승인하고 처리하는 절차는 워크플로우 애플리케이션과 많은 공통점을 가지고 있다. 대부분의 단계에 사람이 아닌 전자식 참여자가 관여하지만 말이다. 주문 접수 및 처리는 다음 단계 중 일부 혹은 모두를 포함한다. :
여러분은 고객이 "구매"를 클릭한 후 확정 번호와 영수증을 받기 위해 너무 오래 기다리게 하고 싶지 않을 것이다. 따라서 주문을 접수시킨 결과 어떤 코드 경로가 실행되더라도 실행 시간이 짧고 예측 가능해야 한다. 그러나 이들 중 많은 단계가 고객의 주문 시점에 사용 가능할 수도 있고 그렇지 못할 수도 있는 자원들에 접근해야 할 수 있고 응답시간을 보장받지 못할 수도 있다. 이 경우 이들은 중요한 경로에서 빠져야 한다. 주문의 개시로 일련의 이벤트를 작동하도록 해야 하지만, 주문을 개시하기 위해 접수 단계를 최소로 짧아지도록 함으로서 사용자를 가능한 한 신속하게 루프에서 빠지게 한다. 주문 처리를 여러 개의 개별적인 (그리고 보다 짧은) 단계로 나누면 고객에게 보다 나은 경험을 제공할 뿐 아니라 자원 활용율이 높아지고 경쟁이 줄어든다. 이는 트랜잭션 시간이 짧아지고 (따라서 잠금이 빨리 해제될 것이다), 한 단계에 사용된 자원 (네트워크나 데이터베이스 접속 등)이 보다 빨리 해제된다는 의미이다. 주문 처리에 있어 가장 예측하기 어려운 단계 중 하나가 확정 메일을 보내는 것이다. 종종 메일 서버가 폭주하여 메시지를 받는데 오랜 시간이 걸릴 수 있고 접속을 아예 거부할 수도 있다. 고객의 메일 서버가 확장 메시지를 거절한다면 여러분은 나중에 다시 전송을 시도하려 할 것이다. 이런 방식으로 확장 메일을 보낸다는 것은 "위험"하다. 첫번째 시도에서 성공하지 못하거나 처리에 오랜 시간이 걸릴 수도 있기 때문이다. 그리고 여러분은 확정 메일을 보낼 때까지 고객 (혹은 이에 해당하는 다른 무엇)을 기다리게 만드는 것을 원하지 않을 것이다. 이와 비슷하게 재고는 주문 처리와 개별적인 데이터베이스에 저장되어 있을 수 있고 주문이 이루어진 시점에 사용할 수 없을 수도 있다. 혹은 신용 부서가 금요일에 휴무일 수도 있다. 미해결된 확정 메일과 재고 체크, 혹은 신용 체크를 메시지 큐를 사용해 저장함으로써 여러분은 "위험한" 작업을 나머지 프로세스에서 분리할 수 있고 따라서 나머지 프로세스는 작업이 실패하거나 장시간 걸릴지 모르는 위험에서 벗어난다. 또한 각 처리 단계가 하나의 간단한 작업만 수행하기 때문에 각 작업의 에러 처리가 상당히 간단해진다. 결론 다음 달에는 자바 트랜잭션 서버 (JTS)의 역할에 대해 살펴보겠다. EJB나 다른 J2EE 요소에 비해 많은 주목을 받고 있지는 못하지만 JTS는 아마도 J2EE의 가장 중요한 부분이라 할 수 있을 것이다. 트랜잭션은 우리가 신뢰성 있는 분산 애플리케이션을 구축하도록 해 주는 것이다. 향후 칼럼에서는 MQ를 다시 방문하여 메시지 큐잉과 관계형 데이터베이스가 어떻게 상호보완하는지를 보여주는 워크플로우 애플리케이션을 구축해 보겠다.
| ||||||||||||||||||||||||||||||||||||||||||||