VS2005, VS2008에서 VC++을 이용해 ISAPI 개발하기

VS2005에서 새로운 프로젝트 창에 ISAPI 프로젝트 항목이 제외되었습니다. 게다가 VS2008에는 그나마 있던 VC++로 개발가능한 WebService 프로젝트 항목도 빠져버렸습니다. 그렇다고 해서 완전이 빠진것은 아니고 새로운 프로젝트 창에서만 제외되었고, 기존의 프로젝트를 열어서 VS2005와 VS2008에서 작업이 가능합니다. 그렇다면 새로운 프로젝트로 ISAPI 개발을 VS2005 이상에서는 시작할 수 있을까요? ISAPI를 이용한 웹컴포넌트 개발이 비록 시대에 역행하는 행위이기는 하지만 어찌되었든 MS 플렛폼인 IIS 서버 웹기반의 서비스 기술로써 가장 퍼포먼스가 뛰어나므로, 아직 폐기 시키기에는 다소 아깝지 않나 하는 생각이 듭니다.

사실 처음에는 ISAPI를 쓰지 않고 대세인 XML 기반인 웹서비스를 사용하려고 하였습니다. 그 배경은 0.2 메가 정도되는 바이너리 데이터를 웹을 통해 주고 받아야합니다. 문제는 0.2메가 크기의 바이너리 데이터를 웹서비스가 사용하는 XML로 인코딩시킬 경우의 문제점입니다.

  • 원본 크기가 최대 4배까지 커진다.
  • 인코딩과 디코딩하는데 걸리는 시간이 매우 길다.

자세한 내용은 이 블로그의 웹서비스와 퍼포먼스(http://www.gisdeveloper.co.kr/entry/웹서비스와-퍼포먼스)를 참고해보시길 바랍니다. 이런 문제점으로 인해 ISAPI를 이용한 서버기술로 회귀하게 되었는데…. 문제는 Visual Studio 2005와 2008에서는 이 프로젝트가 눈에 보이지 않는다는 것입니다. 다행인것은 아예 제거된것이 아닙니다. 그래서 이 글에서는 간단하게나마 ISAPI를 Visual Studio 2005, 2008에서 개발하는 방법을 간단하게 정리한 글입니다. 여기서는 Visual Studio 2005에서 ISAPI Extension 개발에 대한 내용입니다.

1. 새로운 프로젝트 생성하기

정확히 말해 ISAPI는 일반적인 DLL일 뿐입니다. 여기서 몇가지 함수를 외부로 Export 시켜 IIS가 이 함수를 호출함으로써 서로 통신을 하게됩니다. 그 몇가지 함수가 무엇인지는 아래에 설명하겠습니다.

2. 프로젝트 위저드 설정하기
앞서 설명한 것처럼 응용프로그램 종류는 DLL로 지정하며 일단 빈 프로젝트로 생성합니다.

3. 모듈파일 추가하기
외부로 Export할 함수를 지정하기 위한 파일인 모듈파일을 추가합니다.

4. 모듈 파일이 Export할 함수명 지정하기

LIBRARY	"ChartService"

EXPORTS
	HttpExtensionProc
	GetExtensionVersion
	TerminateExtension

앞서 추가한 모듈파일인 module.def에 3개의 함수를 Export 하는데, 위처럼 HttpExtensionProc, GetExtensionVersion, TerminateExtension 입니다. 각 함수의 역활은 아래서 간단하게 살펴보겠습니다.

5. Export할 함수를 구현할 파일 추가하기
앞에서 언급한, 외부로 Export 할 함수를 구현할 cpp 파일 추가합니다.

6. Export할 함수 구현하기

#include 
#include 
#include 

BOOL WINAPI TerminateExtension(DWORD dwFlags)
{
	// 실제 구현
	return TRUE;
}

BOOL WINAPI GetExtensionVersion(HSE_VERSION_INFO *pVer)
{
	// 실제 구현
	return TRUE;
}

DWORD WINAPI HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pecb)
{
	// 실제 구현
	return HSE_STATUS_SUCCESS;
}

이미 이 글을 읽어볼 요량이셨다면, .. 아마도 .. ISAPI은 한번쯤 개발해보셨다고 생각이되는데요.. 여기서는 일단 이 함수들의 주요목적에 대해서만 간단하게 설명드리겠습니다.

TerminateExtension은 서비스가 IIS로부터 Unload될때 실행되는 함수이고, GetExtensionVersion은 서비스가 IIS로부터 처음 Load될때 실행되는 함수입니다. 그리고 HttpExtensionProc는 궁극적으로 클라이언트가 해당 서비스를 요청할때마다 실행되는 함수입니다. 이 상태에서 컴파일을 하면 하나의 dll이 만들어집니다. 실제로 이를 자신의 관리하고 있는 PC의 IIS에 배포을 해야하는데, 그 과정은 아래와 같습니다.

7. IIS에 배포하기
컴파일되어 생성된 dll을 IIS의 폴더에 복사하기전에 기존의 서비스를 Unload 시켜(복사 전 언로드를 예로 지정)야하고, 복사할 폴더의 이름을 지정하고(가상 디렉터리 이름을 지정) 빌드에서 제외를 ‘아니오’로 지정하면 됩니다.

웹서비스와 퍼포먼스

원래 출처는 http://blog.naver.com/kaizer0720/80042740822 이며, 웹서비스가 바이너리 데이터 전송에 적합한지에 대한 의문점과 적합하지 않다면(적합하지 않다고 짐작했기에) 그 해결방안이 무엇인가에 대해 검색을 하다가 찾은 글입니다. 일반적으로 쉽게 이해할 수 있는 글인데요, 그중에 퍼포먼스에 대한 부분만 간단하게 나름대로 정리해 간추렸습니다.

웹서비스와 퍼포먼스

웹서비스는 SOAP 프로토콜을 사용하므로 SOAP 포로토콜이 가지고 있는 문제를 그대로 가지고 있다고 할 수 있습니다… 해서, SOAP 패킷에 대한 SOAP Envelope에 대한 압축을 푸는 시간과 SOAP이 사용하는 데이터 표현인 XML에 대한 파싱에 매우 많은 시간이 소모됩니다. 이를 정리하면…

  • SOAP 패킷에서 SOAP Envelope에 대한 압축을 포는 것에 많은 시간이 소모된다.
  • XML 파서를 이용하여 SOAP Envelope에 있는 XML 파싱에 많은 시간이 소모된다.

또한 앞에 언급한 XML은 실제 데이터를 기술하는 메타 데이터(Tag Element)가 붙음으로 중복적이며 비효율적이며 최적화에 대한 여지가 매우 적습니다.

특히 앞서 언급한 바이너리 데이터의 경우 SOAP은 원래의 하나의 바이트가 표현할 수 있는 256개(ASCII 코드의 개수)를 XML이라는 텍스트 포맷으로 표현하기 위해 화면상에 표현할 수 있는 것들로만 간추린 64개의 문자로 인코딩을 함으로써 원본의 크기보다 4배로 커지게 된다는 극심한 문제점이 발생합니다. 즉, 데이터의 크기가 커진다는 문제와 64개의 문자로 인코딩하는 연산이 필요로 합니다. 마찬가지로 이러한 문제는 서버측에서만 발생하는 것이 아니라 클라이언트 측에서도 4배로 커진 데이터를 받아 다시 원본으로 디코딩해줘야 합니다. 이를 정리하면…

  • 서버측에서 바이너리 데이터에 대해서 Base64로 인코딩하는 연산이 필요하다.
  • 인코딩 결과 원본의 크기에 대해 4배로 커진다.
  • 클라이언트 측에서 서버가 보낸 데이터를 다시 디코딩하는 연산이 필요하다.

그렇다면 이에 대한 해결책이 무엇일까.. 고민하게 됩니다. 실망스럽게도… 바이너리 데이터에 대한 Base64 인코딩 결과를 압축을 해서 데이터의 크기를 줄여 클라이언트로 보내라는 것이 전부입니다. 그렇다면 데이터의 크기는 줄어드는 장점은 있으나… 서버측에서 데이터를 인코딩하고 다시 압축한 후에 클라이언트로 전송하여 클라이언트에서 압축을 풀고 데이터를 디코딩하는 복잡한 연산을 필요로 하게됩니다. 사실 SOAP의 Envelope에 대한 문제점은 무시하고라도 인코딩과 디코딩.. 그리고 원본보다 4배(평균) 커진다는 문제점이 가장 염려스러운 부분이긴 합니다.

대용량 또는 작은 용량의 바이너리 데이터 전송에 웹서비스가 접합한 기술인지… 여러분은 어떻게 생각하십니까?