Standardy w zakresie systemów rozproszonych i baz danych

K.Subieta. SSR, Wykład 5, Folia 1 marzec 2009

Standardy w zakresie systemów rozproszonych i baz danych

Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 5:

Wprowadzenie do OMG CORBA


• Zapewnia możliwość wiązania nazwy do obiektu relatywnie w stosunku do kontekstu.• Kontekst nazwowy jest to pewien obiekt zawierający wiązania nazw.• Wszystkie obiekty muszą być nazwane. • Nazwy są relatywne w stosunku do kontekstu; w ramach kontekstu są unikalne.• Usługa nazwowa nie zajmuje się ani składnią ani znaczeniem nazw.

Graf nazw:Graf nazw:

user home sys

u1 u2 u3 bill alden

c1 c2 l1 l2

bin lib

Usługi nazewniczaName Service

- kontekst nazwowy- nazwa obiektu


Wiązanie: przypisanie nazwy do obiektu

Rozstrzyganie: odszukanie obiektu posiadającego przypisaną nazwę.

void bind( in Name n, in Object obj ) raises(NotFound, CannotProceed, InvalidName, AlreadyBound)

Przykładowe wywołanie: kontekst -> bind( foo, myobj )

Object resolve( in Name n) raises (NotFound, CannotProceed, InvalidName)

Przykładowe wywołanie: myobjref = kontekst -> resolve( foo )

Nazwy mogą mieć postać ciągów <c1;c2;...;cn>. Wiązanie i rozstrzyganie rekurencyjne.

Usługa nazewnicza: wiązanie, rozstrzyganiebinding, resolving

user; u2; foo

kontekst kontekst nazwa prosta


Usługa nazewnicza: kroki dla uzyskania referencji Otrzymaj początkowy kontekst nazwowy:

Utwórz nazwę złożoną:

Znajdź obiekt opatrzony tą nazwą:

Wywołaj metodę na docelowym obiekcie zidentyfikowanym przez fooRef .

org.omg.CORBA.Object objRef = orb.resolve_initial_references(“NameService”);

NamingContext rootContext = NamingContextHelper.narrow(objRef);

NameComponent comp1 = new NameComponent(“user”,””); NameComponent comp2 = new NameComponent(“u2”,””); NameComponent comp3 = new NameComponent(“foo”,””); NameComponent [] name = {comp1, comp2, comp3}

org.omg.CORBA.Object objRef = rootContext.resolve(name);orb.resolve_initial_references(“NameService”);

FooClass fooRef = FooHelper.narrow(objRef);

narrow - kast do określonego typu.


Usługa handlowa (Trader)Trade Service

Trader jest bazą danych, która umożliwia klientom wyszukanie informacji o usługach dostarczanych przez obiekty. Na podstawie uzyskanych informacji klient może wybrać obiekt, który go interesuje jako dostawca usługi. Obiekt informuje o swoich usługach poprzez zapisanie odpowiedniej informacji w bazie danych Trader. Klient może odpytywać tę bazę danych celem wyszukania odpowiedniego obiektu.

Trader Obiekt

Klient

Pytanie

o us

ługę

Rezult

at wys

zukiw

ania

Rejestracja usługi wraz z opisem

Korzystanie z usługi


Funkcje bazy danych Trader

Podstawową funkcją tej bazy jest dostarczenie klientom możliwości wyszukiwania ofert usług zgłoszonych (zareklamowanych) przez dostarczające je obiekty.Dodatkowo pozwala ona na:

tworzenie nowych typów usług, ich usuwanie i listowanie rejestrację nowych ofert usług, wycofywanie ofert, pobieranie ich

opisu i modyfikację wartości ich właściwości administrację, czyli modyfikację rożnych parametrów bazy, jak

również pobieranie listy zarejestrowanych ofert, zarówno zwykłych jak i zastępczych.

tworzenie, usuwanie i modyfikację połaczeń danej instancji bazy danych Trader z innymi jej egzemplarzami

rejestrację i wycofywanie ofert zastępczych

Można tu odnieść wrażenie, że twórcy standardu CORBA próbują skonstruować na własną rękę coś, co dawno zostało dobrze opanowane przez technologie znane jako zmaterializowane perspektywy i (relacyjne, obiektowe) bazy danych. Koncepcja razi plątaniną szczegółów.


Definicja typu usługi

Z każdą usługą przechowywaną w bazie danych Trader związany jest typ:• typ interfejsu dostarczającego usługę• typ właściwości opisujących tę usługę

usługa OperacjeBankowe {interfejs :: Finanse :: Bank;obowiązkowa właściwość short ProcentROR;właściwość float MaxWysokośćKredytu;tylko_do_odczytu właściwość boolean GwarancjePaństwowe;

};

Jest to schemat (format) zapisu w bazie danych Trader.

Usługa OperacjeBankowe służy do zapisu informacji o warunkach kredytowania. Taka deklaracja przypomina deklarację schematu tablicy w SQL. Odpowiednio do tego, CORBA definiuje coś w rodzaju języka zapytań (a la SQL, ale znacznie niższego poziomu), przy pomocy którego można wyszukać obiekt (obiekty) spełniające kryteria wyszukiwania.


Event Service

Dwa modele komunikacji zdarzeń pomiędzy ich dostawcami i konsumentami:- pchający (push): dostawcy “pchają” zdarzenia i ich dane do konsumentów

- ciągnący (pull): konsumenci “ciągną” dane zdarzeń od dostawców.

Usługa ustala dwie role obiektów: dostawcy zdarzeń i konsumenta zdarzeń.Komunikacja pomiędzy dostawcą i konsumentem wykorzystuje standardowezlecenia CORBA.

Usługa ustala dwie role obiektów: dostawcy zdarzeń i konsumenta zdarzeń.Komunikacja pomiędzy dostawcą i konsumentem wykorzystuje standardowezlecenia CORBA.

Np. notowanie aktualizacji obiektu: aktualizowany obiekt działa jako dostawca zdarzenia.Inne relewantne obiekty (np. posiadające wskaźniki do obiektu aktualizowanegodziałają jako konsumenci zdarzenia.

W modelu “ciągnącym” konsumenci periodycznie odpytują dostawcę (metoda try_pull)na okoliczność wystąpienia zdarzenia.

W modelu “ciągnącym” konsumenci periodycznie odpytują dostawcę (metoda try_pull)na okoliczność wystąpienia zdarzenia.

interface PushConsumer { void push( in any data ) raises(Disconnected); void disconnect_push_consumer(); };

Usługi w zakresie zdarzeń


Life Cycle Service

Tworzenie obiektówTworzenie obiektów

Przykładowe problemy do rozstrzygnięcia:Przykładowe problemy do rozstrzygnięcia:

Przesuwanie obiektówPrzesuwanie obiektów

• Czy klient może sterować lokacją nowo tworzonego obiektu?• Czy taka lokacja może być ustalona poprzez pewien serwis administracyjny?• W jakim stopniu klient może decydować o implementacji obiektu?• Jak klient może wpłynąć na początkowe wartości obiektu?• Jeżeli obiekty tworzą powiązany graf, jak ustalić granice takiego grafu?

Object create_object(in Key k,in Criteria the_criteria

raises( NoFactory, InvalidCriteria, CannotMeetCriteria );

Key: nazwa obiektu, zgodnie z usługami w zakresie nazw;Criteria: ciąg par <nazwa, wartość>, służący jako zestaw parametrów tworzenia obiektu,np. inicjalizacja, warunki, ograniczenia, lokacja logiczna, preferencje dotyczące sprzętu, itd.

Kasowanie obiektówKasowanie obiektówKopiowanie obiektówKopiowanie obiektów

Usługi w zakresie cyklu życiowego


Klient

Trwały obiekt, PO Trwały identyfikator, PID

Protokół Zarządca Trwałymi Obiektami, POM

Usługi w/z trwałych obiektów, PDS

Skład danych

Zawiera zestaw interfejsówdo zarządzania trwałymi obiektami.

Zawiera zestaw interfejsówdo zarządzania trwałymi obiektami.

Ze względu na niski poziom koncepcyjny, brak niezależności danych, przywiązanie do bardzo partykularnych protokółów, usługabardzo przypomina styl DBTG CODASYL,który dawno temu został odrzucony.

Usługi w zakresie trwałych obiektówPersistent Object Service


Umożliwia powiązanie obiektów przy pomocy związków, np. powiązanie samochodu z osobą będącą jego właścicielem.

Umożliwia powiązanie obiektów przy pomocy związków, np. powiązanie samochodu z osobą będącą jego właścicielem.

• Definicja typów związanych encji i typów związków• Definicja ról, które odgrywają encje w poszczególnych związkach• Definicja stopnia (degree) związku: binarny, ternarny, itd.• Definicja kardynalności związku (minimum i maksimum powiązań encji)• Definicja semantyki związków, tj. jego atrybutów.

Encje są reprezentowane jako obiekty CORBA.Związek jest tworzony poprzez przesłanie zestawu ról do obiektu-wytwórcy związku.Można tworzyć związki dowolnego stopnia.Typy i kardynalności mogą być zadeklarowane i kontrolowane.Do związku mozna dodać atrybuty.

Encje są reprezentowane jako obiekty CORBA.Związek jest tworzony poprzez przesłanie zestawu ról do obiektu-wytwórcy związku.Można tworzyć związki dowolnego stopnia.Typy i kardynalności mogą być zadeklarowane i kontrolowane.Do związku mozna dodać atrybuty.

Podobnie jak w przypadku trwałości,usługa w zakresie związków jest zdefiniowana na niskim poziomie abstrakcji.

Usługi w zakresie związków (1)Relationship Service


Operacje:Operacje:

• Tworzenie ról i obiektów przechowujących związki• Nawigacja wzdłuż związków• Skasowanie ról i związków• Iterowanie po związkach w których uczestniczy dana rola

• Tworzenie ról i obiektów przechowujących związki• Nawigacja wzdłuż związków• Skasowanie ról i związków• Iterowanie po związkach w których uczestniczy dana rola

Rola obiektu jest tworzona niezależnie poprzez wytwórnię ról.Ciąg ról jest parametrem dla wytwórni związku.

Relationship create ( in NamedRoles named_roles ) raises ( RoleType Error, MaxCardinalityExceeded, DegreeError, DuplicateRoleName, UnknownRoleName)

Role create_role ( in RelatedObject related_object ) raises ( NilRelatedObject, RelatedObjectTypeError )

struct NamedRole { RoleName name; Role aRole; } ;typedef sequence <NamedRole> NamedRoles;

RelatedObject get_other_related_object ( in RelationshipHandle rel, in RoleName target_name )

raises ( UnknownRoleName, UnknownRelationship )

Usługi w zakresie związków (2)


Zapewnia operacje w zakresie zapytań na kolekcjach obiektów.Typowe zapytanie zwraca kolekcje obiektów.Termin “query” obejmuje także operacje:

wstawiania (insert), aktualizacji (update) i usuwania (delete).

Zapewnia operacje w zakresie zapytań na kolekcjach obiektów.Typowe zapytanie zwraca kolekcje obiektów.Termin “query” obejmuje także operacje:

wstawiania (insert), aktualizacji (update) i usuwania (delete).

Zasady projektowe:- zgodność z usługami w/z nazw, cyklu życiowego, trwałych obiektów i związków;- zapytania mogą dotyczyć dowolnych obiektów, z dowolnymi atrybutami i operacjami- powinny umożliwiać metody podwyższenia wydajności, takie jak indeksy- aby być użyteczne w wielu środowiskach, usługi muszą dobrze odwzorowywać lokalne mechanizmy zapytań

Okoliczności związane z przetwarzaniem zapytań:- Środki graficzne konstruowania zapytań- Zapamiętywanie zapytań celem ich późniejszego wykonania, z różnymi parametrami- Prekompilacja zapytań celem późniejszego wykonania- Wykonanie zapytań w trybie asynchronicznym- Sprawdzanie statusu długo przetwarzanego zapytania z możliwością jego zerwania

Okoliczności związane z przetwarzaniem zapytań:- Środki graficzne konstruowania zapytań- Zapamiętywanie zapytań celem ich późniejszego wykonania, z różnymi parametrami- Prekompilacja zapytań celem późniejszego wykonania- Wykonanie zapytań w trybie asynchronicznym- Sprawdzanie statusu długo przetwarzanego zapytania z możliwością jego zerwania

Usługi w zakresie zapytań (1)Query Service


Usługa jest zorientowana na wiele języków zapytań, przede wszystkim na SQL i OQL.Porozumienie pomiędzy ANSI X3H2 (SQL-3) i ODMG (OQL) zmierzało do opracowaniawspólnego identycznego języka zapytań (w sensie języka wyszukiwania). Nic z tego nie wyszło.

Usługa jest zorientowana na wiele języków zapytań, przede wszystkim na SQL i OQL.Porozumienie pomiędzy ANSI X3H2 (SQL-3) i ODMG (OQL) zmierzało do opracowaniawspólnego identycznego języka zapytań (w sensie języka wyszukiwania). Nic z tego nie wyszło.

Co zapewnia usługa w zakresie zapytań?

• Operacje selekcji, wstawiania, aktualizacji i usuwania na kolekcjach obiektów.• Obiekty mogą być chwilowe i trwałe, lokalne lub odległe, z dowolnymi atryb. i operac.• Dowolna granulowość obiektów• Zakres dostępnych obiektów regulowany przez kolekcje będące argumentami zapytań• Wspomaganie dla odpytywania i zwracania złożonych struktur danych• Wspomaganie dla użycia atrybutów, dziedziczenia, operacji w predykatach zapytań

i w obliczeniach zwracanego rezultatu• Dowolne użycie interfejsów wyspecyfikowanych w OMG IDL. • Dowolne użycie związków dla nawigacji, z użyciem testowania występowania związku

pomiędzy obiektami• Nie łamanie zasady hermetyzacji przewidzianej przez interfejsy do obiektów.

Usługi w zakresie zapytań (2)


OMG jest w tej chwili ogromnym, największym w świecie i bardzo aktywnym konsorcjum. Prowadzi prace badawczo-rozwojowe i standaryzacyjne w bardzo wielu tematach: przetwarzanie w czasie rzeczywistym, Internet, telekomunikacja, systemy finansowe, systemy medyczne, analiza i projektowanie obiektowe, elektroniczne systemy komercyjne, bezpieczeństwo, systemy baz danych, języki programowania.

Komitety:

Dziedzinowy Komitet Techniczny (DTC, Domain Technical Committee):skupia się na technologiach, ktore są zorientowane dziedzinowo: Finanse, Wytwarzanie, Medycyna, Biznes, Telekomunikacja.

Dziedzinowy Komitet Techniczny (DTC, Domain Technical Committee):skupia się na technologiach, ktore są zorientowane dziedzinowo: Finanse, Wytwarzanie, Medycyna, Biznes, Telekomunikacja.

Platformowy Komitet Techniczny (PTC, Platform Technical Committee):skupia się na technologiach wspólnych dla wielu dziedzin:ORB/ObjectServices (ORBOS), Common Facilities.

Platformowy Komitet Techniczny (PTC, Platform Technical Committee):skupia się na technologiach wspólnych dla wielu dziedzin:ORB/ObjectServices (ORBOS), Common Facilities.

Rada d/s Architektury (AB, Architecture Board):skupia sie na integralności i spojności architektury OMA i modelu obiektowego.

Rada d/s Architektury (AB, Architecture Board):skupia sie na integralności i spojności architektury OMA i modelu obiektowego.

Bieżące prace OMG (1)


ORBOS (ORB/Object Services) Task Force

Dotychczas CORBA pozwala przesyłać referencje do obiektów, ale nie pozwalaprzesyłać obiektów jako wartości (objects by values). Stwarza to problemy dla niektórych języków programowania, np. C++. ORBOS Task Force rozpowszechnia obecnie RFP mające na celu technologię przesyłania obiektów jako wartości.

Dotychczas CORBA pozwala przesyłać referencje do obiektów, ale nie pozwalaprzesyłać obiektów jako wartości (objects by values). Stwarza to problemy dla niektórych języków programowania, np. C++. ORBOS Task Force rozpowszechnia obecnie RFP mające na celu technologię przesyłania obiektów jako wartości.

Drugim tematem ORBOS Task Force jest dwukierunkowe współdziałanie zestandardami Microsoft COM i DCOM. COM/CORBA jest właśnie zaakceptowany, natomiastDCOM/CORBA jest w trakcie opracowania.

Drugim tematem ORBOS Task Force jest dwukierunkowe współdziałanie zestandardami Microsoft COM i DCOM. COM/CORBA jest właśnie zaakceptowany, natomiastDCOM/CORBA jest w trakcie opracowania.

COM/DCOM niekoniecznie jest konkurentem dla CORBA, raczejjest to inna technologia, która może być zintegrowana pod parasolem standardu CORBA.(Jest to pogląd twórców CORBA. Microsoft uważa inaczej.)

Docelowo (i nieco idealistycznie) CORBA ma być realizacją prawdziwego komercyjnego off-the-shelf (COTS) rynku składników oprogramowania, które może być składanew dowolne konfiguracje architektoniczne. Trudno powiedzieć, czy ten cel jest osiągalny.

Bieżące prace OMG (2)


Specyfikacje OMG (1)

MDA - The Model Driven Architecture.

UML - the Unified Modeling Language

MOF - The MetaObject Facility

XMI - XML Metadata Interchange

CWM - The Common Warehouse Metamodel

CORBA - the Common Object Request Broker

Architecture


Specyfikacje OMG (2)

Data-Distribution Service for Real-time Systems™

(DDS™)

OMG Systems Modeling Language

Business Process Modeling Notation (BPMN)


Najbardziej znane implementacje CORBAProducent Nazwa systemu Opis

BEASystems

ObjectBrokerIceberg

http://beasys.com/Pierwsza i najbardziej dojrzała implementacja ORB narynku. Iceberg jest integracją ObjectBroker z Tuxedo,tworzac Object Transaction Monitor (OTM).

Borland/Visigenic

VisiBroker http://www.visigenic.com/prodVisiBroker for Java jest czołowym CORBA/Java ORB.VisiBroker for C++ jest bardzo szybkim ORBem opartymna IIOP. Jest on włączany w produkty Netscape, Oracle,Novell, Sybase, Netscape, etc.

Expertsoft PowerBroker http://www.expertsoft.com/Jeden z najlepszych ORBów dla C++.

IBM SOMComponentBroker

http://www.software.ibm.com/objects/somobjects/http://www.software.ibm.com/ad/cb/SOM jest teraz częścią ComponentBroker. Zintegrowany zOTM i DB2.

ICL DAIS http://www.icl.co.uk/products/dais/home.htmlPierwszy ORB implementujacy OMG Security Service.

IONA OrbixOrbixWeb

http://www.iona.ie/Bardzo popularne ORBy. Orbix bazuje na C++.OrbixWeb bazuje na Java. Firewalls, pomosty do DCOM,usługa w zakresie transakcji.

JavaSoft Java IDL http://www.javasoft.com/CORBA/Java ORB zanurzony w JDK 1.2. Dostępny bezopłat.


CORBA Vendor Directory Listing 2AB Inc. AdNovum Informatik AG - OMG Member (I) eCube Systems - OMG Member (I) IBM Rational - OMG Member (C) IONA Technologies - OMG Member (C) iWay Software - OMG Member (T) Liantis GmbH & Co. KG Logical Tracking&Tracing International AG No Magic, Inc. - OMG Member (C) Object Computing Inc. - OMG Member (I) Objective Interface Systems, Inc - OMG Member

(C) ObjectSecurity Ltd. PrismTech - OMG Member (C) Remedy IT - OMG Member (P) Southwest Research Institute - OMG Member (U) Sparx Systems - OMG Member (C) TenFold Corporation

OMG Membership Level:C - ContributingD - DomainP - PlatformI - InfluencingG - GovernmentU - UniversityT - TrialA - Analyst


Wady OMG CORBA Zbyt maksymalistyczne cele, wolne tempo rozwoju, nie nadążanie za rozwojem

współczesnych technologii (Konkurenci: DCOM/Remoting.Net, Web Services, RMI+JavaBeans).

Niski poziom abstrakcji, zbytnie przywiązanie do szczegółów technicznych jęz.prog. niskiego rzędu takich jak C++ i protokółów transportowych (przypadek podobny do DBTG CODASYL). Jako konsekwencja -współdziałanie i przenaszalność jest często trudne do osiągnięcia.

Tendencja do rozrostu standardu w kierunku nowego języka programowania, z rozbudowanymi specjalizacjami “pionowymi” i “poziomymi”.

Ograniczenia modelu danych: brak rozdzielenia typów i “interfejsów”, brak niektórych typów masowych (wielozbiorów), brak relatywizmu i ortogonalności typów,

Problemy wydajności: komunikacja klient-serwer na poziomie dostępu do pojedynczych obiektów jest dla wielu aplikacji nieakceptowalna. Konieczna jest komunikacja makroskopowa, np. w stylu (optymalizowanych) języków zapytań takich jak SQL, SBQL lub OQL.

Problem bezpieczeństwa nie jest dotychczas traktowany z wystarczającą uwagą.


Podsumowanie (1)

OMG CORBA jest standardem współdziałania systemów obiektowych i nieobiektowych, heterogenicznych i rozproszonych, opracowany przez gremium OMG.

Dość ambitnym celem standardu OMG CORBA jest uzyskanie możliwości współdziałania pomiędzy niekompatybilnymi systemami, pracującymi na różnych platformach sprzętowych i programowych, oddalonych geograficznie.

Osiągnięcie tego celu wymagało zwiększenia poziomu abstrakcji w taki sposób, aby (zazwyczaj zasadnicze) różnice implementacyjne nie miały znaczenia. Ten poziom abstrakcji osiąga się poprzez opis obiektów w uniwersalnym języku IDL (Interface Definition Language), który oprócz struktury obiektów ustala także specyfikacje metod działających na obiektach oraz zależności (wielo-) dziedziczenia.

Do współdziałania konieczne jest także określenie odwzorowania (mapping) implementacji obiektów na abstrakcyjną postać implikowaną przez IDL. Temu celowi poświęcony jest adapter obiektów, w szczególności BOA (Basic Object Adapter); jest on specyficzny dla danego języka programowania.


Podsumowanie (2)

Powiązanie pomiędzy aplikacją (odwołującą się do obiektów) i implementacją obiektów może mieć charakter statyczny lub dynamiczny, w zależności od tego, czy wiązanie następuje w czasie kompilacji czy też w czasie wykonania.

W przypadku statycznym, z wyrażenia IDL jest generowany automatycznie tzw. pniak (stub), czyli fragment kodu, który jest konsolidowany z aplikacją klienta. Po stronie serwera obiektów z wyrażenia IDL generowany jest szkielet (skeleton) implementacji, który programista musi zapełnić konkretnym kodem implementacyjnym wyspecyfikowanych metod.

W przypadku dynamicznym, dostęp następuje bezpośrednio poprzez odwołania dynamiczne, na zasadzie podobnej do RPC.

OMG CORBA obejmuje także dużą kolekcję usług i udogodnień, zarówno poziomych (niezależnych od dziedziny aplikacyjnej, np. usługi w zakresie nazw, zdarzeń, trwałych obiektów, związków, zapytań), jak i pionowych (specyficznych dla danej dziedziny aplikacyjnej, np. telekomunikacja, medycyna, finanse, wytwarzanie).


Podsumowanie (3)

Podstawowym elementem architektonicznym standardu CORBA jest tzw. pośrednik (Object Request Broker, ORB), skupiający w sobie funkcjonalności niezbędne do przetwarzania rozproszonych obiektów i współdziałania.

Pakiety ORB komunikują się ze sobą w sieci komputerowej przy pomocy protokółu GIOP (General Inter-ORB Protocol) lub jego internetowego odpowiednika IIOP.

W tej chwili zaimplementowano kilkanaście pakietów ORB.

CORBA ma ogromne znaczenie kulturotwórcze w dziedzinie informatyki.

Maksymalistyczne cele tego standardu są trudne do osiągnięcia, szczególnie w zakresie akceptowalnej wydajności (performance). Niektórzy specjaliści głoszą, że oparcie rozproszonych aplikacji o standard CORBA będzie zbyt kosztowne. Opinie te są prawdopodobnie nie zawsze prawdziwe, ale są podsycane przez konkurencję (np. Microsoft z technologią COM/DCOM).

Argument Microsoft’u przeciwko CORBA dotyczy zbyt wolnego rozwoju (COM już działa w skali masowej, natomiast pakiety ORB nie działają w tej skali i są zbyt zróżnicowane.)

Standardy w zakresie systemów rozproszonych i baz danych

Documents

Transcript of Standardy w zakresie systemów rozproszonych i baz danych