Rozproszona architektura zarządzania danymi - Distributed Data Management Architecture

Distributed Data Management Architecture (DDM) to otwarta, opublikowana architektura oprogramowania IBM do tworzenia, zarządzania i uzyskiwania dostępu do danych na zdalnym komputerze. DDM został początkowo zaprojektowany do obsługi plików zorientowanych na rekordy ; został rozszerzony o obsługę katalogów hierarchicznych , plików zorientowanych strumieniowo , kolejek i przetwarzania poleceń systemowych; został następnie rozszerzony, aby stać się podstawą architektury rozproszonej relacyjnej bazy danych IBM (DRDA); i wreszcie został rozszerzony o obsługę opisu i konwersji danych . Zdefiniowany w okresie od 1980 do 1993 roku, DDM określa niezbędne komponenty, komunikaty i protokoły, wszystkie oparte na zasadach orientacji obiektowej . DDM sam w sobie nie jest oprogramowaniem; wdrożenie DDM przybiera formę produktów klienckich i serwerowych. Jako architektura otwarta , produkty mogą implementować podzbiory architektury DDM, a produkty mogą rozszerzać DDM w celu spełnienia dodatkowych wymagań. Podsumowując, produkty DDM implementują rozproszony system plików .

Architektura DDM w mediach.

Aplikacje rozproszone

Projektanci aplikacji rozproszonych muszą określić najlepsze rozmieszczenie programów i danych aplikacji pod względem ilości i częstotliwości przesyłanych danych, a także kwestii związanych z zarządzaniem danymi, bezpieczeństwem i terminowością. Istnieją trzy modele klient-serwer do projektowania aplikacji rozproszonych:

  1. Protokół FTP ( File Transfer Protocol ) kopiuje lub przenosi całe pliki lub tabele bazy danych do każdego klienta, dzięki czemu można je obsługiwać lokalnie. Model ten jest odpowiedni dla wysoce interaktywnych aplikacji, takich jak edytory dokumentów i arkuszy kalkulacyjnych, gdzie każdy klient ma kopię odpowiedniego edytora, a udostępnianie takich dokumentów nie stanowi problemu.
  2. Cienkie aplikacje klienckie przedstawiają interfejs aplikacji użytkownikom, podczas gdy części obliczeniowe aplikacji są scentralizowane z plikami lub bazami danych, których dotyczy problem. Komunikacja składa się wtedy ze zdalnych wywołań procedur między cienkimi klientami a serwerem, w których unikalnie zaprojektowane komunikaty określają procedurę do wywołania, powiązane z nią parametry i wszelkie zwracane wartości.
  3. Grube aplikacje klienckie wykonują wszystkie zadania związane z przetwarzaniem aplikacji w systemach klienckich, ale dane są scentralizowane na serwerze, dzięki czemu można nimi zarządzać, tak aby można było uzyskać do nich dostęp przez dowolną autoryzowaną aplikację kliencką, dzięki czemu wszystkie aplikacje klienckie działają z aktualnymi dane i tak, żeprzesyłane sątylko rekordy , sekcje strumieni lub tabele bazy danych, na które ma wpływ aplikacja. Programy aplikacji klienckich muszą być dystrybuowane do wszystkich klientów, którzy pracują ze scentralizowanymi danymi.

Architektura DDM została początkowo zaprojektowana do obsługi modelu grubego klienta aplikacji rozproszonych; obsługuje również transfery całych plików.

Korzyści zapewniane przez architekturę DDM

Architektura DDM zapewnia aplikacjom rozproszonym następujące korzyści:

  • Przejrzystość lokalna/zdalna. Programy użytkowe można łatwo przekierować z danych lokalnych do danych zdalnych. Nie są potrzebne specjalistyczne programy, które uzyskują dostęp do danych i zarządzają nimi w systemach zdalnych.
  • Zmniejszona nadmiarowość danych. Dane muszą być przechowywane tylko w jednym miejscu w sieci.
  • Lepsze bezpieczeństwo. Eliminując nadmiarowe kopie danych, dostęp do danych w sieci można lepiej ograniczyć do autoryzowanych użytkowników.
  • Integralność danych. Aktualizacje równoczesnych użytkowników lokalnych i zdalnych nie są tracone z powodu konfliktów.
  • Więcej aktualnych informacji. Użytkownicy wielu komputerów w sieci mają zawsze dostęp do najnowszych danych.
  • Lepsze zarządzanie zasobami. Można zoptymalizować zasoby przechowywania i przetwarzania danych w sieci komputerów.

Historia

Architektura DDM to zestaw specyfikacji komunikatów i protokołów, które umożliwiają zarządzanie danymi rozproszonymi w sieci komputerów i uzyskiwanie do nich dostępu.

Początkowe wysiłki

Architektura systemów sieciowych IBM (SNA) została początkowo zaprojektowana w celu umożliwienia hierarchicznego połączenia stacji roboczych z komputerami typu mainframe IBM. Dostępne w tamtym czasie sieci komunikacyjne były sztywno zaprojektowane pod kątem stałych połączeń między komputerem typu mainframe a zestawem stacji roboczych, które znajdowały się pod pełną kontrolą oprogramowania komputera typu mainframe. Inna komunikacja między komputerami typu mainframe również polegała na stałych połączeniach wykorzystywanych przez oprogramowanie zdefiniowane do określonych celów. Ponieważ sieci komunikacyjne stały się bardziej elastyczne i dynamiczne, pożądana była ogólna komunikacja peer-to-peer , w której program na jednym komputerze może inicjować i współdziałać z programem na innym komputerze.

Kiedy na początku lat 80. zdefiniowano architekturę IBM SNA Advanced Program to Program Communications (APPC), stało się jasne, że APPC może być używana do świadczenia usług systemu operacyjnego na zdalnych komputerach. Grupa robocza SNA kontynuowała ten pomysł i przedstawiła kilka możliwych usług rozproszonych, takich jak usługi plików, usługi drukarek i usługi konsoli systemowej, ale nie była w stanie zainicjować rozwoju produktu. Oprogramowanie APPC nie było jeszcze dostępne na komputerach mainframe, a mówiąc bardziej ogólnie, komputery mainframe były nadal postrzegane głównie jako systemy samodzielne. W rezultacie prace nad usługami rozproszonymi zostały zawieszone przez grupę roboczą SNA.

Członkowie grupy roboczej SNA z laboratorium rozwoju IBM Rochester w stanie Minnesota byli przekonani, że istnieje uzasadnienie biznesowe dla usług rozproszonych wśród systemów komputerowych średniej klasy produkowanych w Rochester. Prymitywna forma usług plików rozproszonych, zwana Distributed Data File Facility (DDFF), została zaimplementowana w celu połączenia minikomputerów IBM System/3 , IBM System/34 i IBM System/36 . Ponadto komputery IBM System/36 i IBM System/38 były sprzedawane klientom w wielu egzemplarzach i istniała wyraźna potrzeba umożliwienia, na przykład, komputerom w centrali przedsiębiorstwa interakcji z komputerami w różnych magazynach. APPC został wdrożony w tych systemach i używany przez różne aplikacje klientów. Idea usług rozproszonego systemu operacyjnego odżyła wówczas jako projekt Golden Gate i podjęto próbę uzasadnienia jego rozwoju. Ta próba również się nie powiodła; cała idea usług rozproszonych była zbyt nowa, aby planiści produktów IBM byli w stanie oszacować wartość oprogramowania łączącego heterogeniczne komputery.

Jednak jeden planista Golden Gate , John Bondy, pozostał przekonany i przekonał kierownictwo do utworzenia działu poza normalną kontrolą laboratorium Rochester, tak aby nie było natychmiastowej potrzeby predefiniowanego uzasadnienia biznesowego. Ponadto zawęził swoją misję, aby obejmowała tylko obsługę rozproszonego zarządzania danymi (DDM), w szczególności obsługę plików zorientowanych na rekordy . Następnie przekonał doświadczonego architekta oprogramowania Richarda A. Demersa, aby dołączył do niego w zadaniach definiowania architektury DDM i sprzedaży idei DDM do systemów IBM.

Pierwszy rok tych wysiłków był w dużej mierze bezowocny, ponieważ firmy zajmujące się systemami IBM nadal domagały się wstępnych uzasadnień biznesowych i nalegały, aby formaty wiadomości były izomorficzne z interfejsami bloków kontrolnych ich lokalnych systemów plików. Co więcej, gdy komputery osobiste zaczęły być używane jako terminale podłączane do komputerów typu mainframe, twierdzono, że proste rozszerzenie strumienia danych 3270 umożliwiłoby komputerom dostęp do danych typu mainframe.

W tym okresie firma Demers zaprojektowała model architektoniczny klientów i serwerów DDM, ich komponentów oraz interakcji między komunikującymi się komputerami. Ponadto zdefiniował ogólny format komunikatów DDM oparty na zasadach orientacji obiektowej, których pionierem był język programowania Smalltalk i IBM System/38. Model ten wyjaśniał, w jaki sposób produkty DDM mogą być wdrażane w różnych systemach. Zobacz Jak działa DDM .

W 1982 roku planiści System/36 przekonali się, że istnieje wystarczający rynek dla usług plików DDM zorientowanych na rekordy.

DDM poziom 1: Pliki zorientowane na rekord

Ogólny format komunikatów DDM został już zaprojektowany, ale jakie konkretnie komunikaty należy zdefiniować? System plików System/36 został zdefiniowany w celu zaspokojenia potrzeb zorientowanych na rekordy języków programowania trzeciej generacji (3GL), takich jak Fortran , COBOL , PL/I i IBM RPG , podobnie jak system plików System/38 i System plików Virtual Storage Access Method (VSAM) komputerów mainframe IBM. A jednak ich rzeczywiste urządzenia i interfejsy znacznie się różniły, więc jakie urządzenia i interfejsy powinna obsługiwać architektura DDM? Zobacz pliki zorientowane na rekordy .

Początkowe prace nad DDM w ramach projektu Golden Gate podążały za międzynarodowym standardem dostępu i zarządzania plikami ( FTAM ) dla plików rozproszonych, ale były bardzo abstrakcyjne i trudne do zmapowania do lokalnych usług plików. W rzeczywistości była to jedna z barier w akceptacji przez systemy IBM. Kenneth Lawrence, architekt systemu odpowiedzialny za usługi plików System/36, twierdził, że lepiej byłoby zdefiniować komunikaty, które przynajmniej jeden system IBM mógłby łatwo zaimplementować, a następnie pozwolić innym systemom żądać wszelkich niezbędnych zmian. Naturalnie opowiadał się za wsparciem wymagań Systemu/36. Po roku niepowodzeń w sprzedaży idei DDM innym firmom zajmującym się systemami IBM, argumenty Lawrence'a przeważyły.

Richard Sanders dołączył do zespołu zajmującego się architekturą DDM i współpracował z Lawrence i Demers w celu zdefiniowania konkretnych komunikatów potrzebnych dla System/36 DDM. Postęp w definiowaniu DDM zachęcił System/38 również do udziału. Rozszerzyło to zakres obsługi plików rekordów DDM, aby spełnić wiele wymagań zaawansowanego systemu plików System/38.

Pliki istnieją w kontekście zapewnianym przez system operacyjny, który udostępnia usługi organizowania plików, udostępniania ich równoczesnym użytkownikom oraz zabezpieczania ich przed nieuprawnionym dostępem. Na poziomie 1 DDM dostęp do zdalnych katalogów plików nie był obsługiwany poza transmisją pełnej nazwy pliku, który ma być używany. Wymagane było jednak bezpieczeństwo i udostępnianie. Sanders wykonał prace projektowe w tych obszarach. Sanders zdefiniował również określone protokoły dotyczące korzystania z urządzeń komunikacyjnych, które zostały włączone do komponentu o nazwie Menedżer komunikacji konwersacyjnej DDM. Początkowo zaimplementowany przy użyciu APPC, później został zaimplementowany przy użyciu protokołu TCP/IP .

Wraz z ukończeniem produktu System/36 DDM, Lawrence współpracował z programistami z IBM Hursley Park w Wielkiej Brytanii nad dostosowaniem większości oprogramowania serwera System/36 DDM do użytku w środowisku przetwarzania transakcji IBM Customer Information Control System (CICS). dzięki temu CICS jest serwerem DDM dla systemów operacyjnych mainframe MVS i VSE. Lawrence współpracował również z programistami z laboratorium IBM Cary w Północnej Karolinie nad wdrożeniem klienta zorientowanego na rekordy DDM dla IBM PC DOS .

Poziom 1 architektury DDM został formalnie opublikowany w 1986 roku. W momencie tego ogłoszenia firma IBM przyznała Kennethowi Lawrence'owi nagrodę za wybitne osiągnięcia techniczne , Richardowi Sandersowi nagrodę za wybitny wkład , a Richardowi Demersowi nagrodę za wybitne osiągnięcia .

  • W niniejszym artykule termin System/38 będzie odtąd używany w odniesieniu do Systemu/38 i jego następców: IBM AS/400 (który połączył funkcjonalność Systemu/36 i Systemu/38), IBM iSeries oraz IBM Power Series (która połączyła iSeries z IBM RS/6000, linią produktów IBM do serwerów i stacji roboczych opartych na RISC/UNIX).

DDM poziom 2: Hierarchiczne katalogi i pliki zorientowane strumieniowo

Wraz z rosnącym znaczeniem IBM PC i systemu operacyjnego Unix w środowiskach sieciowych, wsparcie DDM było również potrzebne dla hierarchicznych katalogów i plików zorientowanych strumieniowo na komputerze osobistym IBM z systemem IBM PC DOS i IBM RS/6000 z systemem IBM AIX ( wersja systemu Unix firmy IBM). Zobacz Pliki zorientowane strumieniowo .

Architektura DDM Level 2 została opublikowana w 1988 roku. Jan Fisher i Sunil Gaitonde wykonali większość prac nad architekturą nad obsługą DDM dla katalogów i plików strumieniowych.

DDM poziom 3: Usługi relacyjnych baz danych

W 1986 roku IBM wypuścił na rynek cztery różne produkty relacyjnych baz danych (RDB), z których każdy został stworzony dla określonego systemu operacyjnego IBM. Naukowcy z Laboratorium Badawczego Almaden firmy IBM opracowali System/R*, prototyp rozproszonego RDB i uznali, że nadszedł czas, aby przekształcić go w produkty nadające się do sprzedaży. Jednak System/R* był oparty na System/R, prototypie badawczym RDB i nie można go było łatwo dodać do produktów IBM RDB. Zobacz omówienie baz RDB w środowisku przetwarzania rozproszonego.

Roger Reinsch z IBM Santa Theresa Programming Center kierował zespołem zajmującym się różnymi produktami, aby zdefiniować architekturę rozproszonej relacyjnej bazy danych (DRDA). Zaciągnął:

  • Przedstawiciele każdego z czterech produktów IBM RDB.
  • Bruce Lindsay, badacz Systemu/R*,
  • Paul Roever (z laboratorium IBM Sindelfingen, Niemcy), który opracował specyfikację opisu danych zwaną Formatted Data: Object Content Architecture (FD:OCA).
  • Richard Sanders i Richard Demers z zespołu ds. architektury DDM w celu zdefiniowania odpowiednich modeli, komunikatów i protokołów.

W 1990 r. w tym samym czasie zostały opublikowane DDM Architecture Level 3 i DRDA. Zarówno DDM, jak i DRDA zostały wyznaczone jako strategiczne komponenty architektury aplikacji systemowych IBM (SAA). DRDA został wdrożony przez wszystkie cztery produkty IBM RDB oraz przez innych dostawców.

Nagrody przyznano kluczowym uczestnikom projektu DRDA. Richard Sanders otrzymał nagrodę Outstanding Contribution Award, a Roger Reinsch i Richard Demers otrzymał nagrodę Outstanding Innovation Awards .

DDM poziom 4: Usługi dodatkowe

Projekt Distributed File Management (DFM) został zainicjowany w celu dodania usług DDM do systemu operacyjnego IBM MVS, aby umożliwić programom na zdalnych komputerach tworzenie, zarządzanie i dostęp do plików VSAM . John Hufferd, kierownik projektu DFM, szukał w zespole DDM Architecture możliwości konwersji pól danych w rekordach podczas ich przepływu między systemami. Richard Demers objął prowadzenie w tej kwestii, wspomagany przez Koichi Yamaguchi z projektu DFM. Zobacz Opis i konwersja danych .

Następujące usługi dodatkowe zostały zdefiniowane przez Richarda Sandersa, Jana Fishera i Sunila Gaitonde w architekturze DDM na poziomie 4:

  • Do DFM, zarządzania pamięcią masową i atrybutów plików zdefiniowanych przez użytkownika.
  • W przypadku DRDA, dwufazowe protokoły kontroli zobowiązań dla rozproszonych jednostek pracy skierowanych do aplikacji.
  • Kolejki, które można tworzyć, usuwać lub usuwać na zdalnym serwerze. Wpisy kolejki to zdefiniowane przez aplikację rekordy, które są dodawane lub odbierane z kolejki. Zobacz Kolejki DDM .
  • System Command Processor, menedżer, do którego można wysyłać polecenia zdefiniowane przez system hosta serwera w celu wykonania.
  • Multi-tasking Communications Manager, który umożliwia wielu agentom klienta komunikowanie się z odpowiednimi agentami serwera za pomocą pojedynczej konwersacji między systemem klienta i serwera.
  • Menedżer punktów synchronizacji koordynuje logiczne jednostki pracy na wielu serwerach DDM. Protokoły zobowiązań dwufazowych zapewniają skoordynowane odzyskiwanie zasobów w przypadku awarii dowolnej logicznej jednostki pracy.

Poziom 4 architektury DDM został opublikowany w 1992 roku.

DDM poziom 5: Usługi biblioteczne

Prace nad architekturą na poziomie DDM 5 polegały na wsparciu

  • partycjonowane zestawy danych mainframe , które są plikami składającymi się z katalogu wewnętrznego i wielu elementów członkowskich; w efekcie są to biblioteki podobnych plików.
  • Biblioteki komputerów osobistych , które konsolidują dostęp do plików w wielu folderach w jednej bibliotece.
  • dalsze ulepszenia DRDA.

Jan Fisher był architektem odpowiedzialnym za DDM level 5, który został opublikowany przez Open Group , a nie przez IBM. Wkrótce potem grupa zajmująca się architekturą IBM DDM została rozwiązana.

Wewnątrz DDM

Architektura DDM to formalnie zdefiniowany i wysoce ustrukturyzowany zestaw specyfikacji. W tej sekcji przedstawiono kluczowe koncepcje techniczne leżące u podstaw DDM.

Jak działa DDM

Przegląd przetwarzania DDM

Architektura DDM definiuje protokół klient/serwer; to znaczy, że klient żąda usług od serwera, który wchodzi w interakcję ze swoimi lokalnymi zasobami w celu wykonania żądanej usługi, której wyniki, dane i wskaźniki stanu, są zwracane do klienta. Powyższy diagram ilustruje role klientów i serwerów DDM w odniesieniu do zasobów lokalnych. ( Używana jest tutaj powszechna terminologia klientów i serwerów , ale w architekturze DDM klient jest nazywany serwerem źródłowym, a serwer nazywany jest serwerem docelowym ).

  1. Program użytkowy współdziała z lokalnym zasobem, takim jak plik, za pomocą interfejsów programistycznych udostępnianych przez lokalnego menedżera zasobów (LRM). Jeśli jednak żądany zasób znajduje się na komputerze zdalnym, do pośredniczenia w interakcji używany jest DDM. Aplikacja nadal korzysta z interfejsów udostępnianych przez LRM, ale są one przekierowywane do klienta DDM. Architektura DDM nie określa, w jaki sposób ma nastąpić przekierowanie, ponieważ nie obsługuje katalogu zasobów zdalnych. Jedną z metod przekierowania używanych przez kilka produktów zorientowanych na pliki DDM jest otwarcie przez aplikację specjalnego pliku lokalnego, zwanego przez System/38 plikiem DDM , który zapewnia informacje o lokalizacji i dostępie do pliku zdalnego. Następnie następuje przekierowanie do klienta DDM.
  2. Architektura DDM definiuje jednostki na poziomie menedżera dla plików, relacyjnych baz danych, metod dostępu itp. Menedżer zasobów klienta (CRM) polimorficznie obsługuje interfejsy funkcjonalne zdefiniowane przez LRM systemu klienta. Jego podstawową funkcją jest generowanie odpowiednich zlinearyzowanych poleceń i obiektów danych DDM dla każdego interfejsu funkcjonalnego. (Zobacz Komunikaty DDM .) Te obiekty są wysyłane do menedżera zasobów serwera (SRM) zdalnego serwera DDM. W rzeczywistości jednak są one kierowane przez agentów klienta i serwera DDM oraz menedżerów ds. komunikacji.
  3. Agent klienta DDM umieszcza zlinearyzowaną komendę w kopercie RQSDSS, a zlinearyzowane obiekty w połączonych kopertach OBJDSS. (Zobacz Komunikaty DDM .) Agent klienta współdziała z agentem serwera, aby utworzyć ścieżkę dla komunikatów, które otrzymuje z CRM, aby przepływały do ​​SRM. Jeśli aplikacja wymaga interakcji tylko z jednym zdalnym zasobem, jest to proste. Istnieje jednak możliwość jednoczesnej interakcji aplikacji z wieloma zasobami różnego rodzaju, które znajdują się w wielu systemach zdalnych. Agent klienta reprezentuje program aplikacji we wszystkich przypadkach i kieruje komunikaty oddzielnymi ścieżkami wirtualnymi do każdego zasobu.
  4. Menedżer komunikacji klienta współdziała z Menedżerem komunikacji serwera w celu zaimplementowania protokołu konwersacyjnego w postaci „Mówię, gdy ty słuchasz, a następnie mówisz, gdy ja słucham”. Można używać różnych protokołów telekomunikacyjnych, w tym SNA APPC firmy IBM i internetowego protokołu TCP/IP.
  5. Komunikaty DDM przesyłane do Menedżera komunikacji serwera są przekazywane do agenta serwera na ścieżce określonej przez komunikat, a on przekazuje komunikaty do SRM na tej samej ścieżce. Jeśli agent serwera wchodzi w interakcję z pojedynczym klientem na jednej ścieżce, jest to proste. Jednak agent serwera może współdziałać z wieloma klientami na wielu ścieżkach.
  6. Menedżer zasobów serwera (SRM) analizuje komunikaty DDM i określa, co musi zrobić, aby wykonać żądanie. Może wykorzystywać jeden lub więcej interfejsów funkcjonalnych odpowiedniego lokalnego menedżera zasobów (LRM) systemu serwera.
  7. SRM gromadzi dane i wskaźniki stanu z LRM i generuje odpowiednie linearyzowane obiekty oraz komunikaty zwrotne, które przekazuje do Agenta Serwera.
  8. Agent serwera pakuje odpowiedzi i obiekty w koperty RPYDSS i OBJDSS i przekazuje je do Menedżera komunikacji serwera, który wysyła je do Menedżera komunikacji klienta i agenta klienta w tej samej ścieżce, co oryginalne polecenie.
  9. Agent klienta usuwa odpowiedź i obiekty z odpowiednich kopert RPYDSS i OBJDSS i przekazuje je do Menedżera zasobów klienta.
  10. Menedżer zasobów klienta analizuje zwrócony obiekt i komunikaty odpowiedzi oraz mapuje je zgodnie z oczekiwaniami interfejsu funkcjonalnego oryginalnego LRM w celu powrotu do programu aplikacji.

Orientacja obiektowa

Architektura DDM jest zorientowana obiektowo . Wszystkie jednostki zdefiniowane przez DDM są obiektami zdefiniowanymi przez samodefiniujące się obiekty klasy . Komunikaty, odpowiedzi i dane, które przepływają między systemami, są obiektami serializowanymi. Każdy obiekt określa swoją długość, identyfikuje swoją klasę za pomocą punktu kodowego DDM i zawiera dane zdefiniowane przez jego klasę. Ponadto jego klasa określa polecenia, które mogą być wysyłane do jego instancji, gdy obiekt znajduje się w kliencie lub serwerze DDM, tym samym hermetyzując obiekt za pomocą ograniczonego zestawu operacji.

Strukturalnie architektura DDM składa się z hierarchicznych poziomów obiektów, przy czym każdy poziom przejawia wyłaniające się właściwości na coraz wyższych poziomach.

  • Pole to ciąg bitów, który koduje liczbę, znak lub inną jednostkę danych. Wystąpienia podklasy Field są hermetyzowane przez operacje, które mogą być wykonywane przez jej klasę; na przykład operacje arytmetyczne na polach liczb całkowitych.
  • Obiekt to samoidentyfikująca się jednostka składająca się z jednego lub więcej pól zawartych w określonym zestawie operacji. Obiekty na tym poziomie zostały zainspirowane klasami obiektów jądra języka programowania Smalltalk
    • Obiekt skalarny składa się z jednego pola, zgodnie z zakodowaniem i opisem w klasie obiektu. Obiekty skalarne są używane jako wartości parametrów obiektów poleceń i odpowiedzi. Są one również używane jako wartości atrybutów obiektu, takich jak długość obiektu w dokumentacji DDM. Metody kodowania używane dla wartości tych obiektów skalarnych są w pełni zdefiniowane przez architekturę DDM.
    • Zmapowany obiekt składa się z jednego lub więcej pól, takich jak pola rekordu zdefiniowanego w aplikacji. Metody kodowania i wyrównanie tych pól nie są zdefiniowane przez architekturę DDM; zamiast tego jest definiowany przez deklaracje programu aplikacji oraz metody kodowania i wyrównywania jego języka programowania.
    • Obiekt kolekcji to kontener na obiekty, zgodnie z definicją klasy kolekcji. Przykładami obiektów kolekcji są polecenia i odpowiedzi DDM.
  • Menedżer to samoidentyfikująca się jednostka, która zapewnia środowisko do przechowywania i przetwarzania obiektów. Menedżer jest hermetyzowany przez operacje zdefiniowane przez jego klasę. Wspólnie zespół menedżerów wdraża ogólne środowisko przetwarzania klienta lub serwera DDM. Encje menedżera na tym poziomie zostały zainspirowane obiektami systemowymi systemu operacyjnego System/38. Menedżerowie zdefiniowani przez DDM to: słownik, nadzorca, agent, katalog, plik(i), metody dostępu, relacyjna baza danych, menedżer aplikacji SQL, kolejka, menedżer zamków, menedżer ds. bezpieczeństwa, menedżer odzyskiwania, systemowy procesor poleceń, menedżer ds. komunikacji (s).
  • Serwer to samoidentyfikująca się jednostka, która zapewnia środowisko do przechowywania i przetwarzania menedżerów, jako klienta lub serwera, w środowisku przetwarzania rozproszonego. Przykładami są klienci i serwery wyspecjalizowane w zarządzaniu plikami rozproszonymi lub rozproszonymi relacyjnymi bazami danych.

Chociaż architektura DDM jest zorientowana obiektowo, produkty DDM zostały zaimplementowane przy użyciu języków i metod typowych dla ich systemów hostów. Wersja Smalltalk DDM została opracowana dla IBM PC przez Object Technology International , z odpowiednimi klasami Smalltalk utworzonymi automatycznie na podstawie podręcznika DDM Reference Manual.

Podzbiory i rozszerzenia

DDM to otwarta architektura. Produkty DDM mogą implementować podzbiory architektury DDM; mogą również tworzyć własne rozszerzenia.

Polecenie DDM „Exchange Server Attributes” jest pierwszym poleceniem wysyłanym, gdy klient jest połączony z serwerem. Identyfikuje klienta i określa menedżerów wymaganych przez klienta oraz poziom architektury DDM, na którym wymagane jest wsparcie. Serwer odpowiada identyfikując się i określając, na jakim poziomie obsługuje żądanych menedżerów. Ogólna zasada jest taka, że ​​produkt obsługujący poziom X menedżera DDM musi również obsługiwać poziom X-1, aby nowe produkty serwerowe mogły łączyć się ze starszymi produktami klienckimi.

Podzbiory DDM można wdrożyć, aby spełnić różne wymagania dotyczące produktu:

  • jako klient, serwer lub oba. Na przykład DDM/PC to tylko klient, CICS/DDM to tylko serwer, a System/38 DDM to zarówno klient, jak i serwer.
  • do obsługi określonych menedżerów, takich jak pliki zorientowane na rekordy, pliki zorientowane na strumień, relacyjne bazy danych (w ramach DRDA) lub dowolna ich kombinacja. Na przykład MVS Database 2 zapewnia obsługę klienta i serwera tylko dla podzbioru DDM wymaganego przez DRDA.
  • do obsługi tylko wybranych poleceń menedżera, takich jak możliwość ładowania i rozładowywania rekordów z pliku sekwencyjnego.
  • do obsługi wybranych parametrów polecenia, takich jak parametr „Zwróć nieaktywne rekordy” polecenia „Pobierz rekord”.

Gdy klient DDM jest połączony ze znanym serwerem DDM, takim jak klient System/38 z serwerem System/38, architekturę DDM można również rozszerzyć, dodając

  • nowych menedżerów konkretnych produktów.
  • nowe polecenia do istniejącego menedżera DDM.
  • nowe parametry do polecenia DDM lub wiadomości zwrotnej.

Takie rozszerzenia można zdefiniować w ramach zorientowanej obiektowo struktury DDM, aby można było wykorzystać istniejące narzędzia obsługi komunikatów DDM.

Wiadomości DDM

W czysto obiektowej implementacji DDM klienci i serwery oraz wszystkie zawarte w nich menedżery i obiekty istnieją na stercie pamięci, ze wskaźnikami (adresami pamięci) używanymi do ich wzajemnego łączenia. Na przykład obiekt polecenia wskazuje na każdy z jego obiektów parametrów. Ale w ten sposób nie można przesłać polecenia od klienta do serwera; izomorficzna kopia polecenia musi być utworzona jako pojedynczy, ciągły ciąg bitów. W stercie polecenie składa się z rozmiaru polecenia w stercie, wskaźnika do klasy polecenia i wskaźników do każdego z obiektów parametrów polecenia. Zlinearyzowane, polecenie składa się z całkowitej długości zlinearyzowanego polecenia, punktu kodowego identyfikującego klasę polecenia oraz każdego z jego zlinearyzowanych obiektów parametrów. Architektura DDM przypisuje unikalne punkty kodowe do każdej klasy obiektu. Ta prosta technika jest używana do wszystkich obiektów przesyłanych między klientem a serwerami, w tym poleceń, rekordów i wiadomości zwrotnych.

Wszystkie te linearyzowane obiekty są umieszczane w kopertach, które umożliwiają klientowi i serwerowi koordynację ich przetwarzania. W architekturze DDM te obwiednie nazywane są strukturami strumienia danych (DSS). Polecenia są umieszczane w Request DSS (RQSDSS), odpowiedzi są umieszczane w Reply DSS (RPYDSS), a inne obiekty są umieszczane w Object DSS (OBJDSS). W RQSDSS może być tylko jedna komenda i tylko jedna odpowiedź w RPYDSS, ale wiele obiektów, takich jak rekordy, można umieścić w OBJDSS. Ponadto wiele obiektów OBJDSS może być połączonych łańcuchowo z RQSDSS lub PRYDSS, aby pomieścić tyle obiektów, ile jest to konieczne. DSS składa się z całkowitej długości DSS, bajtu flagi identyfikującego typ DSS, identyfikatora żądania i linearyzowanych obiektów w DSS. Identyfikator żądania wiąże RQSDSS z kolejnymi OBJDSS od klienta, takimi jak rekordy, które mają być załadowane do pliku za pomocą komendy Ładuj plik . Identyfikator żądania wiąże również RQSDSS od klienta z RPYDSS lub OBJDSS z serwera do klienta.

Dokumentacja

Podręcznik DDM Reference składa się z nazwanych obiektów Menu, Help i Class. Podklasy klasy DDM Class są opisane przez zmienne, które określają:

  • superklasa klasy. Klasy są zdefiniowane przez hierarchię dziedziczenia; na przykład Record File jest podklasą File, która jest podklasą Managera i dziedziczy ich dane i polecenia. Klasa Çlass i jej podklasy są samoopisujące się za pomocą poleceń çlass i zmiennych klas , w tym:
  • tytuł, który pokrótce opisuje klasę.
  • status klasy w stosunku do trwających prac nad architekturą DDM.
  • tekst opisowy i grafika odnoszące się do klasy z jej elementami składowymi i środowiskiem.
  • dane (pola, obiekty, menedżerowie itp.) zawarte w instancjach klasy.
  • komendy, które można wysyłać do jego instancji.

Obiekty te mogą zawierać odniesienia do innych nazwanych obiektów w tekście i specyfikacjach, tworząc w ten sposób powiązania hipertekstowe między stronami podręcznika DDM Reference Manual. Strony menu i pomocy tworzą zintegrowany samouczek na temat DDM. Papierowa wersja podręcznika DDM Reference Manual Level 3 jest obszerna, liczy ponad 1400 stron i jest nieco niewygodna w użyciu, ale zbudowano również wersję interaktywną przy użyciu wewnętrznych narzędzi komunikacyjnych IBM. Biorąc pod uwagę stosunkowo niską prędkość tych urządzeń komunikacyjnych, był on używany głównie w laboratorium IBM Rochester.

Oprócz podręcznika DDM Reference Manual, dokument Informacje ogólne zawiera informacje na temat DDM dla kadry kierowniczej, a Podręcznik programisty podsumowuje koncepcje DDM dla programistów wdrażających klientów i serwery.

Modele plików DDM

Architektura DDM definiuje trzy ogólne modele plików: pliki zorientowane na rekordy, pliki zorientowane na strumień i katalogi hierarchiczne.

Następujące usługi są dostarczane przez architekturę DDM do zarządzania plikami zdalnymi:

  • tworzenie, czyszczenie i usuwanie plików,
  • kopiowanie, ładowanie i rozładowywanie danych pliku,
  • blokowanie i odblokowywanie plików,
  • pozyskiwanie i zmiana atrybutów plików,

Pliki zorientowane na rekord

Pliki zorientowane na rekordy zostały zaprojektowane tak, aby spełnić wymagania dotyczące wprowadzania, wyprowadzania i przechowywania danych języków programowania trzeciej generacji (3GL), takich jak Fortran, Cobol, PL/I i RPG. Zamiast tego, aby każdy język zapewniał własne wsparcie dla tych możliwości, zostały one włączone do usług dostarczanych przez systemy operacyjne.

Rekord to seria powiązanych pól danych, takich jak imię i nazwisko, adres, numer identyfikacyjny oraz wynagrodzenia jednego pracownika, w której każde pole jest kodowany i odwzorowywany na ciągły ciąg bajtów. Wczesne komputery miały ograniczone możliwości wejścia i wyjścia, zwykle w postaci stosów 80-kolumnowych kart dziurkowanych lub w postaci papieru lub taśmy magnetycznej. Rekordy aplikacji, takie jak rekordy danych pracowników, były kolejno odczytywane lub zapisywane po jednym rekordzie i przetwarzane w partiach. Kiedy urządzenia pamięci masowej o dostępie bezpośrednim stały się dostępne, języki programowania dodawały sposoby, aby programy miały losowy dostęp do rekordów pojedynczo, na przykład dostęp za pomocą wartości pól kluczowych lub pozycji rekordu w pliku. Wszystkie rekordy w pliku mogą mieć ten sam format (jak w pliku listy płac) lub różne formaty (jak w dzienniku zdarzeń). Niektóre pliki są tylko do odczytu, ponieważ ich rekordy, po zapisaniu do pliku, mogą być tylko odczytywane, podczas gdy inne pliki umożliwiają aktualizację ich rekordów.

Modele plików DDM zorientowane na rekordy składają się z atrybutów pliku, takich jak data utworzenia, data ostatniej aktualizacji, rozmiar rekordów i miejsca, w których można przechowywać rekordy. Rekordy mogą mieć stałą lub różną długość, w zależności od nośnika używanego do przechowywania rekordów pliku. DDM definiuje cztery rodzaje plików zorientowanych na rekordy:

  • Pliki sekwencyjne, w których rekordy są przechowywane w kolejnych slotach.
  • Pliki bezpośrednie, w których poszczególne rekordy są przechowywane w slocie pliku określonym przez wartość pola rekordów.
  • Pliki z kluczami, w których rekordy są przechowywane w kolejnych slotach i dla których kolejność wtórna jest utrzymywana za pomocą indeksu wartości pól kluczowych zawartych w rekordach.
  • Alternatywne pliki indeksów, w których osobny indeks wartości pól kluczowych jest oparty na istniejącym pliku sekwencyjnym, bezpośrednim lub z kluczami.

Architektura DDM definiuje również różne metody dostępu do pracy z plikami zorientowanymi na rekordy na różne sposoby. Metoda dostępu to instancja użycia pliku utworzonego za pomocą komendy OPEN, która łączy się z plikiem po ustaleniu, czy klient jest uprawniony do korzystania z niego. Sposób dostępu jest odłączany od pliku za pomocą polecenia CLOSE.

Metoda dostępu śledzi aktualnie przetwarzany rekord za pomocą kursora. Używając różnych poleceń SET, kursor może wskazywać początek lub koniec pliku, następny lub poprzedni sekwencyjny rekord pliku, rekord z określoną wartością klucza lub następny lub poprzedni rekord zgodnie z zamówieniem przez ich klucze.

W pliku można jednocześnie otworzyć wiele wystąpień metod dostępu, z których każda obsługuje jednego klienta. Jeśli plik zostanie otwarty w celu uzyskania dostępu do aktualizacji, mogą wystąpić konflikty, gdy do tego samego rekordu uzyskuje dostęp wielu klientów. Aby zapobiec takim konfliktom, można nałożyć blokadę na cały plik. Ponadto, jeśli plik jest otwierany w celu aktualizacji, blokowanie rekordu jest uzyskiwane przez pierwszego klienta w celu jego odczytania i zwalniane, gdy ten klient go aktualizuje. Wszyscy pozostali klienci muszą czekać na zwolnienie blokady.

Pliki zorientowane strumieniowo

Pliki zorientowane strumieniowo składają się z pojedynczej sekwencji bajtów, na których programy mogą dowolnie mapować dane aplikacji. Pliki strumieniowe są podstawowym modelem plików obsługiwanym przez systemy operacyjne uniksowe i uniksopodobne oraz system Windows . DDM definiuje model pliku z pojedynczym strumieniem i metodę dostępu do pojedynczego strumienia.

Model pliku strumienia DDM składa się z atrybutów pliku, takich jak data utworzenia i rozmiar strumienia oraz ciągły strumień bajtów. Dostęp do strumienia można uzyskać za pomocą metody dostępu do strumienia. Programy aplikacji zapisują dane w częściach strumienia, nawet jeśli te dane składają się z rekordów. Śledzą lokalizację elementów danych w strumieniu w dowolny sposób. Na przykład strumień danych plików dokumentów jest definiowany przez program do przetwarzania tekstu, taki jak Microsoft Word, a strumień danych z pliku arkusza kalkulacyjnego przez program, taki jak Microsoft Excel .

Metoda dostępu Stream to wystąpienie użycia pliku strumieniowego przez pojedynczego klienta. Kursor śledzi pozycję bieżącego bajtu podstrumienia używanego przez klienta. Używając różnych poleceń SET, kursor może wskazywać początek lub koniec pliku, dowolną określoną pozycję w pliku lub dowolne dodatnie lub ujemne przesunięcie względem bieżącej pozycji.

W pliku można jednocześnie otworzyć wiele wystąpień metody dostępu Stream, z których każde obsługuje jednego klienta. Jeśli plik zostanie otwarty w celu uzyskania dostępu do aktualizacji, mogą wystąpić konflikty, gdy do tego samego strumienia podrzędnego uzyskuje dostęp wielu klientów. Aby zapobiec takim konfliktom, można nałożyć blokadę na cały plik. Ponadto, jeśli plik jest otwierany do aktualizacji, pierwszy klient uzyskuje blokadę w strumieniu podrzędnym, aby go „odczytać” i zwolnić, gdy ten klient go „zaktualizuje”. Wszyscy pozostali klienci muszą czekać na zwolnienie blokady.

Katalogi hierarchiczne

Katalogi hierarchiczne to pliki, których rekordy kojarzą nazwę z lokalizacją. Hierarchia występuje, gdy rekord katalogu identyfikuje nazwę i lokalizację innego katalogu. Korzystając z produktów klienckich i serwerowych DDM, program może tworzyć, usuwać i zmieniać nazwy katalogów na zdalnym komputerze. Mogą również wyświetlać i zmieniać atrybuty plików katalogów zdalnych. Rekordy w katalogu można sekwencyjnie odczytywać za pomocą metody dostępu do katalogu DDM. Pliki identyfikowane przez rekordy katalogów można zmieniać, kopiować i przenosić do innego katalogu.

Kolejki DDM

Kolejki to mechanizm komunikacji, który umożliwia ogólnie krótkotrwałą komunikację między programami za pomocą rekordów. Kolejka DDM znajduje się w jednym systemie, ale dostęp do niej mogą uzyskiwać programy w wielu systemach. Istnieją trzy podklasy kolejek DDM, które można tworzyć w systemie docelowym za pomocą różnych poleceń tworzenia:

  • Kolejki pierwszy-w-pierwszy-wyjściowy, asynchroniczny potok między wstawiającymi i usuwającymi kolejkę programami.
  • Kolejki last-in-first-out, stos pushdown.
  • Kolejki z kluczami, mechanizm rozszerzający, w którym wybrane wpisy mogą być usuwane z kolejki według wartości klucza.

Model kolejki DDM składa się z atrybutów kolejki, takich jak data utworzenia, liczba rekordów, które kolejka może zawierać, oraz długość rekordów. Rekordy w kolejce mogą mieć stałą lub różną długość.

W przeciwieństwie do modeli plików DDM nie jest konieczne otwieranie metody dostępu w kolejce. Programy mogą dodawać rekordy do kolejki i odbierać rekordy z kolejki zgodnie z klasą kolejki. Programy mogą również usuwać rekordy z kolejki, zatrzymywać operacje na kolejce, wyświetlać listę atrybutów kolejki i zmieniać atrybuty kolejki. Programy mogą również blokować kolejkę lub pojedyncze rekordy w kolejce, aby uniemożliwić rywalizację z innymi programami. Wszyscy pozostali klienci muszą czekać na zwolnienie blokady.

Relacyjne bazy danych

Relacyjnej bazy danych (RDB) jest realizacja Structured Query Language (SQL), który umożliwia tworzenie, zarządzanie, zapytań, aktualizacja, indeksowanie i wzajemne tabel danych. Interaktywny użytkownik lub program może wysyłać instrukcje SQL do bazy danych RDB i otrzymywać w odpowiedzi tabele danych i wskaźniki stanu. Jednak instrukcje SQL mogą być również kompilowane i przechowywane w RDB jako pakiety, a następnie wywoływane przez nazwę pakietu. Jest to ważne dla wydajnego działania programów użytkowych, które wysyłają złożone zapytania o wysokiej częstotliwości. Jest to szczególnie ważne, gdy tabele, do których chcesz uzyskać dostęp, znajdują się w systemach zdalnych.

Architektura rozproszonej relacyjnej bazy danych (DRDA) dobrze pasuje do ogólnej struktury DDM, jak omówiono w Object-Orientation . (Jednak DDM może być również postrzegany jako architektura składowa DRDA, ponieważ wymagane są również inne specyfikacje). Obiekty poziomu menedżera DDM obsługujące DRDA są nazywane RDB (dla relacyjnej bazy danych) i SQLAM (dla SQL Application Manager).

Opis i konwersja danych

Przejrzystość jest kluczowym celem architektury DDM. Bez rekompilacji powinno być możliwe przekierowanie istniejących aplikacji do usług zarządzania danymi na komputerze zdalnym. W przypadku plików zostało to w dużej mierze osiągnięte przez klientów DDM na poziomie interfejsu/funkcjonalności, ale co z polami danych w rekordzie? Pełna przejrzystość wymaga, aby aplikacje klienckie były w stanie zapisywać i odczytywać pola zakodowane przez lokalny system zarządzania danymi, niezależnie od tego, jak koduje je zdalny serwer, a to oznacza automatyczną konwersję danych .

Na przykład komputery typu mainframe IBM kodują liczby zmiennoprzecinkowe w formacie szesnastkowym , a dane znakowe w EBCDIC , podczas gdy komputery osobiste IBM kodują je w formacie IEEE i ASCII . Dalsza złożoność pojawiła się ze względu na sposoby, w jakie różne kompilatory języka programowania mapują pola rekordów na ciągi bitów, bajtów i słów w pamięci. Przejrzysta konwersja rekordu wymaga szczegółowych opisów zarówno widoku klienta, jak i widoku rekordu serwera. Biorąc pod uwagę te opisy, pola widoków klienta i serwera można dopasować według nazwy pola i można wykonać odpowiednie konwersje.

Kluczową kwestią jest uzyskanie wystarczająco szczegółowych opisów rekordów, ale opisy rekordów są zazwyczaj określane abstrakcyjnie w programach użytkowych za pomocą instrukcji deklaracji zdefiniowanych przez język programowania, przy czym kompilator języka obsługuje szczegóły kodowania i mapowania. W środowisku przetwarzania rozproszonego potrzebny jest pojedynczy, ustandaryzowany sposób opisywania rekordów, niezależny od wszystkich języków programowania, który może opisywać szeroką gamę formatów rekordów o stałej i zmiennej długości, które można znaleźć w istniejących plikach.

W rezultacie zdefiniowano kompleksową architekturę opisu i konwersji danych (DD&C), opartą na nowym, wyspecjalizowanym języku programowania, A Data Language (ADL), do opisywania widoków klienta i serwera rekordów danych oraz do określania konwersji. Skompilowane programy ADL mogą być następnie wywoływane przez serwer w celu wykonania niezbędnych konwersji, gdy rekordy przepływają do lub z serwera.

Architektura DD&C poszła dalej i zdefiniowała środki, za pomocą których deklaracje deklaracji języka programowania mogą być automatycznie konwertowane do iz ADL, a tym samym z jednego języka programowania na inny. Ta funkcja nigdy nie została wdrożona ze względu na jej złożoność i koszt. Utworzono jednak kompilator ADL i programy ADL są wywoływane, jeśli są dostępne, w celu wykonywania konwersji przez DFM i IBM 4680 Store System. Jednak programiści aplikacji muszą ręcznie pisać programy ADL.

Wdrażanie produktów

Produkty DDM firmy IBM

Następujące produkty IBM zaimplementowały różne podzbiory architektury DDM:

  • System IBM/370
    • MVS (MVS/SP, MVS/ESA)
      • Baza danych 2 - klient i serwer DRDA
      • CICS - serwer plików nagrań w środowisku przetwarzania transakcji CICS. Wycofane w CICS for z/OS V5.2 i nowsze.
    • VM (system operacyjny) (VM/SP, VM/ESA)
      • SQL/DS - klient i serwer DRDA
    • DOS/VSE
      • CICS — serwer plików nagrań w środowisku przetwarzania transakcji CICS. Wycofane w CICS for z/VSE V2.1 i nowsze.
    • z/OS
      • Rozproszone zarządzanie plikami - Serwer plików nagrań
      • Baza danych 2 - klient i serwer DRDA
  • System/36
  • System/38 i jego następcy: AS/400, iSeries i Power Series
    • Klient i serwer plików nagrań
    • Klient i serwer katalogów i plików strumieniowych
    • Klient i serwer DRDA
  • Komputer osobisty IBM
    • PC DOS
      • Netview/PC — klient i serwer katalogów i plików strumieniowych
      • DDM/PC - Klient katalogów i plików strumieniowych.
      • PC Support/36 - Klient katalogów i plików strumieniowych.
      • PC Support/400 - Klient katalogów i plików strumieniowych.
    • System osobisty/2 - OS/2
      • PC/Support/400 - Klient i serwer strumieniowy plików i katalogów
      • Klient i serwer DRDA
  • Systemy sklepowe IBM 4680 i IBM 4690
    • Klient i serwer plików nagrań
    • Klient i serwer katalogów i plików strumieniowych
  • RS/6000 AIX
    • Klient i serwer DRDA

Produkty DDM innych dostawców

Aby uzyskać pełną listę produktów, w których zaimplementowano DRDA, zobacz Tabela identyfikatorów produktów Open Source DRDA .

Zobacz też

Bibliografia