techno.blog("Dion")

I have been having fun with Tapestry for the last couple of days. It really is a breath of fresh air compared to some of the Other frameworks.

Although request-based frameworks allow you to get the job done… and there are some good ones out there (WebWork 2 is great)… I am really enjoying a more component/event-driven approach.

A long long time ago, in a galaxy far far away I remember writing a web templating system. One of the major goals was that the HTML “templates” should be WYZYWYG/browser preview friendly. This was very much needed based on the way that we built websites, and how the designers were in the process.

Ever since then I have shed a tear or two when I see lots of evil markup which makes a system non-web designer friendly. JavaServer Faces unfortunately seems to take the cake on this one with its <f:use_faces> …. and just check out a table based on facets!

As soon as you start to work with components, this holy grail becomes hard to find… however I really like that Tapestry tries hard at this goal.

There are definitely cons to this approach. You could argue that having a conditional look like:

<span jwcid=”@Conditional” condition=”ognl:isFun”>foo</span>

isn’t as easy to view as:

#if ( isFun )
bar
#endif

However, being able to have real HTML makes it worthwhile, and after a few minutes you can get it.

Having this HTML approach is just one thing that I like. What I really like is how the I can’t put code in my view, and how the low level servlet stuff is just really hidden nicely. This is great stuff. Thanks Howard.

I just saw Geir Magnusson Jr. and Jeremy Boynes entry discussing the problem that we have with persistence at this moment of time.

I have personally written about this before here, here, and here.

But back to the blog from Geir and Jeremy. The go through the problem at hand, and notice that we all want the same thing:

Give me a transparent persistence API

It looks like we can agree on that. So then the next question is how do we get to that path.

It seems like a no-brainer to me that we should use JDO 2.0 to get there, but I am of course biased. JDO shouldn’t only be in J2EE, it should be in J2SE in my opinion. You know, sometimes I want to access a data source WITHOUT being in an enterprise environment! I definitely want to do this without having to have an EJB container.

It is great to hear this from some of the Apache guys, and I look forward to us all coming together to work on the same problem. If we got in the same room we would find out that having blue eyes or brown eyes don’t matter. We both see.

Persisting Problems

Eclipse is a great product, don’t get me wrong. But I have such a tough time keeping things in sync.

It means that:

a) I have multiple versions of Eclipse
b) I keep spending time “trying” to see if the latest plugin works on the latest Eclipse version

Then, add the fact that eclipse plugin X has a dependency on plugin Y and you soon are driven nuts :)

I am really glad that 3.0 is in RC1 and that the API shouldn’t be changing, so hopefully the plugin writers have time to catch up and I can just use 3.0 :)

Until then, I will keep using IDEA unless I need to do AspectJ (in which I use AJDT), Tapestry (Spindle, or the cool Eclipse profiler plugin, …

Scott Crawford has written up his thoughts on the EJB 3.0 process.

Scott is an independent member of the EJB expert group, and his thoughts are very interesting.

I agree with a lot of the comments that he made in his various articles on the topic, however I do dissagree (of course) with the following:

Since I am not a world expert on object persistence but I do want to do the right thing I listen carefully to these arguments. But I also try to take a step back and look at the big picture. A persuasive point for me is to consider the fundamental design goals of JDO and of the O/R tools. One of JDO

There has obviously been a lot of buzz that cropped up after the EJB 3 announcement at TheServerSide Java Symposium. On the one hand, it is very impressive that the JCP is making a bold move…. and really trying to make EJB simpler to develop. Although it is great to see this happen, I can’t help but find myself confused when it comes to the persistence side of the equation.

JDO vs. EJB: Technical differences

There are a few technical differences between what looks to be in EJB 3 (which is still in VERY early stages by the way… and who knows when IBM will wake up ;). Gavin blogged about some of the issues he has with JDO, and I appreciate him coming out in public. I think it is really important to have these discussions in the open, and we are very lucky here with Gavin.

However, if you look at the points raised (e.g. JDO-QL isn’t as he likes, and persistence-by-reachability), I think they are fairly minor. Both JDO 2 and EJB 3 are not finished, however if you look at the features sets as they stand today, you will see many more similarities than differences. They are SO close that it isn’t even funny. In fact, they are so close that I don’t understand why Gavin and Oracle (who announced they are leaving the JDO expert group by the way) wouldn’t want to discuss them more. I know the expert group has really enjoyed having both of those parties involved, and together the java-persistence world is a great force.

So, the technical discussions between JDO and EJB have started. I hope they continue. However, I am actually more concerned about looking at the forests instead of the trees.

Do one thing. Keep it loosely coupled. Do it well

I really do not understand why persistence has ever been coupled to EJB. Persistence is a cross-cutting concern, that needs to be solved in AND out of the enterprise.

Let’s take a look at two alternate universes:

1. JDO and EJB working together

Imagine if the persistence experts from both the EJB side, and the JDO side all got together. JDO would become a fantastic persistence standard (in fact I think JDO 2.0 already is…). From the EJB world, we would make sure that JDO is written in such a way that it fits in perfectly with the needs from that side of the house. JDO has always tried to do this (working with J2EE CA, EJB transaction model, etc)…. and I think it is very important.

So, now we have a top class persistence spec, which would be ready to roll pretty darn quickly. EJB 3.0 can now get rid of ALL of the entity baggage (what is the % of the spec?). They can focus on making the programming model lean and mean. Session beans will be so clean to write, Message Driven beans a pleasure, and we have a chance to handle more. EJB should be all about transaction processing, and handling true enterprise needs. Now the expert group can spend time on a half decent security model, a nice thread worker pool for the times in which you need them, an interceptor stack, and things the enterprise truly needs.

Wow, as I type this I feel happier. Wouldn’t this all be great? Wouldn’t this be something we could be proud of? Now if you say “I use EJB” people say “I am so sorry”. In this alternate universe that would disappear. Let’s get back to the current real world though :(

2. JDO and EJB fighting, or ignoring each other

As it looks right now, we have two separate camps. There will be infighting between them. Developers will find it hard to choose which technology to use on their project. If an application isn’t an enterprise application they can simply plug into JDO. Then imagine if they want to migrate it to an enterprise app… would they want to change it to EJB 3?

Why wouldn’t you want universe #1?

I am finding it really hard to understand what sane person wouldn’t vote for universe #1. Please correct me if I am wrong here, but are there any technical reasons for this?

The only reason I can come up with is political: Vendors want the lock-in that they get with the current tight coupling of their persistence engines to their EJB container

Take a look at the EJB specs, and how:

(EJB 2.0 spec, page 509)

“We plan to provide the following in future releases of the EJB specification:

- specification for the pluggability of Persistence Managers

Why has this been on the list for all of time with respect to EJB? Isn’t it time to get around to this yet? I worry that the only reason is that vendors are scared. They want their container to be tightly coupled to their persistence engine. This actually seems so bizarre to me. I think it would be in the vendors interest to open this up. At one time the CMP engine was a main differentiator. Now we have moved up the stack, and there are plenty of others areas. The application server is becoming a commodity, so lets open up the bad boy and move on.

If we were writing code that tightly coupled items such as business objects with persistence, we would make fun of ourselves.

Let’s go for a brave new world

I really hope we end up at universe #1 one day. At this point the EJB spec will just be a standardization of some enterprise services. When it makes sense, sub-specs can be created allowing us to divide and conquer. We can work on the sub-parts in parallel, and experts in those areas can work on doing the best job they can.

I have been honored to work with the JDO expert group members. There are too many of them who are far too knowledgeable of the world of transparent persistence, and ORM, to not be part of the biggest effort.

As Marc Fleury himself would say… let’s take the red pill ;)

Linda DeMichiel was asked if EJB 3.0 would have to be backwards compatible. She immediately said yes.

What would it mean if the backwards compatibility was made “optional”?

• Containers like Spring could support EJB 3 (they are not going to put in support for EJB 2.1 and below!!!)
• Other projects could ramp up to support the more lightweight EJB 3 model
• Other vendors could make a choice on whether they want to support a backwards compatible version. They could even offer two versions!

Would the world be so bad if this was an option? Users would have a choice. If the backwards compatibility means a lot to them, they can choice a vendor which has the optional “Supports 2.1″ checkbox.

The programming model is changing so much, that I think it would be fair to not burden EJB vendors with The Old Ways.

What are the reasons to mandate backwards compatibility?

• Politics: Current EJB vendors have already implemented it, and can use this as an advantage. It keeps the likes of Spring out of the game.
• The usual reasons why we like backwards compatibility

Personally, I wish they made it optional, and we could break out on the new road with EJB 3.

The ballot results for the JDO 2.0 spec are in.

Although the spec passed, there was some significant “No Votes” from IBM, BEA, and Oracle.

They made comments to the effect of:

“There is no room for JDO anymore. EJB 3 is your new persistence model”

Personally, I just want a nice transparent persistence standard. I guess if EJB 3 does a better job than JDO does…. good for them. However, logically, it seems to make more sense that:

JDO: Defines a specification for transparent persistence.
EJB: Define enterprise cross-cutting concerns, using existing specifications where possible.

I think everyone would have been better served in this model. The JDO model allows for persistence without EJB. One of the use cases there is JDO on devices. Are we going to start to see EJB for mobile phones?

JDO has a lot of smart people, who have spent a lot of time on these problems. It is almost a little arrogant to say “we don’t need you”. Why not involve some of these people in the process?

Oh well, time will show us the story. As long as we actually get transparent persistence!

Marc Fleury said the following in an interview at InfoWorld:

When is EJB 3.0 due out and what