Some questions

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

Hi all,

I recently gave a presentation "Introducing Apache Isis" [1] and at the 
end of the session had a few questions that I wasn't sure of the 
answers to. I have since followed up with the asker after the event 
and received a few more (I've provided some initial answers below in 
square brackets).

I'd appreciate answers from those in the know! (and perhaps others 
would be, too)

In no particular order:
a) how well does it work on EE6+ servers and how much of EE 
infrastructure can it leverage? (see next questions)

b) how do annotations that are use relate to JSR-330, or even CDI for 
that matter given that you share names of annoations

c) could validation be extended to use bean validation spec? 
http://beanvalidation.org/

d) could user use JPA instead of JDO?
[The Isis DN objectstore currently has a JDO implementation. One 
would have to write a JPA equivalent?]

e) any there other persistence providers that work with isis beyond 
datanucleus?
[Again, for a "seamless" fit, you can write your own objectstore 
implementation. Otherwise, you can bypass Isis' objectstore and use 
your own store API - but this would require disabling bytecode 
enhancements, etc... More specific guidance can be provided on 
demand.] 

f) What about client-side validation?

General feedback: The guys asking all seemed to working on or for 
Redhat (JBoss) and related. They seemed surprised that Isis adopted 
JDO over JPA, with comments along the lines of "but JDO is dead 
already". Otherwise, the general consensus was positive, since Isis 
handles all that one could want, if one wanted everything to be 
provided by a single framework.

[1] http://www.meetup.com/OpenBlend-Slovenian-Java-User-Group/events/149732352/
(warning: it's in Slovenian)

Re: Some questions

[Kevin Meyer <ke...@kmz.co.za>]

Thank you Dan!

I will pass these on.

Regards,
Kevin

Dan Haywood <da...@haywood-associates.co.uk> wrote:
>On 21 November 2013 19:39, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
>>
>> I was aked if the wars can be deployed into non-Tomcat installations.
>>
>>
>Don't see why not, it's a WAR file after all.  In dev mode, we run it
>under
>jetty as well as Tomcat.  Haven't tried it under a JBoss server,
>though.
>
>
>
>> > > and how much of EE
>> > > infrastructure can it leverage? (see next questions)
>> > >
>> > Since Isis is a framework that provides a container for domain
>objects,
>> the
>> > user's code is substantially hidden from JEE.  So the question
>really is
>> to
>> > what extent could one expose these services.
>>
>> I think this question was from the other perspective: Can the
>> user-written domain classes access services provided by the EE
>> server? (i.e. can the "developer" access more than what is provided
>> by Isis). [I don't know what these could be, personally].
>>
>>
>Yeah, that's how I understood the question, let me have another bash at
>answering it.
>
>So, the short answer is... no, there is no mechanism for user-written
>domain classes (specifically, domain entities) to access services
>provided
>by the EE server... and that's deliberate.  The domain entities should
>not
>depend on technology stuff.
>
>The longer answer is... while the domain entities should have no
>access,
>the domain services (or rather, the implementations of domain services)
>can
>use EE services.  The API of the domain service represents that
>functionality to the domain entity (into which it is injected) in a
>technology-agnostic way.
>
>
>
>> >
>> > Supporting a different JPA implementaition would be much more
>work...
>> >  Note: we cannot ever support Hibernate because of its license
>(LGPL);
>> that
>> > basically leaves OpenJPA.
>>
>> To clarify, a user could add Hibernate into their own extension, but
>it
>> could never be added to the Apache Isis codebase on
>> isis.apache.org.
>>
>>
>Yes, one could write a Hibernate object store as a third-party plugin.
>
>
> > > f) What about client-side validation?
>> > >
>> > What's the client in this context... presumably the
>browser/Javascript?
>> >
>> > It would be possible, if using the Wicket viewer, to write some
>custom
>> > Javascript, and have it call back into the Restful Objects viewer
>to
>> > perform validation.  Otherwise, we are leveraging the capabilities
>of the
>> > Wicket framework.  That does quite a lot in this space.  Isis'
>Wicket
>> > viewer has a pluggable architecture for its components, so writing
>> cleverer
>> > widgets is certainly do-able.
>>
>> On further questioning, the asker of this question was after reducing
>> the number of queries to the server - so the idea of AJAX calls back
>> to the RO viewer is not ideal. He'd want scripts that do the
>validation
>> on the client without additional calls back to the server.
>>
>> I can imagine a system whereby validation scripts get served to the
>> client. Can they be introspected from the validateXXX methods? That
>> would be interesting!
>>
>>
>In Wicket it is possible to associate arbitrary bits of Javascript with
>the
>components.  It would therefore be possible to develop more
>sophisticated
>components that use Javascript to enforce some of the semantics of the
>domain model.  (Indeed, the maxLength of a string is done this way)
>
>Isis' Wicket viewer is also extensible through its ComponentFactory
>API, so
>"dropping in" new and improved components would be quite feasible.
>
>
>
>
>> > > General feedback: The guys asking all seemed to working on or for
>> > > Redhat (JBoss) and related. They seemed surprised that Isis
>adopted
>> > > JDO over JPA, with comments along the lines of "but JDO is dead
>> > > already".
>> >
>> >
>> > I doubt that Andy Jefferson would agree. But yes, it is the betamax
>to
>> > JPA's vhs.  Note: it's also more capable, eg supporting NoSQL
>stores as
>> > well as RDBMS [2]
>>
>> Interesting! Are you offering to push this analogy to the next level:
>> betamax was also the better technology over VHS.. is JDO somehow
>> better than JPA? (apart from the extra NoSQL functionality).
>>
>>
>Yes, the analogy was deliberate :-)  JDO is better than JPA.
>
>Actually, if excluding the NoSQL functionality, then to be completely
>fair,
>I've seen benchmarks that JDO/DN is not the fastest ORM; there are
>JPA-only
>solutions that have the edge.
>
>And, the more pressing issue is probably community... DataNucleus is,
>it
>would appear, pretty much a one-man band.  That said, given we can't
>use
>Hibernate, I think that DN is as a good a choice as either OpenJPA or
>EclipseLink (the only other two candidates).
>
>If we take the NoSQL functionality into account, then - to me at least
>-
>JDO fits much better to Isis' hexagonal ports-and-adapters
>architecture:
>JDO takes care of the various adapters for the "persistence" port,
>while
>Isis takes care of the "presentation" port.  A nice symmetry.
>
>
>Cheers
>Dan

-- 
Sent from my phone with K-9 Mail.
Please excuse my brevity.

Re: Some questions

[Dan Haywood <da...@haywood-associates.co.uk>]

On 21 November 2013 19:39, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:

>
> I was aked if the wars can be deployed into non-Tomcat installations.
>
>
Don't see why not, it's a WAR file after all.  In dev mode, we run it under
jetty as well as Tomcat.  Haven't tried it under a JBoss server, though.



> > > and how much of EE
> > > infrastructure can it leverage? (see next questions)
> > >
> > Since Isis is a framework that provides a container for domain objects,
> the
> > user's code is substantially hidden from JEE.  So the question really is
> to
> > what extent could one expose these services.
>
> I think this question was from the other perspective: Can the
> user-written domain classes access services provided by the EE
> server? (i.e. can the "developer" access more than what is provided
> by Isis). [I don't know what these could be, personally].
>
>
Yeah, that's how I understood the question, let me have another bash at
answering it.

So, the short answer is... no, there is no mechanism for user-written
domain classes (specifically, domain entities) to access services provided
by the EE server... and that's deliberate.  The domain entities should not
depend on technology stuff.

The longer answer is... while the domain entities should have no access,
the domain services (or rather, the implementations of domain services) can
use EE services.  The API of the domain service represents that
functionality to the domain entity (into which it is injected) in a
technology-agnostic way.



> >
> > Supporting a different JPA implementaition would be much more work...
> >  Note: we cannot ever support Hibernate because of its license (LGPL);
> that
> > basically leaves OpenJPA.
>
> To clarify, a user could add Hibernate into their own extension, but it
> could never be added to the Apache Isis codebase on
> isis.apache.org.
>
>
Yes, one could write a Hibernate object store as a third-party plugin.


 > > f) What about client-side validation?
> > >
> > What's the client in this context... presumably the browser/Javascript?
> >
> > It would be possible, if using the Wicket viewer, to write some custom
> > Javascript, and have it call back into the Restful Objects viewer to
> > perform validation.  Otherwise, we are leveraging the capabilities of the
> > Wicket framework.  That does quite a lot in this space.  Isis' Wicket
> > viewer has a pluggable architecture for its components, so writing
> cleverer
> > widgets is certainly do-able.
>
> On further questioning, the asker of this question was after reducing
> the number of queries to the server - so the idea of AJAX calls back
> to the RO viewer is not ideal. He'd want scripts that do the validation
> on the client without additional calls back to the server.
>
> I can imagine a system whereby validation scripts get served to the
> client. Can they be introspected from the validateXXX methods? That
> would be interesting!
>
>
In Wicket it is possible to associate arbitrary bits of Javascript with the
components.  It would therefore be possible to develop more sophisticated
components that use Javascript to enforce some of the semantics of the
domain model.  (Indeed, the maxLength of a string is done this way)

Isis' Wicket viewer is also extensible through its ComponentFactory API, so
"dropping in" new and improved components would be quite feasible.




> > > General feedback: The guys asking all seemed to working on or for
> > > Redhat (JBoss) and related. They seemed surprised that Isis adopted
> > > JDO over JPA, with comments along the lines of "but JDO is dead
> > > already".
> >
> >
> > I doubt that Andy Jefferson would agree. But yes, it is the betamax to
> > JPA's vhs.  Note: it's also more capable, eg supporting NoSQL stores as
> > well as RDBMS [2]
>
> Interesting! Are you offering to push this analogy to the next level:
> betamax was also the better technology over VHS.. is JDO somehow
> better than JPA? (apart from the extra NoSQL functionality).
>
>
Yes, the analogy was deliberate :-)  JDO is better than JPA.

Actually, if excluding the NoSQL functionality, then to be completely fair,
I've seen benchmarks that JDO/DN is not the fastest ORM; there are JPA-only
solutions that have the edge.

And, the more pressing issue is probably community... DataNucleus is, it
would appear, pretty much a one-man band.  That said, given we can't use
Hibernate, I think that DN is as a good a choice as either OpenJPA or
EclipseLink (the only other two candidates).

If we take the NoSQL functionality into account, then - to me at least -
JDO fits much better to Isis' hexagonal ports-and-adapters architecture:
JDO takes care of the various adapters for the "persistence" port, while
Isis takes care of the "presentation" port.  A nice symmetry.


Cheers
Dan

Re: Some questions

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

> > In no particular order:
> > a) how well does it work on EE6+ servers
> 
> 
> very well, thank you!

:)

I was aked if the wars can be deployed into non-Tomcat installations.
 
> > and how much of EE
> > infrastructure can it leverage? (see next questions)
> >
> Since Isis is a framework that provides a container for domain objects, the
> user's code is substantially hidden from JEE.  So the question really is to
> what extent could one expose these services.

I think this question was from the other perspective: Can the 
user-written domain classes access services provided by the EE 
server? (i.e. can the "developer" access more than what is provided 
by Isis). [I don't know what these could be, personally].

> > d) could user use JPA instead of JDO?
> > [The Isis DN objectstore currently has a JDO implementation. One
> > would have to write a JPA equivalent?]
> >
> Not currently.  DN does support JPA syntax, so I imagine the changes would
> be pretty simple.
> 
> Supporting a different JPA implementaition would be much more work...
>  Note: we cannot ever support Hibernate because of its license (LGPL); that
> basically leaves OpenJPA.

To clarify, a user could add Hibernate into their own extension, but it 
could never be added to the Apache Isis codebase on 
isis.apache.org.

> > f) What about client-side validation?
> >
> >
> What's the client in this context... presumably the browser/Javascript?
> 
> It would be possible, if using the Wicket viewer, to write some custom
> Javascript, and have it call back into the Restful Objects viewer to
> perform validation.  Otherwise, we are leveraging the capabilities of the
> Wicket framework.  That does quite a lot in this space.  Isis' Wicket
> viewer has a pluggable architecture for its components, so writing cleverer
> widgets is certainly do-able.

On further questioning, the asker of this question was after reducing 
the number of queries to the server - so the idea of AJAX calls back 
to the RO viewer is not ideal. He'd want scripts that do the validation 
on the client without additional calls back to the server.

I can imagine a system whereby validation scripts get served to the 
client. Can they be introspected from the validateXXX methods? That 
would be interesting!

> > General feedback: The guys asking all seemed to working on or for
> > Redhat (JBoss) and related. They seemed surprised that Isis adopted
> > JDO over JPA, with comments along the lines of "but JDO is dead
> > already".
> 
> 
> I doubt that Andy Jefferson would agree. But yes, it is the betamax to
> JPA's vhs.  Note: it's also more capable, eg supporting NoSQL stores as
> well as RDBMS [2]

Interesting! Are you offering to push this analogy to the next level: 
betamax was also the better technology over VHS.. is JDO somehow 
better than JPA? (apart from the extra NoSQL functionality).

> > Otherwise, the general consensus was positive, since Isis
> > handles all that one could want, if one wanted everything to be
> > provided by a single framework.
> >
> >
> Nice to hear!
> 
> Thanks for doing this talk, Kevin.

I quite enjoy giving these talks.. I do quite like the Isis Framework ;)

- Kevin

Re: Some questions

[Dan Haywood <da...@haywood-associates.co.uk>]

On 20 November 2013 18:19, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:

> Hi all,
>
>
> In no particular order:
> a) how well does it work on EE6+ servers


very well, thank you!


> and how much of EE
> infrastructure can it leverage? (see next questions)
>
>
Since Isis is a framework that provides a container for domain objects, the
user's code is substantially hidden from JEE.  So the question really is to
what extent could one expose these services.

The answer to that is that, if you can write a domain service that
encapsulates some capability you want to leverage, then Isis apps can use
all of JEE 6.  For example, a domain service could provide access to a
rules engine, or simply to HttpServletRequest.  Domain services are the
"gateway" to the rest of the world.

A similar question might be... to what extent can the various components of
Isis (the Wicket viewer, the RESTful viewer etc) be customized themselves?
  To which the answer varies.  The Wicket viewer can to some extent, see my
various component factories that integrate gmap, calendar, highcharts etc;
the RO viewer cannot be extended at all, but then it's purpose is simply to
provide a well-defined REST API into the Isis runtime for arbitrary uses
(eg an Javascript SPA app, for migration, etc etc).



> b) how do annotations that are use relate to JSR-330,


they don't... they are in a different package.

A similar question might be... how does Isis' injection of domain services
compare to JSR-330? Right now there's not much overlap... JSR-330 defines
@Inject, whereas Isis supports either setXxx() or injectXxx() as methods.
 Oscar just raised a ticket (at my request) to also support @Inject, so
that will come in the next release.

@Named (which qualifies two services of coincidentally the same type) is
not supported... Isis would probably trip up on this.  However, all Isis
services can optionally define an id() method which "names" them, so this
would be easy enough to add as well, I guess.  Same goes for @Qualifier...
not supported yet.

@Scope also isn't supported, but here it's harder to see the justification.
 Isis automatically provides request-scoping for each interaction, while
domain services are globally scoped singletons.  For that reason the
@Singleton annotation is implied.




> or even CDI for
> that matter given that you share names of annoations
>
>
again, coincidence... different package.

Related, it would be trivial, if one wanted, to use @javax.inject.Named
instead of org.apache.isis.applib.annotation.Named... just write an Isis
FacetFactory.  Not sure that's a good idea, but would take about 30 minutes
to implement.



> c) could validation be extended to use bean validation spec?
> http://beanvalidation.org/
>
>
yep, easily enough.... write some FacetFactory's.  There is in fact some
example code on this [1] as well as a ticket, IIRC.



> d) could user use JPA instead of JDO?
> [The Isis DN objectstore currently has a JDO implementation. One
> would have to write a JPA equivalent?]
>
>
Not currently.  DN does support JPA syntax, so I imagine the changes would
be pretty simple.

Supporting a different JPA implementaition would be much more work...
should distinguish between the API (JDO vs JPA) and the impl (DN vs
Hibernate vs OpenJPA vs ...).  So as I say, supporting a different API on
DN is easy.  Supporting a different implementation is rather more work.
 Note: we cannot ever support Hibernate because of its license (LGPL); that
basically leaves OpenJPA.




> e) any there other persistence providers that work with isis beyond
> datanucleus?
>

I believe that Maurizio has got Isis running on Google App Engine, which is
a different JDO impl (though derived from DN, I think).  I'm pretty sure
that I do use some DN-specific APIs, so I'm a bit surprised this works, but
there you go.



> [Again, for a "seamless" fit, you can write your own objectstore
> implementation. Otherwise, you can bypass Isis' objectstore and use
> your own store API - but this would require disabling bytecode
> enhancements, etc... More specific guidance can be provided on
> demand.]
>
>
As you say, Isis itself does define its own ObjectStore API, and the JDO/DN
ObjectStore is only one implementation (albeit at this stage the most
mature).   There is an unreleased NoSQL ObjectStore however.  Writing an
OpenJPA ObjectStore would take a couple of months work, I reckon (the DN
one took about 3, and another 6 months of use to stabilize).



> f) What about client-side validation?
>
>
What's the client in this context... presumably the browser/Javascript?

It would be possible, if using the Wicket viewer, to write some custom
Javascript, and have it call back into the Restful Objects viewer to
perform validation.  Otherwise, we are leveraging the capabilities of the
Wicket framework.  That does quite a lot in this space.  Isis' Wicket
viewer has a pluggable architecture for its components, so writing cleverer
widgets is certainly do-able.



> General feedback: The guys asking all seemed to working on or for
> Redhat (JBoss) and related. They seemed surprised that Isis adopted
> JDO over JPA, with comments along the lines of "but JDO is dead
> already".


I doubt that Andy Jefferson would agree. But yes, it is the betamax to
JPA's vhs.  Note: it's also more capable, eg supporting NoSQL stores as
well as RDBMS [2]



> Otherwise, the general consensus was positive, since Isis
> handles all that one could want, if one wanted everything to be
> provided by a single framework.
>
>
Nice to hear!

Thanks for doing this talk, Kevin.

Cheers
Dan


[1] https://github.com/apache/isis/tree/master/example/misc/metamodel/jsr303
[2] http://www.datanucleus.org/extensions/store_manager.html