komunikacja Inter-Object
Model COM został zaprojektowany tak, aby umożliwić klientom komunikację przezroczystą z obiektami, niezależnie od tego, gdzie te obiekty są uruchomione — w tym samym procesie, na tym samym komputerze lub na innym komputerze. Zapewnia to pojedynczy model programowania dla wszystkich typów obiektów oraz dla klientów obiektów i serwerów obiektów.
Z punktu widzenia klienta dostęp do wszystkich obiektów uzyskuje się za pośrednictwem wskaźników interfejsu. Wskaźnik musi być w trakcie przetwarzania. W rzeczywistości każde wywołanie funkcji interfejsu zawsze osiąga jakiś fragment kodu w procesie. Jeśli obiekt jest w trakcie przetwarzania, wywołanie dociera bezpośrednio do niego bez pośredniczącego kodu infrastruktury systemu. Jeśli obiekt jest poza procesem, wywołanie najpierw dociera do obiektu "proxy" dostarczonego przez com lub przez obiekt (jeśli implementator chce). Pakiety proxy wywołają parametry (w tym wszystkie wskaźniki interfejsu) i wygenerują odpowiednie zdalne wywołanie procedury (lub inny mechanizm komunikacji w przypadku niestandardowych wygenerowanych serwerów proxy) do innego procesu lub innego komputera, na którym znajduje się implementacja obiektu. Ten proces pakowania wskaźników transmisji przez granice procesów jest nazywany marshaling.
Z punktu widzenia serwera wszystkie wywołania funkcji interfejsu obiektu są wykonywane za pośrednictwem wskaźnika do tego interfejsu. Ponownie wskaźnik ma kontekst tylko w jednym procesie, a obiekt wywołujący musi zawsze być fragmentem kodu w procesie. Jeśli obiekt jest w trakcie przetwarzania, obiekt wywołujący jest sam klient. W przeciwnym razie obiekt wywołujący jest obiektem "wycinkowym" dostarczonym przez com lub sam obiekt. Łącznik odbiera zdalne wywołanie procedury (lub inny mechanizm komunikacji w przypadku niestandardowych wygenerowanych serwerów proxy) z "serwera proxy" w procesie klienta, unmarshalshals parametry i wywołuje odpowiedni interfejs na obiekcie serwera. Z punktu widzenia zarówno klientów, jak i serwerów, zawsze komunikują się bezpośrednio z innym kodem w procesie.
Com zapewnia implementację marshalingu, o nazwie standard marshaling. Ta implementacja działa bardzo dobrze w przypadku większości obiektów i znacznie zmniejsza wymagania programistyczne, dzięki czemu proces marshalingu jest skutecznie przejrzysty.
Jasne rozdzielenie interfejsu od implementacji przejrzystości procesów MODELU COM może jednak w niektórych sytuacjach przebiegać tak, jak w niektórych sytuacjach. Projekt interfejsu, który koncentruje się na jego funkcji z punktu widzenia klienta, może czasami prowadzić do decyzji projektowych, które powodują konflikt z efektywną implementacją tego interfejsu w sieci. W takich przypadkach potrzebne jest nie czysta przejrzystość procesu, ale "przejrzystość procesów, chyba że trzeba się obchodzić". Com zapewnia tę funkcję, umożliwiając implementatorowi obiektów obsługę niestandardowego marshalingu (nazywanej również marshalingiem IMarshal). Przeprowadzanie marshalingu w warstwie Standardowa jest w rzeczywistości wystąpieniem marshalingu niestandardowego; jest to domyślna implementacja używana, gdy obiekt nie wymaga marshalingu niestandardowego.
Można zaimplementować niestandardowe marshaling, aby umożliwić obiektowi wykonywanie różnych akcji w przypadku użycia z całej sieci niż w ramach dostępu lokalnego i jest całkowicie niewidoczne dla klienta. Ta architektura umożliwia projektowanie interfejsów klienta/obiektu bez względu na problemy z wydajnością sieci, a następnie późniejsze rozwiązywanie problemów z wydajnością sieci bez zakłócania ustalonego projektu.
Com nie określa, w jaki sposób składniki są ustrukturyzowane; określa sposób ich interakcji. COM pozostawia obawy dotyczące wewnętrznej struktury składnika do języków programowania i środowisk programistycznych. Z drugiej strony środowiska programistyczne nie mają ustalonych standardów pracy z obiektami poza natychmiastową aplikacją. Program Microsoft Visual C++, na przykład, działa bardzo dobrze w przypadku manipulowania obiektami wewnątrz aplikacji, ale nie obsługuje pracy z obiektami spoza aplikacji. Ogólnie rzecz biorąc, wszystkie inne języki programowania są takie same w tym zakresie. W związku z tym, aby zapewnić współdziałanie w całej sieci, COM, za pośrednictwem interfejsów niezależnych od języka, wybiera miejsce, w którym języki programowania odchodzą.
Podwójna pośrednia struktura vtbl oznacza, że wskaźniki w tabeli wskaźników funkcji nie muszą wskazywać bezpośrednio rzeczywistej implementacji w rzeczywistym obiekcie. Jest to serce przejrzystości procesów.
W przypadku serwerów przetwarzania, gdzie obiekt jest ładowany bezpośrednio do procesu klienta, wskaźniki funkcji w tabeli wskazują bezpośrednio do rzeczywistej implementacji. W takim przypadku wywołanie funkcji od klienta do metody interfejsu bezpośrednio przesyła kontrolkę wykonywania do metody . Nie może to jednak działać w przypadku obiektów lokalnych, nie mówiąc już o zdalnych, ponieważ wskaźniki pamięci nie mogą być współdzielone między procesami. Niemniej jednak klient musi mieć możliwość wywoływania metod interfejsu tak, jakby wywoływać rzeczywistą implementację. W związku z tym klient jednolicie przenosi kontrolkę do metody w niektórych obiektach, wykonując wywołanie.
Klient zawsze wywołuje metody interfejsu w niektórych obiektach procesu. Jeśli rzeczywisty obiekt jest lokalny lub zdalny, wywołanie jest wykonywane do obiektu proxy, który następnie wykonuje zdalne wywołanie procedury do rzeczywistego obiektu.
Więc jaka metoda jest rzeczywiście wykonywana? Odpowiedź polega na tym, że za każdym razem, gdy istnieje wywołanie interfejsu poza procesem, każda metoda interfejsu jest implementowana przez obiekt serwera proxy. Obiekt proxy jest zawsze obiektem w procesie, który działa w imieniu wywoływanego obiektu. Ten obiekt proxy wie, że rzeczywisty obiekt jest uruchomiony na serwerze lokalnym lub zdalnym.
Obiekt proxy pakuje parametry funkcji w niektórych pakietach danych i generuje wywołanie RPC do obiektu lokalnego lub zdalnego. Ten pakiet jest pobierany przez obiekt wycinkowy w procesie serwera na komputerze lokalnym lub zdalnym, który rozpakuje parametry i wykonuje wywołanie rzeczywistej implementacji metody. Po powrocie tej funkcji wycinkowie pakują wszystkie parametry out-parameters i zwracaną wartość i wysyła je z powrotem do serwera proxy, który rozpakuje je i zwraca je do oryginalnego klienta.
W związku z tym klient i serwer zawsze komunikują się ze sobą tak, jakby wszystko było w trakcie procesu. Wszystkie wywołania klienta i wszystkie wywołania serwera są w pewnym momencie procesem. Jednak ponieważ struktura vtbl umożliwia niektórym agentom, takim jak COM, przechwycenie wszystkich wywołań funkcji i wszystkich zwrotów z funkcji, agent może przekierować te wywołania do wywołania RPC w razie potrzeby. Chociaż wywołania w procesie są szybsze niż wywołania poza procesem, różnice procesów są całkowicie niewidoczne dla klienta i serwera.
Aby uzyskać więcej informacji, zobacz następujące tematy:
Tematy pokrewne