Question sur REST et AOP
58 views
Skip to first unread message
François Coppey
Jul 7, 2012, 7:55:31 AM7/7/12
to ju...@googlegroups.com
Bonjour,
Je m’appelle François Coppey et je viens de terminer mon bachelor en « ingénieur des médias » à Yverdon.
Je me permets de vous écrire, car j’ai développé une application Java EE 6 qui permet de gérer des clubs de sports en ligne (www.plugin.ch) mais j’ai des soucis concernant la sécurisation du webservice REST lorsque mon client PHP appelle mon serveur Java. Je n’ai pas trouvé de système qui me permette de faire quelque chose de bien sécurisé entre du PHP et du Java autant du côté client que serveur.
J’ai également un problème afin de déterminer quelle URL appelle mon webservice ceci dans le but de le rediriger vers la bonne base de données. Actuellement, je le fais en AspectJ mais c’est n’est pas 100% fiable (des fois ce n’est pas la bonne BDD qui est appelée…) et je suis sûr qu’il y a un meilleur moyen de le faire… par exemple en AOP ?
Après plusieurs recherches sans succès, l’un de mes professeurs (Olivier Liechti) et Philippe Kernévez m’ont dit que je pourrais m’adresser au JUGL afin de trouver quelqu’un qui pourrait être intéressé à m’aider à avancer.
C’est avec plaisir que je me déplace pour en discuter si quelqu’un est intéressé….
Merci et meilleures salutations
Plugin.ch
François Coppey
Hubert Behaghel
Jul 7, 2012, 8:52:34 AM7/7/12
to ju...@googlegroups.com
Salut François,
J'ai du creuser ce sujet l'an dernier pour faire un client S3 en
scala. Cet article a été celui que j'aurai voulu lire en premier pour
ce faire alors voici :
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
On y aborde la sécurisation des API Rest d'Amazon Web Services. Je te
conseille vivement de t'y attarder. Et je pense pas dire ça parce que
j'y travaille...
Pour ton mapping URL - DB, faudrait que tu donnes plus de détails mais
je vois pas trop ce que l'AOP vient y faire. Btw AspectJ == AOP for
Java. Et l'AOP c'est tricher mais je voudrais pas mettre un feu
trollesque aux poudres d'ordinaire si calme de cette liste, alors je
retire ce que je viens de dire =)
Pour te déplacer, ça aurait été avec plaisir mais je suis à Londres,
en plus il pleut. Depuis au moins 30 jours. Too bad for the olympic
games.
J'espère que cela t'aidera. Salue le professeur Kernévez pour moi.
--
Hubert
2012/7/7 François Coppey <frac...@gmail.com>:
J'ai du creuser ce sujet l'an dernier pour faire un client S3 en
scala. Cet article a été celui que j'aurai voulu lire en premier pour
ce faire alors voici :
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
On y aborde la sécurisation des API Rest d'Amazon Web Services. Je te
conseille vivement de t'y attarder. Et je pense pas dire ça parce que
j'y travaille...
Pour ton mapping URL - DB, faudrait que tu donnes plus de détails mais
je vois pas trop ce que l'AOP vient y faire. Btw AspectJ == AOP for
Java. Et l'AOP c'est tricher mais je voudrais pas mettre un feu
trollesque aux poudres d'ordinaire si calme de cette liste, alors je
retire ce que je viens de dire =)
Pour te déplacer, ça aurait été avec plaisir mais je suis à Londres,
en plus il pleut. Depuis au moins 30 jours. Too bad for the olympic
games.
J'espère que cela t'aidera. Salue le professeur Kernévez pour moi.
--
Hubert
2012/7/7 François Coppey <frac...@gmail.com>:
François Helg
Jul 7, 2012, 1:43:05 PM7/7/12
to ju...@googlegroups.com, ju...@googlegroups.com
+1 pour le conseil d'Hubert.
Bon courage pour l'implem
François
Bon courage pour l'implem
François
Guillaume Lederrey
Jul 7, 2012, 2:17:25 PM7/7/12
to ju...@googlegroups.com
Hello !
Sans plus de détails sur l'implémentation, difficile de donner des conseils éclairés. Pour l'authentification, tu peux toujours te rabattre sur une bête BASIC Auth. Ou pour faire plus sérieux, aller regarder du côté de OAuth.
Si tu veux faire le point autour d'une bière et que tu passes parfois sur Lausanne, fais-moi signe!
MrG
François Coppey
Jul 8, 2012, 7:18:58 PM7/8/12
to ju...@googlegroups.com
Merci Hubert pour ton conseil ! Je vais essayer cela demain et je vous redonnerais des nouvelles...
en ce qui concerne mon matching URL - DB, j'avais choisi d'abord en AOP, mais je n'ai pas trouvé de solution qui me convenait. C'est pourquoi je me suis tourné vers l'AspectJ.... Mais il est très bien possible qu'aucune soient efficace pour mes besoins :D ... Alors je vais essayer de vous expliquer un peu mieux ce problème afin peut être de me diriger sur une autre voie....
Coté client :
J'ai un site - www.pluginres.ch - sur lequel j'ai plusieurs alias de domaine qui sont redirigé vers lui - www.cs-maisonnex.ch et www.cscointrin.ch. Grâce à mon client REST, je communique avec mon serveur.
Coté serveur :
J'ai une seul appli plugin.ws qui tourne sur glassfish et elle est codée en Java EE 6 sur un model en couches (WS - Traitement - DAO - Entity) . Mon appli donne accès à plusieurs WebService qui retourne des objets en JSON.
Coté DB :
Chaque DNS (pluginres.ch, cs-maisonnex.ch, cscointrin.ch) utilise sa propre base de données. Mon appli plugin.ws communique avec ma DB MySQL grâce à Hibernate.
Mon objectif :
Matcher à 100% (ce qui n'est pas le cas actuellement) la bonne DB en fonction de l'alias de domaine qui a appelé mon WS.
Comment géreriez-vous une situations comme celle-là ? Pensez-vous qu'il existe une solution simple en EE 6 qui permette de faire cela ?
Actuellement tous mes WS hérite de la class FacadeREST qui va juste récupérer l'URL du client grâce à l'annotation et l'objet @Context UriInfo. Ensuite mon Aspect est utilisé avant chaque appelle de service et va déterminer avec quel @EntityManager il va devoir travailler.
public class FacadeREST {
@Context UriInfo uriInfo;
@EJB
EntityMan entityMan;
public UriInfo getUri(){
return uriInfo;
}
}
AspectJ :
pointcut nom() : execution(* FacadeREST+.*(..));
before():nom(){
String uri = ((FacadeREST)thisJoinPoint.getThis()).uriInfo.getBaseUri().toString();
FacadeREST facade = ((FacadeREST)thisJoinPoint.getThis());
if(uri.contains("cointrin"))
facade.entityMan.switchEM(1);
else if(uri.contains("maisonnex"))
facade.entityMan.switchEM(2);
}
Dans la couche DAO, toutes mes classes commence par
@EJB
EntityMan EntityMan;
protected EntityManager getEntityManager() {
return EntityMan.getEM();
}
Ma classe EntityMan définit les différents @PersistenceContext et contient une méthode switchEM qui est appelée par mon Aspect afin de définir quelle DB utilisée et une fonction getEM qui returne l' EntityManager au DAO.
public class EntityMan {
private EntityManager em;
@PersistenceContext(unitName = "plugin_cointrin")
private EntityManager em1;
@PersistenceContext(unitName = "plugin_maisonnex")
private EntityManager em2;
public void switchEM(int url)
{
switch(url){
case 2:
em = em2;
break;
default:
em = em1;
break;
}
}
public EntityManager getEM(){
return em;
}
}
Voilà j'espère que c'est compréhensible........... C'est difficile quand on est pas dedans :D .... Mais je pense que le problème provient au moment où 2 clients appellent un service en même temps et que la variable "em" change de valeur avant que le premier finisse sa transaction.... Mais je ne suis pas sûr de ça car je pense que les variables sont définies par sessions. Donc lorsque 2 clients appellent un service en même temps, ça devrait être dans 2 sessions différentes donc ne pas se mélanger ?
Merci encore de votre précieuse aide
François
en ce qui concerne mon matching URL - DB, j'avais choisi d'abord en AOP, mais je n'ai pas trouvé de solution qui me convenait. C'est pourquoi je me suis tourné vers l'AspectJ.... Mais il est très bien possible qu'aucune soient efficace pour mes besoins :D ... Alors je vais essayer de vous expliquer un peu mieux ce problème afin peut être de me diriger sur une autre voie....
Coté client :
J'ai un site - www.pluginres.ch - sur lequel j'ai plusieurs alias de domaine qui sont redirigé vers lui - www.cs-maisonnex.ch et www.cscointrin.ch. Grâce à mon client REST, je communique avec mon serveur.
Coté serveur :
J'ai une seul appli plugin.ws qui tourne sur glassfish et elle est codée en Java EE 6 sur un model en couches (WS - Traitement - DAO - Entity) . Mon appli donne accès à plusieurs WebService qui retourne des objets en JSON.
Coté DB :
Chaque DNS (pluginres.ch, cs-maisonnex.ch, cscointrin.ch) utilise sa propre base de données. Mon appli plugin.ws communique avec ma DB MySQL grâce à Hibernate.
Mon objectif :
Matcher à 100% (ce qui n'est pas le cas actuellement) la bonne DB en fonction de l'alias de domaine qui a appelé mon WS.
Comment géreriez-vous une situations comme celle-là ? Pensez-vous qu'il existe une solution simple en EE 6 qui permette de faire cela ?
Actuellement tous mes WS hérite de la class FacadeREST qui va juste récupérer l'URL du client grâce à l'annotation et l'objet @Context UriInfo. Ensuite mon Aspect est utilisé avant chaque appelle de service et va déterminer avec quel @EntityManager il va devoir travailler.
public class FacadeREST {
@Context UriInfo uriInfo;
@EJB
EntityMan entityMan;
public UriInfo getUri(){
return uriInfo;
}
}
AspectJ :
pointcut nom() : execution(* FacadeREST+.*(..));
before():nom(){
String uri = ((FacadeREST)thisJoinPoint.getThis()).uriInfo.getBaseUri().toString();
FacadeREST facade = ((FacadeREST)thisJoinPoint.getThis());
if(uri.contains("cointrin"))
facade.entityMan.switchEM(1);
else if(uri.contains("maisonnex"))
facade.entityMan.switchEM(2);
}
Dans la couche DAO, toutes mes classes commence par
@EJB
EntityMan EntityMan;
protected EntityManager getEntityManager() {
return EntityMan.getEM();
}
Ma classe EntityMan définit les différents @PersistenceContext et contient une méthode switchEM qui est appelée par mon Aspect afin de définir quelle DB utilisée et une fonction getEM qui returne l' EntityManager au DAO.
public class EntityMan {
private EntityManager em;
@PersistenceContext(unitName = "plugin_cointrin")
private EntityManager em1;
@PersistenceContext(unitName = "plugin_maisonnex")
private EntityManager em2;
public void switchEM(int url)
{
switch(url){
case 2:
em = em2;
break;
default:
em = em1;
break;
}
}
public EntityManager getEM(){
return em;
}
}
Voilà j'espère que c'est compréhensible........... C'est difficile quand on est pas dedans :D .... Mais je pense que le problème provient au moment où 2 clients appellent un service en même temps et que la variable "em" change de valeur avant que le premier finisse sa transaction.... Mais je ne suis pas sûr de ça car je pense que les variables sont définies par sessions. Donc lorsque 2 clients appellent un service en même temps, ça devrait être dans 2 sessions différentes donc ne pas se mélanger ?
Merci encore de votre précieuse aide
François
Raphael Tagliani
Jul 9, 2012, 5:22:08 AM7/9/12
to ju...@googlegroups.com
Hello,
--
Personellement, j'ai interfacé deux fois du php avec du JEE ou encore avec des webservices microsoft. La solution que j'ai trouvé la plus efficace et la plus simple à sécuriser + garantir que je passe les proxys, c'est d'utiliser libcurl en php, pour faire un post, et sécuriser avec de l'HTTPS + basic. Bref, tu l'auras compris, les ws et moi, ce n'est pas le grand amour, à part lorsque je peux faire un post http dessus :)
Dans quelques cas d'utilisation, la technique dont je te parle ne doit pas être utilisée : transactions distribuées, définition du service qui change souvent, crypto partielle du message plutôt que de tout parser. Sinon, ça marche bien, et selon la le cas, ce sera beaucoup plus performant que de charger tes libs + le code généré automatiquement pour le ws.
A+
François Coppey
Jul 9, 2012, 11:45:20 AM7/9/12
to ju...@googlegroups.com
Salut à tous,
Merci encore pour votre aide...
Mais j'ai lu l'article que m'a transmis Hubert, mais je n'ai pas tout compris....
Est-ce que les objets sont envoyé crypté ??? Si oui, c'est pas vraiment une solution pour moi.... car je récupère partout des entitées.... Alors il me viendrait compliquer pour modifier afin d'envoyer et de recevoir que des objets crypter....
Je n'ai pas compris également l'utilisation du HMAC du côté java.... ça m'a l'air bien complexe vu qu'il n'y a pas de fonction qu'il le fait comme dans PHP... Et je pense aussi que cette solution est bien si on commence avec... Mais si on l'intègre à la fin d'un projet, c'est pas l'idéal... Car je ne vois pas comment l'intégrer sur tous mes services sans de l'AOP ^^
Mais sinon dans cet article j'ai vu également qu'il parlait de la solution de Raphael qui est l'utilisation du HTTPS + Basic.... Est-ce que cette solution est fiable ? Savez-vous me dire si le HTTPS est compatible avec EE6 et GlassFish ? et peut-être Raphael tu aurais un exemple de comment l'intégrer ? Car j'avoue que j'avais déjà pensé à faire du Basic, mais j'ai été incapable de le mettre en place du côté Java avec NetBeans...
Merci encore de vos commentaires !
François
Merci encore pour votre aide...
Mais j'ai lu l'article que m'a transmis Hubert, mais je n'ai pas tout compris....
Est-ce que les objets sont envoyé crypté ??? Si oui, c'est pas vraiment une solution pour moi.... car je récupère partout des entitées.... Alors il me viendrait compliquer pour modifier afin d'envoyer et de recevoir que des objets crypter....
Je n'ai pas compris également l'utilisation du HMAC du côté java.... ça m'a l'air bien complexe vu qu'il n'y a pas de fonction qu'il le fait comme dans PHP... Et je pense aussi que cette solution est bien si on commence avec... Mais si on l'intègre à la fin d'un projet, c'est pas l'idéal... Car je ne vois pas comment l'intégrer sur tous mes services sans de l'AOP ^^
Mais sinon dans cet article j'ai vu également qu'il parlait de la solution de Raphael qui est l'utilisation du HTTPS + Basic.... Est-ce que cette solution est fiable ? Savez-vous me dire si le HTTPS est compatible avec EE6 et GlassFish ? et peut-être Raphael tu aurais un exemple de comment l'intégrer ? Car j'avoue que j'avais déjà pensé à faire du Basic, mais j'ai été incapable de le mettre en place du côté Java avec NetBeans...
Merci encore de vos commentaires !
François
Philippe Kernévez
Jul 10, 2012, 11:13:52 AM7/10/12
to ju...@googlegroups.com
Hello,
--
Philippe Kernévez
Directeur technique (Suisse)
pker...@octo.com
+41 79 888 33 32
Retrouvez OCTO sur OCTO Talk : http://blog.octo.com
OCTO Technology http://www.octo.com
AOP = Aspect Object Programming.
AspectJ est une implem d'AOP (pas d'opposition donc) :-)
Pour le reste je regarde en rentrant de vacances
Philippe Kernévez
Directeur technique (Suisse)
pker...@octo.com
+41 79 888 33 32
Retrouvez OCTO sur OCTO Talk : http://blog.octo.com
OCTO Technology http://www.octo.com
François Coppey
Jul 10, 2012, 5:46:39 PM7/10/12
to ju...@googlegroups.com
Merci Philippe !
J'attends avec impatience tes commentaires ;-)
En attendant, si quelqu'un à une idée pour le maching URL - DB... Je prends avec plaisir... car ca devient un grand souci maintenant :D
Encore merci à tous
François
J'attends avec impatience tes commentaires ;-)
En attendant, si quelqu'un à une idée pour le maching URL - DB... Je prends avec plaisir... car ca devient un grand souci maintenant :D
Encore merci à tous
François
Benoit Perroud
Jul 11, 2012, 9:59:11 AM7/11/12
to ju...@googlegroups.com
Le 10 juillet 2012 23:46, François Coppey <frac...@gmail.com> a écrit :
> Merci Philippe !
>
> J'attends avec impatience tes commentaires ;-)
>
> En attendant, si quelqu'un à une idée pour le maching URL - DB... Je prends
> avec plaisir... car ca devient un grand souci maintenant :D
Utiliser la même db et avoir une FK qui détermine le client ?
> Merci Philippe !
>
> J'attends avec impatience tes commentaires ;-)
>
> En attendant, si quelqu'un à une idée pour le maching URL - DB... Je prends
> avec plaisir... car ca devient un grand souci maintenant :D
François Coppey
Jul 11, 2012, 10:11:16 AM7/11/12
to ju...@googlegroups.com
Salut Benoit,
Merci pour ton message !
Mais j'aimerais éviter cette solution car je ne veux pas regrouper toutes les données sur une même BDD car j'ai quand même pas mal de données par clients.... Alors je veux éviter le ralentissement.... :D ...
Je préfères nettement que chaque client à sa Base de données.
Merci !
François
Merci pour ton message !
Mais j'aimerais éviter cette solution car je ne veux pas regrouper toutes les données sur une même BDD car j'ai quand même pas mal de données par clients.... Alors je veux éviter le ralentissement.... :D ...
Je préfères nettement que chaque client à sa Base de données.
Merci !
François
Raphael Tagliani
Jul 11, 2012, 10:14:11 AM7/11/12
to ju...@googlegroups.com
Alors, je te conseille plutôt un domaine glassfish par client.
François Coppey
Jul 11, 2012, 10:16:49 AM7/11/12
to ju...@googlegroups.com
J aime bien ton idée... Cela n implique pas plusieurs déployement d applications?
Pourrais-tu me donner plus de détails sur la façon de procéder?
Merci
Raphael Tagliani
Jul 11, 2012, 10:38:41 AM7/11/12
to ju...@googlegroups.com
Oui, ça demande plusieurs déploiement d'applis, mais c'est plus 'propre' : ça permet de mettre une version pour un client qui teste, pendant qu'un autre est sur une version stable...
Ca te permet aussi d'allouer plus de ressources à un client qu'à un autre, en jouant avec le domain.xml.
Installe un module apache, qui s'appelle jk, et dans site-available, voici un exemple de conf (en document joint), avec du ssl.
A+
2012/7/11 François Coppey <frac...@gmail.com>
François Coppey
Jul 11, 2012, 11:58:41 AM7/11/12
to ju...@googlegroups.com
Merci de tes infos, je vais voir ca ce soir...
Mais ca m embête de faire plusieurs déploiement car pour les mises a jour de l appli ca va être super chiant :-).. surtout si tu as 100 clients! d ou mon idée d avoir une appli qui fait toute seule le matching..
A moins que dans ton cas ya un moyen de faire les mises a jours facilement?
Donc le ssl pourrait m aider a sécuriser mon appli? En ajoutant encore un baside auth?
Raphael Tagliani
Jul 11, 2012, 12:11:28 PM7/11/12
to ju...@googlegroups.com
Pour le redéploiement, tu peux toujours faire un script qui les met à jour les uns après les autres (avec asadmin).
Par contre, si tu veux mettre 100 clients sur une seule machine physique, ne te lance pas dans les domaines glassfish séparés : ça va te demander trop de mémoire. A l'inverse, utilise une colonne discriminant dans ta base de données, comme suggéré auparavant par Benoit. Le problème du volume de données est réglé en faisant un where dans tes queries : on a tout un erp qui fonctionne très bien comme ça.
On a déjà réglé tous ces problèmes dans notre erp : tu peux nous rendre visite si tu veux.
François Coppey
Jul 11, 2012, 3:34:57 PM7/11/12
to ju...@googlegroups.com
et est-ce que 100 clients qui génèrent un trafic d'environ 2'000 personnes par jour sur la même application c'est faisable ou ca risque de planter ??? et si je passes à 500 clients qui génère 10'000 personnes par jour ?
Mais j'aurais réellement voulu éviter cette solution d'une seul base de données.. .je voudrais vraiment avoir le cas de 1 BDD par client.... Mais je pense qu'il ne doit pas avoir de solution fiable.... et peut-être qu'au final, je m'embête moins avec ta solution... Mais n'aurais-je pas des problèmes de ralentissement dans le cas ou j'ai 200'000 enregistrements dans la même DB et que j'ai environ 4'000 requête par jour la-dessus ?
Qu'en penses-tu ? Il n'y a vraiment aucun moyen en continuant ma solution ????
Merci encore de tes conseils....
François Coppey
Mais j'aurais réellement voulu éviter cette solution d'une seul base de données.. .je voudrais vraiment avoir le cas de 1 BDD par client.... Mais je pense qu'il ne doit pas avoir de solution fiable.... et peut-être qu'au final, je m'embête moins avec ta solution... Mais n'aurais-je pas des problèmes de ralentissement dans le cas ou j'ai 200'000 enregistrements dans la même DB et que j'ai environ 4'000 requête par jour la-dessus ?
Qu'en penses-tu ? Il n'y a vraiment aucun moyen en continuant ma solution ????
Merci encore de tes conseils....
François Coppey
Guillaume Lederrey
Jul 11, 2012, 5:48:04 PM7/11/12
to ju...@googlegroups.com
Hello !
Je remets donc mon grain de sable ... la scalabilité est une
problématique que j'aime bien !
Je te félicite de penser aux problématiques de scalabilité en début de
projet ! Par contre, fais attention à ne pas mettre en place une usine
à gaz pour traiter un problème qui n'existe en fait pas. On peut très
bien traiter des centaines de milliers de transactions par jour sur
une seule DB. Sur ce ...
Il faut distinguer deux problématiques :
a) scalabilité (simplifion et parlons juste du nombre de requêtes HTTP / SQL)
b) maintenabilité
En terme de scalabilité, il faut également distinguer deux problématiques :
a.1) la quantité de données : il faut aller très loin pour que la
quantité pose problème, tant que tes index sont bons, la charge est
indépendante de la quantité de données
a.2) la quantité de requêtes : en partageant la charge sur plusieurs
DB, tu permets une scalabilité horizontale. On va parler parfois de
sharding, ou de partitionnement de données ou de system multi-tenant.
C'est sur ce point que tu vas pouvoir gagner de la scalabilité.
Hibernate shards propose une solution dans ce sens, mais toujours en
béta depuis une éternité. Oracle propose des solutions de
partitionnement au niveau DB. On doit pouvoir trouver des solution de
ce stlye pour EclipseLink ou OpenJPA, mais je ne les connais pas. Quoi
qu'il en soit, cherche une solution "standard" plutôt que
d'implémenter une solution maison.
Et pour la partie maintenabilité :
b.1) en partageant les DB, tu augmentes de manière non négligeable le
coût de maintenance. Plus de DB à maintenir, plus de DB à mettre à
jour, plus de serveurs à installer, ... Tu peux mitiger ce point en
automatisant la maintenance, mais seulement jusqu'à un certain point.
b.2) en déployant une DB + une appli par client, tu donnes la
possibilité de passer un seul de tes clients en maintenance.
Typiquement cette solution est utilisée sur des applications avec un
public mondial : en ayant une instance de l'application pour chaque
zone géographique, tu peux avoir des plages de maintenance durant des
périodes de faible charge. Par exemple, tu peux mettre à jour
l'application Asie / Australie vers midi heure Suisse et l'application
Europe vers 2h du matin heure Suisse.
Comme d'habitude, la bonne solution est une question de compromis.
Toujours à ta disposition si tu veux passer pour en parler de vive
voix sur Lausanne ...
A+
Guillaume
2012/7/11 François Coppey <frac...@gmail.com>:
--
mobile : +41 76 573 32 40
skype : Guillaume.Lederrey
projects :
* http://rwanda.ledcom.ch/
* http://trock.ch/
others :
* http://kiva.org/
Je remets donc mon grain de sable ... la scalabilité est une
problématique que j'aime bien !
Je te félicite de penser aux problématiques de scalabilité en début de
projet ! Par contre, fais attention à ne pas mettre en place une usine
à gaz pour traiter un problème qui n'existe en fait pas. On peut très
bien traiter des centaines de milliers de transactions par jour sur
une seule DB. Sur ce ...
Il faut distinguer deux problématiques :
a) scalabilité (simplifion et parlons juste du nombre de requêtes HTTP / SQL)
b) maintenabilité
En terme de scalabilité, il faut également distinguer deux problématiques :
a.1) la quantité de données : il faut aller très loin pour que la
quantité pose problème, tant que tes index sont bons, la charge est
indépendante de la quantité de données
a.2) la quantité de requêtes : en partageant la charge sur plusieurs
DB, tu permets une scalabilité horizontale. On va parler parfois de
sharding, ou de partitionnement de données ou de system multi-tenant.
C'est sur ce point que tu vas pouvoir gagner de la scalabilité.
Hibernate shards propose une solution dans ce sens, mais toujours en
béta depuis une éternité. Oracle propose des solutions de
partitionnement au niveau DB. On doit pouvoir trouver des solution de
ce stlye pour EclipseLink ou OpenJPA, mais je ne les connais pas. Quoi
qu'il en soit, cherche une solution "standard" plutôt que
d'implémenter une solution maison.
Et pour la partie maintenabilité :
b.1) en partageant les DB, tu augmentes de manière non négligeable le
coût de maintenance. Plus de DB à maintenir, plus de DB à mettre à
jour, plus de serveurs à installer, ... Tu peux mitiger ce point en
automatisant la maintenance, mais seulement jusqu'à un certain point.
b.2) en déployant une DB + une appli par client, tu donnes la
possibilité de passer un seul de tes clients en maintenance.
Typiquement cette solution est utilisée sur des applications avec un
public mondial : en ayant une instance de l'application pour chaque
zone géographique, tu peux avoir des plages de maintenance durant des
périodes de faible charge. Par exemple, tu peux mettre à jour
l'application Asie / Australie vers midi heure Suisse et l'application
Europe vers 2h du matin heure Suisse.
Comme d'habitude, la bonne solution est une question de compromis.
Toujours à ta disposition si tu veux passer pour en parler de vive
voix sur Lausanne ...
A+
Guillaume
2012/7/11 François Coppey <frac...@gmail.com>:
mobile : +41 76 573 32 40
skype : Guillaume.Lederrey
projects :
* http://rwanda.ledcom.ch/
* http://trock.ch/
others :
* http://kiva.org/
François Coppey
Jul 12, 2012, 6:46:25 AM7/12/12
to ju...@googlegroups.com
Merci Guillaume pour ce complément d'informations qui m'est vraiment très utile.
Par contre, 2 points à éclaircir :
1. Je ne suis malheureusement pas au début de mon projet, mais à la fin !!! :D .. Des clients utilisent déjà mon programme... Mais je ne pense pas qu'il serait un problème de modifier en passant de plusieurs BDD à une seule... ca prend juste du temps....
2. En lisant la doc sur Hibernate Shared, c'est indiqué que ce framework ne peut pas être utilisé si l'API utilise les sessions par JPA ou Hibernate Annotations.. Ce qui est mon cas :-( ... Donc Bye Bye Shared :D
Mais j'aime bien ton idée d'avoir une API + BDD par zone géographique! Ca me permettrait de gérer pas mal de problème dû au décalage horaire vu que mon programme à une ambition "mondiale".
Mais avant de partir sur ce système, j'aimerais assez qu'on se rencontre afin que je soies sûr de repartir sur la bonne base... Je n'aimerais pas encore changer de système dans quelques temps... Je suis à Lausanne lundi matin, si tu as du temps libre, on pourrait se rencontrer ?
Mais il me reste toujours le problème concernant le meilleur moyen simple de sécuriser mon appli entre PHP et JAVA ?
Merci encore pour toute votre aide !!
François Coppey
Par contre, 2 points à éclaircir :
1. Je ne suis malheureusement pas au début de mon projet, mais à la fin !!! :D .. Des clients utilisent déjà mon programme... Mais je ne pense pas qu'il serait un problème de modifier en passant de plusieurs BDD à une seule... ca prend juste du temps....
2. En lisant la doc sur Hibernate Shared, c'est indiqué que ce framework ne peut pas être utilisé si l'API utilise les sessions par JPA ou Hibernate Annotations.. Ce qui est mon cas :-( ... Donc Bye Bye Shared :D
Mais j'aime bien ton idée d'avoir une API + BDD par zone géographique! Ca me permettrait de gérer pas mal de problème dû au décalage horaire vu que mon programme à une ambition "mondiale".
Mais avant de partir sur ce système, j'aimerais assez qu'on se rencontre afin que je soies sûr de repartir sur la bonne base... Je n'aimerais pas encore changer de système dans quelques temps... Je suis à Lausanne lundi matin, si tu as du temps libre, on pourrait se rencontrer ?
Mais il me reste toujours le problème concernant le meilleur moyen simple de sécuriser mon appli entre PHP et JAVA ?
Merci encore pour toute votre aide !!
François Coppey
Benoit Perroud
Jul 12, 2012, 8:46:57 AM7/12/12
to ju...@googlegroups.com
Une seule base ou plusieurs sur le même serveur physique ca ne change
rien, surtout dans la volumétrie que tu présente (sans vouloir être
offensant). La prochaine étape d'optimisation est le caching, pas le
sharding.
Et tu pourras toujours isoler et scaler verticalement ton serveur de
DB, et ainsi obtenir un certain buffer temporel pour mettre en place
shard/replication/nosql.
Mon seul conseil, c'est "Keep it simple". C'est la meilleure chance
que tu peux te donner pour atteindre tes ambitions mondiales. Ca veut
dire pas d'AOP, une seule DB, un seul domaine glassfish.
Bonne journée,
Benoit.
rien, surtout dans la volumétrie que tu présente (sans vouloir être
offensant). La prochaine étape d'optimisation est le caching, pas le
sharding.
Et tu pourras toujours isoler et scaler verticalement ton serveur de
DB, et ainsi obtenir un certain buffer temporel pour mettre en place
shard/replication/nosql.
Mon seul conseil, c'est "Keep it simple". C'est la meilleure chance
que tu peux te donner pour atteindre tes ambitions mondiales. Ca veut
dire pas d'AOP, une seule DB, un seul domaine glassfish.
Bonne journée,
Benoit.
François Coppey
Jul 16, 2012, 3:39:23 AM7/16/12
to ju...@googlegroups.com
Merci à tous pour vos réponses..
Je crois que je vais suivre votre idée et que je vais pas me lancer dans du trop compliqué et faire 1 DB et 1 domaine glassfish...
Merci encore de vos conseils..
Par contre je suis toujours embêté pour faire qqch comme HTTPS + Basic Auth.... Je pense que c'est amplement suffisant comme sécurité pour mon programme... mais je n'ai toujours rien trouver pour la mise en place de ca dans un environnement NetBeans 7.1.... Je vais continuer mes recherches... mais si quelqu'un à une idée..... d'avance merci ! :D
A bientot et merci encore pour votre coup de main.....
Guillaume Lederrey
Jul 16, 2012, 3:27:01 PM7/16/12
to ju...@googlegroups.com
Hello !
Pour la partie authentification, tu peux soit la déléguer à ton
serveur d'appli, soit gérer l'authentification au niveau de ton
application. De manière générale, tu as plus de souplesse en gérant
l'authentification au niveau de l'application.
J'ai un petit faible pour Spring Security
(http://static.springsource.org/spring-security/site/). Tu as moyen de
plugger à peu près tous les mechanismes possibles et imaginables
d'authentification et d'authorisation. Par exemple une authorisation
HTTP Basic.
A+
MrG
2012/7/16 François Coppey <frac...@gmail.com>:
Pour la partie authentification, tu peux soit la déléguer à ton
serveur d'appli, soit gérer l'authentification au niveau de ton
application. De manière générale, tu as plus de souplesse en gérant
l'authentification au niveau de l'application.
J'ai un petit faible pour Spring Security
(http://static.springsource.org/spring-security/site/). Tu as moyen de
plugger à peu près tous les mechanismes possibles et imaginables
d'authentification et d'authorisation. Par exemple une authorisation
HTTP Basic.
A+
MrG
2012/7/16 François Coppey <frac...@gmail.com>:
François Coppey
Jul 17, 2012, 8:45:31 AM7/17/12
to ju...@googlegroups.com
Merci pour ton idée d'utiliser SPRING... Mais comme je n'utilise pas du tout ce framework, je ne voulais pas l'utiliser maintenant :D
Mais j'ai enfin trouver la solution avec JAX-RS !!!!
Si jamais, ces sites m'ont beaucoup aidés :
http://www.butonic.de/2010/06/18/a-simple-jax-rs-security-context-example-in-glassfish/
http://docs.oracle.com/cd/E18930_01/html/821-2418/beacr.html
Et au final, c'est beaucoup plus simple que ce que je pensais... Mais faut juste le savoir :D
Mais j'ai enfin une HTTPS + Basic AUTH basé sur JAX-RS ce que je cherchais depuis longtemps :D
Merci à tous de votre aide... Je crois que le sujet est clos maintenant :D ... Il me reste plus qu'à transférer tous mes clients sur une DB... ca va prendre du temps.. mais comem vous dites, c'est la meilleure solution :D
Encore merci pour tout !!!
Mais j'ai enfin trouver la solution avec JAX-RS !!!!
Si jamais, ces sites m'ont beaucoup aidés :
http://www.butonic.de/2010/06/18/a-simple-jax-rs-security-context-example-in-glassfish/
http://docs.oracle.com/cd/E18930_01/html/821-2418/beacr.html
Et au final, c'est beaucoup plus simple que ce que je pensais... Mais faut juste le savoir :D
Mais j'ai enfin une HTTPS + Basic AUTH basé sur JAX-RS ce que je cherchais depuis longtemps :D
Merci à tous de votre aide... Je crois que le sujet est clos maintenant :D ... Il me reste plus qu'à transférer tous mes clients sur une DB... ca va prendre du temps.. mais comem vous dites, c'est la meilleure solution :D
Encore merci pour tout !!!
Guillaume Lederrey
Jul 17, 2012, 8:55:51 AM7/17/12
to ju...@googlegroups.com
Attention, si j'en crois l'article en lien (que j'ai lu en diagonale),
tu t'orientes vers une authentification déléguée au container. La
portabilité en est réduite (chaque container implémente des mechanisme
d'authentification différents) et la flexibilité également.
Bref, je ne dis pas que c'est une mauvaise solution (loin de là), mais
il faut en connaitre les limites ...
A+
2012/7/17 François Coppey <frac...@gmail.com>:
tu t'orientes vers une authentification déléguée au container. La
portabilité en est réduite (chaque container implémente des mechanisme
d'authentification différents) et la flexibilité également.
Bref, je ne dis pas que c'est une mauvaise solution (loin de là), mais
il faut en connaitre les limites ...
A+
2012/7/17 François Coppey <frac...@gmail.com>:
François Coppey
Jul 17, 2012, 8:59:04 AM7/17/12
to ju...@googlegroups.com
Et ca serait quoi les limites???
Guillaume Lederrey
Jul 17, 2012, 2:31:03 PM7/17/12
to ju...@googlegroups.com
En restant dans les grandes lignes ...
Portabilité :
En général, ton serveur d'appli va proposer quelques connecteur
d'authentification :
* fichier local
* ldap
* SQL selon un schema particulier
* ...
Chaque serveur va ête configuré de manière différente pour ces mêmes
connecteurs.
Si tu veux des méthodes d'authentification, par exemple le plugguer
sur un schema de base de données particulier, il va te falloir écrire
du code. La plupart des serveurs vont supporter JAAS, mais le modèle
n'est pas des plus simples ni des plus souples. Il est bien plus
simple d'utiliser Spring Security dans ce genre de cas.
Et pour le moment, nous n'avons parlé que d'authentification. Si on
passe à l'authorisation c'est toute une autre histoire. Dans la
plupart des cas, les shcemas d'authorisation sont bien plus complexes
que les schemas d'authentification. Par exemple la gestion de
hierarchies de groupe, ou d'autres schema complexes. De plus, ton
serveur d'appli va te permettre de poser des contraintes
d'authorisation sur des URL, mais difficilement sur des concepts plus
précis, par exemple de l'authorisation au niveau des méthodes ...
Bref, tout dépend de tes besoins, une authentification / authorisation
uniquement gérée par le serveur est parfaitement utilisable dans de
nombreuses situation, mais elle a ses limites.
A+
MrG
2012/7/17 François Coppey <frac...@gmail.com>:
Portabilité :
En général, ton serveur d'appli va proposer quelques connecteur
d'authentification :
* fichier local
* ldap
* SQL selon un schema particulier
* ...
Chaque serveur va ête configuré de manière différente pour ces mêmes
connecteurs.
Si tu veux des méthodes d'authentification, par exemple le plugguer
sur un schema de base de données particulier, il va te falloir écrire
du code. La plupart des serveurs vont supporter JAAS, mais le modèle
n'est pas des plus simples ni des plus souples. Il est bien plus
simple d'utiliser Spring Security dans ce genre de cas.
Et pour le moment, nous n'avons parlé que d'authentification. Si on
passe à l'authorisation c'est toute une autre histoire. Dans la
plupart des cas, les shcemas d'authorisation sont bien plus complexes
que les schemas d'authentification. Par exemple la gestion de
hierarchies de groupe, ou d'autres schema complexes. De plus, ton
serveur d'appli va te permettre de poser des contraintes
d'authorisation sur des URL, mais difficilement sur des concepts plus
précis, par exemple de l'authorisation au niveau des méthodes ...
Bref, tout dépend de tes besoins, une authentification / authorisation
uniquement gérée par le serveur est parfaitement utilisable dans de
nombreuses situation, mais elle a ses limites.
A+
MrG
2012/7/17 François Coppey <frac...@gmail.com>:
> Et ca serait quoi les limites???
François Coppey
Jul 18, 2012, 12:14:17 PM7/18/12
to ju...@googlegroups.com
Chui pas sûr d'avoir tout tout compris, mais l'essentiel je crois que oui...... :D
Je vais me pencher sur spring security alors et je verrais ca.... Mais si j'ai bien compris, et comme je pars sur une base de données et non plusieurs et qu'également je ne vais pas utiliser de degré différents d'authentification mais juste une autorisation et qu'aussi j'ai trouvé un moyen de réglé les autorisations directement sur les méthodes et non sur l'URL grâce à @RolesAllowed.. Je crois que mon système est bon également.....
Je vais étudier les 2 cas. Merci pour ses précisions
Je vais me pencher sur spring security alors et je verrais ca.... Mais si j'ai bien compris, et comme je pars sur une base de données et non plusieurs et qu'également je ne vais pas utiliser de degré différents d'authentification mais juste une autorisation et qu'aussi j'ai trouvé un moyen de réglé les autorisations directement sur les méthodes et non sur l'URL grâce à @RolesAllowed.. Je crois que mon système est bon également.....
Je vais étudier les 2 cas. Merci pour ses précisions
Reply all
Reply to author
Forward
0 new messages