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/
