Java2 Enterprise 1.3 ormai a tiro

Fuori la nuova beta 2 del Java 2 SDK Enterprise Edition, la nuova piattaforma di sviluppo che spinge Java a nuovi livelli di scalabilità

Palo Alto (USA) - Sun ha rilasciato la seconda beta della versione 1.3 della Java 2 Platform Enterprise Edition (J2EE), una nuova release della nota piattaforma Java dedicata al mercato aziendale che include nuove specifiche per gli EJB (Enterprise JavaBeans), un'architettura a componenti per lo sviluppo di applicazioni enterpirse orientate agli oggetti, distribuite e maggiormente scalabili.

Le nuove specifiche EJB 2.0 semplificano ulteriormente il processo di sviluppo, consentendo agli sviluppatori di concentrarsi maggiormente sulle logiche di business, ed introducono un miglior supporto al multi-transaction e alla sicurezza.

Sun sostiene che il nuovo J2EE Software Development Kit (SDK) fornisce più prestazioni, flessibilità, portabilità ed interoperabilità fra server J2EE. Inoltre, per gli sviluppatori di Web service, la nuova piattaforma di sviluppo consente un miglior supporto dello standard XML attraverso delle nuove API per il parsing e la trasformazione di documenti XML e la traduzione di questo linguaggio per l'utilizzo con le Java Servlet e le JavaServer Pages.
La nuova versione del J2EE SDK può essere scaricata da qui.
TAG: sw
22 Commenti alla Notizia Java2 Enterprise 1.3 ormai a tiro
Ordina
  • Vorrei sapere se esistono aziende qui in Italia
    che fanno progetti usando gli EJB.

    Nelle aziende dove sto io si parla solo
    di COM+ e DCOM e parlano di Java come
    dell'ultima ciofeca specie se rapportato
    al Visual Basic.

    Qualcuno conosce Application Server gratuiti
    dove poter installare degli EJB?

    Grazie

    Pino Silvestre
    non+autenticato

  • > Nelle aziende dove sto io si parla solo
    > di COM+ e DCOM e parlano di Java come
    > dell'ultima ciofeca specie se rapportato
    > al Visual Basic.

    Se pensi che con i componenti scritti in VB non puoi fare il pooling dei componenti, beh java vince il confronto, ma come manutenzione del codice lasciamo perdere...
    non+autenticato
  • sono d'accordo con te, ma... non confondiamo l'object pooling con il "Connection Pooling", molto più interessante e decisivo in "progetti seri". Qsto perchè il connection pooling è, invece, disponibile anche usando VB.
    Così come la Just In Time Activation, che nella maggior parte dei casi sostituisce (all'atto pratico) l'object pooling senza sostanziali differenze (ossia permette il contenimento delle istanze COM effettivamente in esecuzione)
    Oltretutto, l'object pooling è possibile solo se il server COM+ è "free-threaded", e qndi oneroso per i + o - continui switch di contesto e marshaling dei dati...
    A meno che la tua macchina non sia "grossina"...

    - Scritto da: JP
    >
    > > Nelle aziende dove sto io si parla solo
    > > di COM+ e DCOM e parlano di Java come
    > > dell'ultima ciofeca specie se rapportato
    > > al Visual Basic.
    >
    > Se pensi che con i componenti scritti in VB
    > non puoi fare il pooling dei componenti, beh
    > java vince il confronto, ma come
    > manutenzione del codice lasciamo perdere...
    non+autenticato
  • Infatti le performance di applicazioni COM+ scritte in VB non sono molto differenti da quelle scritte in C++ (per quanto riguarda istanze al minuto). Il connection pooling se utilizzi i provider OLEDB viente automaticamente gestito dallo stesso (la prima volta attendi, poi per 60 secondi si mantiene la connessione attiva per sfruttarla da altri componenti, se non basta se ne aprono altre, tutto in maniera trasparente).

    - Scritto da: pecos
    > sono d'accordo con te, ma... non confondiamo
    > l'object pooling con il "Connection
    > Pooling", molto più interessante e decisivo
    > in "progetti seri". Qsto perchè il
    > connection pooling è, invece, disponibile
    > anche usando VB.
    > Così come la Just In Time Activation, che
    > nella maggior parte dei casi sostituisce
    > (all'atto pratico) l'object pooling senza
    > sostanziali differenze (ossia permette il
    > contenimento delle istanze COM
    > effettivamente in esecuzione)
    > Oltretutto, l'object pooling è possibile
    > solo se il server COM+ è "free-threaded", e
    > qndi oneroso per i + o - continui switch di
    > contesto e marshaling dei dati...
    > A meno che la tua macchina non sia
    > "grossina"...

    L'object pooling è possibilè se il tuo linguaggio ammette la compilazione MTA (e non STA come VB).
    non+autenticato
  • ed infatti MTS sta per "Multi-Thread Apartment", tutto qui. Non stavo "sfoggiando" una fantomatica preparazione tecnica, ma solo affermando che nella mia esperienza non esistono vantaggi significativi nell'adozione di C++ rispetto a VB in un progetto reale.
    cmq finalmente qlcuno che parla "tecnichese": ne sentivo la mancanza su qsti forum...
    P.S.: il "think time" funziona anche se usi il bridge per ODBC ed è settato di defatul a 30 secondi.

    - Scritto da: JP
    > Infatti le performance di applicazioni COM+
    > scritte in VB non sono molto differenti da
    > quelle scritte in C++ (per quanto riguarda
    > istanze al minuto). Il connection pooling se
    > utilizzi i provider OLEDB viente
    > automaticamente gestito dallo stesso (la
    > prima volta attendi, poi per 60 secondi si
    > mantiene la connessione attiva per
    > sfruttarla da altri componenti, se non basta
    > se ne aprono altre, tutto in maniera
    > trasparente).
    >
    > - Scritto da: pecos
    > > sono d'accordo con te, ma... non
    > confondiamo
    > > l'object pooling con il "Connection
    > > Pooling", molto più interessante e
    > decisivo
    > > in "progetti seri". Qsto perchè il
    > > connection pooling è, invece, disponibile
    > > anche usando VB.
    > > Così come la Just In Time Activation, che
    > > nella maggior parte dei casi sostituisce
    > > (all'atto pratico) l'object pooling senza
    > > sostanziali differenze (ossia permette il
    > > contenimento delle istanze COM
    > > effettivamente in esecuzione)
    > > Oltretutto, l'object pooling è possibile
    > > solo se il server COM+ è "free-threaded",
    > e
    > > qndi oneroso per i + o - continui switch
    > di
    > > contesto e marshaling dei dati...
    > > A meno che la tua macchina non sia
    > > "grossina"...
    >
    > L'object pooling è possibilè se il tuo
    > linguaggio ammette la compilazione MTA (e
    > non STA come VB).
    non+autenticato
  • > Nelle aziende dove sto io si parla solo di
    > COM+ e DCOM e parlano di Java come
    > dell'ultima ciofeca specie se rapportato
    > al Visual Basic.

    Aziende con personale altamente qualificato, insoma...
    ...poveretti!
    non+autenticato


  • - Scritto da: Pino Silvestre
    > Vorrei sapere se esistono aziende qui in
    > Italia
    > che fanno progetti usando gli EJB.
    >
    > Nelle aziende dove sto io si parla solo
    > di COM+ e DCOM e parlano di Java come
    > dell'ultima ciofeca specie se rapportato
    > al Visual Basic.
    >
    > Qualcuno conosce Application Server gratuiti
    > dove poter installare degli EJB?
    >
    > Grazie
    >
    > Pino Silvestre
    Nella mia azienda li usiamo tranquillamente, ed anzi stiamo abbandonando COM+, DCOM, VB per quanto riguarda le applicazioni distribuite e quelle via web.

    Per quanto riguarda la seconda domanda puoi tranquillamente utilizzare JRun (ex Allaire ora Macromedia) che per gli sviluppatori non richiede nessuna licenza, ma limita gli accessi a max 3 connessioni contemporanee.
    non+autenticato

  • - Scritto da: Pino Silvestre
    > Vorrei sapere se esistono aziende qui in
    > Italia
    > che fanno progetti usando gli EJB.
    Tante!

    > Nelle aziende dove sto io si parla solo
    > di COM+ e DCOM
    Mi sa che dovrebbero cambiare consulenti visto che COM+ e DCOM (questo si una ciofeca) li ha abbandonati pure microsoft...

    >e parlano di Java come
    > dell'ultima ciofeca specie se rapportato
    > al Visual Basic.
    Questa poi! Sorride)
    non+autenticato


  • - Scritto da: paolo
    >
    > - Scritto da: Pino Silvestre
    > > Vorrei sapere se esistono aziende qui in
    > > Italia
    > > che fanno progetti usando gli EJB.
    > Tante!
    >    
    > > Nelle aziende dove sto io si parla solo
    > > di COM+ e DCOM
    > Mi sa che dovrebbero cambiare consulenti
    > visto che COM+ e DCOM (questo si una
    > ciofeca) li ha abbandonati pure microsoft...
    >
    > >e parlano di Java come
    > > dell'ultima ciofeca specie se rapportato
    > > al Visual Basic.
    > Questa poi! Sorride)
    Questa del Java vs VisualBasic non l'avevo mai sentita nemmeno io e non credo abbia un qualsiasi fondamento. A parte che sono certo della superiore validità dell'architettura CORBA(probailmente la + vicina a J2EE), non credo che con COM+ e DCOM sia possibile la stessa scalabilità pernessa da J2EE, specie se supportato da un application server robusto e clusterizzabile. Tomkat anche se un po' 'grezzo', è free ed è un ottimo container, sopratutto per impratichirsi.
    non+autenticato
  • balle. Ho in hosting un applicativo web "serio" (che significa diverse decine migliaia di accessi unici al giorno) composto da pagine ASP che scriptano server COM configurati in una applicazione COM+ residente sulla stessa macchina. Ovviamente il tutto accede ad un DB SQL Server (seppure versione 7)
    La macchina è, incredibile ma vero, un "misero" P3 450 con i dischi IDE (non RAID) da 5400 rpm e 256 Mb RAM. Eppure va come un treno. Su Windoze 2000 Server.
    La verità è che il sw basta saperlo scrivere.

    - Scritto da: angelo
    >
    >
    > - Scritto da: paolo
    > >
    > > - Scritto da: Pino Silvestre
    > > > Vorrei sapere se esistono aziende qui
    > in
    > > > Italia
    > > > che fanno progetti usando gli EJB.
    > > Tante!
    > >    
    > > > Nelle aziende dove sto io si parla solo
    > > > di COM+ e DCOM
    > > Mi sa che dovrebbero cambiare consulenti
    > > visto che COM+ e DCOM (questo si una
    > > ciofeca) li ha abbandonati pure
    > microsoft...
    > >
    > > >e parlano di Java come
    > > > dell'ultima ciofeca specie se
    > rapportato
    > > > al Visual Basic.
    > > Questa poi! Sorride)
    > Questa del Java vs VisualBasic non l'avevo
    > mai sentita nemmeno io e non credo abbia un
    > qualsiasi fondamento. A parte che sono certo
    > della superiore validità dell'architettura
    > CORBA(probailmente la + vicina a J2EE), non
    > credo che con COM+ e DCOM sia possibile la
    > stessa scalabilità pernessa da J2EE, specie
    > se supportato da un application server
    > robusto e clusterizzabile. Tomkat anche se
    > un po' 'grezzo', è free ed è un ottimo
    > container, sopratutto per impratichirsi.
    non+autenticato


  • - Scritto da: pecos
    > balle. Ho in hosting un applicativo web
    > "serio" (che significa diverse decine
    > migliaia di accessi unici al giorno)
    > composto da pagine ASP che scriptano server
    > COM configurati in una applicazione COM+
    > residente sulla stessa macchina. Ovviamente
    > il tutto accede ad un DB SQL Server (seppure
    > versione 7)
    > La macchina è, incredibile ma vero, un
    > "misero" P3 450 con i dischi IDE (non RAID)
    > da 5400 rpm e 256 Mb RAM. Eppure va come un
    > treno. Su Windoze 2000 Server.

    Si si... ma se cominciamo a gestire anche milioni di utenti che acquistano biglietti aerei in web e off-line il tutto poi và a interfacciarsi con il sistema informaico aziendale della british airways....allora lascia stare che l' unica soluzione è Java2EE.....

    > La verità è che il sw basta saperlo
    > scrivere.

    Si ma se ci sono limiti nelle infrastrutture sw a cui ti appogi... che fai????
    non+autenticato