메시지 지향 미들웨어

Message-oriented middleware

메시지 지향 미들웨어(MOM)는 분산형 시스템 간 메시지 송수신을 지원하는 소프트웨어 또는 하드웨어 인프라다. MOM은 애플리케이션 모듈이 이기종 플랫폼에 걸쳐 분산될 수 있도록 하며, 여러 운영 체제와 네트워크 프로토콜에 걸쳐 있는 애플리케이션 개발의 복잡성을 줄인다. 미들웨어는 다양한 운영 체제와 네트워크 인터페이스의 세부사항으로부터 애플리케이션 개발자를 절연시키는 분산 통신 계층을 만든다. 다양한 플랫폼과 네트워크로 확장되는 API는 일반적으로 MOM에 의해 제공된다.[1]

이 미들웨어 계층은 독립적으로 개발되었으며 서로 다른 네트워크 플랫폼에서 실행되는 소프트웨어 구성요소(애플리케이션, Enterprise JavaBeans, 서블릿 및 기타 구성요소)가 상호작용을 할 수 있도록 한다. 서로 다른 네트워크 노드에 분산된 애플리케이션은 애플리케이션 인터페이스를 사용하여 통신한다. 또한, 관리 인터페이스를 제공함으로써, 상호연결된 애플리케이션의 이 새로운 가상 시스템이 신뢰할 수 있고 안전하게 만들어질 수 있다.[2]

MOM은 클라이언트/서버 아키텍처의 모든 통신 구성요소에 상주하는 소프트웨어 요소를 제공하며 일반적으로 클라이언트와 서버 응용프로그램 간의 비동기 호출을 지원한다. MOM은 클라이언트/서버 메커니즘의 마스터 슬레이브 특성의 복잡성으로 애플리케이션 개발자의 개입을 줄인다.

미들웨어 카테고리

이 모든 모델은 한 소프트웨어 구성요소가 네트워크를 통해 다른 구성요소의 동작에 영향을 미치는 것을 가능하게 한다. RPC-와 OBR 기반 미들웨어는 긴밀하게 연결된 컴포넌트의 시스템을 만드는 반면 MOM 기반 시스템은 컴포넌트의 느슨한 커플링을 허용한다는 점에서 다르다. RPC 기반 또는 OBR 기반 시스템에서는 한 절차가 다른 절차를 호출할 때 호출된 절차가 돌아오기를 기다려야 다른 작업을 수행할 수 있다. 이러한 동기식 메시징 모델에서 미들웨어는 부분적으로 슈퍼링크 역할을 하며, 네트워크에서 호출된 절차를 찾아내고 네트워크 서비스를 사용하여 기능 또는 방법 파라미터를 절차로 전달하고 나서 결과를 반환한다.[2]

이점

메시지 기반 통신 프로토콜을 사용하는 주된 이유는 메시지를 송신자에서 수신자로 전달하면서 메시지를 저장(버퍼), 라우팅 또는 변환하는 능력을 포함한다.

클라이언트 간 메시징 제공자 매개 메시징의 또 다른 장점은 관리 인터페이스를 추가하여 성능을 모니터링하고 튜닝할 수 있다는 것이다. 따라서 클라이언트 애플리케이션은 메시지 전송, 수신 및 처리를 제외한 모든 문제를 효과적으로 해결한다. 상호운용성, 신뢰성, 보안성, 확장성, 성능 등의 문제를 해결하는 것은 MOM 시스템을 구현하는 코드와 관리자의 몫이다.

비동기성

클라이언트는 MOM 시스템을 사용하여 API 호출을 수행하여 제공자가 관리하는 대상에 메시지를 전송한다. 호출은 프로바이더 서비스를 호출하여 메시지를 라우팅하고 전달한다. 일단 메시지를 보내면, 클라이언트는 수신 클라이언트가 메시지를 검색할 때까지 제공자가 메시지를 보관한다고 확신하면서 다른 작업을 계속할 수 있다. 메시지 기반 모델은 제공자의 조정과 결합되어 느슨하게 연결된 구성요소의 시스템을 만들 수 있게 한다.

MOM은 요청-응답 아키텍처와는 반대로 일반적으로 비동기 메시지 전달에 의존하는 애플리케이션 간 통신 소프트웨어의 범주로 구성된다. 비동기식 시스템에서 메시지 대기열은 대상 프로그램이 사용 중이거나 연결되지 않을 때 임시 저장소를 제공한다. 또한 대부분의 비동기식 MOM 시스템은 메시지 큐를 백업하기 위한 영구 스토리지를 제공한다. 송신자와 수신자가 동시에 네트워크에 접속할 필요가 없고(비동기 전달) 간헐적인 접속 문제가 해결된다는 뜻이다. 그것은 또한 수신기 어플리케이션이 어떤 이유로든 실패하더라도, 송신자는 영향을 받지 않고 계속할 수 있다는 것을 의미하는데, 그들이 보내는 메시지는 수신기가 다시 시작될 때 나중에 처리하기 위해 메시지 큐에 쌓이기 때문이다.

라우팅

많은 메시지 지향 미들웨어 구현은 메시지 대기열 시스템에 의존한다. 어떤 구현은 라우팅 로직을 메시징 계층 자체에 의해 제공되도록 허용하는 반면, 다른 구현들은 라우팅 정보를 제공하거나 두 패러다임의 혼합을 허용하기 위해 클라이언트 애플리케이션에 의존한다. 일부 구현에서는 브로드캐스트 또는 멀티캐스트 배포 패러다임을 사용한다.

변환

메시지 기반 미들웨어 시스템에서, 목적지에서 받은 메시지는 원래 보낸 메시지와 동일할 필요는 없다. 내장된 인텔리전스를 가진 MOM 시스템은 발신인 또는 수신인의 요구 사항에 맞게 메시지를 변환하고 라우트할 수 있다.[3] 라우팅 및 방송/멀티캐스트 시설과 연계하여, 한 애플리케이션은 자체적인 네이티브 포맷으로 메시지를 보낼 수 있으며, 두 개 이상의 다른 애플리케이션은 각각 자신의 네이티브 포맷으로 메시지의 복사본을 받을 수 있다. 현대의 많은 MOM 시스템은 프로그래머가 간단한 GUI 끌어서 놓기 작업에 적용할 수 있는 변환 규칙을 지정할 수 있는 정교한 메시지 변환(또는 매핑) 도구를 제공한다.

단점들

많은 메시지 지향 미들웨어 시스템의 일차적인 단점은 아키텍처에서 추가 요소인 메시지 전송 에이전트(메시지 브로커)가 필요하다는 것이다. 어떤 시스템과 마찬가지로, 다른 구성요소를 추가하면 성능과 신뢰성이 저하될 수 있으며, 또한 시스템을 전체적으로 유지하기가 더 어렵고 비용이 많이 들 수 있다.

또한, 많은 애플리케이션 간 통신은 본질적으로 동기적인 측면을 가지며, 송신자는 계속하기 전에 메시지에 대한 회신을 기다리기를 특별히 원한다(극한 경우에는 실시간 컴퓨팅 및 거의 실시간 참조). 메시지 기반 통신은 본질적으로 비동기적으로 기능하기 때문에 그러한 상황에서는 잘 맞지 않을 수 있다. 즉, 대부분의 MOM 시스템은 하나의 사이비 동기식 트랜잭션으로 요청과 응답을 그룹화할 수 있는 기능을 가지고 있다.

동기식 메시징 시스템에서는 호출된 기능이 업무를 마칠 때까지 호출 기능이 돌아오지 않는다. 느슨하게 결합된 비동기 시스템에서, 호출 클라이언트는 이 작업을 처리하는 데 필요한 자원이 고갈되고 호출된 구성요소가 고장날 때까지 수신자에게 작업을 계속 로드할 수 있다. 물론 성능을 모니터링하고 메시지 흐름을 조정함으로써 이러한 조건을 최소화하거나 피할 수 있지만, 이것은 동기식 메시징 시스템으로는 필요 없는 작업이다. 중요한 것은 각 종류의 시스템의 장점과 책임을 이해하는 것이다. 각 시스템은 다른 종류의 작업에 적합하다. 때로는 원하는 동작을 얻기 위해 두 종류의 시스템을 조합해야 한다.

표준

역사적으로, 문제를 일으킨 메시지 지향 미들웨어의 사용을 통제하는 표준이 부족했다. 주요 벤더는 대부분 자체 구현을 하고 있으며, 각각 자체 API(응용 프로그래밍 인터페이스)와 관리 툴을 갖추고 있다.

메시지 지향 미들웨어의 오랜 표준 중 하나는 X/Open 그룹의 XATMI 사양(분산 트랜잭션 처리: 프로세스 간 통신을 위한 API를 표준화하는 XATMI 사양) 이 API의 알려진 구현은 ATR 발틱의 Enduro/X 미들웨어와 오라클의 턱시도다.

AMQP(Advanced Message Queuing Protocol)는 참여 애플리케이션 구성 요소 간에 사용되는 프로토콜과 형식을 정의하는 승인된 OASIS[4] 및 ISO[5] 표준이므로 구현이 상호운용 가능하다. AMQP는 포인트 투 포인트(point-to-point), 팬아웃(fan-out), 게시/구독(public/subscribe), 요청-응답(이러한 것들은 프로토콜 표준 자체의 v1.0에서 의도적으로 생략되지만 라우팅에 대한 특정 구현 및/또는 기본 네트워크 프로토콜에 의존한다는 점에 유의)과 같은 일반적인 메시징 패러다임을 포함한 유연한 라우팅 체계로 사용될 수 있다. 또한 트랜잭션 관리, 대기열, 배포, 보안, 관리, 클러스터링, 연합 및 이기종 멀티플랫폼 지원도 지원한다. AMQP를 사용하는 Java 애플리케이션은 일반적으로 Java JMS로 작성된다. 다른 구현에서는 C#, C++, PHP, Python, Ruby 및 기타 언어에 대한 API를 제공한다.

HLA IEEE 1516(High-Level Architecture, HLA IEEE 1516)은 시뮬레이션 상호운용성을 위한 IEEE 및 SISO 표준이다. C++ 또는 Java의 API를 통해 제공되는 일련의 서비스를 정의한다. 이 서비스는 모듈식 Federation Object Model에 기반한 게시/구독 기반 정보 교환을 제공한다. 또한 동기화 포인트뿐만 아니라 논리적 시뮬레이션 시간을 기반으로 데이터 교환 및 시간 단축을 조정하기 위한 서비스도 있다. 추가 서비스는 소유권 이전, 데이터 배포 최적화 및 참여 연방정부(시스템)의 모니터링 및 관리를 제공한다.

MQ 원격측정 전송(MQTT)은 OASIS 조직이 지원하는 ISO 표준(ISO/IEC PRF 20922)이다. 작은 코드 풋프린트가 필요하거나 네트워크 대역폭이 프리미엄인 M2M/IoT 컨텍스트에서 통신에 적합한 TCP/IP 위에 신뢰할 수 있는 메시지 전송 프로토콜을 경량적으로 게시/구독한다.

객체 관리 그룹의 데이터 배포 서비스(DDS)는 출판사와 구독자 사이의 확장 가능하고 실시간, 신뢰할 수 있으며 고성능 및 상호운용 가능한 데이터 교환을 가능하게 하는 것을 목적으로 하는 메시지 지향 P/S 미들웨어 표준을 제공한다.[6] 이 표준은 C++, C++11, C, Ada, Java, Ruby에 대한 인터페이스를 제공한다.

eXtensible Messaging and Presence Protocol(XMPP)은 XML(Extensible Markup Language) 기반의 메시지 지향 미들웨어에 대한 통신 프로토콜이다. 확장 가능하도록 설계된 이 프로토콜은 또한 출판-가입 시스템, VoIP, 비디오, 파일 전송, 게임, 스마트 그리드와 같은 사물인터넷 애플리케이션, 소셜 네트워킹 서비스에도 사용되었다. 대부분의 인스턴트 메시징 프로토콜과 달리, XMPP는 개방형 표준으로 정의되고 누구나 XMPP 서비스를 구현하고 다른 조직의 구현과 상호운용할 수 있는 개발 및 애플리케이션의 개방형 시스템 접근방식을 사용한다. XMPP는 개방형 프로토콜이기 때문에 어떠한 소프트웨어 라이센스도 사용하여 구현할 수 있다. 비록 많은 서버, 클라이언트 및 라이브러리 구현이 무료 오픈 소스 소프트웨어로 배포되지만, 수많은 프리웨어 및 독점 소프트웨어 구현도 존재한다. IETF(Internet Engineering Task Force)는 2002년에 XMPP 실무 그룹을 구성하여 핵심 프로토콜을 IETF 인스턴트 메시징 및 인식 기술로 공식화하였다. XMPP 작업 그룹은 2004년에 제안 표준으로 승인된 네 가지 규격(RFC 3920, RFC 3921, RFC 3922, RFC 3923)을 작성하였다. 2011년에 RFC 3920과 RFC 3921은 각각 RFC 6120과 RFC 6121로 대체되었고, RFC 6122는 XMPP 주소 형식을 명시하였다. IETF에서 표준화된 이러한 핵심 프로토콜 외에도 XMPP 표준 재단(구 Jabber Software Foundation)은 개방형 XMPP 확장 개발에 적극적이다. XMPP 표준 재단에 따르면 XMPP 기반 소프트웨어는 인터넷 전반에 걸쳐 광범위하게 배치되며 국방부(DoD) 통합 역량 프레임워크의 기반을 형성한다.[7]

자바 EE 프로그래밍 환경은 대부분의 MOM 벤더에 의해 구현되는 JMS(Java Message Service)라는 표준 API를 제공하고 있으며, 특정 MOM API 구현을 숨기는 것을 목표로 하고 있지만, JMS는 교환되는 메시지의 형식을 정의하지 않기 때문에 JMS 시스템은 상호운용성이 없다.

이와 유사한 노력도 적극적으로 진화하고 있는 OpenMAMA 프로젝트에서, 특히 C 클라이언트에 공통 API를 제공하는 것을 목표로 하고 있다. 그러나 현재(2012년 8월)에는 주로 펍 서브 미들웨어보다 시장 지향적인 데이터(예: 주식 시세)를 배포하는 것이 적절하다.

메시지 큐

참고 항목: 메시지 큐 서비스

메시지 대기열은 분산된 응용프로그램 간의 정보 교환을 허용한다. 메시지 큐는 메모리 또는 디스크 저장소에 있을 수 있다. 메시지는 서비스 소비자가 처리할 때까지 대기열에 남아 있다. 메시지 큐를 통해, 응용 프로그램은 독립적으로 구현될 수 있다. - 그들은 서로의 입장을 알 필요가 없거나, 이 메시지를 받기 위해 기다릴 필요가 없는 절차를 계속 시행한다.[8]

트렌드

참고 항목

참조

  1. ^ 커리, 에드워드 2004. "메시지 지향 미들웨어"[permanent dead link] 미들웨어 for Communications, Ed. 쿠세이 H 마흐무드, 1-28 영국 치체스터: 존 와일리 앤 선즈. 도이:10.1002/0470862084.ch1. ISBN978-0-470-86206-3
  2. ^ a b Message Oriented Middleware.
  3. ^ "E. Curry, D. Chambers, and G. Lyons, "Extending Message-Oriented Middleware using Interception", presented at Third International Workshop on Distributed Event-Based Systems (DEBS '04), ICSE '04, Edinburgh, Scotland, UK, 2004" (PDF). Archived from the original (PDF) on 2011-07-26. Retrieved 2011-08-09.
  4. ^ 1.0 OASIS 표준이 됨. AMQP(2012-10-31). 2014-05-23에 검색됨.
  5. ^ "ISO/IEC 19464:2014". ISO.
  6. ^ 실시간 시스템(DDS), 객체 관리 그룹용 데이터 배포 서비스, 버전 1.2, 2007년 1월
  7. ^ [1] 2013년 5월 23일 웨이백머신에 보관
  8. ^ "多彩网客户端:404錯誤提示的界面". www.tutorialsto.com.
  9. ^ OASIS AMQP 버전 1.0, 섹션 2.6.7-2.6.8". OASIS AMQP 기술 위원회. 2012년 6월 18일 회수
  10. ^ 요한슨, 레이프(2005년 4월 18일) "XMPP as MOM". Grant Nordic Middleware Symposum (GNOMIS). 오슬로: 스톡홀름 대학교
  11. ^ STOMP 프로토콜 사양, 버전 1.2, 2012년 10월 22일
  12. ^ 중간에 부드러우십니까? 엔터프라이즈 IT의 미래는 하드웨어 애플리케이션에 달려 있음 2009-02-09년 Wayback Machine에 보관됨

외부 링크