C'est bien ce que je sous-entendais. 2-3 jours pour s'y mettre, pour creer des objets sur une machine et y acceder depuis une autre. En gros, pour faire du SOAP. Corba est beaucoup plus riche avec quantité de services mais ceux-ci sont facultatifs (et d'ailleurs absents du JRE standard). De la meme maniere que les services annexes de SOAP sont en cours de definition ailleurs et sont absents de SOAP lui-meme.Disons qu'il faut 2-3 jours pour comprendre le principe si on part de zeroTu est cour , les POA c'est quand même un poco complexe, et comprendre tous les services annexe
Sécurité, transaction,IIOP et le reste voir la norme !!!!!.... ca prend nettement plus de 2 jours !!!! (enfin pour moi)
Sauf bien sur si on l' utilise comme un simple RPC
Ce que j'essaye de dire, c'est que SOAP est plus complique que CORBA et
que SOAP+UDDI+WSDL+... est plus complique que CORBA+SERVICES.
Corba, dans son utilisation premiere, n'est pas complexe en Java,
les Holders c'est super propre et intuitifs moi je trouve pas trop, la gestion des erreur....Les Holders et Helpers: c'est propre (comment faire autrement compte tenu des limites de Java ?), ce n'est pas complique mais ce n'est pas intuitif (faut bien s'occuper pendant ces 2-3 jours).
un peu plus en C++, penible en C (et autres langages non OO) et franchement ultra-simple en Python, Perl, ...
Sauf a faire du pur C, SOAP est plus complexe. Toutefois, on devrait voir arriver progressivement de bons outils qui genereront tout ce qu'il faut pour que ce soit (presque) transparent (en gros comme Corba).
ces outils existe déja et je t'ai même cité une liste !!!;-) Je me suis un peu emporte. J'en ai marre d'entendre tout le temps que Corba c'est complique alors chaque annee depuis six ans, nos stagiaires apprenent ca tres rapidement.
et la je te rejoint sur le fait que certaine implemention ne sont pas a maturité est était bien plus complexe a utilisé que Corba en simple RPC
En fait je crois vraiment que certaines implementation de SOAP on vraiment nuit a ce standard
il n'y a qu'a voir voir votre agressivité sur ce standard !!!
Dans bien 80% des application distribuées que j'ai pu rencontré il est bien plus utilisé en dessous de son cadre de fonctionalité
Ca, c'est de l'argument ! ,
J'essaye juste d'argumenter avec l'experience que j'ai des middleware(et je crois sincèrement pouvoir dire que j'en ai une) guillaume maintenant si tu juge que ce n'est pas un argumentOk. Ce que tu as ecrit, c'est que 80% des applis distribuees n'utilisent qu'une petite partie (le coeur) de Corba. Je suis d'accord avec toi mais je n'en tire pas les memes conclusions.
peut être a tu raison , a près tous a moi il ma fallu plus de 2jours pour comprendre(du moins essayer ) CORBA
Si je prends le meme raisonement, 80% des applis Java n'utilisent pas java.rmi ou java.security. Donc il ne faut pas utiliser Java ? Il faut l'utiliser que pour des projets "ayant des contraintes de securite, de transaction ou autre service" ?
Corba est un ensemble de reponses elegantes aux problemes de distribution. Il permet de faire du client/serveur multi-langages multi-os en une dizaine de ligne. En ce sens, il est nettement plus adapte pour faire un outil d'admin, du calcul reparti ou du multi-agent que SOAP.
Cordialement (I mean it)
A+ Guillaume
