Discussion :

[ChrisPM]

Bonjour,

Je sais que mon titre n'est pas très explicites, veuillez m'en excuser, mais mon problême est difficile à résumer. Dans un souci de détail, je vais écrire un pavé, j'espère que vous aurez le courage de me lire.

Je travaille actuellement dans une entreprise de reprographie, qui fait partie d'un groupement d'entreprises. La gestion de toutes les entreprises du groupe est centralisée sur un seul serveur pour tous les sites, situés dans différentes villes.

Notre application de gestion, éditée et gérée par une société externe, est actuellement utilisée grâce à un système de connexion de bureau à distance, et tout passe par un tunnel VPN sécurisé par-dessus la connexion internet de chaque site. Il y a plusieurs problêmes qui en découlent :

- L'application, et donc l'utilisateur, subit les aléas de la connexion internet (lenteurs, déconnexions)
- En cas de déconnexion, il y a souvent des pertes de données, ainsi que des problêmes d'accès au services à cause de la précédente session qui n'a pas expirée.
- En cas de lenteur de la connexion (on a souvent des problêmes de ping qui monte à plus de 1-3 secondes) l'application est pénible à utiliser car à chaque action on doit attendre son affichage.

au sujet des volumes de données, très approximativement, il y a donc 20-30 clients connectés à un serveur, de manière distante. Plus de 200-300 enregistrements divers par jours (Bons de livraisons, factures, devis...etc)

L'autre problême est que la société qui s'occuppe de ce logiciel est feignate, elle encaisse tous les mois l'argent qu'elle demande et ne fait que peu d'interventions pour assurer un service correct, sans parler du support téléphonique déplorable.

Tout ça pour dire que le grand patron veut se débarasser de cette entreprise J'aurais donc peut-être à proposer une ou plusieurs solutions alternatives.

Ma question, enfin :

Quelle type de technologie (au niveau de l'utilisation, mais aussi de la bande passante nécéssaire) jugez-vous la plus adéquate pour ce genre de cas ?

- Technologie basée sur un modèle web (formulaires clients HTML, puis traitements sur le serveur en php, et utilisation d'une base de données mysql (je redoute que mysql ne tienne pas face à un volume de ce type, qu'en dites-vous ?), ou autre base de données ?

- Technologie client serveur plus classique, c'est a dire une application sur chaque poste client qui se connecterait à une base de données distante sur le serveur

- autre choix ?


voilà, merci de m'avoir lu. et merci d'avance pour votre aide.

[ChrisPM]

Je suis un peu plus réveillé aujourd'hui... j'ai peut-être mal choisi le thème ou poster ce message, veuillez m'excuser !

[zekey]

Et bien, il faudra connaitre plusieurs points importants:

-le nombre d'utilisateurs
-l'architecture client (pc, mac, terminal X)
-le type d'application (consultation, graphique, de gestion pure)
-Si il y a bcp de saisie (plus de 20-25 formulaires)


Je vois 5 solutions:
1) une solution web avec db et serveur centralisé
2) une solution web decentralisé mais avec db qui se synchro
3) Une solution swing a la webstart si l'ui est vraiment compliqué
4) Un rtuc du genre oracle web-forms
5) Que nous te fassions une offre ;-)

--------------------------------------------
Steve Hostettler
ze_key@hotmail.com / www.zekey.net

[ChrisPM]

Salut, merci pour ta réponse

- le nombre d'utilisateurs au total est situé entre 30 et 40, et il peut y avoir plus de 20 utilisateurs en même temps.
- Les cliens seront principlament des PC, mais il est vrai qu'un interface web permettrait plus d'interopérabilité entre plateformes
- L'application consiste à remplir des formulaires, les documents finaux étant imprimés
- Il y a un certains nombre de formulaires, je ne connais pas le chiffre exact, mais je pense que ça peut monter au-delà de 25...

Pourrais-tu me donner plus d'informations, ou des pistes de recherche au sujet des solutions 3 et 4 ? je ne connais pas ces technologies.

Pour finir, de quel type d'offre parle-tu ?

merci encore !

[zekey]

Salut,

- Concernant l'offre c'était une plaisanterie (à moitié) sur le fait que nous(la société que ou je bosse) pourrions vous faire une analyse et eventuellement le coaching.

Concerant le reste

1) Oracle Web forms est une solution d'oracle (la db) pour develloper facilement des application intranet de gestion basé sur une db.
+ Très facile à mettre en oeuvre
- coute chère (licence serveur par cpu)
- Basé sur la technologie des applet, un peu demodé
2) Web Start permet de deployer une application swing au travers du net,
c'est à dire sans devoir l'installer sur chacun des postes
+ Plus sympa que le html
- gros besoin en bande passante. Parce que passe par SOAP ou la serialisation.
- j'ai deja eu des probleme de deployement donc 30/40 postes hétérogène .....
3) La solution HTML couplé a de l'ajax
- ergonomie moins poussé
+ peut de besoin en bande passante
+ plus universel

Pour le prix de dev du moins cher au plus cher
Oracle web forms / HTML / Swing-Web Start
(Mais bon à condition que tu connaisses les technos)

il y aurait encore tout un tas d'autre paramètres à prendre en compte mais bon je vais pas te faire un roman.

[tipiak]

Pour le coté : génération de formulaire, je pense qu'un client swing avec du webstart c'est un peut sortir l'artillerie lourde pour pas grand chose,
pour des formulaires, l'interface reste simple ...
(en gros tu as le serveur plus les Bd ds tes locaux, et les clients utilisent l'appli n swing qui se connecte sur tes serveurs... on va dire que des solutions proposées c'est celle qui fait tourner le plus de truc sur les machines clientes : avantage : tu peux optimiser les echanges entre ces clients et tes serveurs : inconvéniant : c'est une des solutions les plus lourdes proposées en termes techniques et developpement)

sinon pour du web : tu as la solution web centralisée en java avec du struts ou du JSF ou .NET avec des webforms

la web decentralisée, cela me parait trop lourd (synchro des serveurs, et cela implique : un serveur chez les clients ....)

sinon pous adapté au formulaires : la solution oracle est pas mal
avec le portail oracle mais ca ne doit pas être la moins cher (quoi au'il faut voir les temps de developement qui sont plus court que les autres solutions .... car le coté "technique", acces concurrent, acces Bd, persistance ... est gérée en natif ...)

sinon en termes mega pas cher : tu as tjr la solution PHP avec des formulaires et la librairie de génération de doc Pdf ...

pour le choix entre la solution PHP - ou web centralisé (java struts, jsf, webforms) cela dépend plus de la complexié de ta logique métier
(si elle est simple, la solution php passe en tete, si elle est compliquée et au'il y a du traitement poussé a faire sur le contenu des formulaires, ou avant génération de doc : autant s'orienté vers du java ou du .net...)


tu peux aussi faire des solutions mixtes :
genre acces web pour les clients qui remplissent des formulaire
et appli swing en interne pour l'administration du produit, edition des formulaire ....

[ChrisPM]

Merci pour vos réponses.

Il faudra que je me documente sur swing.
Sinon, étant donné que je maîtrise plus ou moins le php (j'ai juste à me remettre à jour avec la dernière version de php, de mysql et à plancher sur les tables innoDB pour faire des transactions) je pense que je vais proposer cette solution à mon patron.

Des formulaires web peuvent être très conviviaux, et avec javascript on peut autoriser la création dynamique de lignes de bl/factures.

Pour ajax, il faut voir, car ça peut nécéssiter une bonne connexion (c'est à dire sans problêmes de ping) dans certains cas, non ?

Sinon, à ce que je sache, mais il faudra que je me renseigne pour confirmation, il n'y a pas de traitements particulièrement difficiles à réaliser.

Et oui la librairie de génération de pdf est une excellente solution pour créer des documents imprimables.

[zekey]

Ajax n'a pas besoin d'une meilleure connection que les autres pages. Dans la mesure ou tu es en deconnecté (HTTP).
Si tu as bcp de logique je ne suis pas sure que PHP soit le meilleur choix.
D'un autre coté si tu economise sur le temps de formation pourquoi pas.