Re: Archi web d'un projet back office

Bonjour,

J'ai tendance à penser que le datastore de GAE n'est pas fait pour JPA/JDO.
Google a fait une API pour les *émuler* parce qu'une grosse majorité de la
communauté Java utilise ces standards. Mais les contraintes du datastore
(no-sql non relationnel => scalabilité, haute-dispo, etc) impose une autre
mode de fonctionnement avec certaines limitations par rapport à JPA. Il ne
faut pas les émuler mais faire le modèle de données de son appli dès le
début en prenant en compte ces contraintes.

J'ai découvert slim3 :
https://sites.google.com/site/slim3appengine/slim3-datastore, un framework
type-safe très léger qui wrappe l'API de bas-niveau du datastore en python.
J'adore.

Je pense aujourd'hui que le pattern MVP est indispensable dans une appli
GWT. Guit \o/ http://code.google.com/p/guit/ rend ce service est bien plus
encore.

slim3 & guit deux frameworks 'révolutionnaires' pour moi. Survolez leurs
docs : claires et concises ... :)

// thb

2011/4/13 Laurent Forêt <[email protected]>

> L'utilisation de Google authentication est un bon exemple, si je me sors de
> GAE j'ai plus ça. C'est quand même pas négligeable.Donc il faudra
> remplacer Google Authentication par JAAS, je me demandais si finalement
> c'était pas moins douloureux de réinventer la roue et ne dépendre ni de l'un
> ni de l'autre. J'ai une gestion de profil rudimentaire.
>
> La question de la reprise des données aussi n'est pas anodine.
>
> Laurent.
>
>
> 2011/4/13 Damien Lecan <[email protected]>
>
>> Dans ce sens là, ça se passe très bien.
>> Si les appels aux API propriétaires sont bien encapsulés, il faut "juste"
>> prévoir de les adapter à ton nouveau contexte.
>>
>> Attention, JAAS et le système d'authentification de Google ne se
>> ressemblent pas du tout.
>>
>> Dans tous les cas, faire des prototypes démontrant la faisabilité de tous
>> les choix techniques (sur GAE ou non).
>>
>> Damien
>>
>> Le 13 avril 2011 14:14, Laurent Forêt <[email protected]> a écrit :
>>
>> Ok c'est bien ce que je pensais, mais peut on imaginer l'inverse. On
>>> commence sur du GAE, on aime ça, ça marche bien. Puis tout d'un coup une
>>> montée en charge, des conditions tarifaires qui changent, caprice du client
>>> qui veut son propre hébergement ... ou autre . Ca s’héberge bien ailleurs ?
>>>
>>> Laurent.
>>>
>>>
>>> 2011/4/13 Damien Lecan <[email protected]>
>>>
>>>> Salut à tous,
>>>>
>>>> Je prends le fil avec un peu de retard (de retour de congé paternité :p)
>>>> et je saute sur la question GAE.
>>>> Oui, il y a une palanquée de limitation sur le JPA de GAE (types de
>>>> données, identifiants, ...), mais pas que sur cette couche.
>>>>
>>>> Un projet qui démarre avec une belle archi JEE en se disant "tiens, on
>>>> va prévoir sur le papier une comptabilité avec GAE", il faut prévoir entre
>>>> 10% et 20% de la charge initiale pour migrer l'application vers GAE ensuite.
>>>>
>>>> Parce qu'il y a des limitations pour tout et tout le temps : classes non
>>>> disponibles, temps d'exécution d'un processus trop long (requêtes externes,
>>>> ...), API proprio, environnement de développement qui ne reproduit que
>>>> partiellement le comportement de la plateforme de prod GAE, bugs (en dev ou
>>>> en prod, ...).
>>>>
>>>> Donc si vous voulez du GAE, ne le prévoyez pas, faites-le.
>>>>
>>>> Damien
>>>>
>>>> Le 28 mars 2011 12:09, Laurent Forêt <[email protected]> a écrit
>>>> :
>>>>
>>>> Sinon des retours sur les limitations de JPA dans GAE ? Des suggestions
>>>>> pour JDO, DataNucleus et consort ?
>>>>>
>>>>> Autre question : Y a t'il des alternatives à JAAS ? Le fait que ca
>>>>> existe depuis longtemps et que personne n'a l'air de s'en servir m'effraie
>>>>> un peu. Alors que sur le papier ça a l'air de faire le job, c'est à dire de
>>>>> l'authentification et de la gestion de profil.
>>>>>
>>>>> Laurent
>>>>>
>>>>> 2011/3/28 Olivier Lamy <[email protected]>
>>>>>
>>>>>> Nope pas d'ejb (la plateforme actuelle est tomcat).
>>>>>> Après ejb ou pas : c'est un vaste débat :-) (perso j'aime pas trop :
>>>>>> j'aime bien la simplicité d'un simple container de servlet)
>>>>>>
>>>>>> L'avantage de cloudbees c'est que tu as "tout sous la main" : scm repo
>>>>>> (svn ou git), un ci (jenkins enfin nectar : distrib customisé et
>>>>>> stable : vous connaissez comme moi le mode "motherfucking programming"
>>>>>> de jenkins :-) ) et le RUN (via tomcat et du mysql).
>>>>>> Donc tu limites ta gestion d'infra.
>>>>>> Et surtout le mode RUN n'est pas limité en terme de java contrairement
>>>>>> à d'autres.
>>>>>>
>>>>>> /Olivier
>>>>>>
>>>>>> Le 28 mars 2011 11:30, Laurent Forêt <[email protected]> a
>>>>>> écrit :
>>>>>> > C'est une piste je la note. Mais pas d'EJB alors ?
>>>>>> >
>>>>>> > Laurent Forêtx
>>>>>> >
>>>>>> >
>>>>>> > 2011/3/28 Olivier Lamy <[email protected]>
>>>>>> >>
>>>>>> >> Hello,
>>>>>> >> En terme d'infra, ss tu regardé du côté de cloudbees [1] ?
>>>>>> >> Celà te permet de ne pas avoir à maintenir/gérer tes instances
>>>>>> (mysql
>>>>>> >> ou tomcat).
>>>>>> >> En plus, ils sont supers sympas et très réactifs :-)
>>>>>> >>
>>>>>> >> --
>>>>>> >> Olivier Lamy
>>>>>> >> http://twitter.com/olamy
>>>>>> >> http://www.linkedin.com/in/olamy
>>>>>> >>
>>>>>> >> [1] http://cloudbees.com/
>>>>>> >>
>>>>>> >> Le 28 mars 2011 10:13, Laurent Forêt <[email protected]> a
>>>>>> écrit :
>>>>>> >> > Salut la liste,
>>>>>> >> >   je pars sur un nouveau projet qui maintiendra un back office
>>>>>> d'un
>>>>>> >> > modèle
>>>>>> >> > métier d'une vingtaine d'entités. Je veux faire dans le risque
>>>>>> minimum,
>>>>>> >> > du
>>>>>> >> > fiable, du maintenable et du non exotique. Je suis donc à priori
>>>>>> partie
>>>>>> >> > sur
>>>>>> >> > la stack techno suivante :
>>>>>> >> >    - JPA 2
>>>>>> >> >    - EJB 3
>>>>>> >> >    - JAAS
>>>>>> >> >    - GWT et JAXRS
>>>>>> >> >   Concernant le déploiement, les contraintes sont un hébergement
>>>>>> type
>>>>>> >> > linux,
>>>>>> >> >  mysql, glassfish sur un serveur dédié.
>>>>>> >> > Le problème est qu'il n'est pas exclue que l'hébergement change
>>>>>> pour du
>>>>>> >> >  GAE. Donc si je veux anticiper et prendre cette possibilité en
>>>>>> compte
>>>>>> >> > que
>>>>>> >> > reste t'il de ma belle stack :
>>>>>> >> >    - JPA 2  --> JPA 1 bridé
>>>>>> >> >    - EJB 3  --> POJO, guice ?
>>>>>> >> >    - JAAS  -->  Google Authentication
>>>>>> >> >    - GWT et JAXRS   --> JAXRS ?
>>>>>> >> > Ca me parait pas anodin comme changement.
>>>>>> >> > Quitte a passer sur le cloud n'y a t'il pas des offres PAAS plus
>>>>>> proche
>>>>>> >> > de
>>>>>> >> > mon architecture cible de base ? Ou doit on encore installé et
>>>>>> maintenir
>>>>>> >> > un
>>>>>> >> > serveur glassffish et mysql sur une IAAS style Amazon ? Qu'en
>>>>>> pensez
>>>>>> >> > vous ?
>>>>>> >> > Par avance, merci pour vos avis éclairé.
>>>>>> >> > Laurent Forêt
>>>>>> >> > http://www.devcoop.fr,
>>>>>> >> > http://laurentforet.org
>>>>>> >> > IvyBeans Creator
>>>>>> >> > Membre du JUG Bordeaux
>>>>>> >> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>