The Naked Objects group has announced the Milestone 1 release of Naked Objects version 3.0, downloadable from sourceforge.net/projects/nakedobjects.
In this article, the Naked Objects group looks at new features included in the release. Among the changes are a POJO programming model and integration with Hibernate.
Many people first heard about Naked Objects through the Naked Objects article series on TheServerSide in 2004. These articles provide a summary of the Naked Objects concept and of its benefits.
What do you think of Naked Objects, and the new features included in this version 3.0 release? Are you using Naked Objects?

Our current position is that once version 3.0 gets to a full release (sometime next year) we will offer a commercial license on the framework for people who either want commercial support and warranties, and/or who do not wish to work within the constraints of GPL.
Sorry, we don't yet have a pricing structure yet - our priority is working on the framework at present - except to say that it will probably be a per server/CPU license, and the pricing will be realistic and competitive compared to other application server options.
We have provided commercial support on earlier versions, but to date these have always been as part of a development contract. If you need any more information, please get in touch with me via www.nakedobjectsgroup.com.

Our current position is that once version 3.0 gets to a full release (sometime next year) we will offer a commercial license on the framework for people who either want commercial support and warranties, and/or who do not wish to work within the constraints of GPL.

Sorry, we don't yet have a pricing structure yet - our priority is working on the framework at present - except to say that it will probably be a per server/CPU license, and the pricing will be realistic and competitive compared to other application server options.

We have provided commercial support on earlier versions, but to date these have always been as part of a development contract. If you need any more information, please get in touch with me via www.nakedobjectsgroup.com.

I'll get in touch about money specifics.
But I think it would be nice for everyone to know how the GPL affects usage. Since the framework uses the code I would write and not the other way around, is it more like an app running on Linux?
I typically avoid GPL software becuase of this confusion, unless it is clear (Like creating a custom app and running on Linux) what the rules are. But I have been interested in Naked Objects for a long time (way before the previous article) and the concept is valuable enough for me for me to try to figure out the issues.

Mark
Our intent, as I think you would expect, is that if you are developing an application for in-house use only, or for distribution externally under an open source license, then you would be fine using Naked Objects under the GPL.
If you are intending to develop a proprietary application for distribution then we would expect you to take out a commercial license from us.
But we accept that there is ambiguity in regard to the GPL - I had a long discussion on this will Richard Stallman himself some years ago.
As you have observed, with Naked Objects 3.0, your POJO domain objects are no longer in any way dependent upon the Naked Objects framework, and could therefore be distributed without any issues.
However, when you move from a prototype to a full implementation, you will need to write proper implementations for Repositories and Factories. The amount of coding for this can be very small indeed, but necessarily the Repositories and Factory objects must call servcies in the (injected) application container in order to create and persist objects such that the framework can manage them. So there would be a dependency there. This is not a deliberate trap - it is unavoidable from a technical perspective.
We will clarify our position on this formally in due course. Meantime we're willing to work with anyone to find a solution that's both flexible and fair.
Richard

Richard,
Thanks for your reply. That bascially answers my question. I'll have to wait on apps that I distribute till you all can clarify your position.
I've been looking at NO for, it has to be, about 4 years. And I look forward to where NO and all of the projects like it are heading.

Mark
We are actively discussing the issue internally right now as it happens. If you send me your email (to rpawson at nakedobjects.org) I'll update you when we have a resolution. Or, if you prefer, you can keep monitoring nakedobjects.org website (which has recently changed to a Wiki to allow posting of discussion against any of the pages).
Richard

As with the original NakedObjects stuff, this is very innovative and pretty impressive, especially basing the app on a POJO domain model. And I like the idea of the CLI. I guess this makes it easy to script apps.
I also appreciate the fact that this framework is being used in a serious high-volume production environment. That is the quickest way to find any flaws/limitations in both design and code. Means I should be able to use it with a greater degree of confidence.
But I still have a nagging doubt about frameworks that presume that the domain model can also model the user interface one-to-one. RoR falls into this category too. My experience is that users don't think about their work in terms of the entities, but rather processes and actions, ie. use cases that operate on entities. Does this framework allow use cases to be coded that drive entity interactions? Do my use cases become entites themselves in the domain model? Are there any examples of this in action?
Even with this, NakedObjects has my respect for one.
Kit

I understand your point, but I think that to the extent that users 'think in terms of processes and use-cases' this is only because they have been trained into this way of thinking by prior systems methodologies and implementations.
Certainly we have encountered the issue - though it has been more from systems people than from the end users. I have on many occasions been told by systems people present at my modelling sessions that 'we HAVE to start with the processes/use-cases'. I have always resisted that and forced them to start from the nouns. Once I have overcome that opposition, I have found that users and senior business people have no difficulty whatever grasping the idea of starting from the objects. I am a big fan of Eric Evans' Domain Driven Design - just listen to the language they are using. Granted this is sometimes ambiguous: the difference between 'change an Address' and 'do a Change Of Address'.
What it comes down to is the difference between a Verb-Noun style of interaction and a Noun-Verb style - clearly we favour the latter, whether it is through a drag and drop GUI or a command line interface. There is research showing that the noun-verb is more natural, and certainly more expressive.
To answer your question, it would be possible in theory to drive a Naked Objects application from some explicit representation of the use-cases/processes, but I suggest that in practice this would defeat the advantage: in two different ways. First I suggest it would lead to a poorer UI; secondly I suggest that it would lead to a poorer object model. If you'd like more evidence for this claim, I would point you to my PhD thesis on Naked Objects, which can be downloaded from http://www.nakedobjects.org/downloads/thesis.pdf

Richard/Dan,
I suspect it varies from situation to situation. I work at one of the oil majors and life is pretty prescribed, not just in what gets done but how it is done. In this case, users expect systems to work pretty much as they always have done, and OO UIs are still a bit cutting-edge for some of them.
That said, I think when most business users think of implementing new requirements, they understand what the required "blob of functionality" needs to do before they understand all the nouns and their relationships. Granted once the domain model is understood, it may be quicker to work in a more OO way. This is interesting as it is the UI equivalent to the programmatic pattern of having a complex underlying model and providing a facade with a simplified API to handle standard use cases. IMHO both approaches are valid and important.
Keep up the good work!
Regards
Kit

This is interesting as it is the UI equivalent to the programmatic pattern of having a complex underlying model and providing a facade with a simplified API to handle standard use cases. IMHO both approaches are valid and important.

We're just reworking part of the DSFA application at the moment to do something like this. Originally we had the notion of a "case" object that managed correspondence, did simple workflow and also had a part in quality control. This is rather a lot of responsibilities! We're now refactoring the workflow and QC stuff into new "task" objects that have more functionality. However, the case object still delegates to the underlying task object, acting rather like a facade as you say. For "more sophisticated" users, the task object functionality is there if they need it. Later on, we'll probably remove the workflow functionality from the case object altogether.
Another example: the Customer object has a number of sub-objects that represent Name, Birth, Marriage and so forth. For most of the time these can be ignored, but they are there if required.

But I still have a nagging doubt about frameworks that presume that the domain model can also model the user interface one-to-one. My experience is that users don't think about their work in terms of the entities, but rather processes and actions, ie. use cases that operate on entities.

Having worked extensively with Richard and Rob at the DSFA, I can assure you that there is no problem. Because the entities are tangibly "there" in the UI, users have no problem in identifying with or understanding them. And when I'm working at the DSFA offices, I can assure you that users and technical guys alike communicate exclusively in terms of these domain objects.

Does this framework allow use cases to be coded that drive entity interactions? Do my use cases become entites themselves in the domain model? Are there any examples of this in action?

Yes, you can model use cases as entities. At the DSFA there are a couple of examples. One is the Pension take-on sheet, which allows the officer to quickly upload a customer's pension contribution history. The take-on sheet itself is never persisted, it is merely a "means-to-an-end". Another example which is being considered is a "QC review sheet" to allow a quality control officer to quickly review a collection of changes before signing them off. Again, this review sheet (if we do it) will be transient, but it will used to update each of the actions it references.
So, the NO approach does allow for this where necessary; however it should be the exception rather than the rule.
HTH.

Thanks for the very interesting article and ongoing discussion.
I just have a question :
- if someone wants to "drive" some interactive Java2d graphics from the Naked Objets framework, is it possible and if so what does it involve ?
Thanks in advance
ZedroS

There are two possibilities.
The first is to extend the existing viewing mechanism to add graphical representations. The trick here is to come up with a generic interface. For example, you might decide that any domain object implementing the 'HasMapCoordinates' interface should allow the user to view it via a map viewer. We have plans to do a number of these ourselves, but not any time soon, unfortunately.
I won't pretend that extending the viewer is easy. It's not well documented at present. Robert has committed both to improving the documentation in that area and to refactoring the viewing mechanism to make it much easier to extend, in one of the next few Milestones. It is certainly our intention to encourage the development of new viewers by other people.
The second option, less elegant but easier in the short term, is to write a conventional front end that accesses the same domain objects either in parallel with the default Naked Objects UI, or in place of it. This would be easy. If you ran Naked Objects within an application server such as JBoss you could get access to the objects as Beans, or expose them through web services. Seen this way, Naked Objects is just a technique for rapid prototyping (i.e. without the graphics) and, most importantly, for encouraging good object modelling.

Another question : currently we see a strong move in favor of RCP platform, be it Netbeans, Eclipse or Spring RCP.
Regarding Netbeans and Eclipse, the RCPs provide some interresting feature, like an update module, some predefined UI widget and the like and a module based architecture.
Furthermore, they allow some "business model developpers" to focus more on the business than, say, how to use a Jpanel to add a "Close" button on each panel.
As such, when looking at a framework like NakedObjects, I can't stop wondering :
- would an integration with some RCP app provide some value ?
- if so, is there any plan to go in this direction ?
Thanks (again) in advance
ZedroS

As such, when looking at a framework like NakedObjects, I can't stop wondering :- would an integration with some RCP app provide some value ?- if so, is there any plan to go in this direction ?

Indeed. I started work last year on a framework called Essential (http://www.essentialplatform.org) that runs on Eclipse RCP and implements the NO pattern. While still far from finished, the intent is for this to be a complete reimplementation leveraging Java5, AspectJ, Spring, JMS and EJB3/Hibernate.
In the meantime, though, the NO framework is far ahead of where I am. Therefore, I am working with Richard and Rob to open up the NO framework with a series of APIs such that Essential and other compliant frameworks can use the NO runtime, eg distribution, persistence, security, transactions etc.
As Richard has said, we'd like there to be a whole set of framework that implement the NO pattern (just as these days there are umpteen web app frameworks). However, since an NO app is pojo-based, we hope that there could be complete compatibility between them. Indeed, one might then think of the NOF / Essential as "containers", akin to an EJB3 container or servlet container.
Hope that helps. And if you'd like to contribute...!
Dan

Hi Naked Men !
First off, congrats for this release, and glad you posted a news here !
Actually, I tried NO a few years ago, and loved the concept. But unfortunately the generated UI wasn't fully usable according to my clients, and so I got back to hand-written UIs (not mentioning coding the whole damn back-end stack again !)...
Life being a continuous circle, I discovered JMatter a few months ago, and got back in the Naked mood.
I'm currently playing with it, and so far I'm pretty happy with the generated UIs, even if, of course, you can find things to improve.
The dark side of it is, IMHO, the programming model. Don't get me wrong, it's pretty simple and works fine, but it's not POJO-based (you have to extend some base class in your objects).
Apparently you score on that topic :-)
Could you give a short comparison between the two products ?
Also, is there some online doc available (tutos, examples, screen shots, ...) ? I tried to follow some links (sf, wiki, NO Group) but I found no technical info there...
Thanks for all, and keep up the good work !
Have fun,
Remi

Remi
In the download there are a number of simple demonstrations. The Demos folder contains standalone executables, and the Examples folder contains the same simple applications, but capable of being build (using Ant) and run with Hibernate persistence also. In all cases you can run the demos or examples with the 'Drag And Drop' UI or with the Command Line Interface.
The download also includes the documentation in .pdf and .html form.
I'll leave to to someone else to make the comparisons between Naked Objects and JMatter, as I would hardly be unbiased! However I will confirm that Naked Objects 3.0 is certainly POJO based - the domain classes do not need to inherit from anything. When you want to be able to save an object you will need to get hold of the container, and if you provide your domain object with a getter and setter for the container, it will be injected automatically by the framework. If you want to do this from many domain classes, then you can save some time and effort by inheriting this property from the top of the tree but that is purely optional. In the Expenses example, all domain classes inherit from a simple 'Contained Object' superclass - but I stress again that this was the programmer's choice (mine, in that case). A alternative would be to use AspectJ to add that capability to all domain objects that needed it.
Richard

Hi Richard,
Yes, I've downloaded the distro, tried the examples and found the docs (sorry for the stupid question, should have tried before asking once again)...
Impressive to say the least :-)
For the JMatter vs NO comparison, I would have *loved* to see you and Eitan Suez defend your respective implementations of the pattern, point by point.
Who else can talk about that better ?
I really think we (potential users of your frameworks) miss that in order to make our choice.
Reviewing all this is doable, but the problem is that we (application developers, with clients pushing behind) usually don't have the time to do so :-/
We all have specific requirements that are not addressed the same way in the two frameworks. So even if trying out is really easy with each of them, a quick feature comparison would really be nice.
I also honestly think you and Eitan are bright people, and that you should be able to layout a real comparison, without fluff.
Maybe you've already done this in private ;-P
I'll probably have a lot of questions to ask about your framework when I'll be back on this... I'll ask on the sourceforge forum then.
Thanks.
Have fun,
Remi

Was about to work through the book and learn how to use the naked objects framework but nothing in the book seems to work with this new version of the framework. Is there some intention to produce an updated version of the tutorial at all???

The book was written when Naked Objects was in version 1.0. While many of the principles remain the same, the programming examples in the book will not work with Naked Objects 3.0. We make that clear on our website.
There is a tutorial included in the documentation that comes in the Doc section of the download.
(We would like to see the book updated, but it was an expensive book to produce - due to the colour - so we don't want to do it while some aspects of the framework are still changing.)

I am currently writing my final year project, my thesis is based on a project I am developing around the naked objects framework.
The problem I am having at the moment is that I wish to use an instance of an class rather than a factory or respository within the drag and drop exploration. Is this possible as all my efforts so far to do this have so far been unsuccessful.
If not is there a way in which you could create an application in which an instance of a class rather than the actually class itself is given to the user??
For example in your bookings example instead of the user having access to the customer class they would only have access to an instance of a customer say Josh for example and then all other classes (bookings, cities, locations, etc) worked as normal????

Hi,
I am currently working on a project using naked objects. I am using dates fields an have noticed that the UI does isnt very helpful when it comes to helping the user to input a date.
Would like to know if anywork is being done to rectifiy this??
And also if anyone has any pointers on how I could go about modifying this myself would be very greatful.
Thanks
Josh

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.