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:
- Realizuj rzeczywiste transakcje za pomocą WS-Atomic Transaction lub podobnego
- 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ą?