Bazy danych i inżynieria oprogramowania

Slides:



Advertisements
Podobne prezentacje
nowoczesny system zarządzania przedsiębiorstwem
Advertisements

1. 2 W ostatnim okresie jesteśmy świadkami ogromnemu postępowi w technologiach rozproszonych systemów informatycznych a co za tym idzie rozproszenie danych.
Projektowanie w cyklu życia oprogramowania
Zaawansowane metody programowania – Wykład V
© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 3, Folia 1 październik 2004 Konstrukcja systemów obiektowych i rozproszonych Wykładowca:
WEB SERVICE Stefan Rutkowski.
przetwarzaniu informacji
Rola komputera w przetwarzaniu informacji.
Studia Podyplomowe IT w Biznesie Systemy Rozproszone
e-commerce jako efektywny rozwój dystrybucji
Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 4 Wprowadzenie do OMG CORBA (2) Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa.
Studia Podyplomowe IT w Biznesie Systemy Rozproszone
CORBA Łukasz Wnęk.
Projektowanie Aplikacji Komputerowych
Architektura systemu Gra strategiczna „Strusia Jama”
Projektowanie systemów informacyjnych
© K.Subieta. Systemy rozproszone 6, Folia 1 styczeń 2005 Systemy rozproszone (SYR) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik.
RMI I RMI-IIOP Wprowadzenie Co to jest RMI?
Internet Communication Engine
Standardy w zakresie systemów rozproszonych i baz danych
Dokumentowanie wymagań w języku XML
Zasady zaliczenia Warunki uzyskania zaliczenia:
Systemy operacyjne.
Jakość systemów informacyjnych (aspekt eksploatacyjny)
Enteprise Java Beans Emil Wcisło.
Wzorce projektowe w J2EE
Wstęp do programowania obiektowego
Rozproszone bazy danych
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Praca Inżynierska „Analiza i projekt aplikacji informatycznej do wspomagania wybranych zadań ośrodków sportowych” Dyplomant: Marcin Iwanicki Promotor:
Modele baz danych - spojrzenie na poziom fizyczny
Projektowanie - wprowadzenie
Wykład 4 Analiza i projektowanie obiektowe
Wykład 2 Cykl życia systemu informacyjnego
InfinitERP prezentacja systemu.
Protokół Komunikacyjny
Źródła: podręcznikopracował: A. Jędryczkowski.
Jakub Wołczko W obiektowym świecie… Jakub Wołczko
STAĆ CIĘ NA INNOWACJE System CRM w Focus Telecom Polska - cechy i funkcjonalność usługi Autor: Tomasz Paprocki.
Wybrane zagadnienia relacyjnych baz danych
Programowanie obiektowe – język C++
Programowanie obiektowe 2013/2014
1 Każdy obiekt jest scharakteryzowany poprzez: tożsamość – daje się jednoznacznie wyróżnić; stan; zachowanie. W analizie obiektowej podstawową strukturą
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
S IMON SAYS … A RCHITECTURE ! Usługi zdalne Technologie, techniki i praktyki implementacji.
Bazy danych, sieci i systemy komputerowe
Programowanie w języku C++
Sieci komputerowe.
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Service Oriented Architecture
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Systemy informatyczne
Andrzej Majkowski 1 informatyka +. 2 Bezpieczeństwo protokołu HTTP Paweł Perekietka.
Piotr Czapiewski Wydział Informatyki ZUT. Web Services Description Language.
Zakres wykładu Pojęcia podstawowe Architektury i oprogramowanie Przykłady systemów rozproszonych.
Zakres wykładu Kierunki rozwoju oprogramowania systemów rozproszonych Własności wybranych architektur - problemy badawcze Przykładowe obszary zastosowań.
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Ergonomia procesów informacyjnych
XML w serwisach webowych. Zapotrzebowanie na serwisy XML.
Struktura systemu operacyjnego
Podział sieci komputerowych
Zintegrowany monitoring infrastruktury IT w Budimex
Architektura Rafał Hryniów. Architektura Wizja projektu systemu, którą dzielą twórcy Struktura komponentów systemu, ich powiązań oraz zasad i reguł określających.
Inżynieria systemów informacyjnych
Protokoły używane w sieciach LAN Funkcje sieciowego systemu komputerowego Wykład 5.
Aplikacje i usługi internetowe
JavaBeans by Paweł Wąsala
Modele baz danych - spojrzenie na poziom fizyczny
Zapis prezentacji:

Bazy danych i inżynieria oprogramowania Wykład 1: Wprowadzenie do OMG CORBA Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

Terminologia, pojęcia, literatura Niniejsza 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ści Akademicka Oficyna Wydawnicza PLJ, Warszawa 1999 Dostępny w księgarniach technicznych, np. Warszawa, ul. Wilcza 45 Literatura: K.Subieta. Slajdy do wykładu CORBA/ODMG dostępne poprzez http://www.ipipan.waw.pl/~subieta 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

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. 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).

Przyczyny heterogeniczności Inżynierskie kompromisy Rzadko 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ść finansowa Dostawcy oferują rożne produkty w różnych cenach. Klienci kupują te produkty zgodnie ze swoim najlepszym wyczuciem spełnienia zadanych wymagań oraz zminimalizowania 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ąpienie ich 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)

Co to jest OMG? Rezultat działalności: Object 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 konkretnych temató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)

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.

Zalety rozproszonych obiektów Zgodność z logiką biznesu (obiekty biznesowe mogą być bezpośrednio zaimplementowane jako obiekty CORBA) Skalowalność aplikacji: mała zależność czasu reakcji systemu od 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

Koncepcja OMG 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

OMG: Czołowi partnerzy Andersen APM Apple ASCII AT&T Bell Nothern Borland Bull CA CI Labs Data Access Digital EDS Expertsoft Fujitsu Genesis HP HyperDesk ICL Informix Intel IntelliCorp IBM Micro Focus Microsoft MITRE NeXT Novell Object Design Object Tech.Int’l Oracle OSF ParcPlace POSC Siemens Nixdorf Software AG Sun Microsyst. Sybase Symantec Taligent Telefonica I+D Tivoli TRW Unisys Xerox Istnieje wiele produktów i aplikacji opartych o standard CORBA. Praktycznie każdy miesiąc przynosi informację o nowym produkcie.

OMA: ogólna architektura Wspólne udogodnienia (Udogodnienia CORBA) Wspólne udogodnienia pionowe (dziedzinowe) Rachunkowość Finanse Medycyna ..... Obiekty Aplikacyjne Wspólne udogodnienia poziome Rozproszone dokumenty Zarządzanie informacją Zarządzanie systemem Zarządzanie zadaniami ..... Object Request Broker (Pośrednik Zapotrzebowania na Obiekty) Nazwowa Trwałość Cykl życiowy Współbieżność Kolekcje Handlowa Dostęp zewnętrzny Transakcje Zapytania Związki Ochrona Czas Wspólne Usługi Obiektowe (Usługi CORBA) Własności Zdarzenia Startup Licencje

OMA: Architektura Zarządzania Obiektami Object Management Architecture OMA{ Model obiektów (opis obiektów rozproszonych w sieci komputerowej) Model referencji (interakcja pomiędzy obiektami) 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.

Usługi i udogodnienia standardu CORBA Usługi CORBA Udogodnienia pionowe Udogodnienia poziome Współbieżność Zdarzenia Dostęp z zewnątrz Cykl życiowy Nazywanie Trwałość Zapytania Związki Transakcje Licencje Prawa własności Bezpieczeństwo Temporalność Zarządzanie zmianami Kolekcje danych Wymiana danych Replikacje Obrót skł. oprogr. Rachunkowość Rozwijanie aplikacji Wytwarzanie wsp. komp. Finanase Rozproszona symulacja Wizualizacja Informatyczne autostrady Mapy wsp.komp. Produkcja i ekspl. ropy i gazu Instytucje ochrony Telekomunikacja Medycyna ... Interfejsy użytkownika Zarządzanie informacją Zarządzanie systemem Zarzadzanie jakością Planowanie Zarządzanie zadaniami Przepływy pracy Zarządz. bezpieczeństwem ...

OMA: usługi obiektowe Object Services 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ług jest potrzebna niezależnie od dziedziny aplikacyjnej. 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: 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: wspólne udogodnienia Common Facilities 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.

OMA: Interfejsy dziedzinowe i aplikacyjne Domain Interfaces, Application Interfaces 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 ... 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.

ORB, Object Request Broker Użycie modelu OMA 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. komponenty aplikacji komunikują się poprzez ORB IA, ID, WU, UO IA, WU, UO WU, UO ORB, Object Request Broker (Pośrednik Zapotrzebowania na Obiekty) UO UO Zrąb obiektowy IA - Interfejsy Aplikacyjne ID - Interfejsy Dziedzinowe WU - Wspólne Udogodnienia UO - Usługi Obiektowe

CORBA: podstawowe cechy Common Object Request Broker Architecture CORBA 2.0, ostatnia aktualizacja - środek 1995. Głó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)

Ogólna architektura standardu CORBA Klient Implementacja obiektów (reprezentacja i przechowywanie obiektów; realizacja dostępu i usług) Wołania dynamiczne (RPC) Pieniek IDL (IDL stub) Interfejs do pośrednika ORB Dynamiczny Szkielet Interfejsu Szkielet obiektów (IDL skeleton) Adapter obiektów Rdzeń Pośrednika (ORB core) Takie samo dla wszystkich ORB Może być wiele adapterów obiektów Pieńki i szkielety specyficzne dla interfejsów Prywatne interfejsy ORB

Przesyłanie zlecenia od klienta do obiektów Implementacja obiektów Klient dynamiczne statyczne Wołania dynamiczne (RPC) Pieniek IDL (IDL stub) Interfejs do pośrednika ORB Dynamiczny Szkielet Interfejsu Szkielet obiektów (IDL skeleton) Adapter obiektów Rdzeń Pośrednika (ORB core)

CORBA: schemat komunikowania się klienta z serwerem Host klienta Host serwera Klient Obiekt Wywołanie operacji zlecenie Pośrednik (ORB, Object Request Broker) wynik, parametry wyj 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.

CORBA: schemat wywoływania statycznego Host klienta Host serwera Klient Obiekt Implementacja interfejsu do obiektu (szkielet + kod) Wywołanie operacji Pieniek klienta zlecenie Pośrednik (ORB, Object Request Broker) wynik, parametry wyj 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.

Pniaki i szkielety 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.