Bazy danych i inżynieria oprogramowania

Standardy w zakresie systemów rozproszonych
i baz danych
Wykład 1:
Wprowadzenie do
OMG CORBA
Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
K.Subieta. SSR, Wykład 1, Folia 1
luty 2009
Terminologia, pojęcia, literatura
Niniejsza prezentacja nie obejmuje wielu cech OMG CORBA. Wyjaśnienie wielu
terminów z zakresu obiektowości, które wystąpią w tej prezentacji, znajduje się w:
K. Subieta: Słownik terminów z zakresu obiektowości
Akademicka Oficyna Wydawnicza PLJ, Warszawa 1999
http://www.ipipan.waw.pl/~subieta/artykuly/slownik_obiektowosci/hasla_slownika.html
Literatura:
Dokumentacja: http://www.omg.org + ogromna
ilość materiałów pochodnych
G.M. Doss, CORBA networking with Java
M. Henning, S. Vinoski, Advanced CORBA
programming with C++
U. Lang, R. Schreiner, Developing secure
distributed systems with CORBA
K.Subieta. SSR, Wykład 1, Folia 2
luty 2009
Problem: heterogeniczność
Heterogeniczność jest nieodłączną cechą sieci komputerowych i rozproszonych
aplikacji.Jest to cecha Internetu, Intranetu, WWW, syst. przepływu prac,
rozproszonych baz danych.
Np. system Intranetowy może składać się z różnorodnego 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
- różnorodne systemy oparte na RPC (Remote Procedure Call)
...oraz wymieniać pomiędzy sobą zróżnicowane zasoby informacyjne (dane).
K.Subieta. SSR, Wykład 1, Folia 3
luty 2009
Przyczyny heterogeniczności
Inżynierskie kompromisy
Rzadko się zdarza, aby było jedno akceptowalne rozwiązanie dla złożonego problemu.
Różni ludzie najczęściej znajdują różne rozwiązania dla podobnych problemów.
Integracja tych rozwiązań prowadzi do heterogeniczności.
Efektywność finansowa
Dostawcy oferują rożne produkty w różnych cenach. Klienci kupują te produkty
zgodnie ze swoim najlepszym wyczuciem spełnienia zadanych wymagań oraz
zminimalizowania kosztów.
Systemy spadkowe (legacy)
Systemy, które dawno zostały wdrożone dawno i działają efektywnie nie mogą być z tego
działania wyłączone. Nie jest możliwe lub jest bardzo kosztowne szybkie zastąpienie
ich przez nowe systemy. Muszą one jednak byæ integrowane z nowszymi systemami.
Np. efektywnie działający od 15-tu lat system zamówień jest krytyczny dla codziennej
działalności danej organizacji.
K.Subieta. SSR, Wykład 1, Folia 4
luty 2009
Współdziałanie (interoperacyjność)
interoperability


Dziedzina zajmująca się umożliwieniem współpracy niezależnie
zbudowanych (heterogenicznych) systemów, szczególnie w
sieciach komputerowych.
Spośród ogromnej liczby aspektów związanych z tym pojęciem
można wyróżnić następujące:
– Budowa otwartych systemów operacyjnych; podtrzymywanie przez te
systemy odległego wołania procedur (remote procedure calls, RPC)
– Adaptacja/wykorzystanie starszego oprogramowania przez nowsze systemy
(legacy applications)
– Budowa wspólnego obrazu danych (wizji danych), oraz wspólnego języka
dostępu i manipulacji danymi dla heterogenicznego zbioru baz danych.
– Dostęp do „obcych” baz danych z danego systemu zarządzania bazą
danych.
– Automatyczna translacja programów.
– Opracowanie różnorodnych standardów: SQL, ODMG, ODBC, JDBC, itd.
K.Subieta. SSR, Wykład 1, Folia 5
luty 2009
Przenaszalność
portability





Własność języka programowania umożliwiająca przenoszenie
programów napisanych w tym języku na różne platformy.
Przenaszalność wymaga precyzyjnego wyspecyfikowania składni i
semantyki języka, oraz wyeliminowania z niego wszelkich własności
specyficznych dla poszczególnych platform.
Przenaszalność jest podstawowym celem standaryzacji, ale wiele
standardów nie spełnia tego kryterium.
Przenaszalność jest celem standardów OMG CORBA oraz ODMG,
ale jak dotąd jest to życzenie, a nie realnie osiągnięta własność.
Przenaszalność realizuje język Java, który nie jest kompilowany do
poziomu sprzętowego, a do poziomu abstrakcyjnej maszyny.
– Ale przenaszalność w Java dotyczy tylko „czystej” Javy.
– Jakiekolwiek odwołania do zewnętrza mogą czynić program nieprzenaszalnym
K.Subieta. SSR, Wykład 1, Folia 6
luty 2009
Co to jest OMG?
Object Management Group
Konsorcjum programistyczne utworzone w 1989 r. Zajmuje się rozwojem,
adaptacją i promowaniem standardów dla rozwijania i rozprzestrzeniania
aplikacji w środowiskach heterogenicznych i rozproszonych.
Skupia ok. 800 czołowych firm rozwojowych, producentów i dostawców
oprogramowania oraz użytkowników.
Technika działania: RFP (Request For Proposal): zapytania odnośnie konkretnych
tematów wysyłane przez komitety OMG do wszystkich członków.
Członkowie (aktywni w danej sprawie) nadsyłają swoje propozycje.
Integracja propozycji następuje wewnątrz komitetów na zasadzie głosowania.
Rezultat działalności:
OMA (Object Management Architecture), której najważniejszym składnikiem jest
CORBA (Common Object Request Broker Architecture)
OMG oferuje wiele innych standardów, w tym UML, MDA, MOF, XMI, CWM,
oraz prowadzi prace nad nowymi, w tym nad obiektowymi bazami danych
K.Subieta. SSR, Wykład 1, Folia 7
luty 2009
Misja OMG
Opracowanie jednorodnej architektury z użyciem technologii obiektowej,
mającej na celu integrację rozproszonych aplikacji, która zapewniałaby:
•
ponowne użycie komponentów oprogramowania i danych
•
współdziałanie i przenaszalność
•
podstawy rynku kompatybilnego oprogramowania
OMG skupia się na szybkim rozwoju łatwych w użyciu
(dostępnych “na półce”) standardowych komponentów.
K.Subieta. SSR, Wykład 1, Folia 8
luty 2009
Zalety rozproszonych obiektów
Zgodność z logiką biznesu (obiekty biznesowe mogą być bezpośrednio
zaimplementowane jako obiekty CORBA)
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 małe 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
K.Subieta. SSR, Wykład 1, Folia 9
luty 2009
Koncepcja OMG
• Jednorodna terminologia dla modelu obiektowego
• Jedna, zuniformizowana perspektywa danych dla
całego rozproszonego, heterogenicznego systemu
• Zachowanie autonomii lokalnych systemów
• Wspólna abstrakcyjna rama koncepcyjna
• Wspólny model odwoływania się do danych i usług
• Wspólne interfejsy i protokóły
• Podstawą integracji modelu są kluczowe cechy obiektowości,
takie jak obiekty, klasy (interfejsy), metody (operacje),
hermetyzacja, polimorfizm i dziedziczenie
K.Subieta. SSR, Wykład 1, Folia 10
luty 2009
OMG: Czołowi partnerzy
Andersen
APM
Apple
ASCII
AT&T
Bell Nothern
Borland
Bull
CA
CI Labs
Data Access
Digital
EDS
Expertsoft
Fujitsu
Genesis
HP
HyperDesk
ICL
Informix
Intel
IntelliCorp
IBM
Micro Focus
Microsoft
MITRE
NeXT
Novell
Object Design
Object Tech.Int’l
Oracle
OSF
ParcPlace
POSC
Siemens Nixdorf
Software AG
Sun Microsyst.
Sybase
Symantec
Taligent
Telefonica I+D
Tivoli
TRW
Unisys
Xerox
Od 2006 roku PJWSTK jest członkiem OMG
* Jako jedyna instytucja w Polsce
Istnieje wiele produktów i aplikacji opartych o standard CORBA.
* Szacunkowo ok. 7 milionów
* Praktycznie każdy miesiąc przynosi informację o nowym produkcie.
Microsoft należy do OMG, ale konkuruje z tym ciałem i nie uczestniczy w pracach
K.Subieta. SSR, Wykład 1, Folia 11
luty 2009
Konkurencja dla CORBA

RMI (Remote Method Invocation) + Java Beans
– Technologia związana wyłącznie z językiem Java, więc nie
nadaje się dla aplikacji pisanych w innych językach.

Web Services – podobna idea, ale wszystko odbywa się na
bazie „prostego” protokołu SOAP opartego na XML
– Reklamowane jako prostsze od CORBA, ale na dzisiaj wcale nie
jest to pewne



ESB (Enterprise Service Bus) – technologia związana z
Web Services, zajmująca się komunikacją i
kolejkowaniem komunikacji pomiędzy serwisami
Sieci P2P – ograniczone zastosowania biznesowe ze
względu na ograniczoną funkcjonalność i bezpieczeństwo
Wirtualne repozytoria – technologia, która jeszcze nie
wyszła z fazy laboratoryjnej.
K.Subieta. SSR, Wykład 1, Folia 12
luty 2009
OMA: ogólna architektura
Wspólne udogodnienia (Udogodnienia CORBA)
Wspólne udogodnienia pionowe (dziedzinowe)
Rachunkowość
Obiekty Aplikacyjne
Finanse
Medycyna
.....
Wspólne udogodnienia poziome
Rozproszone Zarządzanie Zarządzanie Zarządzanie
dokumenty informacją
systemem
zadaniami
.....
Object Request Broker
(Pośrednik Zapotrzebowania na Obiekty)
Nazwowa
Trwałość
Dostęp zewnętrzny
Własności
K.Subieta. SSR, Wykład 1, Folia 13
Cykl życiowy
Transakcje
Zdarzenia
Współbieżność
Zapytania
Związki
Wspólne Usługi Obiektowe
(Usługi CORBA)
Kolekcje
Ochrona
Startup
Handlowa
Czas
Licencje
luty 2009
OMA: Architektura Zarządzania Obiektami
Object Management Architecture
OMA
{
Model obiektów (opis obiektów rozproszonych w sieci komputerowej)
Model referencji (interakcja pomiędzy obiektami)
Model obiektów OMA:
Obiekt jest hermetyzowanym bytem z unikalną niezmienialną tożsamością.
Obsługa obiektów może odbywać się wyłącznie poprzez dobrze
zdefiniowane interfejsy.
Klienci wysyłają zlecenia do obiektów, które wykonują
odpowiednie usługi.
Implementacja i lokacja obiektów jest dla klienta ukryta.
K.Subieta. SSR, Wykład 1, Folia 14
luty 2009
Usługi i udogodnienia standardu CORBA
Usługi CORBA
Udogodnienia pionowe
Udogodnienia poziome
Współbieżność
Zdarzenia
Dostęp z zewnątrz
Cykl życiowy
Nazwowa
Trwałość
Zapytania
Związki
Transakcje
Licencje
Prawa własności
Bezpieczeństwo
Temporalność
Zarządzanie zmianami
Kolekcje danych
Wymiana danych
Replikacje
Obrót skł. oprogr.
Rachunkowość
Rozwijanie aplikacji
Wytwarzanie wsp. komp.
Finanse
Rozproszona symulacja
Wizualizacja
Informatyczne autostrady
Mapy wsp.komp.
Produkcja i ekspl.
ropy i gazu
Instytucje ochrony
Telekomunikacja
Medycyna
...
Interfejsy użytkownika
Zarządzanie informacją
Zarządzanie systemem
Zarządzanie jakością
Planowanie
Zarządzanie zadaniami
Przepływy pracy
Zarządz. bezpieczeństwem
...
K.Subieta. SSR, Wykład 1, Folia 15
luty 2009
OMA: usługi obiektowe
Object Services
Są to interfejsy niezależne od dziedziny, które mogą być używane przez wiele
systemów rozproszonych obiektów.
Np. usługa polegająca na rozpoznaniu wszystkich istniejących w systemie usług
jest potrzebna niezależnie od dziedziny aplikacyjnej.
Przykłady usług:
Usługa w zakresie nazw (naming service) - pozwala klientom na odszukanie
obiektów (ich referencji) na podstawie ich nazw.
Usługa “handlowa” (trading service) - pozwala klientom na odszukanie
obiektów na podstawie pożądanych własności obiektów.
Pozostałe:
K.Subieta. SSR, Wykład 1, Folia 16
 usługi w zakresie zarządzania cyklem życia obiektu
 usługi w zakresie bezpieczeństwa
 usługi w zakresie transakcji
 usługi w zakresie zdarzeń
 ...inne...
luty 2009
OMA: wspólne udogodnienia
Common Facilities
Są to mechanizmy wspólne dla dziedzin aplikacyjnych, ale w odróżnieniu od usług
obiektowych są one
zorientowane na aplikacje związane z użytkownikiem końcowym.
Przykładem jest DDCF (Distributed Document Component Facility), mechanizm
do tworzenia i zarządzania składowymi dokumentów oparty na OpenDoc
(Apple). Umożliwia on zaprezentowanie i wymianę obiektów opartych o model
dokumentu, np. umożliwia powiązanie/wstawienie obiektu zawierającego arkusz
kalkulacyjny do obiektu zawierającego raport.
Inne przykłady: wspólny edytor tekstowy, udogodnienia dla tworzenia grafiki,
itd.
K.Subieta. SSR, Wykład 1, Folia 17
luty 2009
OMA: Interfejsy dziedzinowe i aplikacyjne
Domain Interfaces, Application Interfaces
Interfejsy dziedzinowe są podobne do usług obiektowych i wspólnych
udogodnień, ale są zorientowane nie “poziomo” lecz “pionowo”,
tj. na konkretną dziedzinę aplikacyjną.
Przykłady
• PDM (Product Data Management) dla dziedziny CAM
(Computer-Aided Manufacturing, wytwarzanie wspomagane komputerowo).
• telekomunikacja
• medycyna
• finanse
• ...
Interfejsy aplikacyjne są opracowane dla konkretnej dziedziny aplikacyjnej.
OMG nie zajmuje się aplikacjami, lecz specyfikacjami. Interfejsy te nie należą
więc do standardu, ale są kandydatami do standaryzacji w przyszłości.
K.Subieta. SSR, Wykład 1, Folia 18
luty 2009
Użycie modelu OMA
Koncepcja polega na zdefiniowaniu zrębów (frameworks), tj. grup obiektów
specyficznych dla danej dziedziny, które ustalają w niej rozwiązanie jakiegoś
problemu: np. w telekomunikacji, medycynie, finansach, wytwarzaniu.
IA, ID,
WU, UO
IA,
WU, UO
WU, UO
komponenty
aplikacji
komunikują
się poprzez
ORB
ORB, Object Request Broker
(Pośrednik Zapotrzebowania na Obiekty)
UO
IA - Interfejsy Aplikacyjne
ID - Interfejsy Dziedzinowe
K.Subieta. SSR, Wykład 1, Folia 19
UO
Zrąb
obiektowy
WU - Wspólne Udogodnienia
UO - Usługi Obiektowe
luty 2009
CORBA: podstawowe cechy
Common Object Request Broker Architecture
CORBA 2, 1995
CORBA 3, 2000
Główne cechy
• Rdzeń ORB (ORB Core)
• OMG IDL (Interface Definition Language) Język Definicji Interfejsu
• Repozytorium Interfejsów (Interface Repository)
• Repozytorium Implementacji (Implementation Repository)
• Odwzorowania językowe
• Pieńki (stubs) i szkielety (skeletons)
• Dynamiczne wołanie i przesyłanie (dispatching)
• Obiektowe adaptery (Object Adapters)
• Wewnętrzne protokoły ORB (GIOP, IIOP)
K.Subieta. SSR, Wykład 1, Folia 20
luty 2009
Ogólna architektura standardu CORBA
Implementacja obiektów
(reprezentacja i przechowywanie
obiektów; realizacja dostępu i usług)
Klient
Wołania
dynamiczne
(RPC)
Pieniek
IDL
(IDL stub)
Interfejs
do
pośrednika
ORB
Dynamiczny
Szkielet Interfejsu
Szkielet obiektów
(IDL skeleton)
Adapter
obiektów
Rdzeń Pośrednika (ORB core)
Takie samo dla wszystkich ORB
Może być wiele adapterów obiektów
Pieńki i szkielety
specyficzne dla interfejsów
Prywatne interfejsy ORB
K.Subieta. SSR, Wykład 1, Folia 21
luty 2009
Przesyłanie zlecenia od klienta do obiektów
Implementacja obiektów
Klient
dynamiczne
Wołania
dynamiczne
(RPC)
Pieniek
IDL
(IDL stub)
Interfejs
do
pośrednika
ORB
statyczne
Dynamiczny
Szkielet Interfejsu
Szkielet obiektów
(IDL skeleton)
Adapter
obiektów
Rdzeń Pośrednika (ORB core)
K.Subieta. SSR, Wykład 1, Folia 22
luty 2009
CORBA: schemat komunikowania się klienta z
serwerem
Host klienta
Host serwera
Klient
Wywołanie
operacji
Obiekt
zlecenie
Pośrednik (ORB, Object Request Broker)
wynik, parametry wyj
Definicja obiektów w IDL pozwala dla klienta widzieć je na abstrakcyjnym poziomie.
Klient jest zwolniony z rozpatrywania jakichkolwiek środków komunikacji pomiędzy
klientem i serwerem. Z jego punktu widzenia obiekty znajdują się bezpośrednio
(wirtualnie) w jego przestrzeni adresowej.
K.Subieta. SSR, Wykład 1, Folia 23
luty 2009
CORBA: schemat wywoływania statycznego
Host klienta
Host serwera
Klient
Wywołanie
operacji
Obiekt
Pieniek
klienta
zlecenie
Implementacja
interfejsu do
obiektu
(szkielet + kod)
Pośrednik (ORB, Object Request Broker)
wynik, parametry wyj
Pieniek klienta jest fragmentem aplikacji klienta generowanym automatycznie z
wyrażenia IDL.
Implementacja interfejsu do obiektu po stronie serwera powstaje ze szkieletu interfejsu
do obiektu, automatycznie generowanego z wyrażenia IDL, który jest następnie
wypełniany (ręcznie) kodem implementacji operacji zdefiniowanych w wyrażeniu IDL.
K.Subieta. SSR, Wykład 1, Folia 24
luty 2009
Pniaki i szkielety
stubs, skeletons
Pniak (stub) znajduje sie po stronie klienta i zajmuje się tworzeniem i wysyłaniem
jego zleceń.
Szkielet (skeleton) znajduje się po stronie serwera. Szkielet wypełniony kodem
implementacji operacji zajmuje się dostarczaniem zleceń klienta do implementacji
obiektów.
Obydwa mechanizmy są tworzone bezpośrednio ze specyfikacji w IDL, są więc specyficzne dla
danego interfejsu. Są one wbudowane bezpośrednio w w aplikację klienta i w implementację
obiektów. Wiązanie jest statyczne, wołanie operacji jest odwzorowane w wołanie funkcji w
odpowiednim języku programowania.
Pniak zajmuje się uszeregowaniem (marshal) zlecenia, tj. zamienia je na formę odpowiednią
dla transmisji. Serwer ORB i szkielet dokonują operacji odwrotnej (unmarshal), czyli konwersji
z postaci transmitowanej do postaci wymaganej przez język programowania.
Po wykonaniu zlecenia, odpowiedź jest wysyłana w odwrotną stronę, poprzez szkielet, serwer
ORB i pniak, do aplikacji klienta.
K.Subieta. SSR, Wykład 1, Folia 25
luty 2009