"메시지 전달"시스템과 "이벤트 기반"시스템의 장점

내 질문은 다소 교육받지 않은 관점에서 비롯됩니다.

" 메시지 전달 "시스템과 " 이벤트 기반 "시스템 의 상대적인 장점은 무엇입니까?

왜 하나가 다른 하나를 선택합니까? 그들의 강점과 약점은 무엇입니까?

"이론"뿐만 아니라 "실제"도 알고 싶습니다.

편집하다:

특정 문제 :

소규모 서비스로 작동하는 플러그 가능한 구성 요소 시스템을 만들고 싶습니다 (각각 작은 작업을 수행하거나 정보를 제공함).

서비스는 다음을 수행 할 수 있습니다.

• 한 서비스의 출력이 다른 서비스의 입력 중 하나로 작동 할 수 있도록 계층화
• 이전 문장에서 언급 한 것처럼 특정 입출력 관계없이 하나의 서비스가 다른 서비스에 의해 포함될 수 있도록 포함 계층 구조를 가짐

이 시스템의 목표는 다른 시스템에서 한 수준의 낮은 수준의 이벤트 흐름을보다 높은 수준의 정보 및 기능으로 변환하고 다른 일련의 이벤트를 제공하는 다른 시스템으로 다시 채널을 제공하는 것입니다.

충분하지 않으면 더 자세한 정보를 제공 할 수 있습니다.

좀 더 둘러 본 후. 이 와 이 아마 더 나은 내 상황을 설명합니다.

이것은 내 상황에 잘 맞는 것 같습니다 : http://akka.io/

필자의 경험에 따르면 유일한 차이점은 대부분의 메시지 전달 시스템에서 메시지를 보낸 사람이 메시지를받는 사람이 누구인지를 알고 있다는 사실입니다.

따라서 이벤트와 이벤트를 수신 한 이벤트를 수신 한 사람을 대상으로하는 대신 발신자가 의도 된 수신자 또는 논리적 수신자 그룹의 일부 ID를 정의한 다음 메시지를 직접 보내거나 메시지 브로커를 통해 전달합니다. (OS는 이벤트 기반 시스템에서 메시지 브로커로 볼 수 있지만).

분명히 Telastyn이 C #의 이벤트 구현으로 언급 한 스레딩 사례가 있지만 다른 스레드에서 실행되는 자체 pub / sub 모델을 만들 수 있습니다.

이것은 사과와 오렌지입니다.

이벤트 중심 시스템은 이벤트가 발생함에 따라 메시지 (이 컨텍스트의 메시지는 불변 의 비공유 데이터를 암시 함 )로 전달 된 이벤트에 반응 할 수 있습니다 . 이것은 순수한 건축 디자인입니다.

메시지 전달 시스템은 메시지 를 작성하고 전달하는 이벤트에 의해 구동 될 수 있습니다 . 이것은 순전히 구현 디자인입니다.

둘은 상호 배타적이지 않습니다.

예 : Erlang에서와 같이 메시지 전달 환경 일 수있는 모든 언어로 이벤트 중심 디자인을 구현할 수 있습니다 .

"메시지 전달"과 "이벤트 기반"의 혼동은 아키텍처와 구현 세부 사항과 관련이 있습니다. 실제로 OS 제공 메시지를 사용하여 구현하는 이벤트 중심 시스템을 보았습니다. 나는 당신이 정말로 건축 아이디어를 언급하고 있다고 생각합니다.

많은 사람들이 이미 지적한 것처럼 "메시지 전달"과 "이벤트 기반"은 모호성을 피하기에 충분한 용어가 아닙니다.

"메시지 전달"시스템과 "이벤트 기반"시스템의 상대적인 장점은 무엇입니까?

메시지 전달

"메시지 전달"시스템이라고 말할 때 한 객체가 특정 다른 객체에 메시지를 보내는 시스템에 대해 이야기하고 있다고 생각합니다. 이 패러다임을 기반으로 한 시스템을 생각할 때, 더 일반적으로 무언가를 감지하는 물체가 무언가에 대해 알아야 할 사람을 알고있는 시스템을 생각합니다. (알고있는 방법을 지정하지 않고 알고 있습니다.)

이 유형의 아키텍처는 생산자와 소비자가 잘 알려진 시스템에 매우 적합합니다. 메시지 제작자는 메시지를받는 사람을 알고 있거나 소비자는 메시지를받을 사람을 알고 있어야합니다.

뱅킹 응용 프로그램을 작성하는 경우 거래를 누가 보내고 있는지, 누가 누구인지 알고 싶어 할 것입니다.

이벤트 기반

"이벤트 기반"시스템이라고 말할 때 내가 생각하고있는 다른 시스템은 어떤 사람이 누구에게 응답하는지 알지 못하고 객체가 "이벤트"를 발생시키는 시스템입니다.

이러한 유형의 이벤트 중심 아키텍처는 생산자가 이벤트를 소비하는 사람을 신경 쓰지 않거나 소비자가 실제로 누가 이벤트를 생산했는지 신경 쓰지 않는 시스템에 매우 유용합니다.

일반적으로 이러한 시스템은 소비자와 생산자 간의 관계를 모르고 관계가 역동적 일 것으로 예상되는 곳에서 유용합니다.

내가 사용한 한 시스템은 응용 프로그램이 실제로 런타임에로드 된 동적으로 구성된 모듈 (플러그인)으로 구성된 시스템이었습니다. 모듈이로드되면 모듈은 관련된 이벤트를 등록합니다. 그 결과 기능 확장이 매우 쉬운 시스템이 탄생했습니다.

예를 들어 조건 A가 이벤트 EA를 발생시켜 일반적으로 응답 RA가 발생했다고 가정 해 봅시다. 응답 RA를 발생시킨 오브젝트는 단순히 이벤트 EA를 수신하도록 등록하고 도착했을 때 조치를 취했습니다. 이제 RA_1이라는 EA에 새로운 응답을 추가하려고합니다. 이를 위해 EA를 찾고 응답 RA_1을 생성하는 새 객체를 추가하기 만하면됩니다.

다음은 몇 가지 예입니다 (용어 사용).

• "메시지 전달" : 상사가 시간표를 작성하라는 메시지를 표시합니다.
• "이벤트 주도" : 부서 비서가 모든 사람에게 자신의 작업 표 마감일을 알리는 이메일을 보냅니다.

SOA에는 명령 메시지 및 이벤트 메시지 개념이 있습니다. 둘 다 필요합니다.

그러나 명령 메시지는 엔드 포인트가 일부 기능을 수행하도록 명시 적으로 요청하므로 수신자 엔드 포인트에 대한 더 높은 작동 결합을 갖습니다. 특정 엔드 포인트에 연결될 필요는 없습니다 (실행 시간에 구성하거나 결정할 수 있음).

반면, 이벤트 메시지는 보낸 사람이받는 사람이 메시지로 무엇을할지 알지 못하므로 보낸 사람 /받는 사람간에 동작 연결이 없습니다. 누구든지 이벤트에 가입 했는지조차 알지 못합니다 .

더 많은 배경 지식을 얻으려면 여기 내 서비스 버스 사이트를 숙독하십시오 : http://www.servicebus.co.za

필자의 경험에 따르면이 둘의 가장 큰 차이점은 메시지 전달 시스템의 메시지는 일류 개체이며 이벤트 기반 시스템의 이벤트는 훨씬 단순하다는 것입니다. 메시지는 정보를 전달하는 경향이 있으며 해당 정보는 변환, 저장, 검색 및 재전송 될 수 있습니다. 이벤트는 더 작고 더 집중된 정보 비트를 운반하는 경향이 있으며,이 정보는 즉시 소비 된 후 폐기됩니다. 이들은 메시지 소스에서 하나 이상의 이벤트 싱크로 직접 전송되는 반면, 메시지는 여러 수신자간에 라우팅되는 경우가 많으며 경로를 따라 어떤 지점에서든 변환 / 번역 / 래핑되거나 처리 될 수 있습니다. 그들은 비슷한 기술 (버스, 대기열, 필터 등)을 사용하지만 실제로는 다른 짐승입니다.

실용적인 관점에서, 메시지는 일반적으로 발신자의 주소 공간에서 수신자의 주소 공간으로 복사되는 (또는 불변의 객체로 강제되는) 메모리 블록으로 구현되므로 스레드 안전성을 즉시 얻을 수 있습니다.

메시지 전달의 경우 발신자가 수신자를 지정해야하지만 다른 경우에는 메시지를 사서함에 게시 할 수 있고 누구나 해당 사서함의 메시지를들을 수 있으므로 얼마나 밀접하게 연결되어 있는지에 대한 유연성이 있습니다. 물론 계약이 "이 이벤트 가 발생 하면이 사서함에 메시지를 게시하겠습니다"라는 사서함이있을 수 있습니다.

이벤트의 경우 이벤트 소유자에게 대리인 또는 콜백을 등록합니다. 객체 지향 프로그래밍에서 이것은 이벤트 소유자가 이벤트를 받도록 등록 된 객체에 대한 참조를 유지함을 의미합니다. 이로 인해 이벤트 처리기를 등록 취소하는 것을 잊어 버린 객체를 알아 내려고 부기 악몽이 발생할 수 있습니다. 대상이 더 이상 유용한 작업을 수행하지 않더라도 이벤트 소유자가 가비지 수집 될 때까지 대상을 가비지 수집 할 수 없습니다.

개인적으로 Windows GUI 프로그래밍 등과 같이 이벤트가 발생하는 경우를 제외하고는 이벤트를 전달하는 메시지를 선택합니다.