Czy skład usługi SOA faktycznie działa w praktyce?

Jedną z głównych zasad projektowania usług SOA jest zasada Kompatybilności usług ( https://en.wikipedia.org/wiki/Service_composability_principle ).

Chodzi o to, że komponując nowe usługi wykorzystując istniejące jako elementy składowe, można szybko opracowywać nowe usługi. Podobnie jak w przypadku wywoływania istniejących metod obiektów podczas wdrażania nowych metod. To właśnie stąd ma pochodzić znaczny wzrost wydajności SOA.

Czy ktoś naprawdę robi to w praktyce? Widziałem to w nieskończoność powtarzane w tekście pisanym, ale sam nie doświadczyłem implementacji w świecie rzeczywistym. Większość tekstu pomija również wszelkie wzmianki o obsłudze transakcji , co wydaje mi się największą przeszkodą w realizacji usług składanych.

Po pierwsze, naprawdę musisz rozwiązać problem z transakcjami, zanim będziesz mógł utworzyć dowolne niebanalne usługi. Jasne, jeśli przykład zawiera usługi „findCurrentTime ()” i „writeLogMessage ()”, łatwo jest nie martwić się o transakcje, ale nie w przypadku rzeczywistych przykładów, takich jak „depositMoney ()” i „drawMoney () ”.

Znam dwie opcje:

1. Realizuj rzeczywiste transakcje za pomocą WS-Atomic Transaction lub podobnego
2. Zaimplementuj rozwiązanie oparte na kompensacji, które kompensuje wywołanie do A za pomocą „cancelA ()” lub w inny sposób, jeśli wywołanie do B nie powiedzie się

Oba wydają mi się bardzo problematyczne / prawie nieużyteczne:

• Transakcja atomowa WS
  • wiele komplikacji, najbardziej rada, że znalazłem tylko ostrzega „ból w dupie, dont go”
  • wsparcie jest ograniczone, na przykład jeśli bierzesz ESB typu open source, główne alternatywy ServiceMix, Mule lub WSO2 nie obsługują go
• odszkodowania
  • wdrożenie obsługi rekompensat wydaje mi się bardzo skomplikowane. Co robimy, jeśli usługa A się powiedzie i nigdy nie otrzymamy odpowiedzi z usługi B i nie wiemy, czy się nie udało? Ręczne posługiwanie się taką logiką (jako realizatorem usług kompozytorskich) powoduje, że chcę podciąć sobie nadgarstki - to rodzaj pracy, jaką niektóre narzędzia powinny dla mnie zrobić!
  • Nie rozumiem też, w jaki sposób można uzyskać metody kompensacji w nietrywialnych usługach. Powiedz, że twoja usługa A to „depositMoney ()” i to się powiedzie, niektóre inne działania szybko przenoszą pieniądze w inne miejsce, a następnie otrzymujemy „kompensateDepositMoney ()”, co teraz robimy? Wygląda jak duża puszka robaków.

Wydaje mi się, że skład usługi jest tak fundamentalną zasadą SOA, że tak naprawdę nie zyskujesz korzyści z SOA, jeśli nie możesz (wygodnie) komponować usług . Jaka jest rzeczywistość 90% użytkowników SOA korzysta z „skrupulatnego SOA” bez rzeczywistej kompresji usług? Czy większość użytkowników faktycznie korzysta ze składu usługi, a ja przesadzam z jego trudnością?

Krótka odpowiedź brzmi: tak!

Widziałem to w kilku dużych organizacjach finansowych i działało to dobrze.

Problemy z transakcjami są złożone, ale zwykle są obsługiwane przez (drogie) oprogramowanie pośrednie, takie jak Oracles WebLogic EAI lub IBMs Websphere ESB.

Tak, można sprawić, by działało w praktyce. Jednak może to nie być najlepsze podejście i być może jest używane jako domyślna opcja bardziej niż powinno. Moim zdaniem SOA zyskała popularność jako sposób na integrację starszych systemów, ponieważ organizacje ewoluowały w swoich systemach informatycznych w celu automatyzacji coraz większych zadań. Może być bardzo nieuporządkowany, ale być może warto, jeśli można ponownie wykorzystać starsze systemy. Jeśli masz szczęście, że zaczynasz projekt zielonego pola, przed założeniem, że jest to najlepszy sposób, należy rozważyć inne metody.

Aby odpowiedzieć na niektóre z twoich bardziej szczegółowych obaw ...

Możesz korzystać z transakcji:

1. WS-TX jest PITA i chciałbym jej uniknąć.
2. Wszystkie Twoje usługi mogą działać na jednym serwerze aplikacji, w którym to przypadku możesz rozdzielić je wszystkie za pomocą transakcji XA. Właśnie dlatego wymyślono takie rzeczy jak serwery aplikacji.

Biorąc pod uwagę podejście oparte na rekompensacie:

Działania kompensacyjne należy brać pod uwagę tylko w przypadku awarii. Czy narzędzie do komponowania usług ma flagę, którą może kontrolować, która jest usuwana podczas pierwszego uruchomienia kroku przepływu pracy, ale ustawiana przy kolejnych wywołaniach? Podobnie jak ewentualna flaga ponownego wysłania w JMS. Następnie możesz użyć tak zwanego zatwierdzenia 1,5-fazowego, co w zasadzie oznacza kontynuację, jeśli flaga jest czysta, ale jeśli flaga jest ustawiona, najpierw zadzwoń, aby sprawdzić, czy stan jest już zaktualizowany i musi zostać wykonany po raz drugi . To wciąż wymaga ręcznej obsługi błędów i może być złożone, a nawet niemożliwe, jak zauważyłeś.

W niektórych sytuacjach nie ma znaczenia:

To jest ostatecznie spójne podejście. Załóżmy, że jedna usługa wysyła wiadomość e-mail. Jeśli skład usługi nie powiedzie się i zostanie ponownie uruchomiony, wiadomość e-mail zostanie ponownie wysłana. Jest to nieco denerwujące dla odbiorcy, ale prawdopodobnie zdają sobie sprawę, że jest to duplikat i wszystko może trwać bez większego problemu.

Możesz także przechowywać dziennik wysłanych wiadomości e-mail i użyć go do usunięcia duplikatu, gdy flaga jest ustawiona, i w ten sposób wyślij wiadomość e-mail tylko raz.

Za pomocą komunikatów asynchronicznych można rozdzielić transakcje na mniejsze części:

Rozważ kolejkę JMS, która jest transakcyjna. Twój koordynator usługi może zaktualizować jego stan i wysłać wiadomość do kolejki w jednym Tx. Usługi podrzędne mogą usuwać wiadomości i aktualizować ich stan w jednym Tx. Teraz koordynujesz usługi w wielu jednostkach pracy, ale każda ma charakter atomowy. Jeśli coś zawiedzie i musi zostać ponownie uruchomione, nie ma problemu.

To wciąż oznacza, że ​​robisz transakcje XA na bazie danych i kolejce JMS, ale nadal może to być efektywne przy użyciu ostatniego gambitu zasobów, aby uniknąć pełnego narzutu XA.

Alternatywnie możesz użyć tego wzorca, ale z zatwierdzeniem 1,5 fazy do bazy danych i JMS. LUB możesz uruchomić JMS bez transakcji, ale zwiększyć jego niezawodność przez tworzenie klastrów.

Asynchroniczne przesyłanie wiadomości może również pomóc w rozłączeniu systemów, ponieważ producenci i konsumenci mogą stać się bardziej niezależni od siebie, zmniejszając ilość sprzężenia w całym systemie i czyniąc go bardziej elastycznym. Tego rodzaju oddzielenie płatności jest bardzo istotne w przypadku dużych organizacji posiadających wiele różnorodnych usług.

Nie, to mit. Jest to niewłaściwa intencja przy projektowaniu architektury usług. Istnieje cała masa problemów:

1. Bardzo szczelne połączenie. Jeśli jedna usługa została zmieniona, musisz przetestować cały system.
2. Takie usługi są bardzo szczegółowe, dlatego istnieje wiele komunikacji wewnętrznej.
3. W wyniku drobnoziarnistości istnieje wiele usług. System staje się trudny do zrozumienia, zapytania coraz trudniej śledzić.
4. Usługi encji są źle zamknięte: żadna z reguł biznesowych nie jest tam sprawdzana, logika ta działa w usługach. Tak więc każda usługa może wywołać dowolną usługę encji i zaktualizować jej dane za pomocą zwykłego zapytania aktualizacyjnego, które jest obecne w jego interfejsie. Tego rodzaju usługi encji są często określane jako zorientowane na dane - w przeciwieństwie do usług zorientowanych na proces i zorientowanych na zachowanie.
5. Wrodzony charakter komunikacji między tymi usługami jest synchroniczny. Są więc szanse, że wybrany transport to http. Stąd wszystkie jego wady, o których powiem nieco później.

Istnieje jeszcze więcej niewłaściwych sposobów podejścia do architektury usług . Więc bądź ostrożny.