Discussion :

[Neva]

Bonjour à tous. Après 12 ans passés chez un éditeur de progiciel, nous souhaitons concevoir une application de gestion pour des entreprises et des établissements publics. Nous ne souhaitons pas nous tromper sur les différents outils et les langages à utiliser dans ce développement. Nous avons une idée sur le sujet mais nous souhaiterions avoir un avis des meilleurs spécialistes car ce choix est fondamental pour la suite de notre entreprise.

Les caractéristiques retenues de cette application sont les suivantes :
- Full Web, client léger, si possible sans composant sur les postes clients
- Multi-Plateformes, compatible tout Serveur Web (WebSphere, Tomcat, Apache, IIS …), compatible tout Navigateur
- Multi-Bases de données (à terme) : Oracle, Sql Server, MySql ou PostGreSql, voire DB2
- Performante et Fiable : jusqu ’à 500 000 personnes gérées, jusqu ’à 100 000 connexions simultanées
- Intégrant toutes les sécurités d ’accès et d ’utilisation et la Traçabilité
- Intégrant du WorkFlow
- Accessibilité multi-supports (Pc, Pda..) en intranet, extranet, internet (pour certaines fonctionnalités)
- Ouverte : échanges avec d’autres applications de gestion et bureautique : Open Office, Messageries, Lotus, Ldap, Bo, Elearning (Aicc,Scorm…)

Nous savons que la question est vaste et que le sujet n'est pas facile mais merci par avance pour vos avis qui nous serons très utiles

[Celelibi]

Bonjour,

Faire une appliation web qui tourne sur tous les serveurs me semble peu aisé. Tu devras forcément utiliser un langage très répandu pour que son support soit assuré partout. Au hasard php ou asp.

Ceci dit je ne sais pas si il existe un module pour permettre à Tomcat d'exécuter de l'asp ou pour permettre à IIS d'exécuter du php.

Pour le multi-bdd il te suffit avec le langage choisi d'utiliser une classe qui s'occupe de la liaison entre tes scripts et la bdd.

Pour supporter une grosse charge il te faudra forcément un gros serveur. La lenteur de ton application viendra sûrement plus de la bdd que du langage choisi.

Pour que ton application soit accessible aussi bien avec les anciennes versions de navigateur que les nouvelles ainsi que les pda et autre mini-navigateurs je te conseil d'utiliser un moteur de template. Tu pourras ainsi choisir le template à utiliser selon le navigateur. Tu pourras par exemple envoyer un template en html-old-school aux vieux navigateur, un en html 4 pour les navigateurs pas trop vieux et xhtml pour les pda et autre.

Pour ce qui est de l'échange avec d'autres applications tout dépend du type d'échange que tu veux réaliser.

[Neva]

Merci pour ces réponses.
Est-ce que tu connais des spécialistes de XML, XHMTL, XSL, XSLT, CSS, Web
Services, Javascript et PHP qui pourraient nous conseiller/valider le socle technique de notre projet avant que l'on démarre nos développements.
Nous sommes sur Paris / RP.

Merci

[Celelibi]

Je suis désolé, mais je n'ai encore jamais eut de contacte avec des professionels du développement web.

De plus ma réponse ne fait pas office de vérité absolue, attends peut-être que d'autres donnent leur avis sur la question.

[rozwel]

Bonjour,

Je ne suis pas non plus un professionel (pas encore) mais je travaille sur un projet avec des contraintes similaires et je confirme ce que dit Celelibi : je ne connais aucun moyen de développer une application FullWeb qui soit compatible avec tous les serveurs d'applications du marché. Dans le domaine il y a au moins deux gros mastodontes complètement incompatibles : Microsoft et ses .NET d'un côté, Java et J2EE de l'autre. Sinon il y a aussi le couple Python/Zope mais c'est encore très marginal.
Pour le multibase de données effectivement il n'y a pas trop de problèmes, en Java en tout cas (la plateforme que j'ai choisi personnellement) grâce à JDBC. Pour ce qui est de la publication intranet/extranet sur tous types de terminaux, il y a des chances que ça intègre beaucoup beaucoup de XML (comme dans tout système qui gère du workflow moderne qui se respecte je pense) donc il faut voir à se renseigner sur des serveurs de publication comme Apache Cocoon ou ObjectWeb PresentationServer (sur plateforme Java également).
Il doit exister des équivalents sur .Net, qui a aussi la préférence pour l'échange avec d'autres applications de bureautique (notamment Microsoft forcément), même s'il existe des outils en Java pour faire ça, mais en moins puissant.

Bref à mon avis, le premier choix pour le socle d'une telle application c'est un choix draconien auquel de nombreux architectes doivent faire face : .NET ou Java. Chacune des deux plateformes a ses avantages et ses inconvénients, et le choix est une affaire de compromis. Ce qui est sur c'est qu'on ne peut pas taper au milieu.

Sinon personnellement je déconseille PHP pour tout ce qui dépasse le cadre du petit site de base, à moins d'utiliser un système de gestion de contenu robuste mais forcément très gourmand comme Typo3 ou ezPublish, et encore...

Bon courage @+++

[Sylvain James]

Pour ce qui est de la publication intranet/extranet sur tous types de terminaux, il y a des chances que ça intègre beaucoup beaucoup de XML (comme dans tout système qui gère du workflow moderne qui se respecte je pense) donc il faut voir à se renseigner sur des serveurs de publication comme Apache Cocoon ou ObjectWeb PresentationServer (sur plateforme Java également).

Dans le même style que Cocoon mais en beaucoup plus ouvert (plateformes JAVA, .NET, Win32) il y a XMLRAD dont l'environnement de développement est très graphique et moins abscons que Cocoon.

Bref à mon avis, le premier choix pour le socle d'une telle application c'est un choix draconien auquel de nombreux architectes doivent faire face : .NET ou Java

Justement, comme XMLRAD repose sur des standards toutes plateformes (XML, XSL, Middlewares multiplateforme d'accès aux données etc.), ce choix n'est pas irrévocable. Il est relativement aisé de migrer une appli XMLRAD .NET vers XMLRAD .JAVA

Sylvain

[waldo2188]

Personnellement (avis d'un non professionnelle) je choisirais le Php pour la partie présentation. Si le développement d'une structure PHP est bien réalisé, surtout avec la nouvelle version, il n'y aura pas de problème.

Java apporte aussi une portabilité, c'est ce que tu cherchais (j'ai cru comprendre). Car Java ne se cantonne pas à un Système d'exploitation, contrairement au technologie .net de microsoft.
Et pour répondre a une question situé quelque poste plus haut, il IIS peut géré du php, mais l'instalation n'est pas très facile.

Pour ce qui est du choix du serveur je prendrais Apache, c'est ce qui est utilisé dans l'une des plus grande banque française(ca et Java)

Vu la taille du projet je te souhaite bonne chance, biensûr ce que je vien d'écrire n'est pas à prendre pour argent comptant, je n'est pas la science infuse.
Sur ce bonne journée.

[rozwel]

Car Java ne se cantonne pas à un Système d'exploitation, contrairement au technologie .net de microsoft.

Juste pour apporter une petite précision qui complexifie encore le choix d'une plateforme applicative côté serveur : .NET est exploitable sur Linux (et me semble-t-il sur Unix) grâce au projet Mono qui, si elle n'est pas encore aussi aboutie que l'implémentation de Billou, est prometteuse (et sponsorisée par Novell).

Il n'y a pas de plateforme meilleure qu'une autre. Tout dépend des contraintes. Et je reste sur l'idée que PHP n'est pas adaptée à la complexité d'un projet de cette ampleur. On ne fait pas des gâteaux avec de la terre glaise : PHP est né comme un langage de scripting et même s'il a beaucoup évolué, le développement PHP ne dispose ni du niveau ni de la robustesse d'un J2EE ou d'un .Net Les choses progressent mais on en est pas encore là.

Je crois que l'idée générale c'est qu'il faut s'enlever l'idée de pouvoir couvrir toutes les plateformes avec une seule base. Soit il faut choisir, soit il faut se préparer à mener plusieurs bases de codage en parallèle.

[Neva]

Merci pour toutes ces informations.
Notre souci étant d'apporter à l'utilisateur une interface graphique plus ergonomique que des pages html classiques et souvent statiques (mais sans mettre en place du client serveur classique), nous étudions actuellement une architecture "client riche" en utilisant des technologies telles que XPFE-XUL.

Le dialogue entre le poste client et le poste serveur web reposerait sur des protocoles XML-RPC, Soap... On utiliserait également des Web Services.

Entre le serveur Web (qui pourrait être PHP, .Net ou Java) et la base de données (Oracle, SQL Server, PostGreSql), on mettrait en place des connecteurs relativement simples (l'application se résumant essentiellement à des ajouts et modification de données. Il n'y a pas en effet de gros traitements compliqués).

Pour la partie cliente, on envisage donc de découpler la présentation (rendu graphique) du traitement des données.

Ce type d'architecture permettrait d'apporter à l'utilisateur une ergonomie plus riche (il s'agit d'une application de gestion), de limiter les développements sur la partie serveur web et sur les connections avec la base de données. Cela permettrait donc d'adapter l'application sans trop de développement sur les 3 plateformes Web et sur les 3 ou 4 bases de données que l'on souhaite utiliser.

Qu'en pensez vous ?
Quelles sont les risques de ce type d'architecture ?
Que pensez vous de l'architecture "client riche" ?

Merci pour votre contribution.