Komponentowe systemy rozproszone Interludium czyli krótki wykład o rozpraszaniu.

Slides:



Advertisements
Podobne prezentacje
11. Różniczkowanie funkcji złożonej
Advertisements

Decyzje projektowe w .NET Framework
CORBA Łukasz Wnęk.
Michał Żwinis s3472.
Service Oriented Architecture & Web Services
Projektowanie architektoniczne
Zespół L Prezentacja aplikacji Friendly Help Desk.
Architektura systemu Gra strategiczna „Strusia Jama”
Opracował: Patryk Kołakowski(s1715)
Internet Communication Engine
SYSTEM ZARZĄDZANIA JAKOŚCIĄ
Dokumentowanie wymagań w języku XML
Wykład 2. Wprowadzenie do architektur systemów rozproszonych
Jakość systemów informacyjnych (aspekt eksploatacyjny)
Enteprise Java Beans Emil Wcisło.
Co to jest SOA Czym SOA nie jest
Wzorce projektowe w J2EE
Paweł Fałat Katedra Informatyki Stosowanej
Projektowanie i programowanie obiektowe II - Wykład IV
Problem rozbieżności czasów jednym z wielu problemów pojawiających się w systemach rozproszonych jest rozbieżność wartości zegarów na poszczególnych węzłach-maszynach.
Architektura SOA.
Inżynieria Oprogramowania
Wykład 2 Cykl życia systemu informacyjnego
Tomasz Hankus Jarosław Janik Konrad Tendera
Platforma udostępniająca skalowalną komunikację w środowisku rozproszonym Tomasz Hankus Jarosław Janik Konrad Tendera Opiekun: dr inż. Tomasz Szydło Prowadzący:
PROJEKT SIECI KOMPUTEROWYCH
Web Serwisy w praktyce Technologie internetowe ( )
Dotcom Projektowanie systemów CCTV Projektowanie sieci LAN
Programowanie strukturalne i obiektowe
SYSTEM DYNAMICZNEJ ANALIZY JAKOŚCI SCENARIUSZY BIZNESOWYCH Łukasz Budnik.
Jakub Wołczko W obiektowym świecie… Jakub Wołczko
Wymiana integracja ? oprogramowania dr Danuta Kajrunajtys.
Mechanizm OLE ang. Object Linking and Embedding źródła:
SEKTOR IT AKTYWIZATOREM SKUTECZNEJ KONKURENCJI BANKÓW SPÓŁDZIELCZYCH NA RYNKU BANKOWYM Jerzy Różyński Prezes Zarządu Krajowego Związku Banków Spółdzielczych.
Komponentowe systemy rozproszone Wprowadzenie. Komponent... jest to podstawowa jednostka oprogramowania z kontraktowo (deklaratywnie) opisanymi interfejsami,
Komponentowe i rozproszone Interludium. OOA vs SOA OOA (obiekty rozproszone): CORBA, COM(+), EJB Współdzielenie obiektów SOA (serwisy rozproszone): Autonomiczne.
Zaprojektowanie i wykonanie prototypowego systemu obiegu dokumentów (workflow) dla Dziekanatu Wydziału z wykorzystaniem narzędzi open-source i cloud computing.
SYSTEMY OPERACYJNE Adresowanie IP cz3.
1 Każdy obiekt jest scharakteryzowany poprzez: tożsamość – daje się jednoznacznie wyróżnić; stan; zachowanie. W analizie obiektowej podstawową strukturą
S IMON SAYS … A RCHITECTURE ! Usługi zdalne Technologie, techniki i praktyki implementacji.
MS Excel - wspomaganie decyzji
Sieci komputerowe.
Skalowanie aplikacji JPA na przykładzie Oracle TopLink Grid
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
W W W Łukasz Stochniał.
Service Oriented Architecture
Model obiektowy bazy danych
Jednym z podstawowych celów tworzenia sieci komputerowych jest współdzielenie zasobów, takich jak pliki lub drukarki. Każdy z takich zasobów musi być udostępniony,
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Click here to download this powerpoint template : Brown Floral Background Free Powerpoint TemplateBrown Floral Background Free Powerpoint Template For.
Komponentowe systemy rozproszone Wprowadzenie. Komponent... jest to podstawowa jednostka oprogramowania z kontraktowo (deklaratywnie) opisanymi interfejsami,
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.
Obiekty COM Przemysław Buczkowski. Plan prezentacji 1.Wprowadzenie do COM 2.Historia standardu 3.Jak działa COM 4.Interface IUknown 5.Paradygmaty COM.
Komponentowe i rozproszone Interludium czyli krótki wykład o rozpraszaniu.
Sławomir Staśkiewicz JBossAS i EJB 3.1 Sławomir Staśkiewicz
Usługi webowe & Service- Oriented Architecture (SOA) S2523 Anna Jenerowicz.
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.
Komponentowe i rozproszone (Web)Service Oriented Architecture.
Wzorzec MVC na przykładzie CakePHP
Komponentowe systemy rozproszone
materiały dla uczestników
Hipertekst HTML WWW.
JavaBeans by Paweł Wąsala
Komponentowe systemy rozproszone
Konteneryzacja i DevOps
Zapis prezentacji:

Komponentowe systemy rozproszone Interludium czyli krótki wykład o rozpraszaniu

Trudne pytania proste odpowiedzi? Sens życia ? 42 Jak realizować systemy rozproszone? SOA SOA 2.0, EDA  SOA

Po co rozpraszać? skalowalność ? niezawodność ??  aspekt sprzętowy  geograficzny łatwość utrzymania i rozwoju ???  częściowy outage  wdrazanie częsciowe  rozwół niezależnych części bo mozna ????

Krotka historia rozpraszania Komunikacja pakietowa Komunikacja strumieniowa (gniazda) Komunikacja obiektowa (obiekty rozproszone, CORBA, (D)COM+), RMI Architektura Zorientowana na Serwisy SOA, SOA 2.0, EDA, ESB,  SOA Drugi wymiar: Chmury, silniki wyszukiwawcze bazy dokumentowe, kolumnowe, hurtownie danych, bigdata

Obiekty rozproszone obiekty+komunikacja = system rozproszony? CORBA, COM(+), EJB Współdzielenie obiektów  Na poziomie kodu lub binariów  Pomiędzy podsystemami  Pomiędzy gui i serwerem Problemem nie jest technologia! Problemem jest rozproszenie!

Połączeń nie można ignorować … Typowe założenia deweloperów (i archi- tektów) dla systemów rozproszonych:  Sieć jest niezawodna  Opóźnienia nie są problemem  Pasmo nie jest problemem  Sieć jest bezpieczna  Topologia się nie zmienia  Administrator zawsze wie co robić  Koszty transportu danych nie są problemem  Sieć jest jednorodna P. Deutsch 94 J.Gosling 97

Suplement Typowe założenia deweloperów (i architektów) dla systemów rozproszonych:  System jest atomowy/monolityczny  System jest skończony  Logika biznesowa może (i powinna) być scentralizowana Neward 06

System ≠ aplikacja Aplikacja: jeden proces, jeden system op., jeden komputer System:  wiele procesów  (czesto) wiele komputerów  (czasem) wiele systemów operacyjnych. System = N*aplikacja + połączenia

3 wymiary systemu Scalability Availiability Reliability

Atrubuty jakościowe które SOA może pomóc zapewnić Reusability Adaptability Maintainability

Kilka luźnych uwag nt. SOA SOA to jakiś czas temu jedno z najbardziej nadużywanych “buzzword” W tym sensie “SOA” przypomina “object oriented” SOA ma kilkanascie lat (obecnie mówi sie już o SOA 2.0, event driven architecture,  SOA/  S) OOA i SOA to różne poziomy abstrakcji SOA, to nie technologia – to nie webserwisy, to nie WCF

Marketing SOA

Czym SOA nie jest sposobem na pogodzenie wymgań IT i wymagań biznesowych aplikacją, która ma interfejs w postaci usługi www (web serwis) zbiorem technologii (np. SOAP, REST, WS-I itd) strategią reużycia gotowym rozwiązaniem (“z pudełka”)

A - oznacza architekturę Definicja wg. IEEE: “Podstawowe koncepcje lub własności systemu ujęte w jego elementach, relacjach, zasadach projektowania i ewolucji” (IEEE 42010).

A - oznacza architekturę DEFINICJA Architektura oprogramowania to zbiór fundamentalnych decyzji nt. produktu lub rozwiązania programowego mających na celu zapewnienie pewnych atrybutów jakościowych (-> wymagania architektoniczne). Architektura obejmuje główne komponenty, ich podstawowe własności oraz wzajemne zależności (interakcje i zachowania) w kontekście wspomnianych atrybutów jakściowych. Architektura może, i zwykle powinna, być wyrażona na kilku poziomach abstrakcji, przy czym liczba tych poziomów zależy od rozmiaru i komplikacji projektu ARNON ROTEM-GAL-OZ

A - oznacza architekturę Architektura jest cechą każdego system. Architektura powinna zaistnieć wcześnie. Architektura narzuca podział na komponenty i ustala granice między nimi. Architektura określa relacje i interakcje między komponentami. Architektura objąśnia racje stojące za decyzjami. Architektura to nie pojedyncza struktura, rysunek czy nawet grupa rysunków.

SOA DEFINICJA: Service-oriented architecture (SOA) jest stylem architektonicznym pozwalającym na budowę systemów opartych na interakcjach luźno powiązanych, zgrubnych, autonomicznych komponentów nazywanych serwisami. Każdy serwis udostepnia procesy i zachowania ujete w formie kontraktów i wyrażone w formie komunikatów. Komunikaty dostępne są pod odkrywalnymi adresmi - punktami dostępowymi (endpoint). Zachowanie serwisu jest określane przez zewnętrzne (w stosunku do niego) polityki. Kontrakt i komunikaty są używane przez inne komponenty systemu nazywane konsumentami serwisu. ARNON ROTEM-GAL-OZ

Styl Architektoniczny Styl architektoniczny – zespół wytycznych na temat jakie decyzje i rozwiązania sa akceptowalne I pożądane w ramach architektur definiowanych systemów

Kilka ważnych wyrazów SOA (serwisy rozproszone):  Autonomiczne usługi  Jawne granice  Wspoóldzielenie kontraktu a nie klas/typów  Kontrakt jest dostępny poprzez komunikaty wysyłane na adres endpoint-ów przez konsumentów serwisu.  Polityka pozwala określić takie atrybuty jak bezpieczeństwo, audyty, SLA i ew. kompatybilność wsteczną.  Polityka vs kontakt (interfejs): Polityka może zmieniać sie w trakcie rune-time-u.

Serwis ws. moduł Serwis ma tożsamość (adres) moduł (dll) niekoniecznie koszt utrzymania serwisu jest niezerowy, koszt istnienia (nie mowimy o developmencie/destowaniu/dystrybucji) koszt komunikacji z serwisem może być znaczący moduł może istnieć w przestrznie adresowej nie można udawać, że komunikacji nie ma!!! Wołanie zdalne może się nie powieść na różne sposoby.

Dlaczego SOA jest trudne Problemy  Utrzymywanie wersji (serwisu!!!) nie jest darmowe  Sztywność architektury + trudne zmiany kontraktu – ale w sumie chodzi o to aby tego nie zmieniać  Co z kompatybilnością ? jeśli zmiany są konieczne – wersjonowanie  Diagnostyka, Deploymenty, Dokumentacja  Stabilność systemu opartego na synchronicznych wołaniach zależy (czy powinna?) od stabilności sieci/komunikacji