Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona10/113
Data23.10.2017
Rozmiar8,01 Mb.
1   ...   6   7   8   9   10   11   12   13   ...   113

Obiekty aplikacji (Aplication Objects). OMA jest ukierunkowana na aplikacje, które są współoperatywne, przenośne i nadające się do ponownego użycia. Dlatego obiekty aplikacji są specyficzne dla poszczególnych aplikacji użytkownika końcowego i reprezentują obiekty biznesowe lub programy użytkowe działające na tych obiektach. Ten rozdaj obiektów obejmuje np. Word, Excel, i inne aplikacje użytkownika.

  • Pośrednik zleceń obiektów(Object Request Broker –ORB). Jest to główny składnik pośredniczący między rozproszonymi obiektami, przesyłający wywołania metod do odpowiednich obiektów docelowych i zwracający wyniki do obiektów wywołujących.

  • Wspólne usługi obiektów (Object Services). Usługi te wspierają komunikację między rozproszonymi obiektami. Obejmują one podstawowe funkcje, takie jak zabezpieczenie, przetwarzanie zdarzeń, trwałość obiektów, obsługę transakcji, zapytań, związków(asocjacji) między obiektami i inne.

  • Wspólne udogodnienia (Common Facilities). Tworzą one zbiór obiektów o przeznaczeniu ogólnym (np. Obsługa błędów, drukowanie, poczta elektroniczna) wymagane przez wiele aplikacji.

    Rys. 22


    CORBA działa jako główna architektura DOM, nadająca konkretny kształt Architekturze Zarządzania Obiektami (OMA), treści, funkcjonalności i interfejsom pośrednika. Celem standardu 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 różnice implementacyjne nie miały znaczenia. Dlatego konsorcjum OMG nigdy nie poprzestawało na standardach binarnych. 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 specyfikację metod działających na obiektach oraz zależności 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 BOA (Basic Object Adapter). Ten adapter jest specyficzny dla wyznaczonego języka programowania. Na rys.23 jest pokazana architektura standardu CORBA oraz przesyłanie zleceń statycznych i dynamicznych pomiędzy klientem i obiektem.

    Rys. 23


    Podstawowym elementem standardu CORBA jest pośrednik zamówień (Obiect Request Broker, ORB), skupiający w sobie wymienione wyżej funkcjonalności niezbędne do przetwarzania rozproszonych obiektów i współdziałania. ORB jest pośrednikiem spełniającym funkcję brokera. Broker przekazuje zlecenie usługi do serwera, a później przekazuje wyniki z powrotem do klienta. Jeśli broker, do którego się zwrócono, nie może dostarczyć zleconej usługi, to może się skonsultować z innymi brokerami. Pakiety ORB klienta i obiektu komunikują się ze sobą w sieci komputerowej przy pomocy protokółu IIOP (Internet Inter –ORB Protocol).

    Standard CORBA składa się w istocie z trzech części:



    1. Zbioru interfejsów wywołań

    2. Pośrednika zamówień obiektowych (ORB)

    3. Zbioru adapterów obiektów.

    Każdy pośrednik ORB musi mieć magazyny interfejsów oraz implementacji. Skompilowane interfejsy można odzyskiwać z magazynu interfejsów za pomocą interfejsu do pośrednika ORB. Skompilowane fragmenty programów, nazywane serwerami obiektów, które mogą implementować takie interfejsy, mogą być również rejestrowane w magazynie implementacji pośrednika ORB. Po otrzymaniu zamówień wywołań obiektu takiego serwera, pośrednik ORB potrafi ten serwer ładować i uruchamiać przez adapter obiektu.

    W celu wydajnego ustawiania argumentów w obie strony należy posłużyć się specyficznym dla danego pośrednika ORB kompilatorem OMG IDL, który wygeneruje namiastki (Stub) i szkielety (skeleton). Namiastka wygląda jako obiekt pośredniczący, który przekazuje wszystkie wywołania od aplikacji użytkownika za pośrednictwem ORB do rzeczywistego obiektu docelowego. Szkielet odbiera informacje, dokonuje ustawienie argumentów i bezpośrednio wywołuje metodę docelową. Szkielet także akceptuje wartości zwracane i wysyła je z powrotem do namiastki.

    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 automatyczne namiastek (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 projektant musi zapełnić konkretnym kodem implementacyjnym wyspecyfikowanych metod. W przypadku dynamicznym, dostęp następuje bezpośrednio poprzez odwołania dynamiczne, na zasadzie protokołu wywołań dynamicznych DII (Dynamic Invocation Interface), analogicznym RPC.

    Repozytorium implementacji jest bazą danych, zawierającą informacje lub implementacje obiektów serwera, które mogą być użyte przez adapter obiektu. Może ono obejmować nazwę i lokalizację pliku przechowującego kod do wykonania dla obiektu. Natomiast repozytorium interfejsu zawiera opisy IDL znanych aktualnie interfejsów obiektów, które mogą być użyte do definiowania nowych aplikacji lub do konstruowania (przez klienta) zleceń dynamicznych.

    Z chwilą zarejestrowania obiektu serwera u pośrednika ORB, pośrednik „wie” jak w razie potrzeby uaktywnić ten serwer. Aby można było rozstrzygnąć, na której maszynie rozpocząć pracę serwera, każdy zarejestrowany obiekt ma swoją maszynę macierzystą, której używa się do uruchomienia serwera. Programy czysto użytkowe, które tylko wywołują obiekty, nie eksportując żadnego z własnych, nie rejestrują się u pośrednika ORB, nie mogą więc być przed niego uruchomione.

    System obiektowej bazy danych może być dołączony do implementacji CORBA, tak że odpowiedni ORB będzie zastosowany do zarządzania dostępami do obiektów przechowywanych w bazach danych. W ten sposób aplikacje uzyskują dostęp do baz danych przez pośrednika, a w rzeczywistości maja dostęp do wszystkich systemów baz danych dołączonych do tego pośrednika. Przy wykorzystaniu odpowiednich usług CORBA możliwy jest dostęp do wielu baz danych w ramach jednej aplikacji. Podejście to ilustruje rys.24 , na którym do pośrednika jest dołączony jeden system bazy danych.


    Rys. 24


    Wszystkie obiekty w ramach rozproszonej architektury obiektów mogą być same traktowane jako obiektowa baza danych. Z tego punktu widzenia CORBA nie jest już tylko mechanizmem komunikacyjnym, ale pełni funkcje wewnętrznego narzędzia implementacji, tzn. może występować jako system bazy danych, co pokazano na rys. 25

    Rys. 25



  • 1   ...   6   7   8   9   10   11   12   13   ...   113


    ©operacji.org 2017
    wyślij wiadomość

        Strona główna