Discussion :

[alfreedd]

Bonjour à tous!

Je suis étudiant en informatique, et je participe actuellement à la réalisation d'un projet qui s'étale sur un an. Ce projet devra faire communiquer deux programmes qui peuvent être situés sur des machines distantes, avec d'un côté un programme en C++ (l'IHM) et de l'autre côté un programme qui peut être réalisé dans un langage différent (il s'agit des bibliothèques de calcul).
A priori, pour réaliser cela, il me semble logique de s'orienter soit vers CORBA, soit vers la technologies des webservices. Seulement, je ne sais quelle solution choisir. CORBA correspond plus spécifiquement à mon problème, mais semble plus lourd (l'utiliseur devra installer un ORB pour pouvoir faire fonctionner le programme si j'ai bien compris). Les web services semblent plus légers et plus simples àm ettre en oeuvre, mais j'ai apr contre beaucoup de mal à trouver de la documentation dessus, avec des exemple concrets. Aussi je n'ai aucune idée de la difficulté de la mise en place d'un webservice.
Qu'en pensez vous? Quel est pour vous la meilleure solution?

Je vous remercie par avance de votre aide.

[menator]

Hello,

grande question !

Ca dépend de la nature des échanges entre ton IHM et tes bibliothèques de calcul (disons le serveur ). Avec CORBA tu as des vrais objets distribués, avec les WS tu exposes des fonctions côté serveur, ce n'est pas tout à fait la même chose.

Quelques critères en vrac:
1) contraintes de performances ?
2) dialogue stateless / statefull ? i.e: mémorise-tu côté serveur des états relatifs au dialogue entre l'IHM et le serveur.
Corollaire : as-tu plusieurs clients IHM ?
3) veux-tu mentionner les WebServices sur ton CV ?

1) les appels distants avec WebServices sont plus lents en WebServices qu'avec CORBA ou RMI .
Source: "Benchmarking various Java-based middleware" http://www.lifl.fr/~merle/benchmarking.pdf
Exple: appel CORBA 0.1ms, appel WebServices Axis 4ms (!)

Tu fais une IHM, donc tes contraintes de perfs sont à priori faibles : tun'as pas plusieurs centaines/milliers d'échanges par secondes, mais plutôt un par ci par là, lorsque l'utilisateur clique.

-> l'aspect performance de CORBA ne t'apporte rien là, les WebService peuvent te suffir.

2) Quelle est la nature du dialogue ? Quelles sont les messages échangés ?
Si ton serveur héberge une bibliothèque de calcul, je suppose que ton IHM lance juste des calculs sur le serveur et affiche le résultat.
-> à priori ton interface est sans états ("stateless") :le serveur héberge simplement une série de fonctions, ne mémorise pas d'état lors des appels et se fiche de l'identité de l'IHM qui réclame les calculs.
Dans ce cas les WebServices conviennent.
Si ton interaction est "statefull", CORBA est plus pertinent car tu auras des vrais objets distribués, efficaces pour mémoriser l'état d'une interaction.

3) Si tu veux avoir l'air au goût du jour après ton diplôme, ce sera plus vendeur de citer les WebServices que CORBA (ça dépend du milieu dans lequel tu vas bosser dans le bancaire ou le télécom, CORBA a encore droit de cité).

Quant à la difficulté ... je trouve 1000 fois plus facile de faire un petit serveur CORBA qu'un serveur WebServices.
Le design d'une interface IDL est très simple, ça peut se faire à la main, l'interopérabilité entre ORB est assurée.

Ecrire des WebService est une horreur (avis strictement perso), il faut dérouler 50 lignes là de XML (WSDL + XML Schema) là ou 5 lignes suffisent en IDL, l'interopérabilité entre serveurs de WS n'est pas encore au top.
Mais bon les WS sont fait pour être fait avec des outils, donc pas de panique.

Donc ... à toi de voir . Les avantages de CORBA ne sont pas flagrants dans ton cas si mes suppositions sont bonnes. Les WebServices résultent d'un assemblage de technos Web et XML qui sont souvent déroutantes: les WS sont "simples" dans le sens ou ils ne peuvent pas prétendre remplir autant de services que CORBA, mais ils ne sont pas simples du tout dans leur expression (WSDL/XMLSchema). Mais ça peut valoir le coût pour toi d'investir ce monde XML.

Quand à la lourdeur, ce sera probablement la même chose dans les 2 cas: il te faudra installer l'environnement WS ou CORBA (l'ORB) côté client et serveur. La légèreté supposée des WS a disparu depuis bien longtemps (à l'échelle de l'évolution informatique).

Comment ça j'aime pas les WS ??

A ta disposition pour poursuivre la discussion.

[alfreedd]

Merci pour cette réponse rapide!

Alors je vais déjà répondre à tes questions :
1) pas de contraintes de performances
2) dialogue stateless
3) j'ai pas spécialement besoin de mentionner webservices sur mon cv (je suis pas sur que ça ait conservé son effet de mode actuel à ma sortie des études), j'aimerais surtout mener ce projet à bien et dans les meilleures conditions possibles.

A priori je m'oriente vers CORBA mais j'ai quelques questions bien précises.
Est cequ'il existe des outils grauits et efficaces pour développer des web services? (je sais déjà qu'il existe des outils gratuits pour CORBA, moyennement efficaces mais bon)
Peut on trouver facilement de la documentation claire et pratique sur les web services? (là encore aucun probleme pour CORBA, mais pour les web services j'ai bien du mal)
Lorsque l'utilisateur devra installer notre programme sur sa machine, il devra aussi installer un ORB. Tandis qu'avec les web services il n'a rien à installer à part notre application. J'ai bon?

[menator]

A priori je m'oriente vers CORBA mais j'ai quelques questions bien précises.

Ah bon, je te voyais plutôt parti côté WS.

Est cequ'il existe des outils grauits et efficaces pour développer des web services? (je sais déjà qu'il existe des outils gratuits pour CORBA, moyennement efficaces mais bon)

Oui, tu as un plugin Axis pour Eclipse, tout ça gratuit.
Axis : environnement WS de la fondation apache http://ws.apache.org/axis/
Tu peux les trouver tout packagés grâce au sous projet Eclipse WTP (Web tools Platform):
http://www.eclipse.org/webtools/releases/1.0/

Pour CORBA je ne connais pas d'environnement intégré, en général tu codes plutôt à la main (il existe tout de même qques plugin pour Eclipse).

Peut on trouver facilement de la documentation claire et pratique sur les web services

Du côté d'Axis (www.apache.org) il y aura pas mal de doc en english bien sûr.

Lorsque l'utilisateur devra installer notre programme sur sa machine, il devra aussi installer un ORB. Tandis qu'avec les web services il n'a rien à installer à part notre application. J'ai bon?

Non, l'utilisateur n'aura pas besoin d'installer un ORB.
Si tu choisis l'ORB intégré à Java, tu n'as que ton application à fournir à l'utilisateur (l'ORB est dans le runtime Java).
Si tu choisis un autre ORB tu devras seulement packager/embarquer les librairies de l'ORB avec ton application.
Si tu ne veux pas packager les libs de l'ORB dans l'application, là effectivement l'utilisateur devra installer l'ORB.
Certains ORB commerciaux t'imposent peut-être une installation à part.

Avec les WS, même combat: si tu utilises Axis, tu devras livrer les librairies propres à Axis avec ton application, ou l'installer à côté.

[alfreedd]

Merci pour toutes ces réponses, je pense que ça va être décisif pour mon choix. J'était persuasé qu'il fallait installer un orb. Maintenant que je sais que non, la balance penche definitivement pour CORBA.
Une dernière question: vu comment tu présentes les choses, j'ai beaucoup de mal à voir ce qu'apportent les web services par rapport à CORBA. Pourquoi ils connaissent un tel succès alors?

[menator]

Bienvenue dans le monde de l'informatique et du business !

Les Web Services naissent d'une démarche pragmatique:
- "j'ai une grosse infrastructure Web dans ma boite et mes clients aussi, on pourrait pas communiquer ensemble tout en exploitant cette infrastructure déjà installée ?"
- "ben si eh banane, vous allez vous echanger des fichiers XML via HTTP, il suffit de renvoyer du XML au lieu du HTML.
- "cool, ça marche bien, c'est 'achement plus simple que CORBA/RMI/DCOM (même si c'est moins riche). Et en plus ça passe tout seul les firewall car tout passe par le port 80! Allez on va en mettre partout."
... "bon on va normer tout ça avec tous les acteurs du marché, car faudrait voir à pas faire n'importe quoi"
..."Merde, tout le monde a mis son grain de sel dans les normes, ça commence a devenir vraiment n'importe quoi !!"

Trêve de plaisanteries, il y a des motivations interessantes derrière les Web Services, surtout du point de vue des entreprises :
- échanger via XML, qui est d'hors et déjà le langage universel du Web
avec la promesse de messages extensibles, et "lisibles" (i.e non binaires), et au final d'un monde tout XML (avec des dialectes XML pour tous les secteurs économiques)
- réutiliser en partie les infrastructures Web existantes (investissement moindres)
- bénéficier d'une technologie commune de communication entre applications, utilisable dans tous les langages (des implems de WS ont été disponibles très vite dans la plupart des langages)

Bref les échanges entre entreprises se font en XML, souvent en WS. Dans l'entreprise elle-même on met des WS afin de coordonner les applications entre elles. Il faut admettre que l'on voit peu d'entreprises communiquer en CORBA ou RMI...
Et quand tu as des dizaines d'applications qui ont leurs interfaces propres (socket, DCOM, CORBA, fichiers...) on comprend l'envie d'unifier tout ça.

L'unification ne s'est pas faite avec CORBA car ce middleware a une image trop complexe (parfois à juste titre), qu'il n'a pénétré que certains secteurs traditionnellement très technologiques : télécom, finance (d'ailleurs ce sont des boites de ces secteurs qui normalisé CORBA), et qu'il manque d'outils. C'est aussi finalement une faillite du modèle d'objets distribué : est-ce que j'ai vraiment besoin de voir mes objets à distance, avec l'héritage et tout le tin touin ?
L'informatique orientée + gestion et Web a répondu non, et s'est trouvé une autre technologie de communication plus en accord avec ses besoins.

Donc les WS ont explosés et sont encore en pleine ébulition, pour tenter d'arriver à un niveau fonctionnel équivalent à CORBA. Les mêmes causes causeront les mêmes effets: certaines fonctions trop compliquées ou mal designés ont plombé CORBA (trading service, mapping C++ complexe, API du POA aussi). WS souffrira des mêmes maux.
Mais ça restera la techno de communication des années futures (... enfin là ou on n'a pas besoin de performance ... hin hin...)

[alfreedd]

Effectivement on ne m'avait pas présenté les choses comme ça . Bon cette fois ci, c'est décidé, c'est CORBA qui sera utilisé.

J'ai encore une dernière petite question (enfin normalement c'est vraiment la dernière ) : quels sont selon toi les meilleurs outils pour développer en CORBA, sachant que nous devrons travailler en Java et C++, et sous Windows et Linux. Nous avons essayé plusieurs Orb, principalement Mico, mais nous avons toujours eu des gros problèmes d'installation, principalement sous Windows. Existe t il des outils gratuits plus faciles d'utilisation, multi plate-formes et multi langages, et gratuits (parceque sinon nous nous serions payés une licence Visibroker depuis longtemps...) ? Je sais j'en demande beaucoup là...

[menator]

Quelle est ta configuration cible ?
Client C++/Windows serveur Java/Linux ?

Les ORBs C++ que je connaissais sont:
- Mico
- Orbacus (passé dans le giron de Iona, désormais payant il me semble)
- TAO
- OmniORB

Je ne sais pas lesquels sont aisément utilisables/compilables sous windows.

Du côté Java
- ORB du JDK
- JacORB (bonne doc, plein d'exemples)

Existe t il des outils gratuits plus faciles d'utilisation, multi plate-formes et multi langages

Le Père Noël est passé : il existe un ORB CORBA like
- multi plate-forme : Windows / Linux / Solaris / HP-UX...
(avec installeurs pour Windows)
- multi-langages : Java, C++, C#, Python, Php, Visual Basic
(Windows: .NET et VC++6.0)
- sous licence GPL

C'est comme du CORBA (contrat IDL) mais avec quelques ajustements pour simplifier le dev.
Les auteurs sont des rois de CORBA (Michi Henning notamment, un cador du monde CORBA auteur d'un bouquin de référence) qui continuent l'aventure mais en se dégageant de la norme, afin de se bâtir un CORBA + à leur gout:
- suppression de quelques éléments dans l'IDL (any par exemple)
- protocole propriétaire (donc pas IIOP)

Le produit se nomme Ice et est dispo là:
http://www.zeroc.com

Très interessant, de la doc, un peu de condescendance pour les produits CORBA traditionnels, mais franchement ça donne envie d'essayer.

Si ton projet n'a pas besoin d'une compatibilité CORBA, tu peux aller voir de ce côté.
Si ton projet va au delà du projet d'études, que ton client ou ton serveur vont s'intégrer avec d'autres appli, alors là difficile d'imposer "Ice".

Bon courage et n'hesites pas si tu as d'autres questions.

[alfreedd]

Je te remercie pour ton aide (avec un peu de retard ). J'ai bien étudié ICE et notre groupe a longtemps hésité à le choisir, mais nous avons finalement décidé il y a peu de nous orienter vers un standard plus utilisé et plus connu, c'esdt-à-dire CORBA.
En tout cas, tes conseils nous auront vraiment été très utiles, ça nous a permis d'y voir bien plus clair et de mieux nous décider dans nos choix.

[menator]

Ravi d'avoir pu t'éclairer et bon projet avec CORBA !

[mi6fred]

[Désolé du déterrage, mais le sujet vaut le coup]

Je viens de lire votre sujet, c'est réellement très intéressant et vos conseils m'aideront dans mes choix de solution.

Je suis confronté à un problème légèrement différent, si vous en voulez la description complète le thread se trouve ici. Dans mon cas, il s’agit d’une application de distribution de fichiers (des licences de logiciels) dans un modèle P2P. Les licences sont partagées par tous les postes du réseau. Il nous faut trouver un nouveau moyen de communication pour pouvoir passer sous Unix, il y a principalement des contraintes de fiabilité et de performances. Mes quelques recherches m’ont donc orienté vers Corba, et je me suis renseigné sur ICE et Artix de IONA.

Je ne sais pas si mon choix de Corba est judicieux (corrigez-moi si je me trompe). J’ai besoin d’un impact réduit sur l’application en termes de performance et de code. C’est une application commerciale, il me faudrait donc des licences compatibles et un coût de runtime nul. Je n’ai jamais touché à Corba, un bon bouquin et une aide de SDK corrects seraient un plus.

Les deux systèmes ont l’air bons, mais je ne sais pas vraiment lequel choisir, ni si d’autres solutions sont également valables. Je vais sans doute les évaluer bientôt (j’attends la fin des négociations concernant l’estimation des coûts), et les comparer avec la solution précédente, à savoir les pipes Windows, et à des sockets génériques.

Merci de votre aide

[menator]

Tu cherches une techno de communication multi-plateforme, donc considérer CORBA a du sens.

Cependant je n'ai pas saisi si ton transfert de fichier doit passer aussi par la couche de com que tu auras choisi ou si tu le fais à côté (par ftp, http...), une fois la demande de fichier faite. CORBA ne t'aidera pas si tu dois passer un fichier à travers un contrat IDL, bien au contraire (il faudra exprimer en IDL la manière de transporter ce fichier, par ex un tableau d'octets, valable pour des petits fichiers) !

La solution socket ne me semble pas déconnante : tu as aujourd'hui des pipes, qui sont des flux, tu devrais pouvoir les remplacer par des sockets, qui sont un d'autres flux. Si tu échanges du XML, alors l'aspect multi-plateforme ne devrais pas poser de pb, l'échange est en format texte (tu évites le pb de format des données binaires que tu aurais sur un échange purement binaire).

Passer à un ESB me paraît bien lourd. Un ESB est un environnement d'intégration qui permet d'héberger moults services utilisant diverses technos de communication (SOAP, CORBA...), de fédérer ces services, d'en coordonner d'autres (l'orchestration qu'ils appellent ça). Ca se traduit par des conteneurs d'appplications qui sont + proches du bon gros serveur J2EE que du petit serveur de fichier que tu cherches à remplacer.

Les perfs.... tout dépend de la charge que tu imposes : nbre de clients, nombre de requête/s.

Quels sont tes contraintes légales ? Pour le coût de runtime nul, pas de pb, la plupart des ORB sont dans le domaine du libre et ont une licence qui permet de les embarquer dans un produit.

[tet.dum]

Bonjour,
je profite de cette discussion (un peu tardivement...) pour vous poser quelques questions sur le sujet:
je dispose de 2 logiciels (un écrit en JAVA, l'autre en C++). Je dois les faire communiquer par web services. Quelles sont les solutions possibles?
- ecrire le web service en Java ou en C++?
- utiliser JNI
-AXis?
Quelqu'un a-t-il des experiences dans ces domaines?
Merci
tet.dum

[CocoRambo]

Je déterres ce topic mais volontairement... (Ne pas croire que je n'a pas regardé la date )

Je voulais savoir ce qu'il en était au jour d'aujourd hui et le must serait de savoir ce qu'en pense maintenant les personnes qui ont participées à cette discussion ?

Merci d'avance