poniedziałek, 24 lutego 2014

Introduce to SOA. Chapter 1.

SOA - według niektórych największa ściema ostatnich lat w informatyce. Inni podpisują prawię wszystko po ten termin. Przez co wielu uprawia dyfuzje semantyczną zjawisko opisane przez Fowlera.
Czym jest SOA (service oriented architecture) - to po prostu styl tworzenia systemów informatycznych oparty na iteracjach luźno powiązanych, samodzielnych komponentów, które to świadczą pewne usługi (services).
Każda usługa dostarcza pewne zachowania opisane przez kontrakt (contracts). Te składają się z komunikatów (messages) wykrywanych w adresach czyli punktach końcowych (endpoints)
Zachowanie usług wynika z pewnej polityki czy restrykcji zwanych policies.
Regulacje te są zewnętrze wobec usługi.
Kontrakty i komunikaty są wykorzystywane poprzez zewnętrzych klientów - konsumentów usług.(service consumers).


 źródło : soa.sys-con.com













Generalnie jak miałeś do czynienia w WS dostrzeżesz szybko pewne analogie.
Stosują WebServices możemy  integrować usługi od równych producentów, tworzyć systemy bezstanowe i skalowalne, implementować i wiązać usługi w różnych środowiskach.

SOA to również :
 - orientacja na usługi (service orientation)
 - enkapsulacja logiki
 - luźne powiązania (loose couplings) - powiązania tylko na zasadzie wzajemnej świadomości

 - kontraktowość - stosowanie się do uzgodnień w kwestii komunikacji, zdefiniowanych w opisach

 - autonomia - każda usługa kontroluję swoją własną logikę, która jest mocno odseparowana od reszty 'świata'

 - abstrakcja - usługi ukrywają przez klientem elementu logiki

 - reużywalność - usługi budowane są z myślą jak największej uniwersalności oraz wielkokrotnego użycia

 - komponowalność - może istnieć koordynator, który umożliwi łączenie usług w kolekcje, stanowiące jedną spójną całość biznesową

 - bezstanowość - usługi nie powinny opierać się na jakimkolwiek stanie.

 - wykrywalność - usługi powinny być zaprojektowane intuicyjnie by za pomocą dostępnych komponentów można było je wykryć i użyć do zadanego zadania.

- dostarcza jakość usług (QoS - Quality of Service) czyli :
  - zdolność do realizowania usług w sposób bezpieczny

  - niezawodnej komunikacji, oraz gwarancji dostarczenia w przypadku 
niedostarczenia wiadomości usługa powinna dostarczyć odpowiednie powiadomienie

  - wydajność : narzut SOAP , Ws-Security oraz przetwarzanie XML nie powinno stanowić znaczącego narzutu na ogólną wydajność usługi

 -  transakcyjność poprzez integralność określonych zadań biznesowych oraz gwarancję wykonania odpowiedniego kodu w przypadku niepowodzenia wykonywanego zadania

- bazuje na otwartych standardach (SOAP, WSDL, XML, XSD etc)


ESB picture : source : http://www.thecloudcomputingaustralia.com/

Następny twór mocno powiązany z SOA to ESB. Jest to efektywny sposób realizacji usług. Dużą analogią będzie wzorzec Observer z głównego katalogu GoF.
Aplikacje łączą się z szyną - rejestrują swoje usługi, subskrybują i publikują komunikaty. ESB pozwala uwolnić się od sieci powiązań każdy-z-każdym pomiędzy aplikacjami, separuje dostawcę od odbiorcy usług oraz  zapewnia przejrzystość usług. Nie dostrzeżemy tu kłębka, plątaniny połączeń i integracji p2p.
W przypadku n usług, liczba połączeń systemu opartego na  ESB wynosi n, w porównaniu z n(n−1)/2 w przypadku połączeń bezpośrednich.

Ważne jest również to, że zadaniem ESB jest zapewnienie solidnego, odpornego na awarię i wiarygodnego systemu wymiany komunikatów.
Routing między komponentami odbywa się poprzez zastosowanie wzorców EIP dzięki czemu programista może łatwo odgadnąć zamiary projektanta systemu. Warunek jest jeden musi znać te wzorce.

Funkcje ESB: 
- routing komunikatów
- transformacje wiadomości
- monitoring
- security
- mediacja wiadomości
- JBI (Java Business Integration) (Apache ServiceMix)

Zalety ESB :
- dobrze zdefiniowana architektura
- łatwość podpięcia nowego systemu
- niezawodność
- łatwość skalowania
- rozproszenie
- luźne wiązania
- uniezależnienie od lokacji
- uniezależnienie od formatu wiadomości i protokołu
- mediacja wiadomości
- zcentralizowane zarządzanie

Wady ESB : 
 - duży narzut na początkowy setup
 - duża złożoność - rozwój

Tip : Apache ServiceMix, Apache Karaf, Mule


źródło : docs.huihoo.com  

źródło : www.uml.org.cn



 
















Opis korelacji jest z grubsza następujący :

Service consumer stosuje się do policy, wiąże się z endpointem, rozumie kontrakt oraz wysyła czy odbiera komunikaty

Service zarządzana jest przez policy, udostępnia endpointy, implementuje kontrakt i wysyła lub odbiera wiadomości.

Jak możemy się domyślać główną cechą SOA jest usługa. Powinna ona świadczyć jakąś funkcję biznesową oraz implementować wszystkie opisane dla niej kontrakty.
Ważne jest to, że musimy tworzyć usługi samowystarczalne (service autonomy)
 

Kontrakt opisuje definiuje komunikaty obsługiwane przez usługę. Kontrakt może mieć charakter jednostronny - skierowany tylko w jednym kierunku lub dwu strony zorientowany na komunikację z jednym lub grupą innych komponentów.

TIP :Mówiąc kontrakt myśl interfejs.

Punkt końcowy jest taki id (URI) zasób w którym osadzona jest dana usługa.
Stąd też możesz pobrać sobie kontrakt.

TIP : analogia np /services/pay?wsdl 

Komunikat to swego rodzaju jednostka komunikacji. Forma przekazu może być różna od JMS, po REST, SOAP czy SMTP.

Komunikat składa się z nagłówka (header) i treści (body). Nagłówek niesie cześć informacyjną dla innych komponentów bądź struktury, pomaga w routingu komunikatów czy w implementacji wzorca Request-Reply

MEP

Wzorzec Request-Reply wchodzi w skład katalogu wzorców wymiany komunikatów oraz w skład katalogu EIP (patrz Camel post)
- możesz zadać pytanie i otrzymać odpowiedź - Request/Reply
- możesz zostawić wiadomość z zapytaniem i swoim numerem telefonu i oczekiwać odpowiedzi Request/Reaction
- możesz prowadzić obszerną korespondencję z handlowcem wymieniając maile za czym Twój problem zostanie rozwiązany Saga


Komunikaty jednokierunkowe (one-way, fire-and-forget) -  dane są wysyłane tylko od wywołującego operację  (brak wartości zwracanej)

Komunikaty dwukierunkowe (two-way, request/reply) - dane są przesyłane do komponentu w momencie wykonania metody, wówczas komponent ma czas na wykonanie dodatkowych czynności, po zakończeniu których wysyła odpowiedz z powrotem do pytającego (bazuje na polu JMSCorrelationID).
 
Policy (regulacje) -  stanowią separację pomiędzy specyfikacją dynamiczną a statyczną. Definiują zasady tworzenia usług, konsumowanych przez klientów.
Określają własności dynamiczne jak bezpieczeństwo, audyt czy SLA. Umożliwiają późniejszą łatwą rekonfiguracje.

Konsumenci usług komunikują się z usługami poprzez komunikaty. Korzystają z usług zdefiniowanych w systemie w obrębie SOA.

Orkiestracja (orchestration) - logika centralnego sterowania, która umożliwia współdziałanie i przepływ informacji pomiędzy dwoma lub więcej systemami.
Często spotykamy to samo znaczenie pod terminem (hub-and-spoke) .
Usługa narzędzia orkiestracji ułatwia scalanie skomplikowanych procesów biznesowych. Orkiestracja nadaje procesom reprezentację w skali przedsiębiorstwa, wspiera federacyjność i propaguje zorientowanie na usługi.

SOA -> zalety : 

 - reużywalność (reusability)
 - zdolność adaptacyją (adaptability)
 - łatwość utrzymania (maintainability)
 - uniknięcie systemów spaghetii
 - zrozumienie wymagań biznesu, wymiana kompomentów
 - zmniejszony wysiłek integracji systemów
 - łatwiejszy proces automatyzacji procesów biznesowych
 - zredukowanie przestojów  - alternatywne drogi przepływów danych

Wady :
 - trudne tworzenie systemów opartych na SOA


Podobnie jak w modelu REST tak i w SOA możemy określić dojrzałość zaimplementowanych usług:



źródło : www.enterprise-architecture.info



Wzorce dotyczące bezpieczeństwa oraz standardy Ws-Security :

Mój mindMap : (security problems) (trochę już nieaktualny ale zawsze.:) )
 













































 - Secured Message
 - Secured Infrastructure
 - Service Firewall
 - Identity Provider
 - Service Monitor
 - XML Signature
 - XML Encryption
 - SAML
 - WS-Trust
 - SSL (Secure Socket Layer)
 - WS-Security
 - Single Sign-On (SSO)
 - Auth2
 - CSRF (cross-site request forgery)
 - STRIDE czyli potencjalne zagrożenia jak  :
    - podszywanie (spoofing)
    - fałszowanie (tampering)
    - odrzucenie komunikatu (repudiation)
    - ujawnienie informacji (information disclosure)
    - odmowę usługi (denial service)
    - podniesienie uprawnień (elevation of privilege)

 - budowanie bloków bezpieczeństwa jak :
   - poufność (confidentiality)
   - uwierzytalnianie (authentication)
   - autoryzacja (authrization)
   - spójność  (consistency)
   - integralność (integrity)
   - niezaprzeczalność (non-repudiation)
   - dostępność (availability
   - oraz katalog potencjalnych ataków. 

Dokładny opis problemów, rodzajów ataków oraz rozwinięcie  powyższych terminów -> to wszystko znajdziesz tutaj

Przykłady z wykorzystaniem Apache CXF znajdziesz tutaj

Katalog wzorców umieszczam poniżej:


Opis pozostałych standardów WS
  - związany z orkiestracją WS-BPEL (Business Process Execution Language)
  - WS-Addressing
  - WS-ReliableMessaging
  - WS-Policy
  - WS-MetadataExchange
  - WS-Notification
  - WS-Eventing


znajdziesz tutaj

Podsumowanie : Ten post miał za zadanie wprowadzić Cię  w świat SOA.
Albo może inaczej przybliżyć terminy związane z usługami.
Jak już zdążyłeś zauważyć mówiąc SOA , a mając na myśli standardowe podejście WebServices popełniałeś wielki błąd.
WebServices a SOA ma się tak jak koń do wielbłąda. Podobieństwo jest takie, że zarówno jeden jak i drugi  'człapie' na czterech nogach.

SOA != WS-* + SOAP + UDDI + WSDLs

Generalnie projektowanie systemów SOA wymaga wiedzy i wprawy. Znajomość ESB i wzorców EIP oraz SOA często stanowi totalne podwaliny aby cokolwiek zacząć implementować.
W dalszych postach z cyklu SOA i okolice dowiesz się jak projektować prawdziwe komponenty i usługi SOA.

Aha jeszcze jedna ważna rzecz.
Nie uważam, że SOA to recepta na wszystko. Fajnie jednak poznać wszystkie podejścia, ponieważ takie postępowanie otwiera Twój umysł na inne standardy i rozwiązania.
Ja np z nauki o SOA dostałem solidną porcję wiedzy jak projektować systemy w oparciu o WS oraz jak zabezpieczać takie systemy (security problems).

cdn


EIP w oparciu o framework Apache Camel. Chapter 1


Poznaj swojego nowego przyjaciela.
Ma na imię Camel. To taki integration master. Silnik do budowy i obsługi zdefiniowanych tras. Pozwala projektantowi zadecydować kiedy wysłać i odebrać wiadomość, ustalić politykę procesowania, błędów, gwarancji dostarczenia czy ponawiania.
Dostarcza się warstwę abstrakcji, która przykrywa szczegóły protokołów i dostarcza obsługę popularnych formatów danych.

Integracja systemów to ciężka praca. Developer musi zmierzyć się z następującymi problemami :


- komunikacją systemów (wystawianiem i konsumpcją danych serwowanych przez zdefiniowane endpoint'y)

- transformacją komunikatów (tak aby jeden system mógł porozumieć się z drugim)

- manipulacją tras (czyli zmianą logiki działania, serwowania danych czy strategii transformacji oraz wyboru rodzajów i sposobów komunikacji po przez czynniki wewnętrzne  - uwarunkowania biznesowe)

- odpowiednie reakcję na zaistniałe błędy (zdefiniowanie polityki obsługi błędów )

Co dostajemy w zamian korzystając z systemów integracji jak Camel czy Spring Integration ?

- redukcje boilerplate code (nie musimy już programować obsługę JMS, SOAP, JDBC, socket-level I/O czy mechanizmów transformacji i konwersji jak np CSV, XML, JSON etc )

- jasność działania biznesu aplikacji. Posługujemy się wzorcami EIP, które są ogólnie skatalogowane i dobrze znane programistą implementującym logikę biznesową czy też integrację pomiędzy systemami.

- monitoring. To dostajemy out-of-the-box. Czyli wiemy ile komunikatów przeszło daną trasą ile wpadło do Dead letter queue etc

- redukcje popełnionych błędów. Stosujemy szablony i sprawdzone abstrakcję poparte setkami testów oraz działaniem produkcyjnych w wielu systemach.

- ponad 160 istniejących komponentów wśród nich znajdziemy takie jak np:
 File, JMS, PGP, SMTP, ZooKeeper, Facebook, Twitter, SAP, Nagios i wiele innych. 

Camel opiera się na na lekkim i lubianym modelu POJO, DSL, akceptuje definicję i konfigurację zarówno w javie, xml, scali czy groovy'm.
Posiada lekki core, automatyczną konwersje typów, wbudowane wsparcie testów, modularną budowę, zestawy wtyczek i komponentów ułatwiających integrację na różnych płaszczyznach.
Integrację z wieloma frameworkami jak np Spring, OSGi Blueprint etc

Koncepcja EIP jest prosta i czytelna i stąd jej ogromna potęga.

Wygląda to w skrócie następująco :

 nasłuchuj na zadanym endpointcie korzystając z JMS
     rozdziel wiadomość bazując na jakimś wrażeniu
             przetwórz wiadomość niezależnie i równolegle
                   z agreguj wynik w całość
    dostarcz przetworzoną wiadomość do końcowego klienta używając protokołu  SFTP i danego endpointu


Może inaczej. Jeśli jeszcze nie czujesz tej potęgi zalet systemów integracji to może mój przykład Cie przekona.

Wyobraź sobie, że masz dany zasób na który w dowolnych momentach wpadają wiadomości w formie plików XML. Twoim zadaniem jest konsumować te pliki, po przetworzeniu każdego z nich przenieść każdy z osobna do innej lokacji np /backup , rozdzielić wiadomości bazując na dostawcach i priorytetach. Wysłać powiadomienia o udanych transakcjach do klientów korzystając z SMTP  i równolegle dostarczyć wiadomość w formie pliku csv do magazynu sklepu w celu wysłania towaru do klienta. W przypadku błędnego pliku powiadomić po przez WS system dostarczający pliki do naszej lokacji czyli startowego endpointa.

Uffff. Sporo tego. Nie korzystając z Camela musimy uporać się z wieloma problemami. Każdy z nich z osobna możemy spieprzyć czytaj spierdolić :).
Czy będzie to przetwarzanie pliku XML, czy to wytwarzanie pliku CSV, wysyłka maila z szyfrowaniem załącznika, obsługa błędów, wystawienie WS, transformację wiadomości, obsługę operacji I/O. Jest tego naprawdę dużo.


Rozważmy np prosty endpoint file:/ czy sftp:/. , których zadaniem jest polling lokalnego zasobu.
Pisząc jedną linię kodu w Camelu równoważymy setki linii kodu, który musieli byśmy napisać a potem przetestować itd.
Stosując Camela nasz kod jest reużywalny i łatwy w testowaniu. Przy czym również bardzo prosty do zrozumienia przez drugiego programistę.

Używając Camela można to wszystko co opisałem wyżej zrobić na jednym ekranie monitora! Brzmi super! i tak też działa.

Ale po kolei:)

Generalnie możemy wyróżnić następujące typy integracji : (moje stare notatki)




 
Information Portals
Problem : Użytkownik końcowy musi mieć dostęp do wielu systemów aby otrzymać odpowiedź na zadane pytanie.
Przykład : sklep internetowy i system reprezentowany przez firmę kurierską monitorującą stan zadanej przesyłki.
Nie dość, że jesteśmy zalogowani w sklepie to czasem musimy zalogować się do systemy monitoringu firmy kurierskiej. Obecnie jest to rzadko spotykane, bo wystarcza nam w tym celu wygenerowany token.
Data Replication
Problem : Wiele heteregoniczych systemów potrzebuje dostępu do tych samych danych, tworzą bliźniacze magazyny danych.
Przykład : System  A, B i C korzysta z danych znajdujących się w tej samej fizycznej bazie. Rozwiązaniem jest replikacja danych na poziomie samej bazy lub np zastosowanie kolejek do transportowania danych między systemami
Shared Business Functions

Problem : W ten sam sposób wiele aplikacji przechowuje nadmiarowe dane, co aplikuje tendencją do redundancji funkcjonalności.


Przykład : Wiele systemów korzysta z NIP'u danego klienta, lub słownika kodów pocztowych. Można ujednolicić usługę poprzez wystawienie wspólnego API, co z kolei skutkuje tym, iż podobne usługi w heterogenicznych systemach znikną zastąpione klientami.
Service-Oriented Architectures

Problem : Wspólne funkcje biznesowe możemy realizować za pomocą dobrze zdefiniowanych usług. Sługi te są powszechnie dostępne i odpowiadają na żądania klientów. Usługi te muszą być na stałe zamontowane w infrastrukturze systemu, skatalogowane pod względem dostępnych funkcji. Każda usługa SOA musi opisywać swoją funkcję oraz sposób komunikacji z innymi usługami w tejże architekturze. Wszystkie usługi z katalogu usług muszą dostępne być w spójny sposób.
Tutaj może się zatrzeć różnica pomiędzy integracją a rozpowszechnianiem usługi. 
Distributed Business Processes

Problem : Jedna transakcja biznesowa może być rozprzestrzeniana pomiędzy wiele systemów. Często brakuje koordynatora dla takich zadań, który zarządza wykonaniem podobnych funkcji w wielu istniejących systemach.

Przykład : Rozmycie odpowiedzialności dla funkcji biznesowych jak i usług SOA
Business-to-Business Integration

Problem : Ujednolicenie protokołów komunikacji, formatu danych  oraz systemów bezpieczeństwa pomiędzy dostawcą a klientem usługi.


Przykład : Sklep internetowy - dostawca towaru, komunikacja pomiędzy partnerami biznesowymi.

Sposoby zdalnej komunikacji :
- RPC
- RMI
- REST
- WS
- COBRA
- JMS
- Remoting (spring http remoting etc)

Rozważmy najprostszy znany typ integracji to komunikacji TCP/IP ale ma ona następujące wady :

- Location - musimy zrobić hard-coded dla adresów fizycznych maszyn
- Time  - komponenty objęte obszarem komunikacji muszą być dostępne w tym samym czasie
- Data Format - listy parametrów i ich typu muszą się zgadzać po obu stronach
- bardziej tight coupling niż loose coupling


Na decyzję integracji mogą wpływać następujące czynniki : 

- Application coupling -  aplikacje powinny dążyć do minimalizacji wspólnych zależności

- Integration simplicity - należy dążyć do maksymalizacji prostoty integracji.
Minimalizować ilość kodu i  koszty utrzymania aplikacji.

- Integration technology - należy brać po uwagę użyte technologie, koszty z nimi związane oraz ewentualne problemy projektowe

- Data format - należy umożliwić wymianę danych pomiędzy systemami bazującymi na innych formatach danych czy protokołach. Należy tak projektować systemy integracji aby zamiana protokołu czy formatu była możliwie jak najprostsza i jak najmniej kosztowna.

- Data timeliness - integracja powinna brać pod uwagę minimalizację czasu pomiędzy udostępnieniem danych przez jedną z aplikacja a konsumpcją i ewentualną odpowiedzią przez drugą aplikację. Dane powinny być wymieniane w stosunkowo małych kawałkach, a nie w zbiorach dużych niepowiązanych elementów co może mieć impakt z przyszłą wydajnością systemu
Tip : Spring Batch
Opóźnienia (Latency in data sharing) powinny być uwzględnione w procesie projektowym, gdyż może skutkować to tym, że dane dane nie będą już aktualne, a integracja stanie się bardziej złożona.

- Data or functionality -  zintegrowane aplikacje mogą nie tylko dzielić ze sobą dane ale również dzielić funkcjonalność (SOA). Zdalne wywołanie funkcji jest zawsze trudniejsze i bardziej kosztowne niż wywołanie jej lokalnie - zawsze musi brać to pod uwagę, bo konsekwencje mogą być istotne.

- Asynchronicity - typowym podejście jest proces synchroniczny czyli klient czeka na odpowiedź serwera, jak już ją dostanie może kontynuować przetwarzanie danych. Takie podejście może stwarzać nie tylko problemy wydajnościowe ale także problemy związane z dostępnością. Np mogą wystąpić chwilowe problemy z siecią, dany zasób może być chwilowo niedostępny również z innych powodów. Zastosowanie mechanizmów asynchronicznych, gwarancji dostarczenia oraz ponawiania pomoże rozwiązać ten problem.

Sposoby integracji systemów : 

- File transfer - czyli wymiana plików :








Aplikacja produkuje pliki zawierające informację potrzebne do integracji. Druga aplikacja konsumuje je w określonych odstępach czasu albo przez ciągły monitoring (polling) zasobu. Następnie musi wziąć odpowiedzialność za transformowanie plików do spójnych czytelnych formatów.

   Features :
   - systemy budowane w różnym czasie - problem wyboru technologii
   - systemy budowane przez różnych ludzi, różne podejścia (preferencje)
   - wybór formatu pliku
   - dostępność pliku, periodyczność wytwarzania czy konsumncji

   Zalety :
   - uniwersalny mechanizm przechowywania danych, dostępny w każdym  systemie
   - nie potrzeba jest wiedza na temat wewnętrznej części aplikacji (jedynie warunki negocjacji integratorów systemów)
  - nie wymaga skomplikowanej konfiguracji jak np : MOM

  Wady : 
    - integracja zazwyczaj wymaga więcej pracy od dewelopera (nazewnictwo, parsowanie, transformacje, kopie zapasowe, polityka postępowania z plikami)
    - zastosowanie mechanizmów blokujących (jeśli plik nadpisywany jest strumieniowo, klient nie może go odczytać aż do skończenia pisania)
   - brak szybkiej synchronizacji
   - duże koszty przetwarzania i obsługi zasobów dyskowych (I/O)
   - walidacja i niespójność danych 
   - zachowanie izolacji między systemami kosztem aktualności danych. (Systemy nie nadążają za sobą, współpraca jest zbyt wolna)
  
 TIP : jeśli zależy Ci na umożliwieniu częstej wymiany małych ilości danych bardziej odpowiednie będzie użycie RPC lub Messaging.

- Shared database - wspólna baza danych













Features : 
  - wszystkie dane opierają się na tej samej bazie danych. Gwarancja spójności.
  - wiele formatów plików (File transfer) = wiele potencjalnych problemów
  - gdy aplikacja mu być dystrybuowana na wielu komputerach baza danych musi być również replikowana

Zalety :
  - lepsze walidacja i spójność danych niż w przypadku File Transfer
  - łatwiej wykryć i poprawić ewentualne rozbieżności w formatach danych

Wady :
  - opracowanie jednego jednolitego schematu dla wszystkich kontraktorów systemu
  - przechowuje dane razem kosztem sprzęgania.

  TIP : NOSQL = schema free

  - potencjalne przyczyny wąskich gardeł : locks
  - rozproszona baza danych z konfliktem (locking conflict) może stać się koszmarem jeśli chodzi o wydajność
  - baza danych zbyt odsłania struktury danych co kłóci się z ideą enkapsulacji, a taki kod jest trudniejszy w utrzymaniu.

TIP : Do umożliwienia częstej wymiany małych ilości danych przy użyciu jednego formatu na typ danych użyj RPC, w przypadku uniwersalnego formatu lepiej sprawdzi się Messaging.

- RPC - czyli wywołania zdalne










Features :
 - samo udostępnianie danych często nie wystarcza. Częste zmiany danych mogą prowadzić do poważnych zmian w różnych aplikacjach.
 - wywołanie funkcji w jednej aplikacji wraz z przekazaniem informacji jak te dane ma procesować
 - RPC , Corba , Remoting, RMI, WS, REST

Zalety : 
 - lepsze enkapsulacja niż w przypadku podejścia Shared database
 - każda aplikacja z osobna jest wstanie utrzymać integralność swoich danych
 - każda aplikacja może zmienić swoje dane wewnętrzne bez żadnego negatywnego wpływu na drugą aplikację.
 - wsparcie dla transakcji
 - użycie WS nie koliduje z regułami firewalla
 - eliminacja wspólnych dużych struktur danych, zmniejszenie sprzężenia pomiędzy systemami

Wady :
  - negocjowanie interfejsu z innymi systemami podlegającymi integracji
  - duże różnice w wydajności pomiędzy wywołaniem zdalnym a lokalnym
  - tight couple (ciasne wiązanie)
  - nieodporny na uszkodzenia lub chwilową niedostępność innego systemu

Tip : W celu częstej wymiany małych ilości informacji, bez żadnego narzutu na sprzężenie i obawy na wydajność lepiej sprawdzi się Messaging.

- Messaging - komunikacja systemów poprzez systemy kolejek (loose coupling)









Tworzenie kolejki :














Features : 
 - niezależny od platformy
 - niezależny od języka i systemu










 - Channels - wirtualne kanału przekazywania wiadomości zestawiane pomiędzy senderem a receiverem.

- Message - to atomowy pakiet danych serwowany przez channel. Składa się z nagłówka(header) i ciała (body)

















- Multi-step delivery - wykonanie działań mających na celu poprawne dostarczenie wiadomości do adresata. Np walidację czy transformację danych podczas wysyłki.

Routing - połączenie kanałów i procesów biznesowych w logiczną spójną całość.

Transformation - zmiana formatu danych tak aby zaakceptował go docelowy odbiorca

Endpoint - umowny punkt wejścia i wyjścia dla danego procesu routingu, definiujący określony protokół.

Pojęcia kluczowe w messagingu :

- broker (broker) – odpowiednik poczty
Zapewnia on dostarczenie wiadomości do określonego adresata . Klient nie musi posiadać żadnej wiedzy jak broker sobie z tym poradzi – to jest dla niego
przezroczyste.

- miejsce docelowe (destination) – rodzaj adresu pocztowego
Określają gdzie komunikat będzie odebrany, nie na tym kto go odbierze

Rozróżniamy dwa rodzaje miejsc docelowych :
- kolejki (Queue)
- tematy (Topic)



P2P - opis : 
Punkt-punkt czyli P2P (point-to-point) w przypadku kolejek
W modelu P2P każdy komunikat ma jednego dostawce i jednego odbiorcę
Broker umieszcza komunikat w kolejce. Odbiorca zgłasza się po komunikat
komunikat jest pobierany z kolejki i dostarczany odbiorcy.
Podczas dostarczania komunikat jest usuwany z kolejki stąd pewność, że trafi on tylko do jednego odbiorcy.
Komunikaty z kolejki mogą być przetwarzane przez dowolną liczbę odbiorców
Analogią takiego działania może być kolejka do kasy

Zastosowanie P2P :
 - klaster usług
 - load balancing – czyli równoważnie obciążenia na zasadzie pull, nie push
   Jeśli usługa jest nadmiernie przeciążona wystarczy dodać kilka nowych    instancji usług (MDB) odbierających komunikaty z danej kolejki

 - kosztowne czynności, których rezultatów nie musimy mieć od razu
 - komunikacja pozbawiona blokowania (asynchroniczność)
 - wysoka skalowalność
 - łatwa priorytyzacja
 - integracja
 - luźne sprzeżenia
 - większa wydajność przy słabym łączu
 - szeregowanie transakcji
 - routing
 - strategia Master-Slave

Sub-Pub : opis
Publikacja-Subskrypcja czyli (publish-subscribe) w przypadku tematów
W tym modelu komunikaty są wysyłane do tematów.
Wiele odbiorów nasłuchuje kanał jak w przypadku kolejek ale w modelu Pub-Sub wszyscy subskrybenci dostają kopie tematu.

Analogia : gazeta – prenumerata, czyli każdy kto zaprenumeruje daną gazetę
otrzymuję np. co tydzień identyczny egzemplarz
Zalety messaging'u: 
 - totalnie luźnie wiązanie
Luźne wiązanie + rozprężenie (loose coupling + decoupling) – klient nie musi wiedzieć nic o serwerze. Integracja różnych systemów napisanych w różnych technologiach. Klient nie jest uzależniony od konkretnego adresu usługi jak w przypadku komunikacji HTTP

 - mechanizm ponawiania

 - gwarancja dostarczenia (quaranteed delivery

 - mechanizm persystencji Trwałość komunikatu (durable)

 - odporny na uszkodzenia lub chwilową niedostępność danego systemu
Niezawodność (reliability) - klient nie jest uzależniony od dostępności zdalnej  usługi 

 - ogólna odporność (robustness)
 
 - obsługa asynchronicznych komunikatów - odpowiednia reakcja na problemy występujący w systemach rozproszonych.  
Asynchroniczność – klient nie czeka, aż usługa zostanie przetworzona (wydajność) czyli brak blokowania. Usługa typu file-and-forget.

 - mniej punktów awarii (fewer points of failure)

 - łatwa transformacja i routowanie wiadomości  np : XPath

 - brak wrażliwości na zmianę koncepcji czy interfejsu zdalnej usługi, dla klienta jest to nadal przezroczyste. (dobry przykład to WS czy REST)

 - koncentracja na danych zamiast wywołaniu metody jak w przypadku komunikacji RPC

Wady :
 - trudniejsza implementacja
 - trudniej testować i debugować


Mając podstawową wiedzę możemy powrócić do tematu czyli Apache Camel.
























Podstawowym obiektem Camela jest obiekt wymiany jakim jest Exchange Message.
Zawiera on właściwości w postaci  mapy<String,Object>, unikalny identyfikator wiadomości Exchange ID, Message Exchange Pattern w skrócie MEP, dwie wiadomości oraz ewentualne wyjątki.

InOnly—A one-way message (znaną też jako Event message). Czesto JMS wykorzystuje one-way messaging. Odpal i zapomij operacja jednokierunkowa.

InOut—A request-response message. Transport typu HTTP często bazuje na tego typu wiadomości gdzie żąda wyświetlenia strony ale musi i czeka na odpowiedź serwera. Żądanie-odpowiedź.

MEP określa czy użyć styl InOut, czy InOnly.

MEP to skrót określający wzorzec wymiany komunikatów. Jest to termin zaczerpnięty z nomenklatury SOA. Najbardziej znany przykład tego wzorca to 'żądanie-odpowiedź' - usługodawca wysyła komunikat-żądanie do usługi-dostarczyciela. Po poprawnym odebraniu komunikatu wysyła do jego nadawcy komunikat-odpowiedź w kierunku przeciwnym przez usługę dostarczyciela.
Więcej o wzorcu MEP czytaj w poście SOA czyli tutaj.

MEP to po prostu abstrakcyjny wzorzec interakcji pomiędzy dwiema usługami. Definiuje wymianę komunikatów pomiędzy nimi.

Exception - ewentualne błędy, które pojawią się podczas routingu wiadomości.

Processor jest to bazowy interfejs służący do przetwarzania wiadomości. Generalnie implementowany zawsze przez programistę.

Route - zestaw kroków zdefiniowanych przez programistę zaczynając od słowa kluczowego a zarazem Endpointu "from". Trasy są z reguły luźno powiązane i powinny być łatwe do przetestowania i użycia w innym miejscu systemu.
  
Trasy :
- zdecydują o dynamicznym zachowaniu serwera 
- pozwalają w elastyczny sposób dodać dodatkowe przetwarzanie
- powalają odseparować klienta od logiki serwera
- umożliwiają mockowanie procesów
- promują najlepsze praktyki projektowe
- mogą być wykorzystane w systemach typu ESB

Context - czyli ładowanie i definicja wszystkich komponentów, tras, konwerterów oraz ustawień potrzebnych aby wystartować proces Camela.












Component - biblioteka, która enkapsuluje komunikację, transport i zachowanie za wspólnym interfejsem zdefiniowanym przez Camela. Camel używa komponentów do produkcji bądź konsumpcji wiadomości.

Endpoint - może być potraktowany jako identyfikator źródła zasobów czy będzie to JMS, czy File jest to obojętne. Słowo kluczowe "from" - oznacza czytaj z , a słowo "to" - zapis , wyślij do.

Camel DSL - możemy użyć płynnych interfejsów :
 - Java DSL
 - Spring DSL
 - OSGI Bluepring XML DSL
 - Groovy DSL
 - Scala DSL

Każdy z DSL ma swoje wady i zalety ale o tym potem w następnym poście.
Poniżej obrazowy przekrój problemów oraz wybór odpowiedniego komponentu. (jako rozgrzewka przed następnymi postami z cyklu integracja)
źródło : http://www.eaipatterns.com/

Podsumowując: Dziś nauczyłeś się co to jest integracja. Jaką możesz wybrać strategię. Co to jest Camel ? - czyli  totalny wstęp. Jak wybrać i dobrać odpowiednie rozwiązanie integracyjne do Twoich potrzeb.
Dla mnie Camel to cudowne narzędzie. W wielu przypadkach pozwolił mi redukować kod i potencjalne problemy do minimum.
Kiedyś nie znałem wzorców integracji EIP oraz żadnego frameworka integracyjnego.
Jak dziś oglądam swój kod w, którym przeprowadzam integrację ręcznie - cóż wygląda pożal się Boże.
Wstydzę się go dzisiaj. Niestety wtedy jeszcze jakieś cztery czy pięć lat temu nie posiadałem takiej wiedzy i zapłaciłem wtedy duże frycowe. Napotkałem szereg problemów, napisałem dużo gównianego kodu. Chciałbym, żeby każdy kto przeczytał dzisiejszy wstęp do integracji nie popełnił mojego błędu i poszedł w kierunku Camela czy Spring Integration.
Co więcej zarówno Camel jak i Spring Intergration super integrują się z Spring Batch to bardzo ważne jak to robić pokaże w następnych postach z cyklu intergracja.


training in Camel part 1

niedziela, 9 lutego 2014

maven best practices - enforce plugin, (logback, slf4j)

Enforce plugin

OK,;) Analiza problemu.(przykład)
Używając Springa jako zależności sam spring ładuje sobie z automatu commons-logging.jar. Czy to jest dobre ? - nie. Nie chcemy używać dziadowskiego commons-logging wolimy wykorzystać nowy stos logowania np slf4j i logback . Pomimo, że temat strategii logowania bardzo odbiega od tematu posta postanowiłem go trochę rozwinąć.

Slf4j to nic innego jak implementacja wzorca fasada.
Logback to 'syn' log4j stworzony i zaimplementowany przez tego samego autora.




Zalety logback w porównaniu do swojego poprzednika są następujące :

- znacznie szybsze działanie – lepsza implementacja
- automatyczne przeładowanie oraz zmiany konfiguracji loggera
- wyświetlanie informacji co do właściciela klasy – t.j jara
- lepsze filtrowanie
- automatyczna kompresja i archiwizacja plików z logami
- automatyczne usuwanie starych archiwów
- śledzenie danego kawałka kodu po zadanym markerze
- konfiguracja w XML lub groovy
 
- natywna komunikacja z slf4j bez jakiekolwiek innego narzutu.


Resztę powodów dla których warto od razu przesiąść się na logbacka znajdziesz tutaj


Polecam bardzo te biblioteki. Ja osobiście wykorzystuje je od dawna na rzecz starego już log4j.

TIP : Wszędzie używaj Slf4j jako fasady systemów logowania oraz logback jako jednej z implementacji. Zapewni Ci to szybkość działania, konfigurowalność i niesamowitą elestyczność. 

Zasady działania logback'a znajdziesz tutaj  i  właśnie z tego bloga pochodzą poniższe rysunki.
































Zestawienie slf4j wygląda następująco :






















Przykład wykorzystania znajdziesz tutaj.


Ok. Wracajmy do pluginu enforce. Poniżej widzimy, że podczas kompilacji źródeł wystąpił błąd.
po wykonaniu komendy mvn depencency:tree określamy miejsce wysŧępowania zależności niechcianej biblioteki. Znalazł się winowajca. Jest nim spring.

Teraz musimy tylko exludować daną bibliotekę i gotowe.

recepta :
Przypadek nr czyli wybieramy stabilne wersje pluginów : 1.3.1

plugin update

Plugin maven enforce możemy użyć do różnych stadium przypadków problemów z naszym wytwarzaniem np :
- zakładając restrykcję na wersje javy 
- zakładając restrykcję na wersje mavena 
- zakładając restrykcję na wersje danej biblioteki lub jej występowanie 
- zakładając restrykcję na wersje plugina 
- zakładając restrykcję na występowanie danego pliku np : changeLog.txt 
i wiele innych ich spis znajdziesz tutaj

Przykładowa konfiguracja enforce plugin:

Czyli : nie chcemy wykorzystywać hibernate w wersji 3, adaptera slf4j dla log4j, samego log4j, commons-logging oraz narzucamy wykorzystanie javy w tym przypadku od 1.7 do 1.8v.

TIP : Jeśli używasz mavena zawsze użyj enforce plugin. Uchroni Cie on od nieprzewidzianych kłopotów oraz pozwoli na zdefiniowanie polityki restrykcji dla zależności oraz innych funkcji i zasad w Twoim projekcie.
cdn

wtorek, 4 lutego 2014

REST i okolice - chaper 1


REST = REpresentation State Transfer
REST in a nutshell to : 'RE' zasoby reprezentowane w każdej możliwej formie , 'T' = umożliwia transfer zasobów z jednej aplikacji do drugiej, 'S' - koncentrujemy się na zasobie a nie na działaniu (WS)
REST to również styl architektoniczny, którego autorem jest koleś współtworzący protokół HTTP czyli Roya T. Fieldinga . Można się spodziewać, że w takim razie wiedział on co robi tworząc REST.
Podstawowym komponentem jest zasób (resource), który jest adresowany poprzez URI.
W dzisiejszych czasach każdy poważny serwis internetowy udostępnia API. Więc czemu się na tym nie wzorować ? W przeciwieństwie do standardowych WS pozbawiony jest często niepotrzebnej otoczki jaką jest SOAP i działa! - poprzez efektywne wykorzystanie HTTP. Bardzo fajnie sprawdza się w aplikacjach mobilnych, ze względu na swoją 'lekkość'.


Ale zawsze jest coś za coś.... Nie ma róży bez kolców.
Standardowy WS wybieram zawsze tam gdzie potrzebuje wyrafinowanego security (WS-Security),
walidacji, routingu, gwarancji dostarczenia czy wysokiej niezawodności.
Generalnie pewnie lepiej sprawdzi się w aplikacjach korporacyjnych.
WS oparty na SOAP można tworzyć na 2 sposoby :
  - Bottom-Up czyli najpierw tworzymy klasy domenowe oraz klasy serwisu
  - Top-Down - punktem wyjścia jest istniejący już plik WSDL opisujący usługę.     

TIP: SOAPUI - testuj REST i WS zarazem

REST daje mi nowe możliwości w tworzeniu publicznego API na wzór wyżej wspomnianych portali czy serwisów internetowych.
Widzieliście już wcześniej API Facebooka czy Twittera.
Są świetne. Warto się na nich wzorować. Wiele firm buduje na podstawie tego API usługi dodane (value-added services) zwane mashupami.
Jest to serwis, który w celu stworzenia nowych usług wykorzystuje i łączy ze sobą dane pochodzące z co najmniej dwóch źródeł. Cechą mashup'a jest agregacja i wizualizacja. Przetworzone w ten sposób dane mają stać się bardziej przydatne.



Co więcej proponuje pisać od samego początku aplikacje w stylu REST. Dzięki temu nie obchodzi mnie wcale warstwa prezentacji bo zawsze mogą ją podmienić na inną (MVC) a dane ciągnę sobie poprzez AJAX.
Mało tego dostaje od razu dostęp do danych poprzez HTTP, bez użycia przeglądarki czyli usługę WS.

Tip : Poster, HttpRequester, RestClient firefox plugins 
Tip : Rest-shell - polecam ....
Tip : CURL przykład :
curl -H "Accept: application/json" -i http://localhost:8080/api/tags/1



Teraz inne aplikacje mogą gadać ze sobą poprzez takie API.
Wniosek jest następujący dostajemy łatwość integracji oraz bardziej elastyczny system. Dostęp do danych będzie bardziej intuicyjny, a dane zwracane mogą być w różnym formacie od json'a, xml'a po swoje własne egzotyczne formaty.

REST wspomaga ogólną wydajność bo łatwo się cache'uje oraz zyskuję trochę na przepustowości łącza.
Zalet jest więcej. Ważne jest aby pisać RESTful, a nie RESTless bo wtedy przygotowujemy sobie dwie pieczenie przy jednym ogniu.

OK.

REST – to obecnie bardzo popularne usługi internetowe
WS – bardziej wykorzystywanie w usługach aplikacji enterprise wymagających zapewnienia wysokiej jakości (QoS)
WS – wyższe standardy zabezpieczeń, walidacji, routingu, niezawodności
REST – skalowalność, prostota architektury, łatwość użytkowania oraz integracji.

REST to także :
System warstwowy  - w której każda warstwa może mieć tylko jeden poziom poniżej. Promocja prostoty.
Klient/Serwer - rozdzielenie klienta i dostawcy
Komunikacja bezstanowa  - warunek dobrej skalowalności
Replikowane repozytorium -można dostarczać określoną usługę za pomocą więcej niż jednego procesu = dostarcza skalowalność (scalability) i dostępność (HA)
Buforowanie = cache - komunikaty same określają jak i kiedy i ile czasu możemy buforować je w pamięci. Czyli otrzymujemy redukcję obciążenia serwera przez dostajemy większą wydajność.

Jednolity interfejs - 8 metod (PUT,POST,GET,DELETE,OPTIONS,HEAD,TRACE,CONNECT)


Teraz ważne jest zrozumienie terminów metoda: bezpieczna i idempotentna.
Metoda bezpieczna nie zmienia stanu zasobu.  
Metoda idempotentna może zmieniać stan lub nie, ale każde dalsze wywołanie takiej metody nie powinno powodować dalszych skutków. Wszystkie bezpieczne metody są idempotentne, ale nie wszystkie idempotentne są bezpieczne.

HATEOAS (Hypermedia as the Engine of Application State) - czyli zastosowanie "hipermediów jako silnika stanu aplikacji". Rozwiązanie to dostarcza linki do kolejnych zasobów powiązach logicznie czy biznesowo z obecnym bytem. Zajebiste ;)
Albo inaczej używając HATEOAS dostajesz samo opisujące się API.
Co jest dla mnie bardzo ważne poprzez HATEOAS możemy nawigować po aplikacji bez żadnego interfejsu użytkownika.

Dojrzałość serwisu REST ocenimy na podstawie tzn modelu dojrzałości Richardsona.

Ale po cholerę mi ten model ? Odpowiadam Ci, że  po to abyś ocenił ile Twój serwis jest RESTful a ile Restless.



























WS SOAP - również preferuje model bezstanowy, a buforowalność możemy osiągnąć na jednej z niższe z warstw np serwisie.
WS pozwala tworzyć reużywalne elementy.

Można wzbogacić SOA poprzez REST ? - tak : 
 - budowanie usług REST i poszerzanie ich tak aby stały się SOA.
 - poszerzanie usług SOA tak aby stały się usługami RESTful.

TIP : Wzorzec komponent brzegowy, CAMEL

Security : 
W WS podniesienie poziomu bezpieczeństwa uzyskujemy po przez użycie SSL czy użycie WS-Security.
Dla REST istnieje podejście alternatywne zwane OAuth czy OAuth2.
WS-Security jak i OAuth wykorzystuje tokeny w procesie autoryzacji.

Rozwinięcie problemu zabezpieczenia serwisów REST i WS znajdziesz niebawem tutaj

REST posiada znakomite wsparcie od Spring 3 w górę :

RestTemplate unikamy 'code boilerplate' i skupiamy się na rzeczach ważnych dla biznesu aplikacji. Oraz upraszczamy do minimum konsumpcje komunikatów REST.
 


Używając springa wykorzystujemy HiddenHttpMethodFilter do obsługi żądań różnych od GET i POST.



Klienta wywołuje również prosto :






































W konwersji @ResponseBody wiadomości type MiME pomogą konwertery:
























Ogólne zasady programowania serwisów REST są następujące :

Zwracamy odpowiedni status kodu w zależności od odpowiedzi :


Znaczenie kodów nagłówka HTTP : 
200 OK - żądanie zrealizowane prawidłowo

201 Created - zwraca Location header dla nowo stworzonego zasobu

202 Accepted - serwer zaakceptował żadanie, ale nie jest ono jeszcze kompletne.


301 Moved Permanently / 302 Move Temporarily - zasób przeniesiono w inne miejsce. Nowe położenie zasobu znajdziesz z nagłówku Location w ramach response.

304 - Not Modified - żądany zasób nie był zmodyfikowany od czasu poprzedniego żądania (sprawdzanie za pomocą nagłówka IF-Modified-Since)

401 Unauthorized - klient nie ma uprawnień by dobrać się do żądanego zasobu. W odpowiedzi powinna znaleźć się informacja dlaczego tak się stało (nagłówek WWW-Authenticate)

403 Forbidden - klient nie ma uprawnień niezbędnych do uzyskania dostępu do danego zasobu. Inaczej jak w przypadku instrukcji 401 odpowiedź nie zawiera żadnych informacji na temat uwierzytelnienia.

404 Not Found - nie można znaleźć zasobu.

406 Incompatible - nie kompatybilny nagłówek (Accept)

409 Conflict - konflikt zasobów podczas próby dostania się do zasobu przez klienta

500 Internal Server Error  - serwer nie może z jakiś powodów zrealizować danego żądania


Projektujemy API :







































Tip : Content negotiation - porozumienie się jeśli chodzi o  reprezentacje zasobu
Client - > Accept header
Server -> Content-Type header

Tip : Zawsze zwracaj czytelny komunikat błędu.

Tip :@ControllerAdvice - pomoże Ci globalnie lub generycznie obsługiwać sytuacje wyjątkowe.

Tip : SSL - zapobiega atakowi man-in-the-middle

Kod do aplikacji znajdziesz niebawem tutaj

P.S Ten post rozpoczyna jeden z moich ulubionych problemów i tematyk. Będzie ewoluował jeszcze przez jakiś czas. Czekajcie na kody na GitHubie. Oraz kolejne wersje, które wprowadzą Was także w świat i wzorce SOA od kuchni.

REST API part 2 ->

poniedziałek, 3 lutego 2014

Wydajne i skalowalne systemy - wstęp

OK, lecimy dalej :)
Dziś zapoznajmy się z kilkoma terminami, które powinieneś już znać jeśli jesteś na poziomie Competent albo wyższym. Jeśli interesujesz się trochę wydajnością, profilowaniem, tuningiem jvm jak i całego stosu aplikacyjnego to na bank znasz już cały poniższy słownik. Możesz więc zamiast czytać tego posta, po prostu iść na browara. Ale jeśli chcesz utrwalić swoją wiedzę to możesz sobie trochę poczytać.
Na początek podam kilkanaście wydawało by się suchych danych, na które natknąłem się jakiś czas temu na portalu  http://highscalability.com/.
Regularnie tam wchodzę i bardzo polecam to innym. To najlepszy portal o tematyce wydajności rozwiązań oraz skalowalności. Znajdziesz tu np architekturę Facebooka, Twittera , YouTube oraz szeregu innych wielkich produkcji świata IT.
Zunifikujemy sobie  nasz słownik pojęć. Potem go wykorzystamy do tuningu naszych aplikacji. Najważniejsze jest to żeby zacząć coś robić czy zdobywać wiedzę. Bo temat skalowalności oraz wydajności przez skalowalność jest wykurwiście ciekawy.


Zbudujmy sobie mini klaster do ćwiczeń. Wystarczy do tego Tomcat lub JBoss oraz HAProxy lub Apache jak kto woli. Jak nie wiesz jak tego dokonać to dowiesz tego się w następnych postach. Sam możesz zacząć już teraz jak czas żeby coś szperać. Możesz wszystko to  potraktować  jako takie małe ćwiczenie.


Pamiętaj : Zasada n1 jeden -> Zapis jest drogi.
Tradycyjne bazy potrzebują dysków. Dostęp do dysku wymaga wyszukania danego sektora. Przyjmuje się , że trwa to średnio 10ms.
Wynika z tego, że przeciętna maszyna potrafi wykonać 100 seeks/sec maximum
Wynik ten zależy jednak od rozmiaru i kształtu danych do zapisu oraz od typu pracy np batch

Tip : NoSql , chunk processing , batch

Zasada numer 2 -> Odczyt jest tani.
Zwykle odczyty nie potrzebują transakcji, możemy traktować je jako zwarte atomowe operacje. Raz wyszukane dane można cache'ować co bardzo zwiększa  szybko ponownego dostępu do tychże danych. 
Trzymamy się zasady :
  - 250usec for 1MB of data from memory
  - 1s / 250usec = 4GB/sec maximum

Tip :  Spring : @Transactional(readOnly = true)

Teraz trochę ciekawych numerów :
   L1 cache reference 0.5 ns 
   Branch mispredict 5 ns
   L2 cache reference 7 ns
   Mutex lock/unlock 100 ns
   Main memory reference 100 ns
   Compress 1K bytes with Zippy 10,000 ns
   Send 2K bytes over 1 Gbps network 20,000 ns
   Read 1 MB sequentially from memory 250,000 ns
   Round trip within same datacenter 500,000 ns
   Disk seek 10,000,000 ns
   Read 1 MB sequentially from network 10,000,000 ns
   Read 1 MB sequentially from disk 30,000,000 ns
   Send packet CA->Netherlands->CA 150,000,000 ns  

Końcowe wnioski :
 Zapis jest ponad 40 razy bardziej kosztowny niż odczyt
 Globalne dane współdzielone są kosztowne. 
 To jest główne ograniczenie rozproszonych systemów. 
 Występują blokady do współdzielonych zasobów co skutkuje lockami, transakcje stają się wolne.
 Należy optymalizować operację zapisu, i w  miarę możliwości je zrównoleglać.

TIP : MASTER-SLAVE

źródło wiedzy : http://highscalability.com/ (dane i numerologia)

Terminy, które musisz znać : 

źródło wiedzy : JEE design pattern (słownik pojęć)

Rozszerzalność (Extensibility) - często idzie w parze z Elastycznością (Flexibility)

Wymagania stale się zmieniają. Samo życie, ale mamy manifest AGILE.
Z każdą następną wersją pojawiają się nowe błędy i nowe funkcjonalności w systemie.
Rozszerzalność określa  łatwość przeprowadzenia zmian, przewidujemy ją na etapie projektowym.

Trudności w wprowadzania zmian rozszerzalności to:
-obawa że zepsuję inną cześć funkcjonalności nawet pozornie nie powiązanego z obszarem w którym robię zmiany
- wraz z rozbudowa aplikacji wzrasta liczba zależności miedzy modułami oraz tym samym liczba testów, które należy wykonać po każdej modyfikacji

Strach przed wprowadzeniem modyfikacji może paraliżować i aplikacja przestaje rozwijać czyli ewaluować w stronę lepszego.
Sytuacja może być jeszcze gorsza, ponieważ modyfikację jednej aplikacji mogą mieć wpływ na działanie pozostałych. 

Np system bankowy od dziś przelicza wszystkie transakcje tylko w $, jeśli systemy z nim powiązane nie zostaną odpowiednio dobrze przygotowane - powstanie chaos.

TIP : testy, test coverage, TDD

Zmiana interfejsu - modyfikacja nie tylko obiektu, który korzysta z tego interfejsu ale również obiektów z nim powiązanych
(Gwarantowanie zgodności interfejsu)

Rozszerzalność wymaga ścisłego korzystania z interfejsów w celu zagwarantowania, że obiekty współdziałają ze sobą w określony sposób na określonych zasadach.
Komponenty o rozbudowanych interfejsach są bardziej użyteczne niż komponenty o  ograniczonych interfejsach ale rozbudowane interfejsy powodują też ze powiązania miedzy komponentami mogą wydawać się zbyt ścisłe.

Dobrze zaprojektowane interfejsy pozwalają oddzielić implementacje od interakcji. Dzięki czemu implementacja może być niezależna od reszty kodu i tym samym dowolnie modyfikowana, poprawiana lub zastępowana nową wersją.

TIP : DIP, ISP

W ten sposób aplikacja przestaje być całością a staje się kolekcją komponentów w znacznym stopniu niezależnych od siebie.
Wspomaga to też prace w zespole poprzez :
   - używanie scm
   - testability
   - grupowanie w większe byty
   - reużywalność 

Zastosowanie takich reużywalnych komponentów pozwala ograniczyć stopień komplikacji tworzenia aplikacji, zapobiega tworzeniu ścisłych zależności, łatwość rozbudowy.

Koszt rozbudowy oraz aktualizacji (extensibility problem)
  - dług projektowy
  - nawarstwiające się poprawki utrudniają zarządzanie projektem oraz ograniczają możliwości ponownego użycia  jego kodu
- kod nadmiernie rozbudowanych programów jest trudny do zrozumienia
- wprowadzenie DSL  (camel)

Jak poprawić rozszerzalność :
- usuwanie powiązań - loose coupling (testablity, rozbudowa, zrozumienie)
- centralizacja - gromadzimy wspólną funkcjonalność w centralnych zasobach - ułatwia to zrozumienie, aktualizację oraz rozbudowę
- ponowne użycie (reusability)
- hermetyzacja wspólnej funkcjonalności za pomocą komponentów wielokrotnego użycia (umieszczenie zbyt wielu funkcji w jednym komponencie powoduje jego specjalizacje!!)

Skalowalność (scalability) - (własność systemu umożliwiająca obsługę rosnącej ilości pracy lub też łatwość rozbudowy istniejącego systemu w przypadku zwiększenia zapotrzebowania na pewne zasoby)

Skalowalność  jest to także zdolność aplikacji do zachowania wydajności przy jednoczesnym wzroście obsługiwanych żądań. Najlepszym przypadkiem skalowalności jest stały czas odpowiedzi, czyli sytuacja gdy czas przetwarzania zadania nie zależy od bieżącego obciążenia serwera.

W praktyce najlepiej jak aplikacja potrafi zachować w przybliżeniu stały czas odpowiedzi, gdy liczba obsługiwanych żądań zbliżona jest do standardowego obciążenia przewidzianego dla aplikacji.
Np jeśli aplikacja a będzie obsługiwać np  400 żądań na min. Sek to czas obsługi każdego żądania powinien zająć tyle czasu ile obsługa pojedynczego żądania w każdych innych warunkach.

O liniowej skalowalności mówimy wtedy, gdy czas potrzebny do przetworzenia n - żądań jest równy n * czas przetworzenia jednego żądania. Systemy mogą osiągać liniową skalowalność znajdując się pod szczególnie dużym obciążeniem . Jeśli obciążenie serwera osiągnie 400 userów na sek to czas odpowiedzi może wydłużyć się 2x w stosunku do sytuacji gdy jest obsługiwanych 200 userów na sek.

Jeśli system przetwarza żądania - otrzymuje 10 000 żądań i odpowiada na każde z nich  w 3 sek - to powiemy, że system skaluję się poprawnie a nawet wyjątkowo dobrze. Natomiast gdy system ten otrzyma 100 000 i odpowie na każde  z nich w ciągu 3 minut  sytuacja to będzie nie do zaakceptowania.












TIP : Zawsze dąż do liniowej skalowalności













Skalowalność jest kombinacją czynników: stałego czasu odpowiedzi aż do osiągnięcia pewnej liczby obsługiwanych klientów.

Skalowalność często wymaga kompromisu z rozszerzalnością. Czasami rozkład większych komponentów na mniejsze oraz ich powielenie stosowanie do potrzeb, pozwala zwiększyć skalowalność systemu.
Ale też czas komunikacji między komponentami ogranicza skalowalność więc potrzebny jest kompromis.

Wzorce projektowe wspomagają skalowalność umożliwiają efektywne użycie zasobów, tak by obsługa n klientów nie wymagała n jednostek zasobów. Rozszerzają też rozszerzalność aplikacji w celu poprawienia skalowalności.(rozproszenie operacji pomiędzy wiele serwerów, zastąpienie komponentów innymi o większej wydajności, o  lepszych algorytmach lub ułatwiając przeniesienie systemu na wydajniejszy serwer)













   























 




Wyróżniamy typy skalowalności jak :

 - horizonal-out - dodanie nowych węzłów mających taką samą funkcjonalność jak te które używaliśmy  dotychczas
- vertical-up rozbudowa istniejących węzłów poprzez dodanie nowych zasobów np pamięć, procesor itd
Wysoka dostępność (ang. high availability) czyli zdolność do przyjmowania wywołań na dowolnym węźle bez względu na stan pozostałych węzłów, dzięki czemu aplikacja pozostaje dostępna pomimo niedostępności niektórych węzłów. Czyli zapewnienie ciągłości funkcjonalnej systemu przez cały czas.
Użycie klastra pozwala na osiągniecie osiągniecie pewnego rodzaju high availability poprzez dostarczenie dodatkowych nadmiarowych serwerów w klastrze fail-over.
Dostępność liczymy na podstawie wzoru : 100 - (100*D/U) gdzie :
  -  D to unplanned downtime 
  -  U to uptime.


źródło : technews.tmcnet.com








  




























TIP : MapReduce, Spring Batch, Stateless

Reakcja na błędy (fail-over) – poprawna reakcja na uszkodzenie węzła,
polegająca na automatycznym przekierowaniu wywołań do innych sprawnych węzłów. Działanie to jest przezroczyste dla końcowego użytkownika.
Wymagania dwie lub więcej maszyn w klastrze.

Niezawodność (Availability, Robustness, Fault Tolerance and Reliability)
Oprogramowanie powinno działać zawsze w sposób przewidywalny .
Jest zawsze dostępne dla użytkownika (availability, fault tolerance)
Wprowadzenie tych samych danych powoduje uzyskanie tych samych wyników  (thread safe, robustness)

Jeśli któryś z komponentów nie działa poprawnie w ramach systemu , a użytkownik nie może skorzystać z aplikacji uznajemy system jako zawodny.

TIP : Zapewnienie jakości oprogramowania (wydzielić osobę z zespołu programistów) , audyt

Terminowość :
to terminowe dostarczenie gotowego - działającego produktu.

Np łatwo rozbudowany system może również lepiej skalować się poprzez dołączenie komponentów o większej wydajności, czasem czas poświęcony na zaimplementowanie obsługi skalowalności ułatwi dodatkowo terminowe opracowanie kolejnych wersji aplikacji.
Zastosowanie wzorców projektowych umożliwi poprawę efektywności aplikacji w 4 wyżej wymieniowych obszarach.

Tip : Oszczędności : zastosowanie wzorców projektowych, modularność, łatwość rozbudowy
Równoważenie obciążenia (ang. load balancing) - zapewnienie efektywnego
przetwarzanie wywołań poprzez ich rozdzielenie pomiędzy dostępne w klastrze
węzły. Jednocześnie fakt istnienia mutliplexingu jest ukryty przez końcowym klientem. Możemy użyć load balancingu bezstanowego (REST , WS) lub stanowego wymagającego współdzielenia sesji HTTP. Istnieje także wiele algorytmów rozdzielania żądań jak  np round robin. Pomaga osiągnąć high availability.

Cluster -  składa się z dwóch lub większej ilości serwerów połączonych ze sobą fizycznie siecią. Jest przezroczysty dla końcowego użytkownika. Jego zadaniem jest zazwyczaj zwiększanie wydajności i dostępności systemu. Koszt skalowania horyzontalnego w celu osiągnięcia tej samej wydajności jak w skalowaniu wertykalnym powinien być niższy.
Wyróżniamy tryby pracy jak  active-active (A/A) i  active-passive(A/P).
W A/A wszystkie maszyny pracują jednocześnie.
W A/P  inne maszyny przejmują zadania gdy jakaś maszyna aktywna ulegnie awarii.

Cache - przechowywanie danych najczęściej w pamięci w celu szybkiego serwowania ich do końcowego klienta. Dane najlepiej pasujące do tego schematu to dane ciężkie lub dane których generacja wymaga znacznych nakładów procesora.
Jeśli to są dane typu READ_ONLY wtedy mamy do czynienia z sytuacją idealną odnoście ich cache'owania.















Heterogeniczność węzłów (nodes heterogeneity) – możliwość dodawania do klastra węzłów bazujących na różnych systemach czy platformach sprzętowych

Dynamiczna rekonfiguracja (dynamic reconfiguration) – dodajemy, usuwamy, powielamy węzły  bez potrzeby chociaż chwilowego przerywania pracy całego systemu.

Tip : Zookeeper

Przepustowość (throughput) - ilość jednostek pracy (transakcji) jaką system może wykonać w zadanym okresie czasu

Opóźnienie (Latency) - minimalny czas wymagany do otrzymania jakiejkolwiek odpowiedzi z systemu na dane żądanie.

Ilość transakcji na sekundę (TPS, transactions per second) - jest to ilość przetworzonych transakcji systemu, które to wystąpiły w ciągu jednej sekundy.


Wykorzystanie zasobów (Utilization) - stosunek procentowy dostępnych zasobów, które system wykorzystuje do przetwarzania procesów. Nie wliczamy do tego zasobów będących w spoczynku (idle resource)


Przepustowosc systemu na sekunde DTPS (data throughput per second) - to wartość oznaczająca ilość danych jaka system przyjmuje do przetworzenia w ciągu sekundy. Jest to ilość danych zapisanych w każdej operacji zakończonej w jedno sekundowym przedziale.

Efektywność (Efficiency) - stosunek przepustowości do wykorzystanych zasobów

Pojemność (Capacity) - największa dopuszczalna wartość przepustowości lub obciążenia, które mogą być przyjmowane przez systemem w danej chwili.

Czas odpowiedzi (Response time) - ilość czasu potrzebna systemowi na udzielenie odpowiedzi na dane żądanie
Czas reakcji (Responsiveness) - szybkość z jaką system potwierdza przyjęcie żądania. Uwaga proces niezależny od jego przetworzenia. (Ważne w UI)
Zależność pomiędzy średnim obciążeniem, a szybkością generowania odpowiedzi (responsiveness) zależy często od rodzajów procesów oczekujących (priorytety).

Obciążenie (Load) - liczna jednocześnie podłączonych klientów

Wąskie gardło (bootleneck) - jest to odcinek drogi o przepustowości mniejszej niż pozostałych odcinków trasy czy danego przepływu powodujący znaczący spadek wydajności.

TCO (Total Cost of Ownership) - koszt wyrażony czasem pracy programisty niezbędnym do wprowadzenia danej poprawki , przekracza wskaźnik całkowitego kosztu pozyskania sprzętu, który zapewni podobny wzrost wydajności.

Profilowanie kodu (code profiling) - rejestrowanie w zadanym czasie informacji i markerów na temat przetwarzani i działania procesów programu. Powstałe dane zgromadzone są w celu późniejszej analizy i eliminacji ewentualnych wąskich gardeł.



Wrażliwość na obciążenie (Load sensivity) - stosunek czasu odpowiedzi, latencji lub przepustowości do wzrostu obciążenia. Zwany jest też degradacją systemu (Degradation)

Mediana (Median) - możemy ją traktować jako średnią artmetyczną bardziej odporną za wszelkiego rodzaju zakłócenia lub odchylenia.

Wydajność: (moje stare notatki)











Co należy mierzyć i na co zwracać uwagę:









































































Jeśli używasz springa : 








  
Popraw wydajności swojej aplikacji web :




Przedstawiałem Wam dzisiaj problem wydajności i skalowalności w pigułce.
Warto zapoznać się dobrze z powyższymi pojęciami aby przejść dalej i ewoluować w kierunku zwiększania poprawności oraz jakości swoich systemów.

next ->