SOA,EAI,미들웨어에 대해...

SOA와 EAI에 대해서 자료를 찾아 봤는데요, 관련 블로그에 도움이 될 만한 자료가 있어 정리해봤습니다.

 

우선 SOA가 무엇인지 알아보자면요,

 

SOA는 아키텍처와 인터페이스의 다른점을 신경 쓰지않고 모든 어플리케이션을 네트워크를 경유하여 서비스로서 자유롭게 조합하여 이용할 수 있도록 하기위한 시스템 설계상의 방법입니다.

 

여기서 서비스라는 것은 비지니스 로직을 컴포넌트화 한 것으로, 예를 들면 '2분기연속으로 이익을 내고 있는 기업의 리스트를 조회한다'라는 비교적 포괄적인 형태에서도 API를 호출하는 것처럼 서비스를 호출하는 측이 하위레벨(네트워크 설정과 SQL 등)를 의식할 필요가 없이 필요로 하는 서비스를 호출하기만 하면 됩니다.

 

웹 서비스는 여기서 말하는 서비스의 내장방법 중에 하나입니다.

 

그럼 다음으로 EAI는 무엇인지 알아보겠습니다.

 

소위 EAI 툴이라 불리 우는 제품을 판매하고 있는 각 벤더는 최근에는 EAI 보다는 BPM이라는 단어를 사용하기 시작하고 있고 웹 어플리케이션 서버도 어댑터가 사용되면서 EAI 툴이라 불리게 되었습니다.

 

더욱 진보한 SOA(Service Oriented Architecture)에 기반으로 하는 ESB (Enterprise Service Bus) 제품 이라는 새로운 흐름도 나타나기 시작했습니다. 그 외에 데이터 웨어 하우스 구축에서 사용되는 ETL (Extract, Transform, Loading : IT환경에서 상이한 종류의 데이터를 추출, 변환, 가공하는 툴)도 어플리케이션의 데이터 연계라는 의미에서는 EAI의 범위에 포함됩니다.

 

EAI의 기본은 1대1 어플리케이션 연계에서 시작됩니다.

다시 말해서 EAI는 부분적으로 도입 되어지는 업무 어플리케이션과 기존 시스템을 통합해서 하나의 시스템으로 활용하기 위한 조합을 목적으로 하고 있습니다.

여기에서 우선 1대1 어플리케이션 연계를 설명해보도록 하죠.

 

1대1 어플리케이션 연계에는 MOM(Message Oriented Middleware)이 사용됩니다.

MOM 이라는 것은 어플리케이션간의 계속적인 쌍방향 데이터 교환을 가능하게 하는 미들웨어 이며 EAI의 가장 기본이 되는 소프트웨어입니다.

프로그래머는 MOM을 도입함으로써 어플리케이션의 통신부분을 개발하지 않고도 개발을 마칠 수 있습니다. 어플리케이션의 연계부분의 개발시간과 개발비용을 크게 절감 할 수 있다는 얘기가 됩니다.

MOM에는 메시지 큐잉 모델이 사용됩니다.

 

여기서는 아이비엠의 MQ를 예를 들어 알아보겠습니다.

이 시스템간의 통신방식의 최대 특징은 어플리케이션 간에 직접 세션을 맺지않고 큐(Queue)라고 불리는 스토리지 (디스크상이나 메모리 상에 생성이 가능)를 경유해서 간접적으로 메시지(데이터)를 주고 받을 수 있습니다.

결국 메시지 큐잉 모델에서는 메시지 발신 어플리케이션에서 발송 되어진 메시지를 일단 큐에 저장을 하고 그 후에 수신 어플리케이션이 큐로부터 메시지를 받는 방식으로 되어있습니다.

 

이 방법이라면 발신측은 수신측 상태를 신경 쓸 필요가 없어집니다. 실제 어플리케이션 간의 통신에서는  운영체재의 장해, 네트워크의 장해 등으로 수신측 어플리케이션이 이용할 수 없는 경우가 발생하지만 그 때에는 이용이 가능할 때까지 큐에 메시지를 일시적 (장기간 보존가능)으로 보관해 두기만 해도 됩니다.

 

구체적으로는 MQ는 tcp/ip, SNA 등의 복수의 프로토콜에 대응하고 있기 때문에 프로그래머는 어떤 통신 프로토콜을 통해서 통신을 하고 있는가에 대해 의식 할 필요가 없습니다.

MQI(Message Queue Interface)라는 복수의 플랫폼 간의 통일된 13개의 인터페이스 (MQOPEN:큐의 오픈, MQPUT : 큐로 메시지 전송) 구사만으로 충분합니다

1. 미들웨어

    - 말 그대로, "중간 단계에 위치하여 서비스를 해 주는 소프트웨어적으로 운영되는 프로세스"를 말합니다.

    - 이러한 소프트웨어가 출현한 배경으로는 우선 기존 Client/Server의 2 Tier 환경에 있어서 업무 처리 로직이 Client에 위치하게 되어 Fat Client를 초래함으로써 버젼 관리가 어렵고, Client 프로그램이 많아지게 되면 Server에 추가되는 부하도 동일하게 증가되어 대용량 환경하에서의 컴퓨팅에 적당하지 않게 되었습니다.

    - 이에, 비즈니스 로직을 Client에서 떼어내고, Client의 수가 증가하더라도 Server에 미치는 영향을 최소화하고자 하는 측면에서 중간에 Middleware라는 소프트웨어를 활용하게 되었습니다.

    - 현재 사용하는 EAI, WAS(Web Application Server)도 Web 환경하에서 운영되는 대표적인 미들웨어라고 볼 수 있습니다.

 

2. EAI(Enterprise Application Integration)

    - 기업이 업무를 처리하는 데 있어서는 인사 시스템, 회계 시스템, 마케팅 시스템, 재무 시스템 등 많은 시스템들이 존재하게 되는 데,

    - 시간이 지남에 따라서 이러한 시스템들간에 데이터 연동이 필요로 하게 되었습니다.

    - 이러한 연동을 위해서 각 시스템들간의 1:1 직접적인 연동 프로그램을 개발하여 문제를 해결하였습니다만,

    - 이 같은 해결 방식은 연동 대상 시스템이 많을 경우, 개발할 연동 프로그램의 수가 많아질 뿐 아니라, 연동에 대한 내용이 변경이 될 때에 관련되는 모든 프로그램을 고쳐야 해서 관리 측면에서 많은 문제를 야기 했습니다.

    - 이러한 문제를 해결하기 위해서, 연동 되는 시스템들의 중간에 일종의 Middleware로서 EAI를 두고 EAI에서 각 시스템들간의 연동과 다른 시스템으로의 데이터 송수신을 책임지게 하는 아키텍쳐를 고안하게 되었습니다.

    - 이렇게 되면, 연동해야 시스템들은 EAI에게만 데이터를 전송하면 EAI가 다른 시스템으로 필요한 데이터를 필요한 포맷에 맞게 전달해 주게 되므로 인해 기존의 1:1적인 연동으로 인해 일어나는 관리상의 문제들을 제거할 수 있습니다.

 

3. SOA(Service Oriented Architecture)

    - IT 자원을 서비스화하여 재사용함으로써 비즈니스의 요구에 빨리 대응할 수 있게하는 IT Architecture의 한 형태를 말합니다.

    - IT 자원을 재사용한다는 측면에서 컴포넌트를 사용하는 개발방법과 유사하다고 할 수 있지만, 요즘 얘기되는 SOA는 플랫폼에 관계 없는 표준 기반의 기술을 사용한다는 측면에서 조금 차이가 있다고 볼 수 있습니다.

    - SOA가 되기 위해서는 사용할 수 있는 서비스를 설명(Description)하고, 이러한 서비스를 찾을 수(Search) 있는 인프라가 제공이 되어야 하는 데, 그러한 인프라를 요즘 얘기하는 ESB(Enterprise Service Bus)라고 합니다.

    - 이 ESB는 일종의 Middleware로서 기존 시스템의 연동 기능을 제공하는 EAI와 유사한 기능을 제공하고 있습니다만,

    - EAI가 제공하는 업체가 사용하는 벤더 종속적인 기술을 사용하는 반면, ESB는 표준 기반(예를들면 웹서비스)의 기술을 사용한다는 측면에서 EAI와 가장 큰 차이가 있다고 볼 수 있습니다.

 

결론은, EAI나 (SOA의) ESB는 미들웨어라고 볼 수 있고 동일한 목적, 즉 시스템의 연동이라는 목적을 수행하는 솔루션이라고 볼 수 있지만, 그 방법에 있어서는 표준 기술을 사용하느냐 하지 않느냐의 차이가 있습니다.

 

표준 기술을 사용하는 것의 잇점은 서로 다른 벤더 제품의 ESB를 사용하고 있는 기업이라도 ESB의 연동을 통해 다른 기업의 IT 자원을 재사용할 수 있어 기업간 프로세스 통합에 큰 도움이 된다는 것입니다