Wenn ich das richtig verstanden habe, benutzen eure Clients
DCOM, um auf dem Anwendungsserver Aktionen anzustoßen, die dann intern mit SQLServer arbeiten. Richtig?
Wenn nicht, vergiss das folgende
Wir arbeiten hier auch mit
DCOM und haben damit große Probleme. Das fängt damit an, dass es sehr kompliziert ist, auf den einzelnen Rechnern die Rechte so zu verwalten, dass sie Zugriff auf die
DCOM-Server haben und hört damit auf, dass die Kommunikation häufig aus unerfindlichen Gründen eingestellt wird und der Server beendet werden muss.
DCOM hat eigentlich nur einen Vorteil: Du kannst eine Instanz des Servers einfach dadurch starten, dass du eine Serverfunktion aufrufst. Das System erledigt den Rest.
Nachteil: Die
DCOM-Kommunikation läuft auf dem Server im Haupt-Thread. Man kann zwar andere Threads nach Aufruf von CoInitialize(Ex) benutzen, aber um z.B. ein Abfrageergebnis an den Client zurückzuschicken musst du wieder in den Hauptthread, sonst knallts (Vielleicht sind wir ja auch nur zu blöd dafür, aber wir haben schon viel probiert...).
Daher wird die nächste Version von unserem Server als Windows-Service laufen und per
TCP/
IP kommunizieren. Webservices wären eine Alternative, aber, da wir nur im LAN kommunizieren, eher Overkill. Dasselbe gilt m.E. für WCF. Wenn du allerdings übers WAN mit dem Server reden willst, ist WCF eine gute Sache, weil die Authentifizierung integriert und gut gelöst ist. Dummerweise ist dann Delphi erstmal außen vor.