You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2014/06/08 20:14:40 UTC
[DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Hi folks,
On Friday and Saturday just gone a number of us - Jeroen, Oscar, Maurizio,
Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in
Milan for the first "IsisCon". Ok, not exactly a conference, but a great
opportunity to see what we'd each been using Isis for, and to build a
roadmap for Isis' future. There was also plenty of conversation about
"marketing" Isis, in order to build up the user base.
I believe we all came away the event feeling it had been extremely useful
(as well as enjoyable), and I think there was a consensus on what that
roadmap and respective priorities for Isis should be.
That said, the "Apache way" is for such matters to be discussed on the
mailing list: "if it isn't on the mailing list then it didn't happen". I
therefore want to summarize the main topics of conversation that we had.
For those who were in Milan: please amplify/extend/correct as necessary.
For everyone else: please join in the conversation with your own thoughts.
Remember: we assume silent consensus.
~~~~~
Some of the ideas that follow build upon each other, some are independent
of each other. I won't attempt to outline an exact timetable, but you can
see that some of this work could be performed in parallel. For example,
improved Shiro support (4) could be done at the same time as simplifying
the framework (1).
1. Simplifying the framework
Apache Isis is the evolution of the original Naked Objects Framework for
Java; when it entered the Apache incubator in 2010 the codebase was the NOF
code along with a number of "sister projects" that I had written over the
previous few years.
Some of this codebase is very old however - Rob Matthews (one of our
committers) actually started on NOF in about 1999; 15 years ago!
Obviously, since then a lot has changed, both in terms of the
architectures we aim to support, and in other libraries/frameworks that are
available that we can leverage.
For example, originally the NOF was intended to run either as standalone
client, or in client/server mode, or as a server-only webapp. In Isis we
retired the client/server remoting support when we graduated in 2012, but
we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT viewer
(even though this hasn't been released since we graduated the Apache
incubator in 2012).
Another change over the years is in persistence support. Isis has an
ObjectStore API, and this allows different ObjectStore implementations to
be plugged in. These include the JDO/Datanucleus ObjectStore, but also the
In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore.
(Again, these latter two have not been released since we graduated).
While the JDO/Datanucleus ObjectStore manages (through the DataNucleus ORM)
its own lazy loading and dirty object tracking, the other ObjectStores do
not have this ability; which means that the core-runtime component of the
Isis framework must handle such matters instead. This introduces a lot of
complexity into Isis, as it must do many of the tasks that an ORM would
normally do.
Finally, another area where we have the opportunity to leverage third party
frameworks is in security. Isis defines its own authentication and
authorization APIs, and these are exposed to the domain code in the
DomainObjectContainer#getUser() method. Right now we have three such
implementations - a simple file-based implementation, a do-nothing "bypass"
implementation, and an implementation based on Apache Shiro.
So... we now feel the time is right to simplify:
* Isis will run only as a server-side webapp. This implies that the DnD
viewer will be retired. This will also enable Isis' bootstrapping to be
simplified and rationalized.
* Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
ObjectStore implementation then made part of core. The other ObjectStore
implementations will be retired. This step in particular should enable
considerable simplification
* Isis will adopt the Shiro authentication classes rather than define its
own. This will also allow authentication to be moved into the core.
Each of these changes is relatively low risk, and introduces only minimal
changes to existing domain code. In fact, hopefully only the change to
authentication classes will require updates to existing code. The main
intent is to throw away code that no longer provides any benefit, thus
making it easier for others to learn a simplified Isis codebase.
2. JPA support
Having simplified the codebase, the next step (so far as persistence is
concerned) is to also support JPA. While DataNucleus is the reference
implementation for JDO, we do recognize that most Java developers know and
therefore prefer JPA over JDO. Luckily DataNucleus does also support JPA.
Hopefully it will be easy enough to allow developers to use either API -
JDO or JPA - with DataNucleus as the underlying implementation.
3. Alternative Persistence providers
Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
object tracking) and on DataNucleus in particular, the next step in the
roadmap is to re-introduce pluggability so that developers can use other
ORM implementations; particularly for the JPA API. Being an Apache product
means that we cannot dependent on certain licenses, but we certainly
provide alternative implemenation based on either Apache OpenJPA, or on
EclipseLink (the old TopLink product).
We might also look to provide an implementation for the market leader,
namely Hibernate. However, because Hibernate is LGPL, this implementation
would need to live outside of Apache Isis' formal codebase, eg in the
apache-extras.org site or perhaps just likely on github.
4. Improved support for Shiro
We've noticed a number of users wanting to use our Shiro integration, with
Shiro configured to use a JDBC Realm. It ought to be relatively simple to
build Isis entities that map onto the Shiro concepts (users, roles,
permissions). In this way Isis could provide a self-contained security
subsystem for managing users "out-of-the-box".
We anticipate delivering this as an optional module that could be included
as necessary.
An extension of this is to deliver a standalone application built with Isis
for administrating the users/roles/permissions for any application
configured to use the Shiro JDBC realm (not just an Isis application).
5. Other Reusable modules
In the applib there are a number of services; some depend on parts of the
Isis runtime; some do not. Some have their own entities, some do not:
- CommandContext (applib implementation)
- BackgroundService (core-runtime implementation)
- BackgroundCommandService (JDO implementation, with entities)
- AuditingService3 (JDO implementation, with entities)
- PublishingService (JDO implementation, with entities)
- ApplicationSettingsServiceRW (JDO implementation, with entities)
- UserSettingsServiceRW (JDO implementation, with entities)
- ClockService (applib implementation)
- QueryResultsCache (applib implementation)
- Scratchpad (applib implementation)
- MementoService (core-runtime implementation)
- BookmarkService (core-metamodel implementation)
- XmlSnapshotService (core-runtime)
- EventBus (core-runtime implementation)
- ClassDiscoveryService (applib implementation,
+optional org.reflections dependency)
- WrapperFactory (core-wrapper)
- DeveloperUtilitiesService (core-metamodel implementation)
Extended the idea of the Shiro security module (4, above), we think it
makes sense to modularize these other services; probably in five or so
modules in line with the grouping shown above. That way developers could
bring in a dependency to the services that they require, and ignore the
others.
6. Profile Store
The profile store is a component of the framework that is not supported by
either the Wicket or Restful Objects viewers, but whose functionality is
broadly superceded by the UserSettingsService.
In line with simplification (1) we'll retire this component.
7. Restful APIs
The Restful Objects viewer implements the Restful Objects spec [2] and
provides a full REST Hypermedia API to the Isis metamodel and runtime.
The original intent of the RO spec/viewer was to provide a rich http/json
API, rigorously following RESTful principles, to enable both the
development of a "next-gen" generic viewer written in something like
AngularJS [3], and also to enable bespoke REST applications to be written.
While we still feel that the RO viewer is appropriate for the former, what
is becoming more obvious is that the RO viewer is too complex for
"idiomatic" RESTful access when using tools such as AngularJS and in
particular higher-level lbraries such as Angular UI [4]
We therefore have decided to:
- rename the Restful Objects viewer, probably to be called the "Hypermedia
API" (remove the term "viewer")
- implement a new "Idiomatic REST" API which - although not necessarily
REST in the purist's sense - will play well with the aforementioned tools.
Many of the capabilities of the existing RO viewer can be leveraged to
write this new Idiomatic REST API. But we do hope it will open up the
possibilities of using Isis as a back-end to a new group of users. And, an
influx of new users might then lead in turn to the development of a generic
viewer against the "Hypermedia API".
8. Wicket Viewer
We intend to continue developing the Wicket viewer. One part of its
development will be to re-implement its components to use Wicket-Bootstrap
[5]; this will make it easier for its look-n-feel to be customised.
We will also probably rename it. "Wicket" is merely the implementation
technology; its name should represent what it's role is. Possible names
are the "default viewer", or the "standard viewer" (preferences?
alternatives?)
9. Community outreach
In line with making Isis appeal to Javascript developers, we also want to
make contact with the user communities of some of the technologies that we
use.
Within Apache these include Wicket and Shiro. Meanwhile Oscar and Nacho's
application has a custom UI that leverages Wavemaker and React.js.
Once we have the new "Idiomatic REST API" implemented, then opportunities
open up to build demos to attract AngularJS and similar technologies (eg
dhtmlx).
10. "framework" vs "platform"
Although Isis was originally conceived as a framework - indeed, was
originally named the Naked Objects Framework - the consensus in Milan was
that it would be better to position Isis as a platform. Part of the
rationale comes down with the way in which Isis is deployed, either sitting
on top of the JEE platform or Cloud platforms such as Google App Engine.
11. Better documentation, better website.
Probably every open source project would wish for better documentation and
examples; we are no different, and we intend to keep improving the docs and
providing examples of usage.
On the homepage one idea is to make Isis' value proposition more obvious.
We intend to distinguish our audience, though; what a business person
wants to know about is different from what a techie wants. So we will
provide different material for each to consume.
For a bit of interest/originality, Maurizio has offered to develop some
goanimate [6] cartoon videos; he has used these with some success in his
own software development company. Right now I am working on some scripts
to be developed; one 2-minute business-focused one, and a number (3 or 4)
of 2-minute technicaly focussed ones.
Also, I am aware that much of the materials were written by me and all of
the screencasts have my voice on them. But there should be other voices
present on the website; Isis isn't a one-man show and visitors to the
website shouldn't get that impression.
12. The great and the good
With so many great open source projects out there it can of course be
difficult to get heard and discovered. But if we can get some publicity
and hopefully nice words/endorsements from the "great and the good", then
that might well help increase our user base.
Once we have updated the website a little (see 10) there are a few
individuals we have in mind who we will look to contact.
13. Conferences, articles, podcasts
Jeroen and I are intending to submitting a couple of sessions to ApacheCon
EU in Hungary [7], and in general try to do a few more sessions.
I have also promised an 500-word blog post for Zeroturnaround to advertise
our JRebel integration.
And, it'd also be good to do some podcasts sessions; I am sure they are
several looking for new people to talk with.
~~~
As you'll have noticed, the last 4 or 5 topics fall broadly under the
category of "marketing". So - if you've read this far - can I ask anyone
and everyone in Isis to start help generate collateral. Blog posts (not
just in the English language) are great; or ask (and self-answer) questions
on stackoverflow (with the #isis tag); or simply just send hints and tips
on the mailing lists and I'll put them onto the website.
~~~
OK, I think that's it.
As I say, for those who were in Milan, please amplify/expand/correct. For
everyone else, your comments/thoughts are welcome.
Cheers
Dan
Apache Isis PMC Chair
[1] http://semver.org
[2] http://restfulobjects.org
[3] http://angularjs.org/
[4] http://angular-ui.github.io/bootstrap
[5] http://wb.agilecoders.de/demo/components
[6] http://goanimate.com
[7] http://www.apachecon.com/
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 17 June 2014 08:15, Stephen Cameron <st...@gmail.com> wrote:
> Hi Dan,
>
> Just a thought bubble that the future is Web Components and maybe Angular
> may or may not be compatible with that?
>
>
Web components (polymer etc) is certainly promising, but given that Google
is putting considerable resource behind both projects, I would be amazed if
they don't converge.
As I see it, AngularJS directives will be refactored into/replaced by web
components; but much of the rest of Angular remains.
Yhat said, I say this based on very little research, so happy to be
corrected.
> Personally I hope that the Application developers do get themselves sorted
> with a good UI 'component object' approach and leave the REST to get on
> with building a true 'web' outside of Facebook.
>
>
+1
Dan
> Steve Cameron
>
>
>
> On Mon, Jun 9, 2014 at 4:14 AM, Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
>
> > Hi folks,
> >
> > On Friday and Saturday just gone a number of us - Jeroen, Oscar,
> Maurizio,
> > Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in
> > Milan for the first "IsisCon". Ok, not exactly a conference, but a great
> > opportunity to see what we'd each been using Isis for, and to build a
> > roadmap for Isis' future. There was also plenty of conversation about
> > "marketing" Isis, in order to build up the user base.
> >
> > I believe we all came away the event feeling it had been extremely useful
> > (as well as enjoyable), and I think there was a consensus on what that
> > roadmap and respective priorities for Isis should be.
> >
> > That said, the "Apache way" is for such matters to be discussed on the
> > mailing list: "if it isn't on the mailing list then it didn't happen". I
> > therefore want to summarize the main topics of conversation that we had.
> >
> > For those who were in Milan: please amplify/extend/correct as necessary.
> > For everyone else: please join in the conversation with your own
> thoughts.
> > Remember: we assume silent consensus.
> >
> > ~~~~~
> > Some of the ideas that follow build upon each other, some are independent
> > of each other. I won't attempt to outline an exact timetable, but you
> can
> > see that some of this work could be performed in parallel. For example,
> > improved Shiro support (4) could be done at the same time as simplifying
> > the framework (1).
> >
> > 1. Simplifying the framework
> >
> > Apache Isis is the evolution of the original Naked Objects Framework for
> > Java; when it entered the Apache incubator in 2010 the codebase was the
> NOF
> > code along with a number of "sister projects" that I had written over the
> > previous few years.
> >
> > Some of this codebase is very old however - Rob Matthews (one of our
> > committers) actually started on NOF in about 1999; 15 years ago!
> > Obviously, since then a lot has changed, both in terms of the
> > architectures we aim to support, and in other libraries/frameworks that
> are
> > available that we can leverage.
> >
> > For example, originally the NOF was intended to run either as standalone
> > client, or in client/server mode, or as a server-only webapp. In Isis we
> > retired the client/server remoting support when we graduated in 2012, but
> > we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT
> viewer
> > (even though this hasn't been released since we graduated the Apache
> > incubator in 2012).
> >
> > Another change over the years is in persistence support. Isis has an
> > ObjectStore API, and this allows different ObjectStore implementations to
> > be plugged in. These include the JDO/Datanucleus ObjectStore, but also
> the
> > In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore.
> > (Again, these latter two have not been released since we graduated).
> >
> > While the JDO/Datanucleus ObjectStore manages (through the DataNucleus
> ORM)
> > its own lazy loading and dirty object tracking, the other ObjectStores do
> > not have this ability; which means that the core-runtime component of the
> > Isis framework must handle such matters instead. This introduces a lot
> of
> > complexity into Isis, as it must do many of the tasks that an ORM would
> > normally do.
> >
> > Finally, another area where we have the opportunity to leverage third
> party
> > frameworks is in security. Isis defines its own authentication and
> > authorization APIs, and these are exposed to the domain code in the
> > DomainObjectContainer#getUser() method. Right now we have three such
> > implementations - a simple file-based implementation, a do-nothing
> "bypass"
> > implementation, and an implementation based on Apache Shiro.
> >
> > So... we now feel the time is right to simplify:
> > * Isis will run only as a server-side webapp. This implies that the DnD
> > viewer will be retired. This will also enable Isis' bootstrapping to be
> > simplified and rationalized.
> > * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> > ObjectStore implementation then made part of core. The other ObjectStore
> > implementations will be retired. This step in particular should enable
> > considerable simplification
> > * Isis will adopt the Shiro authentication classes rather than define its
> > own. This will also allow authentication to be moved into the core.
> >
> > Each of these changes is relatively low risk, and introduces only minimal
> > changes to existing domain code. In fact, hopefully only the change to
> > authentication classes will require updates to existing code. The main
> > intent is to throw away code that no longer provides any benefit, thus
> > making it easier for others to learn a simplified Isis codebase.
> >
> >
> > 2. JPA support
> >
> > Having simplified the codebase, the next step (so far as persistence is
> > concerned) is to also support JPA. While DataNucleus is the reference
> > implementation for JDO, we do recognize that most Java developers know
> and
> > therefore prefer JPA over JDO. Luckily DataNucleus does also support
> JPA.
> > Hopefully it will be easy enough to allow developers to use either API -
> > JDO or JPA - with DataNucleus as the underlying implementation.
> >
> >
> > 3. Alternative Persistence providers
> >
> > Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> > object tracking) and on DataNucleus in particular, the next step in the
> > roadmap is to re-introduce pluggability so that developers can use other
> > ORM implementations; particularly for the JPA API. Being an Apache
> product
> > means that we cannot dependent on certain licenses, but we certainly
> > provide alternative implemenation based on either Apache OpenJPA, or on
> > EclipseLink (the old TopLink product).
> >
> > We might also look to provide an implementation for the market leader,
> > namely Hibernate. However, because Hibernate is LGPL, this
> implementation
> > would need to live outside of Apache Isis' formal codebase, eg in the
> > apache-extras.org site or perhaps just likely on github.
> >
> >
> > 4. Improved support for Shiro
> >
> > We've noticed a number of users wanting to use our Shiro integration,
> with
> > Shiro configured to use a JDBC Realm. It ought to be relatively simple
> to
> > build Isis entities that map onto the Shiro concepts (users, roles,
> > permissions). In this way Isis could provide a self-contained security
> > subsystem for managing users "out-of-the-box".
> >
> > We anticipate delivering this as an optional module that could be
> included
> > as necessary.
> >
> > An extension of this is to deliver a standalone application built with
> Isis
> > for administrating the users/roles/permissions for any application
> > configured to use the Shiro JDBC realm (not just an Isis application).
> >
> >
> > 5. Other Reusable modules
> >
> > In the applib there are a number of services; some depend on parts of the
> > Isis runtime; some do not. Some have their own entities, some do not:
> >
> > - CommandContext (applib implementation)
> > - BackgroundService (core-runtime implementation)
> > - BackgroundCommandService (JDO implementation, with entities)
> > - AuditingService3 (JDO implementation, with entities)
> >
> > - PublishingService (JDO implementation, with entities)
> >
> > - ApplicationSettingsServiceRW (JDO implementation, with entities)
> > - UserSettingsServiceRW (JDO implementation, with entities)
> >
> > - ClockService (applib implementation)
> > - QueryResultsCache (applib implementation)
> > - Scratchpad (applib implementation)
> >
> > - MementoService (core-runtime implementation)
> > - BookmarkService (core-metamodel implementation)
> > - XmlSnapshotService (core-runtime)
> > - EventBus (core-runtime implementation)
> > - ClassDiscoveryService (applib implementation,
> > +optional org.reflections dependency)
> > - WrapperFactory (core-wrapper)
> > - DeveloperUtilitiesService (core-metamodel implementation)
> >
> > Extended the idea of the Shiro security module (4, above), we think it
> > makes sense to modularize these other services; probably in five or so
> > modules in line with the grouping shown above. That way developers could
> > bring in a dependency to the services that they require, and ignore the
> > others.
> >
> >
> > 6. Profile Store
> >
> > The profile store is a component of the framework that is not supported
> by
> > either the Wicket or Restful Objects viewers, but whose functionality is
> > broadly superceded by the UserSettingsService.
> >
> > In line with simplification (1) we'll retire this component.
> >
> >
> > 7. Restful APIs
> >
> > The Restful Objects viewer implements the Restful Objects spec [2] and
> > provides a full REST Hypermedia API to the Isis metamodel and runtime.
> >
> > The original intent of the RO spec/viewer was to provide a rich http/json
> > API, rigorously following RESTful principles, to enable both the
> > development of a "next-gen" generic viewer written in something like
> > AngularJS [3], and also to enable bespoke REST applications to be
> written.
> >
> > While we still feel that the RO viewer is appropriate for the former,
> what
> > is becoming more obvious is that the RO viewer is too complex for
> > "idiomatic" RESTful access when using tools such as AngularJS and in
> > particular higher-level lbraries such as Angular UI [4]
> >
> > We therefore have decided to:
> > - rename the Restful Objects viewer, probably to be called the
> "Hypermedia
> > API" (remove the term "viewer")
> > - implement a new "Idiomatic REST" API which - although not necessarily
> > REST in the purist's sense - will play well with the aforementioned
> tools.
> >
> > Many of the capabilities of the existing RO viewer can be leveraged to
> > write this new Idiomatic REST API. But we do hope it will open up the
> > possibilities of using Isis as a back-end to a new group of users. And,
> an
> > influx of new users might then lead in turn to the development of a
> generic
> > viewer against the "Hypermedia API".
> >
> >
> > 8. Wicket Viewer
> >
> > We intend to continue developing the Wicket viewer. One part of its
> > development will be to re-implement its components to use
> Wicket-Bootstrap
> > [5]; this will make it easier for its look-n-feel to be customised.
> >
> > We will also probably rename it. "Wicket" is merely the implementation
> > technology; its name should represent what it's role is. Possible names
> > are the "default viewer", or the "standard viewer" (preferences?
> > alternatives?)
> >
> >
> >
> > 9. Community outreach
> >
> > In line with making Isis appeal to Javascript developers, we also want to
> > make contact with the user communities of some of the technologies that
> we
> > use.
> >
> > Within Apache these include Wicket and Shiro. Meanwhile Oscar and
> Nacho's
> > application has a custom UI that leverages Wavemaker and React.js.
> >
> > Once we have the new "Idiomatic REST API" implemented, then opportunities
> > open up to build demos to attract AngularJS and similar technologies (eg
> > dhtmlx).
> >
> >
> >
> > 10. "framework" vs "platform"
> >
> > Although Isis was originally conceived as a framework - indeed, was
> > originally named the Naked Objects Framework - the consensus in Milan was
> > that it would be better to position Isis as a platform. Part of the
> > rationale comes down with the way in which Isis is deployed, either
> sitting
> > on top of the JEE platform or Cloud platforms such as Google App Engine.
> >
> >
> > 11. Better documentation, better website.
> >
> > Probably every open source project would wish for better documentation
> and
> > examples; we are no different, and we intend to keep improving the docs
> and
> > providing examples of usage.
> >
> > On the homepage one idea is to make Isis' value proposition more obvious.
> > We intend to distinguish our audience, though; what a business person
> > wants to know about is different from what a techie wants. So we will
> > provide different material for each to consume.
> >
> > For a bit of interest/originality, Maurizio has offered to develop some
> > goanimate [6] cartoon videos; he has used these with some success in his
> > own software development company. Right now I am working on some scripts
> > to be developed; one 2-minute business-focused one, and a number (3 or 4)
> > of 2-minute technicaly focussed ones.
> >
> > Also, I am aware that much of the materials were written by me and all of
> > the screencasts have my voice on them. But there should be other voices
> > present on the website; Isis isn't a one-man show and visitors to the
> > website shouldn't get that impression.
> >
> >
> > 12. The great and the good
> >
> > With so many great open source projects out there it can of course be
> > difficult to get heard and discovered. But if we can get some publicity
> > and hopefully nice words/endorsements from the "great and the good", then
> > that might well help increase our user base.
> >
> > Once we have updated the website a little (see 10) there are a few
> > individuals we have in mind who we will look to contact.
> >
> >
> > 13. Conferences, articles, podcasts
> >
> > Jeroen and I are intending to submitting a couple of sessions to
> ApacheCon
> > EU in Hungary [7], and in general try to do a few more sessions.
> >
> > I have also promised an 500-word blog post for Zeroturnaround to
> advertise
> > our JRebel integration.
> >
> > And, it'd also be good to do some podcasts sessions; I am sure they are
> > several looking for new people to talk with.
> >
> > ~~~
> >
> > As you'll have noticed, the last 4 or 5 topics fall broadly under the
> > category of "marketing". So - if you've read this far - can I ask anyone
> > and everyone in Isis to start help generate collateral. Blog posts (not
> > just in the English language) are great; or ask (and self-answer)
> questions
> > on stackoverflow (with the #isis tag); or simply just send hints and tips
> > on the mailing lists and I'll put them onto the website.
> >
> > ~~~
> > OK, I think that's it.
> >
> > As I say, for those who were in Milan, please amplify/expand/correct.
> For
> > everyone else, your comments/thoughts are welcome.
> >
> > Cheers
> > Dan
> > Apache Isis PMC Chair
> >
> >
> >
> > [1] http://semver.org
> > [2] http://restfulobjects.org
> > [3] http://angularjs.org/
> > [4] http://angular-ui.github.io/bootstrap
> > [5] http://wb.agilecoders.de/demo/components
> > [6] http://goanimate.com
> > [7] http://www.apachecon.com/
> >
>
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Stephen Cameron <st...@gmail.com>.
Hi Dan,
Just a thought bubble that the future is Web Components and maybe Angular
may or may not be compatible with that?
Personally I hope that the Application developers do get themselves sorted
with a good UI 'component object' approach and leave the REST to get on
with building a true 'web' outside of Facebook.
Steve Cameron
On Mon, Jun 9, 2014 at 4:14 AM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Hi folks,
>
> On Friday and Saturday just gone a number of us - Jeroen, Oscar, Maurizio,
> Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in
> Milan for the first "IsisCon". Ok, not exactly a conference, but a great
> opportunity to see what we'd each been using Isis for, and to build a
> roadmap for Isis' future. There was also plenty of conversation about
> "marketing" Isis, in order to build up the user base.
>
> I believe we all came away the event feeling it had been extremely useful
> (as well as enjoyable), and I think there was a consensus on what that
> roadmap and respective priorities for Isis should be.
>
> That said, the "Apache way" is for such matters to be discussed on the
> mailing list: "if it isn't on the mailing list then it didn't happen". I
> therefore want to summarize the main topics of conversation that we had.
>
> For those who were in Milan: please amplify/extend/correct as necessary.
> For everyone else: please join in the conversation with your own thoughts.
> Remember: we assume silent consensus.
>
> ~~~~~
> Some of the ideas that follow build upon each other, some are independent
> of each other. I won't attempt to outline an exact timetable, but you can
> see that some of this work could be performed in parallel. For example,
> improved Shiro support (4) could be done at the same time as simplifying
> the framework (1).
>
> 1. Simplifying the framework
>
> Apache Isis is the evolution of the original Naked Objects Framework for
> Java; when it entered the Apache incubator in 2010 the codebase was the NOF
> code along with a number of "sister projects" that I had written over the
> previous few years.
>
> Some of this codebase is very old however - Rob Matthews (one of our
> committers) actually started on NOF in about 1999; 15 years ago!
> Obviously, since then a lot has changed, both in terms of the
> architectures we aim to support, and in other libraries/frameworks that are
> available that we can leverage.
>
> For example, originally the NOF was intended to run either as standalone
> client, or in client/server mode, or as a server-only webapp. In Isis we
> retired the client/server remoting support when we graduated in 2012, but
> we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT viewer
> (even though this hasn't been released since we graduated the Apache
> incubator in 2012).
>
> Another change over the years is in persistence support. Isis has an
> ObjectStore API, and this allows different ObjectStore implementations to
> be plugged in. These include the JDO/Datanucleus ObjectStore, but also the
> In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore.
> (Again, these latter two have not been released since we graduated).
>
> While the JDO/Datanucleus ObjectStore manages (through the DataNucleus ORM)
> its own lazy loading and dirty object tracking, the other ObjectStores do
> not have this ability; which means that the core-runtime component of the
> Isis framework must handle such matters instead. This introduces a lot of
> complexity into Isis, as it must do many of the tasks that an ORM would
> normally do.
>
> Finally, another area where we have the opportunity to leverage third party
> frameworks is in security. Isis defines its own authentication and
> authorization APIs, and these are exposed to the domain code in the
> DomainObjectContainer#getUser() method. Right now we have three such
> implementations - a simple file-based implementation, a do-nothing "bypass"
> implementation, and an implementation based on Apache Shiro.
>
> So... we now feel the time is right to simplify:
> * Isis will run only as a server-side webapp. This implies that the DnD
> viewer will be retired. This will also enable Isis' bootstrapping to be
> simplified and rationalized.
> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> ObjectStore implementation then made part of core. The other ObjectStore
> implementations will be retired. This step in particular should enable
> considerable simplification
> * Isis will adopt the Shiro authentication classes rather than define its
> own. This will also allow authentication to be moved into the core.
>
> Each of these changes is relatively low risk, and introduces only minimal
> changes to existing domain code. In fact, hopefully only the change to
> authentication classes will require updates to existing code. The main
> intent is to throw away code that no longer provides any benefit, thus
> making it easier for others to learn a simplified Isis codebase.
>
>
> 2. JPA support
>
> Having simplified the codebase, the next step (so far as persistence is
> concerned) is to also support JPA. While DataNucleus is the reference
> implementation for JDO, we do recognize that most Java developers know and
> therefore prefer JPA over JDO. Luckily DataNucleus does also support JPA.
> Hopefully it will be easy enough to allow developers to use either API -
> JDO or JPA - with DataNucleus as the underlying implementation.
>
>
> 3. Alternative Persistence providers
>
> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> object tracking) and on DataNucleus in particular, the next step in the
> roadmap is to re-introduce pluggability so that developers can use other
> ORM implementations; particularly for the JPA API. Being an Apache product
> means that we cannot dependent on certain licenses, but we certainly
> provide alternative implemenation based on either Apache OpenJPA, or on
> EclipseLink (the old TopLink product).
>
> We might also look to provide an implementation for the market leader,
> namely Hibernate. However, because Hibernate is LGPL, this implementation
> would need to live outside of Apache Isis' formal codebase, eg in the
> apache-extras.org site or perhaps just likely on github.
>
>
> 4. Improved support for Shiro
>
> We've noticed a number of users wanting to use our Shiro integration, with
> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
> build Isis entities that map onto the Shiro concepts (users, roles,
> permissions). In this way Isis could provide a self-contained security
> subsystem for managing users "out-of-the-box".
>
> We anticipate delivering this as an optional module that could be included
> as necessary.
>
> An extension of this is to deliver a standalone application built with Isis
> for administrating the users/roles/permissions for any application
> configured to use the Shiro JDBC realm (not just an Isis application).
>
>
> 5. Other Reusable modules
>
> In the applib there are a number of services; some depend on parts of the
> Isis runtime; some do not. Some have their own entities, some do not:
>
> - CommandContext (applib implementation)
> - BackgroundService (core-runtime implementation)
> - BackgroundCommandService (JDO implementation, with entities)
> - AuditingService3 (JDO implementation, with entities)
>
> - PublishingService (JDO implementation, with entities)
>
> - ApplicationSettingsServiceRW (JDO implementation, with entities)
> - UserSettingsServiceRW (JDO implementation, with entities)
>
> - ClockService (applib implementation)
> - QueryResultsCache (applib implementation)
> - Scratchpad (applib implementation)
>
> - MementoService (core-runtime implementation)
> - BookmarkService (core-metamodel implementation)
> - XmlSnapshotService (core-runtime)
> - EventBus (core-runtime implementation)
> - ClassDiscoveryService (applib implementation,
> +optional org.reflections dependency)
> - WrapperFactory (core-wrapper)
> - DeveloperUtilitiesService (core-metamodel implementation)
>
> Extended the idea of the Shiro security module (4, above), we think it
> makes sense to modularize these other services; probably in five or so
> modules in line with the grouping shown above. That way developers could
> bring in a dependency to the services that they require, and ignore the
> others.
>
>
> 6. Profile Store
>
> The profile store is a component of the framework that is not supported by
> either the Wicket or Restful Objects viewers, but whose functionality is
> broadly superceded by the UserSettingsService.
>
> In line with simplification (1) we'll retire this component.
>
>
> 7. Restful APIs
>
> The Restful Objects viewer implements the Restful Objects spec [2] and
> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>
> The original intent of the RO spec/viewer was to provide a rich http/json
> API, rigorously following RESTful principles, to enable both the
> development of a "next-gen" generic viewer written in something like
> AngularJS [3], and also to enable bespoke REST applications to be written.
>
> While we still feel that the RO viewer is appropriate for the former, what
> is becoming more obvious is that the RO viewer is too complex for
> "idiomatic" RESTful access when using tools such as AngularJS and in
> particular higher-level lbraries such as Angular UI [4]
>
> We therefore have decided to:
> - rename the Restful Objects viewer, probably to be called the "Hypermedia
> API" (remove the term "viewer")
> - implement a new "Idiomatic REST" API which - although not necessarily
> REST in the purist's sense - will play well with the aforementioned tools.
>
> Many of the capabilities of the existing RO viewer can be leveraged to
> write this new Idiomatic REST API. But we do hope it will open up the
> possibilities of using Isis as a back-end to a new group of users. And, an
> influx of new users might then lead in turn to the development of a generic
> viewer against the "Hypermedia API".
>
>
> 8. Wicket Viewer
>
> We intend to continue developing the Wicket viewer. One part of its
> development will be to re-implement its components to use Wicket-Bootstrap
> [5]; this will make it easier for its look-n-feel to be customised.
>
> We will also probably rename it. "Wicket" is merely the implementation
> technology; its name should represent what it's role is. Possible names
> are the "default viewer", or the "standard viewer" (preferences?
> alternatives?)
>
>
>
> 9. Community outreach
>
> In line with making Isis appeal to Javascript developers, we also want to
> make contact with the user communities of some of the technologies that we
> use.
>
> Within Apache these include Wicket and Shiro. Meanwhile Oscar and Nacho's
> application has a custom UI that leverages Wavemaker and React.js.
>
> Once we have the new "Idiomatic REST API" implemented, then opportunities
> open up to build demos to attract AngularJS and similar technologies (eg
> dhtmlx).
>
>
>
> 10. "framework" vs "platform"
>
> Although Isis was originally conceived as a framework - indeed, was
> originally named the Naked Objects Framework - the consensus in Milan was
> that it would be better to position Isis as a platform. Part of the
> rationale comes down with the way in which Isis is deployed, either sitting
> on top of the JEE platform or Cloud platforms such as Google App Engine.
>
>
> 11. Better documentation, better website.
>
> Probably every open source project would wish for better documentation and
> examples; we are no different, and we intend to keep improving the docs and
> providing examples of usage.
>
> On the homepage one idea is to make Isis' value proposition more obvious.
> We intend to distinguish our audience, though; what a business person
> wants to know about is different from what a techie wants. So we will
> provide different material for each to consume.
>
> For a bit of interest/originality, Maurizio has offered to develop some
> goanimate [6] cartoon videos; he has used these with some success in his
> own software development company. Right now I am working on some scripts
> to be developed; one 2-minute business-focused one, and a number (3 or 4)
> of 2-minute technicaly focussed ones.
>
> Also, I am aware that much of the materials were written by me and all of
> the screencasts have my voice on them. But there should be other voices
> present on the website; Isis isn't a one-man show and visitors to the
> website shouldn't get that impression.
>
>
> 12. The great and the good
>
> With so many great open source projects out there it can of course be
> difficult to get heard and discovered. But if we can get some publicity
> and hopefully nice words/endorsements from the "great and the good", then
> that might well help increase our user base.
>
> Once we have updated the website a little (see 10) there are a few
> individuals we have in mind who we will look to contact.
>
>
> 13. Conferences, articles, podcasts
>
> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
> EU in Hungary [7], and in general try to do a few more sessions.
>
> I have also promised an 500-word blog post for Zeroturnaround to advertise
> our JRebel integration.
>
> And, it'd also be good to do some podcasts sessions; I am sure they are
> several looking for new people to talk with.
>
> ~~~
>
> As you'll have noticed, the last 4 or 5 topics fall broadly under the
> category of "marketing". So - if you've read this far - can I ask anyone
> and everyone in Isis to start help generate collateral. Blog posts (not
> just in the English language) are great; or ask (and self-answer) questions
> on stackoverflow (with the #isis tag); or simply just send hints and tips
> on the mailing lists and I'll put them onto the website.
>
> ~~~
> OK, I think that's it.
>
> As I say, for those who were in Milan, please amplify/expand/correct. For
> everyone else, your comments/thoughts are welcome.
>
> Cheers
> Dan
> Apache Isis PMC Chair
>
>
>
> [1] http://semver.org
> [2] http://restfulobjects.org
> [3] http://angularjs.org/
> [4] http://angular-ui.github.io/bootstrap
> [5] http://wb.agilecoders.de/demo/components
> [6] http://goanimate.com
> [7] http://www.apachecon.com/
>
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 14 June 2014 10:56, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
wrote:
> [snip]
>
> We also mentioned on IsisCon (but also I can remember Dan mentioned
> something similar on the mailing list as his intention for version 2) that
> domain objects (domain entity instances) could be "wrapped by default",
> acting as a "container" of the business logic and ensuring it was preserved
> by default when invoked from other domain objects.
>
> [snip]
> Any thoughts?
>
>
Thanks for mentioning this idea too; I forgot to add it to my list.
Whether Isis 2.0 has the feature on by default, or is somehow a flag, not
sure. Don't really want to have lots of flags to enable/disable features
in the framework, but maybe in this case it would be warranted.
That said, I'm still not sure if it could be implemented, though. Wrapping
objects returned by repository queries is easy enough; the difficulty is in
handling objects that are loaded by lazy loading. If you look in
IsisLifecycleListener there is the postLoad(InstanceLifecycleEvent ev)
method; this is the callback fired whenever JDO/DN loads an object for us.
However, as you can see, the InstanceLifecycleEvent doesn't allow the
object loaded to be substituted (there is no setObject(...) method in the
interface).
I'll ask Andy Jefferson (DN lead) if I'm missing something.
Cheers
Dan
> Thanks,
>
> Oscar
>
>
>
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
I think the same, Dan.
In fact, I like a lot the concept of "trust boundaries".
Micro-services implements it for services, Isis with wrapped objects for domain entities instances (domain objects).
Isis *is not* a micro-services architecture. The similarity is only from the encapsulation perspective, where each domain object could act as a "behavioral" entity "isolated" from the others (preserving pre/post-conditions, as you mentioned, including invocations between domain objects, not only from outside of the domain).
In other words, for better representing the paralelism I see:
| MICRO-SERVICES ARCHITECTURE | ISIS WITH WRAPPED OBJECTS |
| micro-services architecture tries to have "small" services | Isis wrapped objects act as "small" domain objects |
| isolated from other "small" services | isolated from other "small domain objects |
| through a well-defined interface (REST, etc.) | through a well-defined interface (Isis Object Specification, Programming Model) |
| so business logic (pre/post-conditions) is always preserved between invocations | so business logic is always preserved between invocations |
I think it's a benefit not specific for our domain, but a global benefit for any domain.
Do you agree? Any thoughts by anybody?
Thanks,
Oscar
El 16/06/2014, a las 15:02, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
>
>
> On 16 June 2014 12:27, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
> Hi, David!
>
> I see more parallelism with the "micro-services architecture", but inside the business domain [1].
>
>
> Hmm.
>
> Much that I like to think that Isis embodies multiple architectures and paradigms (object orientation, aspect orientation, DCI... not to mention the naked objects pattern of course as well as the hexagonal architecture ... and with passable support for CQRS, come to that), I *do* think it's stretching things rather to position Isis as a micro-service architecture.
>
> IIRC, one of the benefits of micro-services is the ability to change the implementation of different services. That isn't the case with Isis; the whole thing must get deployed as a single unit. (This understanding is based on [1], also on a Fred George presentation [2] and this great article in InfoQ [3]).
>
> Dan
>
> [2] http://oredev.org/2013/wed-fri-conference/implementing-micro-service-architectures
> [3] http://www.infoq.com/articles/microservices-intro
>
>
> Each object could be considered as equivalent to a behavioral entity (like a "service") accessed (published to the other domain entities) under a well-defined interface (the Isis Object Specification, comprised of properties and actions) that fully encapsulates all business logic, avoiding pitfalls, errors, etc. when directly invoking methods without taking into account all associated business logic.
>
> [1] http://martinfowler.com/articles/microservices.html
>
>
> Regards,
>
> Oscar
>
>
> El 16/06/2014, a las 13:14, David Tildesley <da...@yahoo.co.nz> escribió:
>
>> Hi Oscar,
>>
>> I have a question about this idea: Is this not akin to the old EJB (1.x/2.x) "component" concept and therefore a move away from "POJO". A POJO domain model that is loosely coupled for maintainability would use design principles such as Demeter's Law (in particular). The question for you therefore is how would you preserve this design principle?
>>
>> I agree that the domain layer must protect itself and not depend on any UI layer to do that protection. However is it necessary to go to that extent within the domain layer itself?
>>
>> However, on the same theme - there is currently a reliance on the generated viewer to implement domain object annotated business logic "guards" for setters in particular. Anything from the UI layer that is not part of the generated viewer that calls the domain layer directly (e.g a view object), effectively bypass these guards and I think this is not right. Your suggestion would solve that problem.
>>
>> So maybe there is a way of introducing this automated wrapper without at the same time turning ISIS into EJB 1.x/2.x? If that is possible then you have my vote.
>>
>> I think the main threat to the (fully contained business logic) rich domain layer is actually the misuse of the view object - particularly when combined with the issue that the framework makes it necessary to use the view object in lieu of a non-dm-persisted domain object. Don't get me wrong - I see the view object as essential for (in particular) a web viewer in order to build an user friendly UI.
>>
>> Kind Regards,
>> David.
>>
>>
>>
>>
>>
>> On Saturday, 14 June 2014 9:56 PM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>>
>>
>> Just one more thing for the roadmap.
>>
>> We also mentioned on IsisCon (but also I can remember Dan mentioned something similar on the mailing list as his intention for version 2) that domain objects (domain entity instances) could be "wrapped by default", acting as a "container" of the business logic and ensuring it was preserved by default when invoked from other domain objects.
>>
>> That would imply that, for example, a call to:
>>
>> domainObject.someAction(x, y, z);
>>
>> Would always validate the parameters, choices, etc. and all other associated business logic.
>>
>> And that a call to:
>>
>> domainObject.setXXX(x);
>>
>> would always preserve the business rules implemented on the modifyXXX, validateXXX, clearXXX methods, for example.
>>
>>
>> It has many advantages, for example for testing. It really avoids "programming errors" originated by invoking in the domain actions or setters without taking into account validations or business logic inside the modifyXXX methods, for example.
>>
>> In our case, nearly all our actions are setter invocations are made through:
>>
>> this.wrap(domainObject).setXXX, this.wrap(domainObject).actionXXX
>>
>> or, if they're hidden or disabled,
>>
>> this.wrapSkipRules(domainObject).setXXX, this.wrapSkipRules(domainObject).actionXXX
>>
>>
>> That strategy of "always wrapping" helps REALLY A LOT while debugging.
>>
>>
>> Sincerelly, this was one of our expectations when we arrived to Isis. And we don't know of any other platform that always tries to preserve all business logic.
>>
>>
>> Thay would imply that Isis would act as a "true" hexagonal architecture when the UI just is another port-adapter, with exactly the same behavior as any other invokation from any other port-adapter, and what it's most exclusive of any platform, doing the same with intra-domain invocations.
>>
>> Any thoughts?
>>
>>
>> Thanks,
>>
>> Oscar
>>
>>
>>
>>
>>
>>
>>
>> El 10/06/2014, a las 21:28, Kevin Meyer - KMZ <ke...@kmz.co.za> escribió:
>>
>>> Quick immediate reply:
>>>
>>>> ~~~~~
>>>> Some of the ideas that follow build upon each other, some are independent
>>>> of each other. I won't attempt to outline an exact timetable, but you can
>>>> see that some of this work could be performed in parallel. For example,
>>>> improved Shiro support (4) could be done at the same time as simplifying
>>>> the framework (1).
>>>>
>>>> 1. Simplifying the framework
>>>>
>>>> * Isis will run only as a server-side webapp. This implies that the DnD
>>>> viewer will be retired. This will also enable Isis' bootstrapping to be
>>>> simplified and rationalized.
>>>
>>> By the way: A DnD viewer can be later re-implemented, if so desired.
>>>
>>>> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
>>>> ObjectStore implementation then made part of core. The other ObjectStore
>>>> implementations will be retired. This step in particular should enable
>>>> considerable simplification
>>>
>>> As described, this is a temporary state, with a future plan to later
>>> abstract out a new Objectstore API to support other objectstore
>>> frameworks. See below.
>>>
>>>> * Isis will adopt the Shiro authentication classes rather than define its
>>>> own. This will also allow authentication to be moved into the core.
>>>
>>> I have no comment :)
>>>
>>>> 3. Alternative Persistence providers
>>>>
>>>> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
>>>> object tracking) and on DataNucleus in particular, the next step in the
>>>> roadmap is to re-introduce pluggability so that developers can use other
>>>> ORM implementations; particularly for the JPA API. Being an Apache product
>>>> means that we cannot dependent on certain licenses, but we certainly
>>>> provide alternative implemenation based on either Apache OpenJPA, or on
>>>> EclipseLink (the old TopLink product).
>>>>
>>>> We might also look to provide an implementation for the market leader,
>>>> namely Hibernate. However, because Hibernate is LGPL, this implementation
>>>> would need to live outside of Apache Isis' formal codebase, eg in the
>>>> apache-extras.org site or perhaps just likely on github.
>>>>
>>>>
>>>> 4. Improved support for Shiro
>>>>
>>>> We've noticed a number of users wanting to use our Shiro integration, with
>>>> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
>>>> build Isis entities that map onto the Shiro concepts (users, roles,
>>>> permissions). In this way Isis could provide a self-contained security
>>>> subsystem for managing users "out-of-the-box".
>>>>
>>>> We anticipate delivering this as an optional module that could be included
>>>> as necessary.
>>>>
>>>> An extension of this is to deliver a standalone application built with Isis
>>>> for administrating the users/roles/permissions for any application
>>>> configured to use the Shiro JDBC realm (not just an Isis application).
>>>
>>> The discussions I've had and heard regarding other application
>>> development suites lead me to believe that this would be an extremely
>>> useful add-on! I'd almost like to request that this be the first thing
>>> worked on, before any of the fundamental changes listed above.
>>>
>>> But that's just my wish.
>>>
>>> (I'd like to demo that Isis can also support RBAC, out-of-the-box).
>>>
>>>>
>>>>
>>>> 5. Other Reusable modules
>>>>
>>>> In the applib there are a number of services; some depend on parts of the
>>>> Isis runtime; some do not. Some have their own entities, some do not:
>>>>
>>>> - CommandContext (applib implementation)
>>>> - BackgroundService (core-runtime implementation)
>>>> - BackgroundCommandService (JDO implementation, with entities)
>>>> - AuditingService3 (JDO implementation, with entities)
>>>>
>>>> - PublishingService (JDO implementation, with entities)
>>>>
>>>> - ApplicationSettingsServiceRW (JDO implementation, with entities)
>>>> - UserSettingsServiceRW (JDO implementation, with entities)
>>>>
>>>> - ClockService (applib implementation)
>>>> - QueryResultsCache (applib implementation)
>>>> - Scratchpad (applib implementation)
>>>>
>>>> - MementoService (core-runtime implementation)
>>>> - BookmarkService (core-metamodel implementation)
>>>> - XmlSnapshotService (core-runtime)
>>>> - EventBus (core-runtime implementation)
>>>> - ClassDiscoveryService (applib implementation,
>>>> +optional org.reflections dependency)
>>>> - WrapperFactory (core-wrapper)
>>>> - DeveloperUtilitiesService (core-metamodel implementation)
>>>>
>>>> Extended the idea of the Shiro security module (4, above), we think it
>>>> makes sense to modularize these other services; probably in five or so
>>>> modules in line with the grouping shown above. That way developers could
>>>> bring in a dependency to the services that they require, and ignore the
>>>> others.
>>>>
>>>>
>>>> 6. Profile Store
>>>>
>>>> The profile store is a component of the framework that is not supported by
>>>> either the Wicket or Restful Objects viewers, but whose functionality is
>>>> broadly superceded by the UserSettingsService.
>>>
>>> When the UI becomes user-configurable (re-arranged, pallete change,
>>> etc) this should be demo'd.
>>>
>>> Where are user preferences (e.g. UI language, timezone, etc) currently
>>> stored? Do we have demo code?
>>>
>>>> In line with simplification (1) we'll retire this component.
>>>>
>>>>
>>>> 7. Restful APIs
>>>>
>>>> The Restful Objects viewer implements the Restful Objects spec [2] and
>>>> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>>>>
>>>>
>>>> 8. Wicket Viewer
>>>>
>>>> We intend to continue developing the Wicket viewer. One part of its
>>>> development will be to re-implement its components to use Wicket-Bootstrap
>>>> [5]; this will make it easier for its look-n-feel to be customised.
>>>>
>>>> We will also probably rename it. "Wicket" is merely the implementation
>>>> technology; its name should represent what it's role is. Possible names
>>>> are the "default viewer", or the "standard viewer" (preferences?
>>>> alternatives?)
>>>
>>> Thinking about it further, I would probably prefer to keep "Wicket" in the
>>> name somewhere, as the viewer *is* dependent on Wicket, and those
>>> who wish to extend (I want to add some additional view components),
>>> need to know Wicket. But I guess that other names may also be more
>>> appropriate..
>>>
>>>
>>>>
>>>> 11. Better documentation, better website.
>>>>
>>>> Probably every open source project would wish for better documentation and
>>>> examples; we are no different, and we intend to keep improving the docs and
>>>> providing examples of usage.
>>>>
>>>> On the homepage one idea is to make Isis' value proposition more obvious.
>>>> We intend to distinguish our audience, though; what a business person
>>>> wants to know about is different from what a techie wants. So we will
>>>> provide different material for each to consume.
>>>>
>>>> For a bit of interest/originality, Maurizio has offered to develop some
>>>> goanimate [6] cartoon videos; he has used these with some success in his
>>>> own software development company. Right now I am working on some scripts
>>>> to be developed; one 2-minute business-focused one, and a number (3 or 4)
>>>> of 2-minute technicaly focussed ones.
>>>>
>>>> Also, I am aware that much of the materials were written by me and all of
>>>> the screencasts have my voice on them. But there should be other voices
>>>> present on the website; Isis isn't a one-man show and visitors to the
>>>> website shouldn't get that impression.
>>>
>>> I agree and will try and step in more, here.
>>>
>>>> 13. Conferences, articles, podcasts
>>>>
>>>> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
>>>> EU in Hungary [7], and in general try to do a few more sessions.
>>>>
>>>> I have also promised an 500-word blog post for Zeroturnaround to advertise
>>>> our JRebel integration.
>>>>
>>>> And, it'd also be good to do some podcasts sessions; I am sure they are
>>>> several looking for new people to talk with.
>>>
>>> I'll be in touch later for ideas for ApacheCon EU and other opportunities.
>>>
>>> Don't forget about opportunities to show off Isis in "rapid app" dev
>>> competitions. Jeroen, you mentioned one in the Netherlands??
>>> Perhaps Isis can become the disruptive change from a surprising
>>> direction!
>>>
>>>>
>>>> ~~~
>>>> OK, I think that's it.
>>>>
>>>> As I say, for those who were in Milan, please amplify/expand/correct. For
>>>> everyone else, your comments/thoughts are welcome.
>>>>
>>>> Cheers
>>>> Dan
>>>> Apache Isis PMC Chair
>>>
>>>
>>> :)
>>>
>>> Unless otherwise indicated, I agree with the proposals.. ;)
>>>
>>> Regards,
>>> Kevin
>>>
>>>
>>
>>
>> Óscar Bou Bou
>> Responsable de Producto
>> Auditor Jefe de Certificación ISO 27001 en BSI
>> CISA, CRISC, APMG ISO 20000, ITIL-F
>>
>> <contactenos.html.gif> 902 900 231 / 620 267 520
>> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou
>>
>> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou
>>
>> <blog.png> http://www.GesConsultor.com
>>
>> <gesconsultor_logo_blue_email.png>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>> Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
>>
>>
>>
>>
>>
>>
>>
>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> 902 900 231 / 620 267 520
> http://www.twitter.com/oscarbou
>
> http://es.linkedin.com/in/oscarbou
>
> http://www.GesConsultor.com
>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 16 June 2014 12:27, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
wrote:
> Hi, David!
>
> I see more parallelism with the "micro-services architecture", but inside
> the business domain [1].
>
>
Hmm.
Much that I like to think that Isis embodies multiple architectures and
paradigms (object orientation, aspect orientation, DCI... not to mention
the naked objects pattern of course as well as the hexagonal architecture
... and with passable support for CQRS, come to that), I *do* think it's
stretching things rather to position Isis as a micro-service architecture.
IIRC, one of the benefits of micro-services is the ability to change the
implementation of different services. That isn't the case with Isis; the
whole thing must get deployed as a single unit. (This understanding is
based on [1], also on a Fred George presentation [2] and this great article
in InfoQ [3]).
Dan
[2]
http://oredev.org/2013/wed-fri-conference/implementing-micro-service-architectures
[3] http://www.infoq.com/articles/microservices-intro
> Each object could be considered as equivalent to a behavioral entity (like
> a "service") accessed (published to the other domain entities) under a
> well-defined interface (the Isis Object Specification, comprised of
> properties and actions) that fully encapsulates all business logic,
> avoiding pitfalls, errors, etc. when directly invoking methods without
> taking into account all associated business logic.
>
> [1] http://martinfowler.com/articles/microservices.html
>
>
> Regards,
>
> Oscar
>
>
> El 16/06/2014, a las 13:14, David Tildesley <da...@yahoo.co.nz>
> escribió:
>
> Hi Oscar,
>
> I have a question about this idea: Is this not akin to the old EJB
> (1.x/2.x) "component" concept and therefore a move away from "POJO". A POJO
> domain model that is loosely coupled for maintainability would use design
> principles such as Demeter's Law (in particular). The question for you
> therefore is how would you preserve this design principle?
>
> I agree that the domain layer must protect itself and not depend on any UI
> layer to do that protection. However is it necessary to go to that extent
> within the domain layer itself?
>
> However, on the same theme - there is currently a reliance on the
> generated viewer to implement domain object annotated business logic
> "guards" for setters in particular. Anything from the UI layer that is not
> part of the generated viewer that calls the domain layer directly (e.g a
> view object), effectively bypass these guards and I think this is not
> right. Your suggestion would solve that problem.
>
> So maybe there is a way of introducing this automated wrapper without at
> the same time turning ISIS into EJB 1.x/2.x? If that is possible then you
> have my vote.
>
> I think the main threat to the (fully contained business logic) rich
> domain layer is actually the misuse of the view object - particularly when
> combined with the issue that the framework makes it necessary to use the
> view object in lieu of a non-dm-persisted domain object. Don't get me
> wrong - I see the view object as essential for (in particular) a web
> viewer in order to build an user friendly UI.
>
> Kind Regards,
> David.
>
>
>
>
>
> On Saturday, 14 June 2014 9:56 PM, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com> wrote:
>
>
> Just one more thing for the roadmap.
>
> We also mentioned on IsisCon (but also I can remember Dan mentioned
> something similar on the mailing list as his intention for version 2) that
> domain objects (domain entity instances) could be "wrapped by default",
> acting as a "container" of the business logic and ensuring it was preserved
> by default when invoked from other domain objects.
>
> That would imply that, for example, a call to:
>
> domainObject.someAction(x, y, z);
>
> Would always validate the parameters, choices, etc. and all other
> associated business logic.
>
> And that a call to:
>
> domainObject.setXXX(x);
>
> would always preserve the business rules implemented on the modifyXXX,
> validateXXX, clearXXX methods, for example.
>
>
> It has many advantages, for example for testing. It really avoids
> "programming errors" originated by invoking in the domain actions or
> setters without taking into account validations or business logic inside
> the modifyXXX methods, for example.
>
> In our case, nearly all our actions are setter invocations are made
> through:
>
> this.wrap(domainObject).setXXX, this.wrap(domainObject).actionXXX
>
> or, if they're hidden or disabled,
>
> this.wrapSkipRules(domainObject).setXXX,
> this.wrapSkipRules(domainObject).actionXXX
>
>
> That strategy of "always wrapping" helps REALLY A LOT while debugging.
>
>
> Sincerelly, this was one of our expectations when we arrived to Isis. And
> we don't know of any other platform that always tries to preserve all
> business logic.
>
>
> Thay would imply that Isis would act as a "true" hexagonal architecture
> when the UI just is another port-adapter, with exactly the same behavior as
> any other invokation from any other port-adapter, and what it's most
> exclusive of any platform, doing the same with intra-domain invocations.
>
> Any thoughts?
>
>
> Thanks,
>
> Oscar
>
>
>
>
>
>
>
> El 10/06/2014, a las 21:28, Kevin Meyer - KMZ <ke...@kmz.co.za> escribió:
>
> Quick immediate reply:
>
> ~~~~~
> Some of the ideas that follow build upon each other, some are independent
> of each other. I won't attempt to outline an exact timetable, but you can
> see that some of this work could be performed in parallel. For example,
> improved Shiro support (4) could be done at the same time as simplifying
> the framework (1).
>
> 1. Simplifying the framework
>
> * Isis will run only as a server-side webapp. This implies that the DnD
> viewer will be retired. This will also enable Isis' bootstrapping to be
> simplified and rationalized.
>
>
> By the way: A DnD viewer can be later re-implemented, if so desired.
>
> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> ObjectStore implementation then made part of core. The other ObjectStore
> implementations will be retired. This step in particular should enable
> considerable simplification
>
>
> As described, this is a temporary state, with a future plan to later
> abstract out a new Objectstore API to support other objectstore
> frameworks. See below.
>
> * Isis will adopt the Shiro authentication classes rather than define its
> own. This will also allow authentication to be moved into the core.
>
>
> I have no comment :)
>
> 3. Alternative Persistence providers
>
> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> object tracking) and on DataNucleus in particular, the next step in the
> roadmap is to re-introduce pluggability so that developers can use other
> ORM implementations; particularly for the JPA API. Being an Apache product
> means that we cannot dependent on certain licenses, but we certainly
> provide alternative implemenation based on either Apache OpenJPA, or on
> EclipseLink (the old TopLink product).
>
> We might also look to provide an implementation for the market leader,
> namely Hibernate. However, because Hibernate is LGPL, this implementation
> would need to live outside of Apache Isis' formal codebase, eg in the
> apache-extras.org site or perhaps just likely on github.
>
>
> 4. Improved support for Shiro
>
> We've noticed a number of users wanting to use our Shiro integration, with
> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
> build Isis entities that map onto the Shiro concepts (users, roles,
> permissions). In this way Isis could provide a self-contained security
> subsystem for managing users "out-of-the-box".
>
> We anticipate delivering this as an optional module that could be included
> as necessary.
>
> An extension of this is to deliver a standalone application built with Isis
> for administrating the users/roles/permissions for any application
> configured to use the Shiro JDBC realm (not just an Isis application).
>
>
> The discussions I've had and heard regarding other application
> development suites lead me to believe that this would be an extremely
> useful add-on! I'd almost like to request that this be the first thing
> worked on, before any of the fundamental changes listed above.
>
> But that's just my wish.
>
> (I'd like to demo that Isis can also support RBAC, out-of-the-box).
>
>
>
> 5. Other Reusable modules
>
> In the applib there are a number of services; some depend on parts of the
> Isis runtime; some do not. Some have their own entities, some do not:
>
> - CommandContext (applib implementation)
> - BackgroundService (core-runtime implementation)
> - BackgroundCommandService (JDO implementation, with entities)
> - AuditingService3 (JDO implementation, with entities)
>
> - PublishingService (JDO implementation, with entities)
>
> - ApplicationSettingsServiceRW (JDO implementation, with entities)
> - UserSettingsServiceRW (JDO implementation, with entities)
>
> - ClockService (applib implementation)
> - QueryResultsCache (applib implementation)
> - Scratchpad (applib implementation)
>
> - MementoService (core-runtime implementation)
> - BookmarkService (core-metamodel implementation)
> - XmlSnapshotService (core-runtime)
> - EventBus (core-runtime implementation)
> - ClassDiscoveryService (applib implementation,
> +optional org.reflections dependency)
> - WrapperFactory (core-wrapper)
> - DeveloperUtilitiesService (core-metamodel implementation)
>
> Extended the idea of the Shiro security module (4, above), we think it
> makes sense to modularize these other services; probably in five or so
> modules in line with the grouping shown above. That way developers could
> bring in a dependency to the services that they require, and ignore the
> others.
>
>
> 6. Profile Store
>
> The profile store is a component of the framework that is not supported by
> either the Wicket or Restful Objects viewers, but whose functionality is
> broadly superceded by the UserSettingsService.
>
>
> When the UI becomes user-configurable (re-arranged, pallete change,
> etc) this should be demo'd.
>
> Where are user preferences (e.g. UI language, timezone, etc) currently
> stored? Do we have demo code?
>
> In line with simplification (1) we'll retire this component.
>
>
> 7. Restful APIs
>
> The Restful Objects viewer implements the Restful Objects spec [2] and
> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>
>
> 8. Wicket Viewer
>
> We intend to continue developing the Wicket viewer. One part of its
> development will be to re-implement its components to use Wicket-Bootstrap
> [5]; this will make it easier for its look-n-feel to be customised.
>
> We will also probably rename it. "Wicket" is merely the implementation
> technology; its name should represent what it's role is. Possible names
> are the "default viewer", or the "standard viewer" (preferences?
> alternatives?)
>
>
> Thinking about it further, I would probably prefer to keep "Wicket" in the
> name somewhere, as the viewer *is* dependent on Wicket, and those
> who wish to extend (I want to add some additional view components),
> need to know Wicket. But I guess that other names may also be more
> appropriate..
>
>
>
> 11. Better documentation, better website.
>
> Probably every open source project would wish for better documentation and
> examples; we are no different, and we intend to keep improving the docs and
> providing examples of usage.
>
> On the homepage one idea is to make Isis' value proposition more obvious.
> We intend to distinguish our audience, though; what a business person
> wants to know about is different from what a techie wants. So we will
> provide different material for each to consume.
>
> For a bit of interest/originality, Maurizio has offered to develop some
> goanimate [6] cartoon videos; he has used these with some success in his
> own software development company. Right now I am working on some scripts
> to be developed; one 2-minute business-focused one, and a number (3 or 4)
> of 2-minute technicaly focussed ones.
>
> Also, I am aware that much of the materials were written by me and all of
> the screencasts have my voice on them. But there should be other voices
> present on the website; Isis isn't a one-man show and visitors to the
> website shouldn't get that impression.
>
>
> I agree and will try and step in more, here.
>
> 13. Conferences, articles, podcasts
>
> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
> EU in Hungary [7], and in general try to do a few more sessions.
>
> I have also promised an 500-word blog post for Zeroturnaround to advertise
> our JRebel integration.
>
> And, it'd also be good to do some podcasts sessions; I am sure they are
> several looking for new people to talk with.
>
>
> I'll be in touch later for ideas for ApacheCon EU and other opportunities.
>
> Don't forget about opportunities to show off Isis in "rapid app" dev
> competitions. Jeroen, you mentioned one in the Netherlands??
> Perhaps Isis can become the disruptive change from a surprising
> direction!
>
>
> ~~~
> OK, I think that's it.
>
> As I say, for those who were in Milan, please amplify/expand/correct. For
> everyone else, your comments/thoughts are welcome.
>
> Cheers
> Dan
> Apache Isis PMC Chair
>
>
>
> :)
>
> Unless otherwise indicated, I agree with the proposals.. ;)
>
> Regards,
> Kevin
>
>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> <contactenos.html.gif> 902 900 231 / 620 267 520
> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou
>
> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou
>
> <blog.png> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>
> <gesconsultor_logo_blue_email.png>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
> 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
>
>
>
>
>
>
>
> *Óscar Bou Bou*
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> 902 900 231 / 620 267 520
> http://www.twitter.com/oscarbou
>
> http://es.linkedin.com/in/oscarbou
>
> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
> 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
>
>
>
>
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi, David!
I see more parallelism with the "micro-services architecture", but inside the business domain [1].
Each object could be considered as equivalent to a behavioral entity (like a "service") accessed (published to the other domain entities) under a well-defined interface (the Isis Object Specification, comprised of properties and actions) that fully encapsulates all business logic, avoiding pitfalls, errors, etc. when directly invoking methods without taking into account all associated business logic.
[1] http://martinfowler.com/articles/microservices.html
Regards,
Oscar
El 16/06/2014, a las 13:14, David Tildesley <da...@yahoo.co.nz> escribió:
> Hi Oscar,
>
> I have a question about this idea: Is this not akin to the old EJB (1.x/2.x) "component" concept and therefore a move away from "POJO". A POJO domain model that is loosely coupled for maintainability would use design principles such as Demeter's Law (in particular). The question for you therefore is how would you preserve this design principle?
>
> I agree that the domain layer must protect itself and not depend on any UI layer to do that protection. However is it necessary to go to that extent within the domain layer itself?
>
> However, on the same theme - there is currently a reliance on the generated viewer to implement domain object annotated business logic "guards" for setters in particular. Anything from the UI layer that is not part of the generated viewer that calls the domain layer directly (e.g a view object), effectively bypass these guards and I think this is not right. Your suggestion would solve that problem.
>
> So maybe there is a way of introducing this automated wrapper without at the same time turning ISIS into EJB 1.x/2.x? If that is possible then you have my vote.
>
> I think the main threat to the (fully contained business logic) rich domain layer is actually the misuse of the view object - particularly when combined with the issue that the framework makes it necessary to use the view object in lieu of a non-dm-persisted domain object. Don't get me wrong - I see the view object as essential for (in particular) a web viewer in order to build an user friendly UI.
>
> Kind Regards,
> David.
>
>
>
>
>
> On Saturday, 14 June 2014 9:56 PM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>
>
> Just one more thing for the roadmap.
>
> We also mentioned on IsisCon (but also I can remember Dan mentioned something similar on the mailing list as his intention for version 2) that domain objects (domain entity instances) could be "wrapped by default", acting as a "container" of the business logic and ensuring it was preserved by default when invoked from other domain objects.
>
> That would imply that, for example, a call to:
>
> domainObject.someAction(x, y, z);
>
> Would always validate the parameters, choices, etc. and all other associated business logic.
>
> And that a call to:
>
> domainObject.setXXX(x);
>
> would always preserve the business rules implemented on the modifyXXX, validateXXX, clearXXX methods, for example.
>
>
> It has many advantages, for example for testing. It really avoids "programming errors" originated by invoking in the domain actions or setters without taking into account validations or business logic inside the modifyXXX methods, for example.
>
> In our case, nearly all our actions are setter invocations are made through:
>
> this.wrap(domainObject).setXXX, this.wrap(domainObject).actionXXX
>
> or, if they're hidden or disabled,
>
> this.wrapSkipRules(domainObject).setXXX, this.wrapSkipRules(domainObject).actionXXX
>
>
> That strategy of "always wrapping" helps REALLY A LOT while debugging.
>
>
> Sincerelly, this was one of our expectations when we arrived to Isis. And we don't know of any other platform that always tries to preserve all business logic.
>
>
> Thay would imply that Isis would act as a "true" hexagonal architecture when the UI just is another port-adapter, with exactly the same behavior as any other invokation from any other port-adapter, and what it's most exclusive of any platform, doing the same with intra-domain invocations.
>
> Any thoughts?
>
>
> Thanks,
>
> Oscar
>
>
>
>
>
>
>
> El 10/06/2014, a las 21:28, Kevin Meyer - KMZ <ke...@kmz.co.za> escribió:
>
>> Quick immediate reply:
>>
>>> ~~~~~
>>> Some of the ideas that follow build upon each other, some are independent
>>> of each other. I won't attempt to outline an exact timetable, but you can
>>> see that some of this work could be performed in parallel. For example,
>>> improved Shiro support (4) could be done at the same time as simplifying
>>> the framework (1).
>>>
>>> 1. Simplifying the framework
>>>
>>> * Isis will run only as a server-side webapp. This implies that the DnD
>>> viewer will be retired. This will also enable Isis' bootstrapping to be
>>> simplified and rationalized.
>>
>> By the way: A DnD viewer can be later re-implemented, if so desired.
>>
>>> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
>>> ObjectStore implementation then made part of core. The other ObjectStore
>>> implementations will be retired. This step in particular should enable
>>> considerable simplification
>>
>> As described, this is a temporary state, with a future plan to later
>> abstract out a new Objectstore API to support other objectstore
>> frameworks. See below.
>>
>>> * Isis will adopt the Shiro authentication classes rather than define its
>>> own. This will also allow authentication to be moved into the core.
>>
>> I have no comment :)
>>
>>> 3. Alternative Persistence providers
>>>
>>> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
>>> object tracking) and on DataNucleus in particular, the next step in the
>>> roadmap is to re-introduce pluggability so that developers can use other
>>> ORM implementations; particularly for the JPA API. Being an Apache product
>>> means that we cannot dependent on certain licenses, but we certainly
>>> provide alternative implemenation based on either Apache OpenJPA, or on
>>> EclipseLink (the old TopLink product).
>>>
>>> We might also look to provide an implementation for the market leader,
>>> namely Hibernate. However, because Hibernate is LGPL, this implementation
>>> would need to live outside of Apache Isis' formal codebase, eg in the
>>> apache-extras.org site or perhaps just likely on github.
>>>
>>>
>>> 4. Improved support for Shiro
>>>
>>> We've noticed a number of users wanting to use our Shiro integration, with
>>> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
>>> build Isis entities that map onto the Shiro concepts (users, roles,
>>> permissions). In this way Isis could provide a self-contained security
>>> subsystem for managing users "out-of-the-box".
>>>
>>> We anticipate delivering this as an optional module that could be included
>>> as necessary.
>>>
>>> An extension of this is to deliver a standalone application built with Isis
>>> for administrating the users/roles/permissions for any application
>>> configured to use the Shiro JDBC realm (not just an Isis application).
>>
>> The discussions I've had and heard regarding other application
>> development suites lead me to believe that this would be an extremely
>> useful add-on! I'd almost like to request that this be the first thing
>> worked on, before any of the fundamental changes listed above.
>>
>> But that's just my wish.
>>
>> (I'd like to demo that Isis can also support RBAC, out-of-the-box).
>>
>>>
>>>
>>> 5. Other Reusable modules
>>>
>>> In the applib there are a number of services; some depend on parts of the
>>> Isis runtime; some do not. Some have their own entities, some do not:
>>>
>>> - CommandContext (applib implementation)
>>> - BackgroundService (core-runtime implementation)
>>> - BackgroundCommandService (JDO implementation, with entities)
>>> - AuditingService3 (JDO implementation, with entities)
>>>
>>> - PublishingService (JDO implementation, with entities)
>>>
>>> - ApplicationSettingsServiceRW (JDO implementation, with entities)
>>> - UserSettingsServiceRW (JDO implementation, with entities)
>>>
>>> - ClockService (applib implementation)
>>> - QueryResultsCache (applib implementation)
>>> - Scratchpad (applib implementation)
>>>
>>> - MementoService (core-runtime implementation)
>>> - BookmarkService (core-metamodel implementation)
>>> - XmlSnapshotService (core-runtime)
>>> - EventBus (core-runtime implementation)
>>> - ClassDiscoveryService (applib implementation,
>>> +optional org.reflections dependency)
>>> - WrapperFactory (core-wrapper)
>>> - DeveloperUtilitiesService (core-metamodel implementation)
>>>
>>> Extended the idea of the Shiro security module (4, above), we think it
>>> makes sense to modularize these other services; probably in five or so
>>> modules in line with the grouping shown above. That way developers could
>>> bring in a dependency to the services that they require, and ignore the
>>> others.
>>>
>>>
>>> 6. Profile Store
>>>
>>> The profile store is a component of the framework that is not supported by
>>> either the Wicket or Restful Objects viewers, but whose functionality is
>>> broadly superceded by the UserSettingsService.
>>
>> When the UI becomes user-configurable (re-arranged, pallete change,
>> etc) this should be demo'd.
>>
>> Where are user preferences (e.g. UI language, timezone, etc) currently
>> stored? Do we have demo code?
>>
>>> In line with simplification (1) we'll retire this component.
>>>
>>>
>>> 7. Restful APIs
>>>
>>> The Restful Objects viewer implements the Restful Objects spec [2] and
>>> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>>>
>>>
>>> 8. Wicket Viewer
>>>
>>> We intend to continue developing the Wicket viewer. One part of its
>>> development will be to re-implement its components to use Wicket-Bootstrap
>>> [5]; this will make it easier for its look-n-feel to be customised.
>>>
>>> We will also probably rename it. "Wicket" is merely the implementation
>>> technology; its name should represent what it's role is. Possible names
>>> are the "default viewer", or the "standard viewer" (preferences?
>>> alternatives?)
>>
>> Thinking about it further, I would probably prefer to keep "Wicket" in the
>> name somewhere, as the viewer *is* dependent on Wicket, and those
>> who wish to extend (I want to add some additional view components),
>> need to know Wicket. But I guess that other names may also be more
>> appropriate..
>>
>>
>>>
>>> 11. Better documentation, better website.
>>>
>>> Probably every open source project would wish for better documentation and
>>> examples; we are no different, and we intend to keep improving the docs and
>>> providing examples of usage.
>>>
>>> On the homepage one idea is to make Isis' value proposition more obvious.
>>> We intend to distinguish our audience, though; what a business person
>>> wants to know about is different from what a techie wants. So we will
>>> provide different material for each to consume.
>>>
>>> For a bit of interest/originality, Maurizio has offered to develop some
>>> goanimate [6] cartoon videos; he has used these with some success in his
>>> own software development company. Right now I am working on some scripts
>>> to be developed; one 2-minute business-focused one, and a number (3 or 4)
>>> of 2-minute technicaly focussed ones.
>>>
>>> Also, I am aware that much of the materials were written by me and all of
>>> the screencasts have my voice on them. But there should be other voices
>>> present on the website; Isis isn't a one-man show and visitors to the
>>> website shouldn't get that impression.
>>
>> I agree and will try and step in more, here.
>>
>>> 13. Conferences, articles, podcasts
>>>
>>> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
>>> EU in Hungary [7], and in general try to do a few more sessions.
>>>
>>> I have also promised an 500-word blog post for Zeroturnaround to advertise
>>> our JRebel integration.
>>>
>>> And, it'd also be good to do some podcasts sessions; I am sure they are
>>> several looking for new people to talk with.
>>
>> I'll be in touch later for ideas for ApacheCon EU and other opportunities.
>>
>> Don't forget about opportunities to show off Isis in "rapid app" dev
>> competitions. Jeroen, you mentioned one in the Netherlands??
>> Perhaps Isis can become the disruptive change from a surprising
>> direction!
>>
>>>
>>> ~~~
>>> OK, I think that's it.
>>>
>>> As I say, for those who were in Milan, please amplify/expand/correct. For
>>> everyone else, your comments/thoughts are welcome.
>>>
>>> Cheers
>>> Dan
>>> Apache Isis PMC Chair
>>
>>
>> :)
>>
>> Unless otherwise indicated, I agree with the proposals.. ;)
>>
>> Regards,
>> Kevin
>>
>>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> <contactenos.html.gif> 902 900 231 / 620 267 520
> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou
>
> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou
>
> <blog.png> http://www.GesConsultor.com
>
> <gesconsultor_logo_blue_email.png>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
>
>
>
>
>
>
>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 16 June 2014 12:14, David Tildesley <da...@yahoo.co.nz> wrote:
>
> I agree that the domain layer must protect itself and not depend on any UI
> layer to do that protection. However is it necessary to go to that extent
> within the domain layer itself?
>
>
I see this in terms of trust boundaries. In a highly modularized domain
(using "module" in the DDD sense) it could be that - even though those
modules are deployed together - each entity would want to ensure that it's
preconditions/invariants are maintained.
Where Isis leaks a bit is that the wrapped objects the domain model have
three different ways to indicate that a precondition/invariant has been
violated: by throwing a hidden exception or a disabled exception or an
invalid exception. But I see those merely as "hints"; fundamentally these
are all subclasses of a common subclass (InteractionException).
What Oscar and his team report is that having no trust boundaries - ie
always wrapping - has yielded benefits. This might be in part to do with
team structure and process, or it might be to do with the particulars of
their domain. If it has worked for them, then fair enough I say.
But what we probably do need to do is to provide better guidance as to the
pros and cons of the feature; and threads like this help figure out what
that should be :-)
> However, on the same theme - there is currently a reliance on the
> generated viewer to implement domain object annotated business logic
> "guards" for setters in particular. Anything from the UI layer that is not
> part of the generated viewer that calls the domain layer directly (e.g a
> view object), effectively bypass these guards and I think this is not
> right. Your suggestion would solve that problem.
>
>
This might be a reasonable half-way house for many: that view model objects
(in the "application" layer) should always wrap calls to the domain model
(in the domain layer). But again this is just a reflection of trust
boundaries - an application layer is even less likely to be trusted by the
domain layer than some other domain object.
> So maybe there is a way of introducing this automated wrapper without at
> the same time turning ISIS into EJB 1.x/2.x? If that is possible then you
> have my vote.
>
> This may be moot, because technically, I'm not sure it is possible to do
automatically. The issue is that JDO/DN does not provide a suitable
callback for lazily-loaded objects to get wrapped. (But I've sent an email
to Andy Jefferson to see if I'm wrong about any of that).
> I think the main threat to the (fully contained business logic) rich
> domain layer is actually the misuse of the view object - particularly when
> combined with the issue that the framework makes it necessary to use the
> view object in lieu of a non-dm-persisted domain object. Don't get me
> wrong - I see the view object as essential for (in particular) a web
> viewer in order to build an user friendly UI.
>
>
I agree with you... misuse of view models can lead to anaemic domain models.
Thx
Dan
> Kind Regards,
> David.
>
>
>
>
>
> On Saturday, 14 June 2014 9:56 PM, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com> wrote:
>
>
> Just one more thing for the roadmap.
>
> We also mentioned on IsisCon (but also I can remember Dan mentioned
> something similar on the mailing list as his intention for version 2) that
> domain objects (domain entity instances) could be "wrapped by default",
> acting as a "container" of the business logic and ensuring it was preserved
> by default when invoked from other domain objects.
>
> That would imply that, for example, a call to:
>
> domainObject.someAction(x, y, z);
>
> Would always validate the parameters, choices, etc. and all other
> associated business logic.
>
> And that a call to:
>
> domainObject.setXXX(x);
>
> would always preserve the business rules implemented on the modifyXXX,
> validateXXX, clearXXX methods, for example.
>
>
> It has many advantages, for example for testing. It really avoids
> "programming errors" originated by invoking in the domain actions or
> setters without taking into account validations or business logic inside
> the modifyXXX methods, for example.
>
> In our case, nearly all our actions are setter invocations are made
> through:
>
> this.wrap(domainObject).setXXX, this.wrap(domainObject).actionXXX
>
> or, if they're hidden or disabled,
>
> this.wrapSkipRules(domainObject).setXXX,
> this.wrapSkipRules(domainObject).actionXXX
>
>
> That strategy of "always wrapping" helps REALLY A LOT while debugging.
>
>
> Sincerelly, this was one of our expectations when we arrived to Isis. And
> we don't know of any other platform that always tries to preserve all
> business logic.
>
>
> Thay would imply that Isis would act as a "true" hexagonal architecture
> when the UI just is another port-adapter, with exactly the same behavior as
> any other invokation from any other port-adapter, and what it's most
> exclusive of any platform, doing the same with intra-domain invocations.
>
> Any thoughts?
>
>
> Thanks,
>
> Oscar
>
>
>
>
>
>
>
> El 10/06/2014, a las 21:28, Kevin Meyer - KMZ <ke...@kmz.co.za> escribió:
>
> Quick immediate reply:
>
> ~~~~~
> Some of the ideas that follow build upon each other, some are independent
> of each other. I won't attempt to outline an exact timetable, but you can
> see that some of this work could be performed in parallel. For example,
> improved Shiro support (4) could be done at the same time as simplifying
> the framework (1).
>
> 1. Simplifying the framework
>
> * Isis will run only as a server-side webapp. This implies that the DnD
> viewer will be retired. This will also enable Isis' bootstrapping to be
> simplified and rationalized.
>
>
> By the way: A DnD viewer can be later re-implemented, if so desired.
>
> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> ObjectStore implementation then made part of core. The other ObjectStore
> implementations will be retired. This step in particular should enable
> considerable simplification
>
>
> As described, this is a temporary state, with a future plan to later
> abstract out a new Objectstore API to support other objectstore
> frameworks. See below.
>
> * Isis will adopt the Shiro authentication classes rather than define its
> own. This will also allow authentication to be moved into the core.
>
>
> I have no comment :)
>
> 3. Alternative Persistence providers
>
> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> object tracking) and on DataNucleus in particular, the next step in the
> roadmap is to re-introduce pluggability so that developers can use other
> ORM implementations; particularly for the JPA API. Being an Apache product
> means that we cannot dependent on certain licenses, but we certainly
> provide alternative implemenation based on either Apache OpenJPA, or on
> EclipseLink (the old TopLink product).
>
> We might also look to provide an implementation for the market leader,
> namely Hibernate. However, because Hibernate is LGPL, this implementation
> would need to live outside of Apache Isis' formal codebase, eg in the
> apache-extras.org site or perhaps just likely on github.
>
>
> 4. Improved support for Shiro
>
> We've noticed a number of users wanting to use our Shiro integration, with
> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
> build Isis entities that map onto the Shiro concepts (users, roles,
> permissions). In this way Isis could provide a self-contained security
> subsystem for managing users "out-of-the-box".
>
> We anticipate delivering this as an optional module that could be included
> as necessary.
>
> An extension of this is to deliver a standalone application built with Isis
> for administrating the users/roles/permissions for any application
> configured to use the Shiro JDBC realm (not just an Isis application).
>
>
> The discussions I've had and heard regarding other application
> development suites lead me to believe that this would be an extremely
> useful add-on! I'd almost like to request that this be the first thing
> worked on, before any of the fundamental changes listed above.
>
> But that's just my wish.
>
> (I'd like to demo that Isis can also support RBAC, out-of-the-box).
>
>
>
> 5. Other Reusable modules
>
> In the applib there are a number of services; some depend on parts of the
> Isis runtime; some do not. Some have their own entities, some do not:
>
> - CommandContext (applib implementation)
> - BackgroundService (core-runtime implementation)
> - BackgroundCommandService (JDO implementation, with entities)
> - AuditingService3 (JDO implementation, with entities)
>
> - PublishingService (JDO implementation, with entities)
>
> - ApplicationSettingsServiceRW (JDO implementation, with entities)
> - UserSettingsServiceRW (JDO implementation, with entities)
>
> - ClockService (applib implementation)
> - QueryResultsCache (applib implementation)
> - Scratchpad (applib implementation)
>
> - MementoService (core-runtime implementation)
> - BookmarkService (core-metamodel implementation)
> - XmlSnapshotService (core-runtime)
> - EventBus (core-runtime implementation)
> - ClassDiscoveryService (applib implementation,
> +optional org.reflections dependency)
> - WrapperFactory (core-wrapper)
> - DeveloperUtilitiesService (core-metamodel implementation)
>
> Extended the idea of the Shiro security module (4, above), we think it
> makes sense to modularize these other services; probably in five or so
> modules in line with the grouping shown above. That way developers could
> bring in a dependency to the services that they require, and ignore the
> others.
>
>
> 6. Profile Store
>
> The profile store is a component of the framework that is not supported by
> either the Wicket or Restful Objects viewers, but whose functionality is
> broadly superceded by the UserSettingsService.
>
>
> When the UI becomes user-configurable (re-arranged, pallete change,
> etc) this should be demo'd.
>
> Where are user preferences (e.g. UI language, timezone, etc) currently
> stored? Do we have demo code?
>
> In line with simplification (1) we'll retire this component.
>
>
> 7. Restful APIs
>
> The Restful Objects viewer implements the Restful Objects spec [2] and
> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>
>
> 8. Wicket Viewer
>
> We intend to continue developing the Wicket viewer. One part of its
> development will be to re-implement its components to use Wicket-Bootstrap
> [5]; this will make it easier for its look-n-feel to be customised.
>
> We will also probably rename it. "Wicket" is merely the implementation
> technology; its name should represent what it's role is. Possible names
> are the "default viewer", or the "standard viewer" (preferences?
> alternatives?)
>
>
> Thinking about it further, I would probably prefer to keep "Wicket" in the
> name somewhere, as the viewer *is* dependent on Wicket, and those
> who wish to extend (I want to add some additional view components),
> need to know Wicket. But I guess that other names may also be more
> appropriate..
>
>
>
> 11. Better documentation, better website.
>
> Probably every open source project would wish for better documentation and
> examples; we are no different, and we intend to keep improving the docs and
> providing examples of usage.
>
> On the homepage one idea is to make Isis' value proposition more obvious.
> We intend to distinguish our audience, though; what a business person
> wants to know about is different from what a techie wants. So we will
> provide different material for each to consume.
>
> For a bit of interest/originality, Maurizio has offered to develop some
> goanimate [6] cartoon videos; he has used these with some success in his
> own software development company. Right now I am working on some scripts
> to be developed; one 2-minute business-focused one, and a number (3 or 4)
> of 2-minute technicaly focussed ones.
>
> Also, I am aware that much of the materials were written by me and all of
> the screencasts have my voice on them. But there should be other voices
> present on the website; Isis isn't a one-man show and visitors to the
> website shouldn't get that impression.
>
>
> I agree and will try and step in more, here.
>
> 13. Conferences, articles, podcasts
>
> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
> EU in Hungary [7], and in general try to do a few more sessions.
>
> I have also promised an 500-word blog post for Zeroturnaround to advertise
> our JRebel integration.
>
> And, it'd also be good to do some podcasts sessions; I am sure they are
> several looking for new people to talk with.
>
>
> I'll be in touch later for ideas for ApacheCon EU and other opportunities.
>
> Don't forget about opportunities to show off Isis in "rapid app" dev
> competitions. Jeroen, you mentioned one in the Netherlands??
> Perhaps Isis can become the disruptive change from a surprising
> direction!
>
>
> ~~~
> OK, I think that's it.
>
> As I say, for those who were in Milan, please amplify/expand/correct. For
> everyone else, your comments/thoughts are welcome.
>
> Cheers
> Dan
> Apache Isis PMC Chair
>
>
>
> :)
>
> Unless otherwise indicated, I agree with the proposals.. ;)
>
> Regards,
> Kevin
>
>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> 902 900 231 / 620 267 520
> http://www.twitter.com/oscarbou
>
> http://es.linkedin.com/in/oscarbou
>
> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
> 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
>
>
>
>
>
>
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Oscar,
I have a question about this idea: Is this not akin to the old EJB (1.x/2.x) "component" concept and therefore a move away from "POJO". A POJO domain model that is loosely coupled for maintainability would use design principles such as Demeter's Law (in particular). The question for you therefore is how would you preserve this design principle?
I agree that the domain layer must protect itself and not depend on any UI layer to do that protection. However is it necessary to go to that extent within the domain layer itself?
However, on the same theme - there is currently a reliance on the generated viewer to implement domain object annotated business logic "guards" for setters in particular. Anything from the UI layer that is not part of the generated viewer that calls the domain layer directly (e.g a view object), effectively bypass these guards and I think this is not right. Your suggestion would solve that problem.
So maybe there is a way of introducing this automated wrapper without at the same time turning ISIS into EJB 1.x/2.x? If that is possible then you have my vote.
I think the main threat to the (fully contained business logic) rich domain layer is actually the misuse of the view object - particularly when combined with the issue that the framework makes it necessary to use the view object in lieu of a non-dm-persisted domain object. Don't get me wrong - I see the view object as essential for (in particular) a web viewer in order to build an user friendly UI.
Kind Regards,
David.
On Saturday, 14 June 2014 9:56 PM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
Just one more thing for the roadmap.
We also mentioned on IsisCon (but also I can remember Dan mentioned something similar on the mailing list as his intention for version 2) that domain objects (domain entity instances) could be "wrapped by default", acting as a "container" of the business logic and ensuring it was preserved by default when invoked from other domain objects.
That would imply that, for example, a call to:
domainObject.someAction(x, y, z);
Would always validate the parameters, choices, etc. and all other associated business logic.
And that a call to:
domainObject.setXXX(x);
would always preserve the business rules implemented on the modifyXXX, validateXXX, clearXXX methods, for example.
It has many advantages, for example for testing. It really avoids "programming errors" originated by invoking in the domain actions or setters without taking into account validations or business logic inside the modifyXXX methods, for example.
In our case, nearly all our actions are setter invocations are made through:
this.wrap(domainObject).setXXX, this.wrap(domainObject).actionXXX
or, if they're hidden or disabled,
this.wrapSkipRules(domainObject).setXXX, this.wrapSkipRules(domainObject).actionXXX
That strategy of "always wrapping" helps REALLY A LOT while debugging.
Sincerelly, this was one of our expectations when we arrived to Isis. And we don't know of any other platform that always tries to preserve all business logic.
Thay would imply that Isis would act as a "true" hexagonal architecture when the UI just is another port-adapter, with exactly the same behavior as any other invokation from any other port-adapter, and what it's most exclusive of any platform, doing the same with intra-domain invocations.
Any thoughts?
Thanks,
Oscar
El 10/06/2014, a las 21:28, Kevin Meyer - KMZ <ke...@kmz.co.za> escribió:
Quick immediate reply:
>
>
>~~~~~
>>Some of the ideas that follow build upon each other, some are independent
>>of each other. I won't attempt to outline an exact timetable, but you can
>>see that some of this work could be performed in parallel. For example,
>>improved Shiro support (4) could be done at the same time as simplifying
>>the framework (1).
>>
>>1. Simplifying the framework
>>
>>* Isis will run only as a server-side webapp. This implies that the DnD
>>viewer will be retired. This will also enable Isis' bootstrapping to be
>>simplified and rationalized.
>>
>By the way: A DnD viewer can be later re-implemented, if so desired.
>
>
>* Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
>>ObjectStore implementation then made part of core. The other ObjectStore
>>implementations will be retired. This step in particular should enable
>>considerable simplification
>>
>As described, this is a temporary state, with a future plan to later
>abstract out a new Objectstore API to support other objectstore
>frameworks. See below.
>
>
>* Isis will adopt the Shiro authentication classes rather than define its
>>own. This will also allow authentication to be moved into the core.
>>
>I have no comment :)
>
>
>3. Alternative Persistence providers
>>
>>Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
>>object tracking) and on DataNucleus in particular, the next step in the
>>roadmap is to re-introduce pluggability so that developers can use other
>>ORM implementations; particularly for the JPA API. Being an Apache product
>>means that we cannot dependent on certain licenses, but we certainly
>>provide alternative implemenation based on either Apache OpenJPA, or on
>>EclipseLink (the old TopLink product).
>>
>>We might also look to provide an implementation for the market leader,
>>namely Hibernate. However, because Hibernate is LGPL, this implementation
>>would need to live outside of Apache Isis' formal codebase, eg in the
>>apache-extras.org site or perhaps just likely on github.
>>
>>
>>4. Improved support for Shiro
>>
>>We've noticed a number of users wanting to use our Shiro integration, with
>>Shiro configured to use a JDBC Realm. It ought to be relatively simple to
>>build Isis entities that map onto the Shiro concepts (users, roles,
>>permissions). In this way Isis could provide a self-contained security
>>subsystem for managing users "out-of-the-box".
>>
>>We anticipate delivering this as an optional module that could be included
>>as necessary.
>>
>>An extension of this is to deliver a standalone application built with Isis
>>for administrating the users/roles/permissions for any application
>>configured to use the Shiro JDBC realm (not just an Isis application).
>>
>The discussions I've had and heard regarding other application
>development suites lead me to believe that this would be an extremely
>useful add-on! I'd almost like to request that this be the first thing
>worked on, before any of the fundamental changes listed above.
>
>But that's just my wish.
>
>(I'd like to demo that Isis can also support RBAC, out-of-the-box).
>
>
>
>>
>>5. Other Reusable modules
>>
>>In the applib there are a number of services; some depend on parts of the
>>Isis runtime; some do not. Some have their own entities, some do not:
>>
>>- CommandContext (applib implementation)
>>- BackgroundService (core-runtime implementation)
>>- BackgroundCommandService (JDO implementation, with entities)
>>- AuditingService3 (JDO implementation, with entities)
>>
>>- PublishingService (JDO implementation, with entities)
>>
>>- ApplicationSettingsServiceRW (JDO implementation, with entities)
>>- UserSettingsServiceRW (JDO implementation, with entities)
>>
>>- ClockService (applib implementation)
>>- QueryResultsCache (applib implementation)
>>- Scratchpad (applib implementation)
>>
>>- MementoService (core-runtime implementation)
>>- BookmarkService (core-metamodel implementation)
>>- XmlSnapshotService (core-runtime)
>>- EventBus (core-runtime implementation)
>>- ClassDiscoveryService (applib implementation,
>> +optional org.reflections dependency)
>>- WrapperFactory (core-wrapper)
>>- DeveloperUtilitiesService (core-metamodel implementation)
>>
>>Extended the idea of the Shiro security module (4, above), we think it
>>makes sense to modularize these other services; probably in five or so
>>modules in line with the grouping shown above. That way developers could
>>bring in a dependency to the services that they require, and ignore the
>>others.
>>
>>
>>6. Profile Store
>>
>>The profile store is a component of the framework that is not supported by
>>either the Wicket or Restful Objects viewers, but whose functionality is
>>broadly superceded by the UserSettingsService.
>>
>When the UI becomes user-configurable (re-arranged, pallete change,
>etc) this should be demo'd.
>
>Where are user preferences (e.g. UI language, timezone, etc) currently
>stored? Do we have demo code?
>
>
>In line with simplification (1) we'll retire this component.
>>
>>
>>7. Restful APIs
>>
>>The Restful Objects viewer implements the Restful Objects spec [2] and
>>provides a full REST Hypermedia API to the Isis metamodel and runtime.
>>
>>
>>8. Wicket Viewer
>>
>>We intend to continue developing the Wicket viewer. One part of its
>>development will be to re-implement its components to use Wicket-Bootstrap
>>[5]; this will make it easier for its look-n-feel to be customised.
>>
>>We will also probably rename it. "Wicket" is merely the implementation
>>technology; its name should represent what it's role is. Possible names
>>are the "default viewer", or the "standard viewer" (preferences?
>>alternatives?)
>>
>Thinking about it further, I would probably prefer to keep "Wicket" in the
>name somewhere, as the viewer *is* dependent on Wicket, and those
>who wish to extend (I want to add some additional view components),
>need to know Wicket. But I guess that other names may also be more
>appropriate..
>
>
>
>
>>11. Better documentation, better website.
>>
>>Probably every open source project would wish for better documentation and
>>examples; we are no different, and we intend to keep improving the docs and
>>providing examples of usage.
>>
>>On the homepage one idea is to make Isis' value proposition more obvious.
>>We intend to distinguish our audience, though; what a business person
>>wants to know about is different from what a techie wants. So we will
>>provide different material for each to consume.
>>
>>For a bit of interest/originality, Maurizio has offered to develop some
>>goanimate [6] cartoon videos; he has used these with some success in his
>>own software development company. Right now I am working on some scripts
>>to be developed; one 2-minute business-focused one, and a number (3 or 4)
>>of 2-minute technicaly focussed ones.
>>
>>Also, I am aware that much of the materials were written by me and all of
>>the screencasts have my voice on them. But there should be other voices
>>present on the website; Isis isn't a one-man show and visitors to the
>>website shouldn't get that impression.
>>
>I agree and will try and step in more, here.
>
>
>13. Conferences, articles, podcasts
>>
>>Jeroen and I are intending to submitting a couple of sessions to ApacheCon
>>EU in Hungary [7], and in general try to do a few more sessions.
>>
>>I have also promised an 500-word blog post for Zeroturnaround to advertise
>>our JRebel integration.
>>
>>And, it'd also be good to do some podcasts sessions; I am sure they are
>>several looking for new people to talk with.
>>
>I'll be in touch later for ideas for ApacheCon EU and other opportunities.
>
>Don't forget about opportunities to show off Isis in "rapid app" dev
>competitions. Jeroen, you mentioned one in the Netherlands??
>Perhaps Isis can become the disruptive change from a surprising
>direction!
>
>
>
>>~~~
>>OK, I think that's it.
>>
>>As I say, for those who were in Milan, please amplify/expand/correct. For
>>everyone else, your comments/thoughts are welcome.
>>
>>Cheers
>>Dan
>>Apache Isis PMC Chair
>>
>
>:)
>
>Unless otherwise indicated, I agree with the proposals.. ;)
>
>Regards,
>Kevin
>
>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Just one more thing for the roadmap.
We also mentioned on IsisCon (but also I can remember Dan mentioned something similar on the mailing list as his intention for version 2) that domain objects (domain entity instances) could be "wrapped by default", acting as a "container" of the business logic and ensuring it was preserved by default when invoked from other domain objects.
That would imply that, for example, a call to:
domainObject.someAction(x, y, z);
Would always validate the parameters, choices, etc. and all other associated business logic.
And that a call to:
domainObject.setXXX(x);
would always preserve the business rules implemented on the modifyXXX, validateXXX, clearXXX methods, for example.
It has many advantages, for example for testing. It really avoids "programming errors" originated by invoking in the domain actions or setters without taking into account validations or business logic inside the modifyXXX methods, for example.
In our case, nearly all our actions are setter invocations are made through:
this.wrap(domainObject).setXXX, this.wrap(domainObject).actionXXX
or, if they're hidden or disabled,
this.wrapSkipRules(domainObject).setXXX, this.wrapSkipRules(domainObject).actionXXX
That strategy of "always wrapping" helps REALLY A LOT while debugging.
Sincerelly, this was one of our expectations when we arrived to Isis. And we don't know of any other platform that always tries to preserve all business logic.
Thay would imply that Isis would act as a "true" hexagonal architecture when the UI just is another port-adapter, with exactly the same behavior as any other invokation from any other port-adapter, and what it's most exclusive of any platform, doing the same with intra-domain invocations.
Any thoughts?
Thanks,
Oscar
El 10/06/2014, a las 21:28, Kevin Meyer - KMZ <ke...@kmz.co.za> escribió:
> Quick immediate reply:
>
>> ~~~~~
>> Some of the ideas that follow build upon each other, some are independent
>> of each other. I won't attempt to outline an exact timetable, but you can
>> see that some of this work could be performed in parallel. For example,
>> improved Shiro support (4) could be done at the same time as simplifying
>> the framework (1).
>>
>> 1. Simplifying the framework
>>
>> * Isis will run only as a server-side webapp. This implies that the DnD
>> viewer will be retired. This will also enable Isis' bootstrapping to be
>> simplified and rationalized.
>
> By the way: A DnD viewer can be later re-implemented, if so desired.
>
>> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
>> ObjectStore implementation then made part of core. The other ObjectStore
>> implementations will be retired. This step in particular should enable
>> considerable simplification
>
> As described, this is a temporary state, with a future plan to later
> abstract out a new Objectstore API to support other objectstore
> frameworks. See below.
>
>> * Isis will adopt the Shiro authentication classes rather than define its
>> own. This will also allow authentication to be moved into the core.
>
> I have no comment :)
>
>> 3. Alternative Persistence providers
>>
>> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
>> object tracking) and on DataNucleus in particular, the next step in the
>> roadmap is to re-introduce pluggability so that developers can use other
>> ORM implementations; particularly for the JPA API. Being an Apache product
>> means that we cannot dependent on certain licenses, but we certainly
>> provide alternative implemenation based on either Apache OpenJPA, or on
>> EclipseLink (the old TopLink product).
>>
>> We might also look to provide an implementation for the market leader,
>> namely Hibernate. However, because Hibernate is LGPL, this implementation
>> would need to live outside of Apache Isis' formal codebase, eg in the
>> apache-extras.org site or perhaps just likely on github.
>>
>>
>> 4. Improved support for Shiro
>>
>> We've noticed a number of users wanting to use our Shiro integration, with
>> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
>> build Isis entities that map onto the Shiro concepts (users, roles,
>> permissions). In this way Isis could provide a self-contained security
>> subsystem for managing users "out-of-the-box".
>>
>> We anticipate delivering this as an optional module that could be included
>> as necessary.
>>
>> An extension of this is to deliver a standalone application built with Isis
>> for administrating the users/roles/permissions for any application
>> configured to use the Shiro JDBC realm (not just an Isis application).
>
> The discussions I've had and heard regarding other application
> development suites lead me to believe that this would be an extremely
> useful add-on! I'd almost like to request that this be the first thing
> worked on, before any of the fundamental changes listed above.
>
> But that's just my wish.
>
> (I'd like to demo that Isis can also support RBAC, out-of-the-box).
>
>>
>>
>> 5. Other Reusable modules
>>
>> In the applib there are a number of services; some depend on parts of the
>> Isis runtime; some do not. Some have their own entities, some do not:
>>
>> - CommandContext (applib implementation)
>> - BackgroundService (core-runtime implementation)
>> - BackgroundCommandService (JDO implementation, with entities)
>> - AuditingService3 (JDO implementation, with entities)
>>
>> - PublishingService (JDO implementation, with entities)
>>
>> - ApplicationSettingsServiceRW (JDO implementation, with entities)
>> - UserSettingsServiceRW (JDO implementation, with entities)
>>
>> - ClockService (applib implementation)
>> - QueryResultsCache (applib implementation)
>> - Scratchpad (applib implementation)
>>
>> - MementoService (core-runtime implementation)
>> - BookmarkService (core-metamodel implementation)
>> - XmlSnapshotService (core-runtime)
>> - EventBus (core-runtime implementation)
>> - ClassDiscoveryService (applib implementation,
>> +optional org.reflections dependency)
>> - WrapperFactory (core-wrapper)
>> - DeveloperUtilitiesService (core-metamodel implementation)
>>
>> Extended the idea of the Shiro security module (4, above), we think it
>> makes sense to modularize these other services; probably in five or so
>> modules in line with the grouping shown above. That way developers could
>> bring in a dependency to the services that they require, and ignore the
>> others.
>>
>>
>> 6. Profile Store
>>
>> The profile store is a component of the framework that is not supported by
>> either the Wicket or Restful Objects viewers, but whose functionality is
>> broadly superceded by the UserSettingsService.
>
> When the UI becomes user-configurable (re-arranged, pallete change,
> etc) this should be demo'd.
>
> Where are user preferences (e.g. UI language, timezone, etc) currently
> stored? Do we have demo code?
>
>> In line with simplification (1) we'll retire this component.
>>
>>
>> 7. Restful APIs
>>
>> The Restful Objects viewer implements the Restful Objects spec [2] and
>> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>>
>>
>> 8. Wicket Viewer
>>
>> We intend to continue developing the Wicket viewer. One part of its
>> development will be to re-implement its components to use Wicket-Bootstrap
>> [5]; this will make it easier for its look-n-feel to be customised.
>>
>> We will also probably rename it. "Wicket" is merely the implementation
>> technology; its name should represent what it's role is. Possible names
>> are the "default viewer", or the "standard viewer" (preferences?
>> alternatives?)
>
> Thinking about it further, I would probably prefer to keep "Wicket" in the
> name somewhere, as the viewer *is* dependent on Wicket, and those
> who wish to extend (I want to add some additional view components),
> need to know Wicket. But I guess that other names may also be more
> appropriate..
>
>
>>
>> 11. Better documentation, better website.
>>
>> Probably every open source project would wish for better documentation and
>> examples; we are no different, and we intend to keep improving the docs and
>> providing examples of usage.
>>
>> On the homepage one idea is to make Isis' value proposition more obvious.
>> We intend to distinguish our audience, though; what a business person
>> wants to know about is different from what a techie wants. So we will
>> provide different material for each to consume.
>>
>> For a bit of interest/originality, Maurizio has offered to develop some
>> goanimate [6] cartoon videos; he has used these with some success in his
>> own software development company. Right now I am working on some scripts
>> to be developed; one 2-minute business-focused one, and a number (3 or 4)
>> of 2-minute technicaly focussed ones.
>>
>> Also, I am aware that much of the materials were written by me and all of
>> the screencasts have my voice on them. But there should be other voices
>> present on the website; Isis isn't a one-man show and visitors to the
>> website shouldn't get that impression.
>
> I agree and will try and step in more, here.
>
>> 13. Conferences, articles, podcasts
>>
>> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
>> EU in Hungary [7], and in general try to do a few more sessions.
>>
>> I have also promised an 500-word blog post for Zeroturnaround to advertise
>> our JRebel integration.
>>
>> And, it'd also be good to do some podcasts sessions; I am sure they are
>> several looking for new people to talk with.
>
> I'll be in touch later for ideas for ApacheCon EU and other opportunities.
>
> Don't forget about opportunities to show off Isis in "rapid app" dev
> competitions. Jeroen, you mentioned one in the Netherlands??
> Perhaps Isis can become the disruptive change from a surprising
> direction!
>
>>
>> ~~~
>> OK, I think that's it.
>>
>> As I say, for those who were in Milan, please amplify/expand/correct. For
>> everyone else, your comments/thoughts are welcome.
>>
>> Cheers
>> Dan
>> Apache Isis PMC Chair
>
>
> :)
>
> Unless otherwise indicated, I agree with the proposals.. ;)
>
> Regards,
> Kevin
>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by David Tildesley <da...@yahoo.co.nz>.
Just a thought: I think it would be sensible to optionally (by configuration) allow Shiro-ISIS to "trust" principal asserted either by container authentication or some other servlet-filter based authentication e.g. openAM/SSO) and for Shiro/ISIS to handle the authorisation part as normal.
Regards,
David.
On Friday, 13 June 2014 11:11 PM, Dan Haywood <da...@haywood-associates.co.uk> wrote:
Hi Martin,
On 13 June 2014 09:25, Martin Grigorov <mg...@apache.org> wrote:
> Hi Isis devs,
>
> On Thu, Jun 12, 2014 at 1:14 PM, Dan Haywood <dan@haywood-associates.co.uk
> >
> wrote:
>
> > > > 4. Improved support for Shiro
>
> I have a small doubt here.
> Maybe it is just temporarily but it seems Apache Shiro project has some
> development issues lately.
> Users fill issues at their JIRA and no one addresses them.
> They don't have new committers since 2 years.
> There was a security fix this year but apart from it there is no active
> development for a rather long period of time -
> https://github.com/apache/shiro/commits/1.2.x.
> Les (the main guy) just committed a rather big refactoring in the 2.x
> branch - https://github.com/apache/shiro/commits/2.0-api-design-changes.
>
> So there is a hope for the project, but I don't feel comfortable to
> recommend Shiro to my clients.
> Unfortunately the alternatives are even worse.
>
> Just my 2c.
>
>
Thanks for this, Martin, understand what you're saying.
Even if Shiro hasn't had much work done on it, it could be just that it is
"done" (at least as far as the 1.x codeline is concerned).
Certainly outside of Apache I think that Shiro has a good reputation; as
you say, there's nothing else really out there. So from a marketing
perspective (of Isis) there's no harm in being coupled with Shiro.
Meantime we're trying to figure out what Isis' core responsibility are:
namely being a metamodel and container for domain logic. But Isis isn't
really about the security domain. And certainly I suspect that Shiro's
security classes have had a lot more love and attention than Isis'.
I'll ping Les about his views on the health of Shiro. If he's just done a
big refactoring, that means that he at least is committed to maintaining
the project. And if we were to find issues with either the 1.x or new 2.x
codebase, well, we can always go and contribute over there in the context
of that project. That feels like the right thing to do.
Dan
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Martin,
On 13 June 2014 09:25, Martin Grigorov <mg...@apache.org> wrote:
> Hi Isis devs,
>
> On Thu, Jun 12, 2014 at 1:14 PM, Dan Haywood <dan@haywood-associates.co.uk
> >
> wrote:
>
> > > > 4. Improved support for Shiro
>
> I have a small doubt here.
> Maybe it is just temporarily but it seems Apache Shiro project has some
> development issues lately.
> Users fill issues at their JIRA and no one addresses them.
> They don't have new committers since 2 years.
> There was a security fix this year but apart from it there is no active
> development for a rather long period of time -
> https://github.com/apache/shiro/commits/1.2.x.
> Les (the main guy) just committed a rather big refactoring in the 2.x
> branch - https://github.com/apache/shiro/commits/2.0-api-design-changes.
>
> So there is a hope for the project, but I don't feel comfortable to
> recommend Shiro to my clients.
> Unfortunately the alternatives are even worse.
>
> Just my 2c.
>
>
Thanks for this, Martin, understand what you're saying.
Even if Shiro hasn't had much work done on it, it could be just that it is
"done" (at least as far as the 1.x codeline is concerned).
Certainly outside of Apache I think that Shiro has a good reputation; as
you say, there's nothing else really out there. So from a marketing
perspective (of Isis) there's no harm in being coupled with Shiro.
Meantime we're trying to figure out what Isis' core responsibility are:
namely being a metamodel and container for domain logic. But Isis isn't
really about the security domain. And certainly I suspect that Shiro's
security classes have had a lot more love and attention than Isis'.
I'll ping Les about his views on the health of Shiro. If he's just done a
big refactoring, that means that he at least is committed to maintaining
the project. And if we were to find issues with either the 1.x or new 2.x
codebase, well, we can always go and contribute over there in the context
of that project. That feels like the right thing to do.
Dan
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Martin Grigorov <mg...@apache.org>.
Hi Isis devs,
On Thu, Jun 12, 2014 at 1:14 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Thanks for the comments, Kevin. Within.
>
>
>
> On 10 June 2014 20:28, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
> > >
> > > This implies that the DnD
> > > viewer will be retired.
> >
> > By the way: A DnD viewer can be later re-implemented, if so desired.
> >
> >
> Indeed, probably on of the RO API.
>
> >
>
> > > 4. Improved support for Shiro
> > >
> >
> > The discussions I've had and heard regarding other application
> > development suites lead me to believe that this would be an extremely
> > useful add-on! I'd almost like to request that this be the first thing
> > worked on, before any of the fundamental changes listed above.
> >
> > But that's just my wish.
> >
> >
> Jeroen has already started on this, because Estatio needs a solution here
> too. We'll try to build something that can then be retrofitted into Isis
> "proper", and which plays nicely (somehow) with users/roles being also
> managed in LDAP.
>
I have a small doubt here.
Maybe it is just temporarily but it seems Apache Shiro project has some
development issues lately.
Users fill issues at their JIRA and no one addresses them.
They don't have new committers since 2 years.
There was a security fix this year but apart from it there is no active
development for a rather long period of time -
https://github.com/apache/shiro/commits/1.2.x.
Les (the main guy) just committed a rather big refactoring in the 2.x
branch - https://github.com/apache/shiro/commits/2.0-api-design-changes.
So there is a hope for the project, but I don't feel comfortable to
recommend Shiro to my clients.
Unfortunately the alternatives are even worse.
Just my 2c.
>
>
>
>
> > >
> > > 6. Profile Store
> > >
> > > The profile store is a component of the framework that is not supported
> > by
> > > either the Wicket or Restful Objects viewers, but whose functionality
> is
> > > broadly superceded by the UserSettingsService.
> >
> > When the UI becomes user-configurable (re-arranged, pallete change,
> > etc) this should be demo'd.
> >
> > Where are user preferences (e.g. UI language, timezone, etc) currently
> > stored? Do we have demo code?
> >
> >
> There are two points here... where to store preferences, and how/what
> within Isis should consume them.
>
> For the former, we have the UserSettingsService (part of applib); in the
> JDO applib there is an entity-based implementation,
>
> For the latter, nothing in Isis particularly consumes these. For timezones
> we tend to use LocalDate which gets around the issue to some extent; but
> you are right that the UserProfile class (in the profilestore) does hold
> this Localization class; that needs surfacing out as a first-class concept
> somehow.
>
> So perhaps ProfileStore should live on, but not as a component, but instead
> as a separate service.
>
> In all, I see three related subdomains:
>
> [Shiro security] -> [Isis user profile (i18n etc) service] -> [Isis
> user settings service]
>
> I'll raise a ticket to capture this thinking so far.
>
>
>
>
>
> > >
> > > 8. Wicket Viewer
> > >
> > > We will also probably rename it. "Wicket" is merely the implementation
> > > technology; its name should represent what it's role is. Possible
> names
> > > are the "default viewer", or the "standard viewer" (preferences?
> > > alternatives?)
> >
> > Thinking about it further, I would probably prefer to keep "Wicket" in
> the
> > name somewhere, as the viewer *is* dependent on Wicket, and those
> > who wish to extend (I want to add some additional view components),
> > need to know Wicket. But I guess that other names may also be more
> > appropriate..
> >
> >
> Hmm, perhaps you are right. Not sure. Don't feel very strongly either
> way, really, so maybe the "colloquial" name of Wicket viewer will suffice
> for the foreseeable.
>
>
> > Don't forget about opportunities to show off Isis in "rapid app" dev
> > competitions. Jeroen, you mentioned one in the Netherlands??
> > Perhaps Isis can become the disruptive change from a surprising
> > direction!
> >
> >
> Thanks for the reminder.
>
> Cheers
> Dan
>
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 12 June 2014 12:14, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>> > 6. Profile Store
>>
>> I'll raise a ticket to capture this thinking so far.
>
>
https://issues.apache.org/jira/browse/ISIS-802
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Thanks for the comments, Kevin. Within.
On 10 June 2014 20:28, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
> >
> > This implies that the DnD
> > viewer will be retired.
>
> By the way: A DnD viewer can be later re-implemented, if so desired.
>
>
Indeed, probably on of the RO API.
>
> > 4. Improved support for Shiro
> >
>
> The discussions I've had and heard regarding other application
> development suites lead me to believe that this would be an extremely
> useful add-on! I'd almost like to request that this be the first thing
> worked on, before any of the fundamental changes listed above.
>
> But that's just my wish.
>
>
Jeroen has already started on this, because Estatio needs a solution here
too. We'll try to build something that can then be retrofitted into Isis
"proper", and which plays nicely (somehow) with users/roles being also
managed in LDAP.
> >
> > 6. Profile Store
> >
> > The profile store is a component of the framework that is not supported
> by
> > either the Wicket or Restful Objects viewers, but whose functionality is
> > broadly superceded by the UserSettingsService.
>
> When the UI becomes user-configurable (re-arranged, pallete change,
> etc) this should be demo'd.
>
> Where are user preferences (e.g. UI language, timezone, etc) currently
> stored? Do we have demo code?
>
>
There are two points here... where to store preferences, and how/what
within Isis should consume them.
For the former, we have the UserSettingsService (part of applib); in the
JDO applib there is an entity-based implementation,
For the latter, nothing in Isis particularly consumes these. For timezones
we tend to use LocalDate which gets around the issue to some extent; but
you are right that the UserProfile class (in the profilestore) does hold
this Localization class; that needs surfacing out as a first-class concept
somehow.
So perhaps ProfileStore should live on, but not as a component, but instead
as a separate service.
In all, I see three related subdomains:
[Shiro security] -> [Isis user profile (i18n etc) service] -> [Isis
user settings service]
I'll raise a ticket to capture this thinking so far.
> >
> > 8. Wicket Viewer
> >
> > We will also probably rename it. "Wicket" is merely the implementation
> > technology; its name should represent what it's role is. Possible names
> > are the "default viewer", or the "standard viewer" (preferences?
> > alternatives?)
>
> Thinking about it further, I would probably prefer to keep "Wicket" in the
> name somewhere, as the viewer *is* dependent on Wicket, and those
> who wish to extend (I want to add some additional view components),
> need to know Wicket. But I guess that other names may also be more
> appropriate..
>
>
Hmm, perhaps you are right. Not sure. Don't feel very strongly either
way, really, so maybe the "colloquial" name of Wicket viewer will suffice
for the foreseeable.
> Don't forget about opportunities to show off Isis in "rapid app" dev
> competitions. Jeroen, you mentioned one in the Netherlands??
> Perhaps Isis can become the disruptive change from a surprising
> direction!
>
>
Thanks for the reminder.
Cheers
Dan
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
Quick immediate reply:
> ~~~~~
> Some of the ideas that follow build upon each other, some are independent
> of each other. I won't attempt to outline an exact timetable, but you can
> see that some of this work could be performed in parallel. For example,
> improved Shiro support (4) could be done at the same time as simplifying
> the framework (1).
>
> 1. Simplifying the framework
>
> * Isis will run only as a server-side webapp. This implies that the DnD
> viewer will be retired. This will also enable Isis' bootstrapping to be
> simplified and rationalized.
By the way: A DnD viewer can be later re-implemented, if so desired.
> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> ObjectStore implementation then made part of core. The other ObjectStore
> implementations will be retired. This step in particular should enable
> considerable simplification
As described, this is a temporary state, with a future plan to later
abstract out a new Objectstore API to support other objectstore
frameworks. See below.
> * Isis will adopt the Shiro authentication classes rather than define its
> own. This will also allow authentication to be moved into the core.
I have no comment :)
> 3. Alternative Persistence providers
>
> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> object tracking) and on DataNucleus in particular, the next step in the
> roadmap is to re-introduce pluggability so that developers can use other
> ORM implementations; particularly for the JPA API. Being an Apache product
> means that we cannot dependent on certain licenses, but we certainly
> provide alternative implemenation based on either Apache OpenJPA, or on
> EclipseLink (the old TopLink product).
>
> We might also look to provide an implementation for the market leader,
> namely Hibernate. However, because Hibernate is LGPL, this implementation
> would need to live outside of Apache Isis' formal codebase, eg in the
> apache-extras.org site or perhaps just likely on github.
>
>
> 4. Improved support for Shiro
>
> We've noticed a number of users wanting to use our Shiro integration, with
> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
> build Isis entities that map onto the Shiro concepts (users, roles,
> permissions). In this way Isis could provide a self-contained security
> subsystem for managing users "out-of-the-box".
>
> We anticipate delivering this as an optional module that could be included
> as necessary.
>
> An extension of this is to deliver a standalone application built with Isis
> for administrating the users/roles/permissions for any application
> configured to use the Shiro JDBC realm (not just an Isis application).
The discussions I've had and heard regarding other application
development suites lead me to believe that this would be an extremely
useful add-on! I'd almost like to request that this be the first thing
worked on, before any of the fundamental changes listed above.
But that's just my wish.
(I'd like to demo that Isis can also support RBAC, out-of-the-box).
>
>
> 5. Other Reusable modules
>
> In the applib there are a number of services; some depend on parts of the
> Isis runtime; some do not. Some have their own entities, some do not:
>
> - CommandContext (applib implementation)
> - BackgroundService (core-runtime implementation)
> - BackgroundCommandService (JDO implementation, with entities)
> - AuditingService3 (JDO implementation, with entities)
>
> - PublishingService (JDO implementation, with entities)
>
> - ApplicationSettingsServiceRW (JDO implementation, with entities)
> - UserSettingsServiceRW (JDO implementation, with entities)
>
> - ClockService (applib implementation)
> - QueryResultsCache (applib implementation)
> - Scratchpad (applib implementation)
>
> - MementoService (core-runtime implementation)
> - BookmarkService (core-metamodel implementation)
> - XmlSnapshotService (core-runtime)
> - EventBus (core-runtime implementation)
> - ClassDiscoveryService (applib implementation,
> +optional org.reflections dependency)
> - WrapperFactory (core-wrapper)
> - DeveloperUtilitiesService (core-metamodel implementation)
>
> Extended the idea of the Shiro security module (4, above), we think it
> makes sense to modularize these other services; probably in five or so
> modules in line with the grouping shown above. That way developers could
> bring in a dependency to the services that they require, and ignore the
> others.
>
>
> 6. Profile Store
>
> The profile store is a component of the framework that is not supported by
> either the Wicket or Restful Objects viewers, but whose functionality is
> broadly superceded by the UserSettingsService.
When the UI becomes user-configurable (re-arranged, pallete change,
etc) this should be demo'd.
Where are user preferences (e.g. UI language, timezone, etc) currently
stored? Do we have demo code?
> In line with simplification (1) we'll retire this component.
>
>
> 7. Restful APIs
>
> The Restful Objects viewer implements the Restful Objects spec [2] and
> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>
>
> 8. Wicket Viewer
>
> We intend to continue developing the Wicket viewer. One part of its
> development will be to re-implement its components to use Wicket-Bootstrap
> [5]; this will make it easier for its look-n-feel to be customised.
>
> We will also probably rename it. "Wicket" is merely the implementation
> technology; its name should represent what it's role is. Possible names
> are the "default viewer", or the "standard viewer" (preferences?
> alternatives?)
Thinking about it further, I would probably prefer to keep "Wicket" in the
name somewhere, as the viewer *is* dependent on Wicket, and those
who wish to extend (I want to add some additional view components),
need to know Wicket. But I guess that other names may also be more
appropriate..
>
> 11. Better documentation, better website.
>
> Probably every open source project would wish for better documentation and
> examples; we are no different, and we intend to keep improving the docs and
> providing examples of usage.
>
> On the homepage one idea is to make Isis' value proposition more obvious.
> We intend to distinguish our audience, though; what a business person
> wants to know about is different from what a techie wants. So we will
> provide different material for each to consume.
>
> For a bit of interest/originality, Maurizio has offered to develop some
> goanimate [6] cartoon videos; he has used these with some success in his
> own software development company. Right now I am working on some scripts
> to be developed; one 2-minute business-focused one, and a number (3 or 4)
> of 2-minute technicaly focussed ones.
>
> Also, I am aware that much of the materials were written by me and all of
> the screencasts have my voice on them. But there should be other voices
> present on the website; Isis isn't a one-man show and visitors to the
> website shouldn't get that impression.
I agree and will try and step in more, here.
> 13. Conferences, articles, podcasts
>
> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
> EU in Hungary [7], and in general try to do a few more sessions.
>
> I have also promised an 500-word blog post for Zeroturnaround to advertise
> our JRebel integration.
>
> And, it'd also be good to do some podcasts sessions; I am sure they are
> several looking for new people to talk with.
I'll be in touch later for ideas for ApacheCon EU and other opportunities.
Don't forget about opportunities to show off Isis in "rapid app" dev
competitions. Jeroen, you mentioned one in the Netherlands??
Perhaps Isis can become the disruptive change from a surprising
direction!
>
> ~~~
> OK, I think that's it.
>
> As I say, for those who were in Milan, please amplify/expand/correct. For
> everyone else, your comments/thoughts are welcome.
>
> Cheers
> Dan
> Apache Isis PMC Chair
:)
Unless otherwise indicated, I agree with the proposals.. ;)
Regards,
Kevin
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi Bilgin!
As Dan mentioned, we've already integrated our Isis domain with Drools.
But the problem in our case is that we used Drools 5.6, as version 6 was still in Beta those days, and the API has changed A LOT (in uppercase, you know ... :-))
Also, our Isis Service was highly-coupled with our domain.
So it would be great if you point us about how to initialize it by means of, for example, the Isis quickstart archetype.
We are going to need also some Camel integration (mainly accepting incoming events through an open TCP port and sending them to the Drools stateful session) so any basic example would also be great!
Count to meet you on the next IsisCon!!!
I'm sure your knowledge about Apache and JBoss technologies will be invaluable !!
Regards,
Oscar
El 20/06/2014, a las 16:24, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> On 20 June 2014 12:24, Bilgin Ibryam <bi...@gmail.com> wrote:
>
>> Hi all, it seems you had a nice time at the mini conference. Hopefully
>> I'll join you next time.
>>
>>
> That'd be good.
>
>
>
>> If I remember correct, one of the talk was supposed to be about the
>> ISIS-Camel integration which I implemented. I wonder how did it go? Any
>> feedback or do you see whether such an integration at framework would be
>> useful?
>>
>>
> Must admit, this isn't something we ended up talking about, I'm afraid.
> Come along to the next one (whenever that is) and make sure we do!
>
>
>
>
>> What about an integration with a Drools, does anyone see having a rule
>> engine extension to ISIS might be useful?
>>
>>
> I think that Oscar has integrated a rules engine (might be Drools) already.
> Oscar... am I right about that?
>
>
>
>> Also, I really hope to see some progress on point 1 above - cleaning up and
>> making ISIS easier for new comers to understand and use. Having obsolete
>> modules as part of the project source code doesn't help in this regard.
>>
>>
> Yup, definitely going to happen.
>
> In fact, I realized that there's no need to wait until Isis 2.0 for doing
> some of this; there's nothing to prevent me moving Restful and JDO/DN into
> core right now; that won't break backward compatibility. Should let me make
> some early progress on that front, and will make subsequent releases a bit
> less time-consuming.
>
> Cheers
> Dan
>
>
>
>> Cheers,
>>
>>
>>
>>
>> On 8 June 2014 19:14, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>>
>>> Hi folks,
>>>
>>> On Friday and Saturday just gone a number of us - Jeroen, Oscar,
>> Maurizio,
>>> Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in
>>> Milan for the first "IsisCon". Ok, not exactly a conference, but a great
>>> opportunity to see what we'd each been using Isis for, and to build a
>>> roadmap for Isis' future. There was also plenty of conversation about
>>> "marketing" Isis, in order to build up the user base.
>>>
>>> I believe we all came away the event feeling it had been extremely useful
>>> (as well as enjoyable), and I think there was a consensus on what that
>>> roadmap and respective priorities for Isis should be.
>>>
>>> That said, the "Apache way" is for such matters to be discussed on the
>>> mailing list: "if it isn't on the mailing list then it didn't happen". I
>>> therefore want to summarize the main topics of conversation that we had.
>>>
>>> For those who were in Milan: please amplify/extend/correct as necessary.
>>> For everyone else: please join in the conversation with your own
>> thoughts.
>>> Remember: we assume silent consensus.
>>>
>>> ~~~~~
>>> Some of the ideas that follow build upon each other, some are independent
>>> of each other. I won't attempt to outline an exact timetable, but you
>> can
>>> see that some of this work could be performed in parallel. For example,
>>> improved Shiro support (4) could be done at the same time as simplifying
>>> the framework (1).
>>>
>>> 1. Simplifying the framework
>>>
>>> Apache Isis is the evolution of the original Naked Objects Framework for
>>> Java; when it entered the Apache incubator in 2010 the codebase was the
>> NOF
>>> code along with a number of "sister projects" that I had written over the
>>> previous few years.
>>>
>>> Some of this codebase is very old however - Rob Matthews (one of our
>>> committers) actually started on NOF in about 1999; 15 years ago!
>>> Obviously, since then a lot has changed, both in terms of the
>>> architectures we aim to support, and in other libraries/frameworks that
>> are
>>> available that we can leverage.
>>>
>>> For example, originally the NOF was intended to run either as standalone
>>> client, or in client/server mode, or as a server-only webapp. In Isis we
>>> retired the client/server remoting support when we graduated in 2012, but
>>> we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT
>> viewer
>>> (even though this hasn't been released since we graduated the Apache
>>> incubator in 2012).
>>>
>>> Another change over the years is in persistence support. Isis has an
>>> ObjectStore API, and this allows different ObjectStore implementations to
>>> be plugged in. These include the JDO/Datanucleus ObjectStore, but also
>> the
>>> In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore.
>>> (Again, these latter two have not been released since we graduated).
>>>
>>> While the JDO/Datanucleus ObjectStore manages (through the DataNucleus
>> ORM)
>>> its own lazy loading and dirty object tracking, the other ObjectStores do
>>> not have this ability; which means that the core-runtime component of the
>>> Isis framework must handle such matters instead. This introduces a lot
>> of
>>> complexity into Isis, as it must do many of the tasks that an ORM would
>>> normally do.
>>>
>>> Finally, another area where we have the opportunity to leverage third
>> party
>>> frameworks is in security. Isis defines its own authentication and
>>> authorization APIs, and these are exposed to the domain code in the
>>> DomainObjectContainer#getUser() method. Right now we have three such
>>> implementations - a simple file-based implementation, a do-nothing
>> "bypass"
>>> implementation, and an implementation based on Apache Shiro.
>>>
>>> So... we now feel the time is right to simplify:
>>> * Isis will run only as a server-side webapp. This implies that the DnD
>>> viewer will be retired. This will also enable Isis' bootstrapping to be
>>> simplified and rationalized.
>>> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
>>> ObjectStore implementation then made part of core. The other ObjectStore
>>> implementations will be retired. This step in particular should enable
>>> considerable simplification
>>> * Isis will adopt the Shiro authentication classes rather than define its
>>> own. This will also allow authentication to be moved into the core.
>>>
>>> Each of these changes is relatively low risk, and introduces only minimal
>>> changes to existing domain code. In fact, hopefully only the change to
>>> authentication classes will require updates to existing code. The main
>>> intent is to throw away code that no longer provides any benefit, thus
>>> making it easier for others to learn a simplified Isis codebase.
>>>
>>>
>>> 2. JPA support
>>>
>>> Having simplified the codebase, the next step (so far as persistence is
>>> concerned) is to also support JPA. While DataNucleus is the reference
>>> implementation for JDO, we do recognize that most Java developers know
>> and
>>> therefore prefer JPA over JDO. Luckily DataNucleus does also support
>> JPA.
>>> Hopefully it will be easy enough to allow developers to use either API -
>>> JDO or JPA - with DataNucleus as the underlying implementation.
>>>
>>>
>>> 3. Alternative Persistence providers
>>>
>>> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
>>> object tracking) and on DataNucleus in particular, the next step in the
>>> roadmap is to re-introduce pluggability so that developers can use other
>>> ORM implementations; particularly for the JPA API. Being an Apache
>> product
>>> means that we cannot dependent on certain licenses, but we certainly
>>> provide alternative implemenation based on either Apache OpenJPA, or on
>>> EclipseLink (the old TopLink product).
>>>
>>> We might also look to provide an implementation for the market leader,
>>> namely Hibernate. However, because Hibernate is LGPL, this
>> implementation
>>> would need to live outside of Apache Isis' formal codebase, eg in the
>>> apache-extras.org site or perhaps just likely on github.
>>>
>>>
>>> 4. Improved support for Shiro
>>>
>>> We've noticed a number of users wanting to use our Shiro integration,
>> with
>>> Shiro configured to use a JDBC Realm. It ought to be relatively simple
>> to
>>> build Isis entities that map onto the Shiro concepts (users, roles,
>>> permissions). In this way Isis could provide a self-contained security
>>> subsystem for managing users "out-of-the-box".
>>>
>>> We anticipate delivering this as an optional module that could be
>> included
>>> as necessary.
>>>
>>> An extension of this is to deliver a standalone application built with
>> Isis
>>> for administrating the users/roles/permissions for any application
>>> configured to use the Shiro JDBC realm (not just an Isis application).
>>>
>>>
>>> 5. Other Reusable modules
>>>
>>> In the applib there are a number of services; some depend on parts of the
>>> Isis runtime; some do not. Some have their own entities, some do not:
>>>
>>> - CommandContext (applib implementation)
>>> - BackgroundService (core-runtime implementation)
>>> - BackgroundCommandService (JDO implementation, with entities)
>>> - AuditingService3 (JDO implementation, with entities)
>>>
>>> - PublishingService (JDO implementation, with entities)
>>>
>>> - ApplicationSettingsServiceRW (JDO implementation, with entities)
>>> - UserSettingsServiceRW (JDO implementation, with entities)
>>>
>>> - ClockService (applib implementation)
>>> - QueryResultsCache (applib implementation)
>>> - Scratchpad (applib implementation)
>>>
>>> - MementoService (core-runtime implementation)
>>> - BookmarkService (core-metamodel implementation)
>>> - XmlSnapshotService (core-runtime)
>>> - EventBus (core-runtime implementation)
>>> - ClassDiscoveryService (applib implementation,
>>> +optional org.reflections dependency)
>>> - WrapperFactory (core-wrapper)
>>> - DeveloperUtilitiesService (core-metamodel implementation)
>>>
>>> Extended the idea of the Shiro security module (4, above), we think it
>>> makes sense to modularize these other services; probably in five or so
>>> modules in line with the grouping shown above. That way developers could
>>> bring in a dependency to the services that they require, and ignore the
>>> others.
>>>
>>>
>>> 6. Profile Store
>>>
>>> The profile store is a component of the framework that is not supported
>> by
>>> either the Wicket or Restful Objects viewers, but whose functionality is
>>> broadly superceded by the UserSettingsService.
>>>
>>> In line with simplification (1) we'll retire this component.
>>>
>>>
>>> 7. Restful APIs
>>>
>>> The Restful Objects viewer implements the Restful Objects spec [2] and
>>> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>>>
>>> The original intent of the RO spec/viewer was to provide a rich http/json
>>> API, rigorously following RESTful principles, to enable both the
>>> development of a "next-gen" generic viewer written in something like
>>> AngularJS [3], and also to enable bespoke REST applications to be
>> written.
>>>
>>> While we still feel that the RO viewer is appropriate for the former,
>> what
>>> is becoming more obvious is that the RO viewer is too complex for
>>> "idiomatic" RESTful access when using tools such as AngularJS and in
>>> particular higher-level lbraries such as Angular UI [4]
>>>
>>> We therefore have decided to:
>>> - rename the Restful Objects viewer, probably to be called the
>> "Hypermedia
>>> API" (remove the term "viewer")
>>> - implement a new "Idiomatic REST" API which - although not necessarily
>>> REST in the purist's sense - will play well with the aforementioned
>> tools.
>>>
>>> Many of the capabilities of the existing RO viewer can be leveraged to
>>> write this new Idiomatic REST API. But we do hope it will open up the
>>> possibilities of using Isis as a back-end to a new group of users. And,
>> an
>>> influx of new users might then lead in turn to the development of a
>> generic
>>> viewer against the "Hypermedia API".
>>>
>>>
>>> 8. Wicket Viewer
>>>
>>> We intend to continue developing the Wicket viewer. One part of its
>>> development will be to re-implement its components to use
>> Wicket-Bootstrap
>>> [5]; this will make it easier for its look-n-feel to be customised.
>>>
>>> We will also probably rename it. "Wicket" is merely the implementation
>>> technology; its name should represent what it's role is. Possible names
>>> are the "default viewer", or the "standard viewer" (preferences?
>>> alternatives?)
>>>
>>>
>>>
>>> 9. Community outreach
>>>
>>> In line with making Isis appeal to Javascript developers, we also want to
>>> make contact with the user communities of some of the technologies that
>> we
>>> use.
>>>
>>> Within Apache these include Wicket and Shiro. Meanwhile Oscar and
>> Nacho's
>>> application has a custom UI that leverages Wavemaker and React.js.
>>>
>>> Once we have the new "Idiomatic REST API" implemented, then opportunities
>>> open up to build demos to attract AngularJS and similar technologies (eg
>>> dhtmlx).
>>>
>>>
>>>
>>> 10. "framework" vs "platform"
>>>
>>> Although Isis was originally conceived as a framework - indeed, was
>>> originally named the Naked Objects Framework - the consensus in Milan was
>>> that it would be better to position Isis as a platform. Part of the
>>> rationale comes down with the way in which Isis is deployed, either
>> sitting
>>> on top of the JEE platform or Cloud platforms such as Google App Engine.
>>>
>>>
>>> 11. Better documentation, better website.
>>>
>>> Probably every open source project would wish for better documentation
>> and
>>> examples; we are no different, and we intend to keep improving the docs
>> and
>>> providing examples of usage.
>>>
>>> On the homepage one idea is to make Isis' value proposition more obvious.
>>> We intend to distinguish our audience, though; what a business person
>>> wants to know about is different from what a techie wants. So we will
>>> provide different material for each to consume.
>>>
>>> For a bit of interest/originality, Maurizio has offered to develop some
>>> goanimate [6] cartoon videos; he has used these with some success in his
>>> own software development company. Right now I am working on some scripts
>>> to be developed; one 2-minute business-focused one, and a number (3 or 4)
>>> of 2-minute technicaly focussed ones.
>>>
>>> Also, I am aware that much of the materials were written by me and all of
>>> the screencasts have my voice on them. But there should be other voices
>>> present on the website; Isis isn't a one-man show and visitors to the
>>> website shouldn't get that impression.
>>>
>>>
>>> 12. The great and the good
>>>
>>> With so many great open source projects out there it can of course be
>>> difficult to get heard and discovered. But if we can get some publicity
>>> and hopefully nice words/endorsements from the "great and the good", then
>>> that might well help increase our user base.
>>>
>>> Once we have updated the website a little (see 10) there are a few
>>> individuals we have in mind who we will look to contact.
>>>
>>>
>>> 13. Conferences, articles, podcasts
>>>
>>> Jeroen and I are intending to submitting a couple of sessions to
>> ApacheCon
>>> EU in Hungary [7], and in general try to do a few more sessions.
>>>
>>> I have also promised an 500-word blog post for Zeroturnaround to
>> advertise
>>> our JRebel integration.
>>>
>>> And, it'd also be good to do some podcasts sessions; I am sure they are
>>> several looking for new people to talk with.
>>>
>>> ~~~
>>>
>>> As you'll have noticed, the last 4 or 5 topics fall broadly under the
>>> category of "marketing". So - if you've read this far - can I ask anyone
>>> and everyone in Isis to start help generate collateral. Blog posts (not
>>> just in the English language) are great; or ask (and self-answer)
>> questions
>>> on stackoverflow (with the #isis tag); or simply just send hints and tips
>>> on the mailing lists and I'll put them onto the website.
>>>
>>> ~~~
>>> OK, I think that's it.
>>>
>>> As I say, for those who were in Milan, please amplify/expand/correct.
>> For
>>> everyone else, your comments/thoughts are welcome.
>>>
>>> Cheers
>>> Dan
>>> Apache Isis PMC Chair
>>>
>>>
>>>
>>> [1] http://semver.org
>>> [2] http://restfulobjects.org
>>> [3] http://angularjs.org/
>>> [4] http://angular-ui.github.io/bootstrap
>>> [5] http://wb.agilecoders.de/demo/components
>>> [6] http://goanimate.com
>>> [7] http://www.apachecon.com/
>>>
>>
>>
>>
>> --
>> Bilgin Ibryam
>>
>> Apache Camel & Apache OFBiz committer
>> Blog: ofbizian.com
>> Twitter: @bibryam <https://twitter.com/bibryam>
>>
>> Author of Instant Apache Camel Message Routing
>> http://www.amazon.com/dp/1783283475
>>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 20 June 2014 12:24, Bilgin Ibryam <bi...@gmail.com> wrote:
> Hi all, it seems you had a nice time at the mini conference. Hopefully
> I'll join you next time.
>
>
That'd be good.
> If I remember correct, one of the talk was supposed to be about the
> ISIS-Camel integration which I implemented. I wonder how did it go? Any
> feedback or do you see whether such an integration at framework would be
> useful?
>
>
Must admit, this isn't something we ended up talking about, I'm afraid.
Come along to the next one (whenever that is) and make sure we do!
> What about an integration with a Drools, does anyone see having a rule
> engine extension to ISIS might be useful?
>
>
I think that Oscar has integrated a rules engine (might be Drools) already.
Oscar... am I right about that?
> Also, I really hope to see some progress on point 1 above - cleaning up and
> making ISIS easier for new comers to understand and use. Having obsolete
> modules as part of the project source code doesn't help in this regard.
>
>
Yup, definitely going to happen.
In fact, I realized that there's no need to wait until Isis 2.0 for doing
some of this; there's nothing to prevent me moving Restful and JDO/DN into
core right now; that won't break backward compatibility. Should let me make
some early progress on that front, and will make subsequent releases a bit
less time-consuming.
Cheers
Dan
> Cheers,
>
>
>
>
> On 8 June 2014 19:14, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
> > Hi folks,
> >
> > On Friday and Saturday just gone a number of us - Jeroen, Oscar,
> Maurizio,
> > Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in
> > Milan for the first "IsisCon". Ok, not exactly a conference, but a great
> > opportunity to see what we'd each been using Isis for, and to build a
> > roadmap for Isis' future. There was also plenty of conversation about
> > "marketing" Isis, in order to build up the user base.
> >
> > I believe we all came away the event feeling it had been extremely useful
> > (as well as enjoyable), and I think there was a consensus on what that
> > roadmap and respective priorities for Isis should be.
> >
> > That said, the "Apache way" is for such matters to be discussed on the
> > mailing list: "if it isn't on the mailing list then it didn't happen". I
> > therefore want to summarize the main topics of conversation that we had.
> >
> > For those who were in Milan: please amplify/extend/correct as necessary.
> > For everyone else: please join in the conversation with your own
> thoughts.
> > Remember: we assume silent consensus.
> >
> > ~~~~~
> > Some of the ideas that follow build upon each other, some are independent
> > of each other. I won't attempt to outline an exact timetable, but you
> can
> > see that some of this work could be performed in parallel. For example,
> > improved Shiro support (4) could be done at the same time as simplifying
> > the framework (1).
> >
> > 1. Simplifying the framework
> >
> > Apache Isis is the evolution of the original Naked Objects Framework for
> > Java; when it entered the Apache incubator in 2010 the codebase was the
> NOF
> > code along with a number of "sister projects" that I had written over the
> > previous few years.
> >
> > Some of this codebase is very old however - Rob Matthews (one of our
> > committers) actually started on NOF in about 1999; 15 years ago!
> > Obviously, since then a lot has changed, both in terms of the
> > architectures we aim to support, and in other libraries/frameworks that
> are
> > available that we can leverage.
> >
> > For example, originally the NOF was intended to run either as standalone
> > client, or in client/server mode, or as a server-only webapp. In Isis we
> > retired the client/server remoting support when we graduated in 2012, but
> > we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT
> viewer
> > (even though this hasn't been released since we graduated the Apache
> > incubator in 2012).
> >
> > Another change over the years is in persistence support. Isis has an
> > ObjectStore API, and this allows different ObjectStore implementations to
> > be plugged in. These include the JDO/Datanucleus ObjectStore, but also
> the
> > In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore.
> > (Again, these latter two have not been released since we graduated).
> >
> > While the JDO/Datanucleus ObjectStore manages (through the DataNucleus
> ORM)
> > its own lazy loading and dirty object tracking, the other ObjectStores do
> > not have this ability; which means that the core-runtime component of the
> > Isis framework must handle such matters instead. This introduces a lot
> of
> > complexity into Isis, as it must do many of the tasks that an ORM would
> > normally do.
> >
> > Finally, another area where we have the opportunity to leverage third
> party
> > frameworks is in security. Isis defines its own authentication and
> > authorization APIs, and these are exposed to the domain code in the
> > DomainObjectContainer#getUser() method. Right now we have three such
> > implementations - a simple file-based implementation, a do-nothing
> "bypass"
> > implementation, and an implementation based on Apache Shiro.
> >
> > So... we now feel the time is right to simplify:
> > * Isis will run only as a server-side webapp. This implies that the DnD
> > viewer will be retired. This will also enable Isis' bootstrapping to be
> > simplified and rationalized.
> > * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> > ObjectStore implementation then made part of core. The other ObjectStore
> > implementations will be retired. This step in particular should enable
> > considerable simplification
> > * Isis will adopt the Shiro authentication classes rather than define its
> > own. This will also allow authentication to be moved into the core.
> >
> > Each of these changes is relatively low risk, and introduces only minimal
> > changes to existing domain code. In fact, hopefully only the change to
> > authentication classes will require updates to existing code. The main
> > intent is to throw away code that no longer provides any benefit, thus
> > making it easier for others to learn a simplified Isis codebase.
> >
> >
> > 2. JPA support
> >
> > Having simplified the codebase, the next step (so far as persistence is
> > concerned) is to also support JPA. While DataNucleus is the reference
> > implementation for JDO, we do recognize that most Java developers know
> and
> > therefore prefer JPA over JDO. Luckily DataNucleus does also support
> JPA.
> > Hopefully it will be easy enough to allow developers to use either API -
> > JDO or JPA - with DataNucleus as the underlying implementation.
> >
> >
> > 3. Alternative Persistence providers
> >
> > Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> > object tracking) and on DataNucleus in particular, the next step in the
> > roadmap is to re-introduce pluggability so that developers can use other
> > ORM implementations; particularly for the JPA API. Being an Apache
> product
> > means that we cannot dependent on certain licenses, but we certainly
> > provide alternative implemenation based on either Apache OpenJPA, or on
> > EclipseLink (the old TopLink product).
> >
> > We might also look to provide an implementation for the market leader,
> > namely Hibernate. However, because Hibernate is LGPL, this
> implementation
> > would need to live outside of Apache Isis' formal codebase, eg in the
> > apache-extras.org site or perhaps just likely on github.
> >
> >
> > 4. Improved support for Shiro
> >
> > We've noticed a number of users wanting to use our Shiro integration,
> with
> > Shiro configured to use a JDBC Realm. It ought to be relatively simple
> to
> > build Isis entities that map onto the Shiro concepts (users, roles,
> > permissions). In this way Isis could provide a self-contained security
> > subsystem for managing users "out-of-the-box".
> >
> > We anticipate delivering this as an optional module that could be
> included
> > as necessary.
> >
> > An extension of this is to deliver a standalone application built with
> Isis
> > for administrating the users/roles/permissions for any application
> > configured to use the Shiro JDBC realm (not just an Isis application).
> >
> >
> > 5. Other Reusable modules
> >
> > In the applib there are a number of services; some depend on parts of the
> > Isis runtime; some do not. Some have their own entities, some do not:
> >
> > - CommandContext (applib implementation)
> > - BackgroundService (core-runtime implementation)
> > - BackgroundCommandService (JDO implementation, with entities)
> > - AuditingService3 (JDO implementation, with entities)
> >
> > - PublishingService (JDO implementation, with entities)
> >
> > - ApplicationSettingsServiceRW (JDO implementation, with entities)
> > - UserSettingsServiceRW (JDO implementation, with entities)
> >
> > - ClockService (applib implementation)
> > - QueryResultsCache (applib implementation)
> > - Scratchpad (applib implementation)
> >
> > - MementoService (core-runtime implementation)
> > - BookmarkService (core-metamodel implementation)
> > - XmlSnapshotService (core-runtime)
> > - EventBus (core-runtime implementation)
> > - ClassDiscoveryService (applib implementation,
> > +optional org.reflections dependency)
> > - WrapperFactory (core-wrapper)
> > - DeveloperUtilitiesService (core-metamodel implementation)
> >
> > Extended the idea of the Shiro security module (4, above), we think it
> > makes sense to modularize these other services; probably in five or so
> > modules in line with the grouping shown above. That way developers could
> > bring in a dependency to the services that they require, and ignore the
> > others.
> >
> >
> > 6. Profile Store
> >
> > The profile store is a component of the framework that is not supported
> by
> > either the Wicket or Restful Objects viewers, but whose functionality is
> > broadly superceded by the UserSettingsService.
> >
> > In line with simplification (1) we'll retire this component.
> >
> >
> > 7. Restful APIs
> >
> > The Restful Objects viewer implements the Restful Objects spec [2] and
> > provides a full REST Hypermedia API to the Isis metamodel and runtime.
> >
> > The original intent of the RO spec/viewer was to provide a rich http/json
> > API, rigorously following RESTful principles, to enable both the
> > development of a "next-gen" generic viewer written in something like
> > AngularJS [3], and also to enable bespoke REST applications to be
> written.
> >
> > While we still feel that the RO viewer is appropriate for the former,
> what
> > is becoming more obvious is that the RO viewer is too complex for
> > "idiomatic" RESTful access when using tools such as AngularJS and in
> > particular higher-level lbraries such as Angular UI [4]
> >
> > We therefore have decided to:
> > - rename the Restful Objects viewer, probably to be called the
> "Hypermedia
> > API" (remove the term "viewer")
> > - implement a new "Idiomatic REST" API which - although not necessarily
> > REST in the purist's sense - will play well with the aforementioned
> tools.
> >
> > Many of the capabilities of the existing RO viewer can be leveraged to
> > write this new Idiomatic REST API. But we do hope it will open up the
> > possibilities of using Isis as a back-end to a new group of users. And,
> an
> > influx of new users might then lead in turn to the development of a
> generic
> > viewer against the "Hypermedia API".
> >
> >
> > 8. Wicket Viewer
> >
> > We intend to continue developing the Wicket viewer. One part of its
> > development will be to re-implement its components to use
> Wicket-Bootstrap
> > [5]; this will make it easier for its look-n-feel to be customised.
> >
> > We will also probably rename it. "Wicket" is merely the implementation
> > technology; its name should represent what it's role is. Possible names
> > are the "default viewer", or the "standard viewer" (preferences?
> > alternatives?)
> >
> >
> >
> > 9. Community outreach
> >
> > In line with making Isis appeal to Javascript developers, we also want to
> > make contact with the user communities of some of the technologies that
> we
> > use.
> >
> > Within Apache these include Wicket and Shiro. Meanwhile Oscar and
> Nacho's
> > application has a custom UI that leverages Wavemaker and React.js.
> >
> > Once we have the new "Idiomatic REST API" implemented, then opportunities
> > open up to build demos to attract AngularJS and similar technologies (eg
> > dhtmlx).
> >
> >
> >
> > 10. "framework" vs "platform"
> >
> > Although Isis was originally conceived as a framework - indeed, was
> > originally named the Naked Objects Framework - the consensus in Milan was
> > that it would be better to position Isis as a platform. Part of the
> > rationale comes down with the way in which Isis is deployed, either
> sitting
> > on top of the JEE platform or Cloud platforms such as Google App Engine.
> >
> >
> > 11. Better documentation, better website.
> >
> > Probably every open source project would wish for better documentation
> and
> > examples; we are no different, and we intend to keep improving the docs
> and
> > providing examples of usage.
> >
> > On the homepage one idea is to make Isis' value proposition more obvious.
> > We intend to distinguish our audience, though; what a business person
> > wants to know about is different from what a techie wants. So we will
> > provide different material for each to consume.
> >
> > For a bit of interest/originality, Maurizio has offered to develop some
> > goanimate [6] cartoon videos; he has used these with some success in his
> > own software development company. Right now I am working on some scripts
> > to be developed; one 2-minute business-focused one, and a number (3 or 4)
> > of 2-minute technicaly focussed ones.
> >
> > Also, I am aware that much of the materials were written by me and all of
> > the screencasts have my voice on them. But there should be other voices
> > present on the website; Isis isn't a one-man show and visitors to the
> > website shouldn't get that impression.
> >
> >
> > 12. The great and the good
> >
> > With so many great open source projects out there it can of course be
> > difficult to get heard and discovered. But if we can get some publicity
> > and hopefully nice words/endorsements from the "great and the good", then
> > that might well help increase our user base.
> >
> > Once we have updated the website a little (see 10) there are a few
> > individuals we have in mind who we will look to contact.
> >
> >
> > 13. Conferences, articles, podcasts
> >
> > Jeroen and I are intending to submitting a couple of sessions to
> ApacheCon
> > EU in Hungary [7], and in general try to do a few more sessions.
> >
> > I have also promised an 500-word blog post for Zeroturnaround to
> advertise
> > our JRebel integration.
> >
> > And, it'd also be good to do some podcasts sessions; I am sure they are
> > several looking for new people to talk with.
> >
> > ~~~
> >
> > As you'll have noticed, the last 4 or 5 topics fall broadly under the
> > category of "marketing". So - if you've read this far - can I ask anyone
> > and everyone in Isis to start help generate collateral. Blog posts (not
> > just in the English language) are great; or ask (and self-answer)
> questions
> > on stackoverflow (with the #isis tag); or simply just send hints and tips
> > on the mailing lists and I'll put them onto the website.
> >
> > ~~~
> > OK, I think that's it.
> >
> > As I say, for those who were in Milan, please amplify/expand/correct.
> For
> > everyone else, your comments/thoughts are welcome.
> >
> > Cheers
> > Dan
> > Apache Isis PMC Chair
> >
> >
> >
> > [1] http://semver.org
> > [2] http://restfulobjects.org
> > [3] http://angularjs.org/
> > [4] http://angular-ui.github.io/bootstrap
> > [5] http://wb.agilecoders.de/demo/components
> > [6] http://goanimate.com
> > [7] http://www.apachecon.com/
> >
>
>
>
> --
> Bilgin Ibryam
>
> Apache Camel & Apache OFBiz committer
> Blog: ofbizian.com
> Twitter: @bibryam <https://twitter.com/bibryam>
>
> Author of Instant Apache Camel Message Routing
> http://www.amazon.com/dp/1783283475
>
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Bilgin Ibryam <bi...@gmail.com>.
Hi all, it seems you had a nice time at the mini conference. Hopefully
I'll join you next time.
If I remember correct, one of the talk was supposed to be about the
ISIS-Camel integration which I implemented. I wonder how did it go? Any
feedback or do you see whether such an integration at framework would be
useful?
What about an integration with a Drools, does anyone see having a rule
engine extension to ISIS might be useful?
Also, I really hope to see some progress on point 1 above - cleaning up and
making ISIS easier for new comers to understand and use. Having obsolete
modules as part of the project source code doesn't help in this regard.
Cheers,
On 8 June 2014 19:14, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Hi folks,
>
> On Friday and Saturday just gone a number of us - Jeroen, Oscar, Maurizio,
> Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in
> Milan for the first "IsisCon". Ok, not exactly a conference, but a great
> opportunity to see what we'd each been using Isis for, and to build a
> roadmap for Isis' future. There was also plenty of conversation about
> "marketing" Isis, in order to build up the user base.
>
> I believe we all came away the event feeling it had been extremely useful
> (as well as enjoyable), and I think there was a consensus on what that
> roadmap and respective priorities for Isis should be.
>
> That said, the "Apache way" is for such matters to be discussed on the
> mailing list: "if it isn't on the mailing list then it didn't happen". I
> therefore want to summarize the main topics of conversation that we had.
>
> For those who were in Milan: please amplify/extend/correct as necessary.
> For everyone else: please join in the conversation with your own thoughts.
> Remember: we assume silent consensus.
>
> ~~~~~
> Some of the ideas that follow build upon each other, some are independent
> of each other. I won't attempt to outline an exact timetable, but you can
> see that some of this work could be performed in parallel. For example,
> improved Shiro support (4) could be done at the same time as simplifying
> the framework (1).
>
> 1. Simplifying the framework
>
> Apache Isis is the evolution of the original Naked Objects Framework for
> Java; when it entered the Apache incubator in 2010 the codebase was the NOF
> code along with a number of "sister projects" that I had written over the
> previous few years.
>
> Some of this codebase is very old however - Rob Matthews (one of our
> committers) actually started on NOF in about 1999; 15 years ago!
> Obviously, since then a lot has changed, both in terms of the
> architectures we aim to support, and in other libraries/frameworks that are
> available that we can leverage.
>
> For example, originally the NOF was intended to run either as standalone
> client, or in client/server mode, or as a server-only webapp. In Isis we
> retired the client/server remoting support when we graduated in 2012, but
> we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT viewer
> (even though this hasn't been released since we graduated the Apache
> incubator in 2012).
>
> Another change over the years is in persistence support. Isis has an
> ObjectStore API, and this allows different ObjectStore implementations to
> be plugged in. These include the JDO/Datanucleus ObjectStore, but also the
> In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore.
> (Again, these latter two have not been released since we graduated).
>
> While the JDO/Datanucleus ObjectStore manages (through the DataNucleus ORM)
> its own lazy loading and dirty object tracking, the other ObjectStores do
> not have this ability; which means that the core-runtime component of the
> Isis framework must handle such matters instead. This introduces a lot of
> complexity into Isis, as it must do many of the tasks that an ORM would
> normally do.
>
> Finally, another area where we have the opportunity to leverage third party
> frameworks is in security. Isis defines its own authentication and
> authorization APIs, and these are exposed to the domain code in the
> DomainObjectContainer#getUser() method. Right now we have three such
> implementations - a simple file-based implementation, a do-nothing "bypass"
> implementation, and an implementation based on Apache Shiro.
>
> So... we now feel the time is right to simplify:
> * Isis will run only as a server-side webapp. This implies that the DnD
> viewer will be retired. This will also enable Isis' bootstrapping to be
> simplified and rationalized.
> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> ObjectStore implementation then made part of core. The other ObjectStore
> implementations will be retired. This step in particular should enable
> considerable simplification
> * Isis will adopt the Shiro authentication classes rather than define its
> own. This will also allow authentication to be moved into the core.
>
> Each of these changes is relatively low risk, and introduces only minimal
> changes to existing domain code. In fact, hopefully only the change to
> authentication classes will require updates to existing code. The main
> intent is to throw away code that no longer provides any benefit, thus
> making it easier for others to learn a simplified Isis codebase.
>
>
> 2. JPA support
>
> Having simplified the codebase, the next step (so far as persistence is
> concerned) is to also support JPA. While DataNucleus is the reference
> implementation for JDO, we do recognize that most Java developers know and
> therefore prefer JPA over JDO. Luckily DataNucleus does also support JPA.
> Hopefully it will be easy enough to allow developers to use either API -
> JDO or JPA - with DataNucleus as the underlying implementation.
>
>
> 3. Alternative Persistence providers
>
> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> object tracking) and on DataNucleus in particular, the next step in the
> roadmap is to re-introduce pluggability so that developers can use other
> ORM implementations; particularly for the JPA API. Being an Apache product
> means that we cannot dependent on certain licenses, but we certainly
> provide alternative implemenation based on either Apache OpenJPA, or on
> EclipseLink (the old TopLink product).
>
> We might also look to provide an implementation for the market leader,
> namely Hibernate. However, because Hibernate is LGPL, this implementation
> would need to live outside of Apache Isis' formal codebase, eg in the
> apache-extras.org site or perhaps just likely on github.
>
>
> 4. Improved support for Shiro
>
> We've noticed a number of users wanting to use our Shiro integration, with
> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
> build Isis entities that map onto the Shiro concepts (users, roles,
> permissions). In this way Isis could provide a self-contained security
> subsystem for managing users "out-of-the-box".
>
> We anticipate delivering this as an optional module that could be included
> as necessary.
>
> An extension of this is to deliver a standalone application built with Isis
> for administrating the users/roles/permissions for any application
> configured to use the Shiro JDBC realm (not just an Isis application).
>
>
> 5. Other Reusable modules
>
> In the applib there are a number of services; some depend on parts of the
> Isis runtime; some do not. Some have their own entities, some do not:
>
> - CommandContext (applib implementation)
> - BackgroundService (core-runtime implementation)
> - BackgroundCommandService (JDO implementation, with entities)
> - AuditingService3 (JDO implementation, with entities)
>
> - PublishingService (JDO implementation, with entities)
>
> - ApplicationSettingsServiceRW (JDO implementation, with entities)
> - UserSettingsServiceRW (JDO implementation, with entities)
>
> - ClockService (applib implementation)
> - QueryResultsCache (applib implementation)
> - Scratchpad (applib implementation)
>
> - MementoService (core-runtime implementation)
> - BookmarkService (core-metamodel implementation)
> - XmlSnapshotService (core-runtime)
> - EventBus (core-runtime implementation)
> - ClassDiscoveryService (applib implementation,
> +optional org.reflections dependency)
> - WrapperFactory (core-wrapper)
> - DeveloperUtilitiesService (core-metamodel implementation)
>
> Extended the idea of the Shiro security module (4, above), we think it
> makes sense to modularize these other services; probably in five or so
> modules in line with the grouping shown above. That way developers could
> bring in a dependency to the services that they require, and ignore the
> others.
>
>
> 6. Profile Store
>
> The profile store is a component of the framework that is not supported by
> either the Wicket or Restful Objects viewers, but whose functionality is
> broadly superceded by the UserSettingsService.
>
> In line with simplification (1) we'll retire this component.
>
>
> 7. Restful APIs
>
> The Restful Objects viewer implements the Restful Objects spec [2] and
> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>
> The original intent of the RO spec/viewer was to provide a rich http/json
> API, rigorously following RESTful principles, to enable both the
> development of a "next-gen" generic viewer written in something like
> AngularJS [3], and also to enable bespoke REST applications to be written.
>
> While we still feel that the RO viewer is appropriate for the former, what
> is becoming more obvious is that the RO viewer is too complex for
> "idiomatic" RESTful access when using tools such as AngularJS and in
> particular higher-level lbraries such as Angular UI [4]
>
> We therefore have decided to:
> - rename the Restful Objects viewer, probably to be called the "Hypermedia
> API" (remove the term "viewer")
> - implement a new "Idiomatic REST" API which - although not necessarily
> REST in the purist's sense - will play well with the aforementioned tools.
>
> Many of the capabilities of the existing RO viewer can be leveraged to
> write this new Idiomatic REST API. But we do hope it will open up the
> possibilities of using Isis as a back-end to a new group of users. And, an
> influx of new users might then lead in turn to the development of a generic
> viewer against the "Hypermedia API".
>
>
> 8. Wicket Viewer
>
> We intend to continue developing the Wicket viewer. One part of its
> development will be to re-implement its components to use Wicket-Bootstrap
> [5]; this will make it easier for its look-n-feel to be customised.
>
> We will also probably rename it. "Wicket" is merely the implementation
> technology; its name should represent what it's role is. Possible names
> are the "default viewer", or the "standard viewer" (preferences?
> alternatives?)
>
>
>
> 9. Community outreach
>
> In line with making Isis appeal to Javascript developers, we also want to
> make contact with the user communities of some of the technologies that we
> use.
>
> Within Apache these include Wicket and Shiro. Meanwhile Oscar and Nacho's
> application has a custom UI that leverages Wavemaker and React.js.
>
> Once we have the new "Idiomatic REST API" implemented, then opportunities
> open up to build demos to attract AngularJS and similar technologies (eg
> dhtmlx).
>
>
>
> 10. "framework" vs "platform"
>
> Although Isis was originally conceived as a framework - indeed, was
> originally named the Naked Objects Framework - the consensus in Milan was
> that it would be better to position Isis as a platform. Part of the
> rationale comes down with the way in which Isis is deployed, either sitting
> on top of the JEE platform or Cloud platforms such as Google App Engine.
>
>
> 11. Better documentation, better website.
>
> Probably every open source project would wish for better documentation and
> examples; we are no different, and we intend to keep improving the docs and
> providing examples of usage.
>
> On the homepage one idea is to make Isis' value proposition more obvious.
> We intend to distinguish our audience, though; what a business person
> wants to know about is different from what a techie wants. So we will
> provide different material for each to consume.
>
> For a bit of interest/originality, Maurizio has offered to develop some
> goanimate [6] cartoon videos; he has used these with some success in his
> own software development company. Right now I am working on some scripts
> to be developed; one 2-minute business-focused one, and a number (3 or 4)
> of 2-minute technicaly focussed ones.
>
> Also, I am aware that much of the materials were written by me and all of
> the screencasts have my voice on them. But there should be other voices
> present on the website; Isis isn't a one-man show and visitors to the
> website shouldn't get that impression.
>
>
> 12. The great and the good
>
> With so many great open source projects out there it can of course be
> difficult to get heard and discovered. But if we can get some publicity
> and hopefully nice words/endorsements from the "great and the good", then
> that might well help increase our user base.
>
> Once we have updated the website a little (see 10) there are a few
> individuals we have in mind who we will look to contact.
>
>
> 13. Conferences, articles, podcasts
>
> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
> EU in Hungary [7], and in general try to do a few more sessions.
>
> I have also promised an 500-word blog post for Zeroturnaround to advertise
> our JRebel integration.
>
> And, it'd also be good to do some podcasts sessions; I am sure they are
> several looking for new people to talk with.
>
> ~~~
>
> As you'll have noticed, the last 4 or 5 topics fall broadly under the
> category of "marketing". So - if you've read this far - can I ask anyone
> and everyone in Isis to start help generate collateral. Blog posts (not
> just in the English language) are great; or ask (and self-answer) questions
> on stackoverflow (with the #isis tag); or simply just send hints and tips
> on the mailing lists and I'll put them onto the website.
>
> ~~~
> OK, I think that's it.
>
> As I say, for those who were in Milan, please amplify/expand/correct. For
> everyone else, your comments/thoughts are welcome.
>
> Cheers
> Dan
> Apache Isis PMC Chair
>
>
>
> [1] http://semver.org
> [2] http://restfulobjects.org
> [3] http://angularjs.org/
> [4] http://angular-ui.github.io/bootstrap
> [5] http://wb.agilecoders.de/demo/components
> [6] http://goanimate.com
> [7] http://www.apachecon.com/
>
--
Bilgin Ibryam
Apache Camel & Apache OFBiz committer
Blog: ofbizian.com
Twitter: @bibryam <https://twitter.com/bibryam>
Author of Instant Apache Camel Message Routing
http://www.amazon.com/dp/1783283475
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Stephen Cameron <st...@gmail.com>.
Hi Dan,
Just a thought bubble that the future is Web Components and maybe Angular
may or may not be compatible with that?
Personally I hope that the Application developers do get themselves sorted
with a good UI 'component object' approach and leave the REST to get on
with building a true 'web' outside of Facebook.
Steve Cameron
On Mon, Jun 9, 2014 at 4:14 AM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Hi folks,
>
> On Friday and Saturday just gone a number of us - Jeroen, Oscar, Maurizio,
> Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in
> Milan for the first "IsisCon". Ok, not exactly a conference, but a great
> opportunity to see what we'd each been using Isis for, and to build a
> roadmap for Isis' future. There was also plenty of conversation about
> "marketing" Isis, in order to build up the user base.
>
> I believe we all came away the event feeling it had been extremely useful
> (as well as enjoyable), and I think there was a consensus on what that
> roadmap and respective priorities for Isis should be.
>
> That said, the "Apache way" is for such matters to be discussed on the
> mailing list: "if it isn't on the mailing list then it didn't happen". I
> therefore want to summarize the main topics of conversation that we had.
>
> For those who were in Milan: please amplify/extend/correct as necessary.
> For everyone else: please join in the conversation with your own thoughts.
> Remember: we assume silent consensus.
>
> ~~~~~
> Some of the ideas that follow build upon each other, some are independent
> of each other. I won't attempt to outline an exact timetable, but you can
> see that some of this work could be performed in parallel. For example,
> improved Shiro support (4) could be done at the same time as simplifying
> the framework (1).
>
> 1. Simplifying the framework
>
> Apache Isis is the evolution of the original Naked Objects Framework for
> Java; when it entered the Apache incubator in 2010 the codebase was the NOF
> code along with a number of "sister projects" that I had written over the
> previous few years.
>
> Some of this codebase is very old however - Rob Matthews (one of our
> committers) actually started on NOF in about 1999; 15 years ago!
> Obviously, since then a lot has changed, both in terms of the
> architectures we aim to support, and in other libraries/frameworks that are
> available that we can leverage.
>
> For example, originally the NOF was intended to run either as standalone
> client, or in client/server mode, or as a server-only webapp. In Isis we
> retired the client/server remoting support when we graduated in 2012, but
> we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT viewer
> (even though this hasn't been released since we graduated the Apache
> incubator in 2012).
>
> Another change over the years is in persistence support. Isis has an
> ObjectStore API, and this allows different ObjectStore implementations to
> be plugged in. These include the JDO/Datanucleus ObjectStore, but also the
> In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore.
> (Again, these latter two have not been released since we graduated).
>
> While the JDO/Datanucleus ObjectStore manages (through the DataNucleus ORM)
> its own lazy loading and dirty object tracking, the other ObjectStores do
> not have this ability; which means that the core-runtime component of the
> Isis framework must handle such matters instead. This introduces a lot of
> complexity into Isis, as it must do many of the tasks that an ORM would
> normally do.
>
> Finally, another area where we have the opportunity to leverage third party
> frameworks is in security. Isis defines its own authentication and
> authorization APIs, and these are exposed to the domain code in the
> DomainObjectContainer#getUser() method. Right now we have three such
> implementations - a simple file-based implementation, a do-nothing "bypass"
> implementation, and an implementation based on Apache Shiro.
>
> So... we now feel the time is right to simplify:
> * Isis will run only as a server-side webapp. This implies that the DnD
> viewer will be retired. This will also enable Isis' bootstrapping to be
> simplified and rationalized.
> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> ObjectStore implementation then made part of core. The other ObjectStore
> implementations will be retired. This step in particular should enable
> considerable simplification
> * Isis will adopt the Shiro authentication classes rather than define its
> own. This will also allow authentication to be moved into the core.
>
> Each of these changes is relatively low risk, and introduces only minimal
> changes to existing domain code. In fact, hopefully only the change to
> authentication classes will require updates to existing code. The main
> intent is to throw away code that no longer provides any benefit, thus
> making it easier for others to learn a simplified Isis codebase.
>
>
> 2. JPA support
>
> Having simplified the codebase, the next step (so far as persistence is
> concerned) is to also support JPA. While DataNucleus is the reference
> implementation for JDO, we do recognize that most Java developers know and
> therefore prefer JPA over JDO. Luckily DataNucleus does also support JPA.
> Hopefully it will be easy enough to allow developers to use either API -
> JDO or JPA - with DataNucleus as the underlying implementation.
>
>
> 3. Alternative Persistence providers
>
> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> object tracking) and on DataNucleus in particular, the next step in the
> roadmap is to re-introduce pluggability so that developers can use other
> ORM implementations; particularly for the JPA API. Being an Apache product
> means that we cannot dependent on certain licenses, but we certainly
> provide alternative implemenation based on either Apache OpenJPA, or on
> EclipseLink (the old TopLink product).
>
> We might also look to provide an implementation for the market leader,
> namely Hibernate. However, because Hibernate is LGPL, this implementation
> would need to live outside of Apache Isis' formal codebase, eg in the
> apache-extras.org site or perhaps just likely on github.
>
>
> 4. Improved support for Shiro
>
> We've noticed a number of users wanting to use our Shiro integration, with
> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
> build Isis entities that map onto the Shiro concepts (users, roles,
> permissions). In this way Isis could provide a self-contained security
> subsystem for managing users "out-of-the-box".
>
> We anticipate delivering this as an optional module that could be included
> as necessary.
>
> An extension of this is to deliver a standalone application built with Isis
> for administrating the users/roles/permissions for any application
> configured to use the Shiro JDBC realm (not just an Isis application).
>
>
> 5. Other Reusable modules
>
> In the applib there are a number of services; some depend on parts of the
> Isis runtime; some do not. Some have their own entities, some do not:
>
> - CommandContext (applib implementation)
> - BackgroundService (core-runtime implementation)
> - BackgroundCommandService (JDO implementation, with entities)
> - AuditingService3 (JDO implementation, with entities)
>
> - PublishingService (JDO implementation, with entities)
>
> - ApplicationSettingsServiceRW (JDO implementation, with entities)
> - UserSettingsServiceRW (JDO implementation, with entities)
>
> - ClockService (applib implementation)
> - QueryResultsCache (applib implementation)
> - Scratchpad (applib implementation)
>
> - MementoService (core-runtime implementation)
> - BookmarkService (core-metamodel implementation)
> - XmlSnapshotService (core-runtime)
> - EventBus (core-runtime implementation)
> - ClassDiscoveryService (applib implementation,
> +optional org.reflections dependency)
> - WrapperFactory (core-wrapper)
> - DeveloperUtilitiesService (core-metamodel implementation)
>
> Extended the idea of the Shiro security module (4, above), we think it
> makes sense to modularize these other services; probably in five or so
> modules in line with the grouping shown above. That way developers could
> bring in a dependency to the services that they require, and ignore the
> others.
>
>
> 6. Profile Store
>
> The profile store is a component of the framework that is not supported by
> either the Wicket or Restful Objects viewers, but whose functionality is
> broadly superceded by the UserSettingsService.
>
> In line with simplification (1) we'll retire this component.
>
>
> 7. Restful APIs
>
> The Restful Objects viewer implements the Restful Objects spec [2] and
> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>
> The original intent of the RO spec/viewer was to provide a rich http/json
> API, rigorously following RESTful principles, to enable both the
> development of a "next-gen" generic viewer written in something like
> AngularJS [3], and also to enable bespoke REST applications to be written.
>
> While we still feel that the RO viewer is appropriate for the former, what
> is becoming more obvious is that the RO viewer is too complex for
> "idiomatic" RESTful access when using tools such as AngularJS and in
> particular higher-level lbraries such as Angular UI [4]
>
> We therefore have decided to:
> - rename the Restful Objects viewer, probably to be called the "Hypermedia
> API" (remove the term "viewer")
> - implement a new "Idiomatic REST" API which - although not necessarily
> REST in the purist's sense - will play well with the aforementioned tools.
>
> Many of the capabilities of the existing RO viewer can be leveraged to
> write this new Idiomatic REST API. But we do hope it will open up the
> possibilities of using Isis as a back-end to a new group of users. And, an
> influx of new users might then lead in turn to the development of a generic
> viewer against the "Hypermedia API".
>
>
> 8. Wicket Viewer
>
> We intend to continue developing the Wicket viewer. One part of its
> development will be to re-implement its components to use Wicket-Bootstrap
> [5]; this will make it easier for its look-n-feel to be customised.
>
> We will also probably rename it. "Wicket" is merely the implementation
> technology; its name should represent what it's role is. Possible names
> are the "default viewer", or the "standard viewer" (preferences?
> alternatives?)
>
>
>
> 9. Community outreach
>
> In line with making Isis appeal to Javascript developers, we also want to
> make contact with the user communities of some of the technologies that we
> use.
>
> Within Apache these include Wicket and Shiro. Meanwhile Oscar and Nacho's
> application has a custom UI that leverages Wavemaker and React.js.
>
> Once we have the new "Idiomatic REST API" implemented, then opportunities
> open up to build demos to attract AngularJS and similar technologies (eg
> dhtmlx).
>
>
>
> 10. "framework" vs "platform"
>
> Although Isis was originally conceived as a framework - indeed, was
> originally named the Naked Objects Framework - the consensus in Milan was
> that it would be better to position Isis as a platform. Part of the
> rationale comes down with the way in which Isis is deployed, either sitting
> on top of the JEE platform or Cloud platforms such as Google App Engine.
>
>
> 11. Better documentation, better website.
>
> Probably every open source project would wish for better documentation and
> examples; we are no different, and we intend to keep improving the docs and
> providing examples of usage.
>
> On the homepage one idea is to make Isis' value proposition more obvious.
> We intend to distinguish our audience, though; what a business person
> wants to know about is different from what a techie wants. So we will
> provide different material for each to consume.
>
> For a bit of interest/originality, Maurizio has offered to develop some
> goanimate [6] cartoon videos; he has used these with some success in his
> own software development company. Right now I am working on some scripts
> to be developed; one 2-minute business-focused one, and a number (3 or 4)
> of 2-minute technicaly focussed ones.
>
> Also, I am aware that much of the materials were written by me and all of
> the screencasts have my voice on them. But there should be other voices
> present on the website; Isis isn't a one-man show and visitors to the
> website shouldn't get that impression.
>
>
> 12. The great and the good
>
> With so many great open source projects out there it can of course be
> difficult to get heard and discovered. But if we can get some publicity
> and hopefully nice words/endorsements from the "great and the good", then
> that might well help increase our user base.
>
> Once we have updated the website a little (see 10) there are a few
> individuals we have in mind who we will look to contact.
>
>
> 13. Conferences, articles, podcasts
>
> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
> EU in Hungary [7], and in general try to do a few more sessions.
>
> I have also promised an 500-word blog post for Zeroturnaround to advertise
> our JRebel integration.
>
> And, it'd also be good to do some podcasts sessions; I am sure they are
> several looking for new people to talk with.
>
> ~~~
>
> As you'll have noticed, the last 4 or 5 topics fall broadly under the
> category of "marketing". So - if you've read this far - can I ask anyone
> and everyone in Isis to start help generate collateral. Blog posts (not
> just in the English language) are great; or ask (and self-answer) questions
> on stackoverflow (with the #isis tag); or simply just send hints and tips
> on the mailing lists and I'll put them onto the website.
>
> ~~~
> OK, I think that's it.
>
> As I say, for those who were in Milan, please amplify/expand/correct. For
> everyone else, your comments/thoughts are welcome.
>
> Cheers
> Dan
> Apache Isis PMC Chair
>
>
>
> [1] http://semver.org
> [2] http://restfulobjects.org
> [3] http://angularjs.org/
> [4] http://angular-ui.github.io/bootstrap
> [5] http://wb.agilecoders.de/demo/components
> [6] http://goanimate.com
> [7] http://www.apachecon.com/
>
Re: [DISCUSSION] IsisCon 2014 - write-up, roadmap, marketing
Posted by Bilgin Ibryam <bi...@gmail.com>.
Hi all, it seems you had a nice time at the mini conference. Hopefully
I'll join you next time.
If I remember correct, one of the talk was supposed to be about the
ISIS-Camel integration which I implemented. I wonder how did it go? Any
feedback or do you see whether such an integration at framework would be
useful?
What about an integration with a Drools, does anyone see having a rule
engine extension to ISIS might be useful?
Also, I really hope to see some progress on point 1 above - cleaning up and
making ISIS easier for new comers to understand and use. Having obsolete
modules as part of the project source code doesn't help in this regard.
Cheers,
On 8 June 2014 19:14, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Hi folks,
>
> On Friday and Saturday just gone a number of us - Jeroen, Oscar, Maurizio,
> Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in
> Milan for the first "IsisCon". Ok, not exactly a conference, but a great
> opportunity to see what we'd each been using Isis for, and to build a
> roadmap for Isis' future. There was also plenty of conversation about
> "marketing" Isis, in order to build up the user base.
>
> I believe we all came away the event feeling it had been extremely useful
> (as well as enjoyable), and I think there was a consensus on what that
> roadmap and respective priorities for Isis should be.
>
> That said, the "Apache way" is for such matters to be discussed on the
> mailing list: "if it isn't on the mailing list then it didn't happen". I
> therefore want to summarize the main topics of conversation that we had.
>
> For those who were in Milan: please amplify/extend/correct as necessary.
> For everyone else: please join in the conversation with your own thoughts.
> Remember: we assume silent consensus.
>
> ~~~~~
> Some of the ideas that follow build upon each other, some are independent
> of each other. I won't attempt to outline an exact timetable, but you can
> see that some of this work could be performed in parallel. For example,
> improved Shiro support (4) could be done at the same time as simplifying
> the framework (1).
>
> 1. Simplifying the framework
>
> Apache Isis is the evolution of the original Naked Objects Framework for
> Java; when it entered the Apache incubator in 2010 the codebase was the NOF
> code along with a number of "sister projects" that I had written over the
> previous few years.
>
> Some of this codebase is very old however - Rob Matthews (one of our
> committers) actually started on NOF in about 1999; 15 years ago!
> Obviously, since then a lot has changed, both in terms of the
> architectures we aim to support, and in other libraries/frameworks that are
> available that we can leverage.
>
> For example, originally the NOF was intended to run either as standalone
> client, or in client/server mode, or as a server-only webapp. In Isis we
> retired the client/server remoting support when we graduated in 2012, but
> we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT viewer
> (even though this hasn't been released since we graduated the Apache
> incubator in 2012).
>
> Another change over the years is in persistence support. Isis has an
> ObjectStore API, and this allows different ObjectStore implementations to
> be plugged in. These include the JDO/Datanucleus ObjectStore, but also the
> In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore.
> (Again, these latter two have not been released since we graduated).
>
> While the JDO/Datanucleus ObjectStore manages (through the DataNucleus ORM)
> its own lazy loading and dirty object tracking, the other ObjectStores do
> not have this ability; which means that the core-runtime component of the
> Isis framework must handle such matters instead. This introduces a lot of
> complexity into Isis, as it must do many of the tasks that an ORM would
> normally do.
>
> Finally, another area where we have the opportunity to leverage third party
> frameworks is in security. Isis defines its own authentication and
> authorization APIs, and these are exposed to the domain code in the
> DomainObjectContainer#getUser() method. Right now we have three such
> implementations - a simple file-based implementation, a do-nothing "bypass"
> implementation, and an implementation based on Apache Shiro.
>
> So... we now feel the time is right to simplify:
> * Isis will run only as a server-side webapp. This implies that the DnD
> viewer will be retired. This will also enable Isis' bootstrapping to be
> simplified and rationalized.
> * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus
> ObjectStore implementation then made part of core. The other ObjectStore
> implementations will be retired. This step in particular should enable
> considerable simplification
> * Isis will adopt the Shiro authentication classes rather than define its
> own. This will also allow authentication to be moved into the core.
>
> Each of these changes is relatively low risk, and introduces only minimal
> changes to existing domain code. In fact, hopefully only the change to
> authentication classes will require updates to existing code. The main
> intent is to throw away code that no longer provides any benefit, thus
> making it easier for others to learn a simplified Isis codebase.
>
>
> 2. JPA support
>
> Having simplified the codebase, the next step (so far as persistence is
> concerned) is to also support JPA. While DataNucleus is the reference
> implementation for JDO, we do recognize that most Java developers know and
> therefore prefer JPA over JDO. Luckily DataNucleus does also support JPA.
> Hopefully it will be easy enough to allow developers to use either API -
> JDO or JPA - with DataNucleus as the underlying implementation.
>
>
> 3. Alternative Persistence providers
>
> Having in (1) made Isis dependent on an ORM (for lazy loading and dirty
> object tracking) and on DataNucleus in particular, the next step in the
> roadmap is to re-introduce pluggability so that developers can use other
> ORM implementations; particularly for the JPA API. Being an Apache product
> means that we cannot dependent on certain licenses, but we certainly
> provide alternative implemenation based on either Apache OpenJPA, or on
> EclipseLink (the old TopLink product).
>
> We might also look to provide an implementation for the market leader,
> namely Hibernate. However, because Hibernate is LGPL, this implementation
> would need to live outside of Apache Isis' formal codebase, eg in the
> apache-extras.org site or perhaps just likely on github.
>
>
> 4. Improved support for Shiro
>
> We've noticed a number of users wanting to use our Shiro integration, with
> Shiro configured to use a JDBC Realm. It ought to be relatively simple to
> build Isis entities that map onto the Shiro concepts (users, roles,
> permissions). In this way Isis could provide a self-contained security
> subsystem for managing users "out-of-the-box".
>
> We anticipate delivering this as an optional module that could be included
> as necessary.
>
> An extension of this is to deliver a standalone application built with Isis
> for administrating the users/roles/permissions for any application
> configured to use the Shiro JDBC realm (not just an Isis application).
>
>
> 5. Other Reusable modules
>
> In the applib there are a number of services; some depend on parts of the
> Isis runtime; some do not. Some have their own entities, some do not:
>
> - CommandContext (applib implementation)
> - BackgroundService (core-runtime implementation)
> - BackgroundCommandService (JDO implementation, with entities)
> - AuditingService3 (JDO implementation, with entities)
>
> - PublishingService (JDO implementation, with entities)
>
> - ApplicationSettingsServiceRW (JDO implementation, with entities)
> - UserSettingsServiceRW (JDO implementation, with entities)
>
> - ClockService (applib implementation)
> - QueryResultsCache (applib implementation)
> - Scratchpad (applib implementation)
>
> - MementoService (core-runtime implementation)
> - BookmarkService (core-metamodel implementation)
> - XmlSnapshotService (core-runtime)
> - EventBus (core-runtime implementation)
> - ClassDiscoveryService (applib implementation,
> +optional org.reflections dependency)
> - WrapperFactory (core-wrapper)
> - DeveloperUtilitiesService (core-metamodel implementation)
>
> Extended the idea of the Shiro security module (4, above), we think it
> makes sense to modularize these other services; probably in five or so
> modules in line with the grouping shown above. That way developers could
> bring in a dependency to the services that they require, and ignore the
> others.
>
>
> 6. Profile Store
>
> The profile store is a component of the framework that is not supported by
> either the Wicket or Restful Objects viewers, but whose functionality is
> broadly superceded by the UserSettingsService.
>
> In line with simplification (1) we'll retire this component.
>
>
> 7. Restful APIs
>
> The Restful Objects viewer implements the Restful Objects spec [2] and
> provides a full REST Hypermedia API to the Isis metamodel and runtime.
>
> The original intent of the RO spec/viewer was to provide a rich http/json
> API, rigorously following RESTful principles, to enable both the
> development of a "next-gen" generic viewer written in something like
> AngularJS [3], and also to enable bespoke REST applications to be written.
>
> While we still feel that the RO viewer is appropriate for the former, what
> is becoming more obvious is that the RO viewer is too complex for
> "idiomatic" RESTful access when using tools such as AngularJS and in
> particular higher-level lbraries such as Angular UI [4]
>
> We therefore have decided to:
> - rename the Restful Objects viewer, probably to be called the "Hypermedia
> API" (remove the term "viewer")
> - implement a new "Idiomatic REST" API which - although not necessarily
> REST in the purist's sense - will play well with the aforementioned tools.
>
> Many of the capabilities of the existing RO viewer can be leveraged to
> write this new Idiomatic REST API. But we do hope it will open up the
> possibilities of using Isis as a back-end to a new group of users. And, an
> influx of new users might then lead in turn to the development of a generic
> viewer against the "Hypermedia API".
>
>
> 8. Wicket Viewer
>
> We intend to continue developing the Wicket viewer. One part of its
> development will be to re-implement its components to use Wicket-Bootstrap
> [5]; this will make it easier for its look-n-feel to be customised.
>
> We will also probably rename it. "Wicket" is merely the implementation
> technology; its name should represent what it's role is. Possible names
> are the "default viewer", or the "standard viewer" (preferences?
> alternatives?)
>
>
>
> 9. Community outreach
>
> In line with making Isis appeal to Javascript developers, we also want to
> make contact with the user communities of some of the technologies that we
> use.
>
> Within Apache these include Wicket and Shiro. Meanwhile Oscar and Nacho's
> application has a custom UI that leverages Wavemaker and React.js.
>
> Once we have the new "Idiomatic REST API" implemented, then opportunities
> open up to build demos to attract AngularJS and similar technologies (eg
> dhtmlx).
>
>
>
> 10. "framework" vs "platform"
>
> Although Isis was originally conceived as a framework - indeed, was
> originally named the Naked Objects Framework - the consensus in Milan was
> that it would be better to position Isis as a platform. Part of the
> rationale comes down with the way in which Isis is deployed, either sitting
> on top of the JEE platform or Cloud platforms such as Google App Engine.
>
>
> 11. Better documentation, better website.
>
> Probably every open source project would wish for better documentation and
> examples; we are no different, and we intend to keep improving the docs and
> providing examples of usage.
>
> On the homepage one idea is to make Isis' value proposition more obvious.
> We intend to distinguish our audience, though; what a business person
> wants to know about is different from what a techie wants. So we will
> provide different material for each to consume.
>
> For a bit of interest/originality, Maurizio has offered to develop some
> goanimate [6] cartoon videos; he has used these with some success in his
> own software development company. Right now I am working on some scripts
> to be developed; one 2-minute business-focused one, and a number (3 or 4)
> of 2-minute technicaly focussed ones.
>
> Also, I am aware that much of the materials were written by me and all of
> the screencasts have my voice on them. But there should be other voices
> present on the website; Isis isn't a one-man show and visitors to the
> website shouldn't get that impression.
>
>
> 12. The great and the good
>
> With so many great open source projects out there it can of course be
> difficult to get heard and discovered. But if we can get some publicity
> and hopefully nice words/endorsements from the "great and the good", then
> that might well help increase our user base.
>
> Once we have updated the website a little (see 10) there are a few
> individuals we have in mind who we will look to contact.
>
>
> 13. Conferences, articles, podcasts
>
> Jeroen and I are intending to submitting a couple of sessions to ApacheCon
> EU in Hungary [7], and in general try to do a few more sessions.
>
> I have also promised an 500-word blog post for Zeroturnaround to advertise
> our JRebel integration.
>
> And, it'd also be good to do some podcasts sessions; I am sure they are
> several looking for new people to talk with.
>
> ~~~
>
> As you'll have noticed, the last 4 or 5 topics fall broadly under the
> category of "marketing". So - if you've read this far - can I ask anyone
> and everyone in Isis to start help generate collateral. Blog posts (not
> just in the English language) are great; or ask (and self-answer) questions
> on stackoverflow (with the #isis tag); or simply just send hints and tips
> on the mailing lists and I'll put them onto the website.
>
> ~~~
> OK, I think that's it.
>
> As I say, for those who were in Milan, please amplify/expand/correct. For
> everyone else, your comments/thoughts are welcome.
>
> Cheers
> Dan
> Apache Isis PMC Chair
>
>
>
> [1] http://semver.org
> [2] http://restfulobjects.org
> [3] http://angularjs.org/
> [4] http://angular-ui.github.io/bootstrap
> [5] http://wb.agilecoders.de/demo/components
> [6] http://goanimate.com
> [7] http://www.apachecon.com/
>
--
Bilgin Ibryam
Apache Camel & Apache OFBiz committer
Blog: ofbizian.com
Twitter: @bibryam <https://twitter.com/bibryam>
Author of Instant Apache Camel Message Routing
http://www.amazon.com/dp/1783283475