Exposing the framework and the naked objects pattern to a wider audience.

Apache Isis Interview

Jessica Thornsby
Exposing-the-framework-and-the-naked-objects-pattern-to-a-wider-audience

After the Isis project entered the Apache Incubator last week, JAXenter asked initial committer Dan Haywood, about the new project…..


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!)

 

Author
Comments
comments powered by Disqus