Mark Little and I disagree on things, agree on others. Of course, he has a much better educated opinion on this subject than I do. He’s the man, I’m just a loud jackass.

Found your blog just today. Boy, you kept this secret

I think WS-* (and BPEL is a good example) is over hyped and more complex than it needed to be (blame the vendors!) Web Services are another tool that makes sense for certain scenarios (heterogeneous interoperability being the prime candidate). They’re not a global panacea. People get burned by trying to replace existing infrastructure with entire Web Services based implementations! Many people who say they need BPEL don’t even understand what that means. Plus BPEL 2.0 is a lot poorer in many respects than the original BPEL4WS. Anyway, your entry wasn’t about WS-*, but I thought since someone mentioned my name I’d chime in here I agree with you: it could have been a lot simpler/easier and tooling support needs an overhaul.

The current choice of “eat as much XML as you can stand” or “1 class – 1 container oversimplification” is still not very satiating. That being said…spring really is starting to show it’s age. EJB3+JPA really shines as a programming model by comparison…but market uptake and vendor failure (including JBoss’s) to bring production products to market in a timely manner is really making Java EE 6 a questionable enterprise in my mind…let alone 7. And there is of course what I said some time ago….EJB3 should have never been named EJB because EJB is associated with “suck” in most developers’ minds. Branding baby. (though spring is a bad brand because news.google.com never brings up weather)

Meanwhile its obvious the market is moving on. The big boys and middle sized boys are all in ESB, BPI and SMD and shouting things that mean nothing like SOA. Injection is so last year.

I thought I’ve said this over and over? Maybe not. I want the pure IoC stuff standardized and for Interface 21 to follow whatever is standardized. We don’t need a fragmented component model between EJB and Spring users. Unifying them, like we did with Hibernate, JDO, and CMP in EE 5, would be uber beneficial to the community at large.

The persistence exception hierarchy would be beneficial as well, but I see that as something minor. Their security work with acegi might be something too, but I know the Seam guys have different ideas for the same space. Really, I’d just want the IoC stuff standardized.

As far as stepping over the line Corby, well, I get aggravated and emotional sometimes, so be it, its my nature and personality. But hopefully I backed it up later on with some reasoning behind it. If Red Hat wants to fire me over my tone that’s their prerogative.

Your original TSS post suggests that the only way Rod Johnson can assist with the standards process at this point is to “bring Spring to a standards body”, and I’m really not sure that’s correct.

The Interface21 folks have brought some really good ideas to the table (backed by successful work in the field) in terms of improving Java EE for users, and yes, they did influence the Java EE5 specification. I think it’s extremely short-sighted to think that Rod Johnson couldn’t contribute some very useful ideas about extension points on Java EE servers, and specifications of profiles, regardless of what happens with the Spring product.

And at the end of the day, you will always get back to the question of what should be standardized.

AspectJ? That’s very appealing to me, but that’s not Rod Johnson’s baby.

Those goddawful proprietary annotations that are all the craze these days? I don’t want those in Spring, much less in the standards process.

The XML configuration format? This is certainly the most visible target, but I’m not buying it. In my opinion, this file format serves the same function as a proprietary graphical configuration tool that would be offered by IBM, BEA, or JBoss. It is basicallly a useful input format that delegates to the standards API’s. There are a dozen ways that configuration and dependency injection can be performed, and it’s not clear to me that this particular one needs to be standardized.

Those cute little helper API’s? Nah, these sorts of take-it-or-leave-it bits belong right where they are, as a third-party optional library.

In my opinion, the most valuable thing that Spring could contribute to the standards process would be their data access runtime exception hierarchy. I think it really adds to the existing specs, and makes it much easier to work with disparate database vendors. But I don’t think that’s the sort of broad contribution you had in mind.

So, if you were advising Interface21, what would be involved in “bringing Spring to a standards body”?

Umm…does that mean we can expect JBossESB to stay away from WS-* and BPEL etc? Wonder what Mark Little would have to say about that or are you going to do a u-turn when JBoss ESB also plays the WS-* game?

Mark Little and I disagree on things, agree on others. Of course, he has a much better educated opinion on this subject than I do. He’s the man, I’m just a loud jackass.

But, JBoss ESB already plays the WS-* game. I’ll u-turn when JBoss or a specification effort has simplified things.

J2EE hasn’t performed so badly over the years. Otherwise you wouldn’t have so many deployments out there and WLS, Websphere, and JBoss wouldn’t be making so much money for their perspective companies. JMS, JTA, JMX, JCA, and Servlet are great specifications. Persistence and EJB are on the road to recovery. JSF is pretty damn good as Seam has shown. Even JAX-WS has made things easier for Java-based web services.

Again, I’ll repeat myself. Standards should be about standardizing existing innovations. This is the point where JBoss jumped into the JCP game. We brought Hibernate to the JCP. We’re working out the kinks with Seam before we bring it to the Web Beans JSR.

Each volunteer OSS project or vendor each have their own innovations that many times overlap. Instead of having a fractured community isn’t it better to bring groups together to decide on something common and grow the community?

Just to be sure you understand me. What I mean is that good technology emerges over time through experimentation and evolution. Freezing this process prematurely is IMO one of the main reasons why J2EE has performed so badly over the years.

If the OSS community joins in with this “premature standardisation” practice also, then IMO Java in the Enterprise is truly doomed.

I agree with you about OSGi. Getting over class loader problems helps, but that is not the whole story. You didn’t respond to this though:

“…but if a Java Enterprise Component Framework that is simple, and productive and does the job arrives on the seen, then why bother with J2EEX? In such a scenario why sit in the shit (your words not mine :^))?”

And I guess this is why I’m giving you a hard time :^). IMO the best frameworks emerge from working applications, and this is where I believe OSS is at it’s strongest. People solving real world problems and then factoring out parts that can be re-used and then choosing to share those parts with their peers.

Standardisation should occur once a technology is proven, which is why J2EE5 is much better than J2EE1.4. BTW thanks for Hibernate/JPA it really does help.

Going forward, I’m not sure that J2EE6 will be based on proven technology. How about building it first, seeing what works, then standardising?

If you had got it wrong with Hibernate, then it wouldn’t have become popular and it wouldn’t of ended up as a standard – which is a good thing :^).

Umm…does that mean we can expect JBossESB to stay away from WS-* and BPEL etc? Wonder what Mark Little would have to say about that or are you going to do a u-turn when JBoss ESB also plays the WS-* game?

I’m still hopeful that they’ll have some input for JSR 299, but I doubt it.

As for Spring-OSGi, you’re absolutely right… there is a lot of propoganda out there. It’s also probably about a year away from being useful.

However the biggest win it will have for developers is better application modulaization. Right now we Spring users are kind of forcing one big .war file. That just shouldn’t be “the way.” Spring-OSGi should theoretically solve that problem.

I would like to see more helpful information from I21, IBM, BEA and Oracle which are all on the OSGi bandwaggon.

Heck, I’d like to see a clean solution that enables easy Hibernate-OSGi integration…