Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Esistono molti modi per gestire l'invio dei messaggi SOAP ricevuti al servizio appropriato. I due meccanismi più semplici sono l'instradamento a livello di trasporto e l'instradamento di indirizzi e azioni.
Invio a livello di trasporto
Con l'invio a livello di trasporto, il server HTTP sottostante ( ad esempio l'API HTTP ) viene usato per gestire il routing delle richieste al dispositivo e ai relativi servizi. Il server fornisce un URL diverso per ogni servizio e per il dispositivo, e diversi "sink" vengono registrati per ciascun URL. In questo modo il codice può essere progettato in modo che ogni servizio sia isolato dall'altro, in esecuzione come componenti separati all'interno dello stesso processo o in esecuzione come processi separati.
L'invio a livello di trasporto presenta alcuni vantaggi. I messaggi possono essere inviati al componente appropriato senza prima analizzare la busta SOAP o il corpo del messaggio. Inoltre, il meccanismo esistente per il routing dei messaggi forniti dalla maggior parte delle implementazioni del server HTTP può essere riutilizzato, il che significa che il codice di invio personalizzato non è necessario. Isola inoltre il codice di elaborazione SOAP tra i servizi, che fornisce un livello di sicurezza, in quanto i servizi sicuri evitano che i messaggi vengano inviati attraverso codice comune.
Indirizzo e invio di azioni
L'indirizzo e l'invio di azioni si basano sulle intestazioni SOAP per determinare il servizio appropriato a cui viene inviato il messaggio. Questo modello può anche usare informazioni aggiuntive, ad esempio parametri di riferimento, per facilitare l'invio.
Questo modello incoraggia il riutilizzo del codice in uno stack di messaggistica a più livelli, poiché tutto il codice fino al processore SOAP è condiviso da tutti i servizi. Inoltre, non sono necessari indirizzi di trasporto distinti per i servizi, il che significa che gli indirizzi UUID possono essere usati per gli endpoint di servizio. L'invio di indirizzi e azioni si traduce anche più direttamente in un modello di programmazione. Gli sviluppatori possono collegare servizi e dispositivi in un singolo componente che gestisce il routing, invece di dover collegare in un livello HTTP o creare componenti separati per ogni servizio.