IBM Sistem Nesne Modeli - IBM System Object Model

Sistem Nesne Modeli (dosya formatı) ile karıştırılmamalıdır .
IBM SOMnesneleri
IBM SOM Logosu
Geliştirici(ler) IBM
kararlı sürüm
3.0 / Aralık 1996
İşletim sistemi OS/2 , Windows , AIX , Klasik Mac OS , Copland , OS/390 , NonStop OS
Tip nesne yönelimli paylaşımlı kütüphane sistemi

Hesaplamada, Sistem Nesne Modeli ( SOM ), IBM tarafından geliştirilen nesne yönelimli bir paylaşımlı kitaplık sistemidir . DSOM dayalı bir dağıtık sürüm ÇORBA , farklı bilgisayarlar üzerinde izin nesneler iletişim kurmak için.

SOM, programlar arasında veya kitaplıklar ve programlar arasında bir arabirim tanımlar, böylece bir nesnenin arabirimi, uygulamasından ayrılır. SOM, nesne sınıflarının bir programlama dilinde tanımlanmasına ve diğerinde kullanılmasına ve bu tür sınıfların kitaplıklarının istemci kodunun yeniden derlenmesine gerek kalmadan güncellenmesine izin verir.

Bir SOM kitaplığı, bir dizi sınıf, yöntem, statik işlev ve veri üyelerinden oluşur. SOM kitaplığı kullanan programlar, SOM kitaplığına erişen programın dili sınıf yazmayı desteklemese bile, kitaplıkta tanımlanan türlerde nesneler oluşturabilir, bir nesne türü için tanımlanan yöntemleri kullanabilir ve SOM sınıflarından alt sınıflar türetebilir. Bir SOM kitaplığı ve bu kitaplığın nesnelerini ve yöntemlerini kullanan programların aynı programlama dilinde yazılmasına gerek yoktur. SOM ayrıca kitaplıklara yapılan revizyonların etkisini de en aza indirir. Bir SOM kitaplığı, yeni sınıflar veya yöntemler eklemek veya sınıfların veya yöntemlerin dahili uygulamasını değiştirmek için değiştirilirse, bu kitaplığı kullanan bir program yeniden derlemeden çalıştırılabilir. Bu, bazı durumlarda kitaplıklar değiştirildiğinde bunları kullanan tüm programların yeniden derlenmesini gerektiren diğer tüm C++ kitaplıkları için geçerli değildir, bu durum kırılgan ikili arabirim sorunu olarak bilinir .

SOM, programların bir SOM sınıfı veya SOM nesnesi hakkındaki bilgilere erişmesini sağlayan bir uygulama programlama arabirimi (API) sağlar. Herhangi bir SOM sınıfı, örneğin bir nesnenin sınıf adını bulmak veya belirli bir yöntemin bir nesne için kullanılabilir olup olmadığını belirlemek için kullanılabilecek bir dizi sanal yöntemi devralır.

Uygulamalar

SOM , IBM'in ana bilgisayarlarından OS/2'deki masaüstüne kadar evrensel olarak kullanılmak üzere tasarlandı ve masaüstünde çalışacak ancak işleme ve veri depolama için ana çerçeveleri kullanacak programların yazılmasına izin verdi. IBM OS / 2 için SOM / DSOM sürümlerini üretilen Microsoft Windows ve çeşitli Unix tatlar (özellikle IBM'in kendi AIX ). AIM ittifakının kurulmasından bir süre sonra SOM/DSOM, Apple Computer tarafından da benzer amaçlarla kullanıldı. En yaygın olarak OpenDoc çerçevesinde kullanıldı, ancak diğer rollerde de sınırlı kullanım gördü.

SOM'un IBM içinde belki de en yaygın kullanımları, onu Workplace Shell de dahil olmak üzere çoğu kod için kullanan OS/2'nin sonraki sürümlerindeydi . OS/2 için REXX nesnesi , WPS dahil olmak üzere SOM sınıfları ve nesneleri ile başa çıkabilir.

SOMobjects, IBM tarafından tamamen kapatılmadı. OS/390'a taşındılar ve bu işletim sisteminde hala kullanılabilir durumdalar. IBM web sitesindeki belgeler okunabilir. 1996 yılında Tandem Computers Inc., SOMobjects teknolojisini aldı. Tandem Compaq'a, Compaq Hewlett-Packard'a satıldı. NonStop DOM ve diğer bazı teknolojiler sonunda NonStop CORBA ile birleştirildi, ancak NonStop ürünlerinin mevcut belgeleri, NonStop ürünlerine güç vermeye devam eden SOM teknolojisinin belirtilerini içermiyor.

Sesin yok olması

1990'ların ortalarında OS/2'nin "ölümü" ile, SOM/DSOM'un varlık nedeni büyük ölçüde ortadan kalktı; kullanıcılar masaüstünde OS/2 çalıştırmıyor olsaydı, zaten evrensel bir nesne kitaplığı olmazdı. 1997'de Steve Jobs Apple'a döndüğünde ve Copland ve OpenDoc dahil olmak üzere birçok geliştirme çabasını sonlandırdığında , SOM, OPENSTEP'te (daha sonra Mac OS X olacak) halihazırda kullanımda olan Objective-C ile değiştirildi . SOM/DSOM geliştirmesi azaldı ve ArcaOS gibi OS/2 tabanlı sistemlere dahil edilmeye ve kullanılmaya devam etmesine rağmen artık aktif olarak geliştirilmiyor .

OS/2 ve OpenDoc'un etkili bir şekilde ölmesine rağmen, SOM'un başka bir alanı daha olabilir: Windows ve platformlar arası geliştirme. WinNT için SOM 3.0, Aralık 1996'da genel olarak mevcuttu. Bu yönlerde ilerlememenin nedenleri, pazar benimseme sorunlarının ötesine geçiyor. IBM tarafından kaçırılan fırsatları ve yıkıcı uyumsuz değişiklikleri içerir:

  • Windows için VisualAge C++'ın ilk sürümü 3.5 idi. SOM'u destekleyen ilk ve son sürümdü. Derleyicide SOM 2.1 paketi ve Direct-to-SOM desteği vardı. 3.6.5 ve sonraki sürümlerde SOM izi yoktu.
  • SOMobjects büyük ölçüde makefiles'e dayanıyordu . VisualAge C++ 4.0, .icc projelerini tanıttı ve icc.exe ve ilink.exe komut satırı derleyicisini ve bağlayıcısını tedarikten kaldırdı. VAC++ 4.0 ile kutudan çıktığı gibi herhangi bir SOM DTK örneği oluşturmak imkansızdır. VisualAge C++ kendi örnekleriyle birlikte gelir, ancak OS/2 için VAC++ 4.0'da bile .icc SOM örnekleri yoktur. Tek komut satırı derleme aracı olan vacbld.exe, SOM'u desteklemez.
  • VisualAge C++ paketlenmiş Nesne Bileşen Kitaplığı (OCL), SOM'u temel almıyordu. Muhtemelen C++ Direct-to-SOM modu kullanılarak SOM'a taşınması gerekiyordu, ancak VAC v3.6.5'te bu mod terk edildi ve OCL'nin şu ana kadar SOM arayüzü yok.
  • 1990'ların sonlarına doğru IBM, SOMobjects indirme sitelerini kapattı ve bir daha asla çevrimiçi duruma getirmedi. WinNT için SOM 3.0 DTK, etrafta serbestçe dolaşan birçok eski şeye rağmen IBM FTP'de bulunamıyor. SOM 3.0'ın WinNT için genel kullanıma sunulmasına rağmen, 2012'nin sonuna kadar yerini bulmak neredeyse imkansızdı.
  • Son olarak, IBM , çeşitli makalelere ve dilekçelere rağmen , hiçbir zaman açık kaynaklı SOM'u ( Object REXX'te olduğu gibi ) sağlamadı .

Alternatif uygulamalar

Açık kaynaklı SOM uygulamalarının iki projesi mevcuttur. Bunlardan biri, teknik olarak aynı, ancak ikili uyumsuz olan Netlabs Nesne Modeli'dir (NOM). Bir diğeri, IBM SOM'un temiz oda tasarımı olan ve ikili uyumlu olan somFree'dir .

Derlenmiş sınıf kitaplıkları desteğinin karşılaştırılması

Tarihsel olarak, SOM, IBM tarafından Microsoft'un Bileşen Nesne Modeli (COM) ile karşılaştırıldı. Ancak bazı açılardan COM'a hiç yer yoktur. Yayından yayına dönüşümler açısından, COM yordamsal düzeydedir, bu nedenle RRBC makalesindeki ( daha önce başvurulan Yayından Yayına İkili Uyumluluk ) tablo 1 COM sütununu hiç içermez. Bunun yerine, SOM şu şekilde karşılaştırılır:

Bu tablodaki çoğu bilgi, Objective-C 2.0'ın kırılgan olmayan örnek değişkenleri olarak adlandırılması dışında, modern sürümler için (2015 itibariyle) hala geçerlidir. Bazı çözümler deneysel olarak kaldı: SGI Delta/C++ veya Sun OBI. Bir programlama diline dayalı yaklaşımların çoğu aşamalı olarak kaldırıldı veya hiçbir zaman aynı şekilde aktif olarak kullanılmadı. Örneğin, Netscape Eklentisi Uygulama Programlama Arayüzü ( NPAPI ) tarayıcı eklentileri başlangıçta Java API kullanılarak yazılmıştır (LiveConnect), ancak Java Sanal Makinesi (JVM) daha sonra zincirden çıkarılmıştır. Java'nın Çapraz Platform Bileşen Nesne Modeli ( XPCOM ) ile değiştirildiği görülebilir . Common Lisp Object System (CLOS) ve Smalltalk, LiveConnect'teki Java gibi zincir bağlantılar olarak bilinmemektedir. Objective-C de bu rolde pek bilinmez ve bu şekilde pazarlandığı bilinmemektedir, ancak çalışma zamanı benzer kullanım durumlarına en uygun olanlardan biridir.

Generic C++ hala Qt ve K Desktop Environment'ta ( KDE ) kullanılmaktadır. Qt ve KDE, geliştirme araçlarında özel destek olmaksızın ikili uyumluluğu sürdürmek için gereken çabaları açıklamak için dikkate değerdir.

GObject yalnızca C++ derleyicisine bağımlılıktan kaçınmayı amaçladı, ancak RRBC sorunları genel C++ ile aynıdır.

Özel çalışma zamanı olmadan diğer birçok programlama dilinde aynı sorunlar olacaktır, örneğin Delphi , Ada . Bu sözde ile gösterilebilir görülmemiş bir yaklaşımla bunun 2006 Delphi üretmeye aldı ikili uyumlu Delphi 2007 sürümü: DCU uyumluluğu bozmadan bir "yayınlanan" özelliği nasıl eklenir

Objective-C , SOM için en umut verici rakiptir (çoklu dil platformu olarak aktif olarak pazarlanmamasına rağmen) ve SOM, tarihsel olarak olduğu gibi COM'un aksine tercihen Objective-C ile karşılaştırılmalıdır. Objective-C 2.0'daki kırılgan olmayan örnek değişkenleri ile aktif olarak desteklenenler arasında en iyi alternatiftir.

COM , XPCOM aktif olarak kullanılmaktadır, ancak uygulamaları değil sadece arayüzleri yönetirler ve bu nedenle SOM, GObject ve Objective-C ile aynı seviyede değildirler . Windows Çalışma Zamanı daha yakından bakıldığında COM gibi davranır. Meta veri açıklaması .NET'e dayanmaktadır, ancak WinRT, Objective-C veya SOM'daki gibi RRBC sorunlarını çözmek için özel çalışma zamanı içermediğinden, WinRT'yi prosedürel düzeyde sınırlayan birkaç kısıtlamanın uygulanması gerekiyordu:

Tip Sistem (C++/CX)

Daha fazla türetmeyi önlemek için ortak bir oluşturucuya sahip bir ref sınıfı mühürlü olarak bildirilmelidir.

Windows Çalışma Zamanı Bileşenleri - .NET Dünyasında Windows Çalışma Zamanı Bileşenleri

Başka bir kısıtlama, hiçbir genel genel sınıf veya arabirimin açığa çıkarılamamasıdır. Çok biçimlilik WinRT türleri için mevcut değildir ve en yakınınız WinRT arabirimlerini uygulamaktır; Windows Çalışma Zamanı Bileşeniniz tarafından herkese açık olarak gösterilen tüm sınıfları mühürlü olarak bildirmeniz gerekir.

COM ile karşılaştırma

SOM, kavram olarak COM'a benzer. Her iki sistem de birden fazla dilden çağrılabilen standart bir kitaplık formatı üretme sorununu ele alır. SOM, COM'dan daha sağlam olarak kabul edilebilir. COM, bir nesneye erişim yöntemleri için iki yöntem sunar ve bir nesne bunlardan birini veya her ikisini birden uygulayabilir. İlki dinamik ve geç bağlamadır ( IDispatch ) ve SOM tarafından sunulanlara benzer şekilde dilden bağımsızdır. Özel Arayüz adı verilen ikincisi, C'de oluşturulabilen, ancak Microsoft'un C++ derleyicisindeki sanal C++ nesnelerinin ikili düzeniyle de doğrudan uyumlu olan bir işlev tablosu kullanıyor. Uyumlu C++ derleyicileri ile Özel Arayüzler bu nedenle doğrudan saf sanal C++ sınıfları olarak tanımlanabilir. Ortaya çıkan arabirim daha sonra işaretçiler aracılığıyla C işlevlerini çağırabilen diller tarafından çağrılabilir. Özel Arayüzler, performans için sağlamlık takas eder. Bir arayüz piyasaya sürülen bir üründe yayınlandıktan sonra değiştirilemez, çünkü bu arayüzün istemci uygulamaları bu arayüzün belirli bir ikili düzenine göre derlenmiştir. Bu, paylaşılan bir kitaplığın yeni bir sürümü yüklendiğinden ve eski sürüme dayalı tüm programlar düzgün çalışmayı durdurabileceğinden DLL cehennemine yol açabilecek kırılgan temel sınıf sorununa bir örnektir . Bu sorunu önlemek için COM geliştiricileri, yayımlandıktan sonra bir arabirimi asla değiştirmemeyi ve yeni yöntemler veya başka değişiklikler gerekliyse yeni arabirimlerin tanımlanması gerektiğini unutmamalıdır.

SOM, çalışma zamanı bağlayıcısının tabloyu anında yeniden oluşturmasına izin vermek için yalnızca geç bağlama sağlayarak bu sorunları önler. Bu şekilde, temel kitaplıklarda yapılan değişiklikler, bir performans maliyeti olsa da, programlara yüklendiklerinde çözümlenir.

SOM ayrıca çok çeşitli OO dillerini tam olarak destekleme açısından çok daha sağlamdır. Temel COM temel olarak programlamak için C++'ın kısaltılmış bir sürümünü tanımlarken, SOM hemen hemen tüm ortak özellikleri ve hatta daha ezoterik olanları destekler. Örneğin SOM, çoklu kalıtımı , metasınıfları ve dinamik gönderimi destekler . Bu özelliklerden bazıları çoğu dilde bulunmaz, bu da çoğu SOM/COM benzeri sistemin daha az dili destekleme pahasına daha basit olmasına neden olmuştur. Ancak, hem Smalltalk'ı ( tek devralma ve dinamik gönderme ) hem de C++ ( çoklu devralma ve sabit gönderme ) ile desteklemek için büyük çaba sarf ettikleri için, çoklu dil desteğinin tam esnekliği IBM için önemliydi .

SOM ve COM arasındaki en dikkate değer fark, kalıtım desteğidir; COM'da herhangi bir destek yoktur. Microsoft'un OO programlamanın en temel kavramlarından birini destekleyemeyen bir nesne kitaplığı sistemi üretmesi garip görünebilir; bunun ana nedeni, kütüphanelerin potansiyel olarak rastgele bir sırayla yüklendiği bir sistemde bir temel sınıfın nerede olduğunu bilmenin zor olmasıdır. COM, programcının derleme zamanında tam temel sınıfı belirlemesini talep eder, bu da ortaya başka türetilmiş sınıfların eklenmesini imkansız hale getirir (en azından diğer COM kitaplıklarında).

Bunun yerine SOM, miras ağacını izleyerek ve eşleşen ilkinde durarak potansiyel temel sınıfları arayan basit bir algoritma kullanır; çoğu durumda kalıtımın arkasındaki temel fikir budur. Bu yaklaşımın dezavantajı, API aynı kalsa bile bu temel sınıfın yeni sürümlerinin artık çalışmayabilmesidir . Bu olasılık, yalnızca paylaşılan bir kitaplık kullananlarda değil, herhangi bir programda mevcuttur, ancak bir başkasının kodunda varsa, bir sorunun izini sürmek çok zor olabilir. SOM'da tek çözüm, her zaman kolay olmayan kitaplıkların yeni sürümlerinin kapsamlı bir şekilde test edilmesidir.

SOM ve COM, IBM tarafından çelişkili olarak kullanılsa da, birbirlerini dışlamıyorlardı. 1995'te Novell, ComponentGlue teknolojisini Windows için OpenDoc'a katkıda bulundu. Bu teknoloji, COM ve SOM tabanlı bileşenler arasında entegrasyon için farklı yollar sağladı. Özellikle, SOM nesneleri, geç bağlama köprüsü (IDispatch'e dayalı) veya daha yüksek performansa sahip COM arabirimleri aracılığıyla OLE2 uygulamaları için kullanılabilir hale getirilebilir. Özünde, SOM sınıfları COM arabirimlerini bu şekilde uygular.

SOM tarafından sunulan esneklik değerinde neredeyse herkes tarafından sorun olarak kabul edildi, ancak bu tür benzer sistemler, Sun Microsystems ' Dağıtık Nesneler Her yerde , aynı zamanda tam bir miras destekledi. NeXT 'in Taşınabilir Dağıtık Nesneler böylece garanti kütüphane yazarları eski ile birlikte yeni sürümleri sevk sağlayan güçlü bir sürüm sistemi üzerinden bu konuları kaçınılması geriye dönük uyumluluk disk alanı küçük maliyet için.

Ayrıca bakınız

Referanslar

  1. ^ SOM ve Object REXX , Dr. Willis Boughton (Ağustos 2004)
  2. ^ OS/390 belgeleri için SOMobjects
  3. ^ Tandem, Dağıtılmış Nesne Hesaplama için IBM'in SOMobjects Teknolojisinden Yararlanıyor
  4. ^ Ira R. Forman ve Scott Danforth (1999). Metasınıfları Çalıştırmak . ISBN'si 0-201-43305-2.
    Bölüm 11 "Yayından Yayına İkili Uyumluluk", sayfa 246
    Aynı ada ve aynı yazara ait benzer içeriğe sahip bir makale Web'de bulunabilir: Yayından Yayına İkili Uyumluluk
  5. ^ "ArcaOS 5.0 WPS Sınıflarının Listesi" . 2020-09-03 alındı .
  6. ^ Lost in the Garden , Roger Sessions (Ağustos 1996)
  7. ^ Linux geliştiricileri için küçük bir SOM olayı , Esther Schindler (Şubat 2008)
  8. ^ Reviving OS/2'nin Linux masaüstünde en iyisi Steven J. Vaughan-Nichols tarafından2010-04-17'de Wayback Machine'de arşivlendi (Şubat 2008)
  9. ^ OS/2 dilekçesi , ikinci tur (2007-2010)
  10. ^ C++ ile İkili Uyumluluk Sorunları
  11. ^ ComponentGlue(tm) OLE, OCX Denetimleriyle Tam Birlikte Çalışabilirlik Sağlar

Dış bağlantılar