2.5 Tiers

U. Landini & L. Fugaro - [email protected] - JUG Roma

Javaday IV – Roma – 30 gennaio 2010

Web 2.0 o 1.0?

Ugo Landini & Luigi Fugaro, Jug Roma

sabato 30 gennaio 2010

mailto:[email protected]




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 fisica

• Anni di gloria degli Application Server

• Problemi di scalabilità impliciti

• difficoltà 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 artificale fra client e server sono stateful per natura

• Stateful: JSF, Wicket

• no scalability, dimensionamento difficile

• 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 identificativo 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/find/&q=”boh” findUser(“boh”)




http://my.com/user/ugol








http://my.com/users

http://my.com/users

http://my.com/findUser

http://my.com/findUser



PUT vs POST

PUT(new resource)

PUT(existing resource)

POST

/weblogs NA NO EFFECT Crea un nuovo weblog

/weblogs/myblog Crea il blog myblog

Modifica settaggi di

myblog

Crea nuova entry nel weblog

/weblogs/myblog/entries/18

NA(chi ti da la

URI?)Edit entry 18

Posta un commento alla

entry 18






Safety & Idempotenza

• Safety

4 x 1 x 1 x 1 = 4 x 1 = 4

• Idempotenza

4 x 0 = 4 x 0 x 0 x 0

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






http://my.com/users/ugol/delete

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 oggetto javascript (ma anche Java)

• RFC 4627

• Formato semplice per scambiare oggetti: alternativa light ad XML (meno verbosa)

{ "firstName": "Luigi", "lastName": "Fugaro", "address": { "streetAddress": "via G.Belli", "city": "Roma", "postalCode": “00100” },

"phoneNumbers": [ "346 1234567", "330 8901234" ] }






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 grafici 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/




http://jtemplates.tpython.com

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 notifiche 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 Affinity.






Enterprise

2.5 tier & Enterprise






Scalabilità

• 2.5 tier scala all’infinito

• 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 fino 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 è semplificata

• 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 graficamente (ok, solo se avete un grafico 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 RomaLuigi Fugaro, Jug Roma




2.5 Tiers

Technology

Transcript of 2.5 Tiers