1. EAI(Enterprise Application Integration)의 개요
| 개념 | 필요성 |
|---|---|
| 서로 다른 다양한 정보 시스템간 연결을 위해 Mediation, Federation 기반 데이터, 오브젝트, 프로세스를 연계하고 통합하는 정보시스템 아키텍처/프레임워크 | – IT시스템 거대화에 따른 데이터 관리 필요 – 개별 APP 간 직접 통신에 한계 발생 – 통합이 필요한 이기종 시스템 간 연동 필요 – 인터페이스 기반 효과적 데이터 통신 필요 |
- 기업 IT시스템의 거대화, 세분화에 따라 복잡하고 다양해진 서비스간 연동은 중요한 극복 이슈이며, 이를 해결하기 위해 EAI, ESB, API Gateway 등 아키텍처 기반 데이터, 오브젝트, 프로세스 통합 필요
2. EAI의 구성요소 및 주요 기능
(1) EAI의 구성요소
| 구성요소 | 역할 | 상세 설명 |
|---|---|---|
| Adapter | 데이터 추출 지원 | – 파일 어댑터, DB 어댑터 등 |
| Message Hub | 목표 시스템 데이터 분기 | – 목표시스템에 적합한 포맷 데이터 작성 |
| Workflow | 프로세스 통제 | – 자동화 및 통합 |
| Middleware | 시스템 간 데이터 전송 | – 네트워크 프로토콜, 하드웨어 상태와 무관 |
(2) EAI의 주요 기능
| 구분 | 주요 기능 | 상세 설명 |
|---|---|---|
| 데이터 측면 | 데이터 브로커 | – 중개 데이터를 자동변환, 데이터 소스에서 목표 시스템까지 연결 |
| 데이터 접근 | – 데이터 통합 기반 데이터 전송, 타입 변환, 데이터 정제 및 추출 | |
| APP 측면 | APP 접근 | – PKG APP 및 이 기종 시스템 간 접속, SW와 플랫폼 사이에 데이터 중개, APP 연동 인터페이스 제공 |
| 플랫폼 기능 | – APP 서버 또는 미들웨어 영역으로 안정적 실행 및 기능 동작 지원 | |
| 비즈니스 측면 | 비즈니스 프로세스 관리 | – 업무 시스템 및 app 상호 간 데이터의 교환과 업무 흐름에 대해 시점 및 이벤트에 따라 업무 진행 프로세스를 정의/운용 |
2. EAI의 구현 방식 및 구축 유형
(1) EAI의 구현 방식
| 구분 | 구현 방식 | 동작 방식 |
|---|---|---|
| 그룹 내 통신 | Mediation | – EAI 엔진이 중개장(Broker)로 동작 – 데이터 생성/갱신 등 이벤트 발생 식별 – Publish/Subscribe Model |
| 그룹 간 통신 | Federation | – EAI 엔진이 상대편 그룹으로부터 데이터 요청 수령/전달 – Request/Reply Model |
(2) EAI의 구축 유형
| 구분 | 구축 유형 | 설명 |
|---|---|---|
| 범위 통합 측면 | Data Level | – APP 간 Data 내용 전달 |
| Object Level | – APP 간 트랜잭션 및 연관 데이터 통합 | |
| Process Level | – 다단계 프로세스의 중앙집중식 프로세스 제어 관리 | |
| 모델 통합 측면 | Peer-to-Peer | – 미들웨어 없이 APP 간 1:1 연계 – 단순한 APP 통합 |
| Hub & Spoke | – APP 간 허브 형식 미들웨어로 중개 – 미들웨어를 통합 통합 | |
| Messaging Bus | – APP 간 버스 형식 미들웨어로 중개 – 미들웨어를 통합 통합 | |
| Hybrid | – 그룹 내 Hub & Spoke 방식 통합 – 그룹 간 Messaging Bus 방식 통합 |
- 기업 서비스 연동을 위해 EAI, ESB(Enterprise Service Bus), API Gateway 방식의 아키텍처들이 있으며 각 아키텍처의 단점을 보완하여 솔루션 변화 중
3. EAI와 ESB, API Gateway 비교
| 비교 항목 | EAI | ESB | API Gateway |
|---|---|---|---|
| 개념도 | |||
| 전송 방식 | Adapter 기반 1:1, 허브 | SOAP(XML/HTTP) | REST(HTTP/JSON) |
| 기술 요소 | Adapter, EAI Platform, Message Queue | SOAP, Interaction Link, ESB 패턴 | API Token/Routing, Mediation |
| 장점 | 이기종 연동, 유지관리 효율성 | 통신 표준화, 분산구조, 재사용성 | 메시지 경량화, 서비스 단순화, 관리 효율성 |
| 단점 | 비표준화, APP 통합에 한계 | 복잡한 스펙, XML 적용 한계 | API G/W 부하, SPoF 리스크 |
- MSA(Micro Service Architecture) 등의 API Gateway의 SPoF 단점을 보완하기 위해 외부와 연동 시 API Gateway를 적용하고 내부 연동에는 Service Mesh 방식의 아키텍처를 사용하는 Service Mesh 아키텍처 고려
[참고]
- 조대협님의 블로그, “EAI, ESB, API 게이트 웨이,서비스 매쉬“