Suggerimenti per la connessione della GUI .NET WPF con Java SE Server

Per dare una scelta diversa, prova un protocollo non connesso ma bidirezionale come una coda di messaggi (di cui la mia preferenza sarebbe ZeroMQ ) in cui è possibile trasferire le modifiche al client e, se il client si disconnette, le otterrà al successivo collegamento e sarà possibile inviare gli aggiornamenti a tutti i client connessi con estrema facilità. (esistono numerosi scenari di topologia che è possibile supportare con un'architettura di passaggio dei messaggi).

Ti preoccuperai se molti client chiedono il polling del server per gli aggiornamenti, quindi se stai cercando di avere più client, è meglio pensarlo fin dall'inizio.

Ho fatto due progetti rilevanti (per questa domanda). Il primo utilizza SOAP, un server Java e un client .NET. Il secondo utilizza REST, ma entrambi, client e server, sono scritti in Java.

I tuoi pro e contro sembrano validi per me. Personalmente mi piacciono di più i messaggi in stile REST. Il motivo principale per questo è che è molto leggero (in azione e sviluppo), ciò che hai già indicato. I cambiamenti nel livello del messaggio devono essere fatti a mano, ma nei miei progetti non è stato un grosso problema. Inoltre, se consideri di consentire l'utilizzo del tuo Webservice da altri client, REST potrebbe essere la scelta migliore, perché non ho mai avuto problemi in nessuna lingua che ho usato con REST, con SOAP è sempre stato, siamo estenuanti.

Ma se senti che ci saranno molti cambiamenti, potresti dargli un altro peso. Quindi, secondo questo articolo, puoi far funzionare SOAP senza J2EE.

Spero che ti aiuti.

Ho confrontato REST + JSON per l'interscambio di dati tra client .NET e server Java rispetto all'approccio client / server SOAP tradizionale. In entrambi i casi, l'app del server Java è in esecuzione come processo autonomo e non all'interno del contenitore J2EE.

Per client .NET, ho provato RestSharp per inviare le richieste REST e gestire le risposte. Ho trovato RestSharp come soluzione elegante, facile e leggera. Sul lato server Java, ho provato Restlet , che era anche abbastanza facile da configurare, e ho anche testato Gson per serializzare e deserializzare oggetti. Dopo un po 'di confusione con Restlet, sono stato in grado di testare la serializzazione di oggetti .NET su JSON e la ricezione con il server Java. (Ho trovato che la documentazione e il modello a oggetti di Restlet sono confusi, specialmente in confronto a RestSharp. Questo è anche il motivo per cui ho finito per usare Gson per serializzare / deserializzare).

Lo svantaggio significativo che ho trovato (ma non l'unico), è che la deserializzazione di Gson fa distinzione tra maiuscole e minuscole (come immagino probabilmente la maggior parte se non tutte le librerie Json sono), e c'era una discrepanza tra il Lato .NET e lato Java. (Per inciso, penso che chiunque abbia deciso che i nomi di variabili / proprietà debbano essere sensibili alle maiuscole e minuscole ha introdotto una complessità non necessaria nell'interoperabilità. Sarebbe molto meglio se tutto il testo corrispondente non fosse case-insensitive di default, ma configurabile globalmente case-sensitive. Penso che sarebbe molto più utile.)

Ho quindi confrontato questo aspetto con SOAP WS, utilizzando VS 2010 per generare le classi proxy e jSoapServer per l'esecuzione su Java lato. Era operativo e funzionante con un sacco di operazioni in pochi minuti (solo 1 problema secondario per far funzionare i prototipi).

Devo dire che, per la semplicità con questo set di strumenti (VS 2010 ed Eclipse) e un insieme di componenti (.NET WPF e Java), il SOAP Web Service vince a mani basse. È molto più semplice gestire l'accoppiamento tra server e client con la generazione di client di servizi Web WSDL e .NET, rispetto a JSON (e REST). Mentre posso vedere gli enormi vantaggi di JSON + REST per Ajax e le app web (dove non hai il framework SOAP facilmente integrato), per una rapida modalità di sviluppo, SOAP era la strada da percorrere in questo caso.

Aggiorna

Qualcuno su StackOverflow mi ha indicato un'impostazione Gson per specificare la politica di denominazione dei campi. Questo risolve il problema tra le differenze tra il client e l'involucro del server dei nomi. Tuttavia, sembra ancora che SOAP offra uno sviluppo più rapido di nuovi metodi e aggiornamenti agli oggetti tra GUI e server (sebbene io possa rivedere le opinioni in futuro).

Aggiorna

Alla fine, ho selezionato Apache CXF, che funziona incredibilmente bene. La configurazione del servizio in Java è stata semplicissima e Visual Studio ha generato tutte le classi di servizio e il client di servizi Web senza intoppi. Qualsiasi modifica all'interfaccia del server viene facilmente propagata alla GUI mediante l'aggiornamento da parte di VS del riferimento del servizio. Questa è risultata la soluzione RAD appropriata per noi, dato il nostro set di strumenti.