glycerine :: 서른의 시작

책을 보며 느낀것 이지만 이번 챕터는 WCF 만 제한된 내용은 아닙니다.
아키텍처가 되자. 라는 얘기가 생각나네요.

개요

인터페이스(또는 클래스)를 서비스 지향적인 계약으로 노출

è  언어의 인터페이스 등의 기능을 이용해 프로그래밍: WCF 서비스와 계약으로 제공

 

1.     Operation 오버로딩

 

Interface ICalculator {    Int Add(int arg1, int arg2);    Double Add(double arg1, double arg2); }

 

C++이나 C# 등의 프로그래밍 언어는 이름은 같지만 파라미터의 타입이나 수가 다른 메서드의 오버로딩을 지원하고 있다. 중요한 건 Operation 오버로딩은 개념상 WSDL 기반의 동작에서는 동작할 수 없다는 것이다. 따라서 다음과 같은 계약은 컴파일이 가능하지만 서비스 호스트 로드 시 Invalid operationException 예외를 발생시킨다.

 

하지만 수동으로 Operation 오버로딩을 가능하게 설정할 수 있다. 그 방법은 OperationContract 애트리뷰트의 Name 속성을 이용하여 Operation의 가칭을 지어 주는 것이다.

 

[ServiceContract] Interface ICalculator {    [OperationContract(Name = “AddInt”)]    Int Add(int arg1, int args2);       [OperationContract(Name = “AddDouble”)]    Double Add(double arg1, double arg2); }

 

클라이언트에서도 참조한 계약의 Name 프로퍼티를 이용하여 참조된 Opetion과 동일한 이름의 가칭(별칭)을 주어 메서드를 오버로딩 할 수 있다.

 

[ServiceContract] Public interface ICalculator {    [OperationContract(Name = “AddInt”)]    Int Add(int arg1, int arg2);      [OperationContract(Name = “AddDouble”)]    Double Add(double arg1, double arg2); }   Public partial class CalculatorClient : ClientBase<ICalculator>, ICalculator {    Public int Add(int arg1, int arg2)    {       Return Cahnnel.Add(arg1, arg2);    }      Public double Add(double arg1, double arg2)    {       Return Channel.Add(arg1, arg2);    } }

 

이렇게 하여 클라이언트는 Operation 오버로딩을 통하여 읽기 쉽고 자연스러운 프로그래밍 모델로 구현할 수 있다.

 

CalculatorClient proxy = new CalculatorClient();   Int result1 = proxy.Add(1, 2); Double result2 = proxy.Add(1.0, 2.0);   Proxy.Close();

 

2.     계약의 상속

 

서비스 계약의 인터페이스는 각각 파생할 수 있고, 계약의 계층으로 정의하여 이용할 수 있지만, ServiceContract 애트리뷰트는 상속이 불가능하다. 따라서 인터페이스의 모든 계층은 명백한 ServiceContract 애트리뷰트를 가지고 있어야 한다.

 

호스트는 최종적으로 상속받은 인터페이스로 하나의 엔드 포인트를 노출시킬 수 있다.

 

<service name = “MyCalculator”>    <endpoint       Address = http://localhost:8001/MyCalculator/       Binding = “basicHttpBinding”       Contract = “IScientificCalculator”    /> </service>

 

인터페이스를 상속하여 정의된 서비스 엔드 포인트의 메타 데이터를 클라이언트가 참조하게 되면 클라이언트의 계약은 상속 계층을 유지하지 않고, 하나의 계약 안에 포함되어 구성한다. 즉, 그 계약은 기존의 인터페이스들에서 가졌던 모든 Operation이 하나의 계약으로 조합된다. 또한 참조된 계약의 모든 메서드는 하나의 프록시를 통해 구현된다.

 

추가사항: 클라이언트에서 상속의 재구성

 

3.     서비스 계약의 설계 및 팩토링

 

서비스 계약에 대한 디자인을 어떻게 할 것인가?

어느 계약에 어느 동작들을 포함시킬 것인가?

서비스 계약에는 얼마나 많은 동작들을 가지는 것이 좋은가?

è  서비스 지향적 분석 및 설계

 

WCF 에서 만의 내용이 아닌 객체지향 프로그램으로 생각하자. 서비스 계약을 분해할 때 언제나 재사용적인 관점들을 생각해야 한다.

 

간단한 예를 통해 생각해보자.

강아지 서비스 모델을 만들고 싶다고 가정해보자. 이 서비스의 요구 사항을 살펴보면 강아지는 짖을 수 있거나 물어 오기 놀이를 할 수 있다. 또한 가출병원의 등록 번호를 가지고 있고 백신 접종도 할 수 있을 것이다. 즉, IDog 서비스 계약을 정의할 수 있고 PoodleService, GermanShepherdService와 같은 서비스의 종류도 정의할 수 있을 것이다.

 

[ServiceContract] Interface IDog {    [OperationContract]    Void Fetch();      [OperationContract]    Void Bark();      [OperationContract]    Long GetVetClinicNumber();      [OperationContract]    Void Vaccinate(); }   Class PoodleService : IDog { … }   Class GermanShepherdService : IDog { … }

 

하지만 IDog 서비스 계약의 구성은 요소화가 잘 되었다고 보기 어렵다. Fetch()와 Bark() 같은 경우는 논리적으로 관련이 있지만 GetVetClinicNumber()와 Vaccinate()는 논리성이 조금 떨어진다. Fetch()와 Bark()는 개가 가지고 있는 특성의 한 요소지만 GetVetClinicNumber()와 Vaccinate()는 다른 동물들도 가지고 있는 요소이기 때문이다.

 

[ServiceContract] Interface IPet {    [OperationContract]    Logn GetVetClinicNumber();      [OperationContract]    Void Vaccinate(); }   [ServiceContract] Interface IDog {    [OperationContract]    Void Fetch();      [OperationContract]    Void Bark(); }

 

더 나은 요소화적인 서비스를 위해 IPet 인터페이스를 생성해서 GetVetClinicNumber() 와 vaccinate() 동작을 분리 시켰다. 이렇게 강아지과의 동물을 구별해 놓으면 서비스 계약의 재사용성이 가능하기 때문이다.

 

이러한 유형에서 각각의 독립된 계약으로 정의하지 않고 계약들의 상속으로 서비스를 요소화 할 수 있다.

 

팩토링

서비스 계약은 하나의 동작을 갖는 것이 가능하지만 이것은 피해야 할 것이다. 서비스 계약은 어떤 개체의 특징 중 하나인데 만약 한 가지 동작으로 표현 가능하다면 그 특징은 꽤 단조로운 편이라고 할 수 있다. 이 한 동작에 대해 다음을 생각해 보자. 너무 많은 파라미터를 사용하고 있지는 않은지? 너무 조잡하여 여러 개의 동작으로 나누는 것이 좋지 않은지? 기존에 존재하는 다른 서비스 계약에 포함시켜야 하지 않은지?

 

동작들을 요소화한 후에 각각의 동작들이 너무 세분화 되어 있지는 않은지를 살펴봐야 한다. 만약 12개 이상의 동작을 가지고 있다면 서비스 계약의 상속이나 서비스 계약의 분리로 요소화할 수 있는 방법을 정확하게 찾아 적용해야 할 것이다. 또한 코딩 표준을 정해 경우에 상관없이 넘지 말아야 할 상한선을 정하는 것이 좋다.

(최적 멤버 수는 3~5개, 서비스 계약 안의 동작들은 6~9개의 동작이 적당)

 

추가사항: 계약 쿼리

정리 노트 랄까요.
대단한건 아닙니다. 마치 강의 시간 필기 노트의 그것처럼.
강의를 들으려고 Programming WCF 책을 지난 주말에 구입했습니다.
지금부터 그 노트를 공개해볼까 합니다.

1.     WCF 소개

: 윈도우 기반의 서비스를 개발하고 배포하기 위한 기술.

è  서비스 상호 작용.  커뮤니케이션 타입, 마샬링, 그리고 여러 프로토콜 관리 등을 정의하는 업계 표준의 마이크로소프트사의 구현.

: 여러 서비스들 간의 상호 운용성 제공.

è  호스팅, 서비스 인스턴스 관리, 비동기 호출, 신뢰도, 트랜잭션 관리, 비연결 큐 호출 기능 제공.

 

2.     서비스

: 외부에 노출되는 기능의 한 단위.

미리 규약 된 통신 패턴들만 통신으로 이용.

: 서비스와 클라이언트는 메시지(SOAP 구조)를 주고 받으며 서로 상호 작용.

    메시지? 웹 서비스와 달리 전송 프로토콜로부터 독립적.

 

è  HTTP 뿐만 아니라 다양한 프로토콜에서도 통신 가능

è  WCF 기반이 아닌 다른 서비스들과 통신 가능.

 

서비스의 구성? 외부에서 보았을 때는 불투명하기 때문에 WCF 서비스는 서비스에서 사용 가능한 기능과 통신 방식을 기술하는 메타 데이터를 이용하여 노출(서비스 제공).

-       메타 데이터는 미리 정의된 HTTP-GET 방식의 WSDL이나 메타 데이터 노출을 위해 업계 표준과 같은 기술로 배포.

 

3.     주소 (Address)

: 모든 서비스는 주소를 가지며, 이 주소는 서비스가 사용하고 있는 서비스 위치와 서비스의 전송 프로토콜인 전송 스키마 정보를 제공.

: 주소 포맷

[전송계층] : // [machine 혹은 domain] [ : 추가적인 포트] / [추가적인 URI]

http://localhost:8000

net.tcp://localhost:8002/MyService

net.msmq://localhost/private/MyService

 

읽는 방법? http://localhost:8001/MyService

è  HTTP 전송 계층을 사용하고 있고, localhost라는 이름을 갖는 머신의 8001번 포트의 MyService가 호출을 기다리고 있다.

 

: 지원 통신 스키마

è  HTTP, TCP, Peer network, IPC(명명된 파이프 위의 Inter-Process 통신), MSMQ

4.     계약 (Contract)

: 모든 서비스는 한 개 이상의 계약을 노출한다.

  계약? 서비스가 무엇을 하는지에 대해 플랫폼 중립적이고 표준적인 방식으로 설명하는 방법

 

종류

è  서비스 계약 (Service Contracts)

서비스에서 클라이언트가 어떤 동작들을 수행할 수 있는지를 설명

è  데이터 계약 (Data Contracts)

서비스와 주고받는 데이터 타입을 정의하는 계약

è  오류 계약 (Fault Contracts)

서비스로부터 어떤 에러가 발생하는지, 이 에러들을 서비스가 어떻게 처리하고 클라이언트에 전달하는지를 정의.

è  메시지 계약 (Message Contracts)

주고받을 메시지와 직접 상호 작용할 수 있게 해준다.

 

서비스 계약의 정의와 구현 예제

: ServiceContract를 사용했을 때 그 타입의 멤버를 노출하기 위해서 OperationContract를 메소드에 지정. (프로퍼티, 인덱스, 이벤트와 같은 CLR 타입에는 적용 불가)

[ServiceContract] Interface IMyContract {    [OperationContract]    String MyMethod(string text);      // 계약에 포함되지 않는다.    String MyOtherMethod(string text); } Class MyService : IMyContract {    Public string MyMethod(string text)    {       Return “Hello ” + text; } Public string MyOtherMethod(string text) {    Return “Cannot call this method over WCF”; } }

5.     호스팅

: 모든 WCF 서비스는 호스트를 제공하는 윈도우 프로세스 안에 호스팅 되어야 한다.

 

è  IIS 호스팅

클라이언트의 요청으로 프로세스가 자동적으로 실행되고 호스트 프로세스의 생명 주기를 IIS에서 관리

HTTP 전송 계층만 호스팅 가능할 수 있다는 단점.

 

CLR 코드

Public static void Main() {    Uri tcpBaseAddress = new Uri(“net.tcp://localhost:8001/”);    Uri httpBaseAddress = new Uri(http://localhost:8002/);      ServiceHost host = new ServiceHost(typeof(MySerivce), tcpBaseAddress, httpBaseAddress); }

 

설정파일 (Web.config 나 App.config)

<system.serviceModel>    <services>       <service name=”MyNamespace.MyService”>          <host>             <baseAddresses>                <add baseAddress=”net.tcp://localhost:8001/” /> <add baseAddress=”http://localhost:8002/” /> </baseAddresses>          </host>       </service>    </services> </system.serviceModel>

 

è  WAS 호스팅

IIS와 달리 HTTP에 한정되지 않고 다른 여러 WCF 통신 및 포트를 사용 할 수 있다.

(애프릴케이션 풀링, 재사용, idle time 관리, identity 관리, 분리)  

 

6.     바인딩 (Binding)

: 서비스는 여러 가지 관점과 많은 패턴을 가지고 있다.

è  메시지의 경우 동기 방식의 request/reply 나 비동기 방식의 fire-and-forget 방식을 이용할 수 있고, 양방향 통신이나 여러 가지 큐 기반의 통신이 존재..

è  HTTP, TCP, P2P, IPC, MSMQ와 같은 여러 전송 계층 이용

è  성능을 위해 바이너리 인코딩 사용

è  큰 용량의 데이터를 위해 MTOM 방식 사용

위와 같은 선택들을 간단하게 하고 더 편하고 효율적으로 관리하기 위해서 바인딩 제공.

즉, 전송 계층, 메시지 인코딩, 통신 패턴, 신뢰도, 보안, 전파, 상호 운용성과 같은 항목들을 조합한 설정.

 

표준 바인딩

è  Basic 바인딩

BasicHttpBinding 클래스. 기본적인 ASMX 웹 서비스와 같은 WCF 서비스를 노출하도록 설계. (옛 클라이언트들이 새 서비스를 사용할 수 있도록 설계)

è  TCP 바인딩

NetTcpBinding 클래스. 신뢰도, 트랜잭션, 보안 제공. WCF-to-WCF 통신에 최적화.

è  Peer network 바인딩

NetPeerTcpBinding 클래스. Peer 네트워크가 가능한 클라이언트와 서비스들은 동일한 그리드에 접속하여 메시지를 브로드캐스팅 방식으로 전송.

è  IPC 바인딩

NetNamedPipeBinding 클래스. 같은 머신 안에서 명명된 파이프 계층 이용. (밖에서 호출 X, 안전한 바인딩)

è  WS 바인딩

WSHttpBinding 클래스. HTTP 전송 계층 사용. 신뢰도, 트랜잭션, 보안 속성 제공

è  Federated WS 바인딩

WSFederationHttpBinding 클래스

è  Duplex 바인딩

WSDualHttpBinding 클래스. 양방향 통신을 제공. WS 바인딩과 같다.

è  MSMQ 바인딩

NetMsmqBinding 클래스. MSMQ 전송 계층을 사용하고 비연결 기반으로 큐를 호출 하는 것을 지원.

è  MSMQ integration 바인딩

MsmqIntegrationBinding 클래스. WCF 메시지를 MSMQ 메시지로 변환하여 MSMQ를 사용하는 다른 환경의 시스템과 상호 운용  

 

7.     엔드 포인트(끝점) => Address + Binding + Contract

: 모든 서비스는 서비스의 위치를 위한 주소(Address)와 통신 방법을 정의하고 있는 바인딩(Binding), 그 서비스가 무엇을 하는지를 정의하는 계약(Contract)으로 구성. WCF는 이 셋의 관계를 엔드 포인트(끝점)라는 형식으로 표현하고 위 3가지 요소로 구성.

 

: 즉, 모든 엔드 포인트는 이 세가지 요소를 가지고 있어야만 하며, 호스트를 통해 노출된다. 또한, 모든 서비스는 최소한 하나의 엔드 포인트를 구성하여 노출해야 하며, 각각의 엔드 포인트는 정확한 하나의 계약을 가지고 있어야 한다.

 

CLR 코드

Public static void Main() {    Uri tcpBaseAddress = new Uri(“net.tcp://localhost:8001/”);    Uri httpBaseAddress = new Uri(http://localhost:8002/);      Binding wsBinding = new WSHttpBinding();    Binding tcpBinding = new NetTcpBiding();      // 트랜잭션 서비스 가능하게 설정.    tcpBinding.TransactionFlow = true;      // 다중 EndPoint 설정    ServiceHost host = new ServiceHost(typeof(MySerivce));    host.AddServiceEndpoint(typeof(IMyContract), wsBinding, httpBaseAddress);    host.AddServiceEndpoint(typeof(IMyContract), tcpBinding, tcpBaseAddress);       host.Open(); }

 

설정 파일

<system.serviceModel>    <services>       <service name=”MyNamespace.MyService”>          <endpoint             Address=”net.tcp://localhost:8000/MyService”             BindingConfiguration=”TransactionalTCP”             Binding=”netTcpBinding”             Contract=”IMyContract”          />       </service>    </services>    <bindings>       <netTcpBinding>          <binding name=”TransactionalTCP” transactionFlow=”true” />       </netTcpBinding>    </bindings> </system.serviceModel>

 

8.     메타 데이터의 교환

: 서비스는 HTTP-GET 방식을 이용하거나 메타 데이터 전용으로 만든 엔드 포인트를 사용하여 메타 데이터(Metadata)를 노출. (ServiceBehavior 설정에서 enable 속성을 설정하면 HTTP-GET 방식으로 메타 데이터를 자동으로 노출.)

 

CLR 코드

ServiceHost host = new ServiceHost(typeof(MyService));   ServiceMetadataBehavior metadataBehavior; metadataBehavior = host.Description.Behaviors.Find<ServiceMetadataBehavior>();   if(metadataBehavior == null) {    metadataBehavior = new ServiceMetadataBehavior();    metadataBehavior.HttpGetEnabled = true;    host.Description.Behaviors.Add(metadataBehavoir); }   host.Open();

 

설정 파일

<system.serviceModel>    <services>       <service name=”MyService” behaviorconfiguration=”MEXGET”>          <endpoint             Address=”net.tcp://localhost:8000/MyService”             BindingConfiguration=”TransactionalTCP”             Binding=”netTcpBinding”             Contract=”IMyContract”          />       </service>    </services>    <behaviors>       <serviceBehaviors>          <behavior name=”MEXGET”>             <serviceMetadata httpGetEnabled = “true” />          </behavior>       </serviceBehaviors>    </behaviors> </system.serviceModel>

 

9.     클라이언트 프로그래밍

: 클라이언트가 서비스의 동작을 호출하기 위해서 먼저 서비스 계약을 보고 해석.

è  클라이언트가 WCF를 이용하고 있다면 일반적으로 프록시를 이용할 것

프록시? 서비스의 계약을 나타내고 단일 CLR인터페이스를 노출하는 클라이언트의 CLR 클래스 서비스에서 여러 개의 계약들을 지원하고 있다면 클라이언트는 각각의 계약에 매칭하는 프록시를 필요로 하게 된다. 또한 서비스의 게약과 같은 동작을 제공하며 서비스를 연결하고 프록시 생명 주기를 관리하기 위한 추가적인 메소드를 추가한다.

 

è  비주얼 스튜디오 [Add Service Reference…]

è  SvcUtil

SvcUtil http://localhost/MyService/MyService.scv /out:Proxy.cs

 

10.   CLR 코드와 설정 파일

: 이 두 가지 설정 방법은 상호 보완적이라 할 수 있다.

è  설정 파일

재빌드나 재배포 없이 서비스의 주요한 옵션을 변경할 수 있다.

단 타입이 안전하지 않다는 것과 컴파일이 아닌 런타임 시에 그 에러가 발생한다는 것이 문제점.

è  CLR 코드

해당 설정이 특정 조건, 현재 입력 값 등과 같은 런타임 시에만 알 수 있는 것들에 의해 결정되는 경우나 해당 설정이 한 번 정해지면 절대 바뀌지 않을 경우에 유용.

 

: CLR 코드는 동적으로 설정을 추가할 때 유용하며, 설정 파일은 정적이고 변하지 않을 경우에 유용하다. (대부분의 클라이언트와 서비스는 설정 파일을 자주 사용.) 

 

11.   채널 설정 작업

: 프록시 클래스를 이용하지 않고 서비스에서 동작 중인 채널들을 직접적으로 사용할 수 있다 -> ChannelFactory<T> 클래스는 필요할 때 바로 프록시를 생성하는 것이 가능

 

ChannelFactory<IMyContract> factory = new ChannelFactory<IMyContract>();   IMyContract proxy1 = factory.CreateChannel(); Using(proxy1 as IDisposable) {    Proxy1.MyMethod(); }   IMyContract proxy2 = factory.CreateChannel(); Proxy2.MyMethod(); ICommunicationObject channel = proxy2 as ICommunicationObject; Debug.Assert(channel != null); Channel.Close();

 

12.   신뢰도

: 전송 계층의 신뢰도와 메시지의 신뢰도로 구분.

è  전송 계층의 신뢰도

패킷의 순서 그리고 패킷이 두 지점 간에 제대로 전달된다는 것을 네트워크 패킷 수준에서 보장. (중간에 끊기면 곧바로 대응하기 힘들다)

è  메시지 신뢰도

메시지를 배달하는 것에 대한 보증과 메시지의 순서에 대한 보증을 제공

연결이 끊겨 전송이 실패할 경우 다시 메시지를 전송.

메시지 버퍼링이나 플로 제어, 폭주와 같은 것들을 자동으로 관리.

연결을 확인하고 더 이상 필요하지 않을 경우 스스로 정리하는 등의 관리 기능 제공.

 

바인딩 이름	신뢰도 지원	신뢰도 기본지원	메시지 순서 보증	메시지 순서 기본 보증
BasicHttpBinding	No	N/A	No	N/A
NetTcpBinding	Yes	Off	Yes	On
NetPeerTcpBinding	No	N/A	No	N/A
NetNamedPipeBinding	No	N/A(On)	Yes	N/A(On)
WSHttpBinding	Yes	Off	Yes	On
WSFederationHttpBinding	Yes	Off	Yes	On
WSDualHttpBinding	Yes	On	Yes	On
NetMsmqBinding	No	N/A	No	N/A
MsmqIntegrationBinding	No	N/A	No	N/A

 

TCP 바인딩의 신뢰도 설정 예제

<system.serviceModel>    <services>       <service name=”MyService”>          <endpoint             Address=”net.tcp://localhost:8000/MyService”             Binding=”netTcpBinding”             bindingConfiguration=”ReliableTCP”             contract=”IMyContract”          />       </service>    </services>    <bindings>       <netTcpBinding>          <binding name=”ReliableTCP”>             <reliableSession enabled=”true” />          </binding>       </netTcpBinding>    </bindings> </system.serviceModel>

 

 

 

 

용어	정의
계약 (contract)	계약은 계약의 특정 형식에 대한 지원 사양입니다. 예를 들어, 서비스 계약은 작업 그룹의 사양입니다. WCF에서 계약은 System.ServiceModel.Description 네임스페이스에 있는 설명 개체에 미러링되는 계층 구조를 가집니다. 서비스 계약은 WCF에서 가장 큰 계약 범위입니다. 서비스 계약에 있는 각 서비스 작업에는 작업에서 교환할 수 있는 메시지(오류 메시지 포함) 및 교환 방향을 지정하는 작업 계약이 포함됩니다. 작업의 각 메시지에는 메시지 계약, SOAP 메시지 봉투의 구조에 대한 사양이 포함되고, 각 메시지 계약에는 메시지에 포함된 데이터 구조를 지정하는 데이터 계약이 포함됩니다.
구성 (configuration)	구성은 개발자 이외의 다른 담당자(예: 네트워크 관리자)가 코드를 기록한 후 다시 컴파일 할 필요 없이 클라이언트 및 서비스 매개 변수를 설정할 수 있는 이점이 있습니다. 구성을 사용하면 끝점 주소와 같은 값을 설정할 수 있을 뿐만 아니라 끝점, 바인딩 및 동작을 추가하여 보다 세부적인 제어를 수행할 수 있습니다. 코딩이나 구성을 사용하여, 또는 두 가지를 모두 사용하여 응용 프로그램을 제어할 수 있습니다.
끝점 (endpoint)	끝점은 메시지가 전송 및/또는 수신되는 구문입니다. 끝점은 메시지가 전송될 수 있는 장소를 정의하는 위치(주소), 메시지가 전송되는 방법을 설명하는 통신 메커니즘의 사양(바인딩) 및 전송될 수 있는 메시지를 설명하는 위치에서 전송 및/또는 수신될 수 있는 메시지 집합의 정의(서비스 계약)로 구성됩니다. WCF 서비스는 끝점 컬렉션으로 전역에 노출됩니다.
데이터 계약 (data contract)	서비스가 사용하는 데이터 형식은 다른 서비스와 해당 서비스가 상호 운용될 수 있도록 메타데이터로 설명해야 합니다. 데이터 형식에 대한 설명을 데이터 계약이라고 하며 형식은 예를 들어 매개 변수 또는 반환 형식과 같이 메시지 일부로 사용할 수 있습니다. 서비스가 간단한 형식만 사용하는 경우 명시적으로 데이터 계약을 사용할 필요가 없습니다.
동작 (behavior)	동작은 서비스, 끝점, 특정 작업 또는 클라이언트의 다양한 런타임 측면을 제어하는 구성 요소입니다. 동작은 범위에 따라 그룹화됩니다. 일반 동작은 모든 끝점에 전역적으로 영향을 주고 서비스 동작은 서비스 관련 측면에만 영향을 주며, 끝점 동작은 끝점 관련 속성에만 영향을 주고 작업 수준 동작은 특정 작업에 영향을 줍니다.
메시지 (message)	메시지는 본문 및 헤더를 포함하여 여러 부분으로 구성될 수 있는 독립적인 데이터 단위입니다.
메시지 계약 (message contract)	메시지 계약은 메시지 형식을 설명합니다. 예를 들어, 메시지 요소가 헤더 또는 해당 본문에 삽입되어야 할지 여부, 메시지 요소에 적용되어야 하는 보안 수준 등을 선언합니다.
메시지 보안 모드 (message security mode)	메시지 보안 모드는 하나 이상의 보안 사양을 구현하여 보안을 제공하도록 지정합니다. 각 메시지에는 전송 중에 보안을 제공하고 수신자가 변조를 감지하거나 메시지를 해독하는 데 필요한 메커니즘이 포함되어 있습니다. 따라서 보안은 모든 메시지 내에 캡슐화되어 여러 홉 전반에 걸쳐 종단 간 보안을 제공합니다. 보안 정보가 메시지의 일부이기 때문에 여러 종류의 자격 증명을 메시지에 포함시킬 수도 있습니다. 이러한 자격 증명을 클레임이라고 합니다. 또한 이러한 접근 방식은 원본 및 대상 간 여러 전송을 포함하여 메시지가 전송을 통해 안전하게 전달될 수 있는 이점이 있습니다. 그러나 관련 암호화 메커니즘이 복잡하기 때문에 성능이 떨어질 수 있다는 단점이 있습니다.
메시지 자격 증명을 사용한 전송 보안 모드 (transport with message credential security mode)	이 모드는 전송 계층을 사용하여 기밀성, 인증 및 메시지 무결성을 제공하는 동시에 각 메시지에는 메시지 수신자에게 필요한 여러 자격 증명(클레임)이 포함될 수 있습니다.
메타데이터 (metadata)	서비스 메타데이터는 서비스와 통신하기 위해 외부 엔터티가 이해해야 하는 서비스 특성을 설명합니다. ServiceModel Metadata 유틸리티 도구(Svcutil.exe)에서 메타데이터를 사용하여 서비스와 상호 작용하는 데 클라이언트 응용 프로그램이 사용할 수 있는 WCF 클라이언트 및 관련 구성을 생성할 수 있습니다. 서비스에 의해 노출된 메타데이터에는 서비스의 데이터 계약을 정의한 XML 스키마 문서와 서비스의 메서드를 설명하는 WSDL 문서가 포함되어 있습니다. 사용할 경우 서비스와 끝점을 검사하여 WCF에 의해 서비스 메타데이터가 자동으로 생성됩니다. 서비스에서 메타데이터를 게시하려면 명시적으로 메타데이터 동작을 사용해야 합니다.
바인딩 (binding)	바인딩은 끝점이 전역에서 통신하는 방법을 정의합니다. 바인딩은 통신 인프라를 만들기 위해 요소 위에 다른 요소를 "스택"하는 바인딩 요소라는 구성 요소 집합으로 구성됩니다. 최소한 바인딩은 사용할 전송(예: HTTP 또는 TCP) 및 인코딩(예: 텍스트 또는 이진)을 정의합니다. 바인딩은 메시지 보안을 위해 사용되는 보안 메커니즘 또는 끝점에서 사용하는 메시지 패턴과 같은 세부 사항을 지정하는 바인딩 요소를 포함할 수 있습니다.
바인딩 요소 (binding element)	바인딩 요소는 전송, 인코딩, 인프라 수준 프로토콜의 구현(예: WS-ReliableMessaging) 또는 통신 스택의 기타 모든 구성 요소와 같이 바인딩의 특정 부분을 나타냅니다.
보안 (security)	WCF의 보안에는 기밀성(도청을 방지하기 위해 메시지 암호화), 무결성(메시지 변조를 감지하기 위한 방법), 인증(서버 및 클라이언트의 유효성 검사를 위한 방법) 및 권한 부여(리소스 액세스 권한 제어)가 포함됩니다. 이러한 기능은 HTTP를 통한 TLS(HTTPS라고도 함)와 같이 기존 보안 메커니즘을 활용하거나 다양한 WS-* 보안 사양 중 하나 이상을 구현하여 제공합니다.
서비스 (service)	서비스는 하나 이상의 끝점을 노출하는 구문이며 각 끝점은 하나 이상의 서비스 작업을 노출합니다.
서비스 계약 (service contract)	서비스 계약은 서로 연관된 여러 작업을 하나의 기능 단위로 묶습니다. 계약은 서비스의 네임스페이스, 해당 콜백 계약 및 기타 설정과 같은 서비스 수준 설정을 정의할 수 있습니다. 대부분의 경우 계약은 선택한 프로그래밍 언어로 인터페이스를 만들고 T:System.ServiceModel.ServiceContractAttribute 특성을 인터페이스에 적용하여 정의합니다. 실제 서비스 코드는 인터페이스를 구현한 결과입니다.
서비스 작업 (service operation)	서비스 작업은 작업의 기능을 구현하는 서비스 코드에서 정의된 프로시저입니다. 이 작업은 WCF 클라이언트에서 메서드로 클라이언트에 노출됩니다. 메서드는 값을 반환하고 선택적 인수 개수를 가져오거나, 인수를 가져오지 않고 응답을 반환하지 않을 수 있습니다. 예를 들어, "Hello"로 기능하는 작업을 클라이언트의 존재에 대한 알림으로 사용하고 일련의 작업을 시작할 수 있습니다.
시스템 제공 바인딩 (system-provided binding)	WCF에는 다양한 시스템 제공 바인딩이 포함되어 있습니다. 이러한 바인딩은 특정 시나리오에 맞게 최적화된 바인딩 요소의 컬렉션입니다. 예를 들어, T:System.ServiceModel.WSHttpBinding은 다양한 WS-* 사양을 구현하는 서비스와의 상호 운용성을 위해 디자인되었습니다. 이러한 바인딩은 특정 시나리오에 제대로 적용될 수 있는 옵션만 제공하기 때문에 시간이 절약됩니다. 이러한 바인딩 중 하나가 요구 사항을 충족하지 않을 경우 사용자 지정 바인딩을 만들 수 있습니다.
시작 작업 (initiating operation)	새 세션의 첫 번째 작업으로 호출되는 작업입니다. 하나 이상의 작업을 호출한 후에만 시작 작업이 아닌 작업을 호출할 수 있습니다.
오류 계약 (fault contract)	오류 계약은 서비스 작업과 연결하여 호출자에게 반환될 수 있는 오류를 나타낼 수 있습니다. 작업에는 작업과 관련된 오류가 0개 이상 포함될 수 있습니다. 이러한 오류는 프로그래밍 모델에서 예외로 모델링된 SOAP 오류입니다. 예외는 클라이언트에 보낼 수 있는 SOAP 오류로 변환됩니다.
응용 프로그램 끝점 (application endpoint)	응용 프로그램에 의해 노출된 끝점이며 응용 프로그램이 구현하는 서비스 계약에 해당합니다.
인스턴스 만들기 모델 (instancing model)	서비스에는 인스턴스 만들기 모델이 포함되어 있습니다. 인스턴스 만들기 모델에는 세 가지가 있습니다. 즉, 단일 CLR 개체가 모든 클라이언트에 서비스를 제공하는 "단일" 모델, 각 클라이언트 호출을 처리하기 위해 새로운 CLR 개체를 만드는 "호출별" 모델 및 각 개별 세션에 대해 CLR 개체 집합을 만드는 "세션별" 모델입니다. 인스턴스 만들기 모델은 응용 프로그램 요구 사항 및 예상되는 서비스 사용 패턴에 따라 선택합니다.
자체 호스팅 서비스 (self-hosted service)	자체 호스팅 서비스는 개발자가 만든 프로세스 응용 프로그램 내에서 실행되는 서비스입니다. 개발자는 수명을 제어하고 서비스 속성을 설정하며 서비스를 열고(수명 모드로 설정된 경우) 서비스를 닫습니다.
작업 계약 (operation contract)	작업 계약은 매개 변수를 정의하고 작업 형식을 반환합니다. 서비스 계약을 정의하는 인터페이스를 만드는 경우 T:System.ServiceModel.OperationContractAttribute 특성을 계약의 일부인 각 메서드 정의에 적용하여 작업 계약을 나타냅니다. 작업은 단일 메시지를 가져오고 단일 메시지를 반환하거나 형식 집합을 가져오고 형식을 반환하는 방법으로 모델링할 수 있습니다. 후자의 경우 시스템에서 해당 작업에 대해 교환되는 메시지 형식을 결정합니다.
전송 보안 모드 (transport security mode)	보안은 세 가지 모드 즉, 전송 모드, 메시지 보안 모드 및 메시지 자격 증명을 사용한 전송 모드 중 하나를 통해 제공할 수 있습니다. 전송 보안 모드는 전송 계층 메커니즘(예: HTTPS)에 의해 제공되는 기밀성, 무결성 및 인증을 지정합니다. HTTPS와 같은 전송을 사용하면 이 모드는 성능이 효율적이며 인터넷에서 널리 사용되기 때문에 이해하기 쉽습니다. 단점은 이러한 종류의 보안이 통신 경로의 각 홉에서 개별적으로 적용되기 때문에 통신이 "메시지 가로채기(man in the middle)" 공격을 받기 쉽습니다.
종료 작업 (terminating operation)	기존 세션에서 마지막 메시지로 호출되는 작업입니다. 기본적으로 WCF에서는 서비스와 연결된 세션이 닫힌 후에 서비스 개체 및 컨텍스트를 재활용합니다.
주소 (address)	주소는 메시지가 수신될 위치를 지정하며, URI(Uniform Resource Identifier)로 지정됩니다. URI 스키마 부분은 HTTP 및 TCP와 같은 주소에 도달하는 데 사용할 전송 메커니즘 이름을 지정합니다. URI의 계층적 부분에는 전송 메커니즘에 따라 다른 고유한 위치 형식이 포함됩니다. 끝점 주소를 사용하면 서비스의 각 끝점마다 고유한 끝점 주소를 만들거나 특정한 조건으로 여러 끝점 간에 주소를 공유할 수 있습니다.
채널 (channel)	채널은 바인딩 요소의 구체적인 구현입니다. 바인딩은 구성을 나타내고 채널은 해당 구성과 관련된 구현입니다. 따라서 각 바인딩 요소마다 관련된 채널이 있습니다. 채널은 다른 채널 맨 위에 스택되어 바인딩의 구체적인 구현인 채널 스택을 만듭니다.
코딩 (coding)	개발자가 서비스 또는 클라이언트의 모든 구성 요소에 대해 엄격한 제어를 유지할 수 있도록 하며, 구성을 통해 수행된 모든 설정을 검사하고 필요한 경우 코드를 통해 재지정할 수 있습니다. 코딩이나 구성을 사용하여, 또는 두 가지를 모두 사용하여 응용 프로그램을 제어할 수 있습니다.
클라이언트 응용 프로그램 (client application)	클라이언트 응용 프로그램은 메시지를 하나 이상의 끝점과 교환하는 프로그램입니다. 클라이언트 응용 프로그램은 WCF 클라이언트의 인스턴스를 만들고 WCF 클라이언트의 메서드를 호출하여 시작합니다. 하나의 응용 프로그램이 클라이언트 및 서비스 역할을 모두 수행할 수 있다는 점에 주의하십시오.
호스팅 (hosting)	일부 프로세스의 경우 서비스를 호스팅해야 합니다. 호스트는 서비스 수명을 제어하는 응용 프로그램입니다. 서비스는 기존 호스팅 프로세스에 의해 자체 호스팅되거나 관리될 수 있습니다.
호스팅 프로세스 (hosting process)	호스팅 프로세스는 서비스를 호스팅하기 위해 디자인된 응용 프로그램입니다. 여기에는 IIS(인터넷 정보 서비스), WAS(Windows Activation Services) 및 Windows Services가 있습니다. 이러한 호스팅된 시나리오에서 호스트는 서비스 수명을 제어합니다. 예를 들어, IIS를 사용하는 경우 서비스 어셈블리 및 구성 파일이 포함된 가상 디렉터리를 설정할 수 있습니다. 메시지를 수신하면 IIS는 서비스를 시작하고 수명을 제어합니다.
WCF 클라이언트 (WCF client)	WCF 클라이언트는 서비스 작업을 메서드로(Visual Basic 또는 Visual C#과 같이 선택한 .NET Framework 프로그래밍 언어로 표시) 노출하는 클라이언트 응용 프로그램 구문입니다. 모든 응용 프로그램은 서비스를 호스팅하는 응용 프로그램을 포함하여 WCF 클라이언트를 호스팅할 수 있습니다. 따라서 다른 서비스의 WCF 클라이언트를 포함하는 서비스를 만들 수 있습니다. WCF 클라이언트는 ServiceModel Metadata 유틸리티 도구(Svcutil.exe)를 사용하고 메타데이터를 게시하는 실행 중인 서비스에서 선택하여 자동으로 만들 수 있습니다.
WS-*	WS-Security, WS-ReliableMessaging 등과 같이 WCF에서 구현되고 계속 업데이트되는 WS(웹 서비스) 사양 집합의 약어입니다.

 

빌린 WCF 책 번역 오타가 심해 이리저리 WCF 자료를 찾던중 역시 떠오르는것은 MSDN!
최근들어 관심이 가고 MSDN 내용을 한번 쭉 정리해보고자 이렇게 시작을 하였지만
얼마나 갈런지~

그 1탄 초보자를 위한 자습서!
이미 내용은 MSDN에 있지만 차근 정리를 한번 해보았다.

서버
: 계약 정의 - 계약 구현
: 서비스 노출 끝점
: 메타데이터 교환

클라이언트
: EndpointAddress
: WCF Client Instance

초보자를 위한 자습서

 

이 단원에 포함된 항목에서는 WCF(Windows Communication Foundation) 프로그래밍 기능에 대해 간략하게 설명합니다. 이 항목 아래쪽에 나열된 순서대로 진행하십시오. 이 자습서를 수행하면 WCF 서비스 및 클라이언트 응용 프로그램을 만드는 데 필요한 단계에 대한 기초적인 이해를 할 수 있습니다. 서비스는 하나 이상의 끝점을 노출하는 구문이며 각 끝점은 하나 이상의 서비스 작업을 노출합니다. 서비스의 끝점은 서비스를 찾을 수 있는 주소, 클라이언트가 서비스와 통신해야 하는 정보가 포함된 바인딩 및 서비스에서 클라이언트에 제공하는 기능을 정의하는 계약을 지정합니다.

 

이 자습서의 항목을 순서대로 수행하면 서비스를 실행하고 클라이언트에서 서비스의 작업을 호출할 수 있습니다. 첫 번째 세 개 항목에서는 계약을 사용하여 서비스를 정의하는 방법, 서비스를 구현하는 방법 및 서비스를 코드에서 구성, 호스팅 및 실행하는 방법에 대해 설명합니다. 만들어진 서비스는 자체 호스팅되며 클라이언트와 서비스는 동일한 컴퓨터에서 실행됩니다. 서비스는 구성 대신 코드를 사용하여 구성됩니다. IIS(인터넷 정보 서비스)에서 서비스를 호스팅할 수도 있습니다. 구성 파일 내에 서비스를 구성할 수도 있습니다.

 

다음 세 개 항목에서는 클라이언트 프록시를 만드는 방법, 클라이언트 응용 프로그램을 구성하는 방법 및 서비스의 기능에 액세스할 수 있는 클라이언트를 만들고 사용하는 방법에 대해 설명합니다. 서비스는 클라이언트 응용 프로그램이 서비스 작업과 통신하는 데 필요한 구문을 정의하는 액세스 가능한 메타데이터를 게시합니다. WCF에서는 ServiceModel Metadata Utility Tool (Svcutil.exe)를 통해 이 게시된 메타데이터에 액세스하고 해당 메타데이터를 사용하여 서비스에 대한 클라이언트 응용 프로그램을 생성 및 구성하는 프로세스를 자동화합니다.

 

이 단원에 있는 모든 항목에서는 Visual Studio 2008을 개발 환경으로 사용하는 것으로 간주합니다

 

참고: 

Windows Vista를 실행하는 경우 시작 메뉴로 이동하여 Microsoft Visual Studio 2008을 마우스 오른쪽 단추로 클릭하고 관리자 권한으로 실행을 선택하여 Visual Studio를 시작해야 합니다. Visual Studio 2008을 항상 관리자로 시작하려면 바로 가기를 만들어 마우스 오른쪽 단추로 클릭한 다음 속성을 선택하십시오. 여기서 호환성 탭을 선택하고 관리자 권한으로 이 프로그램 실행 확인란을 선택하십시오. 이 바로 가기로 Visual Studio 2008을 시작하면 프로그램이 항상 관리자로 실행됩니다.

방법: Windows Communication Foundation 서비스 계약 정의

 

이 작업은 기본 WCF(Windows Communication Foundation) 서비스와 이 서비스를 호출할 수 있는 클라이언트를 만드는 데 필요한 6가지 작업 중 첫 번째입니다.

 

기본 WCF 서비스를 만들 때 첫 번째 작업은 계약을 정의하는 것입니다. 계약은 서비스가 지원하는 작업을 지정합니다. 작업은 웹 서비스 메서드로 간주될 수 있습니다. C++, C# 또는 VB 인터페이스를 정의하여 계약을 만듭니다. 인터페이스의 각 메서드는 특정 서비스 작업에 해당합니다. 각 인터페이스에는 ServiceContractAttribute가 적용되어야 하고 각 작업에는 OperationContractAttribute가 적용되어야 합니다. ServiceContractAttribute를 포함하는 인터페이스 내에 있는 메서드에 OperationContractAttribute가 없으면 해당 메서드가 노출되지 않습니다.

 

인터페이스를 사용하여 Windows Communication Foundation 계약을 만들려면

 

1.     시작 메뉴에서 Visual Studio 2008를 마우스 오른쪽 단추로 클릭한 다음 관리자 권한으로 실행을 선택하여 해당 프로그램을 관리자로 엽니다.

 

2.     콘솔 응용 프로그램 프로젝트를 새로 만듭니다. 새 프로젝트 대화 상자에서 Visual Basic 또는 Visual C#을 선택하고 콘솔 응용 프로그램 템플릿을 선택한 다음 이름을 Service로 지정합니다. 기본 위치를 사용합니다.

 

3.     기본 Service 네임스페이스를 Microsoft.ServiceModel.Samples로 변경합니다.

 

4.     다음과 같이 System.ServiceModel.dll에 대한 참조를 프로젝트에 추가합니다.

 

솔루션 탐색기의 프로젝트 폴더 아래에서 참조 폴더를 마우스 오른쪽 단추로 클릭하고 참조 추가를 선택합니다.

 

참조 추가 대화 상자에서 찾아보기 탭을 클릭하고

        c:\Windows\Microsoft.Net\Framework\v3.0\Windows Communication Foundation

을 탐색하고 System.ServiceModel.dll을 선택한 다음 확인을 클릭합니다.

 

참고: 

Csc.exe 또는 Vbc.exe와 같은 명령 줄 컴파일러를 사용하는 경우 어셈블리의 경로도 제공해야 합니다. 기본적으로 예를 들어 Windows Vista을 실행하는 컴퓨터에서 경로는

 Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation

입니다.

 

5.     System.ServiceModel 네임스페이스에 대한 using 문(Visual Basic의 경우 Imports)을 추가합니다.

 

6.     ICalculator라고 하는 새 인터페이스를 정의하고 ServiceContractAttribute 특성을 Namespace 값이 "http://Microsoft.ServiceModel.Sample"인 인터페이스에 적용합니다. 네임스페이스를 명시적으로 지정하면 기본 네임스페이스 값이 계약 이름에 추가되지 않기 때문에 되도록이면 명시적으로 지정하는 것이 좋습니다.

 

참고: 

특성을 사용하여 인터페이스 또는 클래스에 주석을 달 때 특성 이름에서 "특성" 부분을 삭제할 수 있습니다. 따라서 ServiceContractAttribute가 [ServiceContract]가 됩니다.

 

7.     ICalculator 계약이 인터페이스 내에서 노출(더하기, 빼기, 곱하기, 나누기)하는 각 작업에 대한 메서드를 선언하고 공용 WCF 계약의 일부로 노출할 각 메서드에 OperationContractAttribute 특성을 적용합니다.

 

// Define a service contract. [ServiceContract(Namespace="http://Microsoft.ServiceModel.Sample")] public interface ICalculator {     [OperationContract]     double Add(double n1, double n2);     [OperationContract]     double Subtract(double n1, double n2);     [OperationContract]     double Multiply(double n1, double n2);     [OperationContract]     double Divide(double n1, double n2); }

 

방법: Windows Communication Foundation 서비스 계약 구현

 

이 작업은 기본 WCF(Windows Communication Foundation) 서비스와 이 서비스를 호출할 수 있는 클라이언트를 만드는 데 필요한 6가지 작업 중 두 번째입니다.

 

WCF 서비스를 만들려면 먼저 인터페이스를 사용하여 정의된 계약을 만들어야 합니다. 이 예제에서처럼 다음 단계에서는 인터페이스를 구현합니다. 여기에는 사용자 정의 ICalculator 인터페이스를 구현하는 CalculatorService 클래스의 생성이 포함됩니다. 이 작업에 사용되는 코드는 이 절차 다음에 나오는 예제에 제공되어 있습니다.

 

WCF 서비스 계약을 구현하려면

 

1.     ICalculator 인터페이스를 정의한 동일한 파일에서 CalculatorService라는 새 클래스를 만듭니다.

           CalculatorService은 ICalculator 인터페이스를 구현합니다.

 

2.     CalculatorService 클래스 내에서 ICalculator 인터페이스에 정의한 각 메서드를 구현합니다.

 

// Service class that implements the service contract. public class CalculatorService : ICalculator {     public double Add(double n1, double n2)     {         return n1 + n2;     }     public double Subtract(double n1, double n2)     {         return n1 - n2;     }     public double Multiply(double n1, double n2)     {         return n1 * n2;     }     public double Divide(double n1, double n2)     {         return n1 / n2;     } }

 

방법: 기본 Windows Communication Foundation 서비스 호스트 및 실행

 

이 작업은 기본 WCF(Windows Communication Foundation) 서비스와 이 서비스를 호출할 수 있는 클라이언트를 만드는 데 필요한 6가지 작업 중 세 번째입니다.

 

이 항목은 기본 WCF(Windows Communication Foundation) 서비스를 실행하는 방법을 설명합니다. 이 절차는 다음 단계로 구성됩니다.

 

l  서비스에 대한 기본 주소를 만듭니다.

l  서비스에 대한 서비스 호스트를 만듭니다.

l  메타데이터 교환을 사용하도록 설정합니다.

l  서비스 호스트를 엽니다.

 

이 작업에서 작성된 전체 코드 목록은 이 절차 다음에 나오는 다음 예제에 제공되어 있습니다. Program 클래스에 정의된 Main() 메서드에 다음 코드를 추가합니다. 이 클래스는 Service 솔루션을 만들 때 생성되었습니다.

 

서비스에 대한 기본 주소를 구성하려면

 

1.     서비스의 기본 주소에 대한 Uri 인스턴스를 만듭니다. 이 URI는 HTTP 구성표, 사용자의 로컬 컴퓨터, 포트 번호 8000 및 서비스 계약의 서비스 네임스페이스에 대해 지정된 서비스에 대한 ServiceModelSample/Service 경로를 지정합니다.

 

서비스를 호스팅하려면

 

1.     System.ServiceModel.Description 네임스페이스를 가져옵니다. 이 코드 줄은 using 또는 imports 문의 나머지 부분과 함께 Program.cs/Program.vb 파일의 맨 위에 배치되어야 합니다.

 

2.     서비스를 호스팅할 새 ServiceHost 인스턴스를 만듭니다. 서비스 계약을 구현하는 형식 및 기본 주소를 지정해야 합니다. 이 샘플에서는 기본 주소가 http://localhost:8000/ServiceModelSample/Service이며 CalculatorService는 서비스 계약을 구현하는 형식입니다.

 

3.     CommunicationException을 catch하는 try-catch 문을 추가하고 다음 세 단계에서 try 블록에 코드를 추가합니다. catch 절은 오류 메시지를 표시한 다음 selfHost.Abort()를 호출해야 합니다.

 

4.     서비스를 노출하는 끝점을 추가합니다. 이렇게 하려면 끝점이 노출하는 계약, 바인딩 및 끝점에 대한 주소를 지정해야 합니다. 이 샘플에서는 ICalculator를 계약으로, WSHttpBinding을 바인딩으로, CalculatorService를 주소로 지정합니다. 여기에서는 끝점 주소가 상대 주소입니다. 끝점에 대한 전체 주소는 기본 주소와 끝점 주소의 조합입니다. 이 경우 전체 주소는

http://localhost:8000/ServiceModelSample/Service/CalculatorService입니다.

 

5.     메타데이터 교환을 사용하도록 설정합니다. 이렇게 하려면 서비스 메타데이터 동작을 추가합니다. 먼저 ServiceMetadataBehavior 인스턴스를 만들고 HttpGetEnabled 속성을 true로 설정한 다음 새 동작을 서비스에 추가합니다. 메타데이터를 게시하는 경우 보안 문제에 대한 자세한 내용은 메타데이터 관련 보안 고려 사항을 참조하십시오.

 

6.     ServiceHost를 열고 들어오는 메시지를 기다립니다. 사용자가 Enter 키를 누르면 ServiceHost가 닫힙니다.

 

서비스가 작동하는지 확인하려면

 

1.     Visual Studio 내에서 service.exe를 실행합니다. Windows Vista에서 실행하는 경우 이 서비스는 관리자 권한으로 실행해야 합니다. Visual Studio가 관리자 권한으로 실행되었기 때문에 service.exe도 관리자 권한으로 실행됩니다. 또한 관리자 권한으로 서비스를 실행하는 새 명령 프롬프트를 시작하고 해당 명령 프롬프트 내에서 service.exe를 실행할 수 있습니다.

 

2.     Internet Explorer를 열고 서비스의 디버그 페이지인 http://localhost:8000/ServiceModelSamples/Service를 찾습니다.

 

static void Main(string[] args)         {             Uri uri = new Uri("http://localhost:8000/ServiceModelSample/Service");               using (ServiceHost serviceHost =                    new ServiceHost(typeof(CalculatorService), uri))             {                 serviceHost.AddServiceEndpoint(typeof(ICalculator), new WSHttpBinding(),                     "http://localhost:8000/ServiceModelSample/Service/CalculatorService");                   ServiceMetadataBehavior metadata = new ServiceMetadataBehavior();                 metadata.HttpGetEnabled = true;                 metadata.HttpGetUrl = uri;                 serviceHost.Description.Behaviors.Add(metadata);                   serviceHost.Open();                   Console.WriteLine("The service is ready.");                 Console.WriteLine("Press <ENTER> to terminate service.");                 Console.WriteLine();                 Console.ReadLine();             }         }

 

방법: Windows Communication Foundation 클라이언트 만들기

 

이 작업은 기본 WCF(Windows Communication Foundation) 서비스와 이 서비스를 호출할 수 있는 클라이언트를 만드는 데 필요한 6가지 작업 중 네 번째입니다.

 

이 항목에서는 WCF 서비스에서 메타데이터를 검색하고 이를 사용하여 서비스에 액세스할 수 있는 WCF 프록시를 만드는 방법에 대해 설명합니다. 이 작업은 WCF에서 제공하는 ServiceModel Metadata Utility Tool (Svcutil.exe)를 사용하여 수행합니다. 이 도구는 서비스로부터 메타데이터를 가져와 사용자가 선택한 언어를 사용하여 프록시에 대한 관리되는 소스 코드 파일을 생성합니다. 클라이언트를 만드는 것 이외에 해당 도구는 클라이언트에 대한 구성 파일도 만듭니다. 이 구성 파일을 사용하여 클라이언트 응용 프로그램에서 해당 끝점 중 하나의 서비스에 연결할 수 있습니다.

 

클라이언트 응용 프로그램은 생성된 프록시를 사용하여 WCF 클라이언트 개체를 만듭니다. 이 절차에 대해서는 방법: Windows Communication Foundation 클라이언트 사용에서 설명합니다.

 

이 작업에서 생성된 클라이언트 코드는 다음 예제 절차에서 제공됩니다.

 

Windows Communication Foundation 클라이언트를 만들려면

 

1.     Visual Studio 2008에서 다음 단계를 수행하여 클라이언트의 현재 솔루션에서 새 프로젝트를 만듭니다.

 

서비스가 포함된 동일한 솔루션 내의 오른쪽 위에 있는 솔루션 탐색기에서 프로젝트가 아니라 현재 솔루션을 마우스 오른쪽 단추로 클릭하고 추가를 선택한 다음 새 프로젝트를 선택합니다.

 

새 프로젝트 추가 대화 상자에서 Visual Basic 또는 Visual C#을 선택하고 콘솔 응용 프로그램 템플릿을 선택한 다음 이름을 Client로 지정합니다. 기본 위치를 사용합니다.

 

확인을 클릭합니다.

 

2.     다음과 같이 System.ServiceModel.dll에 대한 참조를 프로젝트에 추가합니다.

 

솔루션 탐색기의 클라이언트 프로젝트 아래에서 참조 폴더를 마우스 오른쪽 단추로 클릭하고 참조 추가를 선택합니다.

 

최근에 사용한 파일 탭을 선택하고 목록 상자에서 System.ServiceModel.dll을 선택한 다음 확인을 클릭합니다. 이 자습서의 첫 단계에서 이 어셈블리에 대한 참조를 이미 추가했으므로 최근 사용한 파일 탭에 이 어셈블리가 나열되어 있을 것입니다. 최근 사용한 파일 탭에서 보이지 않으면 찾아보기 탭을 클릭하고 C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation으로 이동하여 어셈블리를 선택합니다.

 

참고: 

Csc.exe 또는 Vbc.exe와 같은 명령줄 컴파일러를 사용하는 경우 어셈블리의 경로도 제공해야 합니다. 기본적으로 예를 들어 Windows Vista를 실행하는 컴퓨터에서 경로는

 Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation입니다.

 

3.     생성된 Program.cs 또는 Program.vb 파일에 있는 System.ServiceModel 네임스페이스에 using 문(Visual Basic에서는 Imports)을 추가합니다.

 

using System.ServiceModel;

 

4.     이전 단계에서 만든 서비스를 시작합니다.

 

5.     적절한 스위치로 Service Model Metadata Utility Tool (SvcUtil.exe)를 실행하고 다음 단계를 수행하여 클라이언트 코드 및 구성 파일을 만듭니다.

 

시작 메뉴의 Microsoft Windows SDK 항목 아래에서 CMD 셸을 선택하여 Windows SDK 콘솔 세션을 시작합니다.

 

클라이언트 노드를 배치할 디렉터리로 이동합니다. 기본값을 사용하여 클라이언트 프로젝트를 만든 경우 디렉터리는 C:\Users\<사용자 이름>\Documents\Visual Studio 2005\Projects\Service\Client입니다.

 

적절한 스위치로 명령줄 도구 Service Model Metadata Utility Tool (SvcUtil.exe)를 사용하여 클라이언트 코드를 만듭니다. 다음 예제에서는 서비스에 대해 코드 파일 및 구성 파일을 생성합니다.

 

svcutil.exe /language:cs /out:generatedProxy.cs

/config:app.config http://localhost:8000/ServiceModelSample/service

 

기본적으로 클라이언트 프록시 코드 이름은 서비스 이름에 따라 지정됩니다. 예를 들어 이 경우에는 CalculatorService.cs 또는 CalculatorService.vb가 되며, 여기서 확장명은 프로그래밍 언어에 해당합니다( .vb는 Visual Basic, .cs는 C#). /out 스위치는 클라이언트 프록시 파일의 이름을 generatedProxy.cs로 변경하고 /config 스위치는 클라이언트 구성 파일의 이름을 기본 output.config에서 app.config로 변경합니다. 이 두 파일은 C:\Users\<사용자 이름>\Documents\Visual Studio 2005\Projects\Service\Client 디렉터리에 생성됩니다.

 

6.     생성된 프록시를 Visual Studio의 클라이언트 프로젝트에 추가하려면 솔루션 탐색기에서 클라이언트 프로젝트를 마우스 오른쪽 단추로 클릭하고 추가를 선택한 다음 기존 항목을 선택합니다. 이전 단계에서 생성된 generatedProxy.cs 파일을 선택합니다.

 

방법: 기본 Windows Communication Foundation 클라이언트 구성

 

이 작업은 기본 WCF(Windows Communication Foundation) 서비스와 이 서비스를 호출할 수 있는 클라이언트를 만드는 데 필요한 6가지 작업 중 다섯 번째입니다.

 

이 항목에서는 Service Model Metadata Utility (Svcutil.exe)를 사용하여 생성된 클라이언트 구성 파일을 클라이언트 프로젝트에 추가하고 클라이언트 구성 요소의 내용을 자세히 설명합니다. 클라이언트를 구성하려면 클라이언트에서 서비스에 액세스하는 데 사용하는 끝점을 지정해야 합니다. 끝점에는 주소, 바인딩 및 계약이 포함되어 있으며 이러한 각 항목은 클라이언트 구성 프로세스에서 지정되어야 합니다.

 

클라이언트에 대해 생성된 구성 파일의 컨텐츠는 해당 절차 이후의 예제에서 제공됩니다.

 

Windows Communication Foundation 클라이언트를 구성하려면

 

1.     이전 방법: Windows Communication Foundation 클라이언트 만들기 절차에서 생성된 App.config 구성 파일을 Visual Studio의 클라이언트 프로젝트에 추가합니다. 솔루션 탐색기에서 클라이언트 프로젝트를 마우스 오른쪽 단추로 클릭하고 추가를 선택한 다음 기존 항목을 선택합니다. 그런 다음 C:\Users\<사용자 이름>\Documents\Visual Studio 2005\Projects\Service\Client 디렉터리에서 App.config 구성 파일을 선택합니다. Svcutil.exe 도구를 사용하여 생성할 때 /config:app.config 스위치를 사용했기 때문에 이 구성 파일의 이름은 App.config 파일로 지정됩니다. 확인을 클릭합니다. 기본적으로 기존 항목 추가 대화 상자에서는 .config 확장명을 가진 파일을 모두 필터링합니다. 이러한 파일을 표시하려면 기존 항목 추가 대화 상자의 오른쪽 아래에 있는 드롭다운 목록 상자에서 모든 파일(*.*)을 선택합니다.

 

2.     생성된 구성 파일을 엽니다. Svcutil.exe는 바인딩에 대한 모든 설정 값을 생성합니다. 다음 예제에서는 생성된 구성 파일을 보여 줍니다. <system.serviceModel> 섹션 아래에서 <endpoint> 요소를 찾습니다. 다음 구성 파일은 생성된 파일의 단순화된 버전입니다.

 

<?xml version="1.0" encoding="utf-8"?> <configuration>   <system.serviceModel>     <bindings>       <wsHttpBinding>         <binding name="WSHttpBinding_ICalculator">         </binding>       </wsHttpBinding>     </bindings>     <client>       <endpoint            address="http://localhost:8000/ServiceModelSamples/Service/CalculatorService"            binding="wsHttpBinding"            bindingConfiguration="WSHttpBinding_ICalculator"            contract="Microsoft.ServiceModel.Samples.ICalculator"            name="WSHttpBinding_ICalculator">       </endpoint>     </client>   </system.serviceModel> </configuration>

 

이 예제에서는 다음 주소에 위치한 서비스에 액세스하도록 클라이언트가 사용하는 끝점을 구성합니다. http://localhost:8000/ServiceModelSample/service

 

끝점 요소는 Microsoft.ServiceModel.Samples.ICalculator 계약이 시스템 제공 WsHttpBinding을 통해 구성된 통신에 사용되도록 지정합니다. 이 바인딩은 HTTP를 전송, 상호 운용 가능한 보안 및 기타 구성 세부 사항으로 지정합니다.

 

방법: Windows Communication Foundation 클라이언트 사용

 

이 작업은 기본 WCF(Windows Communication Foundation) 서비스와 이 서비스를 호출할 수 있는 클라이언트를 만드는 데 필요한 6가지 작업 중 여섯 번째입니다.

 

WCF(Windows Communication Foundation) 프록시를 만들고 구성한 후에는 클라이언트 인스턴스를 만들고 클라이언트 응용 프로그램을 컴파일하여 WCF 서비스와 통신하는 데 사용할 수 있습니다. 이 항목에서는 WCF 클라이언트를 만들고 사용하는 절차에 대해 설명합니다. 이 절차에서는 WCF 클라이언트 만들기, 생성된 프록시에서 서비스 작업 호출, 작업 호출 완료 후 클라이언트 닫기의 세 가지 작업에 대해 설명합니다.

 

또한 이 절차에서 설명하는 코드는 절차 다음에 나오는 예제에 제공됩니다. 이 작업의 코드는 클라이언트 프로젝트에서 생성된 Program 클래스의 Main() 메서드에 배치해야 합니다.

 

Windows Communication Foundation 클라이언트를 사용하려면

 

1.     호출할 서비스의 기본 주소에 대한 EndpointAddress 인스턴스를 만든 다음 WCF Client 개체를 만듭니다.

 

2.     Client 내에서 클라이언트 작업을 호출합니다.

 

3.     WCF 클라이언트에서 Close를 호출하고 사용자가 Enter 키를 눌러 응용 프로그램을 종료할 때까지 기다립니다.

 

static void Main(string[] args)         {             Uri uri = new Uri("http://localhost:8000/ServiceModelSample/Service");             EndpointAddress address = new EndpointAddress(uri);             //app.config             CalculatorClient client = new CalculatorClient("WSHttpBinding_ICalculator");               double value1 = 100.0D;             double value2 = 15.99D;             double result = client.Add(value1, value2);               Console.WriteLine(result);         }