Laden...

C/S mit Remoting: Beispiele für Client-/Server Activated Objects

Erstellt von juetho vor 16 Jahren Letzter Beitrag vor 16 Jahren 2.076 Views
J
juetho Themenstarter:in
3.331 Beiträge seit 2006
vor 16 Jahren
C/S mit Remoting: Beispiele für Client-/Server Activated Objects

Hallo,

mich interessiert, wann bei einer Client/Server-Anwendung mit Remoting (d.h. natürlich auf der Client-Seite) eher serveraktivierte Typen und wann eher clientaktivierte Typen verwendet werden.

Bitte versteht mich nicht falsch: Das Prinzip und das jeweilige Verfahren (GetObject bzw. CreateInstance) sind mir klar. Zum besseren Verständnis und zur praktischen Umsetzung fehlen mir noch eine Reihe Beispiele.

Danke! Jürgen

PS. Meine Anwendung befasst sich mit Datenbanken: Adressen, Buchhaltung, Auswertungen und natürlich entsprechenden Eingabeformularen. Auswertungen und Verarbeitungen erfolgen unterschiedlich: teils per StoredProcedure in den DBs, teils "automatisch" in der Server-Anwendung, teils "halbautomatisch" oder "manuell" beim Client.

3.728 Beiträge seit 2005
vor 16 Jahren
Aktivierungsarten

Wenn möglich sollte man immer serveraktivierte Objekte verwenden, da diese besser skalieren. Serverseitig werden sehr wenig Ressourcen belegt, da entweder eine einzelne Instanz alle Clientanfragen verarbeitet (Singleton) oder Instanzen pro Anfrage erzeugt aber danach sofort wieder entsorgt werden (SingleCall). Beispiele, für was ich persönlich serveraktivierte Objekte verwende:*Zentraler Sicherheitsdienst eines ERP-Systems (Singleton) *Buchungssystem für Verkaufs- und Einkaufsvorgänge (SingleCall) *Lagerverwaltungs- und Buchungssystem (SingleCall) *Freigabe und Sperr-System für Auslagerungsaufträge eines ERP-Systems (Singleton) *Benachrichtigungsdienst für Clients (Singleton)

Auf clientaktivierte Objekte muss man zurückgreifen, wenn man mit Benutzer- bzw. Sitzungsgebundenen Ressourcen arbeitet, die aufwändig zu erzeugen sind. Für clientaktivierte Objekte habe ich aus meiner Praxis leider nur ein Beispiel:*Gekapselte .NET API für DATEV Rechnungswesen; Das DATEV Rechnungswesen über DCOM "ferngesteuert" und arbeitet zeilenorientiert (Also wie früher hust eben üblich)

Zu 90% lassen sich clientaktivierte Objekte vermeiden. Wenn Du sie vermeiden kannst, dann vermeide sie. Bei steigender Anzahl der Clients explodiert die Serverlast bei clientaktivierten Objekten.

Für Deinen Typ Anwendung würde ich mit serveraktivierten Objekten arbeiten. So SingleCall wie möglich und so Singleton wie nötig.

J
juetho Themenstarter:in
3.331 Beiträge seit 2006
vor 16 Jahren

Hallo Rainbird,

danke für diese Beispiele. Es verblüfft mich, dass tatsächlich fast alles serveraktiviert abläuft. Aber ich verstehe es.

Konkrete Nachfrage:

Auf clientaktivierte Objekte muss man zurückgreifen, wenn man mit Benutzer- bzw. Sitzungsgebundenen Ressourcen arbeitet, die aufwändig zu erzeugen sind.

Wenn sie ohne Aufwand zu erzeugen sind, nutzt man auch solche Objekte serveraktiviert?
++
Allgemeine Nachfrage++ (diesen Punkt hätte ich gleich in meine Hauptfrage einbeziehen sollen): Welche **lifetime **stellt man sinnvollerweise ein? Bei Singleton vermutlich "unbegrenzt"; aber z.B. eine Adressenänderung kann (einschließlich zusätzliche Maßnahmen und Brief an den Kunden) durchaus auch mehrere Minuten in Anspruch nehmen.

Nachtrag dazu: Alle (aktuell wichtigen) Daten zur Adresse stehen in einem DataSet des Servers. Sie könnten (mit längerer lifetime) direkt per Interface-bezogenes Objekt zur Verfügung gestellt werden; oder eine Methode (per Interface mit kurzer lifetime) gibt eine Kopie der Daten zurück.

Nach welchen Kriterien geht man hier vor?

Danke! Jürgen

3.728 Beiträge seit 2005
vor 16 Jahren

Wenn sie ohne Aufwand zu erzeugen sind, nutzt man auch solche Objekte serveraktiviert?

Genau. Würde z.B. bei meiner DATEV-Schnittstelle für jeden Buchungszugriff vom Client ein neues Objekt erzeugt (SingleCall), müsste die aufgerufene Funktion bei jedem Clientzugriff folgende Schritte ausführen:*Anmelden an der DATEV-Nutzungskontrolle *Herstellen einer DCOM-Verbindung zur Rechnungswesen-Applikation *Öffnen des entsprechenden Mandanten *Öffnen des gewünschten Datenobjekts *Zur betroffenen Buchung navigieren *Eigentliche Operation ausführen

Ein Zugriff würde ca. 30 Sekunden (ohne Übertreibung) dauern.Singleton geht aber auch nicht, da dann nur eine DCOM-Sitzung (also nur ein gleichzeitiger Benutzer) möglich wäre. Also clientaktiviert. So werden die ersten 5 der obigen Punkte einmal im Konstruktor abgehandelt und die eigentlichen Operationen sind angenehm schnell.

Welche **lifetime **stellt man sinnvollerweise ein? Bei Singleton vermutlich "unbegrenzt"; aber z.B. eine Adressenänderung kann (einschließlich zusätzliche Maßnahmen und Brief an den Kunden) durchaus auch mehrere Minuten in Anspruch nehmen.

Ich finde den Standardwert ganz gut. Der liegt bei 15 Minuten. Am besten per App.Config einstellbar machen. Dann kann man im laufenden Betrieb feinabstimmen. Die Admins werden es Dir danken.

Alle (aktuell wichtigen) Daten zur Adresse stehen in einem DataSet des Servers. Sie könnten (mit längerer lifetime) direkt per Interface-bezogenes Objekt zur Verfügung gestellt werden; oder eine Methode (per Interface mit kurzer lifetime) gibt eine Kopie der Daten zurück.

Du meinst serverseitiges Caching von Daten, die oft benötigt werden? Auf keinen Fall komplette Adress-Tabellen im Speicher der Servers halten. Jetzt hast Du vielleicht nur 1.000 Adressen. In drei Jahren könnten es 30.000 sein. Dein Server wird in die Knie gehen. Außerdem sind DataSets bei großen Datenmengen nicht performant. überlass das Caching lieber dem SQL Server. Der macht das besser, als Du es je programmieren könntest. Objekt-fetischisten denken sich gerne die Datenbank nur als "Objektspeicher" und programmieren alles nach, was die Datenbank eigentlich schon kann. Das ist zumindest für Business-Anwendungen totaler Unsinn.

J
juetho Themenstarter:in
3.331 Beiträge seit 2006
vor 16 Jahren

Original von Rainbird
Du meinst serverseitiges Caching von Daten, die oft benötigt werden? Auf keinen Fall komplette Adress-Tabellen im Speicher der Servers halten.

Nein nein, das wäre ein grobes Missverständnis! Ständig im Dataset stünden allenfalls Nachschlagetabellen wie Anreden (Herr, Frau), aber die passen auch in die ComboBoxen des Client. Mit "Alle (aktuell wichtigen) Daten zur Adresse" meinte ich die Daten zu der einen bestimmten Adresse, die im Moment bearbeitet wird...

Aber mit Deinem Hinweis auf den Standardwert von 15 Minuten hast Du mir auch im Hinblick auf die lifetime wesentlich geholfen. (In den Beispielen hatte ich nur Werte von 5 Sekunden u.ä. gelesen.)

Danke für Deine Erläuterungen! Jürgen