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

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

Po co rozpraszać? skalowalność ? bo można ???? dostępność i niezawodność ?? aspekt sprzętowy geograficzny ułatwienie utrzymania i rozwoju ??? częściowy outage wdrażanie częściowe rozwój niezależnych części bo można ????

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

Problemem nie jest technologia! Problemem jest rozproszenie! 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ć … MGB 2003 Połączeń nie można ignorować … Typowe (błędne) 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 P.Deutch - Ghostscript, implementacja Smalltalk ->inspiracja Java JitComp, R.Gosling – Tworca Javy, sun P. Deutsch 94 J.Gosling 97 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Suplement błednych założeń ciąg dalszy: MGB 2003 Suplement błednych założeń ciąg dalszy: System jest atomowy/monolityczny System jest skończony Logika biznesowa może (i powinna) być scentralizowana Wiecej: Fallacies of Distributed Computing Explained, A. RotemGalOz Neward 06 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

MGB 2003 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 © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Reusability Adaptability Maintainability Atrubuty jakościowe które SOA może pomóc zapewnić Reusability Adaptability Maintainability Reusability—This isn’t reusability in the sense of “write once integrate anywhere,” but rather in the sense that you “don’t throw everything out when you need different functionality.”  Adaptability—Isolating the internal structure of a service from the rest of the world lets you make changes more easily. You only need to adhere to the contracts you publish.  Maintainability—Services can be maintained by dedicated, smaller teams and can be tested this way as well. Robert L. Glass has said, “software maintenance is a solution, not a problem”.4 SOA greatly helps make this a reality.

Marketing SOA

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 ~ 20 lat (od jakiegoś czasu 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

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”) sposobem na pogodzenie wymgań IT I wymagań biznesowych. That’s not true. Better IT and business alignment is something we want to achieve using SOA, but it isn’t what SOA is. Nevertheless, the loosely coupled systems that result from a good SOA solution enable the agility needed to truly align IT and the business team. aplikacją, która ma interfejs w postaci “web serwisu”. This isn’t necessarily true. To begin with, we can implement SOA with other technologies. A nice example is the Open Services Gateway initiative (OSGi), which defines a Java-based service platform (see www.osgi.org). Furthermore, by exposing a method as a web service, we can create procedural-like RPCs, which is far from the SOA concepts and direction (see also the Nanoservice antipattern in chapter 8). zbiorem technologii (np. SOAP, REST, WS-I itd). This is a general case of the previous misconception. Although some technologies are identified with SOA, or fit in well with SOA, SOA is an architectural approach. Remember, SOA is technology-independent. strategią reużycia. This is not always true. Reuse certainly sounds like a tempting reason to use SOA, but the larger the granularity of a component, the harder it is to reuse it. Nevertheless, SOA will allow your services to evolve over time and adapt, so that you don’t need to start from scratch every time. gotowym rozwiązaniem (“z pudełka”). SOA isn’t a product you can buy—it’s a way to architect distributed systems. Perhaps you can resell the resulting service, but that’s only a convenient artifact of a good design.

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. Architektura jest atrybutem każdego systemu – nieważne czy przypadkowo czy przez project ale kazdy system ma architekturę, Architektura powinna zaistnieć wcześnie – reprezentuje zbiór krytycznych (istotnych I trudnych do zmiany) decyzji Architektura narzuca podział na komponenty i ustala granice m. nimi – nie musi to być opis szczegółowy, niemniej architektura dotyczy głównych elementów całego rozwiązania I interfejsów m. nimi Architektura okresla relacje i interakcje między komponentami. – istotne są dla nas zachowania pojedynczych komponentów które wynikają z oczekiwań innych komponentów I służą interakcji m. nimi The architecture doesn’t have to describe the complete characteristics of the components; it mainly deals with their interfaces other interactions. Architektura objąśnia racje stojące za decyzjami. It’s important to understand the reasoning as well as the implications of the decisions made in the architecture because their impact on the project is large. Also, it can be beneficial to understand what alternatives were weighed and abandoned. This may be important for future reference, if and when things need to be reconsidered, and for anyone new to the project who needs to understand the situation. Architektura to nie pojedyncza struktura, rysunek czy nawet grupa rysunków. We need to look at the architecture from different directions or viewpoints to fully understand it. One diagram, or even a handful, isn’t enough to be considered an architecture.

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 komunikacja nie wpływa na działanie!!! 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 kontakt zmieniać jak najrzadziej 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 Ale pot problem: Development I modyfikacje interfejsu Utrzymanie wersji nie jest za darmo Nie rozwiazuje z automatu opznien itd