Cześć
Zdarza się, że ttrzeba zintegrować ze sobą różne systemy za pomocą np. web-service, magistrali serwisowej czy magistrali danych. Od czego zależy sposób integracji między systemami? Jakie czynniki mają wpływ na to, że wybiera się taki a nie inny sposób integracji?
PS. Jeżeli wątek nie pasuje do tego działu to proszę o przeniesienie do właściwego.
Udanego weekendu
nie jestem fachowcem w tym temacie, ale może zostać wykorzystany np. JBoss
Mam doświadczenie głównie w integracji przez esb (IBM IB, SAP PI) i webserwisy z wykorzystaniem SOAP w dużej korporacji, ale powiedziałbym że wybór sposobu integracji zależy głównie od liczby integrowanych systemów i rozkładu siatki interfejsów pomiędzy nimi, ilości przesyłanych danych, spodziewanej zmienności tego wszystkiego w czasie, wymagań co do niezawodności, monitoringu... Pewnie duże znaczenie ma rodzaj organizacji (stabilna korporacja?, startup?).
Dużo też zależy od samych systemów: jakie udostępniają interfejsy, czy w ogóle? Jaki jest cel tej integracji?
Chodzi mi głownie o wytyczne teoretyczne służące co sposobu integracji. Jakie czynniki przemawiają na tym, że integracje robię z wykorzystaniem web-service a jakie za tym, że integracje robi się z wykorzystaniem magistrali danych czy ESB.
Pytanie wydaje mi się trochę źle sformułowane, ponieważ ESB i webserwisy to nie są alternatywne opcje. Webserwisy (SOAP albo REST) mogą być używane z ESB, który jest takim hubem integracyjnym dostarczającym Tobie techniczną infrastrukturę i narzędzia (do implementacji architektury SOA). Może bardziej chodzi Ci o to, kiedy stosować ESB a kiedy nie?
Nie wiem dlaczego przedmówcy nadają z roku 2011... ale co do ESB, Jboss itp. to proponuje zajrzeć na strony Technology Radar.
https://www.thoughtworks.com/radar/tools/esb
To wszytko echa starych czasów EJB i technologii Enterprise. Dziś miejsce tego jest na śmietniku raczej.
Całe pytanie jest w stylu - jak programować... ? Nie ma prostej odpowiedzi.
Ale żeby jakoś Cie nakierować to:
Trzeba to dopasować do wymagań - servisy rest/json sa względnie najprostsze w użyciu, ale nie sprawdzają się jak masz bardzo duże dane do przesłania. Średnio też wychodzi komunikacja asynchroniczna :-)
Po prostu zapoznaj się z różnymi rozwiązaniami (w okolicy Javy to np.: Kafka, RabbitMQ, gRPC, Protobuf, Json streaming, HTTP/Rest z load balancerami etc. i staraj się wybierać w zależności od potrzeb.
Nie warto zawsze iść najbardziej wydajne czy eventowe rozwiązania... bo to kosztuje i komplikuje.
W moich okolicach najczęściej kończę z HTTP/JSon do komunikacji synchronicznej i jakimś cudem do komunikacji asynchronicznej (ze wzgledów poje....ch - zwykle jest to własna / korporacyjna Kafka dużo gorsza w użyciu od oryginału i mniej wydajna (za to jacyś architekci mieli dużo zabawy kodując).
JSON Streaming i WebSockety na bardzo specyficzne przypadki. (jak sam sobie koduje dla zabawy - to używam tego dużo częściej).
W praktyce, najczęściej jestem zależny od zastanej w firmie infrastruktury, jak jest tam tylko SOAP i XML to nic nie poradzę i trzaskam te XMLe po sieci.
Integracje w stylu JavaEE (JMS, ESB, EJB) to już raczej smród przeszłości. Wychodzą z tego słabe monolity. (nie wszystkie monolity są złe, ale te oparte o JavaEE często kończą jako kula błota. ).