SOA(Service Oriented Architecture)에서 ESB-(Enterprise Service Bus)는 비즈니스 프로세스를 유연하게 유지해 줄 수 있다. 이번 달에는 이 복잡한 신기술에 대해 쏟아져 나오는 과장 광고들의 홍수를 어떻게 헤쳐 갈 수 있는지, 그래서 올바른 선택을 어떻게 할 수 있는지를 소개한다.
변하지 않을 것처럼 개발된 애플리케이션들은 조직이 새로운 비즈니스의 필요에 맞추기 위해 이들을 변경할 때마다 점점 더 비싸고 부담스러워진다. 시스템은 계속적인 사람의 개입과 IT 재개발을 필요로 하기 때문에 자동화는 좀체 실현되기가 힘들다. 기술을 비즈니스 목표에 맞게 조화시키는 일은 통합 문제와 화이트보드를 넘지 못하는 프로그레스로 인해 미궁에 빠지기 십상이다.
이러한 문제에 대한 해결책은 무엇인가. 서비스 지향성(Service Orientation)이라 말하면 거의 모든 사람들이 돌아볼 것이다. 비즈니스 쪽에서는 서비스를 이해한다. 계약에 따라 한 쪽에서는 다른 쪽에 원하는 것을 전달한다. 서비스가 너무 비싸거나 회사에서 원하는 것을 따라주지 못하면 다른 사업자로 바꿀 수 있다. 서비스 패러다임은 또한 여러 파트너들이 함께 모여 즉각적인 고객의 니즈를 충족시켜 준다는 협업 관계에도 맞는 개념이다.
설문 응답자 54%, ESB 이행
기업의 임원들은 IT와 애플리케이션 커뮤니티가 역동적인 서비스 관계를 지원하는 일을 보다 잘 해내기를 요구하고 있다. 따라서 서비스를 정의한 다음 내·외부의 IT 사업자들
과 함께 협동해 이들을 서비스 수준 협정(Service Level Agreement)과 같이 계약서에 명기된 대로 배치하기를 원한다. 현명한 임원들은 스스로 프로세스와 서비스를 정의하고, 적절한 거버넌스(governane) 규정과 베스트 프랙티스(best practice)를 통해 이들을 실제 행동으로 이끌어간다는 달콤한 꿈도 꾼다.
SOA(Service Oriented Architecture)는 IT쪽 해답이다. 급속히 진화하는 XML과 웹 서비스 표준은 개발자들이 시스템을 조립하고 분산 네트워크를 통해 이들을 통합시키는 방식을 혁신시키고 있다. 이제 개발자들은 더 이상 엄격한 전용 언어와 SOA 이전 시대에 유행했던 객체 모델인 CORBA와 마이크로소프트의 DCOM(Distributed Component Object Model)에 구속될 필요가 없다. SOA
의 출현은 특히 웹 기반 분산 컴퓨팅의 개발 방안의 견인
차 역할을 하고 있다. SOA 채택이 확산됨에 따라 BPM (Business Process Management), EAI(Enterprise Application Integration) 및 메시지 지향형 미들웨어용 툴에도 혁신이 일고 있다.
웹 서비스는 성숙한 기술들을 이용할 수 있지만 비즈니스 리더들의 꿈 속에 나오는 것들을 실현시키기려면 SOA에 그 자체의 ‘엔진’, 즉 ESB(Enterprise Service Bus)가 필요하다. ESB는 몇 가지 기술들을 녹여서 SOA 배치 기반에서 비즈니스 서비스를 재활용해 “코딩 작업 대신 구성을 통해 애플리케이션들간의 관계와 프로세스를 변화시킬 수 있도록 해준다” 고 포레스터리서치의 마이크 길핀 부사장은 설명했다. ESB의 핵심 역할로는 메시징, 데이터 변형, 라우팅, 웹 서비스, 프로토콜 지원, 그리고 서비스 오케스트레이션(service orchestration) 등이 있으며, 그 중요도는 비즈니스 니즈에 따라 다르다.
본지 독자 설문조사에 따르면, 응답자의 54%가 ESB를 이행하고 있거나 올해 안에 할 예정인 것으로 나타났다. 그리고 절반 이상(66%)이 통합 및 프로세스 자동화 모두에 ESB를 이용하고 있었다. ESB 통합의 가장 큰 장벽을 묻는 질문에서는 사용 가능한 전문 기술 부족이 가장 많이 언급되었으며, 그 다음이 보안에 대한 염려였다.
ESB 이해의 첫 걸음, EAI
ESB는 순수 참여 ESB와 그 결쟁자들을 구분짓는 데 사용되는 ‘마키텍처(marketecture)’ 용어다. 시장에서 정의된 범주의 역사를 돌이켜 보건데, BEA, IBM, 마이크로소프트, 오라클 및 SAP 등과 같은 대형 업체들이 자신들의 포괄적인 스위트에 이 기술을 포함시키기만 하면 ESB의 보관수명(shelf life)이 끝날 것으로 전망하고 있다. 그럴지도 모른다. 하지만 이 기술이 어떻게 흔들리든 관계없이 IT는 ESB에서 새로운 기술의 조합을 어떻게 설명하는지 알고 있어야 하며, 이는 일부 컴포넌트들이 이미 큰 스위트의 일부인 경우도 마찬가지다.
ESB의 SOA를 향한 지향성과 분산 네트워크는 시장 포지셔닝 이상으로 매우 중요하다. ESB 제품이 어떻게 다른지를 이해할 수 있는 가장 좋은 방법은 애플리케이션 미들웨어 영역에서 이에 앞서 무엇이 있었는지부터 살펴보는 것이다. 그리고 그것은 바로 EAI다.
웹 이전의 시대에서 EAI는 맞춤 프로그래밍된 포인트 투 포인트 통신의 대안이었으며, 조직을 스파게티 코드의 혼란에 빠트렸던 정보 액세스 루틴이었다. ERP(Enterprise Resource Planning) 등과 같은 내부의 많은 레거시 및 패키지 애플리케이션들을 통합하고자 하는 사이트들은 이 문제로 인해 곤란을 겪었다. 패키지 애플리케이션 업체의 API는 수준도 낮았다. 시스템들간의 인하우스 통합에는 반복되고 에러도 빈번한 변형(transformation) 프로그램이 필요했다.
EAI 업체들은 변형이나 보안 등과 같은 기능들을 집중화시키기 위해 허브 앤 스포크(hub-and-spoke) 모델을 제공했다. 허브는 객체 기반의 어댑터와 통신을 하는데, 이것은 본래 기존의 애플리케이션을 래핑(wrapping)함으로써 이들이 다른 애플리케이션으로부터 허브를 통해 라우팅되는 데이터를 수용함으로써 참여할 수 있게 해준다.
EIA는 스파게티 코드나 포인트 투 포인트 통신의 경쟁 대안들에게서 결코 승리를 거둔 적이 없지만 애플리케이션 통합을 애드혹 공사에서부터 보다 추상적인 단계로 바꿔준다는 흥미로운 비전을 제공했다. 이 단계에서는 개발자들이 컴포넌트 및 객체 모델링을 이행하는 데 역점을 둘 수 있었다. 이런 식으로 EAI는 모델 주도식의 아키텍처가 시작될 수 있는 발판이 되었는데, 이런 아키텍처에서는 개발자들이 OMG(Object Management Group) UML(Unified Modeling Language) 표준과 애플리케이션 독립형 데이터 모델을 이용해 어떤 플랫폼에서나 돌아가는 시스템을 만들 수 있다. 허브 앤 스포크 모델은 또한 이런 애플리케이션이 네트워크 프로토콜이나 다른 통신 수단을 공유할 필요 없이 함게 작동할 수 있다는 것을 의미하기도 했다.
새로운 군단 등장
선도적인 EAI 업체들은 분산 컴퓨팅 노드들간에 더 많은 표준 상호운용성을 지원하기 위해 자신들의 허브 앤 스포크 아키텍처에서 OMG CORBA 사양을 이행했다. CORBA와 마이크로소프트 DCOM 시스템은 독점적으로 객체 지향형 RPC 통신을 지원했는데, 이것은 SOAP(Simple Object Access Protocol)가 HTTP 등의 인터넷 프로토콜에서 XML 문서에게 하는 것과 비슷한 역할을 한다.
CORBA의 IDL(Interface Definition Language)은 WSDL(Web Services Description Language)이 웹 서비스에서 하는 것의 전조격으로, ORB(Object Request Broker) 미들웨어 내에서의 객체 상호작동을 지원하기 위한 API를 규정했다. IBM/래쇼널(Rational) 등 업체들은 SOA 및 웹 서비스와 작동하도록 자신들의 ULM과 MDA 기반 배치 및 아키텍처 툴을 개조하고 있다.
동기적인 RPC 컴퓨팅은 한 가지 형태의 미들웨어 통신만을 대변했다. 이 모드는 쌍으로 이뤄지는 경향이 있는데, 이는 곧 제대로 수행하기 위해서는 요청 및 응답 파트너가 정해진 방식으로 있어야만 인터페이스 불일치나 와해를 피할 수 있다는 것을 의미한다. 다른 컴퓨팅 모드(일종의 프로세스 및 워크플로우 관리 포함)를 지원하기 위해 새로운 군단의 업체들이 메시지 및 이벤트기반 컴퓨팅 기술을 들고 EAI 시장으로 들어 왔다.
IBM이나 팁코(TIBCO) 같은 업체들은 이미 메시지 지향형 미들웨어 시장에서 입지를 굳히고 있었다. 그리고 액티브 소프트웨어(Active Software: CORBA를 만든 짐 그린이 설립한 회사로 웹메쏘드에서 인수) 같은 업체들은 이것을 모두 합쳐서 허브 앤 스포크의 이벤트 주도식 시스템을 만들었는데, 여기서는 어댑터가 큐잉, 필터링, 전달 및 보안 등을 관리하는 중앙 브로커(central broker)로 ‘이벤트(events)’라고 하는 메시지를 보내고 받는다. 시스템은 더 많은 브로커를 추가하고, 쓰레딩(threading)과 멀티프로세싱(multiprocessing)의 이점을 활용함으로써 성장이 가능했다.
OMG는 궁극적으로 CORBA용 비동기 메시징 서비스를 정의했다. 업체들은 표준을 사용하거나, 자체 사양을 이용해서 메시징 서비스, 실시간 부하조절 및 라우터를 추가함으로써 엄중성을 파괴시켰다.
하지만 대다수 CORBA 이행안의 전용 속성 때문에 이기종 컴퓨팅은 힘이 들었다. 서버들간의 허브 앤 스포크 관계는 오브젝트 레퍼런스와 객체들 사이의 점 대 점 연결이 돼야 했기 때문에, CORBA 시스템은 모든 애플리케이션 통합과 긴밀히 연결됐다.
그런 다음 인터넷으로 인해 아마도 수 천 개의 알려지지 않은 클라이언트가 웹을 통해 서버와 통신을 하고자 시도하고 있는 상황이 나타났으며, 기업들은 새로운 분산 컴퓨팅 모델, 즉 웹 서비스를 요구했다.
허브 앤 스포크, 친구냐 적이냐?
웹 서비스 스택은 많은 표준들이 CORBA가 소개했던 것과 유사해 CORBA에 많은 빚을 지고 있다(하지만 CORBA보다 훨씬 더 개방적이고 상호운용적인 방식으로 진행이 된다). 그 결과는 아직 필적할 만한 수준은 아니다. 예를 들어 웹 서비스는 성능 면에서 CORBA 시스템에 미치지 못하며, 트랜잭션 프로세싱 속성들(properties)에 대한 보다 완전한 지원을 필요로 한다.
이것은 일부 ESB들은 거의 성공하지 못하고 있는, 수정이 필요한 문제들이기도 하다. 하지만 웹 서비스의 채택이 늘어나면서 많은 조직들이 하나의 전략적 방향으로 SOA를 채택함에 따라 주류에서는 CORBA가 꿈꾸던 것과는 다른 수준의 분산 컴퓨팅으로 시선을 돌리고 있다. SOA에서는 오픈 웹 표준에 따라 발견 및 액세스가 되는 독립적이고 재활용이 가능한 서비스의 네트워크를 설명하고 있다.
IT에게 있어 허브 앤 스포크의 가장 큰 매력은 바로 제어다.
IT는 허브의 개념적 모델과 비즈니스 로직을 이용해 애플리케이션과 데이터 소스들 사이의 데이터 구성요소 같은 것들을 표준화할 수 있다. 많은 IT 조직들이 SOA로의 패러다임 이동에서 이런 미덕들을 보존하고 싶어할 것이다. 불행히도 집중식 허브 방안과, CORBA나 EAI과 관련된 보다 느린 모델 주도식 개발 방안들은 오늘날의 민첩성에 대한 목표와는 상반된 영향을 미친다.
게다가 CORBA에는 스토리지와 텍스트 조작에 초점을 둔 다른 표준 패밀리를 넘어서 성장한 XML이 쉽게 통합되지 못하고 있다. 전반적으로 SOAP, WSDL, UDDI 및 웹 서비스는 바로 사람들이 XML의 잠재력을 CORBA에 대한 데이터 분산형 미들웨어로서 인식하기 때문에 힘을 얻었다.
XML/SOA 패러다임에서 활개를 치고 있는 것은 익스트림 프로그래밍(Extreme Programming), 기민한 방법론(Agile Methodology) 등과 같이, 비즈니스 니즈를 신속하게 충족시킨다는 ‘저스트 두 잇(just do it)’ 개념을 선호해 UML과 CORBA를 요약한 소프트웨어 개발용의 예전 ‘디자인 엔지니어링(design engineering)’ 개념을 거부하는 기술들이다. 유망한 새 AJAX(Asynch JavaScript Technology and XML) 웹 애플리케이션 모델은 SOA 개발에 얼마간의 풍부함(과 아마도 IT 거버넌스까지)을 가져다 주고 있다. AJAX에서는 브라우저 기반의 클라이언트 및 서버와의 비동기적인 상호작동을 관리할 수 있는 매개 엔진을 제안하고 있다. BEA, 케이프클리어(Cape Clear), 소닉 및 팁코 등과 같은 ESB 사업자들은 자신들의 개발 환경용으로 AJAX 기능성을 이미 개발 했거나 하고 있는 중이다.
EAI 업체들은 새로운 허브 앤 스포크를 이용해 신규 서비스와 허브 업그레이드에 많은 수수료를 부과하면서 재미를 보고 있기 때문에, 비용이 SOA에 대한 관심을 끄는 데 일조를 했다는 것도 놀랄 일이 아니다.
라이선스 수수료외에도 EAI 프로젝트는 시스템을 개발 및 유지보수하는 데 전문가가 필요하기 때문에 예산을 잡아먹는 것으로 악명이 높다. 이것은 EAI의 ‘엔터프라이즈(enterprise)’ 부분 때문이다. ERP와 마찬가지로, 사업기능(business function)들간의 막대한 리엔지니어링 작업을 포함하고 있는 시스템들은 결코 저렴하지 않다.
SOA는 하나의 사업 라인이나 부서에서 ESB와 웹 서비스 표준을 고수하는 한 자체 서비스와 애플리케이션 개발 작업을 진행시키기 한층 수월하게 만들어 준다.
ESB 시장에는 메시지 기반 통합을 다루는 방식외에도 몇 가지 논쟁거리가 있다. 메시지 지향형 미들웨어가 실시간 정보를 전달하거나,
이기종 애플리케이션들간의 트랜잭션을 지원해야 한다는 압박 하에서 분산형 시스템에서 오랫동안 기반이 돼 온 것과 마찬가지로, 메시징은 TCP/IP 네트워크에서 간단한 SOAP/HTTP 웹 서비스보다 더 많은 종류의 컴퓨팅을 지원하기 위해 ESB가 SOA를 실현시키는 방식이다.
SOA 실현 방식, 메시지
메시지 지향형 미들웨어는 데이터와 콘텐츠 통신을 조직화하고 우선순위를 지정할 뿐만 아니라, 분산형 시스템들간에 트랜잭션 ‘상태(state)’를 전달하는 수단으로 대기열을 이용한다. ESB는 SOAP/HTTP에서 요구하는 영속적인 RPC 양식의 록스텝(lockstep)에서 제대로 기능하지 못할 느슨하게 결합된 서비스(loose coupled service)들을 지원하기 위해 이 수단을 이용하고 있다. 마지막으로 메시징은 또한 이벤트 주도식 컴퓨팅에서 기반이 된다. 즉 ESB는 백본의 역할을 하며, 여기서 시스템은 애플리케이션을 가입시키는 데 있어서의 이벤트나 상태 변화를 ‘듣고(listen)’, 프로세스 지능을 이용해 자동으로 어떻게 반응할지를 결정한다.
ESB 순수 방식과 ESB로의 EAI 제품 변형 방식 모두에 있어서 가장 큰 의무 중 하나는 레거시 메시지 지향형 미들웨어 시스템들과의 호환성을 가능하게 함으로써, SOA가 XML과 비 XML 세상을 합하고 메시지 큐잉 능력을 이용해 애플리케이션과 데이터베이스, 디렉토리로의 액세스를 관리할 수 있게 하는 것이다.
예를 들어 아이웨이소프트웨어(iWay Software)의 SOA 미들웨어는 네이티브 메시징이 없는 ESB 기반 스위트로서, 많은 조직들이 이미 방화벽 내외부에 구축돼 있는 다중 메시지 지향형 미들웨어 시스템을 사용하기를 선호할 것이라는 가정을 기반으로 만들어졌다.
특히 SOA를 열망하는 애플리케이션 서버용으로 개발된 것으로 JMS(Java Messaging Service) 1.1이 있는데, 이것은 마이크로소프트 외부의 이런 제품들을 위한 표준의 결정판인 J2EE 1.4 사양의 일부인 API다. BEA, IBM, 오라클 및 SAP 등과 같은 애플리케이션 서버 사업자들은 자신들의 전통적인 중간층 역할이 분산형 컴퓨팅의 SOA 양식과 조화를 이루게 해야 한다는 압박을 받고 있다. 여기서는 물론 어떠한 단일 오류 지점도 없어야 한다. 어떤 업체는 제이보스(JBoss)나 글루코드(Gluecode) 같은 오픈소스 업체의 JMS 컴포넌트를 통합시켰는데, 글루코드의 경우는 아이비엠에서 2005년 인수를 했다. 그리고 어떤 곳들은 피오라노(Fiorano)나 소닉과 같이 자체 메시징 제품을 개발해 온 ESB 업체들과 파트너십을 맺고 있다.
경쟁 업체들은 피오라노와 소닉이 느슨히 결합된 SOA 비전을 손상시키는 전용 메시징을 갖고 있다고 비난하고 있다(단 이 두 업체의 제품은 모두 JMS와 호환이 가능하다). 하지만 BEA의 아쿠아로직 메시징(AquaLogic Messaging)을 제외하면 피오라노와 소닉은 메시징에 있어서의 자체 기술력으로 가장 잘 알려진 곳들이기도 하다.
네이티브 메시징 컴포넌트가 없는 케이프클리어는 라우팅, 서비스 탐색, 중개(mediation) 및 변형 등과 같은 관련 기능들을 메시지 지향형 미들웨어 레벨보다 높은 것으로 보고, 그러한 ESB 기능을 메시징 엔진에 밀접하게 연관시키면 SOA 목표와는 상반되는 ‘허브’ 개념이 다시 살아난다고 주장하고 있다.
SOA 심장 방식 논쟁
메시징과 신뢰성용으로 제정된 OASIS(Organization for the Advancement of Structured Information Standards) 웹 서비스 표준의 후원업체인 마이크로소프트 또한 소닉 등 업체들이 주장하는 ESB 접근 방식이 너무 전용이며, 회사들로서는 COM+ 노드와 같은 기술과 이기종 플랫폼들을 자신들의 SOA에 집어넣기가 너무 복잡하다는 생각이다.
바로 지금 마이크로소프트는 ESB 기능성을 함께 집어넣는 데 대한 해결책으로 비즈토크 서버(BizTalk Server)와 닷넷 프레임워크(.Net Framework)를 제공하고 있다. 비즈토크 서버 2006 릴리즈에서 마이크로소프트는 ESB라는 명칭을 쓰지는 않았지만, 2004 버전의 메시징 엔진에 인핸스먼트를 제공할 뿐만 아니라 서비스 오키스트레이션용 개발자 툴의 리프레시(refresh)도 제공하고 있다.
이 시장에서 벌어지고 있는 이러한 모든 긴장 상황은 ESB를 SOA의 심장으로 만드는 방식에서는 더 큰 논쟁으로 불거지고 있다. SOA의 심장부는 통신, 서비스 요청, 변형 및 중개, 보안 등과 같은 것들의 제어 지점으로서 극도로 느슨하게 결합된 서비스 네트워크여야 한다.
소닉은 트랜잭션 ‘상태 전달(state passing)’용으로 메시징 플랫폼을 이용함으로써 허브 부분을 덜었다. ‘
여정(itinerary)’, 즉 사용자에 의해 설정된 전달 종단지점에 대한 메타데이터는 메시지에 의해 전달이 되며, 이들이 중앙 로케이션에 등록할 필요 없이 스스로 라우팅할 수 있게 해준다. 여정은 첫 배치 이후에 변경될 수도 있다. 소닉의 이러한 여정 방안은 물론 이 회사의 느슨한 서비스 결합 개념에서는 결정적으로 중요하지만, 너무 전용이라는 비난을 받고 있다.
BEA나 폴라레이크(PolarLake) 같은 업체들도 유사한 라우팅 방안을 갖고 있긴 하지만 충분히 다르기 때문에 그 이행을 신중히 비교해야 한다. 일부 라우팅 시스템들은 업체측의 데이터 변형 및 중개 도구들뿐만 아니라 이들의 UDDI와 서비스 레지스트리 및 탐색에 대한 지원과도 밀접한 연관이 있다. 이러한 프로시저가 사업의 목표를 명확히 하는 모델에 의해 안내되고 자동화가 가능할수록, 개발자와 프로그래머들 쪽에서 낭비되는 시간과 경비가 줄어든다.
데이터 라우팅은 마이크로소프트 비즈토크 서버는 말할 것도 없고 모든 ESB에서 다루고 있는 중요한 작업으로써, 매개자들이 메시지의 방향을 오케스트레이팅할 수 있게 해준다. 이것은 일반적으로 JMS 프레임워크 안에서 이뤄지지만, 정상적인 메시지 가입 장치보다는 메시지의 XML 콘텐츠를 기반으로 발생하기도 한다. 외부 및 서비스 라우팅은 데이터 염려밖의 사항으로, 비즈니스 프로세스 관리 및 서비스 실행과 관련이 있다.
아마도 기존의 ESB 메시징 구도는 세 가지 요인들로 인해 바뀌게 될 것 같다. 우선 마이크로소프트의 WCF(Windows Communication Foundation, 구 인디고)와 마이크로소프트의 닷넷 SOA 활동의 핵심 요소인 비즈토크 서버는 2006년 ESB용으로 보다 분명하게 제품의 포커스를 맞추게 될 것이다. 둘째, 일부 기업들은 ESB의 모든 기능이 필요하지 않기 때문에 오픈 소스가 주목을 끌 수 있을 것이다.
지난 1월 아이오나테크놀로지스(Iona Technologies)와 오브젝트웹(ObjectWeb) 컨소시엄에서는 셀틱스 마일스톤(Celtix Milestone) 4를 내놓았는데, 이것은 이들의 오픈소스 프로젝트에서 중요한 단계로 리눅스와 마찬가지로 개발자들에게 필요에 따라 맞춤화할 수 있는 가벼운 ‘마이크로커널’ ESB를 제공할 것이다.
그리고 셋째, 신뢰할 수 있는 메시징 및 라우팅을 위한 새로운 OASIS 웹 서비스 표준이 JMS를 대신하고, 나아가 ESB를 범용화 시킬 것이다. OASIS는 아직 두 가지 경쟁 표준인 WS-릴라이어블 메시징(Reliable Messaging)과 WS-릴라이어빌러티(Reliability)를 가려내야 하는데, 이 둘은 모두가 ESB가 상태를 관리하고 느슨하게 결합된 메시지 지향형 프레임워크에서의 에러 상황을 처리하는 방법을 다루고 있다.
비즈니스 인티그레이터
시스템들이 네트워크에서 느슨하게 결합된 서비스로 상호 작동할 수 있도록 지원해야 하는 극히 중대한 SOA 의미를 수반하는 ESB는 전통적인 EIA의 ‘단일 허브’ 입장을 완전히 버리지 못했다. BPEL(Business Process Execution Language)을 채택한 ESB가 만약 서비스 실행을 유도하는 모델, 규정 및 프로세스의 방향을 바꾸는 수단이 된다면 중앙 권력기관으로서의 그 역할은 더욱 커질 것이다.
ESB 정의는 그 엔진의 어떠한 전용 특성에 독립적인 라우팅 및 비즈니스 프로세스 기능성을 제공하는 이벤트 주도식의 XML 기반 메시징 엔진쪽으로 천천히 자리잡고 있다. 하지만 ESB는 또한 범용화가 되고 있으며 비교하기 쉬운 수준에까지 이르렀다. 어떤 것들은 자체의 메시징 엔진을 갖고 있는 반면 파트너들의 툴과 작동하는 표준을 단순히 이용하는 것들도 있다. 어떤 것들은 변형, 중개 및 서비스 레지스트리의 주요 통합 작업을 전문으로 하며, 수직적 맞춤화를 통해 훨씬 더 깊이를 갖출 수도 있다. 반면 내부의 정보 매니저와 프로그래머들의 몫으로 더 많이 남겨두는 것들도 있다.
ESB가 SOA를 이행하는 조직들을 고객의 요구에 대응하는 데 걸리는 시간을 줄이는 데 필수인 재사용성(reusability)이라는 성배에 한층 가깝게 데려갈 수 있을까? 아니면 비즈니스 민첩성을 지원할까? ESB가 다음 두 가지를 할 수 있다면 대답은 예스다. 우선 ESB는 메시징을 성공적으로 채택하고, 단순한 웹 서비스가 제공하는 것보다도 훨씬 더 느슨하게 결합된 서비스를 허용해야 한다. 비즈니스 임원들은 ‘느슨하게 결합된’이란 말을 직관적으로 이해할 것이다. 인수 합병을 통해 성장을 거듭해 온 자신들의 조직이 이미 그런 상태기 때문이다. IT는 이러한 정신적인 차이를 극복해야만 한다.
두 번째 작업은 재사용성 검색을 코드나 객체, 혹은 심지어 서비스보다 더 높은 단계인 추상(abstraction)으로 옮기는 것이다. 비즈니스 임원 및 매니저들은 신규 고객과 비즈니스 라인, 그리고 공급망에게 쉽게 받아들여지도록 프로세스를 다듬고 향상시킨다는 개념을 잘 이해하고 있다. 이러한 개념이 현실이 되도록 기반 기술을 맞추는 일은 바로 IT의 몫이다.
더 나은 ‘두뇌’ 간절히 필요
BPM 툴과 이행은 얼마간의 성공을 거두고 있으며, 여기에는 패키지 애플리케이션과 EAI 업체들이 내놓고 있는 초보적인 워크플로우 툴들은 말할 것도 없이 파일넷(FileNet), 퓨고(Fuego), 새비온(Savvion) 등의 제품들이 포함돼 있다. 하지만 SOA는 조직들이 아웃사이드 인 관점을 갖추기 위해 할 수 있는 일의 범위를 극적으로 넓여줄 수 있는 잠재력을 갖고 있다.
물론 개방형 표준들이 애플리케이션 통합을 향상 및 범용화시킬수록 BPM 개발자들이 해야 할 일은 적어진다. 보다 중요한 사실은 역동적인 비스니스 프로세스(많은 시스템을 포함하고 있는 액션 시퀀스)가 SOA에게 있는 비동기적인 메시지 기반 컴퓨팅 특성을 필요로 한다는 사실이다. 그리고 동시에 웹 서비스는 많은 서비스들을 포함하고 있는 복잡한 장기 실행 프로세스들을 돌리는 데(그리고 가급적 자동화하는 데) 더 나은 ‘두뇌’를 간절히 필요로 한다.
BPM에 대한 생각을 웹 서비스 세상으로 가지고 온 것은 바로 WSDL에서 발견된 한계였다.
WSDL은 메시지에서 운영 가능한 네트워크에서 일련의 웹 서비스를 정의하기 위한 XML 기반 표준이다.
WSDL과 관련 웹 서비스 표준은 예를 들어 이동 플랜(travel plan)을 만드는 데 필요한 많은 상호작동 서비스들을 오케스트레이팅 및 관리하기에 충분치가 못했다. 프로세스 오케스트레이션과 함께 시스템은 서로 다른 서비스의 트랜잭션 상태를 관리해야 하는데, 이것은 많은 서비스들이 장기 실행 트랜잭션을 마무리짓기 위해 교신해야 할 때 복잡한 문제가 될 수 있다.
2003년 BEA 시스템즈, IBM 및 마이크로소프트 등이 주도하는 OASIS에서 웹 서비스용 BPEL을 만들었다. WSDL과 마찬가지로 BPEL은 XML을 기반으로 하고 있다. 사실 BPEL 프로세스는 WSDL에서는 웹 서비스로 노출이 된다. BPEL은 프로세스의 추상(abstract) 개념을 이용해 최종 결론을 만들어내기 위해 모든 종류의 서비스들(동기와 비동기)을 모두 함께 가져가기 위한 로직을 정의한다. BPEL은 SOAP/HTTP에만 한정되지 않는데, 이는 곧 아파치 WSIF(Web Service Invocation Framework), JMS, 기타 자바 컴포넌트 및 마이크로소프트 플랫폼 등과 같은 다른 수단들을 통해 서비스를 액세스 및 바인딩하는 방법에 대한 기술 정의와 별도로 비즈니스 로직을 유지한다는 것을 의미한다.
ESB 업체들은 자신들의 제품이 웹 서비스 오케스트레이션 문제에 대한 솔루션으로, 그리고 SOA/BPM 시너지 효과를 위한 허브로 둘 다 쓰일 수 있게 하기 위해 BPEL로 뛰어들고 있다. ESB 업체들의 BPEL 툴은 모델링 및 표현(representation) 프로세스를 설명, 시각화 및 스크립팅하는 데 도움이 된다. 이들은 또한 GUI를 통해 ‘선언’을 하거나, 실행 가능한 비즈니스 프로세스를 프로그래밍하는 데도 유용하다.
서비스, 라우팅, 데이터 변형 및 중개 등에 BPM의 관점을 도입함으로써, 순수 BPM 업체들과 토털 스위트 업체들이 제공하는 오케스트레이션 엔진이 값비싼 VPM 제품의 관련성을 줄여줄 수 있을까? 포레스터리서치의 애널리스트인 켄 볼머는 “오케스트레이션은 시스템 중심적이고 고도의 자동화가 필요한 프로세스용으로 좋다”며, 그러나 “인간의 개입, 사용자 대시보드, 활동 모니터링 및 보고 등의 경우는 아직 BPM 업체들의 보다 완전한 기능을 갖춘 스위트들과 안정되지 않은 EAI 업체들의 제품에서 볼 수 있다”고 덧붙였다.
SOA 패러다임 이동
서비스 통합 및 오키스트레이션이 전용 BPEL 이행안들간의 전쟁이 되는 것을 막기 위해, 오픈 ESB 프로젝트에서 JBI(Java Business Integration)용의 JSR(Java Specification Request) 208이라는 새로운 표준을 만들었다. 자바 커뮤니티에서는 JBI가 J2EE가 애플리케이션 서버와 EIA에서 했던 역할을 보다 높은 레벨의 서비스 통합에서 할 수 있으리라 희망하고 있다. JBI는 또한 기존의 컴포넌트를 서비스로 노출시키기 위해 레거시 J2EE 시스템을 지원하는 데 대한 것이기도 하다. JBI는 J2EE 애플리케이션 개발자들이 SOA 패러다임으로 이동해 자바가 아닌 BPEL로 비즈니스 프로세스 로직을 한층 쉽게 이용할 수 있도록 만들어졌다.
썬, IBM, BEA 및 기타 주요 J2EE 툴 사업자들간의 정치적인 문제와 경쟁으로 인해 JBI의 진행이 계속 느려질 수 있겠지만, 문서상으로는 기존의 1.1 버전에서도 폭넓은 ESB, EAI 및 ERP 업체들에 대한 지원이 이루어지고 있는 것 같다. 오픈 ESB의 문서에 따르면 JBI는 ‘통합 기술의 협업을 지원하는 개방되고 확장 가능한 플러거블(pluggable) 플랫폼’으로 돼 있다.
플러그인 컴포넌트는 BPEL 엔진뿐만 아니라 EJB 컨테이너(container), XSLT(Extensible Stylesheet Language Transformation) 엔진(서로 다른 XML 방안과 포맷들 사이를 중개), 그리고 SOAP와 레거시 EDI 프로토콜 어댑터 등이 될 수가 있다. JBI는 또한 라우팅, 아티팩트(artifact), 그리고 SOA 애플리케이션을 구성하는 서비스들의 조합도 정의하고 있다.
