Architectuur voor gedistribueerd gegevensbeheer - Distributed Data Management Architecture

Distributed Data Management Architecture (DDM) is IBM 's open, gepubliceerde software-architectuur voor het creëren, beheren en openen van gegevens op een externe computer. DDM is oorspronkelijk ontworpen om record-georiënteerde bestanden te ondersteunen ; het werd uitgebreid om hiërarchische mappen , stream-georiënteerde bestanden , wachtrijen en systeemopdrachtverwerking te ondersteunen; het werd verder uitgebreid tot de basis van IBM's Distributed Relational Database Architecture (DRDA); en ten slotte werd het uitgebreid om gegevensbeschrijving en -conversie te ondersteunen . Gedefinieerd in de periode van 1980 tot 1993, specificeert DDM noodzakelijke componenten, berichten en protocollen, allemaal gebaseerd op de principes van object-oriëntatie . DDM is op zich geen stukje software; de implementatie van DDM neemt de vorm aan van client- en serverproducten. Als open architectuur kunnen producten subsets van DDM-architectuur implementeren en producten kunnen DDM uitbreiden om aan aanvullende vereisten te voldoen. Alles bij elkaar genomen implementeren DDM-producten een gedistribueerd bestandssysteem .

Gedistribueerde applicaties

De ontwerpers van gedistribueerde toepassingen moeten de beste plaatsing van de programma's en gegevens van de toepassing bepalen in termen van de hoeveelheid en frequentie van de gegevens die moeten worden verzonden, samen met gegevensbeheer, beveiliging en tijdigheidsoverwegingen. Er zijn drie client-servermodellen voor het ontwerp van gedistribueerde toepassingen:

1. File Transfer Protocol (FTP) kopieert of verplaatst hele bestanden of databasetabellen naar elke client, zodat ze lokaal kunnen worden gebruikt. Dit model is geschikt voor zeer interactieve toepassingen, zoals document- en spreadsheeteditors, waarbij elke klant een kopie van de bijbehorende editor heeft en het delen van dergelijke documenten over het algemeen geen probleem is.
2. Thin client- applicaties presenteren de interface van een applicatie aan gebruikers, terwijl de computationele delen van de applicatie worden gecentraliseerd met de betrokken bestanden of databases. De communicatie bestaat dan uit procedureaanroepen op afstand tussen de thin clients en een server waarin uniek ontworpen berichten een procedure specificeren die moet worden aangeroepen, de bijbehorende parameters en eventuele geretourneerde waarden.
3. Fat client- applicaties voeren alle applicatieverwerkingstaken uit op clientsystemen, maar de gegevens worden gecentraliseerd op een server zodat ze kunnen worden beheerd, zodat ze toegankelijk zijn voor elke geautoriseerde clientapplicatie, zodat alle clientapplicaties werken met up-to-date gegevens, en zodat alleen de records , stroomsecties of databasetabellen die door een toepassing worden beïnvloed, worden verzonden. Clienttoepassingsprogramma's moeten worden gedistribueerd naar alle clients die met de gecentraliseerde gegevens werken.

De DDM-architectuur was oorspronkelijk ontworpen om het fat client- model van gedistribueerde applicaties te ondersteunen; het ondersteunt ook de overdracht van hele bestanden.

Voordelen van DDM-architectuur

De DDM-architectuur biedt gedistribueerde applicaties met de volgende voordelen:

• Transparantie ter plaatse/op afstand. Applicatieprogramma's kunnen eenvoudig worden omgeleid van lokale gegevens naar gegevens op afstand. Gespecialiseerde programma's voor toegang tot en beheer van gegevens in externe systemen zijn niet nodig.
• Verminderde gegevensredundantie. Gegevens hoeven maar op één locatie in een netwerk te worden opgeslagen.
• Betere beveiliging. Door overbodige kopieën van gegevens te elimineren, kan de toegang tot de gegevens in een netwerk beter worden beperkt tot geautoriseerde gebruikers.
• Data-integriteit. Updates door gelijktijdige lokale en externe gebruikers gaan niet verloren door conflicten.
• Meer actuele informatie. Gebruikers van meerdere computers in een netwerk hebben altijd toegang tot de meest recente gegevens.
• Beter middelenbeheer. De gegevensopslag en verwerkingsbronnen van een netwerk van computers kunnen worden geoptimaliseerd.

Geschiedenis

DDM-architectuur is een reeks specificaties voor berichten en protocollen waarmee gegevens die via een netwerk van computers zijn verspreid, kunnen worden beheerd en geopend.

eerste inspanningen

IBM's Systems Network Architecture (SNA) was oorspronkelijk ontworpen om de hiërarchische verbinding van werkstations met IBM-mainframecomputers mogelijk te maken. De destijds beschikbare communicatienetwerken waren strak ontworpen in termen van vaste verbindingen tussen een mainframe en zijn reeks werkstations, die onder de volledige softwarecontrole van de mainframecomputer stonden. Andere communicatie tussen mainframes was ook in termen van vaste verbindingen die werden gebruikt door software die voor specifieke doeleinden was gedefinieerd. Naarmate communicatienetwerken flexibeler en dynamischer werden, was generieke peer-to-peercommunicatie wenselijk, waarbij een programma op de ene computer een programma op een andere computer kon initiëren en ermee kon interageren.

Toen IBM's SNA Advanced Program to Program Communications (APPC)-architectuur begin jaren tachtig werd gedefinieerd, was het ook duidelijk dat APPC kon worden gebruikt om besturingssysteemservices op externe computers te leveren. Een SNA-werkgroep volgde dit idee en schetste verschillende mogelijke gedistribueerde services, zoals bestandsservices, printerservices en systeemconsoleservices, maar kon de productontwikkeling niet starten. APPC-software was nog niet beschikbaar op mainframes en, meer in het algemeen, werden mainframes nog voornamelijk als stand-alone systemen gezien. Als gevolg hiervan werden de werkzaamheden aan gedistribueerde diensten door de SNA-werkgroep opgeschort.

Leden van de SNA-werkgroep van IBM's ontwikkelingslaboratorium in Rochester, Minnesota waren ervan overtuigd dat er een businesscase bestond voor gedistribueerde diensten voor de middelgrote computersystemen die in Rochester werden geproduceerd. Een primitieve vorm van gedistribueerde bestandsservices, Distributed Data File Facility (DDFF) genaamd, was geïmplementeerd om de IBM System/3- , IBM System/34- en IBM System/36- minicomputers met elkaar te verbinden . Verder werden de computers IBM System/36 en IBM System/38 in veelvouden aan klanten verkocht en bestond er een duidelijke behoefte om bijvoorbeeld de computers op het hoofdkantoor van een bedrijf in staat te stellen te communiceren met de computers in de verschillende magazijnen. Op deze systemen is APPC geïmplementeerd en door verschillende klantapplicaties gebruikt. Het idee van gedistribueerde besturingssysteemdiensten werd vervolgens nieuw leven ingeblazen als het Golden Gate- project en een poging om de ontwikkeling ervan te rechtvaardigen. Ook deze poging mislukte; het hele idee van gedistribueerde diensten was te nieuw voor IBM-productplanners om de waarde te kunnen kwantificeren van software die heterogene computers met elkaar verbond.

Een Golden Gate- planner, John Bondy, bleef echter overtuigd en overtuigde het management om een ​​afdeling op te richten buiten de normale controle van het Rochester-laboratorium, zodat er niet onmiddellijk een vooraf gedefinieerde businesscase nodig zou zijn. Verder beperkte hij zijn missie om alleen ondersteuning voor Distributed Data Management (DDM) op te nemen, in het bijzonder ondersteuning voor record-georiënteerde bestanden . Vervolgens overtuigde hij Richard A. Demers, een ervaren softwarearchitect, om samen met hem de DDM-architectuur te definiëren en het idee van DDM te verkopen aan de IBM-systeemhuizen.

Het eerste jaar van deze inspanning was grotendeels vruchteloos omdat de IBM-systeemhuizen vooraf businesscases bleven eisen en omdat ze aandrongen op berichtformaten die gelijkvormig waren aan de besturingsblokinterfaces van hun lokale bestandssystemen. Verder, toen personal computers begonnen te worden gebruikt als terminals die waren aangesloten op mainframecomputers, werd beweerd dat het eenvoudigweg verbeteren van de 3270-gegevensstroom pc's in staat zou stellen toegang te krijgen tot mainframe-gegevens.

Tijdens deze periode ontwierp Demers een architectonisch model van DDM-clients en -servers, van hun componenten en van interacties tussen communicerende computers. Verder definieerde hij een generiek formaat voor DDM-berichten op basis van de principes van objectoriëntatie zoals ontwikkeld door de Smalltalk- programmeertaal en door de IBM System/38. Dit model maakte duidelijk hoe DDM-producten op verschillende systemen konden worden geïmplementeerd. Zie Hoe DDM werkt .

In 1982 raakten de planners van System/36 ervan overtuigd dat er voldoende markt was voor DDM-recordgerichte bestandsservices.

DDM-niveau 1: Record-georiënteerde bestanden

Het generieke formaat van DDM-berichten was al ontworpen, maar welke specifieke berichten moeten worden gedefinieerd? Het System/36-bestandssysteem was gedefinieerd om te voldoen aan de recordgerichte behoeften van programmeertalen van de derde generatie (3GL's), zoals Fortran , COBOL , PL/I en IBM RPG , en dat gold ook voor het System/38-bestandssysteem en de Virtual Storage Access Method (VSAM) bestandssysteem van de IBM-mainframecomputers. En toch varieerden hun feitelijke faciliteiten en interfaces aanzienlijk, dus welke faciliteiten en interfaces zouden de DDM-architectuur moeten ondersteunen? Zie record-georiënteerde bestanden .

Het eerste werk aan DDM door het Golden Gate- project had het voorbeeld gevolgd van de internationale standaard voor File Transfer Access and Management ( FTAM ) voor gedistribueerde bestanden, maar het was erg abstract en moeilijk toe te wijzen aan lokale bestandsservices. In feite was dit een van de belemmeringen voor acceptatie door de IBM-systeemhuizen. Kenneth Lawrence, de systeemarchitect die verantwoordelijk is voor System/36-bestandsservices, betoogde dat het beter zou zijn om berichten te definiëren die gemakkelijk door ten minste één IBM-systeem kunnen worden geïmplementeerd, en dat andere systemen vervolgens de gewenste wijzigingen kunnen aanvragen. Uiteraard pleitte hij voor ondersteuning van System/36-vereisten. Nadat het een jaar lang niet was gelukt om het idee van DDM aan andere IBM-systeemhuizen te verkopen, kregen de argumenten van Lawrence de overhand.

Richard Sanders voegde zich bij het DDM-architectuurteam en werkte samen met Lawrence en Demers om de specifieke berichten te definiëren die nodig waren voor System/36 DDM. Vooruitgang in de definitie van DDM moedigde System/38 aan om ook deel te nemen. Dit verbreedde de reikwijdte van de ondersteuning van DDM-recordbestanden om te voldoen aan veel van de vereisten van het geavanceerde bestandssysteem van System/38.

Bestanden bestaan ​​in een context die wordt geboden door een besturingssysteem dat services biedt voor het organiseren van bestanden, voor het delen ervan met gelijktijdige gebruikers en voor het beveiligen van bestanden tegen ongeoorloofde toegang. In niveau 1 van DDM werd toegang tot externe bestandsdirectory's niet ondersteund na het verzenden van de volledig gekwalificeerde naam van het te gebruiken bestand. Beveiliging en delen waren echter vereist. Sanders deed het ontwerpwerk op deze gebieden. Sanders definieerde ook specifieke protocollen met betrekking tot het gebruik van communicatiefaciliteiten, die zijn opgenomen in een onderdeel dat de DDM Conversational Communications Manager wordt genoemd. Aanvankelijk geïmplementeerd met behulp van APPC, werd het later geïmplementeerd met behulp van TCP/IP .

Met de voltooiing van het System/36 DDM-product werkte Lawrence samen met programmeurs van het IBM Hursley Park, UK-laboratorium om een ​​groot deel van de System/36 DDM-serverprogrammering aan te passen voor gebruik in de IBM Customer Information Control System (CICS) transactieverwerkingsomgeving, waardoor CICS een DDM-server wordt voor zowel de MVS- als de VSE-mainframebesturingssystemen. Lawrence werkte ook samen met programmeurs van het IBM Cary, North Carolina-laboratorium om een ​​DDM-recordgeoriënteerde client voor IBM PC DOS te implementeren .

Level 1 van DDM Architecture werd formeel gepubliceerd in 1986. Op het moment van deze aankondiging reikte IBM een Outstanding Technical Achievement Award uit aan Kenneth Lawrence, een Outstanding Contribution Award aan Richard Sanders en een Outstanding Innovation Award aan Richard Demers.

• In dit artikel wordt System/38 voortaan gebruikt om te verwijzen naar System/38 en zijn opvolgers: de IBM AS/400 (die de functionaliteit van System/36 en System/38 samenvoegde), de IBM iSeries en de IBM Power Series (die de iSeries samenvoegde met de IBM RS/6000, IBM's op RISC/UNIX gebaseerde server- en werkstationproductlijn).

DDM-niveau 2: Hiërarchische mappen en stream-georiënteerde bestanden

Met het toenemende belang van de IBM PC en het Unix-besturingssysteem in netwerkomgevingen, was DDM-ondersteuning ook nodig voor de hiërarchische mappen en stream-georiënteerde bestanden van de IBM Personal Computer met IBM PC DOS en de IBM RS/6000 met IBM AIX ( IBM's versie van Unix). Zie Stream-georiënteerde bestanden .

DDM Architecture Level 2 werd in 1988 gepubliceerd. Jan Fisher en Sunil Gaitonde deden het meeste architectuurwerk aan DDM-ondersteuning voor directory's en streambestanden.

DDM-niveau 3: relationele databaseservices

In 1986 bracht IBM vier verschillende relationele databaseproducten (RDB) op de markt, elk gebouwd voor een specifiek IBM-besturingssysteem. Wetenschappers van het Almaden Research Laboratory van IBM hadden System/R* ontwikkeld, een prototype van een gedistribueerde RDB en ze vonden dat het nu tijd was om er verkoopbare producten van te maken. System/R* was echter gebaseerd op System/R, een onderzoeksprototype van een RDB, en kon niet gemakkelijk worden toegevoegd aan de IBM RDB-producten. Zie voor een bespreking van RDB's in een gedistribueerde verwerkingsomgeving.

Roger Reinsch van het IBM Santa Theresa Programming Center leidde een productoverschrijdend team om een Distributed Relational Database Architecture (DRDA) te definiëren . Hij meldde zich aan:

• Vertegenwoordigers van elk van de vier IBM RDB-producten.
• Bruce Lindsay, een System/R*-onderzoeker,
• Paul Roever (van het laboratorium IBM Sindelfingen, Duitsland), die een specificatie had ontwikkeld voor het beschrijven van gegevens, de Formatted Data: Object Content Architecture (FD:OCA).
• Richard Sanders en Richard Demers van het DDM-architectuurteam om geschikte modellen, berichten en protocollen te definiëren.

In 1990 werden tegelijkertijd DDM Architecture Level 3 en DRDA gepubliceerd. Zowel DDM als DRDA werden aangewezen als strategische componenten van IBM's Systems Application Architecture (SAA). DRDA is geïmplementeerd door alle vier de IBM RDB-producten en door andere leveranciers.

Er werden prijzen uitgereikt aan de belangrijkste deelnemers aan het ontwerp van DRDA. Richard Sanders ontving een Outstanding Contribution Award en Roger Reinsch en Richard Demers ontvingen Outstanding Innovation Awards .

DDM-niveau 4: Aanvullende services

Het Distributed File Management (DFM)-project is gestart om DDM-services toe te voegen aan IBM's MVS-besturingssysteem, zodat programma's op externe computers VSAM- bestanden kunnen maken, beheren en openen . John Hufferd, de manager van het DFM-project, vroeg het DDM Architecture-team om een ​​manier om de gegevensvelden in records om te zetten terwijl ze tussen systemen stroomden. Richard Demers nam hierin het voortouw, geholpen door Koichi Yamaguchi van het DFM-project. Zie Gegevensbeschrijving en conversie .

De volgende aanvullende services zijn gedefinieerd door Richard Sanders, Jan Fisher en Sunil Gaitonde in DDM-architectuur op niveau 4:

• Voor DFM, opslagbeheer en door de gebruiker gedefinieerde bestandskenmerken.
• Voor DRDA, tweefasige verbinteniscontroleprotocollen voor toepassingsgerichte gedistribueerde werkeenheden.
• Wachtrijen, die kunnen worden gemaakt, gewist of verwijderd op een externe server. Wachtrijvermeldingen zijn door een toepassing gedefinieerde records die worden toegevoegd aan of ontvangen van een wachtrij. Zie DDM-wachtrijen .
• System Command Processor, een Manager waarnaar opdrachten die door het hostsysteem van een server zijn gedefinieerd, voor uitvoering kunnen worden verzonden.
• Multi-tasking Communications Manager, waarmee meerdere client-agents kunnen communiceren met bijbehorende server-agents via een enkel gesprek tussen de client- en serversystemen.
• Sync Point Manager coördineert logische werkeenheden in meerdere DDM-servers. Tweefasige commitment-protocollen zorgen voor gecoördineerd herstel van bronnen wanneer een logische werkeenheid faalt.

DDM-architectuur niveau 4 werd gepubliceerd in 1992.

DDM-niveau 5: Bibliotheekdiensten

Architectuurwerk op DDM-niveau 5 bestond uit ondersteuning voor:

• mainframe gepartitioneerde datasets , dit zijn bestanden die bestaan ​​uit een interne map en meerdere leden; in feite zijn het bibliotheken van vergelijkbare bestanden.
• Personal Computer Libraries , die de toegang tot bestanden in meerdere mappen in één bibliotheek consolideren.
• verdere verbeteringen aan DRDA.

Jan Fisher was de architect die verantwoordelijk was voor DDM level 5, dat werd gepubliceerd door de Open Group , in plaats van IBM. Kort daarna werd de IBM DDM-architectuurgroep ontbonden.

Binnen DDM

DDM-architectuur is een formeel gedefinieerde en zeer gestructureerde set specificaties. Deze sectie introduceert de belangrijkste technische concepten die ten grondslag liggen aan DDM.

Hoe DDM werkt

DDM-architectuur definieert een client/server-protocol; dat wil zeggen, een cliënt vraagt ​​diensten aan van een server die samenwerkt met zijn lokale bronnen om de gevraagde dienst uit te voeren, waarvan de resultaten, gegevens en statusindicatoren, worden teruggestuurd naar de cliënt. Het bovenstaande diagram illustreert de rollen van DDM-clients en -servers in relatie tot lokale bronnen. (De algemene terminologie van clients en servers wordt hier gebruikt, maar in de DDM-architectuur wordt een client een bronserver genoemd en een server een doelserver .)

1. Een applicatieprogramma werkt samen met een lokale bron, zoals een bestand, door middel van programmeerinterfaces die worden geleverd door een lokale bronmanager (LRM). Maar als de gewenste bron zich op een externe computer bevindt, wordt DDM gebruikt om de interactie te bemiddelen. Het applicatieprogramma blijft de interfaces gebruiken die door zijn LRM worden geleverd, maar ze worden omgeleid naar een DDM-client. De DDM-architectuur specificeert niet hoe deze omleiding moet plaatsvinden, aangezien het geen directory met externe bronnen ondersteunt. Een methode van omleiding die door verschillende DDM-bestandsgeoriënteerde producten wordt gebruikt, is om de toepassing een speciaal lokaal bestand te laten openen, een DDM-bestand genoemd door het System/38, dat locatie- en toegangsinformatie over het externe bestand biedt. Er vindt dan een omleiding naar de DDM-client plaats.
2. DDM Architecture definieert entiteiten op managerniveau voor bestanden, relationele databases, toegangsmethoden, enz. Een Client Resource Manager (CRM) ondersteunt polymorf de functionele interfaces die zijn gedefinieerd door de LRM van het clientsysteem. De primaire functie is het genereren van geschikte gelineariseerde DDM-opdrachten en gegevensobjecten voor elke functionele interface. (Zie DDM-berichten .) Deze objecten worden verzonden naar de server resource manager (SRM) van de externe DDM-server. In werkelijkheid worden ze echter gerouteerd via DDM-client- en serveragents en communicatiemanagers.
3. De DDM Client Agent plaatst een gelineariseerd commando in een RQSDSS-envelop en gelineariseerde objecten in gekoppelde OBJDSS-enveloppen. (Zie DDM-berichten .) De Client Agent werkt samen met de Server Agent om een ​​pad te creëren voor de berichten die hij ontvangt van de CRM om naar de SRM te stromen. Als het toepassingsprogramma slechts met één externe bron hoeft te communiceren, is dit eenvoudig. Het is echter mogelijk dat het toepassingsprogramma gelijktijdig communiceert met meerdere bronnen van verschillende soorten die zich op meerdere systemen op afstand bevinden. De Client Agent vertegenwoordigt in alle gevallen het toepassingsprogramma en routeert berichten op afzonderlijke virtuele paden naar elke bron.
4. De Client Communications Manager werkt samen met de ServerCommunications Manager om een ​​gespreksprotocol te implementeren van de vorm "Ik praat terwijl u luistert, en dan praat u terwijl ik luister." Er kunnen verschillende telecommunicatieprotocollen worden gebruikt, waaronder IBM's SNA APPC en het internet-TCP/IP-protocol.
5. DDM-berichten die naar de Server Communications Manager worden verzonden, worden doorgegeven aan de Server Agent op het pad dat door het bericht wordt gespecificeerd, en het stuurt de berichten door naar de SRM op hetzelfde pad. Als de Server Agent op één pad communiceert met een enkele client, is dit eenvoudig. De Server Agent kan echter communiceren met meerdere clients op meerdere paden.
6. De Server Resource Manager (SRM) analyseert DDM-berichten en bepaalt wat het moet doen om het verzoek uit te voeren. Het kan een of meer van de functionele interfaces van de overeenkomstige Local Resource Manager (LRM) van het serversysteem gebruiken.
7. De SRM verzamelt de gegevens en statusindicatoren van de LRM en genereert geschikte gelineariseerde objecten en antwoordberichten, die het doorgeeft aan de Server Agent.
8. De Server Agent verpakt de antwoorden en objecten in RPYDSS- en OBJDSS-enveloppen en stuurt ze door naar de Server Communication Manager, die ze naar de Client Communication Manager en de Client Agent stuurt op hetzelfde pad als de oorspronkelijke opdracht.
9. De Client Agent verwijdert het antwoord en de objecten uit hun respectievelijke RPYDSS- en OBJDSS-enveloppen en geeft ze door aan de Client Resource Manager.
10. De Client Resource Manager analyseert het geretourneerde object en de antwoordberichten en brengt ze in kaart zoals verwacht door de functionele interface van de originele LRM voor terugkeer naar het toepassingsprogramma.

Object-oriëntatie

DDM-architectuur is objectgeoriënteerd . Alle entiteiten gedefinieerd door DDM zijn objecten gedefinieerd door zelfdefiniërende Class objecten. De berichten, antwoorden en gegevens die tussen systemen stromen, zijn geserialiseerde objecten. Elk object specificeert zijn lengte, identificeert zijn klasse door middel van een DDM-codepunt en bevat gegevens zoals gedefinieerd door zijn klasse. Verder specificeert zijn klasse de opdrachten die naar zijn instanties kunnen worden verzonden wanneer een object zich in een DDM-client of -server bevindt, waardoor het object wordt ingekapseld door een beperkte reeks bewerkingen.

Structureel gezien bestaat DDM-architectuur uit hiërarchische niveaus van objecten, waarbij elk niveau opkomende eigenschappen op steeds hogere niveaus manifesteert.

• Een veld is een reeks bits die een getal, teken of andere gegevensentiteit codeert. Instanties van een Field-subklasse worden ingekapseld door de bewerkingen die door zijn klasse kunnen worden uitgevoerd; bijvoorbeeld rekenkundige bewerkingen op gehele velden.
• Een object is een zelfidentificerende entiteit die bestaat uit een of meer velden die zijn ingekapseld door een gedefinieerde reeks bewerkingen. Objecten op dit niveau zijn geïnspireerd op de kernel-objectklassen van de programmeertaal Smalltalk
  • Een scalair object bestaat uit een enkel veld, zoals gecodeerd en beschreven door de klasse van het object. Scalaire objecten worden gebruikt als parameterwaarden van opdracht- en antwoordobjecten. Ze worden ook gebruikt als de waarden van objectattributen, zoals de lengte van een object in DDM-documentatie. De coderingsmethoden die worden gebruikt voor de waarden van deze scalaire objecten zijn volledig gedefinieerd door de DDM-architectuur.
  • Een toegewezen object bestaat uit een of meer velden, zoals de velden van een applicatiegedefinieerd record. De coderingsmethoden en de uitlijning van deze velden wordt niet gedefinieerd door de DDM-architectuur; in plaats daarvan wordt het gedefinieerd door declaratieverklaringen van het toepassingsprogramma en de coderings- en uitlijningsmethoden van de programmeertaal.
  • Een collectieobject is een container voor objecten, zoals gedefinieerd door de klasse van de collectie. Voorbeelden van collectieobjecten zijn DDM-opdrachten en antwoorden.
• Een manager is een zichzelf identificerende entiteit die een omgeving biedt voor de opslag en verwerking van objecten. Een manager wordt ingekapseld door de bewerkingen die zijn gedefinieerd door zijn klasse. Samen implementeert een set managers de algehele verwerkingsomgeving van een DDM-client of -server. Managerentiteiten op dit niveau werden geïnspireerd door de systeemobjecten van het besturingssysteem System/38. De door DDM gedefinieerde managers zijn onder meer: ​​Woordenboek, Supervisor, Agent, Directory, Bestand(en), Toegangsmethode(n), Relationele database, SQL Application Manager, Queue, Lock Manager, Security Manager, Recovery Manager, System Command Processor, Communication Manager (s).
• Een server is een zichzelf identificerende entiteit die een omgeving biedt voor opslag en verwerking van managers, als client of als server, in een gedistribueerde verwerkingsomgeving. Voorbeelden zijn clients en servers die gespecialiseerd zijn in het beheer van gedistribueerde bestanden of gedistribueerde relationele databases.

Hoewel de DDM-architectuur objectgeoriënteerd is, werden de DDM-producten geïmplementeerd met behulp van de talen en methoden die typerend zijn voor hun hostsystemen. Een Smalltalk-versie van DDM is ontwikkeld voor de IBM PC door Object Technology International , met de juiste Smalltalk-klassen die automatisch zijn gemaakt op basis van de DDM Reference Manual.

Subsets en extensies

DDM is een open architectuur. DDM-producten kunnen subsets van DDM-architectuur implementeren; ze kunnen ook hun eigen extensies maken.

Het DDM-commando 'Exchange Server Attributes' is het eerste commando dat wordt verzonden wanneer een client is verbonden met een server. Het identificeert de klant en specificeert de managers die de klant nodig heeft en het niveau van de DDM-architectuur waarop ondersteuning vereist is. De server reageert door zichzelf te identificeren en aan te geven op welk niveau hij de gevraagde beheerders ondersteunt. Een algemene regel is dat een product dat Level X van een DDM-manager ondersteunt, ook Level X-1 moet ondersteunen, zodat nieuwe serverproducten verbinding maken met oudere clientproducten.

Subsets van DDM kunnen worden geïmplementeerd om aan verschillende productvereisten te voldoen:

• als client, server of beide. DDM/PC is bijvoorbeeld alleen een client, CICS/DDM is alleen een server en System/38 DDM is zowel een client als een server.
• ter ondersteuning van specifieke beheerders, zoals record-georiënteerde bestanden, stream-georiënteerde bestanden, relationele databases (als onderdeel van DRDA), of een combinatie daarvan. MVS Database 2 biedt bijvoorbeeld client- en serverondersteuning voor alleen de door DRDA vereiste subset van DDM.
• om alleen geselecteerde opdrachten van een manager te ondersteunen, zoals de mogelijkheid om records uit een sequentieel bestand te laden en te verwijderen.
• om geselecteerde parameters van een opdracht te ondersteunen, zoals de parameter 'Return Inactive Records' van de opdracht 'Get Record'.

Wanneer een DDM-client is aangesloten op een bekende DDM-server, zoals een System/38-client op een System/38-server, kan de DDM-architectuur ook worden uitgebreid door toevoeging

• nieuwe productspecifieke managers.
• nieuwe opdrachten naar een bestaande DDM-manager.
• nieuwe parameters toe aan een DDM-opdracht of antwoordbericht.

Dergelijke uitbreidingen kunnen worden gedefinieerd binnen het objectgeoriënteerde raamwerk van DDM, zodat bestaande DDM-berichtenverwerkingsfaciliteiten kunnen worden gebruikt.

DDM-berichten

In een puur objectgeoriënteerde implementatie van DDM bestaan ​​clients en servers en al hun daarin aanwezige managers en objecten in een geheugenheap, met pointers (geheugenadressen) die worden gebruikt om ze met elkaar te verbinden. Een opdrachtobject verwijst bijvoorbeeld naar elk van zijn parameterobjecten. Maar op deze manier kan een opdracht niet van een client naar een server worden verzonden; een isomorfe kopie van de opdracht moet worden gemaakt als een enkele, aaneengesloten reeks bits. In de heap bestaat een opdracht uit de grootte van de opdracht in de heap, een aanwijzer naar de klasse van de opdracht en verwijzingen naar elk van de parameterobjecten van de opdracht. Gelineariseerd, het commando bestaat uit de totale lengte van het gelineariseerde commando, een codepunt dat de klasse van het commando identificeert, en elk van zijn gelineariseerde parameterobjecten. DDM-architectuur wijst unieke codepunten toe aan elke objectklasse. Deze ongecompliceerde techniek wordt gebruikt voor alle objecten die tussen client en servers worden verzonden, inclusief opdrachten, records en antwoordberichten.

Al deze gelineariseerde objecten worden in enveloppen gestopt die de client- en serveragenten in staat stellen hun verwerking te coördineren. In de DDM-architectuur worden deze enveloppen Data Stream Structures (DSS) genoemd. Commando's worden in een Request DSS (RQSDSS) geplaatst, antwoorden worden in een Reply DSS (RPYDSS) geplaatst en andere objecten worden in een Object DSS (OBJDSS) geplaatst. Er kan slechts één commando in een RQSDSS en slechts één antwoord in RPYDSS zijn, maar veel objecten, zoals records, kunnen in een OBJDSS worden geplaatst. Verder kunnen veel OBJDSS'en worden geketend aan een RQSDSS of een PRYDSS om zoveel objecten als nodig te huisvesten. Een DSS bestaat uit de totale lengte van de DSS, een vlagbyte die het type DSS identificeert, een verzoek-ID en de gelineariseerde objecten in de DSS. De aanvraag-ID koppelt een RQSDSS met daaropvolgende OBJDSS'en van de client, zoals de records die met de opdracht Bestand laden in een bestand moeten worden geladen . De aanvraag-ID koppelt ook de RQSDSS van de client met een RPYDSS of de OBJDSSen van de server aan de client.

Documentatie

De DDM Reference Manual bestaat uit benoemde Menu-, Help- en Class-objecten. De subklassen van de DDM-klasse Klasse worden beschreven door variabelen die specificeren:

• de superklasse van de klas. Klassen worden gedefinieerd door een overervingshiërarchie; Record File is bijvoorbeeld een subklasse van File, een subklasse van Manager en erft hun gegevens en opdrachten. Klasse klasse en haar subklassen zijn self-beschrijven door klasse opdrachten en klasse variabelen , waaronder:
• een titel die de klas kort beschrijft.
• de status van de klas ten opzichte van het lopende werk aan de DDM-architectuur.
• beschrijvende tekst en afbeeldingen die de klasse relateren aan zijn componenten en zijn omgeving.
• de gegevens (velden, objecten, managers, enz.) ingekapseld door instanties van de klasse.
• de opdrachten die naar zijn instanties kunnen worden verzonden.

Deze objecten kunnen verwijzingen naar andere benoemde objecten in tekst en specificaties bevatten, waardoor hypertext- koppelingen ontstaan ​​tussen de pagina's van de DDM Reference Manual. Menu- en Help-pagina's vormen een geïntegreerde tutorial over DDM. De papieren versie van de DDM Reference Manual Level 3 is omvangrijk, met meer dan 1400 pagina's, en enigszins onhandig in gebruik, maar er is ook een interactieve versie gebouwd met behulp van interne IBM-communicatiefaciliteiten. Gezien de relatief lage snelheid van die communicatiefaciliteiten, was het vooral nuttig binnen het IBM Rochester-laboratorium.

Naast de DDM-referentiehandleiding bevat een document met algemene informatie op directieniveau informatie over DDM, en een programmeerhandleiding die DDM-concepten samenvat voor programmeurs die clients en servers implementeren.

DDM-bestandsmodellen

Drie algemene bestandsmodellen worden gedefinieerd door DDM-architectuur: record-georiënteerde bestanden, stream-georiënteerde bestanden en hiërarchische mappen.

De volgende services worden geleverd door de DDM-architectuur voor het beheren van externe bestanden:

• bestanden maken, wissen en verwijderen,
• het kopiëren, laden en lossen van de gegevens van een bestand,
• bestanden vergrendelen en ontgrendelen,
• het verkrijgen en wijzigen van bestandskenmerken,

Record-georiënteerde bestanden

Record-georiënteerde bestanden zijn ontworpen om te voldoen aan de gegevensinvoer-, uitvoer- en opslagvereisten van derde generatie (3GL) programmeertalen, zoals Fortran, Cobol, PL/I en RPG. In plaats van dat elke taal zijn eigen ondersteuning voor deze mogelijkheden biedt, werden ze opgenomen in services die door besturingssystemen worden geleverd.

Een record is een reeks gerelateerde gegevensvelden, zoals de naam, het adres, het identificatienummer en het salaris van een enkele werknemer, waarin elk veld is gecodeerd en toegewezen aan een aaneengesloten reeks bytes. Vroege computers hadden beperkte invoer- en uitvoermogelijkheden, meestal in de vorm van stapels van 80 kolomponskaarten of in de vorm van papier of magnetische banden. Applicatierecords, zoals records met werknemersgegevens, werden achtereenvolgens per record gelezen of geschreven en in batches verwerkt. Toen opslagapparaten met directe toegang beschikbaar kwamen, voegden programmeertalen manieren toe voor programma's om willekeurig één voor één toegang te krijgen tot records, zoals toegang door de waarden van sleutelvelden of door de positie van een record in een bestand. Alle records in een bestand kunnen hetzelfde formaat hebben (zoals in een salarisbestand) of verschillende formaten (zoals in een gebeurtenislogboek). Sommige bestanden zijn alleen-lezen omdat hun records, eenmaal naar het bestand geschreven, alleen kunnen worden gelezen, terwijl andere bestanden hun records kunnen bijwerken.

De DDM-recordgeoriënteerde bestandsmodellen bestaan ​​uit bestandsattributen, zoals de aanmaakdatum, de datum van de laatste update, de grootte van de records en slots waarin records kunnen worden opgeslagen. De records kunnen een vaste of variërende lengte hebben, afhankelijk van de media die worden gebruikt om de records van het bestand op te slaan. DDM definieert vier soorten record-georiënteerde bestanden:

• Sequentiële bestanden, waarin records in opeenvolgende slots worden opgeslagen.
• Directe bestanden, waarin individuele records worden opgeslagen in een slot van het bestand dat wordt bepaald door de waarde van een veld van de records.
• Versleutelde bestanden, waarin records in opeenvolgende slots worden opgeslagen en waarvoor een secundaire volgorde wordt bijgehouden door middel van een index van de waarden van sleutelvelden in de records.
• Alternatieve indexbestanden, waarin een afzonderlijke index van de waarden van sleutelvelden is gebaseerd op een bestaand sequentieel, direct of versleuteld bestand.

DDM-architectuur definieert ook een verscheidenheid aan toegangsmethoden om op verschillende manieren met record-georiënteerde bestanden te werken. Een toegangsmethode is een instantie van het gebruik van een bestand dat is gemaakt door middel van een OPEN-commando dat zichzelf met het bestand verbindt nadat is vastgesteld of de client geautoriseerd is om het te gebruiken. De toegangsmethode wordt losgekoppeld van een bestand door middel van een CLOSE-commando.

Een toegangsmethode houdt door middel van een cursor bij welke record op dat moment wordt verwerkt. Met behulp van verschillende SET-commando's kan de cursor naar het begin of einde van het bestand wijzen, naar het volgende of vorige opeenvolgende record van het bestand, naar het record met een specifieke sleutelwaarde, of naar het volgende of vorige record zoals besteld door hun sleutels.

Meerdere exemplaren van toegangsmethoden kunnen tegelijkertijd op een bestand worden geopend, die elk een enkele client bedienen. Als een bestand wordt geopend voor toegang tot updates, kunnen er conflicten optreden wanneer hetzelfde record door meerdere clients wordt geopend. Om dergelijke conflicten te voorkomen, kan een vergrendeling op een heel bestand worden verkregen. Ook als een bestand wordt geopend voor update, wordt een vergrendeling op een record verkregen door de eerste client die het leest en vrijgegeven wanneer die client het bijwerkt. Alle andere klanten moeten wachten op de ontgrendeling van het slot.

Stream-georiënteerde bestanden

Stream-georiënteerde bestanden bestaan ​​uit een enkele reeks bytes waarop programma's toepassingsgegevens kunnen toewijzen zoals ze willen. Streambestanden zijn het primaire bestandsmodel dat wordt ondersteund door Unix en Unix-achtige besturingssystemen en door Windows . DDM definieert een single-stream bestandsmodel en een single-stream toegangsmethode.

Het DDM-stroombestandsmodel bestaat uit bestandskenmerken, zoals de aanmaakdatum en de grootte van de stream en een continue stroom van bytes. De stream is toegankelijk via de Stream Access Method. Applicatieprogramma's schrijven gegevens op delen van de stream, zelfs als die gegevens uit records bestaan. Ze houden de locatie van gegevensitems in de stream bij op elke gewenste manier. De gegevensstroom van documentbestanden wordt bijvoorbeeld gedefinieerd door een tekstverwerkingsprogramma zoals Microsoft Word en die van een spreadsheetbestand door een programma zoals Microsoft Excel .

Een Stream-toegangsmethode is een instantie van het gebruik van een streambestand door een enkele client. Een cursor houdt de positie bij van de huidige byte van de substream die door de client wordt gebruikt. Met behulp van verschillende SET-commando's kan de cursor naar het begin of het einde van het bestand wijzen, naar een specifieke positie in het bestand of naar een positieve of negatieve afwijking van de huidige positie.

Meerdere instanties van de Stream-toegangsmethode kunnen tegelijkertijd in een bestand worden geopend, die elk een enkele client bedienen. Als een bestand wordt geopend voor "update"-toegang, kunnen er conflicten optreden wanneer dezelfde substream door meerdere clients wordt gebruikt. Om dergelijke conflicten te voorkomen, kan een vergrendeling op een heel bestand worden verkregen. Ook als een bestand wordt geopend voor update, wordt een vergrendeling verkregen op een substream door de eerste client om het te "lezen" en vrijgegeven wanneer die client het "bijwerkt". Alle andere klanten moeten wachten op de ontgrendeling van het slot.

Hiërarchische mappen

Hiërarchische mappen zijn bestanden waarvan de records elk een naam koppelen aan een locatie. Een hiërarchie treedt op wanneer een directoryrecord de naam en locatie van een andere directory identificeert. Met behulp van DDM-client- en serverproducten kan een programma mappen maken, verwijderen en hernoemen op een externe computer. Ze kunnen ook de bestandskenmerken van externe mappen weergeven en wijzigen. De records in een directory kunnen achtereenvolgens worden gelezen met behulp van de DDM Directory Access Method. De bestanden die worden geïdentificeerd door directoryrecords kunnen worden hernoemd, gekopieerd en verplaatst naar een andere directory.

DDM-wachtrijen

Wachtrijen zijn een communicatiemechanisme dat over het algemeen kortetermijncommunicatie tussen programma's mogelijk maakt door middel van records. Een DDM-wachtrij bevindt zich op één systeem, maar is toegankelijk voor programma's op meerdere systemen. Er zijn drie subklassen van DDM-wachtrijen die op een doelsysteem kunnen worden aangemaakt door middel van verschillende aanmaakopdrachten:

• First-in-first-out-wachtrijen, een asynchrone verbinding tussen programma's die in de wachtrij staan ​​en die uit de wachtrij worden gehaald.
• Last-in-first-out wachtrijen, een pushdown-stack.
• Versleutelde wachtrijen, een fan-out-mechanisme waarbij geselecteerde items uit de wachtrij kunnen worden gehaald op basis van sleutelwaarde.

Het DDM-wachtrijmodel bestaat uit wachtrijkenmerken, zoals de aanmaakdatum, het aantal records dat de wachtrij kan bevatten en de lengte van de records. De records in een wachtrij kunnen een vaste of variërende lengte hebben.

In tegenstelling tot de DDM-bestandsmodellen is het niet nodig om een ​​toegangsmethode voor een wachtrij te openen. Programma's kunnen records toevoegen aan een wachtrij en records ontvangen van een wachtrij, zoals bepaald door de klasse van de wachtrij. Programma's kunnen ook records uit een wachtrij wissen, bewerkingen in een wachtrij stoppen, de kenmerken van een wachtrij weergeven en de kenmerken van een wachtrij wijzigen. Programma's kunnen ook een wachtrij of afzonderlijke records in een wachtrij vergrendelen om conflicten met andere programma's te voorkomen. Alle andere klanten moeten wachten op de ontgrendeling van het slot.

Relationele databases

Een relationele database (RDB) is een implementatie van de Structured Query Language (SQL) die het maken, beheren, opvragen, bijwerken, indexeren en onderlinge relaties van gegevenstabellen ondersteunt. Een interactieve gebruiker of programma kan SQL-instructies afgeven aan een RDB en als antwoord tabellen met gegevens en statusindicatoren ontvangen. SQL-instructies kunnen echter ook als pakketten worden gecompileerd en opgeslagen in de RDB en vervolgens worden aangeroepen op pakketnaam. Dit is belangrijk voor de efficiënte werking van applicatieprogramma's die complexe, hoogfrequente queries afgeven. Het is vooral belangrijk wanneer de te benaderen tabellen zich in systemen op afstand bevinden.

De Distributed Relational Database Architecture (DRDA) past mooi in het algemene DDM-raamwerk, zoals besproken in Object-Orientation . (DDM kan echter ook worden gezien als een componentarchitectuur van DRDA, aangezien ook andere specificaties vereist zijn). De objecten op DDM-managerniveau die DRDA ondersteunen, worden RDB (voor relationele database) en SQLAM (voor SQL Application Manager) genoemd.

Gegevensbeschrijving en conversie

Transparantie is een hoofddoel van de DDM-architectuur. Zonder hercompilatie moet het mogelijk zijn om bestaande applicatieprogramma's om te leiden naar de gegevensbeheerservices van een externe computer. Voor bestanden werd dit grotendeels gerealiseerd door DDM-clients op interface/functioneel niveau, maar hoe zit het met de datavelden in een record? Volledige transparantie vereist dat clienttoepassingsprogramma's velden kunnen schrijven en lezen zoals gecodeerd door hun lokale gegevensbeheersysteem, ongeacht hoe een externe server ze codeert, en dat impliceert automatische gegevensconversies .

IBM-mainframecomputers coderen bijvoorbeeld getallen met drijvende komma in hexadecimaal formaat en tekengegevens in EBCDIC , terwijl IBM Personal computers ze coderen in IEEE- formaat en ASCII . Verdere complexiteit ontstond vanwege de manieren waarop verschillende programmeertaalcompilers recordvelden toewijzen aan strings van bits, bytes en woorden in het geheugen. Transparante conversie van een record vereist gedetailleerde beschrijvingen van zowel de clientview als de serverview van een record. Met deze beschrijvingen kunnen de velden van de client- en serverweergaven worden gematcht, op veldnaam, en kunnen de juiste conversies worden uitgevoerd.

Het belangrijkste probleem is het verkrijgen van voldoende gedetailleerde recordbeschrijvingen, maar recordbeschrijvingen worden over het algemeen abstract gespecificeerd in toepassingsprogramma's door declaratieverklaringen gedefinieerd door de programmeertaal, waarbij de taalcompiler de codering en toewijzingsdetails afhandelt. In een gedistribueerde verwerkingsomgeving is een enkele, gestandaardiseerde manier nodig om records te beschrijven die onafhankelijk is van alle programmeertalen, een die de grote verscheidenheid aan recordformaten met vaste en variërende lengtes in bestaande bestanden kan beschrijven.

Het resultaat was de definitie van een uitgebreide Data Description and Conversion- architectuur (DD&C), gebaseerd op een nieuwe, gespecialiseerde programmeertaal, A Data Language (ADL), voor het beschrijven van client- en serverweergaven van datarecords en voor het specificeren van conversies. Gecompileerde ADL-programma's kunnen vervolgens door een server worden aangeroepen om de nodige conversies uit te voeren terwijl records naar of van de server stromen.

DD&C-architectuur ging verder en definieerde een middel waarmee verklaringen van programmeertaaldeclaraties automatisch kunnen worden geconverteerd van en naar ADL, en dus van de ene programmeertaal naar de andere. Deze mogelijkheid is nooit geïmplementeerd vanwege de complexiteit en de kosten. Er is echter een ADL-compiler gemaakt en ADL-programma's worden, indien beschikbaar, aangeroepen om conversies uit te voeren door DFM en door het IBM 4680 Store System. Het is echter noodzakelijk voor applicatieprogrammeurs om de ADL-programma's handmatig te schrijven.

Producten implementeren

DDM-producten van IBM

De volgende IBM-producten hebben verschillende subsets van DDM-architectuur geïmplementeerd:

• IBM-systeem/370
  • MVS (MVS/SP, MVS/ESA)
    • Database 2 - DRDA-client en server
    • CICS - record file server binnen de CICS transactieverwerkingsomgeving. Stopgezet in CICS voor z/OS V5.2 en hoger.
  • VM (besturingssysteem) (VM/SP, VM/ESA)
    • SQL/DS - DRDA-client en server
  • DOS/VSE
    • CICS - Record file server binnen de CICS transactieverwerkingsomgeving. Stopgezet in CICS voor z/VSE V2.1 en later.
  • z/OS
    • Beheer van gedistribueerde bestanden - Recordbestandsserver
    • Database 2 - DRDA-client en server
• Systeem/36
  • Systeemondersteuningsprogramma - Record bestand client en server
• System/38 en zijn opvolgers: AS/400, iSeries en Power Series
  • Record bestand client en server
  • Directory en streambestand client en server
  • DRDA- client en server
• IBM Personal Computer
  • PC-DOS
    • Netview/PC - Directory en streambestand client en server
    • DDM/PC - Directory en streambestand-client.
    • PC-ondersteuning/36 - Directory en client voor streambestanden.
    • PC Support/400 - Directory- en streambestand-client.
  • Persoonlijk systeem/2 - OS/2
    • PC/Support/400 - Stream bestand en directory client en server
    • DRDA- client en server
• IBM 4680 en IBM 4690 Store-systemen
  • Record bestand client en server
  • Directory en streambestand client en server
• RS/6000 AIX
  • DRDA- client en server

DDM-producten van andere leveranciers

Zie de Open Source DRDA Product Identifier Table voor een volledige lijst van de producten die DRDA hebben geïmplementeerd .

Zie ook

• Record-georiënteerd bestandssysteem

Referenties