BPM에 SOA 결합하고 엑스트라넷 통합…서비스시장 진입
하지만 마이크로소프트의 SOA 계획 만큼은 누구에게도 뒤지지 않는다.
마이크로소프트는 엔터프라이즈 서비스 버스(ESB) 시장에는 이미 진입했으며 거버넌스를 위한 디자인도 보유하고 있는데다, 관리 벤더와의 제휴관계도 강화하고 있다. 아울러, 기업간(B2B)의 웹 서비스를 겨냥한 기술도 발표했다.
◆ MS의 적극적인 진입=마이크로소프트측은 자사가 언제나 SOA를 지원해왔다고 주장한다.
SOA를 그 자체가 아닌 비즈니스 프로세스 관리의 토대로 간주하고 있다는 것.
부분적으로 맞긴 하다. 마이크로소프트는 SOAP의 초기 지원 업체였으며 상당수 웹 서비스(WS) 표준이 이를 토대로 구현되었기 때문이다.
마이크로소프트는 SOA가 특정 제품이 아닌 구조적인 형태라는 점에 동의하고 있다. 마이크로소프트는 한발 더 나아가 ESB가 제품이라는 것을 부인하고 있다. 현재 많은 벤더들이 스탠드얼론 형태의 엔터프라이즈 서비스 버스를 판매하고 있으며 ESB는 SOA의 코어로 간주되고 있지만 마이크로소프트의 주장이 완전히 잘못된 것은 아니다. 더욱이, ESB 기능이 여러 제품으로 확대될 것으로 예상된다.
마이크로소프트 Vs. 타 업체
SOA 제품 카테고리 마이크로소프트 제품
엔터프라이즈 서비스 버스 비즈토크 서버,
윈도우 서버
디자인 타임 거버넌스 UDDI 서비스, 비주얼 스튜디오
런타임 관리 N/A
보안 게이트웨이 N/A
비즈니스 프로세스 관리 비즈토크 서버
사실, 마이크로소프트는 자사의 제품이 ESB 성능보다 상위에 있다며 '엔터프라이즈 서비스 버스'라는 용어를 의도적으로 피해왔다. 하지만 언제 그랬냐는듯 BPM 서버인 BizTalk 서버 2006을 ESB 구현 제품이라고 적극 홍보하기 시작했다. 하지만 BizTalk가 ESB는 아니다. 완전한 ESB 성능을 원하는 사용자들이라면 마이크로소프트 비주얼 스튜디오 닷넷 개발 환경과 오피스 인포패스(InfoPath) 에디터와 SQL 서버를 도입해야 한다.
먼저 ESB에 대해 짚고 넘어가자. 전통적으로, ESB는 적어도 두 가지 분야로 나뉜다. 하나는 서비스 구현(Service enablement)으로, 애플리케이션들을 재활용할 수 있는 요소로 쪼갠다. 또 다른 하나는 서비스 오케스트레이션(service orchestration)으로, 이들을 복합적인 애플리케이션으로 재전환하는 것에 해당된다. 또한 ESB는 일반적으로 여러 대의 서버에서 구동하는 반면 BPM은 오케스트레이션의 상단에서 구동하는 세번째 계층으로 간주된다.
마이크로소프트는 이러한 분류법을 따르지 않고 있다. 그 대신, 비즈토크 서버가 모든 통합을 처리, 구현에서부터 오케스트레이션, BPM까지 모두 담당한다. 순수한 SOA를 사용하건 혹은 완벽한 BPM을 구현하건 간에 애플리케이션 개발을 위해서는 비주얼 스튜디오가 필요하다. 인포패스와 SQL 서버는 XML 변환과 라우팅, 관리 업무를 지원한다.
마이크로소프트의 SOA를 고려하고 있는 사용자라면 서비스 구현 요소에 주의를 기울여야 한다. SOA용으로 개발된 대부분의 애플리케이션 서버는 자바 엔터프라이즈 에디션을 토대로 하고 있지만 마이크로소프트는 닷넷을 사용하기 때문에 호환성 문제가 발생한다. 표준형 웹 서비스나 다양한 어댑터를 사용해 데이터를 공유할 수밖에 없다.
다른 벤더들의 ESB가 닷넷과 연동하는데 비해 비즈토크는 그렇지 않다. 대부분의 ESB처럼, 비즈토크는 메시징 포맷과 다른 애플리케이션에 탑재된 API를 이해할 수 있는 어댑터를 포함하고 있다. 마이크로소프트는 경쟁사만큼 많은 어댑터를 제공하지 않지만 여러 SOA가 내부적으로 사용하는 자바 메시지 포맷을 이해할 수 있다.
마이크로소프트의 애플리케이션의 경우, 가장 중요한 어댑터는 닷넷 버전 3.0에서 구동하는 분산형 애플리케이션 구축을 위한 프레임워크인 WCF(Windows Communication Foundation)이다. 윈도우만 있는 환경에서는 ESB가 필요 없다.
SOA 서비스 영향 평가
장점 위험성
IT 부서 모든 종류의 SOA의 목표는 IT의 민첩성을 향상시키는 것이며 서비스로서의 SOA도 예외는 아니다. 엑스트라넷 애플리케이션에 있어서 통합 관련 작업을 줄일 수 있다. 각 외부 서비스를 개별적으로 연결시킬 필요가 없다. 웹 서비스를 인터넷에 노출시키는 것은 언제나 위험성이 수반된다. 다양한 비즈니스 파트너를 통해 여러 기능을 통합하는 것보다 단일한 서비스 사업자를 이용하는 것이 덜 위험하지만 아직 기술이 성숙하지 않았다.
비즈니스 부서 이론적으로 보면 완성품 형태로 제공되는 서비스는 핵심적인 비즈니스에 적합하지 않다. 하지만 실제로, SaaS는 관리의 용이성과 의사 결정의 효율성으로 인해 비즈니스에 긍정적인 영향을 끼친다는 것이 입증되고 있다. SOA 서비스는 애플리케이션 통합의 기술적인 측면에만 연관된다. 비즈니스 측면에서 본다면 써드 파티와의 협력 관계가 절실히 요구된다.
비즈니스 경쟁력 조직의 역할과 IT의 속성, 통합 여하에 따라 이점이 달라진다. 서비스 형태의 SOA는 SaaS를 이미 도입한 기업들에게 가장 유용하다. SaaS 기반의 통합은 비즈니스 파트너가 동일한 서비스를 사용할 경우에만 수월해진다. 아직 초기 단계인 SOA 서비스 시장은 다양하고 복잡한 형태로 전개되고 있어 시장이 무르익길 기다려야 한다.
최종 평가
기업 내부에 맞춤형 애플리케이션이 공존할 경우 외부에서의 서비스를 도입한다는 것은 또 다른 통합 문제를 야기할 수 있다. 하지만 내부 ESB를 보완할 수 있다는 점에서 엑스트라넷 통합 분야에서의 잠재력이 매우 높은 편이다. 또한 SaaS를 이미 도입한 기업에게는 충분한 경쟁력이 있다.
SOA 형태로 애플리케이션을 전환하는 것이 목표인 벤더는 마이크로소프트만이 아니다. 자바 관련 업계 역시 BEA와 IBM, 오라클, 레드햇, 썬 등 벤더가 주도하는 표준인 SCA(Services Component Architecture)에서 이와 유사한 작업을 추진하고 있다.
SCA와 WCF는 직접적으로 호환되지는 않지만 WS 스택의 일부를 사용하기 때문에 웹 서비스를 위해 애플리케이션이 개발될 수 있다. 또한 데이터 계층에서도 호환되지 않는다. SCA는 일부 벤더들이 범용 데이터 통합의 확장을 위해 도입한 프레임워크인 서비스 데이터 오브젝트(Service Data Objects)를 사용한다. 하지만 마이크로소프트는 이러한 벤더에 속하지 않는다. 유사한 이름을 가진 서버 데이터 오브젝트(Server Data Objects)는 윈도우 서버를 위한 원격 접속 API이다.
또한 마이크로소프트는 자사의 어댑터를 BPM이나 ESB에 포함시키지 않고 개별적으로 판매할 방침이다. 표준형 웹 서비스를 통해 레거시 시스템에 액세스를 제공하기 때문에 SOA보다 훨씬 더 큰 시장 잠재력이 있기 때문. 마이크로소프트측은 모든 오피스 애플리케이션 역시 웹 서비스 형태로 전환할 것이라고 밝혔다.
◆ 미래의 모델링=대부분의 RIA(Rich Internet Application)은 에이잭스를 사용하고 있지만 마이크로소프트는 RIA가 결국에는 자사의 새로운 실버라이트(Silverlight) 플랫폼으로 전환하게 될 것이라고 주장한다.
액티브X나 윈도우 미디어 플레이어 등 이전의 클라이언트 기반의 마이크로소프트 기술과는 달리, 실버라이트는 교차 플랫폼(맥 지원)이 가능하며 브라우저도 넘나들 수 있다(파이어폭스나 오페라, 사파리와 연동).
RIA 개발자들이 더욱 풍부한 플랫폼을 목표로 하길 바라면서 브라우저를 주류에서 밀어내려는 의도가 명백하다. 하지만 에이잭스의 광범위한 호환성은 플래시와 같은 대안이 있음에도 공중 인터넷에서의 애플리케이션에 주요 플랫폼으로 인정받고 있다는 것을 의미한다.
인트라넷의 경우 표준화가 더딘 대표적인 분야로, 웹 기반의 애플리케이션은 표준형 기업 이미지만을 지원한다. 하지만 여기에서도 실버라이트는 플래시나 컬(Curl) 등과 경쟁하고 있다. 마이크로소프트는 실버라이트가 비주얼 스튜디오나 C#과 같이 브라우저와 웹 서버 구축용으로 개발자들에게 채택되기를 바라고 있다. 하지만 자바의 영향력이 만만치 않은 것이 사실이다.
장기적으로 볼 때, 마이크로소프트가 SOA 개발자들을 공략하고 있는 분야는 전통적인 프로그래밍 언어를 뛰어넘는다. 물론 전통적인 개발자들도 능가하는 것으로 모든 사용자들을 위한 개방형 애플리케이션 개발을 목표로 하고 있다. 지난 6월에 발표한 코드명 오슬로(Oslo)는 BPM 모델링을 채용한 것이다.
오슬로는 BPM 모델을 확장한 것으로, SOA 애플리케이션을 타깃으로 하고 있지만 향후 윈도우 서버나 데스크톱에서 구동하는 애플리케이션까지도 적용할 계획이다.
오슬로는 마이크로소프트의 SOA 전략에 탄력을 붙여줄 것으로 기대된다. 윈도우 서버에 부족한 SOA 레포지터리를 보완하며 비즈토크나 비주얼 스튜디오 등의 모델링과 공유 기능을 강화할 방침이다.
하지만 오슬로는 아직 완성 단계가 아니다. 베타 버전이 2008년에 공개될 예정이며 아직 최종 제품의 출시 일자도 확정되지 않았기 때문이다.
◆ '본능'적인 독점욕=마이크로소프트의 SOA 전략 중 가장 야심찬 부분은 비즈토크 서비스로, ISB 즉 인터넷 서비스 버스라 불린다. 마이크로소프트는 비즈토크 서비스가 진정한 표준 기반의 ESB이며 기업들이 내부에서 호스팅하고 있는 ESB와 동일간 기능을 수행할 수 있다고 주장한다. 오슬로와 마찬가지로 비즈토크 서비스 역시 아직 출시되지 않았지만 온라인(labs.biztalk .net)에서 테스트를 실행해볼 수 있다.
마이크로소프트는 ISB를 두 단계에 걸쳐 두 곳의 시장을 목표로 출시할 계획이다.
첫 번째 타깃은 애플리케이션을 비즈니스 파트너와 통합하거나 다른 써드 파티와 '간단하게' 통합시켜야 하는 기업들을 대상으로 하고 있다. 여러 네트워크에 연결된 다양한 웹 서비스를 처리하는 대신에 마이크로소프트라는 한 벤더만 연결함으로써 해결된다는 이론이다.
물론, 이것은 모든 조직들이 마이크로소프트의 고객일 경우에만 효과가 있다. 마이크로소프트는 궁극적으로 자사가 기업간의 웹 서비스를 위한 '허브'가 되길 원하고 있다. 중단없는 통합을 위해서는 모든 이해당사자간의 ID 서비스를 호스트해야 한다. 이를 위한 버전도 역시 테스트 중인 것으로 알려졌다.
마이크로소프트는 두 번째 단계를 ESB 시장 확대로 언급하면서 ESB의 도입 여력이 없는 기업들에게 SOA와 BPM을 개방하겠다고 밝혔다. 이는 SaaS 업체들의 전략과 유사한 것이다.
이 두 번째 단계는 SaaS 벤더뿐만 아니라 전통적인 SOA와 애플리케이션 플랫폼 벤더들도 대거 참여하고 있는 '격전지'가 되고 있다. ESB가 점차 보편화 추세에 접어들고 오픈 소스 버전이 레드햇이나 뮬소스(MuleSource), 썬 후원의 OpenESB으로부터 이용 가능해짐에 따라 마이크로소프트에게 한층 힘겨운 상황이 되고 있다. SOA를 서비스 형태로 판매하는데 있어 가장 큰 경쟁자는 세일즈포스닷컴이 될 수도 있다.
SaaS 제공 업체로 거듭나기 위한 시도로, 마이크로소프트는 기업들이 자사 서버에서 설치할 수 있도록 비즈토크를 서비스 형태로 모두 제공하게 될 것이다.
이러한 소프트웨어 서비스 개념은 마이크로소프트에게 확실히 이점을 안겨줄 것이다. 매출원을 다양화할 수 있는데다 데스크톱 소프트웨어에서의 지배적인 위치를 살려 서비스 분야에도 진출할 수 있기 때문이다.
하지만 고객들에게도 좋을지는 확실치 않다. SaaS의 대표적인 특징은 소프트웨어를 '로컬'에 설치하지 않는다는 것이다. 거의 모두가 윈도우와 오피스를 데스크톱에 이미 설치한 반면, 윈도우 서버 제품을 서비스 형태로 전환하는데 있어 이점이 무엇인지 사용자들이 인식하지 못하게 될 수도 있다.
InformationWeek USA
webmaster@itdaily.kr