클라이언트/서버로 구성된 Tiered application을 만들게 되면 두 어플리케이션 간에 통신하는 부분을 작성해야 하는데 이걸 처음부터 소켓 프로그래밍으로 하게 되면 패킷도 정의해야 하고 뭐 이래 저래 완전 개고생이다. 증권사 프론트 데스크에서 언제 이런것 까지 다 개발하고 있으랴…(물론 트레이딩 관련이고 엄청난 속도가 필요하면 해야겠지…) 그래서 결국 택한게 .NET의 WCF다. WCF는 매우 유연한 환경을 갖고 있어서 둘 간에 HTTP나 HTTPS로 통신할 수도 있고 TCP로 통신할 수도 있다.

WCF 서비스를 호스팅하는 별개의 서비스 어플레케이션을 만들어 호스팅할 수도 있고 IIS에 호스팅할 수도 있다. 단 윈도 서버 2003의 IIS 6.0에 호스팅하면 HTTP나 HTTPS 통신 채널만을 지원한다. 2008서버에서는 모든 가능한 채널을 다 지원한다고 한다. (그런데 회사 서버는 2003 그래서 TCP 호스팅은 포기 OTL ㅠㅠ) 아무튼 이녀석을 이용해 개발해 IIS에 호스팅하게 되면 Web Service가 되어서 아무나 접속해 쓸 수 있는 문제가 생긴다. 아무리 부서에서만 쓰는 시스템이라지만 혹시 다른 부서에서 이상한 짓을 하면 어쩌랴. 그래서 사용자 Id/Password 인증 부분을 처리하기로 했다. 그런데 이걸 처음부터 다 만들면 그것도 또 엄청난 일…그래서 찾다보니 Basic HTTP Binding + SQL Membership Provider라는 조합을 찾아냈다. 여기에 TransportCredentialsOnly로만 하면 HTTPS 오버헤드도 없고. 설마 사내에서 패킷 스니핑하는 도청꾼이 있지는 않겠지? 그건 IT에서 해결해 줄 문제고, 하여간 나는 제한된 사용자만 접근하는데 초점을 맞췄다. 그래서 MSDN을 열라 서베이 해서 찾아낸 것이 바로!!!

How to: Use Username Authentication with Transport Security in WCF Calling from Windows Forms

그러나 이 설정에도 문제가 있으니, 그것이 뭔고하니 요청과 응답을 HTTPS로 한다는 것이다. 인트라넷에서 굳이 필요 없는 부분이지 않은가! 위 문서에 있는 것 대부분을 따라하고 몇가지만 다르게 설정하면 HTTP로 할 수 있다. HTTP를 쓸 것이니 당연히 Certificate은 필요 없을 것같다. (확실하지 않음, 나는 Certificate이 설정되어 있는 상황에서 했기 때문에…) 그러니 인증서 설치 부분은 가볍게 스킵! 그리고 이 문서에서 하라는대로 해서 안되는 부분이 하나 있는데 그것은 바로 13번째 스텝. Anonymous access를 끄라고 했는데 그러면 Visual Studio에서 자동으로 Proxy를 만들어 주는 기능이 동작하지 않는다. 이것 때문에 날린 시간이 대략 한 1시간 ㅠㅠ.

HTTPS를 쓰지 않기 위해서는 먼저 Step 3의 4번을 하지 말아야 한다. 그리고 https로 하라는 거 전부 그냥 http로 하면 된다. 청개구리 처럼. Step 4의 13번 째에서 Security tab에서 Mode attribute를 Transport로 하지 않고 TransportCredentialOnly으로 한다. 이거는 서버쪽 설정. Client쪽은 Step 16의의 app.config 파일 수정하는 부분에서 <security mode=”Transport“> 대신에 <security mode=”TransportCredentialOnly“>로 하면 된다. 나머지는 위 MSDN문서의 대부분 스텝을 그대로 따라하면 끝!

하지만 ws*Binding을 사용하지 못하는 것은 좀 아쉽. 그냥 Encryption overhead를 감수하고 message level security를 쓰는 것도 한가지 방법. 2008로 업글하고 싶어 ㅠㅠ

참고로 Oreilly에서 출판된 Programming WCF Services, Second Edition

을 추천한다. 그리고 부록 CD에 CredentialsManager라는게 있는데 SQL Membership Provider의 사용자 및 역할 설정을 쉽게 매니지할 수 있게 해주는 툴의 소스가 들어 있다. 하지만 설정하는게 장난이 아니게 어렵다는거 ㅠㅠ. 사용 설명서대로 해도 안된다는…몇가지 힌트를 주자면 위 MSDN문서를 읽다 보면 나오는데 기본 SQL Membership Provider를 제거해야 하며, Connection string을 충분한 권한이 있는 사용자로 접속하도록 하던가 Network_Service 사용자에게 SQL Server의 aspnetdb에 대한 Access권한을 충분하게 줘야 한다.

덧) 이것 저것 하다가 갑자기 서버가 자꾸 죽는 일이 발생해서 이래저래 디버깅을 하다 안 것인데 서버쪽 서비스 바인딩 설정에서
<security mode=”TransportCredentialOnly”>
<transport clientCredentialType=”None”/>
</security>
와 같이 clientCrendentialType을 Basic이 아닌 None으로 해줘야 한다는 것이다. 클라이언트 쪽은 바인딩은
<security mode=”TransportCredentialOnly”>
<transport clientCredentialType=”Basic” proxyCredentialType=”None” realm=”"/>
</security>
와 같이 Basic으로 해줘야 한다.

이유는 서버쪽은 IIS의 기본 인증을 사용하는 것이 아니라 자체적으로 제작한 인증 모듈을 사용하기 때문.

VSTO란 Visual Studio Tools for Office라고 해서 Visual Basic for Application(VBA)으로 하던 기능을 .NET framework로 끌어 들인 녀석이다. 당연히 .NET 기반의 모든 Base class library에 억세스 할 수 있으며 사용자 Class library로 붙여 쓸 수 있다. 또한 .NET의 훌륭한 Interop을 이용하면 Native code나 Java와의 Interaction도 가능하다. 좋은 점은 여기까지.

그럼 함 Hello VSTO 어플을 만들어 보고 Visual Studio에서 컴파일 한 후에 실행해 봐라. 물론 잘되겠지. 그럼 거기서 bin/Release건 bin/Debug건 하여간 Excel파일하고 어셈블리 파일(.dll)을 다른 컴퓨터로 복사해서 실행해 봐라. 되야 할 것 같은데, 안되버린다 ㅠㅠ OTL. Microsoft가 VBA 매크로 바이러스 때문에 호되게 당한 것들이 있어서인지, 이딴식의 Unsecure하지만 매우 Straightforward한 Deployment scheme을 없애버렸다 ㅠㅠ.

그럼 내가 만든 VSTO 프로그램을 다른 사람이 쓸 수 있게 하려면 어쩌란 말이냐!!!

폴 드 센느빌(Paul de Senneville)이 자신의 딸을 위해 작곡하고 리차드 클레이더만이 연주해 히트친 곡이다. 나는 딸이 없어서 그런지 별로 ㅠㅠ. 역시 OTL. 갖고 있는 악보보다 화음을 더 넣어서 쳐봤다. 이상하게 초반부 페달을 미디 기계가 놓친 듯…(사실 내가 잘못한 듯, 원래 실력없는 사람이 기계 탓해여 ㅠㅠ)

아드린느를 위한 발라드