Session Model for Web Services

[GregTomkins]

I found some old posts on this subject but they aren't very clear. I'm interested in the difference between the "FREE" and "MANAGED" session models (eg. as selectable in ProxyGen). From the doc, it is clear that Web Services "SESSION FREE" corresponds to AppServer "STATE FREE", but why I'd pick one over the other is not clear.

This, from the 11.2 WSA doc, *implies* to me that if you use "SESSION MANAGED", and five users hit you with a request at the same time, they execute in series, even if there are 5 AppServer agents available. I am doubtful that this is true (why would anyone want that?). Anyone?

session-managed Web services are single-threaded. Thus, the WSA maintains a single network session to connect the Web service and all its objects to a single AppServer on behalf of a single Web service client. All requests from the client to the same Web service objects use the same AppServer connection.

Also, I have a vague belief that the whole notion of "STATE FREE" AppServers (as opposed to state LESS) were added for the specific purpose of Web Services. Although, in ProxyGen, this property seems to apply to all types of proxies. Am I wrong?

 

[RealHeavyDude]

IMHO Progress is notorious for not promoting best practices. Any session managed model could only make sense to the Java or .Net open client where a persistent connection to the AppServer might be of an added value. I have done a lot with Java open clients and even for them I use the session free ( = state free AppServer ) model. Locking resources and binding stuff on a server, IMHO, would need a very good justification in order for me to implement it.


Heavy Regards, RealHeavyDude.

 

[GregTomkins]

I was hoping you'd reply, thanks.

Correct me if I am wrong (please); if you use session-free, there is no concept of a connection, therefore: any clients must either (a) be of the sort that don't require authentication (eg. serving up generic, public-safe data such as price lists); or (b) each call has to include some kind of authentication, a-la a session cookie in WebSpeed.

The advantage is session-free is that you're not tying up resources for connections but you can still achieve multi-threaded performance. (Again, please correct me if I'm wrong).

 

[RealHeavyDude]

Concept of connection:

Precisely there is no persistent connection, therefore every request is its own connection and must therefore provide authentication credentials ( when they are required ) with each call. Depending on your authentication standards this could be username/password or some other one-time token ( weak authentication ) or the client SSL certificate or some ANS.1 token ( strong authentication ). The SSL certificate and/or ASN.1 token handling can be part of the SSL handshake between the client and the server. Unfortunately, to this date, Progress does not support the SSL client certificate whatsoever. But to some extent this lack can be worked around.

Depending on the client technology there might be some connection pooling in the client ( for example the AVM or Java support connection pooling ). Maybe this is not completely correct - others may be able to give a better explanation: These are possible connections that are activated and deactivated per request. In theorie the backend service could be restarted without the client noticing. Ditto for load balancing. I did only test with load balancing though.

Multi-threading:

You are correct in that not occupying resources on the server when there is no request is one advantage. Another one is that you're only loosely coupled - see above comment on load balancing, for me that is one of the biggest advantages.

Progress does not support multi-threading and I have not implemented something like mimicking multi-threading using the AppServer yet. But I suppose that any workaround could only be based on a state-free AppServer. A stateless AppServer would requiere a new connection for each thread. Please, prove me wrong if you have achiebed something like that with a stateless AppServer ...

Heavy Regards, RealHeavyDude.