IBM 시스템 객체 모델

IBM System Object Model
시스템 객체 모델(파일 형식)과 혼동하지 마십시오.
IBM SOM 오브젝트
IBM SOM Logo
개발자IBM
안정된 릴리스
3.0 / 1996년 12월
운영 체제OS/2, Windows, AIX, Classic Mac OS, Copland, OS/390, 논스톱 OS, OS/400
유형객체 지향 공유 라이브러리 시스템

컴퓨팅에서 시스템 객체 모델(SOM)은 IBM이 개발한 객체 지향 공유 라이브러리 시스템입니다.CORBA에 기반한 분산 버전인 DSOM은 서로 다른 컴퓨터의 개체들이 통신할 수 있도록 허용했습니다.

SOM은 프로그램 간 또는 라이브러리와 프로그램 간의 인터페이스를 정의하여 개체의 인터페이스가 구현에서 분리되도록 합니다.SOM에서는 오브젝트 클래스를 하나의 프로그래밍 언어로 정의하고 다른 프로그래밍 언어로 사용할 수 있습니다.또, 클라이언트 코드를 재컴파일 할 필요 없이, 이러한 클래스의 라이브러리를 갱신할 수 있습니다.

SOM 라이브러리는 클래스, 메서드, 정적 함수 및 데이터 멤버 세트로 구성됩니다.SOM 라이브러리를 사용하는 프로그램에서는 SOM 라이브러리에 정의된 유형의 개체를 만들고 개체 유형에 정의된 메서드를 사용하며 SOM 라이브러리에 액세스하는 프로그램의 언어가 클래스 입력을 지원하지 않는 경우에도 SOM 클래스에서 하위 클래스를 파생할 수 있습니다.SOM 라이브러리와 해당 라이브러리의 개체 및 메서드를 사용하는 프로그램은 동일한 프로그래밍 언어로 작성될 필요가 없습니다.또한 SOM은 라이브러리에 대한 리비전의 영향을 최소화합니다.SOM 라이브러리가 변경되어 새로운 클래스 또는 메서드가 추가되거나 클래스 또는 메서드의 내부 구현이 변경되어도 다시 컴파일하지 않고 해당 라이브러리를 사용하는 프로그램을 실행할 수 있습니다.이것은 다른 모든 C++ 라이브러리의 경우는 아닙니다.이러한 라이브러리가 변경될 때마다 라이브러리를 사용하는 모든 프로그램을 재컴파일해야 하는 경우가 있습니다.이러한 프로그램은 취약한 바이너리 인터페이스 문제로 알려져 있습니다.

SOM은 프로그램에서 SOM 클래스 또는 SOM 개체에 대한 정보에 액세스할 수 있는 Application Programming Interface(API; 응용 프로그램프로그래밍 인터페이스)를 제공합니다.SOM 클래스는 예를 들어 개체의 클래스 이름을 찾거나 지정된 메서드를 개체에 사용할 수 있는지 여부를 결정하기 위해 사용할 수 있는 일련의 가상 메서드를 상속합니다.

적용들

SOM은 IBM의 메인프레임 컴퓨터에서 OS/2의 데스크톱에 이르기까지 보편적으로 사용되도록 설계되어 데스크톱에서 실행되지만 프로세싱 및 데이터 스토리지에 메인프레임을 사용하는 프로그램을 작성할 수 있게 되었습니다.IBM은 OS/2용 SOM/DSOM 버전, Microsoft Windows 및 다양한 Unix 맛(특히 IBM 자체 AIX)을 생산했습니다.AIM 얼라이언스 결성 후 한동안 SOM/DSOM은 애플 컴퓨터에서도 비슷한 목적으로 사용되었습니다.OpenDoc 프레임워크에서 가장 널리 사용되었지만 다른 역할에서도 제한적으로 사용되었습니다.

아마도 IBM 내에서 SOM을 가장 널리 사용한 것은 Workplace Shell을 포함한 대부분의 코드에 SOM을 사용한 OS/2의 최신 버전일 것입니다.OS/2용 오브젝트 REXX는 SOM 클래스 및 [1]WPS를 포함한 오브젝트를 처리할 수 있습니다.

SOMobjects는 IBM에 의해 완전히 종료되지 않았습니다.OS/390으로 이식되어 현재도 이 OS에서 사용할 수 있습니다.IBM [2]웹사이트에서 문서를 읽을 수 있다.1996년에 Tandem Computers Inc.는 SOMobjects [3]기술을 취득했다.Tandem은 Compaq에 매각되었고 Compaq는 Hewlett-Packard에 매각되었습니다.NonStop DOM 및 기타 테크놀로지는 최종적으로 NonStop CORBA로 통합되었지만, 현재 NonStop 제품의 문서에는 SOM 테크놀로지가 NonStop 제품을 계속 지원한다는 징후는 포함되어 있지 않습니다.

점점 희미해지다

1990년대 중반 OS/2가 "사망"되면서 SOM/DSOM의 존재 이유가 거의 사라졌습니다. 사용자가 데스크톱에서 OS/2를 실행하지 않는다면 범용 객체 라이브러리는 존재하지 않을 것입니다.1997년 스티브 잡스가 애플로 돌아와 Copland와 OpenDoc을 포함한 많은 개발 노력을 끝냈을 때 SOM은 OPENSTEP에서 이미 사용되고 있는 Objective-C로[4] 대체되었다(나중에 Mac OS X가 되었다).SOM/DSOM 개발은 점점 희미해져 현재는 활발하게 개발되지 않고 있지만,[5] ArcaOS와 같은 OS/2 기반 시스템에 계속 포함되어 사용되고 있습니다.

OS/2와 OpenDoc이 사실상 사망했지만 SOM에는 또 다른 틈새가 있을 수 있습니다.Windows 및 크로스 플랫폼 개발.WinNT용 SOM 3.0은 1996년 12월에 일반적으로 제공되었습니다.이러한 방향으로 나아가지 않는 이유는 시장 채택 문제를 넘어서는 것입니다.여기에는 IBM이 [6]놓친 기회와 호환되지 않는 파괴적인 변경 사항이 포함됩니다.

  • VisualAge C++ for Windows의 첫 번째 버전은 3.5였습니다.SOM을 지원하는 첫 번째 버전이자 마지막 버전입니다.컴파일러에서는 SOM 2.1을 번들하여 Direct-to-SOM을 지원하고 있습니다.버전 3.6.5 이후에는 SOM의 흔적이 없었습니다.
  • SOM 객체는 주로 makefile에 의존했다.VisualAge C++ 4.0은 .icc 프로젝트를 도입하여 icc.exe 및 ilink를 삭제하였습니다.exe 명령줄 컴파일러 및 링커를 제공합니다.VAC++ 4.0에서는 SOM DTK 샘플을 처음부터 작성할 수 없습니다.VisualAge C++는 자체 샘플과 함께 제공되지만 OS/2용 VAC++ 4.0에도 .icc SOM 샘플이 없습니다. 유일한 명령줄 컴파일 도구인 vacbld.exe는 SOM을 지원하지 않습니다.
  • VisualAge C++ OCL(Bundled-in Object Component Library)이 SOM을 기반으로 하지 않았습니다.C++ Direct-to-SOM 모드를 사용하여 SOM으로 포팅하는 것이 목적이었지만 VAC v3.6.5에서는 이 모드가 포기되어 지금까지 OCL에는 SOM 인터페이스가 없습니다.
  • 1990년대 말에 IBM은 SOMobjects 다운로드 사이트를 폐쇄하고 다시 온라인에 올리지 않았습니다.WinNT용 SOM 3.0 DTK는 IBM FTP에서 찾을 수 없습니다. 다른 많은 레거시 파일들이 자유롭게 놓여있음에도 불구하고 말이죠.WinNT용 SOM 3.0은 일반적으로 제공되지만 2012년 말까지 위치를 찾는 것은 거의 불가능했습니다.
  • 마지막으로, IBM은 여러[7][8] 기사와 [9]청원에도 불구하고 (Object REXX에 대해 한 것처럼) SOM을 오픈 소싱하지 않았습니다.

대체 구현

오픈 소스 SOM 구현에는 두 가지 프로젝트가 있습니다.하나는 Netlabs Object Model(NOM)로, 기술적으로 동일하지만 이진 호환성이 없습니다.또 다른 하나는 IBM SOM의 클린룸 설계로 바이너리 [citation needed]호환성이 있는 솜프리입니다.

컴파일된 클래스 라이브러리 지원 비교

지금까지 SOM은 IBM에 의해 Microsoft의 Component Object Model(COM)과 비교되었습니다.다만, 어떤 관점에서는, COM 의 존재는 전혀 없습니다.릴리스에서 릴리스로의 변환의 관점에서 COM은 절차적인 수준이기 때문에 RRBC 기사(앞에서 언급한 릴리스에서 릴리스로의 바이너리 호환성)의 표1에는 COM 컬럼이 전혀 포함되어 있지 않습니다.대신 SOM은 다음 제품과 비교됩니다.

이 표의 대부분의 정보는 비취약 인스턴스 변수라고 불리는 Objective-C 2.0을 제외하고 여전히 최신 버전(2015년 기준)에 적용할 수 있다.일부 솔루션(SGI Delta/C++ 또는 Sun OBI)은 실험적인 상태로 남아 있었습니다.하나의 프로그래밍 언어에 기반한 대부분의 접근 방식은 단계적으로 폐지되거나 동일한 방식으로 적극적으로 사용되지 않았습니다.예를 들어 Netscape Plugin Application Programming Interface(NPAPI) 브라우저 플러그인은 처음에는 Java API(LiveConnect)를 사용하여 작성되었지만 나중에 Java Virtual Machine(JVM)은 체인에서 제외되었습니다.Java가 Cross Platform Component Object Model(XPCOM; 크로스 플랫폼컴포넌트 오브젝트 모델)로 대체된 것으로 볼 수 있습니다.공통 Lisp Object System(CLOS)과 Smalltalk는 LiveConnect의 Java와 같은 체인 링크로 알려져 있지 않습니다.Objective-C는 또한 이 역할에 대해 잘 알려져 있지 않고 이러한 방식으로 마케팅되는 것으로 알려져 있지 않지만, 실행 시간은 유사한 사용 사례에 가장 우호적인 것 중 하나입니다.

Generic C++는 Qt 및 K데스크탑 환경(KDE)에서 아직 사용되고 있습니다.Qt와 KDE는 특별한 개발 [10]도구 지원 없이 바이너리 호환성을 유지하기 위한 노력을 설명하는 것으로 유명하다.

GObject는 C++ 컴파일러에 의존하지 않는 것을 목적으로 했을 뿐이지만, RRBC의 문제는 일반적인 C++와 동일합니다.

특별한 런타임이 없으면 델파이, 에이다 등 다른 프로그래밍 언어도 같은 문제가 발생합니다.이는 Dellphi 2006 바이너리 호환 Dellphi 2007 릴리스를 제작하기 위해 도입된 전례 없는 접근방식으로 설명할 수 있습니다.DCU 호환성을 해치지 않고 "공개된" 속성을 추가하는 방법

Objective-C는 SOM에 대한 가장 유망한 경쟁사이며(다언어 플랫폼으로 적극적으로 마케팅되지는 않지만), SOM은 역사적으로 발생했던 COM이 아닌 Objective-C와 비교되는 것이 바람직하다.Objective-C 2.0의 비취약 인스턴스 변수에서는 능동적으로 지원되는 것 중 가장 좋은 대안이다.

COM, XPCOM은 적극적으로 사용되고 있지만, 인터페이스만 관리하고 실장은 하고 있지 않기 때문에 SOM, GObject 및 Objective-C와 같은 레벨은 아닙니다.자세히 보면 Windows Runtime이 COM과 같이 동작합니다.메타데이터의 설명은, 에 근거하고 있습니다.NET 단, WinRT에는 Objective-C 또는 SOM과 같이 RRBC 문제를 해결하기 위한 특별한 실행 시간이 포함되어 있지 않기 때문에 절차 수준에서 WinRT를 제한하는 몇 가지 제한이 적용되어야 합니다.

타입 시스템(C++/CX)

퍼블릭 컨스트럭터가 있는 ref 클래스는 더 이상 파생되지 않도록 sealed로 선언해야 합니다.

Windows Runtime Components - 의 Windows Runtime Components.NET 월드

또 다른 제약사항은 범용 퍼블릭클래스나 인터페이스는 공개할 수 없다는 것입니다.다형성은 WinRT 타입에서는 사용할 수 없습니다.가장 가까운 것은 WinRT 인터페이스를 구현하는 것입니다.Windows Runtime Component에 의해 공개되는 클래스는 sealed로 선언해야 합니다.

COM과의 비교

SOM은 COM과 비슷한 개념입니다.두 시스템 모두 둘 이상의 언어로 호출할 수 있는 표준 라이브러리 포맷을 생성하는 문제에 대처합니다.SOM은 COM보다 견고하다고 간주할 수 있습니다.COM은 오브젝트에 대한 메서드에 액세스하는 두 가지 방법을 제공하며 오브젝트는 둘 중 하나 또는 둘 모두를 구현할 수 있습니다.첫 번째는 Dynamic and Late Binding(IDISPatch)으로 SOM에서 제공하는 것과 마찬가지로 언어 중립적입니다.두 번째 커스텀인터페이스라고 불리는 것은 C에서 빌드할 수 있는 함수 테이블을 사용하고 있지만 Microsoft의 C++ 컴파일러에 있는 C++ 객체의 바이너리 테이블의 바이너리 레이아웃과도 직접 호환성이 있습니다.따라서 호환성이 있는 C++ 컴파일러를 사용하면 커스텀인터페이스를 순수 가상 C++ 클래스로 직접 정의할 수 있습니다.그 결과 생성된 인터페이스는 포인터를 통해 C 함수를 호출할 수 있는 언어로 호출할 수 있습니다.커스텀 인터페이스는 견고성과 퍼포먼스를 트레이드합니다.릴리스된 제품으로 인터페이스가 퍼블리시되면 변경할 수 없습니다.이 인터페이스의 클라이언트애플리케이션은 이 인터페이스의 특정 바이너리 레이아웃에 근거해 컴파일 되어 있기 때문입니다.이는 새로운 버전의 공유 라이브러리가 설치되고 이전 버전에 기반한 모든 프로그램이 제대로 작동하지 않을 수 있기 때문에 DLL Hell로 이어질 수 있는 취약한 기본 클래스 문제의 예입니다.이 문제를 방지하려면 COM 개발자는 인터페이스가 공개되면 절대 변경하지 않도록 기억해야 합니다.또, 새로운 메서드나 그 외의 변경이 필요한 경우는, 새로운 인터페이스를 정의할 필요가 있습니다.

SOM은 런타임링커가 테이블을 즉시 재구축할 수 있도록 레이트바인딩만 제공함으로써 이러한 문제를 방지합니다.이렇게 하면 기본 라이브러리에 대한 변경 사항이 프로그램에 로드될 때 해결되지만 성능 비용이 발생합니다.

SOM은 또한 다양한 OO 언어를 완전히 지원한다는 측면에서 훨씬 더 강력합니다.기본 COM은 기본적으로 프로그램 대상 C++의 컷다운 버전을 정의하지만 SOM은 거의 모든 공통 기능과 더 난해한 기능을 지원합니다.예를 들어 SOM은 여러 상속, 메타클래스 및 동적 디스패치를 지원합니다.이러한 기능 중 일부는 대부분의 언어에서 찾을 수 없기 때문에 대부분의 SOM/COM 유사 시스템은 적은 수의 언어를 지원하면서 더 단순해졌습니다.그러나 IBM은 C++(복수 상속 및 고정 디스패치)를 통해 Smalltalk(단일 상속 및 동적 디스패치)를 모두 지원하기 위해 많은 노력을 기울이고 있었기 때문에 다국어 지원의 완전한 유연성이 중요했습니다.

SOM과 COM의 가장 현저한 차이점은 상속 지원입니다.COM에는 아무것도 없다.Microsoft가 OO 프로그래밍의 가장 기본적인 개념 중 하나를 지원하지 않는 객체 라이브러리 시스템을 만든 것은 이상하게 보일 수 있습니다. 주된 이유는 라이브러리가 랜덤 순서로 로드되는 시스템에서 기본 클래스가 어디에 존재하는지 알기 어렵기 때문입니다.COM은 프로그래머가 컴파일 시 정확한 베이스 클래스를 지정하도록 요구하기 때문에 중간에 다른 파생 클래스를 삽입할 수 없습니다(적어도 다른 COM 라이브러리에서는).

대신 SOM은 상속 트리에 따라 일치하는 첫 번째 클래스에서 중지함으로써 잠재적인 기본 클래스를 검색하는 단순한 알고리즘을 사용합니다.이것은 대부분의 경우 상속의 기본 개념입니다.이 접근법의 단점은 API가 그대로 유지되더라도 이 기본 클래스의 새 버전이 더 이상 작동하지 않을 수 있다는 것입니다.이러한 가능성은 공유 라이브러리를 사용하는 프로그램뿐만 아니라 다른 사용자의 코드에 문제가 있을 경우 추적하기가 매우 어려워질 수 있습니다.SOM에서 유일한 해결책은 새로운 버전의 라이브러리를 광범위하게 테스트하는 것입니다.이것은 항상 쉬운 것은 아닙니다.

SOM과 COM은 IBM에 의해 대체되었지만 상호 배타적이지 않았습니다.1995년 Novell은 Windows용 OpenDoc에 ComponentGlue[11] 기술을 기부했습니다.이 기술은 COM 기반 및 SOM 기반 구성요소 간에 서로 다른 통합 수단을 제공했습니다.특히 SOM 오브젝트는 레이트바인딩 브리지(IDispatch 기반) 또는 퍼포먼스가 높은 COM 인터페이스를 통해 OLE2 응용 프로그램에서 사용할 수 있습니다.기본적으로 SOM 클래스는 이러한 방식으로 COM 인터페이스를 구현합니다.

SOM이 제공하는 유연성은 거의 모든 사람들이[citation needed] 수고를 들일 만한 가치가 있다고 생각했지만, Sun Microsystems의 분산 객체(Distributed Objects Everywhere)와 같은 유사한 시스템도 완전한 상속을 지원했습니다.NeXT의 Portable Distributed Objects는 강력한 버전 관리 시스템을 통해 이러한 문제를 방지하여 라이브러리 작성자가 이전 버전과 함께 이전 버전을 출하할 수 있도록 함으로써 적은 디스크 공간 비용으로 하위 호환성을 보장합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Willis Buyon 박사의 SOM 및 객체 REXX (2004년 8월)
  2. ^ OS/390용 SOM 오브젝트 매뉴얼
  3. ^ 분산 객체 컴퓨팅을 위해 IBM의 SOMobjects 기술을 활용하는 Tandem
  4. ^ Ira R. Forman and Scott Danforth (1999). Putting Metaclasses to Work. ISBN 0-201-43305-2.
    11장 "릴리스 대 릴리스 이진 호환성", 246페이지
    동일한 이름과 동일한 작성자의 유사한 내용을 가진 문서는 웹에서 찾을 수 있습니다: 릴리스 간 바이너리스크
  5. ^ "List of ArcaOS 5.0 WPS Classes". Retrieved 2020-09-03.
  6. ^ Roger Sessions가 정원에서 길을 잃었다(1996년 8월)
  7. ^ Linux 개발자를 위한 Esther Schindler의 작은 SOM (2008년 2월)
  8. ^ Linux 데스크톱에서 OS/2의 최고 재생 2010-04-17 Wayback Machine by Steven J. Vaughan-Nichols (2008년 2월)
  9. ^ OS/2 청원, 2차 (2007~2010)
  10. ^ C++와의 바이너리 호환성 문제
  11. ^ ComponentGlue(tm)는 OLE, OCX 컨트롤과의 완전한 상호 운용성을 제공합니다.

외부 링크