Java: RMI vs servizi Web

Question

Ho bisogno di creare un'applicazione distribuita composta da più client che inviano file (più informazioni sui file) a un server, anche interrogare quel server.

I client devono accedere a tale server Web dall'interno dell'azienda per l'invio dei file. Tuttavia, occasionalmente alcune query specifiche devono essere eseguite all'esterno dell'azienda.

Penso, dato quello che so, che RMI è un modo più veloce (prestazioni operative) per connettere il client desktop con il motore di indicizzazione più il motore di archiviazione. E credo che anche la creazione di un servizio Web che fornisca un livello di accesso al motore di ricerca sia una buona decisione, poiché verrà eseguita al di fuori della rete aziendale.

Cosa ne pensi? È un buon approccio o hai qualche alternativa da prendere in considerazione.

Grazie in anticipo.

Answer 1

RMI può essere sottoposto a tunnelling su HTTP (vedere here), quindi non lasciare che questo influisca troppo sulla tua decisione.

Se entrambe le estremità possono parlare RMI, quindi RMI è probabilmente quello che si dovrebbe usare; è molto più facile lavorare che un servizio web.

Answer 2

Cosa ti fa pensare che RMI sia più veloce? Dalla mia esperienza, può essere lento, difficile da configurare, difficile da proteggere e generalmente spiacevole con cui lavorare.

Poiché i servizi Web sono generalmente solo XML su HTTP, è generalmente possibile progettare una soluzione che si scalerà meglio.

Answer 3

Se l'API si vuole sostenere con il servizio non mappare bene a HTTP, credo che sceglierò per RMI (ma attenzione di andata e ritorno non necessari.)

In caso contrario la mappa su HTTP bene, avrei scelto per andare con REST che è essenzialmente Servlet HTTP che implementa la tua API come azioni. Se la maggior parte del traffico è il caricamento/scaricamento dei file che hai citato combinato con alcune chiamate API, questa è probabilmente la strada da percorrere.

Btw, la tua esperienza che RMI è più veloce dei servizi web coincide con la mia. (Entrambi possono essere implementati con prestazioni lente come risultato, principalmente con roundtrip in un'API mal progettata).

Answer 4

Fai attenzione qui, ho sviluppato una soluzione simile di recente e ho scoperto che le prese erano il modo più efficiente e perfomant di trasferire file, mentre RMI era buono per le chiamate ai metodi semplici (come le query). Ho anche avuto difficoltà a configurare RMI, la configurazione può essere fonte di confusione a volte e non c'è molta documentazione sul tema.

Credo fermamente che RMI offrirà prestazioni migliori rispetto ai servizi Web; ma i servizi web saranno probabilmente più manutenibili e flessibili per i requisiti futuri.

Answer 5

In ogni caso è un dibattito senza fine. Ecco il mio modesto parere:

• I servizi Web consentono un'architettura accoppiata libera. Con RMI, devi compilare tutto anche se ci sono state modifiche minime (a causa degli UUID seriali di classe e quant'altro).
• WS consentono una coesistenza più semplice con altri componenti aziendali (ESB, SSO, Identity Management, bilanciamento del carico, filtri di sicurezza, certificati di sicurezza) in quanto HTTP è il protocollo di rete sottostante.
• La riflessione in RMI (e in EJB) sembra essere più costosa del protocollo HTTP stesso.

Se state pensando di EJB come più adatto per ambienti server delle applicazioni e easyer da confrontare con WS e CORBA secondo il vostro articolo, (EJB supporta la gestione delle transazioni, la gestione di fagioli; WS hanno WS + estensioni (sicurezza, transazioni)) :

• EJB sono più lento di WS secondo articolo: Remote EJB is 3x slower than WebService in 7.1
• EJB durante la compilazione/costruzione abbiamo dovuto usare esattamente stessa versione del server di applicazione tra cui patch su dev e produzione per evitare errori di runtime dubbia produzione (questo sembra semplice - il team di produzione (datacenter) non sempre sa e quale patch hanno, quando facciamo le correzioni per l'applicazione dobbiamo sempre ri-chiedere la versione esatta del server).
• correzioni parziali dell'applicazione non sono così facili, se EJB viene ricostruito a causa di una piccola correzione, i vasi del client devono essere ricostruiti, quindi le applicazioni che usano i jar dei client hanno bisogno di ridistribuzione.

(questi erano i problemi da mia esperienza, forse altre persone erano più fortunati)

Vorrei concludere che WebServices sono più flessibili, usano meno riflessione, e, auspicabilmente, più velocemente se progettati con cura. Se RESTful viene utilizzato nel controller MVC come risultato, ESB può aiutare sia con l'offerta di trasformazioni (meno codice, solo trasformazione) e di sicurezza direttamente nelle intestazioni HTTP (ad esempio ivheader, ivgroup - se si utilizza ibm web seal, Tivoli access manager). L'utilizzo di SAMAC XACML è possibile solo quando si utilizza WS come le asserzioni funzionano con XML. Pertanto, per le applicazioni aziendali distribuite e dislocate, WS è più flessibile a causa di quanto sopra menzionato.

L'articolo che si riferisce afferma che WS non ha transazioni ma solo proposte. L'articolo è sbagliato o troppo vecchio. Vedi OASIS WSAT 1.0 and WSAT 2.0. Microsoft, JBoss, Oracle e pochi altri supportano la tecnologia out of the box nei loro server applicazioni. Apache Metro sembra sostenere che è andata bene (si prega di verificare).

Answer 6

RMI è fondamentalmente per piccole applicazioni. Sì, è più veloce, ma nel tempo sentirai che, al fine di migliorare ulteriormente la tua applicazione quando il traffico aumenta, il webservice è più manutenibile di RMI e se scegli REStFull webservice sarà l'opzione migliore.

Grazie