Série de billets sur Google App Engine

Version imprimable

17/05/2009, 18h30
benwit

Série de billets sur Google App Engine
Bonjour à toutes et à tous,

Je me suis lancé dans l'écriture d'une application GAE et j'aimerai partager cette expérience avec vous à travers une série de billets :
Je travaille dans l'ombre et comme Developpez.com veut allumer un gros projecteur, venez nombreux vous mettre devant :mouarf:

Généralement, à la fin d'une conférence, le speaker demande si on a des questions ?
Puisque c'est le début, je vais vous posez quelques questions et je vais vous demandez des réponses !

:arrow: Connaissez vous GAE ? Et si oui, qu'en pensez vous ?

:arrow: Pensez vous l'utilisez prochainement ? Pour déployer une application existante ? Pour en créer une de toute pièce ?

:arrow: Est-ce que l'offre de google vous incite encore plus à écrire en Java maintenant qu'il existe une offre de déploiement "gratuite" et facile ?
17/05/2009, 20h48
Baptiste Wicht

Bonjour benwit,

Citation:

Connaissez vous GAE ? Et si oui, qu'en pensez vous ?

Je ne le connaissais que de nom, et encore, mais je suis allé me renseigner après avoir lu tes billets de blogs. A première vue, ça a l'air très intéressant.

Citation:

Pensez vous l'utilisez prochainement ? Pour déployer une application existante ? Pour en créer une de toute pièce ?

Je pense essayer de déployer une application sur le Google App Engine, mais pas encore tout de suite,mais dès que j'aurai un peu de temps.

Citation:

Est-ce que l'offre de google vous incite encore plus à écrire en Java maintenant qu'il existe une offre de déploiement "gratuite" et facile ?

Ca pourrait m'inciter à faire plus de développement web pour moi, oui :)

En tout cas, merci pour tes billets.
22/05/2009, 22h06
Ricky81

Salut,

Vraiment instructifs ces billets :D

Google montre bien avec tout ca que ce n'est pas qu'une boîte avec des pointures techniques. Tout est bien pensé pour aller dans le sens du business model Google, et ca ca force le respect.

L'une des métriques pour l'allocations de ressources m'a interpellé : l'envoi de mail.
En effet, c'est un peu un comble de potentiellement devoir payer pour que son application puisse envoyer davantage de mails, sachant que l'utilisation de gmail est gratuite. Je suppose qu'il est possible d'utiliser son propre serveur smtp, et j'ose espérer que cela permet de contourner cette contrainte ?

Eric
22/05/2009, 22h31
benwit

Salut,

Je subodore que c'est pour éviter que soient créée des applications de "Spam".
Je n'ai pas trop regardé cette partie. Il semblerait néanmoins que l'utilisation de leur api de mail utilise un de leur serveur smtp :

Citation:

When creating a JavaMail Session, you do not need to provide any SMTP server configuration. App Engine will always use the Mail service for sending messages.

Je suppose également que l'on peut utiliser un autre serveur smtp mais il reste à voir comment c'est comptabiliser ?
Peut être dans les "url fetch" car on doit être également limité pour interagir avec d'autres serveurs. Il semblerait que la communication vers l'extérieur passe obligatoirement par http/https.

A creuser ...
23/05/2009, 14h49
*alexandre*

Je viens de créer un compte et me renseigne également si l'app engine supportera mes développements

Je note déjà que spring 3.0 est supporté http://www.ardentlord.com/apps/blog/...gle-app-engine

MyFaces l'est également mais je me demande si ICEFaces le sera, quelqu'un à des infos ? (EDIT : http://www.icefaces.org/JForum/posts/list/12361.page)

Je sais également que hibernate n'est pas supporté

Il y a quand même pas mal de restrictions : http://java.dzone.com/articles/googl...ine-where-does
23/05/2009, 20h25
benwit

Citation:

Envoyé par *alexandre*

Il y a quand même pas mal de restrictions : http://java.dzone.com/articles/googl...ine-where-does

Oui, c'est vrai mais c'est un début ... Gageons que ça ne peut que s'améliorer.
Si on prend l'exemple de GWT, depuis la première version, c'est en progrès.
01/06/2009, 21h34
Antoine_935

Ca m'a l'air pas mal du tout ce service de google :) De plus les conditions d'utilisations sont claires en ce qui concerne les droits intellectuels, c'est bien.

Néanmoins il y a un détail qui m'empêche un peu d'aller plus loin:
développer une application chez google signifie qu'elle sera à jamais dépendante de cette architecture. C'est un peu dommage, puisqu'on pourrait vouloir un jour l'installer sur un serveur privé, et pour différentes personnes.

Qu'en pensez-vous ?
01/06/2009, 21h39
*alexandre*

C'est un peu normal que lorsque tu déploies une application sur ce type d'architecture que tu sois liés.

Google propose et diffuses ses standards ... le private cloud computing n'est pas (ou du moins pas pour l'instant proposé) (mais le cloud de Sun est toujours ouvert aux propositions...)
01/06/2009, 22h01
Antoine_935

Citation:

Envoyé par *alexandre*

Google propose et diffuses ses standards ... le private cloud computing n'est pas (ou du moins pas pour l'instant proposé)

C'est vrai, mais ici on ne se sert pas directement du cloud, on pourrait tout aussi bien s'en passer.

Par contre on est directement lié à leur api, et ça on ne peut rien y faire, puisque même leurs conditions d'utilisations interdisent le reverse (normal en soi), ce qui signifie que personne ne pourra créer des classes "identiques" pour pouvoir un jour redéployer cette application hors de google, en privé.
01/06/2009, 22h03
*alexandre*

Il existe dors et deja plusieurs autres implementations de cloud qui sont moins restrictives mais je ne comprends pas tes besoins que veux tu dire par reverse ?

Ce qu' il faut comprende du cloud c est qu il existe au maximunm dans le cloud une et une seule classe qui sera référencé lors des appels, le tout au travaux de tout cloud privé (ou distribué)

Une classe de référence accessible au travers de ton clloud

Et tous mes propos sont plus relatifs au Cloud de Sun ...
01/06/2009, 22h31
Antoine_935

Ce n'est justement pas le cloud qui m'intéresse. De ça je m'en fiche pas mal. Puis de tte façon c'est le bazar interne de google et on ne peut pas y toucher ;)

Non, c'est leur api java qui viendrait à manquer si on voulait sortir notre applicaiton de leurs serveurs :(
02/06/2009, 12h35
nicorama

AppEngine & GWT : Tout cela me parait excellent. Après avoir vu la démo de Google Wave, il peut sembler assez tentant de concilier GWT + Wave + AppEngine afin de bénéficier de futures librairies.

Mais c'est vrai que si tout est "standard", pourquoi tout remettre à Google ?

Malheureusement, si on regarde l'offre de Sun :
http://www.sun.com/solutions/cloudcomputing/index.jsp

Dites-moi où sont les PC ? Où on signe ? Comme d'hab, c'est pas clair, alors que Sun devrait petre les premiers à offrir un cloud computing avantageux et simple à déployer.
02/06/2009, 18h55
benwit

Citation:

Envoyé par Antoine_935

Néanmoins il y a un détail qui m'empêche un peu d'aller plus loin:
développer une application chez google signifie qu'elle sera à jamais dépendante de cette architecture. C'est un peu dommage, puisqu'on pourrait vouloir un jour l'installer sur un serveur privé, et pour différentes personnes.

Qu'en pensez-vous ?

C'est intéressant comme remarque, ça me donne des idées pour écrire un autre billet. Peut être pas le prochain, mais bientôt ... je vous tiens au courant.
04/06/2009, 08h10
Baptiste Wicht

Salut,

Je suis allé voir hier soir sur Google Apps pour m'inscrire, mais je commence à mélanger leur différents services d'hébergement (Apps, Sites, App Engine)...

Quels sont les différences entre Google App Engine et Google Apps ?

J'ai vu qu'il fallait un nom de domaine sur Google Apps et j'ai vu aussi qu'un domaine était proposé à la création. En passant par eux, est-ce que je pourrais contrôler mon domaine (cname, ...) ?

A+
04/06/2009, 09h09
benwit
@ Baptiste

Ce sont deux services bien distincts qui peuvent être séparés l'un de l'autre mais qui gagnent à être utilisés conjointement.

:arrow: Google App Engine, c'est le "moteur" qui permet de faire tourner des applications Python ou Java sur l'infrastructure de Google. (On peut appeler ça leur cloud computing)

:arrow: Google Apps, c'est une suite d'applications (email, agenda, documents, ...) à destinations des entreprises, associations ... Dans cette suite, à toi, en tant qu'administrateur de créer des comptes pour les personnels de ton entreprise ou pour les adhérents de ton association.

Dans les deux cas, tu as une version de base gratuite et ensuite des versions premium payantes.
Avec la version de base de Google Apps, tu peux créer jusqu'à 50 comptes gmail de 7Go avec ton nom de domaine !!!

Utiliser les deux te permet :
- d'accéder à tes applications GAE à partir de ton domaine Google Apps (cf mon billet)
- de développer des applications GAE accessibles uniquement par les membres de Google Apps (cf mon billet).
Pour s'inscrire à Google Apps, deux alternatives s'offrent à toi :
- Soit tu utilises un nom de domaine que tu possèdes ailleurs (ce qui étais mon cas)
- Soit tu en achètes un via les partenariats que Google propose.
Je suppose qu'en passant par eux :
- tu as comme moi un contrôle de ton domaine (dans la limite de ce que propose le registrar bien entendu)
- le gros intérêt semble de pouvoir modifier directement ces cnames depuis leur interface Google Apps (Ce que moi, je n'ai pas et qui peut être un peu pénible sinon)
Tu comprendras que comme je n'ai pas essayé cette deuxième alternative, je ne peux rien te garantir sur ce sujet, je peux seulement te dire ce que j'ai compris.
Tu feras comme tu voudras mais si c'est cette version que tu choisissais, ton retour en intéresserait plus d'un (moi le premier).

@+
04/06/2009, 10h15
Baptiste Wicht

Merci c'est très clair :)

Maintenant, je vais me permettre d'abuser de tes connaissances :aie:

Admettons que je crée un domaine pour Google Apps directement depuis Google Apps et qu'ensuite je crée un site Google Sites et que je configure mon site pour être affiché sur mon domaine que je viens de créer, est-ce que je pourrai en plus mettre des fichiers sur le domaine moi-même ?

C'est assez tordu comme question :aie:
04/06/2009, 14h24
benwit
Il faut distinguer deux choses :
- le domaine
- l'hebergement
Avec le dépôt d'un nom de domaine, c'est uniquement une sorte "d'alias" que tu loues et qui pointe vers des machines physiques. Ces "alias" sont enregistrés dans les serveurs DNS d'internet.

Souvent, domaine et hébergement sont couplés dans une même offre car :
- ceux qui ont un domaine doivent bien pointer vers une ressource physique.
- ceux qui ont un hébergement ne veulent généralement pas accéder directement à leur ressources par la seule adresse IP.
Les hébergements peuvent être de différents types :
- serveur mutualisé (partagé par plusieurs domaines, pré-configuré, où tu disposes d'un espace de stockage et de logiciels déjà installés, ...)
- serveur dédié chez ton hébergeur (tu fais ce que tu veux au niveau logiciel, tu peux généralement changer d'options au niveau matériel...)
- serveur dédié chez toi (tu fais ce que tu veux logiciellement et matériellement)
Si tu m'as suivi et si j'ai été assez clair, tu comprend qu'avec un nom de domaine seul, tu ne fais pas grand chose ... (au mieux, avec un dyndns, tu pourrais pointer sur ton pc)

L'intérêt de ton domaine et des sous domaines est de pointer vers des adresses IP avec des noms plus faciles à retenir que des numéros ...
En utilisant mon domaine avec Google Apps, je fais pointer mes sous domaines vers les différents "services" de google apps.

Ainsi, par exemple, avec le domaine benwit.fr
Code:

1 2 3 www.benwit.fr pourrait pointer vers Google Site agenda.benwit.fr pourrait pointer vers Google Calendar
et ainsi de suite ...

En achetant un domaine avec Google Apps, à priori, tu dois pouvoir faire directement ces réglages dans leur interface.
Moi, il faut que je le fasse des deux côtés : chez mon registrar et dans Google Apps.

Après, Google Site (qui est un des services applicatifs de Google Apps), je ne connais pas (je ne m'en sers pas pour l'instant) mais je ne crois pas que tu disposes d'un espace pour mettre tes fichiers toi même (au mieux, peut être par upload et encore ?).

Utiliser Google Apps avec son domaine, c'est avant tout faire pointer son domaine vers des machines de Google sur lequel tu n'as pas "la main".

Il faudrait un service Google (idéalement dans Google Apps) où on puisse mettre nos fichiers et avoir des urls (de son domaine) pour y accéder ... Je ne sais pas si un tel service existe à l'heure actuel ?

Le seul moyen de mettre mes fichiers en ligne que j'imagine actuellement est de mettre des fichiers dans mes applications GAE (1000 fichiers statiques x 10 applications = 10000 fichiers pour un total de peut être 500Mo/application ) et de les servir via une servlet (une par application) mais c'est plus de la bidouille.

Il est prévu dans la roadmap de GAE :

Citation:

Future Releases: January 2009 - June 2009
Service for storing and serving large files

Vivement que ça vienne ... ;)
04/06/2009, 16h04
Baptiste Wicht

Merci pour les explications, c'est très clair :ccool:
04/06/2009, 22h35
*alexandre*

Google app n'a rien inventer ca reprend le principe d'amazon pour de déployement d'une application sur un cloud

Mais j'aimerais quand même mentionner que lorsque tu déployes sur google app ou un autre cloud tu bénéficies d'une infrastructre de serveurs bien plus performante que sur un simple serveur mutualisé lorsque tu fais du développement php

Il suffit de lire les papiers des laboratoires de google pour mieux le comprendre (l'une des dernières publications des laboratoires de google dans l'univers du cloud http://www.morganclaypool.com/doi/pd...1Y200905CAC006)
05/06/2009, 00h22
nicorama

Citation:

Envoyé par *alexandre*

Google app n'a rien inventer ca reprend le principe d'amazon pour de déployement d'une application sur un cloud

Je ne suis pas si sur de cela. Amazon EC2 fait plus de la virtualisation d'OS qu"un pur Cloud. En fait je me demande si Google n'invente pas sa propre définition du "pure Cloud".

Je m'explique :
Allez sur les slides 32-37 de ce slide présentant EC2 : http://www.slideshare.net/chris.e.ri...d-presentation

Vous voulez Tomcat & Mysql ? Installez et configurez.

Avec AppEngine, rien de tout cela, c'est automatique. En tout cas, c'est du Java : http://code.google.com/appengine/doc.../usingjpa.html

...
Ou alors je rêve :roll:
05/06/2009, 23h14
JWillow

J'ai quand même l'impression que beaucoup oubli que Google fournit un infrastructure de cloud pas un simple serveur où on peut faire ce que l'on veut.
Pourquoi les restrictions de Google ? Simplement pour permettre la scalabilité de l'ensemble des applications qu'ils hébergent pas pour nous embêter.
Ok je suis dépendant de leur infrastructure mais c'est un peu ce que chercher parce que cela me permet de répondre à des milliers de requêtes (et de me prémunir des pics d'affluence qui peuvent submergé mes serveurs) sans avoir investi des milliers d'euros en serveur et sans avoir à les administrer (pas d'administration serveur, pas d'administration de BdD et en plus j'ai pas forcément à ma disposition ces compétences).
05/06/2009, 23h57
nicorama

Parfaitement d'accord. Je préfère être dépendant des compétences et de la solidité (toute relative) économique de Google que de mes qualités dans ce domaines :).
06/06/2009, 13h58
*alexandre*

petite question à benwit

concernant ton billet sur l'authentification à google app engine, le principe du cloud c'est quand même au travers d'une application de se connecté à plusieurs services tout en réutilisant le même login

comment navigues tu aux travers des applications SANS UN COMPTE GOOGLE ? et ainsi réutiliser ton compte loggé au travers de l'application initial ;)

l'App Engine ne se base sur aucune API connu et commune à l'ensemble des providers de services c'est donc impossible ... (sans une passerelle commune impossible d'échanger des données encryptées ou non -exemple un user token-)
06/06/2009, 20h10
benwit
Citation:

Envoyé par *alexandre*

le principe du cloud c'est quand même au travers d'une application de se connecté à plusieurs services tout en réutilisant le même login

ça, c'est plutôt le principe du SSO (cloud ou non).

Comme tu dis, il n'y a pas de mystère, pour naviguer d'un service applicatif à un autre, il faut bien que les fournisseurs de services mettent en œuvre un système d'authentification commun.

Les universités utilisent par exemple un serveur CAS pour leur SSO afin de pouvoir passer d'un service à l'autre avec une identification unique.

Certaines entreprises utilisent également un SSO pour leur différents services.

C'est plus facile à mettre en œuvre dans une même organisation mais l'authentification unique aurait encore plus d'intérêt entre différentes entreprises.

A mon avis, si on veut que ça fonctionne, il faut une solution ouverte.
Il y a eu plusieurs tentatives mais certaines n'ont jamais prises. La tentative d'Open Id se développe lentement mais prendra t'elle ???

Ce que je trouve bien dans l'authentification app engine, c'est qu'on peut développer une application qui utilise les comptes google.

Ce que je trouve critiquable :
- Si les comptes google sont un vrai SSO entre les différents services de google (passage de l'un à l'autre sans ressaisir son mdp), ils n'en sont pas un entre les services google et les applications app-engine (puisqu'il faut dans tous les cas saisir son mdp) et je doute (je n'ai pas essayé) que ce soit un SSO entre diverses applications GAE.
- Google supporte Open Id avec ses comptes Google. J'avais l'impression que ce n'était pas mis en œuvre dans l'authentification de GAE mais je n'en suis plus aussi sûr ... (Alors que la majorité d'entre vous qui ont essayé mon application de demo de login se sont connectés avec leur compte gmail, je ne m'explique pas que l'un d'entre vous a laissé son email orange.fr dans mes traces de console :calim2:)
06/06/2009, 21h15
*alexandre*

Je t'embête un peu avec ce problème car c'est un problème récurant dans le cadre de nos développements :mouarf:

Que penses-tu d'une solution comme http://www.zurich.ibm.com/news/08/ztic.html ? couplé avec un ldap et un service d'authentification qui valide une key unique selon le provider de solution et de services

c'est un mélange d'authentification centralisé (ztic) et une solution de de clef validé de type carte à matrice validé par un provider

tu ne valides qu'après une première authentification qu'une clef dynamique qui sera par la suite validé avec ton username et échanger d'après le service que tu veux consulter donc tu ne communiques que ton username et la clef qui est définit par service et dont sa validité n'a qu'un temps limitée et est gérée par le dit service (cela ressemble à CAS mais deviendrait valide sur un ensemble de service ...)

Code:

1
2
3
4
 
HTTP 1.1
GET http://server.externe.com/whatYouWant
Auhtorization : GiveMeTheWayGiveItToMeNow

REST, guyz. REST !

07/06/2009, 13h11
*alexandre*

Une *petite* publication dans le domaine du management de l'identité

http://www.aspeninstitute.org/sites/..._Computing.pdf

C'est pas technique mais peut permettre d'ouvrir un débat sur la notion d'identité