- JMS
JNDI 설정
JMS Conn 설정
JMS Topic ( send - receive ) Tutorial 참고
JMS Send
connectionAliasName : JMS_Conn ( 설정 값 )
destinationName : Topic 명 ( TestTopic ) 으로 설정
destinationType : TOPIC / QUEUE ( Topic으로 설정 )
status
snoop
Trigger 로 consume
processJMSData
vi consumeData
+) trigger 를 두 개로 설정하여 같은 Topic을 바라보게 하면 같은 message를 consume 할 수 있음.
- Event Driven APIs with API Gateway and SOAP over JMS
Tutorial
- JMS 비동기 처리 Guide (최상혁 팀장님 가이드) 정리
< 핵심 정리 >
JDNI -> JMS 설정
JMS/AMQP REST Routing
=> API Policy Routing 부분 Destination Name ( Input Queue ) 만 설정 한 후, Reply To Name ( Response Queue ) 를
설정 하지 않음으로 써 비동기 처리를 할 수 있도록 설정
=> IS 에서 Destination Queue로 지정된 TEST queue 를 Trigger 설정을 통해 특정 Flow service 가 실행되도록 처리
테스트
API Routing 설정
Service
Trigger 설정
IS Settings > Messaging > JMS Trigger Management
API 호출
Server.log
- AMQP Tutorial
JNDI
/webM/IntegrationServer/amqp.properties
JMS Connection 설정
Input Source Name : API Gateway가 입력 요청을 수신 할 Queue 또는 Topic의 이름
Resource : API resource 명
trigger 에서 에러가 나는데 왜 나는지 모르겠음
- 추가 AMQP 참고자료
- AMQP란
- Advanced Message Queing Protocol의 약자로, 흔히 알고 있는 MessageQueue의 오픈소스에 기반한 표준 프로토콜을 의미
- 등장배경
- 이전에도 상용화된 MQ 제품들은 많았지만, 한 가지 문제가 있다면 대부분 플랫폼 종속적인 제품들이었기 때문에 서로 다른 이 기종 간에 메시지를 교환하기 위해서는 메시지 포멧 컨버전을 위한 메시지 브릿지를 이용하거나 (속도 저하 발생) 시스템 자체를 통일 시켜야 하는 불편함과 비효율성이 있었다. (시스템을 교체하는 것은 논외로 치고 메시지 브릿지의 경우 MQ가 금융 쪽에서도 많이 사용 된다는걸 감안하면 속도 및 응답성의 저하는 치명적인 약점일 수 밖에 없다) 이러한 기존의 MQ들의 약점을 보완하기 위해 등장한 것이 AMQP이다. 즉, AMQP의 목적은 서로 다른 시스템 간에 (비용/기술/시간적인 측면에서) 최대한 효율적인 방법으로 메시지를 교환하기 위한 MQ 프로토콜인 것이다.벤더에 종속 되는 것을 방지하기 위해 AMQP는 대략 아래와 같은 조건을 충족한다.
- 모든 broker들은 똑같은 방식으로 동작할 것
- 모든 client들은 똑같은 방식으로 동작할 것
- 네트워크 상으로 전송되는 명령어들의 표준화
- 프로그래밍 언어 중립적
- AMQP Routing model
- Exchange
Publisher로부터 수신한 메시지를 적절한 큐 또는 다른 exchange로 분배하는 라우터의 기능, 각 큐나 exchange는 'Binding'을 사용해서 exchange에 바인드 되어 있고, 따라서 exchange는 수신한 메시지를 이 binding에 따라 적당한 큐나 exchange 로 라우팅한다. Binding과 메시지를 매칭시키기 위한 라우팅 알고리즘을 정의한 것을 Exchange type이라고 하고, exchange type은 라우팅 알고리즘의 클래스이다. 브로커는 여러개의 exchange type 인스턴스를 가질 수 있다. binding과 exchange type이 혼동될 수 있는데, exchange type은 메시지를 어떤 방법으로 라우팅 시킬지를 결정하는 것이고, binding을 이러한 방법을 이용해 실제로 어떤 메시지를 어떤 큐에 보낼지를 결정하는 라우팅 테이블이라고 할 수 있다.
- Queue
일반적으로 알고 있는 큐이다. 메모리나 디스크에 메시지를 저장하고, 그것을 consumer에게 전달하는 역할을 한다. 큐는 스스로가 관심있는 메시지 타입을 지정한 Binding을 통해 exchange에 말 그대로 bind된다.
- Binding
exchange와 큐와의 관계를 정의한 일종의 라우팅 테이블이다. 같은 큐가 여러개의 exchange에 bind 될 수도 있고, 하나의 exchange에 여러개의 큐가 binding 될 수도 있다.
- Routing Key
Publisher에서 송신한 메시지 헤더에 포함되는 것으로 일종의 가상 주소라고 보면 된다. Exchange는 이것을 이용해서 어떤 큐로 메시지를 라우팅할지 결정할 수 있다. (이것을 사용하지 않고 다른 룰을 이용할 수도 있음) AMQP의 표준 exchange type은 이 라우팅 키를 이용하도록 되어있다.
- Standard Exchange Type
- 대부분의 MQ 에서 사용 가능한 여러가지 상황에 대하여 AMQP에서 정의한 표준 라우팅 알고리즘
- Direct Exchange 방식
- 메세지의 routing_key 값을 1:N으로 매핑 시키는 방법 일반적으로 라우팅 키와 큐의 이름을 바인딩 하고자 같은 이름으로 작성 ( Routing Key = Queue Name )
- Topic Exchange 방식
- 와일드 카드(???) 를 이용하여 큐에 매핑 라우팅 키는 "." 으로 구분되어 0개 이상의 단어로 구성 하여 특정 큐에 바인딩 ( * : 하나의 단어, # : 0개 이상의 단어)
- Fanout Exchange 방식
- 모든 메세지를 모든 큐로 라우팅
- Headers Exchange 방식
- Key - Value 로 정의된 헤더에 의해 라우팅 결정, x-match 라는 특별한 argument로 헤더를 어떤 식으로 해석하고 바인딩 할지 결정, x-match가 all : 바인딩 조건 모두 충족 시켜야 함 , any : 하나만 충족 시켜도 됨
왜 AMQP 라우팅은 백엔드 서비스가 메세징 API로 만들어져서 응답을 주는 케이스에서만 사용되는지..??
=>> webMethods 에서 JMS는 Trigger 설정해서 Flowservice 를 하나 실행 시킬 수 있는데 반해 AMQP는 메세징API 기능만 사용할 수 있기 때문???
+) 추가 스터디 >> Erlang , RabbitMQ 관련 정보 , AMQP Client 툴? 소스 사용해서 호출 테스트