엔터프라이즈 서비스 버스

Enterprise service bus
모든 고객 서비스는 ESB와 같은 방법으로 통신합니다.ESB는 메시지를 올바른 메시지유형으로 변환하여 올바른 개인 사용자 서비스로 전송합니다.

엔터프라이즈 서비스 버스(ESB)는 서비스 지향 아키텍처(SOA)에서 상호 상호작용하는 소프트웨어 애플리케이션 간의 통신 시스템을 구현한다.분산 컴퓨팅을 위한 소프트웨어 아키텍처를 나타내며, 응용 프로그램이 서버 또는 클라이언트처럼 동작할 수 있는 보다 일반적인 클라이언트-서버 모델의 특별한 변형입니다.ESB는 애플리케이션 간의 높은 수준의 프로토콜 통신과 관련하여 민첩성과 유연성을 향상시킵니다.주요 용도는 이기종 복잡한 서비스 환경의 엔터프라이즈 애플리케이션 통합(EAI)입니다.

아키텍처

엔터프라이즈 서비스 버스의 개념은 고성능 컴퓨터 운영 체제의 모듈식 동시 설계와 결합된 컴퓨터 하드웨어 아키텍처에서 볼 수 있는 버스 개념과 유사합니다.아키텍처 개발의 동기는 네트워크 내에서 독립적으로 배치, 실행, 이종 및 이종 이질적인 것으로 예상되는 느슨하게 결합된 소프트웨어 컴포넌트(서비스라고 불린다)의 구현을 기술하기 위한 표준, 구조화 및 범용 개념을 찾는 것이었습니다.ESB는 월드 와이드 웹의 본질적으로 채택된 네트워크 설계를 포함하여 서비스 지향 아키텍처의 일반적인 구현 패턴이기도 합니다.

엔터프라이즈서비스 버스의 개념 또는 [1]구현에 관한 글로벌 표준은 존재하지 않습니다.대부분의 메시지 지향 미들웨어 프로바이더는 엔터프라이즈 서비스 버스 개념을 서비스 지향 아키텍처의 사실상의 표준으로 채택하고 있습니다.ESB 구현에서는 이벤트 기반 및 표준 기반 메시지 지향 미들웨어를 메시지 큐와 결합하여 테크놀로지 [2]프레임워크로 사용합니다.그러나 일부 소프트웨어 제조업체는 버스 개념의 중요한 측면을 채택하지 않고 기존 미들웨어 및 통신 솔루션에 ESB로 라벨을 다시 붙입니다.

기능들

ESB는 현대 운영 체제의 설계 개념을 이종 및 독립 컴퓨터의 네트워크 내에서 실행되는 독립 서비스에 적용합니다.동시 운영체제와 마찬가지로 ESB는 고객요구의 채택, 번역 및 적절한 응답서비스로의 라우팅 외에 범용서비스를 제공합니다.

ESB의 주요 업무는 다음과 같습니다.

  • 서비스 간 메시지 라우팅
  • 서비스 간 메시지 교환 라우팅 모니터링 및 제어
  • 통신하는 서비스 컴포넌트 간의 경합 해결
  • 서비스 도입 및 버전 관리
  • 다중 서비스 사용 촉진
  • 이벤트 처리, 데이터 변환 및 매핑, 메시지 및 이벤트 큐잉 및 시퀀스 처리, 보안 또는 예외 처리, 프로토콜 변환 및 적절한 통신 서비스 품질 강화와 같은 범용 서비스를 제공합니다.

역사

"엔터프라이즈 서비스 버스"라는 용어가 처음 공개된 것은 Gartner Group 2002의 Roy W. Schulte와 David Chappell의 The Enterprise Service Bus에 기인합니다.많은 회사들이 이 문구를 만든 것에 대해 공로를 인정하지만, 슐트는 인터뷰에서 이 문구를 처음 들었을 때 캔들이라는 이름의 회사로부터 "ESB의 가장 직접적인 조상은 1998년의 [3]캔들 로마 제품이었다"라고 말했고, 그의 최고 설계자이자 특허 출원 소유자는 게리 어벤드였다.로마는 1998년에 처음 판매되어 최초의 상용 ESB가 되었습니다만, 2002년의 소닉의 제품도 초기 [4]ESB의 하나였습니다.

  • 서비스 - 메시지 교환을 통해 다른 서비스와 통신하는 비반복적이고 자율적으로 실행되는 프로그램을 나타냅니다.
  • 버스 - 컴퓨터 하드웨어 버스에 비유하여 사용됩니다.
  • 엔터프라이즈 - 이 개념은 원래 기업 내 엔터프라이즈 애플리케이션 통합의 복잡성을 줄이기 위해 고안되었습니다.현대 인터넷 통신이 더 이상 기업체에 국한되지 않기 때문에 이 제한은 폐지되었습니다.

소프트웨어로서의 ESB

ESB는 비즈니스 애플리케이션 간에 작동하는 소프트웨어로 구현되어 있으며, 이러한 애플리케이션 간의 통신을 가능하게 합니다.이상적으로는 ESB가 버스상의 애플리케이션과의 모든 직접접촉을 대체할 수 있어야 하며, 따라서 모든 통신이 ESB를 통해 이루어집니다.이 목적을 달성하기 위해 ESB는 컴포넌트 어플리케이션에 의해 제공되는 기능을 의미 있는 방법으로 캡슐화해야 합니다.이 문제는 일반적으로 엔터프라이즈메시지 모델을 사용하여 발생합니다.메시지 모델에서는 ESB가 송수신하는 표준 메시지세트를 정의합니다.ESB는 메시지를 수신하면 메시지를 적절한 응용 프로그램으로 라우팅합니다.대부분의 경우 해당 응용 프로그램은 동일한 메시지모델 없이 진화했기 때문에 ESB는 메시지를 응용 프로그램이 해석할 수 있는 형식으로 변환해야 합니다.소프트웨어 어댑터는 물리적 [5]어댑터와 유사하게 이러한 변환을 수행하는 작업을 수행합니다.

ESB는 엔터프라이즈메시지 모델을 정확하게 구축하고 애플리케이션에서 제공하는 기능을 적절하게 설계하는 데 의존합니다.메시지 모델이 응용 프로그램 기능을 완전히 캡슐화하지 않으면 이 기능을 필요로 하는 다른 응용 프로그램은 버스를 바이패스하여 일치하지 않는 응용 프로그램을 직접 호출해야 할 수 있습니다.이렇게 하면 ESB 모델의 원칙에 위배되며 이 아키텍처를 사용하는 많은 이점이 무효화됩니다.

ESB의 장점은 플랫폼에 구애받지 않는 특성과 어떠한 조건에서도 어떤 것과도 통합할 수 있다는 데 있습니다.애플리케이션 라이프 사이클 관리 벤더는 SOA를 채택하면서 자사의 통합 제품에 모든 ESB 기능을 진정으로 적용하는 것이 중요합니다.따라서 EAI 벤더의 과제와 기회는 저렴한 비용으로 쉽게 구성할 수 있고 직관적이며 사용하기 쉽고 고객이 선택하는 모든 툴에 개방적인 통합 솔루션을 제공하는 것입니다.

ESB 일반 부품 하이브

특성.

카테고리 기능들
호출 동기 및 비동기 전송 프로토콜, 서비스 매핑(예: 및 바인딩) 지원
라우팅 어드레스 어빌리티, 스태틱라우팅 또는 스태틱라우팅, 콘텐츠베이스 라우팅, 규칙베이스 라우팅, 정책베이스 라우팅
중개 어댑터, 프로토콜 변환, 서비스 매핑
메시지 메시지 처리, 메시지 변환 및 메시지 확장
프로세스 안무★ 복잡한 비즈니스 프로세스의 구현
서비스 오케스트레이션² 하나의 집약 서비스로 공개되는 여러 구현 서비스의 조정
복잡한 이벤트 처리 이벤트 확인, 상관, 패턴 검색
기타 서비스 품질 보안(암호화 및 서명), 신뢰성 높은 전달, 트랜잭션 관리
관리 모니터링, 감사, 로깅, 미터링, 관리 콘솔, BAM(BAM은 ESB가 특정 임계값에 반응하지 않는 관리 기능이 아님)이는 최종 사용자에게 표면화된 비즈니스 서비스 기능입니다.)
불가지론 운영 체제 및 프로그래밍 언어에 대한 일반적인 불가지론. 예를 들어 Java와 프로그래밍 간의 상호 운용성을 활성화해야 합니다.NET 어플리케이션
프로토콜 변환 주제 통신 프로토콜 서비스 표준에 대한 포괄적인 지원
메시지 교환 패턴 다양한 MEP(Message Exchange Patterns) 지원(예를 들어 동기 요구/응답, 비동기 요구/응답, 송신/포기, 퍼블리시/서브스크라이브)
어댑터 레거시 시스템과의 통합을 지원하기 위한 어댑터(JCA 등의 표준에 근거할 수 있음)
보안. ESB 사용을 허가, 인증 및 감사하기 위한 표준화된 보안 모델
변혁 송신 어플리케이션과 수신 어플리케이션 포맷 간의 변환 서비스(종종 XSLT 또는 XQuery 경유)를 포함한 데이터 형식 및 값의 변환 촉진
확인 메시지 송수신용 스키마에 대한 검증
거버넌스 비즈니스 규칙을 균일하게 적용하는 능력
농축 다른 원본에서 메시지 풍부화
분할 및 병합 여러 메시지의 분할과 결합 및 예외 처리
추상화 여러 층에 걸친 통일된 추상화 제공
라우팅 및 변환 (중앙 규칙 엔진이 필요 없는) 비집중형 정책에 따라 메시지를 조건부로 라우팅 또는 변환합니다.
상품 서비스 컨텍스트에 따라 공유 서비스로 일반적으로 사용되는 기능 프로비저닝

③ 프로세스 안무를 ESB 기능으로 간주하지 않는 사람도 있다. 예를 들어 M을 참조하십시오.리처드.[6]

² 프로세스 안무는 여러 비즈니스 서비스(일반적으로 BPEL 사용)를 조정해야 하는 복잡한 비즈니스 프로세스의 구현을 지원하는 반면, 서비스 조정은 개별 요청을 처리하기 위해 여러 구현 서비스(가장 적절하게 제공되는 서비스)를 조정할 수 있습니다.

이러한 솔루션은 연결, 라우팅 및 변환과 같은 낮은 수준의 ESB 기능에 중점을 두고 있으며 조정을 [7]구현하려면 코딩 또는 스크립팅이 필요합니다.예를 들어, 문제를 해결하려고 하는 등 프로젝트 또는 전술적 수준에서 운영되는 개발자들은 종종 경량 서비스 버스 기술에 끌리지만, 이러한 이니셔티브와 여러 [8]프로젝트에 걸쳐 인프라를 최적화하는 것을 목표로 하는 엔터프라이즈 아키텍처 사이에는 종종 긴장이 지속되고 있습니다.

메시지 브로커(ESB 소프트웨어)가 어떤 형식에서 다른 형식으로 메시지를 번역하는 경우, 모든 변환과 마찬가지로 메시지의 의미론 문제가 발생합니다.예를 들어 레코드는 JSON에서 XML로 변환할 수 있지만, 같은 필드 세트를 응용 프로그램에 따라 다르게 해석할 수 있습니다.특히 ESB에 접속되어 있는 응용 프로그램에 대한 폭넓은 경험이 있는 개발자에게만 알려진 다양한 코너 케이스의 경우입니다.이미 알려진 코너 케이스의 경우 ESB에 접속된 모든 애플리케이션은 ESB에 접속된 다른 모든 애플리케이션에 대해 테스트해야 하기 때문에 모든 코너 케이스를 커버하는 테스트의 수는 ESB에 접속된 모든 애플리케이션에 대해 기하급수적으로 증가합니다.

주요 장점

  • 포인트 솔루션에서 엔터프라이즈 도입(분산 버스)으로 확장 가능
  • 통합 코딩이 아닌 더 많은 구성
  • 중앙 규칙 엔진, 중앙 브로커 없음
  • 간단한 플러그인 및 플러그아웃 및 느슨한 결합 시스템

주요 단점

  • 통신 속도 저하(특히 이미 호환되는 서비스의 경우)
  • 단일 장애점으로 인해 기업 내 모든 통신이 중단될 수 있습니다.
  • 구성 및 유지보수의 복잡성이 높음

상품들

다음 항목도 참조하십시오.비즈니스 통합 소프트웨어 비교

주목할 만한 제품은 다음과 같습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Lapeira, Raul. "ESB is an architectural style, a software product, or a group of software products?". Artifact Consulting. Archived from the original on 2014-08-08. Retrieved 2010-04-16. The first thing a ESB architect should have in mind is that as of 2010 there is no global standard for ESB.
  2. ^ 카레, 에드워드2004. 메시지 지향 미들웨어.[permanent dead link]미들웨어 for Communications, ed.Qusay H. Mahmoud, 1-28Chickhester, England: John Wiley and Sons. doi: 10.1002/0470862084.ch1.ISBN 978-0-470-86206-3
  3. ^ McKendrick, Joe. "The great ESB squabble of 2005". ZDNet. Retrieved 2020-12-31.
  4. ^ "Difference between a Message Broker and an ESB". Retrieved 2017-07-19.
  5. ^ "Enterprise Service Bus [Book]".
  6. ^ Richards, Mark. "The Role of the Enterprise Service Bus (presentation)". Retrieved 2009-06-04. I do not consider process choreography part of an ESB, if we consider an ESB as a high-speed messaging middleware. However, I do consider process choreography part of the ESB *platform*. Fortunately most ESB vendors separate out these major components into different products, but package them under a consolidated ESB offering. So, in the strictest sense of the word, no, I would not consider it as part of an ESB. It is a related capability.
  7. ^ Feraga, Matthias (6 Jun 2011). "How to: choosing between lightweight and traditional ESBs". Octo. Retrieved 23 April 2014.
  8. ^ Fulton, Larry (12 Sep 2007). "Learn How to Embrace Lightweight ESBs". Fo2014.

추가 정보

외부 링크