AJAX e Tibco General Interface. www . Java . Italian . Portal . it

Caro Simone,
inizio questa mia mail cercando di illustrarti come oggi sto vedendo cambiare le architetture Web Enterprise grazie alle nuove tecnologie standard che sono attualmente disponibili.

Sono arrivato a testare nuove possibilità dopo una serie di riflessioni che sono sicuro ti potrebbero interessare.

In questi ultimi anni ho professato nei miei corsi e nei seminari i vantaggi di una architettura basata su più tiers, e le agevolazioni che la stessa offriva in ambiti tra loro particolarmente eterogenei. Ho parlato di “Enterprise Application Integration (EAI)”, con le rispettive tecniche di integrazione a vari livelli:
• Integrazione a livello di Interfaccia Applicativa.
• Integrazione a livello di metodi (CORE Wrapper).
• Integrazione a livello di Accesso alla base Dati (Data warehouse, Gateway, …).

Affermando che soluzioni di integrazione dovrebbero offrire alcuni servizi essenziali, tali da consentire ad applicazioni e dati di comunicare ed interagire in modo corretto e sicuro quali:
• Servizi di Messaging
• Servizi di Connessione
• Servizi di Sicurezza

Ti ricordi che spesso abbiamo discusso di come la tecnologia J2EE sia in questo ambito una “Key Features” per progetti di medie e grandi dimensioni, grazie ad una vasta gamma di tecnologie:
• Java Connector Architecture JCA
• Java Naming Directory Interface JNDI
• Java DataBase Connectivity JDBC
• Java Management Extensions JMX

Non ho mai smesso di consigliare l’uso di pattern architetturali come approccio corretto per realizzare applicazioni stabili ed estendibili, filosofeggiando sulle “capabilities” di una applicazione enterprise: Availability, Reliability, Manageability, Flexibility, Performance, Capacity, Scalability, Exstensibility, Validity, Reusability, Security ..

E’ stato molto interessante anche quando abbiamo parlato di Service Oriented Architecture SOA e degli standard che la stessa richiede:
• Standard d’invocazione e di interazione con il servizio (implementazione)
• Standardizzazione della descrizione del servizio (interfaccia)
• Standardizzazione della modalità di ricerca e definizione della location dei servizi.

Mi ricordo anche, che abbiamo parlato in quella occasione del concetto di Web Services, come operazioni server side che espongono una interfaccia XML, accessibili attraverso protocolli standard, in grado di supportare anche lo scambio di documenti attraverso RPC, ed il perché del loro utilizzo :
• Integrazione di piattaforme all'interno di un contesto enterprise.
• Esposizione delle applicazioni elettronicamente.
• Aumento della visibilità da diverse tipologie di client.
• Possibili integrazioni con nuovi partner.
• Modularità delle applicazioni rispetto al software presente sul mercato.
• Possibilità di integrazione di tipo:
      o data integration
      o legacy integration
      o interface integration
      o workflow integration
      o B2B

Abbiamo anche testato i nostri web services di Javaportal, tipo quello che calcola il codice fiscale “JIPCodice” oppure le java news “JIPNews” o i Comuni d’Italia “JIPComuni”.

Ci siamo salutati parlando di Best Practices Data Caching per applicazioni Web Enterprise :

• Se il client ha problemi di “slow network communication”, considerare di comprimere i dati che vengono scambiati tra i tiers.
• Cercare di minimizzare il numero di “round-trip” tra i tiers.
• Per applicazioni con un ampio bacino di utenti contemporanei cercare di ridurre al minimo la quantità di memoria destinata al singolo user.
• Caching di riferimenti ad oggetti e dati statici.
• Cercare di ottimizzare e destinare maggior risorse hardware a parti applicative maggiormente sollecitate.

Oggi mi rendo conto che le soluzioni che proponiamo all’interno della maggior parte dei progetti, non tengono conto delle nuove accattivanti tecnologie che abbiamo a disposizione.

Circa 2 anni fa ho avuto modo di giocare con XMLHttpRequest, un oggetto JavaScript.
Ho creato una Java Server Pages JSP in cui erano presenti due TextBox, e ho fatto si che al variare dei dati all’interno delle stesse un istanza di oggetto XMLHttpRequest chiamasse in maniera asincrona ed in background il server in cui era deployata una servlet con il compito di restituire un file xml in cui scrivevo se il campo era valido ed una descrizione aggiuntiva da mostrare all’utente, questo senza che mai avvenisse il refresh della pagina ed in totale parallelismo rispetto all’utente.

Ti vorrei proporre un esempio simile, in cui il contenuto di una semplice pagina html viene popolato dinamicamente con un file XML attraverso 2 chiamate al server.

L’esempio quindi si compone di un file xml (sample.xml) un file html (sample.html) ed un file javascript (sample.js).

Il primo è un semplice file formattato secondo la sintassi xml:

<articolo>
   <ajax>
        <javaportal>
        <!- - Contenuto da mostrare a video - ->
        Ajax and TIBCO General Interface by Nino Guarnacci
        </javaportal>
   </ajax>
</articolo>

Il secondo file rappresenta una normale e vuota pagina html:

<html>
   <head>
   <! - - Richiamo del java script - ->
   <script src="sample.js" type="text/javascript">
   </script>
    </head>
<! - - Invocazione della funzione nel JavaScript - ->
<body onload="sampleCall('start', 'sample.xml', 'inside')">
<! - - Dichiarazione di un tag DIV di nome ‘inside’ - ->
   <div id="inside"></div>
   </body>
    </html>

Il terzo e ultimo file javascript contiene la chiamata al server:

// FUNZIONE RICHIAMATA DALLA PAGINA HTML
function sampleCall()
   {
   // REPERIMENTO DEGLI ARGOMENTI DI CHIAMATA
   var args = sampleCall.arguments;

   switch (args[0])
        {
        case "start":
        if (document.getElementById) {
// CREO L’ISTANZA DI UN OGGETTO XMLHttpRequest PER SAFARI,OPERA FIREFOX…
// ALTRIMENTI Microsoft.XMLHTTP PER INTERNET EXPLORER
var x = (window.ActiveXObject) ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();
            }

            if (x){
   // ISCRIVO UN LISTENER SUGLI STATI DELL’OGGETTO
   x.onreadystatechange = function(){

            // SE STA CARICANDO IL CONTENUTO
            if (x.readyState == 1){
                    el = document.getElementById(args[2]);
                    el.innerHTML = 'Waiting for Response !!!';
            }
            // SE IL CONTENUTO E’ DISPONIBILE ED INIZIALIZZATO
                       if (x.readyState == 4 && x.status == 200){
                    el = document.getElementById(args[2]);
                    el.innerHTML = x.responseText;
                                     }
        }
   // PREDISPONGO LA CHIAMATA CON LA URL

x.open("GET", args[1], true);

// EFFETTUO LA CHIAMATA PASSANDOGLI LA QUERY STRING

Incredibile ma vero, tutto funziona come mi aspettavo, se ti interessa puoi scaricare l’esempio qui
http://services.javaportal.it/kservices/article/sample.zip (LINK)altrimenti lo puoi testare a questa URL
http://services.javaportal.it/kservices/article/sample.html (LINK), anche se leggermente diverso.

In pratica ho chiamato il server in modo Asincrono utilizzando Javascript per ottenere un file Xml, diciamo che seppur in maniera banale ho sfruttato oppure utilizzato o meglio sviluppato in AJAX (Asynchronous JavaScript and XML, http://it.wikipedia.org/wiki/AJAX ).
Infatti non parlo di una singola tecnologia, ma piuttosto di una tecnica che combina l’uso di tecnologie e tecniche diverse come XML, DHTML, CSS, XHTML.

Nello script avrai sicuramente notato che avevo la possibilità di controllare lo stato della richiesta attraverso alcune proprietà dell’oggetto XMLHttpRequest :

• onreadystatechange – Handler di ascolto sugli stati della request
• readyState – lo stato corrente della request http
• responseText – il testo di ritorno dalla richiesta
• responseXML - DOM xml
• status - HTTP status code

// ESEMPIO
if (“XMLHttpRequest”.readyState == 4 && “XMLHttpRequest”.status == 200)
//

quindi ho potuto gestire ogni stadio della stessa con i rispettivi codici di stato:
• 0 – Uninitialized
• 1 – Loading
• 2 – Loaded
• 3 – Interactive
• 4 – Complete

Controllando inoltre il suo ciclo di vita con metodi molto “java style”:
getAllResponseHeaders(), getResponseHeader("header"), open("method", "URL", asyncFlag, "userName", "password"), send(content), setRequestHeader("label", "value") .

Ho quindi provato a cercare qua e la sulla rete, un prodotto valido che mi permettesse di realizzare applicazioni AJAX con semplicità, una sorta di “Rapid Application Development” RAD, e mi sono imbattuto in un prodotto di Tibco che si chiama General Interface 3.1 (GI) .

E’ esattamente ciò che stavo cercando, un RAD per AJAX con una enorme quantità di librerie con componenti aggiuntive.
In più ha un supporto straordinario per l’invocazione dinamica di “Web Services”.
L’interfaccia di G.I. è scritta anch’essa in AJAX. E quindi fruibile attraverso un browser web. Praticamente con un tool di sviluppo via web.

G.I. come application framework in grado di supportare lo sviluppo di “Rich client applications”, simili ad applicazioni desktop, richiamandone appieno il look and feel e la velocità di interazione, tutto però all’interno di un Browser Web.

Sfruttando le tecniche e le tecnologie AJAX per la comunicazione con “i server”. G.I. permette con estrema facilità la realizzazione di interfacce applicative complesse e fortemente dinamiche. Proprio perché basato su tecnologie standard non necessita di plug-in aggiuntivi, rendendo quindi la distribuzione del software applicativo del tutto automatica.

L’idea di G.I. è quella di modificare sensibilmente le tradizionali applicazioni server centriche basate su paradigma MVC, offrendo la possibilità di spostare parte della logica di controllo ed accesso al dato direttamente lato client.

Questo concetto seppur gia visitato durante gli anni passati, si enfatizza oggi grazie all’uso di più tecniche e tecnologie creando una nuova generazione di “Web Based Application”.

Oggi per realizzare una classica applicazione MVC attraverso J2EE probabilmente realizzeremo una web/enterprise application in cui demanderemo alla Servlet il controllo del flusso ad un Bean/EJB l’elaborazione della Business Logic ed ad una JSP la responsabilità di restituire al client le informazioni elaborate.

Da notare che pero solo il 20/40% dei contenuti che l’utente ha richiesto sono dati e non formattazione grafica. Immagina se tutte le volte che acquisti on-line dallo stesso sito, per ogni singolo prodotto ti siano nuovamente richiesti tutti i tuoi dati personali e quelli di consegna della merce.

Devi riuscire ad immaginare un’applicazione che permetta all’utente di avere una “vista” più complessa in cui sono autonomamente presenti alcune delle logiche di flusso ed un sistema di “cache and call” che interpeti la figura del model, tutto questo offrendo una interfaccia grafica degna di una applicazione Desktop.

Gran parte del carico macchina/memoria e della gestione “statefull” delle informazioni viene demandata al client e quindi alla macchina dell’utente finale.

I vantaggi sono molteplici, come la riduzione della quantità di dati in transito tra client e server, senza dover fare “Extreme Tuning” al server o al codice per ottenere quel secondo di performance in più, giusto per farmi restituire un quantità di stringhe HTML, necessarie solo a ridisegnare la grafica del client.

Demandando comunemente la gestione della sicurezza e della transazionalità direttamente sul server, attraverso il controller ed il model, svolgendo attività proprie del paradigma.
In più sfruttando la standardizzazione delle tecnologie mi adopero per costruire una nuova generazione di architetture in cui il server principale offre l’utilizzo del client, aggiornandolo e distribuendolo continuamente a costo zero, permettendo inoltre una vera e propria interazione con più server, da parte di uno stesso client.

Ma mentre osservo questa immagine, mi viene in mente una architettura già studiata e conosciuta, SOA. La “Service Oriented Architecture”, mi permette di “Concertare” più servizi in maniera dinamica e trasparente.

Quindi ho deciso di utilizzare quei web services di javaportal di cui accennavo prima , e realizzare un client AJAX con G.I. nel quale interagisco con i diversi servizi direttamente lato client, gestendone la cache e le dinamiche di interazione e trasporto.

Graficamente mi ha dato una mano G.I. quindi ho utilizzato alcuni oggetti già presenti nel framework, il risultato finale è per me stupefacente.
“Un client scaricato a runtime che interroga Web Services diversi, gestendone le logiche applicative”. Ho deciso di pubblicarlo come Beta Client, guarda se ti piace, lo trovi qui http://services.javaportal.it/kservices/betaclient.html , per ora gira solo con Internet Explorer 6.x, ma mi riprometto di renderlo “browser indipendent” quanto prima.

I tempi che ho impiegato per sviluppare il client sono realmente ristretti, circa 2 ore, dovute soprattutto alla mia quasi completa inattitudine alla grafica, e siccome so che come al solito sei scettico ho girato un “desktop video” per te in cui ti mostro passo passo le operazioni da seguire per creare un Client Grafico per Web Services con AJAX e G.I. in soli 5 minuti, guardalo lo trovi qui http://services.javaportal.it/kservices/article/video_jipnews.html , il WSDL che ho utilizzato per questa dimostrazione lo trovi qui http://services.javaportal.it/kservices/JIPNews.jws?wsdl .

Ho anche scoperto che TIBCO General Interface viene distribuito con diverse forme di licenza, te le incollo in copia qui sotto:

Developer License
There’s no cost to use TIBCO General Interface Professional Edition – the highest rated AJAX toolkit in the industry. Develop and test your solutions for free with the Developer License. Then when you’re ready to deploy, there are multiple deployment licenses available to fit your needs.
Public Deployment License
If your application is accessible via the World Wide Web at no cost to the general public then you can deploy under the terms of the Public Deployment License for free. View this License Agreement for details. If your application is not accessible for free to the general public via the World Wide Web, then you need to purchase a license for that private use.


Sitemap	© 2002-2004 Copyright Information. Privacy .	Today is	domenica 1 agosto 2010