Dağıtılmış Veri Yönetim Mimarisi - Distributed Data Management Architecture

Dağıtılmış Veri Yönetim Mimarisi (DDM) IBM açık, yayınlandı yazılım mimarisi uzak bilgisayardaki verileri oluşturmak, yönetmek ve bunlara erişmek için. DDM başlangıçta desteklemek için tasarlandı kayıt odaklı dosyalar; desteklemek için genişletildi hiyerarşik dizinler, akış odaklı dosyalar, kuyruklar ve sistem komut işleme; IBM'in temelini oluşturmak için daha da genişletildi Dağıtılmış İlişkisel Veritabanı Mimarisi (DRDA); ve nihayet, destekleyecek şekilde genişletildi veri açıklaması ve dönüştürme. 1980'den 1993'e kadar olan dönemde tanımlanan DDM, tümü şu ilkelere dayalı olarak gerekli bileşenleri, mesajları ve protokolleri belirtir. nesne yönelimi. DDM, kendi başına bir yazılım parçası değildir; DDM'nin uygulanması, istemci ve sunucu ürünleri biçimini alır. Bir açık mimari ürünler DDM mimarisinin alt kümelerini uygulayabilir ve ürünler ek gereksinimleri karşılamak için DDM'yi genişletebilir. Birlikte ele alındığında, DDM ürünleri bir dağıtılmış dosya sistemi.

Medyada DDM Mimarisi.

Dağıtılmış uygulamalar

Dağıtılmış uygulamaların tasarımcıları, iletilecek verilerin miktarı ve sıklığının yanı sıra veri yönetimi, güvenlik ve zamanlılık hususları açısından uygulama programlarının ve verilerinin en iyi yerleşimini belirlemelidir. Üç vardır istemci-sunucu modelleri dağıtılmış uygulamaların tasarımı için:

1. dosya aktarım Protokolü (FTP), yerel olarak çalıştırılabilmeleri için tüm dosyaları veya veritabanı tablolarını her istemciye kopyalar veya taşır. Bu model, her müşterinin ilgili düzenleyicinin bir kopyasına sahip olduğu ve bu tür belgelerin paylaşılmasının genellikle bir sorun olmadığı belge ve elektronik tablo düzenleyicileri gibi yüksek düzeyde etkileşimli uygulamalar için uygundur.
2. Zayıf müşteri uygulamalar bir uygulamanın arayüzünü kullanıcılara sunarken, uygulamanın hesaplama bölümleri etkilenen dosyalar veya veritabanları ile merkezileştirilir. İletişim daha sonra şunlardan oluşur: uzaktan prosedür çağrıları ince istemciler ve benzersiz tasarlanmış mesajların çağrılacak bir yordamı, ilişkili parametrelerini ve döndürülen değerleri belirlediği bir sunucu arasında.
3. Şişman müşteri uygulamalar, tüm uygulama işleme görevlerini istemci sistemler üzerinde gerçekleştirir, ancak veriler, yönetilebilmesi için bir sunucuda merkezileştirilir, böylece herhangi bir yetkili istemci uygulaması tarafından erişilebilir, böylece tüm istemci uygulamaları güncel verilerle çalışır, ve böylece sadece kayıtları bir uygulamadan etkilenen akış bölümleri veya veritabanı tabloları iletilir. İstemci uygulama programları, merkezi verilerle çalışan tüm istemcilere dağıtılmalıdır.

DDM mimarisi, başlangıçta şişman müşteri dağıtık uygulamaların modeli; ayrıca tüm dosya aktarımlarını da destekler.

DDM mimarisinin sağladığı avantajlar

DDM mimarisi, dağıtılmış uygulamalara aşağıdaki faydaları sağlar:^[1]

• Yerel / uzaktan şeffaflık. Uygulama programları, yerel verilerden uzak verilere kolayca yeniden yönlendirilebilir. Uzak sistemlerdeki verilere erişen ve bunları yöneten özel programlara gerek yoktur.
• Azaltılmış veri yedekliliği. Verilerin bir ağda yalnızca bir konumda depolanması gerekir.
• Daha iyi güvenlik. Gereksiz veri kopyalarını ortadan kaldırarak, bir ağdaki verilere erişim yetkili kullanıcılarla daha iyi sınırlandırılabilir.
• Veri bütünlüğü. Eşzamanlı yerel ve uzak kullanıcılar tarafından yapılan güncellemeler, çakışmalar nedeniyle kaybolmaz.
• Daha zamanında bilgi. Bir ağdaki birden fazla bilgisayarın kullanıcıları her zaman en yeni verilere erişebilir.
• Daha iyi kaynak yönetimi. Bir bilgisayar ağının veri depolama ve işleme kaynakları optimize edilebilir.

Tarih

DDM mimarisi, bir bilgisayar ağı boyunca dağıtılan verilerin yönetilmesini ve erişilmesini sağlayan mesajlar ve protokoller için bir dizi özelliktir.^[2]

İlk çabalar

IBM'in Sistem Ağ Mimarisi (SNA) başlangıçta iş istasyonlarının IBM ana bilgisayar bilgisayarlarına hiyerarşik bağlantısını sağlamak için tasarlandı. O sırada mevcut olan iletişim ağları, ana bilgisayar ile tam yazılım kontrolü altında olan bir ana bilgisayar ve onun iş istasyonları grubu arasındaki sabit bağlantılar açısından katı bir şekilde tasarlandı. Ana bilgisayarlar arasındaki diğer iletişimler, belirli amaçlar için tanımlanan yazılımlar tarafından kullanılan sabit bağlantılar anlamındadır. İletişim ağları daha esnek ve dinamik hale geldikçe, genel Eşler arası bir bilgisayardaki bir programın farklı bir bilgisayardaki bir programı başlatabileceği ve onunla etkileşime girebileceği iletişimler arzu edilirdi.

IBM'in SNA'sı İletişim Programlamaya Yönelik Gelişmiş Program (APPC) mimarisi 1980'lerin başında tanımlanmıştı, APPC'nin uzak bilgisayarlarda işletim sistemi hizmetleri sağlamak için kullanılabileceği de açıktı. Bir SNA çalışma grubu bu fikri takip etti ve dosya hizmetleri, yazıcı hizmetleri ve sistem konsolu hizmetleri gibi birkaç olası dağıtılmış hizmetin ana hatlarını çizdi, ancak ürün geliştirmeyi başlatamadı. APPC yazılımı henüz anabilgisayarlarda mevcut değildi ve daha temel olarak, anabilgisayarlar hala birincil olarak bağımsız sistemler olarak görülüyordu. Sonuç olarak, SNA çalışma grubu tarafından dağıtılmış hizmetler üzerindeki çalışma askıya alındı.

IBM'in Rochester, Minnesota geliştirme laboratuvarından SNA çalışma grubunun üyeleri, Rochester'da üretilen orta düzey bilgisayar sistemleri arasında dağıtılmış hizmetler için bir iş vakasının mevcut olduğuna ikna oldu. İlkel bir dağıtılmış dosya hizmetleri biçimi Dağıtılmış Veri Dosyası Tesisi (DDFF), IBM Sistemi / 3, IBM Sistemi / 34, ve IBM Sistemi / 36 mini bilgisayarlar. Dahası, IBM Sistemi / 36 ve IBM Sistemi / 38 bilgisayarlar müşterilere katlar halinde satılıyordu ve örneğin, bir şirketin merkez bilgisayarlarının çeşitli depolarındaki bilgisayarlarla etkileşime girmesini sağlamak için açık bir ihtiyaç vardı. APPC, bu sistemlere uygulandı ve çeşitli müşteri uygulamaları tarafından kullanıldı. Dağıtık işletim sistemi hizmetleri fikri daha sonra altın Kapı proje ve gelişimini haklı çıkarmak için yapılan bir girişim. Bu girişim de başarısız oldu; IBM ürün planlayıcılarının heterojen bilgisayarları birbirine bağlayan yazılımın değerini belirleyebilmesi için dağıtılmış hizmetler fikri tümüyle çok yeniydi.

Ancak, bir altın Kapı Planlamacı John Bondy, yönetimi Rochester laboratuarının normal kontrolü dışında bir departman oluşturmaya ikna etti ve böylece önceden tanımlanmış bir iş vakasına acil ihtiyaç kalmayacaktı. Dahası, misyonunu yalnızca aşağıdakilere desteği içerecek şekilde daralttı: Dağıtık Veri Yönetimi (DDM), özellikle, kayıt odaklı dosyalar. Daha sonra deneyimli bir yazılım mimarı Richard A. Demers'i, DDM mimarisini tanımlama ve DDM fikrini IBM sistem evlerine satma görevlerinde kendisine katılmaya ikna etti.

Bu çabanın ilk yılı, IBM sistem evleri önden iş vakaları talep etmeye devam ettikçe ve yerel dosya sistemlerinin kontrol bloğu arayüzlerine izomorfik mesaj formatlarında ısrar ettikleri için büyük ölçüde sonuçsuz geçti. Ayrıca Kişisel bilgisayarlar ana bilgisayarlara bağlı terminaller olarak kullanılmaya başlandığında, sadece 3270 veri akışı PC'lerin ana bilgisayar verilerine erişmesini sağlar.

Bu dönemde Demers, DDM istemcileri ve sunucularının, bileşenlerinin ve iletişim kuran bilgisayarlar arasındaki etkileşimlerin mimari bir modelini tasarladı. Ayrıca, DDM mesajları için nesne yönelimi ilkelerine dayanan genel bir format tanımladı. Smalltalk programlama dili ve IBM System / 38 tarafından. Bu model, DDM ürünlerinin çeşitli sistemlerde nasıl uygulanabileceğini açıkça ortaya koydu. Görmek DDM nasıl çalışır?.

1982'de, System / 36 planlayıcıları, DDM kayıt odaklı dosya hizmetleri için yeterli bir pazar olduğuna ikna oldu.^[3]

DDM seviye 1: Kayıt odaklı dosyalar

DDM mesajlarının genel biçimi zaten tasarlanmıştı, ancak hangi özel mesajlar tanımlanmalıdır? System / 36 dosya sistemi, üçüncü nesil programlama dillerinin (3GL'ler) kayıt odaklı ihtiyaçlarını karşılamak için tanımlanmıştır. Fortran, COBOL, PL / I, ve IBM RPG ve System / 38 dosya sistemi ve Sanal Depolama Erişim Yöntemi IBM ana bilgisayar bilgisayarlarının (VSAM) dosya sistemi. Yine de, gerçek tesisleri ve arayüzleri önemli ölçüde çeşitlilik gösteriyordu, öyleyse DDM mimarisi hangi tesis ve arayüzleri desteklemelidir? Görmek kayıt odaklı dosyalar.

Tarafından DDM ile ilgili ilk çalışma altın Kapı proje öncülüğünü takip etti Dosya Aktarımı Erişimi ve Yönetimi (FTAM ) dağıtılmış dosyalar için uluslararası standart, ancak çok soyut ve yerel dosya hizmetleriyle eşlenmesi zordu. Aslında bu, IBM sistem evleri tarafından kabul görmenin önündeki engellerden biriydi. System / 36 dosya hizmetlerinden sorumlu sistem mimarı Kenneth Lawrence, en az bir IBM sisteminin kolayca uygulayabileceği mesajları tanımlamanın ve ardından diğer sistemlerin ihtiyaç duydukları değişiklikleri talep etmelerine izin vermenin daha iyi olacağını savundu. Doğal olarak, Sistem / 36 gereksinimlerinin desteklenmesini savundu. DDM fikrini diğer IBM sistem evlerine satmadaki bir yıl başarısız olduktan sonra, Lawrence'ın argümanları galip geldi.

Richard Sanders, DDM mimari ekibine katıldı ve Sistem / 36 DDM için gereken belirli mesajları tanımlamak için Lawrence ve Demers ile birlikte çalıştı. DDM tanımındaki ilerleme, System / 38'i de katılmaya teşvik etti. Bu, DDM kayıt dosyası desteğinin kapsamını, System / 38'in gelişmiş dosya sisteminin gereksinimlerinin çoğunu karşılayacak şekilde genişletti.

Dosyalar, dosyaları düzenlemek, bunları eşzamanlı kullanıcılarla paylaşmak ve onları gereksiz erişimden korumak için hizmetler sağlayan bir işletim sistemi tarafından sağlanan bir bağlamda bulunur. DDM'nin 1. düzeyinde, uzak dosya dizinlerine erişim, kullanılacak dosyanın tam adının iletilmesinin ötesinde desteklenmiyordu. Ancak güvenlik ve paylaşım gerekliydi. Sanders, bu alanlarda tasarım çalışmasını yaptı. Sanders ayrıca, DDM Açıklamalı İletişim Yöneticisi adlı bir bileşene dahil edilen iletişim olanaklarının kullanımına ilişkin özel protokoller tanımladı. Başlangıçta APPC kullanılarak uygulandı, daha sonra kullanılarak uygulandı TCP / IP.

System / 36 DDM ürününün tamamlanmasıyla Lawrence, System / 36 DDM sunucu programlamasının çoğunu IBM'de kullanılmak üzere uyarlamak için İngiltere'deki IBM Hursley Park'taki programcılarla birlikte çalıştı. Müşteri Bilgi Kontrol Sistemi (CICS) işlem işleme ortamı, böylece CICS'i hem MVS hem de VSE ana bilgisayar işletim sistemleri için bir DDM sunucusu haline getirir.^[4] Lawrence ayrıca, IBM Cary, North Carolina laboratuvarından programcılarla birlikte çalışarak DDM kaydı odaklı bir istemciyi IBM PC DOS.

DDM Mimarisinin Seviye 1'i 1986'da resmen yayınlandı. Bu duyuru sırasında IBM, Üstün Teknik Başarı Ödülü Kenneth Lawrence'a Üstün Katkı Ödülü Richard Sanders'a ve bir Üstün Yenilik Ödülü Richard Demers'a.

• Bu makalede, Sistem / 38 Bundan böyle System / 38 ve onun haleflerine atıfta bulunmak için kullanılacaktır: IBM AS / 400 (System / 36 ve System / 38'in işlevselliğini birleştiren), IBM iSeries ve IBM Power Series^[5] (iSeries'i IBM'in RISC / UNIX tabanlı sunucusu ve iş istasyonu ürün grubu olan IBM RS / 6000 ile birleştiren).

DDM düzey 2: Hiyerarşik dizinler ve akış odaklı dosyalar

IBM PC'nin ve Unix işletim sisteminin ağ ortamlarında artan önemi ile birlikte, DDM desteğinin hiyerarşik dizinler ve akış odaklı dosyalar için de gerekli hale geldi. IBM Kişisel Bilgisayar koşma IBM PC DOS ve IBM RS / 6000 koşma IBM AIX (IBM'in Unix sürümü). Görmek Akış odaklı dosyalar.

DDM Mimarisi Seviye 2 1988'de yayınlandı. Jan Fisher ve Sunil Gaitonde dizinler ve akış dosyaları için DDM desteği üzerine mimari çalışmaların çoğunu yaptı.

DDM düzey 3: İlişkisel veritabanı hizmetleri

1986'da IBM, dört farklı ilişkisel veritabanı (RDB) ürünleri, her biri belirli bir IBM işletim sistemi için oluşturulmuştur. IBM'in Almaden Araştırma Laboratuvarı'ndaki bilim adamları, dağıtılmış bir RDB'nin bir prototipi olan System / R * 'yi geliştirdiler ve artık onu pazarlanabilir ürünlere dönüştürme zamanının geldiğini hissettiler. Ancak, System / R *, bir RDB'nin araştırma prototipi olan System / R'ye dayanıyordu ve IBM RDB ürünlerine kolayca eklenemiyordu. Görmek^[6]dağıtılmış bir işlem ortamında RDB'lerin tartışılması için.

IBM Santa Theresa Programlama Merkezi'nden Roger Reinsch, ürünler arası bir ekibin Dağıtılmış İlişkisel Veritabanı Mimarisi (DRDA). O askere gitti:

• Dört IBM RDB ürününün her birinden temsilciler.
• Sistem / R * araştırmacısı Bruce Lindsay,
• Paul Roever (IBM Sindelfingen, Almanya laboratuvarından), Biçimlendirilmiş Veriler: Nesne İçerik Mimarisi (FD: OCA) adlı verileri açıklamak için bir özellik geliştirmiştir.
• DDM mimari ekibinden Richard Sanders ve Richard Demers, uygun modelleri, mesajları ve protokolleri tanımlamak için.

1990'da, DDM Mimarisi Seviye 3 ve DRDA^[7] aynı zamanda yayınlandı. Hem DDM hem de DRDA, IBM'in stratejik bileşenleri olarak belirlenmiştir. Sistem Uygulama Mimarisi (SAA). DRDA, IBM RDB ürünlerinin dördü ve diğer satıcılar tarafından uygulandı.

DRDA'nın tasarımında önemli katılımcılara ödüller verildi. Richard Sanders bir Üstün Katkı Ödülü ve Roger Reinsch ve Richard Demers aldı Üstün İnovasyon Ödülleri.

DDM seviye 4: Ek Hizmetler

Dağıtılmış Dosya Yönetimi (DFM)^[8] Uzak bilgisayarlardaki programların oluşturulması, yönetilmesi ve bunlara erişim sağlanması için IBM'in MVS işletim sistemine DDM hizmetleri eklemek için proje başlatıldı VSAM Dosyalar. DFM projesinin yöneticisi John Hufferd, sistemler arasında akarken kayıtlardaki veri alanlarını dönüştürmek için DDM Mimarisi ekibine baktı. Richard Demers, DFM projesinden Koichi Yamaguchi'nin yardımıyla bu konuda başı çekti. Görmek Veri açıklaması ve dönüştürme.

Aşağıdaki ek hizmetler Richard Sanders, Jan Fisher ve Sunil Gaitonde tarafından Düzey 4'te DDM mimarisinde tanımlanmıştır:

• DFM için, depolama yönetimi ve kullanıcı tanımlı dosya öznitelikleri.
• DRDA için, uygulamaya yönelik dağıtılmış iş birimleri için iki aşamalı taahhüt kontrol protokolleri.
• Uzak bir sunucuda oluşturulabilen, silinebilen veya silinebilen kuyruklar. Kuyruk girişleri, bir kuyruğa eklenen veya kuyruktan alınan uygulama tanımlı kayıtlardır. Görmek DDM Sıraları.
• Bir sunucunun ana bilgisayar sistemi tarafından tanımlanan komutların yürütüldüğü bir Yönetici olan Sistem Komut İşlemcisi, yürütülmek üzere gönderilebilir.
• Birden çok istemci aracısının, istemci ve sunucu sistemleri arasındaki tek bir görüşmeyi kullanarak karşılık gelen sunucu aracılarıyla iletişim kurmasını sağlayan Çoklu Görev İletişim Yöneticisi.
• Senkronizasyon Noktası yöneticisi, birden çok DDM sunucusundaki mantıksal çalışma birimlerini koordine eder. İki aşamalı taahhüt protokolleri, herhangi bir mantıksal çalışma birimi başarısız olduğunda koordineli kaynak kurtarma sağlar.

DDM mimarisi seviye 4, 1992'de yayınlandı.

DDM düzey 5: Kitaplık hizmetleri

DDM düzey 5 üzerindeki mimari çalışması,

• ana bilgisayar Bölümlendirilmiş Veri Kümeleri, bir iç dizinden ve birden çok üyeden oluşan dosyalardır; aslında, benzer dosyaların kitaplıklarıdır.
• Kişisel bilgisayar Kitaplıklar, birden çok klasördeki dosyalara erişimi tek bir kitaplıkta birleştiren.
• DRDA'da daha fazla iyileştirme.

Jan Fisher, tarafından yayınlanan DDM seviye 5'ten sorumlu mimardı. Açık Grup IBM yerine. Kısa bir süre sonra IBM DDM mimari grubu dağıtıldı.

DDM içinde

DDM mimarisi, resmi olarak tanımlanmış ve oldukça yapılandırılmış bir özellikler dizisidir. Bu bölüm, DDM'nin altında yatan temel teknik kavramları tanıtır.^[2]

DDM nasıl çalışır?

DDM mimarisi bir istemci / sunucu protokolünü tanımlar; başka bir deyişle, bir müşteri, talep edilen hizmeti gerçekleştirmek için yerel kaynakları ile etkileşime giren bir sunucudan, sonuçları, verileri ve durum göstergeleri müşteriye döndürülen hizmetler talep eder. Yukarıdaki şema, DDM istemcilerinin ve sunucularının yerel kaynaklarla ilgili rollerini göstermektedir. (Ortak terminoloji müşteriler ve sunucular burada kullanılır, ancak DDM mimarisinde bir istemciye Kaynak Sunucu ve bir Sunucu a Hedef Sunucu.)

1. Bir uygulama programı, bir yerel kaynak yöneticisi (LRM) tarafından sağlanan programlama arabirimleri aracılığıyla bir dosya gibi yerel bir kaynakla etkileşime girer. Ancak istenen kaynak uzak bir bilgisayardaysa, etkileşime aracılık etmek için DDM kullanılır. Uygulama programı, kendi LRM'si tarafından sağlanan arayüzleri kullanmaya devam eder, ancak bunlar bir DDM istemcisine yönlendirilir. DDM mimarisi, uzak kaynaklardan oluşan bir dizini desteklemediğinden, bu yeniden yönlendirmenin nasıl gerçekleşeceğini belirtmez. Birkaç DDM dosya yönelimli ürün tarafından kullanılan yeniden yönlendirme yöntemlerinden biri, uygulamanın a adı verilen özel bir yerel dosyayı açmasını sağlamaktır. DDM Dosyası uzak dosya hakkında konum ve erişim bilgileri sağlayan System / 38 tarafından. DDM İstemcisine yeniden yönlendirme daha sonra gerçekleşir.
2. DDM Mimarisi, dosyalar, ilişkisel veritabanları, erişim yöntemleri, vb. İçin Yönetici düzeyinde varlıkları tanımlar. Bir İstemci Kaynak Yöneticisi (CRM), istemci sistemin LRM'si tarafından tanımlanan işlevsel arabirimleri polimorfik olarak destekler. Birincil işlevi, her bir işlevsel arayüz için uygun doğrusallaştırılmış DDM komutu ve veri nesneleri oluşturmaktır. (Görmek DDM mesajları.) Bu nesneler, uzak DDM sunucusunun sunucu kaynak yöneticisine (SRM) gönderilir. Aslında, DDM istemcisi ve sunucu Aracıları ve İletişim Yöneticileri aracılığıyla yönlendirilirler.
3. DDM İstemci Aracısı, bir RQSDSS zarfına doğrusallaştırılmış bir komut ve bağlantılı OBJDSS zarflarına doğrusallaştırılmış nesneler koyar. (Görmek DDM mesajları.) İstemci Aracısı, CRM'den aldığı mesajların SRM'ye akması için bir yol oluşturmak üzere Sunucu Aracısı ile etkileşime girer. Uygulama programının yalnızca tek bir uzak kaynakla etkileşime girmesi gerekiyorsa, bu basittir. Bununla birlikte, uygulama programının, birden çok uzak sistemde bulunan çeşitli türlerdeki birden çok kaynakla eşzamanlı olarak etkileşime girmesi mümkündür. İstemci Aracısı, her durumda uygulama programını temsil eder ve iletileri her kaynağa ayrı sanal yollarda yönlendirir.
4. İstemci İletişim Yöneticisi, Sunucu İletişim Yöneticisi ile etkileşime girerek "Sen dinlerken konuşurum, sonra ben dinlerken konuşursun" biçiminde bir konuşma protokolü uygular. IBM'in SNA APPC'si ve İnternet'in TCP / IP protokolü dahil olmak üzere çeşitli telekomünikasyon protokolleri kullanılabilir.
5. Sunucu İletişim Yöneticisine iletilen DDM mesajları, mesajla belirtilen yolda Sunucu Aracısına iletilir ve mesajları aynı yol üzerindeki SRM'ye iletir. Sunucu Aracısı tek bir istemciyle tek bir yolda etkileşim halindeyse, bu basittir. Ancak, Sunucu Aracısı birden çok yol üzerinde birden çok istemciyle etkileşime girebilir.
6. Sunucu Kaynak Yöneticisi (SRM), DDM mesajlarını ayrıştırır ve isteği gerçekleştirmek için ne yapması gerektiğini belirler. Sunucu sisteminin karşılık gelen Yerel Kaynak Yöneticisinin (LRM) bir veya daha fazla işlevsel arayüzünü kullanabilir.
7. SRM, verileri ve durum göstergelerini LRM'den toplar ve uygun doğrusallaştırılmış nesneler ve Sunucu Aracısına ilettiği yanıt mesajlarını üretir.
8. Sunucu Aracısı, yanıtları ve nesneleri RPYDSS ve OBJDSS zarfları içinde paketler ve bunları, orijinal komutla aynı yolda Müşteri İletişim Yöneticisine ve İstemci Aracısına gönderen Sunucu İletişim Yöneticisine iletir.
9. Müşteri Aracısı, yanıtı ve nesneleri ilgili RPYDSS ve OBJDSS zarflarından kaldırır ve bunları Müşteri Kaynak Yöneticisine iletir.
10. İstemci Kaynak Yöneticisi, döndürülen nesneyi ayrıştırır ve mesajları yanıtlar ve bunları, uygulama programına geri dönmek için orijinal LRM'nin işlevsel arabiriminden beklendiği gibi eşler.

Nesne yönelimi

DDM mimarisi nesne odaklı. DDM tarafından tanımlanan tüm varlıklar, kendi kendini tanımlayan nesnelerdir Sınıf nesneler. Sistemler arasında akan mesajlar, yanıtlar ve veriler serileştirilmiş nesnelerdir. Her nesne uzunluğunu belirtir, bir DDM kod noktası aracılığıyla sınıfını tanımlar ve kendi sınıfıyla tanımlanan verileri içerir. Ayrıca, sınıfı, bir nesne bir DDM istemcisinde veya sunucusunda bulunduğunda örneklerine gönderilebilen komutları belirtir, böylece nesneyi sınırlı bir işlem kümesi ile sarmalar.

Yapısal olarak, DDM mimarisi nesnelerin hiyerarşik seviyelerinden oluşur, her seviye yeni ortaya çıkan özellikleri giderek daha yüksek seviyelerde gösterir.

• Alan, bir sayı, karakter veya başka bir veri varlığını kodlayan bir bit dizisidir. Bir Field alt sınıfının örnekleri, kendi sınıfı tarafından gerçekleştirilebilen işlemler tarafından kapsüllenir; örneğin, tamsayı alanlarındaki aritmetik işlemler.
• Bir nesne, tanımlanmış bir işlem kümesi tarafından kapsüllenmiş bir veya daha fazla alandan oluşan kendi kendini tanımlayan bir varlıktır. Bu seviyedeki nesnelerden esinlenilen nesnenin çekirdek nesne sınıfları Smalltalk Programlama dili^[9]
  • Skaler bir nesne, nesnenin sınıfı tarafından kodlandığı ve tanımlandığı şekliyle tek bir alandan oluşur. Skaler nesneler, komut ve yanıt nesnelerinin parametre değerleri olarak kullanılır. Ayrıca, DDM belgelerinde bir nesnenin uzunluğu gibi nesne özniteliklerinin değerleri olarak da kullanılırlar. Bu skaler nesnelerin değerleri için kullanılan kodlama yöntemleri, DDM mimarisi tarafından tam olarak tanımlanmıştır.
  • Eşlenen bir nesne, bir uygulama tanımlı kaydın alanları gibi bir veya daha fazla alandan oluşur. Kodlama yöntemleri ve bu alanların hizalanması DDM mimarisi tarafından tanımlanmaz; bunun yerine, uygulama programı bildirim ifadeleri ve programlama dilinin kodlama ve hizalama yöntemleri ile tanımlanır.
  • Koleksiyon nesnesi, koleksiyonun sınıfı tarafından tanımlandığı şekliyle nesneler için bir kapsayıcıdır. Koleksiyon nesnelerine örnek olarak DDM Komutları ve Yanıtları verilebilir.
• Yönetici, nesnelerin depolanması ve işlenmesi için bir ortam sağlayan kendi kendini tanımlayan bir varlıktır. Bir yönetici, kendi sınıfı tarafından tanımlanan işlemlerle özetlenir. Birlikte, bir dizi yönetici, bir DDM istemcisinin veya sunucusunun genel işleme ortamını uygular. Bu seviyedeki yönetici varlıkları, Sistem / 38 işletim sisteminin Sistem Nesnelerinden esinlenmiştir.^[10] DDM tarafından tanımlanan Yöneticiler şunları içerir: Sözlük, Süpervizör, Aracı, Dizin, Dosya (lar), Erişim Yöntemleri, İlişkisel Veritabanı, SQL Uygulama Yöneticisi, Kuyruk, Kilit Yöneticisi, Güvenlik Yöneticisi, Kurtarma Yöneticisi, Sistem Komutu İşlemcisi, İletişim Yöneticisi (s).
• Sunucu, dağıtılmış bir işleme ortamında bir istemci veya sunucu olarak yöneticilerin depolanması ve işlenmesi için bir ortam sağlayan, kendi kendini tanımlayan bir varlıktır. Örnekler, dağıtılmış dosya veya dağıtılmış ilişkisel veritabanı yönetimi için uzmanlaşmış istemciler ve sunuculardır.

DDM mimarisi nesne yönelimliyken, DDM ürünleri, ana bilgisayar sistemlerine özgü diller ve yöntemler kullanılarak uygulanmıştır. IBM PC için DDM'nin Smalltalk sürümü, Nesne Teknolojisi Uluslararası, DDM Referans Kılavuzundan otomatik olarak oluşturulan uygun Smalltalk sınıflarıyla.

Alt kümeler ve uzantılar

DDM açık bir mimaridir. DDM ürünleri, DDM mimarisinin alt kümelerini uygulayabilir; kendi uzantılarını da oluşturabilirler.^[11]

DDM 'Exchange Sunucusu Nitelikleri' komutu, bir istemci bir sunucuya bağlandığında gönderilen ilk komuttur. Müşteriyi tanımlar ve müşterinin ihtiyaç duyduğu yöneticileri ve desteğin gerekli olduğu DDM mimarisi düzeyini belirtir. Sunucu, kendisini tanımlayarak ve istenen yöneticileri hangi düzeyde desteklediğini belirleyerek yanıt verir. Genel bir kural, DDM yöneticisinin X Düzeyini destekleyen bir ürünün, yeni sunucu ürünlerinin daha eski istemci ürünleriyle bağlantı kurması için Düzey X-1'i de desteklemesi gerektiğidir.

DDM'nin alt kümeleri, değişen ürün gereksinimlerini karşılamak için uygulanabilir:

• istemci, sunucu veya her ikisi olarak. Örneğin, DDM / PC yalnızca bir istemcidir, CICS / DDM yalnızca bir sunucudur ve System / 38 DDM hem bir istemci hem de bir sunucudur.
• kayıt odaklı dosyalar, akış yönelimli dosyalar, ilişkisel veritabanları (DRDA'nın bir parçası olarak) veya bunların herhangi bir kombinasyonu gibi belirli yöneticileri desteklemek. Örneğin, MVS Veritabanı 2, yalnızca DRDA tarafından gerekli görülen DDM alt kümesi için istemci ve sunucu desteği sağlar.
• sıralı bir dosyadan kayıtları yükleme ve kaldırma yeteneği gibi yalnızca bir yöneticinin seçilen komutlarını desteklemek için.
• 'Kaydı Al' komutunun 'Etkin Olmayan Kayıtları Döndür' parametresi gibi bir komutun seçilen parametrelerini desteklemek için.

Bir DDM istemcisi bir Sistem / 38 istemcisi gibi bir Sistem / 38 sunucusuna gibi bilinen bir DDM sunucusuna bağlandığında, DDM mimarisi de ekleyerek genişletilebilir.

• yeni ürüne özel yöneticiler.
• mevcut bir DDM yöneticisine yeni komutlar.
• DDM komutuna veya yanıt mesajına yeni parametreler.

Bu tür uzantılar, mevcut DDM mesaj işleme araçlarının kullanılabilmesi için DDM'nin nesne yönelimli çerçevesi içinde tanımlanabilir.

DDM mesajları

DDM'nin tamamen nesne odaklı bir uygulamasında, istemciler ve sunucular ve bunların içerdiği tüm yöneticiler ve nesneler, onları birbirine bağlamak için kullanılan işaretçilerle (bellek adresleri) bir bellek yığınında bulunur. Örneğin, bir komut nesnesi, parametre nesnelerinin her birine işaret eder. Ancak bir istemciden bir sunucuya bu şekilde bir komut iletilemez; komutun izomorfik bir kopyası tek, bitişik bit dizisi olarak oluşturulmalıdır. Yığın içinde bir komut, öbekteki komutun boyutundan, komutun sınıfına bir işaretçiden ve komutun parametre nesnelerinin her birine işaretçilerden oluşur. Doğrusallaştırılmış komut, doğrusallaştırılmış komutun toplam uzunluğundan, komutun sınıfını tanımlayan bir kod noktasından ve her bir doğrusallaştırılmış parametre nesnesinden oluşur. DDM mimarisi, her nesne sınıfına benzersiz kod noktaları atar. Bu basit teknik, istemciler ve sunucular arasında iletilen komutlar, kayıtlar ve yanıt mesajları dahil tüm nesneler için kullanılır.

Tüm bu doğrusallaştırılmış nesneler, istemci ve sunucu aracılarının işlemlerini koordine etmelerini sağlayan zarflara konur. DDM mimarisinde bu zarflara Veri Akışı Yapıları (DSS). Komutlar bir DSS isteyin (RQSDSS), yanıtlar bir DSS'yi yanıtla (RPYDSS) ve diğer nesneler bir Nesne DSS (OBJDS). Bir RQSDSS'de yalnızca bir komut ve RPYDSS'de yalnızca bir yanıt olabilir, ancak kayıtlar gibi birçok nesne bir OBJDSS'ye yerleştirilebilir. Ayrıca birçok OBJDSS, gerektiği kadar çok nesneyi barındırmak için bir RQSDSS veya bir PRYDSS'ye zincirlenebilir. Bir DSS, DSS'nin toplam uzunluğundan, DSS tipini tanımlayan bir bayrak baytından, bir talep tanımlayıcısından ve DSS'deki doğrusallaştırılmış nesnelerden oluşur. İstek tanımlayıcısı, bir RQSDSS'yi istemciden gelen sonraki OBJDSS'ler ile bağlar, örneğin, kullanıcı tarafından bir dosyaya yüklenecek kayıtlar gibi. Dosya yükle komut. Talep tanımlayıcı ayrıca istemciden gelen RQSDSS'yi bir RPYDSS veya sunucudan istemciye OBJDSS ile bağlar.

Dokümantasyon

DDM Referans Kılavuzu^[12][13] adlandırılmış Menü, Yardım ve Sınıf nesnelerinden oluşur. DDM sınıfının alt sınıfları Sınıf belirleyen değişkenlerle tanımlanır

• sınıfın süper sınıfı. Sınıflar, bir miras hiyerarşisi ile tanımlanır; örneğin, Kayıt Dosyası, Yönetici'nin bir alt sınıfı olan ve verilerini ve komutlarını devralan bir Dosya alt sınıfıdır. Sınıf Sınıf ve alt sınıfları kendi kendini tanımlıyor çlass komutları ve sınıf değişkenleri, dahil olmak üzere:
• sınıfı kısaca tanımlayan bir başlık.
• DDM mimarisi üzerinde devam eden çalışmaya göre sınıfın durumu.
• Sınıfı bileşenleri ve çevresiyle ilişkilendiren açıklayıcı metin ve grafikler.
• sınıf örnekleri tarafından kapsüllenen veriler (Alanlar, Nesneler, Yöneticiler vb.).
• örneklerine gönderilebilecek komutlar.

Bu nesneler, metin ve spesifikasyonlarda diğer adlandırılmış nesnelere referanslar içerebilir, böylece köprü metni DDM Referans El Kitabı sayfaları arasındaki bağlantılar. Menü ve Yardım sayfaları, DDM hakkında entegre bir öğretici oluşturur. DDM Referans El Kitabı Seviye 3'ün basılı versiyonu 1400 sayfadan fazla büyüktür ve kullanımı biraz zordur, ancak interaktif bir versiyon da dahili IBM iletişim olanakları kullanılarak oluşturulmuştur. Bu iletişim olanaklarının nispeten düşük hızı göz önüne alındığında, öncelikle IBM Rochester laboratuvarında kullanılıyordu.

DDM Referans Kılavuzuna ek olarak, Genel Bilgi^[1] belge sağlayıcısının DDM ile ilgili yönetici düzeyindeki bilgileri ve bir Programcı Kılavuzu^[11] İstemcileri ve sunucuları uygulayan programcılar için DDM kavramlarını özetler.

DDM dosya modelleri

DDM mimarisi tarafından üç genel dosya modeli tanımlanmıştır: kayıt odaklı dosyalar, akış odaklı dosyalar ve hiyerarşik dizinler.

Aşağıdaki hizmetler, uzak dosyaların yönetimi için DDM mimarisi tarafından sağlanır:

• dosya oluşturma, temizleme ve silme,
• bir dosyanın verilerini kopyalamak, yüklemek ve boşaltmak,
• dosyaları kilitleme ve kilidini açma,
• dosya özniteliklerinin elde edilmesi ve değiştirilmesi,

Kayıt odaklı dosyalar

Kayıt odaklı dosyalar, Fortran, Cobol, PL / I ve RPG gibi üçüncü nesil (3GL) programlama dillerinin veri girişi, çıkışı ve depolama gereksinimlerini karşılamak üzere tasarlanmıştır. Her dilin bu yetenekler için kendi desteğini sağlaması yerine, işletim sistemleri tarafından sağlanan hizmetlere dahil edilmişlerdir.

Bir kayıt tek bir çalışanın adı, adresi, kimlik numarası ve maaşı gibi, her alanın kodlandığı ve bitişik bir bayt dizisine eşlendiği bir dizi ilgili veri alanıdır. İlk bilgisayarların, tipik olarak 80 sütunlu delikli kart yığınları şeklinde veya kağıt veya manyetik bantlar biçiminde sınırlı girdi ve çıktı yetenekleri vardı. Çalışan veri kayıtları gibi uygulama kayıtları, bir seferde sırayla okundu veya yazıldı ve toplu halde işlendi. Doğrudan erişimli depolama aygıtları kullanıma sunulduğunda, programlama dilleri, programların her seferinde bir tane olmak üzere rasgele kayıtlara erişmesi için yollar ekledi, örneğin anahtar alanların değerlerine veya bir dosyadaki bir kaydın konumuna göre erişim. Bir dosyadaki tüm kayıtlar aynı formatta (bir bordro dosyasında olduğu gibi) veya çeşitli formatlarda (bir olay günlüğünde olduğu gibi) olabilir. Bazı dosyalar salt okunurdur, çünkü kayıtları dosyaya yazıldıktan sonra yalnızca okunabilirken, diğer dosyalar kayıtlarının güncellenmesine izin verir.

DDM kaydı odaklı dosya modelleri, oluşturulma tarihi, son güncelleme tarihi, kayıtlarının boyutu ve kayıtların depolanabileceği yuvalar gibi dosya özniteliklerinden oluşur. Kayıtlar, dosyanın kayıtlarını depolamak için kullanılan medyaya bağlı olarak sabit veya değişen uzunlukta olabilir. DDM, dört tür kayıt odaklı dosya tanımlar:

• Kayıtların ardışık yuvalarda depolandığı sıralı dosyalar.
• Bireysel kayıtların, kayıtların bir alanının değerine göre belirlenen dosyanın bir yuvasında depolandığı doğrudan dosyalar.
• Kayıtların ardışık aralıklarda depolandığı ve kayıtlarda bulunan anahtar alanlarının değerlerinin bir dizini aracılığıyla ikincil bir sıranın korunduğu anahtarlı dosyalar.
• Anahtar alanlarının değerlerinin ayrı bir dizininin var olan sıralı, doğrudan veya anahtarlı bir dosyayı temel aldığı alternatif dizin dosyaları.

DDM mimarisi aynı zamanda çeşitli erişim yöntemleri çeşitli şekillerde kayıt odaklı dosyalarla çalışmak için. Erişim yöntemi, istemcinin onu kullanmaya yetkili olup olmadığını belirledikten sonra kendisini dosyaya bağlayan bir OPEN komutu aracılığıyla oluşturulan bir dosyanın kullanımının bir örneğidir. Erişim yönteminin bir dosyadan bağlantısı, CLOSE komutu aracılığıyla kesilir.

Bir erişim yöntemi, bir imleç aracılığıyla halihazırda işlenmekte olan kaydın kaydını tutar. Çeşitli SET komutları kullanılarak, imleç dosyanın başlangıcına veya sonuna, dosyanın sonraki veya önceki sıralı kaydına, belirli bir anahtar değeri olan kayda veya sıralı olarak sonraki veya önceki kaydı gösterecek şekilde yapılabilir. anahtarlarıyla.

Her biri tek bir istemciye hizmet veren birden çok erişim yöntemi örneği, aynı anda bir dosya üzerinde açılabilir. If a file is opened for update access, conflicts can occur when the same record is being accessed by multiple clients. To prevent such conflicts, a lock can be obtained on an entire file. Also, if a file is opened for Güncelleme a lock is obtained on a record by the first client to read it and released when that client updates it. All other clients must wait for the lock's release.

Stream-oriented files

Stream-oriented files consist of a single sequence of bytes on which programs can map application data however they want. Stream files are the primary file model supported by Unix ve Unix benzeri operating systems and by pencereler. DDM defines a single stream file model and a single stream access method.

The DDM stream file model consists of file attributes, such as its creation date and the size of the stream and a continuous stream of bytes. The stream can be accessed by means of the Stream Access Method. Application programs write data onto portions of the stream, even if that data consists of records. They keep track of the location of data items in the stream in any way they want. For example, the data stream of document files is defined by a text processing program such as Microsoft Word and that of a spreadsheet file by a program such as Microsoft Excel.

A Stream access method is an instance of use of a stream file by a single client. A cursor keeps track of the position of the current byte of the sub-stream in use by the client. Using various SET commands, the cursor can be made to point to the beginning or end of the file, to any specific position in the file, or to any positive or negative offset from the current position.

Multiple instances of the Stream access method can be opened on a file at the same time, each serving a single client. If a file is opened for "update" access, conflicts can occur when the same sub-stream is being accessed by multiple clients. To prevent such conflicts, a lock can be obtained on an entire file. Also, if a file is opened for Güncelleme a lock is obtained on a sub-stream by the first client to "read" it and released when that client "updates" it. All other clients must wait for the lock's release.

Hierarchical directories

Hierarchical directories are files whose records each associate a name with a location. A hierarchy occurs when a directory record identifies the name and location of another directory. Using DDM client and server products, a program can create, delete and rename directories in a remote computer. They can also list and change the file attributes of remote directories. The records in a directory can be sequentially read by using the DDM Directory Access Method. The files identified by directory records can be renamed, copied, and moved to a different directory.

DDM queues

Queues are a communication mechanism that enables generally short term communication among programs by means of records. A DDM queue resides in a single system, but it can be accessed by programs on multiple systems. There are three subclasses of DDM queues that can be created on a target system by means of distinct creation commands:

• First-in-first-out queues, an asynchronous pipe between enqueuing and dequeuing programs.
• Last-in-first-out queues, a pushdown stack.
• Keyed queues, a fan-out mechanism where selected entries can be dequeued by key value.

The DDM queue model consists of queue attributes, such as its creation date, the number of records the queue can contain, and the length of the records. The records in a queue can be either fixed or varying length.

Unlike the DDM file models, it is not necessary to open an access method on a queue. Programs can add records to a queue and receive records from a queue as determined by the class of the queue. Programs can also clear records from a queue, stop operations on a queue, list the attributes of a queue, and change the attributes of a queue. Programs can also lock a queue or individual records in a queue to inhibit contention from other programs. All other clients must wait for the lock's release.

İlişkisel veritabanları

Bir ilişkisel veritabanı (RDB) is an implementation of the Yapılandırılmış sorgu dili (SQL) that supports the creation, management, querying, updating, indexing and interrelationships of tables of data. An interactive user or program can issue SQL statements to a RDB and receive tables of data and status indicators in reply. However, SQL statements can also be compiled and stored in the RDB as packages and then invoked by package name. This is important for the efficient operation of application programs that issue complex, high-frequency queries. It is especially important when the tables to be accessed are located in remote systems.

Dağıtılmış İlişkisel Veritabanı Mimarisi (DRDA) fits nicely into the overall DDM framework, as discussed in Object-Orientation. (However, DDM can also be viewed as a component architecture of DRDA since other specifications are also required ^[2]). The DDM manager-level objects supporting DRDA are named RDB (for relational database) and SQLAM (for SQL Application Manager).

Data description and conversion

Transparency is a key objective of DDM architecture. Without recompilation, it should be possible to redirect existing application programs to the data management services of a remote computer. For files, this was largely accomplished by DDM clients at the interface/functional level, but what about the data fields in a record? Complete transparency requires that client application programs be able to write and read fields as encoded by their local data management system, regardless of how any remote server encodes them, and that implies automatic data conversions.

For example, IBM mainframe computers encode floating point numbers in onaltılık format and character data in EBCDIC, while IBM Personal computers encode them in IEEE biçim ve ASCII. Further complexity arose because of the ways in which various programming language compilers map record fields onto strings of bits, bytes, and words in memory. Transparent conversion of a record requires detailed descriptions of both the client view and the server view of a record. Given these descriptions, the fields of the client and server views can be matched, by field name, and appropriate conversions can be performed.

The key issue is obtaining sufficiently detailed record descriptions, but record descriptions are generally specified abstractly in application programs by declaration statements defined by the programming language, with the language compiler handling encoding and mapping details. In a distributed processing environment, what is needed is a single, standardized way of describing records that is independent of all programming languages, one that can describe the wide variety of fixed and varying length record formats found in existing files.

The result was the definition of a comprehensive Data Description and Conversion architecture (DD&C),^[14] based on a new, specialized programming language, A Data Language (ADL),^[15] for describing client and server views of data records and for specifying conversions. Compiled ADL programs can then be called by a server to perform necessary conversions as records flowed to or from the server.

DD&C architecture went further and defined a means by which programming language declaration statements can be automatically converted to and from ADL, and thus from one programming language to another. This capability was never implemented because of its complexity and cost. However, an ADL compiler was created and ADL programs are called, when available, to perform conversions by DFM and by the IBM 4680 Store System.^[16] However, it is necessary for application programmers to manually write the ADL programs.

Implementing products

DDM products by IBM

The following IBM products implemented various subsets of DDM architecture:

• IBM Sistemi / 370
  • MVS (MVS/SP, MVS/ESA)
    • Database 2 - DRDA client and server
    • CICS - record file server within the CICS transaction processing environment. Discontinued in CICS for z/OS V5.2 and later.^[17]
  • VM (işletim sistemi) (VM/SP, VM/ESA)
    • SQL / DS - DRDA client and server
  • DOS / VSE
    • CICS - Record file server within the CICS transaction processing environment. Discontinued in CICS for z/VSE V2.1 and later.^[18][19]
  • z / OS
    • Distributed File management - Record file server
    • Database 2 - DRDA client and server
• Sistem / 36
  • Sistem Destek Programı - Record file client and server
• Sistem / 38 and its successors: AS/400, iSeries, and Power Series
  • Record file client and server
  • Directory and stream file client and server
  • DRDA istemci ve sunucu
• IBM Kişisel Bilgisayar
  • PC DOS
    • Netview/PC - Directory and stream file client and server
    • DDM/PC - Directory and stream file client.
    • PC Support/36 - Directory and stream file client.
    • PC Support/400 - Directory and stream file client.
  • Kişisel Sistem / 2 - OS / 2
    • PC/Support/400 - Stream file and directory client and server
    • DRDA istemci ve sunucu
• IBM 4680 ve IBM 4690 Store Systems
  • Record file client and server
  • Directory and stream file client and server
• RS / 6000 AIX
  • DRDA istemci ve sunucu

DDM products by other vendors

For a complete list of the products that have implemented DRDA, see the Open Source DRDA Product Identifier Table.

Ayrıca bakınız

• Kayıt odaklı dosya sistemi

Referanslar