Laden...

WebService mit "Pooling"?

Erstellt von Kantiran vor 17 Jahren Letzter Beitrag vor 16 Jahren 3.716 Views
K
Kantiran Themenstarter:in
71 Beiträge seit 2005
vor 17 Jahren
WebService mit "Pooling"?

Hallo Alle

Ich habe ein paar Fragen zu einer Softwarearchitektur.
Um Hinweise / Vorschläge wäre ich dankbar.

Ausgangslage
Es soll ein Server-Dienst entwickelt werden, der API-Aufrufe an einen anderen Dienst weiterleitet.
Dieser Dienst wird mit .NET realisiert.

Die Funktion(en) müssen per WebService angeboten werden.
Remoting / WCF sind nicht möglich, da die aufrufenden Applikationen auf unterschiedlichen Technologien basieren (3 Applikationen, keine in .NET).

Problem
Der zu entwickelnde Dienst muss bei jedem Aufruf eine Verbindung zur API des anderen Dienstes aufbauen.
Dabei muss er sich jeweils mit dem Benutzer "Einloggen", welcher den Aufruf gestartet hat.

Dieses "Einloggen" (-> API Funktion) dauert jedoch 4-6 Sekunden.
Eine solche Dauer bei jedem Aufruf ist nicht akzeptabel.

Lösungskonzept
Der Server-Dienst hält eine Art "Connection-Pool" mit "Eingeloggten APIs".
Beim ersten Aufruf eines Benutzers wird dieser eingeloggt. Alle nächsten Aufrufe des Benutzers benutzen dieselbe "Connection".

Wird eine Connection eine gewisse zeit nicht mehr benutzt (z.B. 2h), wird diese vom Dienst wieder entfernt um die Ressourcen freizugeben.

Nun habe ich jedoch zwei Fragen;

  • Wie kann man dies Lösen, da ein WebService ja stateless ist? (-> Pooling nicht möglich)
  • Falls doch möglich: Wie sieht es mit der "Threadsicherheit" aus? (-> Zwei parallele aufrufe eines Benutzers)?

Gruss Fellmer

S
8.746 Beiträge seit 2005
vor 17 Jahren

Man kann mit Webservices Sessions verwenden. Dann sind Webservices zustandsbehaftet.

K
Kantiran Themenstarter:in
71 Beiträge seit 2005
vor 17 Jahren

Hallo Svenson

Hmm, dann sieht das ganze ja schon besser aus.
Kannst du mir sagen, ob diese Sessions grobe Einbussen versursachen? Z.b. bei der Skalierbarkeit?

Wir sprechen hier von ca. 80 Sessions, möglicherweise ansteigend.

Gruss Fellmer

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von Fellmer Lloyd
Kannst du mir sagen, ob diese Sessions grobe Einbussen versursachen? Z.b. bei der Skalierbarkeit?

Genau das ist das Problem. 80 Sessions hören sich aber für mich nicht kritisch an. Anders wäre das sicher bei 1000 oder mehr. Kann dir ja aber nicht mit konreken Erfahrungen dienen. Ist mehr ein Bauchgefühl. Aber ein kleiner Test sollte da ja Aufschluss geben.

K
Kantiran Themenstarter:in
71 Beiträge seit 2005
vor 17 Jahren

Ok, danke. Das Thema hat sich somit erst einmal geklärt.

80 Sessions sollten mit entsprechender Hardware eigentlich möglich sein, das denke ich auch.

Danke

1.274 Beiträge seit 2005
vor 17 Jahren

Warum dauert dein Login so lange? 4-6 Sekunden ist schon viel.

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

K
Kantiran Themenstarter:in
71 Beiträge seit 2005
vor 17 Jahren

Hallo

Es handelt sich leider nicht um "mein" Login, sondern um das einer Drittapplikation.
Warum dies solange dauert ist mir unbekannt. Diese Applikation ist sozusagen eine Black-Box.

Gruss

Gelöschter Account
vor 17 Jahren

wir haben in unseren programmen auch 2000 sessions und das geht ganz gut...
du musst nur aufpassen das du in den sessionvariablen möglichst wenig reinschreibst da das ansonsten sehr viel ram frisst.

J
140 Beiträge seit 2006
vor 16 Jahren

Ich habe gerade eben auch so eine Anforderung.

Frage: Die Session wäre dann schon Pro Benutzer, oder?

D.h. wenn sich ein User verbindet, dann würde der erstmalige Aufruf an das Backend (Absolutely Black-Box) pro User geschehen?

Ich würde dann in der Session schon einiges an Daten halten um eine möglichst hohe Performance zu gewährleisten. Wäre die RAM-Belastung je User ähnlich einer Win-Forms Applikation die dieselben Daten in den RAM schaufelt? Müsste ja, oder?

J
140 Beiträge seit 2006
vor 16 Jahren

Okay, ich hab gerade ein bisschen gespielt mit dieser Session...

Das was es bietet, ist mir zu wenig. Immer dann wenn ich den Webservice neu instanziiere, erzeugt er logischerweise eine Session.

Ich will aber übergreifend Daten behalten. Also ich will ein Bag pro User (Authentifiziert) wo ich Daten hinterlegen kann, egal wieviele Webservice-Instanzen existieren, die sollen für den passenden User immer die entsprechende Bag finden.

Gibt es sowas, oder geht das am Webservice-Konzept vorbei?

Will vermeiden mir einen Windows-Service und zusätzliches .Net-Remoting mir reinzuholen.

S
8.746 Beiträge seit 2005
vor 16 Jahren

Wozu brauchst du mehrere Client-Instanzen des Webservice? Solange du den User eingeloggt läßt, kannst du doch problemlos Daten innerhalb der Session übermitteln und speichern.