Offrire Hosting Java ad un prezzo davvero contenuto e nello stesso tempo conservare una buona qualità di servizio risulta per le aziende sempre più difficile.
Ultimamente però nel panorama degli hoster dedicati a questo tipo di piani HostingDreams.it si sta imponendo come soluzione di punta davvero affidabile oltre che soprattutto a basso costo.

Il servizio è curato, completo e soprattutto gestito da sistemisti ed analisti programmatori J2EE con anni alle spalle di sviluppo su tale piattaforma.

HostingDreams.it e' Hosting JAVA di qualita' professionale offerto da professionisti JAVA ed ad oggi intende affermarsi come l'Hosting JAVA più evoluto del web mediante l'utilizzo di automazioni da web 2.0 ( pannelli di contollo basati su ajax e sulla massima interazione tra server ed utente ).

Tutti i piani di Hosting JAVA supportano pienamente i piu' recenti framework come Struts, Hibernate, GWT, EJB (anche la versione 3), JSF e si basano sui più accreditati server come Tomcat e JBoss.

A differenza di altri hoster si segnala anche il supporto per Jetty ( al momento supportato addirittura sino alla versione 7 ).

Da notare poi come il sito offra all'utente più diffidente la possibilità di testare il servizio di punta: l'hosting java basato su tomcat.

L'attivazione dell'account demo, che richiede davvero pochi dati di registrazione e non vincola all'acquisto, viene completata in pochi minuti.
E dopo ancora qualche minuto l'utente è già in grado di testare le funzionalità scelte per 5 giorni.

In definitiva HostingDreams.it è un servizio da provare ( gratis ) e da tenere davvero in seria considerazione per esigenze basate su spazio web java.

Da Wikipedia, l'enciclopedia libera.
 

Spring è un framework open source per lo sviluppo di applicazioni su piattaforma Java.

La prima versione venne scritta da Rod Johnson e rilasciata con la pubblicazione del proprio libro "Expert One-on-One Java EE Design and Development" (Wrox Press, Ottobre 2002).

All'inizio il framework venne rilasciato sotto Licenza Apache nel giugno 2003.
Il primo rilascio importante è stato l'1.0 del marzo 2004, seguito da due successivi rilasci importanti nel settembre 2004 e nel marzo 2005.

Spring è stato largamente riconosciuto all'interno della comunità Java quale valida alternativa al modello basato su Enterprise JavaBeans (EJB). Rispetto a quest'ultimo, il framework Spring lascia una maggiore libertà al programmatore fornendo allo stesso tempo un'ampia e ben documentata gamma di soluzioni semplici adatte alle problematiche più comuni.

Sebbene le peculiarità basilari di Spring possano essere adottate in qualsiasi applicazione Java, esistono numerose estensioni per la costruzione di applicazioni web-based costruite sul modello della piattaforma Java EE. Questo ha permesso a Spring di raccogliere numerosi consensi e di essere riconosciuto anche da importanti vendor commerciali quale framework di importanza strategica.

Storia [modifica]

Nel 2000 Rod Johnson inizia lo sviluppo di Spring mentre lavora a Londra come consulente libero professionista, ma è durante la scrittura di "Expert One-on-One Java EE Design and Development" che espande il proprio codice al fine di esprimere la sua visione di semplificare e rendere più consistente il modo di interoperare delle varie parti che compongono una applicazione Java EE.

Prima del 2001 i modelli di programmazione dominanti per le applicazioni web erano basati sulle Java Servlet API e gli Enterprise JavaBeans. Entrambe le specifiche furono create da Sun Microsystems in collaborazione con altri vendor e godevano di grande popolarità all'interno della comunità Java. Le applicazioni che non erano basate sul web si appoggiavano ad altri strumenti e paradigmi di programmazione. Rod Johnson ha avuto il merito di creare un framework basato su principi "ottimali" largamente accettate e le ha rese disponibili per tutti i tipi di applicazione, non solo web.

Nel febbraio 2003 un piccolo gruppo di sviluppatori ha creato un progetto su Sourceforge al fine di estendere il framework e dopo circa un anno ha rilasciato la prima versione 1.0. Sebbene sia stato largamente adottato, Spring venne pesantemente criticato per il fatto che il progetto si poneva come obiettivo la semplice integrazione con gli standard Java EE senza un documento di specifica controllato da un comitato ufficiale.

Spring tuttavia rese popolari alcune tecniche prima d'allora poco note come l'Inversion of Control il paradigma di Programmazione orientata agli aspetti. Il 2005 ha visto un enorme aumento di consensi in concomitanza di un nuovo importante rilascio. Inoltre ilforum ufficiale ha notevolmente aiutato ad accrescere la popolarità del framework e si è imposto quale fonte primaria di informazione e di supporto agli utenti.

Diamo un'occhiata agli EJB

Gli Enterprise JavaBean (EJB) sono i componenti che implementano, lato server, la logica di business all’interno dell’architettura J2EE. Le specifiche per gli EJB definiscono diverse proprietà che questi devono rispettare, tra cui la persistenza, il supporto alle transazioni, la gestione della concorrenza e della sicurezza e l’integrazione con altre tecnologie, come JMS, JNDI, e CORBA.
Gli EJB sono uno strumento molto potente e sono di solito utilizzati in applicazioni distribuite, in cui la necessità di ripartire il carico e le funzionalità, sono di sostanziale importanza.

Un EJB è una classe Java che segue determinate regole imposte dalla specifica che, una volta programmato, viene posto in un application server e da esso verrà gestito secondo le regole definite.

In un contesto Java puro, generalmente, i client di questi oggetti sono le pagine JSP e le servlet, che si poggiano agli EJB per definire il contenuto dinamico da mostrare all’utente (una ricerca, un carrello della spesa, ecc). In realtà, l’idea di questi componenti è nata per permettere a diverse tecnologie di usare lo stesso strato di logica, residente in un contesto distribuito.

Esistono tre tipi di EJB:

• EJB di Entità (Entity EJB): il suo scopo è di inglobare gli oggetti sul lato server che memorizzano i dati. Gli EJB di entità forniscono la caratteristica della persistenza dei dati:
  • Persistenza gestita dal contenitore (CMP): il contenitore si incarica della memorizzazione e del recupero dei dati relativi a un oggetto utilizzando una tabella di una base di dati.
  • Persistenza gestita dal bean (BMP): in questo caso è il bean a occuparsi del salvataggio e recupero dei dati a cui fa riferimento, il salvataggio può avvenire in una base di dati o con qualsiasi altro meccanismo perché è il programmatore che si incarica di realizzare il meccanismo della persistenza dei dati.
• EJB di sessione (Session EJB): gestiscono l’elaborazione delle informazioni sul server. Generalmente sono una interfaccia tra i client e i servizi offerti dai componenti disponibili sul server. Ne esistono di due tipi:
  • con stato (stateful). I bean di sessione con stato sono oggetti distribuiti che posseggono uno stato. Lo stato non è persistente, però l’accesso al bean è limitato ad un unico client.
  • senza stato (stateless). I bean di sessione senza stato sono oggetti distribuiti senza uno stato associato, questa carattestistica permette un accesso concorrente alle funzionalità offerte dal bean. Non è garantito che il contenuto delle variabili di istanza si conservi tra diverse chiamate ai metodi del bean.
• EJB guidati da messaggi (Message driven EJBs): sono gli unici bean con funzionamento asincrono. Tramite il Java Message Service (JMS), si iscrivono a un argomento (topic) o a una coda (queue) e si attivano alla ricezione di un messaggio inviato all’argomento o alla coda a cui sono iscritti. Non richiedono una istanziazione da parte dei client.

Notevoli passi in avanti sono stati fatti dalla versione 2 alla 3.0

La grossa differenza nel passaggio da una versione ad un'altra è stata l'eliminazione delle classi utilizzate come Factory per istanziare concretamente il bean. Ciò significa che nella versione 3 non dovremo più creare una classe Home per ogni bean creato, né dovremo preoccuparci di estendere altre classi o interfacce.

Gli EJB 3.0 hanno in pratica modificato radicalmente l'architettura, lasciando molta più libertà alla costruzione dell'application server che ospiterà i componenti. Sarà infatti il container e la maniera in cui esso è implementato a gestire il ciclo di vita del componente. Non importa come questo avvenga: importante è rispettare la specifica e garantire il corretto ciclo di vita dei componenti. Fondamentalmente nella versione 3 sarà sufficiente scrivere una classe POJO (Plain Old Java Object) che implementa l'interfaccia di business.

Questa cosa potrebbe non essere positiva, in quanto in questo modo perderemmo la possibilità di intervenire in particolari momenti del ciclo di vita dell'oggetto (ad esempio durante le operazioni di passivazione ed attivazione). Ciò viene risolto dalla possibilità di creare delle apposite classi callback oppure di scrivere i metodi per gestire gli eventi ed annotarli con le annotazioni.

A questo punto risulta piuttosto evidente che il descrittore di deploy è inutile. Attraverso le annotazioni, infatti, riusciamo a definire in maniera precisa il componente e le sue diverse funzionalità, il ciclo di vita (anche le transazioni o altre funzioni di middleware da implementare). Di tutti i componenti, probabilmente questo è stato quello meno amato per un semplice motivo: è XML. Difficile da scrivere, da leggere e da capire, attraverso le annotazioni, fortunatamente questo componente viene meno. Inoltre, la sua redazione avviene in una seconda fase rispetto allo sviluppo del componente, quindi, l'insidia può essere rappresentata dalle dimenticanze. La possibilità di definire già all'interno della classe il suo comportamento del componente (transazioni, sicurezza, riferimenti ad altri ejb, ecc) facilita (e non poco) il lavoro.

Come application server per gli EJB consigliamo certamente JBOSS.

Maggiori informazioni su JBoss: www.jboss.com
Comunità degli sviluppatori: www.jboss.org