Il modo migliore per distribuire e distribuire l'applicazione JEE sul client

3

Ho lavorato per poche aziende e ho anche sviluppato progetti per conto mio - questi progetti erano basati su Java Enterprise Edition. A volte con Spring Framework coinvolto, a volte era un puro JEE. Tuttavia, la creazione di applicazioni basate su Java ha per me un grosso difetto: troppi ambienti eterogenei.

  1. Server di applicazioni differenti. Ognuno con il proprio diverso insieme di problemi e bug.
  2. Diversi client hanno JDK diversi. Dovrebbe essere un'operazione semplice per l'amministratore di scambiare JDK. In pratica, è un rompiscatole.

In questo modo, a volte siamo costretti a basare i nostri progetti su JDK 1.6 e distribuirli a server di applicazioni obsoleti già esistenti. Anche se i nostri clienti impostano da zero l'ambiente per noi, installando il JDK più recente e un AS decente come WildFly, potrebbero essere deprecati in mesi (JDK) o pochi anni (App.Server).

Poiché alcuni client dispongono solo di Tomcat o di altri contenitori servlet, è necessario utilizzare Spring Framework, senza alcuna scelta per il futuro, come le nuove librerie di servizi Java Micro. Non vedo davvero come questo sia un problema, ma cambiare completamente l'ambiente è potenzialmente pericoloso, specialmente nel settore bancario. Tutto deve essere testato di nuovo e costa denaro.

Pertanto, sto cercando un modo per confezionare un'applicazione Java e presentarla come una scatola nera per gli amministratori del client. Forse con una quantità minima di configurazione (esterna).

WildFly Swarm ( link ) Questo sembra promettente. WildFly offre la distribuzione solo servlet, quindi è adatto per i progetti Spring Framework, se necessario. In effetti, potrebbe essere il miglior server là fuori in questo momento. Il vaso grasso risultante può essere accompagnato con qualsiasi JDK e può essere eseguito tramite uno script di shell nativo / file eseguibile. Questo sembra promettente. Le dipendenze esterne come il database non sono un problema di solito - di solito non abbiamo un strong bisogno di server di database più recenti.

Non sono sicuro che questo supporti più guerre in uno swarm WildFly.

Docker Tutto il server delle applicazioni, le applicazioni java (guerre, orecchie) vengono semplicemente inserite in un'immagine Docker. Ciò richiede l'installazione della finestra mobile, ma, ancora una volta, la finestra mobile viene installata una volta e può essere facilmente aggiornata senza riesaminare l'intero ecosistema delle applicazioni. Dockerizing ha un grande vantaggio: se voglio includere qualcosa come un database (Mongo), posso farlo.

Riepilogo

L'idea generale è di avere il controllo sull'ambiente del cliente. Non installarlo ora e cercare di aggiornare tutto qualche anno dopo. Con ogni aggiornamento dell'applicazione, voglio semplicemente aggiornare il JDK se voglio. Quindi voglio aggiornare il mio application server / servlet container. Essere in grado di aggiungere altri programmi al pacchetto è un vantaggio, ma non necessario.

Tuttavia, non ho alcuna esperienza con questo modo di distribuzione delle applicazioni.

  • Qualcuno ha esperienza con questa distribuzione di applicazioni?
  • C'è forse un altro / migliore approccio per le applicazioni Java?
  • Che cosa usi?
posta Pavel Pscheidl 04.06.2016 - 17:47
fonte

1 risposta

1

Swarm, Spring Boot, Dropwizard - sono solo microcontainer, invece di impacchettare la tua app come una guerra e farla funzionare in un contenitore che stai impacchettando con gli strumenti AS all'interno della tua app.

C'è un buon confronto qui: link

    
risposta data 11.06.2016 - 14:57
fonte

Leggi altre domande sui tag