Apache Isis Interview
After the Isis project entered the Apache Incubator last week, JAXenter asked initial committer Dan Haywood, about the new project…..
DAN HAYWOOD is a freelance consultant, writer, trainer, mentor, specializing in domain-driven design, agile development and enterprise architecture on the Java and .NET platforms. He’s best known as a leading advocate of Naked Objects, and has a 6+ year ongoing involvement as technical advisor for the Irish Government’s strategic Naked Objects system. He’s been a committer to the Naked Objects Framework (on Java) for several years, and has taken the lead in organizing the donation of this code and his own sister projects to the Apache Software Foundation. Previous lives include 4 years’ consulting with Sybase Professional Services in the mid 90s (he still keeps his hand in), and 5 years working on big IT systems at Accenture (hence his deep-rooted aversion to waterfall). Dan has authored or co-authored a couple of books, the most recent being “Domain Driven Design using Naked Objects” (pragprog 2009.)
Isis is a new standards-based framework for developing and deploying domain-driven applications, which builds on the Naked Objects Framework. After it was announced that the framework for building and deploying domain-driven (DDD) applications had entered the Apache Incubator, JAXenter caught up with Isis initial committer and long-time Naked Objects Framework committer Dan Haywood, to find out about this new project…….
JAXenter: What is the Apache Isis project?
Dan Haywood: Apache Isis is a pojo-based framework to enable the rapid development of enterprise domain-driven (DDD) applications. In other words, it takes care of infrastructure concerns to allow you to focus on the bit that matters to your business, the core domain logic.
Isis’ definition of “infrastructure” goes somewhat further than most though: not only does it take care of persistence, remoting and security concerns, it also takes care of the user interface too. It does this by automatically rendering your domain objects in a generic object-oriented user interface. This style of user interface is fantastic for building up (what DDD practitioners call) the ubiquitous language with your domain experts: they get a very direct representation of the domain objects and allocated responsibilities. This helps you as the developer too: you can focus on getting to grips with the intricacies of the domain rather than being waylaid by technical concerns. I probably should point out that some of the newer viewers we’ve been working on do also allow customization of the UI, so you don’t have to stick with the default views if you don’t want to.
Another important architecture pattern adopted by Isis is the hexagonal architecture: allowing both the front-end (i.e presentation layer) and back-end (persistence layer and related services)to be pluggable. That allows you to take your same domain application and run it as a webapp, as a client/server desktop app, or with a RESTful interface. You can also choose to persist your domain objects to an RDBMS, to a NoSQL store, or even (by the time we graduate) to the Cloud.
In terms of what Isis means to you, the programmer, it’s a matter of writing your domain objects as pojos following various programming conventions, and annotated with Isis’ own annotations as required. From this Isis builds up a metamodel which is then used to render the UI, to perform remoting, to interact with security, etc etc. You can think of the UI elements of Isis as being analogous to an ORM; but rather than reflecting your domain objects into an RDBMS, it reflects it back to the user.
Something else we’re aiming to do during incubation is to make it easier to extend and customize the framework. Much of the code base for Isis was donated from the (now superseded) Naked Objects Framework for Java. Some of that code dates back to Java 1.1, well before generics, before Spring, before many of the core JEE APIs. Right now Isis has a variety of own home-grown mechanisms for such things as bootstrapping, customizing and dependency injection. We’re aiming instead to
standardize on JSR-299 (CDI) for both JEE and JSE deployments, because we think that’s likely to become a popular standard for enterprise apps going forward. We hope that will reduce the learning curve for programmers wanting to bend the framework to fit into their particular architectural landscape.
Last but not least, we also hope to provide some “off the shelf” domain models, pre-tested, so that you can use them as a starting point for your own application. Suppose you need to send out an email, or render a PDF, or send a domain event to a message bus; or you wanted a Customer, Order or perhaps Communication object; or perhaps you wanted to use JodaTime or the timeandmoney library for your value types… the idea is to have modules available that you can import and then use or adapt.
JAXenter: Over the past few years, there seems to have been a resurgence in interest, in object modelling at the enterprise level. What do you believe is the driving force behind this?
Dan Haywood: I guess there are several possible explanations. I don’t know if any one of these should take all the credit, or whether it’s a combination of factors, but you’re right: enterprise object modelling is in vogue.
I guess the first driver I’d cite is domain-driven design, as popularized by Eric Evans’ book of the same name. Eric’s book is basically a patterns book, and I don’t think he necessarily invented any of the patterns he describes there (though some of the names are new). But what he did do very well was to bring those patterns together to form a coherent pattern language, while compellingly arguing the case
that we should devote the lion’s share of our development efforts where it matters: in the domain. Certainly, so far as Isis (and its predecessor, the NOF) goes, we’ve adopted the terminology of DDD because it helps would-be users understand which DDD patterns we try to support.
I think another factor is the rise of pojo-based frameworks such as Spring and Hibernate. Back in the “bad old days” of J2EE 1.2/1.3, domain objects were so polluted with infrastructure concerns that it could be very hard to even see the business logic, let alone have a conversation as to whether it was correct. The weight of those older frameworks also meant that refactoring was tiresome in the extreme, severely throttling back the feedback loop with the business domain experts and making the ubiquitous language that much harder to develop.
Another driver could be the maturing of web frameworks. With the first generation of such frameworks (typified for example by Struts 1) it could be very easy to have business logic creep into the web layer, leaving anaemic domain objects acting as little more than data holders. Newer frameworks such as Wicket and Tapestry avoid this by adopting a component model; and in so doing, it lets our domain objects remain rich.
Perhaps one further driver is the influence of agile development and TDD/BDD, a practice that gives us good quality, well-designed and of course tested code. I’m pretty sure that frameworks such as Spring wouldn’t have become so popular if testability hadn’t been so much of a concern, and if that hadn’t happened, then we might still be stuck with J2EE 1.2 and anaemic models.
JAXenter: At the project proposal, you state that attaining Apache Incubator status will help legitimise the “naked objects” concept. Why do you believe this concept has attracted criticism?
Dan Haywood: When I say “legitimise”, it’s mostly about exposing the framework and the naked objects pattern to a wider audience, hopefully so that we can pick up good new ideas and develop the framework further. As I indicated in the proposal, right now it seems that many Java developers haven’t even heard of the naked objects pattern. But there are frameworks out there that overlap to some extent with naked objects; I’m thinking of Rails, Grails and Spring Roo. However, whereas these other frameworks tend to use scaffolding / code generation for the non-domain layers, naked objects avoids the use of code generation completely. No code means no maintenance, and that keeps the feedback loop back to the business tight.
But yes, naked objects as a pattern has attracted some criticism, generally along the lines of “a generic UI would never be sufficient for my users, I need to be able to customize the UI”. We have two responses to this. The first is: you can’t really say that ’til you try it. There is in fact a substantial existence proof of the efficacy of the naked objects concept, namely the benefit administrations application that runs in a government department in Ireland. That app is used by 1500+ users daily, is responsible for administering over EUR 5bn a year in benefit payments, and still (and this is testament to the sort of well-crafted domain models you get by following a naked objects approach) still pushes out a new release every month, six years in. But the UI for this system is completely generic. To use the system the end-users obviously need to understand the domain objects, but they require very little other training: the interaction idiom is consistent throughout.
All that said, our other response to that criticism is somewhat more pragmatic: “if you can’t beat them, join them”. So, yes, the newer viewers that we’ve been working on do allow more customization of the UI. This is always optional; no customization and you’ll get a generic view, then layer customization on top afterwards if needed. I tend to think of it a little like denormalizing a relational database. With an RDBMS we start fully normalized, and then denormalize to improve performance. With a naked objects-style system, we start with a fully generic OOUI, then customize on the commonly-trodden paths where the interaction idiom needs to be slicker (improve the “performance” of the end-users, if you will). In a denormalized database, you selectively duplicate data. In a customized naked objects system, you selectively duplicate logic. The pros and cons are just the same.
All that said though, the CTO for the Irish government department tells us he doesn’t want to deploy these newer customizable viewers: his experience over the years of building apps (which bears out my own) is that the UI concerns can consume an inordinate amount of effort. He’d rather have a non-customizable UI if only because it removes the temptation to “tinker”; instead the team gets on focusing on the stuff that matters: the domain logic.
JAXenter: Does it seem likely Isis will encourage synergies between Naked Objects concepts and other Apache projects? At the proposal, you mention developing new viewers and object stores, for example a new viewer using Tapestry……..
Dan Haywood: Well, I do hope so. One of the newer customizable viewers that we’re bringing in using Apache Wicket, which I ended up working on as a result of a chapter I wrote for my book last year which described how to use Wicket as a hand-crafted UI for the original Naked Objects Framework. At the time I chose Wicket for that chapter because it was easy to learn, and was up-and-coming. I’m now hoping that some of the vibrant Wicket community might explore Isis’ Wicket OOUI viewer and help me develop it further.
You mentioned Tapestry, and yes, we’ve had an expression of interest in building a viewer in that framework. My understanding of Tapestry is that – like Wicket – it is also component-based, so it’d be great to see something put together by someone who really knows Tapestry well (in comparison, my own knowledge of Wicket is comparatively shallow). I’m really hopeful that we get something there.
Also on the UI front, I noticed that our Apache champion is also involved in the Apache MyFaces project. He doesn’t know it yet, but I’m going to see if I can cajole him into helping me get a MyFaces viewer off the ground, too
But probably one of the most significant integrations will be in terms of JSR-299. Our champion, again, is one of the leading lights of JSR-299 through the OpenWebBeans project, and I know of at least two others involved who are committers on that project. So their input is going to be invaluable to meet our objective of using JSR-299 to underpin the architecture of Isis.
There’s probably a dozen other Apache projects too that I can see synergies with – that’s the nice thing about targeting the middle domain layer, it touches everything. They include: persistence-oriented projects such as JDO, OpenJPA and CouchDB; integration-oriented projects such as Camel and WS; tying in with the Bean Validation project for JSR-303 support; not to mention the various UI frameworks such as Wicket, Tapestry, MyFaces, Click, Pivot, … the list goes on. I really don’t know how many of these will come to anything, but I’m looking forward to building as many bridges as I can.
So, I think that’s it. If I can just say before we close that, obviously, we’ve only just entered the incubator, so we have a good deal of work to do before we even get our first release out. But I hope a few people reading will be interested enough to follow our efforts (or even feel inclined to lend a hand!)