Mailing-List: contact users-help@isis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@isis.apache.org
Received-SPF: error (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <F6FEC42C-2D93-4679-8153-A714F8FB1444@gesconsultor.com>
References: <F6FEC42C-2D93-4679-8153-A714F8FB1444@gesconsultor.com>
From: Dan Haywood <dan@haywood-associates.co.uk>
Date: Thu, 5 Sep 2013 14:52:18 +0100
Message-ID: 
 <CALJOYLEk1usKYU3J5Cj1dnztwTe4XzbAU7VTLvUm+VdywisXTw@mail.gmail.com>
Subject: Re: Isis session and transaction management on a custom viewer
To: users <users@isis.apache.org>, dev <dev@isis.apache.org>
Content-Type: multipart/alternative; boundary=047d7b5daca022598204e5a33cd6

--047d7b5daca022598204e5a33cd6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 - =D3scar 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.Authenticat=
edWebSessionForIsis
(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, th=
at
> 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

--047d7b5daca022598204e5a33cd6--