Kommunikation zwischen Server-Client und zw. Client-Clientprogrammen: Wie, mit welcher Technologie?

Hallo zusammen,

folgendes Projekt ist zu realisieren:
Auf den Client-Rechnern laufen verschiedene Programme, die durch eine zentrale SW (Client-SW) gesteuert werden sollen. Ferner soll ein Server alle Clients koordinieren.

Mit anderen Worten soll

1. die Client-SW mit den einzelnen Programmen kommunizieren (gleicher Rechner, also Anwendung zu Anwendung) und
2. der Server mit der Client-SW (über ein Netzwerk) kommunizieren.

Die Client-SW soll dabei die Kommunikation zum Server für die einzelnen Programme übernehmen. Auch sollen jederzeit neue Programme hinzukommen können. Die Idee ist nun folgende: Will ein Programm mit der Client-SW kommunizieren (und somit indirekt mit dem Server), so muss dieses Programm eine bestimmte Schnittstelle bereitstellen.

Was die Client-Server Kommunikation anbelangt bin ich bisher auf drei unterschiedliche Technologien gestoßen:

1. TCP/IP-Sockets
2. Remoting
3. Webservices

So, wie ich das in der Diskussion Remoting oder TCP/IP? verstanden habe sind TCP/IP-Sockets gegenüber Remoting nur selten von Vorteil und umständlicher zu programmieren.

Somit stellt sich wahrscheinlich doch (fast) immer nur die Frage Remoting oder Webservice, oder?
Stimmt es, dass es einfacher ist einen Webservice zu implementieren? Inwiefern??

Ich habe auch schon mal ein nettes Tutorial zum Thema Remoting gefunden (siehe Remoting ). Die Vorstellung, einfach nur entfernte Methoden aufzurufen, klingt natürlich sehr verlockend.

Insbesondere habe ich mal gelesen, dass es mit Remoting auch möglich sein soll, Anwendungen, die sich auf dem selben Rechner befinden, miteinander kommunizieren zu lassen, sollange diese die selbe Schnittstelle bereitstellen, d.h. das selbe Interface implementieren. Somit könnte jedes Programm, das dieses Interface implementiert mit der Client-SW kommunizieren. Nur leider kann ich kein Tutorial finden, das mir dieses Vorgehen mit Remoting erklärt.

Kennt ihr ein entsprechendes Tutorial?
Oder gibt es vielleicht noch eine einfachere Methode eine Kommunikation zwischen zwei Programmen auf einem PC zu realisieren?

Ganz allgemein währe ich für Tutorials aus den Bereichen

• Client/Server
• Remoting
• Webservices
  dankbar.

Danke schon im Voraus für eure Hilfe.

Gruß,
Dante

Also die Client-Server Kommunikation würde ich auf jeden Fall mit Webservices machen. Ich kann dir jetzt hier keine Liste von pros und cons auflisten, weil ich auch selbst noch nie mit remoting gearbeitet habe. Alles was ich davon gehört habe hat mich dazu gebracht gar nicht erst damit anzufangen 😉

Wie Anwendungen untereinandern Kommunizieren weiss ich jetzt auch nicht grad. Aber ich denke da kommt es drauf an was für Daten(mengen) ausgetauscht werden sollen und was für Anforderungen (Geschwindigkeit, Verfügbarkeit, ...) gestellt sind.

Es geht nicht genau hervor was der Client ist.
Falls der Client ein mobiles Devices sein sollte, kannst Du Remoting vergessen. Ist in der CompactFramework nicht enthalten, leider auch zu meinem Leid!

Ansonsten (um es einfach zu halten) WebServices nutzen.

Gruß,
Rushmore

@Rushmore:

Zunächst: Der Client sollte auch auf einem mobilen Device laufen können.

Der Client, also die Client-SW, soll so eine Art Verwaltungstool für diverse andere Programme sein (die Client-SW und die einzelnen Programme befinden sich auf dem selben Rechner). Genauer gesagt, soll die Client-SW Aufgaben an diese Programme weiterleiten und Ergebnisse entgegennehmen. Die Aufgaben bekommt die Client-SW vom Server. Die Ergebnisse, welche die einzelenen Programme zurückliefern, sollen wiederum an den Server weitergeleitet werden. Ferner verteilt der Server die gesammelten und aufbereiteten Ergebnisse an die Clients.

Dass ich die Client-Server-Kommunikation mit Web Services realisiere ist mitlerweile beschlossene Sache. Mir stellt sich jetzt eigentlich nur noch die Frage:

Wie soll die Client-SW mit den einzelnen Programmen kommunizieren?

Am schönsten wäre es, wenn die Client-SW Methoden bzw. Funktionen der Programme aufrufen könnte (und im Idealfall, wenn die Programme Methoden der Client-SW aufrufen könnte). Von daher finde ich den Remoting-Ansatz sehr verlockend, da Interfaces definiert werden, die von beiden Parteien implementiert werden müssen. Und Remoting soll angeblich auch für Programme funktionieren, die sich am selben Rechner befinden. Nur leider fehlt es mir hier an entsprechender Literatur!

Am unschönsten fände ich die Lösung, die Kommunikation über Dateien zu regeln.

Wenn jemand einen anderen (einfacheren) Weg kennt, zwei Programme über eine Schnittstelle miteinander Kommunizieren zu lassen, wäre ich auch äußerst dankbar!!!

MfG,
Dante

Eine andere Möglichkeite wäre zum Bsp. Objekte zu serialisieren, die über tcp zu versenden, und auf der anderen Seite zu deserialisieren.

Wenn Du Remoting so verlockend findest, nutze es doch einfach.
Gut, jetzt kommt wieder der Aspekt mit den mobilen Endgeräten, aber die könnten ja mit einem Webservice kommunizieren, der wiederum über einen TcpChannel mit irgendwelchen anderen Services spricht, und Daten weiterleitet bzw. zurück gibt.

Eine weitere Möglichkeit wäre, dass die Applikationen über WindowsMessages kommunzieren (sofern die Apps auf der selben Maschine laufen).

Gruß,
Rushmore

Webservices spielen ihre Vorteile eigentlich erst über Weitverkehrsnetze aus, wo Sicherheit oder Plattformneutralität eine Rolle spielen. Lokal oder im Unternehmensnetz würde ich Remoting nutzen.

Du kannst aber auch einfach WCF einsetzen und dann die einen Romoting-Channel nutzen. Zur Not kannst du den ganzen Kram dann mit 2 Handgriffen auf Webservices umstellen.

Ggf. solltest du dir auch mal Messaging ansehen (MSMQ bzw. Http-Messaging, geht auch alles via WCF). Ein gutes Mittel um die Verfügbarkeit der Anwendung zu steigern ohne dafür extra Code schreiben zu müssen.

Remoting ist eine schöne Sache. Problematisch wird es erst wenn das darunterliegende Netz nicht stabil ist.... insbesondere ergibt die Kombination aus instabilem Netz und Remoting-Channels ein NOGO

Dies ist aber meine ganz persönliche Meinung (weil ich schon mal mit Channels in einem instabilen Netz auf die Schnauze gefallen bin).

ich bin mir nicht sicher aber könntest du die client-sw auch als dienst realisieren?

und im allgemeinen bevorzuge ich persönlich tcp/ip da man wie schon erwähnt wirklich probleme hat bei instabilen netzen. insbesondere wlan ist so eine sache...

Sehe jetzt erst, dass der Client auch auf dem mobile Device laufen soll. Dort gibts kein Remoting.

Bleibt dir also nur WebServices. Alternativ kannst du aber auch den Server mit WCF machen und sowohl einen Remoting (schnell), als auch einen Webservice-Endpoint (für PDAs) parallel anbieten. Auf dem WS-Endpunkt musst du dann aber Sicherheit mit https machen und auf Sessions und Events musst du grundsätzlich verzichten. Der Verzicht auf Events ist dabei besonders bitter, weil du damit in jedem Fall Polling machen musst, oder dir per Hand Push durch die Hintertür bauen musst.

Hallo

Eventuell wurde mein Vorschlag schon genannt, ich bin mir jedoch nicht genz sicher 😉
Mein Vorschlag ist die zwei Anforderungen voneinander zu Trennen, und zwar in zwei "Applikationen".

Die erste ist eine 2- oder 3-Tier Architektur im Client-Server Prinzip (Applikationsserver). Mit dieser Applikation bietest du auf dem Client die benötigten Dienste an.
Hier empfiehlt sich wie schon erwähnt Webservices oder WCF.
Idealerweise implementierst du das Chanel-Pattern, dann kannst du die kommunikationsplattform auch beliebig ändern ohne neu kompilieren zu müssen.

Diese Dienste kannst du dann von einem (oder mehreren) Programmen auf dem Client konsumieren.
Die Trennung sollte wirklich zu 100% sein, d.h. eine kommunikation findet nur über gemeinsame DTOs statt und nicht über Objekte der ersten Applikation.
Hier würde ich eine möglichst schnelle Variante zur kommunikation wählen, da die Daten ja nicht übers Netzwerk versandt werden müssen (und daher auch über keine Firewall).

Mit mobilen Geräten kenne ich mich leider nicht aus, kann daher nichts empfehlen.
Auf jeden Fall würde ich diese zwei Dinge auseinander halten.

Gruss Fellmer