So this is a little heavy for my first blog entry, but I figured I’d start out with something that at least sounded interesting before I resorted to “What I installed on my computer today” style entries. On my current project we’re dealing extensively with J2EE Entity beans. There are some legacy ones using BMP that we’re moving to CMP and some new ones that are being written CMP style right off the bat. So, this gets me thinking about where the business rules live…

Here’s the situation: we have a set of legacy BMP entity beans with business rule validation in the setters and getters. We need to move those to CMP beans at some point the future. I’m aware of the Antipatterns book about subclassing the bean to allow easy migration, etc. That’s not what this is about. This is about how to validate the data moving in and out of the bean in the context of the larger system.

Obviously once we move to CMP we end up with abstract setters and getters, so that’s not going to work. I don’t feel like the logic should be there in the first place, but that’s a different story.

Then there’s the option of putting it in ejbStore, but I feel like that’s too late to really do anything useful (other than punting on the commit) and really makes me feel… dirty.

So, move it up to the next level, start building a services based approach. A clean, subsystem like API that can enforce business rules; once everything checks out, persist the bean. However, this seems to push back against the idea of using local interfaces and hitting the entity beans directly in favor of BO’s or DTO’s or whatever you want to call them.

We’ve chosen to go the subsystem route with BO’s coming in and out of the APIs. That gives us a cleaner layering where the subsystems (session beans) handle validating and persisting their information using entity beans but the rest of the system passes BOs around.

Thoughts?

Related link: http://www.flickr.com/photos/88189111@N00/sets/794898/

While most people were enjoying a relaxing weekend, I really needed to stay up until 2 AM this morning and create graphs of FOAF “networks”. Instead of 8 hours of sleep, I drank far too much soda, and did battle with Python’s ClientCookie, O’Reilly Connection, Graphviz, and FOAF. The results are on Flickr…

Read more…

Maybe if someone had a FOAF feed that also included links to DOAP documents we could create a political map of open source?

Related link: http://getahead.ltd.uk/doctree/

I’ve been programming in Java for years, and JavaDoc is
still a real pain. I’ve got a whole collection of bookmarks to the JavaDoc I use - namely J2SE 5, Hibernate 3, Spring 1.2, and various Jakarta Commons JavaDoc pages. When I really need to refer to some JavaDoc, I almost never have it loaded and I have to rifle through a huge alphabetical list of classes. Ick. I know there are better ways….

Anyone know of any other useful JavaDoc aggregation sites out there?

Related link: http://www.gnu.org/software/emacs/emacs.html

Yeah, it’s a slow news day, but after reading Derek Sivers’ Lovesong to VIM, I thought it was time to invoke The Great Holy War. I couldn’t let the day end without giving a shoutout to Emacs.

I’m not even going to engage in a debate for something that is already established as scientific fact. To do so would be giving credibility to the wild accusation that vi can even compete. I leave you with some lisp-poetry.

Fear ye the mighty power of Emacs. It yields to no one and lights the path to true enlightenment. Dare not disturb Emacs with erroneous key strokes.

Related link: http://www.datadosen.se/riverlayout/

I continue to be surprised how often I get mail from Swing developers who’ve just discovered RelativeLayout and are now using it in one project or another. This past week I heard from two new people, one of whom turned things around by introducing me to his own layout manager project. It looks quite promising!

David Ekholm’s RiverLayout leverages HTML intuitions to allow you to control the position of user interface elements within a container. You don’t need to learn about and understand constraints. You don’t need to construct a bunch of objects to represent them, or write an XML configuration file. You just add elements to the container in a concise and readable way. It looks noticeably quicker to get started with than RelativeLayout, and eminently suitable for the kinds of dialog and window layout that make up the bulk of tedious application coding.

Rather than describe it any further, I’d encourage you to check out its own site–the URL is at the top of this blog entry.

What other nifty layout managers do I need to know about?

Related link: http://dev2dev.bea.com/pub/a/2005/08/jvm_aop_2.html?page=1

Aspect Orientation (AO) is still on the outskirts of the developer community, waiting for its time in the limelight (I for one hope that that will not be too far off) and this article by Alexandre Vasseur, Jonas Boner and Joakim Dahlstedt aims to show how the power of the AO approach can be applied, often more efficiently, at the JVM level.

The concept of doing all the AO work at the JVM is not necessarily a new one but full marks to Jonas and the guys at JRockit for creating what is a really nice set of API extensions that in turn take advantage of the AO JVM optimisations. The danger was that this approach would tie you to one AO language or framework, but the JRockit team have avoided this by providing the underlying constructs with which AO programming can be achieved. So, in many ways they have built the foundation upon which AO languages, such as AspectJ could potentially take advantage of runtime optimizations, if and when the JVM supports it.

However, there are a couple of down sides-aren’t there always. Much of the static cross-cutting behavior, the ability to change the actual static structure of your classes, that is part of so-called heavyweight AO implementations such as AspectJ is not really present in the JRockit JVM AO extensions. Not surprising really as these tend to be advanced AO problems, and many lightweight frameworks don’t include them anyway.

Another problem is likely to be that this approach for implementing AO in the JVM is totally non-standard right now; heck, the guys at JRockit are not pretending that it is. One thing their effort does show though is that AO in the JVM can work and be implemented in a higher level framework independent way. So rather than presenting their work as the AO implementation, the JRockit team have really just made the first important step towards potential standardization of AO support, focussing clearly on the JVM level.

All in all, this is a nice attempt at pushing the boundaries of AO implementations and so hats off to the guys at JRockit. Time will tell if this makes a real impact, but the sooner they release the prototype implementation (ideally so that I can run it on my Mac) the better.

Looking to the future I can see some really great opportunties for AOP that is integrated into the JVM, especially in managing large application feature concern updates. It would be great to here from you if you have had some success in doing this (using regular AOP frameworks or something more JVM-centric).