이전 직장에서 "Enterprise Service Bus"(ESB)에 대한 이야기가 많았습니다. 나는 그것에 대한 개념 책의 일부를 읽었지만 구체적인 용어로 구현 / 통합하는 방법을 실제로 이해하지 못했습니다. SOA / queueing / directory services / etc에 익숙합니다. 하지만 ESB가 정확히 무엇인지 이해하지 못합니다.
모든 앱을 다른 방식으로 연결하는 것이 구체적인 것 (서비스 / 서버 / 브로커 등)입니까, 아니면 시스템을 설계하는 개념적 방법일까요?
좋은 예에 대한 설명이나 링크는 대단히 감사하겠습니다. 감사.
답변:
상당히 높은 수준의 추상화 개념입니다. 핵심 개념은 ESB가 기업이 코드를 작성하지 않고도 애플리케이션을 연결할 수 있도록 미들웨어와 인터페이스를 제공한다는 것입니다.
여기에는 호환되지 않는 프로토콜, 데이터 및 상호 작용을 조정하기위한 중재가 포함될 수 있습니다.
모든 것이 통과하는 중앙 버스의 아이디어는 추가적인 추상화 계층을위한 기회를 제공합니다. 업계 표준을 사용하여 다른 애플리케이션, 클라이언트 등을이 버스에 "연결"하면 서로 다른 요구를 가진 새로운 서비스, 데이터 소스, 클라이언트를 비교적 쉽게 연결할 수 있습니다.
실제 구현에 관한 한 그것은 대기업 지원 비즈니스의 영역입니다. 매우 유행어이지만 목표는 인터넷과의 비교를 통해 어느 정도 작은 수준에서 이해할 수있는 이상입니다.
용도와 데이터가 매우 다른 하나의 큰 통신 버스는 모두 프로토콜을 표준화합니다.
실제로 브라우저가 FTP 클라이언트를 호출하지 않고 FTP 사이트에 액세스 할 수 있도록하는 HTTP-FTP 커넥터를 작성할 수 있습니다 (일반적으로 현재 브라우저에 내장 됨).
매쉬업은 흥미로운 구현을 보여줍니다. 샌프란시스코 당국의 버스 경로 데이터, Google의지도, yahoo의 스시 바 위치를 평가하고 가장 가까운 스시 바를 제공하는 간단한 쿼리를 실행하여 가중치를 부여합니다. 더 나은 술집을 위해 조금 더 멀리 이동할 의향이 있습니다.
완전히 다른 모든 서비스는 자체적으로 호환되지 않지만 표준 커넥터 (예 : yahoo 파이프)를 사용하면 응집력 있고 유용한 전체로 통합 될 수 있습니다.
-아담
면책 조항 : 저는 IBM에서 근무하며 ESB를 구축하도록 설계된 IBM 제품인 WebSphere ESB에 대해 컨설팅합니다. 다음은 제 의견이며 반드시 IBM의 입장을 반영하는 것은 아닙니다.
안타깝게도 ESB는 사람마다 다릅니다.
저에게 ESB는 SOA (Service-Oriented Architecture)에 삽입 할 수있는 모든 기술로, 서로 다른 시스템을 함께 연결할 수 있습니다. 종종 프로토콜 변환, 메시지 수정, 라우팅, 로깅, 보안 게이트웨이 역할 등의 기능을 수행합니다. 예를 들어, ESB를 사용하여 이전에는 JMS 기반 서비스로 웹 서비스로만 사용할 수 있었던 서비스를 노출 할 수 있습니다.
이 점에서 ESB 구현 (또는 더 정확하게 말하면 ESB를 구축하기 위해 판매되는 소프트웨어)는 목적이 다소 다르지만 메시징 또는 대기열 브로커로 알려진 것과 기술적으로 유사합니다. , (두문자어에서 알 수 있듯이) 메시지를 한 곳에서 다른 곳으로 이동하는 것이 아니라 서비스를 중심으로하기 때문입니다. 기술적으로 구별이 얼마나 중요한지는 의견의 문제입니다.
상업용 ESB에 대한 나의 경험은 해결하는만큼 많은 문제를 일으키는 과장되고 값 비싼 기술이라는 것입니다. ESB는 새로운 시스템과 레거시를 연결하고 메시지는 버스를 통해 전송되며 모든 것이 다른 모든 것과 원활하게 통신 할 수 있습니다. 탄력성, 오케스트레이션을 도입하면 매우 강력한 엔터프라이즈 응용 프로그램 소프트웨어가 있습니다.
문제는 그것들을 실제로 사용하려고 할 때 발생하며, 버스 작성, 메시지 구조 작성 등의 오버 헤드가 이점을 능가 할 수 있습니다. 고비용 항목 인 ESB는 그렇지 않은 모든 기술 문제에 대한 만병 통치약으로 간주되며, 연결된 애플리케이션 / 데이터가 아닌 버스에서 너무 많은 시간을 소비합니다. 여러 경쟁 표준이 동일한 조직에서 우위를 차지하기 위해 싸우는 경우가 종종 있으며 이러한 시스템이 실제로 수정해야하는 고전적인 기술 지배 사일로로 이어집니다.
IMHO는 일반적으로 필요한 시스템 사이에서만 웹 서비스를 사용하여 적은 수의 특정 인터페이스를 만드는 것이 훨씬 좋습니다.
그것은 기본적으로 시스템을 설계하는 개념적인 방법입니다. 소프트웨어 회사는 'ESB'스티커를 붙임으로써 더 많이 판매하려고하고 관리자는 ESB가 '상위 수준'에서 좋아 보이기 때문에 좋아합니다.
ESB는 기본적으로 데이터 모델 및 구조 정의 관리가 추가 된 MOM (메시지 지향 미들웨어)입니다. 해당 버스의 모든 애플리케이션 및 어댑터에 대한 공통 데이터 정의가 있습니다 (공유 XSD가있는 XML 일 수 있음). 연결되는 모든 것은이 데이터 정의를 준수하는 정보를 전송해야합니다. ESB는이 공통 데이터 정의의로드, 공유 및 버전 관리를 지원합니다. 새 구성 요소를 ESB에 연결할 때 MOM에 연결할 때보 다 기본적으로 더 많은 '호환성'을 기대할 수 있습니다. 해당 버스의 각 구성 요소는 개념적으로 '리소스'로 취급되므로 송신기와 수신기를 분리하기위한 추가 추상화가 도입되었습니다.
예 : 표준 메시지 지향 미들웨어에서 애플리케이션 A를 애플리케이션 B와 연결한다고 가정 해 보겠습니다. JMS를 살펴 보겠습니다. 애플리케이션 B를 작업중인 동료와 이야기하고 주제, 메시지 유형 및 필드에 동의 한 후 전송합니다 (의사 코드) : sendJms ( "TRADE.MSFT", {MapMessage trader = "pete"price = 101.4 vol = 100})
서비스 지향 아키텍처에서 동일한 작업을 수행하는 경우
처음에는 조금 아플 수도 있지만 EJB에 익숙해지는 것처럼 익숙해 질 수 있다고 생각합니다 ;-)
MOM 시스템은 'untyped'(동적 구조)이고 ESB는 'typed'(정적 구조)라고 말할 수 있습니다. 원시 메시징과 ESB의 장단점은 다른 유형이 지정되지 않은 / 유형이 지정된 선택과 유사합니다.
소규모 프로젝트의 경우 기능을 빠르게 해시하는 것이 좋지만 (예 : Groovy 코드) 큰 프로젝트의 경우 디버거 (예 : Java)를 사용하고, 일이 깨질 때 미리 경고를 받고, 사람들이 작업을 수행 하기 전에 표준을 마련하는 것이 좋습니다 . 계획.
따라서 프로젝트가 검증되지 않은 변경 사항을 확인하여 시스템을 손상시키는 사람이 너무 많으면 더 많은 구조 (MOM 대신 ESB)로 이동하십시오. 프로젝트가 제 시간에 충분한 작업을 수행하지 못해 어려움을 겪는 경우 더 간단하고 형식없는 솔루션을 선택하십시오. 둘 다인 경우-컨설턴트를 구하십시오 (농담입니다 ;-)
글쎄요, 그것은 당신이 누구에게 물어 보는가에 달려 있습니다. 많은 사람들은이 모듈들 사이의 메시징에서 코딩을 제거하기 위해 다양한 "비즈니스 로직"을 연결하는 "미들웨어"라고 말할 것입니다. 나는 그것이 충분히 일반적인 정의라고 생각하지만, 당신은 이미 Wikipedia와 그 밖의 것들을 통해 거기에 도착했다고 확신합니다.
위대한 ESB가 세상을 구할 수있는 사람들은 그것이 가장 일반적으로 제시되는 것처럼 모든 것을 할 수있는 허브라고 생각합니다. 대부분의 ESB 구현은 비즈니스 소프트웨어에서 볼 수있는 모든 반복 작업을 캡슐화하기 위해 노력합니다. 즉, 대부분의 ESB는 데이터 전송, 보안, 로깅, 프로토콜 번역, 이벤트 시스템, 웹 서비스를 통한 API 노출 등을 처리합니다.
가능한 한 분명하다고 생각합니다. 도움이되기를 바랍니다.
내 프레젠테이션 " Spoiled for Choice-How to choose the right ESB "를 살펴보십시오 .
ESB, Integration Suite 또는 통합 프레임 워크 (예 : Apache Camel)를 사용하는 경우를 설명합니다. 또한 오픈 소스와 독점 ESB의 차이점에 대해서도 논의합니다.
Wikipedia 에서 얻을 수있는 표준 정의를 넘어서 . 여러 플랫폼과 기술에 걸쳐 많은 레거시 시스템을 연결하기위한 훌륭한 도구라고 생각합니다. 또한 분산 워크 플로 및 상태 관리 시스템 (예 : 총계정 원장)을 구축하는 데 유용한 도구입니다.
그러나 유지 관리 및 확장이 다소 비싸고 복잡하며 불편하기 때문에 응용 프로그램 확장을위한 범용 도구로서 기술 선택이 좋지 않습니다.