WebService Concurrency

[Generic1]

Hallo,

ich habe eine Frage zum WebService und zwar wie schaut es im Zusammenhang mit Webservices mit der
Cuncurrency aus?
Muss ich da beim WebService- Code darauf achten, dass mehrere User zur gleichen Zeit einen "WebService- Operation" aufrufen oder ist da eine andere Methodik dahinter?
lg

 

[Gast2]

Solltest du. Normalerweise wird ja irgendwo in deinem Servlet doPost/doGet aufgerufen. In der Methode solltest du z.B. keine Objecte sharen. Idealerweise von da weiterdeligieren. Oder aber besser gleich ein Framework einsetzen (z.B. Axis).

 

[Generic1]

Ja, Axis wird eh eingesetzt aber WebServices und Servlets sehe ich jetzt nicht direkt in einem Zusammenhang ausser das beides Web- Technologien sind. Kannst du das mit den Servlets nochmal erklären, wie du das meinst?
lg

 

[Gast2]

Du weißt wie Axis und Web Services normalerweise funktionieren?

Axis wird häufig als Java-Servlet innerhalb eines Servlet-Containers (beispielsweise Apache Tomcat) betrieben, der Web Services für Java-Klassen anbietet.

Oder auch: Difference btwn Servlet and Web Service, Java(TM) Boutique - Web Services with Axis

 

[Noctarius]

Man sollte halt generell keine Instanzvariablen nutzen, dann hat man auch keinen Concurrent-Access auf diese

 

[Generic1]

Ok, der Zusammenhang war mir nicht klar,
also zusammenfassend kann man sagen, dass man im WebService- Code auf die Concurrency- Problematik aufpassen muss und da WebServices sicher von mehr als einem Client benutzt werden. ist das bei WebServices immer ein Thema.

Kann man das so sagen?
lg

 

[Noctarius]

Kommt auf deine Implementierung an, generell sollte man bei Web-Dingen niemals Instanzvariablen nutzen und Parameter nur als Parameter innerhalb des eigenen Threads nutzen.
Nur bei externen Instanzen wo Daten geändert werden muss man auf Concurrency achten. Aber das sollte man sowieso immer. Nicht nur bei Webanwendungen. Wenn Code von Anfang an sauber implementiert wird sollte er auch immer gleich Threadsafe gemacht werden. So spart man sich später eventuelle Probleme.

Ergo Ja und Nein: Ja man muss drauf achten, Nein es ist kein Sonderfall sondern sollte immer beachtet werden.

 

[Keo]

Webservices werden idealerweise zustandslos entworfen. Um eine möglichst hohe Skarlierbarkeit zu erreichen, bietet jedoch Axis2 -ähnlich wie das Servlet-API- verschiedene Typen von Sessions an, die unterschiedliche Lebensdauer und Scopes haben. Stichwort Session Verwaltung. Beim Session Management geht es darum, client-spezifische Informationen zu verwalten, zur Laufzeit wird es zwar je deployten Service nur eine Service-Instanz geben, jedoch könnte durch den Session Scope zur Laufzeit mehrere Instanzen der Implementierungsklasse existieren und somit auch mehrere Service-Kontexte, die jeweils ihre eigenen Lebenszyklus haben.

 

[Generic1]

Geht die Session- Verwaltung auch mit Axis 1.4, ich hab nämlich momentan den Fall, dass sich die ganze Logik in den JSPs befindet - auch die Session- Verwaltung -> und das muss ich in meinen WebService bekommen (WebService mit Axis 1.4) -> deshalb brauch ich die Session- Verwaltung für Axis 1.4!?
lg

 

[Noctarius]

Dann entwerfe doch gleich ein sauberes, zustandsloses, neues System. Aus Legacy Gründen kann man das alte System noch eine Weile laufen lassen, Kunden aber ans Herz legen möglichst zeitnah die neue Schnittstelle zu implementieren.

 

[Generic1]

Das Problem ist, ich brauche die Session- Verwaltung, da ich verschiedene User mit verschiedenen Berechtigungen habe. Ein zustandsloses System würde da nicth gehen.
lg

 

[Noctarius]

Doch, du brauchst halt nur ein transparentes Authorisierungssystem, z.B. per BasicAuth. Du musst bei keiner Anwendung irgendwas in einer Session halten. Das ist generell (meiner Ansicht nach) ein schlechtes Softwaredesign. Wir haben in der Firma bei altem Code genau das Problem.

 

[weeedoo]

Doch, du brauchst halt nur ein transparentes Authorisierungssystem, z.B. per BasicAuth. Du musst bei keiner Anwendung irgendwas in einer Session halten.

Also wird bei jeder Benutzung einer WebMethod die User-spezifische Aktionen enthält neu Authentifiziert?

 

[Noctarius]

So ist es bei Stateless, anders geht's ja nicht.

 

[weeedoo]

So ist es bei Stateless, anders geht's ja nicht.

Arbeite mich gerade erst ins Thema ein und habe sowas "befürchtet" ^^
Danke für die Info

 

[Noctarius]

Wieso befürchtet? Ist doch nichts schlimmes wenn man nicht gerade einen Login mit Minutenberechnung hat.

Wenn man einen Servlet-Container hat kann man das Auth relativ simpel in einem Servlet-Filter abhandeln, noch bevor man am eigentlichen WebService ankommt. Damit kann man sich den Code sauber halten und hat eine sichere Authentifizierung vorweg

 

[Gast2]

Man kann es auch noch eine Ebene tiefer machen mit SSL Client Zertifikaten. Ist halt nur sinnvoll bei einer recht fest eingegrenzter Menge an Clients.

 

[Noctarius]

Stimmt ist auch eine Variante

 

[weeedoo]

Wenn man einen Servlet-Container hat kann man das Auth relativ simpel in einem Servlet-Filter abhandeln, noch bevor man am eigentlichen WebService ankommt. Damit kann man sich den Code sauber halten und hat eine sichere Authentifizierung vorweg

Ich finde es eigentlich sehr nett, dass ich die ServiceMethoden mithilfe der Port-Referenz direkt aus dem Client benutzen kann. Irgendwie kann ich mir nicht vorstellen wie ich da ein Servlet zwischen packen soll... würden dann nicht die Vorteile die ein WebService bietet verloren gehen?
Höchstwahrscheinlich ist die Frage totaler Quatsch..entschuldigt mein Halbwissen

 

[Noctarius]

Irgendwo hast du schon ein Servlet, was aber im Hintergrund von den Frameworks bereitgestellt wird. Schau mal in deine web.xml da müsste ein Servlet und ein passendes Mapping hinterlegt sein.

Vor dieses Servlet kannst du nun z.B. einen ServletFilter hängen, der unabhängig von der dahinterliegenden Implementierung die Authorisierung vornimmt.

Dies könnte BasicAuth oder eben ein SSL Zertifikat sein oder auch (dann natürlich mit etwas Handarbeit) Logindaten im XML.