Ho fatto HTTP / REST-ish usando JAX-RS quasi esclusivamente per la comunicazione tra servizi per un po '(escludendo alcuni JMX per il monitoraggio), ma ecco la mia memoria degli argomenti:
-
EJB è un comodo wrapper per RMI
-
RMI è un ottimo protocollo Java proprietario.
-
SOAP ha alcuni sostenitori molto seri, ma sta lottando sotto il peso della rigidità XSD e può creare un accoppiamento stretto tra client e server se non sei veramente, molto attento.
Ecco perché JSON su HTTP si sta affermando come una scelta popolare per la comunicazione tra servizi. È anche ufficialmente parte di JEE con le specifiche JAX-RS, quindi RMI / EJB non è più l'unica risposta ufficiale.
-
EJB ha lo svantaggio di avere bisogno di un contenitore aziendale completo piuttosto che un contenitore di applicazioni gratuito più piccolo come Jetty o anche Tomcat
-
RMI ha lo svantaggio di essere un protocollo Java proprietario, quindi puoi parlare solo da Java a Java. Ho una memoria che puoi collegare altre tecnologie utilizzando un'implementazione CORBA sottostante, ma sono passati 15 anni da quando ho avuto quella conversazione.
-
Inoltre, poiché RMI si basa sulla serializzazione degli oggetti, può essere soggetto a un accoppiamento molto stretto tra client e server. Ciò significa che se si compila una nuova versione del server, è necessario compilare e distribuire una nuova versione di tutti i client. Tuttavia, potrei non averne una base.
Dato che JAX-RS fa parte delle specifiche JEE ora, e ci sono delle belle implementazioni come Jersey o RestEasy, i negozi in cui sono stato per l'ultimo decennio hanno semplicemente gravitato su questo come soluzione (anche prima che fosse parte delle specifiche).
Inoltre, con un protocollo standard come OAuth, puoi esporre la stessa interfaccia su Internet pubblica come rete interna, quindi non avere per fornire tecnologie separate per le API interne e quelle esterne.
Inoltre, anche prima, ero in un negozio che riconosceva tutti i vantaggi dell'esecuzione di un'applicazione all'interno di un container. Quindi, anziché implementare il proprio framework applicativo, era più conveniente, standard e gestibile lasciare semplicemente la nostra funzionalità in un contenitore di applicazioni e lasciare che si occupasse delle preoccupazioni del sistema. EJB & e un contenitore aziendale offre gli stessi vantaggi, ma puoi pagare un sacco di $$$$ per le licenze rispetto a quello che puoi scaricare e distribuire gratuitamente.
Come ho detto, è passato molto tempo da quando ho avuto quelle conversazioni, quindi potrei ottenere qualche downvotes. Tutte le scuse dovute.
