Proprio quello che è Java EE davvero? [chiuso]

Ecco alcune risposte rapidamente composte alle tue domande...

• Perché le librerie JavaEE non possono funzionare senza un server di applicazioni? I servizi forniti da JavaEE (transazioni gestite da container, iniezione di dipendenze gestita da container, servizio timer, ecc..) implicano intrinsecamente server di applicazioni compatibili con JavaEE (ad esempio: GlassFish, JBoss, WebSphere, ecc...). Pertanto le librerie JavaEE non hanno alcun scopo senza un tale contenitore. " Perché ho bisogno qualcosa di massiccio come JBoss solo per compilare un semplice codice per inviare una e-mail? " Non lo fai. Ci sono modi per inviare un'email senza JavaEE... Ma se vuoi farlo nel modo JavaEE, hai bisogno di un contenitore JavaEE.

• Perché le librerie JavaEE non sono incluse nel download di JavaSE? La stessa ragione per cui molte librerie non sono incluse: sarebbe eccessivo. Dal momento che non è possibile utilizzare nemmeno le librerie JavaEE senza un server di applicazioni, perché preoccuparsi di includerle? JavaEE dovrebbe essere scaricato se e quando uno sviluppatore installa un server di applicazioni e decide di utilizzare JavaEE.

• Perché ci sono così tante offerte JavaEE? Ci sono davvero" così tante " offerte JavaEE? Se è così, si prega di elencare alcuni di loro. Più precisamente credo che ci siano implementazioni multiple delle stesse API .

• Cosa si può fare con JavaEE che non possono fare a meno di Java standard? Sacco. Non puoi fare affidamento su un application server per gestire transazioni o contesti di persistenza senza JavaEE. Non è possibile consentire a un server di applicazioni di gestire l'iniezione di dipendenze EJB senza JavaEE. Non è possibile utilizzare un servizio di timer gestito dall'applicazione senza JavaEE. La risposta a questa domanda dovrebbe rendere la risposta alla prima domanda abbastanza chiara... La maggior parte dei servizi forniti da JavaEE richiedono un contenitore JavaEE.

• Cosa puoi fare con JavaSE che non puoi fare con JavaEE? Ehm Um.. Mi non lo so.

• Quando uno sviluppatore decide che ha bisogno di JavaEE? Questa domanda è completamente soggettiva... Ma se hai bisogno di uno qualsiasi dei servizi forniti da JavaEE, inizi a pensarci. Se non sai cos'è JavaEE... probabilmente non ne hai bisogno.

• Quando uno sviluppatore decide di non aver bisogno di JavaEE? Vedi risposta precedente.

• Perché la versione della libreria JavaEE non è sincronizzata con la versione JavaSE? Bene domanda. Non farò finta di sapere come rispondere... Ma immagino che la risposta sia: "perché non sono sincronizzati".

A volo d'uccello, Java EE è una piattaforma, cioè qualcosa su cui possiamo costruire.

In una prospettiva più tecnica, lo standard Java Enterprise Edition definisce un insieme di API comunemente utilizzate per la creazione di applicazioni aziendali. Queste API sono implementate dai server delle applicazioni-e sì, diversi server delle applicazioni sono liberi di utilizzare diverse implementazioni delle API Java EE.

Tuttavia, la libreria java ee non funzionerà, né verrà compilata a meno che il codice viene eseguito su o ha accesso a un server di applicazioni Java EE (come JBoss, GlassFish, Tomcat, ecc.).

Si compila con le API Java EE, quindi è necessario solo quelle API in fase di compilazione. In fase di runtime, avrai anche bisogno di un'implementazione di queste API, ovvero un server di applicazioni.

Perché ho bisogno di qualcosa di massiccio come JBoss solo per compilare un semplice codice per inviare un'e-mail?

Non lo fai. Tuttavia, se si desidera utilizzare l'API Java EE per l'invio di sarà necessaria un'implementazione di tale API in fase di runtime. Questo può essere fornito da un server di applicazioni o fornito da una libreria stand alone aggiunta al classpath.

Perché le librerie Java EE non sono "standard" e incluse nel normale download JVM e/o nell'SDK?

Perché solo le API sono standardizzate, non le implementazioni.

Perché ci sono così tante offerte Java EE

Perché le persone non sono d'accordo sul modo giusto per implementare alcune caratteristiche. Perché diversi fornitori competono per la quota di mercato.

Cosa si può fare con Java EE che non possono fare con Java standard?

Poiché le implementazioni Java EE sono costruite con "Java standard": Niente. Tuttavia, sfruttare le librerie esistenti può risparmiare un grande sforzo se si risolvono problemi tipici aziendali e l'utilizzo di un'API standardizzata può impedire il blocco del fornitore.

Cosa si può fare con Java standard che non possono fare con Java EE?

Niente, poiché Java EE include Java SE.

Quando uno sviluppatore decide di "aver bisogno" di Java EE? Quando uno sviluppatore decide di non aver bisogno di Java EE?

In generale, le API Java EE risolvono problemi tipici e ricorrenti nell'elaborazione aziendale. Se si hanno tali problemi, di solito ha senso utilizzare le soluzioni standard, ma se si hanno problemi diversi, possono essere richieste soluzioni diverse. Ad esempio, se è necessario parla con un database relazionale, dovresti considerare l'utilizzo di JPA. Ma se non hai bisogno di un database relazionale, JPA non ti aiuterà.

Che cos'è Java EE?

Iniziamo dalla definizione di canonicity su wiki:

Java Platform, Enterprise Edition o Java EE è l'azienda di Oracle Piattaforma di calcolo Java. La piattaforma fornisce un'API e un runtime ambiente per lo sviluppo e l'esecuzione di software aziendale, tra cui servizi di rete e web, e altri su larga scala, a più livelli, applicazioni di rete scalabili, affidabili e sicure.

Il punto principale qui è che Java EE è una piattaforma fornisce un'API, non una libreria concreta.

Cosa serve per Java EE?

L'ambito principale di Java EE sono le applicazioni basate sulla rete, a differenza di Java SE orientato allo sviluppo di applicazioni desktop con semplice supporto di rete. Questa è la principale differenza tra loro. Scalabilità, messaggistica, transactioning, supporto DB per ogni applicazione... la necessità in tutto questo è aumentata con l'evoluzione della rete. Naturalmente un sacco di soluzioni pronte che Java SE fornisce sono utile per lo sviluppo della rete, quindi Java EE estende Java SE.

Perché abbiamo bisogno di server di applicazioni per eseguire il nostro codice?

Perché abbiamo bisogno di sistemi operativi? Perché ci sono un sacco di lavoro doloroso con l'hardware che dobbiamo fare per rendere l'applicazione ancora più semplice. E senza OS devi farlo ancora e ancora. Il sistema operativo semplificato è solo un contenitore programmatico, che ci fornisce un contesto globale per eseguire le nostre applicazioni.

E questo è ciò che sono i server delle applicazioni. Essi are ci consente di eseguire le nostre applicazioni nel loro contesto e ci fornisce molte funzionalità di alto livello necessarie per le applicazioni di rete highloaded aziendali. E non vogliamo scrivere le nostre biciclette per risolvere questi problemi, vogliamo scrivere codice in grado di soddisfare le nostre esigenze aziendali.

Un altro esempio qui potrebbe essere JVM per Java.

Perché Java EE non contiene il server app integrato?

Difficile da dire per me. Penso, è stato fatto per una maggiore flessibilità. Java EE dice cosa dovrebbero fare, decidono come farlo.

Perché JVM non include Java EE?

Perché indirizzati a diversi settori di mercato. Java EE ha un sacco di funzionalità che non è necessario per i soliti desktop.

Perché ci sono così tante offerte Java EE?

Perché Java EE descrive solo il comportamento. Tutti possono implementarlo.

Cosa si può fare con Java EE che non possono fare con Java SE?

Per conquistare internet. E davvero difficile da fare con applet e socket Java SE :)

Cosa si può fare con Java SE che non possono fare con Java EE?

Come menzionato sopra Java EE estende Java SE, quindi con Java EE dovresti essere in grado di fare tutto ciò che è disponibile per Java SE.

Quando uno sviluppatore decide di "aver bisogno" di Java EE?

Quando hanno bisogno della potenza di Java EE. Tutto ciò che è menzionato sopra.

Quando uno sviluppatore decide di non aver bisogno di Java EE?

Quando scrivono un solito console o applicazione desktop.

Perché le versioni di Java SE e Java EE non sono sincronizzate?

Java ha sempre avuto problemi con la denominazione e il controllo delle versioni delle sue tecnologie. Quindi questa situazione non è un'eccezione.

Java EE è tutto sul concetto di contenitore.
Contenitore è un contesto di esecuzione all'interno del quale verrà eseguita l'applicazione e che fornisce quest'ultimo un insieme di servizi. Ogni tipo di servizio è definito da una specifica denominata JSR. Ad esempio JSR 907, JTA (java transaction Api) che forniscono un modo standard per gestire transazioni distribuite su risorse diverse.
Ci sono generalmente molte implementazioni diverse per un dato JSR, l'implementazione che userai dipende dal provider di container, ma non ti dispiace in quanto sei sicuro che il comportamento rispetti il contratto predefinito : l'API JSR.
Quindi, per sfruttare Java EE, è necessario eseguire l'applicazione all'interno di un contenitore. I due principali sono EJB e servlet container che sono entrambi presenti su qualsiasi server di applicazioni certificato Java EE.

Lo scopo di tutto ciò è definire un ambiente di esecuzione standard per consentire di impacchettare l'applicazione con solo gli elementi essenziali, id.est. vostro business. Evita di dipendere da un insieme sconosciuto e vario di librerie di terze parti che altrimenti dovresti impacchettare e fornire con la tua app e che potrebbero essere fonti di conflitto con altre app sul server. In Java EE sai che tutti i requisiti standard non funzionali come sicurezza, transazione, scalabilità, invocazione remota e molti altri saranno forniti dal contenitore (fattorizzato per tutte le app in esecuzione al suo interno) e devi solo basare il tuo lavoro sul suo.