�ݺ�ߣ

Web 2.0 o 1.0?

Ugo Landini & Luigi Fugaro, Jug Roma
U. Landini & L. Fugaro - ugol@computer.org - JUG Roma
Javaday IV – Roma – 30 gennaio 2010
sabato 30 gennaio 2010

2.5 tiers

• Agenda
• What’s hot
• Un po’ di storia
• 2.5 tier
• REST con RESTEasy
• Rich client con JQuery
• Conclusioni


C’è chi fa cose del genere oggi...


280slides, come hanno fatto?

• Replica dell’intero stack Cocoa di Apple nel
browser (Cappuccino)
• Creazione di un nuovo linguaggio, a partire da
Javascript: Objective J
• Creazione di un equivalente dell’Interface Builder di
Apple
• Binding evoluti, eventi, ecc.
• IDE completamente browser based (Atlas)
• Non vogliamo arrivare a tanto, ma ...


280slides, come?

Un po’ di storia


Evoluzione

Dal Paleolitico al Neolitico, passando per il Mesolitico


Paleolitico

• Applicazioni Client server
• Two tiers
• Fat Client (Visual Basic, Delphi, ecc.)
• Query dirette sul DB
• Manutenibilità complessa
• Performance elevate


Mesolitico

• Entra in scena il Web, che di fatto uccide il Client/
Server
• Thin client e non più Fat client
• Three tiers (o più precisamente, n-tiers)
• Separazione logica ed anche ﬁsica
• Anni di gloria degli Application Server
• Problemi di scalabilità impliciti
• difﬁcoltà ad essere stateless

Patterns

• Perchè utilizziamo MVC server side?
• Per motivi storici
• Javascript era un incubo, ed i browser avevano
problemi anche con dell’html semplice
• Ormai è questione di abitudine
• Ci sembra normale che la GUI venga generata dal
server
• Non lo è


Mesolitico


Neolitico

• Ajax ha reso possibile oggi dei Rich Client, e
dunque un ritorno ad un 3-tier
• Per i Rich Client ci sono però molte tecnologie a
disposizione
• Tecnologie come JavaFX, Flex, Silverlight,
OpenLaszlo, ...
• ma anche GWT, JSF, Wicket, ed altre librerie Java-
oriented
• ognuna con pro e contro diversi

Stateless vs Stateful

• Stateless è considerato da sempre il miglior modo
per scalare
• Le tecnologie che creano un mapping artiﬁcale fra
client e server sono stateful per natura
• Stateful: JSF, Wicket
• no scalability, dimensionamento difﬁcile
• Stateless: Javascript diretto, generatori di Javascript
(GWT)


Neolitico


Neolitico

• Nel Neolitico è decisamente possibile fare rich
client solo con il browser
• Javascript (con JQuery) è la tecnologia abilitante
• JSon il formato dati, Ajax il protocollo, REST
l’architettura
• HTML 5 a seguire, è completamente in linea con
questa architettura


Come si realizza un 2.5 tier

• JQuery
• Libreria Javascript per consumare servizi REST e creare
componenti riusabili
• si, funziona anche su IE6 :)
• Esposizione dei dati come servizi tramite librerie
REST
• JAX-RS è lo standard
• RestEasy è la migliore implementazione, ma ce ne sono
altre

REST

REST in a Nutshell


REST Architecture in una slide

• Dissertazione PHD di Roy Fielding (coautore di
HTTP), 2000
• REpresentational State Transfer
• Ovvero, usare il Web così com’è per far
collaborare le applicazioni: HTTP è molto più
ricco di quanto si creda!
• Soprattutto in antitesi a WS-* (SOAP, WSDL,
UDDI, ecc.), anche se Roy Fielding presentò un
concetto più ampio

REST Architecture in una slide

• HTTP a pieno potenziale
• PUT, POST, GET, DELETE (l’equivalente di un CRUD)
• ma anche OPTIONS, CONNECT, TRACE, HEAD
• URI come identiﬁcativo di una risorsa (Addressability)
• Uniform interface (ogni risorsa deve essere acceduta
allo stesso modo)


REST verbs

Method URI RPC
GET http://my.com/users/ugol getUser(“ugol”)
POST http://my.com/users addUser()
DELETE http://my.com/users/luigif removeUser(“luigif”)
PUT http://my.com/users/ugol/39 updateUser(“ugol”,39)
GET http://my.com/users listUsers()
GET http://my.com/users/ﬁnd/&q=”boh” ﬁndUser(“boh”)


PUT vs POST
PUT
PUT
(existing POST
(new resource)
resource)
Crea un nuovo
/weblogs NA NO EFFECT
weblog

Modiﬁca Crea nuova
Crea il blog
/weblogs/myblog settaggi di entry nel
myblog
myblog weblog
NA Posta un
/weblogs/myblog/
(chi ti da la Edit entry 18 commento alla
entries/18
URI?) entry 18

Safety & Idempotenza
• Safety
4x1x1x1=4x1=4

• Idempotenza
4x0=4x0x0x0
ma 4 x 0 ≠ 4



GET PUT DELETE POST

SAFE SI NO NO NO

IDEMPOTENTE SI SI SI NO



• Una applicazione che sia buon cittadino del Web
deve rispettare il protocollo HTTP e la semantica
dei suoi “verbi”

METHOD URI
GOOD DELETE http://my.com/user/ugol
BAD GET http://my.com/users/ugol/delete

Safety & Idempotenza, perchè?

• Google accelerator
• client side caching tool, rilasciato nel 2005
• prefetching dei link delle pagine visitate con un
browser
• assumeva che le GET fossero safe
• NON funzionava con moltissimi siti!


REST in Java

• JAX-RS (JSR 311): The Java API for RESTful Web
services
• E’ uno standard, Jersey è la reference implementation
• Facilissimo produrre XML o JSON
• RESTEasy è una delle implementazioni migliori
• Ne parleremo diffusamente nel prossimo talk! Non
cambiate aula :)


JQuery

JQuery


JSON
• JAvaScript Object Notation {

• serializzazione di un "ﬁrstName": "Luigi",
"lastName": "Fugaro",
oggetto javascript (ma anche "address": {
"streetAddress": "via G.Belli",
Java) "city": "Roma",
"postalCode": “00100”
• RFC 4627 },

• Formato semplice per "phoneNumbers": [
"346 1234567",
scambiare oggetti: "330 8901234"
alternativa light ad XML ]
}
(meno verbosa)


JQuery

• JQuery
• JQuery è divenuta negli ultimi anni la libreria dominante
nel panorama javascript
• John Resig, l’autore di Jquery, è stato il pioniere
dell’unobtrusive Javascript
• oggi anche altre librerie vanno nella stessa direzione
• è utilizzatissima per la semplicità con cui si ottengono ottimi
effetti graﬁci cross browser
• permette di separare struttura e comportamento

Unobtrusive Javascript

• Unobtrusive Javascript
• I CSS permettono di separare la presentazione dalla
struttura
• Una libreria js unobtrusive separa anche il
comportamento dalla struttura
• Si “attacca” il comportamento alla struttura tramite dei selector
(CSS compatibili)
• Il comportamento è cross browser, ci pensa la libreria ad
applicare workaround


JQuery Simple Example


JTemplates

• JTemplates è una libreria di Templating client side
• Sfrutta JQuery
• Semplice e leggera (circa 12Kb)
• Permette di scrivere “cascading templates”
• Risolve il problema della componentizzazione delle
interfacce HTML/JS
• http://jtemplates.tpython.com/

Esempio JTemplates


JQuery e 2.5 tier

• L’idea di base dell’architettura 2.5 tier è quella di
utilizzare Javascript e JQuery per fare... tutto.
• Tenendo “ferma” l’architettura REST, dunque solo servizi
• Nessun codice lato server che non sia RESTEasy
• ok le validazioni le abbiamo lasciate lato server :)
• Tutto il resto è sul client
• Solo pagine “statiche”
• Componenti JQuery + templating Javascript (JTemplate)
• What else?

Reverse Ajax

• L’architettura 2.5 tier è Comet-compliant
• se si vuole un full MVC, con notiﬁche dirette verso le
View, si può utilizzare una delle tecnologie Comet
• Comet consiste nel tenere aperta una connessione verso il
server per ricevere gli eventi
• Termine coniato nel 2006 da Alex Russell (Server push, HTTP
push, HTTP Streaming, Pushlets, Reverse Ajax)
• diversi modi di realizzarlo, e diversi contro: attenzione ai
Firewall, alla Scalabilità, alla Server Afﬁnity.

Enterprise

2.5 tier &
Enterprise


Scalabilità

• 2.5 tier scala all’inﬁnito
• Le URI sono inerentemente scalabili. Il Web è
inerentemente scalabile. Dietro ad una URI può esserci
un semplice Tomcat, ma anche un bilanciatore hardware.
E dietro SOAP?
• Se la GUI è solo sul client, i server possono essere
stateless. E anche se le pagine diventano decisamente più
pesanti, possono sfruttare la cache del browser
• Attenzione a Comet, però.

Caching / Pipelining

• Con 2.5 tier possiamo cachare ﬁno all’inverosimile
• cache delle query verso il DB
• cache di HTTP
• Cache-Control in HTTP 1.1
• ci permette di NON trasferire verso il browser i risultati che
sappiamo non essere cambiati
• cache del browser di tutta la GUI (html e js)
• pipelining (effettuare il fetch di più risultati del necessario
e conservarli nel client)

Security

• Con 2.5 tier la sicurezza è sempliﬁcata
• Due possibili approcci
• usare un IDM (IDentity Manager)
• essendo tutta l’applicazione basata su URI, il matrimonio con
un IDM non presenta grossi problemi
• necessario plugin per l’AS se si vuole colloquiare con l’IDM per
migliorare la fruibilità e l’estetica dell’interfaccia
• utilizzare la sicurezza standard JEE, annotando
semplicemente i metodi esposti tramite REST

Server side agnostic!

• Una GUI interamente JS e che consuma JSON è
indipendente dalla tecnologia server side!
• Si possono scrivere componenti (datatable, calendari,
ecc.) e riciclarli all’interno di un’azienda complessa con
architetture miste e non monotecnologiche
• Java, .Net, Scala, Erlang, PHP, C, C++, etc.
• Si può dire che 2.5 tier faciliti il riuso all’interno di una
Enterprise più di ogni altra soluzione ad oggi conosciuta


2.5 tier

Conclusioni


Conclusioni

• Oggi è possibile utilizzare un’architettura full REST
in un’azienda enterprise
• Oggi è possibile utilizzare un MVC completamente client
side, senza ricorrere ad “aiutini”
• Le applicazioni saranno:
• indipendenti dal client e dal server, riusabili (SOA), belle
graﬁcamente (ok, solo se avete un graﬁco bravo),
performanti, e scalabili ai limiti estremi.
• perciò non è solo possibile, ma anche consigliabile...

2.5 tiers, Rest In Peace

MVC Server Side,
REST In Peace

Ugo Landini, Jug Roma
Luigi Fugaro, Jug Roma

�ݺ�ߣ

2.5tier Javaday (italian)

More Related Content

2.5tier Javaday (italian)