Laden...

WCF: WSDualHttpBinding und Alltagstauglichkeit

Erstellt von Christoph K. vor 14 Jahren Letzter Beitrag vor 14 Jahren 2.781 Views
Christoph K. Themenstarter:in
821 Beiträge seit 2009
vor 14 Jahren
WCF: WSDualHttpBinding und Alltagstauglichkeit

Hallo,
diejenigen von euch, die sich ein bischen näher mit der WCF beschäftigt haben, werden sicher wissen, dass man einen Callback-Service-Vertrag nicht über jedes Binding laufen lassen kann, sondern nur über bestimmte - unter Anderen dem WSDualHttpBinding.
Mein bisheriger (naiver) Glaube war, dass es dieses Binding, durch irgeneinen Pollingtrink, oder offenhalten von HTTP-Request, ermöglich auch in Szenarien, wo nur reiner HTTP-Traffik aus Restriktionsgründen erlaub ist, ermöglicht mit Callback-Verträgen zu kommunizieren.
Nähere Studien von Büchern über WCF (die ja noch sehr rar sind) und Traffik-Sniffing brachten mich jedoch zu der Erkenntnis, dass hier nix anderes passieren zu scheint, als ein einfacher HTTP-Verbindungsaufbau vom Server zum Client ?

Nun meine Frage:
Was soll das bringen ? Welcher Client befindet sich denn direkt im Web mit eigener IP - Adresse ? Die meisten Clients hängen doch mindestens hinter einem NAT-Router und selbst hier würde das WSDualHttpBinding ja schon versagen, oder seh ich das falsch?

Mich interessiert jetzt mal schlicht weg einfach ein Szenario , wo ich WSDualHttpBinding einsetzten sollte. Weil wenn ich eh im Intranet kommuniziere kann ich auch TCB-Bindings nehemn.

S
8.746 Beiträge seit 2005
vor 14 Jahren

Kurz gesagt: Das bringt nur was im Intranet. Im Internet sind diese Bindings nicht einsetzbar, bzw. im professionellen Umfeld wird man das nicht an den Start bekommen.

Es gibt bisher auch keine offiziellen Bindungen für SOAP, die z.B. mittels LongPolling arbeiten. Mit Silverlight ist PollingDuplexBinding gekommen, aber das wird zu 100% nicht mit Java-COMET zusammenspielen.

Meine Vermutung: Alles wartet auf HTML5 und Websockets und dann werden die DMZ-Admins ihr schöne Port80-Welt aufgeben müssen.

Alternativ: Baue dir ein VPN.

Christoph K. Themenstarter:in
821 Beiträge seit 2009
vor 14 Jahren

Gut, aber wenn ich auf ein VPN setzten muss, verstehe ich immer noch nicht, wo WSDualHTTP-Binding seite Daseinsberechtigung her hat. Für mich ist das dann totaler Humbug.

S
8.746 Beiträge seit 2005
vor 14 Jahren

Wie schon gesagt: Intranet.

Ansonsten schau mal hier:
http://tomasz.janczuk.org/2009/07/pubsub-sample-using-http-polling-duplex.html
http://tomasz.janczuk.org/2009/09/scale-out-of-silverlight-http-polling.html

Damit hat man dann wenigstens Pub/Sub. Leider wird es ein wenig unschön, wenn man über diese Kanäle dann auch noch Request-Response machen will - in beide Richtungen.

Hier sollte man dann einen Service-Bus einsetzen...

Aber: Interoperabilität sollte man nicht erwarten

Christoph K. Themenstarter:in
821 Beiträge seit 2009
vor 14 Jahren

Ja Intranet schön und und gut, aber wenn ich eh Peer-To-Peer-Bedingung wie im Intranet habe, liegt meine Verständnisschwierigkeit darin, warum man auf das aufgeblähte HTTP statt auf das performate net.tcp setzten sollte.

Du hast da grad den ServiceBus angesprochen...Mir ist dieser Begriff schonmal im Kontext mit Windows Azure in die Quere gekommen.
Hast du damit schon gearbeitet ?, oder ist die ganze Sache noch zu Beta-lastig ?

Danke dir für deine Infos !

S
8.746 Beiträge seit 2005
vor 14 Jahren

Ja Intranet schön und und gut, aber wenn ich eh Peer-To-Peer-Bedingung wie im Intranet habe, liegt meine Verständnisschwierigkeit darin, warum man auf das aufgeblähte HTTP statt auf das performate net.tcp setzten sollte.

Im professionellen Umfeld sieht es doch so aus:

  1. Du hast nur HTTP. Alle anderen Ports sind dicht.
  2. Firewall/NAT
  3. Gegenseite hat dann Mehrfach-Firewalls/NAT/Proxies

Mit P2P-Techniken wie Hole-Punching brauchst du gar nicht erst losgehen. Die hängen dich schon am Eingang der IT-Abteilung auf. Darauf kannst du keine Geschäftsanwendung aufsetzen, selbst wenn es funktionieren würde. Azure versucht ja ähnliches mit der Cloud, aber hier ist der Relay angeblich "vertrauenswürdig". Mal sehen wie das die Admins sehen. 😃
Aber auch die neuen Azure-Relay-Bindings sind im Prinzip nur die alten, aber diesmal vermittelt. Für private Geschichten sind Azure-Dienste hingegen ok, also wenn einfach nur zwei NATs den Fullduplex-Verkehr verhindern, aber die Ports prinzipiell frei sind.

Hast du damit schon gearbeitet ?, oder ist die ganze Sache noch zu Beta-lastig ?

Ist es keine Frage. Aber es gibt ja praktisch nichts anderes für echtes Fullduplex im Internet. Entweder alles per Hand oder wenigstens nur das Binding und dann ein halbwegs stabilen Service Bus drüber. Ich versuche gerade einen NServices-Klon auf das CF zu portieren um darauf eine mobile Fullduplex-Anwendung draufzusetzen. Frag mich nochmal in ein paar Monaten, ob das eine gute Idee war. 😉

Hätte ich ein großes Framework mit WCF würde ich wohl den .NET Service Bus mit PollingDuplex verwenden.