نموذج كائنات نظام IBM

نموذج كائن النظام ( SOM ) هو تقنية مكتبة مشتركة موجهة للكائنات طورتها شركة IBM تدعم تعريف واجهة لكائن ما بحيث تكون واجهته منفصلة عن تنفيذه .

DSOM ، وهو نوع موزع يعتمد على CORBA ، يسمح للكائنات الموجودة على أجهزة كمبيوتر مختلفة بالتواصل.

يمكن تحديث مكتبة SOM دون الحاجة إلى إعادة بناء كود العميل. فإذا تم تغيير المكتبة لإضافة فئات أو دوال جديدة، أو لتغيير التنفيذ الداخلي للفئات أو الدوال، فسيظل بإمكان البرنامج المستخدم الاستفادة منها دون الحاجة إلى إعادة بنائه. وبهذه الطريقة، تعالج SOM مشكلة واجهة البرمجة الثنائية الهشة التي تؤثر على تقنيات مكتبات أخرى مثل C++ .

تتيح SOM تعريف الفئات في لغة برمجة واحدة واستخدامها في لغة أخرى. يمكن للعميل إنشاء واستخدام كائنات من الفئات المعروضة واشتقاق فئات فرعية منها حتى لو كانت لغة العميل لا تدعم تحديد أنواع الفئات.

توفر SOM واجهة برمجة تطبيقات (API) تتيح الوصول إلى بيانات تعريف المكتبة . يعرض كل كائن طرقًا توفر اسم الفئة وما إذا كان الكائن ينفذ طريقة معينة، على سبيل المثال.

كان الهدف من SOM هو استخدامه على نطاق واسع في حواسيب IBM المركزية والمكتبية ( OS/2 )، مما يسمح للبرامج المصممة للحواسيب المكتبية باستخدام الحواسيب المركزية للمعالجة وتخزين البيانات. أنتجت IBM نسخًا من SOM/DSOM لأنظمة OS/2، ومايكروسوفت ويندوز ، وأنظمة يونكس المختلفة (ولا سيما نظام AIX الخاص بشركة IBM ). لفترة من الزمن بعد تشكيل تحالف AIM ، استخدمت شركة Apple Computer أيضًا SOM/DSOM لأغراض مماثلة. كان استخدامها الأكثر شيوعًا في إطار عمل OpenDoc الخاص بها ، ولكن استخدامها كان محدودًا في أدوار أخرى أيضًا.

لعلّ أكثر استخدامات SOM انتشارًا داخل شركة IBM كانت في الإصدارات اللاحقة من نظام التشغيل OS/2، حيث استُخدمت في معظم التعليمات البرمجية، بما في ذلك Workplace Shell . يستطيع Object REXX لنظام التشغيل OS/2 التعامل مع فئات وكائنات SOM، بما في ذلك WPS. ^{[ 1 ]}

لم تُوقف شركة IBM تقنية SOMobjects نهائيًا، بل نُقلت إلى نظام التشغيل OS/390، ولا تزال متاحة عليه. يمكن الاطلاع على الوثائق على موقع IBM الإلكتروني. ^{[ 2 ]} في عام 1996، استحوذت شركة Tandem Computers Inc. على تقنية SOMobjects. ^{[ 3 ]} بِيعت Tandem إلى Compaq، ثم بِيعت Compaq إلى Hewlett-Packard. دُمجت NonStop DOM وبعض التقنيات الأخرى لاحقًا في NonStop CORBA، ولكن الوثائق الحالية لمنتجات NonStop لا تُشير إلى استمرار استخدام تقنية SOM في تشغيلها.

مع "موت" نظام التشغيل OS/2 في منتصف التسعينيات، تلاشت الحاجة إلى مكتبة SOM/DSOM إلى حد كبير؛ فلو لم يكن المستخدمون يشغلون نظام OS/2 على أجهزة سطح المكتب، لما وُجدت مكتبة كائنات شاملة على أي حال. في عام 1997، عندما عاد ستيف جوبز إلى شركة آبل وأنهى العديد من جهود التطوير، بما في ذلك Copland و OpenDoc ، استُبدلت SOM بلغة Objective-C التي كانت مستخدمة بالفعل في OPENSTEP (الذي أصبح لاحقًا Mac OS X). تراجع تطوير SOM/DSOM، ولم يعد يُطوّر بنشاط، على الرغم من استمرار تضمينه واستخدامه في أنظمة تعتمد على OS/2 مثل ArcaOS . ^{[ 4 ]}

على الرغم من توقف نظام التشغيل OS/2 وبرنامج OpenDoc فعليًا، كان بإمكان SOM أن يجد له مكانة أخرى: تطوير تطبيقات ويندوز والتطبيقات متعددة المنصات . أُتيح الإصدار 3.0 من SOM لنظام WinNT بشكل عام في ديسمبر 1996. ولا تقتصر أسباب عدم التقدم في هذه المجالات على مشاكل تبني السوق، بل تشمل أيضًا الفرص التي أضاعتها شركة IBM ، ^{[ 5 ]} والتغييرات غير المتوافقة المدمرة.

• كان الإصدار الأول من VisualAge C++ لنظام التشغيل Windows هو الإصدار 3.5. وكان هذا الإصدار الأول والأخير الذي يدعم SOM. وقد تضمن SOM 2.1 مدمجًا، بالإضافة إلى دعم Direct-to-SOM في المُصرّف. أما الإصدارات 3.6.5 وما بعدها، فلم تتضمن أي أثر لـ SOM.
• كانت كائنات SOM تعتمد بشكل كبير على ملفات makefiles . قدّم VisualAge C++ 4.0 مشاريع .icc وأزال مُجمِّع ومُربط سطر الأوامر icc.exe و ilink.exe من حزمة VisualAge C++. من المستحيل إنشاء أي نموذج SOM DTK مباشرةً باستخدام VAC++ 4.0. يأتي VisualAge C++ مع نماذجه الخاصة، ولكن لا توجد نماذج .icc SOM حتى في VAC++ 4.0 لنظام التشغيل OS/2. لا يدعم vacbld.exe، أداة تجميع سطر الأوامر الوحيدة، كائنات SOM.
• لم تكن مكتبة مكونات الكائنات المدمجة في VisualAge C++ (OCL) مبنية على SOM. ربما كان من المفترض نقلها إلى SOM باستخدام وضع C++ Direct-to-SOM، ولكن في VAC v3.6.5 تم التخلي عن هذا الوضع، ولا تحتوي OCL على واجهة SOM حتى الآن.
• في أواخر التسعينيات، أغلقت شركة IBM مواقع تنزيل SOMobjects ولم تُعد تشغيلها. لا يمكن العثور على SOM 3.0 DTK لنظام التشغيل WinNT على خادم FTP الخاص بشركة IBM، على الرغم من وجود العديد من البرامج القديمة الأخرى مجانًا. وعلى الرغم من توفر SOM 3.0 لنظام التشغيل WinNT بشكل عام، إلا أنه كان من شبه المستحيل العثور عليه حتى نهاية عام 2012.
• وأخيرًا، لم تقم شركة IBM أبدًا بنشر برنامج SOM كمصدر مفتوح (كما فعلت مع برنامج Object REXX )، على الرغم من العديد من المقالات ^{[ 6 ] [ 7 ]} والعرائض. ^{[ 8 ]}

يوجد مشروعان لتطبيقات SOM مفتوحة المصدر. الأول هو نموذج كائنات Netlabs (NOM)، وهو مطابق تقنيًا، ولكنه غير متوافق ثنائيًا. أما الثاني فهو somFree، وهو تصميم مُعدّل بالكامل من IBM SOM، ومتوافق ثنائيًا.

يمكن مقارنة SOM بالمكتبات المجمعة التالية: ^{[ 9 ]}

• أحاديث قصيرة
• نظام كائنات لغة ليسب الشائعة (CLOS)
• لغة C++ العامة
• SGI Delta/C++
• واجهة صن الثنائية للكائنات
• أوبجكتيف سي
• جافا

اعتبارًا من عام 2015، تنطبق معظم المعلومات الواردة في الجدول المرفق على الإصدارات الحديثة، باستثناء حصول Objective-C 2.0 على ما يُسمى بمتغيرات النسخ غير الهشة. بقيت بعض الحلول تجريبية، مثل SGI Delta/C++ وSun OBI. تم التخلي تدريجيًا عن معظم المناهج القائمة على لغة برمجة واحدة، أو لم تُستخدم بشكل فعال بنفس الطريقة. على سبيل المثال، كُتبت إضافات متصفح Netscape Plugin Application Programming Interface ( NPAPI ) باستخدام Java API في البداية (LiveConnect)، ولكن تم استبعاد Java Virtual Machine (JVM) لاحقًا. يمكن اعتبار ذلك استبدال Java بنموذج كائنات المكونات متعدد المنصات ( XPCOM ). لا يُعرف نظام كائنات Common Lisp (CLOS) وSmalltalk بأنهما من روابط السلسلة مثل Java في LiveConnect. كما أن Objective-C غير معروف كثيرًا في هذا الدور، ولا يُعرف تسويقه بهذه الطريقة، ولكن بيئة تشغيله تُعد من أكثر البيئات ملاءمة لحالات الاستخدام المماثلة.

لا تزال لغة C++ العامة مستخدمة في Qt وبيئة سطح المكتب KDE . وتُعرف Qt وKDE بجهودهما المبذولة للحفاظ على التوافق الثنائي دون دعم خاص في أدوات التطوير. ^{[ 10 ]}

كان الهدف من GObject هو تجنب الاعتماد على مترجم C++، لكن مشاكل RRBC هي نفسها الموجودة في C++ العامة.

بدون بيئة تشغيل خاصة ، ستواجه العديد من لغات البرمجة الأخرى نفس المشاكل، مثل دلفي وآدا . ويمكن توضيح ذلك من خلال النهج غير المسبوق الذي تم اتباعه لإنتاج إصدار دلفي 2007 المتوافق ثنائيًا مع دلفي 2006: كيفية إضافة خاصية "منشور" دون الإخلال بتوافق DCU. مؤرشف بتاريخ 8 ديسمبر 2015 على موقع Wayback Machine.

تُعدّ لغة Objective-C المنافس الأبرز لـ SOM (مع أنها لا تُسوّق بنشاط كمنصة متعددة اللغات)، ويُفضّل مقارنة SOM بلغة Objective-C بدلاً من COM كما كان يحدث سابقاً. وبفضل متغيرات النسخ غير الهشة في Objective-C 2.0، تُعتبر الخيار الأمثل بين اللغات المدعومة حالياً.

تُستخدم COM و XPCOM بشكل فعّال، لكنهما تُديران الواجهات فقط، وليس التطبيقات، وبالتالي فهما ليسا على نفس مستوى SOM و GObject و Objective-C . يتصرف Windows Runtime، عند التدقيق فيه، بشكل مشابه لـ COM. يعتمد وصف بياناته الوصفية على .NET، ولكن نظرًا لأن WinRT لا يحتوي على بيئة تشغيل خاصة لحل مشكلات RRBC، كما هو الحال في Objective-C أو SOM، فقد كان لا بد من تطبيق العديد من القيود التي تحدّ من WinRT على المستوى الإجرائي.

نظام الكتابة (C++/CX)

يجب تعريف فئة المرجع التي تحتوي على مُنشئ عام على أنها مغلقة، لمنع المزيد من الاشتقاق.

مكونات وقت تشغيل ويندوز - مكونات وقت تشغيل ويندوز في بيئة .NET

ومن القيود الأخرى عدم إمكانية عرض أي فئات أو واجهات عامة. لا يتوفر تعدد الأشكال لأنواع WinRT، وأقرب ما يمكنك فعله هو تطبيق واجهات WinRT؛ يجب عليك تعريف أي فئات يتم عرضها بشكل عام بواسطة مكون وقت تشغيل Windows الخاص بك على أنها مغلقة.

كثيراً ما تتم مقارنة نموذج كائنات SOM بنموذج كائنات المكونات (COM) من مايكروسوفت . يدعم كلا النموذجين تنسيق مكتبة يمكن استخدامه من أكثر من لغة برمجة.

يرى البعض أن SOM أكثر متانة لأنه يدعم آلية استدعاء محايدة للغة، تشبه آلية الربط المتأخر في COM . يدعم COM أيضًا الربط المبكر ، المعروف أيضًا بالواجهة المخصصة، وهو أقل أمانًا ولكنه أكثر كفاءة. يسمح هذا للعميل بالوصول إلى كائن عبر جدول دوال متوافق مع لغة C ، وبالتالي متوافق مع التخطيط الثنائي للجدول الظاهري لكائنات C++ (على الأقل في مُصرّف C++ من مايكروسوفت). باستخدام مُصرّف C++ متوافق، يمكن تعريف واجهة مخصصة كفئة C++ ظاهرية خالصة. يمكن استدعاء هذه الواجهة من أي لغة تستطيع استدعاء دوال C عبر مؤشر.

A risk of a custom interface is that an incompatibility can result in undefined behavior. In particular, if a version of the object is published with a modified custom interface, a client may crash. This is an example of the fragile base class problem. To prevent the problem, a rule for COM development is that once published, a custom interface cannot be changed. To add or change the exposed features of an object, it can implement additional custom interfaces.

SOM avoid this issue by providing only late binding – allowing the run-time linker to re-build the table on the fly. This way, changes to the underlying libraries are resolved when they are loaded into programs.

SOM is more robust in terms of supporting object-oriented (OO) features. Whereas COM essentially defines a cut-down version of C++ to program to, SOM supports almost all common features. It also supports some less common features such as multiple inheritance, metaclasses and dynamic dispatching, which had led most SOM/COM-like systems to be simpler at the cost of supporting fewer languages. Multi-language support was important to IBM as they wanted to support both Smalltalk (single inheritance and dynamic dispatch) with C++ (multiple inheritance and fixed dispatch).

A notable difference is support for inheritance. COM does not. Although may think it odd that Microsoft produced an object library technology that could not support such a fundamental concept of OO programming; the main reason is that it is difficult to know where a base class exists in memory where libraries are loaded in a order unknown at design time. COM demands that the programmer specify the exact base class at compile time, making it impossible to insert other derived classes in the middle, at least in other COM libraries.

SOM instead uses an algorithm, looking for potential base classes by following the inheritance tree and stopping at the first one that matches. This is the idea behind inheritance in most cases. The downside to this approach is that it is possible that new versions of this base class may no longer work even if the API remains the same. This possibility exists in any program, not only those using a shared library, but a problem can become difficult to resolve if it exists in someone else's code. In SOM, the only solution is testing of new versions of libraries.

على الرغم من أن شركة IBM قد عارضت تقنيتي SOM وCOM، إلا أنهما لم تكونا متناقضتين. ففي عام 1995، ساهمت شركة نوفيل بتقنية ComponentGlue ^{[ 11 ]} في برنامج OpenDoc لنظام ويندوز. وقد وفرت هذه التقنية وسائل مختلفة للتكامل بين مكونات COM وSOM. وعلى وجه الخصوص، يمكن إتاحة كائنات SOM لتطبيقات OLE2 إما عن طريق جسر الربط المتأخر (المبني على IDispatch) أو واجهات COM ذات الأداء العالي. وباختصار، تُنفذ فئات SOM واجهات COM بهذه الطريقة.

تدعم تقنيات مشابهة، مثل Distributed Objects Everywhere ، التوريث الكامل. وقد تجنّبت Portable Distributed Objects هذه المشكلات من خلال نظام قوي للتحكم في الإصدارات، مما يسمح لمطوري المكتبات بإصدار نسخ جديدة إلى جانب النسخ القديمة، وبالتالي ضمان التوافق مع الإصدارات السابقة على حساب مساحة التخزين.