Discussion :

[Atsibat]

Bonjour,

J'ai une application de gestion qui travaille avec une base de donnée en local.
La base centralise les écritures comptables ( factures, commandes, clients etc...
Je travaille à une version full web et j'ai le choix entre deux techniques:
- ouvrir l'accès distant à ma base de donnée et interroger ma base en direct depuis un serveur d'application basé sur une autre machine
- développer un web-service sur le même serveur que le SGBD et interroger ma base via ce web-service.

Comme beaucoup d'hébergeurs ferment l'accès distant aux bases de données je me demandais quelle solution était la meilleure et si il y a des raisons valables pour fermer l'accès direct à une base de donnée. (vitesse, sécurité, volume, nombre de connexions?)
Je ne devrais pas dépasser une cinquantaine de connexions simultanées sur la base. c'est un problème?

Pourriez vous m'éclairer?

Merci d'avance pour vos réponses.

[DotNetMatt]

Comme beaucoup d'hébergeurs ferment l'accès distant aux bases de données je me demandais quelle solution était la meilleure et si il y a des raisons valables pour fermer l'accès direct à une base de donnée. (vitesse, sécurité, volume, nombre de connexions?)
Je ne devrais pas dépasser une cinquantaine de connexions simultanées sur la base. c'est un problème?

Les hébergeurs ferment les accès lorsqu'ils cherchent à minimiser au maximum le risque d'attaques sur les serveurs de bases de données. C'est aussi ce que font bon nombre d'entreprises :
- On empêche les accès extérieurs pour minimiser les risques
- On contrôle les accès internes (via le lan)

Pour une application Web, on peut ainsi n'exposer que le site Web sur Internet. C'est ensuite lui qui va communiquer avec le serveur de base de données en interne (sur le lan).

Là où ça peut devenir un problème, c'est lorsqu'un utilisateur doit utiliser un client lourd, ou un client mobile. Là il y a deux solutions que tu as déjà évoqué :
- Soit on expose le serveur de base de données sur Internet pour que le client lourd/client mobile puisse y accéder directement
- Soit on met en oeuvre un web service qui servira de "proxy" : il est exposé sur le Web, et ensuite c'est lui qui gère les communications avec le serveur de base de données en interne via le lan.

A noter que la présence de ce web service rajoute une couche et des traitements intermédiaires, donc les performances peuvent être plus ou moins réduites.

Enfin, dans ton cas apparemment tu n'as pas besoin d'exposer ton serveur de base de données sur le Web. Il suffit juste d'exposer ton site Web et de laisser passer les communications entre le serveur Web et le serveur de base de données.

[Atsibat]

Bonjour,

merci pour la réponse.
En fait il s'agit bien de faire communiquer
[plusieurs clients lourds] +[un portail sur serveur apache]+[sun site de reporting sur serveur Tomcat] avec une base de donnée PostgreSQL.

Pour les connexions serveur j'ai tous les outils mais pour celles venant des clients lourds je me demande comment éviter les problèmes d'injection SQL, les connexions qui restent ouvertes etc...

[DotNetMatt]

Pour les connexions serveur j'ai tous les outils mais pour celles venant des clients lourds je me demande comment éviter les problèmes d'injection SQL, les connexions qui restent ouvertes etc...

En ce qui concerne les problèmes d'injection SQL, ça c'est à gérer dans ton code (utilisation des requêtes paramétrées, validation, etc.) uniquement.

Concernant les connexions, en principe c'est géré par le serveur de base de données directement, via le pool de connexions, donc pas d'inquiétude particulière à avoir. Et encore une fois, il faut t'assurer que ton code va dans tous les cas libérer les connexions afin de minimiser ce genre de choses. Après il est difficile voire impossible de blinder totalement le code, car tu dépends aussi du réseau et plus généralement de tout ce qui se trouve entre le client lourd et ton serveur de DB...

Si tu ne veux pas exposer directement le serveur de DB sur le net, tu peux envisager, outre l'option du Web Service, de faire passer les communications par ton routeur. En gros tu trouves un port libre sur ton routeur exposé sur le net (ex. 1234), et tu routes ce port vers le port utilisé par ton serveur de base de données.

Si tu as une DMZ, il te faudra peut-être faire deux fois cet exercice (en entrée, et en sortie de la DMZ).

[SQLpro]

Certains SGBDR comme SQL Server permettent de créer directement des web services dans le SGBDR évitant le cout du ping pong entre machine....

A +