https and session state

[Susan]

Can somebody explain how https can be used to maintain session state, as described in the Sun Certified Enterprise Architect for J2EE - Study Guide, p144?


thanks.

[suekar meredilko]

I have not used it but I understand just like you can write to the headers of HTTP you should be able to use it by writing to headers of HTTPS.
Name-value types.

[Thomas Taeger]

Hello Susan, hello all,
interesting question ...

Originally posted by Susan Oso:
Can somebody explain how https can be used to maintain session state, as described in the Sun Certified Enterprise Architect for J2EE - Study Guide, p144?

Mark Cade's book, ok. On page 146 there is a little bit more, but no real explanation of how being stateful.

Session state must mean more than both sides knowing and trusting each other.

In Paul Allen's book of same name, p.589: "HTTPS: ... using encrypted data streams." As I think to remember from Applet programming:
via URLConnection .getInputStream() and .getOutputStream() the Applet can receive and (in another thread) send data through these streams until either side closes the stream.

Could HTTPS turn the communication with a stateless Session EJB to a stateful communication so the same EJB would be locked for the duration of the HTTPS session? Thereby allowing multiple server turn-arounds within one HTTPS session?

Thomas
[ June 08, 2006: Message edited by: Thomas Taeger ]

[Peer Reynders]

Standard HTTP runs over TCP - so there is no notion of a session and the session id is either transported in the URL or in an HTTP header.

HTTPS runs over SSL/TLS. SSL/TLS not only encrypts the data stream but also includes the provision for a session id (it's probably used to keep track of the encryption properties). If the server doesn't want to engage in a session with the client then it returns an empty session id. If it wants to allow a session it can return a unique session ID for the client to use on the next request. Given that SSL/TLS already tracks the session (state) it is no longer necessary to put a separate session identifier in an HTTP header or in the URL.

[Nathan Mathi]

Originally posted by Thomas Taeger:


Could HTTPS turn the communication with a stateless Session EJB to a stateful communication so the same EJB would be locked for the duration of the HTTPS session? Thereby allowing multiple server turn-arounds within one HTTPS session?

I dont think communication protocol has any effect on functioning stateless/stateful beans.

Also, for SF beans, once the bean state is passivated, the same bean can accept request from some other user, so i guess we cant say the bean is locked.

Any other thoughts?

[Thomas Taeger]

Originally posted by Peer Reynders:
If it wants to allow a session it can return a unique session ID for the client to use on the next request. Given that SSL/TLS already tracks the session (state) it is no longer necessary to put a separate session identifier in an HTTP header or in the URL.

This statement uses "state" somehow synonymeous to "session" or more precise to "session id", right?.

When I talk about session state I usually mean (besides the techical session id) business parameters
- in requests and
- in responses
- and/or in server-side non-transient EJB member variables
as well. Is that wrong?

In a stateless connection this business state (these parameters) need to be sent e.g. URL encoded to the server and some need to be returned.
We also can use cookies to store not only the session id but also things like customer id, names, address, baskets etc., but new/changed parameters still need to be transfered.

At the server side the session id could be used to temporarily persist business parameters and retrieving these parameters the next time the Stateless Session EJB gets the same session id. Is that usual? - for stateless EJBs!? Would a developer base the persisting of business data
- on a temporary technical session id or
- would he use an explicite key that is independent of the protocol?
- Would he use this manual persistence mechanism at all?
- I think he would prefere Statefull Session EJBs if he persists anyway.

Having a HTTPS session served by a Stateless Session EJB: How can HTTPS help us to get business state/parameters (besides the session id) over the wire if not persisting at the server side?


If for HTTPS not business state were ment then we would have a divergency for "stateful":
- for Stateful Session EJBs "stateful" would mean business state
- for HTTPS "stateful" would just mean the technical session id.

a) From my actual point of view HTTPS offers just a minimal base on that we can manually build business-state-ful sessions.

b) Stateful Session EJBs offer a full mechanism for passivating / activating server-side non-transient variables used by the next server turn-around of this session - quite a difference.

What did all the gurus like Mark Cade, Paul Allen etc. mean in both cases?

Thomas
[ June 08, 2006: Message edited by: Thomas Taeger ]

[Thomas Taeger]

Hello Nathan,

Originally posted by Nathan Mathi:
I dont think communication protocol has any effect on functioning stateless/stateful beans.

I agree (after having thought [by writing] about the topic a little bit more now).

Thomas

[Peer Reynders]

Originally posted by Thomas Taeger:
This statement uses "state" somehow synonymous to "session" or more precise to "session id", right?.

Correct. Granted it's a bit misleading because the SSL/TLS connection doesn't provide state storage for your application. As far as the SSL/TLS layer is concerned, the session id is the state. It's your application server that has to provide the application session storage (the HttpSession). However the server can exploit the SSL/TLS session ID as a correlation identifier which it will use to correlate the clients individual requests in to a single session (instead of a jsessionid). So when you use HTTPS, the client's browser doesn't have to have cookies enabled, nor do you have to worry about URL-rewriting in your JSP pages.

Now this has got everything to do with servlets and JSPs and it has got nothing to do with EJBs. I don't have access to my Cade right now - so I can't figure out what HTTPS has to do with EJBs. An EJB client does not use either HTTP, nor HTTPS to talk to the EJB server - it always uses RMI/IIOP.

In order to use HTTPS with EJBs you will have to put a servlet between the client (which will be no longer an EJB client) and the EJB. The client simply uses the an URLConnection to talk to the servlet - the servlet then unmarshalls the request and becomes the EJB client itself - marshalls the results from the EJB and sends them back in the response to the client. In this scenario the servlet can use the HttpSession to store the application session data. Ultimately HttpSession is far better suited to store application state than any stateful session bean. SFSBs are best used to store "application transaction" (a Hibernate term) state and should be discarded once the "application transaction" is complete.

Stateful Session Beans: Beast of Burden

From the Hibernate documentation (to explain the term application transaction - has got nothing to do with HTTPS or EJB):

In a two tiered architecture, consider using long persistence contexts.

Database Transactions have to be as short as possible for best scalability. However, it is often neccessary to implement long running application transactions, a single unit-of-work from the point of view of a user. An application transaction might span several client request/response cycles. It is common to use detached objects to implement application transactions. An alternative, extremely appropriate in two tiered architecture, is to maintain a single open persistence contact (session) for the whole lifecycle of the application transaction and simply disconnect from the JDBC connection at the end of each request and reconnect at the beginning of the subsequent request. Never share a single session across more than one application transaction, or you will be working with stale data.

[ June 08, 2006: Message edited by: Peer Reynders ]

[Thomas Taeger]

Originally posted by Peer Reynders:
As far as the SSL/TLS layer is concerned, the session id is the state. [...]

This is true only "as far as the SSL/TLS layer is concerned", and that is just the minimal base. For providing business state we still need
- persisting business state between the Connections of a Session, and / or
- cookies including business state, or
- passing business state forth and back via URL encoded name-value-pairs.
I think this is the topic.

Originally posted by Peer Reynders:
So when you use HTTPS, the client's browser doesn't have to have cookies enabled, nor do you have to worry about URL-rewriting in your JSP pages.

For business state this is not true, see my reasoning above. For business state - and this is the state we usually are interested in - we still need URL encoded name-value-pairs, Cookies and / or Statefull SessionBeans (SFSB, or outside of the exam maybe SFSB-alike replacements) as long as we use HTTPS or HTTP.

Originally posted by Peer Reynders:
In order to use HTTPS with EJBs you will have to put a servlet between the client

For not confusing people preparing for part II:
Do not take this theoretic thought as a rule for the exam. Consider wether agents' access requires HTTPS at all ...
Also take into account that agents access needs to be twice as fast as customer access!

For agents accessing EJBs directly (without a servlet between - in intranet, not via Internet) a much more elegant way of providing business state opens:
- Just pass business state and parameters via a request Transfer Object from the GUI application to the EJB. (Some use a Command object)
- Just return business state and any response data via a response Transfer Object from the EJB back to the GUI application.
- This is somehow similar to passing name-value-pairs. But it directly works with Java objects, does not need any conversion from HTTP parameters to Java objects or back, and does not waste time on this conversion (remember: agents ... twice as fast ...).

Thomas
[ June 11, 2006: Message edited by: Thomas Taeger ]

[Peer Reynders]

And who brought EJBs into it, thereby confusing the issue, eh? p.144 7.1 HTTP - HTTPS � no mention of EJBs. p.146 7.2 HTTPS � again no mention of EJBs. Lets get back to the original post:

Originally posted by Susan Oso:
Can somebody explain how https can be used to maintain session state, as described in the Sun Certified Enterprise Architect for J2EE - Study Guide, p144?

HTTP runs on top of TCP, HTTPS runs on top of SSL/TLS. At the TCP level there is no inherent mechanism for carrying a session id between each request/response pair. HTTP was designed as a stateless protocol, so there is no help here either. So in the HTTP(TCP) cases the application server will return a jsessionid either in a cookie (which is an HTTP header) or as part of the URL in the links of the returned HTML page (URL rewriting). To maintain that HTTP-session the client will have to return that jsession id in the cookie (which a browser will automatically do � a programmed client would have to manage this in code) or as part of the next request URL. Both of these approaches are discussed on p.144 as "Cookies" and "URL Rewriting".
SSL/TLS however has its own session id to track the details of the encryption with that particular client. So the application server can use the SSL/TLS session id to maintain the HTTP-Session and doesn't have to transport a jsessionid via a cookie or URL Rewriting. That's what is meant by:

Using the state in the SSL connection at the application level avoids the security problems associated with cookies or URL Rewriting, and enhances security because of the nature of SSL.

With HTTP(TCP) a programmed client can return a modified jsessionid in an attempt to highjack somebody elses session - with the SSL/TLS session id that is a lot harder.

You should be aware that there is more than one "session" in your application. Web clients will typically keep their "application session" in an HTTP-Session and the objects that define the application state will be stored in an HttpSession object. For non-web clients the "application session" can be maintained in a number of ways - however it is usually better to design this type of interaction as stateless (session-less) from the server point of view. That means that the non-web client has to pass all the information that defines the application state with each request to the server and that the server will send all the information back to the non-web client - in essence application state is maintained by the non-web client. While this can result in increased bandwidth requirements on the network, it makes the server application much more scalable as it doesn't have to maintain (or migrate) client state.

Each stateful session bean has it's own "session", that "session" is not necessarily your "application state" (hopefully it isn't).

While you are using one-and-the-same database connection, you have a "database session". However web applications will usually only use the same database session within one request as the connection should go back into the connection pool after the request is served.

---- END of explanation ----

Originally posted by Thomas Taeger:
For business state - and this is the state we usually are interested in - we still need URL rewriting, Cookies and / or Statefull SessionBeans (SFSB, or outside of the exam maybe SFSB-alike replacements) as long as we use HTTPS or HTTP.

Not for a web client (i.e. browser) and web application that maintains application state within in an HttpSession object - with HTTPS there is no need to maintain jsessionid in a cookie or the URL because the session id is maintained in the SSL/TLS layer. jsessionid is still necessary if only certain parts of your web application use HTTPS while other parts use HTTP.

Originally posted by Thomas Taeger:
Also take into account that agents access needs to be twice as fast as customer access!

Well, non-web clients only need to exchange data, while web-clients receive the entire HTML page which is only partially data. While I agree that Sun is probably looking for a different solution for non-web clients, one needs to be aware of other "real world" options after the SCEA:

(tunneled) RMI

Hessian (Binary over HTTP)

Burlap (XML over HTTP)

XML-RPC (A case of Worse is better as Elliotte Rusty Harold put it)

Spring HTTP Invoker

etc.

HTTP/HTTPS can go through firewalls - plain RMI/IIOP cannot (at least not without a lot of fiddling which would ultimately enlarge your attack surface) which is fine on an intranet but will require the use a VPN over the internet.
[ June 10, 2006: Message edited by: Peer Reynders ]

[Thomas Taeger]

Originally posted by Peer Reynders:
And who brought EJBs into it, thereby confusing the issue, eh?

EJBs are for sure one of the mechanisms we have to consider in a J2EE based SCEA forum, as soon as "maintaining state" is the topic.

Yes, let us go back to the original question:

Originally posted by Susan Oso:
Can somebody explain how https can be used to maintain session state, as described in the Sun Certified Enterprise Architect for J2EE - Study Guide, p144?

Mark Cade and/or Simon Roberts describe there in short what you describe much more detailed, and then they just say "the SSL connection also provides a maintenance of state between one request and the next".
They also leave totally open what they mean with "Using the state in the SSL connection at the application level ...".

I am not willing to guess or assume anything if these gurus can't clarify (or remove) that sentences.

For me providing business state is the interesting question in a J2EE based forum. If you like to explain this then I would appreciate it.

If Susan is interested in the technical basics then she should better discuss them herself.

Thomas
[ June 11, 2006: Message edited by: Thomas Taeger ]

[Abdul Mohsin]

Thanks Guys , it really helped !!

Abdul Mohsin