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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تم نشر المستوى الثاني من بنية DDM في عام 1988. قام كل من جان فيشر وسونيل جايتوندي بمعظم أعمال البنية المتعلقة بدعم DDM للمجلدات وملفات التدفق.

في عام ١٩٨٦، طرحت شركة IBM أربعة منتجات مختلفة لقواعد البيانات العلائقية (RDB)، صُمم كل منها لنظام تشغيل محدد من أنظمة IBM. كان علماء مختبر أبحاث ألمادن التابع لشركة IBM قد طوروا System/R*، وهو نموذج أولي لقاعدة بيانات علائقية موزعة، ورأوا أن الوقت قد حان لتحويله إلى منتجات قابلة للتسويق. مع ذلك، كان System/R* مبنيًا على System/R، وهو نموذج أولي بحثي لقاعدة بيانات علائقية، ولم يكن من السهل إضافته إلى منتجات IBM لقواعد البيانات العلائقية. انظر ^{[ ٦ ]} لمناقشة قواعد البيانات العلائقية في بيئة معالجة موزعة.

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

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

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

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

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

تم تحديد الخدمات الإضافية التالية بواسطة ريتشارد ساندرز، وجان فيشر، وسونيل غايتوندي في بنية DDM في المستوى 4:

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

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

تضمن العمل المعماري على مستوى DDM 5 تقديم الدعم لـ

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

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

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

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

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

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

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

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

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

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

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

• كعميل أو خادم أو كليهما. على سبيل المثال، 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، تُسمى هذه المغلفات هياكل تدفق البيانات (DSS). تُوضع الأوامر في هيكل تدفق بيانات الطلب (RQSDSS)، والردود في هيكل تدفق بيانات الرد (RPYDSS)، والكائنات الأخرى في هيكل تدفق بيانات الكائن (OBJDSS). لا يمكن أن يحتوي هيكل RQSDSS إلا على أمر واحد، ولا رد واحد إلا على هيكل RPYDSS، ولكن يمكن وضع العديد من الكائنات، مثل السجلات، في هيكل OBJDSS. علاوة على ذلك، يمكن ربط العديد من هياكل OBJDSS بهيكل RQSDSS أو PRYDSS لاستيعاب أي عدد من الكائنات حسب الحاجة. يتكون هيكل DSS من الطول الإجمالي له، وبايت علامة يُحدد نوعه، ومعرّف الطلب، والكائنات المُعالجة خطيًا الموجودة فيه. يربط معرّف الطلب هيكل RQSDSS بهياكل OBJDSS اللاحقة من العميل، مثل السجلات المراد تحميلها في ملف بواسطة أمر تحميل الملف . كما يربط مُعرّف الطلب RQSDSS من العميل بـ RPYDSS أو OBJDSSes من الخادم إلى العميل.

يتألف دليل مرجع DDM ^{[ 12 ] [ 13 ]} من كائنات مُسماة من نوع Menu وHelp وClass. ويتم وصف الفئات الفرعية لفئة Class في DDM بواسطة متغيرات تُحدد

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

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

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

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

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

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

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

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

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

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

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

تتكامل بنية قاعدة البيانات العلائقية الموزعة (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. ^{[ 16 ]} لكن لا يزال على مبرمجي التطبيقات كتابة برامج ADL يدويًا.

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

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

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