Alain,
> Je commence à évaluer OPS (Orbeon PresentationServer) et je suis
> intéressé par tout retour d'expérience à son sujet.
De ma part ce sera moins un retour d'experience, puisque je suis l'un
des developpeurs de la plateforme, mais je risque quelques
commentaires ci-dessous.
Je commence par mentionner que OPS 3.0, qui est sorti fin janvier, se
demarque grandement des versions precedentes de par son nouveau moteur
XForms base sur Ajax. C'est la premiere implementation XForms basee
sur Ajax (d'autres implementations s'y sont mises apres). Ceci nous a
permis d'implementer a peu pres tout XForms 1.0, y compris le systeme
d'evenements et les actions. En meme temps, la creation de formulaires
web est devenue la principale fonction d'OPS, au point que nous sommes
en train de considerer appeler la plateforme tout simplement "Orbeon
Forms".
> Le produit est fonctionnellement très séduisant mais qu'en est-il
> des performances par rapport à ce qu'on obtient avec un
> développement "classique" ? Le produit est-il viable pour un projet
> industriel ?
Les versions precedentes (jusqu'a OPS 2.8) ne supportaient pas du tout
Ajax et ne supportaient qu'un tres petit sous-ensemble de XForms
implemente 100% server-side. Mais ces versions ont ete deployees sur
une quantite de projets, principalement en intranet.
Pour 3.0, en toute honnetete, nous avons un recul plus faible. Les
premiers utilisateurs ont effectues leurs premiers deploiements il y a
quelques mois seulement, et nous avons a cette occasion effectue
enormement de travail sur la performance. Ces scenarios de deploiement
sont differents de ceux d'OPS 2.8, puisqu'ils utilisent tous les
fonctionalites avancees de XForms.
Nous pensons que, bien sur, OPS 3.x est viable dans un "projet
industriel", mais tout va dependre du nombre d'utilisateurs, de la
complexite de votre application, et du type de performance auquel vous
vous attendez. Il faut noter qu'avec notre implementation XForms,
comme avec la plupart des applications Ajax, les parametres de
performance ont tendance a changer. Par exemple, on accepte tout a
fait que Google Docs prenne plusieurs secondes a se charger, en
echange d'une interactivite amelioree.
> Que faut-il penser de la base eXist intégrée au produit ?
C'est la seule base XML open source digne de ce nom: concue des le
depart pour XML, XQuery, avec un API REST, etc.
Nous utilisons eXist pour des demos et exemples depuis longtemps, mais
nous deploye eXist sur deux projets recemment. L'un d'eux est un
systeme de saisie de donnees classique qui ressemble a notre example
"DMV Forms" (formulaires en XForms, persistence en XML dans eXist -
belle architecture, soit dit en passant, mais j'y reviens plus bas),
avec une charge d'utilisateur relativement legere. Pour ce genre
d'application, nous sommes tres contents d'eXist.
Le second projet utilise eXist pour faire du data mining. La base est
chargees avec des dizaines de milliers de documents XML, et nous
utilisons XQuery pour en tirer des informations utiles et generer des
rapports (WordML, donc XML aussi). La, nous avons du travailler pour
optimiser les requetes XQuery et obtenir des performances acceptables,
mais nous sommes arrives a des resultats satisfaisants. Il ne faut
tout simplement pas s'attendre a ce qu'eXist ait un optimiseur comme
celui qu'on trouve dans Oracle (mais j'espere que ca viendra).
Plus que l'etat actuel d'eXist question performance / scalabilite,
c'est du cote architecture que c'est tres interessant a partir du
moment ou on l'utilise en conjonction avec XForms. En effet, XForms
est concu des le depart pour manipuler le donnees en XML. De plus,
avec XForms 1.1 (sur lequel nous travaillons en ce moment au W3C),
XForms est utilisable comme un client REST complet (c'etait deja en
partie le cas auparavant, mais 1.1 couvre toutes les methodes, la
gestion des headers, etc.). Donc une page XForms peut directement
attaquer une couche de persistance qui se limiterait a eXist, avec les
operations CRUD effectuees en REST (POST / GET / PUT / DELETE). Pour
de petits projets en particulier, c'est d'une simplicite deroutante,
surtout pour les habitues du object-relational mapping. Ici, on fait
tout en XML.
En passant, depuis lundi eXist vient d'attendre en meme temps les
versions 1.0 et 1.1 finales (1.1 possede un systeme d'indexage de
nouvelle generation).
> Et, enfin, quelqu'un dispose-t'il des docs traduites en français !! ?
Comme mentionne par Eric, nous parlons francais, mais malheureusement
nous n'avons pas suffisamment de ressources pour en faire des
traductions!
Quelques references pour finir. XForms et Ajax:
XForms: an Alternative to Ajax?
http://xtech06.usefulinc.com/schedule/paper/133
Notre blog, qui couvre largement des sujets lies a XForms et OPS:
XForms Everywhere
http://www.orbeon.com/blog/
Le travail que nous effectuons au W3C sur les pipelines XML:
XProc: An XML Pipeline Language (W3C Working Draft)
http://www.w3.org/TR/2006/WD-xproc-20060928/
Notre premier article couvrant XForms et Ajax, debut 2005:
Are Server-Side XForms Engines the Future of XForms?
http://www.idealliance.org/proceedings/xtech05/papers/03-08-03/
-Erik
--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Received on Wed Oct 18 12:57:50 2006
