Discussion :

[Vonotar]

Hello à tous,

j'ai déjà lu des tas de choses là-dessus, sur ce forum et sur MSDN mais j'avoue que je n'arrive toujours pas à dégager les avantages et inconvénients du .Net Remoting et des Web Services.

Comment choisir la bonne méthode ?

Peut-être cela vaut-il la peine que je vous expose le projet que je vais bientôt commencer: un serveur SQL Server 7 et une quinzaine de clients. Le projet est principalement axé sur la mise à jour et l'insertion de champs dans la DB en fonction des actions des utilisateurs: pas vraiment de gros traitement "business".
Par contre, le choix d'un 3ème tiers s'impose car nous avons des contraintes de performance: certaines actions doivent être effectuées en un minimum de temps sous peine de pénalités financières. Nous aurions donc l'application Remoting ou le Web Service côté serveur qui attaquerait la DB directement.

Malheureusement aucune personne dans l'équipe n'a d'expérience dans les 2 technologies à la fois: ceux qui connaissent .Net Remoting prônent son utilisation et il en va de même pour ceux qui connaissent les Web Services. Alors, j'aimerais savoir: que peut-on faire avec .Net Remoting qu'on ne peut pas faire avec les Web Services ? Et inversément ?

Merci à qui pourra m'aider...
Vonotar.

[neo.51]

Pour faire simple :

Un WebService communique via des méssages en XML :
Avantages :
-Tu peux utiliser les réponses XML de ton webservice avec n'importe quel langage.
-Tu passes par le port 80 pour communiquer avec ton webservice donc 0 problèmes de configuration réseau.
Inconvénients :
-Le format xml est trés "verbeux" donc la consomation en bande passante peut-être conséquente.
-Il faut faire en sorte que tous les objets qui vont-être retournés par ton webservice soient sérializables.

En remoting tu communiques en binaire :
Avantages :
-Les méssages sont compréssés et tu limites énormément la consomation de bande passante par rapport à un webservice.
-Tu peux passer n'importe quel objet par remoting même s'il n'est pas sérializable.
Inconvénients :
-Seule une applis .NET peut communiquer avec le serveur via remoting.
-Configuration réseau : je pense que si t'as un proxy qui filtre les paquets, même en utilisant le remoting sur le port 80 il bloquera les paquet puisque c'est du binaire.


Voilà en gros

[dev01]

-Tu peux passer n'importe quel objet par remoting même s'il n'est pas sérializable.

Il faut qu'il soit quand même MarshalByRef dans ce cas.

Sinon je pense que tu ne fait pas le même genre de projet avec le remoting et avec le webService.

Pour moi le webservice va de donner des données. Il ne sert que à ça et ne sais pas faire autre chose. il est donc pratique pour accéder à des données centralisés.

Par contre le remoting est très bien pour des traitements centralisé. en plus il te permet de faire du partage d'information également.

Perso je préfére le remoting, il te permet de programmer comme si tu était dans le même programme.

[Vonotar]

Merci beaucoup à tous les deux pour vos réponses.

-Configuration réseau : je pense que si t'as un proxy qui filtre les paquets, même en utilisant le remoting sur le port 80 il bloquera les paquet puisque c'est du binaire.

Je ne m'y connais malheureusement pas en configuration réseau, mais ne suffit-il pas d'ouvrir le port désiré ? Me trompe-je ?

Par contre le remoting est très bien pour des traitements centralisé. en plus il te permet de faire du partage d'information également.

Qu'entends-tu par 'faire du partage d'information' exactement ?

Il me semble que le Remoting est plus adapté car on devra quand même retourner des DataSets typés au client et la sérialisation en XML risque de manger la bande passante, au détriment des performances si importantes dans le projet.

Un avis là-dessus ? Ou d'autres expériences à me faire partager ?

Merci !
Vonotar.

[olrt]

J'ajouterais qu'avec .NET Remoting il est possible de concevoir des architectures basées sur événement : en effet grâce à .NET Remoting, il est possible de "notifier" le client d'un événement déclenché sur le serveur (moyennant une connection permanente entre le client et le serveur).

Donc le genre d'appli qu'on peut typiquement développer grâce à .NET remoting sont des applis Microsoft du style "instant messaging".

Autre avantage de .NET Remoting , il est possible de concevoir :
1°) Ses propres sondes "formatter" (formatter sink).
2°) Ses propres sondes "transport" (transport sink).
Bien que peu utilisées, cela permet facilement d'insérer une fonction de cryptage ou de compression par ex sans avoir à toucher au code de niveau applicatif.


Comme cela a été dit, les WEB services en revanche sont incontournables dès lors que se posent des contraintes d'interopérabilité avec des technos différentes (J2EE, etc.).


A noter aussi que grâce à .NET Framework 3.0 et à la couche "Communications" (Indigo de mémoire) , il n'y aura théoriquement plus besoin d'implémenter une communication en ASP.NET WEB Service ou en .NET Remoting, il y aura un niveau d'abstraction supérieur et en fait on pourra basculer de l'un à l'autre par configuration.

[Olivier Delmotte]

Il me semble qu'il est possible d'utiliser XML pour le remoting, SOAP plus exactement pour faire du remoting, en tous cas, avec la version 2.0 du framework

[dev01]

Qu'entends-tu par 'faire du partage d'information' exactement ?

J'entend avoir plusieurs client sur les même données de manière transparent (aux accès concourrant près)