.NET 2.0 Remoting oder WSE3.0 Webservice
Hallo,
ich bräuchte mal ein paar Meinungen zu dem Thema :
Dateitransfer mittels WSE3.0 MTOM Webservice oder .NET 2.0 Remoting mit Httpchannel und BinaryFormatter.
Was ist performanter, sinvoller ?
Reines Diskusionsthema, keine direkte Fragestellung.
Gruß MC#
Remoting mit httpchannel ist erfahrungsgemäß langsamer. Man kann einen Service, der per MTOM Daten überträgt, sehr einfach in der WCF implementieren. Schnell programmiert, und relativ fix bei der Übertragung.
LaTino
(Meine Empfehlung: stream over http: http://kjellsj.blogspot.com/2007/02/wcf-streaming-upload-files-over-http.html)
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
danke aber WCF ist leider keine Option. .net 2.0 ist das einzige framework das wir einsetzen können
Dann kommt es auf die Implementierung an. Die zwei von dir genannten Sachen lassen sich jedenfalls nicht vergleichen, da MTOM IMO eine Ebene höher im Anwendungsstack liegt als .NET remoting.
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Was ist performanter, sinvoller ?
Remoting solltest Du nicht für Kommunikation übers Internet verwenden. WSE ist sehr aufwändig im Vergleich zu Remoting. Wenn Deine Anwendung also nur im LAN läuft (und auch zukünftig nur im LAN laufen muss), dann solltest Du Remoting verwenden. Wenn Deine Anwendung jetzt oder zukünftig übers Internet kommunizieren muss/soll, dann solltest Du WSE verwenden.
Remoting solltest Du nicht für Kommunikation übers Internet verwenden.
Das hört man immer wieder. Nur hört man nie, warum das so ist. (ich verwende remoting gar nicht mehr, aber da ich einige olle Anwendungen zu pflegen habe, die ganz hervorragend auch übers Internet mit remoting funktionieren, interessiert mich schon, wo der Haken ist...)
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Es kommt schlicht drauf an, wie die Anforderungen sind. Und: Aufgrund der hohen Latenz im Netz sieht deine Architektur u.U. anders aus.
Hier ein gutes Dokument zum Thema:
http://www.thinktecture.com/resourcearchive/net-remoting-faq/remotingusecases
Zusammengefaßt: Im Internet und unter einer üblichen Systemumgebung (Reverse Proxy, Ports-Blocks, etc.) ist Remoting praktisch ohne Vorteile gegenüber Webservices. Und dabei noch nichtmal interoperabel. In eine weniger restriktiven Umgebung sieht das natürlich anders aus. Aber auch hier sind mit Webservices Geschichten wie Server-Callbacks wieder möglich, wenn auch nicht so elegant.
Das hört man immer wieder. Nur hört man nie, warum das so ist.
Remoting-Anwendungen können u.U. so manipuliert werden, dass Code ausgeführt wird, welcher eigentlich nicht im Sinne des Erfinders ist. Deshalb wurde mit .NET 1.1 auch der TypeFilter eingeführt, der benutzerdefinierte Klassen standardmäßig blockt.
Remoting wurde einfach nicht für den betrieb in einer potenziell "feindlichen" Umgebung, wie dem Internet, entworfen. Im LAN mit ActiceDirectory und aktivierter Windows-Sicherheit sind diese Probleme eigentlich nicht relevant, weshalb Remoting auch heute noch im LAN eine gute Figur macht.