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

Prezentacja na temat: "Komponentowe i rozproszone Interludium czyli krótki wykład o rozpraszaniu."— Zapis prezentacji:

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

2 Obiekty rozproszone 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!

3 Połączeń nie można ignorować … Typowe założenia deweloperów (i architektó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 Deutsch 94 Gosling 97

4 Trudne pytania proste odpowiedzi? Sens życia ? 42 Jak realizować systemy rozproszone? SOA

5 Kilka luźnych uwag nt. SOA SOA to jedno z najbardziej nadużywanych “buzzword” W tym sensie “SOA” przypomina “object oriented” SOA to nic nowego (obecnie mówi sie już o SOA 2.0, event driven architecture) OOA i SOA to różne poziomy abstrakcji To nie technologia – to nie webserwisy, to nie WCF

6 Marketing SOA

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

8 A - oznacza architekturę Definicja wg. IEEE: “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (IEEE 42010).

9 A - oznacza architekturę DEFINITION Software architecture is the collection of fundamental decisions about a software product or solution designed to meet the project’s quality attributes (the architectural requirements). The architecture includes the main components, their main attributes, and their collaborations (their interactions and behavior) to meet the quality attributes. Architecture can, and usually should, be expressed in several levels of abstraction, where the number of levels depends on the project’s size and complexity. ARNON ROTEM-GAL-OZ

10 A - oznacza architekturę Architektura jest atrybutem 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.

11 SOA Definicja: Service-oriented architecture (SOA) is an architectural style for building systems based on interactions of loosely coupled, coarse-grained, and autonomous components called services. Each service exposes processes and behavior through contracts, which are composed of messages at discoverable addresses called endpoints. A service’s behavior is governed by policies that are external to the service itself. The contracts and messages are used by external components called service consumers. ARNON ROTEM-GAL-OZ

12 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ść.  Polityka vs kontakt (interfejs): Polityka może zmieniać sie w trakcie rune-time-u.

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

14 SOA SOA też jest trudne Problemy  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  Utrzymywanie wersji (serwisu!!!) nie jest darmowe