Enterprise Corba

1. Enterprise Corba Prezentacja seminaryjna T. Pieciukiewicz R. Hryniów

2. Wydajność • Prędkość działania konkretnej operacji zależy od: • Ilości RMI niezbędnych do jej zrealizowania, • Ilości danych przekazywanych w każdym wywołaniu, • Kosztach marshallingu danych.

3. Przykład • Pobieramy z serwera tablicę obiektów w celu wyświetlenia. • Wariant pierwszy: • Pobieramy sekwencje referencji do obiektów • Dla każdego obiektu pobieramy interesujące nas dane. • ZALETY: • Wszystkie działania wykonywane są tylko na obiektach • Zawsze mamy aktualne dane

4. Przykład cd. • WADY: • Duży koszt operacji w RMI – mamy 1 + n*m wywołań (n- liczba obiektów, m-liczba atrybutów). • Referencje do obiektów mają najwyższy koszt marshallingu (porównanie kosztów marshallingu dalej)

5. Przykład cd. • Wariant drugi: • Pobieramy sekwencję struktur zawierających interesujące nas dane. • Jeżeli potrzebujemy referencję do jednego z obiektów pobieramy ją na podstawie struktury. • ZALETY: • Mała liczba wywołań – dokładnie jedno – w celu pobrania danych • Mniejsza liczba utworzonych obiektów (poważna zaleta w niektórych ORBach) • Mniejsze koszty marshallingu • WADY: • Potrzeba wykonania dodatkowej operacji w celu pobrania obiektu. Nie wszystkim musi się to podobać.

6. Porównanie kosztów marshallingu

7. Przesyłanie dużej ilości danych • Użycie iteratorów:

8. Przesyłanie dużej ilości danych • Metoda przydatna przy przesyłaniu obrazów (lub innych danych binarnych). • Zalecana również przy przesyłaniu większej ilości struktur.

9. Messaging service – po co? • Przydatna jest możliwość przekazywania informacji z serwera do klienta (klientów) bez żądania ze strony klienta. • Np. aby informować klienta o aktualizacji danych. Jest to lepsze od odpytywania serwera przez klienta co ustalony okres czasu – zmniejsza obciążenie serwera i ruch w sieci.

10. Messaging service - kanały • Klienci zapisują się do kanałów informacyjnych, deklarując swoje zainteresowanie wiadomościami różnych kategorii. • Otrzymują tylko potencjalnie interesujące ich wiadomości. • Możliwość filtrowania wiadomości z określonego kanału.

11. Store and Forward • Zapewnia dotarcie wiadomości do klienta nawet jeśli ten nie był aktywny w momencie rozsyłania wiadomości (po rejestracji w systemie otrzymuje wszystkie oczekujące na niego wiadomości).

12. Messaging service - implementacje • VisiBroker • Orbix • Niektóre darmowe (np. JavaOrb)

13. Bezpieczeństwo • Security Service • Level 1: • Autentykacja użytkownika, • Bezpieczne wywoływanie metod (działające na poziomie interfejsów – tzn. deklarujemy bezpieczeństwo dla wszystkich obiektów implementujących dany interfejs), • Audyt.

14. Bezpieczeństwo cd. • Level 2 (brak pełnej implementacji): • Dynamiczna kontrola siły zabezpieczeń, • Dokładniejsza kontrola uprawnień • Możliwość zdobycia przez aplikację informacji o aktualnie obowiązujących zasadach bezpieczeństwa. • SecIOP – IIOP uzupełnione o bezpieczeństwo • Corba/Firewall Specification

15. Bezpieczeństwo cd. • ORB-SSL (może funkcjonować bez pozostałych serwisów bezpieczeństwa) • Autentykacja, • Szyfrowanie danych, • Integralność danych (zabezpieczenie przed zmianami w czasie transportu),

16. Transakcje • Sterowane przez klienta lub przez serwer. • Transakcje sterowane przez serwer – niewidoczne dla klienta. • Transakcje sterowane przez klienta – wywołania konkretnych metod sterujących transakcjami.

17. Transakcje rozproszone • Object Transaction Monitor – integruje CORBA z monitorem transakcji. • Wymagania: • Wsparcie dla bezpieczeństwa • Wsparcie dla równoważenia obciążenia • Kontrola przepływu wywołań (wielotransakcje!)

18. Transakcje rozproszone

19. Transakcje rozproszone

20. CORBA OTS

21. CORBA OTS – jak to działa?

22. Przepływ wywołań i multitransakcje

23. Zarządzanie pamięcią – zwalnianie obiektów • Możliwe polityki zwalniania obiektów: • Explicite zwalnianie obiektów przez klienta • Zamknięcie połączenia przez klienta • Okresowe przeglądanie obiektów w celu wyłonienia kandydatów do usunięcia • Przekroczenie progu ilości aktywnych obiektów • Podczas tworzenia nowego obiektu • Zewnętrzne

24. Wybór obiektów do zwolnienia • Najdłużej nieużywany • Po zakończeniu czasu wymaganej aktywności • Najstarszy obiekt

25. Skalowalność – limity połączeń • ORBy mają limit jednoczesnych połączeń (zależny od implementacji, np. 1000). • Co zrobić jeśli limit może zostać przekroczony? • Zamykanie połączeń – ze strony klienta (np. nie będzie na dłuższy czas potrzebne) lub serwera (długa nieaktywność klienta). • Koncentratory.

26. Koncentratory

27. Wielowątkowe serwery • Wielowątkowość może uratować nas przed zakleszczeniem w pewnych wypadkach. • Potencjalnie większa wydajność przy wieloprocesorowych maszynach. • Polityki podziału na wątki: • Thread-per-Request • Thread-per-Client (Connection) • Thread-per-Object • Thread Pool

28. Równoważenie obciążenia • Zrównoważenie obciążenia wszystkich serwerów danej aplikacji. • Zmniejszenie strat w wypadku awarii jednego z serwerów. • Ominięcie ograniczeń sprzętowych i programowych (np. limitu połączeń). • Związane z podziałem (poziomym lub pionowym) aplikacji lub replikacją.

29. Polityki migracji klienta • Na operację • Na transakcję • Na jednostkę pracy • Na sesję

30. Równoważenie nie jest darmowe • Koszt wyszukania najmniej obciążonego serwera (czas) • Koszt synchronizacji serwerów (czas) • Koszt uruchomienia nowych serwerów (czas, pieniądze!) • Koszt testowania procedur równoważących (czas, pieniądze!) • Inne koszty (czas?, pieniądze?)

31. CORBA a równoważenie obciążenia • Partycjonowanie poziome – realizacja przy pomocy Naming Service (lub podobnych). • Pionowe – na poziomie BD i aplikacji. • Replikacja – na poziomie ORB (brak specyfikacji) • Każdy dostawca komercyjny proponuje własne rozwiązania.

32. Odporność na awarie • Odporność na awarie -> odporność systemu na awarie spowodowane czynnikami takimi jak: • Awaria sprzętu lub systemu • Awaria sieci • Błędy w aplikacji • Sabotaż, klęski żywiołowe itd... 

33. Środki pozwalające uzyskać odporność • Replikacja serwerów i BD • Cold Backup (czekamy na awarię, po wystąpieniu startujemy nowy serwer) • Warm Standby (serwer zapasowy działa cały czas i synchronizuje się z głównym) • Hot Standby (grupa serwerów realizuje równolegle zlecenia klienta).

34. CORBA i odporność • Brak specyfikacji usług, protokołów itp. • Odporność na poziomie transportu (ORB) zależy od konkretnego produktu, • Odporność na wyższym poziomie zależy od rozwiązań organizacyjnych i konkretnych aplikacji.

35. Bibliografia • Dirk Slama, Jason Garbis, Perry Russel „Enterprise Corba” • Odrobina własnego doświadczenia 