Protocolli semplici (come Twisted.pb) vs Messaging (AMQP/JMS) vs Web Services (REST/SOAP)

Question

Attualmente sto usando il broker di prospettiva di Twisted su Python e in passato ho considerato il passaggio a qualcosa come RabbitMQ, ma non sono sicuro che possa semplicemente sostituire PB - mi sento come se potessi confrontare le mele con le arance qui. Ultimamente ho letto molto sul riposo e l'inevitabile dibattito con SOAP, che mi ha portato a leggere cose di servizio Web "Enterprisey" come SOA.

Ho un progetto in arrivo in cui dovrò implementare alcune funzionalità simili a ERP su Web e desktop, quindi sto considerando quale approccio/tecnologia utilizzare per comunicare tra server e clienti. Ma sto anche cercando di imparare il più possibile su tutto questo, quindi non voglio solo risolvere questo particolare problema.

Cosa usi per la comunicazione tra server e clienti?

Capisco che un protocollo specifico per Python come il broker prospettico può limitare la mia interoperabilità, ma ho ragione su come presumere che alcuni protocolli AMQP possano sostituirlo?

Se non sbaglio, sia Twisted.pb che AMQP utilizzano una connessione sempre attiva e un protocollo aereo molto basso. Ma da una parte, mantenere sempre un gran numero di clienti connessi potrebbe essere un problema e, d'altra parte, anche con HTTP Keep-alive e qualunque trucco usano la parte di serializzazione sarebbe comunque un problema con i servizi web.

Se sbaglio in uno dei miei presupposti, apprezzerei se qualcuno potesse indicarmi nella giusta direzione per saperne di più.

Answer 1

Come sempre, "dipende". Innanzitutto, chiariamo la terminologia.

Twisted's Broker prospettico Fondamentalmente è un sistema che è possibile utilizzare quando si dispone di controllo su entrambe le estremità di un'azione distribuita (sia client che server). Fornisce un modo per copiare gli oggetti da un'estremità all'altra e per chiamare metodi su oggetti remoti. La copia comporta la serializzazione dell'oggetto in un formato adatto per il trasferimento di rete e quindi il trasferimento utilizzando il protocollo di trasferimento di Twisted. Ciò è utile quando entrambe le estremità possono utilizzare Twisted e non è necessario interfacciarsi con sistemi non t-wisted.

Parlando in generale, Servizi web sono applicazioni client-server che si basano su HTTP per la comunicazione. Il client utilizza HTTP per effettuare una richiesta al server, che restituisce un risultato. I parametri possono essere codificati in EG. Ottieni o pubblica richieste o utilizza una sezione dati in una richiesta post per inviare, ad esempio, un documento di formattazione XML che descrive l'azione da intraprendere.

RIPOSO è l'idea architettonica che tutte le risorse e le operazioni sulle risorse che un sistema espone dovrebbero essere direttamente indirizzabili. Per dirla in qualche modo semplicemente, significa che l'URI utilizzato per accedere o manipolare la risorsa include il nome della risorsa e l'operazione da eseguire su di essa. Il riposo può essere e comunemente è implementato come servizio Web utilizzando HTTP.

SAPONE è un protocollo per lo scambio di messaggi. È costituito da due parti: una scelta di diversi metodi di trasporto e un singolo formato di messaggi basato su XML. Il metodo di trasporto può essere, ad esempio, HTTP, che rende SOAP un candidato per l'implementazione di servizi mercoledì. Il formato del messaggio specifica tutti i dettagli sull'azione richiesta e sul risultato dell'azione.

JMS è uno standard API per i sistemi di messaggistica basati su Java. Definisce alcune semantiche per i messaggi (come uno a uno o uno-a-many) e include metodi per indirizzare, creare messaggi, popolarli con parametri e dati, inviarli e ricevere e decodificarli. L'API si assicura che tu possa, in teoria, cambiare l'implementazione del sistema di messaggistica sottostante senza dover riscrivere tutto il codice. Tuttavia, l'implementazione del sistema di messaggi non deve essere compatibile con il protocollo con un altro sistema di messaggistica abilitato per JMS. Quindi avere un sistema JMS non significa automaticamente che è possibile scambiare messaggi con un altro sistema JMS. Probabilmente devi costruire una sorta di servizio a ponte affinché ciò funzioni, che sarà una grande sfida soprattutto quando si tratta di affrontare.

AMQP I tentativi di migliorare la situazione definendo un protocollo di filo che i sistemi di messaggistica devono obbedire. Ciò significa che i sistemi di messaggistica di diversi fornitori possono scambiare messaggi.

Infine, Soa è un concetto di architettura in cui le applicazioni sono suddivise in servizi riutilizzabili. Questi servizi vengono quindi combinati ("orchestrati") per implementare l'applicazione. Ogni volta che viene presentata una nuova applicazione, c'è la possibilità di riutilizzare i servizi esistenti. La SOA è anche qualcosa che richiede attività di supporto non tecniche in modo che il riutilizzo si verifichi realmente e i servizi sono progettati per essere abbastanza generale. Inoltre, la SOA è un modo per iniziare a impacchettare la funzionalità nei sistemi legacy in un tutto significativo che può quindi essere esteso e sviluppato utilizzando ulteriormente tecniche più moderne. La SOA può essere implementata utilizzando una varietà di tecnologie, come servizi Web, sistemi di messaggistica o un bus di servizio aziendale.

Hai riflettuto sul compromesso tra una connessione per richiesta e mantenendo aperta la connessione per più richieste. Questo dipende dalle risorse disponibili, dal modello di messaggistica e dalle dimensioni dei dati. Se il flusso di messaggi in arrivo è costantemente lo stesso, potrebbe andare bene consentire alle connessioni di rimanere aperte poiché la loro quantità non cambierà molto. D'altra parte, se ci sono esplosioni di messaggi da diversi sistemi, potrebbe essere utile rilasciare risorse e non lasciare che le connessioni indugiano per troppo tempo. Inoltre, se molti dati vengono trasferiti per connessione, il sovraccarico di apertura e chiusura della connessione è ridotto rispetto alla lunghezza totale delle transazioni. D'altra parte, se trasferisci molti messaggi molto piccoli, mantenere aperta la connessione potrebbe rivelarsi utile. Il benchmarking con i tuoi parametri particolari è l'unico modo per essere sicuri.

AMQP potrebbe effettivamente sostituire il protocollo specifico intrecciato. Ciò consentirebbe di interagire con un sistema non totalmente.

Spero che questo si riveli utile per te. Se ti stai ancora chiedendo qualcosa (e penso che lo sia, dal momento che questa è un'area così grande), allora suggerirei di dividere le cose in domande più piccole e di pubblicarle individualmente. Le risposte possono quindi essere più precise.