Obiektowe modelowanie systemów informatycznych



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

Standard OMG CORBA


Standard obiektowego modelu ODMG 2.0 jest podmnóstwem standardu CORBA(Common Object Reqest Broker Architecture). Standard CORBA jest opracowany przez OMG (Object Management Group). OMG skupi się na opracowaniu standardów współdziałania pomiędzy heterogenicznymi, rozproszonymi systemami, obiektowymi i nieobiektowymi. Obiekty, reprezentujące składowe programowe oraz stworzone zgodnie z nowymi standardami będą współdziałały w heterogenicznych środowiskach sprzętowych i programowych, wymieniając i oferując usługi oraz przekazując komunikaty w celu uruchomienia programów, wykonania obliczeń, dostępu do baz danych itp. Aby zrealizować tę wizję, należy osiągnąć dwa ważne cele:

  • Współoperatywność, tzn. możliwość współpracy różnych części oprogramowania w heterogenicznym i rozproszonym środowisku;

  • Właściwa integrację nowo opracowanych i istniejących systemów.

Zarządzanie obiektami rozproszonymi (Distributed Obiect Management – DOM) zgodnie z rekomendacjami OMG może być realizowane przy następnych warunkach:

  1. Struktury danych i funkcjonalność systemów DOM są reprezentowane jako hermetyczne obiekty, komunikujące się drogą wysyłania komunikatów do zdefiniowanych interfejsów.

  2. Dla aplikacji klientów jest możliwy przezroczysty dostęp do obiektów serwera bez znajomości dokładnej lokalizacji, wewnętrznej reprezentacji lub stosowanego języka dostępu.

Zarządzanie obiektami rozproszonymi łączy pojęcia modeli systemów obiektowych i rozproszonych, środowisko integracji aplikacji i obiektowe bazy danych, przedstawiając projektantowi wszystkie dostępne w sieci DOM zasoby jako zbiór dostępnych obiektów, które mogą być łączone odpowiednio do zastosowań. Schemat systemu zarządzania rozproszonymi obiektami (Distribiuted Obiect Management System – DOMS) jest pokazany na rys.21 .

Rys. 21


DOMS składa się z następujących elementów:

  • Dowolnej liczby węzłów, na których działają programy użytkowe, systemy baz danych lub proste obiekty – są to dostępne zasoby.

  • Zbiorów klientów, którzy również mogą być programami użytkowymi, narzędziami programowymi lub prostymi obiektami i którzy wydają zlecenia obsługiwane przez zasoby.

  • Pośredników zleceń . Dostawcy usług informują ten składnik o dostępnych funkcjonalnościach. Klienci mogą zwracać się do tego pośrednika, chcąc się dowiedzieć, który z obiektów w systemie może dostarczyć żądanej usługi.

W zasadzie istnieją dwa typy pośredników:

  • Pośrednik jest nazywany „handlowcem” (trader), jeśli jest ściśle ograniczony do funkcji pośrednika, tzn. ustala tylko połączenia między klientem a serwerem. (patrz rys. 21.a).

  • Pośrednik jest nazywany brokerem, jeśli 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ć się z innymi brokerami. OMG popiera tą koncepcję pośrednictwa.

Rys. 21 a

Celem rekomendacji OMG jest stworzenie modelu obiektów, który może być stosowany do obsługi integracji rozproszonych aplikacji. W zasadzie byłoby możliwe utworzenie takich aplikacji w sposób modułowy, z poszczególnymi modułami lub składnikami wywołującymi się wzajemnie za pośrednictwem zdefiniowanych interfejsów.

Ogólne ramy działań OMG po realizacji DOMS są określone przez Architekturę Zarządzania Obiektami (Obiekt Management Architecture –OMA), która jest wzorcowym obiektowym modelem OMG, co pokazano na rys. 22. OMA jest wizją wysokiego poziomu kompletnego środowiska rozproszonego, składa się z czterech głównych części:




1   ...   5   6   7   8   9   10   11   12   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna