Distribuerad datahanteringsarkitektur

Distributed Data Management Architecture ( DDM ) är IBMs öppna, publicerade programvaruarkitektur för att skapa, hantera och komma åt data på en fjärrdator. DDM designades ursprungligen för att stödja rekordorienterade filer ; den utökades för att stödja hierarkiska kataloger , strömorienterade filer , köer och systemkommandobehandling; den utökades ytterligare till att vara basen för IBM:s Distributed Relational Database Architecture (DRDA); och slutligen utökades den för att stödja databeskrivning och konvertering . DDM definierades under perioden 1980 till 1993 och specificerar nödvändiga komponenter, meddelanden och protokoll, allt baserat på principerna för objektorientering . DDM är i sig inte en mjukvara; implementeringen av DDM sker i form av klient- och serverprodukter. Som en öppen arkitektur kan produkter implementera delmängder av DDM-arkitektur och produkter kan utöka DDM för att möta ytterligare krav. Sammantaget implementerar DDM-produkter ett distribuerat filsystem .

DDM-arkitektur i media.

Distribuerade applikationer

Utformarna av distribuerade applikationer måste bestämma den bästa placeringen av applikationens program och data när det gäller mängden och frekvensen av data som ska överföras, tillsammans med datahantering, säkerhet och aktualitet. Det finns tre klient-server-modeller för design av distribuerade applikationer:

  1. File Transfer Protocol (FTP) kopierar eller flyttar hela filer eller databastabeller till varje klient så att de kan hanteras lokalt. Denna modell är lämplig för mycket interaktiva applikationer, såsom dokument- och kalkylbladsredigerare, där varje klient har en kopia av motsvarande redigerare och delning av sådana dokument i allmänhet inte är ett problem.
  2. Tunna klientapplikationer presenterar gränssnittet för en applikation för användare medan beräkningsdelarna av applikationen är centraliserade med de berörda filerna eller databaserna. Kommunikationen består sedan av fjärranrop av procedur mellan de tunna klienterna och en server där unikt utformade meddelanden anger en procedur som ska anropas, dess associerade parametrar och eventuella returnerade värden.
  3. Fettklientapplikationer utför alla applikationsbearbetningsuppgifter på klientsystem, men data är centraliserad i en server så att den kan hanteras, så att den kan nås av alla auktoriserade klientapplikationer, så att alla klientapplikationer fungerar med uppdaterade data, och så att endast poster , strömsektioner eller databastabeller som påverkas av en applikation överförs. Klientapplikationsprogram måste distribueras till alla klienter som arbetar med centraliserad data.

DDM-arkitekturen designades ursprungligen för att stödja den feta klientmodellen för distribuerade applikationer; den stöder också överföringar av hela filer.

Fördelar med DDM-arkitektur

DDM-arkitekturen ger distribuerade applikationer med följande fördelar:

  • Lokal/fjärrtransparens. Applikationsprogram kan enkelt omdirigeras från lokal data till fjärrdata. Specialiserade program som kommer åt och hanterar data i fjärrsystem behövs inte.
  • Minskad dataredundans. Data behöver endast lagras på en plats i ett nätverk.
  • Bättre säkerhet. Genom att eliminera redundanta kopior av data kan tillgången till data i ett nätverk bättre begränsas till auktoriserade användare.
  • Dataintegritet. Uppdateringar från samtidiga lokala och fjärranvändare går inte förlorade på grund av konflikter.
  • Mer aktuell information. Användare av flera datorer i ett nätverk har alltid tillgång till den senaste informationen.
  • Bättre resurshantering. Datalagrings- och bearbetningsresurserna i ett nätverk av datorer kan optimeras.

Historia

DDM-arkitektur är en uppsättning specifikationer för meddelanden och protokoll som gör det möjligt att hantera och komma åt data som distribueras över ett nätverk av datorer.

Inledande ansträngningar

IBMs systemnätverksarkitektur (SNA) designades ursprungligen för att möjliggöra hierarkisk anslutning av arbetsstationer till IBM stordatorer. De kommunikationsnätverk som fanns tillgängliga vid den tiden var strikt utformade när det gäller fasta anslutningar mellan en stordator och dess svit av arbetsstationer, som stod under stordatorns fullständiga mjukvarukontroll. Annan kommunikation mellan stordatorer var också i form av fasta anslutningar som användes av mjukvara definierad för specifika ändamål. När kommunikationsnätverk blev mer flexibla och dynamiska var generisk peer-to-peer- kommunikation önskvärd, där ett program på en dator kunde initiera och interagera med ett program på en annan dator.

När IBM:s SNA Advanced Program to Program Communications (APPC)-arkitektur definierades i början av 1980-talet, var det också uppenbart att APPC kunde användas för att tillhandahålla operativsystemtjänster på fjärrdatorer. En SNA-arbetsgrupp följde denna idé och beskrev flera möjliga distribuerade tjänster, såsom filtjänster, skrivartjänster och systemkonsoltjänster, men kunde inte initiera produktutveckling. APPC-mjukvara var ännu inte tillgänglig på stordatorer och mer i grunden sågs stordatorer fortfarande främst som fristående system. Som ett resultat avbröts arbetet med distribuerade tjänster av SNA:s arbetsgrupp.

Medlemmar av SNA-arbetsgruppen från IBM:s utvecklingslaboratorium i Rochester, Minnesota, var övertygade om att det fanns ett affärscase för distribuerade tjänster bland mellanklassdatorsystemen som produceras i Rochester. En primitiv form av distribuerade filtjänster, kallad Distributed Data File Facility (DDFF) hade implementerats för att koppla ihop IBM System/3 , IBM System/34 och IBM System/36 minidatorer. Vidare såldes datorerna IBM System/36 och IBM System/38 till kunder i multiplar och det fanns ett tydligt behov av att till exempel göra det möjligt för ett företags huvudkontorsdatorer att interagera med datorerna i dess olika lager. APPC implementerades på dessa system och användes av olika kundapplikationer. Idén med distribuerade operativsystemtjänster återupplivades sedan som Golden Gate -projektet och ett försök gjordes för att motivera dess utveckling. Även detta försök misslyckades; Hela idén med distribuerade tjänster var för ny för att IBMs produktplanerare skulle kunna kvantifiera värdet av programvara som kopplade samman heterogena datorer.

En Golden Gate- planerare, John Bondy, förblev dock övertygad och övertalade ledningen att skapa en avdelning utanför Rochester-laboratoriets normala kontroll så att det inte skulle finnas något omedelbart behov av ett fördefinierat affärscase. Vidare minskade han sitt uppdrag till att endast inkludera stöd för distribuerad datahantering (DDM), i synnerhet stöd för rekordorienterade filer . Han övertygade sedan en erfaren mjukvaruarkitekt, Richard A. Demers, att gå med honom i uppgifterna att definiera DDM-arkitektur och sälja idén om DDM till IBM-systemhusen.

Det första året av denna ansträngning var i stort sett fruktlöst eftersom IBM-systemhusen fortsatte att efterfråga affärscase i förväg och eftersom de insisterade på meddelandeformat som var isomorfa till kontrollblockgränssnitten i deras lokala filsystem. Vidare, när persondatorer började användas som terminaler kopplade till stordatorer, hävdades det att enbart förbättring av 3270-dataströmmen skulle göra det möjligt för datorer att komma åt stordatordata.

Under denna period designade Demers en arkitektonisk modell av DDM-klienter och -servrar, av deras komponenter och av interaktioner mellan kommunicerande datorer. Vidare definierade han ett generiskt format för DDM-meddelanden baserat på principerna för objektorientering som banbrytande av Smalltalk -programmeringsspråket och av IBM System/38. Denna modell gjorde det tydligt hur DDM-produkter kunde implementeras på olika system. Se hur DDM fungerar .

1982 blev System/36-planerarna övertygade om att det fanns en tillräcklig marknad för DDM-postorienterade filtjänster.

DDM nivå 1: Record-orienterade filer

Det generiska formatet för DDM-meddelanden hade redan designats, men vilka specifika meddelanden ska definieras? System/36-filsystemet hade definierats för att möta de rekordorienterade behoven hos tredje generationens programmeringsspråk (3GLs), såsom Fortran , COBOL , PL/I och IBM RPG , och så hade System/38-filsystemet och Virtual Storage Access Method (VSAM) filsystem för IBM stordatorer. Och ändå varierade deras faktiska faciliteter och gränssnitt avsevärt, så vilka faciliteter och gränssnitt bör DDM-arkitekturen stödja? Se inspelningsorienterade filer .

Det inledande arbetet med DDM av Golden Gate- projektet hade följt ledningen av den internationella standarden för filöverföring åtkomst och hantering ( FTAM ) för distribuerade filer, men det var mycket abstrakt och svårt att mappa till lokala filtjänster. I själva verket hade detta varit ett av hindren för acceptans av IBM-systemhusen. Kenneth Lawrence, systemarkitekten som ansvarar för System/36-filtjänsterna, hävdade att det skulle vara bättre att definiera meddelanden som åtminstone ett IBM-system enkelt skulle kunna implementera och sedan låta andra system begära de ändringar de behövde. Naturligtvis argumenterade han för stöd för System/36-kraven. Efter ett år av misslyckande med att sälja idén om DDM till andra IBM-systemhus, vann Lawrences argument.

Richard Sanders gick med i DDM-arkitekturteamet och arbetade med Lawrence och Demers för att definiera de specifika meddelanden som behövs för System/36 DDM. Framsteg i definitionen av DDM uppmuntrade System/38 att också delta. Detta breddade omfattningen av DDM-postfilstöd för att möta många av kraven i System/38:s avancerade filsystem.

Filer finns i ett sammanhang som tillhandahålls av ett operativsystem som tillhandahåller tjänster för att organisera filer, för att dela dem med samtidiga användare och för att skydda dem från obefogad åtkomst. I nivå 1 av DDM stöddes inte åtkomst till fjärrfilkataloger utöver överföringen av det fullständiga namnet på filen som skulle användas. Säkerhet och delning krävdes dock. Sanders gjorde designarbetet inom dessa områden. Sanders definierade också specifika protokoll för användningen av kommunikationsfaciliteter, som ingick i en komponent som kallas DDM Conversational Communications Manager. Från början implementerades med APPC, senare implementerades det med TCP/IP .

När System/36 DDM-produkten färdigställdes, arbetade Lawrence med programmerare från laboratoriet i IBM Hursley Park, Storbritannien för att anpassa mycket av System/36 DDM-serverprogrammeringen för användning i IBM Customer Information Control System (CICS) transaktionsbearbetningsmiljö , vilket gör CICS till en DDM-server för både MVS och VSE stordatoroperativsystem. Lawrence arbetade också med programmerare från IBM Cary, North Carolina-laboratoriet för att implementera en DDM-rekordorienterad klient för IBM PC DOS .

Nivå 1 av DDM Architecture publicerades formellt 1986. Vid tidpunkten för detta tillkännagivande delade IBM ut ett Outstanding Technical Achievement Award till Kenneth Lawrence, ett Outstanding Contribution Award till Richard Sanders och ett Outstanding Innovation Award till Richard Demers.

  • I denna artikel kommer System/38 hädanefter att användas för att hänvisa till System/38 och dess efterföljare: IBM AS/400 (som slog ihop funktionerna i System/36 och System/38), IBM iSeries och IBM Power Series (som slog ihop iSeries med IBM RS/6000, IBM:s RISC/UNIX-baserade server- och arbetsstationsproduktlinje).

DDM nivå 2: Hierarkiska kataloger och strömorienterade filer

Med den ökande betydelsen av IBM PC och Unix operativsystem i nätverksmiljöer behövdes DDM-stöd även för de hierarkiska katalogerna och strömorienterade filerna på IBM Personal Computer som kör IBM PC DOS och IBM RS/6000 som kör IBM AIX ( IBM:s version av Unix). Se Stream-orienterade filer .

DDM Architecture Level 2 publicerades 1988. Jan Fisher och Sunil Gaitonde gjorde det mesta av arkitekturarbetet med DDM-stöd för kataloger och strömfiler.

DDM nivå 3: Relationsdatabastjänster

1986 marknadsförde IBM fyra olika relationsdatabasprodukter (RDB), var och en byggd för ett specifikt IBM-operativsystem. Forskare vid IBM:s Almaden Research Laboratory hade utvecklat System/R*, en prototyp av en distribuerad RDB och de kände att det nu var dags att förvandla det till säljbara produkter. System/R* var dock baserat på System/R, en forskningsprototyp av en RDB, och kunde inte enkelt läggas till IBM RDB-produkterna. Se för en diskussion om RDB:er i en distribuerad bearbetningsmiljö.

Roger Reinsch från IBM Santa Theresa Programming Center ledde ett tvärproduktteam för att definiera en distribuerad relationsdatabasarkitektur ( DRDA). Han tog värvning:

  • Representanter från var och en av de fyra IBM RDB-produkterna.
  • Bruce Lindsay, en System/R*-forskare,
  • Paul Roever (från IBM Sindelfingen, Tysklands laboratorium), som hade utvecklat en specifikation för att beskriva data som kallas Formatted Data: Object Content Architecture (FD:OCA).
  • Richard Sanders och Richard Demers från DDM-arkitekturteamet för att definiera lämpliga modeller, meddelanden och protokoll.

1990 publicerades DDM Architecture Level 3 och DRDA samtidigt. Både DDM och DRDA utsågs som strategiska komponenter i IBMs System Application Architecture (SAA). DRDA implementerades av alla fyra IBM RDB-produkterna och av andra leverantörer.

Utmärkelser delades ut till nyckeldeltagare i utformningen av DRDA. Richard Sanders fick en utmärkelse för enastående bidrag och Roger Reinsch och Richard Demers fick utmärkelser för utmärkande innovation .

DDM nivå 4: Tilläggstjänster

Projektet Distributed File Management (DFM) initierades för att lägga till DDM-tjänster till IBMs MVS-operativsystem för att göra det möjligt för program på fjärrdatorer att skapa, hantera och komma åt VSAM -filer. John Hufferd, chefen för DFM-projektet sökte DDM Architecture-teamet efter ett sätt att konvertera datafälten i poster när de flödade mellan systemen. Richard Demers tog ledningen i denna fråga, med hjälp av Koichi Yamaguchi från DFM-projektet. Se Databeskrivning och konvertering .

Följande tilläggstjänster definierades av Richard Sanders, Jan Fisher och Sunil Gaitonde i DDM-arkitektur på nivå 4:

  • För DFM, lagringshantering och användardefinierade filattribut.
  • För DRDA, tvåfas engagemangkontrollprotokoll för applikationsriktade distribuerade arbetsenheter.
  • Köer, som kan skapas, rensas eller raderas på en fjärrserver. Köposter är programdefinierade poster som läggs till eller tas emot från en kö. Se DDM-köer .
  • System Command Processor, en chef till vilken kommandon som definieras av en servers värdsystem kan skickas för exekvering.
  • Multi-tasking Communications Manager, som gör det möjligt för flera klientagenter att kommunicera med motsvarande serveragenter med en enda konversation mellan klient- och serversystemen.
  • Sync Point-hanteraren koordinerar logiska arbetsenheter i flera DDM-servrar. Två-fas åtagandeprotokoll säkerställer koordinerad resursåterställning när någon logisk enhet misslyckas.

DDM-arkitektur nivå 4 publicerades 1992.

DDM nivå 5: Bibliotekstjänster

Arkitekturarbete på DDM nivå 5 bestod av stöd för

  • stordator- partitionerade datamängder , som är filer som består av en intern katalog och flera medlemmar; i själva verket är de bibliotek med liknande filer.
  • Personal Computer Libraries , som konsoliderar åtkomst till filer i flera mappar i ett enda bibliotek.
  • ytterligare förbättringar av DRDA.

Jan Fisher var arkitekten ansvarig för DDM nivå 5, som publicerades av Open Group snarare än IBM. Kort därefter upplöstes IBM DDM-arkitekturgruppen.

Inuti DDM

DDM-arkitektur är en formellt definierad och mycket strukturerad uppsättning specifikationer. Detta avsnitt introducerar viktiga tekniska koncept som ligger till grund för DDM.

Hur DDM fungerar

Overview of DDM Processing

DDM-arkitekturen definierar ett klient/serverprotokoll; det vill säga en klient begär tjänster från en server som interagerar med sina lokala resurser för att utföra den begärda tjänsten, vars resultat, data och statusindikatorer, returneras till klienten. Diagrammet ovan illustrerar rollerna för DDM-klienter och servrar i förhållande till lokala resurser. (Den vanliga terminologin för klienter och servrar används här, men i DDM-arkitektur kallas en klient en källserver och en server kallas en målserver .)

  1. Ett applikationsprogram interagerar med en lokal resurs, såsom en fil, med hjälp av programmeringsgränssnitt tillhandahållna av en lokal resurshanterare (LRM). Men om den önskade resursen finns i en fjärrdator, används DDM för att förmedla interaktionen. Applikationsprogrammet fortsätter att använda gränssnitten som tillhandahålls av dess LRM, men de omdirigeras till en DDM-klient. DDM-arkitekturen anger inte hur denna omdirigering ska ske eftersom den inte stöder en katalog med fjärrresurser. En metod för omdirigering som används av flera DDM-filorienterade produkter är att låta programmet öppna en speciell lokal fil, kallad en DDM-fil av System/38, som ger plats och åtkomstinformation om fjärrfilen. Omdirigering till DDM-klienten sker sedan.
  2. DDM Architecture definierar entiteter på chefsnivå för filer, relationsdatabaser, åtkomstmetoder, etc. En Client Resource Manager (CRM) stöder polymorfiskt de funktionella gränssnitt som definieras av klientsystemets LRM. Dess primära funktion är att generera lämpliga linjäriserade DDM-kommando- och dataobjekt för varje funktionellt gränssnitt. (Se DDM-meddelanden .) Dessa objekt skickas till serverresurshanteraren (SRM) på fjärr-DDM-servern. Men de dirigeras faktiskt via DDM-klient- och serveragenter och kommunikationshanterare.
  3. DDM-klientagenten lägger ett linjäriserat kommando i ett RQSDSS-envelopp och linjäriserade objekt i länkade OBJDSS-envelopp. (Se DDM-meddelanden .) Klientagenten interagerar med serveragenten för att skapa en sökväg för meddelanden som den tar emot från CRM:n för att flöda till SRM. Om applikationsprogrammet bara behöver interagera med en enda fjärrresurs är detta enkelt. Det är dock möjligt för applikationsprogrammet att samtidigt interagera med flera resurser av olika slag som finns på flera fjärrsystem. Klientagenten representerar applikationsprogrammet i alla fall och dirigerar meddelanden på separata virtuella vägar till varje resurs.
  4. Client Communications Manager interagerar med ServerCommunications Manager för att implementera ett samtalsprotokoll av formen "Jag pratar medan du lyssnar, och sedan pratar du medan jag lyssnar." Olika telekommunikationsprotokoll kan användas, inklusive IBM:s SNA APPC och Internets TCP/IP-protokoll.
  5. DDM-meddelanden som sänds till Server Communications Manager skickas till Server Agent på den sökväg som anges av meddelandet, och den vidarebefordrar meddelandena till SRM på samma väg. Om serveragenten interagerar med en enda klient på en enda sökväg är detta enkelt. Serveragenten kan dock interagera med flera klienter på flera vägar.
  6. Server Resource Manager (SRM) analyserar DDM-meddelanden och bestämmer vad den måste göra för att utföra begäran. Den kan använda ett eller flera av de funktionella gränssnitten för serversystemets motsvarande Local Resource Manager (LRM).
  7. SRM ackumulerar data och statusindikatorer från LRM och genererar lämpliga linjäriserade objekt och svarsmeddelanden, som den skickar till serveragenten.
  8. Serveragenten paketerar svaren och objekten i RPYDSS- och OBJDSS-kuvert och vidarebefordrar dem till Server Communication Manager, som skickar dem till Client Communication Manager och Client Agent på samma väg som det ursprungliga kommandot.
  9. Klientagenten tar bort svaret och objekten från deras respektive RPYDSS- och OBJDSS-kuvert och skickar dem till Client Resource Manager.
  10. Client Resource Manager analyserar det returnerade objektet och svarsmeddelanden och mappar dem som förväntat av den ursprungliga LRM:s funktionella gränssnitt för återgång till applikationsprogrammet.

Objektorientering

DDM-arkitekturen är objektorienterad . Alla entiteter som definieras av DDM är objekt definierade av självdefinierande klassobjekt . Meddelanden, svaren och data som flödar mellan systemen är serialiserade objekt. Varje objekt specificerar sin längd, identifierar sin klass med hjälp av en DDM-kodpunkt och innehåller data som definieras av dess klass. Vidare specificerar dess klass de kommandon som kan skickas till dess instanser när ett objekt finns i en DDM-klient eller server, och kapslar därmed in objektet av en begränsad uppsättning operationer.

Strukturellt består DDM-arkitektur av hierarkiska nivåer av objekt, där varje nivå manifesterar framväxande egenskaper på allt högre nivåer.

  • Ett fält är en sträng av bitar som kodar ett nummer, tecken eller annan dataenhet. Förekomster av en fältunderklass är inkapslade av de operationer som kan utföras av dess klass; till exempel aritmetiska operationer på heltalsfält.
  • Ett objekt är en självidentifierande enhet som består av ett eller flera fält inkapslade av en definierad uppsättning operationer. Objekt på denna nivå inspirerades av kärnobjektklasserna i programmeringsspråket Smalltalk
    • Ett skalärt objekt består av ett enda fält, kodat och beskrivet av objektets klass. Skalära objekt används som parametervärden för kommando- och svarsobjekt. De används också som värden för objektattribut, till exempel ett objekts längd i DDM-dokumentation. De kodningsmetoder som används för värdena för dessa skalära objekt är helt definierade av DDM-arkitekturen.
    • Ett mappat objekt består av ett eller flera fält, till exempel fälten i en applikationsdefinierad post. Kodningsmetoderna och justeringen av dessa fält definieras inte av DDM-arkitekturen; i stället definieras den av programdeklarationer och kodnings- och anpassningsmetoderna för dess programmeringsspråk.
    • Ett samlingsobjekt är en behållare för objekt, enligt definitionen av samlingens klass. Exempel på samlingsobjekt är DDM-kommandon och svar.
  • En chef är en självidentifierande enhet som tillhandahåller en miljö för lagring och bearbetning av objekt. En chef är inkapslad av de operationer som definieras av dess klass. Tillsammans implementerar en uppsättning chefer den övergripande bearbetningsmiljön för en DDM-klient eller -server. Chefsenheter på denna nivå inspirerades av systemobjekten i operativsystemet System/38. De hanterare som definieras av DDM inkluderar: ordbok, arbetsledare, agent, katalog, fil(er), åtkomstmetoder, relationsdatabas, SQL-applikationshanterare, kö, låshanterare, säkerhetshanterare, återställningshanterare, systemkommandoprocessor, kommunikationshanterare (s).
  • En server är en självidentifierande enhet som tillhandahåller en miljö för lagring och bearbetning av chefer, antingen som en klient eller en server, i en distribuerad bearbetningsmiljö. Exempel är klienter och servrar specialiserade för distribuerad fil- eller distribuerad relationsdatabashantering.

Medan DDM-arkitekturen är objektorienterad, implementerades DDM-produkterna med de språk och metoder som är typiska för deras värdsystem. En Smalltalk-version av DDM utvecklades för IBM PC av Object Technology International , med lämpliga Smalltalk-klasser skapade automatiskt från DDM Reference Manual.

Delmängder och tillägg

DDM är en öppen arkitektur. DDM-produkter kan implementera delmängder av DDM-arkitektur; de kan också skapa sina egna tillägg.

Kommandot DDM 'Exchange Server Attributes' är det första kommandot som skickas när en klient är ansluten till en server. Den identifierar klienten och specificerar de chefer som klienten kräver och vilken nivå av DDM-arkitektur där stöd krävs. Servern svarar genom att identifiera sig och ange på vilken nivå den stöder de efterfrågade cheferna. En generell regel är att en produkt som stöder nivå X i en DDM-hanterare också måste stödja nivå X-1 så att nya serverprodukter kopplas ihop med äldre klientprodukter.

Underuppsättningar av DDM kan implementeras för att möta olika produktkrav:

  • som klient, server eller båda. Till exempel är DDM/PC bara en klient, CICS/DDM är bara en server och System/38 DDM är både en klient och en server.
  • för att stödja specifika hanterare, såsom postorienterade filer, strömorienterade filer, relationsdatabaser (som en del av DRDA) eller någon kombination därav. Till exempel tillhandahåller MVS Database 2 klient- och serverstöd för endast den delmängd av DDM som krävs av DRDA.
  • för att endast stödja utvalda kommandon från en chef, såsom möjligheten att ladda och ta bort poster från en sekventiell fil.
  • för att stödja valda parametrar för ett kommando, såsom parametern 'Return Inactive Records' för kommandot 'Get Record'.

När en DDM-klient är ansluten till en känd DDM-server, såsom en System/38-klient till en System/38-server, kan DDM-arkitekturen också utökas genom att lägga till

  • nya produktspecifika chefer.
  • nya kommandon till en befintlig DDM-hanterare.
  • nya parametrar till ett DDM-kommando eller ett svarsmeddelande.

Sådana tillägg kan definieras inom DDM:s objektorienterade ramverk så att befintliga DDM-meddelandehanteringsfaciliteter kan användas.

DDM-meddelanden

I en rent objektorienterad implementering av DDM finns klienter och servrar och alla deras inneslutna hanterare och objekt i en minneshög, med pekare (minnesadresser) som används för att koppla ihop dem. Till exempel pekar ett kommandoobjekt på vart och ett av dess parameterobjekt. Men ett kommando kan inte överföras från en klient till en server på detta sätt; en isomorf kopia av kommandot måste skapas som en enda, sammanhängande sträng av bitar. I högen består ett kommando av storleken på kommandot i högen, en pekare till kommandots klass och pekare till vart och ett av kommandots parameterobjekt. Linjäriserat, kommandot består av den totala längden av det linjäriserade kommandot, en kodpunkt som identifierar kommandots klass och vart och ett av dess linjäriserade parameterobjekt. DDM-arkitektur tilldelar unika kodpunkter till varje klass av objekt. Denna enkla teknik används för alla objekt som överförs mellan klienter och servrar, inklusive kommandon, poster och svarsmeddelanden.

Alla dessa linjäriserade objekt placeras i kuvert som gör det möjligt för klient- och serveragenterna att samordna sin bearbetning. I DDM-arkitektur kallas dessa kuvert Data Stream Structures (DSS). Kommandon läggs in i en Request DSS (RQSDSS), svar läggs in i en Reply DSS (RPYDSS), och andra objekt läggs in i en Object DSS (OBJDSS). Det kan bara finnas ett kommando i en RQSDSS och bara ett svar i RPYDSS, men många objekt, såsom poster, kan läggas in i en OBJDSS. Ytterligare många OBJDSSes kan kedjas till en RQSDSS eller en PRYDSS för att rymma så många objekt som behövs. En DSS består av den totala längden av DSS, en flaggbyte som identifierar typen av DSS, en begäranidentifierare och de linjäriserade objekten i DSS. Förfrågningsidentifieraren binder en RQSDSS med efterföljande OBJDSS från klienten, till exempel de poster som ska laddas in i en fil med kommandot Load File . Begärans identifierare binder också RQSDSS från klienten med en RPYDSS eller OBJDSS från servern till klienten.

Dokumentation

DDM-referensmanualen består av namngivna meny-, hjälp- och klassobjekt. Underklasserna av DDM-klass Klass beskrivs av variabler som specificerar

  • klassens superklass. Klasser definieras av en arvshierarki; till exempel är Record File en underklass till File som är en underklass till Manager och ärver deras data och kommandon. Klass Çlass och dess underklasser är självbeskrivande av klasskommandon och klassvariabler , inklusive:
  • en titel som kort beskriver klassen.
  • klassens status i förhållande till pågående arbete med DDM-arkitektur.
  • beskrivande text och grafik som relaterar klassen till dess komponenter och dess miljö.
  • data (fält, objekt, hanterare, etc.) inkapslade av instanser av klassen.
  • kommandona som kan skickas till dess instanser.

Dessa objekt kan innehålla referenser till andra namngivna objekt i text och specifikationer, vilket skapar hypertextlänkar mellan sidorna i DDM Reference Manual. Meny- och hjälpsidor utgör en integrerad handledning om DDM. Pappersversionen av DDM Reference Manual Level 3 är skrymmande, på över 1400 sidor och något besvärlig att använda, men en interaktiv version byggdes också med IBMs interna kommunikationsmöjligheter. Med tanke på den relativt långsamma hastigheten på dessa kommunikationsfaciliteter, användes den främst inom IBM Rochester-laboratoriet.

Utöver DDM-referensmanualen ger ett allmänt informationsdokument information om DDM på chefsnivå, och en programmerares guide sammanfattar DDM-koncept för programmerare som implementerar klienter och servrar.

DDM-filmodeller

Tre allmänna filmodeller definieras av DDM-arkitekturen: postorienterade filer, strömorienterade filer och hierarkiska kataloger.

Följande tjänster tillhandahålls av DDM-arkitekturen för hantering av fjärrfiler:

  • skapa, rensa och ta bort filer,
  • kopiera, ladda och ta bort data från en fil,
  • låsa och låsa upp filer,
  • erhålla och ändra filattribut,

Record-orienterade filer

Record-orienterade filer designades för att möta datainmatning, utdata och lagringskrav för tredje generationens (3GL) programmeringsspråk, såsom Fortran, Cobol, PL/I och RPG. Istället för att varje språk skulle ge sitt eget stöd för dessa funktioner, inkorporerades de i tjänster som tillhandahålls av operativsystem.

En post är en serie relaterade datafält, såsom namn, adress, identifikationsnummer och lön för en enskild anställd, där varje fält är kodat och mappat till en sammanhängande sträng av byte. Tidiga datorer hade begränsade in- och utmatningsmöjligheter, vanligtvis i form av staplar med hålkort med 80 kolumner eller i form av papper eller magnetband. Applikationsposter, såsom personaldataposter, lästes sekventiellt eller skrevs en post åt gången och bearbetades i omgångar. När lagringsenheter för direktåtkomst blev tillgängliga, lade programmeringsspråken till sätt för program att slumpmässigt komma åt poster en i taget, till exempel åtkomst genom värdena i nyckelfält eller genom positionen för en post i en fil. Alla poster i en fil kan ha samma format (som i en lönefil) eller av olika format (som i en händelselogg). Vissa filer är skrivskyddade eftersom deras poster, när de väl skrivits till filen, bara kan läsas, medan andra filer tillåter att deras poster uppdateras.

De DDM-postorienterade filmodellerna består av filattribut, såsom dess skapandedatum, datumet för senaste uppdatering, storleken på dess poster och platser där poster kan lagras. Posterna kan vara av antingen fast eller varierande längd, beroende på vilket medium som används för att lagra filens poster. DDM definierar fyra typer av postorienterade filer:

  • Sekventiella filer, där poster lagras i på varandra följande platser.
  • Direktfiler, där enskilda poster lagras i en plats i filen som bestäms av värdet på ett fält av posterna.
  • Nyckelde filer, i vilka poster lagras i på varandra följande luckor och för vilka en sekundär ordning upprätthålls med hjälp av ett index över värdena för nyckelfält som finns i posterna.
  • Alternativa indexfiler, där ett separat index över värdena för nyckelfält är baserat på en befintlig sekventiell, direkt eller nyckelfil.

DDM-arkitekturen definierar också en mängd olika åtkomstmetoder för att arbeta med postorienterade filer på olika sätt. En åtkomstmetod är en instans av användningen av en fil skapad med hjälp av ett OPEN-kommando som ansluter sig till filen efter att ha fastställt om klienten är behörig att använda den. Åtkomstmetoden kopplas bort från en fil med hjälp av ett CLOSE-kommando.

En åtkomstmetod håller reda på posten som för närvarande bearbetas med hjälp av en markör. Med hjälp av olika SET-kommandon kan markören fås att peka på början eller slutet av filen, på nästa eller föregående sekventiell post i filen, på posten med ett specifikt nyckelvärde, eller till nästa eller föregående post enligt beställning med sina nycklar.

Flera instanser av åtkomstmetoder kan öppnas på en fil samtidigt, var och en betjänar en enda klient. Om en fil öppnas för uppdateringsåtkomst kan konflikter uppstå när samma post nås av flera klienter. För att förhindra sådana konflikter kan ett lås erhållas på en hel fil. Dessutom, om en fil öppnas för uppdatering erhålls ett lås på en post av den första klienten som läser den och släpps när den klienten uppdaterar den. Alla andra klienter måste vänta på att låset släpps.

Stream-orienterade filer

Stream-orienterade filer består av en enda sekvens av byte på vilka program kan mappa applikationsdata hur de vill. Strömfiler är den primära filmodellen som stöds av Unix och Unix-liknande operativsystem och av Windows . DDM definierar en enkelströmsfilmodell och en enkelströmsåtkomstmetod.

DDM-strömfilmodellen består av filattribut, såsom dess skapandedatum och storleken på strömmen och en kontinuerlig ström av byte. Streamen kan nås med hjälp av Stream Access Method. Applikationsprogram skriver data till delar av strömmen, även om dessa data består av poster. De håller reda på platsen för dataobjekt i strömmen på vilket sätt de vill. Till exempel definieras dataströmmen för dokumentfiler av ett textbearbetningsprogram som Microsoft Word och det för en kalkylarksfil av ett program som Microsoft Excel .

En strömåtkomstmetod är en instans av användning av en strömfil av en enskild klient. En markör håller reda på positionen för den aktuella byten av underströmmen som används av klienten. Med hjälp av olika SET-kommandon kan markören fås att peka på början eller slutet av filen, till valfri specifik position i filen, eller till valfri positiv eller negativ förskjutning från den aktuella positionen.

Flera instanser av Stream-åtkomstmetoden kan öppnas på en fil samtidigt, var och en betjänar en enda klient. Om en fil öppnas för "uppdaterings"-åtkomst kan konflikter uppstå när samma underström nås av flera klienter. För att förhindra sådana konflikter kan ett lås erhållas på en hel fil. Dessutom, om en fil öppnas för uppdatering erhålls ett lås på en underström av den första klienten som "läser" den och släpps när den klienten "uppdaterar" den. Alla andra klienter måste vänta på att låset släpps.

Hierarkiska kataloger

Hierarkiska kataloger är filer vars poster var och en associerar ett namn med en plats. En hierarki uppstår när en katalogpost identifierar namnet och platsen för en annan katalog. Med hjälp av DDM-klient- och serverprodukter kan ett program skapa, ta bort och byta namn på kataloger på en fjärrdator. De kan också lista och ändra filattributen för fjärrkataloger. Posterna i en katalog kan läsas sekventiellt med hjälp av DDM Directory Access Method. Filerna som identifieras av katalogposter kan döpas om, kopieras och flyttas till en annan katalog.

DDM-köer

Köer är en kommunikationsmekanism som i allmänhet möjliggör kortsiktig kommunikation mellan program med hjälp av register. En DDM-kö finns i ett enda system, men den kan nås av program på flera system. Det finns tre underklasser av DDM-köer som kan skapas på ett målsystem med hjälp av distinkta skapande kommandon:

  • Först-in-först-ut-köer, ett asynkront rör mellan kö- och urköprogram.
  • Sist-in-först-ut-köer, en pushdown-stack.
  • Nyckelköer, en fan-out-mekanism där valda poster kan urköas efter nyckelvärde.

DDM-kömodellen består av köattribut, såsom dess skapandedatum, antalet poster som kön kan innehålla och längden på posterna. Posterna i en kö kan antingen vara fasta eller varierande.

Till skillnad från DDM-filmodellerna är det inte nödvändigt att öppna en åtkomstmetod i en kö. Program kan lägga till poster i en kö och ta emot poster från en kö som bestäms av köns klass. Program kan också rensa poster från en kö, stoppa operationer på en kö, lista attributen för en kö och ändra attributen för en kö. Program kan också låsa en kö eller enskilda poster i en kö för att förhindra konflikter från andra program. Alla andra klienter måste vänta på att låset släpps.

Relationsdatabaser

En relationsdatabas (RDB) är en implementering av Structured Query Language (SQL) som stöder skapande, hantering, förfrågning, uppdatering, indexering och inbördes relationer mellan datatabeller. En interaktiv användare eller ett interaktivt program kan utfärda SQL-satser till en RDB och ta emot tabeller med data och statusindikatorer som svar. Men SQL-satser kan också kompileras och lagras i RDB som paket och sedan anropas av paketnamn. Detta är viktigt för effektiv drift av applikationsprogram som utfärdar komplexa, högfrekventa frågor. Det är särskilt viktigt när tabellerna som ska nås finns i fjärrsystem.

Distributed Relational Database Architecture) passar bra in i det övergripande DDM-ramverket, som diskuteras i Object-Orientation . (DDM kan dock också ses som en komponentarkitektur för DRDA eftersom andra specifikationer också krävs). Objekten på DDM-hanterarnivå som stöder DRDA heter RDB (för relationsdatabas) och SQLAM (för SQL Application Manager).

Databeskrivning och konvertering

Transparens är ett nyckelmål för DDM-arkitektur. Utan omkompilering bör det vara möjligt att omdirigera befintliga applikationsprogram till datahanteringstjänsterna på en fjärrdator. För filer åstadkoms detta till stor del av DDM-klienter på gränssnitts-/funktionsnivå, men hur är det med datafälten i en post? Fullständig transparens kräver att klientapplikationsprogram kan skriva och läsa fält som kodas av deras lokala datahanteringssystem, oavsett hur någon fjärrserver kodar dem, och det innebär automatiska datakonverteringar .

Till exempel kodar IBM stordatorer med flyttal i hexadecimalt format och teckendata i EBCDIC , medan IBMs persondatorer kodar dem i IEEE- format och ASCII . Ytterligare komplexitet uppstod på grund av de sätt på vilka olika kompilatorer för programmeringsspråk mappar postfält på strängar av bitar, bytes och ord i minnet. Transparent konvertering av en post kräver detaljerade beskrivningar av både klientvyn och servervyn för en post. Givet dessa beskrivningar kan fälten för klient- och servervyerna matchas efter fältnamn och lämpliga konverteringar kan utföras.

Nyckelfrågan är att få tillräckligt detaljerade postbeskrivningar, men postbeskrivningar specificeras i allmänhet abstrakt i applikationsprogram genom deklarationssatser som definieras av programmeringsspråket, med språkkompilatorn som hanterar kodnings- och mappningsdetaljer. I en distribuerad bearbetningsmiljö behövs ett enda, standardiserat sätt att beskriva poster som är oberoende av alla programmeringsspråk, ett som kan beskriva det stora utbudet av fasta och varierande postformat som finns i befintliga filer.

Resultatet blev definitionen av en omfattande Data Description and Conversion- arkitektur (DD&C), baserad på ett nytt, specialiserat programmeringsspråk, A Data Language (ADL), för att beskriva klient- och servervyer av dataposter och för att specificera konverteringar. Kompilerade ADL-program kan sedan anropas av en server för att utföra nödvändiga konverteringar när poster flödar till eller från servern.

DD&C-arkitekturen gick längre och definierade ett sätt med vilket programspråksdeklarationer automatiskt kan konverteras till och från ADL, och därmed från ett programmeringsspråk till ett annat. Denna förmåga implementerades aldrig på grund av dess komplexitet och kostnad. En ADL-kompilator skapades dock och ADL-program anropas, när de är tillgängliga, för att utföra konverteringar av DFM och av IBM 4680 Store System. Det är dock nödvändigt för applikationsprogrammerare att manuellt skriva ADL-programmen.

Implementera produkter

DDM-produkter från IBM

Följande IBM-produkter implementerade olika delmängder av DDM-arkitektur:

DDM-produkter från andra leverantörer

För en fullständig lista över de produkter som har implementerat DRDA, se Open Source DRDA Product Identifier Table .

Se även

Hämtad från " https://en.wikipedia.org/w/index.php?title=Distributed_Data_Management_Architecture&oldid=1123333684 "