Arhitectură de gestionare a datelor distribuite - Distributed Data Management Architecture

Distributed Data Management Architecture (DDM) este arhitectura software deschisă, publicată de IBM , pentru crearea, gestionarea și accesarea datelor de pe un computer la distanță. DDM a fost inițial conceput pentru a suporta fișiere orientate spre înregistrări ; a fost extins pentru a suporta directoare ierarhice , fișiere orientate spre flux , cozi și procesarea comenzilor de sistem; a fost extins în continuare pentru a fi baza arhitecturii de baze de date relaționale distribuite (DRDA) IBM ; și în cele din urmă, a fost extins pentru a susține descrierea și conversia datelor . Definit în perioada 1980-1993, DDM specifică componentele, mesajele și protocoalele necesare, toate pe baza principiilor orientării obiectelor . DDM nu este, în sine, un software; implementarea DDM ia forma produselor client și server. Ca arhitectură deschisă , produsele pot implementa subseturi de arhitectură DDM, iar produsele pot extinde DDM pentru a îndeplini cerințe suplimentare. Luate împreună, produsele DDM implementează un sistem de fișiere distribuit .

Image
Arhitectura DDM în mass-media.

Aplicații distribuite

Proiectanții aplicațiilor distribuite trebuie să stabilească cea mai bună plasare a programelor și datelor aplicației în ceea ce privește cantitatea și frecvența datelor care trebuie transmise, împreună cu gestionarea datelor, securitate și considerații de actualitate. Există trei modele client-server pentru proiectarea aplicațiilor distribuite:

  1. Protocolul de transfer de fișiere (FTP) copiază sau mută fișiere întregi sau tabele de baze de date la fiecare client, astfel încât acestea să poată fi operate local. Acest model este adecvat pentru aplicații foarte interactive, cum ar fi editorii de documente și foi de calcul, în care fiecare client are o copie a editorului corespunzător și partajarea acestor documente nu este, în general, o problemă.
  2. Aplicațiile client subțire prezintă interfața unei aplicații utilizatorilor, în timp ce părțile de calcul ale aplicației sunt centralizate cu fișierele sau bazele de date afectate. Comunicarea constă apoi din apeluri de proceduri la distanță între clienții subțiri și un server în care mesajele proiectate unic specifică o procedură de apelat, parametrii asociați și orice valori returnate.
  3. Aplicațiile client fat realizează toate sarcinile de procesare a aplicațiilor pe sistemele client, dar datele sunt centralizate într-un server, astfel încât să poată fi gestionate, astfel încât să poată fi accesate de orice aplicație client autorizată, astfel încât toate aplicațiile client să funcționeze cu actualizări date, astfel încât să fie transmise numai înregistrările , secțiunile de flux sau tabelele bazei de date afectate de o aplicație. Programele de aplicații pentru clienți trebuie distribuite tuturor clienților care lucrează cu datele centralizate.

Arhitectura DDM a fost inițial concepută pentru a susține modelul de client grăsit al aplicațiilor distribuite; acceptă, de asemenea, transferuri de fișiere întregi.

Avantajele oferite de arhitectura DDM

Arhitectura DDM oferă aplicații distribuite cu următoarele avantaje:

  • Transparență locală / la distanță. Programele de aplicații pot fi redirecționate cu ușurință de la date locale la date la distanță. Nu sunt necesare programe specializate care accesează și gestionează date în sistemele la distanță.
  • Redundanță redusă a datelor. Datele trebuie stocate într-o singură locație dintr-o rețea.
  • O securitate mai bună. Prin eliminarea copiilor redundante ale datelor, accesul la datele dintr-o rețea poate fi mai bine limitat la utilizatorii autorizați.
  • Integritatea datelor. Actualizările efectuate de utilizatorii locali și la distanță nu se pierd din cauza conflictelor.
  • Informații mai oportune. Utilizatorii mai multor computere dintr-o rețea au întotdeauna acces la cele mai recente date.
  • O mai bună gestionare a resurselor. Resursele de stocare și procesare a datelor dintr-o rețea de computere pot fi optimizate.

Istorie

Arhitectura DDM este un set de specificații pentru mesaje și protocoale care permit gestionarea și accesarea datelor distribuite pe o rețea de computere.

Eforturile inițiale

Arhitectura rețelei de sistem (SNA) IBM a fost inițial concepută pentru a permite conectarea ierarhică a stațiilor de lucru la computerele mainframe IBM. Rețelele de comunicații disponibile la acea vreme erau proiectate rigid în termeni de conexiuni fixe între un mainframe și suita de stații de lucru, care se aflau sub controlul complet al software-ului computerului mainframe. Alte comunicații între mainframe au fost, de asemenea, în ceea ce privește conexiunile fixe utilizate de software definite în scopuri specifice. Pe măsură ce rețelele de comunicații au devenit mai flexibile și dinamice, erau de dorit comunicațiile generice de la egal la egal , în care un program de pe un computer ar putea iniția și interacționa cu un program de pe un alt computer.

Când arhitectura IBM SNA Advanced Program to Program Communications (APPC) a fost definită la începutul anilor 1980, era de asemenea evident că APPC putea fi utilizat pentru a furniza servicii de sistem de operare pe computere la distanță. Un grup de lucru SNA a urmărit această idee și a subliniat mai multe servicii distribuite posibile, cum ar fi servicii de fișiere, servicii de imprimantă și servicii de consolă de sistem, dar nu a putut iniția dezvoltarea produsului. Software-ul APPC nu era încă disponibil pe mainframe-uri și, mai practic, mainframele erau încă privite în primul rând ca sisteme independente. Drept urmare, lucrul la serviciile distribuite a fost suspendat de grupul de lucru SNA.

Membrii grupului de lucru SNA din laboratorul de dezvoltare Rochester, Minnesota al IBM, au fost convinși că există un caz de afaceri pentru servicii distribuite între sistemele informatice de gamă medie produse în Rochester. O formă primitivă de servicii de fișiere distribuite, numită Distributed Data File Facility (DDFF) a fost implementată pentru a conecta minicomputerele IBM System / 3 , IBM System / 34 și IBM System / 36 . Mai mult, computerele IBM System / 36 și IBM System / 38 erau vândute clienților în multiple și exista o nevoie clară de a permite, de exemplu, computerelor centrale ale unei companii să interacționeze cu computerele din diferitele sale depozite. APPC a fost implementat pe aceste sisteme și utilizat de diferite aplicații ale clienților. Ideea serviciilor de sisteme de operare distribuite a fost apoi reînviată ca proiect Golden Gate și o încercare de a justifica dezvoltarea acestuia. Această încercare a eșuat, de asemenea; întreaga idee a serviciilor distribuite era prea nouă pentru ca planificatorii de produse IBM să poată cuantifica valoarea software-ului care interconecta calculatoare eterogene.

Cu toate acestea, un planificator Golden Gate , John Bondy, a rămas convins și a convins conducerea să creeze un departament în afara controlului normal al laboratorului Rochester, astfel încât să nu fie nevoie imediată de un caz de afaceri predefinit. Mai mult, el și-a restrâns misiunea de a include doar suport pentru gestionarea datelor distribuite (DDM), în special suport pentru fișiere orientate pe înregistrări . Apoi a convins un arhitect de software experimentat, Richard A. Demers, să i se alăture în sarcinile de definire a arhitecturii DDM și vânzarea ideii de DDM către casele de sistem IBM.

Primul an al acestui efort a fost în mare măsură lipsit de rezultate, întrucât casele de sistem IBM au continuat să solicite cazuri de afaceri inițiale și pe măsură ce au insistat asupra formatelor de mesaje isomorfe pentru interfețele de blocuri de control ale sistemelor lor de fișiere locale. Mai mult, pe măsură ce computerele personale au început să fie utilizate ca terminale atașate la computerele mainframe, s-a susținut că îmbunătățirea simplă a fluxului de date 3270 ar permite computerelor să acceseze datele mainframe.

În această perioadă, Demers a proiectat un model arhitectural al clienților și serverelor DDM, al componentelor acestora și al interacțiunilor dintre computerele comunicante. Mai mult, el a definit un format generic pentru mesajele DDM bazat pe principiile orientării obiectelor, așa cum a fost inițiat de limbajul de programare Smalltalk și de IBM System / 38. Acest model a clarificat modul în care produsele DDM ar putea fi implementate pe diferite sisteme. Vedeți cum funcționează DDM .

În 1982, planificatorii System / 36 au devenit convinși că există o piață suficientă pentru serviciile de fișiere orientate către înregistrări DDM.

DDM nivel 1: fișiere orientate spre înregistrare

Formatul generic al mesajelor DDM fusese deja conceput, dar ce mesaje specifice ar trebui definite? Sistemul de fișiere System / 36 a fost definit pentru a satisface nevoile orientate spre înregistrări ale limbajelor de programare a treia generație (3GL), cum ar fi Fortran , COBOL , PL / I și IBM RPG , la fel și sistemul de fișiere System / 38 și Sistem de fișiere Virtual Storage Access Method (VSAM) al computerelor mainframe IBM. Și totuși, facilitățile și interfețele lor reale au variat considerabil, deci ce facilități și interfețe ar trebui să accepte arhitectura DDM? Vedeți fișiere orientate spre înregistrări .

Lucrarea inițială a proiectului Golden Gate asupra DDM a urmat exemplul standardului internațional pentru accesarea și gestionarea transferului de fișiere ( FTAM ) pentru fișierele distribuite, dar a fost foarte abstract și dificil de mapat la serviciile de fișiere locale. De fapt, acesta fusese unul dintre barierele în calea acceptării de către casele sistemului IBM. Kenneth Lawrence, arhitectul de sistem responsabil pentru serviciile de fișiere System / 36, a susținut că ar fi mai bine să definim mesajele pe care cel puțin un sistem IBM le-ar putea implementa cu ușurință și apoi să permită altor sisteme să solicite orice schimbări au nevoie. Bineînțeles, el a susținut sprijinul cerințelor System / 36. După un an de eșec în vânzarea ideii de DDM către alte case de sistem IBM, argumentele lui Lawrence au predominat.

Richard Sanders s-a alăturat echipei de arhitectură DDM și a lucrat cu Lawrence și Demers pentru a defini mesajele specifice necesare pentru System / 36 DDM. Progresele în definirea DDM au încurajat participarea sistemului / 38. Acest lucru a extins domeniul de aplicare al suportului fișierului de înregistrare DDM pentru a îndeplini multe dintre cerințele sistemului avansat de fișiere System / 38.

Fișierele există într-un context furnizat de un sistem de operare care oferă servicii pentru organizarea fișierelor, pentru partajarea acestora cu utilizatorii concurenți și pentru securizarea acestora de accesul nejustificat. La nivelul 1 al DDM, accesul la directoarele de fișiere la distanță nu a fost acceptat dincolo de transmiterea numelui complet calificat al fișierului care urmează să fie utilizat. Cu toate acestea, securitatea și partajarea erau necesare. Sanders a făcut lucrările de proiectare în aceste domenii. Sanders a definit, de asemenea, protocoale specifice privind utilizarea facilităților de comunicații, care au fost încorporate într-o componentă numită DDM Conversational Communications Manager. Implementat inițial utilizând APPC, ulterior a fost implementat folosind TCP / IP .

Odată cu finalizarea produsului System / 36 DDM, Lawrence a lucrat cu programatori de la laboratorul IBM Hursley Park, Marea Britanie pentru a adapta o mare parte din programarea serverului System / 36 DDM pentru utilizare în mediul de procesare a tranzacțiilor IBM Customer Information Control System (CICS), făcând astfel CICS un server DDM atât pentru sistemele de operare mainframe MVS, cât și pentru VSE. Lawrence a lucrat, de asemenea, cu programatori din laboratorul IBM Cary, Carolina de Nord, pentru a implementa un client DDM orientat spre înregistrări pentru IBM PC DOS .

Nivelul 1 al DDM Architecture a fost publicat oficial în 1986. La momentul acestui anunț, IBM i-a acordat un premiu remarcabil pentru realizarea tehnică lui Kenneth Lawrence, un premiu remarcabil pentru contribuția lui Richard Sanders și un premiu remarcabil pentru inovație lui Richard Demers.

  • În acest articol, System / 38 va fi de acum înainte folosit pentru a se referi la System / 38 și la succesorii săi: IBM AS / 400 (care a îmbinat funcționalitatea System / 36 și System / 38), IBM iSeries și IBM Power Series (care a fuzionat iSeries cu IBM RS / 6000, linia de produse pentru server și stație de lucru bazată pe IBM RISC / UNIX).

DDM nivel 2: Directoare ierarhice și fișiere orientate spre flux

Odată cu creșterea importanței IBM PC și a sistemului de operare Unix în mediile de rețea, suportul DDM a fost, de asemenea, necesar pentru directoarele ierarhice și fișierele orientate spre flux ale computerului personal IBM care rulează IBM PC DOS și IBM RS / 6000 care rulează IBM AIX ( Versiunea IBM a Unix). Consultați fișiere orientate spre flux .

DDM Architecture Level 2 a fost publicat în 1988. Jan Fisher și Sunil Gaitonde au făcut cea mai mare parte a lucrărilor de arhitectură pe suport DDM pentru directoare și fișiere de flux.

DDM nivel 3: Servicii de baze de date relaționale

În 1986, IBM a comercializat patru produse diferite de baze de date relaționale (RDB), fiecare construit pentru un sistem de operare IBM specific. Oamenii de știință de la Laboratorul de Cercetare Almaden de la IBM au dezvoltat System / R *, un prototip al unui RDB distribuit și au considerat că este momentul să-l transforme în produse comercializabile. Cu toate acestea, System / R * s-a bazat pe System / R, un prototip de cercetare a unui RDB și nu a putut fi adăugat cu ușurință la produsele IBM RDB. Consultați pentru o discuție despre RDB-uri într-un mediu de procesare distribuit.

Roger Reinsch de la IBM Santa Theresa Programming Center conduce o echipă multiprodus pentru a defini o arhitectură de baze de date relaționale distribuite (DRDA). El s-a înrolat:

  • Reprezentanți din fiecare dintre cele patru produse IBM RDB.
  • Bruce Lindsay, cercetător System / R *,
  • Paul Roever (de la laboratorul IBM Sindelfingen, Germania), care dezvoltase o specificație pentru descrierea datelor numite Formatted Data: Object Content Architecture (FD: OCA).
  • Richard Sanders și Richard Demers din echipa de arhitectură DDM pentru a defini modele, mesaje și protocoale adecvate.

În 1990, DDM Architecture Level 3 și DRDA au fost publicate în același timp. Atât DDM, cât și DRDA au fost desemnate ca componente strategice ale IBM Application Systems Architecture (SAA). DRDA a fost implementat de către toate cele patru produse IBM RDB și de către alți furnizori.

Premiile au fost acordate participanților cheie la proiectarea DRDA. Richard Sanders a primit un Premiu pentru contribuții remarcabile, iar Roger Reinsch și Richard Demers au primit premii pentru inovație remarcabilă .

DDM nivel 4: Servicii suplimentare

Proiectul Distributed File Management (DFM) a fost inițiat pentru a adăuga servicii DDM la sistemul de operare IBM MVS pentru a permite programelor de pe computerele de la distanță să creeze, să gestioneze și să acceseze fișiere VSAM . John Hufferd, managerul proiectului DFM, a căutat către echipa DDM Architecture un mijloc de a converti câmpurile de date în înregistrări pe măsură ce acestea circulau între sisteme. Richard Demers a preluat conducerea acestei probleme, ajutat de Koichi Yamaguchi din proiectul DFM. Consultați Descrierea și conversia datelor .

Următoarele servicii suplimentare au fost definite de Richard Sanders, Jan Fisher și Sunil Gaitonde în arhitectura DDM la nivelul 4:

  • Pentru DFM, gestionarea stocării și atribute de fișiere definite de utilizator.
  • Pentru DRDA, protocoale de control al angajamentului în două faze pentru unități de lucru distribuite direcționate către aplicație.
  • Cozi, care pot fi create, șterse sau șterse pe un server la distanță. Intrările de coadă sunt înregistrări definite de aplicație care sunt adăugate sau primite de la o coadă. Consultați Cozile DDM .
  • System Command Processor, un Manager către care comenzile definite de sistemul gazdă al unui server, pot fi trimise pentru executare.
  • Multi-tasking Communications Manager, care permite mai multor agenți clienți să comunice cu agenții server corespunzători utilizând o singură conversație între sistemele client și server.
  • Managerul de puncte de sincronizare coordonează unitățile logice de lucru în mai multe servere DDM. Protocoalele de angajament în două faze asigură recuperarea coordonată a resurselor atunci când orice unitate logică de lucru eșuează.

Arhitectura DDM nivelul 4 a fost publicată în 1992.

DDM nivel 5: Servicii de bibliotecă

Lucrările de arhitectură la nivelul DDM 5 au constat în suport pentru

  • seturi de date partiționate mainframe , care sunt fișiere constând dintr-un director intern și mai mulți membri; de fapt, acestea sunt biblioteci de fișiere similare.
  • Biblioteci de calculatoare personale , care consolidează accesul la fișiere în mai multe foldere dintr-o singură bibliotecă.
  • îmbunătățiri suplimentare la DRDA.

Jan Fisher a fost arhitectul responsabil pentru DDM nivelul 5, care a fost publicat de Open Group , mai degrabă decât de IBM. La scurt timp după aceea, grupul de arhitectură IBM DDM a fost desființat.

În interiorul DDM

Arhitectura DDM este un set de specificații definite formal și foarte structurate. Această secțiune introduce conceptele tehnice cheie care stau la baza DDM.

Cum funcționează DDM

Prezentare generală a procesării DDM

Arhitectura DDM definește un protocol client / server; adică un client solicită servicii de la un server care interacționează cu resursele sale locale pentru a efectua serviciul solicitat, ale cărui rezultate, date și indicatori de stare, sunt returnate clientului. Diagrama de mai sus ilustrează rolurile clienților și serverelor DDM în raport cu resursele locale. (Terminologia comună a clienților și serverelor este utilizată aici, dar în arhitectura DDM, un client se numește server sursă și un server se numește server țintă .)

  1. Un program de aplicație interacționează cu o resursă locală, cum ar fi un fișier, prin intermediul interfețelor de programare furnizate de un manager de resurse locale (LRM). Dar dacă resursa dorită se află într-un computer la distanță, DDM este utilizat pentru a media interacțiunea. Programul de aplicație continuă să utilizeze interfețele furnizate de LRM, dar acestea sunt redirecționate către un client DDM. Arhitectura DDM nu specifică modul în care trebuie să aibă loc această redirecționare, deoarece nu acceptă un director de resurse la distanță. O metodă de redirecționare utilizată de mai multe produse orientate către fișiere DDM este ca aplicația să deschidă un fișier local special, numit fișier DDM de către Sistem / 38, care oferă informații despre locație și acces despre fișierul de la distanță. Apare apoi redirecționarea către clientul DDM.
  2. Arhitectura DDM definește entități la nivel de Manager pentru fișiere, baze de date relaționale, metode de acces etc. Un Client Resource Manager (CRM) acceptă polimorf interfețele funcționale definite de LRM-ul sistemului client. Funcția sa principală este de a genera comenzi DDM liniarizate adecvate și obiecte de date pentru fiecare interfață funcțională. (A se vedea mesajele DDM .) Aceste obiecte sunt trimise către managerul de resurse server (SRM) al serverului DDM la distanță. De fapt, totuși, acestea sunt direcționate prin intermediul agenților și managerilor de comunicații și server DDM.
  3. Agentul client DDM introduce o comandă liniarizată într-un plic RQSDSS și obiecte liniarizate în plicuri OBJDSS legate. (Consultați mesaje DDM .) Agentul client interacționează cu agentul server pentru a crea o cale pentru ca mesajele pe care le primește de la CRM să fie transmise către SRM. Dacă programul de aplicație trebuie să interacționeze cu o singură resursă la distanță, acest lucru este simplu. Cu toate acestea, este posibil ca programul de aplicație să interacționeze simultan cu mai multe resurse de diferite tipuri care se află pe mai multe sisteme la distanță. Agentul client reprezintă programul aplicației în toate cazurile și direcționează mesajele pe căi virtuale separate către fiecare resursă.
  4. Client Communications Manager interacționează cu ServerCommunications Manager pentru a implementa un protocol de conversație sub forma „Vorbesc în timp ce asculți, iar apoi vorbești în timp ce ascult”. Pot fi utilizate diverse protocoale de telecomunicații, inclusiv SNA APPC IBM și protocolul TCP / IP de pe Internet.
  5. Mesajele DDM transmise către Server Communications Manager sunt transmise Agentului Server pe calea specificată de mesaj și transmite mesajele către SRM pe aceeași cale. Dacă Agentul Server interacționează cu un singur client pe o singură cale, acest lucru este simplu. Cu toate acestea, Agentul Server poate interacționa cu mai mulți clienți pe mai multe căi.
  6. Server Resource Manager (SRM) analizează mesajele DDM și determină ce trebuie să facă pentru a efectua cererea. Poate utiliza una sau mai multe dintre interfețele funcționale ale Managerului de resurse locale (LRM) corespunzător sistemului de server.
  7. SRM acumulează datele și indicatorii de stare din LRM și generează obiecte liniarizate corespunzătoare și mesaje de răspuns, pe care le transmite Agentului server.
  8. Agentul Server împachetează răspunsurile și obiectele în plicuri RPYDSS și OBJDSS și le redirecționează către Server Communication Manager, care le trimite către Client Communication Manager și Client Agent pe aceeași cale ca și comanda inițială.
  9. Agentul client elimină răspunsul și obiectele din plicurile RPYDSS și OBJDSS respective și le transmite Managerului de resurse client.
  10. Managerul de resurse client analizează obiectele returnate și mesajele de răspuns și le mapează așa cum era de așteptat de interfața funcțională originală a LRM pentru a reveni la programul aplicației.

Orientarea obiectului

Arhitectura DDM este orientată obiect . Toate entitățile definite de DDM sunt obiecte definite prin obiecte de clasă auto-definite . Mesajele, răspunsurile și datele care curg între sisteme sunt obiecte serializate. Fiecare obiect își specifică lungimea, își identifică clasa prin intermediul unui punct de cod DDM și conține date definite de clasa sa. Mai mult, clasa sa specifică comenzile care pot fi trimise instanțelor sale atunci când un obiect se află într-un client sau server DDM, încapsulând astfel obiectul printr-un set limitat de operații.

Structural, arhitectura DDM constă în niveluri ierarhice de obiecte, fiecare nivel manifestând proprietăți emergente la niveluri din ce în ce mai înalte.

  • Un câmp este un șir de biți care codifică un număr, un caracter sau o altă entitate de date. Instanțele unei subclase Field sunt încapsulate de operațiile care pot fi efectuate de clasa sa; de exemplu, operații aritmetice pe câmpuri întregi.
  • Un obiect este o entitate care se autoidentifică constând din unul sau mai multe câmpuri încapsulate de un set definit de operații. Obiectele de la acest nivel au fost inspirate din clasele de obiecte ale nucleului din limbajul de programare Smalltalk
    • Un obiect scalar constă dintr-un singur câmp, așa cum este codificat și descris de clasa obiectului. Obiectele scalare sunt utilizate ca valori ale parametrilor obiectelor de comandă și răspuns. Ele sunt, de asemenea, utilizate ca valori ale atributelor obiectului, cum ar fi lungimea unui obiect în documentația DDM. Metodele de codificare utilizate pentru valorile acestor obiecte scalare sunt complet definite de arhitectura DDM.
    • Un obiect mapat constă din unul sau mai multe câmpuri, cum ar fi câmpurile unei înregistrări definite de aplicație. Metodele de codificare și alinierea acestor câmpuri nu sunt definite de arhitectura DDM; în schimb, este definit de declarațiile de declarație a programului de aplicație și de metodele de codificare și aliniere ale limbajului său de programare.
    • Un obiect de colectare este un container pentru obiecte, așa cum este definit de clasa colecției. Exemple de obiecte de colecție sunt comenzile și răspunsurile DDM.
  • Un manager este o entitate de autoidentificare care oferă un mediu pentru stocarea și prelucrarea obiectelor. Un manager este încapsulat de operațiile definite de clasa sa. Împreună, un set de manageri implementează mediul de procesare general al unui client sau server DDM. Entitățile manager de la acest nivel au fost inspirate din obiectele de sistem ale sistemului de operare System / 38. Managerii definiți de DDM includ: Dicționar, Supervizor, Agent, Director, Fișier (e), Metodă (e) de acces, Baza de date relațională, SQL Application Manager, Coadă, Blocare Manager, Security Manager, Recovery Manager, System Command Processor, Communication Manager (s).
  • Un server este o entitate de autoidentificare care oferă un mediu pentru stocarea și procesarea managerilor, fie ca client, fie ca server, într-un mediu de procesare distribuit. Exemple sunt clienții și serverele specializate pentru gestionarea fișierelor distribuite sau a bazelor de date relaționale distribuite.

În timp ce arhitectura DDM este orientată obiect, produsele DDM au fost implementate folosind limbajele și metodele tipice sistemelor lor gazdă. O versiune Smalltalk a DDM a fost dezvoltată pentru IBM PC de către Object Technology International , cu clasele Smalltalk adecvate create automat din Manualul de referință DDM.

Subseturi și extensii

DDM este o arhitectură deschisă. Produsele DDM pot implementa subseturi de arhitectură DDM; își pot crea propriile extensii.

Comanda DDM „Exchange Server Attributes” este prima comandă trimisă atunci când un client este conectat la un server. Identifică clientul și specifică managerii de care are nevoie clientul și nivelul de arhitectură DDM la care este necesar suportul. Serverul răspunde identificându-se și specificând la ce nivel acceptă managerii solicitați. O regulă generală este că un produs care acceptă nivelul X al unui manager DDM trebuie să accepte, de asemenea, nivelul X-1, astfel încât produsele noi pentru server să se conecteze cu produse client mai vechi.

Subseturile DDM pot fi implementate pentru a îndeplini cerințele diferite ale produsului:

  • ca client, server sau ambele. De exemplu, DDM / PC este doar un client, CICS / DDM este doar un server, iar System / 38 DDM este atât un client, cât și un server.
  • pentru a sprijini manageri specifici, cum ar fi fișiere orientate spre înregistrări, fișiere orientate spre flux, baze de date relaționale (ca parte a DRDA) sau orice combinație a acestora. De exemplu, baza de date MVS 2 oferă asistență client și server numai pentru subsetul de DDM cerut de DRDA.
  • pentru a accepta numai comenzile selectate ale unui manager, cum ar fi posibilitatea de a încărca și descărca înregistrări dintr-un fișier secvențial.
  • pentru a accepta parametrii selectați ai unei comenzi, cum ar fi parametrul „Returnare înregistrări inactive” din comanda „Obțineți înregistrarea”.

Când un client DDM este conectat la un server DDM cunoscut, cum ar fi un client System / 38 la un server System / 38, arhitectura DDM poate fi extinsă și prin adăugarea

  • noi manageri specifici produsului.
  • comenzi noi către un manager DDM existent.
  • noi parametri pentru o comandă DDM sau un mesaj de răspuns.

Astfel de extensii pot fi definite în cadrul DDM orientat obiect, astfel încât să poată fi folosite facilitățile de gestionare a mesajelor DDM existente.

Mesaje DDM

Într-o implementare DDM pur orientată spre obiecte, clienții și serverele și toți managerii și obiectele conținute ale acestora există într-o grămadă de memorie, cu indicatori (adrese de memorie) folosite pentru a le interconecta. De exemplu, un obiect de comandă indică către fiecare dintre obiectele parametrilor săi. Dar o comandă nu poate fi transmisă de la un client la un server în acest fel; o copie izomorfă a comenzii trebuie creată ca un șir unic de biți. În heap, o comandă constă din dimensiunea comenzii din heap, un pointer către clasa comenzii și indicatori către fiecare dintre obiectele parametrului comenzii. Linealizată, comanda constă din lungimea totală a comenzii liniarizate, un punct de cod care identifică clasa comenzii și fiecare dintre obiectele sale de parametri liniarizați. Arhitectura DDM atribuie puncte de cod unice fiecărei clase de obiecte. Această tehnică simplă este utilizată pentru toate obiectele transmise între client și servere, inclusiv comenzi, înregistrări și mesaje de răspuns.

Toate aceste obiecte liniarizate sunt puse în plicuri care permit agenților client și server să își coordoneze procesarea. În arhitectura DDM, aceste plicuri se numesc Structuri de flux de date (DSS). Comenzile sunt plasate într-un DSS de solicitare (RQSDSS), răspunsurile sunt plasate într-un DSS de răspuns (RPYDSS), iar alte obiecte sunt plasate într-un DSS obiect (OBJDSS). Nu poate exista o singură comandă într-un RQSDSS și un singur răspuns în RPYDSS, dar multe obiecte, cum ar fi înregistrările, pot fi introduse într-un OBJDSS. Mai multe OBJDS-uri pot fi înlănțuite la un RQSDSS sau un PRYDSS pentru a găzdui cât mai multe obiecte cât este necesar. Un DSS constă din lungimea totală a DSS, un octet de semnalizare care identifică tipul de DSS, un identificator de cerere și obiectele liniarizate din DSS. Identificatorul cererii leagă un RQSDSS cu OBJDSS-uri ulterioare de la client, cum ar fi înregistrările care trebuie încărcate într-un fișier prin comanda Încărcare fișier . Identificatorul cererii leagă, de asemenea, RQSDSS de la client cu un RPYDSS sau OBJDSSes de la server la client.

Documentație

Manualul de referință DDM constă din obiecte denumite Meniu, Ajutor și Clasă. Subclasele clasei DDM Class sunt descrise de variabile care specifică

  • superclasa clasei. Clasele sunt definite de o ierarhie a moștenirii; de exemplu, Înregistrare fișier este o subclasă a fișierului, care este o subclasă a Managerului și care le moștenește datele și comenzile. Clasa Çlass și subclasele sale se autodescrie prin comenzi çlass și variabile de clasă , inclusiv:
  • un titlu care descrie pe scurt clasa.
  • statutul clasei în raport cu lucrările în curs de desfășurare asupra arhitecturii DDM.
  • text descriptiv și grafică care leagă clasa de componentele sale și de mediul său.
  • datele (câmpuri, obiecte, manageri etc.) încapsulate de instanțe ale clasei.
  • comenzile care pot fi trimise instanțelor sale.

Aceste obiecte pot conține referințe la alte obiecte denumite în text și specificații, creând astfel legături hipertext între paginile Manualului de referință DDM. Paginile Meniu și Ajutor formează un tutorial integrat despre DDM. Versiunea pe hârtie a Manualului de referință DDM Nivelul 3 este voluminoasă, la peste 1400 de pagini, și oarecum incomodă de utilizat, dar o versiune interactivă a fost, de asemenea, construită folosind facilități de comunicare IBM interne. Având în vedere viteza relativ lentă a acestor facilități de comunicații, a fost în primul rând utilă în cadrul laboratorului IBM Rochester.

În plus față de Manualul de referință DDM, un document cu informații generale oferă informații la nivel executiv despre DDM, iar un ghid al programatorului rezumă conceptele DDM pentru programatorii care implementează clienți și servere.

Modele de fișiere DDM

Trei modele generale de fișiere sunt definite de arhitectura DDM: fișiere orientate spre înregistrări, fișiere orientate spre flux și directoare ierarhice.

Următoarele servicii sunt furnizate de arhitectura DDM pentru gestionarea fișierelor la distanță:

  • crearea, ștergerea și ștergerea fișierelor,
  • copierea, încărcarea și descărcarea datelor unui fișier,
  • blocarea și deblocarea fișierelor,
  • obținerea și modificarea atributelor fișierului,

Fișiere orientate spre înregistrare

Fișierele orientate spre înregistrări au fost proiectate pentru a îndeplini cerințele de intrare, ieșire și stocare a datelor ale limbajelor de programare a treia generație (3GL), cum ar fi Fortran, Cobol, PL / I și RPG. În loc să ofere fiecărei limbi un suport propriu pentru aceste capacități, acestea au fost încorporate în serviciile furnizate de sistemele de operare.

O înregistrare este o serie de câmpuri de date conexe, cum ar fi numele, adresa, numărul de identificare și salariul unui singur angajat, în care fiecare câmp este codificat și mapat la un șir contigu de octeți. Primele computere aveau capacități limitate de intrare și ieșire, de obicei sub formă de stive de 80 de coloane perforate sau sub formă de hârtie sau benzi magnetice. Înregistrările aplicațiilor, cum ar fi înregistrările datelor angajaților, au fost citite sau scrise secvențial o înregistrare la un moment dat și procesate în loturi. Când dispozitivele de stocare cu acces direct au devenit disponibile, limbajele de programare au adăugat căi pentru ca programele să acceseze aleatoriu înregistrările pe rând, cum ar fi accesul prin valorile câmpurilor cheie sau prin poziția unei înregistrări într-un fișier. Toate înregistrările dintr-un fișier pot fi de același format (ca într-un fișier de salarizare) sau cu diferite formate (ca într-un jurnal de evenimente). Unele fișiere sunt doar în citire, deoarece înregistrările lor, odată scrise în fișier, pot fi citite numai, în timp ce alte fișiere permit actualizarea înregistrărilor lor.

Modelele de fișiere orientate către înregistrări DDM constau din atribute de fișiere, cum ar fi data creării sale, data ultimei actualizări, dimensiunea înregistrărilor sale și spațiile în care pot fi stocate înregistrările. Înregistrările pot avea o lungime fixă ​​sau variabilă, în funcție de suportul utilizat pentru stocarea înregistrărilor fișierului. DDM definește patru tipuri de fișiere orientate spre înregistrare:

  • Fișiere secvențiale, în care înregistrările sunt stocate în sloturi consecutive.
  • Fișiere directe, în care înregistrările individuale sunt stocate într-un spațiu al fișierului determinat de valoarea unui câmp al înregistrărilor.
  • Fișiere cheie, în care înregistrările sunt stocate în sloturi consecutive și pentru care este menținută o ordine secundară prin intermediul unui index al valorilor câmpurilor cheie conținute în înregistrări.
  • Fișiere index alternative, în care un index separat al valorilor câmpurilor cheie se bazează pe un fișier secvențial, direct sau cu cheie existent.

Arhitectura DDM definește, de asemenea, o varietate de metode de acces pentru lucrul cu fișiere orientate spre înregistrări în diferite moduri. O metodă de acces este o instanță a utilizării unui fișier creat prin intermediul unei comenzi OPEN care se conectează la fișier după ce a stabilit dacă clientul este autorizat să îl folosească. Metoda de acces este deconectată de la un fișier prin intermediul unei comenzi CLOSE.

O metodă de acces ține evidența înregistrării procesate în prezent prin intermediul unui cursor. Folosind diferite comenzi SET, cursorul poate fi făcut să indice spre începutul sau sfârșitul fișierului, către înregistrarea secvențială următoare sau anterioară a fișierului, către înregistrarea cu o anumită valoare a cheii sau către înregistrarea următoare sau anterioară, așa cum a fost comandat după cheile lor.

Mai multe instanțe de metode de acces pot fi deschise simultan pe un fișier, fiecare servind un singur client. Dacă un fișier este deschis pentru acces la actualizare, pot apărea conflicte atunci când aceeași înregistrare este accesată de mai mulți clienți. Pentru a preveni astfel de conflicte, se poate obține o blocare pe un întreg fișier. De asemenea, dacă un fișier este deschis pentru actualizare, un blocaj este obținut într-o înregistrare de către primul client care l-a citit și eliberat atunci când clientul respectiv îl actualizează. Toți ceilalți clienți trebuie să aștepte eliberarea încuietorii.

Fișiere orientate spre flux

Fișierele orientate spre flux constau dintr-o singură secvență de octeți pe care programele pot mapa datele aplicației oricum doresc. Fișierele în flux sunt principalul model de fișiere acceptat de sistemele de operare Unix și similare Unix și de Windows . DDM definește un singur model de fișier de flux și o singură metodă de acces la flux.

Modelul de fișier de flux DDM constă din atribute de fișiere, cum ar fi data creării sale și dimensiunea fluxului și un flux continuu de octeți. Fluxul poate fi accesat prin intermediul metodei de acces la flux. Programele de aplicații scriu date pe porțiuni ale fluxului, chiar dacă aceste date constau din înregistrări. Ei urmăresc locația articolelor de date în flux în orice mod doresc. De exemplu, fluxul de date al fișierelor document este definit de un program de procesare a textului, cum ar fi Microsoft Word și de cel al unui fișier foaie de calcul de către un program precum Microsoft Excel .

O metodă de acces la flux este o instanță de utilizare a unui fișier de flux de către un singur client. Un cursor ține evidența poziției octetului curent al sub-fluxului utilizat de client. Folosind diferite comenzi SET, cursorul poate fi făcut să indice spre începutul sau sfârșitul fișierului, către orice poziție specifică din fișier sau către orice decalaj pozitiv sau negativ față de poziția curentă.

Mai multe instanțe ale metodei de acces Stream pot fi deschise simultan pe un fișier, fiecare servind un singur client. Dacă este deschis un fișier pentru acces „actualizat”, pot apărea conflicte atunci când același sub-flux este accesat de mai mulți clienți. Pentru a preveni astfel de conflicte, se poate obține o blocare pe un întreg fișier. De asemenea, dacă un fișier este deschis pentru actualizare, o primire de blocare este obținută pe un sub-flux de către primul client care îl „citește” și se eliberează atunci când acel client îl „actualizează”. Toți ceilalți clienți trebuie să aștepte eliberarea încuietorii.

Directoare ierarhice

Directoarele ierarhice sunt fișiere ale căror înregistrări asociază fiecare un nume cu o locație. O ierarhie apare atunci când o înregistrare de director identifică numele și locația altui director. Folosind produsele DDM client și server, un program poate crea, șterge și redenumi directoare pe un computer la distanță. De asemenea, pot lista și modifica atributele de fișiere ale directoarelor la distanță. Înregistrările dintr-un director pot fi citite secvențial utilizând metoda DDM Directory Access. Fișierele identificate de înregistrările din director pot fi redenumite, copiate și mutate într-un alt director.

Cozi DDM

Cozile sunt un mecanism de comunicare care permite în general comunicarea pe termen scurt între programe prin intermediul înregistrărilor. O coadă DDM se află într-un singur sistem, dar poate fi accesată de programe pe mai multe sisteme. Există trei subclase de cozi DDM care pot fi create pe un sistem țintă prin intermediul unor comenzi de creație distincte:

  • Cozi First-in-First-Out, o conductă asincronă între programele de stingere și stergere.
  • Cozile Last-in-First-Out, o stivă pushdown.
  • Cozi cu chei, un mecanism de fan-out în care intrările selectate pot fi stinse prin valoarea cheii.

Modelul de coadă DDM constă din atribute de coadă, cum ar fi data creării sale, numărul de înregistrări pe care le poate conține coada și lungimea înregistrărilor. Înregistrările dintr-o coadă pot fi fixe sau cu lungime variabilă.

Spre deosebire de modelele de fișiere DDM, nu este necesar să deschideți o metodă de acces pe o coadă. Programele pot adăuga înregistrări la o coadă și pot primi înregistrări dintr-o coadă, așa cum este determinat de clasa cozii. Programele pot, de asemenea, să șteargă înregistrările dintr-o coadă, să oprească operațiile pe o coadă, să enumere atributele unei cozi și să schimbe atributele unei cozi. Programele pot, de asemenea, să blocheze o coadă sau înregistrări individuale într-o coadă pentru a inhiba contestația din alte programe. Toți ceilalți clienți trebuie să aștepte eliberarea încuietorii.

Baze de date relaționale

O bază de date relațională (RDB) este o implementare a Structured Query Language (SQL) care susține crearea, gestionarea, interogarea, actualizarea, indexarea și relațiile de tabele de date. Un utilizator sau un program interactiv poate emite instrucțiuni SQL către un RDB și poate primi tabele cu date și indicatori de stare ca răspuns. Cu toate acestea, instrucțiunile SQL pot fi de asemenea compilate și stocate în RDB ca pachete și apoi invocate după numele pachetului. Acest lucru este important pentru funcționarea eficientă a programelor de aplicații care emit interogări complexe, de înaltă frecvență. Este deosebit de important atunci când mesele care urmează să fie accesate sunt amplasate în sisteme la distanță.

Distributed Relational Database Architecture (DRDA) se potrivește bine în cadrul general DDM, așa cum sa discutat în obiect-orientare . (Cu toate acestea, DDM poate fi privit și ca o arhitectură componentă a DRDA, deoarece sunt necesare și alte specificații). Obiectele la nivel de manager DDM care acceptă DRDA se numesc RDB (pentru baza de date relațională) și SQLAM (pentru SQL Application Manager).

Descrierea și conversia datelor

Transparența este un obiectiv cheie al arhitecturii DDM. Fără recompilare, ar trebui să fie posibilă redirecționarea programelor de aplicații existente către serviciile de gestionare a datelor de pe un computer la distanță. Pentru fișiere, acest lucru a fost realizat în mare parte de clienții DDM la nivel de interfață / funcțional, dar ce rămâne cu câmpurile de date dintr-o înregistrare? Transparența completă necesită ca programele de aplicații client să poată scrie și citi câmpuri așa cum sunt codificate de sistemul lor local de gestionare a datelor, indiferent de modul în care le codifică orice server de la distanță și asta implică conversii automate de date .

De exemplu, computerele mainframe IBM codifică numere în virgulă mobilă în format hexazecimal și date de caractere în EBCDIC , în timp ce computerele IBM Personal le codifică în format IEEE și ASCII . O complexitate suplimentară a apărut din cauza modurilor în care diferiți compilatori de limbaj de programare mapează câmpurile de înregistrare pe șiruri de biți, octeți și cuvinte din memorie. Conversia transparentă a unei înregistrări necesită descrieri detaliate atât a vizualizării clientului, cât și a vizualizării serverului unei înregistrări. Având în vedere aceste descrieri, câmpurile vizualizărilor client și server pot fi asortate, după numele câmpului și pot fi efectuate conversii adecvate.

Problema cheie este obținerea unor descrieri de înregistrări suficient de detaliate, dar descrierile de înregistrări sunt, în general, specificate abstract în programele de aplicație prin declarații de declarație definite de limbajul de programare, cu compilatorul de limbaj care gestionează detaliile de codare și mapare. Într-un mediu de procesare distribuit, este necesar un mod unic, standardizat de descriere a înregistrărilor, care este independent de toate limbajele de programare, unul care poate descrie marea varietate de formate de înregistrări cu lungime fixă ​​și variabilă, găsite în fișierele existente.

Rezultatul a fost definirea unei arhitecturi cuprinzătoare de descriere și conversie a datelor (DD&C), bazată pe un nou limbaj de programare specializat, A Data Language (ADL), pentru descrierea vizualizărilor clientului și serverului înregistrărilor de date și pentru specificarea conversiilor. Programele ADL compilate pot fi apoi apelate de un server pentru a efectua conversiile necesare pe măsură ce înregistrările au fost trimise către sau de la server.

Arhitectura DD&C a mers mai departe și a definit un mijloc prin care declarațiile de declarație a limbajului de programare pot fi convertite automat în și de la ADL, și astfel de la un limbaj de programare la altul. Această capacitate nu a fost niciodată implementată datorită complexității și costurilor sale. Cu toate acestea, a fost creat un compilator ADL și programele ADL sunt chemate, atunci când sunt disponibile, pentru a efectua conversii de către DFM și de sistemul de stocare IBM 4680. Cu toate acestea, este necesar ca programatorii de aplicații să scrie manual programele ADL.

Implementarea produselor

Produse DDM de IBM

Următoarele produse IBM au implementat diverse subseturi de arhitectură DDM:

  • IBM System / 370
    • MVS (MVS / SP, MVS / ESA)
      • Baza de date 2 - client și server DRDA
      • CICS - server de fișiere de înregistrare în mediul de procesare a tranzacțiilor CICS. Întrerupt în CICS pentru z / OS V5.2 și versiuni ulterioare.
    • VM (sistem de operare) (VM / SP, VM / ESA)
    • DOS / VSE
      • CICS - Înregistrați serverul de fișiere în mediul de procesare a tranzacțiilor CICS. Întrerupt în CICS pentru z / VSE V2.1 și versiuni ulterioare.
    • z / OS
      • Gestionare distribuită a fișierelor - Înregistrați serverul de fișiere
      • Baza de date 2 - client și server DRDA
  • Sistem / 36
  • System / 38 și succesorii săi: AS / 400, iSeries și Power Series
    • Înregistrați fișierul client și server
    • Director și flux fișier client și server
    • Client și server DRDA
  • Computer personal IBM
    • PC DOS
      • Netview / PC - Director și flux fișier client și server
      • DDM / PC - Director de fișiere client și flux.
      • Suport PC / 36 - Director de fișiere client și flux.
      • Suport PC / 400 - Director de fișiere și flux client.
    • Personal System / 2 - OS / 2
      • PC / Support / 400 - Fișier flux și director client și server
      • Client și server DRDA
  • IBM 4680 și IBM 4690 Store Systems
    • Înregistrați fișierul client și server
    • Director și flux fișier client și server
  • RS / 6000 AIX
    • Client și server DRDA

Produse DDM de la alți furnizori

Pentru o listă completă a produselor care au implementat DRDA, consultați Tabelul de identificare a produsului Open Source DRDA .

Vezi si

Referințe