T
Hallo,
ich bin gerade dabei für eine Anwendung Teile abzuspalten und sie auf verschiedenen Prozessen laufen zu lassen. Die Kommunikation wollte ich über Sockets laufen lassen, wobei die Objekte über SOAP oder Binär serialisiert werden und und über TCP verschickt werden.
Leider hat ein kleines Testprogramm mit dieser Vorgehensweise nicht funktioniert. Die Daten können auf der Gegenseite nicht deserialisiert werden, weil die Assembly nicht die gleiche ist wie beim Serialisieren. Bei ähnlichen Problemen wird darauf verwiesen, Remoting zu verwenden. Sockets und Serialisierung ist anscheinend nicht die geeignete Technik.
Zu Remoting habe ich relativ wenig Material gefunden. Es gibt anscheinend ein brauchbares englisches Buch von Apress und ein deutsches von Microsoft Press.
Jetzt habe ich aber gelesen, dass Remoting nicht mehr empfohlen wird, weil es von WCF abgelöst wurde. Jetzt bräuchte ich ein paar Hinweise bzw. Erfahrungsberichte, was sich am besten eignet für meine Problemstellung.
Ich verwende Visual Studio 2005 mit dem .Net Framework 2. Ein Teil der kompletten Applikation ist noch in MFC und soll erst nach und nach durch .Net ersetzt werden. Das bedeutet, der Kommunikationsprozess sollte zwischen MFC und .Net funktionieren und leicht auf neue Versionen des Frameworks migrierbar sein, um bestimmte Teile updaten zu können. Meine Idee war, SOAP zu verwenden, weil es von Microsoft mit entworfen wurde und deshalb wohl die beste Unterstützung bietet innerhalb der Microsoft Technologieen. Wie es mit Corba und .Net aussieht, weiß ich nicht, ebensowenig mit RPCs zwischen MFC und .Net.
Zusammengefasst nochmals die Kernpunkte:
- Kommunikation zwischen MFC und .Net
- Leicht migrierbar auf neue Versionen des .Net Frameworks
- Es muss nicht über Firewalls funktionieren
- Programmiersprachen C++ und C++/CLI
P.S.: Das MFC Projekt kann nicht ohne sehr großen Aufwand in ein CLR Projekt umgewandelt werden.
