google appengine
DESCRIPTION
Presentato al primo talk del Google Tech User Group SardegnaTRANSCRIPT
Google AppEngine
Sassari, 18 febbraio 2012
Agenda
1. Introduzione2. Applicazioni3. Datastore4. Task5. Services6. Conclusioni
Il ‘service’ nel cloud computing
Che tipo di servizi vengono offerti?• Software as a service• Infrastructure as a service• Platform as a service
Il cloud computing offre il computing come servizio piuttosto che come prodotto
Software as a service
•Detto anche ‘software on demand’
•SW e dati sono centralizzati dal provider
•I client accedono usando un thin client, normalmente tramite interfaccia web
•I client pagano abbonamentoper l’utilizzo del software
SOFTWARE
PLATFORM
SERVERS
<<use>><<use>>
Infrastructure as a service
•Viene fornita una infrastruttura HW remota che può essere controllata con appositi tool o web services
•Il service provider è responsabile del mantenimento di tali risorse remote
•Lo strato applicativo (framework e software) al di sopra dell’HW è a cura del cliente
SOFTWARE
PLATFORM
SERVERS
<<configure>><<install>>
<<deploy>>
Platform as a service
SOFTWARE
SERVERS
<<monitor>>
<<deploy>>
PLATFORM
•Il service provider fornisce piattaforme remote (basate ad esempio su J2EE o .Net)
•I client possono deployare le loro applicazioni su tali piattaforme
•Non è a carico del client la configurazione e ottimizzazione dell’hardware e dei server
Services
Microsoft Azure.Net/IIS/SqlServer
HerokuRuby/Java/Scala/Python
Force.comRuby/Java/Scala/Python
Google AppEngineJava/Python
PLATFORMAS A SERVICE
INFRASTRUCTUREAS A SERVICE
Amazon EC2
Google AppEngine
• piattaforma di sviluppo e di hosting di web applications di Google• le app e lo store relativo vengono distribuiti su più server•La tecnologia sottostante è la stessa dei siti web di Google• permette di interagire in modo semplice con altri servizi di Google•il servizio è gratuito entro una determinata soglia
Agenda
1. Introduzione2. Applicazioni3. Datastore4. Task5. Services6. Conclusioni
Creazione applicazioni
Dal sito appengine.google.com
Bisogna avere un account Gmail
Alle applicazioni viene assegnato l’url APP_ID.appspot.com
Si possono creare fino a 10 applicazioni con lo stesso account
Sviluppo applicazioni
GAE supporta Java 5 e Java 6 GAE mette a disposizione il sdk e un plugin per EclipseLe applicazioni sono normali web application J2EE• Possono essere sviluppate con
qualsiasi IDE
In WEB-INF/lib devono essere presenti le librerie Google AppEngine
Configurazione applicazioni
In WEB-INF deve essere presente il file appengine-web.xml, che contiene metainfo utili per il deploy dell’applicazione
<appengine-web-app xmlns… <application>APP_1</application> <version>1</version> <sessions-enabled>true</sessions-enabled> <system-properties><property name="java.util.logging.config.file“… </system-properties> <static-files> <include path="/js/**"/> </static-files>…
Deploy applicazioni
appcfg update
V1
Google AppEngine
APP_ 1
Il deploy viene eseguito da linea di comando utilizzando il tool appcfg (presente nel sdk)
<appengine-web-app xmlns…<application>APP_1</application> <version>V1</version>…
Static files
Static files servers
Frontends
Google AppEngineappcfg update
Una applicazione può specificare quali sono i suoi files staticiGAE provvedere a piazzare questi su web server piuttosto che farli processare dall’application server
<static-files> <include path="/css/**"/> <include path="/flash/**"/> <include path="/img/**"/> <include path="/js/**"/> </static-files>
Configurazione performance applicazioni
Potenza della macchina (più è potente, più consuma la soglia gratuita)
Numero instanze dell’applicazionenel pool
Latenza minima: il tempo che le request devono restare in coda prima di essere processate da una instanza
Mappaggio app su proprio dominio
Di default l’applicazione è sul dominio APP_ID.appspot.com
GAE supporta il mappaggio di app su un altro dominio• ma non su ‘naked domains’:
esempio, http://mydomain.com
Se è associata ad un dominio differente, le chiamate https possono essere fatte solo sul dominio appspot
Architettura
Google AppEngine
Static files servers
Frontends
Un load balancer distribuisce lerequest su uno o più server di Frontend
request
I frontend identificano a partire dal dominio l’applicazione coinvolta, e controllano le configurazioni relative.
Se il path è relativo ad un file statico, la request viene mandata agli static files server
Architettura
Google AppEngine
Services
Application servers Datastore
Frontends
request
Se la request viene riconosciuta come ‘dinamica’, viene indirizzata agli application servers
L’application server pool utilizza una nuova istanza dell’applicazione su un server, o ne utilizza una già esistente
Gli application servers usano varie strategie per distribuire le request ed iniziare instanze dell’applicazione
Sandbox
Google AppEngine
APP 2
APP 3
• Le applicazioni girano in un contesto isolato (sandbox)•La sandbox assicura che le apps possano solo eseguire azioni che non interferiscano con le performance e la scalabilità di altre applicazioni•Analogo al concetto delleapplet java
I services di AppEngine sono fuori dalla sandbox
Services
APP 1
Sandbox
Limite SoluzioneUna applicazione in GAE non può scrivere files nel filesystem del server
Utilizzo dei Blob e di BlobStoreService
Può accedere ad altri server in Internet solo in http
Servizio UrlFetch
Altri computer possono accedere all’applicazione solo usando http ed https sulle porte standardPossono essere usate solo alcune delle classi di JRE
Google mette a disposizione opportuni sostituti
Le request possono durare max un minuto
Per processi lato server più lunghi si usano i task, per upload di grossi files si usa BlobStoreService
Agenda
1. Introduzione2. Applicazioni3. Datastore4. Task5. Services6. Conclusioni
Datastore
High replication datastore Master slave datastore•è la scelta di default per le applicazioni•altamente disponibile•altamente affidabile•replica realizzata usando l’algoritmo Paxos
•adatto per applicazioni che non richiedono alta disponibilità dei dati
Il datastore NON è un database relazionale, ma supporta le transazioni:•Livello isolamento transazioni: SERIALIZABLE•Livello isolamento fuori da una transazione: READ COMMITTED
Datastore - interazione
DataNucleus Access
Platform
Datastore API
JPA1.0
JDO2.3
Application
L’applicazione può interagire con il datastore in 3 modi differenti:• Datastore API• Java Data Object (versione 2.3)• Java Persistence API (versione 1.0)
L’utilizzo di JDO e JPA consentono di migrare più facilmente l’applicazione fuori dal contesto GAE
JPA
L’implementazione di JPA non presenta alcune features, che prevedono l’utilizzo di un database relazionale
Caratteristiche non supportateRelazioni many to manyAggregation queries (group by, having, sum, avg, max, min)Query polimorfiche: non si può fare la query di una classe e ottenere istanze delle sottoclassi.
JPA - configurazione
DatastorePersistenceProvider è l’implementazione del provider(implementazione dell’ interfaccia PersistenceProvider di JPA)
Datanucleus presenta numerose properties che consentono la configurazione di JPA nel modo più opportuno
<persistence xmlns="http://java.sun.com/xml/..." …><persistence-unit name=“app1pu"> <provider> org.datanucleus.store.appengine.jpa.DatastorePersistenceProvider </provider> <properties>… </properties></persistence-unit></persistence>
@Entity(name = “Image")public class Image { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Key id;
@Entity(name = "Folder")public class Folder { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Key id; private List<Folder> subfolders; @OneToMany(cascade = CascadeType.ALL) private List<Image> images;
One to many - esempio
FolderImage
La classe Key delle API Google deve essere usata se l’entity è in relazione one-to-many con altre entity
One to many - esempio
Nel datastore di GAE, la chiave di Image è calcolata anche in rapporto alle chiavi delle entity correlate
Abbiamo legato la classe dell’entity ad una classe proprietaria
Agenda
1. Introduzione2. Applicazioni3. Datastore4. Task5. Services6. Conclusioni
Task
I task consentono:• di gestire operazioni di backend che non richiedono una request dell’utente• di eseguire operazioni che richiedono più del tempo concesso ad una request
Tipologie di task:• Task queue• Scheduled task
Task queue
CaratteristicheIl task risponde in POST ad un determinato URLPuò ricevere una payload con parametri e datiSe messo in coda in un contesto transazionale, viene accodato solo se la transazione va a buon fineGAE ritenta il task se non è andato a buon fine
Il task viene messo in coda e nel frattempo viene subito restituita una response all’utente
Task queue
Browser
1 - HTTP Request /executor
/task_1
2 –assigntask
3- HTTP Response
Task queue
2 –launchtask
APP 1
name: juliet,surname: capuleti
<<HTTP POST>>
TaskOptions taskOptions =TaskOptions.Builder.url("/task_1").param(“name", “juliet”)..param(“surname”,”capuleti”).Queue queue = QueueFactory.getDefaultQueue();queue.add(taskOptions);
Scheduled Task
Caratteristicheadatti per i lavori di batch, che richiedono una schedulazionerisponde in GET ad un determinato URLnon può ricevere parametrile configurazioni sono presenti nel file cron.xml (presente in WEB-INF)
Un task schedulato viene lanciato dal framework con frequenza stabilita
Scheduled task
/cron/reports
launchtask
APP 1
<<HTTP GET>>
Task scheduler
Google AppEngine
appcfg update
<cronentries><cron><url>/cron/reports</url><description>..</description><schedule>every day 23:59</schedule><timezone>America/Los_Angeles</timezone></cron>…
cron.xml Lo scheduler lancia il task a seconda delle informazioni presenti in cron.xml
Agenda
1. Introduzione2. Applicazioni3. Datastore4. Task5. Services6. Conclusioni
Services
Service UtilizzoBlobstore service Upload grossi filesImage service Gestione delle immagini (sopperisce ad
ImageIO che non si può utilizzare)URL Fetch Comunicare con altri servizi in reteMail service Implementazione di javax.mailMemory cache Cache dei contenutiUser service Interazione con la gestione utenti di Google
I services, oltre ad offrire valore aggiunto, sopperiscono ad alcuni restrizioni della sandbox
Blobstore Service
CaratteristichePermette il caricamento di grossi file (superiore ai 3 MB)Non vale il limite di 1 minuto sulla requestPrevede principalmente l’upload fatto dagli utenti• il caricamento dei blob server to server è in
sperimentazioneL’app può accedere ai blob tramite opportune APIDa console si possono vedere e gestire i blob caricati
Permette il caricamento/gestione di files statici (immagini ad esempio)
Blobstore Service
JSP
Blobstore service
2 - insert
/page_1
3 - redirect
<form action= "<%= blobstoreService.createUploadUrl("/page_1") %>”>… </form>
1 - submit
APP 1
Blob repository
Google AppEngine
URL Fetch
CaratteristicheUsa solo i protocolli HTTP/HTTPSUsa i seguenti HTTP methods:• GET• POST• PUT• HEAD• DELETE
Può essere usato in modalità asincrona
Permette di comunicare con altri servizi esposti in rete
URL Fetch - parametri
Parametro Utilizzo
allowTruncate Le response troppo grandi vengono troncate e restituite senza errore
disallowTruncate Se la response è troppo grande, torna eccezione
followRedirects Permette i redirectvalidateCertificate In una connessione https
viene controllata la catena di certificati
doNotValidateCertificate In una connessione https non viene controllata la catena di certificati
URL Fetch – chiamate asincrone
Il metodo call dell’oggetto result può essere invocato anche in un secondo momento
Se all’invocazione la response è disponibile, viene restituita
Altrimenti il sistema rimane in attesa della response
Offre statistiche sulla cache, ad esempio il peso totale di tutti gli oggetti in cache Supporta le operazioni asincrone
• interfaccia java standard• rende più semplice la migrazione• mancano alcune feature
MemCache Service
MemCache Service
JCache Impl
Lowlevel API
JCache API(JSR 107)
JCache API
Low levevl API
Il servizio permette di gestire il caching dei contenuti
Application
Agenda
1. Introduzione2. Applicazioni3. Datastore4. Task5. Services6. Conclusioni
Pro e contro
Non bisogna occuparsi di molti dettagli sistemistici
Implementazione di molti standard Java
Facilità nelle configurazioni e nel deploy
Possibilità di utilizzare svariati framework nello sviluppo
Possibilità di utilizzare in modo semplice l’infrastruttura Google sottostante
Alcuni dei servizi sono ancora in beta e in sperimentazione
L’approccio non SQL non è di immediato apprendimento
Costi: la soglia gratuita può essere facilmente superata
La sandbox non consente l’utilizzo di determinate API
Gli standard Java non sono sempre implementati al 100%
Esempio
CMS sviluppato come concept di un progetto:• con gestione e manipolazioni di immagini
• Spring 3• MVC: parte di presentazione, servizi REST• Spring Security: integrato con il meccanismo
di autenticazione di Google (UserService)• JPA: persistenza dei dati• jQuery
Contesto
Framework/API
Esempio
Lasciarsi una ‘via di fuga’:•isolando le dipendenze da API Google in moduli specifici:• con opportuni design pattern (strategy, bridge, abstract
factory)• con la dependency injection di Spring
• utilizzando interfacce standard come JPA
Strategia
•molte feature di JPA hanno ‘strani comportamenti’• ad esempio le relazioni one-to-many
• Image Service non consente il trattamento avanzato delle immagini
Problemi riscontrati