I have deployed the discussed sample on:
http://www.govdigital.com.br:9090/shopping-webapp/
My goal was to show demonstrate some FAQs. Namely:
Implicit MVC + static resources (img/css/js)
HTTP Basic Authentication
User context without HTTP Session
It is VERY basic, but i am willing to improve it based on further
discussions. Your comments will be appreciated.
If it fails for any reason, please let me know.
Julio
On Fri, Nov 7, 2008 at 4:58 PM, Craig McClanahan
<Craig.McClanahan_at_sun.com> wrote:
> Julio Faerman wrote:
>
> Other point to consider is culture. Most developers stuff the sessions
> because they are used to, and have doing so since, say, ASP 2.0.
>
>
> Or servlet 2.0, which is now twelve years old.
>
> Or JSP, which creates sessions by default unless you tell it not to. :-)
>
> In AJAX apps, it gets a little harder to get rid of the session, as
> you need to fire smaller requests and do not want to keep track of
> session information across pages, with is not nice in javascript.
> Perhaps a new sample app with auth and stateless server, but with
> contextual data. I think i can contribute this. Would it be relevant?
> Any considrations or features that would be intersting to demonstrate?
>
>
>
> I think that would be awesome. Regarding structure, one thing I've seen in
> Ruby on Rails apps is the idea that your basic server side UI based webapp
> should follow exactly the same RESTful design principles, and then add a
> couple of methods to the controller to return the underlying data (for a
> particular page) in XML or JSON, instead of embedded in an HTML UI.
> Translated to Jersey terminology, that would mean using the same resource
> class for, say, a list of customers for the currently logged on sales
> person. If the client requests HTML they get the normal UI (which might
> have embedded javascript inside to perform Ajax calls later); if they ask
> for JSON or XML they just get the underlying data.
>
> Craig
>
> On Fri, Nov 7, 2008 at 11:26 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>
> On Nov 7, 2008, at 1:58 PM, Julio Faerman wrote:
>
>
>
> I would like to discuss this further, i think it is a very common
> question. Let me try do defend some "statefulness".
>
> 1- The overhead of session management is questionable, as there are
> efficient persistence and replication mechanisms available in modern
> app servers. If we are talking about a sufficiently large number of
> server, the overhead is tolerable.
>
>
>
> It is yet another thing to manage and consider, especially when the
> deployment system changes. It makes it harder to route requests to the right
> set of machines each time. The implications of such session state can cross
> many boundaries in the layered and networked system, including clients, for
> example i cannot switch from buying an airline ticket on my laptop,
> bookmarking the URL, and switching to continue the process on my phone,
> perhaps in another country deferring to a bunch of servers close to my
> location for better performance.
>
>
>
>
> 2- The use of HTTP-Basic auth is less secure, specially if not using SSL.
>
>
>
> As the name suggests it is basic :-) but i would argue no less basic than
> many Web apps that send the password typed into the HTML form as part of the
> POST login message. Both have to be used with SSL.
>
>
>
>
> 3- The session helps a lot when the information the system should
> provide is contextualized to the authenticated user. For example,
> showing the accounts of the salesperson using the system. A stateless
> app would require additional authorization checks to perform the same
> operation.
>
>
> When you log in you have to authenticate and that authentication grants
> roles. Is that not independent of the authentication mechanism? The key i
> think is to ensure that the contextualized information is resource state
> identified by a URI associated with the user, or application state that is
> sent by the client to the server.
>
>
>
>
> I tried hard to keep my current project completly "stateless", and i
> agree on storing the minimum possible state in the session, but the
> benefits of a small session outweights the cost in most applications,
> IMHO.
>
>
>
> I understand, pragmatically i can see why this is so. As i said i think the
> tools/frameworks have made it easy to leverage sessions rather than other
> mechanisms that do not leverage sessions that make better use of URIs.
>
> Paul.
>
>
>
> On Fri, Nov 7, 2008 at 6:25 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>
> Hi Craig,
>
> Well said! Further more you often find that some web sites will be hidden
> behind one URL. It is not book markable.
>
> The current state of affairs is this: at any one point in time how to do
> you
> know web sites you are logged into? how do you log out? the browser does
> not
> know really anything, because it is all opaque through server-given
> opaque
> identifiers, usually cookies.
>
> Would it not be nice for the browser, and therefore the user, to have
> more
> control over this? Utilizing HTTP authentication can enable this because
> the
> browser is aware of the authentication process. Unfortunately browsers
> today
> do a dreadful job popping up an ugly dialog box to login. I am sure there
> are ways to get nice login pages working with this type of mechanism but
> the
> frameworks and tools do not encourage this type of approach, thus the
> least
> path of resistance is to use a session, which can easily come to be a
> decision one might regret later on.
>
> Paul.
>
> On Nov 7, 2008, at 9:11 AM, Craig McClanahan wrote:
>
>
>
> Craig McClanahan wrote:
>
>
> Eduardo Pérez Ureta wrote:
>
>
> Ideally I would like to use the servlet session.
>
>
> I should have responded to this particular statement in my previous
> response (sorry for the omission). And it relates to some comments I
> *did*
> make that might not make a lot of sense without a little bit of context.
>
> One of the key principles behind RESTful APIs is that they should be
> *stateless*. In other words, if the server is implemented as multiple
> instances of your application behind a load balancer, it should not
> matter
> if the (n)th request and the (n+1)th request are served by different
> instances. This is a key attribute in designing an application that can
> scale beyond a single server instance.
>
> When you use servlet sessions, you are risking a violation of this basic
> principle. Let's assume that you are taking the typical approach where
> a
> cookie is used to tell the client what session identifier to submit on
> subsequent requests. The usual server side implementation of a
> "session" is
> essentially a HashMap of session attributes, keyed by the session id.
> But
> the *crucial* point is that this information normally lives only within
> the
> context of a single JVM (i.e. a single instance of your server).
> Supporting
> an application that scales horizontally (that is, across multiple server
> instances) would require that either:
>
> * the load balancer recognize that a subsequent request belongs to an
> existing session on a *single* instance of your application, which means
> you are likely to experience service overloads if this single instance
> has
> too many active sessions. (You will often see this referred to as
> "sticky
> sessions").
>
> * the server environment recognizes that there is an existing session,
> but
> the data for it lives on some other server instance so it needs to be
> copied
> to this instance before the request can be processed. As you can
> imagine,
> there can be significant overhead in doing this sort of thing.
>
> With respect to authentication (which was the particular context of
> Eduardo's questions), the standard HTTP approach is to include an HTTP
> header named "Authorization" with each request -- most typically using
> the
> HTTP Basic authentication scheme (http://www.ietf.org/rfc/rfc2617.txt).
> This means that the authentication operation must occur on *every*
> request,
> but it also means that you can indeed scale your application across
> multiple
> server instances, because any one of them is capable of performing the
> authentication transaction. You would be wise, if you are planning on
> an
> application that does, or even *might*, require deployment of more than
> one
> instance, to keep this consideration in mind.
>
> For a Java developer who doesn't want to care about all the nuances and
> complexities of the HTTP protocol, my recommendation is pretty simple --
> figure out how to design your application without using sessions. For
> authentication, that's pretty simple ... just include the authorization
> header on each request (for human-interaction web applications, browsers
> even do this for you if your server is designed for HTTP Basic
> authentication). For application state, everything that the server
> needs to
> know about the current state should be included with each request. (The
> details of this topic is the source of many thesis-length dissertations,
> but
> the fundamental principle is pretty easy to grok.)
>
> Or, of course, if you *know* your application will never need more than
> one instance (even to ensure availability in the case of an instance
> failure), you can safely ignore this advice. But can you really be
> sure?
> (For a 10-user departmental app behind your company firewall, sure you
> can.
> For an Internet facing app, no way IMHO. All it takes is a single
> "Slashdot Effect" surge of interest in your app, which overloads your
> single
> server instance, to demonstrate to you (and to the world, unfortunately)
> that you weren't ready for Internet scale user traffic).
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>