KingCrap.com

잘 알려지지 않았지만, MSE는 마이크로소프트가 SOA 영역, 특히 SOI (Service Oriencted Infrastructure) 영역에서 자신있게 내세우고 있는 서비스 가상화 솔루션으로 Codeplex를 통해 오픈 소스 (Ms-PL)로 제공하고 있다. MSE는 어느날 갑자기 세상에 나온 것이 아니라, 마이크로소프트 컨설팅 서비스가 다년간 서비스 인프라측면에서 자산으로 발전시키며 컨설팅에 활용해온 것이며 이를 오픈 소스로 공개한 것이다. 많은 mission-critical 시스템 구축에 사용되어 그 가치가 입증되었으며 현재 Codeplex에 공개된 최신 버전이 무려 7.0.0.6이다.

MSE는 외부로 노출된 서비스가 버전 업이 되면서 이전 wsdl 기반의 고객과 새로운 wsdl 기반의 고객이 아무 불편함이 없이 서비스를 받을 수 있도록 중간에서 서비스 버전닝을 제공하는데 이 또한 구성의 변경을 통해서 가능하게 한다. 또한 이전에 없던 새로운 정책을 일괄적으로 노출된 서비스들 즉, 시스템 전체 혹은 endpoint 레벨로 혹은 더 세밀하게 Operation 단위로 적용하고자 할 경우에도 구현에는 전혀 변경이 없으면서 drag-and-drop을 통해 정책을 강제할 수 있도록 WS-Policy를 지원하고 있다.

MSE는 위 그림에서 보듯이 사용자의 요청에 대해 적절한 타겟으로 서비스를 전송하기 위해 Messenger, Broker, Dispatcher로 구성되어 있으며 SQL Server 2005/2008을 Service Catalog로 사용하며 관리도구는 WPF로 구현되어 있다. (즉, MSE 설치시 관리도구를 선택하면 .NET Framework 3.5 SP1을 요구한다.) 실질적인 엔진은 설치와 함께 설치되는 MSE Catalog Service와 MSE Runtime Service이며 이들은 윈도우 서비스 형태로 구동되어 가상화 기능을 제공한다. 아래 그림과 같은 MSE 관리도구는 MSE Catalog Service에 접속하여 등록되어 있는 각 요소들과 기본 제공 요소들, 가령 각종 binding이나 정책들을 보여주며 이들을 이용하여 외부에 노출될 새로운 endpoint를 손쉽게 작성하게 한다.

아래와 같이 WCF로 구현된 서비스가 있을 경우, (이는 설치와 함께 제공되는 샘플이다.)

관리도구에서 wsdl을 통해 해당 서비스를 읽어 들일 수 있다. 또한 REST 기반의 웹 서비스도 가능하며 추후 데이터베이스에서 노출된 웹 서비스도 직접 읽어들일 수 있게 할 예정이다.

읽어들인 서비스의 개별 기능들을 원하는 조합으로 엮어 아래와 같이 Endpoint를 작성할 수 있다. 즉, 실제 서비스되고 있는 구현체의 포트나 URL과는 전혀 상관없는 임의의 포트와 URL을 주어 서비스 레이어를 구현체와 분리시켜 관리하는 것이다.

이렇게 drag-and-drop을 통해 서버단의 여러 서비스들로부터 조합된 새로운 endpoint가 MSE Messenger기능을 통해 외부로 노출되는 것이며, MSE는 이렇게 노출된 서비스를 테스트할 수 있는 테스트 클라이언트도 제공하고 있다.

웹 서비스 몇 개 노출시키는 것이 전부인 경우나 배치 작업과 같이 서버의 프로세싱이 전부인 경우 MSE를 적용하는 것은 무의미하다. 하지만, 서비스 노출하는 수가 증가하고 고객의 요구에 따라 공통 서비스의 버전이 달라지고, 예전에 없던 각종 규제등으로 인해 혹은 비지니스 환경의 변화로 인해 각종 정책을 다운 타임없이 적용하고자 할 경우 MSE는 중요한 역할을 한다. 미국내 많은 mission-critial 시스템의 경우 MSE가 BizTalk 서버 혹은 ESB guidance 와 함께 사용되고 있으며 곧 오픈 예정인 모(某)사의 항공 업무 시스템은 잠깐 동안의 다운타임에도 수백만 달러의 손실을 유발하는 mission-critical한 시스템인데 MSE와 WF/WCF를 이용하여 구축되었다. (Case Study 곧 공개 예정)

아래 그림과 같이사용자의 요청은 서비스 가상화를 제공하는 MSE를 통과하여 routing 기능을 제공하는 ESB 거쳐 실제 서비스 제공자에게 전달된다.

SQL Server 2005 혹은 2008과 .NET Framework 3.5 SP1이 설치되어 있다면, Codeplex에서 MSE를 다운로드 받아 설치해보길 권장하는 바이다. 설치 매뉴얼과 기술 문서가 codeplex에 함께 공유되고 있으며, 설치한 후에는 서너개의 웹 서비스 샘플과 정책 샘플들이 함께 제공되기 때문에 손쉽게 테스트해볼 수 있다.

[업데이트] 2009-03-23
본문에서 언급된 항공사 관련 SOA 적용사례에 대한 정보를 다음 링크에서 확인할 수 있다. EDS가 IBM 솔루션을 걷어 내고 마이크로소프트 닷넷 기반의 솔루션 기반으로 개발하여 오픈한 항공 산업 관련 시스템에 대한 내용을 확인해볼 수 있다.
- Service-Oriented Architecture In the Airline Industry
- Real World SOA 사례

[업데이트] 2009-03-25
읽어볼 만한 서비스 가상화에 대한 짤막한 아티클이 있어 소개한다.
Why Service Virtualization Matters

[업데이트] 2009-04-22
MSDN 매거진 5월호에 MSE 관련하여 "Service Virtualization With The Managed Services Engine"이라는 주제의 글이 게재되었다. 마이크로소프트의 SOA Infrastructure 전략과 연계하여 MSE가 어떤 역할을 하는지, MSE에 대한 간단한 소개 등을 볼 수 있다.

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

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 스펙으로 통합 제정함이 어떨까..닷넷하는 사람으로서 대응하기 힘들어서 .... ;)

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