Discussion :

[teto-info]

slt,
Je veux savoir les nouveaux technologies de .net pour la programmation distribuée!

Merci pour votre aide!

[B.AF]

La technologie phare reste l'ESB WCF.
Il y a beaucoup de tutos dessus, après distribué, c'est un concept large

[teto-info]

c'est bien ça que j'ai trouvé! mais j'ai pas trouvé les point forts et les points faibles de la programmation distribuée par rapport Java!!!!

[teto-info]

Saluuuuuuuut!

Dans le monde de .net on trouve la meilleure réponse pour la programmation distribuée est : WCF .
Et dans le monde JAVA on trouve RMI,CORBA...

La question qui se pose: Alors pour la programmation distribuée c quoi le meilleur choix, .net OU Java ????

[B.AF]

Saluuuuuuuut!
La question qui se pose: Alors pour la programmation distribuée c quoi le meilleur choix, .net OU Java ????

En Java, tu vas rencontrer les EJB, qui sont assez simples à mettre en oeuvre et qui ont des notions d'état et de contexte facilement manipulable, avec des conteneurs éprouvés (Jboss par ex). Après tout dépend de comment tu exposes tes services. Si tu veux être plus dans une logique de SOAP / WS (genre XFire ou Axis), dans une logique proprio (IIOP) ou dans une logique web (REST/JSON). Il y a aussi les message beans qui correspondent à du broadcasting /JMS.

En .Net, il y a WCF qui est une implémentation de Soap et qui te permet de spécifier des comportements et des méthodes de distribution, peut être plus simple et plus ouvert que l'équivalent en Java. Enfin plus homogéne.
En revanche, ce qui est persistence est moins lié, mais les technos restent similaires.

Les deux technos permettent de faire les deux assez simplement. Ca demande un temps d'apprentissage, mais il n'y a rien de complexe, les frameworks actuels encapsulent énormément la complexité. La difficulté va venir plutôt d'avoir les idées claires sur ce que tu veux distribuer et pourquoi le distribuer et surtout d'éviter l'orgie de framework.

Ca dépend de quoi tu parles comme distribution. Si comme 80% des gens il s'agit d'envoyer des objets chargés par un orm et de faire des services "add remove update get get all"; abandonnes c'est une perte de temps.

En .Net tu as l'impression d'aller plus vite parce que le développement est bien encapsulé dans VS 2010, mais n'aborde que très superficiellement les problèmes de déploiement, de sécurité. L'apparente facilité est traitre.
En Java, pour créer une environnement de dev correct, il faut quasiment (Avec Eclipse) se mettre en situation de déploiement immédiat.
Le 2nd est plus pénible, mais à l'avantage de former aux problèmatiques tout de suite. Le premier, bon je ne reviendrai quoique grand fan de C# sur la capacité des vendeurs de microsoft et de ses mvp à toujours faire croire que tout est facile.

Bref , je te dirai : fais un serveur d'app sous JBoss qui expose des web services soap sécurisés et persiste des logiques métier dans N bases utilisant soit des proc stocks, soit un orm, construit une couche de test de tes services, et construit un client WPF en .Net qui consomme ces services et publie des messages dans un Apache MQ qui sont consommé dans ton app serveur Java et tu seras pas loin d'avoir compris les problèmatiques de l'architecture distribuée.

Si il y a vraiment une logique de domaines, un bus service avec une hétérogénéité des process et des processus métiers bien identifiés et délimités de façon à ce que chaque service exposé soit atomique ou testable, c'est bien.

Et fais attention à tes perfs. C'est la pire fausse promesse de l'architecture distribuée.