Architettura callback del servizio Web SOAP?

Question

Sono abbastanza nuovo ai servizi Web, JAX-WS ecc. Quindi forse domanda noob ...

Quindi, voglio implementare un servizio Web per far comunicare due sistemi. Il sistema "client" è interessato agli eventi generati sul sistema "server". Ma il "sistema client" è di per sé un server per un'altra app. Il server è Java (WAR in tomcat). Il cliente è .Net.

Ci dovrebbe essere un solo sistema client, ma diversi processi client all'interno del sistema client, ciascuno interessato a distinte categorie di eventi.

Implementerò il server-side e un client di test. Qualcun altro implementerà il codice .Net.

La sequenza in esecuzione dovrebbe essere lungo questa linea:

1. Server è in esecuzione ...
2. client inizia la conversazione, "registri" al server, e richiede alcuni dati iniziali.
3. Il server mantiene un elenco degli endpoint dei client registrati
4. Nel server è presente un listener che viene avvisato quando si verificano determinati eventi. Passerà quindi attraverso l'elenco dei clienti registrati e inoltrerà l'evento a ciascuno di essi
5. Ad un certo punto, il client può "annullare la registrazione" senza notificare al server che non desidera più ricevere eventi.

In primo luogo, sembra qualcosa di ragionevole?

E c'è un meccanismo integrato standard, che utilizza SOAP (JAX-WS sul server, qualsiasi cosa sia disponibile con .Net n il client) - che il server può utilizzare per ottenere un endpoint di callback dal client?

Ad esempio, ho fatto qualcosa di molto simile usando RMI, in questo caso il client può semplicemente inviare un riferimento remoto a se stesso, che il server può solo memorizzare e fare riferimento a più tardi.

Infine, esiste una libreria standard per archiviare riferimenti di endpoint, effettuare callback (collettivi) e magari mantenere aggiornato l'elenco, rimuovendo i client che non rispondono in modo tale da eseguire una chiamata "ping"?

Nota per chiarezza: ho bisogno di qualcosa di più del semplice metodo asincrono con callback: un messaggio dal client genererà molti messaggi di callback dal server al client.

Answer 1

Sembra che si desideri implementare una funzione di notifica per informare i client anonimi arbitrari.

Ti suggerisco innanzitutto di considerare come passare le informazioni utilizzando i messaggi SOAP. Quindi puoi considerare come ottenere ciò usando java-JAX-WS o librerie aggiuntive non standard. Il punto è che potrebbero esserci limitazioni o presupposti significativi per trasferire i messaggi SOAP. Per esempio. i firewall potrebbero bloccare i messaggi HTTP, i client potrebbero "solo client" senza possibilità di agire in un ruolo server per ricevere richieste di notifica SOAP

Nota: un meccanismo di callback asincrono è definito in JAX-WS 2.0, dove il servizio ottiene il riferimento endpoint del client. Questo è lo stesso tipo di funzionalità fornita dalla soluzione proprietaria di WebLogic/Fusion descritta da Deepak Bala. Websphere ha una soluzione asincrona proprietaria simile. Nessuno di questi soddisfa i tuoi requisiti, perché consentono solo una risposta singola per richiesta.

Opzioni SOAP:

1. proprietari messaggi SOAP - "100% Do-It-Yourself opzione"

   a progettare gli schemi di carico utile pieno SOAP e modello di scambio di messaggi.

   È possibile inoltrare la notifica dal server al client se si conosce l'indirizzo dell'endpoint SOAP del client. Il client può trasferire l'indirizzo dell'endpoint SOAP nel payload della richiesta SOAP originale. Qualche tempo dopo il server può inviare una richiesta SOAP al client.

   Problemi/Presupposti: (1) richiede un percorso di comunicazione SOAP/HTTP per le richieste da server a client - non garantito quando esistono firewall; (2) il client deve essere consapevole del proprio schema di notifica - in effetti il ​​client deve agire come endpoint del servizio per ricevere la richiesta di notifica SOAP. Ecco due grandi presupposti se stai cercando di supportare client anonimi arbitrari - non è qualcosa SOAP "supporta solo" entrambe le parti devono progettare tutto questo in dettaglio. In effetti, per farlo in un modo typesafe di servizio, il client dovrebbe dichiarare la propria interfaccia WSDL del proprio servizio in modo da poterlo invocare. (3) Come accennato in precedenza, molti client sono "solo client" - potrebbero non avere un server HTTP per accettare richieste SOAP.

   Quindi, per far funzionare le notifiche "push" proprietarie, entrambe le parti hanno bisogno di server ed entrambi hanno bisogno di pubblicare le loro interfacce SOA.

   In alternativa, è possibile inviare la notifica al client. Il client può utilizzare una richiesta di notifica al server che blocca o esegue il polling. Il server può rispondere con la notifica o nulla o errore.

   Problemi/Presupposti: (1) I server HTTP (ad esempio il server SOAP) non supportano le richieste di blocco, di norma, il che significa che è necessario il polling; (2) il client deve essere consapevole del proprio schema di notifica - in effetti il ​​client deve agire come endpoint del servizio per ricevere la richiesta di notifica SOAP. Sono due assunzioni molto grandi per un cliente anonimo arbitrario - non è qualcosa SOAP "supporta solo" entrambe le parti hanno bisogno di progettare tutto questo in dettaglio.In effetti, per farlo in un modo typesafe di servizio, il client dovrebbe dichiarare la propria interfaccia WSDL del proprio servizio in modo da poterlo invocare.

2. Come sopra, ma includere i dati di indirizzamento WS nelle intestazioni SOAP per informare entrambi i lati dell'indirizzo dell'endpoint dell'altro.

   Fondamentalmente gli stessi Problemi/Presupposti come prima opzione. Gli indirizzi di indirizzamento WS ti aiuteranno a indirizzare in modo intelligente i messaggi SOAP all'indirizzo URL corretto, ma non di più.

3. Usare WS-Notification

   Questa spec è stato progettato per lo scenario.
   Il sub-standard di notifica WS-Base soddisferà le vostre esigenze. Fornisce le definizioni delle porte WSDL per produttori e consumatori di notifiche. Fornisce una soluzione conforme agli standard WS per la sottoscrizione da un consumatore a un produttore e una notifica dai produttori ai consumatori.

   Problemi/Limitazioni: (1) NON definisce il formato dei payload delle notifiche. Il carico utile di notifica è specifico per il dominio dell'applicazione (design proprietario). Lo standard non definisce alcuna notifica o messaggio di notifica "standard" o "incorporato". (2) Ha gli stessi problemi con le notifiche HTTP che passano attraverso i firewall come menzionato sopra. (3) WS-Notification non è uno standard supportato di Java EE/JAX-WS (ma ci sono un sacco di app server, open source e commerciali, che lo supportano come un'estensione).

4. Utilizzare una soluzione di accodamento messaggi (ad esempio JMS) con traffico incapsulato in HTTP Ciò richiede la progettazione proprietaria di payload che passano tra client e server e contratti di back-forming tra le due parti. Un vantaggio è che il client può essere un puro client, con un listener di messaggi invocato in un thread quando viene ricevuto un messaggio.

   Problemi/Limitazioni: (1) Ha gli stessi problemi con le notifiche HTTP che passano attraverso i firewall come menzionato sopra. (2) È un'implementazione fai-da-te. (3) Usa più tecnologia di quella che usi attualmente.

Risultato finale:
Hai bisogno di almeno parte della soluzione per essere un design proprietario - gli standard SOAP/WS non soddisfano le vostre esigenze completi. In teoria questo design proprietario potrebbe sfruttare un prodotto per fornire gran parte del legwork, MA il design dello schema di notifica dovrebbe essere creato e integrato da te.

Se si desidera le notifiche push, è necessario alcuni sorta di contratto per le notifiche che passano al cliente, il cliente ha bisogno di agire come un server di SOA, ed è necessario il firewall openned per il traffico. La maggior parte delle aziende non accetta le richieste HTTP che lasciano un server e passa a un client - normalmente si ha bisogno di un ottimo motivo per aprire le porte del firewall e anche allora molte aziende lo impediranno ...

SE si desidera che i client eseguano il polling per le notifiche , è sufficiente una semplice interfaccia WSDL sul lato server che possa essere chiamata frequentemente dai client.

Opzione futura: socket Web HTML5
Se il client è un'app HTML5, i server abilitati ai socket Web possono spingere il traffico verso il browser e ci sono alcune possibilità che le società aprano i firewall. I messaggi SOAP potrebbero viaggiare su socket Web HTTP, consentendo di inviare notifiche.

Answer 2

I client asincroni sono supportati per servizi basati su WSDL mediante l'utilizzo di polling and callbacks. Nel tuo caso, penso che il requisito sia relativamente più complicato.

Il middleware Fusion Fusion doc page ha uno scenario delineato che ti aiuterà. Descrive dettagliatamente un metodo che consente ai client di inviare richieste che generano un HTTP 202 (accettato) e quindi i client attendono una risposta sulle code dei messaggi. Nel tuo caso lo scenario può essere ottimizzato da quello mostrato di seguito.

Iniziato diverse code di risposta per ogni categoria di callback. I client possono filtrarli fornendo un ID cliente e categoria per la coda. Questo fungerà da meccanismo di callback per ciascun client o i processi che sono governati da ciascun client.L'MDB può essere supportato da un archivio di file o da un archivio DB per garantire l'affidabilità e la consegna una tantum.

Ovviamente non è necessario Oracle fusionware per implementare questo. È possibile utilizzare RabbitMQ o Redis (con transazioni) per confermare la ricezione di un messaggio sul client. Se il cliente desidera annullare la registrazione, effettua una chiamata e interrompe l'ascolto della coda.

Non sono a conoscenza di qualsiasi standard di settore che si adatti al tuo scenario, ma credo che questa soluzione dovrebbe funzionare bene per te.

Answer 3

Avete considerato l'approccio più semplice di "pub-sub" utilizzando un prodotto di messaggistica? (come MQ, EMS o ActiveMQ)

I requisiti che descrivi non sembrano adattarsi agli scenari di servizio Web SOAP richiesta/risposta sincro/asincrono "classico".

In una soluzione Pub/Sub, i client si iscrivono a un argomento una sola volta e gli editori (nel tuo caso, il server) possono inviare qualsiasi numero di messaggi rilevanti a tutti gli abbonati.

Come bonus, la maggior parte dei prodotti di messaggistica include il supporto per "abbonati durevoli", quindi il client può essere off-line a volte e ricevere tutti i messaggi dopo la riconnessione.

Nel tuo caso, il server può ospitare un server ActiveMQ (gratuito) ... Fornendo la maggior parte delle funzionalità che sembra cercare.

Se si va in questo modo, suggerisco di scegliere un prodotto compatibile con JMS con supporto per .Net.

Answer 4

Per coloro arrivare qui da motori di ricerca:

È possibile utilizzare un WebHook per le API web al giorno d'oggi, che funziona essenzialmente come descritto OP.

In REST, ad esempio, il client avrà un endpoint HTTP stesso dedicato alla ricezione di eventi/notifiche POST dal server effettivo. Il client registra il proprio endpoint con il server effettivo assegnandogli un URI sul proprio endpoint di notifica. Da quel momento in poi, il server effettivo può eseguire il POST sull'endpoint di notifica del client. È essenzialmente un callback complesso, se si ha familiarità con la terminologia asincrona.

Forse Java o .Net dispongono di librerie per WebHooks ormai.

Detto questo, gli standard SSE e Websockets forniscono messaggi push e in tempo reale mentre sono compatibili con HTTP e la maggior parte dei browser.

In passato venivano utilizzate anche lunghe variazioni di polling e ora vengono talvolta denominate Comet come aggregato.