Komponentowe systemy rozproszone Pub/sub, Broker vs. ESB.

Prezentacja na temat: "Komponentowe systemy rozproszone Pub/sub, Broker vs. ESB."— Zapis prezentacji:

1 Komponentowe systemy rozproszone Pub/sub, Broker vs. ESB

2 Publish/Subscribe Serwis A Informuj mnie o opłaconych fakturach nadzoruje wysyłkę opłaconych wcześniej faktur Nowa opłacona faktura Serwis B Opłata za fakturę Nowa opłacona faktura Opłata za fakturę

3 Publish / Subscribe Zdarzenia na poziomie systemowym  Wystąpienie zdarzenia oznacza wysłanie komunikatu  Obsługa zdarzenia odpowiada obsłużeniu komunikatu Zdarzenia powinny być rozpatrywane na poziomie biznesowym (zmienił sie stan zamówienia, ktoś ma inny adres, rabt itd.)

4 Kolejność zdarzeń Sprzedaz Rachunko wosc Spedycja Zaakceptowane Opłacone Nie ma zamówienia w DB Komunikat zostaje odrzucony Czeka na Opłacone (które już było)

5 Publish vs Request Publikując zdarzenie nie czekam na odpowiedź Autonomia usługi: do wykonania własnej pracy nie potrzebuje reakcji innych usług. Notyfikuję inne usługi o zdarzeniach biznesowych w “ich interesie”. Jak to się ma do tradycyjnych WS  Request/response jest dopuszczalne, ale wołający nie powinien polegać na odpowiedzi – Np. wyświetlenie reklamy, prognozy pogody  Na upartego można zrealizować pub/sub na WS – kompli- kując odpowiednio logike wołającego, tak by był w stanie powtarzać wołania, obsługiwać listę subskrybentów itd.

6 Kolejność zdarzeń Nie należy zakładać konkretnej kolejności nadchodzenia komunikatów  Możliwe rozwiązanie zapis niekompletnej informacji np. opłacono nieznana fakturę – dane nt. szczegółów przyjdą w przyszłosci  W ostateczności można założyć próbę ponownego przetworzenia komunikatu w przyszłości Zyski to m.in. Lepsza skalowalność Większa odporność na błędy

7 Publish / Subscribe vs kolejki Wykorzystanie kolejek do publikacji informacji o zdarzeniach pozwala  nadawcy nie czekać na przetworzenie komunikatów przez odbiorcę  odbiorcy przetworzyć otrzymane komunikaty w dogodnym momencie  Niebezpieczeństwo: przepełnienie kolejek  ServiceBus czesto używają kolejek jako warstwy transportowej

8 Zmiany kontraktu Co oznacza własność komunikatu? Kto jest właścicielem formatu/protokołu w pdejściu Request/Respone?  nie za bardzo wiadomo Kto jest właścicielem formatu/protokolu w pdejściu Publish/Subscribe?  publikujący

9 Subscribe Dla redukcji powiazań przestrzennych (spatial coupling) możliwe jest mapowanie między typem komunikatu i adresem sewisu odbiorcy (nadawca nie musi więc wiedzieć kto jest odbiorcą) Subskrypcja oznacza gotowość do obsługi danego typu komunikatów  rejestracja handlera (-> Bus) oznacza właśnie subskrypcje  (może przekładać się na wysłanie wewnętrznych komunikatów w obrębie infrastruktury)  Zwykle założenie subskrypcji oznacza zapamietanie adresu handlera/kolejki, której używa itd.

10 SOA jest stylem architektonicznym SOA opiera się na komunikatach SOA zakłada autonomię serwisów … Dwa częste podejscia Bus vs. Broker służą redukcji powiązań przstrzennych

11 Styl architektoniczny Broker Inicjator żąda usługi od brokera Broker obsługuje po kolei żądania i przekazuje je dalej Service A Service B Service C Service D Broker

12 Cechy Broker-a Broker jest fizycznie odseparowany Cała komunikacja odbywa się przez niego Broker musi obsłużyć upadki serwisów i przekazywanie wiadomości Broker stanowi “single point of failure” – musi być wydajny i niezwykle stabilny Technologie: BizTalk, CORBA, UDDI

13 Zalety Broker-a Dzieki skoncentrowaniu komunikacji w jednym miejscu łatwo zarządzać centralnie konfiguracją Łatwe jest uzyskanie inteligentnego przekazywania danych, transformacje, orkiestracje itd. Nie wymaga wielu zmian w serwisach

14 Wady Broker-a Narusza autonomię serwisów Stanowi “single point of failure” i b. często jest wąskim gardłem

15 Styl architektoniczny Szyna Sink SourceSink Source Bus Źródła i ujścia zdarzeń komunikują się za pośrednictwem kanałów w szynie Źródło umieszcza komunikaty (zdarzenia) w kanale a ujście jest notyfikowane odostępności komunikatu

16 Topologia Szyny na przykładzie NServiceBus App1App1 Bus.dllBus.dll App3App3 Bus.dllBus.dll App2App2 Bus.dllBus.dll App4App4 Bus.dl l

17 Cechy Szyny Szyna niekoniecznie jest fizycznie odseparowana  Kanały mogą być zarówno fizyczne jak logiczne Komunikacja jest rozproszona pomiedzy wieloma kanalami Szyna jest prostsza Brak ”single point of failure” (dla niektorych/wszystkich operacji)

18 Zalety Szyny Brak “single point of failure” Nie narusza autonomii serwisu The “anti-broker”

19 Wady szyny Trudniejsza do zaprojektowania niż Broker

20 Komercyjne implementacje ESB Adeptia ESB Suite webmethods Enterprise Service Bus (SoftwareAG) (TIBCO) ActiveMatrix™ Service Bus IBM WebSphere ESB IBM WebSphere Message Broker ttxNgine (3Txpert GmbH) Microsoft BizTalk Server Windows Azure Service Bus Neudesic Neuron-ESB NServiceBus Oracle Enterprise Service Bus (BEA Logic) Progress Sonic ESB Red Hat JBoss Fuse IONA (acquired by Progress) InterSystems Ensemble

21 Otwarte implementacje ESB Apache ServiceMix Apache Synapse JBoss ESB MassTransit NetKernel NServiceBus Rhino Service Bus Petals ESB Spring Integration Open ESB WSO2 ESB Mule UltraESB Talend ESB Shuttle Service Bus Red Hat Fuse ESB (based on Apache ServiceMix)

22 Połączenie obu światów