진정한 약결합, EDA
SOA 정말 느슨한 연결(약결합: Loosely Coupled)인가?
SOA가 특별히 어떤 기술적인 표준과 강한 결합을 강요하지는 않더라도 어찌되었건간에 SOA는 웹서비스와 상당한 관련을 맺고 있는게 사실이다. 사람들이 그렇게 믿고 있고 웹서비스가 SOA를 실현시켜줄 견인차처럼 생각하고 있다면 그걸 틀리다고 말할 수는 없는 법. 웹서비스는 기본적으로 Request and Reply 방식을 선호한다. 부분적으로 비동기적인 메시징도 지원하거나 앞으로 지원하려고 하지만 SOA가 가장 자신있어 하는 기술적인 메시징 방식은 아직까지는 동기적인 처리 방식이며 상호운영성 부분에 있어서도 아직은 비동기적인 부분은 이뤄내야할 부분이 너무나 산적해있다.
그렇다, SOA의 기술적인 구현 부분은 결국 동기적인 방식이 주를 이룬다. 하지만 제 아무리 약결합을 극대화한다고 해도 Request and Reply 방식에서는 강결합이 해소되기 어려운 부분이 존재한다. Consumer는 물리적인 Provider의 위치와 그것을 호출하는 프로토콜을 몰라도 된다. 이것만으로는 완전한 약결합이라 할 수는 없다. Consumer는 어쨌든 어떤 Provider를 이미 예상하고 그 인터페이스도 알고 있어야하기에 Consumer의 메시지는 어느 정도 물리적인 Provider와 연결되어 있다고 볼 수있다.
반면에 EDA의 이벤트는 Provider와 Consumer가 완전히 분리되어 있다. Provider는 Provider가 전달하는 이벤트가 어떤 용도로 쓸일지 전혀 관심이 없고 Consumer역시 어떤 Provider에서 그 이벤트가 왔는지에 관심이 없다. 이벤트 자체에는 어떤 목적성이 있을 수가 없는 것이다.
그래서 사실 SOA가 목표로 하는 최상의 약결합은 오히려 EDA와의 동거를 통해 이루어질 가능성이 있다.
EDA와 SOA의 결합
물론 요새 오라클이 SOA세계에 새로운 강자로 떠오르기 위해 기존 SOA판에서 놀기보다 새판짜려는 마음으로 SOA 2.0이라고 하면서 SOA와 EDA의 결합 모델을 통해 SOA의 더더욱 진화된 유연성을 강조하고는 있지만, EDA는 SOA랑은 원래는 그다지 상관이 없는 독자적인 아키텍처라고 볼 수 있다. 어찌되었건 그 이름이 SOA 2.0이건, SOA와 EDA이건 EDA는 SOA의 탄탄한 기술구조와 거버넌스 및 방법론등을 필요로 하고 SOA는 EDA의 유연함을 필요로 한다. 둘은 서로가 원하고 있다. 아래 그림은 이러한 SOA와 EDA간의 결합 구조이다.
SOA는 프로세스 기반의 여러 비즈니스 인프라를 묶어내는 데에 사용되고 이러한 SOA기반의 비즈니스 서비스 덩어리들 간에 유연한 결합을 위해 EDA가 쓰일 수 있을 것이다.
만약 SOA 부분의 프로세스들을 감싸고 있는 덩어리를 ESB라고 가정한다면 ESB와 ESB들간의 직접적인 연결에 의한 상호 통신도 물론 존재할테지만 이 역시 강결합의 요소가 담겨있을 수 있다.
어찌되었건간에 EDA는 이 SOA로 이루어진 서비스 덩어리들의 이벤트 중계뿐만 아니라 기업내에 존재하는 다양한 Legacy와의 극대화된 약결합, 유연성을 제공할 것이 분명하다.
SOA가 잘할 수 있는 경우
비즈니스 트랜잭션 내에 여러 복잡하고 다양한 계층의 프로세스와 서비스와 컴포넌트의 조합이 필요한 경우Request and Reply 방식의 트랜잭션무결성이나 트랜잭션등이 중요한 프로세스EDA가 잘할 수 있는 경우
너무나 이질적이고 대량의 이벤트 소스로부터의 유연한 처리가 필요할 경우전혀 다른 비즈니스 트랜잭션들간의 통신.워크플로우 스타일의 프로세스
댓글
정인철 · 2008/03/17 20:13
EDA라는 용어는 전부터 들었었지만, 최진호님덕에 감을 더 잡을 수 있었습니다. 감사합니다. 하여튼 EDA라는 사상이 상당이 마음에 드는군요. 그런데, 막상 테스트용이 아닌 실제 현업의 엄청난 이벤트들을 처리하려면 상당한 자원이 필요로 하겠네요. 또한 속도도 무시 못할 것 같습니다. 엄청난 양의 이벤트들을 항상 필터링을 하고 있어야 한다면 정말 장난이 아니겠네요. 제 기억으로 EDA 방식의 서버들이 이미 상용으로 나온것으로 알고 있는데, 그런 EDA 서버들은 이런것들을 잘 처리하고 있다는 이야기가 되는거 같네요.
아무튼 재미있는 포스팅 잘 봤습니다.
Yozz · 2008/03/17 20:56
CEP가 나온지는 1990년대 초중반이니,.. 정말 오래되었네요.. 사실 말씀하신 성능문제 장난아니죠. 그래서 다양한 방법들이 나오는데, 오라클이나 IBM의 경우 Grid 컴퓨팅 기술을 그동안 발전시켜놨잖슴까? 그걸 어떻게든 잘 활용하려고 하는 듯 합니다. 뭐 다른 EDA서버들도 제 나름대로 여러가지 방안을 내놓고 있는듯, 캐쉬기법이라던가…
장생 · 2008/06/09 17:55
음..흥미롭습니다. 그렇다면 EDA에서는 메세지 전달 방식이 특정 이벤트에 대한 notification 을 통해 각 서비스에서 처리하는 방식인가 보군요..그렇다면 내부적으로 특정 이벤트에 대해 notify를 받아야 하는 서비스들이 여러개 있을때, 어떤식으로 처리해 줄까요..publish/subscribe 형태가 되려나..아무튼~ 머리아퍼요~ ^^;
Yozz · 2008/06/09 20:28
예. 그렇지요. 맞습니다. Pub/Sub입니다. 아키텍처는 Pub/Sub을 닮았습니다. 전사적 차원의 Pub/Sub Framework라고도 볼 수 있겠네요. 이것에 전사적 차원의 BizRuleMaintenanceSystem(BRMS)를 포함한 듯한 모습입니다.