이전 내용에서는 WCF의 EndPoint 아키텍쳐에 대한 내용들을 다루어 보았다. 이번 강좌에서는 WCF의 통신으로 채팅 프로그램을 작성하는 방법을 다루어 볼 것이다. 이번 채팅 프로그램 예제에서는 WCF의 인스턴스 관리 부분과 메시지 전달 부분을 주의 깊게 살펴보도록 하자.
본 예제의 소스는 http://wcf.netfx3.com/에서 발행한 샘플을 필자가 커스텀마이징 하여 만들었다. 본 예제를 진행하기 위해서는 Visual Studio.NET 2005와 다음과 같은 환경이 필요하다.
- Microsoft .NET Framework 3.0 RTM
- Microsoft Windows Software Development Kit for RTM
- Microsoft WPF&WCF Extension
WF의 경우는 WPF 와 WCF와는 다르게 별도의 Extension을 설치해야 한다. 지난 2회에 걸쳐 WCF의 개론적인 내용을 다루었다. 그럼 지난호들의 내용을 잠깐 정리해 보도록 하겠다. WCF는 Windows Communication Foundation 의 약어로 통신 부분을 담당하게 되는 부분이다. 예전에 Indigo라는 코드명으로 소개 되어왔고, 기존의 번잡해 보였던 MS의 여러 분산 기술들을 통합하여 큰 생산성과 상호 운용성 그리고 통일성을 가지고 있는 것이 WCF 특징이라고 보면 되겠다. WCF를 보다 잘 이해하려면 기존의 분산기술들에 대한 이해가 있어야 할 것이다. 즉, 기존 MS의 분산 기술에 대한 이해와 원리를 알고 있어야 한다는 것이다. 지난 호에서 설명했던 Endpoint의 한 요소인 Binding을 살펴본다면 Binding은 상호운용성, 신뢰성, 보안, Duplex 등등의 많은 요소들을 가지고 있다. 하지만 만약 독자들이 신뢰성이 무엇이고, Duplex가 무엇인지 모른다면 WCF의 Binding을 이해하기 힘들 것이다. 그렇기 때문에 분산 기술에 대한 이해와 원리를 알고 있어야 할 것이다. 지난 호에서는 WCF Endpoint 프로그래밍에 대해서 살펴 보았다. Endpoint는 Address, Binding, Contract로 구성되어 있다고 했고, Where(Address), How(Binding), What(Contract)으로 Endpoint의 개념을 쉽게 정립할 수 있을 것이다.
자, 그럼 이번 호에서 다루어볼 채팅 프로그램의 외관상의 모습을 먼저 살펴보도록 하자.
<화면1 콘슬 응용 프로그램으로 만든 서비스>
<화면2 클라이언트 - 서비스 접속하기>
<화면3 클라이언트 - 대화>
| 필자 메모 요즘 개발자라는 직업에 대해서 이런 저런 쓴 소리를 많이 듣게 된다. “개발자들은 야근 정말 많이 한다. 연봉 약하다. 3D업종이다.“ 등등 하지만 우리는 개발자라는 직업에 대해서 다시 고찰해 볼 필요가 있다. 의사는 의사가 되기 위해서 몇 년을 공부하고, 얼마나 노력을 하는가? 의사는 의예과 2년, 본과 4년, 인턴과정 1년, 레지던트과정 4년 이렇게 11년 동안 공부한 후에 의사가 되고, 그러한 사회의 대우를 받게 된다. 하지만 개발자는 어떤가? 지금의 현실로 살펴보자면 물론 대학원까지 이수하여 전문적인 개발자의 길을 걷는 사람도 있겠지만, 개발자들의 이력서를 받아 보면 학원에서 6개월 정규과정을 마치거나 혹은 독학으로 개발자의 직업을 선택한 사람이 많다. 개발자가 짧은 기간 동안 공부한 노력으로 의사와 같은 대우를 받을 수 있다면 의사 분들은 얼마나 억울할 것인지 생각해 보아야 할 것이다. 개발자로서 의사와 같은 클래스로 대우를 받고 싶다면 끊임없는 채찍질과 자기 개발이 필요한 것이다. 그래서 개발자로서 성공의 길을 향한 여정은 신입부터라는 생각이 든다. 어느 정도 일을 배웠다고 해서 현재 환경에서 자신이 잘한다는 만족을 주는 순간 채찍은 손에서 떨어지게 되고 최소한 성공해보자라는 목표가 있었던 개발자라면 성공이란 포부는 사라지게 될 것이다. 물론 인간의 욕망은 끝이 없기 때문에 성공이란 목표의 끝을 찾기가 어렵긴 하지만, 개발자로서 경쟁력은 자신이 만들어 가는 것이라고 생각이 든다. |
클라이언트는 Windows C#으로 작성 되었다. 먼저 서비스를 디자인 해 보도록 하겠다. 채팅 프로그램의 서비스는 다음과 같은 요구가 있다고 가정해 보겠다.
| ● 채팅 서비스는 별도의 응용 프로그램으로 관리 된다. ● 닷넷끼리만 통신을 하기 때문에 상호 운용성은 고려하지 않아도 된다. ● TCP 통신을 이용하기 원한다. ● 단순한 Request-Response가 아닌 메시지를 클라이언트에서 서버로 서버에서 클라이언트로 보내야 한다. ● 채팅은 연결 지향적이기 때문에 사용자의 인스턴스가 관리되어야 한다. ● 연결 지향적인 통신을 하기 위해서는 클라이언트의 메시지의 신뢰도가 있어야 한다. |
이런 요구사항이 있다고 가정하고, EndPoint의 요소들과 인스턴스 관리를 위한 Service Behavior요소를 디자인 해보도록 하겠다. 먼저 EndPoint의 요소들을 살펴보도록 하자.
Hosting
호스팅은 크게 웹 호스팅과 셀프 호스팅 이렇게 두 개의 방식으로 나눌 수 있다고 지난 호에서 다루었다. 먼저 요구 조건이 별도의 응용 프로그램으로 관리 된다고 했기 때문에 셀프 호스팅(Self-Hosting)을 선택해야 할 것이다.
Binding(How?)
바인딩을 결정 할 때는 서비스의 조건을 잘 분석해서 결정해야 한다. WCF가 통합된 기술인만큼 분산기술을 분석해서 설계해야 한다는 부담이 있다. 먼저 닷넷 끼리만 통신을 하기 때문에 상호 운용성을 고려하지 않아도 된다라는 전제가 있다. 그리고 TCP 프로토콜을 사용한다는 것이다. 또 중요한것은 R-R 방식이 아닌 양방향 통신을 한다는 것이다. 이런 조건들을 분석해 보자. 먼저 지난 호에서 다루었던 StandardBinding의 요소들을 다시 살펴보도록 하자.
< 그림 1> StandardBinding의 요소
StandardBinding의 요소는 그림1과 같이 구현되어 있다. 자, 상호운용성은 .NET끼리의 통신이고 TCP 프로토콜을 이용하고, 세션이 유지 되어야 한다. 또한 Duplex통신을 해야하기 때문에 당연히 NetTcpBinding을 선택하면 될 것이다. 하지만 만약 Http 프로토콜을 이용해서 상호 운용성을 확보한다고 하는 서비스를 구현한다면 어떤 Binding을 선택해야 할지 한번 생각해 보도록 하자. WsDualHttpBinding 이라고 생각했던 독자가 있다면 Binding과 분산 기술에 대한 이해가 있다는 것이다.
Contract (What?)
Contract는 크게 Message, Data, Service 이렇게 세 가지로 구분된다고 지난 호에 소개 했다. 이번 채팅 프로그램에서는 Data, Message Contract는 구현하지 않는다. Service Contract의 Operation Contract만 구현할 예정이다. Operation Contract는 채팅의 큰 기능인 사용자 조인, 대화하기, 귓속말, 나가기 이렇게 네 가지 메서드로 구현된다.
Service Behavior
채팅의 중요한 특징은 반드시 세션이 유지되어야 한다는 것이다. 웹 서비스처럼 한번 서비스를 호출하는 것이 아닌 양방향 통신으로 서로 통신을 하게 되는 것이 채팅이 주요한 특징이다. WCF에서는 다음과 같은 세 가지의 인스턴스 관리 방식이 존재한다.
이름 | 설명 |
Per-Call | 메서드가 호출됨에 동시에 인스턴스 개체가 제거됨 일반적인 웹 서비스와 유사함 기본 자원효율 우수함 COM+의 JIT방식 .NET Remoting의 Well-Known SingleCall과 유사 |
Per-Session | 클라이언트에서 파괴되거나 설정된 시간에 의해서 개체가 제거됨 신뢰할 수 있는 전송 세션에서 지원하는 바인딩 |
Singleton | 하나의 인스턴스만 생성됨 한 번에 하나의 클라이언트 호출만 실행할 수 있는 동기화 작업이 필요함 자유롭게 인스턴스 초기화 가능 |
다음 그림을 참고 해보자.
<그림 2> Per-Call
<그림3> Per-Session
< 그림 4> Singleton
Per-Call과 같은 경우는 일반적으로 웹 서비스와 유사한 방식이다. 한 메서드를 호출할 때 객체를 한번 생성해서 한 메서드를 호출할 때 객체를 파괴하는 것이다. 자원을 효율적으로 관리할 수는 있지만 세션 관리가 되지 않는다는 단점이 있다. 그렇기 때문에 이번 채팅 프로그램에서 사용할 방식은 바로 Per-Session방식이다. Per-Session방식은 인스턴스가 클라이언트에 의해서 생성되고, 클라이언트에 의해서 파괴된다. 그렇기 때문에 신뢰도 높은 메시지를 필요로 하게 된다. 채팅 서비스에서는 접속한 사람들과 대화방에 나간 사람들과는 철저하게 구별되게 된다. 다음 그림은 채팅에서 사용하게 될 서비스를 보여주고 있다. Per-Session 방식으로 여러 클라이언트들을 관리하고 메시지를 비 동기 방식으로 전달 하게 된다.
< 그림 5> Multiple Clients
Duplex (양방향 통신)
그림 2에서는 메시지를 양방향으로 전달하고 있다. 채팅 서비스는 메시지가 비 동기적으로 전달되어야 한다. 바로 Duplex 방식이 양방향 그리고 비 동기 통신을 한다고 보면 된다. 그럼 WCF의 메시지 전달 방식들을 살펴 보도록 하자.
이름 | 설명 |
Simplex | 단 방향통신으로 특정 로그를 쌓거나 할 경우 간단한 작업에 적합(One Way) |
Request-Response | 동기 양방향 통신 방식으로 특정한 메시지를 보내고 전달 받는 방식 |
Duplex | 비 동기 양방향 통신 방식으로 특정한 메시지를 원격으로 보내고 전달 받는 방식 |
위의 표의 설명으로 이해가 어렵다면 다음 그림을 참고해 보며 이해해 보자.
<그림 6> Simplex(One-Way)
<그림 7> Request-Reply(동기 Two-Way)
<그림 8> Duplex(비 동기 Two-Way)
이렇게 해서 채팅 서비스를 디자인 하기 전에 살펴 볼 WCF의 기능들을 분석해 보았다. 위의 설명들로는 조금 이해가 어려울 수 있지만 채팅 서비스를 직접 구현해보면서 WCF의 기능을 살펴보면 쉽게 이해할 수 있을 것이다. 앞에서도 언급했듯이 이번 채팅 프로그램에서 주의깊게 살펴 볼 부분은 인스턴스 관리와 메시지 전달(Duplex) 방식이다. 자 그럼 채팅 프로그램을 직접 작성해 보도록 하자.