BT

jMatter: Naked Objects with Swing, Hibernate, and Web Start

by Jason Lai on Jun 23, 2006 |
The jMatter framework,  Eitan Suez' modern implementation of the Naked Objects Architectural Pattern using Swing, Hibernate, and deployed with Java WebStart, has been open-sourced this week. jMatter produces 2-tier workgroup apps (Swing  front-ends  that  talk  to rdbms  back-ends) intended to be used in a LAN or VPN environment.  Developers using a Naked Objects style framework focus on building a behaviourally complete domain model and leave everything else (UI, persistence, etc) to the framework.  jMatter takes a domain model and then automatically provides the following services around the domain model:
  • A rich GUI built on top of Swing with support for CRUD operations. The GUI is constructed dynamically at runtime from the introspected model.
  • Persistence (by leveraging Hibernate)
  • Authentication -  the ability to login and to manage users.
  • Built-in support for query construction, invocation and query persistence in GUI
  • Support for the construction of wizards, calendaring (calendaring components), and more.

InfoQ spoke to Eitan Suez to find out more.  According to Eitan "The essence of JMatter is the generic implementation of aspects of business software applications" (the ones listed above)...Developers employing the JMatter framework do not write a single line of GUI code. Application development consists of modeling the domain in question.  Then one simply types "ant schema-export" followed by "ant run" and you're basically done.  So JMatter considers the GUI, the persistence, the query construction as plumbing, plumbing that it offers out of the box. Today, projects dedicate perhaps 80% of their development budgets to the construction of such plumbing, on a per-project basis.  JMatter's vision then is to free developers to concentrate on their customers' business domain."

By focusing on the domain model only, jMatter claims to offer 10x productivity for building Swing workgroup apps.  Jared Richardson (the author of "Dealing with Legacy Code" as recently published on InfoQ) called jMatter Naked Objects that actually work saying that it reminded him of Dave Thomas giving a Rails demo.

Naked Objects focus on the domain model sounds a lot like Eric Evan's vision of Domain Driven Design. On the similarities, Eitan said "Both advocate the same approach:  that to solve a customer's business problem, one must work closely and in collaboration with domain experts, to develop a model of the domain in question.  It is a process of exploration and it focuses on the domain.  Frameworks that follow the NakedObjects architectural pattern aim to provide the means necessary for developers turn that object model, complete with behaviours, into a running application."

On why jMatter was open sourced, Eitan said that one of his "aims is to build a community around this framework, strong enough to extend and evolve JMatter to support other architectures and different front-ends.  I am considering the construction of viewing mechanism targeting the web, based on GWT or a similar technology (such as Echo or wingS)." jMatter is currently licensed under either the GPL or its own commercial license. Eitan hopes to take jMatter n-tier within a year if the community is interested in it.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

yes, but... by Gerald Loeffler

for some time i've been following domain-driven development (as beautifully implemented in jmatter) from the distance with some interest. Initially, i was drawn to the intellectual purity of the approach (the model "is" the application), but i now think that there are very valid reasons why domain-driven development still remains a rather obscure approach:

1. on a pragmatic level, most GUIs need to do so much more than enable CRUD operations on objects: GUIs more often than not are excessively fine-tuned to deal with exactly those pieces of information that are required in each step of a complicated workflow. GUIs that, in each context, show more information than necessary, less information than required or simply show information not as nicely as they could are usually not acceptable. I think this amount of necessary fine-tuning of the GUI spoils the whole idea of domain-driven development.

2. on a more fundamental level, an object-oriented domain model often is an inadequate or inelegant model of reality. In particular, cross-cutting concerns that are best modelled through aspects are not apporpriately represented in an object-oriented domain model. The fact that jmatter explicitly supports login is an indication that they needed to deal with one cross-cutting concern (security) in an ad-hoc fashion. What about other well-known cross-cutting concerns like transaction demarcation, role-dependent views of objects, etc.? What i'm getting at is the feeling that domain-driven development idolizes the object-oriented model to a larger extent than is warranted, and that more flexible architectural approaches (for instance those that can incorporate AOP were appropriate) are actually better suited to deal with complex applications in an intellectually appropriate way...

It would be great to hear practical evidence that i'm all wrong, though!

cheers,
gerald

www.gerald-loeffler.net

Re: yes, but... by Eitan Suez

> most GUIs need to do so much more than
> enable CRUD operations on objects

i agree. i believe jmatter does *much* more than
enable crud operations. check out the screenshots
or the movie posted on jmatter.org or simply give
it a try.

> cross-cutting concerns that are best
> modelled through aspects are not
> appropriately represented in an
> object-oriented domain model

i wholeheartedly agree. i am not suggesting
that we restrict ourselves to oo techniques
to build applications. i am strongly suggesting
however that most cross cutting concerns should
not be coupled to the domain model. if this is
true, then implementations of cross cutting
concerns can be generic and should not be
re-ivented, re-implemented from project to project.

jmatter strives to be the implementation of a complete
set of cross-cutting concerns, such that all that remains is the construction of the domain model. the domain model "plugs in" to a framework that gives it persistence services, crud, authentication, authorization, query services, smart lists, reporting services, wizards support, and more.

DDD for the web by harish singh

Ja, Isn't there already a framework that purports the same pattern in Roma ? an open source project, it provides for cross cutting concerns like persistence (albeit by JDO), authentication, sessions et al. See www.romaframework.org

I don't have hand's on experience with Roma yet, but from Ethian's proposed extension to jMatter, it seems they both have a preference in Echo as a view technology.

Can someone with experience in Roma suggest their USP to jMatter ?

Re: DDD for the web by Eitan Suez

i just stumbled across roma yesterday. i'll try to take some time to learn what roma is all about. hopefully in a few weeks i'll be able to provide a meaningful comparison of the two. thanks!

Re: yes, but... by Dan Haywood


It would be great to hear practical evidence that i'm all wrong, though!


Well, the original NO framework is now live supporting the Irish Government's State Pensions Benefit administration system, with 90 online users. In the next few months there will be 3 or 4 other benefits being migrated onto the system, with a release every 3 months or so. So we very definitely have an existence proof.

What we're learning as we build more and more using NO is that the generic nature of the UI forces you to put stuff into the domain model that might otherwise have been omitted. The model is therefore a much more complete representation of reality - anything but inadequate or inelegant. The NO approach also clarifies concepts for the business themselves. My favourite example is that of "pre-payments" and "post-payments". This was mentioned in the original tender document, and informally it's clear what it means: a payment that hasn't been paid, and one that has. But the question we asked was: what generates these pre-payments to which the answer came back: it's what the customer is entitled to (as a result of receiving their pension). Eventually we were able to rename "pre-payments" as Entitlements, and "post-payments" basically became just Payments. Entitlements are pre-calculated (and may change retrospectively), while Payments are there to pay-off Entitlements when they become due.

Another nice example: right now we're working on central debt management. If the government pays too much to a customer (eg a belated notification of change in circumstances) then there is a debt that needs to be repaid. It wouldn't be appropriate to just demand repayment immediately, because the customer might be on very low means. So this gives rise to the idea of debt recovery strategies. Now in a conventional application who knows how these might be represented, but in an NO application there's only one way: as a domain object. Therefore the government officer can install a debt recovery strategy against the benefit (eg reclaim 5 Euro a week), and each strategy can take responsibility for determining its effectiveness etc. Now that's what I call a rich domain model.

Congrats to Eitan on jMatter. I too am writing a NO-style framework (called Essential) using Eclipse RCP, Hibernate, Java 5 et al. Realistically it's gonna be a while yet before its ready, but look out for it next year...

Dan

Re: yes, but... by Gerald Loeffler

Dan,

thank you for your feedback based on the NakedObjects Irish pension project. Your examples stress the importance of a rich and precise object-oriented domain model - and i would never disagree with that. I can also see that the "pure" approach taken by NakedObjects and jmatter helps in focusing on the domain model - it is, after all, allmost the only artifact that the programmer explicitly produces!

What i did question, however, were 2 aspects of the domain-driven development approach which you do not seem to address in your response:

2. the practical importance IMHO of cross-cutting concerns like security which do not fit nicely into an object-oriented domain model. E.g.: only managers are allowed to read/edit certain properties of domain objects.

1. the fact that UIs need to be much more sophisticated than to provide CRUD operations on domain objects. E.g.: the workflow to create a new pensions claim requires additional authorisation steps if the final salary is above a certain amount. And when editing an existing pensions claim auxiliary information from related objects is to be displayed.

Thanks for taking the time to answer and good luck with your next project phases!

cheers,
gerald

www.gerald-loeffler.net

Re: yes, but... by Dan Haywood


2. the practical importance IMHO of cross-cutting concerns like security which do not fit nicely into an object-oriented domain model. E.g.: only managers are allowed to read/edit certain properties of domain objects.

Indeed, OO models are not a particularly good way of expressing cross-cutting concerns. AOP is a much better solution for that. To be more precise, we can use OO to model the security domain (roles, permissions etc), but should use AO to apply those concepts over the business domain.

In Ireland we have done this by writing an intercepter between the GUI and the domain model. This determines the id of the feature being interacted with (eg ie.welfare.common.Customer#firstName) and then does a lookup into the security domain to determine if the current user has access. This does require a way of mapping permissions and also identities between the two, and this is done use value semantics (the string representing the feature) rather than reference semantics.


1. the fact that UIs need to be much more sophisticated than to provide CRUD operations on domain objects. E.g.: the workflow to create a new pensions claim requires additional authorisation steps if the final salary is above a certain amount. And when editing an existing pensions claim auxiliary information from related objects is to be displayed.

I think if the model is rich enough, then the UI will be sophisticated enough to. I always find applications (or video recorders for that matter) difficult to operate until I've mentally "got inside" the original developer's head. What that really means though is until I've understood the domain model that the UI has usually obscured.

Regarding the workflow example you give: in Ireland we have a Case object that represents (and indeed replaces) a manilla folder of stuff and correspondence relating to a customer's claim for a pension. In order to do any work relating to that claim, the government officer must assign the case to themselves. We have also wrapped quality control stuff into Case.

But the decision about a claim going above some threshold is a responsibility of the claim itself, and so should be modelled in the state chart of that domain object. Yes, that does mean that if the threshold changes then the code needs to be redeployed, but those sort of changes to business process aren't made overnight in a government department. And we don't mind retesting and redeploying: that's why we have full unit tests.

The point about auxiliary information from other objects again comes down to factoring the model correctly. The Customer object is very large, but it has a collection of Names (previous), Addresses, Debt, ContributionHistory, Birth, Marriage and Death, and Relationships. Each of these is displayed as an icon in summary form, but can be opened up and edited directly from the Customer. Anywhere you find yourself using a group widget in a UI to group together some information, you probably are obscuring the fact that there's a domain object as yet unnamed. Why would you want to group that information together otherwise?

Hope that helps.
Dan
www.essentialplatform.org

Re: yes, but... by Felix Leipold

for some time i've been following domain-driven development (as beautifully implemented in jmatter) from the distance with some interest. Initially, i was drawn to the intellectual purity of the approach (the model "is" the application), but i now think that there are very valid reasons why domain-driven development still remains a rather obscure approach:

1. on a pragmatic level, most GUIs need to do so much more than enable CRUD operations on objects: GUIs more often than not are excessively fine-tuned to deal with exactly those pieces of information that are required in each step of a complicated workflow. GUIs that, in each context, show more information than necessary, less information than required or simply show information not as nicely as they could are usually not acceptable. I think this amount of necessary fine-tuning of the GUI spoils the whole idea of domain-driven development.

I think domain-driven design and naked objects are orthogonal paradigms. So you can also add an application layer on top of your domain layer. I am a strong proponent of the notion that there should be nothing in the UI that is not in the model, i.e. in some kind of presentation model or application facade.

The cool thing with NO is, that you can also expose these application facades as (transient) naked objects. You can even allow the user to persists those facades, which allows for customization of the application.

The wizzard mechanism in jMatter is an excellent implementation of this idea.

Re: yes, but... by Gerald Loeffler

Hope that helps.


It does indeed! I think it's fantastic that you took the time to relate my concerns to your actual project experience: it surely does help me (and hopefully others as well) understand how you approach non-trivial problems with domain-driven development:

Your approach to dealing with cross-cutting concerns is pleasently familiar to how you would architect the solution with more mainstream Java EE stacks. Your take on complex UIs is very consistent with the domain-driven approach and i have to take your word for it that it works sufficiently well in your project (although i remain sceptical about the typical users ability and willingness to approach UIs as systematically and logically as you seem to ;-)

cheers,
gerald

www.gerald-loeffler.net

Re: yes, but... by Eitan Suez

i am most impressed by the quality of this discussion.

i'd venture to say that there is
a strong common thread between the ideas behind j2ee
and nakedobjects.

j2ee was all about separating concerns, so that transaction
and security aspects of an application were applied in a manner orthogonal to the domain. with ejb3 we're seeing this applied to persistence.

nakedobjects adds the user interface to the list of services, alongside security, transactions, etc..

imho, the more aspects a framework "covers" or addresses "out of the box", the more complete it is.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT