WSA Sessions

GregTomkins

Active Member
These questions concern the simulated connections available in Session-Managed mode thru the Web Services Adapter (WSA), from the end-client running Java (or whatever) and submitting HTTP/XML/SOAP requests to the WSA. I can't find any documentation about this.

1. Is there any timeout (activity or session) in effect, or, once I get a session ID, could I literally use it for days?

2. How does WSA handle reboots, eg. if I (a Java client) get a WSA session ID and use it for an extended period of time, will it break if WSA happens to get rebooted? Or does WSA persist session ID's?

3. Similar question; how does WSA handle the possibility that I make 2 requests from the same client with the same session ID, but due to load balancing, they are directed to different WSA's?

I also sent this question to PSC Support. Any insights appreciated.
 

RealHeavyDude

Well-Known Member
When a "whatever" client connects via the WSA to the Progress AppServer ( you don't mention it - but I'll take it that it is involved because I don't see any sense talking about the WSA without an AppServer that it forwards the request to ) there are several services involved where a session id eventually could be maintained:

[ WebServer ] - Java Servlet Engine - [ WSA] - AppServer

I deliberately set the WSA in paranthesis because it is a intermediate servlet that just passes request to the AppServer, takes the result and passes it back out.

Futhermore, the WSA is used with web service calls forwarded to a state-free WebServer. Therefore there is no such thing as a persistent connection to any backend service. Therefore there is no session management on any backend service and if you need one you need to roll your own. Even if the client might manage a session pool each request is its own connection and therefore you need to authenticate each single request.

Which session id do you exactly mean?

Heavy Regards, RealHeavyDude.
 

Cringer

ProgressTalk.com Moderator
Staff member
These questions concern the simulated connections available in Session-Managed mode thru the Web Services Adapter (WSA), from the end-client running Java (or whatever) and submitting HTTP/XML/SOAP requests to the WSA. I can't find any documentation about this.

1. Is there any timeout (activity or session) in effect, or, once I get a session ID, could I literally use it for days?

2. How does WSA handle reboots, eg. if I (a Java client) get a WSA session ID and use it for an extended period of time, will it break if WSA happens to get rebooted? Or does WSA persist session ID's?

3. Similar question; how does WSA handle the possibility that I make 2 requests from the same client with the same session ID, but due to load balancing, they are directed to different WSA's?

I also sent this question to PSC Support. Any insights appreciated.
Hi Greg, it might be worth posting this on the Progress Community too. Quite a good number of PSC employees (in particular developers and architects) read there and answer queries. You may well get a speedier response that way?
 

GregTomkins

Active Member
My apologies, I am conflating "object ID" as described in the OE manual and the generic term "session ID". I believe the WSA "object ID" performs the role of what we would call a "session ID" in web development, hence my confusing wording. Anyway, that's what I am talking about.

My understanding is that if my WSA is "state-managed", I can "connect" to it (by supplying a password, etc.), but it's not *really* a connection in the TCP sense, since this is all stateless HTTP; instead WSA hands me an "object ID". I have to attach this same "object ID" to all subsequent requests, and WSA uses that to make sure I'm an authentic user (100% analogous to what most web apps do).

In other words, I don't believe I have to "roll my own" for this, Progress appears to have a built-in method to handle it without requiring credentials on every call.

So my question is about how will the "object ID" behave, given I have several WSA's and the WSA's may go up and down from time to time. Ideally, Progress both persists and synchronizes them, but I am skeptical that this is true.
 

RealHeavyDude

Well-Known Member
I don't understand why you constantly talk about the WSA since it is a Java servlet for which you don't have the source code and on which you can't run any custom code unless you hack it and roll your own. The sole purpose of the WSA is to forward the requests to a state-free AppServer. Whatever authentication happens before the request reaches the AppServer ( for example a plug-in to the WebServer authenticating a SSL client certificate ) has no impact on the AppServer. Since Progress does not support the SSL client certificate the only way to perform authentication on the AppServer is to pass username and password to the connection method. All you have available in the ABL on the AppServer are the input parameters provided to the connect AppServer event response procedure and the SERVER-CONNECTION-ID plus the SERVER-CONNECTION-CONTEXT attribute on the SESSION system handle. But since the AppServer is state-free you can't use that one. The documentation is pretty clear on that: "If the AppServer operating mode is state-free, this value has no meaning". The only information you will ever get is the one you provide on input parameters to the request or the connection method. In order to be able to do such an authentication you would need to access the HTTP header ( which most authentication plug-ins to WebServer enrich with authentication information - be it an ASN.1 certificate or something else providing the user identity ) which is also not possible. This is for example something I would have needed to perform strong authentication with OpenEdge web services. It is no rocket science to roll your own Java Servlet that does the data mapping back and forth from XML to ABL data types and connects to the AppServer using the Java Open Client and so I did. Our version of the "WSA" automatically adds additional parameters to the ABL procedure call which for example contain the ASN.1 certificate representing the user identity which we can then use in the ABL code to do the authentication.

Heavy Regards, RealHeavyDude.
 

GregTomkins

Active Member
Thanks for the extended reply; I don't mean to try your patience, but I am not sure that when in Session-Managed mode, "The sole purpose of the WSA is to forward the requests to a state-free AppServer" is accurate. I would say that is true of, say, the AIA, but from testing, and also based on this:

http://documentation.progress.com/o... Services/09dvwsvC03program.16.04.html#626182

... I believe the WSA *also* has the purpose of doing what we would use a session ID and cookie for in web development, eg., overcoming the problems caused by the connectionless nature of HTTP by passing around a token that gets validated for every request. There is a connect method which the WSA must understand and which I believe uses the AppServer to authenticate, analogous to how a non-WSA connection would, and then the WSA doesn't issue the token until this happens.

I don't understand why you always talk about SSL and "client certificates" because I have almost no understanding of those; possibly that's where I am missing your whole point, I will check that out.

Thanks again, sincerely; have a good weekend.
 

RealHeavyDude

Well-Known Member
Now I got you - sorry for confusing you with SSL certificates, they have nothing to do with your questions.

What I didn't get is that you are NOT talking about state free AppServer. I have never implemented something like session managed with the WSA but I think anything where a session needs to be managed does not make sense without a persistent connection and therefore the AppServer would need to operate at least state-less. I've never set up something like web services with load balancing therefore I have no experience with that - but I think that session-managed and persistent connection do not go together with load balancing for the questions you have asked.

Heavy Regard, RealHeavyDude.
 

RealHeavyDude

Well-Known Member
If I understand the documentation @ http://documentation.progress.com/output/OpenEdge112/oe112html/wwhelp/wwhimpl/js/html/wwhelp.htm#href=Integration and General Business Interfaces/Web Services/08dvwsvC02expose.15.2.html#800488 correct, in a session managed web service the WSA makes a persistent connection to the AppServer and all requests are handled on the same AppServer.

So here are my 2 cents:
  1. You can have a managed session ( persist the connection ) as long as you want to ( and thereby locking resources on the backend ) but you might hit an idle timeout somewhere - but I am not aware of any.
  2. As soon as the WSA ( the Java Servlet engine hosting the WSA ) is re-started ( as well as when the AppServer is re-started ) any persistent connection is dropped and therefore your session id ( object id ) gets useless.
  3. With session managed ( a persistent connection ) the load balancing kicks in at connection time. As soon as the connection is established there is no load balancing anymore. For load balancing individual requests you can not have a managed session ( a persistent connection ) - you would need to switch to session free.
I would guess that you should get similar answers from somebody @ Progress. If they say something different then I would be - to say the least - very surprised.

Heavy Regards, RealHeavyDude.
 
Top