Wednesday April 21, 2004

Container? I don't need no stinkin' container! There's no denying it. A Boston Tea Party is swelling against Sun, the JCP and the way Java API's have been handed down from that Cathedral. Look at all of the bitchin' publications that've cropped up in the last few weeks and are expected in the coming weeks and months

Object-relation mapping without the container

A quick rundown of Hibernate, Spring Framework based transaction management plus a side order of DbUnit; more fun than you can shake a stick at.

Hibernate: A Developer's Notebook

O'Reilly has posted a sample chapter with a simple Hibernate example.

Hibernate In Action

The publish date on this is now listed as August 2004; I thought this was coming sooner but nonetheless seeing as how it's from the horses mouth, it should be a good read.

Java theory and practice: Coaxing J2EE out of the container
Projects like Somnifugi JMS blur the boundary between J2EE and J2SE

Discusses using JMS, JNDI and JMX for J2EE outside of the EJB container.

Expert One-on-One: J2EE Development without EJB

From the Spring Framework creator, Rod Johnson follows up on his fine 2002 publication "Expert One-on-One: J2EE Design and Development"

That's just the activity that's bubbled up through The Establishment. The J2EE blogosphere and TheServerSide is effervescing with stuff about Velocity, Tapestry, Jython, Java Groups, Pico, Hivemind, iBATIS and so on week in and week out. Struts and Ant are probably the prime examples of de-facto standards arising from outside of Sun but Hibernate has certainly opened everyone's eyes to the notion that the blueprints and the pet store aren't ominpotent and in fact, the whole "work inside our container API's and let the magic get handled for you" concept is pretty limited.

The bottom line for me is: I want to be able to easily test stuff outside of the containers and the mandatory interface implementations. Traditional J2EE, the practices promoted around it and the tools provided haven't accounted for that requirement. So the grassroots have.

Sun, consider yourself put on notice!

Due to space constraints, I couldn't get into it in my article about AOP (Aspect Oriented Programming: An Introduction) earlier this month but as I was looking around the landscape of AOP implementations and the related technologies (i.e. Inversion of Control) it's become increasingly apparent that Hibernate, Spring and an array of other projects that've gained momentum from the grassroots level are really the important story this year in J2EE, not Java Server Faces or EJB 2.1 or EJB 3.0 -- the J2EE developers in the trenches are tired of Sun groping around trying to get it right and they're pressing ahead with real-world solutions without Sun's official blessing. If useful standards can arise out of the open source ecosystem, then Sun's JCP, the insular and opaque JSR working groups and the Decisions From On High about what's important at JavaOne are likely to see their relevance ebb.

Hasta La Vista, Baby

( Apr 21 2004, 11:31:18 PM PDT ) Permalink
Comments [2]

Why Content Management Fails Jeffrey Veen of Adaptive Path published an essay, Why Content Management Fails, pointing out that all of the good technology in the world isn't going to provide a successful Content Management System (CMS) installation; getting the users on board is the real challenge.

Yes, you need a good software support system and competent IT help but if the users don't see themselves as publishers, if it's not ingrained in their psyche, it's not going to be a part of the core concerns. Dropping a bunch of tools in someone's lap doesn't necessary stoke their enthusiasm to use them. Creating structured content and collaborative creation is human activity that requires a mindset comfortable with the process. The tools are just there to help.

While Why Content Management Fails emphasizes CMS failures as a "people problem", IMO it also has a technical element: CMS developers aren't grokking their customer's requirements. Instead of imposing upon the users This Is How You Shall Work the toolset should be flexible enough to work the way the users want to use them. And Veen backs up my point

To have any chance of success, a content management project must follow the same user-centered design practices as any other project. Task analysis, rapid prototyping, usability testing - all of these methods are crucial to a CMS rollout. It is foolhardy to unveil a mammoth, nine-month project to an unsuspecting user community and expect adoption.

I predict that the proliferation of low end tools such as blogware (as in low cost, limited templating, story structure flexbility and workflow support) will drive increased awareness right down Main Street that the web is a read-write medium, that you can be a consumer and an author of content and that authoring will become just another part of how people think about their work and their lives. This will drive the demand for publishing tools more feature rich than blogware but without the bloat and absurd price points that most people associate with enterprise content management.

It used to be supposed that with Vignette's and Interwoven's fat market capitalizations in the dot boom daze that the CMS market is done, it's a solved problem. But look around and it's clear that it's still an open issue. The big enterprise vendors with their jumbo price tickets are in trouble. And the market is ripe for a new generation of tools. The writing is on the blog. ( Apr 21 2004, 01:47:51 AM PDT ) Permalink