2.5 Tiers

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.5 Tiers

Recommended

Recommended

More Related Content

More from Ugo Landini

More from Ugo Landini (6)

2.5 Tiers