Message Brokers와 ESB (스택 오버 플로우에서도)에 대해 다른 질문 / 기사를 살펴 보았습니다. Message Broker와 ESB의 CLEAR 구분 차이가 무엇인지에 대한 단서가 여전히 아닙니까? 이제 제품, Websphere Broker 및 Mule ESB를 비교하려고합니다!
첫째, (모든 버전) Webshere Broker는 ESB입니까? IBM의 제품 담당자는 ESB라고 주장합니다!
제한된 정보는 Message Broker가 HUB-SPOKE 모델에서 작동한다는 것을 알려줍니다. 그러나 ESB는 버스 아키텍처에서 작동합니다. 이제 지구상에서 무슨 의미입니까? 허브가 실패하는 경우 (사용할 수없는 경우)보다 읽은 다음 브로커가 완전히 실패합니다. ESB의 경우가 아닙니다 (그 사람들은 말합니다). 내가 여기서 이해하지 못하는 것은 “버스가 실패하면 어떻게됩니까?”입니다.
이제 ESB 및 브로커에 대한 일반적인 사항은 라우팅, 변환, 오케스트레이션 등을 제공한다는 것입니다. 둘 다이 기능을 제공하는 경우 왜 하나를 선택해야합니까?
또 다른 갈등 영역은 변환과 관련이 있습니다. ESB는 Message Broker와 비교할 때 다른 방식으로 ESB를 용이하게합니까? 나는 이것에 대한 통찰력을 정말로 원할 것입니다.
이제 수평 스케일링에 대해 이야기합니다. 누구를 능가합니까? 또는 둘 다 복잡성 (또는 기타 요인) 측면에서 동일하게 확장 가능합니까? 물론 Webshpere Broker는 각 상자 (각 CPU는 물론)에 대해 요금을 청구합니다. 상용 MULE ESB조차도 그렇게하지 않습니다. 비용 부분을 제외하고 ESB 스케일링 및 Message Broker 스케일링의 의미는 무엇입니까? ESB에서 서비스 수준으로 확장 할 수 있다는 것을 알고 있습니다. Message Broker에서 가능합니까?
답변
서비스 버스없이 변환 브로커를 사용할 수 있으며 그 반대도 가능합니다. 특정 제품의 관점에서 볼 때 각 제품이 다른 제품을 보완하는 방식 때문에 어떤 제품도 순수한 제품이라고 생각하지 않습니다. 일부 제품은 한 영역에서 강하고 다른 제품은 다른 영역에서 강합니다. 개별 문제를 가장 잘 다루는 기능에 따라 선택해야 할 수도 있습니다.
브로커는 ESB 제품보다 변환 체인을 구성하는 데 더 나은 기본 제공 “레고 블록”을 가질 수 있습니다. ESB로 서비스를 시작한 브로커는로드 상태에서 분쇄되어 제대로 확장되지 않거나 저널링을위한 강력한 저널링 및 도구가 부족할 수 있습니다.
일부 ESB를 사용하면 논리에서 심각한 오류가 발견되고 수정되면 데이터베이스 업데이트를 롤백하고 큐를 수정 된 응용 프로그램으로 재생할 수 있습니다. 나는 대부분의 중개인이 그 수준의 거래 지원을 통합한다고 생각하지 않습니다. 이것이 모든 “트랜잭션”에서 작동하려면 RPCish “데이터베이스 업데이트”와 같은 비즈니스 이벤트 (판매, 갱신, 소유권 변경 등)가되어야합니다.
답변
면책 조항 : 저는 IBM 컨설턴트이며 WebSphere ESB를 전문으로합니다. 이 의견은 공식적인 용량으로 남지 않았습니다.
ESB는 일반적으로 서비스 기반의 느슨한 결합 엔지니어링 방식 인 제품보다 아키텍처 패턴 또는 개념에 가깝습니다. 그것의 정의는 싸워졌고 정확하게 석재로 설정되지 않았습니다. 일반적으로 ESB는 기술적으로 관련이없는 서비스 세트로 인터페이스를 노출하고 다른 서비스에서 소비합니다. 일반적으로 허브 및 스포크 아키텍처는 없지만 가능합니다.
IBM은 확실히 WebSphere Message Broker와 WebSphere ESB를 모두 ESB를 쉽게 구축 할 수있는 제품으로 판매합니다 (DataPower 하드웨어 어플라이언스와 함께). 그것들은 다른 기술적 인 뿌리를 가지고 있지만, 목적 상 겹치는 부분이 있습니다. 또한 ‘ESB 제품’으로 표시되지 않은 다른 많은 것들로 ESB를 구축 할 수는 없습니다.
모든 질문에 대한 답변은 아니지만 IBM 부분을 다룰 것입니다.
답변
Message Broker와 ESB (Enterprise Service Bus)의 차이점은 주로 ‘버스’입니다.
나에게 Message Broker는 하나의 구조에서 다른 구조로 데이터를 변환하거나 내용을 수정하는 하나의 (일반적으로 큰) 프로세스입니다.
ESB는 메시지 지향 미들웨어 (MOM) 및 추가 서비스이며 그 중 하나 는 메시지 브로커 일 수 있습니다 . 따라서 ESB는 Message Broker를 구성 요소 중 하나로 포함 할 수 있습니다. 버스는 하나 이상의 프로세스로 구성되어 있습니다. 그렇지 않으면 ‘버스’라고 부르지 않습니다. 버스의 특성은 서로 다른 작업을 수행하는 여러 구성 요소가 있으며 각 구성 요소는 MOM을 통해 통신하고 특정 형태의 ‘공통 데이터 형식’을 준수한다는 것입니다. 버스는 MOM으로 데이터를 전송하는 응용 프로그램, 데이터베이스 어댑터, 메시지 브로커, MOM 브리지 등으로 구성됩니다.
분리는 약간 점진적이지만 Message Broker 아키텍처와 버스의 가장 큰 차이점은 세분성 입니다. 응용 프로그램 A, B, .., Z와 몇 개의 데이터베이스를 통합하는 것이 목표라면, 각각과 모두를 연결하는 하나의 큰 메시지 브로커로이를 수행 할 수 있습니다. 또는 여러 개의 작은 구성 요소가 작은 작업을 대신하는 ESB를 사용합니다. 예를 들어 한 어댑터는 A에 연결하고 다른 어댑터는 B에 연결하지만 (변환하지는 않음) 각 어댑터는 하나 이상의 Message Broker에 해당 항목을 전송합니다. 각 브로커는 가능한 한 단순하게 유지해야합니다. ‘A’또는 ‘B’의 데이터 모델에 대해 알아야합니다. 좋은 ESB는 버스에서 공통적 인 데이터 정의를 가져야하며 개별 애플리케이션의 ‘차이 성’을 추상화해야합니다.
변환 : ESB는 Message Broker와 함께 제공되지 않는 한 변환에 도움이되지 않습니다. 그러나 각 ESB에는 메시지 브로커가 포함되어야합니다. Message Broker는 변환에 대한 버스 전문가가되어야합니다.
수평 적 확장 : 연결해야 할 3 가지 (현재와 영원히) 만 있다면 본격적인 ESB를 얻는 데 노력할 가치가 없습니다. Message Broker는 하나의 큰 프로세스라는 장점이 있습니다. 모든 것을 구성하고 모든 데이터 매핑, 필터링 및 라우팅을위한 중앙 위치를 가질 수 있습니다.
그러나 30 개의 응용 프로그램을 연결하면 하나의 Message Broker가 중단 될 수 있습니다. 물론 더 많은 인스턴스를 구매하고, 중복 작업을 수행 할 수 있지만 작업을 ‘현지화’로 변경해야합니다. 각 응용 프로그램의 어댑터 (각각 하나의 작은 Message Broker 인스턴스 일 수 있음)는 추상 공통 데이터 모델 (예 : 공유 XSD가있는 XML)을 생성 및 / 또는 수신 할 수 있어야합니다. 변환 작업을위한 중앙 Message Broker가있을 수도 있지만 해당 인스턴스는 데이터 모델 A 또는 B를 인식하지 않아야합니다. 따라서 ESB는 모든 것을 중앙 위치에 유지하는 대신 처리를 전문가 구성 요소로 이동해야합니다.
답변
며칠 전에 Udi Dahan의이 기사를 읽었습니다. 이것이 내가 느끼는 것이 하나의 근본적인 차이점에 대한 명확한 시각을 제공 할 수 있습니다.
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
인용 :
주어진 이벤트 유형에 대해 단일 게시자 만있을 수 있다는 규칙은 버스를 브로커와 차별화하는 것 중 하나이지만 둘 다 가입자를 여러 명 가질 수 있습니다.
…
불행하게도, Enterprise Service Bus의 배너로 판매되는 많은 브로커 스타일 기술이 있습니다. 일부 제품은 중앙 및 분산 방식으로 배포 할 수 있지만 ( “페더레이션”또는 “임베디드”모드라고도 함) 많은 제품이 “이벤트 유형 당 단일 게시 끝점”규칙을 적용하지 않습니다.
이 제약이 없으면 실수하기가 너무 쉽습니다.
도움이 되길 바랍니다.
답변
엔터프라이즈 서비스 버스는 비즈니스에 세 가지 주요 값을 제공합니다.
- 컨텍스트 또는 컨텐츠 기반 트랜잭션 라우팅;
- 한 메시지 도메인에서 또는 다른 메시지 도메인 또는 전송으로 변환
- 다 대 다 서비스 연결.
ESB는 느슨한 서비스 결합을 제공하고 서비스를 처음 구상하거나 개발할 때와 완전히 다른 애플리케이션 컨텍스트로 서비스를 재구성 할 수 있도록하며 애플리케이션을 다시 코딩 할 필요없이 애플리케이션의 재사용을 촉진합니다. WebSphere Message Broker (또는 현재 IBM Integration Bus)는 Enterprise Service Bus의 대표적인 예입니다. 몇 줄로 큰 힘을 발휘하는 코드의 단순성에 대한 예를 보려면 여기에서 내 게시물을 볼 수 있습니다 : http://soabus.org/viewtopic.php?f=3&t=13 . IIB 런타임 내부의 기본 구성을 논리 메시지 트리 라고합니다.(LMT). 개발자가 원하는 것은 LMT에서 작동하는 것입니다. ESQL은 개발자가 LMT에서 이러한 작업을 수행하는 데 사용할 수있는 가장 효율적인 언어입니다 (예 : Java, PHP, Python 등). 많은 다른 언어가 지원되지만 ESB 개발의 효율성과 용이성에 가까운 다른 제품은 없습니다. 이러한 애플리케이션의 코딩 중 90 %가 노드를 팔레트로 끌어서 놓기 때문에 IBM Integration Bus보다 애플리케이션이 향상됩니다. 따라서 메시지 흐름 개발자가 코딩의 10 % 만 수행 할 수 있습니다. 그런데 WebSphere ESB는 IBM에 의해 중단되었으며 IBM Integration Bus에 대한 많은 경쟁 제품은 현재 몇 년 동안 새로운 개발을 보지 못했습니다. 다양한 ESB 제품 목록은 soabus.org에서 확인할 수 있습니다.
답변
그 이후로 IBM은 ESB 오퍼링의 이름을 변경 한 적이 있기 때문에 그 이름이나 벤더로 가지 않을 것입니다.
ESB를 통해 비즈니스 정보가 여러 하드웨어 및 소프트웨어 플랫폼에서 서로 다른 응용 프로그램간에 흐를 수 있습니다. ESB는 애플리케이션 연결 논리를 보유하고 비즈니스 로직을 최소화하는 미들웨어 계층에 가깝습니다. 이를 통해 응용 프로그램은 데이터를 필요로하는 다른 N 개의 응용 프로그램과 상호 작용하는 방법에 대한 연결 논리를 포함하지 않아도 최선의 작업을 수행 할 수 있습니다. ESB 아키텍처는 기업에서 지점 간 스파게티 혼란을 해결하려고합니다.
ESB와 Message Broker는 서로 동의어이지만 위의 응답 중 하나에서 Messages Broker 패턴이 더 큰 ESB 도메인의 일부임을 강조했습니다. ESB의 문자 “B”는 컴퓨터 아키텍처의 버스 (하드웨어)와 유사합니다. 마더 보드 또는 컴퓨터의 버스는 컴퓨터 기능을 위해 다양한 구성 요소를 연결합니다. ESB는 기업의 다양한 서비스를 연결하는 소프트웨어 기반 버스입니다. 허브 앤 스포크는 ESB 아키텍처가 지원하는 패턴 중 하나입니다. 모 놀리 식 세계에서 각 공급 업체는 ESB를 사용할 수 있도록 고 가용성 배포 아키텍처를 가지고 있습니다. 모든 ESB 공급 업체의 최신 제품은 마이크로 서비스 기반 배포 모델 또는 iPAAS라고하는 자체 클라우드에서 호스팅됩니다. 따라서 선택한 배포 모델을 기반으로 한 자체 치유 기능으로 버스가 일시적으로 중단되거나 중단되지 않습니다. 마이크로 서비스 기반 배치 또는 iPAAS를 통해 ESB는 이제 선택한 공급 업체에 따라 다양한 기능을 갖춘 자동 확장 기능 (수평 또는 수직)을 갖습니다.
ESB가 제공하는 매우 높은 수준의 기능을 위해 다음 링크를 통해 이동할 수 있습니다 => https://en.wikipedia.org/wiki/Enterprise_service_bus
답변
