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 <[email protected]> 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
