สถาปัตยกรรมการจัดการข้อมูลแบบกระจาย ( DDM ) คือสถาปัตยกรรมซอฟต์แวร์แบบเปิดที่เผยแพร่โดยIBMสำหรับการสร้าง การจัดการ และการเข้าถึงข้อมูลบนคอมพิวเตอร์ระยะไกล DDM ถูกออกแบบมาเพื่อรองรับไฟล์แบบบันทึกข้อมูลเป็นหลัก ต่อ มา ได้ขยายเพื่อรองรับไดเร็กทอรีแบบลำดับชั้นไฟล์แบบสตรีมคิวและการประมวลผลคำสั่งระบบ และต่อมาได้ขยายเพิ่มเติมเพื่อเป็นพื้นฐานของสถาปัตยกรรมฐานข้อมูลเชิงสัมพันธ์แบบกระจาย ของ IBM (DRDA) และในที่สุดก็ได้ขยายเพื่อรองรับการอธิบายและการแปลงข้อมูล DDM ถูกกำหนดขึ้นในช่วงปี 1980 ถึง 1993 โดยระบุส่วนประกอบ ข้อความ และโปรโตคอลที่จำเป็นทั้งหมดบนพื้นฐานของหลักการเชิงวัตถุ DDM ไม่ใช่ซอฟต์แวร์ชิ้นเดียว การใช้งาน DDM อยู่ในรูปแบบของผลิตภัณฑ์ไคลเอ็นต์และเซิร์ฟเวอร์ เนื่องจากเป็นสถาปัตยกรรมแบบเปิด ผลิตภัณฑ์จึงสามารถใช้งานส่วนย่อยของสถาปัตยกรรม DDM และสามารถขยาย DDM เพื่อตอบสนองความต้องการเพิ่มเติมได้ โดยรวมแล้ว ผลิตภัณฑ์ DDM จะ ใช้ งานระบบไฟล์แบบกระจาย

ผู้พัฒนาแอปพลิเคชันแบบกระจายต้องพิจารณาตำแหน่งที่ดีที่สุดของโปรแกรมและข้อมูลของแอปพลิเคชัน โดยคำนึงถึงปริมาณและความถี่ของข้อมูลที่จะส่ง รวมถึงการจัดการข้อมูล ความปลอดภัย และความทันเวลา มีโมเดลไคลเอ็นต์-เซิร์ฟเวอร์สามแบบสำหรับการออกแบบแอปพลิเคชันแบบกระจาย:

1. โปรโตคอลการถ่ายโอนไฟล์ (FTP) คัดลอกหรือย้ายไฟล์หรือตารางฐานข้อมูลทั้งหมดไปยังไคลเอนต์แต่ละเครื่อง เพื่อให้สามารถดำเนินการได้ในเครื่องนั้นๆ รูปแบบนี้เหมาะสมสำหรับแอปพลิเคชันที่มีการโต้ตอบสูง เช่น โปรแกรมแก้ไขเอกสารและสเปรดชีต ซึ่งไคลเอนต์แต่ละเครื่องจะมีสำเนาของโปรแกรมแก้ไขนั้นๆ และโดยทั่วไปแล้วการแชร์เอกสารดังกล่าวไม่ใช่เรื่องที่ต้องกังวล
2. แอปพลิ เคชันไคลเอ็นต์แบบบาง (Thin client)นำเสนอส่วนติดต่อผู้ใช้ของแอปพลิเคชันแก่ผู้ใช้ ในขณะที่ส่วนประมวลผลของแอปพลิเคชันจะรวมศูนย์อยู่ที่ไฟล์หรือฐานข้อมูลที่เกี่ยวข้อง การสื่อสารจึงประกอบด้วยการเรียกใช้ฟังก์ชันระยะไกล (Remote Procedure Call)ระหว่างไคลเอ็นต์แบบบางและเซิร์ฟเวอร์ โดยข้อความที่ออกแบบมาเฉพาะจะระบุฟังก์ชันที่จะเรียกใช้ พารามิเตอร์ที่เกี่ยวข้อง และค่าที่ส่งคืนใดๆ
3. แอปพลิ เคชันไคลเอ็นต์แบบ Fatจะประมวลผลงานทั้งหมดของแอปพลิเคชันบนระบบไคลเอ็นต์ แต่ข้อมูลจะถูกรวมศูนย์ไว้ที่เซิร์ฟเวอร์ เพื่อให้สามารถจัดการได้ เพื่อให้แอปพลิเคชันไคลเอ็นต์ที่ได้รับอนุญาตสามารถเข้าถึงได้ เพื่อให้แอปพลิเคชันไคลเอ็นต์ทั้งหมดทำงานกับข้อมูลที่ทันสมัย ​​และเพื่อให้มีการส่งเฉพาะระเบียนส่วนของสตรีม หรือตารางฐานข้อมูลที่ได้รับผลกระทบจากแอปพลิเคชันเท่านั้น โปรแกรมแอปพลิเคชันไคลเอ็นต์จะต้องถูกแจกจ่ายไปยังไคลเอ็นต์ทั้งหมดที่ทำงานกับข้อมูลส่วนกลาง

สถาปัตยกรรม DDM ได้รับการออกแบบมาเพื่อรองรับ โมเดลไคลเอ็นต์แบบเต็มรูปแบบ (fat client)ของแอปพลิเคชันแบบกระจายศูนย์เป็นหลัก และยังรองรับการถ่ายโอนไฟล์ทั้งไฟล์ได้อีกด้วย

สถาปัตยกรรม DDM มอบประโยชน์ดังต่อไปนี้ให้กับแอปพลิเคชันแบบกระจาย: ^{[ 1 ]}

• ความโปร่งใสระหว่างระบบภายในและระบบภายนอก โปรแกรมแอปพลิเคชันสามารถเปลี่ยนเส้นทางการเข้าถึงข้อมูลจากระบบภายในไปยังระบบภายนอกได้อย่างง่ายดาย ไม่จำเป็นต้องใช้โปรแกรมเฉพาะทางที่เข้าถึงและจัดการข้อมูลในระบบภายนอก
• ลดความซ้ำซ้อนของข้อมูลข้อมูลจึงจำเป็นต้องจัดเก็บไว้ในที่เดียวบนเครือข่ายเท่านั้น
• ระบบรักษาความปลอดภัยที่ดีขึ้น ด้วยการกำจัดสำเนาข้อมูลที่ซ้ำซ้อน การเข้าถึงข้อมูลในเครือข่ายจึงสามารถจำกัดให้เฉพาะผู้ใช้ที่ได้รับอนุญาตเท่านั้นได้ดียิ่งขึ้น
• ความสมบูรณ์ของข้อมูลการอัปเดตโดยผู้ใช้ทั้งในระบบและระยะไกลพร้อมกันจะไม่สูญหายเนื่องจากข้อขัดแย้ง
• ข้อมูลที่ทันสมัยยิ่งขึ้น ผู้ใช้คอมพิวเตอร์หลายเครื่องในเครือข่ายจะสามารถเข้าถึงข้อมูลล่าสุดได้เสมอ
• การจัดการทรัพยากรที่ดีขึ้น สามารถเพิ่มประสิทธิภาพการจัดเก็บและประมวลผลข้อมูลของเครือข่ายคอมพิวเตอร์ได้

สถาปัตยกรรม DDM คือชุดข้อกำหนดสำหรับข้อความและโปรโตคอลที่ช่วยให้สามารถจัดการและเข้าถึงข้อมูลที่กระจายอยู่ทั่วเครือข่ายคอมพิวเตอร์ได้ ^{[ 2 ]}

สถาปัตยกรรมเครือข่ายระบบ (SNA) ของ IBM ถูกออกแบบมาเพื่อเชื่อมต่อเวิร์กสเตชันกับ คอมพิวเตอร์ เมนเฟรมของ IBM ใน ลักษณะลำดับชั้น เครือข่ายการสื่อสารที่มีอยู่ในขณะนั้นถูกออกแบบมาอย่างตายตัว โดยใช้การเชื่อมต่อแบบคงที่ระหว่างเมนเฟรมกับชุดเวิร์กสเตชัน ซึ่งอยู่ภายใต้การควบคุมซอฟต์แวร์ของคอมพิวเตอร์เมนเฟรมอย่างสมบูรณ์ การสื่อสารอื่นๆ ระหว่างเมนเฟรมก็ใช้การเชื่อมต่อแบบคงที่เช่นกัน โดยใช้ซอฟต์แวร์ที่กำหนดไว้สำหรับวัตถุประสงค์เฉพาะ เมื่อเครือข่ายการสื่อสารมีความยืดหยุ่นและไดนามิกมากขึ้น การสื่อสาร แบบ peer-to-peer ทั่วไป จึงเป็นที่ต้องการ ซึ่งโปรแกรมบนคอมพิวเตอร์เครื่องหนึ่งสามารถเริ่มต้นและโต้ตอบกับโปรแกรมบนคอมพิวเตอร์อีกเครื่องหนึ่งได้

เมื่อสถาปัตยกรรม SNA Advanced Program to Program Communications (APPC) ของ IBM ถูกกำหนดขึ้นในช่วงต้นทศวรรษ 1980 ก็เป็นที่ชัดเจนว่า APPC สามารถนำมาใช้เพื่อให้บริการระบบปฏิบัติการบนคอมพิวเตอร์ระยะไกลได้ คณะทำงาน SNA จึงได้ศึกษาแนวคิดนี้และร่างบริการแบบกระจายหลายอย่างที่เป็นไปได้ เช่น บริการไฟล์ บริการเครื่องพิมพ์ และบริการคอนโซลระบบ แต่ไม่สามารถเริ่มต้นการพัฒนาผลิตภัณฑ์ได้ เนื่องจากซอฟต์แวร์ APPC ยังไม่พร้อมใช้งานบนเมนเฟรม และที่สำคัญกว่านั้นคือ เมนเฟรมยังคงถูกมองว่าเป็นระบบแบบสแตนด์อะโลนเป็นหลัก ด้วยเหตุนี้ การทำงานเกี่ยวกับบริการแบบกระจายจึงถูกระงับโดยคณะทำงาน SNA

สมาชิกของกลุ่มงาน SNA จากห้องปฏิบัติการพัฒนาของ IBM ในเมืองรอเชสเตอร์ รัฐมินนิโซตา เชื่อมั่นว่า มี โอกาสทางธุรกิจสำหรับการให้บริการแบบกระจายศูนย์ระหว่างระบบคอมพิวเตอร์ขนาดกลางที่ผลิตในรอเชสเตอร์ รูปแบบพื้นฐานของการบริการไฟล์แบบกระจายศูนย์ที่เรียกว่าDistributed Data File Facility (DDFF) ได้ถูกนำมาใช้เพื่อเชื่อมต่อ มินิคอมพิวเตอร์ IBM System/3 , IBM System/34และIBM System/36นอกจากนี้ คอมพิวเตอร์ IBM System/36และIBM System/38ถูกขายให้กับลูกค้าเป็นจำนวนมาก และมีความจำเป็นอย่างยิ่งที่จะต้องทำให้คอมพิวเตอร์ในสำนักงานใหญ่ของบริษัทสามารถโต้ตอบกับคอมพิวเตอร์ในคลังสินค้าต่างๆ ได้ APPC จึงถูกนำไปใช้ในระบบเหล่านี้และถูกใช้โดยแอปพลิเคชันต่างๆ ของลูกค้า แนวคิดเรื่อง การบริการ ระบบปฏิบัติการแบบกระจายศูนย์จึงถูกนำกลับมาใช้ใหม่ใน โครงการ Golden Gateและมีความพยายามที่จะหาเหตุผลในการพัฒนา แต่ความพยายามนี้ก็ล้มเหลวเช่นกัน แนวคิดเรื่องการบริการแบบกระจายศูนย์นั้นใหม่เกินไปสำหรับนักวางแผนผลิตภัณฑ์ของ IBM ที่จะสามารถประเมินมูลค่าของซอฟต์แวร์ที่เชื่อมต่อคอมพิวเตอร์ที่แตกต่างกันได้

อย่างไรก็ตาม จอห์น บอนดี นักวางแผนของ โกลเด้น เกต คนหนึ่ง ยังคงเชื่อมั่นและโน้มน้าวฝ่ายบริหารให้จัดตั้งแผนกใหม่ขึ้นมาอยู่นอกเหนือการควบคุมปกติของห้องปฏิบัติการโรเชสเตอร์ เพื่อที่จะไม่ต้องมีกรณีศึกษาทางธุรกิจที่กำหนดไว้ล่วงหน้าในทันที นอกจากนี้ เขายังจำกัดภารกิจของแผนกให้แคบลงเหลือเพียงการสนับสนุนการจัดการข้อมูลแบบกระจาย (Distributed Data Managementหรือ DDM) โดยเฉพาะอย่างยิ่ง การสนับสนุนไฟล์แบบเน้นระเบียนจากนั้นเขาก็โน้มน้าวให้ริชาร์ด เอ. เดเมอร์ส สถาปนิกซอฟต์แวร์ผู้มีประสบการณ์ มาร่วมงานกับเขาในการกำหนดสถาปัตยกรรม DDM และขายแนวคิด DDM ให้กับบริษัทระบบของ IBM

ความพยายามในปีแรกส่วนใหญ่ไม่ประสบผลสำเร็จ เนื่องจากศูนย์บริการระบบของ IBM ยังคงเรียกร้องให้มีแผนธุรกิจที่ชัดเจนล่วงหน้า และยืนกรานในรูปแบบข้อความที่สอดคล้องกับอินเทอร์เฟซบล็อกควบคุมของระบบไฟล์ในเครื่องของพวกเขา นอกจากนี้ เมื่อคอมพิวเตอร์ส่วนบุคคลเริ่มถูกนำมาใช้เป็นเทอร์มินัลที่เชื่อมต่อกับคอมพิวเตอร์เมนเฟรม ก็มีการโต้แย้งว่าการปรับปรุงสตรีมข้อมูล 3270 เพียงอย่างเดียว ก็จะทำให้พีซีสามารถเข้าถึงข้อมูลจากเมนเฟรมได้

ในช่วงเวลานี้ เดเมอร์สได้ออกแบบแบบจำลองทางสถาปัตยกรรมของไคลเอนต์และเซิร์ฟเวอร์ DDM รวมถึงส่วนประกอบต่างๆ และการโต้ตอบระหว่างคอมพิวเตอร์ที่สื่อสารกัน นอกจากนี้ เขายังได้กำหนดรูปแบบทั่วไปสำหรับข้อความ DDM โดยอิงตามหลักการของการเขียนโปรแกรมเชิงวัตถุ ซึ่งเป็นหลักการที่ริเริ่มโดย ภาษาโปรแกรม Smalltalkและ IBM System/38 แบบจำลองนี้ทำให้เห็นได้อย่างชัดเจนว่าผลิตภัณฑ์ DDM สามารถนำไปใช้กับระบบต่างๆ ได้อย่างไร ดูวิธีการทำงานของ DDM

ในปี พ.ศ. 2525 ผู้วางแผนระบบ System/36 เชื่อมั่นว่ามีตลาดเพียงพอสำหรับบริการไฟล์ที่เน้นบันทึก DDM ^{[ 3 ]}

รูปแบบทั่วไปของข้อความ DDM ได้รับการออกแบบไว้แล้ว แต่ควรจะกำหนดข้อความเฉพาะใดบ้าง? ระบบไฟล์ System/36 ได้รับการกำหนดขึ้นเพื่อตอบสนองความต้องการด้านการจัดเก็บระเบียนของภาษาโปรแกรมรุ่นที่สาม (3GLs) เช่นFortran , COBOL , PL/IและIBM RPGเช่นเดียวกับระบบไฟล์ System/38 และ ระบบไฟล์ Virtual Storage Access Method (VSAM) ของคอมพิวเตอร์เมนเฟรม IBM อย่างไรก็ตาม สิ่งอำนวยความสะดวกและอินเทอร์เฟซที่แท้จริงของระบบเหล่านี้แตกต่างกันอย่างมาก ดังนั้นสถาปัตยกรรม DDM ควรสนับสนุนสิ่งอำนวยความสะดวกและอินเทอร์เฟซใดบ้าง? ดูไฟล์ที่เน้นการจัดเก็บระเบียน

งานเริ่มต้นเกี่ยวกับ DDM โดย โครงการ Golden Gateนั้นได้ยึดตาม มาตรฐานสากล File Transfer Access and Management ( FTAM ) สำหรับไฟล์แบบกระจาย แต่มีความเป็นนามธรรมสูงและยากต่อการนำไปใช้กับบริการไฟล์ในระดับท้องถิ่น อันที่จริง นี่เป็นหนึ่งในอุปสรรคต่อการยอมรับจากฝ่ายระบบของ IBM Kenneth Lawrence สถาปนิกระบบที่รับผิดชอบบริการไฟล์ System/36 ได้โต้แย้งว่าจะเป็นการดีกว่าหากกำหนดข้อความที่อย่างน้อยหนึ่งระบบของ IBM สามารถนำไปใช้ได้อย่างง่ายดาย จากนั้นจึงปล่อยให้ระบบอื่นๆ ร้องขอการเปลี่ยนแปลงใดๆ ที่ต้องการ แน่นอน เขาได้สนับสนุนข้อกำหนดของ System/36 หลังจากพยายามโน้มน้าวฝ่ายระบบอื่นๆ ของ IBM มาเป็นเวลาหนึ่งปีแต่ไม่สำเร็จ ในที่สุดข้อโต้แย้งของ Lawrence ก็ได้รับชัยชนะ

ริชาร์ด แซนเดอร์ส เข้าร่วมทีมออกแบบสถาปัตยกรรม DDM และทำงานร่วมกับลอว์เรนซ์และเดเมอร์สเพื่อกำหนดข้อความเฉพาะที่จำเป็นสำหรับ DDM ของ System/36 ความคืบหน้าในการกำหนด DDM กระตุ้นให้ System/38 เข้าร่วมด้วย ซึ่งเป็นการขยายขอบเขตการสนับสนุนไฟล์บันทึก DDM เพื่อตอบสนองความต้องการหลายประการของระบบไฟล์ขั้นสูงของ System/38

ไฟล์ต่างๆ ดำรงอยู่ภายในบริบทที่ระบบปฏิบัติการจัดเตรียมไว้ ซึ่งระบบปฏิบัติการจะให้บริการด้านการจัดระเบียบไฟล์ การแชร์ไฟล์กับผู้ใช้พร้อมกัน และการรักษาความปลอดภัยจากการเข้าถึงที่ไม่ได้รับอนุญาต ในระดับที่ 1 ของ DDM การเข้าถึงไดเร็กทอรีไฟล์ระยะไกลไม่ได้รับการสนับสนุน นอกเหนือจากการส่งชื่อไฟล์แบบเต็ม (fully qualified name) ที่จะใช้งานเท่านั้น อย่างไรก็ตาม การรักษาความปลอดภัยและการแชร์ไฟล์นั้นเป็นสิ่งจำเป็น แซนเดอร์สเป็นผู้ทำการออกแบบในด้านเหล่านี้ แซนเดอร์สยังได้กำหนดโปรโตคอลเฉพาะเกี่ยวกับการใช้สิ่งอำนวยความสะดวกด้านการสื่อสาร ซึ่งถูกรวมเข้าไว้ในส่วนประกอบที่เรียกว่า DDM Conversational Communications Manager ในตอนแรกนั้นใช้ APPC ในการใช้งาน แต่ต่อมาได้เปลี่ยนมาใช้ TCP/IPแทน

เมื่อผลิตภัณฑ์ System/36 DDM เสร็จสมบูรณ์ ลอว์เรนซ์ได้ทำงานร่วมกับโปรแกรมเมอร์จากห้องปฏิบัติการ IBM Hursley Park ประเทศอังกฤษ เพื่อปรับการเขียนโปรแกรมเซิร์ฟเวอร์ System/36 DDM ส่วนใหญ่ให้สามารถใช้งานได้ใน สภาพแวดล้อม การประมวลผลธุรกรรม ของ ระบบควบคุมข้อมูลลูกค้า ของ IBM (CICS) ซึ่งทำให้ CICS กลายเป็นเซิร์ฟเวอร์ DDM สำหรับระบบปฏิบัติการเมนเฟรม MVS และ VSE ^{[ 4 ]}ลอว์เรนซ์ยังได้ทำงานร่วมกับโปรแกรมเมอร์จากห้องปฏิบัติการ IBM Cary รัฐนอร์ทแคโรไลนา เพื่อนำไคลเอ็นต์ DDM ที่เน้นเรคอร์ดมาใช้กับIBM PC DOS

สถาปัตยกรรม DDM ระดับ 1 ได้รับการเผยแพร่อย่างเป็นทางการในปี 1986 ในช่วงเวลาของการประกาศนี้ IBM ได้มอบรางวัลความสำเร็จทางเทคนิคดีเด่นให้แก่ Kenneth Lawrence รางวัลผลงานดีเด่นให้แก่ Richard Sanders และรางวัลนวัตกรรมดีเด่นให้แก่ Richard Demers

• ในบทความนี้ ต่อไปนี้จะใช้คำว่า System/38เพื่ออ้างถึง System/38 และรุ่นต่อๆ มา ได้แก่ IBM AS/400 (ซึ่งรวมฟังก์ชันการทำงานของ System/36 และ System/38 เข้าด้วยกัน) IBM iSeries และ IBM Power Series ^{[ 5 ]} (ซึ่งรวม iSeries เข้ากับ IBM RS/6000 ซึ่งเป็นกลุ่มผลิตภัณฑ์เซิร์ฟเวอร์และเวิร์กสเตชันที่ใช้ RISC/UNIX ของ IBM)

เนื่องจากคอมพิวเตอร์ส่วนบุคคลของ IBM (IBM PC) และระบบปฏิบัติการ Unix มีความสำคัญเพิ่มมากขึ้นในสภาพแวดล้อมเครือข่าย จึงจำเป็นต้องมีการสนับสนุน DDM สำหรับไดเร็กทอรีแบบลำดับชั้นและไฟล์แบบสตรีมของคอมพิวเตอร์ส่วนบุคคลของ IBMที่ใช้IBM PC DOSและIBM RS/6000ที่ใช้IBM AIX (Unix เวอร์ชันของ IBM) ดูที่ไฟล์แบบสตรีม

เอกสาร DDM Architecture Level 2 ได้รับการเผยแพร่ในปี 1988 โดย Jan Fisher และ Sunil Gaitonde เป็นผู้ดำเนินการด้านสถาปัตยกรรมส่วนใหญ่ในการรองรับไดเร็กทอรีและไฟล์สตรีมของ DDM

ในปี พ.ศ. 2529 IBM ได้วางจำหน่าย ผลิตภัณฑ์ ฐานข้อมูลเชิงสัมพันธ์ (RDB) ที่แตกต่างกันสี่แบบ โดยแต่ละแบบสร้างขึ้นสำหรับระบบปฏิบัติการของ IBM โดยเฉพาะ นักวิทยาศาสตร์ที่ห้องปฏิบัติการวิจัย Almaden ของ IBM ได้พัฒนา System/R* ซึ่งเป็นต้นแบบของ RDB แบบกระจาย และพวกเขารู้สึกว่าถึงเวลาแล้วที่จะเปลี่ยนมันให้เป็นผลิตภัณฑ์ที่สามารถวางจำหน่ายได้ อย่างไรก็ตาม System/R* นั้นอิงตาม System/R ซึ่งเป็นต้นแบบการวิจัยของ RDB และไม่สามารถเพิ่มเข้าไปในผลิตภัณฑ์ RDB ของ IBM ได้ง่ายๆ ดู^{[ 6 ]} สำหรับการอภิปรายเกี่ยวกับ RDB ในสภาพแวดล้อมการประมวลผลแบบกระจาย

Roger Reinsch จากศูนย์การเขียนโปรแกรม IBM Santa Theresa เป็นผู้นำทีมข้ามผลิตภัณฑ์เพื่อกำหนดสถาปัตยกรรมฐานข้อมูลเชิงสัมพันธ์แบบกระจาย (Distributed Relational Database Architectureหรือ DRDA) โดยเขาได้ดึงสมาชิกจาก:

• ตัวแทนจากผลิตภัณฑ์ IBM RDB ทั้งสี่ตัว
• บรูซ ลินด์เซย์ นักวิจัยของ System/R*
• พอล โรเวอร์ (จากห้องปฏิบัติการ IBM ซินเดลฟิงเงน ประเทศเยอรมนี) ผู้พัฒนารูปแบบเฉพาะสำหรับการอธิบายข้อมูลที่เรียกว่า Formatted Object Content Architecture (FD:OCA)
• ริชาร์ด แซนเดอร์ส และริชาร์ด เดเมอร์ส จากทีมสถาปัตยกรรม DDM จะเป็นผู้กำหนดแบบจำลอง ข้อความ และโปรโตคอลที่เหมาะสม

ในปี พ.ศ. 2533 สถาปัตยกรรม DDM ระดับ 3 และ DRDA ^{[ 7 ]}ได้รับการเผยแพร่พร้อมกัน ทั้ง DDM และ DRDA ได้รับการกำหนดให้เป็นส่วนประกอบเชิงกลยุทธ์ของสถาปัตยกรรมแอปพลิเคชันระบบ (SAA) ของ IBM DRDA ได้รับการนำไปใช้โดยผลิตภัณฑ์ RDB ทั้งสี่ของ IBM และโดยผู้จำหน่ายรายอื่น ๆ

มีการมอบรางวัลให้แก่ผู้มีส่วนร่วมสำคัญในการออกแบบ DRDA โดย Richard Sanders ได้รับรางวัลผู้มีผลงานดีเด่นและ Roger Reinsch กับ Richard Demers ได้รับรางวัลผู้สร้างสรรค์นวัตกรรมดีเด่น

โครงการDistributed File Management (DFM) ^{[ 8 ]}เริ่มต้นขึ้นเพื่อเพิ่มบริการ DDM ให้กับระบบปฏิบัติการ MVS ของ IBM เพื่อให้โปรแกรมบนคอมพิวเตอร์ระยะไกลสามารถสร้าง จัดการ และเข้าถึง ไฟล์ VSAMได้ John Hufferd ผู้จัดการโครงการ DFM ได้มองหาวิธีการแปลงฟิลด์ข้อมูลในเรคอร์ดจากทีมสถาปัตยกรรม DDM ในขณะที่ข้อมูลไหลระหว่างระบบ Richard Demers เป็นผู้นำในประเด็นนี้ โดยได้รับความช่วยเหลือจาก Koichi Yamaguchi จากโครงการ DFM ดูคำอธิบายและการแปลงข้อมูล

บริการเพิ่มเติมต่อไปนี้ได้รับการกำหนดโดย Richard Sanders, Jan Fisher และ Sunil Gaitonde ในสถาปัตยกรรม DDM ที่ระดับ 4:

• สำหรับ DFM นั้นเกี่ยวข้องกับการจัดการพื้นที่จัดเก็บข้อมูลและคุณลักษณะไฟล์ที่ผู้ใช้กำหนดเอง
• สำหรับ DRDA นั้น จะใช้โปรโตคอลควบคุมการยืนยันการทำงานแบบสองเฟสสำหรับหน่วยงานกระจายงานที่กำหนดโดยแอปพลิเคชัน
• คิว คือ ข้อมูลที่สามารถสร้าง ล้าง หรือลบได้ในเซิร์ฟเวอร์ระยะไกล รายการในคิวเป็นระเบียนที่กำหนดโดยแอปพลิเคชัน ซึ่งจะถูกเพิ่มหรือรับจากคิว ดูที่คิวDDM
• ตัวประมวลผลคำสั่งระบบ (System Command Processor) คือตัวจัดการที่สามารถส่งคำสั่งที่กำหนดโดยระบบโฮสต์ของเซิร์ฟเวอร์ไปเพื่อดำเนินการได้
• ตัวจัดการการสื่อสารแบบมัลติทาสก์ ซึ่งช่วยให้เอเจนต์ไคลเอ็นต์หลายตัวสามารถสื่อสารกับเอเจนต์เซิร์ฟเวอร์ที่เกี่ยวข้องได้โดยใช้การสนทนาเพียงครั้งเดียวระหว่างระบบไคลเอ็นต์และเซิร์ฟเวอร์
• ตัวจัดการจุดซิงค์จะประสานงานหน่วยงานเชิงตรรกะในเซิร์ฟเวอร์ DDM หลายเครื่อง โปรโตคอลการยืนยันสองขั้นตอนช่วยให้มั่นใจได้ว่าการกู้คืนทรัพยากรจะดำเนินการอย่างเป็นระบบเมื่อหน่วยงานเชิงตรรกะใดๆ ล้มเหลว

มาตรฐานสถาปัตยกรรม DDM ระดับ 4 ได้รับการเผยแพร่ในปี 1992

งานด้านสถาปัตยกรรมในระดับ DDM 5 ประกอบด้วยการสนับสนุนสำหรับ

• ชุดข้อมูลแบบแบ่งพาร์ติชันของเมนเฟรมคือไฟล์ที่ประกอบด้วยไดเร็กทอรีภายในและสมาชิกหลายรายการ กล่าวอีกนัยหนึ่งคือเป็นไลบรารีของไฟล์ที่คล้ายกัน
• ไลบรารีคอมพิวเตอร์ส่วนบุคคลซึ่งรวมการเข้าถึงไฟล์ในหลายๆ โฟลเดอร์ไว้ในไลบรารีเดียว
• การปรับปรุงเพิ่มเติมสำหรับ DRDA

Jan Fisher เป็นสถาปนิกผู้รับผิดชอบ DDM ระดับ 5 ซึ่งเผยแพร่โดย Open Groupไม่ใช่ IBM หลังจากนั้นไม่นาน กลุ่มสถาปนิก DDM ของ IBM ก็ถูกยุบไป

สถาปัตยกรรม DDM คือชุดข้อกำหนดที่กำหนดไว้อย่างเป็นทางการและมีโครงสร้างสูง ส่วนนี้จะแนะนำแนวคิดทางเทคนิคที่สำคัญซึ่งเป็นพื้นฐานของ DDM ^{[ 2 ]}

สถาปัตยกรรม DDM กำหนดโปรโตคอลแบบไคลเอ็นต์/เซิร์ฟเวอร์ กล่าวคือ ไคลเอ็นต์ร้องขอการบริการจากเซิร์ฟเวอร์ ซึ่งเซิร์ฟเวอร์จะโต้ตอบกับทรัพยากรในพื้นที่เพื่อดำเนินการบริการที่ร้องขอ โดยผลลัพธ์ ซึ่งได้แก่ ข้อมูลและตัวบ่งชี้สถานะ จะถูกส่งกลับไปยังไคลเอ็นต์ แผนภาพด้านบนแสดงบทบาทของไคลเอ็นต์และเซิร์ฟเวอร์ DDM ที่เกี่ยวข้องกับทรัพยากรในพื้นที่ (ในที่นี้ใช้คำศัพท์ทั่วไปของไคลเอ็นต์และเซิร์ฟเวอร์แต่ในสถาปัตยกรรม DDM ไคลเอ็นต์เรียกว่าเซิร์ฟเวอร์ต้นทางและเซิร์ฟเวอร์เรียกว่าเซิร์ฟเวอร์ปลายทาง )

1. โปรแกรมแอปพลิเคชันจะโต้ตอบกับทรัพยากรภายในเครื่อง เช่น ไฟล์ โดยอาศัยอินเทอร์เฟซการเขียนโปรแกรมที่จัดเตรียมโดยตัวจัดการทรัพยากรภายในเครื่อง (LRM) แต่หากทรัพยากรที่ต้องการอยู่บนคอมพิวเตอร์ระยะไกล จะใช้ DDM ในการเป็นตัวกลางในการโต้ตอบ โปรแกรมแอปพลิเคชันยังคงใช้อินเทอร์เฟซที่จัดเตรียมโดย LRM แต่จะถูกส่งต่อไปยังไคลเอนต์ DDM สถาปัตยกรรม DDM ไม่ได้ระบุวิธีการส่งต่อนี้ เนื่องจากไม่รองรับไดเร็กทอรีของทรัพยากรระยะไกล วิธีการส่งต่อวิธีหนึ่งที่ใช้โดยผลิตภัณฑ์ DDM ที่เน้นไฟล์หลายตัว คือ การให้แอปพลิเคชันเปิดไฟล์ภายในเครื่องพิเศษที่เรียกว่าไฟล์ DDMโดย System/38 ซึ่งให้ข้อมูลตำแหน่งและการเข้าถึงเกี่ยวกับไฟล์ระยะไกล จากนั้นจึงส่งต่อไปยังไคลเอนต์ DDM
2. สถาปัตยกรรม DDM กำหนดเอนทิตีระดับผู้จัดการสำหรับไฟล์ ฐานข้อมูลเชิงสัมพันธ์ วิธีการเข้าถึง ฯลฯ ตัวจัดการทรัพยากรไคลเอ็นต์ (CRM) สนับสนุนอินเทอร์เฟซการทำงานที่กำหนดโดย LRM ของระบบไคลเอ็นต์แบบโพลีมอร์ฟิก หน้าที่หลักของ CRM คือการสร้างวัตถุคำสั่งและข้อมูล DDM แบบเชิงเส้นที่เหมาะสมสำหรับแต่ละอินเทอร์เฟซการทำงาน (ดูข้อความ DDM ) วัตถุเหล่านี้จะถูกส่งไปยังตัวจัดการทรัพยากรเซิร์ฟเวอร์ (SRM) ของเซิร์ฟเวอร์ DDM ระยะไกล แต่ในความเป็นจริงแล้ว วัตถุเหล่านี้จะถูกส่งผ่านเอเจนต์ไคลเอ็นต์และเซิร์ฟเวอร์ DDM และตัวจัดการการสื่อสาร
3. เอเจนต์ไคลเอ็นต์ DDM จะใส่คำสั่งเชิงเส้นลงในซองจดหมาย RQSDSS และใส่วัตถุเชิงเส้นลงในซองจดหมาย OBJDSS ที่เชื่อมโยงกัน (ดูข้อความ DDM ) เอเจนต์ไคลเอ็นต์จะโต้ตอบกับเอเจนต์เซิร์ฟเวอร์เพื่อสร้างเส้นทางสำหรับข้อความที่ได้รับจาก CRM ให้ไหลไปยัง SRM หากโปรแกรมแอปพลิเคชันต้องการโต้ตอบกับทรัพยากรระยะไกลเพียงรายการเดียว กระบวนการนี้จะทำได้ง่าย อย่างไรก็ตาม เป็นไปได้ที่โปรแกรมแอปพลิเคชันจะโต้ตอบกับทรัพยากรหลายประเภทที่อยู่บนระบบระยะไกลหลายระบบพร้อมกัน เอเจนต์ไคลเอ็นต์จะเป็นตัวแทนของโปรแกรมแอปพลิเคชันในทุกกรณี และกำหนดเส้นทางข้อความบนเส้นทางเสมือนที่แยกต่างหากไปยังแต่ละทรัพยากร
4. ตัวจัดการการสื่อสารของไคลเอ็นต์จะทำงานร่วมกับตัวจัดการการสื่อสารของเซิร์ฟเวอร์เพื่อใช้โปรโตคอลการสนทนาในรูปแบบ "ฉันพูดในขณะที่คุณฟัง และจากนั้นคุณพูดในขณะที่ฉันฟัง" สามารถใช้โปรโตคอลการสื่อสารโทรคมนาคมต่างๆ ได้ รวมถึง SNA APPC ของ IBM และโปรโตคอล TCP/IP ของอินเทอร์เน็ต
5. ข้อความ DDM ที่ส่งไปยัง Server Communications Manager จะถูกส่งต่อไปยัง Server Agent ตามเส้นทางที่ระบุในข้อความ และ Server Agent จะส่งต่อข้อความเหล่านั้นไปยัง SRM ตามเส้นทางเดียวกัน หาก Server Agent ทำงานร่วมกับไคลเอ็นต์เพียงรายเดียวบนเส้นทางเดียว กระบวนการนี้จะตรงไปตรงมา อย่างไรก็ตาม Server Agent สามารถทำงานร่วมกับไคลเอ็นต์หลายรายบนหลายเส้นทางได้
6. ตัวจัดการทรัพยากรเซิร์ฟเวอร์ (SRM) จะวิเคราะห์ข้อความ DDM และพิจารณาว่าต้องทำอะไรเพื่อดำเนินการตามคำขอ โดยอาจใช้ส่วนต่อประสานการทำงานอย่างน้อยหนึ่งรายการของตัวจัดการทรัพยากรภายในเครื่อง (LRM) ที่เกี่ยวข้องของระบบเซิร์ฟเวอร์
7. SRM จะรวบรวมข้อมูลและตัวบ่งชี้สถานะจาก LRM และสร้างอ็อบเจ็กต์เชิงเส้นและข้อความตอบกลับที่เหมาะสม ซึ่งจะส่งต่อไปยัง Server Agent
8. ตัวแทนเซิร์ฟเวอร์จะบรรจุคำตอบและวัตถุต่างๆ ลงในซองจดหมาย RPYDSS และ OBJDSS แล้วส่งต่อไปยังตัวจัดการการสื่อสารเซิร์ฟเวอร์ ซึ่งจะส่งต่อไปยังตัวจัดการการสื่อสารไคลเอ็นต์และตัวแทนไคลเอ็นต์ตามเส้นทางเดียวกับคำสั่งดั้งเดิม
9. ตัวแทนไคลเอ็นต์จะนำข้อความตอบกลับและวัตถุออกจากซอง RPYDSS และ OBJDSS ที่เกี่ยวข้อง แล้วส่งต่อไปยังผู้จัดการทรัพยากรไคลเอ็นต์
10. ตัวจัดการทรัพยากรไคลเอ็นต์จะแยกวิเคราะห์วัตถุที่ส่งคืนและข้อความตอบกลับ และแมปข้อมูลเหล่านั้นตามที่อินเทอร์เฟซการทำงานของ LRM ดั้งเดิมคาดหวังไว้ เพื่อส่งคืนไปยังโปรแกรมแอปพลิเคชัน

สถาปัตยกรรม DDM เป็นแบบเชิงวัตถุ (Object-Oriented ) เอนทิตีทั้งหมดที่กำหนดโดย DDM เป็นวัตถุที่กำหนดโดยวัตถุคลาส ( Class object) ที่กำหนดตัวเอง ข้อความ การตอบกลับ และข้อมูลที่ไหลเวียนระหว่างระบบเป็นวัตถุแบบอนุกรม (Serialized object) แต่ละวัตถุจะระบุความยาว ระบุคลาสโดยใช้รหัส DDM (DDM codepoint) และมีข้อมูลตามที่กำหนดโดยคลาส นอกจากนี้ คลาสยังระบุคำสั่งที่สามารถส่งไปยังอินสแตนซ์ของวัตถุได้เมื่อวัตถุอยู่ในไคลเอ็นต์หรือเซิร์ฟเวอร์ DDM ซึ่งเป็นการห่อหุ้มวัตถุด้วยชุดการดำเนินการที่จำกัด

ในเชิงโครงสร้าง สถาปัตยกรรม DDM ประกอบด้วยระดับลำดับชั้นของวัตถุ โดยแต่ละระดับจะแสดงคุณสมบัติที่เกิดขึ้นใหม่ในระดับที่สูงขึ้นเรื่อยๆ

• ฟิลด์คือสตริงของบิตที่เข้ารหัสตัวเลข อักขระ หรือข้อมูลอื่นๆ อินสแตนซ์ของคลาสย่อย Field จะถูกห่อหุ้มด้วยการดำเนินการที่สามารถทำได้โดยคลาสของมัน ตัวอย่างเช่น การดำเนินการทางคณิตศาสตร์กับฟิลด์จำนวนเต็ม
• อ็อบเจ็กต์คือเอนทิตีที่ระบุตัวเองได้ซึ่งประกอบด้วยฟิลด์หนึ่งฟิลด์ขึ้นไปซึ่งถูกห่อหุ้มด้วยชุดการดำเนินการที่กำหนดไว้ อ็อบเจ็กต์ในระดับนี้ได้รับแรงบันดาลใจจากคลาสอ็อบเจ็กต์เคอร์เนลของภาษาการเขียนโปรแกรมSmalltalk ^{[ 9 ]}
  • อ็อบเจ็กต์สเกลาร์ประกอบด้วยฟิลด์เดียว ซึ่งถูกเข้ารหัสและอธิบายโดยคลาสของอ็อบเจ็กต์นั้น อ็อบเจ็กต์สเกลาร์ใช้เป็นค่าพารามิเตอร์ของอ็อบเจ็กต์คำสั่งและอ็อบเจ็กต์ตอบกลับ นอกจากนี้ยังใช้เป็นค่าของแอตทริบิวต์ของอ็อบเจ็กต์ เช่น ความยาวของอ็อบเจ็กต์ในเอกสาร DDM วิธีการเข้ารหัสที่ใช้สำหรับค่าของอ็อบเจ็กต์สเกลาร์เหล่านี้ได้รับการกำหนดไว้อย่างครบถ้วนโดยสถาปัตยกรรม DDM
  • อ็อบเจ็กต์ที่แมปไว้ประกอบด้วยฟิลด์ตั้งแต่หนึ่งฟิลด์ขึ้นไป เช่น ฟิลด์ของเรคอร์ดที่กำหนดโดยแอปพลิเคชัน วิธีการเข้ารหัสและการจัดเรียงของฟิลด์เหล่านี้ไม่ได้ถูกกำหนดโดยสถาปัตยกรรม DDM แต่จะถูกกำหนดโดยคำสั่งประกาศโปรแกรมแอปพลิเคชันและวิธีการเข้ารหัสและการจัดเรียงของภาษาโปรแกรม
  • อ็อบเจ็กต์คอลเลกชันคือภาชนะสำหรับเก็บอ็อบเจ็กต์ต่างๆ ตามที่กำหนดไว้ในคลาสของคอลเลกชันนั้น ตัวอย่างของอ็อบเจ็กต์คอลเลกชันได้แก่ คำสั่งและคำตอบของ DDM
• ผู้จัดการคือเอนทิตีที่ระบุตัวตนได้เองซึ่งจัดเตรียมสภาพแวดล้อมสำหรับการจัดเก็บและการประมวลผลวัตถุ ผู้จัดการถูกห่อหุ้มด้วยการดำเนินการที่กำหนดโดยคลาสของมัน ชุดของผู้จัดการร่วมกันจะสร้างสภาพแวดล้อมการประมวลผลโดยรวมของไคลเอนต์หรือเซิร์ฟเวอร์ DDM เอนทิตีผู้จัดการในระดับนี้ได้รับแรงบันดาลใจจากออบเจ็กต์ระบบของระบบปฏิบัติการ System/38 ^{[ 10 ]} ผู้จัดการที่กำหนดโดย DDM ได้แก่: พจนานุกรม, หัวหน้างาน, เอเจนต์, ไดเร็กทอรี, ไฟล์, วิธีการเข้าถึง, ฐานข้อมูลเชิงสัมพันธ์, ผู้จัดการแอปพลิเคชัน SQL, คิว, ผู้จัดการการล็อก, ผู้จัดการความปลอดภัย, ผู้จัดการการกู้คืน, ตัวประมวลผลคำสั่งระบบ, ผู้จัดการการสื่อสาร
• เซิร์ฟเวอร์คือหน่วยที่ระบุตัวตนได้ด้วยตนเอง ซึ่งจัดเตรียมสภาพแวดล้อมสำหรับการจัดเก็บและประมวลผลข้อมูลของผู้จัดการ ไม่ว่าจะเป็นในฐานะไคลเอนต์หรือเซิร์ฟเวอร์ ในสภาพแวดล้อมการประมวลผลแบบกระจาย ตัวอย่างเช่น ไคลเอนต์และเซิร์ฟเวอร์ที่เชี่ยวชาญด้านการจัดการไฟล์แบบกระจาย หรือการจัดการฐานข้อมูลเชิงสัมพันธ์แบบกระจาย

แม้ว่าสถาปัตยกรรมของ DDM จะเป็นแบบเชิงวัตถุ แต่ผลิตภัณฑ์ DDM นั้นถูกพัฒนาขึ้นโดยใช้ภาษาและวิธีการที่เป็นแบบฉบับของระบบโฮสต์Object Technology International ได้พัฒนา DDM เวอร์ชัน Smalltalk สำหรับ IBM PC โดยมีการสร้างคลาส Smalltalk ที่เหมาะสมโดยอัตโนมัติจากคู่มืออ้างอิง DDM

DDM เป็นสถาปัตยกรรมแบบเปิด ผลิตภัณฑ์ DDM สามารถนำสถาปัตยกรรม DDM บางส่วนมาใช้ได้ และยังสามารถสร้างส่วนขยายของตนเองได้อีกด้วย ^{[ 11 ]}

คำสั่ง 'Exchange Server Attributes' ของ DDM เป็นคำสั่งแรกที่ส่งเมื่อไคลเอ็นต์เชื่อมต่อกับเซิร์ฟเวอร์ คำสั่งนี้จะระบุไคลเอ็นต์และระบุตัวจัดการที่ไคลเอ็นต์ต้องการ รวมถึงระดับของสถาปัตยกรรม DDM ที่ต้องการการสนับสนุน เซิร์ฟเวอร์จะตอบกลับโดยการระบุตัวตนและระบุระดับที่เซิร์ฟเวอร์สนับสนุนตัวจัดการที่ร้องขอ โดยทั่วไปแล้ว ผลิตภัณฑ์ที่รองรับตัวจัดการ DDM ระดับ X จะต้องรองรับระดับ 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 ซองเหล่านี้เรียกว่าโครงสร้างสตรีมข้อมูล (Data Stream Structures หรือ DSS) คำสั่งจะถูกบรรจุลงในRequest DSS (RQSDSS) การตอบกลับจะถูกบรรจุลงในReply DSS (RPYDSS) และวัตถุอื่นๆ จะถูกบรรจุลงในObject DSS (OBJDSS) RQSDSS จะมีคำสั่งได้เพียงหนึ่งคำสั่ง และ RPYDSS จะมีคำตอบได้เพียงหนึ่งคำตอบ แต่ OBJDSS สามารถบรรจุวัตถุได้หลายรายการ เช่น เรคอร์ด นอกจากนี้ยังสามารถเชื่อมต่อ OBJDSS หลายตัวเข้ากับ RQSDSS หรือ RPYDSS เพื่อรองรับวัตถุได้มากเท่าที่จำเป็น DSS ประกอบด้วยความยาวทั้งหมดของ DSS ไบต์แฟล็กที่ระบุประเภทของ DSS ตัวระบุคำขอ และวัตถุเชิงเส้นใน DSS ตัวระบุคำขอจะเชื่อมโยง RQSDSS กับ OBJDSS ที่ตามมาของไคลเอ็นต์ เช่น เรคอร์ดที่จะโหลดลงในไฟล์โดยคำสั่งLoad Fileตัวระบุคำขอจะเชื่อมโยง RQSDSS จากฝั่งไคลเอนต์กับ RPYDSS หรือ OBJDSS จากฝั่งเซิร์ฟเวอร์ไปยังฝั่งไคลเอนต์ด้วย

คู่มืออ้างอิง DDM ^{[ 12 ] [ 13 ]}ประกอบด้วยวัตถุเมนู ความช่วยเหลือ และคลาสที่มีชื่อ คลาสย่อยของคลาส DDM Class จะถูกอธิบายโดยตัวแปรที่ระบุ

• คลาสแม่ของคลาส คลาสถูกกำหนดโดยลำดับชั้นการสืบทอด ตัวอย่างเช่น Record File เป็นคลาสย่อยของ File ซึ่งเป็นคลาสย่อยของ Manager และสืบทอดข้อมูลและคำสั่งจากทั้งสองคลาส คลาสÇlassและคลาสย่อยของมันสามารถอธิบายตัวเองได้ด้วยคำสั่ง Çlassและตัวแปรคลาสซึ่งรวมถึง:
• ชื่อเรื่องที่อธิบายรายละเอียดของชั้นเรียนโดยย่อ
• สถานะของชั้นเรียนที่เกี่ยวข้องกับงานที่กำลังดำเนินการอยู่เกี่ยวกับสถาปัตยกรรม DDM
• ข้อความและภาพประกอบที่อธิบายความสัมพันธ์ระหว่างคลาสกับส่วนประกอบต่างๆ และสภาพแวดล้อมโดยรอบ
• ข้อมูล (ฟิลด์ อ็อบเจ็กต์ ตัวจัดการ ฯลฯ) ที่ถูกห่อหุ้มไว้ภายในอินสแตนซ์ของคลาส
• คำสั่งต่างๆ ที่สามารถส่งไปยังอินสแตนซ์ของมันได้

วัตถุเหล่านี้สามารถมีข้อมูลอ้างอิงถึงวัตถุอื่นที่มีชื่อในข้อความและข้อกำหนด ทำให้เกิด การเชื่อมโยง แบบไฮเปอร์เท็กซ์ระหว่างหน้าต่างๆ ของคู่มืออ้างอิง DDM เมนูและหน้าช่วยเหลือประกอบกันเป็นบทเรียนแบบบูรณาการเกี่ยวกับ DDM คู่มืออ้างอิง DDM ระดับ 3 ฉบับกระดาษมีขนาดใหญ่กว่า 1400 หน้า และใช้งานค่อนข้างยาก แต่ก็มีการสร้างเวอร์ชันแบบโต้ตอบขึ้นโดยใช้สิ่งอำนวยความสะดวกด้านการสื่อสารภายในของ IBM เนื่องจากความเร็วในการสื่อสารค่อนข้างช้า จึงมีประโยชน์หลักๆ ภายในห้องปฏิบัติการ IBM Rochester เท่านั้น

นอกจากคู่มืออ้างอิง DDM แล้ว เอกสารข้อมูลทั่วไป^{[ 1 ]}ยังให้ข้อมูลระดับผู้บริหารเกี่ยวกับ DDM และคู่มือโปรแกรมเมอร์^{[ 11 ]}สรุปแนวคิด DDM สำหรับโปรแกรมเมอร์ที่ใช้งานไคลเอ็นต์และเซิร์ฟเวอร์

สถาปัตยกรรม DDM กำหนดรูปแบบไฟล์ทั่วไปไว้ 3 แบบ ได้แก่ ไฟล์แบบบันทึกข้อมูล ไฟล์แบบสตรีมข้อมูล และไดเร็กทอรีแบบลำดับชั้น

สถาปัตยกรรม DDM ให้บริการต่อไปนี้สำหรับการจัดการไฟล์ระยะไกล:

• การสร้าง การล้าง และการลบไฟล์
• การคัดลอก การโหลด และการถ่ายโอนข้อมูลของไฟล์
• การล็อกและปลดล็อกไฟล์
• การรับและเปลี่ยนแปลงคุณสมบัติของไฟล์

ไฟล์แบบบันทึกข้อมูล (Record-oriented files) ถูกออกแบบมาเพื่อตอบสนองความต้องการด้านการป้อนข้อมูล การส่งออกข้อมูล และการจัดเก็บข้อมูลของภาษาโปรแกรมรุ่นที่สาม (3GL) เช่น Fortran, Cobol, PL/I และ RPG แทนที่จะให้แต่ละภาษาจัดเตรียมการสนับสนุนความสามารถเหล่านี้เอง จึงมีการรวมความสามารถเหล่านี้เข้าไว้ในบริการที่ระบบปฏิบัติการจัดให้

ระเบียน คือชุดของฟิลด์ข้อมูลที่เกี่ยวข้องกัน เช่น ชื่อ ที่อยู่ หมายเลขประจำตัว และเงินเดือนของพนักงานคน เดียวโดยแต่ละฟิลด์จะถูกเข้ารหัสและแมปไปยังสตริงไบต์ที่ต่อเนื่องกัน คอมพิวเตอร์ยุคแรกมีขีดความสามารถในการรับและส่งข้อมูลที่จำกัด โดยทั่วไปอยู่ในรูปแบบของบัตรเจาะรู 80 คอลัมน์ หรือในรูปแบบของกระดาษหรือเทปแม่เหล็ก ระเบียนแอปพลิเคชัน เช่น ระเบียนข้อมูลพนักงาน จะถูกอ่านหรือเขียนตามลำดับทีละระเบียนและประมวลผลเป็นชุด เมื่ออุปกรณ์จัดเก็บข้อมูลแบบเข้าถึงโดยตรง (DIA) เริ่มใช้งานได้ ภาษาโปรแกรมได้เพิ่มวิธีการให้โปรแกรมสามารถเข้าถึงระเบียนแบบสุ่มทีละระเบียน เช่น การเข้าถึงโดยใช้ค่าของฟิลด์หลักหรือโดยใช้ตำแหน่งของระเบียนในไฟล์ ระเบียนทั้งหมดในไฟล์อาจมีรูปแบบเดียวกัน (เช่นในไฟล์เงินเดือน) หรือมีรูปแบบที่แตกต่างกัน (เช่นในบันทึกเหตุการณ์) ไฟล์บางไฟล์เป็นแบบอ่านอย่างเดียว กล่าวคือ เมื่อเขียนระเบียนลงในไฟล์แล้ว จะสามารถอ่านได้เท่านั้น ในขณะที่ไฟล์อื่นๆ อนุญาตให้มีการอัปเดตระเบียนได้

โมเดลไฟล์แบบเน้นระเบียนของ DDM ประกอบด้วยคุณลักษณะของไฟล์ เช่น วันที่สร้าง วันที่อัปเดตครั้งล่าสุด ขนาดของระเบียน และช่องสำหรับจัดเก็บระเบียน ระเบียนอาจมีความยาวคงที่หรือแปรผันได้ ขึ้นอยู่กับสื่อที่ใช้จัดเก็บระเบียนของไฟล์ DDM กำหนดไฟล์แบบเน้นระเบียนไว้สี่ประเภท:

• ไฟล์แบบเรียงลำดับ ซึ่งจัดเก็บข้อมูลในช่องที่เรียงต่อกัน
• ไฟล์แบบไดเร็กต์ คือไฟล์ที่จัดเก็บระเบียนแต่ละรายการไว้ในช่องของไฟล์ซึ่งกำหนดโดยค่าของฟิลด์ในระเบียนเหล่านั้น
• ไฟล์ข้อมูลแบบมีคีย์ คือไฟล์ที่จัดเก็บระเบียนข้อมูลไว้ในช่องเรียงลำดับต่อเนื่องกัน และมีการรักษาลำดับรองโดยใช้ดัชนีของค่าฟิลด์คีย์ที่อยู่ในระเบียนข้อมูลเหล่านั้น
• ไฟล์ดัชนีทางเลือก ซึ่งดัชนีแยกต่างหากของค่าฟิลด์หลักจะอิงตามไฟล์ลำดับ ไฟล์โดยตรง หรือไฟล์ที่มีคีย์ที่มีอยู่เดิม

สถาปัตยกรรม DDM ยังกำหนด วิธีการเข้าถึงที่หลากหลายสำหรับการทำงานกับไฟล์ที่เน้นระเบียนในรูปแบบต่างๆ วิธีการเข้าถึงคืออินสแตนซ์ของการใช้ไฟล์ที่สร้างขึ้นโดยใช้คำสั่ง OPEN ซึ่งจะเชื่อมต่อกับไฟล์หลังจากตรวจสอบแล้วว่าไคลเอ็นต์ได้รับอนุญาตให้ใช้งานหรือไม่ วิธีการเข้าถึงจะถูกตัดการเชื่อมต่อจากไฟล์โดยใช้คำสั่ง CLOSE

วิธีการเข้าถึงข้อมูลจะติดตามระเบียนที่กำลังประมวลผลอยู่โดยใช้เคอร์เซอร์ โดยใช้คำสั่ง SET ต่างๆ เคอร์เซอร์สามารถชี้ไปยังต้นหรือท้ายไฟล์ ไปยังระเบียนถัดไปหรือก่อนหน้าตามลำดับ ไปยังระเบียนที่มีค่าคีย์เฉพาะ หรือไปยังระเบียนถัดไปหรือก่อนหน้าตามลำดับคีย์ได้

สามารถเปิดวิธีการเข้าถึงไฟล์ได้หลายวิธีพร้อมกัน โดยแต่ละวิธีจะให้บริการแก่ไคลเอ็นต์เพียงรายเดียว หากไฟล์ถูกเปิดเพื่อแก้ไขข้อมูล อาจเกิดข้อขัดแย้งขึ้นได้เมื่อไคลเอ็นต์หลายรายเข้าถึงเรคอร์ดเดียวกัน เพื่อป้องกันข้อขัดแย้งดังกล่าว สามารถล็อกไฟล์ทั้งหมดได้ นอกจากนี้ หากไฟล์ถูกเปิดเพื่อแก้ไขข้อมูลไคลเอ็นต์รายแรกที่อ่านไฟล์จะล็อกเรคอร์ดนั้นไว้ และจะปลดล็อกเมื่อไคลเอ็นต์นั้นแก้ไขข้อมูลเสร็จแล้ว ไคลเอ็นต์รายอื่น ๆ ต้องรอจนกว่าการล็อกจะถูกปลดล็อกก่อน

ไฟล์แบบสตรีมประกอบด้วยลำดับของไบต์เพียงชุดเดียว ซึ่งโปรแกรมสามารถแมปข้อมูลแอปพลิเคชันได้ตามต้องการ ไฟล์แบบสตรีมเป็นรูปแบบไฟล์หลักที่รองรับโดย ระบบปฏิบัติการ Unixและ ระบบปฏิบัติการ ที่คล้าย UnixรวมถึงWindows DDM กำหนดรูปแบบไฟล์แบบสตรีมเพียงแบบเดียวและวิธีการเข้าถึงแบบสตรีมเพียงวิธีเดียว

โมเดลไฟล์สตรีม DDM ประกอบด้วยคุณลักษณะของไฟล์ เช่น วันที่สร้างและขนาดของสตรีม และสตรีมไบต์ต่อเนื่อง สตรีมสามารถเข้าถึงได้โดยใช้วิธีการเข้าถึงสตรีม (Stream Access Method) โปรแกรมแอปพลิเคชันจะเขียนข้อมูลลงในส่วนต่างๆ ของสตรีม แม้ว่าข้อมูลนั้นจะเป็นระเบียนก็ตาม และสามารถติดตามตำแหน่งของรายการข้อมูลในสตรีมได้ตามต้องการ ตัวอย่างเช่น สตรีมข้อมูลของไฟล์เอกสารถูกกำหนดโดยโปรแกรมประมวลผลข้อความ เช่นMicrosoft Wordและสตรีมข้อมูลของไฟล์สเปรดชีตถูกกำหนดโดยโปรแกรม เช่นMicrosoft Excel

วิธีการเข้าถึงสตรีมคือตัวอย่างการใช้งานไฟล์สตรีมโดยไคลเอนต์เดียว เคอร์เซอร์จะติดตามตำแหน่งของไบต์ปัจจุบันของซับสตรีมที่ไคลเอนต์ใช้งานอยู่ โดยใช้คำสั่ง SET ต่างๆ เคอร์เซอร์สามารถชี้ไปยังจุดเริ่มต้นหรือจุดสิ้นสุดของไฟล์ ไปยังตำแหน่งใดๆ ในไฟล์ หรือไปยังค่าออฟเซ็ตบวกหรือลบใดๆ จากตำแหน่งปัจจุบันได้

สามารถเปิดอินสแตนซ์ของวิธีการเข้าถึงแบบสตรีมได้หลายครั้งพร้อมกันบนไฟล์ โดยแต่ละครั้งจะให้บริการแก่ไคลเอ็นต์เพียงรายเดียว หากไฟล์ถูกเปิดเพื่อการเข้าถึงแบบ "อัปเดต" อาจเกิดข้อขัดแย้งขึ้นได้เมื่อไคลเอ็นต์หลายรายเข้าถึงสตรีมย่อยเดียวกัน เพื่อป้องกันข้อขัดแย้งดังกล่าว สามารถล็อกไฟล์ทั้งหมดได้ นอกจากนี้ หากไฟล์ถูกเปิดเพื่อการอัปเดตไคลเอ็นต์รายแรกที่ "อ่าน" ไฟล์นั้นจะได้รับล็อกบนสตรีมย่อย และจะปล่อยล็อกเมื่อไคลเอ็นต์นั้น "อัปเดต" ไฟล์เสร็จแล้ว ไคลเอ็นต์รายอื่น ๆ ต้องรอจนกว่าล็อกจะถูกปล่อย

ไดเร็กทอรีแบบลำดับชั้นคือไฟล์ที่มีแต่ละระเบียนเชื่อมโยงชื่อกับตำแหน่งที่ตั้ง ลำดับชั้นเกิดขึ้นเมื่อระเบียนในไดเร็กทอรีระบุชื่อและตำแหน่งที่ตั้งของไดเร็กทอรีอื่น การใช้ผลิตภัณฑ์ไคลเอ็นต์และเซิร์ฟเวอร์ DDM โปรแกรมสามารถสร้าง ลบ และเปลี่ยนชื่อไดเร็กทอรีในคอมพิวเตอร์ระยะไกลได้ นอกจากนี้ยังสามารถแสดงรายการและเปลี่ยนแปลงคุณสมบัติของไฟล์ในไดเร็กทอรีระยะไกลได้อีกด้วย สามารถอ่านระเบียนในไดเร็กทอรีได้ตามลำดับโดยใช้วิธีการเข้าถึงไดเร็กทอรีของ DDM ไฟล์ที่ระบุโดยระเบียนในไดเร็กทอรีสามารถเปลี่ยนชื่อ คัดลอก และย้ายไปยังไดเร็กทอรีอื่นได้

คิวเป็นกลไกการสื่อสารที่ช่วยให้การสื่อสารระหว่างโปรแกรมต่างๆ เกิดขึ้นได้ในระยะสั้น โดยอาศัยข้อมูลบันทึก คิว DDM จะอยู่ในระบบเดียว แต่โปรแกรมบนหลายระบบสามารถเข้าถึงได้ มีคิว DDM สามประเภทย่อยที่สามารถสร้างได้บนระบบเป้าหมายโดยใช้คำสั่งสร้างที่แตกต่างกัน:

• คิวแบบเข้าก่อนออกก่อน (First-in-first-out queues) คือท่อส่งข้อมูลแบบอะซิงโครนัสระหว่างโปรแกรมที่รับข้อมูลเข้าคิวและโปรแกรมที่ดึงข้อมูลออกจากคิว
• คิวแบบเข้าหลังออกก่อน (Last-in-first-out queues) หรือสแต็กแบบพุชดาวน์ (pushdown stack
• คิวแบบใช้คีย์ คือกลไกการกระจายข้อมูลที่สามารถดึงรายการที่เลือกออกจากคิวได้โดยใช้ค่าคีย์

แบบจำลองคิว DDM ประกอบด้วยคุณลักษณะของคิว เช่น วันที่สร้างคิว จำนวนระเบียนที่คิวสามารถบรรจุได้ และความยาวของระเบียน โดยระเบียนในคิวอาจมีความยาวคงที่หรือเปลี่ยนแปลงได้

แตกต่างจากโมเดลไฟล์ DDM ตรงที่ไม่จำเป็นต้องเปิดวิธีการเข้าถึงบนคิว โปรแกรมสามารถเพิ่มเรคอร์ดลงในคิวและรับเรคอร์ดจากคิวได้ตามที่กำหนดโดยคลาสของคิว นอกจากนี้ โปรแกรมยังสามารถล้างเรคอร์ดออกจากคิว หยุดการทำงานบนคิว แสดงรายการแอตทริบิวต์ของคิว และเปลี่ยนแปลงแอตทริบิวต์ของคิวได้ โปรแกรมยังสามารถล็อกคิวหรือเรคอร์ดแต่ละรายการในคิวเพื่อป้องกันการแย่งชิงจากโปรแกรมอื่น ลูกค้ารายอื่นทั้งหมดต้องรอจนกว่าการล็อกจะถูกปลดล็อก

ฐานข้อมูลเชิงสัมพันธ์ (RDB) คือการนำภาษาการสอบถามเชิงโครงสร้าง (SQL) มาใช้ ซึ่งสนับสนุนการสร้าง การจัดการ การสอบถาม การอัปเดต การจัดทำดัชนี และความสัมพันธ์ระหว่างตารางข้อมูล ผู้ใช้หรือโปรแกรมแบบโต้ตอบสามารถส่งคำสั่ง SQL ไปยัง RDB และรับตารางข้อมูลและตัวบ่งชี้สถานะกลับมาได้ อย่างไรก็ตาม คำสั่ง SQL ยังสามารถคอมไพล์และจัดเก็บไว้ใน RDB ในรูปแบบแพ็กเกจ จากนั้นเรียกใช้โดยใช้ชื่อแพ็กเกจได้ ซึ่งมีความสำคัญต่อการทำงานอย่างมีประสิทธิภาพของโปรแกรมแอปพลิเคชันที่ส่งคำสั่งสอบถามที่ซับซ้อนและมีความถี่สูง โดยเฉพาะอย่างยิ่งเมื่อตารางที่จะเข้าถึงนั้นอยู่บนระบบระยะไกล

สถาปัตยกรรมฐานข้อมูลเชิงสัมพันธ์แบบกระจาย (DRDA) เข้ากันได้ดีกับกรอบงาน DDM โดยรวม ดังที่ได้กล่าวไว้ในการวางแนวเชิงวัตถุ (อย่างไรก็ตาม DDM ยังสามารถมองได้ว่าเป็นสถาปัตยกรรมส่วนประกอบของ DRDA เนื่องจากจำเป็นต้องมีข้อกำหนดอื่นๆ ด้วย^{[ 2 ]} ) วัตถุระดับผู้จัดการ DDM ที่สนับสนุน DRDA มีชื่อว่า RDB (สำหรับฐานข้อมูลเชิงสัมพันธ์) และ SQLAM (สำหรับตัวจัดการแอปพลิเคชัน SQL)

ความโปร่งใสเป็นเป้าหมายหลักของสถาปัตยกรรม DDM โดยไม่ต้องทำการคอมไพล์ใหม่ ควรจะสามารถเปลี่ยนเส้นทางการทำงานของโปรแกรมแอปพลิเคชันที่มีอยู่ไปยังบริการจัดการข้อมูลของคอมพิวเตอร์ระยะไกลได้ สำหรับไฟล์นั้น ส่วนใหญ่แล้ว DDM Client ทำได้ในระดับอินเทอร์เฟซ/ฟังก์ชันการทำงาน แต่แล้วข้อมูลในฟิลด์ของเรคอร์ดล่ะ? ความโปร่งใสอย่างสมบูรณ์ต้องอาศัยให้โปรแกรมแอปพลิเคชันไคลเอ็นต์สามารถเขียนและอ่านฟิลด์ตามที่เข้ารหัสโดยระบบจัดการข้อมูลในเครื่องของตนเองได้ โดยไม่คำนึงถึงวิธีการเข้ารหัสของเซิร์ฟเวอร์ระยะไกล และนั่นหมายถึงการแปลงข้อมูล โดย อัตโนมัติ

ตัวอย่างเช่น คอมพิวเตอร์เมนเฟรมของ 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 V5.2 และเวอร์ชันที่ใหม่กว่า^{[ 17 ]}
  • ระบบปฏิบัติการเสมือน (VM/SP, VM/ESA)
    • SQL/DS - ไคลเอ็นต์และเซิร์ฟเวอร์ DRDA
  • ดOS/VSE
    • CICS - เซิร์ฟเวอร์ไฟล์บันทึกภายในสภาพแวดล้อมการประมวลผลธุรกรรม CICS เลิกใช้งานใน CICS สำหรับ z/VSE V2.1 และเวอร์ชันต่อมา^{[ 18 ] [ 19 ]}
  • z/OS
    • การจัดการไฟล์แบบกระจาย - เซิร์ฟเวอร์ไฟล์บันทึก
    • ฐานข้อมูล 2 - ไคลเอ็นต์และเซิร์ฟเวอร์ DRDA
• ระบบ/36
  • โปรแกรมสนับสนุนระบบ - บันทึกไฟล์ไคลเอ็นต์และเซิร์ฟเวอร์
• System/38และรุ่นต่อๆ มา ได้แก่ AS/400, iSeries และ Power Series
  • ไฟล์บันทึกข้อมูลไคลเอ็นต์และเซิร์ฟเวอร์
  • ไดเร็กทอรีและสตรีมไฟล์ไคลเอ็นต์และเซิร์ฟเวอร์
  • ไคลเอนต์และเซิร์ฟเวอร์DRDA
• คอมพิวเตอร์ส่วนบุคคล IBM
  • พีซี ดีโอเอส
    • Netview/PC - ไคลเอนต์และเซิร์ฟเวอร์สำหรับจัดการไดเร็กทอรีและสตรีมไฟล์
    • DDM/PC - โปรแกรมจัดการไฟล์ไดเร็กทอรีและสตรีมไฟล์
    • PC Support/36 - ไคลเอนต์ไฟล์ไดเร็กทอรีและสตรีม
    • PC Support/400 - โปรแกรมจัดการไฟล์ไดเร็กทอรีและสตรีมไฟล์
  • ระบบส่วนบุคคล/2 - OS/2
    • PC/Support/400 - สตรีมไฟล์และไดเร็กทอรีทั้งฝั่งไคลเอ็นต์และเซิร์ฟเวอร์
    • ไคลเอนต์และเซิร์ฟเวอร์DRDA
• ระบบจัดเก็บข้อมูล IBM 4680และIBM 4690
  • ไฟล์บันทึกข้อมูลไคลเอ็นต์และเซิร์ฟเวอร์
  • ไดเร็กทอรีและสตรีมไฟล์ไคลเอ็นต์และเซิร์ฟเวอร์
• อาร์เอส/6000 เอไอเอ็กซ์
  • ไคลเอนต์และเซิร์ฟเวอร์DRDA

สำหรับรายชื่อผลิตภัณฑ์ทั้งหมดที่ใช้ DRDA โปรดดูตาราง ตัวระบุผลิตภัณฑ์ DRDA แบบโอเพนซอร์ส

• ระบบไฟล์แบบบันทึกข้อมูล