Systemy rozproszone (SYR)

Systemy rozproszone (SYR) Wykład 2: Wprowadzenie do rozproszonych baz danych (2) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl

Główne aspekty rozproszenia baz danych (1) • Przezroczystość (transparency) • Rozproszony SZBD powinien podtrzymywać rozproszenie danych przy założeniu odizolowania programisty/użytkownika od większości aspektów rozproszenia. • Współdziałanie (interoperability) • Oznacza współpracę zbudowanych niezależnie od siebie heterogenicznych systemów (heterogeneous systems). • Aspektem współdziałania jest przyłączenie do rozproszonej BD starych systemów, tzw. spadkowych (legacy) • Przenaszalność (portability) • Własność języka programowania i jego kompilatorów/interpreterów umożliwiająca przenoszenie programów na różne platformy.

Główne aspekty rozproszenia baz danych (2) • Autonomia (autonomy) • Lokalne bazy danych podlegają własnym lokalnym regułom. • Tylko określona część lokalnych zasobów i usług jest udostępniana na zewnątrz. • Niezależność danych (data independence) • Możliwość projektowania, utrzymywania, udostępniania, zmiany nośników, zmiany reprezentacji, itp. działań na danych niezależnie od programów, które na nich operują. • Ontologia (ontology), często w kontekście ontologia biznesowa • Formalny opis wszystkich tych własności lokalnej bazy danych, które są niezbędne do tego, aby projektant/programista mógł prawidłowo zaprogramować nową aplikację (np. mobilnego agenta). • Niekiedy ontologia jest określana jako metadane.

Przezroczystość (1) • Rozproszona BD musi spełniać warunki komfortu pracy programistów, administratorów i użytkowników, jak również niezawodności, bezpieczeństwa danych, zwiększenie odporności na błędy programistów. • To oznacza konieczność redukcji złożoności przy pracy z rozproszoną bazą danych, co jest określane jako „przezroczystość”. • Ma ona następujące formy: • Przezroczystość położenia: Umożliwienie jednorodnych metod operowania na lokalnych i odległych danych. Tego warunku nie spełnia np. system, w którym lokalna baza danych jest obsługiwana przez pewien język 4GL, zaś odległa - przez specjalny zestaw procedur (API). • Przezroczystość dostępu: Uwolnienie użytkowników od konieczności(a niekiedy również uniemożliwienie) korzystania z informacji o aktualnym położeniu danych.

Przezroczystość (2) • Przezroczystość współbieżności: Umożliwia wielu użytkownikom jednoczesny dostęp do danych bez konieczności uzgodnień i porozumiewania się, przy zapewnieniu pełnej spójności danych i przetwarzania. • Przezroczystość skalowania: Umożliwienie dodawania nowych elementów bazy danych bez wpływu na działanie starych aplikacji i pracę użytkowników. • Przezroczystość replikacji: Umożliwienie tworzenia i usuwania kopii danych w innych miejscach geograficznych z bezpośrednim skutkiem dla efektywności przetwarzania, ale bez skutków dla postaci programów użytkowych lub pracy użytkownika końcowego. • Przezroczystość wydajności: Umożliwienie dodawania nowych elementów systemu komputerowego (np. serwerów,) bez wpływu na pracę większości użytkowników rozproszonej bazy danych.

Przezroczystość (3) • Przezroczystość fragmentacji (podziału): automatyczne scalanie obiektów, tabel lub kolekcji, których fragmenty są przechowywane w różnych miejscach. • Przezroczystość awarii: Umożliwienie nieprzerwanej pracy większości użytkowników rozproszonej bazy danych w sytuacji, gdy niektóre z jej węzłów lub linie komunikacyjne uległy awarii. • Przezroczystość migracji: Umożliwienie przenoszenia zasobów danych do innych miejsc bez wpływu na pracę użytkowników. • W praktyce spełnienie wszystkich wymienionych warunków jest ideałem, który prawdopodobnie nie został zrealizowany w żadnym ze znanych systemów.

Współdziałanie i heterogeniczność interoperability, heterogeneity • Umożliwienie współdziałania heterogenicznych systemów baz danych jest drugim ważnym aspektem rozproszenia. • Heterogeniczność jest nieodłączną cechą dużych sieci komputerowych, takich jak Internet, WWW, sieci intranetowych, rozproszonych baz danych, systemów przepływu prac, zasobów WWW opartych na plikach HTML i XML, itd.

Heterogeniczność (niejednorodność) • Np. system Intranetowy może składać się ze sprzętu: • komputerów klasy mainframe • stacji roboczych UNIX • komputerów PC pracujących pod MS Windows • komputerów Apple Macintosh • central telefonicznych, robotów, zautomatyzowanych linii produkcyjnych • ...włączać różnorodne protokoły komunikacyjne: Ethernet, FDDI, ATM, TCP/IP, Novell Netware, protokoły oparte na RPC,... • ...bazować na różnych systemach zarządzania bazą danych/dokumentów: Oracle,SQL Server, DB2, Lotus Notes,.... • ...oraz wymieniać pomiędzy sobą niejednorodne dane, podlegające różnym modelom danych, schematom, semantyce, mechanizmom dostępu,...

Przyczyny heterogeniczności • Niezależność działania: wytwórcy systemów nie uzgadniają między sobą ich cech. Standardy, o ile się pojawiają, są spóźnione, niekompletne i nie przestrzegane w 100%. • Konkurencja: wytwórcy systemów starają się wyposażyć systemy w atrakcyjne cechy, których nie posiadają konkurujące systemy • Różnorodność pomysłów: Nie zdarza się, aby było jedno rozwiązanie dla złożonego problemu. Różne zespoły znajdują różne rozwiązania, bazujące często na odmiennych celach i założeniach. • Efektywność finansowa i kompromisy: Wytwórcy oferują produkty o różnej cenie, funkcjonalności i jakości, zgodnie z wyczuciem potencjalnych potrzeb klientów i maksymalizacją swoich zysków. • Systemy spadkowe (legacy): Systemy, które dawno zostały wdrożone i działają efektywnie, nie mogą być z tego działania wyłączone. Nie jest możliwe (lub jest bardzo kosztowne) zastąpienie ich nowymi systemami. Nowe systemy, o podobnym przeznaczeniu, posiadają inne założenia, cechy i funkcjonalności

Przenaszalność portability • Typy przenaszalności: • Na poziomie składni, koncepcji języka i edukacji (np. SQL-92). • Na poziomie kodu źródłowego (np. C++ (?), JDBC). • Na poziomie interpretowanego kodu skryptowego lub pośredniego (np. Java). • Na poziomie kodu binarnego (? - trudno podać przykład). • Przenaszalność wymaga precyzyjnej specyfikacji składni i semantyki języka, oraz wyeliminowania z niego własności specyficznych dla poszczególnych platform. • Wiele standardów nie spełnia kryterium przenaszalności z powodu niedospecyfikowania i/lub nie spełniania standardu przez wytwórców systemów. • Przenaszalność jest celem standardów SQL, CORBA, ODMG, WebServices - niekoniecznie celem już osiągniętym. • Przenaszalność realizuje kod pośredni języka Java, ale dotyczy to funkcjonalności niskiego poziomu, np. nie dotyczy API do baz danych.

Autonomia autonomy • Autonomia lokalnej bazy danych w federacji baz danych oznacza, że: • Lokalne dane podlegają lokalnym priorytetom, regułom własności, autoryzacji dostępu, bezpieczeństwa, itd. • Lokalna BD może udostępniać aplikacjom działającym na federacji baz danych tylko określoną część swoich danych i usług. • Włączenie lokalnej BD do federacji nie może powodować konieczności zmiany programów aplikacyjnych działających na lokalnej BD. • Federacja może przetwarzać lokalne zasoby tylko poprzez interfejs programowania aplikacji (API) specyficzny dla lokalnego systemu. Inne metody (np. bezpośredni dostęp do plików) są niedozwolone. • Federacja nie może żądać od lokalnej bazy danych zmiany/rozszerzenia jej usług (np. udostępnienia lokalnego dziennika transakcji). • Możliwa jest pewna skala autonomii. Pojęcie autonomii jest raczej intuicyjne. • Autonomia jest także spekulacyjnym ideałem. • Współdziałanie może oznaczać również konieczność dostosowania się lokalnego serwera, czyli rezygnację z części autonomii.

Niezależność danych data independence • Oznacza, że nie ma potrzeby zmiany kodu programów aplikacyjnych mimo zmian organizacji lub schematów danych. • Jest osiągana poprzez interfejsy programistyczne umożliwiające dostęp do danych na odpowiednim poziomie abstrakcji, gdy niewidoczne są szczegóły organizacji i implementacji danych. • Fizyczna niezależność danych: ukrycie detali organizacji fizycznej i technik dostępu, dzięki czemu możliwa jest ich zmiana bez wpływu na kod aplikacji. • Logiczna niezależność danych: umożliwienie niektórych zmian schematu logicznego bez wpływu na kod aplikacji, np. dodanie atrybutów do relacji, zmiana kolejności atrybutów, zmiana ich typów, utworzenie nowych relacji, itd. • Ewolucja schematu (schema evolution): umożliwienie daleko idących zmian schematu danych. • Implikuje konwersję danych i konwersję (poprawienie) aplikacji. • Idealistycznie, może polegać na utworzeniu perspektyw (views) dla starych lub nowych danych.

Ontologia ontology • W filozofii: nauka o bytach, teoria bytu, opis charakteru i struktury rzeczywistości, specyfikacja konceptualizacji. • W sztucznej inteligencji: formalna specyfikacja (przy użyciu logiki matematycznej) obiektów, pojęć i innych bytów, które istnieją w pewnej dziedzinie, oraz formalna specyfikacja związków, które pomiędzy tymi bytami zachodzą. • Podejście sztucznej inteligencji jest naiwne. • Np. Giełda Papierów Wartościowych: wiele tysięcy stron aktów prawnych, zarządzeń, regulacji, itd. Jako (dożywotnia) kara dla sztucznego (ćwierć-) inteligenta wypisującego bzdury na temat "formalnej ontologii": niech to zapisze przy użyciu formuł rachunku predykatów. • W biznesie (ontologia biznesowa, business ontology): wszystko to, co projektanci systemów informatycznych powinni wiedzieć o biznesie, aby poprawnie napisać aplikacje wspomagające ten biznes. • Wiedza ta powinna być formalnie zapisana w pewnym standardowym i uzgodnionym język, np. XML/RDF. • Ontologia jest też rozumiana jako społeczna umowa / kontrakt / standard / regulacja prawna i nie ma nic wspólnego z logiką.

Ontologia i metadane • Głównym celem prac na biznesową ontologią jest standardyzacja następujących elementów: • Gramatyki opisów poszczególnych bytów, • Nazw i znaczeń nazw obowiązujących w ramach danego biznesu (np. co oznaczają słowa "autor", "klient", "instrument", "akcja", itd.), • Ograniczeń związanych z opisywanymi bytami, • Metadanych związanych z bytami (autor opisu, data stworzenia opisu, data ostatniej aktualizacji, itd.), • Dopuszczalnych operacji na bytach. • W tym zakresie zapis ontologii jest pewną meta-bazą danych, w które ustala się zarówno strukturę samej bazy danych, jak i pewne dodatkowe informacje (meta-atrybuty) będące podstawą przetwarzania bazy danych. • Nieco inne podejście prezentuje standard RDF opracowany przez W3C, gdzie ontologię reprezentują wyrażenia RDF.

Metadane • Metadane są kluczowe dla wielu rozproszonych aplikacji, ponieważ umożliwiają rozpoznanie z zewnętrz własności lokalnego zasobu danych • Ogólna definicja: są to dane o danych - co dane zawierają, jaką mają budowę, jakie jest ich znaczenie, jakim podlegają ograniczeniom, jak są zorganizowane, przechowywane, zabezpieczane, udostępniane, itd. • Metadane są pewnym rozszerzeniem pojęcia schematu bazy danych, albo też pewną implementacją tego schematu w postaci katalogów. • Metadane przykrywają także informację niezależną od treści samych danych, np. kiedy pewna dana została utworzona, w jakim jest formacie, kto jest jej autorem, do kiedy jest ważna, itd. • Opisy danych zawarte w metadanych mają dwie podstawowe zalety: • Zawierają wspólne abstrakcje dotyczące reprezentacji danych, takie jak format; ogólnie "wyciągają przed nawias" wszystkie wspólne informacje, co redukuje znacznie objętość samych danych; • Reprezentują wiedzę dziedzinową (ontologię); umożliwiają wnioskowanie o danych, mogą być przez to użyte do redukowania dostępu do samych danych.

Klasyfikacja metadanych • Metadane niezależne od treści danych: lokacja danych, data modyfikacji, typ kamery służącej do sporządzenia zdjęcia, itd. Mimo, że nie składają się bezpośrednio na treść danych, mogą być ważnym kryterium wyszukiwania. • Metadane zależne od treści danych: rozmiar dokumentu, liczba kolorów, liczba wierszy, liczba kolumn w tabeli. Metadane zależne od treści mogą być dalej podzielone na: • Bezpośrednie metadane dotyczące treści, np. indeksy, klasyfikacje, itd. • Metadane opisujące treść: adnotacje o zawartości zdjęcia, np. opis zapachu kwiatu przedstawionego na zdjęciu. • Metadane niezależne od dziedziny biznesowej, której dotyczy treść, np. definicje typu dokumentu HTML/SGML • Metadane zależne od dziedziny biznesowej, np. schemat danych lub opis ontologii biznesowej • Podział na dane i metadane nie jest do końca jasny i silnie zależy od nastawienia projektanta i podziału zadań podczas redakcji treści danych.

Protokół wymiany informacji w rozproszonej BD • Protokół wymiany informacji pomiędzy rozproszonymi miejscami musi uwzględniać: • przesyłanie danych z jednego miejsca do drugiego miejsca • przesyłanie zleceń (np. zapytań) do odległych miejsc celem przetwarzania danych • zwrotne przesyłanie wyników tych zleceń do zlecającego klienta • automatyczną dystrybucję niektórych metadanych (np. schematu BD) pomiędzy uczestników rozproszonej bazy danych. • przesyłanie zapytań dotyczących metadanych • przekazywanie wyników zapytań dotyczących metadanych do pytającego • Aktualnie, protokoły takie istnieją w bardzo uproszczonej lub silnie wyspecjalizowanej formie • IIOP (Internet Inter-Orb Protocol) - bardzo uproszczony • LDAP (Lightweight Directory Access Protocol) - silnie wyspecjalizowany • Wiele ośrodków prowadzi prace badawcze nad uniwersalnymi protokołami, opartymi o różnorodne języki zapytań.

Migracje obiektów • Migracja: przemieszczanie się obiektów między węzłami sieci, przy czym obiekty muszą być skojarzone (statycznie lub dynamicznie związane) ze swoimi klasami i przechowywanymi w ramach tych klas metodami. Problemy: • Określenie jednostki migracji • Śledzenie obiektów • Utrzymywania porządku w katalogu systemu bazy danych • Okresowa kondensacja łańcuchów obiektów pośrednich • Przemieszczanie obiektów złożonych • Zapewnienie globalnej przestrzeni nazw • Zapewnienie właściwych mechanizmów zakresu i wiązania • Dostępność metod umożliwiających przetwarzanie obiektów • Jak dotąd, metody są najczęściej składowymi aplikacji, a nie bazy danych. Konsekwencją jest to, że po przemieszczeniu obiektu aplikacja działająca w jego nowym miejscu musi mieć wbudowane (powielone, skompilowane, zlinkowane) metody do jego przetwarzania.

Oprogramowanie komponentowe ost.06.03.05 • Komercyjny buzzword, marzenie informatyków od 30 lat. • Oznacza technologie zmierzające do budowy standardów oraz wspomagającego je oprogramowania, które pozwoliłoby na składanie dużych aplikacji lub systemów z komponentów, na zasadzie podobnej do składania komputera z podzespołów. • Inne terminy: mega-programming, programming-in-the-large. • Jako przykłady wymienia się teraz: OMG CORBA, OpenDoc firm Apple, IBM i innych, technologia .NET/COM/DCOM, Java Beans i Enterprise Java Beans. • Komponenty mają wiele sukcesów. Istnieją jednak problemy utrudniające szerokie ich stosowanie • problemy z osiągnięciem akceptowalnej wydajności, • trudności w precyzyjnym a jednocześnie dostatecznie abstrakcyjnym wyspecyfikowaniu interfejsów pomiędzy komponentami, • dynamiczny postęp w informatyce, powodujący pojawianie się coraz to nowych wymagań na interfejsy.

Obiektowość w rozproszonych bazach danych • Obiektowość zakłada zwiększenie stopnia abstrakcji, przystosowanie modeli realizacyjnych systemów informatycznych do naturalnych konstrukcji i obrazów myślowych projektantów, programistów i użytkowników. • Główny problem - opanowanie złożoności przy wytwarzaniu oprogramowania. • Punktem zainteresowania twórców narzędzi informatycznych stają się procesy myślowe zachodzące w umysłach osób pracujących nad oprogramowaniem => modelowanie pojęciowe. • Obiektowość przerzuca ciężar problemu z kwestii narzędziowej (jak mam to zrobić?) na kwestię merytoryczną (co mam zrobić i po co?).

Źródła złożoności projektu oprogramowania Zespół projektantów podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji. Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów. Oprogramowanie: decyzje strategiczne, analiza, projektowanie, konstrukcja, dokumentacja, wdrożenie, szkolenie, eksploatacja, pielęgnacja, modyfikacja. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność. Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia.

Jak walczyć ze złożonością ? • Zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości. • Zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy. • Zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd. • Zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata. • Zasada hierarchicznej klasyfikacji bytów dziedziny przedmiotowej, dla lepszego jej rozumienia

Modelowanie pojęciowe • Projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania. • Pojęcia modelowania pojęciowego (conceptual modeling) oraz modelu pojęciowego (conceptual model) odnoszą się procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. • Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu.

Perspektywy w modelowaniu pojęciowym ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... • Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz konstrukcji SI jest dążenie do minimalizacji luki pomiędzy myśleniem o rzeczywistym problemie a myśleniem o danych i procesach zachodzących na danych. odwzorowanie odwzorowanie Percepcja rzeczywistego świata Analityczny model rzeczywistości Model struktur danych i procesów SI

Przykład: pojęciowy schemat obiektowy w UML Firma Zatrudnienie Pracownik Osoba Wyp ł ata * Nazwa Zawód * Nazwisko Ocena * Miejsce * Imi ę * Adres * PZ FZ 0..* 1 0..* 1 Nie więcej niż 10 sekund zastanawiania się, co ten diagram przedstawia i jak jest semantyka jego elementów. Potem można już programować np. w C++ lub Java. Co otrzymamy po odwzorowaniu tego schematu na schemat relacyjny?

Schemat relacyjny Firma(NrF, Nazwa) • Jest to jedno z kilku możliwych rozwiązań. • Schemat relacyjny jest trudniejszy do odczytania i zinterpretowania. • Programista będzie musiał co najmniej 10 minut zastanawiać się, jaką semantykę mają tabele, atrybuty i zaznaczone powiązania. • Efektem jest zwiększona skłonność do błędów (mylnych interpretacji). Zatrudnienie(NrF, NrP) Lokal(NrF, Miejsce) Pracownik(NrP, NrOs) Oceny(NrOceny, Ocena, NrF, NrP) Dochód(NrDochodu, Wypłata, NrF, NrP) Osoba(NrOs, Nazwisko) Wyszkolenie(Zawód, NrP) Adresy(NrOs, Adres) Imiona(NrOs, Imię)

Skutki niezgodności modelu pojęciowego i realizacyjnego • Programy odwołujące się do schematu relacyjnego są dłuższe od programów odwołujących się do schematu obiektowego (30% - 70%). • Ma to ogromne znaczenie dla tempa tworzenia oprogramowania, jego jakości, pielęgnacyjności, itd. • Programy te są też zwykle znacznie wolniejsze. • Mini przykład: Podaj adresy pracowników pracujących w firmach zlokalizowanych w Radomiu • Zapytanie w SQL jest znacznie dłuższe wskutek tego, że w SQL konieczne są „złączeniowe” predykaty (takie jak k.NrF=z.NrF i następne) kojarzące informację semantyczną "zgubioną" w relacyjnej strukturze danych. SBQL: (Firma where ”Radom” in Miejsce).FZ.Zatrudnienie.PZ.Pracownik.Adres SQL: select a.Adres from Lokal as k, Zatrudnienie as z, Pracownik as p, Osoba as s, Adresy as a where k.Miejsce = “Radom” and k.NrF = z.NrF and z.NrP = p.NrP and p.NrOs = s.NrOs and s.NrOs =a.NrOs

Rozproszone obiektowe bazy danych • Problemy są podobne jak w przypadku rozproszonych relacyjnych BD. • Nie jest jednak pewne czy do przetwarzania zapytań w tych systemach będą się odnosić te same metody. • Problemy, różniące przetwarzanie zapytań w rozproszonych obiektowych BD i w rozproszonych relacyjnych BD: • Obiekty nie zawsze są implementowane jako "płaskie" zapisy. • Obiekty mogą mieć referencje do obiektów zlokalizowanych w innych węzłach sieci. • Przetwarzanie zapytań może dotyczyć kolekcji złożonych obiektów • Zapytania mogą mieć odwołania do metod. • Przetwarzanie zapytań w rozproszonych systemach obiektowych jest tematem bardzo istotnym. Standard ODMG tym się nie zajmuje. • Jak dotąd, w zakresie przetwarzania rozproszonych zapytań nie rozwiązano podstawowych problemów koncepcyjnych. • Niektóre z problemów mogą nie mieć ogólnego rozwiązania.

Rozproszona obiektowa baza danych • Przedmiotem przetwarzania i wymiany informacji w obiektowej rozproszonej bazie danych są obiekty. Zarządzanie rozproszonymi obiektami ma na celu utrzymywanie spójności i przezroczystości (niewidoczności) geograficznego rozproszenia obiektów.

Zalety rozproszonych obiektów • Zgodność z logiką biznesu - bezpośrednia implementacja obiektów biznesowych. • Umożliwienie projektantom opóźnienie decyzji - gdzie i jakie usługi powinny być zapewnione. • Skalowalność aplikacji: mała zależność czasu reakcji systemu od zwiększenia ilości danych, liczby użytkowników, liczby węzłów. • Dekompozycja aplikacji na elementy wykonawcze (obiekty, metody,...). • Przyrostowe dodawanie/odejmowanie funkcjonalności (“płacę tylko za to, czego używam”). • Podział zasobów i zbalansowanie obciążeń. • Współbieżność i asynchroniczne przetwarzanie. • Elastyczność zmian w oprogramowaniu (konserwacja), w szczególności, przenoszenie obiektów i usług do innych miejsc. • Możliwość przyłączania aplikacji spadkowych (funkcjonujących wcześniej jako scentralizowane).

Systemy rozproszone (SYR)