![닫기 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
시장 변화에 적응하기 위해 기업은 유연성과 반응성에 초점을 맞추곤 한다. 알맞은 아키텍처와 기술로 이러한 비즈니스 비전을 지원하는 것이 IT에 직면한 도전이었다. 초기 제안은 완전히 통일된 애플리케이션들을 호출 가능한 하위 루틴들로 나누는 것이었지만 진보된 원격 객체 호출과 메시징 프로세싱이 이를 변화시켰다.
보다 최근에는 기업 내에서 기존 자산들의 재사용을 늘리는 것과, 이종의 애플리케이션들을 조합하여 비즈니스 솔루션으로 조합하는 것의 중요성이 대두되었다. 이러한 이유로 SOA와 EDA를 채택하기에 이른 것이다. 이 두 개의 다른 디자인 패러다임은 IT 적응성과 효율성을 늘리는 애플리케이션 중립의 서비스들의 재사용을 극대화하는 것을 목표로 하고 있다. 하지만 대규모 통합 솔루션들을 구현 및 전개하는 것은 결코 쉬운 일이 아니다. 이것 때문에 ESB가 필요하다. 유연하고 믿을 수 있은 아키텍처(SOA와 EDA)의 구현을 단순화 할 수 있기 때문이다.
SOA는 모든 기능 또는 서비스들이 디스크립션 언어를 사용하여 정의되고, 인터페이스들은 네트워크를 통해서 발견되는 아키텍처 개념이다. 인터페이스는 하드웨어 플랫폼, 운영 체계, 프로그래밍 언어와 독립적으로 정의된다.
SOA의 가장 중요한 장점들 중 하나는 소프트웨어 개발 시 고립을 탈피할 수 있다는 점이다. 고립된 방식에서는 한 기업 내의 부서들간 어떤 일이 수행되었는지를 알지 못한다. 이러한 "사일로(silo)" 방식은 비효율적이고 같은 기능이 개발 및 전개 되어 많은 시간동안 관리되어야 하는 상황으로 이어진다. SOA는 기업 전체에 걸쳐 공유되는 서비스 포트폴리오에 기반해 있고 기존 자산들을 효율적으로 재사용 및 통합할 수 있는 방식을 제공한다.(그림 1)
그림 1: "사일로" 방식 대 SOA 방식
SOA는 전통적인 요청/응답 메커니즘에 기반해 있다.(그림 2) 서비스 소비자는 네트워크를 통해 서비스 공급자를 호출하고 공급자 측에서 연산이 완료될 때 까지 기다려야 한다.
그림 2: SOA의 요청/응답 메커니즘
표 1에는 SOA 솔루션의 기본적인 특성을 요약해 놓았다.
표 1: 기본적인 SOA 특성
| 특성 | 설명 |
|---|---|
| 약결합 인터랙션 | 서비스는 기술이나 위치와 독립적으로 호출된다 |
| 일대일 통신 | 특정한 하나의 서비스는 한 명의 소비자에 의해 단 한번 호출된다. 통신은 양방향이다. |
| 소비자 기반 트리거 | 제어의 흐름은 클라이언트(서비스 소비자)가 초기화 한다. |
| 동기식 | 응답은 동기식으로 소비자에게 돌아간다 |
2003년, Gartner(참고자료)는 이벤트에 기반한 디자인 패러다임을 나타내는 새로운 용어를 만들었다. 바로 이벤트 중심 아키텍처(Event-Driven Architecture; EDA)이다. EDA는 개별 소프트웨어 컴포넌트와 서비스들간 이벤트가 전송되는 애플리케이션과 시스템들을 디자인 및 구현하는 방식을 정의한다. EDA는 SOA의 대안이라기 보다는 SOA를 보완한다. 일반적으로 SOA가 요청/응답 교환에 더 잘 맞는 반면 EDA는 장기 실행하는 비동기식 프로세스 기능을 도입했다. 더욱이 EDA 노드는 이벤트를 제공하고 퍼블리시 된 서비스의 가용성에 의존하지 않는다. 실제로 다른 노드들과 떨어져 있다. EDA는 가끔 "이벤트 중심 SOA" 라고도 일컬어진다.
EDA는 두 개 이상의 애플리케이션 프로세스들 간 통신하는 메시징을 사용한다. 이러한 통신은 "이벤트"에 의해 시작된다. 이 트리거는 일반적으로 비즈니스 발생과 연관된다. 그러한 이벤트의 등록자는 공지를 받고 활성화 된다.(그림 3)
그림 3. 이벤트 중심 아키텍처에서의 퍼블리시/등록 메커니즘
표 2에는 EDA의 기본적인 특성을 요약했다.
표 2: 기본적인 EDA 특성
| 특성 | 설명 |
|---|---|
| 디커플(decouple) 인터랙션 | 이벤트 퍼블리셔는 이벤트 등록자의 존재를 알지 못한다 |
| 다대다 통신 | 퍼블리시/등록(Publish/Subscribe) 메시징에서는 한 개의 특정 이벤트가 많은 등록자에게 영향을 줄 수 있다. |
| 이벤트 기반 트리거 | 수혜자에 의해 결정된 이벤트의 흐름은 제공된 이벤트에 근거한다. |
| 비동기식 | 이벤트 메시징에 비동기식 연산을 지원한다. |
Enterprise Service Bus (ESB)는 이벤트 중심 방식과 서비스 지향 방식을 결합하여 비즈니스 단위들의 통합을 수월하게 하면서 이종의 플랫폼과 환경들을 잇는 가교 역할을 한다. ESB는 중간 레이어로서 작동하여 다른 애플리케이션 프로세스들 간 통신을 실행한다. Enterprise Service Bus에 전개된 서비스는 소비자 또는 이벤트에 의해 실행될 수 있다. 동기식과 비동기식을 지원하며, 하나 또는 많은 스테이크홀더들간 인터랙션을 가능케 한다.(일대일 또는 일대다 통신.) 따라서 ESB는 SOA와 EDA 패러다임이 가진 모든 특성을 갖고 있다.(표 1, 표 2 참조)
Enterprise Service Bus는 아키텍처 패턴이며 기업 내 다양한 제품들에 의해 구현될 수 있고 함께 조합되어 연합 버스로서 작동할 수 있다. 점점 더 많은 벤더들이 완벽한 제품을 공급하여 엔터프라이즈 통합의 필요들을 채우고 있다. 예를 들어, IBM WebSphere® Enterprise Service Bus (참고자료)는 통합 버스를 제공하여 애플리케이션들을 효율적으로 연결하면서 웹 서비스와 J2EE 같은 표준을 활용한다.
ESB 구현이 어떠해야 한다는 것을 정의한 공식적인 스팩은 없지만 적어도 트랜스포트, 이벤트, 중재 서비스를 제공하여 이종의 대규모 애플리케이션들의 통합을 구현할 수 있어야 한다고 인식되고 있다.
트랜스포트 서비스의 경우 비즈니스 프로세스들 간 메시지의 전달은 엔터프라이즈 버스를 통해서 서로 연결되어 있어야 한다. 전송에는 콘텐트 기반 라우팅이 포함된다. 메시지를 다른 목적지로 보낼 수 있다는 의미이다. 이러한 서비스들은 트랜잭션 방식이어야 하며 보안 및 감시된다.
이벤트 서비스는 이벤트 탐지, 트리거, 배포 기능을 제공한다. 이것은 이벤트 프로세싱의 개념과 관련되어 있다. 이것은 이벤트 중심 아키텍처(EDA)에서 서로 연관된 이벤트들을 분석 및 제어하는 기술이다. 이벤트 중심 패러다임은 새로운 것이 아니다. 하지만 산업계의 탄력을 받고 있으며 Complex Event Processing 같은 기술의 핵심 개념을 드러내고 있다.(참고자료)
중재 서비스는 두 개의 다른 목적이 있다. 우선, 중재는 필요한 프로토콜 매칭이 이종의 시스템들을 통합하도록 한다. 두 개의 다른 서비스들이 같은 전송 프로토콜을 사용할 필요가 없기 때문에 중재 서비스는 하나의 프로토콜에서 다른 프로토콜로 전송을 관리한다. 따라서 통신이 가능한 것이다. 프로토콜 변환은 비즈니스 트랜잭션에 참여하는 모든 서비스들에 투명하다.
그림 4: 프로토콜 중재 – 이 프로토콜은 ESB에 의해 변형된다.
둘째, 중재는 어떤 메시지의 콘텐트라도 변형할 수 있다. 이것은 비즈니스 통합의 핵심 서비스이다. 버스를 통해 이동하는 데이터는 어떤 프로세스라도 인식하고 있다. 더욱이 중재를 통해서 콘텐트 증가가 가능하다. 메시지에 추가 정보가 붙는다. 콘텐트 변형은 버스에 의해 관리된다. 참여하는 서비스에 투명하다.
그림 5: 콘텐트 중재 – 메시지 콘텐트는 ESB에 의해 변형 및 증가된다.
콘텐트 중재 이점을 잘 나타내주는 예를 들어보자. Yummy Inc.라는 가상의 기업이 있다. 이 회사는 온라인 케이터링 서비스를 제공한다. 고객들에게 제공할 메뉴를 계획하려면 공급자가 제공할 수 있는 재료의 가용성과 가격을 확인해야 한다. 정보를 받기 위해 그들이 보내는 전형적인 메시지 구조에는 제품명, 수량, 인도 날짜 등이 포함된다.
그림 6: 메시지 구조
물론 Yummy Inc.와 공급자는 정보를 표현하는 같은 방식이 없다. 예를 들어, 날짜는 두 시스템에서 조화되지 않는다. 더욱이 공급자는 Yummy Inc.만 상대하는 것이 아니기 때문에 전달 위치가 필요하다. ESB 중재 서비스는 메시지 전송에 대한 정보를 변형 및 증가시켜서 목표 서비스가 모든 필요한 정보를 얻을 수 있도록 한다.(그림 7)
그림 7: ESB 중재에서의 콘텐트 변형과 증가
이전에 정의된 핵심적인 기술 서비스를 활용하면서 ESB는 약결합 된 애플리케이션들을 통합할 수 있는 유연한 연결 인프라를 제공한다. SOA와 EDA 패러다임 모두를 지원한다.
그림 8: Enterprise Service Bus로 서비스들 연결하기
내부 서비스들을 활용하는 ESB 솔루션은 다양한 혜택을 제공한다. 서로 다른 애플리케이션들을 연결하는 일을 단순화 시키고 궁극적으로 비즈니스 기민성을 높인다.
-
표준 기반의 연결
이종의 시스템들간 통합 중추로서, ESB가 다양한 통합 기술을 제공하고 많은 표준 기술들을 활용하는데 필수적인 것이다. 메시징 통합은 일반적으로 Java™ Message Service (JMS) API를 지원하는 반면, 엔터프라이즈 정보 시스템과의 연결은 J2EE Connector Architecture (JCA)가 제공한다. 웹 서비스의 상호 운용성을 위해서 ESB는 JAX-RPC 프로그래밍 모델을 지원한다. 다른 ESB 컴포넌트들 간 통합은 Java Business Integration specification (JBI)에 의해 표준화 될 수 있다.(참고자료)
-
폭 넓은 통합
ESB는 기본적으로 폭이 넓다. 다양한 부서들, 비즈니스 단위들, 심지어 비즈니스 파트너들 사이에서 애플리케이션을 통합할 수 있기 때문이다. 더욱이 이것의 핵심적인 아키텍처 원리는 이종의 개발 환경들에서 구현된 애플리케이션들간 통신을 가능케 하는 것이다. 예를 들어, ESB 솔루션은 J2EE, C++, .Net 같은 프로그래밍 언어들간 가교 역할을 한다.
-
신뢰성 있는 통합
ESB 아키텍처 패턴은 시스템 보안, 확장성, 가용성을 향상시킨다. SOA와 EDA를 활용하기 때문에 Enterprise Service Bus는 동기식/비동기식 기능 모두를 제공한다. 전송 서비스는 신뢰성 있고 트랜잭션 무결성을 자랑한다. ESB의 모든 특성들은 강력함을 증대하고 리스크를 완화시킨다.
Enterprise Service Bus는 전송, 이벤트, 중재 서비스를 통해 비즈니스 통합을 실현하는 아키텍처 패턴이다. 서비스 지향 아키텍처(동기식 일대일 방식)와 이벤트 중심 아키텍처(비동기식 다대다 방식)에서 이종의 노드들 간 통신과 인터랙션들을 연결하고 중재한다. ESB는 오늘날 복잡한 통합 문제를 풀 수 있는 효과적인 방식이며 놀라운 유연성과 효과를 제공하는 기술적 솔루션이다.
교육
-
developerWorks technical articles, Service-Oriented Architecture(SOA) 입문
-
Complex Event Processing.
-
Event-Driven Architecture
-
specifications for the Java platform:
- Java Message Service (JSR-914)
- Java Connector Architecture (JSR-112)
- Java APIs for XML based RPC (JSR-101)
- Java Business Integration (JSR-208)
제품 및 기술 얻기
토론
태그
태그를 더 많이 보거나 적게 보기 위해 슬라이더 막대를 사용하십시오.
인기 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 최고 인기 태그를 보여줍니다.
내 태그는 특정 컨텐츠 존(예를 들어, 자바, 리눅스, WebSphere)의 귀하의 태그를 보여줍니다.
인기 기사 태그 |
내 기사 태그태그 목록으로 건너뛰기
인기 기사 태그 |
내 기사 태그