게시판 본문 COM / COM+ by VB 6.0 - Read Only

안녕하세요? ^_^

먼저 제가 이해한 내용이 맞는지 확인을 해봐야 할 것 같습니다. IIS 서버가 두 대 존재하고 있는 상태이고 본문에서는 편의상 A 서버와 B 서버라고 하겠습니다. A 서버에서 B 서버로 이진 파일을 전송해야 하는 상태이구요, 폰 페이지라고 말씀하신 점을 미루어볼 때 핸드폰에서 A 서버에 작성해 놓은 특정 ASP 프로그램을 호출하면 이 ASP 프로그램이 B 서버에 있는 또 다른 ASP 프로그램으로 C++ 로 작성한 DLL 을 이용해서 파일을 전송하는 환경입니다. 따라서 A 서버에 위치한 ASP 프로그램은 원격지에서 장소에 구애받지 않고 파일 전송을 시작시키기 위한 목적으로 사용되는 것이겠군요. 그리고 B 서버에 위치한 ASP 프로그램이 FROM 태그로 전송을 받는다는 요구 사항을 깔아놓은 것은 별도로 파일을 받아들이는 윈도우즈 서비스나 데몬류의 프로세스를 만들기 어려운 상황이어서 기존에 프로그램을 제작하신 분께서 그렇게 했던 것 같습니다.

이런 제반 사항들로만 미루어서 판단했을 때는 적은 노력을 기울여서 원하시는 목적을 달성하기 위한 여러가지 좋은 방법들 중의 한 가지인 것 같습니다. 특히나 B 서버에 위치한 전송된 파일을 받는 ASP 프로그램이 인상적입니다. 만약 이 방법을 사용하지 않았다면 해당 ASP 프로그램 대신 파일 수신을 전담하는 윈도우즈 서비스를 만들어야 했을 것입니다. ^_^

그런데 제 경험만을 참고해서 말씀드리자면 이런 경우에는 대부분의 B 서버에 FTP 서비스를 하나 운영하면서 A 서버에서 FTP 컴포넌트를 사용해서 파일을 전송하곤 하는데요, 최소한 제가 지금까지 참여했던 프로젝트에서는 이런 경우가 대부분이었습니다. 딱히 제가 그런 구조를 고집한 것은 아니었고 프로젝트에서 사용하는 머신 중에 HOST 등이 섞여 있는 경우 등에는 거의 대부분의 머신에서 제공되는 것이 FTP 서비스라서 즉 프로그래밍 언어와는 무관한 일종의 표준이므로 다른 분들도 이런 구조를 좋아하시더군요. 지금 말씀하신 환경에서는 B 서버의 ASP 프로그램이 바로 FTP 서비스의 역활을 하는 셈이 되겠습니다. 아마도 초기에 어떠한 이유론가 인하여 FTP 서비스를 사용할 수 없는 상황이 아니었나 하고 생각해봅니다. 혹시 이런 구조로 전환하실 생각이 있으시다면 저도 비주얼 베이직으로 만들어 놓은 FTP 컴포넌트가 하나 있으므로 말씀해주시면 드리도록 하겠습니다. 거의 비주얼 베이직 관련 서적 같은데에서 간단한 예제 프로그램 정도로 쓰일만한 수준의 컴포넌트이긴 하지만 그럭저럭 동작이 되므로 참고하실 수는 있으실 것입니다. ^_^

아무튼 현재 상태에서의 문제점 같은 것들을 하나씩 집어보도록 하겠습니다. 말씀하신 바로 짐작하건데 (저도 C++ 코드를 본 것이 아니라, 또 본다고 해도 어려운 코드는 이해하지 못하므로... ^_^) DLL 자체가 멀티쓰레드를 구현하지 않아서라는 이유는 조금 이해하기 힘듭니다. 물론 말씀하신 것처럼 COM+ 를 잘 모르는 분께서 개발하셨더라도 COM 을 아시는 분이 작성하신 프로그램이라면 그렇게 만드실리가 절대로 없다고 생각합니다. 이 부분은 컴포넌트를 만들 때 거의 기본에 해당하는 문제이거든요. 또 만약 그 얘기가 맞다고 한다고 해도 그렇다면 아예 두 번째와 세 번째 인스턴스에서도 문제가 생겨야만 맞겠지요. 대부분의 경우 네 번째 인스턴스에서부터 문제가 발생한다면 이것은 멀티쓰레드 구현 여부의 문제는 아니라고 봅니다. 또 최악의 상황을 가정해서 멀티쓰레드를 진짜로 구현하지 않으셨다면 (사실 COM 컴포넌트에서는 이런 경우는 찾아보기가 극히 힘들고 오히려 그렇게 만들기가 더 어려울 것 같습니다. 일반 DLL 파일이라면 약간 가능성이 있다고 생각은 합니다만 COM+ 에 등록하셨다는 얘기는 그렇지는 않다는 뜻이거든요.) 여러명이 동시에 접속을 시도할 때 접속한 순서대로 하나씩 순차적으로 처리되어 딜레이 될 수는 있을 것입니다. 그러나 지금처럼 매번 네 번째 인스턴스마다 막히거나 하지는 않을 것입니다.

그리고 또 한 가지 의문점이 말씀하신 C++ 로 작성한 컴포넌트를 굳이 COM+ 서비스에 올려서 사용하실 이유가 있는가 하는 점입니다. 말씀하신 대로라면 이 컴포넌트는 자동 트렌젝션 서비스와도 별다른 관계가 없고, 적시 활성화 서비스나 개체 풀링 서비스와도 거리가 있다고 생각합니다. 큐를 사용하시지도 않을 것이고 전혀 COM+ 서비스를 사용하실 이유가 없는 컴포넌트인데 COM+ 서비스에 올리신 것 같습니다. 물론 아주 도움이 안되는 것은 아닙니다. 일단 컴파일시에 IIS 를 재시작하지 않고서도 약간의 조작만으로도 컴파일이 가능하죠. 그러나 실제로 운영중인 서버에서 대놓고 컴파일을 하거나 하시지는 않을 테니 큰 도움이 된다고는 말할 수 없겠네요. 아니면 혹시 이 컴포넌트가 항상 특정 계정하에서 실행되어야 한다면 COM+ 응용 프로그램 설정에서 조정이 가능하므로 도움이 되실 것입니다. 그러나 그렇지 않다면 COM+ 서비스에 올릴 이유가 전혀 없는 컴포넌트라고 판단됩니다. ^_^;;

오히려 COM+ 서비스에 올리고 설정을 잘못하시면 문제가 생길수도 있겠네요. 예를 들어서 개체 풀링을 잘못 설정하시면 지금과 유사한 문제가 발생할 수도 있을 것입니다. 만약 개체 풀링 기능을 사용하도록 설정해 놓으신 상태에서 최대 풀 갯수를 10 개로 잡아 놓으셨다면 11 번째 개체 요청에서부터는 오류가 발생하게 됩니다. 지금 말씀드린 용어는 윈도우즈의 버전에 따라서 약간씩 다를 수 있지만 그 대략의 의미는 상통하므로 이 부분을 혹시 한 번 확인해 보시기 바랍니다. 아무튼 확실한 것은 기존의 C++ 로 제작된 컴포넌트를 사용하시던지 아니면 비주얼 베이직으로 직접 작성하신 새로운 컴포넌트를 사용하시던지 COM+ 서비스에 컴포넌트를 올린다고 무조건 좋은 것은 아니므로 이 점을 충분히 감안하시고 결정하시라는 것입니다. 마침 이 주제와 관련해서 문서를 하나 작성하고 있는데요 조만간 보실수 있을 것입니다.

이제 본론으로 들어가서 정리를 해보도록 하겠습니다. 먼저 질문하신 내용중에 자체 컴포넌트 제작없이, 위의 문제를 해결하면서 서버 스크립트단에서 파일 전송을 할 수 있는 방법이 있는지 여부에 대해서는 일단 비관적입니다. 제가 모르고 있는 방법이 존재할 수도 있겠지만 아마도 컴포넌트의 작성은 피하실 수 없으실 것 같습니다. 그 가장 큰 이유는 B 서버에서 파일을 전송받을 때 요구하는 방식이 FORM 태그 방식이기 때문입니다. 이 얘기는 곧 파일을 전송하는 컴포넌트가 FORM 의 작업을 전부 시뮬레이션해야만 한다는 얘기가 되는 것입니다. ^_^;;

우리가 수작업으로 브라우저상에서 파일을 업로드 할때는 그저 버튼을 하나 눌러주면 모든 작업이 끝나지만 실제로 내부적으로는 HTTP 메세지가 만들어지게 됩니다. 즉 첫 번째 라인에는 무슨무슨 내용이 들어가고 그 다음에는 헤더에 어떤 값들을 설정해주고, \r 과 \n 을 어디어디에 써주고 파일의 내용을 읽어들여서 어떻게 인코딩하고 하는 등의 작업들과 모든 준비가 끝났으면 B 서버의 80 번 포트에 준비한 문자열을 바이트 배열로 소켓을 이용해서 전송해주고 하는 등의 복잡한 작업들을 컴포넌트 내부에서 처리해 주어야만 하는데, 이런 작업들을 ASP 프로그램에서 VBScript 만 가지고 처리하기에는 너무 버겁지 않나 생각됩니다.

두 번째로 자체 DLL 을 제작하신다면 그 내부 구조에 대해서는 지금 제가 말씀드리기는 힘들 것 같고, 만약 제작하신 컴포넌트를 COM+ 서비스에 올리신다면 어떤 프로그래밍 언어를 사용해서 컴포넌트를 작성하시던지 적시 활성화 서비스와 개체 풀링 서비스는 설정하지 마십시요. 즉 사용하지 않도록 하십시요. 그러나 사실 이러한 서비스들을 사용하지 않는다면 COM+ 서비스에 컴포넌트를 올릴 이유의 태반이 사라지는 셈이긴 합니다만 말이죠. 작성하시고자 하는 컴포넌트의 성격상 전혀 성능 향상에 도움이 되지 않을 뿐더러 자칫하면 문제가 발생할 수도 있다는 것이 제 의견입니다. ^_^;;

감사합니다.