|
In-Process |
Out-of-Process |
DLL 확장자를 가진다. |
EXE 확장자를 가진다. |
호출 프로세스와 동일한 메모리 영역에 상주하다. |
호출 프로세스와 다른 메모리 영역에 상주하다. |
32bit에서만 사용가능 |
16bit와 32bit사이에 연결 가능 |
정형(model) 대화상자를 통해서만 화면에 나타난다. |
화면 출력에 대한 제한이 없다 |
원격(remote)으로 실행될 수 없다. |
원격 OLE 오토메이션을 사용할 수 있다. |
통신이 매우 빠르다. |
통신이 상대적으로 느리다. |
근본적인 차이는 메모리의 구성에서 온다. 사실 in-process 서버는 DLL이다. 다른 점이라면 직접적으로 함수를 호출하지 않고 OLE 오토메이션을 사용한다는 사실이다. 그러하기 때문에 in-process 서버는 별도의 메모리 영역을 가지지 못한다. 즉 호출자의 메모리 공간을 공유한다. 따라서 도저히 호출 프로세스와 다른 컴퓨터에 있을 수가 없다. in-process는 비정형(modeless) 대화상자를 사용할 수 없다. 이러한 제한 때문에 한 가지 주의해야 할 점이 있다. 무엇인가 하면, 처음으로 시작되는 폼은 비정형이기 때문이기 때문에 앞에서 언급된 프로젝트 탭에서 Start Form을 Sub Main으로 지정하여 비정형 폼이 열리지 못하게 해야 한다. 호출자와 같은 메모리 영역에 있다는 특성이 단점만 있는 것은 아니다. 메모리를 공유하므로 별도의 통신을 위한 처리가 요구되지 않고, 따라서 속도가 매우 빠르다.
이에 비해 out-of-process는 호출자와 별개의 메모리 공간을 가지는 또 하나의 프로세스이다. 따라서 화면 출력에 전혀 제한이 없고 원격 OLE 오토메이션에 이용될 수 있으며, 호출자와 비동기적(asynchronous)으로 실행될 수 있다. 또한, 서버와 클라이언트는 별개의 프로세스이므로 서로 같은 메모리 여건을 가질 필요도 없다. 즉 서버가 32bit이면 클라이언트는 16bit일 수도 있고 혹은 그 반대일 수도 있다. Out-of-process가 클래스의 모듈의 Instancing 속성을 통해 여러 개의 인스턴스가 활성화 될 수 있도록 하면 클라이언트의 요구에 능동적으로 대응할 수 있다. 각각의 인스턴스는 별도의 프로세스이므로 멀티테스킹에 의해 각각이 활성화된다. 물론 이 경우 쓰레드(thread)로 처리했다면 좀 더 효율적이었을 것이다. 비베 다음 버전은 쓰레드를 지원할 것을 기대해 본다. 참고로 In-process는 DLL이기 때문에 여러 개의 인스턴스가 활성화될 수 없다. 이러한 장점에 비해 out-of-process는 호출자와 메모리 영역이 다르므로 통신이 in-process 서버에 비해서 느릴 수밖에 없다는 단점을 내포하고 있다.
원격 OLE 오토메이션 서버
원격 OLE 오토메이션은 서버와 클라이언트가 서로 다른 컴퓨터에 존재할 수 있도록 한다. 이로써 OLE 서버는 네트워크를 가로질러 존재할 수 있게 되었고 클라이언트는 원격 OLE 오토메이션을 통해 제공되는 이러한 서버 컴포넌트에 쉽게 전근할 수 있게 되었다. 따라서 클라이언트/서버 시스템을 구축하는데 있어서 보다 유연성 있게 프로그램을 네트워크 전체에 걸쳐 분산시킬 수 있다.
그럼 지역(local) OLE 오토메이션과 원격 OLE 오토메이션에 대해 좀 더 내부적으로 고찰해 보자. 먼저 지역 OLE 오토메이션에 대해서 알아보자. In-process 오토메이션인 경우 서버와 클라이언트간의 연결은 매우 간단하다. 두 부분이 하나의 메모리를 공유하는 하나의 프로세스이기 때문이다. 이에 반해 Out-of-process인 경우에는 다소 복잡해진다. 서버와 클라이언트가 별도의 프로세스이기 때문이다. 프로세스의 메모리는 다른 프로세스로부터 철저히 보호된다. 오직 운영체제의 커널만이 불법적인 침입자의 대상에서 제외된다. 이런 상황에서 서버와 클라이언트의 연결을 위해서는 별도의 처리가 필요하다. 이를테면 참조형(call by reference)으로 인자가 메쏘드를 통해 서버에 전달되어야 하는 경우를 생각해 보자. 메모리 보호에 의해 서버는 클라이언트의 메모리 공간을 가리키는 포인터를 전혀 사용할 수 없다. 따라서 OLE 오토메이션은 포인터가 가리키는 메모리의 내용을 서버의 메모리 공간에 복사하고 포인터가 서버에 복사된 내용을 가리키도록 조정한다. 서버의 메쏘드가 끝났을 때 결과를 다시 클라이언트의 메모리 공간으로 복사하고 포인터를 원래의 값으로 전환한다. 이러한 작업은 proxy와 stub에 의해 처리되는데 <그림 7>을 참조하기 바란다.
<그림 7> Out-of-process 지역 OLE 오토메이션에서 연결 방법
클라이언트 쪽의 오토메이션 proxy와 서버 쪽의 오토메이션 관리자(automation manager)는 기존의 지역 OLE 오토메이션을 확장한다. <그림 8>에 나타나 있듯이 클라이언트 쪽의 오토메이션 proxy와 서버 쪽의 오토메이션 관리자중 원격 오토메이션 stub간에 RPC(Remote Procedure Call)을 통한 네트워크 상에 데이터 교류가 일어난다. 오토메이션 관리자는 다중 쓰레드로 구현되어 있어서 많은 클라이언트의 요구를 즉각 처리할 수 있다. 오토메이션 관리자의 OLE proxy와 서버의 OLE stub에 관계는 지역 OLE 오토메이션에서 설명된 proxy/stub 관계와 동일하다. 이러한 방법을 통해 클라이언트 입장에서는 서버가 같은 메모리에 있는지 아니면 네트워크로 연결된 다른 메모리에 있는지는 고려 대상이 아니다. 서버 입장에서도 서버와 같은 메모리에 있는 오토메이션 관리자가 RPC로 넘어온 데이터를 지역 OLE 오토메이션의 상황과 동일하게 넘겨주므로 원격적이든 지역적이든 신경 쓸 필요가 없다. 따라서 이러한 추상화는 개발자에서 많은 짐을 덜어준다.
윈도우즈와 OLE 그리고 비베
마이크로소프트는 자사의 운영체제인 윈도우즈 패밀리를 객체지향적으로 변모시키기 위해 OLE을 내놓았다. 사실 1990년 컴덱스 쇼에서 OLE 1.0 스펙이 발표되었을 때 만 해도 별 다른 특별한 점이 없었다. 복합문서(compound document)를 꾸미기 위해 여러 가지 객체를 연결하고 붙이는 정도였다. 사용자 입장에선 객체 지향을 위해서가 아니라 문서를 예쁘고 손쉽게 꾸미기 위해서 OLE가 있다라고 인식하는 게 보통이었다. 그러나 2.0이 나오면서 OLE는 정말이지 객체지향 윈도우즈를 위한 초석임을 보여주었다. 특히 OLE 2.0의 오토메이션 기술은 모든 응용 프로그램을 위한 컴포넌트를 형성하므로써 기존의 소프트웨어의 설계나 프로그래밍 방식에 큰 영향을 미칠 것이다. 보통 언어 내에서 만의 객체 지향 기술의 첨가는 분명히 한계가 있다. 그 언어 영역 외에 속하는 운영체제의 여러 개체들에 대해서는 전혀 그 힘을 쓰지 못하기 때문이다. OLE와 같은 운영체제 차원에서의 객체지향의 지원은 운영체제가 전체 컴퓨터 환경을 관할하기 때문에 전반적이고 직접적인 영향을 끼친다. 이러한 OLE에 근거해 만들어진 객체는 특정 언어에 비의존적이 되고 메모리의 공유 여부에 비의존적이 되었으며 이제 플랫폼에 비의존적이 되어야 할 것이다. 서로간의 이질적인 운영체제 아래서 서로간의 객체를 서로 교환할 수 있다면 그야말로 완벽한 분산체제 환경이다. 이에 대해선 CORBA(Common Object Request Broker Architecture)와 같은 스펙이 발표되어 있지만 마이크로소프트처럼 독식하기 좋아하는 기업이 과연 다른 곳과 협력하며 이 안을 그대로 수용할 지도 미지수다.
현재로서는 비베가 OLE 객체를 손쉽게 만들 수 있는 최선의 선택이다. C++과 같은 비교적 하위 레벨의 컴파일러 언어로 OLE 객체를 만든다는 것은 쉬운 일만은 아니다. 이런 의미에서 비베 4.0의 출시는 마이크로소프트에게는 전략적으로 매우 중요하다. 사실 OLE 2.0이 나온 지 몇 년이 지났지만 그 기술의 난해함 때문에 쉽게 그 기술을 사용하기가 쉽지는 않았고 그래서인지 OLE 객체를 제공하는 제품은 마이크로소프트사의 제품과 VISIO같은 몇몇 제품을 제외하곤 거의 찾아보기 힘들었다.
다음 회에서는 add-ins라는 비베 개발환경의 독특한 특징을 다루고자 한다. 비베의 개발 환경은 OLE 오토메이션을 통해 개발 환경을 커스터마이징(customizing)할 수 있는 객체들을 공개하고 있다. 비베 개발 환경의 내부를 자세히 몰라도 VBAssist와 같은 애드온 툴을 쉽게 만들 수 있다. 그것도 C++과 같은 언어가 아닌 비베 자체로 말이다.
하루가 다르게 급변하는 컴퓨터 산업을 바라볼 때면 그저 한숨이 나오는 경우가 많다. 그저 따라갈 뿐이다. 미국에서 만든 기술들을 보고 우리는 최신 기술을 얻었음을 기뻐한다. 다른 학문에서도 항상 거론되는 말이지만 순수 기초 학문의 부재는 컴퓨터 과학(computer science)에서도 그대로 적용된다. 미국과 경쟁 자체를 하기에도 너무 뒤쳐져있는 현실 속에서 우리들은 그네들이 만들어 놓은 운영체제, 데이터베이스, 개발 툴들을 가져다 응용할 뿐이다. 대학생들이 운영체제를 만든다는 그들을 우리들은 언제나 따라갈 수 있을는지...
예제에 대해서... <- 적당한 위치에 넣어주세요.
예제는 두 개의 프로그램으로 되어 있다. 하나는 OLE 서버(Telcode.vbp)이고 다른 하나는 클라이언트(OLECli.vbp)이다. 따라서 두 개의 비베를 실행시켜 하나에는 OLE 서버를 실행시키고 다른다른 하나에는 클라이언트 예제 프로그램을 실행시키면 된다.