Re: Archi web d'un projet back office

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