Discussion :

[etiennegaloup]

Bonjour,

j'aimerais développer une application client/serveur avec un SGBDR.
La database utilisée possèdera une table client, une table fournisseur, une table commande, etc.
L'application permettra de gérer, d'ajouter, de rechercher un client, fournisseur ou commande....

Quelle architecture me conseillez-vous d'adopter ?
Parmi les différentes possibilités qui s'offrent à moi, je pense aux sockets, aux application web (struts), aux applets .....
Si j'utilise les sockets par exemple, comment dois-je m'y prendre ? Dois-je installer la partie interface graphique sur les clients ? Ces clients doivent-ils alors interroger directement la base de données ? Ou doivent-ils passer par une application serveur via les sockets ?
Ou la partie graphique se trouve-elle sur le serveur ?

Si je développe une application Web, suis-je obligé de développer l'interface graphique en HTML ? Je pense que oui ? Je suppose que je ne peux pas utiliser swing ou awt ?
A moins que je n'utilise des applets ? Mais est-il conseillé de développer une application client/serveur avec des applets ? Est-ce vraiment adapté ?

Que convient-il le mieux ?

Merci pour vos commentaires, explications et autres remarques.
++

[zekey]

Attention tu dis vouloir une application client/serveur, une applet et à forcerie struts n'en sont pas.

Tout d'abord dis nous si tu veux un client lourd/ riche ou une appli web.
Pour ca le parametre principal est le nombre d'utilisateurs et l'hétérogénéité du parc cible.

[Jacques - 06]

Juste une précision, généralement lorsque l'on parle de "client/serveur" on entend par là une architecture 2 tiers avec client "lourd" et serveur de données. Mais il semblerait que tu ne sois pas fixé sur l'architecture que tu voudrais mettre en place, et comme tu le présumes il existe pas mal de solutions dépendant des contraintes de ton application.

1 - le client/serveur simple : tu développes ton application en swing et seuls les accès à la base de données se font sur le serveur. Tu n'as pas à te préoccuper de la communication entre le client et le serveur, c'est la couche JDBC qui s'en charge (l'url contient l'adresse du serveur de données). Cette solution est très simple car elle est très proche d'une application standalone. Par contre elle nécessite de d'être déployée sur chaque poste client (Java Webstart permet de faciliter cela, ainsi que les mises à jour) et elle peut poser des problèmes suivant l'architecture réseau entre le client et le serveur (ouverture de ports/protocoles sur un firewall).

NB: la programmation par socket, à mon avis, ne doit jamais être envisagée pour ce type d'application, étant de trop bas niveau et donc plus difficilement maintenable.

2 - l'architecture n-tiers qui peut elle aussi se décliner en plusieurs approches:

a) "sans web" : un client lourd implémentant la couche de présentation uniquement, une couche métier (business logic + persistance) déployée sur le serveur. Le client communiquant avec le serveur en utilisant un protocole réseau (RMI par exemple, car inclus dans Java). L'inconvénient est qu'il faut gérer des problématiques de communication réseau et que l'on peut avoir des problèmes avec les firewall et qu'il faut déployer l'application sur les postes clients (même package plus "léger" qu'en 1).

b) "web et client lourd" : d'une approche similaire à la précédente si ce n'est que du côté serveur les services métiers sont déployés sur un serveur J2EE et que la communication entre client et serveur se fait en HTTP. Le client peut être un client swing ou même une applet. Un des moyens de faire appel aux services métier peut être par exemple de développer ceux-ci sous forme de Web Services (SOAP, ...) mais il existe d'autres possibilités), l'avantage de tests Web services est qu'ils peuvent être réutilisables, même par un client non Java (.Net, VB, ...). L'inconvénient dans ce cas est qu'il faut toujours déployer l'application sur les postes clients (transparent dans le cas d'une applet, mais attention dans ce cas à la compatibilité entre browser, généralement réglé en instant un Java Plugin => installation d'un module sur le poste client)

c) "web" : c'est l'approche web classique avec un client léger en html développé en JSP, XML/XSL, ... et une application web déployée côté serveur. Donc plus de problème de déploiement sur le poste client, par contre les inconvénients sont : nécessité d'une bande passante réseau plus importante (pouvant être optimisée en utilisant "à bon escient" par exemple des systèmes comme Ajax) et les possibilités d'IHM sont souvent plus réduites (restrictions HTML, mais pouvant être contournées au moyen du client "riche" : XUL, ... mais là encore attention aux problèmes de compatibilité avec tous les browsers.

Bref, comme tu peux le voir, comme souvent il n'y a pas une seule réponse, tout dépend du contexte et des contraintes de ton application.
Il faut prendre en compte les contraintes suivantes :
- ergonomie : simple / complexe (HTML / swing)
- réseau : débit, sécurité (protocole HTTP / RMI / autre )
- déploiement : installation sur le poste client oui / non (nombre de postes clients, fréquence de mise à jour, ...), possibilité d'installer des applicatifs tiers : plugin, java webstart (client lourd / client léger)
- délai de mise à disposition : utilisation de technologies déjà maitrisée, ...
- objectif du projet : éducatif, professionnel

Le choix n'est pas toujours simple surtout dans un contexte d'application professionnelle, tout particulièrement si elle doit être déployée chez des clients.

Mais dans tous les cas, toutes ces architectures sont envisageables.

Si je développe une application Web, suis-je obligé de développer l'interface graphique en HTML ? Je pense que oui ? Je suppose que je ne peux pas utiliser swing ou awt ?

Si, tu peux utiliser swing/awt avec une applet.

A moins que je n'utilise des applets ? Mais est-il conseillé de développer une application client/serveur avec des applets ? Est-ce vraiment adapté ?

Pourquoi pas, tout dépend des contraintes citées plus haut

je pense aux sockets

Comme je l'ai dit, pour moi cette solution n'est pas envisageable, sauf si c'est à titre éducatif pour faire de la programmation réseau.

Voilà, excuse-moi d'avoir pondu un roman, mais la question est vaste et n'a pas de réponse unique. J'espère néanmoins que tu y trouveras des éléments qui te permettrons de répondre toi-même à ta question :

Que convient-il le mieux ?

Jacques Desmazières

[etiennegaloup]

Bonjour et merci pour ces réponses.

Attention tu dis vouloir une application client/serveur, une applet et à forcerie struts n'en sont pas.

Ah ? Pour les applets, je me doutais mais je pensais que l'on pouvait considérer une application web comme client/serveur.

Voilà, excuse-moi d'avoir pondu un roman, mais la question est vaste et n'a pas de réponse unique

C un peu ce que j'attendais. Je suis tout à fait concient que plusieurs solutions s'offrent à moi et qu'il n'y en a pas qu'une. Je vois déjà mieux comment je dois m'y prendre en fonction de l'architecture.

J'avais déjà réfléchi aux problèmes de déploiement, aux problèmes d'interface graphiques, aux problèmes en cas de mise à jour.

Jusqu'à combien de clients, la solution du client/serveur simple convient ?

En fait mon application devrait être utilisé par une vingtaine de personne. Les clients se trouveront sur le réseau local et sur internet.
Là je présume que l'application web serait assez adapté, non ?
J'ai déjà développé une appli web en php et j'ai trouvé le html assez contraignant pour le côté IHM. Et puis Il faut souvent utiliser aussi le JavaScript en parallèle.
Est-ce qu'il existe des solutions autre que XUL qui permettraient de faciliter tout ça ?

Merci pour tout
++

[willy78]

Bonjour

Il existe d'autre alternatives coté client XUL en est un exemple. Si tu as besoin d'avoir beaucoup d'interactivité cote IHM, tu peux jeter un oeil sur openlazlo http://www.openlaszlo.org/. Il permet de générer des interfaces interactives et les données peuvent provenir d'un service web

Cordialement

[yolepro]

Bonjour

Il existe d'autre alternatives coté client XUL en est un exemple. Si tu as besoin d'avoir beaucoup d'interactivité cote IHM, tu peux jeter un oeil sur openlazlo http://www.openlaszlo.org/. Il permet de générer des interfaces interactives et les données peuvent provenir d'un service web

Cordialement

C'est très jolie, mais c'est quand meme propriétaire (Flash powered)

[etiennegaloup]

Et sinon autre chose ?

J'avais pensé aux applets, parce que ça permettait de faire du swing et d'utiliser un navigateur web.

C'est très jolie, mais c'est quand meme propriétaire (Flash powered)

T sûr que c propriétaire ?

Ciao

[willy78]

Bonjour

C'est très jolie, mais c'est quand meme propriétaire (Flash powered)

La technologie flash est propriétaire comme peut l'être SWING, mais le produit permettant de générer le flash n'est pas propriétaire, il est ditribué sous CPL Common Public License.

Cordialement

[Jacques - 06]

Vu tes contraintes, mais si tu veux pouvoir évoluer en terme d'architecture, tu peux partir sur une architecture web avec client riche.

Dans cette architecture, si ta principale contrainte est au niveau de l'ihm, mais que tu n'es pas certain de quelle techno choisir, la solution pourrait être de créer une application serveur orientée métier / services, et une couche présentation bien découpée. Pour la partie serveur je vois bien une architecture de type services web, avec un client utilisant ceux-ci, développé par exemple en swing sous forme d'applet ou de client lourd avec Java webstart pour le déploiement.

Ainsi, le jour ou tu veux passer à un autre type de client (html, VB pourquoi pas, XUL ) il te suffit de réécrire la couche de présentation en réutilisant la couche métier telle quelle.

Jusqu'à combien de clients, la solution du client/serveur simple convient ?

Pour ce type d'architecture, je dirais que la limitation ne se situe pas au niveau de l'application elle-même, mais plutôt de son déploiement, car tu dois installer quelquechose (l'application, Java Webstart) sur chacun des postes clients. Donc tout dépend de tes contraintes de déploiement. Cette solution n'est peut être pas très adaptée dans le cas où tu ne maîtrise pas le "reseau" de tes utilisateurs : comme installer sur le poste client, tes utilisateurs sont-ils capables d'installer l'application, ... ?
Sinon en terme de charge, cette solution est adaptée, d'autant plus qu'elle est beaucoup moins gourmande en terme de bande passante réseau une fois l'appli installée. Mais attention aux problèmes de sécurité liés au protocole d'accès à la base de données, pour passer au travers des firewall pour tes clients internet (problèmes de DMZ, ...).

Là encore pas de solution unique, au final tu devras prendre la décision par toi-même, car tu es le seul (tout du moins sur ce forum) qui maîtrise tous les tenants et aboutissants. Mais si on peux t'aiguiller, parfait

Jacques Desmazières

[etiennegaloup]

Pour la partie serveur je vois bien une architecture de type services web

Struts par exemple ?

En tout cas, je vous remercie pour toutes vos réponses et surtout Jacques-06, je vais étudier tout ça.

[Jacques - 06]

Struts par exemple ?

Non je parlais plus d'une architecture orientée service, construite à base de services SOAP (Web Services) et un client lourd de type XUL, Swing, ... Dans ce cas le serveur Web ne sert qu'à fournir des services de type HTTP et ne gère pas du tout la présentation.

Struts permet de créer une application Web basée sur le modèle MVC2, et s'applique à la génération de HTML Ce qui dans ton cas ne conviendrait pas du fait des limitations de HTML, si j'ai bien compris !

En tout cas, je vous remercie pour toutes vos réponses et surtout Jacques-06, je vais étudier tout ça.

De rien et amuses-toi bien, le domaine est vaste et peut être interessant

Jacques Desmazières

[etiennegaloup]

Et bien merci encore,

et c parti pour faire du web service.

++