Bazy danych i inżynieria oprogramowania

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 1, Folia 1 listopad 1999

Bazy danych i inżynieria oprogramowania

Kazimierz Subieta

Instytut Podstaw Informatyki PAN, Warszawa

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 1:

Wprowadzenie do OMG CORBA


Terminologia, pojęcia, literaturaNiniejsza prezentacja nie obejmuje wielu cech OMG CORBA. Wyjaśnienie terminów z zakresu obiektowości, które wystąpią w tej prezentacji, znajduje się w:

K. Subieta: Słownik terminów z zakresu obiektowościAkademicka Oficyna Wydawnicza PLJ, Warszawa 1999

Dostępny w księgarniach technicznych, np. Warszawa, ul. Wilcza 45

Dokumentacja: http://www.omg.org + ogromna ilość materiałów pochodnych

Praca magisterska: T. Kaźmierczuk, A.Miazga. Przeglądanie i testowanie aplikacji pracujących w środowisku CORBA. AGH, Katedra Informatyki, Kraków, 1997/98

K.Subieta. Slajdy do wykładu CORBA/ODMG dostępne poprzez http://www.ipipan.waw.pl/~subieta

Literatura:


Problem: heterogeniczność

Heterogeniczność jest nieodłączną cechą sieci komputerowych i rozproszonych aplikacji.Jest to cecha Internetu, Intranetu, WWW, syst. przepływu prac, rozproszonych baz danych.

Heterogeniczność jest nieodłączną cechą sieci komputerowych i rozproszonych aplikacji.Jest to cecha Internetu, Intranetu, WWW, syst. przepływu prac, rozproszonych baz danych.

Np. system Intranetowy może składać się z różnorodnego sprzętu...- komputerów klasy mainframe- stacji roboczych UNIX- komputerów PC pracujących pod MS Windows- komputerów Apple Macintosh- central telefonicznych- robotów, zautomatyzowanych linii produkcyjnych

...włączać różnorodne protokoły komunikacyjne....- Ethernet- FDDI- ATM- TCP/IP- Novell Netware- różnorodne systemy oparte na RPC (Remote Procedure Call)

...oraz wymieniać pomiędzy sobą zróżnicowane zasoby informacyjne (dane).


Inżynierskie kompromisyRzadko się zdarza, aby było jedno akceptowalne rozwiązanie dla złożonego problemu.Różni ludzie najczęściej znajdują różne rozwiązania dla podobnych problemów.Integracja tych rozwiązań prowadzi do heterogeniczności.

Efektywność finansowaDostawcy oferują rożne produkty w różnych cenach. Klienci kupują te produktyzgodnie ze swoim najlepszym wyczuciem spełnienia zadanych wymagań orazzminimalizowania kosztów.

Systemy spadkowe (legacy)Systemy, które dawno zostały wdrożone dawno i działają efektywnie nie mogą być z tego działania wyłączone. Nie jest możliwe lub jest bardzo kosztowne szybkie zastąpienieich przez nowe systemy. Muszą one jednak byæ integrowane z nowszymi systemami.Np. efektywnie działający od 15-tu lat system zamówień jest krytyczny dla codziennej działalności danej organizacji.

Trudne tematy badawczo-rozwojowe: • współdziałanie (interoperability)• przenaszalność (portability)

Trudne tematy badawczo-rozwojowe: • współdziałanie (interoperability)• przenaszalność (portability)

Przyczyny heterogeniczności


Object Management GroupObject Management Group

Konsorcjum programistyczne utworzone w 1989 r. Zajmuje się rozwojem, adaptacją i promowaniem standardów dla rozwijania i rozprzestrzeniania aplikacji w środowiskach heterogenicznych i rozproszonych.

Skupia ok. 800 czołowych firm rozwojowych, producentów i dostawców oprogramowania oraz użytkowników.

Technika działania: RFP (Request For Proposal): zapytania odnośnie konkretnychtematów wysyłane przez komitety OMG do wszystkich członków. Czonkowie (aktywni w danej sprawie) nadsyłają swoje propozycje. Integracja propozycji następuje wewnątrz komitetów na zasadzie głosowania.

Rezultat działalności:

OMA (Object Management Architecture), której najważniejszym składnikiem jest

CORBA (Common Object Request Broker Architecture)

OMA (Object Management Architecture), której najważniejszym składnikiem jest

CORBA (Common Object Request Broker Architecture)

Co to jest OMG?


Misja OMG

Opracowanie jednorodnej architektury z użyciem technologii obiektowej,mającej na celu integrację rozproszonych aplikacji, która zapewniałaby:

• ponowne użycie komponentów oprogramowania i danych

• współdziałanie i przenaszalność

• podstawy rynku kompatybilnego oprogramowania

OMG skupia się na szybkim rozwoju łatwych w użyciu (dostępnych “na półce”) standardowych komponentów.


Zgodność z logiką biznesu (obiekty biznesowe mogą być bezpośrednio zaimplementowane jako obiekty CORBA)

Skalowalność aplikacji: mała zależność czasu reakcji systemuod zwiększenia ilości danych, liczby użytkowników, liczby węzłów.

Dekompozycja aplikacji na małe elementy wykonawcze (obiekty, metody,...)

Przyrostowe dodawanie/odejmowanie funkcjonalności(“płacę tylko za to, czego używam”)

Podział zasobów i zbalansowanie obciążeń

Współbieżność i asynchroniczne przetwarzanie

Zalety rozproszonych obiektów


• Jednorodna terminologia dla modelu obiektowego

• Jedna, zuniformizowana perspektywa danych dla całego rozproszonego, heterogenicznego systemu

• Zachowanie autonomii lokalnych systemów • Wspólna abstrakcyjna rama koncepcyjna

• Wspólny model odwoływania się do danych i usług

• Wspólne interfejsy i protokóły

• Podstawą integracji modelu są kluczowe cechy obiektowości, takie jak obiekty, klasy (interfejsy), metody (operacje), hermetyzacja, polimorfizm i dziedziczenie

Koncepcja OMG


AndersenAPMAppleASCIIAT&TBell NothernBorlandBullCA

CI LabsData AccessDigitalEDSExpertsoftFujitsuGenesisHPHyperDesk

ICLInformixIntelIntelliCorpIBMMicro FocusMicrosoftMITRENeXT

NovellObject DesignObject Tech.Int’lOracleOSFParcPlacePOSCSiemens NixdorfSoftware AG

Sun Microsyst.SybaseSymantecTaligentTelefonica I+DTivoliTRWUnisysXerox

Istnieje wiele produktów i aplikacji opartych o standard CORBA.Praktycznie każdy miesiąc przynosi informację o nowym produkcie.

OMG: Czołowi partnerzy


OMA: ogólna architektura

Obiekty Aplikacyjne

Object Request Broker(Pośrednik Zapotrzebowania na Obiekty)

Wspólne Usługi Obiektowe (Usługi CORBA)

WspółbieżnośćNazwowa

Własności

Cykl życiowyTrwałość Handlowa

Ochrona

Kolekcje

Dostęp zewnętrzny ZwiązkiZapytaniaTransakcje

Zdarzenia Startup Licencje

Czas

Wspólne udogodnienia (Udogodnienia CORBA)Wspólne udogodnienia pionowe (dziedzinowe)

Wspólne udogodnienia poziome

Rozproszonedokumenty

Zarządzanieinformacją

Zarządzaniesystemem

Zarządzaniezadaniami

MedycynaFinanseRachunkowość

.....

.....


OMA{Model obiektów (opis obiektów rozproszonych w sieci komputerowej)Model referencji (interakcja pomiędzy obiektami)

Model obiektów OMA:Model obiektów OMA:

Obiekt jest hermetyzowanym bytem z unikalną niezmienialną tożsamością.

Obsługa obiektów może odbywać się wyłącznie poprzez dobrze zdefiniowane interfejsy.

Klienci wysyłają zlecenia do obiektów, które wykonują odpowiednie usługi.

Implementacja i lokacja obiektów jest dla klienta ukryta.

OMA: Architektura Zarządzania ObiektamiObject Management Architecture


Udogodnienia pionowe

RachunkowośćRozwijanie aplikacjiWytwarzanie wsp. komp.FinanaseRozproszona symulacjaWizualizacjaInformatyczne autostradyMapy wsp.komp.Produkcja i ekspl. ropy i gazuInstytucje ochronyTelekomunikacjaMedycyna...

RachunkowośćRozwijanie aplikacjiWytwarzanie wsp. komp.FinanaseRozproszona symulacjaWizualizacjaInformatyczne autostradyMapy wsp.komp.Produkcja i ekspl. ropy i gazuInstytucje ochronyTelekomunikacjaMedycyna...

Udogodnienia poziome

Interfejsy użytkownikaZarządzanie informacjąZarządzanie systememZarzadzanie jakościąPlanowanieZarządzanie zadaniamiPrzepływy pracyZarządz. bezpieczeństwem...

Interfejsy użytkownikaZarządzanie informacjąZarządzanie systememZarzadzanie jakościąPlanowanieZarządzanie zadaniamiPrzepływy pracyZarządz. bezpieczeństwem...

Usługi CORBA

WspółbieżnośćZdarzeniaDostęp z zewnątrzCykl życiowyNazywanieTrwałośćZapytaniaZwiązkiTransakcjeLicencjePrawa własnościBezpieczeństwoTemporalnośćZarządzanie zmianamiKolekcje danychWymiana danychReplikacjeObrót skł. oprogr.

WspółbieżnośćZdarzeniaDostęp z zewnątrzCykl życiowyNazywanieTrwałośćZapytaniaZwiązkiTransakcjeLicencjePrawa własnościBezpieczeństwoTemporalnośćZarządzanie zmianamiKolekcje danychWymiana danychReplikacjeObrót skł. oprogr.

Usługi i udogodnienia standardu CORBA


Są to interfejsy niezależne od dziedziny, które mogą być używane przez wiele systemów rozproszonych obiektów.Np. usługa polegająca na rozpoznaniu wszystkich istniejących w systemie usługjest potrzebna niezależnie od dziedziny aplikacyjnej.

Są to interfejsy niezależne od dziedziny, które mogą być używane przez wiele systemów rozproszonych obiektów.Np. usługa polegająca na rozpoznaniu wszystkich istniejących w systemie usługjest potrzebna niezależnie od dziedziny aplikacyjnej.

Przykłady usług:Przykłady usług:

Usługa w zakresie nazw (naming service) - pozwala klientom na odszukanie obiektów (ich referencji) na podstawie ich nazw.

Usługa “handlowa” (trading service) - pozwala klientom na odszukanie obiektów na podstawie pożądanych własności obiektów.

Pozostałe:Pozostałe: usługi w zakresie zarządzania cyklem życia obiektu usługi w zakresie bezpieczeństa usługi w zakresie transakcji usługi w zakresie zdarzeń ...inne...

OMA: usługi obiektoweObject Services


Są to mechanizmy wspólne dla dziedzin aplikacyjnych, ale w odróżnieniu od usług obiektowych są one

zorientowane na aplikacje związane z użytkownikiem końcowym.

Są to mechanizmy wspólne dla dziedzin aplikacyjnych, ale w odróżnieniu od usług obiektowych są one

zorientowane na aplikacje związane z użytkownikiem końcowym.

Przykładem jest DDCF (Distributed Document Component Facility), mechanizm do tworzenia i zarządzania składowymi dokumentów oparty na OpenDoc (Apple). Umożliwia on zaprezentowanie i wymianę obiektów opartych o model dokumentu, np. umożliwia powiązanie/wstawienie obiektu zawierającego arkusz kalkulacyjny do obiektu zawierającego raport.

Inne przykłady: wspólny edytor tekstowy, udogodnienia dla tworzenia grafiki, itd.

Common Facilities

OMA: wspólne udogodnienia


Interfejsy dziedzinowe są podobne do usług obiektowych i wspólnych udogodnień, ale są zorientowane nie “poziomo” lecz “pionowo”, tj. na konkretną dziedzinę aplikacyjną.

Interfejsy dziedzinowe są podobne do usług obiektowych i wspólnych udogodnień, ale są zorientowane nie “poziomo” lecz “pionowo”, tj. na konkretną dziedzinę aplikacyjną.

Przykłady

• PDM (Product Data Management) dla dziedziny CAM (Computer-Aided Manufacturing, wytwarzanie wspomagane komputerowo).• telekomunikacja• medycyna• finanse• ...

Domain Interfaces, Application Interfaces

Interfejsy aplikacyjne są opracowane dla konkretnej dziedziny aplikacyjnej. OMG nie zajmuje się aplikacjami, lecz specyfikacjami. Interfejsy te nie należą więc do standardu, ale są kandydatami do standardyzacji w przyszłości.

Interfejsy aplikacyjne są opracowane dla konkretnej dziedziny aplikacyjnej. OMG nie zajmuje się aplikacjami, lecz specyfikacjami. Interfejsy te nie należą więc do standardu, ale są kandydatami do standardyzacji w przyszłości.

OMA: Interfejsy dziedzinowe i aplikacyjne


Koncepcja polega na zdefiniowaniu zrębów (frameworks), tj. grup obiektów specyficznych dla danej dziedziny, które ustalają w niej rozwiązanie jakiegoś problemu: np. w telekomunikacji, medycynie, finansach, wytwarzaniu.

ORB, Object Request Broker(Pośrednik Zapotrzebowania na Obiekty)

Zrąbobiektowy

IA - Interfejsy AplikacyjneID - Interfejsy Dziedzinowe

WU - Wspólne UdogodnieniaUO - Usługi Obiektowe

komponentyaplikacjikomunikują się poprzezORB

UO UO

IA, ID,WU, UO

IA,WU, UO

WU, UO

Użycie modelu OMA


Common Object Request Broker Architecture

CORBA 2.0, ostatnia aktualizacja - środek 1995.

Główne cechyGłówne cechy

• Rdzeń ORB (ORB Core)• OMG IDL (Interface Definition Language) Język Definicji Interfejsu• Repozytorum Interfejsów (Interface Repository)• Repozytorium Implementacji (Implementation Repository)• Odwzorowania językowe• Pieńki (stubs) i szkielety (skeletons)• Dynamiczne wołanie i przesyłanie (dispatching) • Obiektowe adaptery (Object Adapters) • Wewnętrzne protokoły ORB (GIOP, IIOP)

CORBA: podstawowe cechy


Klient Implementacja obiektów

(reprezentacja i przechowywanie obiektów; realizacja dostępu i usług)

Wołaniadynamiczne

(RPC)

PieniekIDL

(IDL stub)

Interfejs do

pośrednika ORB

Szkielet obiektów(IDL skeleton)

Adapterobiektów

Rdzeń Pośrednika (ORB core)

DynamicznySzkielet Interfejsu

Takie samo dla wszystkich ORB

Pieńki i szkielety specyficzne dla interfejsów

Może być wiele adapterów obiektów

Prywatne interfejsy ORB

Ogólna architektura standardu CORBA


Klient Implementacja obiektów

Wołaniadynamiczne

(RPC)

PieniekIDL

(IDL stub)

Interfejs do

pośrednika ORB

Szkielet obiektów(IDL skeleton)

Adapterobiektów

Rdzeń Pośrednika (ORB core)

DynamicznySzkielet Interfejsu

dynamiczne statyczne

Przesyłanie zlecenia od klienta do obiektów


CORBA: schemat komunikowania się klienta z serwerem

Host klienta

KlientKlient

Wywołanieoperacji

Host serwera

ObiektObiekt

Pośrednik (ORB, Object Request Broker)

Definicja obiektów w IDL pozwala dla klienta widzieć je na abstrakcyjnym poziomie.

Klient jest zwolniony z rozpatrywania jakichkolwiek środków komunikacji pomiędzy klientem i serwerem. Z jego punktu widzenia obiekty znajdują się bezpośrednio (wirtualnie) w jego przestrzeni adresowej.

zlecenie

wynik, parametry wyj


CORBA: schemat wywoływania statycznego

Host klienta

KlientKlient

Wywołanieoperacji

Host serwera

ObiektObiekt

Pośrednik (ORB, Object Request Broker)

Pieniek klienta jest fragmentem aplikacji klienta generowanym automatycznie z wyrażenia IDL.

Implementacja interfejsu do obiektu po stronie serwera powstaje ze szkieletu interfejsu do obiektu, automatycznie generowanego z wyrażenia IDL, który jest następnie wypełniany (ręcznie) kodem implementacji operacji zdefiniowanych w wyrażeniu IDL.

Pieniekklienta

Implementacjainterfejsu do

obiektu(szkielet + kod)

zlecenie

wynik, parametry wyj


stubs, skeletons

Pniak(stub) znajduje sie po stronie klienta i zajmuje się tworzeniem i wysyłaniem jego zleceń.

Szkielet (skeleton) znajduje się po stronie serwera. Szkielet wypełniony kodem implementacji operacjizajmuje się dostarczanie zleceń klienta do implementacji obiektów.

Obydwa mechanizmy są tworzone bezpośrednio ze specyfikacji w IDL, są więc specyficzne dla danego interfejsu. Są one wbudowane bezpośrednio w w aplikację klienta i w implementację obiektów. Wiązanie jest statyczne, wołanie operacji jest odwzorowane w wołanie funkcji w odpowiednim języku programowania.

Pniak zajmuje się uszeregowaniem (marshal) zlecenia, tj. zamienia je na formę odpowiednią dla transmisji. Serwer ORB i szkielet dokonują operacji odwrotnej (unmarshal), czyli konwersji z postaci transmitowanej do postaci wymaganej przez język programowania. Po wykonaniu zlecenia, odpowiedź jest wysyłana w odwrotną stronę, poprzez szkielet, serwer ORB i pniak, do aplikacji klienta.

Pniaki i szkielety

Bazy danych i inżynieria oprogramowania

Documents

Transcript of Bazy danych i inżynieria oprogramowania