هندسة إدارة البيانات الموزعة

هندسة إدارة البيانات الموزعة ( DDM ) هي بنية برامج IBM المفتوحة والمنشورة لإنشاء البيانات وإدارتها والوصول إليها على جهاز كمبيوتر بعيد. تم تصميم DDM في البداية لدعم الملفات الموجهة للتسجيل ؛ تم تمديده لدعم الدلائل الهرمية والملفات الموجهة نحو التدفق وقوائم الانتظار ومعالجة أوامر النظام ؛ تم توسيعه ليكون أساسًا لهندسة قواعد البيانات الارتباطية الموزعة (DRDA) الخاصة بشركة IBM ؛ وأخيرًا ، تم تمديده لدعم وصف البيانات وتحويلها. تم تعريفه في الفترة من 1980 إلى 1993 ، يحدد DDM المكونات والرسائل والبروتوكولات الضرورية ، وكلها تستند إلى مبادئ توجيه الكائن . DDM ليس ، في حد ذاته ، قطعة من البرامج ؛ يأخذ تنفيذ DDM شكل منتجات العميل والخادم. باعتبارها بنية مفتوحة ، يمكن للمنتجات تنفيذ مجموعات فرعية من بنية DDM ويمكن للمنتجات توسيع DDM لتلبية المتطلبات الإضافية. مجتمعة ، تنفذ منتجات DDM نظام ملفات موزع .

التطبيقات الموزعة

يجب على مصممي التطبيقات الموزعة تحديد أفضل وضع لبرامج وبيانات التطبيق من حيث كمية وتكرار البيانات المراد نقلها ، إلى جانب اعتبارات إدارة البيانات والأمن وحسن التوقيت. هناك ثلاثة نماذج خادم - عميل لتصميم التطبيقات الموزعة:

1. يقوم بروتوكول نقل الملفات (FTP) بنسخ أو نقل الملفات الكاملة أو جداول قاعدة البيانات إلى كل عميل بحيث يمكن تشغيلها محليًا. هذا النموذج مناسب للتطبيقات التفاعلية للغاية ، مثل محرري المستندات وجداول البيانات ، حيث يكون لكل عميل نسخة من المحرر المقابل ولا يمثل مشاركة مثل هذه المستندات مصدر قلق بشكل عام.
2. تقدم تطبيقات العميل الرقيق واجهة التطبيق للمستخدمين بينما تتمركز الأجزاء الحسابية للتطبيق مع الملفات أو قواعد البيانات المتأثرة. يتكون الاتصال بعد ذلك من استدعاءات الإجراءات عن بُعد بين العملاء الرقيقين والخادم حيث تحدد الرسائل المصممة بشكل فريد الإجراء المطلوب استدعاؤه والمعلمات المرتبطة به وأي قيم تم إرجاعها.
3. تؤدي تطبيقات العميل الدهني جميع مهام معالجة التطبيقات على أنظمة العميل ، ولكن تتمركز البيانات في الخادم بحيث يمكن إدارتها ، بحيث يمكن الوصول إليها من خلال أي تطبيق عميل معتمد ، بحيث تعمل جميع تطبيقات العميل بأحدث التحديثات البيانات ، وبذلك يتم نقل السجلات أو أقسام الدفق أو جداول قاعدة البيانات المتأثرة بالتطبيق فقط. يجب توزيع برامج تطبيقات العميل على جميع العملاء الذين يتعاملون مع البيانات المركزية.

تم تصميم بنية DDM في البداية لدعم نموذج العميل البدين للتطبيقات الموزعة ؛ كما أنه يدعم عمليات نقل الملفات بالكامل.

الفوائد التي توفرها بنية DDM

توفر بنية DDM للتطبيقات الموزعة الفوائد التالية: ^[1]

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

التاريخ

بنية DDM هي مجموعة من المواصفات للرسائل والبروتوكولات التي تتيح إدارة البيانات الموزعة عبر شبكة من أجهزة الكمبيوتر والوصول إليها. ^[2]

الجهود الأولية

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

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

كان أعضاء مجموعة عمل SNA من مختبر التطوير في روتشستر ، مينيسوتا التابع لشركة آي بي إم مقتنعين بوجود دراسة جدوى للخدمات الموزعة بين أنظمة الكمبيوتر متوسطة المدى المنتجة في روتشستر. تم تنفيذ شكل بدائي من خدمات الملفات الموزعة ، يسمى مرفق ملفات البيانات الموزعة ( DDFF ) لتوصيل أجهزة الكمبيوتر الصغيرة / 3 IBM System / 34 و IBM System / 36 . علاوة على ذلك ، فإن نظام IBM / 36 ونظام IBM / 38كان يتم بيع أجهزة الكمبيوتر للعملاء في شكل مضاعفات ، وكانت هناك حاجة واضحة لتمكين أجهزة الكمبيوتر الرئيسية لشركة ما ، على سبيل المثال ، من التفاعل مع أجهزة الكمبيوتر في مستودعاتها المختلفة. تم تنفيذ APPC على هذه الأنظمة واستخدامها بواسطة تطبيقات العملاء المختلفة. ثم تم إحياء فكرة خدمات نظام التشغيل الموزع كمشروع Golden Gate ومحاولة لتبرير تطويره. هذه المحاولة فشلت أيضا ؛ كانت الفكرة الكاملة للخدمات الموزعة جديدة جدًا بالنسبة لمخططي منتجات IBM بحيث لم يتمكنوا من تحديد قيمة البرامج التي تربط أجهزة الكمبيوتر غير المتجانسة.

ومع ذلك ، ظل جون بوندي ، أحد مخططي Golden Gate ، مقتنعًا ومقتنعًا بالإدارة بإنشاء قسم خارج نطاق السيطرة العادية لمختبر روتشستر حتى لا تكون هناك حاجة فورية لحالة عمل محددة مسبقًا. علاوة على ذلك ، قام بتضييق مهمته لتشمل فقط دعم إدارة البيانات الموزعة (DDM) ، على وجه الخصوص ، دعم الملفات الموجهة للتسجيل . ثم أقنع مهندس برمجيات متمرس ، ريتشارد أ. ديمرز ، بالانضمام إليه في مهام تعريف بنية DDM وبيع فكرة DDM لمنازل نظام IBM.

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

خلال هذه الفترة ، صمم Demers نموذجًا معماريًا لعملاء وخوادم DDM ومكوناتهم والتفاعلات بين أجهزة الكمبيوتر المتصلة. علاوة على ذلك ، حدد تنسيقًا عامًا لرسائل DDM استنادًا إلى مبادئ توجيه الكائن كما كانت رائدة في لغة برمجة Smalltalk و IBM System / 38. أوضح هذا النموذج كيف يمكن تنفيذ منتجات DDM على أنظمة مختلفة. انظر كيف يعمل DDM .

في عام 1982 ، أصبح مخططو System / 36 مقتنعين بوجود سوق كافٍ لخدمات الملفات الموجهة لسجلات DDM. ^[3]

مستوى DDM 1: ملفات التسجيل الموجهة

تم بالفعل تصميم التنسيق العام لرسائل DDM ، ولكن ما هي الرسائل المحددة التي يجب تحديدها؟ تم تعريف نظام الملفات System / 36 لتلبية الاحتياجات الموجهة نحو التسجيل للغات برمجة الجيل الثالث (3GLs) ، مثل Fortran و COBOL و PL / I و IBM RPG ، وكذلك نظام الملفات System / 38 ونظام الملفات نظام ملفات طريقة الوصول إلى التخزين الظاهري (VSAM) لأجهزة كمبيوتر IBM المركزية. ومع ذلك ، تباينت المرافق والواجهات الفعلية بشكل كبير ، فما هي المرافق والواجهات التي يجب أن تدعمها بنية DDM؟ انظر الملفات الموجهة للتسجيل .

كان العمل الأولي على DDM من قبل مشروع Golden Gate قد اتبعت ريادة المعيار الدولي للوصول إلى نقل الملفات وإدارتها ( FTAM ) للملفات الموزعة ، لكنه كان مجرّدًا للغاية ويصعب تعيينه لخدمات الملفات المحلية. في الواقع ، كان هذا أحد العوائق التي تحول دون قبول بيوت نظام IBM. جادل كينيث لورانس ، مهندس النظام المسؤول عن خدمات ملفات System / 36 ، بأنه سيكون من الأفضل تحديد الرسائل التي يمكن لنظام IBM واحد على الأقل تنفيذها بسهولة ثم السماح للأنظمة الأخرى بطلب أي تغييرات تحتاجها. بطبيعة الحال ، دافع عن دعم متطلبات النظام / 36. بعد عام من الفشل في بيع فكرة DDM لمنازل نظام IBM الأخرى ، سادت حجج لورانس.

انضم ريتشارد ساندرز إلى فريق هندسة DDM وعمل مع Lawrence and Demers لتحديد الرسائل المحددة اللازمة لـ System / 36 DDM. شجع التقدم في تعريف DDM النظام / 38 على المشاركة أيضًا. أدى ذلك إلى توسيع نطاق دعم ملفات تسجيل DDM لتلبية العديد من متطلبات نظام الملفات المتقدم System / 38.

توجد الملفات في سياق يوفره نظام تشغيل يوفر خدمات لتنظيم الملفات ومشاركتها مع المستخدمين المتزامنين وتأمينها من الوصول غير المبرر. في المستوى 1 من DDM ، لم يكن الوصول إلى أدلة الملفات البعيدة مدعومًا بخلاف إرسال الاسم المؤهل بالكامل للملف المراد استخدامه. ومع ذلك ، فإن الأمن والمشاركة مطلوبان. قام ساندرز بأعمال التصميم في هذه المجالات. حدد ساندرز أيضًا بروتوكولات محددة فيما يتعلق باستخدام مرافق الاتصال ، والتي تم دمجها في مكون يسمى مدير اتصالات المحادثة DDM. تم تنفيذه في البداية باستخدام APPC ، وتم تنفيذه لاحقًا باستخدام TCP / IP .

مع الانتهاء من منتج System / 36 DDM ، عمل لورانس مع مبرمجين من مختبر IBM Hursley Park بالمملكة المتحدة لتكييف الكثير من برمجة خادم System / 36 DDM للاستخدام في بيئة معالجة معاملات نظام التحكم في معلومات العملاء (CICS) من IBM ، وبالتالي جعل CICS خادم DDM لكل من أنظمة تشغيل MVS و VSE المركزية. ^[4] عمل لورانس أيضًا مع مبرمجين من مختبر IBM Cary ، بولاية نورث كارولينا لتنفيذ عميل DDM موجه لسجلات لـ IBM PC DOS .

تم نشر المستوى 1 من DDM Architecture رسميًا في عام 1986. وفي وقت هذا الإعلان ، قدمت شركة IBM جائزة الإنجاز الفني المتميز لكينيث لورانس ، وجائزة المساهمة البارزة لريتشارد ساندرز ، وجائزة الابتكار المتميز لريتشارد ديمرز.

• في هذه المقالة ، سيتم استخدام System / 38 من الآن فصاعدًا للإشارة إلى System / 38 وما يليه: IBM AS / 400 (الذي دمج وظائف System / 36 و System / 38) ، و IBM iSeries ، و IBM Power Series ^[5] (التي دمجت iSeries مع IBM RS / 6000 ، وخط إنتاج محطة العمل والخادم المستند إلى RISC / UNIX من IBM).

DDM المستوى 2: الدلائل الهرمية والملفات ذات الاتجاه المتدفق

مع تزايد أهمية كمبيوتر IBM ونظام التشغيل Unix في بيئات الشبكة ، كان دعم DDM مطلوبًا أيضًا للدلائل الهرمية والملفات ذات الاتجاه المتدفق للكمبيوتر الشخصي من IBM الذي يعمل بنظام IBM PC DOS و IBM RS / 6000 الذي يعمل بنظام IBM AIX ( نسخة آي بي إم من يونكس). انظر الملفات الموجهة نحو التدفق .

تم نشر DDM Architecture Level 2 في عام 1988. قام Jan Fisher و Sunil Gaitonde بمعظم أعمال الهندسة على دعم DDM للأدلة وملفات الدفق.

مستوى DDM 3: خدمات قواعد البيانات الارتباطية

في عام 1986 ، قامت شركة IBM بتسويق أربعة منتجات مختلفة لقواعد البيانات الارتباطية (RDB) ، تم تصميم كل منها لنظام تشغيل معين من شركة IBM. طور العلماء في مختبر أبحاث Almaden التابع لشركة IBM System / R * ، وهو نموذج أولي لـ RDB الموزع وشعروا أن الوقت قد حان لتحويله إلى منتجات قابلة للتسويق. ومع ذلك ، كان System / R * يعتمد على System / R ، وهو نموذج بحثي أولي لـ RDB ، ولا يمكن إضافته بسهولة إلى منتجات IBM RDB. انظر ^[6] لمناقشة RDBs في بيئة معالجة موزعة.

قاد روجر رينش من مركز البرمجة IBM Santa Theresa فريقًا متعدد المنتجات لتحديد بنية قاعدة البيانات العلائقية الموزعة (DRDA). جند:

• ممثلين من كل من منتجات IBM RDB الأربعة.
• بروس ليندسي ، باحث في النظام / R * ،
• Paul Roever (من مختبر IBM Sindelfingen بألمانيا) ، الذي طور مواصفات لوصف البيانات تسمى البيانات المنسقة: بنية محتوى الكائن (FD: OCA).
• ريتشارد ساندرز وريتشارد ديمرز من فريق هندسة DDM لتحديد النماذج والرسائل والبروتوكولات المناسبة.

في عام 1990 ، تم نشر DDM Architecture Level 3 و DRDA ^[7] في نفس الوقت. تم تصنيف كل من DDM و DRDA كمكونات إستراتيجية لهندسة تطبيقات أنظمة IBM (SAA). تم تنفيذ DRDA من قبل جميع منتجات IBM RDB الأربعة ومن قبل البائعين الآخرين.

تم تقديم الجوائز للمشاركين الرئيسيين في تصميم DRDA. حصل ريتشارد ساندرز على جائزة المساهمة المتميزة ، وحصل روجر راينش وريتشارد ديمرز على جوائز الابتكار المتميزة .

مستوى DDM 4: خدمات إضافية

بدأ مشروع إدارة الملفات الموزعة (DFM) ^[8] لإضافة خدمات DDM إلى نظام التشغيل MVS الخاص بشركة IBM لتمكين البرامج الموجودة على أجهزة الكمبيوتر البعيدة من إنشاء ملفات VSAM وإدارتها والوصول إليها. نظر جون هوفيرد ، مدير مشروع سوق دبي المالي ، إلى فريق DDM Architecture للحصول على وسيلة لتحويل حقول البيانات في السجلات أثناء تدفقها بين الأنظمة. تولى ريتشارد ديمرز زمام المبادرة في هذه القضية بمساعدة كويتشي ياماغوتشي من مشروع سوق دبي المالي. انظر وصف البيانات والتحويل .

تم تحديد الخدمات الإضافية التالية بواسطة Richard Sanders و Jan Fisher و Sunil Gaitonde في بنية DDM في المستوى 4:

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

تم نشر مستوى بنية DDM 4 في عام 1992.

مستوى DDM 5: خدمات المكتبة

يتألف عمل الهندسة المعمارية على مستوى 5 DDM من دعم لـ

• مجموعات البيانات المقسمة للحواسيب المركزية ، وهي ملفات تتكون من دليل داخلي وأعضاء متعددين ؛ في الواقع ، فهي مكتبات ملفات متشابهة.
• مكتبات الكمبيوتر الشخصية ، والتي تدمج الوصول إلى الملفات في مجلدات متعددة في مكتبة واحدة.
• مزيد من التحسينات على DRDA.

كان يان فيشر المهندس المعماري المسؤول عن DDM المستوى 5 ، والذي تم نشره بواسطة Open Group ، بدلاً من IBM. بعد ذلك بوقت قصير ، تم حل مجموعة هندسة IBM DDM.

داخل DDM

بنية DDM هي مجموعة مواصفات محددة رسميًا ومنظمة للغاية. يقدم هذا القسم المفاهيم التقنية الأساسية التي تكمن وراء DDM. ^[2]

كيف يعمل DDM

تحدد بنية DDM بروتوكول العميل / الخادم ؛ أي أن العميل يطلب الخدمات من الخادم الذي يتفاعل مع موارده المحلية لأداء الخدمة المطلوبة ، والتي يتم إرجاع نتائجها وبياناتها ومؤشرات الحالة إلى العميل. يوضح الرسم البياني أعلاه أدوار عملاء وخوادم DDM فيما يتعلق بالموارد المحلية. ( تُستخدم هنا المصطلحات الشائعة للعملاء والخوادم ، ولكن في بنية DDM ، يُطلق على العميل اسم خادم المصدر ويسمى الخادم الخادم الهدف .)

1. يتفاعل برنامج التطبيق مع مورد محلي ، مثل ملف ، عن طريق واجهات البرمجة التي يوفرها مدير الموارد المحلي (LRM). ولكن إذا كان المورد المطلوب موجودًا في كمبيوتر بعيد ، فسيتم استخدام DDM للتوسط في التفاعل. يستمر برنامج التطبيق في استخدام الواجهات التي يوفرها LRM الخاص به ، ولكن تتم إعادة توجيهها إلى عميل DDM. لا تحدد بنية DDM كيفية حدوث إعادة التوجيه هذه لأنها لا تدعم دليل الموارد البعيدة. تتمثل إحدى طرق إعادة التوجيه التي تستخدمها العديد من المنتجات الموجهة لملفات DDM في جعل التطبيق يفتح ملفًا محليًا خاصًا ، يسمى ملف DDM بواسطة System / 38 ، والذي يوفر معلومات حول الموقع والوصول حول الملف البعيد. ثم تحدث إعادة التوجيه إلى عميل DDM.
2. يحدد DDM Architecture كيانات مستوى المدير للملفات وقواعد البيانات العلائقية وطرق الوصول وما إلى ذلك. يدعم Client Resource Manager (CRM) بشكل متعدد الأشكال الواجهات الوظيفية المحددة بواسطة LRM لنظام العميل. وتتمثل وظيفتها الأساسية في إنشاء أمر DDM الخطي المناسب وكائنات البيانات لكل واجهة وظيفية. (راجع رسائل DDM .) يتم إرسال هذه الكائنات إلى مدير موارد الخادم (SRM) لخادم DDM البعيد. في الواقع ، على الرغم من ذلك ، يتم توجيههم من خلال عملاء DDM ووكلاء الخادم ومديري الاتصالات.
3. يضع DDM Client Agent أمرًا خطيًا في مظروف RQSDSS وكائنات خطية في مغلفات OBJDSS المرتبطة. (راجع رسائل DDM .) يتفاعل Client Agent مع Server Agent لإنشاء مسار للرسائل التي يتلقاها من CRM للتدفق إلى SRM. إذا احتاج برنامج التطبيق إلى التفاعل مع مورد واحد بعيد فقط ، فهذا واضح ومباشر. ومع ذلك ، فمن الممكن لبرنامج التطبيق أن يتفاعل بشكل متزامن مع موارد متعددة من أنواع مختلفة موجودة على أنظمة بعيدة متعددة. يمثل Client Agent برنامج التطبيق في جميع الحالات ويوجه الرسائل على مسارات افتراضية منفصلة لكل مورد.
4. يتفاعل Client Communications Manager مع ServerCommunications Manager لتنفيذ بروتوكول محادثة من النموذج "أتحدث أثناء الاستماع ، ثم تتحدث بينما أستمع". يمكن استخدام بروتوكولات الاتصالات المختلفة ، بما في ذلك SNA APPC الخاص بشركة IBM وبروتوكول TCP / IP الخاص بالإنترنت.
5. يتم تمرير رسائل DDM المرسلة إلى Server Communications Manager إلى Server Agent على المسار المحدد بواسطة الرسالة ، ويقوم بإعادة توجيه الرسائل إلى SRM على نفس المسار. إذا كان عامل الخادم يتفاعل مع عميل واحد على مسار واحد ، فهذا أمر مباشر. ومع ذلك ، يمكن لعامل الخادم التفاعل مع العديد من العملاء على مسارات متعددة.
6. يوزع Server Resource Manager (SRM) رسائل DDM ويحدد ما يجب القيام به لتنفيذ الطلب. قد يستخدم واحدًا أو أكثر من الواجهات الوظيفية لنظام إدارة الموارد المحلية (LRM) المقابل لنظام الخادم.
7. تقوم SRM بتجميع البيانات ومؤشرات الحالة من LRM وتقوم بإنشاء كائنات خطية مناسبة ورسائل رد ، والتي تمررها إلى عامل الخادم.
8. يحزم وكيل الخادم الردود والكائنات في مغلفات RPYDSS و OBJDSS ويعيد توجيهها إلى Server Communication Manager ، الذي يرسلها إلى Client Communication Manager و Client Agent على نفس المسار مثل الأمر الأصلي.
9. يقوم Client Agent بإزالة الردود والكائنات من مغلفات RPYDSS و OBJDSS الخاصة بها ويمررها إلى Client Resource Manager.
10. يقوم Client Resource Manager بتوزيع الكائن الذي تم إرجاعه ورسائل الرد وتعيينها كما هو متوقع بواسطة واجهة LRM الوظيفية الأصلية للعودة إلى برنامج التطبيق.

اتجاه الكائن

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

من الناحية الهيكلية ، تتكون بنية DDM من مستويات هرمية للكائنات ، يظهر كل مستوى خصائص ناشئة على مستويات أعلى بشكل متزايد.

• الحقل عبارة عن سلسلة من البتات تقوم بتشفير رقم أو حرف أو كيان بيانات آخر. يتم تغليف مثيلات فئة الحقل الفرعية بالعمليات التي يمكن إجراؤها بواسطة فئتها ؛ على سبيل المثال ، العمليات الحسابية في حقول عدد صحيح.
• الكائن عبارة عن كيان معرّف ذاتيًا يتكون من حقل واحد أو أكثر مغلف بمجموعة محددة من العمليات. الكائنات في هذا المستوى مستوحاة من فئات كائن kernel في لغة برمجة Smalltalk ^[9]
  • يتكون الكائن القياسي من حقل واحد ، كما تم ترميزه ووصفه بواسطة فئة الكائن. يتم استخدام الكائنات العددية كقيم معلمات لكائنات الأوامر والرد. يتم استخدامها أيضًا كقيم لسمات الكائن ، مثل طول الكائن في وثائق DDM. يتم تحديد طرق الترميز المستخدمة لقيم هذه الكائنات العددية بشكل كامل بواسطة بنية DDM.
  • يتكون الكائن المعين من حقل واحد أو أكثر ، مثل حقول السجل المحدد من قبل التطبيق. لا يتم تحديد طرق الترميز ومحاذاة هذه الحقول بواسطة بنية DDM ؛ بدلاً من ذلك ، يتم تعريفه من خلال عبارات إعلان برنامج التطبيق وطرق الترميز والمحاذاة للغة البرمجة الخاصة به.
  • كائن المجموعة هو حاوية للكائنات ، كما هو محدد بواسطة فئة المجموعة. من أمثلة كائنات المجموعة أوامر DDM والردود.
• المدير هو كيان معرّف ذاتيًا يوفر بيئة لتخزين العناصر ومعالجتها. يتم تغليف المدير بالعمليات المحددة بواسطة فئته. معًا ، تقوم مجموعة من المديرين بتنفيذ بيئة المعالجة الشاملة لعميل أو خادم DDM. تم استلهام كيانات الإدارة في هذا المستوى من كائنات النظام لنظام التشغيل System / 38. ^[10] يشمل المديرون المحددون بواسطة DDM: القاموس ، المشرف ، الوكيل ، الدليل ، الملف (الملفات) ، طريقة (طرق) الوصول ، قاعدة البيانات العلائقية ، مدير تطبيق SQL ، قائمة الانتظار ، مدير القفل ، مدير الأمان ، مدير الاسترداد ، معالج أوامر النظام ، مدير (مدراء) الاتصالات.
• الخادم هو كيان معرف ذاتي يوفر بيئة لتخزين ومعالجة المديرين ، إما كعميل أو خادم ، في بيئة معالجة موزعة. ومن الأمثلة على ذلك العملاء والخوادم المتخصصة في إدارة الملفات الموزعة أو إدارة قواعد البيانات الارتباطية الموزعة.

في حين أن بنية DDM موجهة للكائنات ، تم تنفيذ منتجات DDM باستخدام اللغات والأساليب النموذجية لأنظمتها المضيفة. تم تطوير إصدار Smalltalk من DDM لجهاز كمبيوتر IBM الشخصي بواسطة Object Technology International ، مع فئات Smalltalk المناسبة التي تم إنشاؤها تلقائيًا من DDM Reference Manual.

المجموعات الفرعية والامتدادات

DDM هي بنية مفتوحة. يمكن لمنتجات DDM تنفيذ مجموعات فرعية من بنية DDM ؛ يمكنهم أيضًا إنشاء ملحقاتهم الخاصة. ^[11]

يعد الأمر DDM "سمات خادم Exchange" هو الأمر الأول الذي يتم إرساله عند اتصال عميل بخادم. إنه يحدد العميل ويحدد المديرين الذين يتطلبهم العميل ومستوى بنية DDM التي يلزم فيها الدعم. يستجيب الخادم بتعريف نفسه وتحديد المستوى الذي يدعم فيه المديرين المطلوبين. القاعدة العامة هي أن المنتج الذي يدعم المستوى X لمدير DDM يجب أن يدعم أيضًا المستوى X-1 بحيث تتصل منتجات الخادم الجديدة بمنتجات العميل الأقدم.

يمكن تنفيذ مجموعات فرعية من DDM لتلبية متطلبات المنتج المختلفة:

• كعميل أو خادم أو كليهما. على سبيل المثال ، DDM / PC هو عميل فقط ، CICS / DDM عبارة عن خادم فقط ، ونظام System / 38 DDM هو عميل وخادم.
• لدعم مديرين معينين ، مثل الملفات الموجهة للتسجيل ، أو الملفات ذات الاتجاه المتدفق ، أو قواعد البيانات العلائقية (كجزء من DRDA) ، أو أي مجموعة منها. على سبيل المثال ، توفر MVS Database 2 دعم العميل والخادم لمجموعة فرعية فقط من DDM التي تتطلبها DRDA.
• لدعم الأوامر المحددة للمدير فقط ، مثل القدرة على تحميل وتفريغ السجلات من ملف تسلسلي.
• لدعم المعلمات المحددة للأمر ، مثل معلمة "إرجاع السجلات غير النشطة" لأمر "الحصول على السجل".

عندما يكون عميل DDM متصلاً بخادم DDM معروف ، مثل عميل System / 38 بخادم System / 38 ، يمكن أيضًا توسيع بنية DDM عن طريق إضافة

• مديري منتجات محددة جديدة.
• أوامر جديدة لمدير DDM موجود.
• معلمات جديدة لأمر DDM أو رسالة رد.

يمكن تعريف هذه الامتدادات داخل إطار عمل DDM الموجه للكائنات بحيث يمكن استخدام مرافق معالجة رسائل DDM الحالية.

رسائل DDM

في تنفيذ موجه للكائنات فقط لـ DDM ، يوجد العملاء والخوادم وجميع المديرين والكائنات الموجودة في كومة ذاكرة ، مع استخدام المؤشرات (عناوين الذاكرة) لربطها ببعضها البعض. على سبيل المثال ، يشير كائن الأمر إلى كل عنصر من كائنات المعلمات الخاصة به. لكن الأمر لا يمكن نقله من عميل إلى خادم بهذه الطريقة ؛ يجب إنشاء نسخة متشابهة من الأمر كسلسلة واحدة متجاورة من البتات. في الكومة ، يتكون الأمر من حجم الأمر في الكومة ، ومؤشر إلى فئة الأمر ، ومؤشرات لكل من كائنات معلمات الأمر. يتكون الأمر الخطي من الطول الإجمالي للأمر الخطي ، ونقطة رمز تحدد فئة الأمر ، وكل عنصر من كائنات المعلمات الخطية. تقوم بنية DDM بتعيين نقاط رمز فريدة لكل فئة من الكائنات.

يتم وضع كل هذه الكائنات الخطية في مظاريف تمكن العملاء ووكلاء الخادم من تنسيق معالجتهم. في بنية DDM ، تسمى هذه الأظرف بنيات تدفق البيانات (DSS). يتم وضع الأوامر في طلب DSS (RQSDSS) ، ويتم وضع الردود في رد DSS (RPYDSS) ، ويتم وضع الكائنات الأخرى في كائن DSS(OBJDSS). يمكن أن يكون هناك أمر واحد فقط في RQSDSS ورد واحد فقط في RPYDSS ، ولكن يمكن وضع العديد من الكائنات ، مثل السجلات ، في OBJDSS. علاوة على ذلك ، يمكن ربط العديد من OBJDSSs بـ RQSDSS أو PRYDSS لاستيعاب أكبر عدد ممكن من الكائنات حسب الضرورة. يتكون DSS من الطول الإجمالي لـ DSS ، وبايت العلم الذي يحدد نوع DSS ، ومعرف الطلب ، والكائنات الخطية في DSS. يربط معرف الطلب RQSDSS مع OBJDSSs اللاحقة من العميل ، مثل السجلات التي سيتم تحميلها في ملف بواسطة الأمر Load File . يربط معرف الطلب أيضًا RQSDSS من العميل مع RPYDSS أو OBJDSS من الخادم إلى العميل.

التوثيق

يتكون دليل DDM المرجعي ^{[12] [13]} من كائنات قائمة وتعليمات وفئة مسماة. يتم وصف الفئات الفرعية لفئة فئة DDM بالمتغيرات التي تحددها

• الطبقة العليا للفئة. يتم تعريف الفئات من خلال التسلسل الهرمي للميراث ؛ على سبيل المثال ، ملف السجل هو فئة فرعية من الملفات وهي فئة فرعية من "المدير" وترث بياناتها وأوامرها. فئة Çlass وفئاتها الفرعية تصف نفسها بأوامر çlass ومتغيرات الفئة ، بما في ذلك:
• عنوان يصف الفصل بإيجاز.
• حالة الفئة بالنسبة إلى العمل الجاري على بنية DDM.
• نصوص وصفية ورسوم بيانية تربط الفصل بمكوناته وبيئته.
• البيانات (الحقول ، الكائنات ، المدراء ، إلخ) مغلفة بحالات الفصل.
• الأوامر التي يمكن إرسالها إلى مثيلاتها.

يمكن أن تحتوي هذه الكائنات على إشارات إلى كائنات أخرى مسماة في النص والمواصفات ، وبالتالي إنشاء روابط تشعبية بين صفحات الدليل المرجعي DDM. تشكل صفحات القائمة والتعليمات برنامجًا تعليميًا متكاملًا حول DDM. الإصدار الورقي من الدليل المرجعي DDM المستوى 3 ضخم ، في أكثر من 1400 صفحة ، ومربك إلى حد ما للاستخدام ، ولكن تم إنشاء نسخة تفاعلية أيضًا باستخدام مرافق اتصالات IBM الداخلية. نظرًا للسرعة البطيئة نسبيًا لمرافق الاتصال هذه ، فقد كانت مفيدة في المقام الأول داخل مختبر IBM Rochester.

بالإضافة إلى دليل DDM المرجعي ، توفر وثيقة المعلومات العامة ^[1] معلومات المستوى التنفيذي حول DDM ، ودليل المبرمج ^[11] يلخص مفاهيم DDM للمبرمجين الذين ينفذون العملاء والخوادم.

نماذج ملفات DDM

يتم تحديد ثلاثة نماذج ملفات عامة بواسطة بنية DDM: الملفات الموجهة للتسجيل ، والملفات الموجهة نحو التدفق والمجلدات الهرمية.

يتم توفير الخدمات التالية بواسطة بنية DDM لإدارة الملفات البعيدة:

• إنشاء ومسح وحذف الملفات ،
• نسخ وتحميل وتفريغ بيانات الملف ،
• قفل وفتح الملفات ،
• الحصول على سمات الملف وتغييرها ،

ملفات موجهة للتسجيل

تم تصميم الملفات الموجهة للتسجيل لتلبية متطلبات إدخال البيانات وإخراجها وتخزينها للغات برمجة الجيل الثالث (3GL) ، مثل Fortran و Cobol و PL / I و RPG. بدلاً من أن توفر كل لغة دعمها الخاص لهذه القدرات ، تم دمجها في الخدمات التي توفرها أنظمة التشغيل.

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

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

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

تحدد بنية DDM أيضًا مجموعة متنوعة من طرق الوصول للعمل مع الملفات الموجهة للتسجيل بطرق مختلفة. طريقة الوصول هي مثال على استخدام ملف تم إنشاؤه بواسطة أمر OPEN الذي يربط نفسه بالملف بعد تحديد ما إذا كان العميل مخولًا باستخدامه. طريقة الوصول مفصولة عن ملف بواسطة أمر CLOSE.

تتعقب طريقة الوصول السجل الذي تتم معالجته حاليًا عن طريق المؤشر. باستخدام أوامر SET المختلفة ، يمكن ضبط المؤشر للإشارة إلى بداية الملف أو نهايته ، أو إلى السجل المتسلسل التالي أو السابق للملف ، أو إلى السجل بقيمة مفتاح معينة ، أو إلى السجل التالي أو السابق حسب الطلب بمفاتيحهم.

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

الملفات ذات التدفق المباشر

تتكون الملفات الموجهة نحو التدفق من تسلسل واحد من البايتات يمكن للبرامج أن تعين عليها بيانات التطبيق كيفما تشاء. ملفات البث هي نموذج الملف الأساسي المدعوم من قبل أنظمة التشغيل التي تشبه يونكس ويونكس ونظام التشغيل Windows . يحدد DDM نموذج ملف دفق واحد وطريقة وصول دفق واحدة.

يتكون نموذج ملف دفق DDM من سمات الملف ، مثل تاريخ إنشائه وحجم الدفق ودفق مستمر من البايت. يمكن الوصول إلى الدفق عن طريق طريقة الوصول إلى الدفق. تكتب برامج التطبيقات البيانات على أجزاء من الدفق ، حتى لو كانت تلك البيانات تتكون من سجلات. يتتبعون موقع عناصر البيانات في الدفق بأي طريقة يريدون. على سبيل المثال ، يتم تعريف دفق البيانات لملفات المستندات بواسطة برنامج معالجة نصوص مثل Microsoft Word وتلك الخاصة بملف جدول بيانات بواسطة برنامج مثل Microsoft Excel .

طريقة الوصول إلى الدفق هي مثيل لاستخدام ملف دفق بواسطة عميل واحد. يتتبع المؤشر موضع البايت الحالي للتيار الفرعي المستخدم من قبل العميل. باستخدام أوامر SET المختلفة ، يمكن عمل المؤشر للإشارة إلى بداية الملف أو نهايته ، أو إلى أي موضع محدد في الملف ، أو إلى أي إزاحة موجبة أو سلبية من الموضع الحالي.

يمكن فتح مثيلات متعددة من طريقة الوصول إلى البث على ملف في نفس الوقت ، كل منها يخدم عميلًا واحدًا. إذا تم فتح ملف للوصول "للتحديث" ، يمكن أن تحدث تعارضات عندما يتم الوصول إلى الدفق الفرعي نفسه من قبل عدة عملاء. لمنع مثل هذه التعارضات ، يمكن الحصول على قفل للملف بأكمله. أيضًا ، إذا تم فتح ملف للتحديث ، فسيحصل العميل الأول على قفل في دفق فرعي من أجل "قراءته" وتحريره عندما "يقوم" العميل "بتحديثه". يجب على جميع العملاء الآخرين انتظار تحرير القفل.

أدلة هرمية

الدلائل الهرمية هي ملفات تربط كل سجلاتها اسمًا بموقع. يحدث التسلسل الهرمي عندما يقوم سجل دليل بتعريف اسم وموقع دليل آخر. باستخدام منتجات خادم وعميل DDM ، يمكن للبرنامج إنشاء الدلائل وحذفها وإعادة تسميتها في جهاز كمبيوتر بعيد. يمكنهم أيضًا سرد وتغيير سمات الملفات الخاصة بالدلائل البعيدة. يمكن قراءة السجلات الموجودة في دليل بالتسلسل باستخدام DDM Directory Access Method. يمكن إعادة تسمية الملفات التي تم تحديدها بواسطة سجلات الدليل ونسخها ونقلها إلى دليل مختلف.

قوائم انتظار DDM

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

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

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

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

قواعد البيانات العلائقية

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

تتلاءم بنية قاعدة البيانات العلائقية الموزعة (DRDA) بشكل جيد مع إطار عمل DDM العام ، كما تمت مناقشته في توجيه الكائن . (ومع ذلك ، يمكن أيضًا اعتبار DDM بمثابة بنية مكونة لـ DRDA نظرًا لأن المواصفات الأخرى مطلوبة أيضًا ^[2] ). يتم تسمية كائنات مستوى مدير DDM التي تدعم DRDA باسم RDB (لقاعدة البيانات العلائقية) و SQLAM (لمدير تطبيق SQL).

وصف البيانات وتحويلها

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

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

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

كانت النتيجة تحديد بنية شاملة لوصف البيانات والتحويل (DD&C) ، ^[14] استنادًا إلى لغة برمجة متخصصة جديدة ، لغة بيانات (ADL) ، ^[15] لوصف طرق عرض العميل والخادم لسجلات البيانات ولأجل تحديد التحويلات. يمكن بعد ذلك استدعاء برامج ADL المجمعة بواسطة الخادم لإجراء التحويلات الضرورية حيث تتدفق السجلات إلى الخادم أو منه.

ذهبت بنية DD&C إلى أبعد من ذلك وحددت وسيلة يمكن من خلالها تحويل عبارات إعلان لغة البرمجة تلقائيًا من وإلى ADL ، وبالتالي من لغة برمجة إلى أخرى. لم يتم تنفيذ هذه القدرة أبدًا بسبب تعقيدها وتكلفتها. ومع ذلك ، تم إنشاء مترجم ADL ويتم استدعاء برامج ADL ، عند توفرها ، لإجراء تحويلات بواسطة DFM وبواسطة IBM 4680 Store System. ^[16] ومع ذلك ، فمن الضروري لمبرمجي التطبيقات كتابة برامج ADL يدويًا.

تنفيذ المنتجات

منتجات DDM بواسطة IBM

نفذت منتجات IBM التالية مجموعات فرعية مختلفة من بنية DDM:

• نظام IBM / 370
  • MVS (MVS / SP ، MVS / ESA)
    • قاعدة البيانات 2 - عميل وخادم DRDA
    • CICS - خادم ملفات التسجيل داخل بيئة معالجة المعاملات CICS. توقف في CICS لـ z / OS V5.2 والإصدارات الأحدث. ^[17]
  • VM (نظام التشغيل) (VM / SP ، VM / ESA)
    • SQL / DS - عميل وخادم DRDA
  • DOS / VSE
    • CICS - خادم ملف السجل ضمن بيئة معالجة المعاملات CICS. توقف في CICS لـ z / VSE V2.1 والإصدارات الأحدث. ^{[18] [19]}
  • ض / نظام التشغيل
    • إدارة الملفات الموزعة - خادم ملفات السجلات
    • قاعدة البيانات 2 - عميل وخادم DRDA
• النظام / 36
  • برنامج دعم النظام - سجل ملف العميل والخادم
• النظام / 38 وما يليه: AS / 400 و iSeries و Power Series
  • سجل ملف العميل والخادم
  • خادم وعميل ملف الدليل والدفق
  • عميل وخادم DRDA
• كمبيوتر IBM الشخصي
  • جهاز كمبيوتر اثنين
    • Netview / PC - خادم وعميل ملف الدليل والدفق
    • DDM / PC - عميل ملف الدليل والدفق.
    • دعم الكمبيوتر / 36 - عميل ملف الدليل والدفق.
    • دعم الكمبيوتر / 400 - عميل ملف الدليل والدفق.
  • النظام الشخصي / 2 - OS / 2
    • الكمبيوتر / الدعم / 400 - دفق الملف والعميل والخادم
    • عميل وخادم DRDA
• IBM 4680 و IBM 4690 Store Systems
  • سجل ملف العميل والخادم
  • خادم وعميل ملف الدليل والدفق
• RS / 6000 AIX
  • عميل وخادم DRDA

منتجات DDM من قبل البائعين الآخرين

للحصول على قائمة كاملة بالمنتجات التي نفذت DRDA ، راجع جدول معرف منتج DRDA مفتوح المصدر .

انظر أيضا

• نظام ملفات التسجيل المنحى

المراجع