Perché utilizzare SOAP su JSON e formato dati personalizzato in un'applicazione "ENTERPRISE"?

Question

Lavoro in un'azienda finanziaria di medie dimensioni in cui tutte le nostre applicazioni comunicano tra loro tramite SOAP e utilizziamo solo JSON per richieste AJAX da siti Web.

Recentemente in una nuova sessione di pianificazione del progetto, qualcuno mi ha chiesto perché dobbiamo utilizzare SOAP per la comunicazione tra le applicazioni? Perché non utilizzare JSON o anche formati di dati personalizzati? Nel mio cuore ho sentito che queste alternative non erano "pronte per l'impresa", ma in realtà non potevo pensare a una risposta molto convincente sul perché sono cattive.

Gli unici due vantaggi di SOAP I possono essere gli strumenti e la sicurezza.

Gli IDE moderni come Visual Studio dispongono di un'utilità incorporata per generare classi dalle definizioni WSDL, che non si ottengono se si utilizza JSON o il formato dati personalizzato. In termini di sicurezza, SOAP ha standard di sicurezza ben definiti che non sono disponibili in altri standard di formato dati.

Cosa ne pensi? usi JSON come formato di scambio dati tra le applicazioni?

Answer 1

IMHO, c'è una grande ragione per cui tutti si attaccano a SOAP invece di usare JSON. Con ogni impostazione JSON, ti viene sempre in mente la tua struttura dati per ogni progetto. Non intendo come i dati vengono codificati e passati, ma come viene definito il formato dei dati, il modello dei dati.

SOAP ha un modo industriale maturo per specificare che i dati saranno nel modulo. Il carrello è una raccolta di prodotti e ogni prodotto può avere questi attributi, ecc. Un documento WSDL ben congegnato ha davvero questo problema. Diamine, è una specifica W3C.

JSON ha metodi simili per specificare questa struttura di dati. Una classe JavaScript viene in mente come il modo più comune per farlo.Una classe JavaScript non è in realtà una struttura di dati in alcun modo agnostico, ben consolidato e ampiamente utilizzato. Heck, JavaScript funziona solo in un ambiente, il browser.

In breve, SOAP è un modo per specificare la struttura dei dati in un documento formattato in modo scaduto (WSDL). JSON no.

UPDATE: Devo dire che sono stupito dal numero di voti negativi che questa risposta ha ottenuto nel corso degli anni, data la sua precisione al momento. Non intendo odiare JSON, ma dopo il reading a recent article, continuo a mantenere i miei punti precedenti. Nel frattempo, JSON-RPC sembra essere praticamente abbandonato da una prospettiva di formato standardizzata (versione 2.0 una proposta del 2010) e nessun altro protocollo JSON apparentemente vicino al livello di standardizzazione di SOAP. (Personalmente, questo non mi ha impedito di abbracciare JSON-RPC 2.0 negli ambienti di produzione. Non lo userò mai in una proposta a un'azienda Fortune 500.)

Per essere chiari, da una prospettiva di uso interno, JSON è grande. Leggero. Veloce. Ampiamente usato. Ragionevolmente leggibile dall'uomo. Ma per l'impresa, dove più flussi di dati vengono spesso uniti. E la specifica del formato dei dati tra dozzine di dipartimenti è necessaria. XML è il leader stabilito.

Answer 2

Il motivo per JSON è la semplicità. È facile da leggere, facile da capire, ha poco overhead e ha implementazioni in quasi tutte le lingue.

Per chiamare qualcosa di "impresa" in grado è un po 'pazzo, IMHO. È solo un formato di scambio di dati. Che si tratti di SOAP, XML, JSON, qualunque sia, è solo un formato di comunicazione.

Gli utensili sono buoni, lo ammetto; le classi generate automaticamente sono fantastiche. D'altro canto, quando gestisci le lezioni a mano, ottieni un vantaggio di quantità e, in generale, non è così difficile.

La sicurezza non è un problema nella mia mente. Il tuo formato dati dovrebbe avere (di nuovo, IMHO) nulla a che fare con la tua sicurezza. Questo deve essere completamente diverso. Mentre SOAP ha alcune estensioni di sicurezza, ecc., Penso che per la maggior parte, forniscono solo molta complessità inutile. Hai mai provato a leggere alcune delle specifiche per WS-Security? Yikes. Che ne dici di usare semplicemente JSON + HTTPS - facile, tutti lo supportano e funziona come un campione ....

Ora, questo non vuol dire che sia la soluzione giusta per ogni problema, ma se stai solo cercando scambio di dati, sono venduto.

Personalmente, adoro JSON come formato e lo uso sempre.

Answer 3

JSON richiede un maggiore sforzo di SOAP XML, ma in genere produce pacchetti molto più piccoli ed è quindi più scalabile. È anche (secondo la mia opinione soggettiva) molto più facile da leggere, mentre eseguo il debugging, annusando il filo, ecc.

Answer 4

Uno dei motivi principali ha nulla da fare per motivi tecnici.

Un sacco di sistemi "enterprise" vengono venduti a grandi clienti "enterprise". Il cliente richiede SOAP e questo è quello che ottengono.

Quali sono le loro ragioni? A volte è molto pragmatico: il loro team ha familiarità con SOAP e hanno molti servizi SOAP esistenti (e questo team manterrebbe il prodotto dopo la consegna). A volte non lo è: lo leggono in qualche articolo e hanno le loro menti inventate.

Answer 5

Non userò SOAP se i dati non sono grandi o la loro struttura è complessa. JSON, AJAX, PHP o anche il REST stanno andando bene.

Answer 6

Sto utilizzando SOAP per comunicare da un JavaEE (Jboss Ejb 3.1 @WebService) Backend a MS C# Winforms.

Forse in futuro ci sarà SOAP (versione X) che utilizzerà il JSON compresso come formato di scambio dati che lo renderà veloce e ideale.

1. Riposo fa bene allo scambio di dati semplice;
2. Ideale per la richiesta Ajax javascript in una pagina Web interattiva.