Kommunikation MFC mit .Net

Hallo,

als Einsteiger in die verteilten Anwendungen bin ich ziemlich überfordert mit der Fülle an Informationen in diesem Forum, deshalb meine Frage:

Ich habe eine alte MFC Applikation die mit einer .Net Applikation kommunizieren soll. Das ganze muss nur innerhalb des Intranets funktionieren, sollte aber für zukünfige .Net Framework Versionen leicht migrierbar sein. Aussdem sollte die Kommunikation sehr schnell sein, weil ziemlich viele Daten versendet werden.

Welche Technoloie verwendet man am besten?

Hallo,

wenn die Applikation in C++ geschrieben ist und du die möglichkeit hast, diese für .NET zu übersetzen (/cli), dann: Remoting

ansonsten gibt es einige Wege:* Native Socket Kommunikation

• CORBA (nicht in .NET direkt enthalten; 3rd Party)

Grüsse,
Egon

Hallo taraneas,

.NET Anwendungen sind im allgemeinen sehr "kontaktfreudig". Im Framework 3.0 sind folgende Kommunikationstechnologieen eingebaut:
**
Remoting**

Leichtgewichtig und schnell, aber properitär und nur zwischen .NET Anwendungen einsetzbar. Remoting ist zwar toll, scheidet aber als direktes Kommunikationsmittel aus. In Verbindung mit einer COM-Wrapper-DLL, die über eine COM-Typbibliothek (TLB) von Deiner MFC-Anwendung konsumiert werden könnte, wäre die MFC-Anwendung in der Lage, mit einer entfernten Remoting-Applikation über TCP oder HTTP zu kommunizieren. Je nach Größe der Lösung kann das Schreiben von Wrapper-Assemblies aber sehr aufwändig werden. Vorteil von COM-Wrappern ist, dass man sie auch z.B. von Office-VBA-Code oder VBScript (was Admins oft verwenden) verwenden kann, um auf die entfernte .NET Anwendung zuzugreifen.

Enterprise Services

ES ist die Integration der in Windows eingebauten COM+-Technologie ins .NET Framework. Damit lassen sich .NET Geschäftskomponenten schreiben, die man im Windows eigenen Applikationsserver COM+ (früher Microsoft Transaction Server) laufen lassen kann. Als Kommunikationsprotokoll kommt DCOM zum Einsatz. DCOM ist direkt in Windows eingebaut, sehr mächtig und vor allem sehr schnell. Leider sind ES Serverkomponenten sehr aufwändig zu deployen und zu versionieren. Auf jedem Client muss ein Proxy-Installationspaket ausgerollt werden, welches die nötigen Schnittstellen-DLLs registriert. ES-Komponenten-Proxies werden wie Standard-COM-DLLs in die Client-Anwendung eingebunden und verwendet. ES (COM+) wird zukünftig immer mehr an Bedeutung verlieren. Was man früher mit COM+ gemacht hat, wird seit .NET 3.0 mit WCF gemacht. Aufgrund dieser Tatsache und des doch nicht unerheblichen Deployment-Aufwands, möchte ich Dir von ES als Kommunikationsmittel eher abraten.

**TCP/IP Sockets **

Direkte TCP/IP-Kommunikation auf Stream-Ebene ist mit C# relativ einfach zu implementieren. So können sich .NET und MFC-Anwendung direkt und ohne unnötigen Overhead unterhalten. Natürlich muss man sich um alle Belange der Kommunikation bei dieser Variante selber kümmern. Ich kann allerdings nicht abschätzen, wie aufwändig eine Socket-Implementierung mit C++ ist. Aber ich denke, dass man wesentlich mehr Code hinschreiben, als bei C#.

HTTP-Kommunikation (bzw. REST)

Das .NET Framework enthält die Klasse HttpListener, mit der man einen eigenen kleinen HTTP-Server aufsetzen kann. Unter der Haube wird HTTP.SYS des Windows-Kernels verwendet. Deshalb funktioniert das erst ab Windows XP/2003, da ältere Windows-Versionen noch keine eigenständige HTTP-Komponente mitbringen. Wie man direkte HTTP-Befehle innerhalb einer MFC-Anwenung absetzt, weiss ich nicht, aber zur Not kann man ja auf Sockets zurückgreifen. Wenn Deine Anwendung nicht auf alten Windows-Versionen laufen muss, kann das Versenden von XML-Dokumenten über HTTP eine einfache, aber komfortable Kommunikationsmöglichkeit sein. Natürlich könnte man auch einfache Textnachrichten statt XML versenden. XML hat da aber dank Schema-Validierung doch die Nase vorn.

MSMQ (Message Queuing)

MSMQ ist auch Bestandteil von Windows und wird von .NET gut unterstützt (Namensraum System.Messaging). Da es MSMQ schon echt lange gibt, gehe ich davon aus, dass man das auch von einer MFC-Anwendung aus ansprechen kann. Die Kommunikation funktioniert bei MSMQ allerdings asynchron. MSMQ-Nachrichten werden "garantiert" zugestellt. Jede Komponente bekommt ein Postfach und kann dort eigegangene Nachrichten abholen. Auch wenn z.B. ein Server neugestartet wird, können Clients im weiterhin Nachrichten schicken. Sobald der Server wieder online ist, holt er die Nachrichten ab und verarbeitet sie. MSMQ braucht allerdings eine gewisse Infrastruktur, die aufgebaut und gepflegt werden will. Es eignet sich daher eher für große Anwendungen und aufgrund seiner asynchronen Arbeitsweise nicht für alle Problemstellungen.

ASP.NET Webservices (SOAP über HTTP)

Standard ASP.NET Webservices laufen nur auf einem Webserver. Vorzugsweise dem IIS. Für direkte Kommunikation zwischen Anwendungen ist es nicht die richtige Technologie. Es sei denn, die .NET Anwendung wird explizit als Webservice entwickelt. Wenn man SOAP-Webservices mit .NET schreibt, tut man das aber mittlerweile besser mit WCF.

WCF (Windows Communication Foundation)

WCF vereint alle der obigen Kommunikationstechnologieen in einem einheitlichen Programmiermodell. Allerdings läuft WCF auch erst ab Windows XP/2003 und benötigt das .NET Framework 3.0 oder höher. Mit dem BasicHttpBinding kann WCF mit allem Reden, was SOAP spricht. WCF ist die modernste und zugleich mächtigste Kommunikations-Technologie. Statt via SOAP direkt mit dem WCF-Server zu reden, kannst Du natürlich auch eine Client-API als COM-Wrapper schreiben, wie ich das auch schon oben für Remoting vorgeschlagen habe.

Hoffentlich hilft Dir diese kleine Zusammenfassung bei der Wahl der passenden Kommunikations-Technologie.

Danke für die kompetenten Antworten.

Wenn ich mir das durchlese, bleiben mir nicht viele Möglichenkeiten übrig.

ES, HTTP Kommunikation, Message Queing und ASP.Net haben für eine kleine schnelle Anwendung zuviel Overhead.

Bei WCF ist mir nicht ganz klar, wie das in Vbdg mit MFC (C++) funktionieren soll.

Da bleiben mir nur noch die Möglichkeiten Remoting, Sockets und CORBA.

Remoting: Ich habe keine Erfahrung mit COM, da kann ich nicht abschätzen, ob es die richtige Lösung ist, hört sich aber interessant an. In meiner Applikation gibt es ca. 10 - 20 Kommunikationkanäle die relativ wenige Kommandos und Daten austauschen.

Sockets: Ist wahrscheinlich die beste Lösung, weil schnell und auf beiden Seiten sicherlich mit einem Aufwand zu bewältigen, den ich selber abschätzen kann. Da ist der größte Aufwand, ein eigenes Protokoll zu entwerfen.

CORBA: Welche Lösungen gibts denn für .NET? Ist es richtig, dass das Protokoll dann über eine IDL festgelegt ist und ich eigentlich selber nichts programmieren muss? Das wäre dann natürlich auch interessant. Ich denke es lohnt sich noch ein wenig in Richtung CORBA zu recherchieren.

Sockets: Ist wahrscheinlich die beste Lösung, weil schnell und auf beiden Seiten sicherlich mit einem Aufwand zu bewältigen, den ich selber abschätzen kann. Da ist der größte Aufwand, ein eigenes Protokoll zu entwerfen.

Ist wenn du das so sagst wahrscheinlich das Richtige für dich aber (auch wenn ich sie nicht mag) möchte ich noch einwerfen das es auch noch die Windows Named Pipes gibt die eigentlich recht einfach zu handhaben sind und sie auch über das Netzwerk funktionieren.
Auf der C/C++ Seite könntest du deine objekte/strukturen einfach in einen Binärstream packen und dann in die Pipe stecken und auf der DotNet-Seite wieder in eine Struktur marshallen und umgekehrt.

Hallo Jaensen, ich glaub NamedPipes fällt flach, da

Das ganze muss nur innerhalb des Intranets funktionieren NamedPipes nur auf der selben Machine geht. Dafür gibts MSMQ

da NamedPipes nur auf der selben Machine geht

Nope, funktionieren auch übers LAN 😜 Macht z.B. der SQL-Server (Wenn man ihn dafür konfiguriert was man eher selten tut)
Guckst du hier:
http://msdn2.microsoft.com/en-us/library/ms187892.aspx
und hier:
http://msdn2.microsoft.com/en-us/library/aa365590(VS.85).aspx

Dann gibts auch noch die lustigen Mailslots:
http://msdn2.microsoft.com/en-us/library/aa365576(VS.85).aspx

Ich habe die Named Pipes mal kurz überfolgen.

Sehe ich das richtig, dass eine zusätzliche Prokollschicht (SNA, SMB) benötigt wird, damit die laufen? Ist die Protokollschicht unter Windows immer aktiv?

Das sieht nach zusätzlichem Protokolloverhead aus, der die Kommunikation verlangsamen könnte.

Das sieht nach zusätzlichem Protokolloverhead aus, der die Kommunikation verlangsamen könnte

In langsamen Netzen (und eigentlich generell) würde ich dir zu Sockets raten aber NamedPipes sind halt recht einfach im Handling. Ich denke es ist eher anders rum und SMB basiert auf NamedPipes (bin mir da aber selbst nicht ganz sicher also bitte korrigieren wenn ich falsch liege) da SMB auch direkt über Tcp laufen kann.

Es kommt auf die Anforderungen an.

Ist die Protokollschicht unter Windows immer aktiv?

Ohne aktive (lokale) NamedPipes wirst du Windows wahrscheinlich nicht zum laufen bekommen, standardmäßig sind sie auch über das Netzwerk aktiv was sich aber durch den Admin z.B. einschränken oder deaktivieren lässt.