1 Komponentowe i rozproszone Kompozycja gui Cap theorem Wydajne Systemy Rozproszone CQRS

2 Czym serwis nie jest Serwis, który dostarcza tylko funkcjonalność a nie posiada stanu jest funkcją  Np walidacja Serwis, który tylko posiada i udostępnia dane jest bazą danych  CRUD

3 Co to jest serwis? Serwis jest techniczną realizacją pewnych biznesowych możliwości. Serwis powinien być niezależny. Czy to znaczy, że musi przechowywać (niekoniecznie być właścicielem) wszystkie dane i reguły niezbędne mu do działania Jakie powinny być "granice serwisu"?

4 Przykład Subscribe to Customer Status Updated Publish Customer Status Updated Save status locally Subscribe to Product Pricing Updated Publish Product Pricing Updated Save pricing locally Place Order Publish Order Accepted Sales Marketing Customer Care

5 Zdarzenia w przykładowym systemie Otrzymanie zamówienia Wystawienie faktury Wysyłka towaru Uzupełnienie magazynu Zmiana Ceny

6 Jaki serwis jest właścicielem strony?

7 Żaden

8 Kompozycja strony (w przeglądarce) Gateway/Firewall+LB Katalog Koszyk Licytacja Cross Sell Spedycja Zdjęcia/Media Server Server Server Server

9 Kompozycja strony (na serwerze) Server Katalog Koszyk Licytacja Cross Sell Spedycja Zdjęcia/Media

10 Proces sprzedaży Jaki serwis jest właścicielem procesu sprzedaży? Żaden

11 Posadowienie serwisów Jeden komputer może gościć wiele serwisów Jedna aplikacja może obejmować wiele serwisów Pojedynczy workflow może angażować wiele serwisów Pojedyncza strona może łączyć dane z wielu serwisów

12 Proces sprzedaży

13 Który serwis odpowiada za proces?

14 Żaden

15 Składowe workflow-u Spedycja Rachunkowość Spedycja Rachunko wość Sprzedaż Sprzedaż

16 CAP theorem Nie można zbudować systemu, który spełni jednoczesnie 3 postulaty: Spójność (Consistency) Dostępnośc (Availiability) Odporność na podziały (Partition tolerance)

17 CAP theorem Mozna wybrać 2 CA – Brak podziałów oznacza monolit CP – Spójny, ale pot. niedostępny w przypadku problemu z wewn. transmisjami AP – Dostępny, ale potencjalnie lokalnie niespójny – Eventual Consistency

18 AP – przykład 1: Request/Response Sprzedaz Uprawnienia Zarządzanie klientami Ostatnia ver. upr. Cache

19 AP – przykład 2 : Pub/Sub SprzedazMarketing Zaakceptowana transakcja klienta X wolumen zaku- pów klienta X Kod zniżkowy na przesyłkę dla stałych klientów spedycja Zaakceptowana transakcja klienta X

20 Współpraca wielu użytkowników Pobranie danych Zmiana danych Użytkownik widzi stare dane

21 Cache = efektywność+problemy DB Cache

22 Zapytania Cache = efektywność+problemy

23 Dane zmieniają się często Dane poprawne 10 minut temu Lista klientów Można to pokazać ex-plicite: Twitter, Facebook

24 Zapytania powinny być proste Normalizacja implikuje zapytania oparte na wielu tabelach Widoki kosztują Persistent View Model UIUI Query only

25 Command Query Responsibility Segregation

26 CQRS Komendy są przetwarzane oddzielnie od zapytań Wynik aktualizacji danych jest replikowany do widoku zapytań (cache) Możliwe jest w przechowywanie tylko listy komend i bieżącego stanu w cache CQRS – to nie jest wzorzec wysokopoziomowy

27 Ale co zrobić z nieaktualnymi danymi w cache-u Co jeżeli do generowana update-u użyte zostaną niektualne dane Orders CancelCancelSaveSave OrderTotalPaymentShippedCustomerConfirmed IDAmountReceivedDateID 321$37.871.09.154.09.15792Yes 322$99.993.09.1513.09.1515324No 323$100.114.09.158.09.1524671Yes 324$69.479.10.1519.10.15792Yes

28 Nowoczesny interfejs Może wcale nie trzeba korzystać z nieaktualnych danych lub nie trzeba ich pokazywać Ważne jest uchwycenie intencji Można troche “oszukać”  Wysyłka może pójść na adres, który był aktualny kilka minut wcześniej  Nie można oczekiwać, że zawsze uda sie rezygnacja z wysyłki w ciagu kilku sekund  Właściwy zakup udbywa sie przy potwierdzeniu a nie kliknieciu "kup teraz"

29 System rezerwacji

30 Tradycyjne podejście Checkbox-y Problemem mogą wyścigi jesli kilka osób spróbuje zarezerwowac nakładające sie obszary Po co użytkownikowi kilka miejsc? Bo chce zarezerwowac miejsca obok siebie dla rodziny/przyjaciół

31 Uchwycenie intencji użytkownika Rezerwacja grupowa:  Mała grupa – siedzi razem  Duża grupa – kilka małych grup Podaj liczbę miejsc Podaj typ miejsc – określa koszt Propozycja z czasowym ograniczeniem – wymaga potwierdzenia/płatności

32 System rezerwacji

33 Drobne optymalizacje i oszustwa Walidacja przed wysłaniem Odgadywanie zmian Bezpośrednia aktualizacja widoku na podstawiwie komendy przed wprowadzeniem i przetworzeniem zmian przez BackEnd)

34 Komenda vs. encja Łatwiej walidować komendę  z mała iloscią danych  bardziej konkretną  Chodzi o potencjalną poprawność (wynik walidacji nie jest ostateczny) Walidacja dużych encji jest trudna