Download
1 / 17
E N D
CORBA Łukasz Wnęk
Model obiektowy Grupa OMG definiując standard CORBA opierała się na opracowanym przez siebie abstrakcyjnym modelu obiektowym. Model opisany jest modelem konkretnym związanym z CORBą, przez co ma pewne ograniczenia oraz własne osobliwości. Obiekt jest identyfikowalnym, złożoną jednostką, która udostępnia jedną lub więcej usług.
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
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
ORB (ang. Object Request Broker). Jego głównym zadaniem jest dostarczanie zleceń do obiektów i następnie zwrot odpowiedzi od nich do klientów. Zapewnia on przezroczystą komunikację pomiędzy klientem i serwerem. ORB ukrywa: • Lokalizację obiektu: klient nie potrzebuje wiedzieć, gdzie obiekt jest ulokowany. • Implementację obiektu: klient nie potrzebuje wiedzieć, jak obiekt jest zaimplementowany. • Stan działania obiektu: klient nie potrzebuje wiedzieć, czy obiekt jest aktywny, gotowy do akceptacji zapytania, czy nie uczestniczy aktualnie w innych procesach. • Mechanizm komunikowania się obiektów: klient nie potrzebuje wiedzieć, jaki mechanizm komunikacyjny jest aktualnie używany (TCP/IP, lokalne wywołania metod, itd.)
Pniaki i szkielety 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 operacjizajmuje się dostarczanie zleceń klienta do implementacji obiektów.
SERWISY CORBY • Standard CORBY określa zbiór usług – serwisów (COS) wspomagających współdziałanie rozproszonych obiektów. • Serwisy są to standardowe obiekty CORBY, określane jako Object Services, zdefiniowane przy użyciu interfejsów języka IDL jako części składowe serwisu ORB.
Serwisy CORBA Jednym z głównych serwisów Corby jest NamingService. Pozwala on na większą uniwersalność systemu rozproszonego. Dostęp to powyższego serwisu dostępny jest z każdej platformy systemowej. Usługa ta umożliwia przekazanie referencji do obiektu. Działanie NamingService przedstawia poniższy rysunek.
SERWISY cd... Object life cycle – definiuje sposób tworzenia, likwidowania, kopiowania i przenoszenia obiektów CORBY, Naming – definiuje zasady nazewnictwa obiektów CORBY, Events – definiuje sposób komunikacji między obiektami CORBY, Relationships – specyfikuje relacje między obiektami CORBY, Externalization – nadzoruje transformację obiektów CORBY w zewnętrznych środowiskach,
CORBA-COM • Zarówno COM, jak i CORBA służą do tworzenia i komunikowania się struktury rozproszonych obiektów. Technologie te mają odrębny sposób obsługi obiektów i oferują różne usługi. Obie mają też swoje plusy i minusy.
CORBA-COM cd ... • COM jest dostępny bezpłatnie dla wszystkich komputerów pracujących w środowisku Windows. Jest to jego zaleta, ale zarazem i wada - nie ma bowiem wersji COM dla żadnej innej platformy. Jego potęgą jest integracja na niskim poziomie z systemem operacyjnym.
CORBA-COM cd • CORBA jest technologią zaimplementowaną praktycznie dla każdej platformy i wspierającą prawie każdy język programowania. Stosując CORBA, spotkamy się jednak z pewnym problemem - nie wszystkie ORB-y potrafią się ze sobą skomunikować. Potęga CORBA tkwi w jej niezawodności i skalowalności, systemy stosujące tę technologię zapewniają efektywniejsze wykorzystanie komputerów i większą stabilność pracy.
