마이크로소프트社의 OLE/COM과
   IBM,애플 사의 OpenDoc에 대한 조사

浦項工科大學校 情報通信大學院
情報通信硏究所 知識 및 言語工學硏究室
김 선 호 (Std. ID: 9551M07)
본 보고서는 앞으로 수년간 소프트웨어 업계를 뒤흔들 객체 기술과 객체 컴포넌트 기술 및 컴포넌트 소프트웨어에 대해 심도 있게 소개하고 이 소프트웨어들 중 현재 선두주자로 앞서가고 있는 OLE 와 OpenDoc을 비교 분석하고 장래 이 분야의 발전 방향을 예측해 보고자 한다. 
                                 Copyright© 1996 by  Sun-ho Kim.

第 1 章.	Component Software란 무엇인가?
컴포넌트 소프트웨어(Component Software) 또는 컴포넌트웨어(Componentware)란 말은 일반적으로 객체 지향 기술의 원리를 이용해 제작한 소프트웨어 모듈을 의미하는데, 기계 부붐과 같이 소프트웨어도 하나하나의 부품으로 제작한 다음 이를 조립해 보다 복잡한 소프트웨어를 만들 수 있을 것이라는 아이디어에서 시작한 개념이다.
1.1.  컴포넌트웨어(Componentware)의 연원
아마도 가장 최초로 컴포넌트웨어의 아이디어를 낸 사람은 1985년 소프트웨어 IC를 주창한 브래드 콕스일 것이다. 1986년에는 스템스톤(StepStone)사에서 ICpak101,Icpack201이라는 최초의 상용 컴포넌트웨어를 시장에 내놓는 등의 브래드 콕스의 이 같은 시도는 몇몇 프로젝트엔 성공적으로 접목되었지만, 앞으로 살펴 볼 소프트웨어 컴포넌트의 시장 여건이 여러 가지로 미숙했기 때문에 더 확산되지는 못했다.  하지만 이제 진정한 컴포넌트웨어를 위한 여건은 객체 기술의 발전과 함께 충분히 성숙했고 대부분의 개발툴들은 나름대로 객체 컴포넌트를 이용한 응용 프로그램 제작을 지원하고 있으며, 전통적인 개발툴들도 발전된 패키징 기술을 이용해 기존 프로시저 모듈의 재사용을 지원하고 있다. 이제 문제는 다양한 소프트웨어 컴포넌트를 하드웨어 플랫폼이나 운영체제에 무관하게 상호 호환되도록 하는 표준화이다.
1.2.  컴포넌트웨어 산업의 현재
현재 소프트웨어 컴포넌트에 대한 표준은 없다. 마이크로소프트(이하 MS)는 OLE 2.0을 밀고 있고, IBM/애플 연합은 오픈독(OpenDoc)을 선전하고 있다. 또한 작년에 혜성과 같이 등장한 선마이크로시스템의 자바(Java)는 이제 MS를 포함한 거의 대부분의 업체가 지원을 약속함으로써 컴포넌트 소프트웨어 시장의 강력한 경쟁자로 부각되었다. 
1.3.  컴포넌트웨어의 중요성
최근 MS를 위시한 대부분의 소프트웨어 업체들은 기존 응용 프로그램의 유지 보수에 엄청난 노력을 기울이고 있다. 수백만 라인의 소스 코드를 유지하는 것부터 시작해 너무도 복잡한 기능들을 계속 업그레이드하기 위해 들이는 노력은 이제 거의 한계점에 다다른 것으로 보인다. 이것은 다른 의미에서 소프트웨어 위기(Software Crisis)이다. 즉 하드웨어의 진보를 소프트웨어가 따라가지 못함은 물론, 날로 복잡해져 가는 업무 요건과 급변하는 기업환경을 정보 시스템이 제대로 지원하지 못함으로써 기업들은 극심한 경쟁 사회에서 경쟁력을 유지하기가 점점 힘들어지고 있는 것이다. 이런 상황을 타개하기 위한 대안으로 객체 기술의 중요성이 부각되었고, 성공적으로 객체 기술을 적용한 소프트웨어 업체와 그렇지 못한 업체 간의 생산성 격차는 날이 갈수록 벌어지고 있다. 한 조사에 의하면 미국의 소프트웨어 생산성은 1993년 이래 매년 평균 13%씩 감소하고 있다고 한다. 이는 앞서 언급한 어려움을 단적으로 보여주는 좋은 증거라 할 수 있다. 그러나 생산성 있는 개발 조직과 그렇지 못한 조직간의 생산성 격차는 600대 1까지 벌어진다고 한다. 이런 겨차는 단순히 객체 지향 프로그램 언어를 사용했기 때문이라고 설명할 수는 없다. 즉 미국의 소프트웨어 생산성 연구 기관에 따르면 C 프로그램의 재사용 비율은 평균 15%이나 스몰토크를 사용할 경우는 최대 80%밖에 증가하지 않는다고 한다. 단순한 코드의 재사용이 아닌 비즈니스 프로세스를 구현한 상위 레벨의 컴포넌트가 아니면 이렇게 엄청난 생산성의 향상은 이루어 질 수 없다. 즉 클래스 라이브러리 형태의 코드는 재사용이 한정될 수 밖에 없으며, 일정 규모 이상의 추상화 된 형태의 컴포넌트(예를 들면 구매 주문 객체, 병원 개체 등)를 통해서만 지속적인 생산성 혁명을 이루어 낼 수 있는 것이다.
第 2 章.	Component Software를 이용한 소프트웨어 개발
2.1.  컴포넌트웨어(Componentware)를 이용한 개발 모습
컴포넌트 소프트웨어를 이용한 개발은 서로 독립적으로 개발된 프로그램 모듈을 보다 큰 프로그램 개발의 단위 요소로 사용해 조립하는 것이다. 지금까지 가장 성공적인 컴포넌트웨어는 비주얼 베이직의 VBX이다. OCX나 오픈독 파트는 VBX의 인터페이스와 기능을 확장한 것이라고 생각하면 될 것이다. 그러나 컴포넌트 소프트웨어와 VBX는 근본적으로 많은 차이가 있다. 컴포넌트 소프트웨어가 지향하는 바는 컴포넌트 자체가 하나의 응용 프로그램처럼 독립적으로 실행 할 수 있도록 하는 실행 환경 아키텍처와 상호 동작성, 분산성을 확보하고 있다. 하지만 MS의 방식은 좀 다르다. 오픈독 파트는 오픈독 환경(기존의 운영체제에 결합된)에서 하나의 독립적인 프로그램처럼 사용자가 실행시킬 수 있고, 또 네트워크 건너편의 다른 파트와 메시지를 주고 받을 수 있다.
  컴포넌트 소프트웨어가 소프트웨어 개발 패러다임을 뒤바꿀 것이라는 예측은 바로 이런 이유에서 기인한다. 프로그래머들은 더 이상 응용 프로그램을 처음부터 구현할 필요가 없고, 단위 기능을 가진 컴포넌트만을 표준 사양에 맞춰 개발하면 된다. 이렇게 개발된 컴포넌트들은 다른 개발자가 만든 컴포넌트와 메시지를 주고 받을 수 있으며, 다른 컴포넌트의 파트가 되거나 다른 컴포넌트를 자신의 파트로 가질 수도 있다. 작은 컴포넌트들은 최종 사용자가 사용하기 편리하게 좀 더 최적화된 형태로 조립되어야 하는데, 이때는 표준화된 스크립트 언어를 사용해 단위 컴포넌트들을 조립한다. 최종 사용자는 이렇게 조립된 컴포넌트를 개인의 업무 환경에 맞게 고칠 수도 있다. 컴포넌트들은 가장 작은 단위(예를 들어 단어 찾기 컴포넌트)부터 가장 큰 단위(워드프로세서, 스프레드시트, 데이터베이스 조회 컴포넌트)까지 실행 환경에서 바로 불러 사용하거나 조합할 수 있다.
2.2.  각 컴포넌트웨어의 전략 시나리오
MS는 기존의 모든 응용 프로그램들이 OLE 객체를 지원하도록 부추기고 있다. 모든 프로그램들이 OLE서버와 컨베이너 프로그램이 되면, 기존의 일체화(monolithic)된 프로그램들은 OLE객체를 통해 서로 통신을 할 수 있게 된다. 
오픈독은 응용 프로그램 중심의 사용 환경을 컴포넌트를 기반으로 한 업무 중심 컴퓨팅(task centric computing)환경으로 변화하도록 노력하고 있다는 점에서 OLE보다 훨씬 혁신적이다. 즉 오픈독 파트(오픈독에서는 컴포넌트를 파트라고 함)는 오픈독의 실행 환경에서 하나의 독립적인 프로그램처럼 데스크 탑에서 바로 실행되거나, 다른 파트의 서브 파트로 담겨져 있다.예를 들어 오픈독 스프레드시트 파트를 사용한다고 가정해보자. 데스크탑에는 스프레드시트 파트의 아이콘이 보이고 이를 더블 클릭하면 문서 쉘(Document Shell) 이라는 범용 프로그램(메인 함수 역할을 하는)이 실행되면서 스프레드시트를 편집하는 명령이 보인다. 만약 이 스프레드시트의 한 쉘에 그래픽 파트가 담겨 있다고 하면 사용자는 스프레드시트 파트에서 바로 그래픽 파트를 편집할 수도 있다. 그래픽 파트를 편집할 때는 문서 쉘의 메뉴가 그래픽 파트에 적합하도록 바뀌게 된다. 그래픽 파트를 별개의 윈도우로 독립시켜서 편집하고 싶으면 그래픽 파트를 더블 클릭하여 새로운 문서 쉘을 띄우면 된다. 따라서 오픈독의 파트는 하나 하나가 독립적인 단위 프로그램으로 기능하며, 각 파트들은 다른 파트들과 표준화된 인터페이스를 통해 매끄럽게 연동하여 동작한다.
자라 애플릿(자바에서 컴포넌트에 해당하는 것은 애플릿)의 경우도 유사하다. 애플릿은 자바 실행 환경에서 플랫폼에 독립적인 중간 코드 형태로 컴파일된 후 인터프리터에 의해 실행된다. 자바의 경우는 웹브라우저가 범용 컨테이너 프로그램의 역할을 한다고 볼 수 있다. 어떤 자바 객체이건 브라우저를 통해 실행될 수 있으며, 브라우저에서 보고 있는 문서 내의 객체는 링크로 연결되어 있다. 이 링크들은 컴포넌트가 다른 컴포넌트에 포함(embedding)되어 있는 관계를 나타내며, 브라우저에게 멀티미디어 객체를 바로 실행시킬 수 있다는 점에서 복합 문서를 지원한다고 할 수 있다.
第 3 章.	OLE/COM과 OpenDoc의 출현
3.1.  마이크로소프트의 OLE
OLE는 간단하게 말하면 여러 응용 프로그램에서 생성된 자료를 한 문서에서 편집할 수 있도록 해주는 메카니즘이다. 이런 문서를 복합 문서(Compound Document)라고 하며, 다양한 유형의 데이터 또는 아이템(Item)을 매끄럽게 통합할 수 있어 OLE를 지원하는 프로그램을 갖고 있으면 여러 프로그램을 오갈 필요 없이 한 곳에서 다양한 종류의 데이터를 편집할 수 있다. OLE에서는 컨테이너 양쪽 역할을 다하는 프로그램으로 컨테이너 양쪽 역할을 다하는 프로그램도 있다. OLE는 이런 기능을 링킹 앤 임베딩(Linking & Embedding), 현재 위치에서의 편집(InPlace Editing), 자동화(Automation),복합 파일(Compound File),UDT(Uniform Data Transfer), 드래그 앤 드롭, 컴포넌트 객체 모델(Component Object Model,COM)등을 통해 지원한다. 이들 기능 중 특히 스크립팅을 통한 자동화 기능은 컴포넌트를 최적화하여 새로운 파트를 개발하거나, 파워 유저들이 컴포넌트를 자신의 환경에 적합한 형태로 조작하는데 매우 유용하다. 
프로그래머 입장에서 보면 OLE는 위의 기능 그룹으로 묶여진 COM인터페이스(Component Object Model Interface)의 집합이라고 볼 수 있다. COM인터페이스는 ‘특정한 이름(인터페이스 이름)으로 서로 밀접하게 연관된 함수들을 모아 놓은’ 것이다. 인터페이스는 C++의 추상 클래스(Abstract class)처럼 실제 코드나 클래스 데이터를 갖고 있지 않은 순수한 선언이므로 통상적인 객체지향 기술에서의 객체/클래스와는 전혀 다른 것이다. 따라서 COM객체가 상속성(Inheritance)을 지원하지 못하는 것은 자연스러운 결과일 것이다.
프로그래머 사이에 OLE의 명성은 이미 프로그래밍이 난해하기로 유명하다. OLE는 서로 다른 14종의 인터페이스 집합일 뿐이라는 혹평도 있다. MS는 이러한 문제점을 개발 툴로 해결하려고 하고 있지만 근본적으로 객체 모델의 제약, 아키텍처 자체의 모호함과 혼동스러운 인터페이스 등으로 인해OLE프로그램 차체의 복잡도는 그리 개선되지 못하고 있다. 또 OLE의 다른 복합 문서 컴포넌트와의 비호환성도 문제가 될 수 있을 것이다. OLE/COM은 또 특정 프로그램 언어(MS C++)와 매우 밀접하게 결합되어 있다.
3.2.  IBM.애플의 OpenDoc
오픈독은 분산 컴퓨팅을 위한 크로스 플랫폼 API이다. 이 말은 오픈독 표준에 부합하는 프로그램과 문서는 이기종 간의 장벽을 넘어 네트워크에서 공유될 수 있다는 것을 의미한다. 애플과 IBM은 MS의 OLE에 대항하는 새로운 데스크탑 표준의 정립을 위해 오픈독의 원천 기술을 CI랩에 기증했다
오픈독의 강점은 OLE와 오픈 독을 동시에 개발할 수 있다는 점이다. 따라서 오픈독 프로그램은 OLE 프로그램으로 변환될 수 있다(물론 OLE 프로그램은 오픈독으로 변환될 수 없다.) 
3.3.  OpenDoc의 출현 배경 - 기존 소프트웨어의 문제
사용자와 기업은 여러 종류의 플랫폼과 네트워크에서 운용되는 보다 사용자 환경에 통합되어 있으면서 최적화가 가능한 소프트웨어를 요구하고 있으나 현대의 소프트웨어는 이러한 요구를 만족시키지 못하고 있으며, 오히려 컴퓨터 환경을 더 복잡하게 만드는데 기여하고 있는 상황이다. 개발자는 사용자의 다양한 기능 요구에 맞추기 위해 기존 제품을 더운 더 복잡하고 거대하게 만듦으로써 사용자 환경과의 통합(일체)화, 타 프로그램과의 조화, 또는 최적화 가능성 등을 희생시키고 있다.
결론적으로 현재의 소프트웨어는 사용자의 요구에 전혀 부응하지 못하고 있다. 여기서 진정으로 필요한 것은 사용자로 하여금 필요한 기능만을 쉽고, 직관적으로 사용할 수 있도록 하고 이와 동시에 소프트웨어 개발자가 보다 효율적으로 일할 수 잇도록 해주는 전혀 새로운 소프트웨어 모델인 것이다.
오픈독은 예의 문제점을 해결하기 위해 개발되었다 - 즉 기존의 컴퓨팅 모델의 복잡도를 감소시키고 협동적이고도, 통합된 매우 최적화하기 쉬운 응용 프로그램을 지원하도록 개발됐다. 다른 말로 하면, 오픈독은 분산형의 복수 플랫폼을 지원하는 컴포넌트 소프트웨어를 가능케 함으로써 소프트웨어 간의 호환성을 보장하는 새로운 소프트웨어 모델이다. 오픈독은 또한 점진적인 채용이 가능하도록 설계됨으로써 사용자나 개발자 모두가 오픈독 환경으로의 무리 없이 이행할 수 있다. 그러면 오픈독이 지향하고 있는 새로운 컴퓨팅 모델이란 무엇인가.
3.4.  OpenDoc 컴퓨팅 모델
OpenDoc은 분산 플랫폼 컴포넌트 응용 프로그램 및 복합 문서 작성을 가능하게 하는 기술로서, 일반 사용자가 컴퓨터를 사용하는 방식, 기업이 정보를 관리하는 방법, 컴퓨터 소프트웨어 업체가 산업을 영위하는 형태를 근본적으로 개선하도록 설계된 새로운 컴퓨팅 모델이다.
•	복합 문서 아키텍처(Compound Document Architecture)를 가지고 있다.
•	복수 개의 파트가 서로 공존하면서 협동할 수 있는 프로토콜에 대한 정의이면서 그것들을 구현해 좋은 클래스들의 집합이다.
•	오픈독 자체나 오픈독 컴포넌트는 CI Lab.이 지원 회사로 부터 라이센스 받은 다음 기술을 기반으로 하고 있다.
①	오픈독-애플
②	시스템 객체 모델 (System Object Model : SOM) - IBM
③	벤토(Bento) - 애플
④	개방형 스크립트 아키텍쳐(Open Scripting Architecture) - 애플
⑤	OLE 상호 호환성 서비스( OLE Interoperability service) - 노벨

第 4 章.	OpenDoc
OpenDoc은 <그림 1>에서 보듯이 프로그램 언어에 중립적인 CORBA 호환 분산 객체 모델을 기반으로 그 위에 컴포넌트 서비스, 복합 문서 서비스, 자동화 서비스, 호환성 서비스 등으로 구성되어 있다. 오픈독의 아키텍처는 흔히 복합 문서 아키텍처라고 한다. 오픈독의 CDA ( Compound Document Architecture ) 는 다음과 같은 성격의 오픈독 복합 문서를 지원하기 위해 강력하고도 유연한 구조를 갖고 있다.
•	어떤 종류의 자료도 가질 수 있다.
•	각 파트는 독립적인 파트 핸들러에 의해 가능하다.
•	한 파트 유형의 파트 핸들러는 서로 호환 가능하다.
•	파트 핸들러는 파트의 내부 내용만을 다루며, 이 파트가 포함하고 있는 다른 파트에 대해서는 관여하지 않는다.
•	클립보드와 드래그 앤 드롭이 일반적인 자료 교환 방법이다.
•	파트 간의 자료 교환을 위한 링크가 가능하다.

<그림 1> 오픈독 아키텍처

4.1.  OpenDoc의 아키텍쳐
4.1.1 객체 관리 서비스
오픈독의 객체 관리 서비스(Object Management Service)는 SOM( System Object Model )을 기반으로 하고 있다. SOM은 객체의 외부 인터페이스와 인터페이스의 내부 구현을 분리함으로써 프로그래밍 언어에 대해 독립적이며 SOM으로 구현한 버전 간의 이진 호환성( Release - to - Release binary compatibility )을 보장한다. 또한 업계 표준의 분산 객체 아키텍처인 CORBA(Common Object Request Broker Architecture)를 지원하는 ORB( Object Request Broker )로서 윈도우, OS/2, AIX, 매킨토시 등 다중 플랫폼을 지원하고 있다.
SOM이 프로그램 언어에 중립적이라고 하는 의미는 SOM객체를 C++나 스몰토크같은 객체지향 언어뿐만 아니라, C, 코볼 등과 같은 3GL로도 구현할 수 있다는 뜻이다. 즉 SOM은 CORBA IDL을 이용해 객체를 정의 하고 구현할 프로그램 언어에 따른 바인딩을 생성함으로써 객체지향 시스템을 저의 구현, 이용할 수 있도록 해준다. 또 여러 프로그램 언어로 작성된 응용 프로그램이 다른 언어로 구현된 클래스 라이브러리도 사용할 수 있도록 해준다. 예를 들어 C로 구현한 클래스 라이브러리도 C++나 스몰토크에서 이용할 수 있다. 또 SOM으로 개발한 객체( 프로그램 언어에 대해 독립성을 갖춘 객체)는 객체지향 언어가 가지고 있는 속성들을 모두 수용하고 있다. 즉 SOM은 강력한 객체지향 시스템으로 구축하는데 필요한 다중 상속, 서브클래싱, 객체의 교체, 동적 바인딩 등을 지원 할 수 있도록 풍부한 객체 개발 환경을 제공하고 있다. 
SOM의 또 다른 특징 중 하나는 상위 이진 호환성(Upward binary compatibility)이다. C++와 같은 객체지향 언어는 클래스 계층에 새로운 클래스를 끼워 넣거나 상위 클래스의 정의가 변경되면 유관된 원시 코드를 다시 컴파일 해야 한다. 즉 어떤 프로그램에서 C++클래스 라이브러리를 사용하고 있다면, 그 클래스 라이브러리의 버전이 바뀌면 원시 코드를 다시 콤파일해야 한다.  SOM은 클래스의 구현을 인터페이스와 완벽히 분리하고 있기 때문에 원시 코드의 재 컴파일이 없이도 응용 프로그램이 링크 되어 있는 SOM 객체 라이브러리의 상위 레벨의 라이브러리로 대체할 수 있다.
오픈독에서 SOM을 기반 객체 관리 서비스로 선택한 가장 큰 이유 중의 하나는 SOM이 업계 표준 분산 객체 관리 아키텍처인 CORBA를 지원하고 있다는 점일 것이다. 현재 발표된 SOMobject 2.1은 CORBA1.2를 지원하며, 올해 상반기중으로 CORBA 2.0의 CORBAservice중 일부를 지원하는 버전 3.0이 나올 계획이다. CORBAservice는 미정의 된 부분들도 있기 때문에 대부분의 ORB업체들은 단계적으로 이를 지원하게 되어 있다. SOM의 실행 환경은 앞서 말한 것처럼 여러 플랫폼에 이미 포팅 되어 있으며, 다른 ORB와의 호환성은 CORBA 2.0을 지원하면서부터 가능할 것이다(CORBA 2.0에서 이 호환성이 정의되었다).
SOM개발 환경은 IDL컴파일러와 프로그램 언어 바인딩을 포함한 객체 프레임워크로 구성되어 있다. 이들 프레임워크는 분산 객체 서비스(DSOM, Distributed SOM), 저장 서비스(PSOM, persistent SOM), 복제 서비스 (RSOM, Replication Framework), 콜렉션 클래스들과 같은 유틸리티 등을 포함하고 있다.
요약하면 SOM은 컴파일러 언어 중립성을 보장해주며, OMG의 표준 인터페이스 정의 언어(Interface Definition Language, IDL)를 지원한다. 또 정의된 SOM객체의 공용(public)및 전용(private) 자료형으로 특정 프로그램 언어 바인딩으로 맵핑 해 줌으로써 SOM객체를 다른 프로그램 언어에서도 사용할 수 있게 해준다고 할 수 있다.
4.1.2. 컴포넌트 서비스 	 
분산 객체 관리 서비스 계층의 바로 윗 부분은 컴포넌트 서비스(Component Service)계층으로써, 소프트웨어 컴포넌트가 복합 문서나 응용 프로그램에 흠결없이(seamless) 통합될 수 있는 기반 환경을 제공한다. 즉 오픈독 컴포턴트가 임의의 오픈독 플랫폼에서도 그 플랫폼 고유의 사용자 인터페이스나 실행 환경에서 원할 하게 동작할 수 있는 소위 크로스 플랫폼 지원 및 서비스의 대체성을 보장하고 있다. 플랫폼 제공 회사나 개발자들은 오픈독 전체 아키텍처 중 이 서비스의 일부 또는 전체를 원래 환경에 맞도록 대체하는 것이 가능하다. 따라서 오픈독의 외관은 윈도우, OS/2, 매킨토시 또는 유닉스 환경마다 특유의 모양을 가질 수 있다. 이 부분은 따라서 각 플랫폼에 포팅 될 때 대체될 수 있도록 명확한 인터페이스를 규정하고 있는 것이다. 또 개발자들이 원하는 개발 언어로 오픈독 파트를 개발할 수 있도록 해준다.
컴포넌트 서비스는 이밖에도 사용자가 파트를 최적화하거나 업무 자동화를 할 수 있도록 스크립트 언어 사용을 가능하게 해주며, 오픈독 파트에 새로운 메쏘드를 추가해도 파트 간에 상호 작용을 가능하게 함으로써 파트의 확장성을 보장한다.
오픈독 파트 간의 호환성은 여러 파트들이 화면에 표시될 때 이들 파트들이 플랫폼의 자원(메뉴 바, 키스트록 포커스 같은)을 공유할 수 있도록 파트 간의 협조/조정을 위한 인터페이스를 포함하고 있다. 
컴포넌트 레벨에서 반드시 필요한 서비스 중 하나가 객체의 저장을 지원하는 것이다. 오픈 독에서도 파트의 저장 서비스는 OLE에서와 마찬가지로 컴포넌트 간의 데이터 교환은 파트의 데이터를 디스크에 저장하는 것과 똑같은 메커니즘으로 클립보드나 네트워크에 저장함으로써 일관성 있는 자료 교환이 가능하다 (OLE의 Uniform Data Transfer와 유사하다). 요약하면, 컴포넌트 서비스에서는 오픈독 서비스에서는 오픈독 복합 문서의 저장을 위해 복합 문서 관리, 파트 편집기가 사용할 임시 메모리 관리, 문서 저장을 위해 문서 내에 포함된 파트 간의 이벤트 관리 등의 기능을 지원하며, 자원 공유를 위한 파트 간의 조정/협조를 위한 중재(Arbitration) 기능, 일관성 있는 자료 교환 기능 등을 포함한 서비스이다.
오픈독의 컴포넌트 서비스의 기능들과 개념들은 오픈독 전체를 이해하는데 매우 중요하기 때문에 조금 더 자세히 알아 보도록 하자.
자원 중재
하나의 컴퓨터에는 여러 컴포넌트들이 함께 공유해야만 하는 자원이 한정되어 있을 수밖에 없다. 이 자원을 어떤 컴포넌트에게 언제 할당해야 하는지를 결정하는 서비스가 오픈독의 자원 중재(Resource Arbitration)시스템이다. 이 서비스는 보통 운영체제가 지원하거나 컴포넌트 소프트웨어에서는 운영체제에서 제공하는 것보다 훨씬 정교한 수준의 서비스가 요구된다. 오픈독의 컴포넌트 서비스는 컴포넌트 레벨에서 이 기능을 제공하므로 플랫폼(운영체제)에 독립적인 자원 공유에 대한 해법을 제시하고 있다. 이 서비스를 위해 오픈독에서는 다음의 4가지 기본적인 컴포넌트(오픈독 파트)를 제공한다.
•	중재자 : 기본적으로 동적인 자원 데이터베이스(다음에 설명할 포커스 모듈의 데이터베이스)이며, 자원의 소유권 변동에 관한 프로토콜이 정의되어 있다.
•	포커스 모듈 : 주어진 특정 자원을 표시하며 이 자원이 어떻게 할당되는지를 알려준다( 즉 하나의 자원이 한 번에 얼마나 많은 요구를 수용할 수 있는지 등).
•	포커스 : 어떤 자원을 가리키는 토큰이다. 이것은 컴포넌트가 사용하기 원하는 자원의 이름(키보드, 마우스, 메뉴, 직력 포트 등)을 지정하는 데 사용된다. 각 포커스는 연결된 포커스 모듈이 있으며, 이를 통해 그 토큰이 가리키는 실제 자원을 관리한다.
•	포커스 세트 : 어떤 자원에 대한 소유권 요청을 하나의 단위로 묶는데 사용된다. 이는 다중 처리, 다중 쓰레드 컴포넌트를 지원하려면 반드시 필요한 기능이다. 즉 포커스 세트는 여러 자원에 대한 요구를 하나의 단위로 묶음으로서 데드락을 방지한다.(예를 들어, 두 컴포넌트가 각각 키보드와 메뉴 자원을 동시에 필요로 하고 한 컴포넌트는 키보드를 다른 컴포넌트는 메뉴를 할당받았다면, 각 컴포넌트는 서로 다른 자원을 동시에 요구할 것이므로(키보드를 소유한 컴포넌트는 메뉴를, 메뉴를 소유하고 있는 컴포넌트는 키보드를) 데드락이 발생할 수 있다. 오픈독에서는 이때 포커스 세트를 이용해 한 컴포넌트가 요구하는 자원을 한꺼번에 모두 할당받을 수 있도록 함으로써 다른 컴포넌트가 끼어 드는 것을 방지한다. 즉 앞의 경우에는 두 컴포넌트 중 한 컴포넌트에게만 두 자원을 모두 할당한다.
자원 중재자는 또 2 단계 위임( 2 phase commit )메카니즘을 사용해 확실한 자원 할당을 보장해주고 있다. 즉 어떤 자원이 요구되었을 때, 그 자원을 현재 소유하고 있는 컴포넌트는 다른 컴포넌트가 요청하고 있는 그 자원을 포기할 것인지 질문 받게 된다. 만약 현 소유자가 포기한다고 하면, 그 자원을 풀어 주는(release) 트랜잭션이 발생한다. 반대로 현 소유자가 그 요청을 거부하면 다른 컴포넌트의 요청은 실패하는 것이다. 실제의 경우 어떤 컴포넌트가 특정 자원을 요청했다는 뜻은 사용자가 그 컴포넌트를 통해 자원을 요구한 것이나 마찬가지므로 자원을 현재 소유하고 있는 컴포넌트가 요청된 자원에 대한 포기를 거부해야만 하는 상황은 매우 드물게 일어난다. 따라서 플랫폼의 자원은 사용자의 제어하에서 서로 협조적으로 할당된다.
여기서 중요한 점은 시스템 자원의 할당은 확장이 가능하다는 것이다. 새로운 종류의 하드웨어나 기타 다른 자원이 추가되면 이들 자원에 대해 새로운 포커스 모듈을 추가하므로 자원 중재가 쉽게 지원되는 것이다. 이들 새로운 포커스 모듈은 플랫폼 자원의 개발자(하드웨어 생산자)가 제작해 이 자원을 사용하는 컴포넌트와 함께 배포하거나 또는 인터넷 같은 공공 매체를 통해 공급할 것이다.
저장 서비스
문서 저장 서비스(Storage Service)는 복합 문서의 구성 요소인 컴포넌트들을 한꺼번에 저장하는 문제를 해결할 수 있도록 설계되었다. 이 서비스는 오픈독 문서 내의 개별 파트들이 실제로 어떤 방식으로 저장되는지를 몰라도 되도록 매우 추상적이면서도 다양한 기능을 가진 인터페이스를 지원한다. 이를 위해 오픈독의 저장 서비스에서는 저장 시스템(Storage system), 컨테이너(container), 문서(document), 드래프트(draft), 저장 유니트(storage unit) 같은 개념들을 정의하고 있다.<그림 2>
< 그림 2 > 오픈독 저장 서비스의 기본 개념

저장 시스템
저장 시스템(Storage System)은 <그림 2>의 연결고리의 맨 첫 부분으로 오픈독 저장 서비스의 여러 가지 구현 형태들을 관리한다. 즉 오픈독의 저장 시스템은 파일 시스템, OODBMS, 메모리 파일, 문서 관리 시스템 등 여러 가지 저장 기술을 동시에 지원할 수 있다. 즉 오픈독의 컴포넌트 저장 API만 충족시키면 어떤 저장 메카니즘이든지 사용할 수 있는 것이다.
컨테이너
컨테이너(Container)는 앞서 언급한 여러 가지 저장 메카니 즘 중 하나로 실제 구현된 저장 공간을 의미한다.  하나의 컨테이너는 하나 이상의 문서도 포함할 수 있다. 현재 오픈독에서는 문서 레벨의 저장을 처리하는 벤토(Bento)파일과 문서보다 상위 레벨의 계층 구조를 표시하는 기존의 파일 시스템(디렉토리/폴더 및 파일)을 사용하고 있다. 컨테이너는 보통 파일 형태를 가지고 있으나 다른 형태일 수도 있다. 예를 들어 메모리 블럭, 클립보드, 네트워크 메시지, 벤토값(Value)등도 컨테이너가 될 수 있으며, 향후에 등장할 임의의 종류의 매체라도 가능하다.
  컨테이너 API를 만족하는 저장 메카니즘이 구현된 것을 컨테이너 슈트(container suite)라고 한다. 벤토는 오픈독 문서를 서로 다른 플랫폼 간에 교환할 수 있는 컨테이너 슈트로 지정되어 있다. 즉 오픈독의 문서 저장 서비스는 기본적으로 벤토로 구현되어 있으나, 다른 방식의 저장 기술을 사용할 수도 있다. 벤토는 이식 가능한 객체 저장 라이브러리와 저장 포맷에 대한 정의로 구성되어 있으며, 오픈독이 멀티미디어 복합 문서의 저장, 교환할 수 있도록 해준다. 벤토는 업계에 공개된 기술로, 상업적으로도 검증된 기술로서 업계 표준 기구인 인터엑티브 멀티미디어 조합(Interactive Multimedia Association, IMA)에 의해 멀티미디어 자료의 교환을 위한 표준으로 채택된 기술이다.
벤토
벤토(Bento)는 목차를 가지고 있어서 저장된 컴포넌트의 계층 레벨이나 위치에 상관없이 매우 빠르게 액세스할 수 있다. 또 오픈독 문서에 포함된 컴포넌트를 문서와 상관없이 독립적으로 액세스할 수 있으므로 오픈독 외부의 시스템에서도 오픈독 문서 내에 데이터를 임의로 삽입하거나 조회할 수 있다. 또 벤토에서는 파일 시스템의 개별적인 요소들이 물리적으로 서로 다른 위치(다른 파일 또는 기계)에 있어도 저장될 수 있다. 현재 오픈독은 이 기능을 활용하고 있지는 않으나, 벤토의 이런 장점은 향후의 분산 처리 시스템으로의 전환을 매우 용이하게 해준다. 즉 벤토는 다음과 같은 장점을 가지고 있다.
①	벤토의 단순함과 범용적인 설계는 광범위한 종류의 저장 매체-파일, 클립보드,전자 메일 등-를 구현하기가 용이하다.
②	벤토 파일은 크기가 작고 매우 고성능의 I/O를 제공한다. 때로는 하드웨어의 성능에 맞먹는 성능을 내기도 한다.
③	매우 작은 객체로부터 매우 거대한 멀티미디어 객체까지 저장할 수 있는 확장성이 있으며, 텍스트, 그래픽, 숫자 자료, 음성, 동화상, 비디오등 다양한 종류의 자료를 저장할 수 있다.
④	저장되는 자료의 포맷과는 독립적으로 작동함으로써 표준 자료 포맷이나 독자적인 자료 포맷을 모두 지원할 수 있다. 또 하나의 컴포넌트가 복수 개의 자료 포맷을 가질 수도 있으며, 컴포넌트에 참조 각주를 부여할 수도 있다.
⑤	매킨토시, 도스, 윈도우, OS/2 및 여러 유닉스 버전에 이식되어 있다. 어떤 종류의 플랫폼에서도 읽을 수 있는 컨테이너를 생성할 수 있다.
⑥	이미 검증된 기술로서 여러 운영체제에서 사용되고 있다. 개발 툴(윈도우용 로터스 1-2-3), 멀티미디어 편집기(Avid OMFI)등 다양한 응용 프로그램에서 사용되며, 플랫폼과 상관없이 자료 교환이 가능하다.
문서
문서는 어떤 식으로든지 서로 연관된 의미를 자지고 있는 컴포넌트들의 집합이다. 앞서 언급한 바와 같이 이들 컴포넌트들은 애니메이션, 다이얼로그 박스, 연구 논문,달력 등과 같이 매우 다양하다. 현재의 오픈독에서 하나의 문서는 하나의 독립적인 벤토 디스크 파일로 되어 있다.
드래프트
드레프트(Draft)는 특정 시점에서의 문서의 상태이다. 다른 말로 하면 문서의 특정 버전이라고 할 수 있다. 한 문서는 여러 개의 드래프트를 가질 수 있다. 따라서 문서의 변경 상황을 파악할 수 있다. 여러 개의 버전을 가지고 있을 필요가 없으면, 이 드래프트들을 하나도 합칠 수도 있다. 드래프트는 문서의 이력을 관리한다는 측면 이외에 다른 용도로도 사용될 수 있다. 즉, 위크플로우 관리 환경에서 각 드래프트는 어떤 사람이 어떤 단계에서 문서의 어느 부분을 편집했는지 표시해주므로 작업의 각 단계를 표시한다. 즉 드래프트를 이용하면 워크플로우 기능을 구현할 수도 있다. 마지막으로 드래프트는 시스템이 다운됐을 때 문서 복구 용도로도 사용할 수 있다.
저장 유니트
저장 유니트(Draft)는 드래프트에 포함된 컴포넌트들이 저장되는 기본적인 단위이다. 하나의 저장 유니트는 이름이 붙여진 속성(property)과 값(value)을 가지고 있다. 저장 유니트는 또 오픈독 파트간에 자료 교환을 위한 기본 단위로도 이용된다.
<그림 3> 오픈독 문서의 구조 예

<그림 3>에 입반적인 오픈독 문서의 구조를 보였다. 여기서 보듯이 하나의 오픈독 문서는 이력에 따라 여러 개의 드래프트를 포함하며, 한 드래프트는 다시 하나 이상의 저장 유니트를 가질 수 있다. 저장 유니트에는 다시 속성과 값이 포함된다.
객체
벤토에 저장되는 객체는 단순한 것, 복잡한 형태를 갖는 것, 작은 것, 큰 것 모두 가능하다. 벤토의 객체는 사용자에게 문서의 내용으로서 실제로 유효한 의미를 가질 수 있는 임의의 구성 요소를 의미한다. 즉 문장의 단락, 차트 등이 벤토의 객체가 될 수 있다.
값
값(value)은 자료가 실제로 저장된 곳이며 컨테이너 내의 어느 곳이든 될 수 있다. 값 자체는 0바이트에서부터 264바이트까지 될 수 있다. 이 값은 저장 매체의 용량에 달려 있다.
속성
값의 역할을 정의한다. 속성은 레코드의 필드 이름과 유사하나, 객체에 자유롭게 추가될 수 있다는 점에서 다르다. 속성의 이름은 전역적으로 유일하여(globally unique)어떤 응용 프로그램에서도 알 수 있어야 한다. 예를 들어 객체의 이름, 작성자, 주석 등과 같은 값이 있다면 이것들은 ‘문자열’ 속성으로 지정될 수 있을 것이다. 보통 값의 용도가 다르면 속성도 달라진다. 속성은 타입이 포맷만을 지정하고 역할은 정의하지 않는다는 점에서 타입과 다르다.
타입
값의 타입은 값의 포맷과 구조를 지정하는 데 사용된다. 즉 어떤 값이 압축되어 있는지, 바이트 오더(byte order)가 무엇인지 등의 자세한 내용도 지정될 수 있다. 벤토는 개방형 아키텍쳐로서 타입 자체도 어떤 종류의 메타 자료든지 오픈독에 저장될 수 있도록 확장 가능하다.
컴포넌트의 라이프 싸이클
오픈독은 컴포넌트의 라이프 싸이클을 관리하는데 참조 개수(reference counting) 기법을 사용한다. 즉 오픈독에서는 오픈독 시스템 자체가 사용하거나 각 컴포넌트가 다른 컴포넌트를 사용하는 것을 컴포넌트별로 참조되고 있는 숫자를 매번 계수하여 컴포넌트에 할당된 자원을 관리한다.
컴포넌트의 확장
오픈독은 오픈독 컴포넌트들이 향후에도 계속 확장될 수 있는 범용 메커니즘을 제공하고 있다. 따라서 새로운 서비스를 추가하거나 기존의 서비스를 확장할 수 있다. 또 외부 컴포넌트에도 마찬가지의 확장성을 제공한다.
서비스 액세스
이 밖에도 오픈독의 실행 환경 제어를 도와주는 서비스로 세선 및 이름 바인딩의 두 가지 서비스가 더 있다. 자세한 내용은 다음에 설명할 오픈독 실행 환경에서 알아보기로 하자.
4.1.3.복합 문서 서비스	
복합 문서 서비스(Compound Document Service)의 주 임무는 화면에 컴포넌트를 표시하고 사용자 인터페이스를 관리하는 것이다. 즉 여러 종류의 자료를 통합적으로 지원하는 문서 모델과 함께 이 문서를 사용자에게 매끄럽고 자연스럽게 보여 주기 위한 사용자 인터페이스를 지원하는 상위 레벨의 서비스이다. 이 서비스는 여러 컴포넌트를 하나의 복합 문서 안에서 편집할 때 컴포넌트 간에 충돌 없이 원활한 편집을 위해 앞서 설명한 컴포넌트 레벨의 자원 중재와 유사한 시각적 공간(디스플레이, Visual Space)의 조정 기능도 포함하고 있다.
또 이 서비스는 여러 소프트웨어 개발자들이 독립적으로 개발한 파트들이 사용자 환경의 한 문서 내에서 서로간에 무리 없이 작동할 수 있도록 한다. 따라서 최종 사용자들이 자연스러운 문서 편집을 위한 In-Place에디팅 등도 이 레벨에서 지원한다.
복합 문서 서비스는 오픈독에서 최상위 레벨의 서비스이므로 오픈독 파트들의 실행 환경과도 밀접하게 관련되며, 파트들의 사용자 인터페이스 관련 서비스들을 지원하고 있다.
4.1.4.자동화 서비스
자동화 서비스(Automation Service)는 오픈독 파트를 프로그램으로 제어하는 수단의 일종이다. 하지만 오픈독 파트 개발 과정과 같은 방식이 아니라 완성된 파트의 파트 개발에 사용되는 프로그램 언어보다 훨씬 간단한 스크립트 언어를 이용해 파트를 제어한다. 오픈독의 자동화 서비스는 스크립트를 사용해 컴포넌트를 제어하고자 하는 사람에게 일관성 있는 내용 모델(content model)을 제공하기 위해 설계된 서비스이다.
  오픈독의 자동화 서비스는 다음에 설명할 개방형 스크립트 아키텍처(Open Script Architecture,OSA)와 애플 이벤트 서비스를 컴포넌트 레벨(응용 프로그램 레벨이 아닌)에서 지원하는 오픈독 클래스들로 구성되어 있다.
4.1.5.호환 서비스
호환 서비스(interoperability Service)는 오픈독과 다른 복합 문서 시스템이 복합 문서나 컴포넌트를 호환 가능하도록 해준다. 이것은 노벨의 OLEO(Open Linking and Embedding of Objects, ComponentGlue Technology)기술을 이용해 마이크로소프트 OLE2와 양방향 호환성을 제공한다.
4.2.  OpenDoc의 장점
4.2.1. 	multimedia document
	오픈독의 문서는 종래의 문자 정보, 그래픽, 스프레드시트 뿐만 아니라 동화상, 음성, 에니메이션, 자료 베이스 등과 같은 다양한 형태의 자료를 포함할 수 있다.
4.2.2. 	direct manipulation and In-Place Editing
	OLE와 달리 오픈독은 파트 간의 포함 관계가 무한대로 가능하다. 따라서 사용자들은 응용 프로그램의 윈도우를 오가며 잘라 붙이기를 할 필요가 없다. 결과적으로 사용자들은 응용 프로그램이 아닌 문서의 내용에 더욱 집중하여 작업할 수 있으며, 파트를 포함하고 있는 문서의 형태나 맥락에 따라 작업할 수 있는 이점이 있
4.2.3. 	Consolidation
	오픈독은 다양한 종류의 데이터가 한 문서에 포함되거나 링크 되어 있음에도 불구하고 이를 관리할 때는 하나의 파일로 통합해 관리할 수 있다. 사용자가 어떤 문서를 구성하고 있는 여러 개의 파일을 일일이 관리하는 대신 오픈독 문서가 낱개의 자료를 한꺼번에 관리해준다. 즉, 문서를 구성하고 있는 다양한 종류의 자료가 하나의 문서에 보관함으로써 문서의 교환이 용이해진다.
4.2.4. 	Consistency
	오픈독에서는 여러 종류의 오픈독 문서를 단 한 가지 툴만을 이용해 다룰 수 있다. 반대로 각각의 파트마다 특수한 편집기인 파트 편집기를 사용자의 입맛에 맞게 바꿀 수도 있다. 따라서 사용자는 한 종류의 자료(예를 들어 테스트)를 편집하는 방법만 알면 같은 텍스트 에디터를 다른 종류의 데이터에도 사용할 수 있으며, 원하면 그 데이터에 적합한 다른 편집기로 바꿔 사용할 수도 있다.
4.2.5. 	Tailorability
	사용자가 파트 단위의 편집기를 바꿀 수 있다면 사용자가 특정한 작업을 하기 위해 여러 곳에서 모아온 범용 파트를 조합하여 보다 복잡한 작업도 할 수 있어야 할 것이다. 즉 이미 정해져 있는 내용을 가진 파트로 다른 파트를 만드는데 사용될 수도 있다. 또 파트를 최적화하기 위해 스크립트를 사용할 수도 있다.
4.2.6. 	Uniformity
	오픈독은 문서 내 모든 종류의 미디어를 다루는 데 있어 일관성 있는 휴먼 인터페이스를 제공한다. 일관성은 오픈독 자체의 특성에 기인한 것과 파트 편집기 간의 상호 작용을 규정하는 가이드라인에 따른 것이 있다.
4.2.7. 	.Scalability
	오픈독의 휴먼 인터페이스는 초보자부터 숙달된 사용자까지 모두 쉽게 사용할 수 있도록 설계되었다. 각 단계의 사용자들은 다음 단계의 사용자가 쓰는 고급의 기능을 이해할 필요가 없다. 초보자도 링크와 스크립트 작성 같은 고급 기능을 몰라도 바로 시작할 수 있으며 - 즉, 초보자도 복합 문서를 쉽게 작성할 수 있다. - 전문 사용자도 자신의 능력에 따라 얼마든지 응용할 수 있다. 즉 오픈독의 아키텍처는 그 내부에 발전 가능성을 심어 놓고 있다.
4.2.8. 	 History
	오픈독의 문서는 이력을 관리하고 있어서 사용자가 언제 새로운 드래프트(draft)를 작성했는지, 수정했는지 등을 알 수 있다. 이 이력 정보는 문서와 함께 저장된다 사용자는 문서의 상태를 필요에 따라 어제의 상태나 두 달 전 상태대로 다시 볼 수 있다.
4.2.9. 	Forgiveness
	오픈독은 현재 대부분의 플랫폼이 갖고 있지 않은 다단계 취소(Undo) 기능을 지원한다. 취소 기능은 한 문서의 영역을 넘을 수도 있는데, 예를 들면 드래그 앤 드롭은 하나 이상의 파트나 문서에 영향을 미칠 수도 있으므로 이러한 기능은 매우 중요하다. 사용자 입장에서 본 이러한 장점을 최대한 살리기 위해 오픈독은 새로운 사용자 인터페이스(휴먼 인터페이스) 개념을 설정하고 있다.
第 5 章.	OpenDOC 대 OLE
5.1.  OpenDoc과 OLE의 비교
오픈독은 객체지향 기술의 기본 원리를 완벽하게 지원하는 업계 표준 분산 객체 모델을 하층 객체 모델로 탄탄한 토대를 쌓은 위에 깔끔하고도 명확한 인터페이스를 정의한 복합 문서 아키텍처이다. 오픈독은 분산 컴포넌트 개발을 위한 이상적인 개발환경을 제공하고 있는 것이다.
  참고로 밑의 표는 이미 널리 알려진 오픈독과 OLE의 비교표이다.
	오픈독	OLE	
객체 관리 모델	SOM
CORBA호환 ORB	COM
마이크로소프트/DEC 독자 기술	
개발 노력 정도	50 functions	126 functions	
스크립트 및 자동화	OSA, recordable macros	VB Script/automation	
Activation Model	directly, across nested, multiple active object	activate & edit, along nesting path, one at a time	
켄텐트 모양	불규칙한 모양도 가능	사각형	
스토리지 시스템	벤토(Bento)	DocFiles(DOS FAT file)
Storage/streams	
객체링크	persistend Ids	모니커(Moniker)	

목차 Contents
第 1 章.  Component Software란 무엇인가?	
1.1.  컴포넌트웨어의 연원	
1.2.  컴포넌트웨어 산업의 현재	
1.3.  컴포넌트웨어의 중요성	
第 2 章.  Component Software를 이용한 소프트웨어 개발	2
2.1.  컴포넌트웨어를 이용한 개발 모습	2
2.2.  각 컴포넌트웨어의 전략 시나리요	3
第 3 章.  OLE/COM과 OpenDoc의 出現	4
3.1.  마이크로소프트의 OLE	5
3.2. 	IBM, 애플의 OpenDoc	5
3.3. 	OpenDoc의 출현 배경 - 기존 소프트웨어의 문제	5
3.4. 	OpenDoc 컴퓨팅 모델			  5
第 4 章.  OpenDoc	6
4.1.  OpenDoc의 아키텍처	7
   4.1.1.  객체 관리 서비스	7
   4.1.2.  컴포넌트 서비스	8
   4.1.3.  복합 문서 서비스	14
   4.1.4.  자동화 서비스	15
   4.1.5.  호환 서비스	15
4.2. 	OpenDoc의 장점	15
第 5 章.  OpenDoc 대 OLE	17
4.1.  OpenDoc과 OLE의 비교	17

참고 자료			 	18

참고 문헌

월간 < 마이크로 소프트웨어 >	1996년 3월 	pp 394 ~ 406
	“OLE와 OpenDoc의 컴포넌트 소프트웨어 전쟁(1)

월간 < 마이크로 소프트웨어 >	1996년 4월 	pp 342 ~ 357
	“OLE와 OpenDoc의 컴포넌트 소프트웨어 전쟁(2)

HTTP :: //198.105.232.5/MSDN/library/back&rnd/objectrat.htm
	“The Microsoft Object Technology Strategy”

HTTP :: //dev.info.apple.com/du/intro_to_opendoc/iod2_ad_industry.html
	“OpenDoc and the Industry”

HTTP:: //www.developer.ibm.com/sdp/library/aixpert/june94/aixpert_june94_closeup.html
	“A close-Up of OpenDoc”

HTTP :: //198.105.232.5/MSDN/library/back&rnd/ole2ctrl.htm
	“OLE Custom Controls Backgrounder”

HTTP :: //cuesys.com/objects/
	“Object Oriented Information”