Dilemma

[Nate Leech]

2 questions:

I'm writing a web application and am making a webservice call for authentication to another application that my web app is integrating with.

Here are my options:
1) I store the webservice connection in the session. That way, I can call methods on the connection to get user assets all through the application lifecycle.
2) I get the assets I need from the original webservice connection and then close the webservice connection. However I need to store the assets in the session. (The assets aren't that big, it will be no more than 10 java beans with only 2 instance variables each) The application is designed to be a 3 step process, it should only take a user about 1 minute to use, once they have completed the steps, the session will automatically be invalidated. If for some reason they decide to open the application where the session is created adnt ehy dont complete the process, I'm only going to have the session stay alive for 5 minutes.

So now my questions:

Which of these is desirable?

If number 1 is desirable, how do I call the webservice disconnection method when the session invalidates? I think it may have something to do with Listeners, but I haven't dug that deep into Google yet

Thanks for any help!

-Nate

[Bear Bibeault]

Didn't have far to look.

[Nate Leech]

Indeed...

I know where that website is, in fact I did visit it, just didn't care to look at it too hard until I have an answer to question #1. Perhaps you have a website for that question as well?

Thanks for any help!

-Nate

[D Rog]

Tell me more about webservices connection. Is it HTTPConnection or something different? Where your webservices run, what's technology used? What are keep-alive settings.

[Nate Leech]

Haven't worked with webservices directly at all unfortunately.
I'm calling the webservice from an API supplied from the vendor.
It is an HTTPS connection. I pass in the webservice URL and the login and password from whoever logs into the application and then it gives me back a "Session Virtual Object".
From the object I call methods which supply user credentials, user assets etc...
When I am done with the service, I call a logout method and it will disconnect the user from the session.

Sorry for any confusion

-Nate

[D Rog]

So, the suggeston looks reasonable, keep this webservices session object in servlet session and use session invalidate listener to discard this session object. You can use a connection pool to keep webservices session with similar credentials alive and share them between servlet sessions unless webservices session stateful.

[Harish M]

As a design suggestion, keeping live objects which holds a webservice connection ( like Axis Call Object for example) is not ususally recommended.Holding such an object is a High Vulnerability/Security issue.
Consider creating webservice call objects only whenever required and pull out required information.

Harish

[Paul Bourdeaux]

Hi Harish,

Welcome to the ranch! Just a quick FYI, you may want to change your name to match the JavaRanch naming poicy before you attract the attention of a bartender.

[Harish M]

Posting reply again..after updating profile...

As a design suggestion, keeping live objects which holds a webservice connection ( like Axis Call Object for example) is not ususally recommended.Holding such an object is a High Vulnerability/Security issue.
Consider creating webservice call objects only whenever required and pull out required information.

Harish

[Yuriy Zilbergleyt]

I agree with Harish on that keeping active connections in the Session (or ServletContext for that matter) object is not a good idea. I would go with your #2 option - get everything you need from the connection, and close it. If you need to update anything, you can do it all at once when the session invalidates (use the HttpSessionListener Bear pointed you too here.)

And Harish, I'm sorry to say that your name is still not quite regulation friendly - you need at least a few more letters after that 'M', or a single letter provided it's a vowel

-Yuriy