الخلاصة

  • يصف سجل John Day الشفهي نموذج OSI المرجعي بأنه إطار لتنظيم أعمال التقييس اللاحقة، لا توجيهاً لتنفيذ حزمة ثابتة من الطبقات.
  • اقترحت RINA لاحقاً بنية تكرارية للاتصال بين العمليات، واختبر ProtoRINA تنفيذاً محدوداً لها. لا تثبت المصادر المذكورة انتشاراً واسعاً في الإنتاج، ولا تثبت انعدام الاستخدام تماماً.

ما الذي لا يقرره الرسم؟

من السهل أن يُقرأ رسم الطبقات السبع بوصفه قائمة أعمال: تُنفّذ طبقة بعد أخرى حتى تكتمل الشبكة. غير أن رواية John Day تشير إلى غرض مختلف. ففي مقابلة التاريخ الشفهي التي سجّلها Computer History Museum عام 2010، وصف Day نموذج OSI المرجعي بأنه إطار لأعمال التقييس التي ستأتي لاحقاً، لا وثيقة تنفيذ. هذا استرجاعه الشخصي، وليس اقتباساً من نص المعيار أو بديلاً عن محاضر الاجتماعات. لكنه يوضح فرقاً عملياً: يمكن لنموذج مشترك أن يسمّي الوظائف ويوحّد لغة اللجان، من دون أن يحدد تصميم كل منتج أو ترتيب نشره لدى المشغّلين.

شارك John Day في ذلك المسار. ففي مقابلة مع Boston University قال إنه تولى دور مقرر النموذج المرجعي لـOSI ورئاسة لجنة البنية المعمارية لـOSI في ANSI. ويسجل أرشيف المتحف روايته عن الوفد الأمريكي والنقاشات الأولى. تضع هذه الشهادات Day داخل عمل جماعي مهم؛ لكنها لا تجعله المؤلف الوحيد لـOSI ولا تحول إطار اللجنة إلى أمر موجّه لكل مشغّل شبكة.

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

RINA: مقترح معماري لا تعداد للمتبنين

لم يكن عمل John Day اللاحق إضافة طبقة ثامنة إلى الرسم. ففي ورقة «Networking is IPC» المنشورة عام 2008، اقترح Day مع Ibrahim Matta وKarim Mattar فهم الشبكات من خلال الاتصال بين العمليات (IPC). تستخدم التطبيقات مرفقاً للـIPC، ويمكن لهذا المرفق أن يطلب بدوره خدمات من مرفق أدنى. تكرار الآلية هو لب الفكرة. إنها بنية مقترحة، وليست حصيلة مسح يبيّن الشبكات التي تبنتها.

تصف مجموعة RINA في Boston University مرفق IPC الموزع (DIF) بوصفه وحدة متكررة، وتشرح أن السياسات القابلة للضبط تحدد طريقة عمله. هذا شرح الفريق لتصميمه. يساعد على فهم ما يقترحه أصحاب المشروع، لكنه ليس تقييماً مستقلاً للأداء ولا برهاناً على أن RINA حلّت محل البنى الأخرى أو عالجت كل المشكلات التشغيلية.

يوضح ProtoRINA المسافة بين الفكرة والتنفيذ. تقدم ورقة عام 2014، التي ألّفها Wang وMatta وEsposito وJohn Day، نموذجاً أولياً يعمل في فضاء المستخدم وتجارب على حرم Boston University ومنصة GENI البحثية. وتصف الورقة نفسها صراحة بأنها مذكرة تحريرية غير محكّمة؛ كما تقول إن التنفيذ غير مكتمل وإن اتصال المستوى صفر يستخدم وسيط TCP. هذه القيود تحدد ما تثبته النتيجة: بُني جزء من التصميم واختُبر في بيئات مسماة. ولا تثبت نشره تجارياً على نطاق عام، أو استبدال الإنترنت، أو تفوقه المقارن.

هناك ثلاثة أسئلة منفصلة: ماذا يعرّف النموذج؟ ماذا شغّل تنفيذ بعينه فعلياً؟ وما الشبكات المستقلة التي اختارت التقنية، وبأي نطاق ولمدة كم؟ تساعد رواية John Day على الإجابة عن السؤال الأول، وتقترح ورقة RINA بنية، ويوثق ProtoRINA تجربة محدودة. لا توفر المصادر التي راجعها هذا الملف تعداداً شاملاً للإجابات عن السؤال الثالث. لذا لا يصح أن نستنتج أن RINA انتشرت في كل مكان، ولا أن لا أحد استخدمها قط.

التنسيق ليس أمراً بالتنفيذ

ليست العبرة في مسيرة John Day بإعلان خريطة نهائية للشبكات، بل بتمييز المواصفة المشتركة عن القرار المحلي. يمكن للتقييس أن يجعل الواجهات مفهومة بين المؤسسات. لكن على كل مشغّل أن يقرر هل تناسب البنية معداته وخدماته وموظفيه ومستوى المخاطر المقبول وموعد التحديث. يقلل النموذج الأولي الشك في قدرة الشيفرة على العمل داخل منصة اختبار؛ أما معرفة من تحمّل كلفة التشغيل وما استمر في الإنتاج فتحتاج إلى أدلة تبنٍّ.

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

المصادر