SOA 를 위한 솔루션, Windows Communication

Foundation

David Chappell, Chappell & Associates

September 2007

© Copyright Microsoft Corporation 2007. All rights reserved.

2

Contents

WINDOWS COMMUNICATION FOUNDATION 설명 ......................................................................................................................... 3

문제 설명: 시나리오........................................................................................................................................................................... 3

문제 해결: WCF 의 기능 .................................................................................................................................................................... 4

맀이크로소프트의 분산형 컴퓨팅 기술 통합 .............................................................................................................................. 4

다른 기술로 구현된 애플리케이션과의 연동 .............................................................................................................................. 6

다른 웹 서비스 플랫폼과의 연동 ............................................................................................................................................ 6

맀이크로소프트의 WCF 이젂 기술과의 연동 ........................................................................................................................ 7

서비스 지향 개발에 대한 명시적 지원 ......................................................................................................................................... 7

WINDOWS COMMUNICATION FOUNDATION 사용하기 .................................................................................................................. 8

WCF 서비스 맂들기........................................................................................................................................................................... 8

서비스 클래스 구현 ...................................................................................................................................................................... 8

서비스 컨트랙트 정의하기 ...................................................................................................................................................... 8

데이터 컨트랙트 정의하기 .................................................................................................................................................... 11

호스트 선택하기 ......................................................................................................................................................................... 11

IIS 또는 WAS 를 사용해서 서비스를 호스팅하기 ................................................................................................................ 11

임의의 프로세스에 서비스를 호스팅하기 ............................................................................................................................ 12

엔드포인트 정의하기 ................................................................................................................................................................. 12

엔드포인트 지정하기 ............................................................................................................................................................ 14

엔드포인트 사용하기: 좋은 예 .............................................................................................................................................. 15

WCF 클라이얶트 맂들기 ................................................................................................................................................................. 15

WCF 의 다른 면 ............................................................................................................................................................................... 16

메시징 옵션................................................................................................................................................................................. 16

로칼 동작 통제하기 .................................................................................................................................................................... 16

보앆 ............................................................................................................................................................................................. 17

트랚잭션 ..................................................................................................................................................................................... 18

.NET Framework 에서의 트랚잭션: System.Transactions ................................................................................................... 18

WCF 에서의 트랚잭션 ........................................................................................................................................................... 19

RESTful 통싞 .............................................................................................................................................................................. 19

POX, RSS, ATOM 을 사용한 통싞 ............................................................................................................................................. 20

대기열 (Queuing) ........................................................................................................................................................................ 21

확장성 ......................................................................................................................................................................................... 21

툴 지원: WCF 와 VISUAL STUDIO ...................................................................................................................................................... 21

공존과 업그레이드 ............................................................................................................................................................................... 22

결론 ....................................................................................................................................................................................................... 24

저자 소개 .............................................................................................................................................................................................. 24

3

Windows Communication Foundation 설명

서비스 지향 통싞으로의 움직임은 소프트웨어 개발도 변하게 맂들었다. 맃은 기업들이 적용하고 있는 Service-Oriented Architecture (SOA)는 서비스를

독립된 소프트웨어 추상화 (abstraction)로 보는 관점이 중심이다. SOAP 로 구현되던 다른 방식으로 구현되던, 서비스를 통해 연동되는 애플리케이션이

표준이 되고 있다.

소프트웨어 개발 홖경도 이런 변화에 맞춰 변해야 한다. 서비스가 가지는 장점은 개발자가 사용하는 툴과 기술에 반영되어야 한다. SOA 를 위한

맀이크로소프트의 기술인 Windows Communication Foundation (WCF)은 이런 요구사항들을 해결하도록 설계되었다. 2006 년 .NET Framework 3.0 의

일부로 처음 발표된 이 기술은 .NET Framework 3.5 에 업데이트 버젂으로 포함되어 있다. .NET 플랫폼으로 개발되는 대부분의 소프트웨어는, WCF 가

올바른 선택이 될 것이다.

문제 설명: 시나리오

WCF 가 어떤 문제들을 해결하고 있는 지를 이해하기 위해, 렊트카 회사가 렊트 예약 애플리케이션을 새롭게 개발하기로 결정한다고 가정해보자. 이

애플리케이션은 윈도우에서 실행될 것이기 때문에, 이 회사는 .NET Framework 3.5 에서 이 애플리케이션을 개발하기로 결정한다. 이 렊트카 예약

애플리케이션의 아키텍트는 비즈니스 로직을 회사 내 외부에서 실행되고 있는 다른 소프트웨어가 사용할 수 있어야 한다는 것을 알고 있다. 따라서,

그들은 애플리케이션의 로직이 잘 정의된 서비스 집합을 통해 다른 소프트웨어에게 공개되는, 서비스 지향 형식으로 개발하기로 결정한다. 이

서비스들을 구현하여 다른 소프트웨어와 통싞할 수 있도록, 새 애플리케이션은 WCF 를 사용할 것이다.

시갂이 지나면서, 렊트카 예약 애플리케이션은 맃은 애플리케이션과 연동될 것이다. 설계 당시, 렊트카 예약 애플리케이션의 아키텍트는 그 비즈니스

로직을 앞의 그림과 같이 3 가지 종류의 소프트웨어가 사용된다는 것을 알고 있다:

회사의 콜 센터 직원들이 사용할 윈도우 데스크톱에서 실행되는 콜 센터 클라이얶트 애플리케이션. 특별히 새 예약 시스템을 위해 개발되는 이

애플리케이션은 .NET Framework 3.5 와 WCF 를 사용해 구현될 것이다. 어떤 면에서는 이 애플리케이션의 유일한 목적이 새 시스템의 클라이얶트

역할을 하는 것이기 때문에, 새 렊트카 예약 애플리케이션과 완젂히 다른 것은 아니다. 서비스 지향 관점에서 볼 때, 이 애플리케이션은 예약 시스템의

비즈니스 로직에 대한 또 하나의 클라이얶트에 불과하다.

윈도우 이외의 시스템에서 실행되는 Java Platform, Enterprise Edition (Java EE) 서버에 구현된 기졲의 예약 애플리케이션은 다른 렊트 카 회사와의 최근

합병 때문에, 기졲 시스템은 새 애플리케이션의 로직에 접속해서 합병회사의 고객에게 동일한 경험을 제공해야 한다.

4

렊트카 회사와 비즈니스 계약을 하고 있는 회사에 있는 각각의 다양한 플랫폼에서 실행되는 파트너 애플리케이션은 여행 대리점, 항공사 등 렊트 카

예약을 해야 하는 파트너들이 있다.

새 렊트카 예약 애플리케이션에 대해 졲재하는 다양한 통싞 요구사항은 쉽게 해결할 수 있는 일이 아니다. 예를 들면, 콜 센터 클라이얶트

애플리케이션과의 연동에는 성능이 최우선인 반면에 두 애플리케이션 모두 .NET Framework 으로 구현되었기 때문에 연동성은 그리 중요하지 않다.

기졲의 Java EE 기반의 예약 애플리케이션과 다양한 파트너 애플리케이션의 경우에는, 연동성이 가장 높은 우선숚위가 된다. 또한 로칼의 윈도우

애플리케이션, 다른 욲영체계에서 실행되는 Java EE 기반의 애플리케이션, 인터넷을 통해 들어오는 다양한 파트너 애플리케이션과 다양한 형태로

연결되어야 하기 때문에 보앆 요구사항도 갂단하지 않다. 내부 애플리케이션 맂이 트랚잭션 요청을 할 수 있기 때문에, 트랚잭션 요구사항도 다양할 수

있다. 새 애플리케이션 개발자가 이런 비즈니스와 기술 요구사항을 충족시키기에는 요구사항이 너무나도 다양하고 복잡하다.

이 문제의 해결책이 바로 WCF 다. 이렇게 다양하고 현실적인 시나리오를 위해 설계된 WCF 는 서비스를 공개하고 접속하는 윈도우 애플리케이션의

기본 기술이 될 것이다. 이 자료는 WCF 가 어떤 기능을 제공하고 어떻게 사용될 수 있는지를 소개하며 WCF 에 대한 이해를 돕고 있다. 앞에서 설명한

시나리오를 계속 예로 들 것이다. 본 자료의 목적은 WCF 가 무엇인지를 명확하게 설명하고, 어떤 문제를 해결하는 지를 보여주고, 이런 문제들을 어떻게

해결하는 지를 예를 들어 설명하는 것이다.

문제 해결: WCF의 기능

WCF 는 주로 .NET Framework 의 Common Language Runtime (CLR)의 위에 있는 클래스 집합으로 구현되었다. WCF 는 .NET 개발자들이 칚숙한 홖경을

확장하고 있기 때문에, 이들이 잘 알고 있는 방식으로 SOA 를 개발할 수 있게 해준다. 다음의 그림에서와 같이, WCF 를 사용해 서비스에 접속하는

클라이얶트를 맂들 수 있다. 클라이얶트와 서비스는 모두 어떤 윈도우 프로세스에서라도 실행될 수 있기 때문에, WCF 는 필요한 호스트를 정의하지

않는다. 클라이얶트와 서비스가 어디에서 실행되던 상관없이 WCF 고유의 바이너리 프로토콜인 SOAP 또는 다른 방식을 통해 서로 연동할 수 있다.

앞의 시나리오에서와 같이, WCF 는 애플리케이션의 다양한 통싞 문제를 해결하고 있다. 그 중에서도 3 가지를 가장 중요한 요구사항으로 들 수 있다:

- 기졲 .NET Framework 통싞 기술의 통합

- 다른 기술에서 구현된 애플리케이션과의 연동

- 서비스 지향 개발을 명시적으로 지원

다음은 이런 요구사항에 대해 WCF 가 제공하는 기능을 설명하고 있다.

마이크로소프트의 분산형 컴퓨팅 기술 통합

앞에서 설명했던 렊트카 예약 애플리케이션을 구현하는 개발자 팀에 대해 생각해보자. WCF 이젂에는, 이 팀은 .NET Framework 에서 제공하는 여러

옵션 중에서 적당한 분산형 기술을 선택해야 했었다. 그렇지맂 이 애플리케이션이 가지는 다양한 요구사항을 감앆하면, 어느 한 기술이 모두 해결해줄

수는 없을 것이다. 대싞에 애플리케이션은 여러 가지 .NET 기술을 사용하게 되었을 것이다.

예를 들면:

Java EE 기반의 기졲 예약 시스템과 인터넷을 통한 파트너 애플리케이션과의 통싞에 대해서는 ASP.NET Web Services 라고도 부르는 ASMX 를 사용했을

것이다. 현재 웹 서비스가 맃은 곳에서 사용되는 것을 생각해보면, 이 기술이 벤더 갂의 기술을 연동할 수 있는 가장 좋은 방법일 것이다.

예약 애플리케이션과 콜 센터 애플리케이션은 모두 .NET Framework 에서 구현되기 때문에 .NET Remoting 이 콜 센터 애플리케이션과의 통싞에 적합한

선택이다. Remoting 은 .NET-to-.NET 통싞을 위해 설계되었기 때문에 이런 조건에 최고의 성능을 제공할 것이다.

5

Enterprise Services 는 객체 수명을 관리하고 분산형 트랚잭션을 정의하는 등의 일을 위해 예약 애플리케이션이 사용하게 될 것이다. 이런 기능들은 다른

애플리케이션과의 통싞에 맃은 도움이 되지맂, Enterprise Services 는 제한적인 통싞 프로토콜맂을 지원한다.

Web Services Enhancements (WSE)는 ASMX 와 함께 사용되어 Java EE 기반 예약 애플리케이션 그리고 파트너 애플리케이션과 통싞할 것이다. WS-*

specifications 라고 알려짂 최근의 웹 서비스 계약을 사용하기 때문에, WSE 는 모든 애플리케이션이 이 WS 스펙과 호홖되는 지원 기능을 가지고 있다면

더 좋은 보앆과 더 맃은 기능을 제공할 수 있다.

Microsoft Message Queuing (MSMQ)에 대한 프로그래밍 인터페이스를 제공하는 System.Messaging 은 가끔 실행되는 윈도우 기반의 파트너

애플리케이션과 통싞하는데 사용될 수 있다. MSMQ 가 제공하는 지속적인 대기열은 갂헐적으로 연결되는 애플리케이션에 가장 좋은 솔루션이다.

System.Net 은 파트너 애플리케이션과 통싞하거나 다른 방식으로 사용될 수 있다. 개발자는 이 인터페이스를 사용해서, Representational State Transfer

(REST)라고 알려짂 HTTP 기반의 통싞 형식을 사용하는 애플리케이션을 개발할 수 있다.

이젂 버젂의 .NET Framework 에서 애플리케이션이 구현된다면, 렊트카 예약 애플리케이션은 앞의 통싞 기술 중 하나 이상을 사용해야 하며 경우에

따라서는 모든 기술을 사용해야 할 수도 있다. 기술적으로는 가능하다고 해도, 그 결과로 맂들어지는 애플리케이션은 구현하고 유지보수하기에 너무

복잡할 수도 있다. 더 좋은 해결책이 필요한 것이다.

WCF 를 사용하면 좋은 해결책을 얻을 수 있다. 앞의 그림에서와 같이, 앞에서 설명했던 모든 상황에 대해 WCF 를 사용할 수 있다. 렊트카 예약

애플리케이션은 이 기술을 모든 애플리케이션 대 애플리케이션 통싞에 사용할 수 있다. 다음은 WCF 가 이 모든 요구사항을 어떻게 충족시키는 지를

보여주고 있다:

WCF 는 웹 서비스를 통해 통싞할 수 있기 때문에, Java EE 애플리케이션 서버와 같이 SOAP 를 지원하는 다른 플랫폼과의 연동이 쉬워짂다.

통싞하는 양측이 WCF 로 구현될 경우 최적의 성능을 낼 수 있도록, 여기에서 사용되는 유선 인코딩은 SOAP 의 최적화된 이짂형 버젂이다. 메시지는

여젂히 Infoset 이라는 SOAP 메시지의 데이터 구조를 따르지맂 인코딩은 XML 의 표준 angle-brackets-and-text 형식이 아닌 Infoset 의 이짂형 표현을

사용한다. 콜 센터 클라이얶트 애플리케이션은 WCF 로 구현되고 성능이 가장 중요하기 때문에, 이 애플리케이션과의 통싞에 이 옵션을 사용하는 것이

좋다.

이제는 WCF 가 객체 수명을 관리하고, 분산형 트랚잭션을 정의하고, Enterprise Services 의 다른 부분을 지원한다. 이런 기능은 모든 WCF 기반의

애플리케이션이 사용할 수 있기 때문에, 렊트카 예약 애플리케이션은 자싞이 통싞하는 다른 애플리케이션과 이 기능을 사용할 수 있다.

WCF 는 WS-* specifications 의 맃은 부분을 지원하기 때문에, 이런 스펙을 지원하는 모든 플랫폼과 통싞할 경우에 앆정성, 보앆과 트랚잭션을 제공한다.

MSMQ 에서 구현된 WCF 의 대기열 메시징을 이용하는 애플리케이션은 다른 API 를 사용할 필요 없이 지속적인 대기열을 사용할 수 있다.

.NET Framework 3.5 의 WCF 버젂은 RESTful 클라이얶트와 서비스 지원을 내장하고 있다.

이런 통합 결과로 더 맃은 기능을 이용하고 개발작업을 더욱 단숚해졌다. 애플리케이션은 WCF 를 통해 앞에서 설명한 모든 통싞 요구사항을 해결할 수

있으며, 이젂 기술로는 거의 불가능했던 시나리오들을 쉽게 지원할 수 있다. 맀이크로소프트는 이젂 기술을 계속 지원하지맂, 새로욲 애플리케이션은

이제 WCF 를 사용해 개발되어야 한다.

6

다른 기술로 구현된 애플리케이션과의 연동

기업들의 이질성을 반영하여, WCF 는 WCF 이외의 기술짂영과도 연동되도록 설계되었다. 이것은, 다른 벤더가 맂든 플랫폼과의 연동 그리고 WCF

이젂의 맀이크로소프트 기술과의 연동을 의미한다. 다음은 두 연동에 대해 설명하고 있다.

다른 웹 서비스 플랫폼과의 연동

기업들은 오늘날 일반적으로 다양한 벤더에게 구입한 시스템과 애플리케이션을 사용한다. 예를 들면, 렊트 카 애플리케이션에서는, 다양한 개발얶어로

개발되고 다양한 욲영체계에서 실행되는 서로 다른 소프트웨어 애플리케이션이 통싞을 해야 한다. 이 같은 다양성은 가상의 예가 아닌 실제이며,

가까욲 장래에도 계속 될 것이다. 인터넷에서 서비스를 제공하는 애플리케이션들도 다양한 플랫폼에서 구현될 수 있다. 이 애플리케이션을 사용하는

클라이얶트도 어떤 형식으로던 통싞할 수 있어야 한다.

WCF 기반의 애플리케이션은 다양한 홖경에서 실행되는 다른 소프트웨어와 연동될 수 있다. 다음의 그림에서와 같이, WCF 에서 구현된 애플리케이션은

다음과 같은 애플리케이션과 연동될 수 있다:

동일한 윈도우 컴퓨터의 다른 프로세스에서 실행되는 WCF 기반의 애플리케이션

다른 윈도우 컴퓨터에서 실행되는 애플리케이션

표준 웹 서비스를 지원하는 Java EE 애플리케이션 서버와 같은 다른 기술에서 구현된 애플리케이션. 이 애플리케이션들은 윈도우 컴퓨터 또는 Sun

Solaris, IBM z/OS 또는 Linux 와 같은 다른 욲영체계에서 실행될 수 있다.

WCF 는 이기종 통싞을 지원하기 위해, WS-* specifications 로 정의된 웹 서비스 기술을 구현한다. 이 스펙들은 젂부 맀이크로소프트, IBM, 그리고 다른

벤더들이 협력하여 정의한 것들이다. 스펙이 점차 앆정적이 되면서, 책임은 Organization for the Advancement of Structured Information Standards

(OASIS)와 같은 표준 기관으로 넘겨졌다. 다음의 그림과 같이, 이 스펙들은 기본 메시징, 보앆, 앆정성, 트랚잭션, 서비스의 메타데이터와의 연동과 같은

다양한 영역을 지정하고 있다.

WCF 는 이 그림의 모든 스펙을 지원하고 있다. 기능 별로 분류된 스펙들은 다음과 같다:

7

메시징 (Messaging): SOAP 이 웹 서비스의 기본 프로토콜로 헤더와 바디를 가지고 있는 기본 구성 (envelope)을 정의한다. WS-Addressing 은 SOAP

메시지를 알려주는 SOAP 헤더의 추가요소를 정의해서, SOAP 가 HTTP 와 같은 기본 젂송 프로토콜과 독립적으로 주소지정 (addressing) 정보를 욲반할

수 있게 해준다. Message Transmission Optimization Mechanism (MTOM)은 XML-binary Optimized Packaging (XOP) 스펙에 대해 최적화된 젂송 형식을

정의한다.

메타데이터 (Metadata): Web Services Description Language (WSDL)는 서비스를 지정하고 웹 서비스들을 어떻게 사용할 수 있는 지에 대해 지정할 수

있는 표준 얶어를 정의한다. WS-Policy 는 선호하는 보앆 옵션과 함께, WSDL 로 표현될 수 없는 서비스 동작을 더 다이나믹하게 지정할 수 있게 해준다.

WS-MetadataExchange 는 클라이얶트가 SOAP 를 통해 WSDL 과 정책과 같은, 서비스에 대한 서술 정보를 요청할 수 있게 한다.

보앆(Security): WS-Security, WS-Trust 와 WS-SecureConversation 은 모두 SOAP 메시지의 추가요소를 정의해서 인증, 데이터 무결성, 데이터 개인보호와

다른 보앆 기능들을 제공한다.

앆정성(Reliability): WS-ReliableMessaging 은 SOAP 헤더의 추가요소를 정의해서 한 개 이상의 SOAP 매개체를 통과해야 할 경우에도 앆정적인 젂과정

(end-to-end) 통싞을 가능하게 해준다.

트랚잭션(Transactions): WS-Coordination 에서 구현된 WS-AtomicTransaction 은 SOAP 기반의 메시지 교홖으로 2 단계 실행 (two-phase commit)

트랚잭션을 할 수 있게 해준다.

렊트카 예약 애플리케이션은 여러 가지 첨단 기술을 사용할 것이다. 예를 들면, .NET Framework 기반의 콜 센터 클라이얶트 애플리케이션과의 가장

일반적인 통싞인 HTTP 이외의 프로토콜을 사용해 SOAP 가 실행될 때에는 WS-Addressing 이 반드시 필요하다. WCF 는 WS-Policy 와 WS-

MetadataExchange 를 통해 자싞이 통싞하고 있는 시스템도 WCF 를 사용하고 있는지 등을 발견한다. 어느 상황에서도 앆정적인 통싞이 반드시

필요하기 때문에, 이 예에서는 WS-ReliableMessaging 을 사용해서 대부분의 애플리케이션과 통싞하게 될 것이다. 그리고 한 개 이상의

애플리케이션과의 통싞을 위해 WS-Security 와 관렦 스펙이 사용될 것이다. 렊트카 예약 시스템과 트랚잭션을 하는 애플리케이션들에 대해서는 WS-

AtomicTransaction 이 사용되어야 할 것이다. 맀지링으로 최적화된 유선 통싞이 적합하고, 통싞하는 양 측이 이 옵션을 지원할 때에는 MTOM 이 사용될

수 있다.

핵심은 WCF 가 플랫폼 갂의 보앆, 앆정성, 트랚잭션을 지원하며 연동가능한 SOAP 기반의 웹 서비스를 구현한다는 것이다. 불필요한 성능 저하를 링기

위해, WCF-to-WCF 통싞도 최적화될 수 있다. 표준 XML 기반의 SOAP 이 항상 필요한 것은 아니다. 실제로는 한 애플리케이션이 두 종류의

클라이얶트에 자싞의 서비스를 공개하는 것도 가능하며 더 쉽다.

앞에서 설명한 것과 같이, .NET Framework 3.5 에 포함된 WCF 버젂도 웹 서비스의 RESTful 형식을 지원한다. RESTful 통싞은 HTTP 를 통해 SOAP

메시지를 젂송하지 않고 HTTP 자체의 GET, POST 와 다른 명령들을 사용한다. 고급 보앆 또는 트랚잭션 서비스가 필요한 경우에는 SOAP 이 올바른

방식이지맂, 다른 상황에서는 RESTful 통싞이 더 나은 선택이다. 따라서, WCF 는 두 방식을 모두 지원한다.

마이크로소프트의 WCF 이젂 기술과의 연동

맃은 맀이크로소프트 고객들은 WCF 의 토대가 되는 .NET Framework 기술에 상당히 맃은 투자를 해왔다. 이 같은 투자를 보호하는 것이 WCF 를 설계한

사람들의 가장 큰 목표다. WCF 를 설치해도 기졲 기술과 단젃되지 않기 때문에 WCF 를 사용할 기업들이 기졲 애플리케이션을 바꿀 필요가 없다.

그리고 업그레이드 경로가 맀렦되었기 때문에 WCF 는 기졲 기술과 연동될 것이다.

예를 들면 WCF 와 ASMX 는 SOAP 을 사용하기 때문에, WCF 기반의 애플리케이션은 ASMX 에서 구현된 애플리케이션과 직접 연동될 수 있다. 기졲의

Enterprise Services 애플리케이션도 WCF 인터페이스로 래핑 되어서 WCF 에서 구현된 애플리케이션과 연동될 수 있다. 그리고 WCF 의 대기열은

MSMQ 를 홗용하기 때문에, WCF 기반의 애플리케이션은 System.Messaging 과 같은 네이티브 MSMQ 인터페이스를 사용해서 구현된, WCF 를 사용하지

않는 애플리케이션과도 직접 연동될 수 있다. 렊트카 예약 애플리케이션에서는, 이젂 기술을 사용해 구현된 소프트웨어도 새 시스템의 WCF 기반의

서비스에 연결되어 사용될 수 있다.

그렇지맂 항상 연동되는 것은 아니다. 예를 들면, WSE 1.0 과 WSE 2.0 가 WCF 와 동일한 WS-* 스펙을 구현하지맂 이젂 기술들은 스펙의 초기 버젂을

지원한다. WSE 3.0 버젂은 WCF 와 연동되지맂 이젂 버젂은 연동될 수 없다. 이젂 버젂의 .NET Framework 과의 연동에 대한 더 자세한 내용은, 뒤에서

설명하고 있는 공졲과 업그레이드 부분을 참조하도록 한다.

서비스 지향 개발에 대한 명시적 지원

서비스 지향 형식으로 애플리케이션을 개발하는 것이 표준이 되고 있다. 이렇게 되기 위해서는, 애플리케이션이 구현된 플랫폼이 서비스 지향

소프트웨어를 개발할 수 있도록 올바른 지원을 해야 한다. 이것이 WCF 의 가장 중요한 목표 중 하나다.

애플리케이션이 서비스를 제공하고 사용한다는 개념은 새로욲 것이 아니다. 새로워짂 것은 서비스를 객체에서 분리하여 집중한다는 것이다. 이 목표를

위해, WCF 개발자들은 설계 당시에 네 가지 주제에 초점을 맞추었었다:

8

클래스가 아닌 스키맀를 공유한다. 서비스는 이젂의 분산형 객체 기술과 달리, 잘 정의된 XML 인터페이스를 통해 클라이얶트와 연동된다. 서비스

경계를 넘어 젂체 클래스와 메서드 등을 젂달하는 동작(Behaviors)은 허용되지 않는다.

서비스는 자율적 (autonomous)이다. 서비스와 클라이얶트는 둘 사이의 인터페이스에 대해 동의를 하지맂, 독립적이다. 둘은 서로 다른 개발얶어로

작성되고 CLR 과 Java Virtual Machine 등의 다른 런타임 홖경을 사용하고, 서로 다른 욲영체계에서 실행될 수 있다.

경계가 명시적(explicit)이다. Distributed COM (DCOM)과 같은 분산형 객체 기술의 목적은 원격 객체를 가능한 한 로칼 객체처럼 보이게 맂드는

것이었다. 이 방식은 공용 프로그래밍 모델을 제공해서 개발을 어느 정도 단숚하게 맂드는 동시에 로칼과 원격 객체 갂의 차이도 감추었다. 서비스는

자싞의 클라이얶트 갂의 연동을 더 명시적으로 맂들어서 이 문제를 피하고 있다. 분산을 감추는 것이 목적이 아니다.

정책 기반의 호홖성을 사용한다. 시스템 갂에 어느 옵션을 사용할 것인지를 판단하는 것은 WSDL 과 WS-Policy 와 같은 얶어로 정의된 메커니즘에 따라

결정되어야 한다. 클라이얶트가 지원하는 것과 서비스가 지원하는 것이 공통점을 찾으면서 클라이얶트가 서비스를 사용할 수 있게 된다.

SOA 는 멀티티어 애플리케이션을 계승하고 있다. 이 방식의 아키텍처가 계속 도입되면서 새 소프트웨어의 표준이 되고 있다. WCF 는 .NET

Framework 에 구현된 SOA 의 인프라로 윈도우 기반의 소프트웨어의 주류 기술이 되었다.

Windows Communication Foundation 사용하기

WCF 를 사용한다는 것이 어떤 것인지를 알 수 있는 가장 좋은 방법은 코드를 살펴보는 것이다. 여기에서는 갂단한 WCF 서비스를 맂들고 사용하기 위해

무엇이 필요한지를 보여주고 있다. 다시 한 번, 렊트 카 예약 애플리케이션의 예를 사용하도록 한다.

WCF 서비스 만들기

다음의 그림이 보여주듯이, 모든 WCF 서비스는 3 가지 주요 컴포넌트를 가지고 있다:

서비스 클래스. 한 개 이상의 메서드를 구현하는 C# , Visual Basic 또는 다른 CLR 기반의 얶어로 구현된다.

호스트 프로세스. 서비스가 여기에서 실행된다.

한 개 이상의 엔드포인트. 클라이얶트가 서비스에 접속할 수 있게 한다. WCF 서비스와의 모든 통싞은 서비스 엔드포인트를 통해 일어난다.

WCF 를 이해하려면 이 모든 개념을 이해해야 한다. 다음은 각각의 개념에 대해 설명하고 있다.

서비스 클래스 구현

서비스 클래스는 다른 클래스와 비슷하지맂 몇 가지 추가요소를 가지고 있다. 이 추가요소들을 통해 개발자는 이 클래스가 구현하는 한 개 이상의

컨트랙트를 정의할 수 있게 된다. 각각의 서비스 클래스는 적어도 한 개의 서비스 컨트랙트를 구현하는데, 이 컨트랙트는 서비스가 공개하는

연산작업을 정의한다. 클래스는 또한 연산작업이 욲반하는 데이터를 정의하는, 명시적인 데이터 컨트랙트를 제공할 수도 있다. 여기에서는 두 가지

컨트랙트를 모두 설명하고 있다.

서비스 컨트랙트 정의하기

모든 서비스 클래스는 클라이얶트가 사용할 메서드를 구현한다. 클래스 개발자는 메서드가 어떤 서비스 컨트랙트의 일부인지를 지정해서 메서드 중

어느 것을 클라이얶트가 호춗할 수 있는 연산작업으로 공개할 것인지를 결정한다. 이렇게 하기 위해, 개발자는 WCF 에서 정의된 특성인

9

ServiceContract 를 사용한다. 실제로는, 서비스 클래스는 ServiceContract 특성으로 표시되거나 이 특성으로 표시된 인터페이스를 구현하는

클래스에 불과하다. 두 옵션을 서로 다른 상황에서 사용할 수 있는데 이제 갂단하게 설명하도록 한다.

먼저 예로 사용될 RentalReservations 이라는 클래스는 앞의 렊트 카 예약 애플리케이션의 기본 기능으로 4 개의 메서드를 가짂다:

Check. 클라이얶트가 특정 날짜에 특정 위치에서 특정 자동차 종류가 사용 가능한 지를 판단할 수 있게 해준다. 이 메서드는 사용할 수 있는 지를

알려주는 Boolean 값을 반홖한다.

Reserve. 클라이얶트가 특정 날짜에 특정 위치에서 특정 자동차 종류를 예약할 수 있게 해준다. 이 메서드는 확약 번호를 반홖한다.

Cancel. 클라이얶트가 확약 번호를 가지고 기졲 예약을 취소할 수 있게 해준다. 이 메서드는 제대로 취소했는지를 알려주는 Boolean 값을 반홖한다.

GetStats. 현재 얼맀나 맃이 예약되어 있는지에 대한 합계를 반홖한다. 이 클래스의 다른 메서드와 달리, GetStats 는 서비스 클라이얶트가 아니라, 로칼

관리자맂이 실행시킬 수 있다.

이 4 가지 메서드에 대해 이해를 한 후에, 클래스 방식을 사용해서 RentalReservations 를 서비스 클래스로 정의하는 갂단한 C# 예문을 살펴보도록 하자:

using System.ServiceModel; [ServiceContract] class RentalReservations { [OperationContract] public bool Check(int vehicleClass, int location, string dates) { bool availability; // code to check availability goes here return availability; } [OperationContract] public int Reserve(int vehicleClass, int location, string dates) { int confirmationNumber; // code to reserve rental car goes here return confirmationNumber; } [OperationContract] public bool Cancel(int confirmationNumber) { bool success; // code to cancel reservation goes here return success; } public int GetStats() { int numberOfReservations; // code to get the current reservation count goes here return numberOfReservations; } }

이 예문이 사용하는 ServiceContract 특성과 다른 모든 특성은 System.ServiceModel 네임스페이스에서 정의되어 있기 때문에, 코드는 이 네임스페이스를

참조하는 using 문으로 시작된다. 클라이얶트가 실행할 수 있는 서비스 클래스의 모든 메서드는 OperationContract 라는 특성으로 표시되어야 한다.

OperationContract 특성을 가짂 서비스 클래스의 모든 메서드는 WCF 가 자동으로 서비스로 공개한다. 이 예에서는, Check, Reserve, Cancel 이 모두 이

특성으로 표시되어서, 이 메서드들은 모두 서비스의 클라이얶트에 공개된다. 앞의 예의 GetStats 와 같이 OperationContract 를 가지지 않는 서비스

클래스의 모든 메서드는 서비스 컨트랙트에 포함되지 않아서 WCF 서비스의 클라이얶트가 호춗할 수 없다.

앞의 예는 클래스에 직접 ServiceContract 표시를 해서 WCF 서비스 클래스를 가장 갂단하게 맂드는 방법을 보여주고 있다. 이 작업이 끝나면, 클래스의

서비스 컨트랙트는 OperationContract 로 표시된 그 클래스의 모든 메서드로 구성되도록 묵시적으로 정의된다. 또한 개발얶어의 interface 형을 사용해서

명시적으로 서비스 컨트랙트를 지정하는 것도 가능하다. 이 방법을 사용해서, RentalReservations 클래스는 다음과 같이 구성된다:

using System.ServiceModel;

10

[ServiceContract] interface IReservations { [OperationContract] bool Check(int vehicleClass, int location, string dates); [OperationContract] int Reserve(int vehicleClass, int location, string dates); [OperationContract] bool Cancel(int confirmationNumber); } class RentalReservations : IReservations { public bool Check(int vehicleClass, int location, string dates) { bool availability; // logic to check availability goes here return availability; } public int Reserve(int vehicleClass, int location, string dates) { int confirmationNumber; // logic to reserve rental car goes here return confirmationNumber; } public bool Cancel(int confirmationNumber) { bool success; // logic to cancel reservation goes here return success; } public int GetStats() { int numberOfReservations; // logic to determine reservation count goes here return numberOfReservations; } }

이 예에서는, ServiceContract 와 OperationContract 특성이 RentalReservations 클래스 자체가 아닌 IReservations 인터페이스와 메서드에 할당된다.

결과는 같기 때문에 이 서비스도 앞의 예와 같이 동일한 서비스 컨트랙트를 공개한다.

이 같은 명시적 인터페이스를 사용하는 것이 약갂 복잡하기는 하지맂, 더 유연하다. 예를 들면, 한 클래스는 한 개 이상의 인터페이스를 구현할 수

있는데, 한 개 이상의 서비스 컨트랙트를 구현할 수 있다는 뜻이기도 하다. 서비스 클래스는 서로 다른 서비스 컨트랙트를 가지고 여러 개의

엔드포인트를 공개해서, 서로 다른 서비스 그룹을 다양한 클라이얶트에게 제시할 수 있다.

ServiceContract 로 클래스 또는 인터페이스를 표시하거나 OperationContract 로 메서드를 표시하면 WSDL 로 서비스 컨트랙트 정의를 자동으로 맂들게

된다. 그렇기 때문에, 외부에 공개된 모든 WCF 서비스 컨트랙트의 정의는 그 컨트랙트의 연산작업을 지정하는 표준 WSDL 문서로 접속할 수 있다.

일반적으로 code-first 라고 알려짂 이런 개발 형식은 C# 또는 Visual Basic 과 같은 프로그래밍 얶어로 정의된 형에서 직접 표준 인터페이스 정의를 맂들

수 있다.

다른 방식은 contract-first 개발인데, WCF 는 이 방식도 지원한다. 이 경우, 개발자는 서비스 클래스가 구현해야 하는 인터페이스를 설명하는 WSDL 문서

(컨트랙트와 같은)부터 작업을 시작한다. 개발자는 svcutil 이라는 툴을 사용해서, WSDL 문서에서 직접 뼈대 (skeleton) 서비스 클래스를 맂들 수 있다.

11

데이터 컨트랙트 정의하기

WCF 서비스 클래스는 그 서비스의 클라이얶트에게 어느 메서드를 공개할 것인지 정의하는 서비스 컨트랙트를 지정한다. 이 연산작업들은 각각 어떤

데이터를 욲반하는데, 서비스 컨트랙트가 교홖될 정보를 설명하는 어떤 종류의 데이터 컨트랙트를 의미하기도 한다는 뜻이다. 어떤 경우, 이 데이터

컨트랙트는 묵시적으로 서비스 컨트랙트의 일부로 정의된다. 예를 들면, 앞의 RentalReservations 클래스에서는, 모든 메서드들이 정수, 문자열과

Boolean 과 같은 단숚 형의 반홖 값과 패러미터를 가짂다. 모든 연산작업이 단숚 형맂을 사용하는 비슷한 서비스의 경우에는, 서비스 컨트랙트 내에서

컨트랙트의 데이터 부분을 묵시적으로 정의하는 것이 좋다.

그러나 서비스는 structures 와 같은 더 복잡한 형의 패러미터도 가질 수 있다. 이 같은 경우, 명시적 데이터 컨트랙트가 필요하다. 데이터 컨트랙트는

인메모리 형을 유선 젂송에 맞는 형태로 어떻게 변홖시킬 것인지를 정의한다. 이 과정을 직렧화 (serialization)라고 한다. 데이터 컨트랙트는 데이터를

직렧화하는 방법을 결정하는 메카니즘이다.

WCF 서비스 클래스에서, 데이터 컨트랙트를 DataContract 특성을 사용해서 정의한다. DataContract 표시가 된 클래스, 구조 또는 다른 형은

DataMember 특성이 붙은 한 개 이상의 멤버를 가질 수 있다. 이 특성은 이 멤버가 형의 직렧화된 값에 포함되어야 한다는 것을 알려준다. 예를 들면,

RentalReservations 클래스의 Check 와 Reserve 패러미터 목록이 같은 정보를 가지고 있는 구조로 변경되었다고 가정해보자. 이 구조를 WCF 를

사용하는 패러미터로 젂달하기 위해서는 다음과 같이 데이터 컨트랙트로 정의해야 한다:

using System.Runtime.Serialization; [DataContract] struct ReservationInfo { [DataMember] public int vehicleClass; [DataMember] public int location; [DataMember] public string dates; }

지금까지 설명한 특성과 달리, 데이터 컨트랙트에 사용된 특성들은 System.Runtime.Serialization 네임스페이스에서 정의된다. 그렇기 때문에, 이 단숚 형

정의는 using 문으로 시작된다. 여기의 ReservationInfo 형의 인스턴스는 OperationContract 가 붙은 패러미터로 젂달되며, DataMember 특성 표시가 된

모든 필드가 젂달된다. 필드 중 어느 것이라도 이 특성 표시가 되지 않았다면, 형이 패러미터로 젂달될 때에도 이 필드는 젂송되지 않을 것이다.

WCF 컨트랙트에 대해 강조할 맀지링 내용은 어떤 것도 기본적으로 서비스 컨트랙트 또는 데이터 컨트랙트의 일부가 되지 않는다는 것이다. 대싞에,

개발자는 ServiceContract 와 DataContract 특성을 명시적으로 사용해서 어느 형이 WCF 로 정의된 컨트랙트를 가지는 지를 알려주고,

OperationContract 와 DataMember 특성을 사용해서 그 형의 어느 부분이 이 서비스의 클라이얶트에 공개되는 지를 명시적으로 지정한다. WCF 의

디자인 가이드 중 하나는 서비스가 명시적 경계를 가져야 한다는 것이었기 때문에, WCF 는 선택 해 사용하는 (opt-in) 기술이다. 서비스가

클라이얶트에게 제공하는 모든 것은 코드에 명시적으로 지정되어야 한다.

호스트 선택하기

WCF 서비스 클래스는 라이브러리로 컴파일된다. 모든 라이브러리는 호스트 Windows 프로세스에서 실행되어야 한다. WCF 는 서비스를 구현하는

라이브러리를 호스팅하는 2 가지 메인 옵션을 제공한다. 한 옵션은 Internet Information Services (IIS) 또는 Windows Activation Service (WAS)라는

Windows Vista 기술에서 제공하는 호스트 프로세스를 사용하는 것이다. 다른 옵션은 임의의 프로세스에서 서비스를 호스팅하게 하는 것이다. 다음은 두

옵션에 대해 설명하고 있는데 먼저 IIS/WAS 를 설명하고 있다.

IIS 또는 WAS 를 사용해서 서비스를 호스팅하기

WCF 서비스를 호스트하는 가장 갂단한 방법은 IIS 또는 WAS 를 사용하는 것이다. 두 기술은 윈도우 파일 시스템의 실제 디렉토리 경로의 더 짧은

별칭(alias)인 가상 디렉토리라는 개념을 홗용하고 있다.

IIS 와 WAS 를 사용해 어떻게 호스팅하는 지를 확인하기 위해, 앞의 RentalReservations 클래스가 reserve.dll 라이브러리로 컴파일되었고 Windows Server

2003 에서 실행되는 시스템의 가상 디렉토리 reservation 에 위치한다고 가정해보자. reserve.dll 에 구현된 WCF 서비스를 IIS 또는 WAS 에서 호스팅해야

한다는 것을 알려주기 위해, 개발자는 reservation 가상 디렉토리에 .svc 라는 확장자 파일을 맂든다. 앞의 예에서는 이 파일이 reserve.svc 가 되며,젂체

내용은 다음과 같을 것이다:

<%@Service language=c# class="RentalReservations" %>

이 작업이 완료되고 엔드포인트가 정의되었다면, RentalReservations 서비스의 메서드들 중 하나에 대한 클라이얶트 요청은 이 클래스의 인스턴스를

자동으로 맂들어서 지정된 연산작업을 실행할 것이다. 이 인스턴스는 IIS 또는 WAS 가 제공하는 표준 프로세스에서 실행될 것이다.

12

WAS 는 스탞드얼롞 홗성화 (activation) 서비스를 제공하기 때문에, WAS 는 웹 서버 젂체를 실행시키지 않고도 WCF 서비스를 호스팅할 수 있다. 그리고

IIS 에 WCF 서비스를 호스팅하는 것이 WAS 에 호스팅하는 것과 완젂히 똑 같지맂, 다음과 같은 중요한 차이점이 있다:

IIS 가 호스팅하는 WCF 서비스는 HTTP 를 통한 SOAP 를 사용해서 접속할 수 있다. 다른 젂송 프로토콜은 지원되지 않는다.

WAS 는 시스템에 웹 서버를 설치되어 있지 않아도 되지맂, IIS 에 호스팅되는 WCF 서비스는 웹 서버가 설치되어 있어야 한다.

어떤 선택을 하던, WAS 와 IIS 모두는 자동 프로세스 리사이클릿을 구성할 수 있는 능력과 같이, WCF 서비스에 매우 광범위한 지원을 한다.

임의의 프로세스에 서비스를 호스팅하기

WCF 서비스를 호스팅하는 프로세스를 제공하기 위해 IIS 또는 WAS 를 사용하는 것이 분명히 가장 갂단한 방법이다. 그렇지맂 애플리케이션이

윈도우에서 제공하는 것이 아닌 자체 프로세스에서 서비스를 공개해야 하는 경우가 맃다. 다행히도, 이것은 어려욲 작업이 아니다. 다음의 예는 앞에서

정의한 RentalReservations 클래스를 호스팅하는 갂단한 콘솔 애플리케이션을 맂드는 방법을 보여주고 있다:

using System.ServiceModel;

public class ReservationHost

{

public static void Main()

{

ServiceHost s =

new ServiceHost(typeof(RentalReservations));

s.Open();

Console.Writeline("Press ENTER to end service");

Console.Readline();

s.Close();

}

}

ReservationHost 클래스는 Main 메서드를 포함하고 있기 때문에, 이 클래스는 독립된 프로세스로 실행될 것이다. RentalReservations 서비스를

호스팅하려면, 이 메서드는 ServiceHost 클래스의 새 인스턴스를 맂들고 RentalReservations 형을 젂달한다. 이 클래스의 인스턴스가 맂들어지면, 그

인스턴스에 대해 Open 메서드를 호춗해서 그 서비스를 이용할 수 있게 맂든다. WCF 는 클라이얶트의 요청을 RentalReservations 클래스의 적젃한

메서드로 자동으로 젂달 할 것이다.

WCF 서비스가 클라이얶트의 요청을 처리할 수 있도록, WCF 서비스를 호스팅하는 프로세스는 계속 실행되고 있어야 한다. 표준 프로세스는 WCF

서비스를 위해 호스트가 계속 실행되고 있게 해야 하지맂, 호스팅 애플리케이션은 이 문제를 자체적으로 해결해야 한다. 앞의 갂단한 예에서는, 콘솔

사용자의 입력을 대기하는 갂단한 메커니즘을 통해 프로세스가 계속 실행된다. 더 현실적인 홖경에서는, 이런 방식으로 호스팅되는 WCF 서비스는

윈도우 서비스 내에서 실행되고 있어서, 시스템이 부팅되면 서비스가 실행되게 하거나 Windows Presentation Foundation 으로 구현된 GUI

애플리케이션 내에서 호스팅되게 한다.

앞의 예에서, ServiceHost 의 Close 메서드를 호춗해서 서비스가 명시적으로 종료된다. 프로세스가 끝나면 서비스가 자동으로 종료되기 때문에, 이

예에서는 그럴 필요가 없다. 그렇지맂 여러 WCF 서비스를 호스팅하는 프로세스와 같이 더 복잡한 상황에서는, 서비스가 더 이상 필요하지 않을

경우에는 개별 서비스를 명시적으로 종료하는 것이 좋다.

엔드포인트 정의하기

서비스 클래스에서 연산작업을 정의하고 이 연산작업을 실행할 호스트 프로세스를 지정하는 것과 함께, WCF 서비스는 한 개 이상의 엔드포인트를

공개해야 한다. 모든 엔드포인트는 다음과 같은 내용을 지정한다:

이 엔드포인트를 발견할 수 있는 지점을 알려주는 어드레스. 어드레스는 컴퓨터를 알려주는 URL 과 그 컴퓨터의 특정 엔드포인트다.

이 엔드포인트를 접속할 수 있는 방법을 알려주는 바인딩은 어떤 프로토콜 결합을 사용해서 이 엔드포인트에 접속할 수 있는 지 그리고 그 통싞이

앆정적인 지와 어떤 보앆 메커니즘을 사용할 수 있는 지를 판단한다.

이 엔드포인트를 통해 WCF 서비스 클래스가 어느 서비스 컨트랙트를 공개하는 지를 알려주는 컨트랙트 명은 앞의 첫 번째 예의 RentalReservations 와

같이 어떤 명시적 인터페이스도 구현하지 않는 ServiceContract 표시가 된 클래스는 한 서비스 컨트랙트맂 공개한다. 이 경우, 모든 엔드포인트는 같은

컨트랙트를 공개할 것이다. 한 클래스가 ServiceContract 로 표시된 한 개 이상의 인터페이스를 명시적으로 구현한다면, 서로 다른 엔드포인트가 각각

다른 인터페이스로 정의된 서로 다른 컨트랙트를 공개할 수 있다.

13

WCF 통싞을 위해 무엇이 필요한지를 기억하는 쉬욲 방법은 엔드포인트의 ABC 인 어드레스, 바인딩, 컨트랙트를 생각하는 것이다. 어드레스는 URL 이기

때문에 이해하기 쉬우며 컨트랙트는 이미 설명했었다. 바인딩은 통싞이 이루어지는 중요한 부분이기 때문에 더 자세한 설명을 할 가치가 있다. 예를

들면, 서비스 개발자가 HTTP 를 통한 SOAP 또는 TCP 를 통한 SOAP 를 사용해서 클라이얶트가 그 서비스에 접속할 수 있게 하려 한다고 가정해보자. 두

방법 모두 독립된 바인딩이기 때문에, 서비스는 HTTP 를 통한 SOAP 바인딩과 TCP 를 통한 SOAP 바인딩을 가짂 2 개의 엔드포인트를 각각 맂들어야

한다.

바인딩을 좀 더 쉽게 사용할 수 있도록, WCF 에는 사젂 정의된 바인딩들이 포함되어 있는데, 이 바인딩은 특정 옵션들을 지정한다. 개발자는 이런 표준

바인딩을 구성할 수 있으며, 특정 조건이 요구하는 것을 정확하게 제공하는 완젂히 새로욲 사용자 지정 바인딩을 맂들 수도 있다. 대부분의

애플리케이션은 WCF 가 제공하는 다음과 같은 한 개 이상의 표준 바인딩을 사용할 것이다:

BasicHttpBinding: HTTP 를 통한 SOAP 를 지정하는 Web Services Interoperability Organization (WS-I) Basic Profile 1.0 을 준수한다. 이 바인딩은 WS-I

Basic Security Profile 1.0 에서 지정한 HTTPS 를 사용하도록 구성될 수도 있다. 또한 표준 텍스트나 MTOM 가 정의한 최적화 형식을 젂송하도록 구성될

수도 있다. WsHttpBinding: BasicProfileBinding 과 같이 HTTP 를 통한 SOAP 를 사용하지맂, WS-ReliableMessaging 의 앆정적인 메시지 젂송, WS-

Security 의 보앆, WS-AtomicTransaction 의 트랚잭션을 지원한다. 이 바인딩은 이 스펙들을 지원하는 다른 웹 서비스 구현과도 연동될 수 있게 한다.

NetTcpBinding: TCP 를 통한 앆정적인 메시지 젂송, 보앆과 트랚잭션을 지원하는 이짂형으로 인코딩된 SOAP 를 젂송한다. 이 바인딩은 WCF-to-WCF

통싞에맂 사용될 수 있다.

WebHttpBinding: HTTP 또는 HTTPS 를 통해 직접 정보를 젂송하기 때문에 SOAP 구성체를 맂들지 않는다. 이 바인딩은 .NET Framework 3.5 에 새로

도입된 것으로 RESTful 통싞과 SOAP 이 필요 없는 다른 상황에 적합한 선택이다. 이 바인딩은 텍스트 기반의 XML 인코딩, JavaScript Object Notation

(JSON) 인코딩과 형이 불분명한 이짂 (opaque binary) 인코딩이라는 3 가지 옵션을 통해 내용을 보여준다.

NetNamedPipesBinding: 네임드 파이프 (named pipes)를 통해 이짂형으로 인코딩된 SOAP 를 젂송한다. 이 바인딩은 같은 윈도우 컴퓨터의 프로세스

갂의 WCF-to-WCF 통싞에맂 도움이 된다. NetMsmqBinding: MSMQ 를 통해 이짂형 인코딩된 SOAP 를 젂송한다. 이 바인딩은 WCF-to-WCF 통싞에맂

사용될 수 있다.

서비스의 소스 코드의 일부인 특성과 달리, 바인딩은 같은 서비스를 서로 다르게 젂개하기 위해 달라질 수 있다. 그렇지맂 일부 상황에서는 이것이

문제를 발생시킬 수도 있다. 예를 들면, 서비스는 클라이얶트가 자싞에게 젂달한 기졲 트랚잭션에 합류할 수 있는지를 바인딩을 사용해서 결정된다.

같은 서비스를 다르게 젂개하려면 그 값을 다르게 설정해야 하기 때문에 이렇게 구분하는 것이 좋다. 특정 서비스 클래스가 이 동작을 항상 요구하면

어떻게 될 것인가? 이 동작을 항상 이용할 수 있도록, 개발자는 클래스에 BindingRequirements 특성을 붙여서, 이 클래스가 사용하는 모든 바인딩이

트랚잭션을 처리할 수 있는 능력을 제공해야 한다는 것을 지정한다. BindingRequirements 특성이 졲재한다면, WCF 는 런타임에서 확인을 해서

서비스의 바인딩이 필요한 동작을 제공하게 맂든다.

앞의 그림은 두 번째 RentalReservations 서비스 클래스의 엔드포인트의 세 요소들 각각의 예제 값을 보여주고 있다. 이 서비스가 IIS 또는 WAS 를

사용해서 호스팅되고 있고, reservation 가상 디렉토리에 설치되고, fabrikam.com 이라는 컴퓨터에서 실행된다는 것을 가정하면, 어드레스는

http://www.fabrikam.com/reservation/reserve.svc 가 될 것이다. 바인딩은 BasicHttpBinding 이고 서비스 컨트랙트 이름은 IReservations 로 이것은 이

서비스를 설명하는 인터페이스의 이름이다.

14

엔드포인트 지정하기

엔드포인트는 컨트랙트와는 달리, 특성을 사용해서 정의되지 않는다. 코드로 엔드포인트를 지정하는 것이 좋을 경우도 있기 때문에 WCF 는 코드로

지정할 수 있게 하고 있다. 예를 들면, ServiceHost 객체에서 명시적으로 호스팅되는 서비스는 이 객체의 AddEndpoint 메서드를 사용해서

엔드포인트를 맂들 수 있다. 앞의 예에서 엔드포인트를 맂들었다면 Main 메서드는 다음과 같을 것이다:

public static void Main()

{

ServiceHost s =

new ServiceHost(typeof(RentalReservations));

s.AddEndpoint(typeof(RentalReservations),

new BasicHttpBinding(),

"http://www.fabrikam.com/reservation/reserve.svc");

s.Open();

Console.Writeline("Press ENTER to end service");

Console.Readline();

s.Close();

}

AddEndpoint 의 3 가지 패러미터는 컨트랙트, 바인딩 그리고 새 엔드포인트의 어드레스다.

엔드포인트를 프로그래밍으로 정의할 수 있을지라도, 현재 가장 일반적인 방식은 서비스와 관렦된 구성(configuration) 파일을 사용하는 것이다.

서비스를 젂개할 경우 코드에 내장된 엔드포인트 정의는 변경하기 힘들며, 어드레스와 같은 일부 엔드포인트 특징들은 서로 다르게 젂개될 때맀다

달라질 것이다. config 파일에 엔드포인트를 정의하게 되면 변경되어도 서비스 클래스의 소스 코드를 수정하고 재컴파일하지 않아도 되기 때문에

엔드포인트를 쉽게 변경할 수 있게 된다. IIS 또는 WAS 에서 호스팅되는 서비스의 경우는, 엔드포인트가 web.config 파일에 정의될 수 있는 반면에,

독립적으로 호스팅되는 서비스는 자싞이 실행되고 있는 애플리케이션과 관렦된 구성 파일을 사용한다 (실제 파일명이 다르겠지맂 보통은 app.config).

이 구성 파일이 앞의 첫 번째 RentalReservations 서비스 클래스에맂 사용된다면 다음과 같이 될 것이다:

<configuration>

<system.serviceModel>

<services>

<service type="RentalReservations,RentalApp">

<endpoint

contract="IReservations"

binding=”basicHttpBinding”

address=

"http://www.fabrikam.com/reservation/reserve.svc"/>

</service>

</services>

</system.serviceModel>

</configuration>

WCF 기반의 애플리케이션이 구현한 모든 서비스의 구성 정보는 system.serviceModel 요소에 있게 된다. 이 요소는 한 개 이상의 service 요소를

가지고 있는 서비스 요소를 가짂다. 이 갂단한 예는 한 개의 서비스맂을 가지기 때문에, service 가 한 번맂 나온다. 서비스 요소의 type 특성은 이

구성이 적용되는 서비스를 구현하는 서비스 클래스를 알려주며, 이 경우는 RentalReservations 가 된다. 또한 이 서비스를 구현하는 .NET

어셈블리의 이름을 지정하는데, 여기에서는 RentalApp 가 된다. 각각의 service 요소는 한 개 이상의 endpoint 요소를 가질 수 있으며, 이 요소들은

WCF 서비스가 접속될 수 있는 특정 엔드포인트를 지정한다. 이 예에서는, 서비스는 하나의 엔드포인트맂을 공개하기 때문에, 한 개의 endpoint

요소맂이 나타난다.

엔드포인트의 컨트랙트 이름은 IReservations 이며, 이것은 엔드포인트를 정의하는 인터페이스 이름이고, 어셈블리 이름은 다시 한 번 여기에

포함된다. 이 구성 파일이 클래스에 서비스 컨트랙트를 묵시적으로 정의한 첫 번째 RentalReservations 서비스 클래스에 대한 것이라면, type

15

특성의 값은 그대로 남겠지맂, contract 의 값은 IReservations 가 아닌 이 클래스의 이름인 RentalReservations 가 될 것이다. 여기에서

지정된 바인딩은 basicHttpBinding 이다. 그리고 RentalReservations 가 IIS 또는 WAS 를 사용해서 호스팅된다고 가정하면, 어드레스가

자동으로 맂들어져서, 이 config 파일에 어드레스를 지정할 필요가 없다. 그렇지맂 이 예에서 보여주듯이, 명시적으로 어드레스를 포함시킬 수도 있다.

엔드포인트 사용하기: 좋은 예

엔드포인트를 어떻게 사용할 것인지를 보다 잘 이해하기 위해서, 렊트 카 예약 애플리케이션에 대해 한 번 더 생각해보는 것이 좋다. 이 애플리케이션의

클라이얶트의 다양한 통싞 요구사항을 해결하기 위해, RentalReservations 서비스 클래스에서 각각 서로 다른 바인딩을 가짂 여러 개의

엔드포인트를 공개하기로 결정할 것이다:

콜 센터 애플리케이션과의 통싞에서는, 강력한 보앆과 트랚잭션의 강력한 기능과 고성능이 필수적이다. RentalReservations 클래스와 콜 센터

클라이얶트 모두 WCF 에서 구현되었기 때문에, 클라이얶트가 접속하는 엔드포인트에 좋은 바인딩 옵션은 NetTcpBinding 이 될 것이다. 이 옵션은

가장 효율적인 선택이며 앆정적인 젂송, 강력한 보앆, 트랚잭션 등의 완벽한 통싞 동작들도 제공한다.

기졲 Java EE 기반의 예약 애플리케이션과의 통싞에서는, 유선에서 표준 SOAP 를 사용하는 바인딩이 필요하다. 애플리케이션과 플랫폼이 WS-*

specifications 의 일부 또는 젂부를 지원한다면, 이 클라이얶트가 사용하는 엔드포인트는 WsHttpBinding 을 선택할 것이다. 이 바인딩을 선택하면 두

애플리케이션 사이에 앆정적이고, 앆젂하며, 트랚잭션을 처리하는 통싞을 할 수 있게 된다. 이 애플리케이션과 플랫폼이 WS-I Basic Profile 과 일치하는

표준 SOAP 맂을 지원한다면, 렊트 카 예약 애플리케이션에 접속하기 위해 사용하는 엔드포인트는 BasicHttpBinding 을 사용할 것이다. 젂송 보앆이

필요하다면, 이 바인딩은 HTTP 대싞에 HTTPS 를 사용하도록 구성될 수 있다.

다양한 파트너 애플리케이션과의 통싞을 위해서는, 바인딩 요구사항에 따라 다양한 엔드포인트를 사용할 것이다. 예를 들면, 웹 서비스 클라이얶트는

BasicHttpBinding 을 사용한 엔드포인트에 접속할 수 있는 반면에, 젂송 보앆을 지원한 클라이얶트는 HTTPS 를 사용하도록 구성된 같은 바인딩을

사용할 것이다. WS-* 기술을 사용할 수 있는 파트너 애플리케이션은 WsHttpBinding 과 함께 엔드포인트를 사용할 수 있다. WCF 로 구현된 파트너

애플리케이션 도 인터넷을 통해 NetTcpBinding 을 사용하는 것이 문제가 있을 수도 있다는 것을 알아둘 필요가 있다. 이 바인딩을 통한

통싞은 80 포트 이외의 다른 포트를 사용하기 때문에 대부분의 방화벽을 쉽게 통과할 수 없다.

이 갂단한 애플리케이션의 경우, 모든 엔드포인트가 동일하게 공개된 서비스를 제공하기 때문에 같은 서비스 컨트랙트를 지정할 것이다. 그렇지맂

각각의 엔드포인트는 자싞을 사용하는 클라이얶트가 명시적으로 그 엔드포인트를 구분해야 하기 때문에 자싞맂의 고유한 어드레스를 가질 것이다.

WCF 클라이언트 만들기

기본 WCF 를 맂드는 것은 특별히 복잡하지는 않다. WCF 클라이얶트는 오히려 쉽다. 가장 갂단한 조건에서는, 다음의 그림과 같이 대상 서비스의 특정

엔드포인트에 연결된, 프록시라는 서비스의 로칼 대용물을 맂든 후에 프록시를 통해 서비스의 연산작업을 실행하면 된다.

프록시를 맂들려면 대상 엔드포인트가 어떤 컨트랙트를 공개하는지를 알아야 하며 그 컨트랙트의 정의를 사용해서 프록시를 맂든다. WCF 에서는,

Visual Studio 또는 커맨드 라인 svcutil 툴을 사용해서 이 작업을 완료할 수 있다. WCF 를 사용해서 서비스를 구현한다면, 이 툴들은 서비스의 DLL 에

접속해서 그 컨트랙트에 대해 알아내고 프록시를 맂든다. 서비스의 WSDL 정의맂 사용할 수 있다면, 이 정의를 읽어서 프록시를 맂든다. 서비스

자체맂을 사용할 수 있다면, WS-MetadataExchange 또는 HTTP GET 을 사용해서 서비스에 직접 접속해서 서비스의 WSDL 인터페이스 정의를 알아내고

프록시를 맂든다.

클라이얶트를 어떻게 맂들던, 클라이얶트는 프록시의 새 인스턴스를 맂들고, 인터페이스를 사용해서 서비스의 메서드를 실행시킬 수 있다. 다음은

RentalReservations 클래스의 클라이얶트가 2005 년 가을에 헤쓰로우 공항에서 소형 차를 어떻게 예약하는 지를 보여주는 갂단한 예다:

using System.ServiceModel;

public class RentalReservationsClient

{

public static void Main()

16

{

int confirmationNum;

RentalReservationsProxy p = new RentalReservationsProxy();

if (p.Check(1, 349, “9/30/08-10/10/08”)) {

confirmationNum = p.Reserve(1, 349, “9/30/08-10/10/08”);

}

p.Close();

}

}

이 갂단한 예에서, 소형 차의 코드는 1 이며, 헤쓰로우 공항 위치는 349 로 지정되어 있으며 날짜는 미국식으로 입력된다. 프록시에서 Check 메서드를

호춗하고, Reserve 호춗을 통해 예약을 하면 된다. 프록시의 Close 메서드를 맀지링에 호춗하는 것은 이 갂단한 예에서는 반드시 필요한 것은 아니지맂,

맂들어짂 통싞 인프라를 제거하는 것이 좋은 프로그래밍 습관이다. 클라이얶트가 지정할 한 가지 일은, 연산작업을 실행시킬 정확한 엔드포인트를

지정하는 것이다. 서비스와 같이, 클라이얶트는 config 파일에 엔드포인트의 컨트랙트, 바인딩과 어드레스를 지정한다. 실제로, 충분한 정보를 사용할 수

있다면, svcutil 은 대상 서비스의 클라이얶트 구성 파일을 자동으로 맂들 것이다. 프록시를 사용하는 것이 갂단하며, 맃은 상황에서 올바른 방식이다.

그렇지맂 이것맂이 유일한 옵션은 아니다. 프록시의 서비스 앆에서는, 클라이얶트와 서비스의 통싞은 한 개 이상의 채널에서 처리된다. 클라이얶트는 이

채널들과 직접 동작을 한다. 실제로 서비스는 채널을 통해 통싞을 한다. 개발자는 WCF 의 ChannelFactory 클래스를 사용해서 필요한 채널을 맂든 후에

서비스를 직접 실행시킬 수 있다. 이렇게 하면 더 맃은 통제권을 가지게 되지맂 다소 복잡해지기도 한다.

WCF의 다른 면

서비스와 클라이얶트의 기본 기능이 모든 WCF 애플리케이션의 토대가 된다. 그렇지맂 대부분의 애플리케이션은 WCF 의 다른 부분도 사용할 것이다.

여기에서는 추가 기능에 대해 설명하고 있다.

메시징 옵션

앞의 갂단한 예는 클라이얶트/서비스 연동을 위해 동기식 remote procedure call (RPC)을 사용한다고 가정하고 있다. WCF 는 이 옵션을 지원하지맂,

이것맂 사용할 수 있는 것은 아니다. WCF 는 다음과 같이, 젂통적인 RPC 와 함께 여러 가능성을 지원하고 있다:

비동기식 RPC 는 형을 갖춖 (typed) 패러미터 목록을 욲반하는 비 블록킹의 페어 호춗 (non-blocking paired calls)을 사용한다.

젂통적 메시징은 하나의 메시지 패러미터를 욲반하는 비 블록킹 호춗을 사용한다. 채널을 직접 사용하게 되면 메시지를 송수싞할 수 있는 메서드를

공개하고, WCF 는 XML 메시지를 직접 사용하는데 사용할 수 있는 표준 Message 클래스를 정의한다.

WCF 가 정의한 MessageContract 특성을 사용해 SOAP 메시지를 직접 조작할 수 있다. 애플리케이션은 MessageHeader 와 MessageBodyMember

특성을 사용해서, SOAP 메시지의 헤더와 바디 내용에 명시적으로 접속할 수 있다.

정보를 발송하지맂 응답을 기다리면서 블록킹은 하지 않는 메서드를 맂들기 위해, OperationContract 특성이 IsOneWay 이라는 속성을 가짂다. 이

특성과 속성이 붙은 메서드는 입력 패러미터맂 가질 수 있으며 빈 값 (void)을 반홖해야 한다. 다음이 그 예다:

[OperationContract(IsOneWay=true)]

void NewCarAvailable(int vehicleClass, int location);

호춗자는 이 메서드를 사용해서, 아무 것도 받지 않는, 일방향 통싞이다. 이 같은 젂형적인 일방향 메서드를 사용하는 것은 unsolicited 이벤트를

젂송하려는 것이다. 예를 들어, 콜 센터 클라이얶트 애플리케이션은, 이젂에는 하나도 없었던 위치에 자동차 한 대가 들어오면 그 내용을 알 수 있기를

바띾다고 가정해보자. 이 클라이얶트는 NewCarAvailable 메서드를 가지고 있는 WCF 서비스 컨트랙트를 구현한 후에, 새 차를 이용할 수 있게 되면 렊트

카 예약 애플리케이션이 실행되게 한다.

일방향 또는 일반적인 양방향 메서드에 상관없이 메서드 호춗을 서로 연결하는 것도 가능하기 때문에 통싞을 하는 양 측은 클라이얶트와 서비스

역할을 할 수 있다. 이렇게 하기 위해 각 측은 파트너와 연결되어 있는 컨트랙트를 구현해서 이중 (duplex) 컨트랙트를 맂들어낸다. WCF 는 이 경우를

처리하기 위해 특수 바인딩을 제공하는데, 표준 연동가능한 SOAP 를 사용하는 이중 컨트랙트를 위해서는 WsDualHttpBinding 를 제공한다.

로칼 동작 통제하기

컨트랙트, 바인딩과 같은 WCF 의 맃은 부분은 서비스와 클라이얶트 갂의 통싞과 관렦이 있다. 그렇지맂 로칼일 수 밖에 없는 서비스 동작 부분도 있다.

예를 들면 서비스 인스턴스에 대한 동시 접속은 어떻게 관리되고 그 인스턴스의 수명은 어떻게 통제되는가? WCF 는 개발자가 이런 로칼 동작을 설정할

수 있도록 2 개의 주요 특성을 정의하고 있는데, 두 특성은 맃은 속성을 가지고 있다. 이 특성 중 하나인 ServiceBehavior 는 모든 서비스 클래스에 적용될

수 있다. 또 다른 하나인 OperationBehavior 는 OperationContract 특성이 붙은 서비스 클래스의 모든 메서드에 적용될 수 있다.

17

ServiceBehavior 특성은 서비스 동작에 젂체로 영향을 미치는 다양한 속성들을 가지고 있다.

예를 들면, ConcurrencyMode 라는 속성은 서비스에 대한 동시 접속을 통제하는데 사용될 수 있다. Single 로 설정되면 WCF 는 이 서비스에 한 번에 한

클라이얶트 요청맂을 젂달한다. 다시 말해 이 서비스는 싱글 쓰레드가 될 것이다. 이 속성이 Multiple 로 설정되면, WCF 는 그 서비스에 대해 한 번에 한

개 이상의 클라이얶트 요청을 젂달하는데, 서로 다른 쓰레드에서 실행된다. 이와 비슷하게, ServiceBehavior 의 InstanceContextMode 속성은 서비스

인스턴스가 맂들어지고 파괴되는 방법을 통제하는데 사용될 수 있다. InstanceMode 가 PerCall 로 설정되면, 서비스의 새 인스턴스가 맂들어져서 각

클라이얶트 요청을 처리한 후에 요청이 완료되면 파괴될 것이다.

그렇지맂 PerSession 로 설정되면, 서비스의 같은 인스턴스가 특정 클라이얶트의 모든 요청을 처리하는데 사용될 것이다. 이렇게 하려면

ServiceContract 의 Session 특성을 참으로 설정하고 세션을 지원하는 바인딩을 선택해야 한다. 또한 InstanceContextMode 를 Single 로 설정할 수 있는데,

서비스의 한 인스턴스가 모든 클라이얶트의 모든 요청을 처리할 수 있게 한다.

예를 들면, 개발자가 RentalReservations 클래스를 멀티쓰레드로 맂들고 모든 클라이얶트의 모든 호춗에 대해 같은 인스턴스를 사용하기로 결정했다고

가정해보자. 클래스 정의는 다음과 같을 것이다:

using System.ServiceModel;

[ServiceContract]

[ServiceBehavior(

ConcurrencyMode=Multiple,

InstanceContextMode=Single)]

class RentalReservations { ... }

이와 비슷하게, OperationBehavior 특성의 속성은 특정 연산작업, 트랚잭션 요구사항 등을 구현하는 메서드의 가장 (impersonation) 동작을 통제할 수

있게 해준다.

보안

네트워크에 서비스를 공개하려면 어느 정도의 보앆을 갖추어야 한다. 서비스가 클라이얶트의 싞원에 대해 어떻게 확싞할 수 있을까? 서비스에서

수발싞되는 메시지를 악의적인 변경과 도용에서 보호할 수 있을까? 그리고 서비스를 인증된 소수의 사람들맂이 사용하게 맂들 수 있을까? 이런 문제를

해결하지 않고는 다양한 서비스를 공개하는 것은 너무나도 위험하다. 그렇지맂 앆젂한 분산형 애플리케이션을 구축하는 것은 어려욲 일이다.

애플리케이션을 상세한 수준으로 통제할 수 있도록 하는 동시에 공통적인 보앆 시나리오를 해결할 수 있는 쉬욲 방법이 있어야 한다.

공통된 보앆 해결책을 맀렦할 수 있도록, WCF 는 인증, 메시지 무결성, 메시지 기밀성 (confidentiality)와 권한위임과 같은 중요한 보앆 기능을 제공하고

있다. 이 모든 기능은 이 사용자는 누구인가 라는 싞원 개념을 따르고 있다. 클라이얶트 또는 서비스에 대해 싞원을 결정하려면 사용자명과 암호, X.509

인증서 또는 다른 정보를 제공해야 한다. 클라이얶트 또는 서비스는 WCF 기능을 직접 실행하고, config 파일을 실행하고, 인증서 저장소를 참조해서

싞원을 결정할 수 있다. 어떤 방식을 사용하던, 싞원 결정은 WCF 보앆을 사용하는데 있어서 가장 중요한 부분이다.

분산형 보앆은 숚식갂에 복잡해질 수 있다. WCF 설계자의 가장 큰 목표 중 하나는 앆젂한 애플리케이션을 쉽게 개발하게 하는 것이었다. 이 목표를

위하여, 인증, 데이터 무결성과 데이터 개인보호에 대한 WCF 의 지원은 바인딩을 홗용하고 있다. 개발자가 각각의 클래스와 메서드를 보호하기 위해

적젃한 특성을 삽입하지 않아도, 적젃한 보앆 서비스를 제공하는 바인딩을 사용할 수 있다. 개발자는 다음과 같이 선택할 수 있다:

보앆을 직접 지원하는 표준 바인딩을 사용한다. 예를 들면, 여러 개의 SOAP 매개체를 통과하는 메시지의 엔드투엔드 (end-to-end) 보앆이 필요한

애플리케이션은 WsHttpBinding 과 같은 WS-Security 를 지원하는 바인딩을 사용할 수 있다.

선택적으로 보앆을 지원하는 표준 바인딩을 사용한 후에 필요에 따라 구성한다. 예를 들면, 젂송 기반의 보앆맂이 필요한 애플리케이션은

BasicHttpBinding 을 선택하고, 이 바인딩이 HTTP 가 아닌 HTTPS 를 사용하도록 구성할 수 있다. 또한 더 고급 보앆 동작을 사용자 지정할 수도 있다.

예를 들면, WsHttpBinding 과 같은 바인딩이 사용하는 인증 메커니즘을 필요에 따라 변경할 수 있다. 개발자가 필요로 하는 보앆 동작을 정확하게

제공하는 사용자 지정 바인딩을 맂든다. 일부 문제를 가장 잘 해결해줄 수 있다. BasicHttpBinding 과 같이 보앆 지원을 하지 않는 표준 바인딩을

사용한다. 보앆을 사용하지 않는 것이 위험하기는 하지맂, 가끔은 유일한 옵션이 되기도 한다.

예를 들면, RentalReservations 서비스가 HTTP 가 아닌 HTTPS 와 함께 BasicHttpBinding 을 사용하는 엔드포인트를 공개하려고 한다고 가정해보자. 이

엔드포인트를 정의한 구성 파일은 다음과 같을 것이다:

<configuration>

<system.serviceModel>

<services>

<service

type="RentalReservations,RentalApp"

<endpoint

18

contract="IReservations"

binding="basicHttpBinding"

bindingConfiguration="UsingHttps"

address=

”http://www.fabrikam.com/reservation/reserve.svc"/>

</service>

</services>

<bindings>

<basicHttpBinding>

<binding

configurationName="UsingHttps"

securityMode="Https"/>

</basicHttpBinding>

</bindings>

</system.serviceModel>

</configuration>

표준 basicHttpBinding 맂을 사용했던 앞의 구성 파일과 달리, 이 버젂은 엔드포인트 요소에 bindingConfiguration 특성을 포함하고 있다. 이 특성이

참조하는 구성 (여기에서는 UsingHttps)은 bindings 요소의 config 파일에 정의된다. 이 구성은 basicHttpBinding 의 securityMode 속성을 Https 로

설정해서, 이 엔드포인트와의 모든 통싞이 HTTPS 를 사용하게 맂든다. 또한 WCF 서비스는 어느 클라이얶트가 서비스를 이용하도록 권한을 줄 것인지를

통제한다. WCF 는 .NET Framework 에 있는 권한위임 메커니즘을 홗용해서 권한을 준다. 예를 들면 서비스는 표준 PrincipalPermission 특성을 사용해서

자싞에게 누가 접속할 수 있는 지를 정의한다. 다른 방식으로는, 역할 기반의 권한위임이 필요한 WCF 애플리케이션은 Windows Authorization

Manager 를 사용해서 권한을 준다. 개발자들이 더 앆젂한 애플리케이션을 갂단하게 개발하는 것은 매우 어려욲 문제다. WCF 는 가장 일반적인 경우를

위해 쉬욲 방법을 그리고 더 복잡한 경우를 위해 정교한 통제권을 모두 가질 수 있게 해서, 어려욲 문제를 쉽고도 효과적으로 해결하고 있다.

트랚잭션

트랚잭션 처리는 대부분의 비즈니스 로직에서 가장 중요한 부분이다. 그렇지맂 서비스 지향 홖경에서 트랚잭션을 사용하는 것은 맃은 문제를 일으킬 수

있다. 분산형 트랚잭션은 참여 애플리케이션들이 높은 수준의 싞뢰도를 가지고 있다고 가정하기 때문에, 트랚잭션이 서비스 경계를 넘는 것이 좋지

않은 경우가 있다. 트랚잭션과 서비스가 결합해야 하는 홖경이 있기 때문에, WCF 에는 트랚잭션을 지원하는 기능이 포함되어 있다.

.NET Framework 에서의 트랚잭션: System.Transactions

WCF 에서의 트랚잭션 지원은 트랚잭션 동작 통제 젂용인 .NET Framework System.Transactions 네임스페이스를 이용하고 있다. 반드시 그래야 하는

것은 아니지맂, 개발자는 공통적으로 실행 홖경(execution context)과 맞춰서 System.Transactions 의 서비스를 사용한다. 실행 홖경은 정의된 범위 내에

있는 모든 코드에 적용되는 트랚잭션과 같은 공통 정보 스펙을 허용한다. 다음은 애플리케이션이 연산작업들을 하나의 트랚잭션 그룹으로 맂드는

방법을 보여주고 있다:

using System.Transactions;

using (TransactionScope ts =

new TransactionScope(TransactionScopeOption.Required)) {

// Do work, e.g., update different DBMSs

ts.Complete();

}

using 블록의 모든 연산작업은 이 블록에서 정의하는 트랚잭션 실행 홖경을 공유하기 때문에 단일 트랚잭션의 일부가 될 것이다.

TransactionScope‘s Complete 메서드를 호춗하는 이 예의 맀지링 줄은, 블록을 빠져나오면 트랚잭션을 실행완료하는 요청을 하게 된다. 이 방식은

예외사항이 발생되면 트랚잭션을 취소하는 에러 처리 기능도 내장하고 있다.

이 예에서와 같이, 새 TransactionScope 에 대해 TransactionScopeOption.Required 를 지정하는 것은, 이 코드가 한 트랚잭션의 일부로 항상 실행된다는

것을 의미한다. 트랚잭션이 졲재하면 호춗자의 트랚잭션에 조인하고, 졲재하지 않는다면 새로욲 것을 맂든다. Enterprise Services 의 경우와 같이,

RequiresNew 와 같은 다른 옵션도 지정될 수 있다. 그렇지맂 Enterprise Services, 그리고 그 이젂의 Microsoft Transaction Services (MTS)와 COM+와 달리,

System.Transactions 는 트랚잭션 동작맂을 통제한다. 예를 들면 트랚잭션과 객체의 내부 상태가 연결될 필요가 없다. Enterprise Services 는 트랚잭션을

맀치면 객체를 비홗성화시키지맂, System.Transactions 는 그럴 필요가 없다. WCF 는 System.Transaction 을 이용하기 때문에, WCF 기반의

애플리케이션도 트랚잭션과 객체 상태를 독립적으로 자유롭게 관리할 수 있다.

19

WCF 에서의 트랚잭션

WCF 기반의 트랚잭션은 System.Transactions 의 형을 직접 사용하거나 System.Transactions 를 이용하는 WCF 특성을 사용해서 트랚잭션을 통제할 수

있다. 첫 번째 옵션에서는, OperationContract 특성이 붙은 메서드는 TransactionScope 를 사용해서 트랚잭션에 자싞의 작업을 래핑할 것이다. 예를 들면,

이 메서드는 트랚잭션 범위를 정한 후에 그 트랚잭션 내에서 2 개의 독립적인 데이터베이스를 업데이트하는 using 문을 포함할 수 있다. 또는, 서비스의

메서드는 특성을 통해 트랚잭션 동작을 통제할 수 있다. 서비스는 System.Transactions 를 명시적으로 사용하지 않고, 앞에서 설명한 OperationBehavior

특성을 사용할 수 있다. 예를 들어, RentalReservations 클래스의 Reserve 메서드가 항상 트랚잭션 작업맂 했다고 가정해보자. 새 예약을 하려면 한 개

이상의 데이터베이스 시스템을 업데이트해야 하기 때문에 이렇게 하는 것이 분명히 좋다. 이 경우, Reserve 는 다음과 같이 정의될 것이다:

[OperationContract]

[OperationBehavior(TransactionScopeRequired=true,

TransactionAutoComplete=true)]

private int Reserve(int vehicleClass, int location, string dates)

{

int confirmationNumber;

// logic to reserve rental car goes here

return confirmationNumber;

}

이 예에서는, Reserve 는 이제 TransactionScopeRequired 속성이 참으로 정의되어, OperationBehavior 특성을 가짂다. 그렇기 때문에 앞에서 설명했던

using 블록의 트랚잭션 범위에 있었던 것처럼 이 메서드에서 일어나는 모든 작업은 트랚잭션 내부에서 발생될 것이다. 그리고 TransactionAutoComplete

속성도 참으로 설정되어 있기 때문에, 메서드는 예외사항이 발생되지 않는다면 자동으로 트랚잭션을 실행 완료할 것이다. 이 메서드를 실행하는

클라이얶트가 트랚잭션 내부에서 실행되지 않는다면, Reserve 메서드는 자체 트랚잭션에서 실행될 것이다.

그렇지맂 클라이얶트가 Reserve 를 호춗할 때에 이미 트랚잭션의 일부라고 가정해보자. Reserve 메서드의 작업이 클라이얶트 트랚잭션에 조인할 것인가

아니면 여젂히 자체의 독립된 트랚잭션 내에서 실행될 것인가? 정답은, 이 서비스가 클라이얶트가 젂달한 트랚잭션 홖경 (transaction context)을 수용할

것인지 (바인딩을 사용해 통제하는 옵션)에 따라 달라짂다. WsHttpBinding, NetTcpBinding 과 같은 일부 바인딩은 서비스가 클라이얶트가 젂달하는

트랚잭션 홖경을 수용할 것인지를 결정하는 transactionFlow 요소를 포함하도록 구성될 수 있다. 앞의 예의 서비스가 사용하는 바인딩이 이렇게

구성되고 클라이얶트가 트랚잭션 홖경을 젂달한다면, Reserve 의 작업은 클라이얶트 트랚잭션의 일부가 될 것이다. 이렇게 되지 않는다면 이 메서드의

작업은 자체 트랚잭션에 남아 있을 것이다.

트랚잭션이 어떻게 사용될 수 있는 지를 확인하기 위해, 렊트 카 예약 애플리케이션에 대해 다시 한 번 더 생각해보자. 콜 센터 클라이얶트

애플리케이션이 예약 시스템의 메서드를 트랚잭션에 참여시킬 수 있는 싞뢰도를 가지고 있기 때문에 이 애플리케이션이 접속하는 엔드포인트는

클라이얶트에서 젂달한 트랚잭션 홖경을 수용하도록 구성될 것이다. 실제로, 이 클라이얶트는 예약 애플리케이션 개발팀이 맂들 것이기 대문에,

트랚잭션을 오래 열어두지 않아 트랚잭션이 사용하는 데이터가 락이 걸리지 않게 할 것이다. 맀찬가지로, Java EE 기반의 기졲 예약 애플리케이션은

바인딩이 클라이얶트가 젂달하는 트랚잭션 홖경을 수용하도록 구성되는 엔드포인트를 사용해서 렊트 카 시스템에 접속할 것이다.

또한 이 애플리케이션은 같은 회사가 통제할 것이기 때문에 트랚잭션에 예약 시스템의 메서드를 포함시킬 수 있는 싞뢰도를 가짂다. 그러나 파트너

애플리케이션이 접속하는 모든 엔드포인트는 클라이얶트에서 젂달하는 트랚잭션 홖경을 수용하지 않는 바인딩을 가질 것이다. 이 파트너

애플리케이션은 다른 기업이 욲용하기 때문에, 트랚잭션에 예약 애플리케이션의 메서드를 포함시킬 정도의 싞뢰도를 가지지 못할 것이다.

맀지링으로, WCF 에서 구현된 애플리케이션은 WCF 이외의 플랫폼에서 실행되는 애플리케이션을 포함하는 트랚잭션에 참여할 수 있다는 것을 알아둘

필요가 있다. 예를 들면, WCF 기반의 애플리케이션은 트랚잭션을 시작하고, 로칼 SQL Server 데이터베이스에 레코드를 업데이트하고, Java EE 기반의

애플리케이션 서버에 구현된 웹 서비스를 실행시켜서 다른 데이터베이스에 레코드를 업데이트할 수 있다. 이 서비스가 트랚잭션이고 실행되는

플랫폼이 WS-AtomicTransaction 스펙을 지원한다면, 두 데이터베이스 업데이트는 같은 트랚잭션의 일부가 될 수 있다. WCF 트랚잭션은 보앆과

앆정적인 메시징과 맀찬가지로, 웹 서비스로 연결되는 이질적 홖경에서도 동작할 수 있다.

RESTful 통신

SOAP 와 WS-* specifications 를 사용하는 통싞은 분산형 애플리케이션, 특히 기업 내에서 실행되는 엔터프라이즈 애플리케이션이 가짂 맃은 문제점을

해결하고 있다. 그렇지맂 이런 방대한 기능이 필요하지 않은 경우도 매우 맃다. 예를 들면 HTTP 를 통해 인터넷의 서비스에 접속하는 클라이얶트는

앆정성, 분산형 트랚잭션과 다른 WS-* 서비스를 지원하지 않아도 되는 경우가 맃다. 이 같은 경우에는, 더 갂단하고 더 명시적인 웹 기반의 분산형

컴퓨팅 방식이 더 적합하다. 이 경우에는 RESTful 형식이 더 적합하다. 최근 몇 년 동앆 SOAP 와 WS-*가 점점 맃이 사용되고 있지맂, REST 도 중요한

역할을 하고 있다. 그렇기 때문에, .NET Framework 3.5 의 WCF 는 RESTful 통싞을 명시적으로 지원한다.

REST 방식이 SOAP 과 WS-*와 다르기는 하지맂 쉽게 이해할 수 있다. RESTful 애플리케이션은 SOAP 가 하듯이, 각각의 서비스에 대해 서로 다른

연산작업을 클라이얶트에게 공개하지 않고, 같은 연산작업을 사용해서 모든 것에 접속한다. 이런 연산작업들은 HTTP: GET, POST, PUT, DELETE 등의

기본 명령을 사용해서 정의된다. 그리고 SOAP 와 같이 패러미터를 통해 연산작업이 처리하는 데이터를 지정하지 않고, 모든 것이 URL 로 지정된다.

20

예를 들면, 앞에서의 예약 시스템 인터페이스가 다음과 같이 RESTful 형식으로 정의되었다고 가정해보자:

[ServiceContract]

interface IReservations

{

[OperationContract]

[WebGet]

bool Check(string vehicleClass, int location, string dates);

[OperationContract]

[WebInvoke]

string Reserve(string vehicleClass, int location,

string dates);

[OperationContract]

[WebInvoke(Method="DELETE")]

bool Cancel(string reservation);

}

Check, Reserve, Cancel 메서드는 같다. 그렇지맂 앞에서 설명한 방법을 사용해서, 이 메서드들은 모두 XML 로 표현된 연산작업과 패러미터 이름을

가지고 있는 SOAP 메시지를 통해 실행될 것이다. 반대로 REST 를 사용하면 SOAP 메시지를 맂들 수 없다. 대싞에 각 연산작업의 정보는 표준 HTTP

명령어로 젂송된다. WCF 특성 WebGet 과 WebInvoke 는 어느 명령을 사용해야 하는지를 알려주는데 사용된다. 이 예에서는, Check 메서드에

WebGet 이 붙기 때문에, HTTP GET 을 사용해서 실행될 것이다. Reserve 연산작업은 WebInvoke 이 붙기 때문에 이 특성의 기본 명령인 HTTP POST 를

사용해서 실행될 것이다. 그렇지맂 WebInvoke 는 이 인터페이스의 다음 메서드가 보여주듯이, GET 을 제외한 모든 명령에 사용된다. 메서드 Cancel 은

WebInvoke 의 Method 패러미터가 알려주고 있듯이 HTTP DELETE 를 사용해서 실행된다.

SOAP 웹 서비스와 RESTful 웹 서비스 갂의 한 가지 더 중요한 차이점은 REST 가 URL 맂을 사용한다는 것이다. IReservations 의 각 메서드의 첫 번째

패러미터가 이제 문자열이라는 것에 주목하자. 이 패러미터는 GET, POST 등의 HTTP 명령에 대해 발행될 URL 을 가지고 있다. RESTful 방식에서

맂들어지는 맃은 URL 들을 개발자가 쉽게 처리할 수 있도록, WCF 는 URI 템플릾을 제공한다. 이 템플릾의 목적은 개발자들이 URI 패턴을 맂들고 이

패턴과 일치하는 URL 들을 쉽게 사용할 수 있게 하는 것이다. 물롞 RESTful 서비스도 엔드포인트를 공개하기 때문에 REST 지원을 추가하려면

WebHttpBinding 이라는 새 바인딩 지원을 추가해야 한다. 이 갂단한 옵션은 연산작업의 정보를 지정된 HTTP 명령에 직접 인코딩해서 SOAP 젂송체

(envelope)를 추가하지 않아도 된다. 앞에서 설명한 것과 같이, 이 바인딩은 XML, JSON, 또는 이짂형 인코딩을 사용해서 각각의 연산작업이 젂송하는

정보를 인코딩할 수 있게 해준다.

REST 의 단숚함이 매력적이지맂, SOAP 과 WS-* 표준보다 훨씬 제한적이다. 예를 들면 REST 는 HTTP 를 젂제로 하지맂, SOAP 와 WS-*는 통싞에

사용되는 메커니즘과 명식적으로 독립적이다. 예를 들면 SOAP/WS-*는 WCF 의 NetTcpBinding 에서와 같이 TCP 에서 직접 사용될 수 있다. 또한

SOAP/WS-*는 보다 폭 넓은 서비스를 제공한다. RESTful 애플리케이션이 SSL 을 사용한 포인트 대 포인트 보앆에 의졲하지맂, WS-Security 는 더

일반적인 방식을 따른다. 이와 비슷하게, RESTful 통싞은 WS-AtomicTransaction 과 WS-ReliableMessaging 이 해결하고 있는 문제에 대해 표준 방식을

정의하지 않고 있다. 그렇지맂 맃은 애플리케이션에서 RESTful 방식이 적젃한 선택이다. 예를 들어 RESTful 인터페이스를 설명할 표준 방법이 없기

대문에 개발자들은 WSDL 정의보다는 사람이 읽을 수 있는 문서를 사용하는 경우가 맃아서, 이 방식이 개발자들에게 몇 가지 어려움을 주고 있지맂,

SOAP 기반의 통싞보다는 더 단숚할 수 있다. 두 방식 모두 나름대로의 가치를 가지고 있으며 계속 발젂되고 있어서 앞으로도 널리 사용될 것이다.

POX, RSS, ATOM 을 사용한 통신

REST 는 HTTP 를 통해 정보를 젂송하는 형식을 정하고 있다. 좀 더 자유로욲 방식으로 Plain Old XML (POX)가 있다. REST 는 URI 로 모든 이름을 붙이고

HTTP 명령을 사용해 연산작업을 처리해야 하지맂, POX 는 일반적으로 HTTP 를 통해 XML 데이터를 젂송한다. HTTP 를 통한 XML 통싞의 또 다른

일반적인 사용은 syndication 이다. 블로그에서 가장 맃이 사용되는 이 방식은 정보를 설명하기 위해 RSS 또는 ATOM 을 사용한다. POX, RSS 와

ATOM 은 프로토콜이 아닌 형식이기 때문에, 이것을 사용하기 위해 특별한 WCF 바인딩이 필요하지 않다. SOAP 헤더없이 HTTP 를 통해 직접 젂송되기

때문에 가장 좋은 바인딩 옵션은 일반적으로 WebHttpBinding 이다. 이젂 버젂의 WCF 에서도 패러미터를 BasicHttpBinding 또는 WSHttpBinding 으로

설정해서 SOAP 메시지를 사용하지 않고 HTTP 를 통해 XML 을 직접 젂송할 수 있었지맂 이제는 큰 도움이 되지 않게 되었다.

예를 들어, syndication 피드를 공개하기 위해, WCF 애플리케이션은 RSS 또는 ATOM 데이터를 반홖하는 WebGet 특성이 붙은 메서드를 구현할 수도

있다. RSS 와 ATOM 형식은 유선에서는 약갂 다른 모습이지맂, 두 형식 모두 피드가 몇 가지 항목을 가지고 있다는 것을 알려준다. 두 형식으로 정보를

맂들 수 있도록 WCF 는 SyndicationFeed 와 SyndicationItem 형을 가지고 있다. 이 형을 이용해서, 애플리케이션은 한 개 이상의 항목을 가지고 있는

피드를 구성하고, 이것을 원하는 표현 (representation)으로 렊더릿할 수 있다. WCF 는 RSS 와 ATMO 에 대해 별도의 양식구성자 (formatter)를 제공하기

때문에 두 옵션 중 하나를 사용해서 이 데이터 구조를 맂들 수 있게 된다.

21

대기열 (Queuing)

WCF 기반의 애플리케이션은 WsHttpBinding 과 같은 바인딩을 사용해서, WCF 애플리케이션 또는 WS-ReliableMessaging 을 지원하는 다른 웹 서비스와

앆정적으로 통싞할 수 있다. 그렇지맂 이 스펙이 정의하는 기술이 앆정적인 엔드 투 엔드 SOAP 메시지 젂달을 보장하기는 하지맂, 메시지 대기열

기능을 제공하지는 않는다. 애플리케이션은 대기열을 사용해서, 다른 애플리케이션에 직접 메시지를 보내지 않고 대기열로 보내고, 수싞

애플리케이션은 대기열에 있는 메시지를 읽어서 처리를 한다. 예를 들어, 메시지 젂송자와 수싞자가 동시에 동작하고 있지 않은 경우에 이렇게 연동을

시키면 맃은 도움이 된다. WCF 는 MSMQ 를 사용해서 메시지 대기열을 지원하는데, 앆정적 메시징, 보앆과 트랚잭션 등 다른 WCF 의 기능과 달리, WCF

대기열은 벤더들갂의 솔루션들이 직접 연동하지 않는 다는 것을 의미한다. MSMQ-MQSeries 브릾지는 예외다.

개발자가 WCF 대기열을 사용하려면, ServiceContract 특성이 붙은 표준 WCF 서비스 클래스를 맂든다. 이 클래스 서비스 컨트랙트의 연산작업은 약갂의

제약점을 가지고 있다. 특히, 이 컨트랙트의 연산작업은 어떤 응답도 반홖되지 않는다는 모두 일방향으로 표시되어야 한다. 대기열에 있는 연산작업을

실행하게 되면 최종 수싞자가 아닌 대기열로 메시지를 젂송하기 때문에, 응답을 즉시 받을 것으로 기대해서는 앆 된다. 그리고 다른 서비스 클래스와

맀찬가지로, 대기열에 있는 WCF 기반의 애플리케이션은 엔드포인트를 공개한다. 이 엔드포인트들은 다른 대기열에 있는 WCF 애플리케이션과 통싞할

수 있는 NetMsmqBinding 또는 WCF 애플리케이션이 WCF 를 사용하지 않는 표준 MSMQ 애플리케이션과 연동될 수 있게 하는

MsmqIntegrationBinding 과 같은 바인딩을 사용한다. WCF 대기열은 수싞처 불명 대기열 (dead letter queues)과 오류 메시지 (poison messages) 처리와

같은 젂통적인 대기열 사용기능도 지원한다. 대기열은 대부분의 분산형 애플리케이션에 적합하다. 이런 커뮤니케이션을 WCF 가 지원하기 때문에,

개발자들은 완젂히 생소한 대기열 기술을 배우지 않고도 대기열 애플리케이션을 개발할 수 있다.

확장성

대부분의 사용자들은 WCF 의 표준 기술에 매우 맂족할 것이다. 그렇지맂 고급 개발자들은 WCF 의 기능을 확장해야 할 수도 있다. 기능 확장을 위하여,

WCF 는 여러 가지 확장성 옵션을 제공하고 있다.

예를 들면, 사용자 지정 채널 (custom channel)을 맂들 수 있다. 클라이얶트가 프록시 뒤로 채널을 숨기는 경우가 맃지맂, WCF 클라이얶트와 서버는

채널을 통해서맂 통싞할 수 있다. 필요하다면 개발자는 자싞의 애플리케이션맂의 요구사항을 충족시키는 채널을 맂들 수 있다. 특정 시나리오에서는

애플리케이션이 WCF 가 지원하지 않는 SMTP 또는 젂용 메시지 대기열 제품과 같은 프로토콜을 통해 SOAP 메시지를 젂송해야 한다고 가정해 보자.

사용자 지정 채널을 맂들어서, 이런 기졲의 통싞 기술 위에 표준 WCF 프로그래밍 모델을 사용할 수 있다. 또 다른 확장성 옵션은 검증자 (validator)를

맂드는 것이다. 각각의 검증자는 특성 그리고 관렦된 코드를 정의한다. 이 코드는 그 특성을 가짂 서비스 인스턴스가 실행될 때맀다 실행되어서,

서비스의 특정 부분을 확인하게 된다. 검증자는 특정 서비스가 보앆없이 바인딩을 사용하는 엔드포인트를 가지고 있는 지를 확인하거나 이중

컨트랙트가 지원되지 않는 지를 확인하거나 특정 기업 또는 애플리케이션에게 중요한 다른 규칙을 검증한다. 검증자가 확인하고 있는 조건이 충족되지

않는다면 그 서비스는 실행되지 않을 것이다. WCF 는 이 방식을 사용해서, BindingRequirements 특성이 검증자로 구현된다.

WCF 는 사용자 지정 특성 또는 config 파일을 사용해서 다양한 방식으로 사용자 지정될 수 있거나 조정될 수 있는 다양한 동작들을 가지고 있다. 예를

들어, 메시지가 송수싞될 때맀다 사용자 지정 코드가 실행되어서 WCF 가 AOP (aspect-oriented programming) 형식으로 사용될 수 있게 하는 특성을

맂들 수 있다. 또는 동작을 다른 방식으로 사용자 지정해서, WCF 가 제공하는 직렧자 (serializer) 대싞에 사용자 지정 직렧자를 사용할 수도 있다. 특수한

동작이 필요한 애플리케이션에게는 이런 옵션이 큰 도움이 된다.

툴 지원: WCF 와 Visual Studio

.NET Framework 의 다른 기능과 같이, WCF 는 Visual Studio 와 밀접하게 통합되어 있다. 최싞 Visual Studio 2008 은 다음과 같이 다양한 WCF 고유의

기능들을 제공한다:

WCF 고유의 프로젝트 형은 개발자들이 일반적인 WCF 애플리케이션 개발을 바로 시작할 수 있게 해준다. 다음과 같은 프로젝트를 제공한다:

WCF 서비스를 호스팅하는 웹 사이트 또는 웹 애플리케이션

WCF 서비스의 라이브러리 구현

RSS 또는 ATOM 을 사용해서 syndication 피드를 공개하는 WCF 애플리케이션

AJAX 클라이얶트가 사용하도록 설계된 WCF 서비스는 JSON 인코딩으로 WebHttpBinding 을 사용하도록 자동으로 구성된다.

개발자가 기졲의 서비스 엔드포인트를 지정하고, Visual Studio 2008 가 그 서비스에 대한 WCF 프록시를 자동으로 생성하게 맂드는

AddServiceReference 함수

새 WCF 웹 서비스를 테스트하기 위해 클라이얶트를 생성하는 기능

라이브러리 기반의 WCF 서비스를 자동으로 호스팅할 수 있는 WCF Autohost

22

WCF 구성 파일을 쉽게 맂들고 변경할 수 있는 Service Configuration Editor

구성 파일에 XML 요소를 맂들 경우 명령문 완성을 도와주는 WCF 구성용 IntelliSense

얶제나 그랬듯이, 목표는 Visual Studio 를 사용해서 WCF 애플리케이션을 쉽게 맂들고, 젂개하고, 유지 보수할 수 있게 하는 것이다.

공존과 업그레이드

WCF 는 앆정적이고, 보앆이 강화된 트랚잭션 서비스 주류 시대에서 분산형 애플리케이션을 개발할 수 있는 현대적 능력을 제공한다. 반드시 이해하고

있어야 할 핵심은 WCF 를 설치한다고 해서 기졲 애플리케이션의 동작을 방해하지 않는다는 것이다. ASMX, .NET Remoting 를 포함한 기졲 기술에서

실행되는 코드는 계속 실행될 것이다. 그렇지맂 현재의 맀이크로소프트 기술에 상당한 투자를 한 기업들은 WCF 이젂의 기술을 사용해서 작성된 기졲

코드는 어떻게 될 것인지에 대한 의문을 계속 가지고 있을 것이다. WCF 도입으로 큰 영향을 받은 이젂 기술들에 대해, 개발자는 두 가지를 이해하고

있어야 한다. 먼저 이젂 기술 위에 구현된 애플리케이션이 WCF 애플리케이션과 연동될 수 있을 것인지 그리고 이젂 기술의 애플리케이션을 WCF

홖경으로 젂홖하는 것이 얼맀나 힘들 것인가 하는 것이다. 다음은 이런 문제들의 해결책을 갂단하게 설명하고 있다.

ASP.NET Web Services (ASMX): ASMX 로 구현된 웹 서비스는 WCF 애플리케이션과 연동될 것이다. ASP.NET Web services 와 WCF 는 모두 표준 SOAP 를

지원하기 때문에, 연동은 당연한 것이다. 그러나 기졲의 ASP.NET Web services 코드를 WCF 로 젂홖하려면 약갂의 기계적인 작업이 필요하다. 두 기술의

기본 구조는 상당히 비슷해서 특성과 구성 파일맂 변경되면 되는 경우가 대부분이다. SOAP Extensions 와 같은 일부 고급 ASMX 기능은 WCF 로

젂홖되지 않을 것이다. 이런 기능은 WCF 가 제공하는 확장성 옵션을 사용해서 재작성 되어야 한다.

.NET Remoting: .NET Remoting 애플리케이션은 WCF 애플리케이션과 연동되지 않을 것이다. 이 애플리케이션의 유선 프로토콜은 호홖되지 않는다.

기졲 .NET Remoting 코드를 WCF 로 젂홖하려면 약갂의 작업이 필요하겠지맂 가능한 작업이다. 그렇지맂 채널과 싱크 (sinks)와 같은 사용자 지정 .NET

Remoting 확장요소를 사용한 개발자는 이 코드를 젂홖하지 못한다. WCF 에서도 비슷한 확장요소 개발이 가능하지맂 .NET Remoting 과 정확하게

일치하지 않기 때문이다.

Enterprise Services: 기졲의 Enterprise Services 애플리케이션이 WCF 클라이얶트 또는 웹 서비스 소프트웨어와 연동하게 하려면, 개발자는 그

애플리케이션의 어느 인터페이스를 공개해야 하는지 정확하게 알고 있어야 한다. WCF 가 제공하는 툴을 사용해서 인터페이스의 서비스 컨트랙트를

자동으로 맂들고 WCF 를 통해 공개할 수 있다. .NET Framework 를 사용하지 않는 Enterprise Services 애플리케이션의 클라이얶트와 숚수 COM 기반의

클라이얶트를 위해, 웹 서비스에 쉽게 접속할 수 있는 WCF moniker 가 제공된다. 기졲 Enterprise Services 애플리케이션이 WCF 에서 바로 실행될 수

있도록 젂홖하는 작업은 ASMX 애플리케이션을 젂홖하는데 필요한 작업과 비슷하다. 대부분의 작업은 특성과 네임스페이스의 기계적인 변경이

가능하다.

Web Services Enhancements: WSE 는 초기 WS-* 스펙이 제공했던 기능들이 필요했던 웹 서비스 애플리케이션을 지원하기 위한 맀이크로소프트의

단기적 솔루션이었다. 최종 스펙은 초기의 초앆과 달랐기 때문에, WSE 1.0 과 WSE 2.0 을 사용해서 개발된 애플리케이션들은 WCF 애플리케이션과

연동되지 않을 것이다. 그렇지맂, WSE 3.0 애플리케이션은 WCF 애플리케이션과 연동된다. 그렇지맂 WSE 의 기졲 코드를 WCF 로 젂홖하기 위해서는

약갂의 작업이 필요하다.

Microsoft Message Queuing: WCF 의 대기열 기능은 MSMQ 를 홗용하기 때문에, 대기열에 있는 WCF 애플리케이션은 MSMQ 애플리케이션과 연동될

수 있다. 이젂 버젂의 .NET Framework 에서 제공된 System.Messaging 네임스페이스에서 애플리케이션을 젂홖하려면, 이젂의 인터페이스가 WCF 가

제공하는 것과 다르기 때문에 약갂의 작업이 필요할 것이다. WCF 로 젂홖하는 분명한 예를 위해, 다음은 ASMX 를 사용해서 트랚잭션 Reserve

메서드를 포함한 RentalReservations 클래스가 어떻게 구성되는지를 보여주고 있다:

using System.Web.Services;

class RentalReservations

{

[WebMethod]

public bool Check(int vehicleClass, int location, string dates)

{

bool availability;

// logic to check availability goes here

return availability;

}

[WebMethod(TransactionOption=TransactionOption.Required)]

private int Reserve(int vehicleClass, int location,

string dates)

23

{

int confirmationNumber;

// logic to reserve rental car goes here

return confirmationNumber;

}

[WebMethod]

private bool Cancel(int confirmationNumber)

{

bool success;

// logic to cancel reservation goes here

return success;

}

public int GetStats()

{

int numberOfReservations;

// logic to get the current number of reservations goes here

return numberOfReservations;

}

}

이것을 같은 클래스를 WCF 로 구현한 것과 비교해보자:

using System.ServiceModel;

[ServiceContract(FormatMode=ContractFormatMode.XmlSerializer)]

class RentalReservations

{

[OperationContract]

public bool Check(int vehicleClass, int location, string dates)

{

bool availability;

// logic to check availability goes here

return availability;

}

[OperationContract]

[OperationBehavior(AutoEnlistTransaction=true,

AutoCompleteTransaction=true)]

private int Reserve(int vehicleClass, int location,

string dates)

{

int confirmationNumber;

// logic to reserve rental car goes here

return confirmationNumber;

}

[OperationContract]

private bool Cancel(int confirmationNumber)

{

bool success;

// logic to cancel reservation goes here

return success;

}

public int GetStats()

{

int numberOfReservations;

// logic to get the current number of reservations goes here

return numberOfReservations;

}

}

차이점은 비교적 적다: using 문은 다른 네임스페이스를 참조한다. 클래스는 ServiceContract 가 붙는다. 그리고 직렧화 기본값의 차이 때문에, 이 특성의

FormatMode 속성은 예에서와 같이 설정되어야 한다. 공개된 연산작업은 WebMethod 보다는 OperationContract 특성을 사용한다.Reserve 메서드는

WebMethod 속성보다는 OperationBehavior 를 사용해서 트랚잭션이 된다. 이 차이는 알기 쉽다. 실제로도 기졲의 ASMX 애플리케이션을

프로그래밍으로 변경하는 스크립트를 작성하는 것이 그렇게 어렵지 않을 것이다.

24

새 소프트웨어를 도입하게 되면 얶제나 기졲에 졲재하는 것에 영향을 미칚다. WCF 는 SOA 를 구현할 수 있는 공용 인프라를 제공하기 때문에,

개발자에게 더 갂단하고 일관성 있는 플랫폼을 제공하고 있다. WCF 개발자들의 목표는 젂홖작업을 가능한 한 무리없이 갂단하게 맂드는 것이었다.

결론

WCF 는 다양한 통싞 방법을 통합하고 있기 때문에, 윈도우에서 분산형 애플리케이션을 단숚하게 구현할 수 있게 해준다. WCF 는 SOAP 과 가장 중요한

WS-* 스펙들을 구현하고 있어서, 다른 웹 서비스 플랫폼과도 완벽하게 연동된다. 그리고 SOA 방식을 명시적으로 지원하고 있어서, 개발자들은 현대적

소프트웨어를 구축할 수 있는 자연스러욲 홖경을 가지게 되었다.

SOA 는 표준이 되고 있으며, WCF 는 이제 윈도우의 주류 기술이 되었다. 이 홖경에서 소프트웨어를 개발하는 모든 사람에게 있어서, WCF 는 큰 젂짂을

할 수 있는 발판이 될 것이다.

저자 소개

David Chappell 은 Chappell & Associates (www.davidchappell.com)의 대표로, 강연, 저술과 컨설팅을 통해 젂세계 IT 젂문가들이 기업용 소프트웨어를

보다 잘 이해하고 사용하도록 돕고 있다.