ESB 란 무엇이며 어떤 장점이 있습니까?

ESB 란 무엇이며 어떤 장점이 있습니까?

---

이전 직장에서 "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})

서비스 지향 아키텍처에서 동일한 작업을 수행하는 경우

1. 추가 소프트웨어 설치
2. 많은 새로운 개념을 배우십시오
3. ESB의 관리 GUI에서 새 Java 구성 요소를 정의하십시오.
4. ESB에서 제어하는 ​​일부 인터페이스 구현
5. sendJms (getDestination (), {MapMessage trader = "pete"price = 101.4 vol = 100})-대상이 ESB에서 주입됩니다.

처음에는 조금 아플 수도 있지만 EJB에 익숙해지는 것처럼 익숙해 질 수 있다고 생각합니다 ;-)

You could say a MOM system is 'untyped' (dynamic structure) while an ESB is 'typed' (static structure). The trade-offs of raw Messaging vs. ESB are similar to other untyped/typed choices:

• REST vs. SOAP
• unvalidated XML vs. XML validated with an XSD
• Groovy vs. Java
• interpreted language vs. compiled language

For smaller projects it's nice to hash out functionality quickly (e.g. Groovy code) but for larger projects it's good to have a debugger (e.g. Java), to be warned in advance when things break and to have a standard for people before they commit to the project.

So if your project suffers from too many people breaking the system by checking in unvalidated changes - move towards more structure (ESB instead of MOM). If your projects suffers from not getting enough things done in time - choose the simpler, untyped solution. If it's both - get a consultant (just kidding ;-)

---

Well, that depends on who you ask... Many would say it's a piece of "Middleware" that connects various pieces of "business logic" together to take the coding out of messaging between these modules. I think that's a general enough definition, but I'm sure you've already gotten there via Wikipedia and whatnot.

Those who would have the great ESB save the world see it as it's most commonly presented, a hub for doing everything. Most ESB implementations effort to encapsulate all repetitive tasks we see in business software. That means most ESBs take care of data transfer, security, logging, protocol translation, event systems, api exposure via web services, etc.

I think that's as clear as I can be... Hope that helps.

---

Take a look at my presentation "Spoilt for Choice - How to choose the right ESB".

I explain when to use an ESB, Integration Suite, or just an Integration Framework (such as Apache Camel). I also discuss the differences between open source and proprietary ESBs.

---

Beyond a the standard definition you can get from Wikipedia. I find it to be a great tool for connecting a bunch of legacy systems across multiple platforms and technologies. It's also a good tools for building distributed workflows and state management systems( such as general ledger).

However, it's rather expensive, complex and inconvenient to maintain and extend which makes it a poor technology choice as a general purpose tool for scaling you applications.

참고URL : https://stackoverflow.com/questions/597397/what-is-an-esb-and-what-is-it-good-for