간혹 ESB나 SOA에 대하여 고객과 회의를 하다보면 참으로 다양한 관점에서 그것들을 바라보고 있음을 발견한다. 그들의 위치와 환경에 따라 다르게 인식하는 이해를 어떻게 우리가 바라보는 곳과 일치시켜야할 지 막막할 때가 있다. 나 역시 ESB나 SOA에 대하여 완전하게 이해하고 있는 것이 아니다 보니 더더욱 힘들다.
오늘 만난 고객은 이전에 웹서비스 적용 파일럿 프로젝트를 진행하였고 점진적으로 SOA의 최종 단계에 이르기 전에 네트워크 SOA에 나아가기 위한 파일럿을 진행하기 위해 우리 회사와 회의를 가졌다. 그들이 가진 의문점은 어째서 ESB가 필요한가 이다. 웹서비스 기술, 즉 SOAP, WSDL로 만들어낸 웹서비스를 UDDI로 관리하면 굳이 ESB를 적용하지 않아도 프로세스 기반의 SOA로 나아갈 수 있지 않느냐는 것이었다. 또한 ESB와 EAI가 다른 점이 무엇이냐라는 이제는 질릴정도로 많이 듣는 질문도 곁들였다. 비록 3시간에 걸쳐 회의를 하고서 보다 심층적인 내용을 다루기로 결론내렸지만 마음 한켠이 찜찜하다.
언뜻보면 ESB와 EAI는 같은 모습을 하고 있다. ESB가 할 수 있는 것을 EAI 역시 할 수 있다. ESB는 표준 기반의 EAI다! 라고 하기에는 고객을 설득하기가 참으로 힘들다. 과연 ESB가 EAI에 비해 다른 점이 고작 표준!일 뿐일까? 내가 생각할 때 그것은 정답이 아니라고 생각한다. ESB와 EAI는 그 모습이 유사하지만 서로가 바라보는 관점과 최종 목적지가 다르다는 것이 나의 생각이다. 즉, EAI는 Integration에 초점을 맞춘 기술임에 비하여 ESB는 프로세스 기반의 SOA로 나아가기 위한 기반으로서 만들어진 것이다. 프로세스 기반의 SOA란 무엇인가? 유연한 비즈니스를 목적으로 하는 아키텍처이다. 이것은 네가지 단계의 라이프싸이클을 가진다. Modeling ->Integration -> Deploy -> Business Monitoring 이 그것으로서, 이 네가지가 계속 반복되면서 목표로 하는 비즈니스 지표를 만족시킬 때까지 끊임없이 그 모습을 유연하게 바꿔가는 것이 SOA의 특징이다. 이러한 SOA의 최종 목적을 위해 만들어진 것이 ESB이고 ESB가 가진, EAI솔루션과 유사해보이는 특징들은 SOA를 만나면서 EAI솔루션들과 격을 달리하는 가치를 부여받게 된다.
ESB에서 모든 자원과 로직들은 서비스화된다. 그런데 이 서비스는 웹서비스만을 지칭하는 것이 아니다. 그것은 때로는 데이터 서비스가 될 수도 있고 메시징 서비스가 될 수도 있다. 그것이 어떠한 것이 되었건 SOA에서 중요한 것은 얼마나 유연하게 Integration이 가능하게 관리가능하느냐이다. 이것을 만족시키기 위해 IBM이나 BEA에서 MS의 WCF에 대응하는 SCA, SDO, CBE등을 만들게 된 것이고 SCA 환경에서 모든 비즈니스 로직은 바인딩 정보와 분리되어 관리된다. 따라서 SOA환경이 모든 자원들을 웹서비스화 해야만 하는 것은 아닌 셈이다.
오늘 만난 고객은 이전에 웹서비스 적용 파일럿 프로젝트를 진행하였고 점진적으로 SOA의 최종 단계에 이르기 전에 네트워크 SOA에 나아가기 위한 파일럿을 진행하기 위해 우리 회사와 회의를 가졌다. 그들이 가진 의문점은 어째서 ESB가 필요한가 이다. 웹서비스 기술, 즉 SOAP, WSDL로 만들어낸 웹서비스를 UDDI로 관리하면 굳이 ESB를 적용하지 않아도 프로세스 기반의 SOA로 나아갈 수 있지 않느냐는 것이었다. 또한 ESB와 EAI가 다른 점이 무엇이냐라는 이제는 질릴정도로 많이 듣는 질문도 곁들였다. 비록 3시간에 걸쳐 회의를 하고서 보다 심층적인 내용을 다루기로 결론내렸지만 마음 한켠이 찜찜하다.
언뜻보면 ESB와 EAI는 같은 모습을 하고 있다. ESB가 할 수 있는 것을 EAI 역시 할 수 있다. ESB는 표준 기반의 EAI다! 라고 하기에는 고객을 설득하기가 참으로 힘들다. 과연 ESB가 EAI에 비해 다른 점이 고작 표준!일 뿐일까? 내가 생각할 때 그것은 정답이 아니라고 생각한다. ESB와 EAI는 그 모습이 유사하지만 서로가 바라보는 관점과 최종 목적지가 다르다는 것이 나의 생각이다. 즉, EAI는 Integration에 초점을 맞춘 기술임에 비하여 ESB는 프로세스 기반의 SOA로 나아가기 위한 기반으로서 만들어진 것이다. 프로세스 기반의 SOA란 무엇인가? 유연한 비즈니스를 목적으로 하는 아키텍처이다. 이것은 네가지 단계의 라이프싸이클을 가진다. Modeling ->Integration -> Deploy -> Business Monitoring 이 그것으로서, 이 네가지가 계속 반복되면서 목표로 하는 비즈니스 지표를 만족시킬 때까지 끊임없이 그 모습을 유연하게 바꿔가는 것이 SOA의 특징이다. 이러한 SOA의 최종 목적을 위해 만들어진 것이 ESB이고 ESB가 가진, EAI솔루션과 유사해보이는 특징들은 SOA를 만나면서 EAI솔루션들과 격을 달리하는 가치를 부여받게 된다.
ESB에서 모든 자원과 로직들은 서비스화된다. 그런데 이 서비스는 웹서비스만을 지칭하는 것이 아니다. 그것은 때로는 데이터 서비스가 될 수도 있고 메시징 서비스가 될 수도 있다. 그것이 어떠한 것이 되었건 SOA에서 중요한 것은 얼마나 유연하게 Integration이 가능하게 관리가능하느냐이다. 이것을 만족시키기 위해 IBM이나 BEA에서 MS의 WCF에 대응하는 SCA, SDO, CBE등을 만들게 된 것이고 SCA 환경에서 모든 비즈니스 로직은 바인딩 정보와 분리되어 관리된다. 따라서 SOA환경이 모든 자원들을 웹서비스화 해야만 하는 것은 아닌 셈이다.
공유하기 버튼
|
|
최근 덧글