Technologie komponentowe COM, COM+, DCOM

Prezentacja na temat: "Technologie komponentowe COM, COM+, DCOM"— Zapis prezentacji:

1 Technologie komponentowe COM, COM+, DCOM
Marek Zdarta©®™ I tak pewnie nikt tego nie będzie czytał więc na rozluźnienie link: LOL

2 Wstęp Pierwotne założenia Historia technologii
Podział (COM, COM+, DCOM) Pierwotne założenia. Podstawowy skrót jest rozumiany jako Component Object Model i odnosi się do zasady działania technologii. Słowo komponent oznacza skompilowany moduł programowy, który za pomocą odgórnie zdefiniowanego interfejsu udostępnia swe funkcje i jest zdolny do współpracy z systemem operacyjnym i innymi komponentami. Już w czasach Windows 3.0 zaistniała potrzeba stworzenia komunikacji międzyprocesowej wykraczającej poza wysyłanie wiadomości tekstowych lub komunikatów systemu. W roku 1993 Microsoft przedstawił więc technologię COM. Jej główną częścią składową były OLE2 (ang. Object Linking and Embedding), których zadania wykraczały poza współdzielenie treści między różnymi dokumentami. Od tej pory były to moduły, które swoją funkcjonalność udostępniały wielu różnym aplikacjom korzystającym z interfejsu COM. Na bazie tej specyfikacji powstały takie technologie, jak DirectX, SQL Server, MS Access i inne. Technologia COM jest w zasadzie ramową i określa całą rodzinę technologii komponentowych. COM+ natomiast powstał z myślą o systemach biznesowych (np.. Windows NT). Z kolei rozwinięcie DCOM powstało jako odpowiedź na konkurencyjną technologię CORBA i umożliwiało aplikacjom sieciowym komunikację. Zostało ono wprowadzone po raz pierwszy również w Windows NT4.0.

3 COM Główne cechy: Możliwość uruchamiania na wielu różnych platformach
Implementacja wspólnych obiektów dla różnych środowisk programistycznych Łatwy dostęp do funkcji przy pomocy tzw. interfejsów Choć COM został stworzony przez Microsoft głównie dla systemów operacyjnych Windows, możliwe jest stosowanie go także na innych platformach. Głównym celem stworzenia technologii było (oprócz współdzielenia tekstu między aplikacjami) danie możliwości współpracy między różnymi językami programowania. Udało się to osiągnąć poprzez implementację obiektów w sposób niezależny od języka programowania, dzięki czemu nie dość, że mogą być używane w środowiskach różnych od tych w jakich zostały stworzone, ale nawet na różnych platformach sprzętowych. Jeśli dany komponent jest bardzo dobrze napisany i odpowiednio wykorzystuje interfejsy – aplikacja nie będzie w stanie „rozpoznać” metody implementacji. Obiekty utworzone za pomocą COM same są odpowiedzialne za tworzenie konstruktorów oraz destruktorów przy pomocy licznika odniesień. Preferowaną metodą dziedziczenia w technologiach komponentowych jest natomiast tworzenie pod-obiektów, do których odwołują się poszczególne metody.

4 COM Wady technologii: Pętla zdarzeń Zliczanie odniesień „DLL hell”
Bezpieczeństwo Mimo, że technologia ma wiele szczytnych założeń, ma też sporo wad. Pierwszą z nich jest tzw. event loop (message pumping, message loop). Sama ta technologia oznacza stworzenie obiektu, który odpowiada za przesyłanie wiadomości między procesami. W praktyce sprowadza się to do odpytywania (a raczej czekania na przyjście zdarzenia) i często do zakleszczeń (nawet w obrębie całego systemu!) jeśli nie pojawi się żadne ze zdarzeń. Drugim znaczącym problemem jest tzw. „Reference counting”. Zliczanie odniesień może stanowić problem, gdy do dwóch lub więcej obiektów pojawiają się cykliczne odniesienia. Projektant aplikacji musi też pamiętać, że obiekty nie mogą zostać osierocone. W tym przypadku proces oczekuje z uruchomieniem zdarzenia do czasu, gdy licznik osiągnie wartość 0; a to nie musi wcale nastąpić! Istnieją dwie metody przerywania cyklu: „out-of-band termination” polega na udostępnieniu przez jeden z obiektów metody, która automatycznie przerwie cykl „split identities” – jeden proces tworzy dwa obiekty połączone „słabym odniesieniem”, przez co mogą być usunięte przez mechanizm garbage collector DLL h3ll – problem dotyczący tylko systemów Windows (95-Me). Wywodził się z tego, że GUID każdego pliku DLL, COM, etc musiał zostać wpisany do rejestru systemu operacyjnego. Nie dość, że powiększało to znacząco jego rozmiary to powodowało masę problemów: Często zdarzało się, że dany plik był wykorzystywany tylko przez jedną aplikację Kilka różnych aplikacji mogło wymagać plików o tych samych nazwach, choć różniących się np. wersją i tym samym zgłaszało komunikaty z błędami Problem ten dało się znacznie ograniczyć w Windows XP (i późniejszych) poprzez tzw „Registration-free COM” – komponenty już nie musiały być „spisane” w rejestrze, a mogły się znajdować w folderach programów (wyjątkami są Internet Explorer, DirectX, MSXML, etc). Kwestia bezpieczeństwa – pomijając negatywny wpływ na bezpieczeństwo i stabilność systemu powyższych problemów jest jeszcze kwestia kontrolek ActiveX. Są to obiekty COM przeznaczone do rozpowszechniania w internecie i zazwyczaj rozszerzające możliwości przeglądarki Internet Explorer. Do niedawna, gdy nie był od nich wymagany podpis cyfrowy – były źródłem rozprzestrzeniania szkodliwego oprogramowania, ataków na komputery, etc. Spowodowało to ogólną niechęć do produktu MS.

5 COM+ Wprowadzone technologii do Windows NT4.0
Nowe możliwości wraz z premierą Windows 2000 Technologia ta miała swój początek w Win NT4 po to, by dać developerom możliwość korzystania z wielu zaawansowanych mechanizmów, pokroju transakcji rozproszonych, odpytywania o zasoby, lepszego wykorzystania CPU i pamięci, ale też by Microsoft mógł wkroczyć na rynek profesjonalnego oprogramowania biznesowego jako „zawodnik” alternatywny do już obecnych. Wraz z premierą Win200 firma wprowadziła do systemu tzw. Microsoft Transaction Server, a wraz z nim na stałe technologię COM+. Interfejsy komponentów COM+ z kolei dostępne przez usługi komponentowe, co pozwalało pozbyć się części problemów i odciążało programistów. Jedną z ważniejszych zalet nowej technologii była możliwość tworzenia wielokrotnych odwołań do już załadowanego komponentu (o ile był dobrze napisany), co pozwalało zmniejszyć zużycie zasobów.

6 DCOM Sieciowa wersja technologii komponentowych
Konieczność rozwiązania problemu marshallingu, „distributed garbage collection” Konkurencyjne technologie Zarzucenie na rzecz platformy .NET Najważniejszą cechą nowej technologii była możliwość użytkowania jej przez interfejsy sieciowe, co w poprzednich wersjach znacznie niedomagało. Przedrostek „D” wziął się z użycia technik DCE/RPC (zdalne wywołanie procedur – pozwala to na pracę oprogramowania na kilku maszynach jednocześnie). Ułatwiło to programistom pisanie aplikacji rozproszonych – nie musieli już się martwić o problemy związane z elementami stricte sieciowymi. Problemem, którego Microsoft (tak samo jak twórcy konkurencyjnej CORBY) nie mógł przeskoczyć były firewalle, przez co obie technologie zwyciężył protokół HTTP wraz z przeglądarkami internetowymi. Dwoma problemami, z którymi trzeba się było uporać był marshalling i „zbieranie nieużytków z aplikacji rozproszonych”. Pierwszy oznacza – konieczność transformacji bardziej złożonych obiektów na prostsze (ciąg znaków, plik XML) w celu przesłania ich np. przez sieć, do innych wątków, czy też aplikacji napisanych w różnych językach programowania. Z kolei drugi problem oznacza systemowy mechanizm usuwania z pamięci użytych już komponentów, danych przez nie pozostawionych i innych śmieci, pozostawionych nawet przez aplikacje „rezydujące” na innej maszynie. Choć DCOM powstało jako odpowiedź na konkurencyjną technologię CORBA, istnieją także inne technologie komponentowe, takie jak COMsource, j-Interloop, j-Integra czy EntireX DCOM (komercyjny). Niezależnie od wad i zalet technologii COM, firma Microsoft zarzuciła jej rozwijanie na rzecz całkowicie autorskiej platformy .NET.

7 Koňec!