grundsätzliches.net remoting vs. webservice vs. enterprise services

[Thomas Zimmermann]

hallo,

ich möchte eine verteilte anwendung schreiben, die zum einen über einen desktop-client und zweitens mittles eines webfrontends auf einen (sql-)server zugreifen können soll.
im msdn hab ich gelesen, dass ich da mind. 3 möglichkeiten habe
1. über einen webservice
2. über .net remoting
3. über enterprise services

nehme ich nur einen webservice für alles? tcp channel soll mit binärcodierung schneller sein als http. oder lieber den webclient über webservice und den rest über .remoting, was aber deutlich mehr aufwand hinsichtlich der programmierung sein soll? wobei ich eine innere abneigung gegen den webservice habe, wenn ich von einem desktop client zugreife.

es wird von mindestens 10 gleichzeitigen usern ausgegangen?

gruß
thomas

[holster]

Hallo Thomas,

für Remoting spricht:

- einfaches Deployment, vergleichsweise gute Performance (TCP/binary), gut geeignet für objektorientierte Architektur

Nachteile:

- Integration nur innerhalb Microsoft-Welt, keine Authentication-Funktion eingebaut, nur für Intranet geeignet

für Webservice spricht:

- Integration mit anderen Systemwelten (Java) einfach, für Internet und Intranet geeignet, Authentication-Mechanismen vorhanden

Nachteile:

- Deployment benötigt Webserver, SOAP-Serialisierung ist aufwändiger als TCP/binary

In Deinem Fall sehe ich folgende Kernfragen:

- Sind die Desktop-Clients ausschließlich Windows-Systeme? Zugriff nur aus dem Intranet oder auch aus dem Internet ?

- Wie werden die Zugriffe authentifiziert ?

Hth,

Klau

[Thomas Zimmermann]

hallo klaus,
erstmal vielen dank für die schnelle anwort.

Die desktop clients sind nach derzeitiger planung windowssysteme, der rest halt über den browser. mit mono sollte dann irgendwannmal auch linux als client möglich sein. >95% sind aber windowsclients. Zugriff soll sowohl aus dem internet als auch intranet möglich sein.

ich dachte mir folgendes:
server+ db unter windows. die clients greifen direkt über enterpriseservices oder remoting (aber was ist nun geeigneter) auf den server zu, der ganze webzugriff geht über den browser+webdienst+webservice. authentifikation übernimmt der server. da ich transaktionen brauche ist remoting wohl nicht die richtige wahl. ich will nicht alles über einen webservice machen, da dieser nur eine lose verbindung zur db herstellt.

mach ich da einen gedankenfehler oder gar grundlegenden fehler?

muß ich den datenbankzugriff auf den server komplett selbst programmieren, z.b. durch referenzübergabe eines datasets, definieren von methoden zur ausführung von sql-anweisungen vom client aus?

gruß
thoma

[holster]

Hallo Thomas,

wenn die Clients aus dem Internet zugreifen sollen, dann scheiden sowohl Remoting als auch Enterprise Services für den Zugriff vom Client aus, da beide Technologien nur für Intranet gedacht sind.

Dann wäre evtl. folgende Struktur sinnvoll: Die Clients greifen per Browser auf das Portal zu oder per SOAP-Aufruf auf den Webservice. Beide können innerhalb derselben ASP.NET-Anwendung implementiert werden.

Damit entfällt ggfs. die Notwendigkeit für Mono auf den Clients, weil die auf den Webservice zugreifende Applikation auch eine native Java-App sein kann.

Von Portal/Webservice geht's per Remoting oder ES durch die Firewall auf die App-Server mit der Businesslogik und der Datenbank. Wenn die Transaktionen über mehrere Businesslogik-Komponenten verteilt sind, dann ist das ein starkes Argument für ES - das geht nur damit.

Anderenfalls kann man die Transaktionslogik auch innerhalb der BL-Komponente im DB-Zugriff einkaspeln.

Die Authentifizierung hat zwei Aspekte:

- Die externe Authentifizierung des Benutzers aus dem Internet in Portal und Webservice. Dafür kann man z.B. Benutzername/Passwort über HTTPS verwenden.

- Die Authentifizierung der internen Komponenten untereinander. Dafür geht Windows Authentication, evtl. in Verbindung mit ASP.NET Impersonation.

Beim Datenzugriff wirst Du nicht um die Implementierung von Data Transfer Object - Klassen herumkommen, da die Daten ja extern zwischen den Clients und Portal/WS transportiert werden sollen. Dafür sind Datasets schlecht geeignet. Sinnvoll sind dagegen streng typisierte Klassen, die im Webservice als Parameter verwendet werden können.

Hth,

Klau

[Thomas Zimmermann]

vielen dank klaus, das hilft erstmal etwas weiter.
es ist vielleicht falsch rübergekommen, aber die desktop-clients liegen im lan, es soll halt zusätzlich ein externer zugriff möglich. dann werde ich es nehmen, da ich com+ schon mit delphi gemacht habe.

gruß thoma