메시징 패턴

Messaging pattern

소프트웨어 아키텍처에서, 메시징 패턴은 애플리케이션의 서로 다른 두 부분 또는 다른 시스템들이 어떻게 서로 연결되고 통신하는지를 설명하는 아키텍처 패턴이다.메시징의 개념에는 하드웨어 장치 메시징(통신, 컴퓨터 네트워킹, IoT 등)과 소프트웨어 데이터 교환(이러한 데이터 교환의 다른 데이터 교환 형식과 소프트웨어 기능)으로 나눌 수 있는 여러 측면이 있다.문맥의 차이에도 불구하고, 두 범주는 데이터 교환에 대한 공통적인 특성을 보인다.

메시징 패턴의 일반 개념

통신에서, 메시지 교환 패턴(MEP)은 통신 채널을 구축하거나 이용하기 위해 통신 프로토콜이 요구하는 메시지의 패턴을 기술한다.통신 프로토콜은 모든 통신 당사자들이 동의하는 (또는 처리할 수 있는) 메시지를 나타내기 위해 사용되는 형식이다.통신 채널은 통신 당사자 사이의 메시지가 "트래블"할 수 있도록 하는 인프라다.메시지 교환 패턴은 의사소통 과정에서 당사자 간의 메시지 흐름을 기술하는데, 크게 두 가지 메시지 교환 패턴이 있는데, 요청-응답 패턴과 일방통행 패턴이다.

예를 들어 인터넷(채널)에서 콘텐츠를 볼 때 웹 브라우저(통신 당사자)는 HTTP(통신 프로토콜)를 사용하여 서버(다른 통신 당사자)에게 웹 페이지를 요청한 다음 반환된 데이터를 시각적 형태로 렌더링한다.요청-응답 메시징 패턴은 이렇게 작동한다.

대신에, 컴퓨터 네트워킹에서, 우리는 UDP 네트워크 프로토콜을 가지고 있다.발신 당사자가 메시지가 수신 당사자에게 도착하는지 여부에 관심이 없거나 수신 당사자가 "반복" 메시지를 만들 것으로 예상하는 일방 메시징 패턴과 함께 사용된다.[1]

장치 통신

이 절은 하드웨어 장치 간의 데이터 교환에 관한 것이다.기기가 데이터를 읽고 교환할 수 있도록 하기 위해 송신당사자(라디오 타워) 역할을 하는 하드웨어 장치에 의해 생성되며 수신 당사자인 다른 하드웨어 장치(예: 주방 라디오)로 해석될 수 있는 하드웨어별 프로토콜(무선 신호 등)을 사용한다.라디오의 예를 들어, 우리는 단방향 통신 패턴을 가지고 있으며, 메시지 교환 프로토콜은 무선 신호 그 자체다.

또한 기기 통신은 메시지 교환 시스템의 하드웨어 장치가 메시지 교환을 가능하게 하는 방법을 참조할 수 있다.예를 들어, 인터넷을 검색할 때 라우터, 스위치, 네트워크 어댑터 등 인터넷 트래픽을 통해 메시지를 전달하기 위해 여러 개의 서로 다른 장치가 함께 작동하는데, 라우터, 스위치 및 네트워크 어댑터는 하드웨어 수준에서 TCP 또는 UDP 패키지 형태로 신호를 주고 받는다.그러한 각각의 패키지는 우리가 서로 통신하는 하드웨어 장치 쌍으로 시야를 좁히면 그 자체로 메시지라고 할 수 있는 반면, 인터넷 통신의 일반적인 의미에서는 순차적으로 배열된 여러 패키지가 함께 이미지나 웹 페이지와 같은 의미 있는 메시지를 형성한다.

소프트웨어 통신

이 절에서는 소프트웨어 시스템 간의 메시징 통신 개념을 설명한다.메시지 데이터의 형식이 관련 장치의 유형과 기능에 의해 지원되는 프로토콜로 제한되는 장치 통신과는 달리(예를 들어, 컴퓨터 네트워킹에서 우리는 TCP와 UDP 프로토콜을 가지고 있다), 무전기는 특정 주파수의 전파를 송신할 것이고, 신호는 pe가 사용하는 Morse 코드 시퀀스를 점멸할 것이다.읽을 수 있다), 소프트웨어는 더 복잡하고 강력한 데이터 교환 형식을 확립할 수 있다.그러한 형식은 송신 당사자에 의해 기본 하드웨어가 전달할 수 있는 형태로 번역된 다음, 수신 당사자에 의해 하드웨어 특정 형식에서 통신 소프트웨어 시스템에 의해 설정된 원래 프로토콜에 부합하는 형식으로 해독될 것이다.이 상위 레벨의 데이터 교환은 보다 인간적인 판독 가능한 형태로 정보 전송을 가능하게 하며, 또한 메시징을 안전하게 만들기 위한 소프트웨어 암호화 및 암호 해독 기법의 사용을 가능하게 한다.또한, 소프트웨어 메시지 교환은 메시지 교환 패턴의 보다 다양한 변화를 가능하게 하며, 이는 단순한 요청-응답과 일방적 접근에 한정되지 않는다.마지막으로, 소프트웨어 통신 시스템은 메시지 전달을 최적화하는 데 사용될 수 있는 데이터 교환을 위한 다양한 채널을 제공할 수 있고, 특정 메시지를 수신할 당사자를 결정하는 데 도움이 되는 복잡한 선택 및 필터링 규칙을 설정할 수 있다.이것은 소프트웨어-주문 메시지 라우팅의 가능성을 가능하게 한다.그 결과, 주제의 개념(대상 그룹의 모든 수신 당사자가 메시지의 복사본을 전달받을 수 있는 위치)과 대기열(대상 그룹의 한 당사자만 메시지를 수신할 수 있는 위치)이 생겨났다.

앞에서 언급했듯이, 소프트웨어 메시징은 데이터 교환 프로토콜에서 더 많은 옵션과 자유를 허용한다.그러나, 통신 당사자들이 관련된 프로토콜의 세부사항에 합의하지 않는 한, 이것은 그리 유용하지 않을 것이며, 따라서 다수의 표준화된 소프트웨어 메시징 프로토콜이 존재한다.이 표준화를 통해 보통 별도의 조직에서 생성 및 유지 보수하고, 서로 다른 하드웨어 장치(서버, 컴퓨터, 스마트 기기 또는 IoT 컨트롤러)에서 운영될 수 있는 서로 다른 소프트웨어 시스템이 실시간 데이터 교환에 참여할 수 있다.

아래에는 오늘날에도 여전히 사용되고 있는 가장 인기 있는 소프트웨어 메시징 프로토콜 몇 가지가 열거되어 있다.이들 각각은 앞 절에서 설명한 메시징 개념에 대해 확장된 의미를 제공한다.

비누

메시지 교환 패턴이라는 용어는 SOAP(Simple Object Access Protocol) 내에서 확장된 의미를 갖는다.[2][3]SOAP MEP 유형:

  1. 내부 전용:이것은 일방향에 해당한다.소비자가 상태 응답만 제공하는 제공자에게 메시지를 보내는 표준 단방향 메시징 교환.
  2. 강력한 내장형:이 패턴은 신뢰할 수 있는 단방향 메시지 교환을 위한 것이다.전기 소비 장치는 공급자가 상태로 응답하는 메시지로 시작한다.반응이 상태일 경우 교환은 완료되지만, 반응이 과실일 경우 소비자는 반드시 상태를 가지고 대응해야 한다.
  3. In-Out: 이것은 요청-응답에 해당한다.소비자가 메시지로 개시하는 표준 양방향 메시지 교환, 제공자는 메시지나 결함으로 응답하고, 소비자는 상태로 응답한다.
  4. In-Option-Out: 제공자의 응답이 선택적인 표준 양방향 메시지 교환.
  5. Out-Only:In-Only의 역방향.주로 이벤트 알림을 지원한다.고장 메시지를 트리거할 수 없음.
  6. 강력한 Out-Only: 오류 메시지를 트리거할 수 있다는 점을 제외하면 아웃 전용 패턴과 유사함.아웃바운드 메시지가 전송을 개시한다.
  7. 아웃인: 인아웃의 역방향.제공자는 요청을 전송하고 교환을 개시한다.
  8. Out-Option-In:In-Option-Out의 역방향.이 서비스는 아웃바운드 메시지를 생성한다.수신 메시지는 선택사항("선택사항 삽입")이다.

øMQ

øMQ 메시지 큐잉 라이브러리는 사용할 메시징 패턴을 표시해야 하는 소위 소켓(기존 IP 및 유닉스 소켓에 대한 일반화의 일종)을 제공하며, 각 패턴에 최적화되어 있다.기본 øMQ 패턴은 다음과 같다.[4]

  • Request-reply는 일련의 고객을 일련의 서비스에 연결한다.원격 프로시저 호출 및 작업 배포 패턴 입니다.[clarification needed]
  • 게시-구독은 게시자 집합을 구독자 집합에 연결한다.이것은 데이터 분포 패턴이다.[clarification needed]
  • 푸시풀은 여러 스텝과 루프를 가질 수 있는 팬아웃/팬인 패턴으로 노드를 연결한다.이것은 병렬 작업 분배 및 수집 패턴이다.[clarification needed]
  • 전용 쌍은 두 개의 소켓을 전용 쌍으로 연결한다.이것은 구체적이고 고급화된 사용 사례에 대한 낮은 수준의 패턴이다.

각 패턴은 특정 네트워크 토폴로지를 정의한다.request-reply는 소위 "서비스 버스"를 정의하고, public은 "데이터 배포 트리"를 정의하며, push-pull은 "병렬화된 파이프라인"을 정의한다.모든 패턴은 무한 확장 가능하고 따라서 인터넷 규모에서 사용할 수 있는 방식으로 의도적으로 설계된다.[5]

쉬다

REST 프로토콜은 HTTP 프로토콜 위에 구축된 메시징 프로토콜로, 마찬가지로 메시지 교환의 요청-응답 패턴을 이용한다.HTTP의 주요 목표는 인간 최종 사용자를 대상으로 하는 웹 페이지와 파일을 인터넷을 통해 전달하는 것이지만, REST 프로토콜은 대부분 다른 소프트웨어 시스템 간의 통신에 사용되며, 마이크로 서비스 소프트웨어 아키텍처 패턴에서 핵심적인 역할을 한다.REST 프로토콜의 주목할 만한 특성 중 하나는 데이터를 다른 많은 형식(일반적으로 JSON 및 XML)으로 나타낼 만큼 충분히 다재다능하며, 그것이 나타내는 메시지에 추가적인 메타데이터 설명자를 제공한다는 점이다.메타데이터 설명자는 HTTP 헤더(기본 HTTP 프로토콜에 의해 표준화됨)로 표현되어 HTTP 표준을 따르기 때문에, 메시지 페이로드 해석 방법에 관한 수신 당사자의 지침으로 사용할 수 있다.그 때문에, REST는 개발자가 메시지 페이로드(JSON 또는 XML 모델)의 고수준 형식만 알면 되기 때문에, 다른 소프트웨어 시스템과 통신할 수 있는 소프트웨어 시스템의 개발을 크게 향상시킨다.실제 HTTP 통신은 대개 소프트웨어 라이브러리나 프레임워크에 의해 처리된다.REST 프로토콜의 또 다른 뛰어난 품질은 그 위에 다른 프로토콜 의미론을 구축하기에 적합하다는 것인데, 이것이 바로 아토아스(HIDTOAS)의 예다.

참고 항목

참조

  1. ^ Erl, Thomas (2005). Service Oriented Architecture: Concepts, Technology, and Design. Indiana: Pearson Education. p. 171. ISBN 0-13-185858-0.
  2. ^ http://www.w3.org/TR/soap12-part1/#SOAP W3C 권장 사항 v1.2의 SOAP MEPs
  3. ^ WSDL(Web Services Description Language) 버전 2.0: 추가 MEP
  4. ^ øMQ 사용 설명서
  5. ^ 인터넷 스택을 강타한 확장성 계층

외부 링크