Standardy w zakresie systemów rozproszonych i baz danych

1. Standardy w zakresie systemów rozproszonych i baz danych Wykład 5: Wprowadzenie do OMG CORBA Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2. Usługi nazewnicza Name Service • 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: user home sys u1 u2 u3 bill alden bin lib c1 c2 l1 l2 - kontekst nazwowy - nazwa obiektu

3. Usługa nazewnicza: wiązanie, rozstrzyganie binding, resolving Wiązanie: przypisanie nazwy do obiektu void bind( in Name n, in Object obj ) raises(NotFound, CannotProceed, InvalidName, AlreadyBound) kontekst -> bind( foo, myobj ) Przykładowe wywołanie: Rozstrzyganie: odszukanie obiektu posiadającego przypisaną nazwę. Object resolve( in Name n) raises (NotFound, CannotProceed, InvalidName) myobjref = kontekst -> resolve( foo ) Przykładowe wywołanie: Nazwy mogą mieć postać ciągów <c1;c2;...;cn>. Wiązanie i rozstrzyganie rekurencyjne. user; u2; foo kontekst kontekst nazwa prosta

4. 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.

5. 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. Klient Korzystanie z usługi Pytanie o usługę Rezultat wyszukiwania Rejestracja usługi wraz z opisem Trader Obiekt

6. Funkcje bazy danych Trader 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 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: 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.

7. 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.

8. Usługi w zakresie zdarzeń Event Service Usługa ustala dwie role obiektów: dostawcy zdarzeń i konsumenta zdarzeń. Komunikacja pomiędzy dostawcą i konsumentem wykorzystuje standardowe zlecenia CORBA. 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. interface PushConsumer { void push( in any data ) raises(Disconnected); void disconnect_push_consumer(); }; Np. notowanie aktualizacji obiektu: aktualizowany obiekt działa jako dostawca zdarzenia. Inne relewantne obiekty (np. posiadające wskaźniki do obiektu aktualizowanego działają jako konsumenci zdarzenia. W modelu “ciągnącym” konsumenci periodycznie odpytują dostawcę (metoda try_pull) na okoliczność wystąpienia zdarzenia.

9. Usługi w zakresie cyklu życiowego Life Cycle Service Tworzenie obiektów Przesuwanie obiektów Kasowanie obiektów Kopiowanie obiektów Przykładowe problemy do rozstrzygnięcia: • 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.

10. Usługi w zakresie trwałych obiektów Persistent Object Service Klient Zawiera zestaw interfejsów do zarządzania trwałymi obiektami. Trwały obiekt, PO Trwały identyfikator, PID Zarządca Trwałymi Obiektami, POM Protokół Usługi w/z trwałych obiektów, PDS Ze względu na niski poziom koncepcyjny, brak niezależności danych, przywiązanie do bardzo partykularnych protokółów, usługa bardzo przypomina styl DBTG CODASYL, który dawno temu został odrzucony. Skład danych

11. Usługi w zakresie związków (1) Relationship 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. • 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. Podobnie jak w przypadku trwałości, usługa w zakresie związków jest zdefiniowana na niskim poziomie abstrakcji.

12. Usługi w zakresie związków (2) • 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 Operacje: Rola obiektu jest tworzona niezależnie poprzez wytwórnię ról. Ciąg ról jest parametrem dla wytwórni związku. Role create_role ( in RelatedObject related_object ) raises ( NilRelatedObject, RelatedObjectTypeError ) struct NamedRole { RoleName name; Role aRole; } ; typedefsequence <NamedRole> NamedRoles; Relationship create ( in NamedRoles named_roles ) raises ( RoleType Error, MaxCardinalityExceeded, DegreeError, DuplicateRoleName, UnknownRoleName) RelatedObject get_other_related_object ( in RelationshipHandle rel, in RoleName target_name ) raises ( UnknownRoleName, UnknownRelationship )

13. Usługi w zakresie zapytań (1) Query Service 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

14. Usługi w zakresie zapytań (2) 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 opracowania wspó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.

15. Bieżące prace OMG (1) 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. 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.

16. Bieżące prace OMG (2) ORBOS (ORB/Object Services) Task Force Dotychczas CORBA pozwala przesyłać referencje do obiektów, ale nie pozwala przesył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 ze standardami Microsoft COM i DCOM. COM/CORBA jest właśnie zaakceptowany, natomiast DCOM/CORBA jest w trakcie opracowania. COM/DCOM niekoniecznie jest konkurentem dla CORBA, raczej jest 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ładane w dowolne konfiguracje architektoniczne. Trudno powiedzieć, czy ten cel jest osiągalny.

17. 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

18. Specyfikacje OMG (2) Data-Distribution Service for Real-time Systems™  (DDS™) OMG Systems Modeling Language Business Process Modeling Notation (BPMN)

19. Najbardziej znane implementacje CORBA

20. 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

21. 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ą.

22. 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 (BasicObject Adapter); jest on specyficzny dla danego języka programowania.

23. 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).

24. 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.)