WCF - ASMX, WSE와 상호운영성 : ASMX, WSE, 닷넷 리모팅 상호 비교
WCF - ASMX, WSE와 상호운영성
ASMX, WSE, 닷넷 리모팅 상호 비교
지난 호에서 WCF에 대한 프로그래밍 모델을 살펴보았다. 이번 호에서는 WCF의 기본적인 프로그래밍 모델을 기술하고 WCF 서비스를 구현하는 방법을 알아보고자 한다. 이어서 WCF 서비스를 호출하기 위한 클라이언트 구현 방법을 설명할 생각이다. 지난 호에서 소개된 WCF 서비스와 클라이언트를 구현하는 방법을 이해했다면, 다음은 왜 WCF를 써야 하는가라는 의문을 가진 독자들도 있을 것이다. 그럼 원격 메소드 호출 방법인 ASP.NET 웹 서비스(ASMX), WSE(Web Service Extension), 닷넷 리모팅 등과 WCF가 어떻게 다른지 살펴보자.
Web Service World
WCF는 마이크로소프트가 밀고 있는 서비스 기반 아키텍처(SOA; Service Oriented Architecture)를 위해 태어났다. 따라서 WCF는 웹 서비스의 다양한 기능을 제공하는 것에 그 초점이 맞추어져 있다고 봐도 과언이 아니다.
그럼 웹 서비스의 다양한 기능이라면 무엇을 말하는가? 대부분의 독자들이 알고 있는 웹 서비스는 SOAP 프로토콜을 구현하는 기본적인 XML 웹 서비스 호출일 것이다. 하지만 SOAP 프로토콜만으로는 실 세계에서 요구하는 다양한 요구사항을 만족시켜줄 수 없었다. 간단한 예를 들어, 웹 서비스의 메시지를 암호화 하고자 한다면 어떻게 해야하는가? 무작정 웹 서비스 메시지를 암호화 하고 복호화 할 수도 있겠지만 웹 서비스란 것이 상호 운영성(interoperability)를 위해 태어난 것을 감안하면, 임의의 웹 서비스를 호출하기 위해 클라이언트와 서비스가 동일한 방식의 암호화/복호화 방법을 사용하지 않으면 안 될 것이다.
또한 SOAP 프로토콜 만을 사용하면 파일 전송과 같이 대용량의 바이너리 데이터를 전송하기에는 XML은 턱없이 비효율적이다. 암호화나 바이너리 데이터 전송 외에도 메시지가 목적지에 도착하는 것을 장담(grantee of message delivery) 해주는 신뢰도 높은(Reliable) 메시징, 트랜잭션 처리 등이 필요하게 되었다.
이렇게 웹 서비스의 메시징, 보안, 신뢰도, 트랜잭션 등의 요구 사항을 만족시켜주기 위해 마이크로소프트, IBM, BEA 등은 웹 서비스에 SOAP 프로토콜 기반의 새로운 웹서비스 스펙을 만들기 시작했다. 웹 서비스는 XML 기반이며 이 XML을 이용하여 메시지를 전송하는데 이 때 메시징(Messaging) 스펙들이 필요하고 이 메시징 스펙 상에서 보안(Security), 신뢰도 높은 메시징(Reliable Messaging), 그리고 트랜잭션(Transactions) 스펙이 정의되어 있다.
마지막으로 웹 서비스가 어떤 계약(contract; 계약 보다는 인터페이스란 용어가 더 이해하는데 도움이 될 것같다), 바인딩 등으로 구성되어 있는지를 기술하는 메타데이터(Metadata)와 관련된 스펙들 역시 필요하다. <그림 1>은 웹 서비스에 관련된 다양한 스펙들의 카테고리를 보여주고 있다.
<그림 1> 웹 서비스 스펙들이 다루는 영역
이들 스펙들에 대해 좀더 자세하게 살펴보면, 웹 서비스의 메시징과 관련된 스펙들은 SOAP 프로토콜 1.1 및 1.2버전 스펙과 웹 서비스 메시지를 보내고 받는 종점(endpoint)을 명시하기 위한 WS-Addressing 스펙, 웹 서비스를 통해 효율적으로 XML 메시지를 인코딩 하여 바이너리 데이터 등을 전송하기 위한 스펙인 MTOM(Message Transmission Optimization Mechanism) 등이 존재한다.
보안과 관련된 웹 서비스 스펙으로는 XML 메시지를 암호화/복호화 하거나 서명하는데 사용되는 WS-Security, WS-Security 상에서 인증 토큰을 발급하여 상호를 신뢰하는 방식을 정의하는 WS-Trust 스펙, 그리고 서로 다른 다양한 인증 시스템 상에서 인증이 가능하도록 하는 WSFederation 등이 존재한다.
웹 서비스 메시지의 신뢰성(Reliability)에 관여되는 스펙들로는 웹 서비스 메시지가 목적지 종점까지 도착하는 것을 장담하도록 클라이언트와 서비스가 주고 받는 ACK(acknowledge) 메시지 등을 정의하는 WSReliableMessaging 스펙 등이 정의되어 있다. 트랜잭션 관련 스펙으로는 WS-AtomicTransaction 이 있으며 웹서비스의 메타데이터를 기술하는 스펙으로 익히 잘 알고 있는 WSDL 과 다른 웹 서비스 스펙이 서비스에 대한 보다 상세한 설명을 하기 위해 사용되는 WS-Policy 등의 스펙을 가지고 있다.
이들 웹 서비스들에 대한 다양한 스펙명이 몇몇을 제외하고 모두 WS- 로 시작하기 때문에 와일드 카드를 의미하는 문자, *을 사용하여 WS-* 로 표기하기도 한다.
Legacy Remote Call Technology
WCF가 추구하는 서비스 지향 아키텍처에서 핵심적으로 사용되는 웹 서비스의 다양한 프로토콜, 스펙 등을 알아 보았으니 이들과 관련된 닷넷 기술들을 살펴보도록 하자. 현존하는 닷넷의 웹 서비스 기술들을 이해하고 이들의 한계를 살펴봄으로써 WCF가 왜 등장하게 되었는지를 이해 할 수 있기 때문이다. 웹 서비스 기술 외에도 가장 많이 사용되는 MSMQ, EnterpriseServices 등 원격 호출 기술을 살펴보고 이들이 어떤 문제를 가지고 있는지 알아보자. 두 말할 필요도 없이 이들 문제를 해결하는 것이 WCF의 설계 목적이기 때문이다.
ASP.NET Web Service
흔히 닷넷에서 웹 서비스라 하면 ASP.NET이 제공하는 웹 서비스 인프라를 말한다. ASP.NET에서 웹 서비스를 제공하는 파일의 확장자가 .asmx이며 흔히들 닷넷의 웹 서비스를 ASMX라 부르기 때문에 편의상 여기에서도 ASP.NET 기반의 XML 웹 서비스를 ASMX라 부르기로 하겠다.
ASMX가 제공하는 웹 서비스는 상당히 기본적인 것만을 제공하고 있다. ASMX가 제공하는 웹 서비스는 SOAP 1.1 과 1.2 그리고 WSDL이 전부이다. <그림 1>을 살펴보면 XML과 메시징의 일부 그리고 메타데이터의 일부만을 구현하고 있는 것을 알 수가 있다. 좀 다른 각도로 얘기하면, ASMX는 WS-I라 불리는 상호운영성(interoperability) 프로파일(profile)만을 만족시키고 있다.
WS-I는 SOAP 프로토콜(1.1 및 1.2) 그리고 WSDL 1.1에 대해 웹 서비스의 상호운영성을 보다 높게 하기 위한 일련의 규칙들을 정의하고 있다. WS-I가 등장하게 된 이유는 SOAP 프로토콜과 WSDL 스펙을 구현하는 다양한 제품들이 스펙을 만족하고 있음에도 조금씩 그 구현을 다르게 함으로써 상호운영성이 떨어지는 것을 보완하기 위해 등장한 규칙이다.
ASMX가 WS-I를 만족한다는 얘기는 웹 서비스의 다양한 스펙 중 아주 기본적인 SOAP 프로토콜과 WSDL을 만족하고 있음을 의미한다. Visual Studio 2005에서 웹 서비스를 프로젝트에 추가하면 웹 서비스 클래스 코드에 등장하는 WebServiceBinding 특성(attribute)에도 잘 나타나있다.
이를 좀더 요약하자면 우리가 가장 많이 사용하는 웹 서비스 기술로서 ASMX는 달랑 SOAP과 WSDL로 표현되는 WS-I를 만족하는 것일 뿐이다. 또 ASMX 만으로는 효율적인 바이너리 데이터 전송, 메시지 수준의 보안, 신뢰도 높은 메시지 전송, 분산 트랜잭션들을 구현하기 매우 어렵다. 마이크로소프트의 한 자료에 의하면 ASMX만을 사용하여 보안, 신뢰도 높은 메시지 전송, 트랜잭션, 그것도 완벽하지 않은 상태로 구현하는데 5만 라인이 넘는 코드가 필요하다고 한다.
ASMX의 또 다른 아픔은 ASP.NET 기반이라는 점이다. IIS와 ASP.NET 엔진 없이는 서비스를 구현할 수가 없다. 이는 P2P 와 비슷하게 80 포트를 이용하여 데스크탑 애플리케이션끼리 웹 서비스로 서로 호출하는 프로그램을 작성하고자 할 때 ASMX를 사용할 수 없다.
ASMX가 ASP.NET에 의존하고 있고 ASP.NET은 IIS와 같은 웹 서버를 요구하기 때문이다. 이 때문에 웹 서비스가 클라이언트에게 무엇인가를 알려주기 위해 클라이언트를 호출하는 콜백(Callback) 메커니즘은 ASMX에서 상상하기 쉽지 않은 기법이 되어 버리기도 한다.
WSE; Web Service Extension
WSE(Web Service Extension)은 ASMX가 제공하는 웹 서비스의 기본에 추가적으로 메시징과 보안에 대한 웹 서비스 스펙들을 구현해 놓은 일종의 애드인(add-in)이 되겠다. 현재 닷넷 프레임워크 2.0에 대한 WSE 버전은 3.0이다. WSE 3.0은 무료로 다운로드 받을 수 있으며 Visual Studio 2005에 통합되어 손쉽게 사용할 수 있도록 되어 있다.
WSE가 구현하는 웹 서비스 스펙은 메시징에 관련하여 WS-Addressing, MTOM 스펙이며 보안에 관련하여 WS-Security, WS-Trust 등을 구현하고 있다. 신뢰도 높은 메시징과 트랜잭션에 대한 지원은 WSE에 포함되어 있지 않다.
WSE를 사용할 때 가질 수 있는 부담감은 이것의 근본이 애드인이기 때문에 WSE 런타임을 클라이언트와 서버에 모두 설치해 주어야 한다는 점이다. 또한 WSE 2.0에서는 성능이 떨어진다는 한계마저 가지고 있으니 메시지 수준의 보안이 큰 문제가 되지 않는 인트라넷에서는 WSE가 외면당하고 있는 현실이 수긍이 갈 것이다.
Other Remote Call Technology in .NET
닷넷이 상대적으로 진보된 웹 서비스 개발환경을 갖추고 있고 웹 서비스가 기술 흐름의 대세라고 하더라도 닷넷은 다양한 원격 호출 메커니즘을 가지고 있다. 닷넷 리모팅, 메시지 큐, EnterpriseService 등으로 대표되는 DCOM 관련 지원이 그것이다. 이들에 대해 간략하게 살펴보자.
- .NET Remoting
닷넷 리모팅은 초창기 DCOM을 대신할 것으로 각광을 받았던 닷넷 고유의 원격 객체 호출 기술이었다. 바이너리 포매터(binary formatter)와 TCP 채널(channel)이 성능이라는 관점에서는 ASMX의 추종을 불허할 정도의 장점을 가졌기 때문이다. 또 한가지 닷넷 리모팅은 ASMX와 달리 웹 서버(그것이 IIS 이건 아니건)를 요구하지 않는다. 자체적으로 닷넷 리모팅 메시지를 수신할 수 있는 리스너(listener)를 구현하고 있기 때문이다. 이 때문에 데스크톱 애플리케이션이나 Windows 서비스 애플리케이션이 닷넷 리모팅의 서버로서 구현 가능한 강점을 가지고 있다.
닷넷 리모팅의 최대의 단점은 상호운영성이다. 닷넷 리모팅이 사용되면 서비스(서버)와 클라이언트는 모두 닷넷으로 구현되어야만 한다. 비록 SOAP 포매터와 HTTP 채널이 존재하기도 하지만 닷넷이 아닌 상대와 메시지를 주고 받기 위해서는 큰 제약이 따를 뿐 더러 ASMX에 비해 성능상의 장점이 거의 없다고 볼 수 있다. XML과 상호운영성이 크게 강조되고 있는 현실과 SOA를 생각해 보면, 다양한 플랫폼을 보유한 대부분의 기업에서 선뜻 닷넷 리모팅을 인프라로 선택하기가 만만치 않다는 것을 이해할 수 있을 것이다.
성능을 위해 바이너리 포매터과 TCP 채널을 선택했을때 닷넷 리모팅의 또 다른 단점은 클라이언트를 위한 프록시 코드 생성이 자동화 되어 있지 않다는 점이다. 이 때문에 서비스를 구현하는 어셈블리(DLL)를 클라이언트에 배포하거나 서비스를 감싸는(wrapping) 껍데기 클래스를 작성하고 이것을 배포해야만 한다. 이는 곧 생산성 저하와 연결되곤 한다.
- Message Queue (MSMQ)
메시지 큐란 말 보다 MSMQ란 이름이 훨씬 더 친숙한 이 메시징 인프라는 Windows NT 시절부터 제공되었다. 다양한 용도로 여러 애플리케이션에서 활용되어 왔다. MSMQ는 닷넷 이전부터 제공되어 온 인프라이기 때문에 닷넷 프레임워크에서도 System.Messaging 네임스페이스를 통해 MSMQ API를 제공해 왔다.
MSMQ를 사용하는 가장 큰 이유는 비동기(asynchronous)적으로 메시지를 목적지까지 배달(delivery)할 수 있다는 점이다. 즉 MSMQ는 신뢰도 높은 메시지 전달 기능을 제공한다. 네트워크가 오프라인이거나 메시지가 목적지까지 전달되는 중간에 유실되더라도 재전송(retransmit)과 ACK(acknowledge) 기법을 통해 비동기적으로 메시지의 전송을 보장해 준다. 또한 MSMQ는 트랜잭션을 지원하기 때문에 다양한 트랜잭션 애플리케이션들과도 잘 융합되어 작동한다는 장점도 있다. 마지막으로 MSMQ는 자체 수준의 메시지를 암호화하는 보안 기능을 제공하기도 한다.
MSMQ의 단점은 이것이 설계되고 개발된 시점에서 인터넷 표준을 거의 만족시키지 못한다는 사실이다. 사용하는 프로토콜도 MS-RPC(Microsoft Remote Procedure Call) 기반이므로 방화벽 통과가 어렵고, 메시지 포맷 역시 바이너리일 뿐 더러 인터넷 표준이 아니기 때문에 메시지를 보내는 쪽도 받는 쪽도 모두 Windows 운영체제를 요구한다는 점이다.
비록 HTTP를 통해 MSMQ 메시지를 전송할 수는 있지만 여전히 이기종 간 상호운영성은 크게 떨어진다. 굳이 <그림 1>과 비교해 설명하자면 신뢰도 높은 메시징과 트랜잭션 정도이며, XML, 메시징, 메타데이터는 MSMQ에 의해 커버되지 않는 영역이 된다.
- EnterpriseServices (DCOM)
닷넷에서 EnterpriseServices라 함은 COM+에 관련된 다양한 기능을 말한다. COM+ 컴포넌트를 작성할 때 ApplicationActivation 특성(attribute)에 서버 타입으로 ActivationOption.Server로 주면 원격 컴퓨터에 존재하는 COM+ 컴포넌트를 호출할 수 있다. 이 때 사용되는 원격 호출 기술이 바로 DCOM 이다.
DCOM은 MS-RPC 기술의 일종이다. 메시지 수준의 보안과 트랜잭션을 지원하면 MSMQ와 함께 사용될 때는 신뢰도 높은 메시징까지 지원할 수 있을 뿐 더러 타입 라이브러리를 통해 어느 정도 메타 데이터를 제공할 수도 있다. VB 6.0과 C++와 같이 unmanaged 코드를 사용하면 성능 역시 상당히 좋은 편이여서 닷넷이 등장하기 전까지 Windows 동네에서는 원격 객체 호출의 표준이었다. 지금도 여전히 운영체제 관리와 WMI 등에서 널리 사용되고 있다.
DCOM은 다른 원격 호출에 비해 <그림 1>에서 봤듯이 많은 영역을 커버하고 있음은 분명하다. 하지만 DCOM의 상호운영성이 크게 떨어진다는 점이 DCOM의 최대 단점이다. DCOM이 방화벽을 통과하기란 낙타가 바늘구멍 빠져나가는 것만큼이나 어렵고 W3C의 표준이라곤 단 하나도 준수하지 않는 오로지 마이크로소프트 만의 기술이기 때문이다. 사실 마이크로소프트가 주도하고 강력하게 밀어붙인 한 웹 서비스(SOAP 프로토콜)가 DCOM, CORBA, 자바의 RMI의 상호운영성 한계 때문임을 고려해 봤을 때 DCOM의 낮은 상호운영성이 얼마나 마이너스적인 요소인지 이해가 될 것이다.
DCOM의 또 다른 단점은 닷넷과의 부조화이다. DCOM이 unmanaged 기술이며 COM에 기반하고 있기 때문에 닷넷에서 DCOM 프로토콜이 사용되면 CCW (Com Callerable Wrapper)와 RCW(Runtime Callerable Wrapper)가 관여될뿐더러 managed 코드와 unmanaged 코드 사이에서 전이가 자주 발생하여 성능상 손해가 상당하다는 점이다. 이 때문에 닷넷으로 COM+를 구현할 때 서버 타입보다는 라이브러리 타입을 사용하는 이유가 서버 타입을 사용하면 어쩔 수 없이 DCOM이 관여되고 이 때문에 성능 저하와 시스템 불안정이 뒤따르기 때문이다.
WCF의 당위성
지금까지 웹 서비스의 다양한 표준들과 닷넷에서 사용 가능한 다양한 원격 호출 기술들을 살펴보았다. 각 기술들의 장점과 단점을 간략하게 언급하였으므로 왜 마이크로소프트가 차세대 메시징(원격 호출) 인프라로서 WCF를 내놓았는지 조금이나마 감을 잡았으리라 생각된다. 이제부터 좀더 구체적으로 살펴 보자.
- 표준 기반의 상호운영성
상대적으로 오래된 기술인 MSMQ나 DCOM은 다양한 기종의 플랫폼상에서는 작동하지 않는다는 상호운영성 문제를 가지고 있다. 마이크로소프트는 수년 전부터 자사의 제품, 기술들이 갖는 상호운영성 문제를 해결하기 위해 적극적으로 인터넷 표준들을 준수하거나 새로운 인터넷 표준을 제안해 왔다. XML 만을 보더라도 그렇다. 마이크로소프트는 더 이상 바이너리 형태로 데이터를 주고 받는 애플리케이션을 내놓지 않는다. 앞으로 등장할 Office 2007의 문서들은 XML 기반의 문서이며 SQL Server는 SQL Server 2000 버전부터 꾸준히 XML에 대한 지원을 늘려오고 있다.
따라서 WCF는 철저히 XML 기반의 메시징 인프라이다. NetTcpBinding 을 사용하고, TCP 프로토콜을 사용하여 원격 호출을 하더라도 주고 받는 메시지는 XML 이다. 비록 NetTcpBinding이 메시지를 바이너리로 인코딩/디코딩 하는 한이 있더라도 메시지 자체는 XML로 되어있다. 이것이 닷넷 리모팅, MSMQ, DCOM과 WCF가 다른 점이라 할 수 있다. XML로 메시지가 구성되어 있고, 대부분의 플랫폼이 텍스트 기반의 XML을 처리할 수 있기 때문에 상호운영성은 증대되는 것이다.
또한 WCF는 WS-* 로 대표되는 웹 서비스 스펙들을 대다수 준수하고 있다. 메시징을 위해 SOAP, WS-Addressing, MTOM을 구현하며, 메시지 보안을 위해 WSSecurity, WS-Trust, WS-Federation 등의 스펙을 구현하고 있다.
WCF가 이렇게 다양한 웹 서비스에 대한 국제적 표준을 준수함에 따라 이들 표준을 준수하는 어떤 플랫폼과도 상호 연동이 가능한 메시징 인프라가 될 수 있는 것이다.
- 프로그래밍 모델의 통합
WCF가 상호운영성과 더불어 강조하는 것은 ASMX, WSE, 닷넷 리모팅, MSMQ, DCOM 등 분산 애플리케이션에서 사용하는 다양한 원격 호출 기술을 WCF라는 하나의 프로그래밍 모델로 통합하고자 한다는 점이다. 이에 대해서는 구체적인 예를 들어 설명하는 것이 보다 이해가 빠를 것이다.
상당수 기업들은 신규 애플리케이션을 닷넷 플랫폼으로 개발하고자 한다. 이 애플리케이션의 요구 사항 중 하나는 기존에 존재하는 ASP 웹 애플리케이션과 자바 애플리케이션과 상호 연동이다. 상호운영성을 고려한다면 애플리케이션의 클라이언트와 서버는 웹 서비스를 원격 호출 메커니즘으로 선택하는 것이 지극히 당연하다.
따라서 개발 생산성과 운영의 편리함 등등을 고려하여 이 애플리케이션의 서버는 IIS 상에 호스팅 되는 ASMX 기반으로 비즈니스 로직을 구현하고 데이터베이스를 액세스하는 구조를 가지게 될 것이다. 비즈니스 로직을 COM+ 기반의 컴포넌트로 구현하더라도 클라이언트 호출을 위해 .asmx와 관련된 클래스를 구현해야 함은 물론이다.
만약 이 애플리케이션의 또 다른 요구 사항 중 하나가 다수의 사용자에 대해서도 빠른 응답 속도를 요구하는 고성능 애플리케이션이라면 어떻겠는가? 서버의 하드웨어 사양이나 데이터베이스 설계 등 고려할 사항이 많을 수 있겠지만 원격 호출 메커니즘의 성능적인 요소도 무시할 수 없다. 오로지 성능만을 고려한다면 닷넷은 닷넷 리모팅, 특히 바이너리 포매터와 TCP 채널을 사용하는 원격 호출 방식을 취해야 한다.
그런데 정작 문제는 ASMX와 닷넷 리모팅의 프로그래밍 모델에서 공통점이 거의 없다는 점이다. 전형적인 ASMX 프로그래밍 모델은 .asmx 파일과 이를 위한 웹 서비스 구현 클래스(WebService 클래스에서 파생된)이지만 닷넷 리모팅은 MarshalByRefObject 에서 파생된 클래스와 이를 위한 설정(configuration)이다. 클라이언트를 구현하는 코드 역시 유사성이 거의 없다. ASMX의 경우 프록시를 생성하고 이 프록시를 호출하는 형태이지만 닷넷 리모팅은 원격으로 호출하고자 하는 클래스의 타입 정보를 반드시 필요하다.
이 뿐인가? 애플리케이션이 신뢰도 낮은 WAN 상에서도 구동하도록 하려면, 메시지가 네트워크 어디에서인가 유실되더라도 재전송 등을 통해 메시지 전달을 보장하는 MSMQ를 써야 할 것이다. MSMQ의 프로그래밍 모델은 ASMX와 닷넷 리모팅과 더욱 더 차이가 난다. ASMX와 닷넷 리모팅은 메소드 호출이 자동적으로 메시지 형태로 변환되지만 MSMQ는 메시지 자체를 만들어야 한다. 더욱더 가관인 것이, MSMQ는 메시지 큐를 리스닝 하는 리스너 코드도 작성해야 한다.
상황이 이러하기 때문에 지금까지는 서버의 비즈니스로직은 완전히 분리하여 컴포넌트로 구현하고(그것이 COM+ 기반이건 아니건 관계 없이) 이 컴포넌트를 다양한 원격 호출 기술 기반의 퍼사드(fa?ade)로 감싸는 것이 일반적인 방법이 되어 왔다. 보다 구체적으로 예를 들어 보자. 주문 관리 서비스를 위해 주문 관리 비즈니스 로직을 COM+ 기반의 컴포넌트로 구현한다. 그리고 ASP나 자바 클라이언트를 위해 컴포넌트의 인터페이스를 ASMX 혹은 ASMX + WSE로 구현한다. 물론 이 구현은 COM+로 작성해 놓은 주문 관리 비즈니스 로직 컴포넌트를 호출할 것이다.
이젠 인트라넷의 클라이언트를 위해 높은 성능을 내는 닷넷 리모팅 래퍼 클래스를 작성한다. 이 클래스는 MarshalByRefObject 에서 파생된 클래스로서 단순히 클라이언트 호출을 COM+ 컴포넌트로 전달하는 역할만을 한다. 닷넷 리모팅 클라이언트가 직접 COM+ 컴포넌트를 호출할 수는 없다. 클라이언트가 COM+ 컴포넌트를 직접 호출하려면 이 컴포넌트 클래스를‘참조’해야 하는데 이를 위해서는 COM+ 컴포넌트를 구현하는 클래스를 클라이언트에 배포해야 하기 때문이다.
<그림 2>다양한 클라이언트를 위한 다양한 인터페이스 구현
<그림 2>는 다양한 요구사항에 따른 여러 원격 호출 기술을 사용하여 다양한 클라이언트를 서비스하는 모습을 보여주고 있다. <그림 2>는 다양한 클라이언트를 모두 지원하는 잘 구성된 아키텍처처럼 보인다. 그렇다. 마이크로소프트의 Pattern & Practice 역시 이러한 아키텍처를 사용하길 권장할 정도로 이 모습에는 문제가 없어 보인다. 하지만 <그림 2>는 상호운영성을 높이고 다양한 클라이언트를 위해 ASMX 혹은 ASMX + WSE를 구현하는 웹 서비스 인터페이스를“구현”해야 하며, 성능을 위해서는 닷넷 리모팅 인터페이스를“구현”해야 한다.
개발자의 관점에서 <그림 2>는 상당히 고통스럽다. ASMX 및 WSE 웹 서비스에 대한 기술과 프로그래밍 모델, API 등을 알아야 하며 닷넷 리모팅도 잘아야 할 뿐더러 들어보지도 못한 MSMQ에 대한 코딩 능력까지 갖추어야만 한다. 누군들 한숨이 나올 법하지 않은가?
<그림 3> WCF의 서비스와 종점(Endpoint)
<그림 4> WCF와 다양한 바인딩
이처럼 WCF는 다양한 기술들을 통합하는 프로그래밍 모델을 제시한다. 지난 10월호에 게재한 그림을 다시 떠올려보자(그림 3 참조). WCF 서비스는 서비스를 정의하는 인터페이스와 이 인터페이스를 구현하는 서비스 클래스로서 구현한다. 그리고 이 서비스에 접근하기 위한 종점(endpoint)은 다양하게 정의될 수 있다. 종점은 다시 주소와 계약(contract), 바인딩으로 구성된다는 것 역시 이미 알고 있을 것이다. 계약이야 서비스의 인터페이스가 될 것 이므로 논외로 하고, 바인딩과 주소에 주목해 보자. 바인딩은 웹 서비스를 호출할 때 사용할“방법”을 정의하고 있다. 즉, 바인딩은 HTTP를 사용할 것인지 TCP를 사용할 것인지 혹은 MSMQ를 사용할 것인지 트랜스포트(transport)를 결정할 뿐 만 아니라 XML 메시지에 대한 보안을 어느 수준에서 수행할 것인지, 세션이나 신뢰성을 유지할 것인지 등 어떤 바인딩을 사용하는가에 따라서 달라진다.
출처 : 마이크로소프트웨어 2006년 11월호
ASMX, WSE, 닷넷 리모팅 상호 비교
지난 호에서 WCF에 대한 프로그래밍 모델을 살펴보았다. 이번 호에서는 WCF의 기본적인 프로그래밍 모델을 기술하고 WCF 서비스를 구현하는 방법을 알아보고자 한다. 이어서 WCF 서비스를 호출하기 위한 클라이언트 구현 방법을 설명할 생각이다. 지난 호에서 소개된 WCF 서비스와 클라이언트를 구현하는 방법을 이해했다면, 다음은 왜 WCF를 써야 하는가라는 의문을 가진 독자들도 있을 것이다. 그럼 원격 메소드 호출 방법인 ASP.NET 웹 서비스(ASMX), WSE(Web Service Extension), 닷넷 리모팅 등과 WCF가 어떻게 다른지 살펴보자.
Web Service World
WCF는 마이크로소프트가 밀고 있는 서비스 기반 아키텍처(SOA; Service Oriented Architecture)를 위해 태어났다. 따라서 WCF는 웹 서비스의 다양한 기능을 제공하는 것에 그 초점이 맞추어져 있다고 봐도 과언이 아니다.
그럼 웹 서비스의 다양한 기능이라면 무엇을 말하는가? 대부분의 독자들이 알고 있는 웹 서비스는 SOAP 프로토콜을 구현하는 기본적인 XML 웹 서비스 호출일 것이다. 하지만 SOAP 프로토콜만으로는 실 세계에서 요구하는 다양한 요구사항을 만족시켜줄 수 없었다. 간단한 예를 들어, 웹 서비스의 메시지를 암호화 하고자 한다면 어떻게 해야하는가? 무작정 웹 서비스 메시지를 암호화 하고 복호화 할 수도 있겠지만 웹 서비스란 것이 상호 운영성(interoperability)를 위해 태어난 것을 감안하면, 임의의 웹 서비스를 호출하기 위해 클라이언트와 서비스가 동일한 방식의 암호화/복호화 방법을 사용하지 않으면 안 될 것이다.
또한 SOAP 프로토콜 만을 사용하면 파일 전송과 같이 대용량의 바이너리 데이터를 전송하기에는 XML은 턱없이 비효율적이다. 암호화나 바이너리 데이터 전송 외에도 메시지가 목적지에 도착하는 것을 장담(grantee of message delivery) 해주는 신뢰도 높은(Reliable) 메시징, 트랜잭션 처리 등이 필요하게 되었다.
이렇게 웹 서비스의 메시징, 보안, 신뢰도, 트랜잭션 등의 요구 사항을 만족시켜주기 위해 마이크로소프트, IBM, BEA 등은 웹 서비스에 SOAP 프로토콜 기반의 새로운 웹서비스 스펙을 만들기 시작했다. 웹 서비스는 XML 기반이며 이 XML을 이용하여 메시지를 전송하는데 이 때 메시징(Messaging) 스펙들이 필요하고 이 메시징 스펙 상에서 보안(Security), 신뢰도 높은 메시징(Reliable Messaging), 그리고 트랜잭션(Transactions) 스펙이 정의되어 있다.
마지막으로 웹 서비스가 어떤 계약(contract; 계약 보다는 인터페이스란 용어가 더 이해하는데 도움이 될 것같다), 바인딩 등으로 구성되어 있는지를 기술하는 메타데이터(Metadata)와 관련된 스펙들 역시 필요하다. <그림 1>은 웹 서비스에 관련된 다양한 스펙들의 카테고리를 보여주고 있다.
<그림 1> 웹 서비스 스펙들이 다루는 영역
이들 스펙들에 대해 좀더 자세하게 살펴보면, 웹 서비스의 메시징과 관련된 스펙들은 SOAP 프로토콜 1.1 및 1.2버전 스펙과 웹 서비스 메시지를 보내고 받는 종점(endpoint)을 명시하기 위한 WS-Addressing 스펙, 웹 서비스를 통해 효율적으로 XML 메시지를 인코딩 하여 바이너리 데이터 등을 전송하기 위한 스펙인 MTOM(Message Transmission Optimization Mechanism) 등이 존재한다.
보안과 관련된 웹 서비스 스펙으로는 XML 메시지를 암호화/복호화 하거나 서명하는데 사용되는 WS-Security, WS-Security 상에서 인증 토큰을 발급하여 상호를 신뢰하는 방식을 정의하는 WS-Trust 스펙, 그리고 서로 다른 다양한 인증 시스템 상에서 인증이 가능하도록 하는 WSFederation 등이 존재한다.
웹 서비스 메시지의 신뢰성(Reliability)에 관여되는 스펙들로는 웹 서비스 메시지가 목적지 종점까지 도착하는 것을 장담하도록 클라이언트와 서비스가 주고 받는 ACK(acknowledge) 메시지 등을 정의하는 WSReliableMessaging 스펙 등이 정의되어 있다. 트랜잭션 관련 스펙으로는 WS-AtomicTransaction 이 있으며 웹서비스의 메타데이터를 기술하는 스펙으로 익히 잘 알고 있는 WSDL 과 다른 웹 서비스 스펙이 서비스에 대한 보다 상세한 설명을 하기 위해 사용되는 WS-Policy 등의 스펙을 가지고 있다.
이들 웹 서비스들에 대한 다양한 스펙명이 몇몇을 제외하고 모두 WS- 로 시작하기 때문에 와일드 카드를 의미하는 문자, *을 사용하여 WS-* 로 표기하기도 한다.
Legacy Remote Call Technology
WCF가 추구하는 서비스 지향 아키텍처에서 핵심적으로 사용되는 웹 서비스의 다양한 프로토콜, 스펙 등을 알아 보았으니 이들과 관련된 닷넷 기술들을 살펴보도록 하자. 현존하는 닷넷의 웹 서비스 기술들을 이해하고 이들의 한계를 살펴봄으로써 WCF가 왜 등장하게 되었는지를 이해 할 수 있기 때문이다. 웹 서비스 기술 외에도 가장 많이 사용되는 MSMQ, EnterpriseServices 등 원격 호출 기술을 살펴보고 이들이 어떤 문제를 가지고 있는지 알아보자. 두 말할 필요도 없이 이들 문제를 해결하는 것이 WCF의 설계 목적이기 때문이다.
ASP.NET Web Service
흔히 닷넷에서 웹 서비스라 하면 ASP.NET이 제공하는 웹 서비스 인프라를 말한다. ASP.NET에서 웹 서비스를 제공하는 파일의 확장자가 .asmx이며 흔히들 닷넷의 웹 서비스를 ASMX라 부르기 때문에 편의상 여기에서도 ASP.NET 기반의 XML 웹 서비스를 ASMX라 부르기로 하겠다.
ASMX가 제공하는 웹 서비스는 상당히 기본적인 것만을 제공하고 있다. ASMX가 제공하는 웹 서비스는 SOAP 1.1 과 1.2 그리고 WSDL이 전부이다. <그림 1>을 살펴보면 XML과 메시징의 일부 그리고 메타데이터의 일부만을 구현하고 있는 것을 알 수가 있다. 좀 다른 각도로 얘기하면, ASMX는 WS-I라 불리는 상호운영성(interoperability) 프로파일(profile)만을 만족시키고 있다.
WS-I는 SOAP 프로토콜(1.1 및 1.2) 그리고 WSDL 1.1에 대해 웹 서비스의 상호운영성을 보다 높게 하기 위한 일련의 규칙들을 정의하고 있다. WS-I가 등장하게 된 이유는 SOAP 프로토콜과 WSDL 스펙을 구현하는 다양한 제품들이 스펙을 만족하고 있음에도 조금씩 그 구현을 다르게 함으로써 상호운영성이 떨어지는 것을 보완하기 위해 등장한 규칙이다.
ASMX가 WS-I를 만족한다는 얘기는 웹 서비스의 다양한 스펙 중 아주 기본적인 SOAP 프로토콜과 WSDL을 만족하고 있음을 의미한다. Visual Studio 2005에서 웹 서비스를 프로젝트에 추가하면 웹 서비스 클래스 코드에 등장하는 WebServiceBinding 특성(attribute)에도 잘 나타나있다.
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
이를 좀더 요약하자면 우리가 가장 많이 사용하는 웹 서비스 기술로서 ASMX는 달랑 SOAP과 WSDL로 표현되는 WS-I를 만족하는 것일 뿐이다. 또 ASMX 만으로는 효율적인 바이너리 데이터 전송, 메시지 수준의 보안, 신뢰도 높은 메시지 전송, 분산 트랜잭션들을 구현하기 매우 어렵다. 마이크로소프트의 한 자료에 의하면 ASMX만을 사용하여 보안, 신뢰도 높은 메시지 전송, 트랜잭션, 그것도 완벽하지 않은 상태로 구현하는데 5만 라인이 넘는 코드가 필요하다고 한다.
ASMX의 또 다른 아픔은 ASP.NET 기반이라는 점이다. IIS와 ASP.NET 엔진 없이는 서비스를 구현할 수가 없다. 이는 P2P 와 비슷하게 80 포트를 이용하여 데스크탑 애플리케이션끼리 웹 서비스로 서로 호출하는 프로그램을 작성하고자 할 때 ASMX를 사용할 수 없다.
ASMX가 ASP.NET에 의존하고 있고 ASP.NET은 IIS와 같은 웹 서버를 요구하기 때문이다. 이 때문에 웹 서비스가 클라이언트에게 무엇인가를 알려주기 위해 클라이언트를 호출하는 콜백(Callback) 메커니즘은 ASMX에서 상상하기 쉽지 않은 기법이 되어 버리기도 한다.
WSE; Web Service Extension
WSE(Web Service Extension)은 ASMX가 제공하는 웹 서비스의 기본에 추가적으로 메시징과 보안에 대한 웹 서비스 스펙들을 구현해 놓은 일종의 애드인(add-in)이 되겠다. 현재 닷넷 프레임워크 2.0에 대한 WSE 버전은 3.0이다. WSE 3.0은 무료로 다운로드 받을 수 있으며 Visual Studio 2005에 통합되어 손쉽게 사용할 수 있도록 되어 있다.
WSE가 구현하는 웹 서비스 스펙은 메시징에 관련하여 WS-Addressing, MTOM 스펙이며 보안에 관련하여 WS-Security, WS-Trust 등을 구현하고 있다. 신뢰도 높은 메시징과 트랜잭션에 대한 지원은 WSE에 포함되어 있지 않다.
WSE를 사용할 때 가질 수 있는 부담감은 이것의 근본이 애드인이기 때문에 WSE 런타임을 클라이언트와 서버에 모두 설치해 주어야 한다는 점이다. 또한 WSE 2.0에서는 성능이 떨어진다는 한계마저 가지고 있으니 메시지 수준의 보안이 큰 문제가 되지 않는 인트라넷에서는 WSE가 외면당하고 있는 현실이 수긍이 갈 것이다.
Other Remote Call Technology in .NET
닷넷이 상대적으로 진보된 웹 서비스 개발환경을 갖추고 있고 웹 서비스가 기술 흐름의 대세라고 하더라도 닷넷은 다양한 원격 호출 메커니즘을 가지고 있다. 닷넷 리모팅, 메시지 큐, EnterpriseService 등으로 대표되는 DCOM 관련 지원이 그것이다. 이들에 대해 간략하게 살펴보자.
- .NET Remoting
닷넷 리모팅은 초창기 DCOM을 대신할 것으로 각광을 받았던 닷넷 고유의 원격 객체 호출 기술이었다. 바이너리 포매터(binary formatter)와 TCP 채널(channel)이 성능이라는 관점에서는 ASMX의 추종을 불허할 정도의 장점을 가졌기 때문이다. 또 한가지 닷넷 리모팅은 ASMX와 달리 웹 서버(그것이 IIS 이건 아니건)를 요구하지 않는다. 자체적으로 닷넷 리모팅 메시지를 수신할 수 있는 리스너(listener)를 구현하고 있기 때문이다. 이 때문에 데스크톱 애플리케이션이나 Windows 서비스 애플리케이션이 닷넷 리모팅의 서버로서 구현 가능한 강점을 가지고 있다.
닷넷 리모팅의 최대의 단점은 상호운영성이다. 닷넷 리모팅이 사용되면 서비스(서버)와 클라이언트는 모두 닷넷으로 구현되어야만 한다. 비록 SOAP 포매터와 HTTP 채널이 존재하기도 하지만 닷넷이 아닌 상대와 메시지를 주고 받기 위해서는 큰 제약이 따를 뿐 더러 ASMX에 비해 성능상의 장점이 거의 없다고 볼 수 있다. XML과 상호운영성이 크게 강조되고 있는 현실과 SOA를 생각해 보면, 다양한 플랫폼을 보유한 대부분의 기업에서 선뜻 닷넷 리모팅을 인프라로 선택하기가 만만치 않다는 것을 이해할 수 있을 것이다.
성능을 위해 바이너리 포매터과 TCP 채널을 선택했을때 닷넷 리모팅의 또 다른 단점은 클라이언트를 위한 프록시 코드 생성이 자동화 되어 있지 않다는 점이다. 이 때문에 서비스를 구현하는 어셈블리(DLL)를 클라이언트에 배포하거나 서비스를 감싸는(wrapping) 껍데기 클래스를 작성하고 이것을 배포해야만 한다. 이는 곧 생산성 저하와 연결되곤 한다.
- Message Queue (MSMQ)
메시지 큐란 말 보다 MSMQ란 이름이 훨씬 더 친숙한 이 메시징 인프라는 Windows NT 시절부터 제공되었다. 다양한 용도로 여러 애플리케이션에서 활용되어 왔다. MSMQ는 닷넷 이전부터 제공되어 온 인프라이기 때문에 닷넷 프레임워크에서도 System.Messaging 네임스페이스를 통해 MSMQ API를 제공해 왔다.
MSMQ를 사용하는 가장 큰 이유는 비동기(asynchronous)적으로 메시지를 목적지까지 배달(delivery)할 수 있다는 점이다. 즉 MSMQ는 신뢰도 높은 메시지 전달 기능을 제공한다. 네트워크가 오프라인이거나 메시지가 목적지까지 전달되는 중간에 유실되더라도 재전송(retransmit)과 ACK(acknowledge) 기법을 통해 비동기적으로 메시지의 전송을 보장해 준다. 또한 MSMQ는 트랜잭션을 지원하기 때문에 다양한 트랜잭션 애플리케이션들과도 잘 융합되어 작동한다는 장점도 있다. 마지막으로 MSMQ는 자체 수준의 메시지를 암호화하는 보안 기능을 제공하기도 한다.
MSMQ의 단점은 이것이 설계되고 개발된 시점에서 인터넷 표준을 거의 만족시키지 못한다는 사실이다. 사용하는 프로토콜도 MS-RPC(Microsoft Remote Procedure Call) 기반이므로 방화벽 통과가 어렵고, 메시지 포맷 역시 바이너리일 뿐 더러 인터넷 표준이 아니기 때문에 메시지를 보내는 쪽도 받는 쪽도 모두 Windows 운영체제를 요구한다는 점이다.
비록 HTTP를 통해 MSMQ 메시지를 전송할 수는 있지만 여전히 이기종 간 상호운영성은 크게 떨어진다. 굳이 <그림 1>과 비교해 설명하자면 신뢰도 높은 메시징과 트랜잭션 정도이며, XML, 메시징, 메타데이터는 MSMQ에 의해 커버되지 않는 영역이 된다.
- EnterpriseServices (DCOM)
닷넷에서 EnterpriseServices라 함은 COM+에 관련된 다양한 기능을 말한다. COM+ 컴포넌트를 작성할 때 ApplicationActivation 특성(attribute)에 서버 타입으로 ActivationOption.Server로 주면 원격 컴퓨터에 존재하는 COM+ 컴포넌트를 호출할 수 있다. 이 때 사용되는 원격 호출 기술이 바로 DCOM 이다.
DCOM은 MS-RPC 기술의 일종이다. 메시지 수준의 보안과 트랜잭션을 지원하면 MSMQ와 함께 사용될 때는 신뢰도 높은 메시징까지 지원할 수 있을 뿐 더러 타입 라이브러리를 통해 어느 정도 메타 데이터를 제공할 수도 있다. VB 6.0과 C++와 같이 unmanaged 코드를 사용하면 성능 역시 상당히 좋은 편이여서 닷넷이 등장하기 전까지 Windows 동네에서는 원격 객체 호출의 표준이었다. 지금도 여전히 운영체제 관리와 WMI 등에서 널리 사용되고 있다.
DCOM은 다른 원격 호출에 비해 <그림 1>에서 봤듯이 많은 영역을 커버하고 있음은 분명하다. 하지만 DCOM의 상호운영성이 크게 떨어진다는 점이 DCOM의 최대 단점이다. DCOM이 방화벽을 통과하기란 낙타가 바늘구멍 빠져나가는 것만큼이나 어렵고 W3C의 표준이라곤 단 하나도 준수하지 않는 오로지 마이크로소프트 만의 기술이기 때문이다. 사실 마이크로소프트가 주도하고 강력하게 밀어붙인 한 웹 서비스(SOAP 프로토콜)가 DCOM, CORBA, 자바의 RMI의 상호운영성 한계 때문임을 고려해 봤을 때 DCOM의 낮은 상호운영성이 얼마나 마이너스적인 요소인지 이해가 될 것이다.
DCOM의 또 다른 단점은 닷넷과의 부조화이다. DCOM이 unmanaged 기술이며 COM에 기반하고 있기 때문에 닷넷에서 DCOM 프로토콜이 사용되면 CCW (Com Callerable Wrapper)와 RCW(Runtime Callerable Wrapper)가 관여될뿐더러 managed 코드와 unmanaged 코드 사이에서 전이가 자주 발생하여 성능상 손해가 상당하다는 점이다. 이 때문에 닷넷으로 COM+를 구현할 때 서버 타입보다는 라이브러리 타입을 사용하는 이유가 서버 타입을 사용하면 어쩔 수 없이 DCOM이 관여되고 이 때문에 성능 저하와 시스템 불안정이 뒤따르기 때문이다.
WCF의 당위성
지금까지 웹 서비스의 다양한 표준들과 닷넷에서 사용 가능한 다양한 원격 호출 기술들을 살펴보았다. 각 기술들의 장점과 단점을 간략하게 언급하였으므로 왜 마이크로소프트가 차세대 메시징(원격 호출) 인프라로서 WCF를 내놓았는지 조금이나마 감을 잡았으리라 생각된다. 이제부터 좀더 구체적으로 살펴 보자.
- 표준 기반의 상호운영성
상대적으로 오래된 기술인 MSMQ나 DCOM은 다양한 기종의 플랫폼상에서는 작동하지 않는다는 상호운영성 문제를 가지고 있다. 마이크로소프트는 수년 전부터 자사의 제품, 기술들이 갖는 상호운영성 문제를 해결하기 위해 적극적으로 인터넷 표준들을 준수하거나 새로운 인터넷 표준을 제안해 왔다. XML 만을 보더라도 그렇다. 마이크로소프트는 더 이상 바이너리 형태로 데이터를 주고 받는 애플리케이션을 내놓지 않는다. 앞으로 등장할 Office 2007의 문서들은 XML 기반의 문서이며 SQL Server는 SQL Server 2000 버전부터 꾸준히 XML에 대한 지원을 늘려오고 있다.
따라서 WCF는 철저히 XML 기반의 메시징 인프라이다. NetTcpBinding 을 사용하고, TCP 프로토콜을 사용하여 원격 호출을 하더라도 주고 받는 메시지는 XML 이다. 비록 NetTcpBinding이 메시지를 바이너리로 인코딩/디코딩 하는 한이 있더라도 메시지 자체는 XML로 되어있다. 이것이 닷넷 리모팅, MSMQ, DCOM과 WCF가 다른 점이라 할 수 있다. XML로 메시지가 구성되어 있고, 대부분의 플랫폼이 텍스트 기반의 XML을 처리할 수 있기 때문에 상호운영성은 증대되는 것이다.
또한 WCF는 WS-* 로 대표되는 웹 서비스 스펙들을 대다수 준수하고 있다. 메시징을 위해 SOAP, WS-Addressing, MTOM을 구현하며, 메시지 보안을 위해 WSSecurity, WS-Trust, WS-Federation 등의 스펙을 구현하고 있다.
WCF가 이렇게 다양한 웹 서비스에 대한 국제적 표준을 준수함에 따라 이들 표준을 준수하는 어떤 플랫폼과도 상호 연동이 가능한 메시징 인프라가 될 수 있는 것이다.
- 프로그래밍 모델의 통합
WCF가 상호운영성과 더불어 강조하는 것은 ASMX, WSE, 닷넷 리모팅, MSMQ, DCOM 등 분산 애플리케이션에서 사용하는 다양한 원격 호출 기술을 WCF라는 하나의 프로그래밍 모델로 통합하고자 한다는 점이다. 이에 대해서는 구체적인 예를 들어 설명하는 것이 보다 이해가 빠를 것이다.
상당수 기업들은 신규 애플리케이션을 닷넷 플랫폼으로 개발하고자 한다. 이 애플리케이션의 요구 사항 중 하나는 기존에 존재하는 ASP 웹 애플리케이션과 자바 애플리케이션과 상호 연동이다. 상호운영성을 고려한다면 애플리케이션의 클라이언트와 서버는 웹 서비스를 원격 호출 메커니즘으로 선택하는 것이 지극히 당연하다.
따라서 개발 생산성과 운영의 편리함 등등을 고려하여 이 애플리케이션의 서버는 IIS 상에 호스팅 되는 ASMX 기반으로 비즈니스 로직을 구현하고 데이터베이스를 액세스하는 구조를 가지게 될 것이다. 비즈니스 로직을 COM+ 기반의 컴포넌트로 구현하더라도 클라이언트 호출을 위해 .asmx와 관련된 클래스를 구현해야 함은 물론이다.
만약 이 애플리케이션의 또 다른 요구 사항 중 하나가 다수의 사용자에 대해서도 빠른 응답 속도를 요구하는 고성능 애플리케이션이라면 어떻겠는가? 서버의 하드웨어 사양이나 데이터베이스 설계 등 고려할 사항이 많을 수 있겠지만 원격 호출 메커니즘의 성능적인 요소도 무시할 수 없다. 오로지 성능만을 고려한다면 닷넷은 닷넷 리모팅, 특히 바이너리 포매터와 TCP 채널을 사용하는 원격 호출 방식을 취해야 한다.
그런데 정작 문제는 ASMX와 닷넷 리모팅의 프로그래밍 모델에서 공통점이 거의 없다는 점이다. 전형적인 ASMX 프로그래밍 모델은 .asmx 파일과 이를 위한 웹 서비스 구현 클래스(WebService 클래스에서 파생된)이지만 닷넷 리모팅은 MarshalByRefObject 에서 파생된 클래스와 이를 위한 설정(configuration)이다. 클라이언트를 구현하는 코드 역시 유사성이 거의 없다. ASMX의 경우 프록시를 생성하고 이 프록시를 호출하는 형태이지만 닷넷 리모팅은 원격으로 호출하고자 하는 클래스의 타입 정보를 반드시 필요하다.
이 뿐인가? 애플리케이션이 신뢰도 낮은 WAN 상에서도 구동하도록 하려면, 메시지가 네트워크 어디에서인가 유실되더라도 재전송 등을 통해 메시지 전달을 보장하는 MSMQ를 써야 할 것이다. MSMQ의 프로그래밍 모델은 ASMX와 닷넷 리모팅과 더욱 더 차이가 난다. ASMX와 닷넷 리모팅은 메소드 호출이 자동적으로 메시지 형태로 변환되지만 MSMQ는 메시지 자체를 만들어야 한다. 더욱더 가관인 것이, MSMQ는 메시지 큐를 리스닝 하는 리스너 코드도 작성해야 한다.
상황이 이러하기 때문에 지금까지는 서버의 비즈니스로직은 완전히 분리하여 컴포넌트로 구현하고(그것이 COM+ 기반이건 아니건 관계 없이) 이 컴포넌트를 다양한 원격 호출 기술 기반의 퍼사드(fa?ade)로 감싸는 것이 일반적인 방법이 되어 왔다. 보다 구체적으로 예를 들어 보자. 주문 관리 서비스를 위해 주문 관리 비즈니스 로직을 COM+ 기반의 컴포넌트로 구현한다. 그리고 ASP나 자바 클라이언트를 위해 컴포넌트의 인터페이스를 ASMX 혹은 ASMX + WSE로 구현한다. 물론 이 구현은 COM+로 작성해 놓은 주문 관리 비즈니스 로직 컴포넌트를 호출할 것이다.
이젠 인트라넷의 클라이언트를 위해 높은 성능을 내는 닷넷 리모팅 래퍼 클래스를 작성한다. 이 클래스는 MarshalByRefObject 에서 파생된 클래스로서 단순히 클라이언트 호출을 COM+ 컴포넌트로 전달하는 역할만을 한다. 닷넷 리모팅 클라이언트가 직접 COM+ 컴포넌트를 호출할 수는 없다. 클라이언트가 COM+ 컴포넌트를 직접 호출하려면 이 컴포넌트 클래스를‘참조’해야 하는데 이를 위해서는 COM+ 컴포넌트를 구현하는 클래스를 클라이언트에 배포해야 하기 때문이다.
<그림 2>다양한 클라이언트를 위한 다양한 인터페이스 구현
<그림 2>는 다양한 요구사항에 따른 여러 원격 호출 기술을 사용하여 다양한 클라이언트를 서비스하는 모습을 보여주고 있다. <그림 2>는 다양한 클라이언트를 모두 지원하는 잘 구성된 아키텍처처럼 보인다. 그렇다. 마이크로소프트의 Pattern & Practice 역시 이러한 아키텍처를 사용하길 권장할 정도로 이 모습에는 문제가 없어 보인다. 하지만 <그림 2>는 상호운영성을 높이고 다양한 클라이언트를 위해 ASMX 혹은 ASMX + WSE를 구현하는 웹 서비스 인터페이스를“구현”해야 하며, 성능을 위해서는 닷넷 리모팅 인터페이스를“구현”해야 한다.
개발자의 관점에서 <그림 2>는 상당히 고통스럽다. ASMX 및 WSE 웹 서비스에 대한 기술과 프로그래밍 모델, API 등을 알아야 하며 닷넷 리모팅도 잘아야 할 뿐더러 들어보지도 못한 MSMQ에 대한 코딩 능력까지 갖추어야만 한다. 누군들 한숨이 나올 법하지 않은가?
<그림 3> WCF의 서비스와 종점(Endpoint)
<그림 4> WCF와 다양한 바인딩
이처럼 WCF는 다양한 기술들을 통합하는 프로그래밍 모델을 제시한다. 지난 10월호에 게재한 그림을 다시 떠올려보자(그림 3 참조). WCF 서비스는 서비스를 정의하는 인터페이스와 이 인터페이스를 구현하는 서비스 클래스로서 구현한다. 그리고 이 서비스에 접근하기 위한 종점(endpoint)은 다양하게 정의될 수 있다. 종점은 다시 주소와 계약(contract), 바인딩으로 구성된다는 것 역시 이미 알고 있을 것이다. 계약이야 서비스의 인터페이스가 될 것 이므로 논외로 하고, 바인딩과 주소에 주목해 보자. 바인딩은 웹 서비스를 호출할 때 사용할“방법”을 정의하고 있다. 즉, 바인딩은 HTTP를 사용할 것인지 TCP를 사용할 것인지 혹은 MSMQ를 사용할 것인지 트랜스포트(transport)를 결정할 뿐 만 아니라 XML 메시지에 대한 보안을 어느 수준에서 수행할 것인지, 세션이나 신뢰성을 유지할 것인지 등 어떤 바인딩을 사용하는가에 따라서 달라진다.
출처 : 마이크로소프트웨어 2006년 11월호