Web Services vs EJB vs RMI, vantaggi e svantaggi?

Question

Il mio server Web verrebbe sovraccaricato rapidamente se tutto il lavoro fosse stato svolto lì. Ho intenzione di alzare un secondo server dietro di esso, per elaborare i dati.

Qual è il vantaggio di EJB su RMI o viceversa?

E i servizi Web (SOAP, REST)?

Answer 1

Gli EJB sono costruiti su RMI. Entrambi implicano client e bean Java. Se i tuoi clienti devono essere scritti in qualcos'altro (ad esempio, .NET, PHP, ecc.), Vai con i servizi web o qualcos'altro che parla un protocollo wire-agnostico, come HTTP o XML su HTTP o SOAP.

Se si sceglie RMI, non è necessario un server di applicazioni EJ Java EE. È necessario mantenere sincronizzate le JVM client e server; non è possibile aggiornare il client senza aggiornare il server. È necessario scrivere tutti i servizi forniti dall'app server EJB (ad esempio, pool di connessioni, servizi di denominazione e directory, pooling, accodamento delle richieste, transazioni, ecc.).

RMI è un livello piuttosto basso quando ci pensi. Perché dovresti tornare indietro a CORBA?

Una scelta migliore è EJB 3.0 rispetto a Spring. Dipende se ti piace lo sviluppo POJO, vuoi una scelta di tecnologie relazionali oltre a ORM e JPA, tra le altre cose.

È possibile pagare un server di applicazioni Java EE (ad esempio, WebLogic, WebSphere) o utilizzare uno open source (JBOSS, Glassfish e OpenEJB e ActiveMQ) oppure è possibile attenersi a Spring e distribuire su Tomcat, Jetty, Resin o qualsiasi altro servlet/motore JSP.

Primavera offre un sacco di scelta per essere la tecnologia agnostica: la persistenza (Hibernate, iBatis, JDBC, JDO, JPA, TopLink), servizi remoti (HTTP, Iuta, Tela ruvida, RMI, SOAP servizio web), ecc

EJB 3.0 è una specifica con molti fornitori; La primavera si può avere solo dalla fonte di primavera.

Vorrei raccomandare Spring. È molto solido, ha molta trazione, non sta andando da nessuna parte. Lascia tutte le opzioni aperte.

servizi Web sono grande, in teoria, ma ci sono alcuni trucchi che avete bisogno di guardare fuori per:

1. latenza. La prima legge di Fowler sugli oggetti distribuiti: "Do not!" Un'architettura composta da molti servizi SOAP distribuiti a grana fine sarà elegante, bella e lenta come melassa. Pensaci attentamente prima di distribuire.
2. Il marshalling da XML a oggetti e back consuma cicli di CPU che non forniscono alcun valore aziendale oltre a consentire ai client di parlare con un protocollo indipendente dalla piattaforma.
3. SOAP è uno standard che sta diventando sempre più gonfio e complesso ogni giorno, ma ha un sacco di supporto per gli strumenti. Ai venditori piace perché aiuta a incrementare le vendite di ESB. REST è semplice ma non così ben compreso. Non è supportato da strumenti.

Il modulo del servizio Web di Spring è molto buono, ma fai attenzione a scegliere di distribuire in questo modo. Scrivi in ​​termini di interfacce di servizio POJO. Questi ti permetteranno di ottenere l'isolamento concettuale che desideri, di rinviare la scelta di schieramento fino all'ultimo momento e di farti cambiare idea se il primo pensiero non funziona bene.

Answer 2

Tra EJB e RMI, EJB sarebbe certamente meglio - ha tutto RMI ha e molto altro tramite il contenitore (il pool di oggetti, la gestione delle transazioni, etc.)

Tra i servizi EJB e web, servizi web darebbero maggiore portabilità se vuoi poterli chiamare da app non java in futuro. EJB ti offre ancora cose come la gestione delle transazioni e il pooling che potresti non ottenere "out of the box" con i servizi web.

Personalmente, se lo facessi, probabilmente userei EJB o qualche framework di oggetto remoto simile (anche il remoting spring mi viene in mente). Se è necessaria la capacità di chiamare gli oggetti da un'app non java, è sempre possibile eseguire il frontespizio dei bean con proxy di servizi Web semplici, se necessario.

Answer 3

Re: servizi Web (SOAP, REST) ​​ Se i server back-end non vengono esposti pubblicamente, non si ottiene alcun vantaggio dall'utilizzo di interfacce di servizi Web indipendenti dalla piattaforma come SOAP/REST.
Infatti, si incorre in una penalità con tutto il sovraccarico aggiunto dai tag XML che avvolgono i dati attraverso una chiamata remota, per non parlare del colpo che si otterrà dal marshalling e di unmarshalling degli oggetti XML in java.
Sebbene qualsiasi chiamata distribuita richieda un certo livello di serializzazione - anche RMI/EJB, ma il prezzo è maggiore quando si esegue la serializzazione in XML leggibile dall'uomo.

Potrebbe non essere necessario codificare le chiamate remote in Java, è possibile eseguire il servizio con una semplice istanza httpd di apache, configurata per bilanciare il carico tra più server java utilizzando mod_jk o mod_proxy.
Questi moduli possono essere utilizzati per bilanciare il carico tra contenitori servlet come tomcat/jetty o contenitori ejb come jboss/glassfish.