Apr 02

Offline Consulting: The next EJB gold mine

Ajax, EJB 6 Comments »

EJB was great for consultants. Complicated software is always good for consultants. Companies need to pay you to explain the darn thing.

Just look at how good COM was for Don Box :)

I think one of the next beasts like this will be offline web applications. With Apollo, Slingshot, Dojo, and the other offline toolkits coming out we are going to see a lot of people saying “I want that”, and “make this work offline”.

The web is a world of connectivity. We have been building applications that take that assumption for granted. Now, with offline, we are changing the paradigm.

Beware the seemless example

Remember the talk of EJB where you can just call a method on a stub and it could be local or remote. Who knows! It was this ignorance that enabled a slew of applications that ran dog slow as they talked across network boundaries and serialized data back and forth all day.

Writing offline capable web applications is going to be hard to do right. We are going to have to take a step back and rethink how our applications are going to work with a new dimension added to the mix.

If you want to make a lot of money consulting, get good at building offline web apps and rake it in :)

May 10

Gluesphere Express

EJB, Java, Tech 1 Comment »

I had a double take when I saw the news that IBM has purchased Gluecode.

IBM is really looking to do something different here. Maybe it is just an experiment with opensource, or maybe something more fully planned.

One of the most interesting parts of the press release is the graph:

Is Gluecode really less that WebSphere Express even??? hopefully not for long!

This makes it look like a migration path too. It will be interesting to see how the brands are marketed (”If you like Gluecode, why not upgrade to the full blown WebSphere”????).

Again, we can read into:

Continuation of IBM’s open source strategy

IBM is making a major commitment to Apache Geronimo as the Open Source application server of the future. The Gluecode team will continue to be major participants in the Apache Software Foundation

Mar 07

GeronoSpring: Developers can use Spring and claim EJB 3

EJB, Java, Open Source, Tech 11 Comments »

One of the controversial points of EJB 3, is whether it should be backwards compatible. The programming model is so different, that it hardly seems right to force 2.1 compliance, but rather, make that an option.

In fact, one of the instant poll questions at TheServerSide Symposium backed this up:

How do you think the EJB 3 spec should handle backwards compatibility (e.g. to allow for a Spring compliant version)

1) Make EJB 2.1 support and below MANDATORY
2) Make EJB 2.1 support and below OPTIONAL (a check box for vendors to compete)

The results came back as ~80% of the crowd wanting this to be optional. Linda DeMichiel mentioned on the panel that she did hear the community here, although I do realise that she has other groups wanting other things. Kudos to her for being the spec lead ;)

Many people at the show laid their point down:

Tim Dawson: Vendors don’t care that the spec enforces backwards compatibility, they care about which server vendors do!

Hear, hear,

We also know that many dev groups need to be able to say “I am using EJB compliant software”. This is from vendors to ISVs to large IT organizations. It is a reality. And, although a couple of vendors told me at the show:

Spring can support the EJB 3 annotations, so they will be source-code compliant…

I think this is short sited. You can’t say “Oh, well we aren’t EJB 3 certified, but we do grok it. Promise”.

So, what if the EJB spec does continue to enforce EJB 2.1 compatibility?

I am not as worried about this anymore. Of course, I would love to see the likes of Spring able to support EJB 3, but there is a good solution if it isn’t the case. Geronimo/Spring integration.

What if Geronimo had first class integration with Spring? Spring Beans/modules could automatically be loaded up with no need for anything else. There are many, many ways in which the two could integrate, and I have heard of some very exciting possibilities from the teams.

What this does, is that it changes the game. We can get the best of all worlds.

If you work in a place that requires “application servers” and the like, you can just use Geronimo for that need… which will be a fully compliant EJB 3, J2EE 5, server.

So, I predict that:

Geronimo will become the server to run the Spring framework within.

Imagine it! EJB 3 view on your Spring modules! No need for Spring to have to implement the spec at all!

Feb 09

Interceptors in EJB 3. Finally.

EJB, Java, Tech 4 Comments »

The 2nd Early Review Draft for EJB 3 has been released. Apart from changes such as splitting the doc into two (persistence + ‘other’), the main addition is the fact that EJB now has interceptors. Something that people have been wanting for a long time.

Currently the draft states support for Session and Message-Driven Beans, and the spec questions the need for support in Entity bean business methods.

The interceptor module is based on AroundInvoke methods:

public Object methodName(InvocationContext context) throws Exception

The InvocationContext has methods such as:





Map getContextData()


Good to see something like this making it into the spec. I will be even more excited about EJB 4.0 when it is an aspect based set of concerns ;)

Read more in the EJB 3.0 Docs

Dec 17


EJB, Java, Lightweight Containers, Tech 6 Comments »

After hearing more about EJB 3, and talking to various people, why are we putting dependency Injection semantics in an EJB spec?

I can see one reason: “Let’s just get EJB 3 done”

This is a reason for not splitting the persistence API into a truly seperate JSR (although it IS mean to be a seperate spec/tck/runtime).

Dependency injection is a very generic concern, and one that should be shared throughout a bunch of specs. One tiny JSR could flush out the semantics
of dependency injection, and end up with javax.dependency.*.

Then EJB 3 would specify that “When you @Inject a transaction manager…. you must do X”. A future Servlet spec could do the same thing for their resources, etc etc.

Also, lightweight containers would have the option of groking these annotations too, without needing some ejb.jar.

Wouldn’t that be nice?

Oct 14

RE: Don wants to know how Indigo can avoid EJB’s fate

EJB, Java, Tech No Comments »

Ted has discussed avoiding the EJB fate in Indigo.

He gets into lightweight containers, and how he wants a “Pay as you go” situation (sounds familiar from the debates ;).

He has a feeling that the current crop of lightweight containers are already heavy and don’t allow this.

I have to disagree. If I want to start of with a minimal system I can literally create a a container (e.g. new SomePicoContainer(), setup a Spring applicationContext) and have minimal configuration for my needs (e.g. XML config, or in code).

Then, if you find yourself wanting to add functionality you grow your configuration and start to use more functionality. You don’t have to grab the full jar files if you don’t want to (if you are worried about that). You do pay as you go.

Pico/Nano may be even better in this regard. Each project has its own goals. PicoContainer is just that. It stays lean and mean and just does the one thing. Then Nano builds on top of that. It manages trees of PicoContainers, has support for services such as Hibernate, NanoWar, etc.

I am enjoying pay as you go right now!

Oct 04

Lightweight containers vs. EJB: Don Box, Ted Neward, Rod Johnson, and more

EJB, Java, Lightweight Containers, Tech 9 Comments »

A blog discussion has started on the subject of lightweight containers, and somehow changed to OR mappers at the end :)

Neward on Crupi

What is the state of the enterprise Java world, anyway?

I think there are some KEY differences with the recent move to lightweight containers.

The various tools that I seem to prefer these days have one thing in common:


I think this is a huge thing. I think that so many projects have gotten away from core OO practices (and OO doesn’t mean distributed objects Ted!) because they were stuck with crappy EJBs. These applications were built using “patterns” of:

Stateless Session Bean – Entity Beans – which use DTOs

This isn’t OO. This is RPC. The entity beans often had simple mapping, and don’t allow for inheritence. DTOs are evil as they are a duplicate layer of structs that you are throwing around.

Note that I am talking about an application that isn’t a service. I am talking about building an internal application first, using good OO practices, and THEN you can lay on the service layer to allow for external stuff.

So, back to transparency.

IoC Containers

I can finally write code that is just POJO based. There are no extension points to the framework. I am not stuck extended evil EJB interfaces and classes, having to create “home” interfaces and such. This all gets in the way. Not only does it get in the way but not I am totally tied up in knots.

With a container like Spring you look at my code and would have no idea if I am using it! What if I want to move to something else like Pico or Hivemind? I can. My core business logic is in tact and I can go about my way of moving. I don’t sit around crying because I have to munge my logic from the coupling with the framework! I love it.

JDO, Hibernate, etc

I like transparent persistence (not that it is truly transparent due to the OO-DB mismatch… but it gets close). Once again, I can develop a full, rich, domain object model. The model can even have inheritence and interfaces, and maybe people will put in real business methods that do things instead of just gets and sets (gasp!).

Now with a marriage of these technologies I have a clean domain object model (transparent persistence), and clean services (lightweight container). Testing IS a lot nicer too in my experience Ted. You don’t need to run around finding or building bloody mocks for the environment.


I do agree with Ted in that EJB is good for some things, such as 2PC and Message Driven Beans. There is going to be a kick arse way to do MDB in Spring coming up soon, so that need will go away. What about 2PC?

Well, a couple of things can happen:

a) The lightweight container can support them
b) You use an EJB when you need to do 2PC! One nice thing about the lightweight containers is that they can be used WITH EJB too :) However, HOW many applications need 2PC? 2%? And then within those applications, how many of their transactions need to be 2PC?

If you can’t see that Spring isn’t nicer than EJB? Ouch. You must like eating the elephant ;)

Sep 25

JDO and EJB join forces: The cat is out of the bag

EJB, JDO, Java, Tech 5 Comments »

The official announcement will come out of Sun on Monday, but the cat is out of the bag.

Firstly lets look at the facts:

  • A new spec/RI/TCK is being created UNDER the JSR-220 (EJB3) umbrella
  • This new spec will be based on the persistence API from the EJB 3 early draft
  • The scope is for a persistence API for BOTH J2SE and J2EE (so it will work outside of a container)
  • JDO experts have been invited to join the EJB team to grow it from here
  • The final spec will be available in the same time frame as J2EE 5
  • The JDO 2.0 spec will continue. It will now add the ability to externalize JDO-QL so it can be used from the new persistence API

I am really hopeful with this situation. A lot of the folks on the JDO camp are NOT all about JDO… they just want a transparent persistence model that isn’t stuck in a container. Now it looks like this is going to happen, and the EJB folk are on board too. If this is done right then it will be a huge win for everyone.

Although I am really excited about the potential, the proof WILL be in the pudding, and I have a couple of concerns:

Where it lives

In my mind there were three options for placing a spec which holds a persistence API for J2SE and J2EE:

  1. JDO: Since this spec kinda has that mandate already, it could have lived here. A reason for doing this would be that there are already users of this API. A reason for not doing this is that there are already users of this API.
  2. EJB 3: It seems a little strange to have a spec that covers J2SE in an EJB spec umbrella, but they have done work on this themselves. I would argue that more work has been done with JDO 2, but hey, let’s move on
  3. New JSR/Group: I know it would have taken more time to come up with a new JSR, but I would have ideally wanted this. A new group would have been formed and it would have set the tone to be a brand new collaboration. As it stands some people are skeptical that the JDO folk will be listened too. I am really hoping that everyone gets their say and that we get a great spec.

Pluggable Persistence

EJB specs have always talked about the idea of a Persistence Manager, and hinted that at some time this will be pluggable. JDO specs have had this notion from the beginning.

I *really* like the fact that JDO plays nice with the J2EE CA, so I can deploy whatever persistence manager I want by throwing a RAR at my application server. This seems like a no brainer on what it should be.

I want to be able to run WebLogic Server with IBM’s persistence manager. Well, I don’t really want that combination, but I want the flexibility.

From what I have heard on the grapevine, the new persistence API may not have the pluggable contract which really bugs me.

Why wouldn’t they define this? The only reason in my opinion is that application vendors don’t want this as they obviously want lock-in.

Please, please, please open up and allow the best persistence managers to fight it out in the market.

Finish on a positive note…

Overall I am really excited on this new bold move from Sun. Kudos to them for getting together and working out that this makes sense for the community. I really hope that in practice this works out and we get a great persistence API that everyone is happy with. My few worries above are only mentioned in the vein hope that people think about these things and we do the right thing.

Let’s get to work!


Jason has good comments:

Any idea if it’s still going to be dependent on 1.5 with annotations? And are those annotations going to be defined and jar’d in the j2ee.jar? Will I have to compile against the j2ee.jar or a vendor jar and either ship with the j2ee.jar or deploy in a container just to get the annotation classes?

I really hope that since this sub-spec is meant to target J2SE, that there is no need to ship j2ee.jar. Surely!

Aug 05

RE: Lightweight Containers vs. EJB3

EJB, Java, Lightweight Containers, Tech No Comments »

Merrick has a nicely thought out critique at Lightweight Containers in comparison to EJB 3.

His basic premise is that EJB 3 fills the gap of the lightweight containers. Although I think it is a great step forward, I think there are a few areas which worry me:

What are we specifying?

I would personally love the expert group to be able to step back and think about what EJB is all about. Where is the “E”, and what should be spec’d?

In my humble opinion, I think that the EJB spec should be a pretty lean one, that acts like the J2EE spec… in that it offers the programming model + integration hooks into other specs. The other specs are basically out there to define the cross-cutting enterprise services, and could later have AOP info.

The obvious example is persistence. Get a new spec for that if you really can’t stomach talking to JDO people. But get it external, and have it for EVERYONE.

There are also many other examples. Security, worker threads, blah blah.

Backwards compatibility requirements

I understand backwards compatibility is good. However, I think it is OK to make some things optional. Having all of the EJB 2.x and below baggage is painful for some people (e.g. Spring) and keeps them out of the loop. Make it optional, and if you ARE backwards compatible you can get a shiny checkbox. Then, if a company gives a monkeys they can get an implementation that has the shiny star.


In some of the open source projects such as Spring, there is an air of inclusion. What do you want to do for persistence? JDO? Hibernate? iBATIS? We will hook in and help you out with all of them.

You don’t feel that same way with the EJB vendors. The feeling is more like “Oh man, they want to hook us into their damn EJB CMP engine that we can’t bloody swap out as the PersistenceManager STILL isn’t pluggable after all these years”.

Come on guys, let’s play nice. You can still compete on features / QoS / etc.

So, although I am excited about EJB 3…. I want more :)

Jul 26

“WebLogic EJB, with some experience making calls on EJB’s”

EJB, Java, Tech 4 Comments »

I saw this quote on a job posting:

WebLogic EJB, with some experience making calls on EJB’s

Yeah. making calls on EJB is the tough part! I know they TRY to make it hard with JNDI + PortableRemoteObject.narrow(..), but come on!

I guess a recruiter wrote that bad boy :)