[linux-neuchatel] JBOSS versus ZOPE...

[Didier Frick]

Hello,

On Tue, 2003-07-01 at 19:54, Patrick GELIN wrote:
...
> 
> Je pense que Zope est une technologie pour les petits et moyens projet
> (prototypes) parce que
> ce sont des projets relativements fermés et l'exotisme de Zope n'a pas
> d'impacte sur
> ce genre de projet car il n'y a pas de forte interactions avec
> l'environnement extérieur de type
> Business to Business (B2B). Par contre pour un projet de grande envergure,
> avec de fortes
> interactions de type B2B, il faut utiliser les standards de l'industrie et
> oublier les
> technologies exotiques.

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.

Par définition un grand projet va souvent intégrer et interagir avec
d'autres systèmes. Si on part du principe qu'un grand projet doit être
obligatoirement entièrement réalisé avec l'une ou l'autre
_implémentation_ d'un standard ouvert, on se prépare des problèmes car
fatalement tôt ou tard apparaîtra la nécéssité de s'intégrer avec une
autre plateforme si le projet est suffisamment complexe.

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.

Aussi bien J2EE que Zope offrent un bon support pour XML, qui est
incontestablement le standard de représentation de l'information
connaissant la plus forte croissance à l'heure actuelle.

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....

> 
> >
> > Tout ça me force presque à me demander si je ne devrais pas me préparer
> > moralement à faire quelques courtes présentations de Zope dans la
> > région. Qu'en pense la liste ?
> 
> Je serais évidamment très intérréssé, notamment par une démonstration de
> Collaborative Portal Server® de la société nüxeo car nous envisageons de
> le mettre en oeuvre rapidement (avant fin juillet) plutôt que de développer
> notre propre prototype expérimentale. En ce qui concerne une demo Zope je
> vais en voir une ce vendredi à Genève faite par la société Prolibre.
> 
En ce qui concerne CPS, je pense que l'entité la plus appropriée pour le
présenter est la société Nuxeo elle même, qui connaît son produit
probablement bien mieux que moi.

Comme un intérêt semble exister pour une présentation de Zope lui-même,
que je connais mieux que CPS, je pense qu'on peut partir du principe
qu'une des prochaines présentations organisées sur la liste sera
consacrée à Zope. Je tiens à garder une durée d'1h30 max pour rester à
l'essentiel et conserver l'attention des participants (avec une séance
de questions-réponses et une discussion en plus des 1h30).

Une (ou mieux, plusieurs) proposition(s) de date ? 

Pour le lieu, n'importe quelle salle équipée d'un beamer et d'un écran
de projection ferait l'affaire. J'ai un local à disposition, mais sans
les équipements en question, qu'il faudrait me prêter. Sinon ça m'est
égal de faire ça ailleurs, mais je ne vois pas encore où.

> >
> > Il y a par ailleurs toute une série de questions ouvertes sur la mesure
> > dans laquelle un application Java peut vraiment être considérée comme
> > "ouverte"... puisque que la licence de l'environnement d'exécution n'est
> > pas "open source", et que l'application est inutilisable sans
> > environnement d'exécution... mais ça reste assez théorique comme
> > objection.
> >
> 
> J2EE est une spécification contrôlée par SUN mais conçu en collaboration
> avec des
> industriels qui ont signés une charte avec SUN. Si Microsoft est un
> dictateur qui impose
> unilatéralement sa vision technologique au reste de la planête, SUN est un
> politique qui
> doit obtenir l'accord des signataires de la charte. Bien sur, SUN a beaucoup
> de pouvoir
> et il peut s'il le souhaite agir un à la manière de Microsoft mais je pense
> que ce serait
> mal vu par le consortium qui a signé la charte et cela aurait des
> conséquences pour SUN.
> En ce qui concerne les implémentations de la spécification j2EE, il existe
> des solutions 100% open
> source comme JBOSS. Donc une solution basée sur JBOSS n'est pas 100% open
> source mais elle
> n'est pas n'ont plus 100% propriétaire.
> 
Comme je le disais, mon objection est théorique et stricte: la license
de la plate-forme Java n'est pas Open Source (je parle de la
_plate-forme_, donc machine virtuelle et librairies de classe standard).

En ce qui concerne le "100% open source", il existe une définition
standard publiée sur
http://www.opensource.org/
et acceptée par toute la communauté.

La license utilisée par Sun pour Java (SCSL) n'est pas certifiée par
l'OSI, Java n'est donc pas open source. JBoss l'est, mais dépend de
Java. C'était le sens de ma remarque initiale.

Il est intéressant de constater que deux autres licenses utilisées par
Sun (Sun Industry Standards Source License (SISSL), et Sun Public
License) sont certifiées par l'OSI.

Cela démontre donc bien que Sun fait clairement une différence entre
Java et l'Open Source, puisqu'ils ont délibérement choisi une autre
license pour Java en toute connaissance de cause.

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