isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
Subject Re: Isis session and transaction management on a custom viewer
Date Fri, 06 Sep 2013 08:12:09 GMT
Thanks for the detailed explanation and the links to those resources. 

As we currently have an Apache Isis integration with our viewer, we knew the "high-level"
structure, but it needs to be improved (experiencing some session or transaction management
problems that originated the request).

We are interfacing Isis only through "generic" repositories (responsible of generating screens,
etc.) and a generic action execution service (that finds the proper Object Specification,
etc.). We are obtaining the proper choices, default values, hidden state, (not auto-complete
by now; at most in 2 weeks), etc.

With the provided information we expect to being able to solve those session handling problems.

We will look at them in detail, and come here if any doubt is raised.

Thanks again,

Oscar



El 05/09/2013, a las 15:52, Dan Haywood <dan@haywood-associates.co.uk> escribió:

> Hi Oscar,
> apols for the delay in replying on this; within...
> 
> And, I'm cc'ing this to dev@i.a.o; I think it belongs there better.
> 
> Dan
> 
> On 26 August 2013 15:45, GESCONSULTOR - Óscar Bou <o.bou@gesconsultor.com>wrote:
> 
>> [snip]
>> ... we have some questions about current design:
>> 
>> 1.- Stateful (Wicket) vs Stateless (RestFul Objects): why the Wicket
>> viewer needs to hold the state,
> 
> 
> The Apache Wicket framework is stateful, that's just the way it is.  In
> fact, it's one of the principles of the framework to handle this [2].  One
> needs to be aware of this [3].
> 
> 
>> from an Apache Isis perspective? Just to hold the current user "context
>> information"?
> 
> 
> No, more than this.  Every component (widget) in the page is backed by a
> Wicket model (LoadableDetachableModel); these must be serializable because
> they are stored in the session.  Isis entities are not serializable (nor
> would we want them to be), but the OIDs are (eg "TODO|123").   Isis handles
> this by providing mementos (for entity, property, collection, action,
> parameter).  Thus, EntityModel is a Wicket model that wraps an
> ObjectAdapterMemento.
> 
> But, yes, Isis itself does also have a session which represents the current
> user.  This is its
> org.apache.isis.core.commons.authentication.AuthenticationSession.  Isis
> delegates to Wicket to store this for it in the HttpSession; this is done
> through org.apache.isis.viewer.wicket.viewer.integration.wicket.AuthenticatedWebSessionForIsis
> (IsisWicketApplication#getWebSessionClass).  By this, Wicket keeps track of
> the user making the request.
> 
> If using Isis' Shiro integration for authenticaiotn/authorizatino, then
> there are also Shiros session management to consider [4].  I am pretty sure
> the default for that is also HttpSession, but it would seem to be pluggable
> and they say it supports clusters [5].
> 
> 
> 
> 
>> Why to choose for other webapps integrating with Isis the stateful design,
>> instead of the - more scalable - stateless design?
>> 
>> 
> Umm.  As [3] says, Wicket's reliance on session management means it
> wouldn't be suitable for an Amazon scale website.  But I believe it's an
> appropriate technology for a typical enterprise app (that might use a farm
> of clustered servers for big deployments).
> 
> Restful Objects in contrast is deliberately stateful.  There is still the
> user identity issue to contend with, but that's pluggable.  I hope that
> someone (who knows more about this than me) might help work through an
> oauth or equivalent implementation.  My understanding (I'm by no means a
> security expert on this) is that these solutions are scalable because the
> user credentials ultimately are stored in HTTP headers (encrypted suitably,
> of course, according to the oauth protocols etc etc).
> 
> 
> 
>> 2.- Is there any class we can inherit from for stateless or stateful
>> clients, that will be maintained in the future, as Apache Isis evolve, that
>> takes care of web session handling, security (shiro) session, transaction
>> management, etc. ? Perhaps we can inherit from classes currently existing
>> on the Wicket viewer (or the Restful Objects viewer).
>> 
> 
> Look at the classes above as a start point, see if you can untangle them.
> 
> There is a ticket to better integrate Shiro and Wicket [6].  Right now we
> logout of the Wicket viewer by invalidating Wicket's authentication
> session.  However, Shiro doesn't know about this, so it preserves its
> sessions.  We do (seemingly) still get the behaviour we want, but
> improvements could be made here.
> 
> 
> 
> 
>> 
>> 3.- Is there any other point we must take into account with this approach
>> - the "custom viewer" interacting with the Apache Isis domain - ?
>> 
>> 
> The biggest immediate risk is that you get the scoping wrong.  There is a
> reasonably clear separation of scopes; see ApplicationScopedComponent,
> SessionScopedComponent, TransactionalScopedComponent.  There's an old
> diagram I did [7] which shows this (it might be a bit out of date, but
> shows the general pattern).
> 
> The biggest ongoing risk is that - because the API is not formally
> documented - that we change the code and break the custom viewer.
> 
> 
> While I can see the value of there being a formal "in-process" API, I do
> hope that most will use the RO viewer.  I guess one could use the RO applib
> and RO viewer on the same box as a loopback; not sure if that would add to
> much overhead to be feasible.
> 
> HTH
> Dan
> 
> 
> 
> 
>> 
>> 
>> Thanks,
>> 
>> Oscar
>> 
>> 
>> [1] http://www.wavemaker.com
>> 
>> 
> 
> [2] http://wicket.apache.org/meet/introduction.html
> [3] http://www.jtict.com/blog/wicket-isnt-suited-for-websites/
> [4] http://shiro.apache.org/session-management.html
> [5] http://shiro.apache.org/web.html#Web-ServletContainerSessions
> [6] https://issues.apache.org/jira/browse/ISIS-299
> [7]
> https://github.com/apache/isis/blob/master/core/src/docbkx/guide-runtime-to-incorporate/images/architecture.png


Mime
View raw message