نموذج كائنات نظام 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 عبر مؤشر.

من مخاطر الواجهة المخصصة احتمال حدوث سلوك غير متوقع نتيجة عدم التوافق . فعلى سبيل المثال، إذا نُشر إصدار من الكائن بواجهة مخصصة مُعدّلة، فقد يتعطل البرنامج. وهذا مثال على مشكلة هشاشة الفئة الأساسية . ولمنع هذه المشكلة، تنص قاعدة تطوير COM على أنه بمجرد نشر الواجهة المخصصة، لا يمكن تغييرها. ولإضافة أو تغيير الميزات المعروضة للكائن، يمكن تنفيذ واجهات مخصصة إضافية.

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

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

يُعد دعم الوراثة أحد أبرز الاختلافات، إذ لا يدعمها COM. قد يبدو غريبًا أن تُنتج مايكروسوفت تقنية مكتبة كائنات لا تدعم هذا المفهوم الأساسي في البرمجة الكائنية، لكن السبب الرئيسي هو صعوبة تحديد موقع الفئة الأساسية في الذاكرة حيث تُحمّل المكتبات بترتيب غير معروف وقت التصميم. يتطلب COM من المبرمج تحديد الفئة الأساسية بدقة وقت الترجمة، مما يجعل إدراج فئات مشتقة أخرى أمرًا مستحيلاً، على الأقل في مكتبات COM الأخرى.

تستخدم SOM خوارزميةً للبحث عن الفئات الأساسية المحتملة من خلال تتبع شجرة الوراثة والتوقف عند أول فئة مطابقة. هذه هي الفكرة الأساسية للوراثة في معظم الحالات. أما عيب هذا النهج فهو احتمال توقف الإصدارات الجديدة من هذه الفئة الأساسية عن العمل حتى لو بقيت واجهة برمجة التطبيقات (API) كما هي. هذا الاحتمال موجود في أي برنامج، ليس فقط البرامج التي تستخدم مكتبة مشتركة، بل قد يصعب حل المشكلة إذا وُجدت في كود برمجي لشخص آخر. في SOM، الحل الوحيد هو اختبار الإصدارات الجديدة من المكتبات.

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

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