메시지 중개인과 ESB의 차이

Question

나는 메시지 중개인과 ESB (stackoverflow에서도)에 대한 다른 질문/기사를 겪었습니다. 메시지 중개인과 ESB의 명확한 경계 차이는 무엇입니까? 이제 저는 제품, WebSphere Broker 및 Mule ESB를 비교하려고합니다!

첫째, (모든 버전) Webshere Broker가 ESB입니까? 우리의 IBM 제품 담당자는 그것이 ESB라고 주장합니다! (나는 그것에 대해 놀라지 않습니다).

제한된 정보는 메시지 중개인이 허브 스포크 모델에서 작동한다고 말합니다. 그러나 ESB는 버스 아키텍처에서 작동합니다. 이제 지구상에서 그게 무슨 뜻입니까? 허브가 실패한 경우보다 읽었습니다 (사용할 수 없습니다). 브로커가 완전히 실패합니다. ESB의 경우가 아닙니다 (그래서 그 사람들은 말합니다). 내가 여기서 이해하지 못하는 것은 "버스가 실패하면 어떻게 될까요?

이제 ESB와 브로커에 대한 일반적인 것들은 라우팅, 변형, 오케스트레이션 등을 제공한다는 것입니다. 따라서 두 가지 모두 이것을 제공한다면 왜 내가 다른 것을 선택해야합니까?

갈등의 또 다른 영역은 변화에 관한 것입니다. ESB가 메시지 중개인과 비교할 때 다른 방식으로이를 촉진합니까? 나는 이것에 대한 통찰력을 정말 좋아할 것입니다.

이제 수평 스케일링에 대해 이야기합니다. 누가 누구를 능가합니까? 또는 둘 다 복잡성 (또는 다른 요인) 측면에서 똑같이 확장 가능합니다. 물론 비용이 현명한 WebShpere Broker는 각 상자에 대해 요금을 청구합니다 (각 CPU는 물론). 나는 상업용 노새 ESB조차도 그렇게하지 않는다고 생각합니다. 비용 부분을 제외하고 ESB 스케일링 및 메시지 중개인 스케일링의 의미는 무엇입니까? ESB의 서비스 수준으로 확장 할 수 있다는 것을 알고 있습니다. 이것이 메시지 중개인에서 가능합니까?

Answer 1

서비스 버스없이 변형 브로커를 사용할 수 있으며 그 반대도 마찬가지입니다. 특정 제품의 관점에서 나는 각자가 서로를 보완하는 방식 때문에 어느 누구도 순전히 하나 또는 다른 하나라고 생각하지 않습니다. 일부 제품은 한 영역에서 더 강하고 다른 제품은 다른 지역에서 더 강합니다. 아마도 어떤 기능이 개별 문제에 가장 적합한지를 기반으로 선택해야 할 것입니다.

브로커는 ESB 제품보다 변환 체인을 구성하기 위해 더 나은 "레고 블록"을 가질 수 있습니다. ESB가 부하에 따라 분쇄 될 수 있으며 규모가 잘 유지되지 않거나 저널을 다루기위한 강력한 저널링 및 도구가 부족할 수 있습니다.

일부 ESB는 논리의 심각한 오류가 발견되고 수정되면 데이터베이스 업데이트를 롤백하고 수정 된 응용 프로그램으로 재생할 수 있습니다. 나는 대부분의 중개인이 그 수준의 거래 지원을 통합한다고 생각하지 않습니다. 이것이 "거래"에서 모든 "거래"에서 작동하기 위해서는 RPCISH "데이터베이스 업데이트"와 같은 것이 아니라 비즈니스 이벤트 (판매, 갱신, 소유권 변경 등)가되어야합니다.

Answer 2

면책 조항 : 저는 IBM 컨설턴트이며 WebSphere ESB를 전문으로합니다. 이 의견은 공식적인 역량으로 남아 있지 않습니다.

ESB는 제품보다 건축 패턴 또는 개념에 가깝습니다. 그것의 정의는 싸워서 돌로 정확하게 설정되지 않았습니다. 일반적으로 ESB는 관련없는 (기술적 인 의미) 서비스 세트 - 인터페이스를 노출시키고 다른 서비스에서 소비합니다. 일반적으로 허브와 스포크 아키텍처가 포함되지는 않지만 가능합니다.

IBM은 확실히 WebSphere 메시지 브로커와 WebSphere ESB를 데이터로서 ESB를 쉽게 구축 할 수있는 제품 (데이터 패러 하드웨어 어플라이언스와 함께)을 판매합니다. 그들은 다른 기술적 뿌리를 가지고 있지만 목적에는 약간의 겹침이 있습니다. 또한 'ESB 제품'으로 브랜드화되지 않은 다른 많은 것들로 ESB를 구축 할 수 없다고 말하는 것은 아닙니다.

그것은 모든 질문에 대답하지는 않지만 IBM 부분을 다루기를 바랍니다.

Answer 3

메시지 중개인과 ESB의 차이점은 주로 '버스'라는 단어입니다.

나에게 메시지 브로커는 데이터를 한 구조에서 다른 구조로 변환하거나 컨텐츠를 수정하는 하나 (미국적으로 큰) 프로세스입니다.

ESB는 메시지 지향 미들웨어 (MOM)와 추가 서비스입니다. 할 수 있습니다 메시지 중개인. 따라서 ESB는 메시지 브로커를 구성 요소 중 하나로 포함시킬 수 있습니다. 버스는 하나 이상의 프로세스로 구성되며 그렇지 않으면 '버스'라고 부르지 않습니다. 버스의 특성은 서로 다른 작업을 수행하는 여러 구성 요소가 있으며 각 구성 요소는 엄마를 통해 의사 소통하고 어떤 형태의 '공통 데이터 형식'을 고수하는 것입니다. 버스는 다음과 같습니다. 응용 프로그램은 엄마, 데이터베이스 어댑터, 메시지 중개인, 엄마 브리지 등으로 데이터를 전송합니다.

분리는 약간 점진적이지만 메시지 중개 아키텍처와 버스의 가장 큰 차이점은 다음과 같습니다. 세분성. 작업이 응용 프로그램 A, B, .., Z 및 몇 개의 데이터베이스를 통합하는 경우 각각을 연결하는 하나의 큰 메시지 브로커로이를 수행 할 수 있습니다. 또는 여러 개의 작은 구성 요소가 작업을 거의 인수하는 ESB의 경우. 예를 들어, 하나의 어댑터는 A에 연결하고, 다른 어댑터는 B에서 B에서 B에서 B에서 B로 연결되면 각각은 물건을 하나 이상 (또는 그 이상) 메시지 브로커로 보냅니다. 각각은 가능한 한 간단하게 유지되어야합니다. 'a'또는 'b'의 데이터 모델에 대해 알아야합니다. 좋은 ESB는 버스에 공통 데이터 정의를 가져야하며 개별 응용 프로그램의 '차이'에서 추상화해야합니다.

변환 : ESB는 메시지 중개인과 함께 제공되지 않는 한 변환에 도움이되지 않습니다. 그러나 각각의 좋은 ESB에는 어쨌든 메시지 중개인이 포함되어야합니다. 메시지 중개인은 변환의 버스 전문가가되어야하지만 다른 것은 없습니다.

수평 스케일링 : 연결할 3 가지만 (현재와 영원히) 만 있다면, 아마도 본격적인 ESB를 얻기 위해 노력할 가치가 없을 것입니다. 메시지 중개인은 단 하나의 큰 프로세스라는 장점이 있습니다. 거기에있는 모든 것을 구성하고 모든 데이터 매핑, 필터링 및 라우팅에 대한 중앙 위치가있을 수 있습니다.

그러나 연결할 30 개의 응용 프로그램이 있으면 하나의 메시지 중개인이 절단 중단 될 것입니다. 물론 더 많은 인스턴스를 구매하고, 중복을 실행하는 등을 운영 할 수는 있지만, 전략을 변경하여 작업을 '현지화'해야합니다. 각 응용 프로그램의 어댑터 (각각 하나의 작은 메시지 브로커 인스턴스 일 수 있음)는 추상적 인 공통 데이터 모델 (예 : 공유 XSD와 함께 XML)을 생성 및/또는 수신 할 수 있어야합니다. 변환 작업을위한 중심 메시지 브로커가있을 수도 있지만, 해당 인스턴스는 데이터 모델 A 또는 B를 인식하지 않아야합니다. 따라서 ESB는 모든 것을 중앙 위치에 유지하는 대신 전문가 구성 요소로 처리해야합니다.

Answer 4

방금 며칠 전에 Udi Dahan 의이 기사를 읽었습니다.이 기사는 내가 느끼는 것이 하나의 근본적인 차이라고 생각하는 것을 더 명확하게 볼 수 있습니다.

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

인용 :

주어진 이벤트 유형에 대한 단일 게시자 만있을 수 있다는 규칙은 버스를 중개인과 차별화하는 것 중 하나이지만 둘 다 가입자가 여러 명을 가질 수 있습니다.

...

불행히도, 엔터프라이즈 서비스 버스의 배너 아래에 판매되는 많은 브로커 스타일 기술이 있습니다. 일부 제품은 중앙 집중식 및 분산 방식 (때때로 "페더레이션"또는 "임베디드"모드로 배치 할 수있는 기능이 있지만 많은 제품은 "이벤트 유형 당 단일 게시 엔드 포인트"규칙을 시행하지 않습니다.

이 제약이 없으면 실수를하기가 너무 쉽습니다.

도움이되기를 바랍니다.

Answer 5

엔터프라이즈 서비스 버스는 비즈니스에 세 가지 핵심 가치를 제공합니다.

1. 트랜잭션의 상황 또는 컨텐츠 기반 라우팅;
2. 하나의 메시지 영역에서 전송 또는 다른 메시지 영역 또는 전송으로 변환;
3. 다수의 서비스 연결.

ESB는 서비스의 느슨한 커플 링을 제공하고 서비스를 처음 구상 또는 개발 한 것보다 완전히 다른 응용 프로그램 컨텍스트로 서비스를 재구성 할 수 있으며 응용 프로그램을 재구성 할 필요없이 응용 프로그램 재사용을 촉진합니다. WebSphere Message Broker (또는 현재 IBM Integration Bus라고 함)는 엔터프라이즈 서비스 버스의 대표적인 예입니다. 몇 줄로 큰 힘을 부여하는 코드의 단순성의 예는 여기에서 내 게시물을 볼 수 있습니다. http://soabus.org/viewtopic.php?f=3&t=13 . IIB 런타임 내부의 기본 구성을 논리적 메시지 트리 (LMT). 개발자가하고자하는 모든 것은 LMT에서 어떤 유형의 운영입니다. ESQL은 개발자가 LMT에서 이러한 작업을 수행하는 데 사용할 수있는 가장 효율적인 언어입니다. 비록 다른 많은 언어가 지원되지만 (예 : Java, PHP, Python 등) ESB 개발의 효율성과 용이성에 가깝지 않습니다. 이 응용 프로그램 코딩의 90 %가 팔레트에 노드를 드래그하고 삭제하여 IBM 통합 버스보다 응용 프로그램이 수행됩니다. 이로 인해 코딩의 10 %만이 메시지 흐름 개발자가 수행해야합니다. 그건 그렇고, WebSphere ESB는 IBM에 의해 중단되었으며 IBM Integration Bus와의 많은 경쟁 제품은 현재 몇 년 동안 새로운 개발을 보지 못했습니다. 다양한 ESB 제품 제품 목록은 soabus.org에서 볼 수 있습니다.