[linux-neuchatel] JBOSS versus ZOPE...

[Didier Frick]

Hello,

On Wed, 2003-07-02 at 08:20, Patrick GELIN wrote:
> Bonjour,
> 
> > Pas tellement d'accord: pour des grands projets, il faut avant tout
> > utiliser des formats de _données_ standardisés, notamment basés sur
> > XML.
> 
> XML c'est bien mais les WebServices c'est pas mal non plus! Ce qui est 
> intérressant avec J2EE c'est qu'il y a une grande liberté dans le choix des 
> technologies pour collaborer et pas seulement pour faire un éechange basic de 
> données mais aussi pour solliciter directement des services d'un business a un 
> autre. Je crois avoir lu quelque part que Zope ne supporte pas Soap, par 
> conséquent on ne peut pas utiliser les WebServices!

Les Webservices sont fortement basés sur XML, encore une "opposition"
entre deux technologies qui n'a pas lieu d'être. 

Le support SOAP pour Zope est encore rudimentaire, mais il existe et je
suis prêt à parier que d'ici la fin de l'année il sera complet. 

Peut-être que ce sera trop tard pour ce projet, mais je doute aussi que
l'intégration des Webservices soit une première priorité dans le cahier
des charges. Si j'ai bien compris il s'agit en premier lieu d'un portail
web "classique".

L'architecture de Zope rend très facile l'accès à des services
identiques à travers des protocoles différents. Par exemple il supporte
déjà très bien XML-RPC (ancêtre de SOAP), et un même service peut être
accédé par HTTP ou XML-RPC sans y changer une ligne de code. L'objectif
du support SOAP est le même. Au bout du compte, les appels de services
par des protocoles réseau sont tous mappés sur un appel de méthode
Python avec les paramètres correspondants, donc la séparation entre le
mécanisme de transport et la logique de l'application est totale.

> > Ceci est particulièrement vrai pour le B2B, puisque par définition il
> > concerne l'échange d'informations entre des organisations différentes,
> > et qu'il est illusoire de prétendre imposer une implémentation unique
> > à toutes les organisations partenaires.
>  
> Oui c'est vrai que c'est illusoire, mais comme tu l'a fait remarquer dans un 
> mail précédant SUN est très actif pour vendre son J2EE et j'ai bien 
> l'impression que l'on baigne dans un océan J2EE...

Oui, mais n'empêche que c'est illusoire comme tu l'admets toi-même ....

> 
> > D'autre part, selon une échelle réaliste, je pense que le projet en
> > question mérite plus d'être catégorisé comme "moyen" que "grand".
> > Si on compare la création d'un portail pour l'enseignement dans le
> > canton de Neuchâtel avec le système de réservation aérienne SABRE, la
> > bourse électronique suisse, ou le logiciel de pilotage d'un engin
> > spatial, ça remet un peu les choses en perspective....
> 
> Il ne faut pas croire que le spatial est plus complex que le social. Si il 
> n'existe encore pas de solution satisfaisante pour les C3MS (Systeme de 
> Management pour les Communauté, le Contenu et la Collaboration) c'est que ce 
> n'est pas aussi simple que cela. Je crois qu'il ne faut pas sous estimer la 
> complexite de ce projet. On attend quand même plus de 1500 login simultanés, 
> pour servir plus de 30000 élèves et un millier d'enseignants. Si vous voulez un 
> portail complet vraiment C3MS, mon point de vue est que c'est du gros projet 
> qui se compte en année/homme de développement.
> 

Ce n'est pas une question de domaine d'application (spatial vs. social),
mais de complexité. Le système SABRE gère des dizaines de milliers
d'utilisateurs répartis sur toute la planète, ainsi que des dizaines de
milliers de vols chaque jour. La bourse électronique suisse gère aussi
des milliers d'utilisateurs et des dizaines de milliers de transactions
par jour en _temps réel_ (moins d'un dixième de seconde de délai par
transaction). 

Pour ma part il est évident que ces applications sont notoirement plus
complexes et exigeantes qu'un portail de communauté. Il ne s'agit pas de
déprécier tel ou tel projet ou domaine d'application, mais de ne pas
perdre de vue le contexte général. J'essaie simplement d'être objectif
et d'admettre que d'autres gens, ailleurs, à un autre moment, ont eu
affaire à des problèmes nettement plus ardus que moi dans mon petit
coin.

En ce qui concerne l'existence d'un C3MS satisfaisant, pour moi il y en
a déjà au moins un qui s'appelle Zope, avec les extensions adéquates.

Et peut-être même d'autres basés sur J2EE: une simple recherche Google
"J2EE Portal framework" donne déjà en première position un résultat très
intéréssant:
http://jporta.sourceforge.net/

Sur quoi te bases-tu pour affirmer qu'il n'existe pas de solution C3MS
satisfaisante à l'heure actuelle ?

Si on veut réinventer la roue, c'est bien clair que ça va coûter des
années/hommes. Si on utilise un "framework" existant et bien pensé, je
pense qu'un effort supérieur à 6 mois à 1 année/homme serait
disproportionné, au moins pour une première version supportant 80% des
fonctionnalités.


-- 
Didier Frick  
Freelance Software Developer & Consultant
http://www.dfr.ch/