Architektura wywołania zwrotnego usługi SOAP w sieci Web?

Question

Jestem całkiem nowy w usługach internetowych, JAX-WS itp., Więc może noob pytanie ...

Tak więc, chcę wdrożyć serwis internetowy, aby komunikować się dwa systemy. System "klient" jest zainteresowany zdarzeniami generowanymi w systemie "serwerowym". Ale "system klienta" sam jest serwerem dla innej aplikacji. Serwer to Java (WAR w tomcat). Klientem jest .Net.

Powinien istnieć tylko jeden system klienta, ale kilka procesów klienta w systemie klienta, każdy zainteresowany różnymi kategoriami zdarzeń.

Zaimplementuję klienta po stronie serwera i klienta testowego. Ktoś inny zaimplementuje kod .Net.

Bieg sekwencja powinna być wzdłuż tej linii:

1. Server jest uruchomiony ...
2. Klient inicjuje rozmowę, „rejestry” do serwera i zapytania pewne wstępne dane.
3. Serwer przechowuje listę punktów końcowych zarejestrowanych klientów.
4. Na serwerze znajduje się detektor, który jest powiadamiany o wystąpieniu określonych zdarzeń. Następnie przejdzie listę zarejestrowanych klientów i przekaże je każdemu z nich.
5. W pewnym momencie klient może "wyrejestrować", nie powiadamia serwera, że ​​nie chce już otrzymywać wydarzeń.

Po pierwsze, czy brzmi to jak racjonalnie wykonalne?

Czy istnieje standardowy wbudowany mechanizm, używając SOAP (JAX-WS na serwerze, cokolwiek jest dostępne z .Net n klientem) - który serwer może wykorzystać do uzyskania punktu końcowego oddzwaniania od klienta?

Na przykład zrobiłem coś bardzo podobnego za pomocą RMI, w tym przypadku klient może wysłać do siebie zdalne odwołanie, które serwer może po prostu przechowywać i odnieść się do niego później.

Wreszcie, czy istnieje standardowa biblioteka do przechowywania odniesień do punktów końcowych, tworzenia (zbiorowych) wywołań zwrotnych i być może aktualizacja jest aktualna, usuwając klientów, którzy nie odpowiadają, aby wywołać "ping"?

Uwaga dla przejrzystości: potrzebuję czegoś więcej niż tylko metody asynchronicznej z funkcją zwrotną: jedna wiadomość od klienta wygeneruje wiele komunikatów oddzwonienia z serwera do klienta.

Answer 1

Wygląda na to, że chcesz zaimplementować funkcję powiadamiania, aby poinformować dowolnych anonimowych klientów.

Proponuję najpierw rozważyć, w jaki sposób przekazać informacje za pomocą wiadomości SOAP. Następnie możesz rozważyć, jak to osiągnąć, używając java - JAX-WS lub dodatkowych niestandardowych bibliotek. Chodzi o to, że mogą istnieć istotne ograniczenia lub założenia wymagane do przesyłania komunikatów SOAP. Na przykład. ściany ogniowe mogą blokować twoje wiadomości HTTP, klienci mogą być "tylko klientami" bez możliwości działania w roli serwera, aby otrzymywać żądania powiadomienia SOAP.

Uwaga: Mechanizm zwrotny asynchroniczny jest zdefiniowany w JAX-WS 2.0, gdzie usługa uzyskuje odniesienie do punktu końcowego klienta. Jest to ten sam rodzaj funkcjonalności zapewniany przez autorskie rozwiązanie WebLogic/Fusion opisane przez Deepak Bala. Websphere ma podobne autorskie rozwiązanie async. Żadne z nich nie spełnia Twoich wymagań, ponieważ dopuszczają tylko jedną odpowiedź na każde żądanie.

SOAP Opcje:

1. Proprietary komunikatów SOAP - "100% Do-It-Yourself opcję"

   zaprojektować pełen SOAP schematów ładowność i wzorzec wymiany wiadomości.

   Możesz przekazać powiadomienie z serwera do klienta, jeśli znasz adres punktu końcowego SOAP klienta. Klient może przesłać swój adres punktu końcowego SOAP w oryginalnym ładunku żądania SOAP. Jakiś czas później serwer może wysłać żądanie SOAP do klienta.

   Problemy/Założenia: (1) potrzebujemy ścieżki komunikacji SOAP/HTTP dla żądań z serwera do klienta - nie gwarantujemy, że istnieją firewalle; (2) klient musi znać schemat powiadamiania - w rzeczywistości klient musi działać jako punkt końcowy usługi, aby otrzymać żądanie powiadomienia SOAP. To dwa duże założenia, jeśli próbujesz obsługiwać arbitralnych anonimowych klientów - to nie jest coś, co SOAP "tylko wspiera", oba cele muszą to wszystko szczegółowo zaprojektować. W rzeczywistości, aby to zrobić w sposób bezpieczny dla usług, klient powinien faktycznie zadeklarować własny interfejs WSDL usługi, aby móc go wywołać. (3) Jak wspomniano wcześniej, wielu klientów to "po prostu klienci" - mogą nie mieć serwera HTTP, który akceptowałby żądania SOAP.

   Tak więc w przypadku zastrzeżonych powiadomień "wypychanych" do pracy obie strony potrzebują serwerów i oba muszą opublikować swoje interfejsy SOA.

   Alternatywnie możesz wyciągnąć powiadomienie do klienta. Klient może użyć żądania powiadomienia do serwera, który blokuje lub odpytuje. Serwer może odpowiedzieć powiadomieniem lub nic lub błąd.

   Problemy/Założenia: (1) Serwery HTTP (tj. Serwer SOAP) nie obsługują żądań blokowania, co oznacza, że ​​należy sondować; (2) klient musi znać schemat powiadamiania - w rzeczywistości klient musi działać jako punkt końcowy usługi, aby otrzymać żądanie powiadomienia SOAP. To dwa bardzo duże założenia dla arbitralnego anonimowego klienta - to nie jest coś, co SOAP "tylko wspiera", oba końce muszą zaprojektować to wszystko w szczegółach.W rzeczywistości, aby to zrobić w sposób bezpieczny dla usług, klient powinien faktycznie zadeklarować własny interfejs WSDL usługi, aby móc go wywołać.

2. To samo, co powyżej, ale uwzględnij dane adresowania WS w nagłówkach SOAP, aby poinformować jedną ze stron adresu punktu końcowego drugiej strony.

   Zasadniczo te same problemy/założenia co pierwsza opcja. Adresy adresowania WS pomogą ci inteligentnie skierować wiadomości SOAP na właściwy adres URL, ale nie więcej.

3. Użyj WS-notification

   Ta specyfikacja została zaprojektowana dla scenariusza.
   Sub-norma WS-BaseNotification zaspokoi Twoje potrzeby. Zapewnia definicje portów WSDL dla producentów powiadomień i konsumentów. Dostarcza rozwiązania zgodne ze standardami WS- w zakresie subskrypcji od konsumenta do producenta i powiadomienia od producentów do konsumentów.

   Problemy/Ograniczenia: (1) NIE określa formatu powiadomień. Ładunek powiadomień jest specyficzny dla aplikacji (zastrzeżony projekt). Standard nie definiuje żadnych "standardowych" ani "wbudowanych" sytuacji lub komunikatów powiadomień. (2) Ma takie same problemy z powiadomieniami HTTP przechodzącymi przez zapory ogniowe, jak wspomniano powyżej. (3) WS-Notification nie jest obsługiwanym standardem Java EE/JAX-WS (ale jest wiele serwerów aplikacji, open source i komercyjnych, które obsługują to jako rozszerzenie).

4. Użyj rozwiązania kolejkowania komunikatów (np. JMS) z ruchem zamkniętym w HTTP Wymaga to własnościowego projektu ładunków przekazywanych między klientem a serwerem oraz zawarcia umów zwrotnych między obiema stronami. Zaletą jest to, że klient może być czystym klientem, z detektorem komunikatów wywołanym w wątku po otrzymaniu wiadomości.

   Problemy/Ograniczenia: (1) Ma takie same problemy z powiadomieniami HTTP przechodzącymi przez zapory, jak wspomniano powyżej. (2) Jest to wdrożenie typu "zrób to sam". (3) Korzysta z większej liczby technologii niż obecnie.

Wynik końcowy:
Trzeba przynajmniej część rozwiązania być zastrzeżona konstrukcja - standardy SOAP/WS nie spełniają wszystkich wymagań. Teoretycznie ten zastrzeżony projekt mógłby wykorzystać produkt, aby zapewnić wiele legen- dury, ALE projekt schematu powiadamiania musiałby zostać stworzony i zintegrowany przez ciebie.

JEŚLI chcesz przesyłać powiadomienia, potrzebujesz pewnego rodzaju umowy dotyczącej powiadomień przekazywanych klientowi, klient musi działać jako serwer SOA i potrzebujesz zapór ogniowych otwartych dla ruchu. Większość firm nie akceptuje żądań HTTP opuszczających serwer i przekazujących je klientowi - zwykle potrzebny jest bardzo dobry powód, aby otwierać porty zaporowe, a nawet wtedy wiele firm nie będzie go akceptować ...

JEŚLI chcesz, aby klienci sondowali się w poszukiwaniu powiadomień potrzebujesz prostego interfejsu WSDL po stronie serwera, który może być często wywoływany przez klientów.

Future Opcja: HTML5 Web Sockets
Jeśli klient jest aplikacja HTML5, a następnie gniazda sieciowe obsługujące serwery mogą naciskać ruch do przeglądarki - i nie jest pewne korporacje szansa otworzą zapór. Komunikaty SOAP mogą przemieszczać się przez gniazda internetowe HTTP, umożliwiając wysyłanie powiadomień.

Answer 2

Klienci Async są obsługiwani dla usług opartych na WSDL za pomocą polling and callbacks. W twoim przypadku wymóg jest stosunkowo bardziej skomplikowany.

Oprogramowanie warstwy bazowej Oracle fusion doc page ma zarysowany scenariusz, który pomoże. Określa metodę, która umożliwia klientom wysyłanie żądań, które generują HTTP 202 (akceptowane), a klienci następnie oczekują na odpowiedź w kolejkach wiadomości. W twoim przypadku scenariusz można poprawić z tego pokazanego poniżej.

zainicjować kilka kolejek odpowiedzi dla każdej kategorii zwrotnego. Klienci mogą je filtrować, dostarczając klientowi i identyfikator kategorii dla kolejki. Będzie to służyć jako mechanizm zwrotny dla każdego klienta lub procesów, które są zarządzane pod każdym klientem.MDB może być wspierany przez magazyn plików lub sklep DB, aby zapewnić niezawodność i jednorazową dostawę.

Oczywiście nie potrzebujesz oprogramowania fusion firmy Oracle, aby to wdrożyć. Możesz użyć RabbitMQ lub Redis (z transakcjami), aby potwierdzić odbiór wiadomości na kliencie. Jeśli Twój klient chce się wyrejestrować, zadzwoń i przestań słuchać kolejki.

Nie jestem świadomy żadnego standardu branżowego, który będzie pasował do twojego scenariusza, ale wierzę, że to rozwiązanie powinno dobrze działać.

Answer 3

Czy zastanawiałeś się nad prostszym podejściem do "pub-sub" za pomocą produktu do komunikacji? (Takich jak MQ, EMS lub ActiveMQ)

Wymogi, które opisujesz, nie pasują do "klasycznej" synchronizacji żądania/odpowiedzi/asynchronicznych scenariuszy SOAP Web Service.

W przypadku rozwiązania Pub/Sub klient (y) subskrybuje jeden temat raz, a wydawca (w twoim przypadku serwer) może publikować dowolną liczbę istotnych wiadomości dla wszystkich subskrybentów.

Jako bonus, większość produktów do przesyłania wiadomości obejmuje obsługę "stałych subskrybentów", dzięki czemu klient może być czasami offline i otrzymywać wszystkie wiadomości po ponownym połączeniu.

W twoim przypadku serwer może pomieścić (bezpłatny) serwer ActiveMQ ... Zapewniając większość funkcji, których szukasz.

Jeśli pójdziesz tą drogą, sugeruję wybrać produkt zgodny z JMS z obsługą .Net.

Answer 4

Dla tych, dojazd z wyszukiwarek:

Można użyć WebHook dla API internetowych w dzisiejszych czasach, który działa w zasadzie jak opisano OP.

Na przykład w REST klient będzie miał punkt końcowy HTTP, który jest przeznaczony do odbierania zdarzeń POST/powiadomień z rzeczywistego serwera. Klient rejestruje swój punkt końcowy na aktualnym serwerze, podając identyfikator URI na swoim punkcie końcowym powiadomienia. Od tego momentu aktualny serwer może POST do punktu końcowego powiadomienia klienta. Jest to w gruncie rzeczy zawiły zwrotny, jeśli znasz terminologię asynchroniczną.

Być może Java lub .Net ma już biblioteki dla WebHook.

To powiedziane, standardy SSE i Websockets zapewniają rzeczywiste wiadomości push i wiadomości w czasie rzeczywistym, jednocześnie będąc kompatybilnymi z HTTP i większością przeglądarek.

W przeszłości stosowano również długie warianty głosowania, które obecnie nazywa się kometą jako agregatem.