lunedì dic 21, 2009

Java EE 6, GlassFish Enterprise Server v3 e NetBeans 6.8

glassfish  Dicembre è stato un mese ricco di novità per chi si occupa della tecnologia Java.

Dopo 3 anni sono state rilasciate le nuove specifiche Java EE 6, e dal 10 dicembre è disponibile ufficialmente tutto ciò che serve per iniziare a sfruttare tutte le potenzialità delle nuove specifiche: GlassFish Enterprise Server v3 e NetBeans 6.8. Per chi usa Eclipse è comunque disponibile il GlassFish Tools Bundle.
Ancora una volta l'easy-of-development ha guidato la definizione delle nuove specifiche, accompagnato dall'obiettivo del right-sizing. Attraverso i Profiles, infatti, si introduce la possibilità di "tagliare" la piattaforma di run-time sulla base delle applicazione che andrà ad ospitare. Un esempio è il Web Profile che si può scaricare pre-configurato e che permette di avere a disposizione le API necessarie per lo sviluppo di applicazioni web: Servlet 3.0, EJB Lite 3.1, JPA 2.0, JSP 2.2, EL 1.2, JSTL 1.2, JSF 2.0, JTA 1.1, JSR 45, Common Annotations. Il risultato è che il tempo di start-up è 1/3 di quello della v2. GlassFish Enterprise Server v3, inoltre, migliora il managment introducendo un'interfaccia REST per gestire l'application server via GET/POST HTTP.

Per tornare alla semplificazione dello sviluppo vi faccio un primo esempio.
Per sviluppare una Servlet, con le precendenti versioni occorreva di fatto produrre due file sorgenti:

  • la classe servlet. Es.:
/\* Code in Java Class \*/
package com.foo;
public class MyServlet extends HttpServlet {
    public void doGet(HttpServletRequest req,HttpServletResponse res) {
       ... 
    }
   ...
}
  • il relativo deployment descriptor web.xml:
<!--Deployment descriptor web.xml -->
<web-app>
<servlet>
<servlet-name>MyServlet
           </servlet-name>
       <servlet-class>
         com.foo.MyServlet
       </servlet-class>
    </servlet>
    <servlet-mapping>
       <servlet-name>MyServlet
       </servlet-name>
       <url-pattern>/myApp/\*
       </url-pattern>
    </servlet-mapping>
    ...
 </web-app>


Con Java EE 6, invece, è possibile usare delle annotation per non doversi preoccupare di gestire due files, e il tutto può essere fuso in:

package com.foo;
@WebServlet(name=”MyServlet”,urlPattern=”/myApp/\*”)
public class MyServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) {
        ...
   }

...

}

Da notare che la classe non è più esplicitamente derivata dalla classe HttpServlet: ci pensa l'annotation.
Le altre interessanti features le vedremo prossimamente.

venerdì gen 16, 2009

Corsi gratis su Glassfish

Vi vorrei segnalare l'opportunità di training web-based che offriamo a chi si registra scaricando Glassfish. Per 90 giorni sono disponibili i seguenti corsi:

  • GlassFish Application Server: Introduction (WMT-SAS-1536)
  • Designing Java Web Services (WJ-4112-EE5)
  • Adding Quality of Service and .NET Interoperability to Web Services (WMT-SAS-1543)
  • Creating Reliable and Secure Interoperable Web Services (WMT-SAS-2544)
  • Creating Transactional Web Services (WMT-SAS-2545)
  • Working With the Web Services Policy (WMT-SAS-2546)
Per maggiori dettagli qui.


venerdì mag 02, 2008

On-line la trascrizione della chat "NetBeans and GlassFish: An Open Source Chat"

Per chi non ha potuto partecipare alla chat del 2 aprile organizzata dalla Sun per permettere a tutti gli interessati all'argomento di porre domande a membri del nostro engineering ed agli ambassador Java, tra cui il sottoscritto, sono disponibile le trascrizioni

giovedì mar 06, 2008

Glassfish mi ha convinto, ma se devo migrare un'applicazione Java EE esistente?

Mi sono trovato spesso di fronte a clienti che, pur avendo apprezzato le features di Glassfish e la possibiltà di avere un supporto diretto da Sun per applicazioni mission-critical, si trovano a dover far i conti con le applicazioni esistenti, sviluppate ad esempio su JBoss, e che per omogeneità di piattaforma andrebbero portate anch'esse su Glassfish.

Per chi ha questo tipo di problemi la Sun offer l'AVK ed il GlassFish Migration tool. Per avere un'idea di come procedere nel porting da JBOSS, il mio collega Sekhar Vajjhala ha postato nel suo blog un interessante esempio  dove mostra come muoversi tra le facelets, JNDI, persistenza e packaging. La maggior parte di questi interventi  vengono segnalati gia passando l'applicazione attraverso l'AVK, tool disponibile anche come plug-in di NetBeans. Nel blog di Sekhar sono riportati anche esempi relativi ad altri application server Java EE.


venerdì nov 23, 2007

Glassfish: high-availability trade-off

Mi è capitato spesso di trovarmi di fronte a richieste in termini di High Availability che non mettevano in relazione il TCO dell'architettura rispetto al potenziale danno derivante dalla indisponibilità del servizio o la perdita di sessioni attive.

Vorrei prendere spunto da questo diagrama di performance di Glassfish V2 nelle due configurazioni  cluster ed enterprise per fare una breve considerazione. Nel primo caso abbiamo una replica della sessione su almeno due istanze con Shoal, senza il salvataggio su file system della sessione stessa. In questa configurazione si potrebbe non raggiungere il 99.999% di disponibilità dei sistemi, cioè 5 minuti di fermo in un anno. Nel secondo caso si fa uso dell'HADB, ovvero un DB multi istanza che oltre a replicare la sessione alla commit garantisce che la sessione sia salvata su storage. I 99.999% di HA su hardware full-redundant è garantito.

Tenendo conto di questo grafico, però, ci si rende conto che rispetto ad un puro load-balancing, si ottiene un fattore di degrado di performance (PD) che va dal 0.3 al 0.7

Detto questo, pertanto, vi invito a valutare queste formule che ho definito per quantificare in modo grossolano le architetture (ben vengano suggerimenti per migliorarle) :

TCO= HC+PCCY+MCY+SS

dove: 

  • HC: hardware cost ($);
  • PCCY: power consumption cost per year ($);
  • MCY: Maintenance cost per year ($)
  • SS: setup services ($)

LFY=MASS\*MRT\*365/MTTF

dove:

  • LFY:  Loss  per Fault per Year ($);
  • MASS:  Mean Active Session per Server (no-replication);
  • MRT: Mean Revenue per Transaction ($);
  • MTTF: Mean Time to Failure (days); 


A mio avviso se:

LFY << TCO\*PD

bisognerebbe valutare seriamente se vale la pena di tenere un'infrastruttura hw degradata in termini di performance pur di non perdere un certo numero di transazioni.

 

 

 

lunedì set 17, 2007

Rilasciato GlassFish v2 (SJS Application Server 9.1)

Get GlassFish V2Da oggi è disponibile la versione 9.1 di Sun Java System Application Server, sia nella sua versione commerciale e supportata da Sun Microsystems che in quella Open Source denominata GlassFish. I clienti non devono più scegliere tra una versione Open Source ed una con features enterprise per effettuare un deployment in contesti medio/grandi di applicazioni Java EE 5.

Tale standard porta con sè notevoli benefici in termini di produttività, grazie all'uso esteso delle annotations, ed in particolare introduce gli EJB 3.0 con le Java Persistence API, le JSF 1.2 per il livello presentation e le API  JAX-WS 2.1 e JAXB 2.0/2.1 per lo sviluppo dei Web Services.
Ma è nelle features Enterprise che questa versione presenta le maggiori novità rispetto al passato. Per iniziare, da questa versione non esiste più la tradizionale distribuzione basata sulle edizioni: platform, standard ed enterprise. La distribuzione è unica e viene introdotto il concetto di profile, attraverso il quale abilitare le features richieste dal tipo di livello di servizio che si vuole garantire per l'applicazione. 

I servizi di clustering permettono il deploy su istanze multiple della stessa applicazione, garantendone il fail-over oltre che con il tradizionale HADB, anche con il nuovo meccanismo di In-Memory Replication che permette di duplicare le sessioni tra le istanze, basando il tutto sulla nota tecnologia peer-to-peer JXTA. La gestione è completamente centralizzata ed il deploy avviene da un'unica postazione che è in grado anche di  monitorare tutte le istanze.

L'interoperabilità con i Web Services sviluppati con Microsoft .NET 3.0 è garantita dalla stretta collaborazione tra le due società in termini di definizione, implementazione e tuning dello stack. Il risultato è il Progetto "Metro", lo stack web services disponibile in Glassfish e Sun Java System Application Server 9.1.
Questa piattaforma, inoltre, è dotata di un completo supporto JBI per il deployment di applicazioni orientate alla SOA, includendo Open ESB con il motore BPEL, il tutto senza tralasciare il supporto per l'autenticazione, attraverso Sun Java System Access Manager che abilita il Liberty HTTP Single Sign on ed il Liberty SOA ID-WSF.

Di tutto rispetto anche le performance, documentate dal rilascio degli SPECjAppServer2004: ben 883.66 JOPS@Standard sul Sun Fire T2000 con 1 CPU da 8 core.

Per finire l'Application Server 9.1 è basato completamente sul progetto Open Source GlassFish. In altre parole, Sun Microsystems offre il supporto per GlassFish V2 attraverso il prodotto commerciale Sun Java System Application Server 9.1.

Per approfondimenti: GlassfishSJS Application Server 9.1


 


lunedì mag 21, 2007

Applicazioni server-push con Glassfish e Comet

Normalmente una connessione HTTP è eseguita in modalità sincrona.
Per ogni richiesta HTTP, il browser apre una connessione HTTP verso il Web Server e la connessione verrà chiusa non appena il risultato viene fornito. Il problema di questo approccio è che la pagina potrà essere aggiornata soltanto quando l'utente la ricarica. La soluzione migliore sarebbe inviare un messaggio al client quando accade l'evento ed il client, normalmente, non dovrebbe richiedere la pagina. Il server dovrebbe agire in modalità push verso il web browser. Questo è ciò che esattamente fa il supporto Comet da parte di GlassFish. Basato sull' Asynchronous Request Processing (ARP), Glassfish ha un'implementazione nativa di Comet con una elevata scalabilità ed affidabilità.

Per poterlo sfruttare è piuttosto semplice.

Per prima cosa occorre modificate il "domain.xml" nella directory di installazione <glassfish_Installation>/domains/domain1/config.xml

Sotto:


<http-listener acceptor-threads="1" address="0.0.0.0" ......

occorre aggiungere:

<property name="cometSupport" value="true"/>

Fatto questo, all'interno di una servlet che voglia sfruttare l'ottimizzazione introdotta da Comet, nella init() occorre:

.......
    public void init(ServletConfig config) throws ServletException {
        super.init(config);
        contextPath = config.getServletContext().getContextPath() + "/chat";
        CometEngine cometEngine = CometEngine.getEngine();        // (1)
        CometContext context = cometEngine.register(contextPath); // (2)
                context.setExpirationDelay(100\*1000);                     // (3)

    }

dove:

  1. occorre inizializzare un engine Comet
  2. registrare solo il contextPath dell'applicazione al fine di condividere le richieste asincrone
  3. settare la durata dell'engine (100 secondi)

Il metodo "doPost" della servlet mostra un altro importante uso di Comet: CometContext è l'oggetto chiave per comunicare con gli altri client della stessa applicazione Comet.

.......

 
public void doPost(HttpServletRequest request, HttpServletResponse response)
                                        throws ServletException, IOException {
       String action = request.getParameter("action");
       CometEngine cometEngine = CometEngine.getEngine();
       CometContext cometContext = cometEngine.getCometContext(contextPath);

    ..........

e per notificare un messaggio a tutti i client connessi:

cometContext.notify("Messaggio da " +request.getRemoteAddr(),CometEvent.NOTIFY, +request.getRemoteAddr(),CometEvent.NOTIFY,inServlet);                 
      
    ..........

Se a questo punto si desidera che sia il server a fare push delle informazioni  verso il browser in maniera continuativa senza richiesta occorre registrare il  CometRequestHandler all'oggetto CometContext (1):

  CometRequestHandler handler = new CometRequestHandler();
   handler.clientIP = request.getRemoteAddr();
   handler.attach(response.getWriter());
   cometContext.addCometHandler(handler);         //(1)
   return;

 Per saperne di più: http://weblogs.java.net/blog/jfarcand/

About

cdb

Search

Categories
Archives
« aprile 2014
lunmarmergiovensabdom
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today