'JBI'에 해당되는 글 1건

  1. 2008.09.23 [펀글] 자바 진영의 SCA, JBI, ESB 용어 정리

예전 블로그에 썼던 글인데, 필요해서 예전 싸이트가 사라지기 전에 가져왔습니다.
--------------------------------------------------------------------------------------------------------------------------------

Service Component Architecture (SCA)에 잠시 살펴보자. SCA는 IBM, BEA 등이 주축이 되어 Sun의 입김이 강한 JCP (Java Community Process)를 거치지 않고 독자적으로 표준화를 진행한 SOA 기반의 서비스 구축에 관한 스펙이다. 당시 자바 표준을 정하는 JCP를 거치지 않고 독자 행보를 한 이들 업체들에 대해 곱지 않은 시선이 있었지만, 이들 외에도 그 당시에 JCP를 벗어나 독자 스펙을 제정하는 일이 여럿 있었다. (가령 볼랜드가 주축이 됐던 툴 표준화라던가...) 그만큼 JCP에 대한 Sun 역할에 불만이 적지 않았던 것이 사실이다.  현재 SCA는 Oasis에 넘겨져 표준화 절차를 밟고 있으며 SCA의 홈페이지는 http://osoa.org이다. SCA는 현재 자바만을 위한 스펙은 아니나 자바가 주축을 이루고 있다. SCA는 서비스를 제공할 애플리케이션을 컴포넌트 기반으로 어떻게 작성하고 이들 컴포넌트를 어떻게 엮어서 좀 더 복잡한 Composite Application을 만드는 가에 관한 스펙이다. 예전에 한국마이크로소프트가 주최한 아키텍트 포럼에서 강연한 David Chappell (http://davidchappell.com)이 언급한 바와 같이 SCA는 WCF와 여러 면에서 유사하다.

가장 큰 유사성은 하나의 비지니스 기능을 구현한 후 다양한 Binding을 제공하는 것이 Configuration 파일에서 선언하는 것만으로 가능하다. 필요한 모든 요소는 SCA 벤더가 제공하는 런타임이 다 제공한다. 차이점이라면 WCF는 닷넷 진영에서 제공해왔던 다양한 분산 환경에서의 통신 기술들은 통합한 전혀 새로운 표준 개발 방식이라면, SCA는 새로운 분산 환경에서의 통신 표준이라기 보다는 자바 진영의 기존 분산 환경 통신 기술들을 쉽게 사용할 수 있게 중간에서 매개 역할을 하며 필요한 것들을 자동화한다는 것이다.
서비스를 제공하는 컴포넌트를 만드는 방식에서도 WCF의 ABC (Address,Binding,Contract) 기법이 그대로 적용된다. 다만 약간의 용어가 다를 뿐....uri, binding, service 라고. 다른 점이라면 SCA는 컴포넌트들을 조합하여 좀 더 복잡한 컴포넌트를 만들기 위한 스펙이 있어서 서비스를 노출하는 인터페이스 외에 서비스를 참조하는 인터페이스를 기술하도록 하고 있다. 즉, 내가 필요로하는 서비스는 이런 이런 기능을 갖춘 서비스입니라..라는 식의 인터페이스를 기술하여 툴을 통해 비주얼하게 서비스를 해당 컴포넌트에 엮을 수 있게 하고 있다.
둘의 가장 큰 차이는 구현 언어에 있다. WCF는 당연 닷넷 언어로 구현하여야 하나, SCA는 자바 외에 C++, BPEL 등이 가능하며 Container 형태로 추가가 가능하다. 아울러 Spring Framework과 궁합이 잘 맞아 구현 Container로 Spring을 바로 적용할 수도 있다.

자바에는 SCA외에도 이와 유사한 기능을 하도록 만든 스펙 및 프레임웍이 존재한다. JBI (Java Business Integration)과 ESB (Enterprise Service Bus)가 그것이다. 이 셋을 어떻게 자리매김하는 가에 대해 상이한 의견이 있는 듯 하며 이들이 향후에 어떻게 교통정리가 되어 자리매김할 지 추측해보자.

SCA의 홈페이지에서는 SCA와 JBI에 대해 언급하면서 이 둘은 서로 충돌하여 하나가 배제되는 것이 아닌, 필요하면 함께 구현 가능하고 혹은 별개로 사용 가능하다고 밝히고 있으며, JBI가 애플리케이션 서버를 만드는 업체에서 JBI Container 만드는데 사용되는 것이며, SCA는 벤더가 아닌 개발자 및 배포자가 컴포넌트를 어떻게 만들고 조작하는가에 중점을 둔 스펙이라고 하고 있다. 이 둘의 아키텍처는 아주 유사하여 런타임이 있고 이를 기반으로 각종 container 형태의 것들이 실제 서비스를 구현한 컴포넌트를 담고 있고, 이들간 혹은 이들과 외부 서비스간의 통신은 binding을 통해 제공되는 형태이다. 하여 SCA입장에서 JBI는 SCA 런타임 위에 올라가는 각종 container를 구현하는 표준 API로서 역할로 자리매김하는 듯 하다. 하지만, JBI를 자세히 들여다 보면 SCA 만큼이나 개발 영역에도 할 말이 많음을 알게 된다. JBI 런타임 혹은 서버 구현은 물론 서비스 모니터링 기능 및 서비스 조합을 위한 에디터 등 컴포넌트 개발과 운영에 관해 큰 그림을 그리고 있음을 알 수 있다. 하지만, 대체적인 분위기는 SCA가 앞단에서 서비스를 조합하는 역할에 치중하고 JBI는 뒷단에서 서버 구현을 표준화시켜 3rd party가 만든 container를 맘껏 올릴 수 있게 하는 것으로 자리매김되고 있는 듯 하다. 썬이 엔터프라이즈 웹 서비스 분야에서의 좁아진 입지를 만회하고자 JCP를 통해 강력히 밀고 있는 JBI는 SCA의 구현을 원활히 하는 표준화 쪽으로 가닥을 잡을 것 같다. 현재 SCA를 구현한 오픈 소스 런타임으로는 아파치의 Tuscany와 Codehaus에 올라있는 Fabric3가 대표적이며 이들은 JBI와 무관하게 구현되어 있다.

그럼 ESB와 SCA 혹은 JBI와는 어떤 관련이 있을까 ?
ESB는 SCA,JBI와 달리 스펙이 아니다. 마케팅 용어로 시작되어 현재는 SOA 기반 개발 표준 프레임웍으로 자리잡고 있으며 SOA 기반의 제품을 표방한 서버 치고 ESB를 언급하지 않은 업체가 없을 정도이다. ESB의 아키텍처는 JBI와 유사하며 다수의 구현에 따라 얼마든지 바뀔 수 있다. JBI의 아키텍처에는 명시적으로 런타임의 가운데에 NMR (Normalized Message Router)라는 메시지 버스가 있고 이 주변에 서비스 구현체에 해당하는 Service Engine과 바인딩을 위한 Binding Component라는 것이 있어서 서비스간 바인딩을 제공한다. ESB는 표준이 없으나 태생이 MOM (Message-oriencted Middleware) 업체의 마케팅 용어이기 때문에 아키텍처 또한 메시지 기반의 백본에 (웹) 서비스를 표준 바인딩 수단으로 하고 중간에 메시지 변환 및 addressing, routing, 메타데이터 관리 등을 제공하는 형태로 되어 있으며 근래에는 BPM 기능도 ESB의 요소로 간주하고 있다. 현재 오픈 기반의 ESB 구현체로 썬 주도의 JBI 스펙 기반의 OpenESB, apache의 ServiceMix 등이 있다.
결국, ESB 제품을 구현함에 있어서 SCA 기능을 제공할 수도 있고 JBI 스펙 기반으로 ESB 서버를 만들 수도 있는 것으로 보인다. 현재 일부 ESB 제품이라고 얘기하는 자바 진영의 서버 가운데 SCA 스펙 제정을 주도한 업체들은 대부분 SCA를 지원하는 ESB를 선보이고 있고, 썬의 애플리케이션 서버는 OpenESB를 지원하며 SCA 기능은 제공하지 않는 것으로 보인다. 참고로 썬도 Open SOA 그룹 (http://osoa.org)의 늦깍이 회원이 되었다.

애초 생각은 WCF와 기능면에서 유사한 SCA에 대해 살펴보고자 했는데, SCA 이전부터 썬이 JBI 기반 구현체를 오픈/상용 형태로 개발 중이었고, 이를 애플리케이션 서버에 Servlet 컨테이너, EJB 컨테이너와 나란히 JBI 컨테이터 형태로 올리려했다는 것을 알고 있었기에 JBI까지 언급하기에 이르렀다. 현재 JBI 입장에서 JEE 컨테이너와의 연동은 중간에 브릿지 역할을 하는 JEE용 Service Engine을 통해 이루어지고 있다. ESB를 또 끌어들인 이유는, 서비스 기반 개발 방법에는 소위 ESB 서버를 빼 놓고는 현재 시장에서 관심을 끌지 못하고 있는게 현실이며, 많은 소위 SOA 제품군들이 ESB를 핵심 백본으로 그리고 있어서 결국 SCA가 하고자 하는 일이 이루어지는 바탕은 ESB가 구현된 SOA 제품군 위에서이다. 속 깊은 내용은 알 길이 없으나 표면적으로 볼때 현재 ESB를 표방한 IBM의 SOA 제품군은 예상대로 SCA를 지원하며 특히 컴포넌트 조합을 위한 개발 툴을 통합시킨 형태로 가고 있고 JBI에 대해서는 그다지 관심이 없어 보인다. 반면 썬의 경우 JCP를 통해 표준화한 JBI관점에서 접근하며 OpenESB (http://open-esb.dev.java.net) 라는 구현체를 통해 JBI를 구현하여 자신들의 오픈 소스 애플리케이션 서버인 Glassfish (http://glassfish.dev.java.net) 에서 OpenESB를 지원함으로써 JBI를 드라이브하고 있고 SCA에 관해서는 그다지 큰 관심을 보이는 것 같지는 않다.

밖에서 보는 입장에서 그리고 상용 벤더 입장에서 보면 SCA가 훨씬 많은 매력적으로 보인다. 컴포넌트를 WISWIG형태로 조합해서 서비스를 만드는 개발 툴과 이를 자신들의 ESB 서버에 바로 디플로이하게 함으로써 개발을 쉽게 할 수 있고, JBI는 ESB 서버를 구현할 때 확장팩 형태로 각종 자바 관련 기술들을 엮는 방식으로 지원하는게 합리적일 듯 싶다. 언제까지 SOA가 시장을 지배할지, 그리고 ESB가 SOA의 핵심이 될 지 모르겠으나, 이런 추세라면 중첩된 기능을 통합하여 SCA + JBI = ESB 스펙으로 통합 제정함이 어떨까..닷넷하는 사람으로서 대응하기 힘들어서 .... ;)

위 내용은 개인의 생각을 적은 것으로 의도적으로 사실을 왜곡하는 내용은 없을 듯 하나 일부 부정확한 내용이 있을 수 있다.

Posted by 장현춘
TAG , , ,

댓글을 달아 주세요