INFO
Sylabus
OMG CORBA, cz. 5
1. Usługa nazewnicza
2. Usługa nazewnicza: Wiązanie, rozstrzyganie
3. Usługa nazewnicza: kroki dla uzyskania referencji
4. Usługa handlowa (Trader)
5. Funkcje bazy danych Trader
6. Definicja typu usługi
7. Usługi w zakresie zdarzeń
8. Usługi w zakresie cyklu życiowego
9. Usługi w zakresie trwałych obiektów
10. Usługi w zakresie związków
11. Usługi w zakresie zapytań
12. Bieżące prace OMG
13. Najbardziej znane implementacje CORBA
14. Wady OMG CORBAi
15. Podsumowanie
Skorowidz
Wyście:
Wyklad V. Wprowadzenie do OMG CORBA, część 5 (KURS SSR)
I II III IV V VI VII VIII IX X XI XII XIII XIV
« poprzedni punkt   następny punkt »

15. Podsumowanie

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.

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

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

« poprzedni punkt   następny punkt »