This post originated from an RSS feed registered with Java Buzz by Norman Richards. Original Post: EJB3 should support session beans without interfaces Feed Title: Orb [norman richards] Feed URL: http://members.capmac.org/~orb/blog.cgi/tech/java?flav=rss Feed Description: Monkey number 312,978,199 Latest Java Buzz Posts Latest Java Buzz Posts by Norman Richards Latest Posts From Orb [norman richards]

I seem to recall that the first version of the EJB3 draft supported the notion of session beans that didn't have local/remote interface. If there was no business interface, the container would automatically generate one to be used internally. I think the original idea was that this might be useful for web services where nobody actually called the object directly.

I'm not sure what the proposed use case was, but I remember thinking it was a dumb idea. What good is a session bean if nobody knows the Java interface to call it? Apparently the expert group felt the same way, as it is no longer a part of the EJB3 draft. That's quite a shame because it turns out that no-interface session beans actually would actually be quite useful.

The use case comes from Seam where EJB3 session bean pojos can be used as web components (JSF backing beans). It's a brilliant combination because it opens up the ability to use all of the EJB3 features directly, instead of forcing you to over-engineer session facades, service locators and all the other wonderful J2EE anti-patterns. It also makes stateful session beans interesting again, especially when combined with the extended persistence manager, which let's you keep a first-level cache between requests so that you never have to detach/merge entities. There's more, but the point is that it's a very nice application of session beans.

Web components are bound to view using dynamic expressions like #{somebean.resultList} or #{somebean.doSearch}. It's all reflective. At no point does the web tier actually need a Java interface or static typing. So, in this usage of session beans, a Java interface is completely pointless. It's quite annoying to be forced to create interfaces that nobody will ever use. I hope that future versions of the EJB3 spec add back in interface-less operation to enable even more streamlined development in advanced frameworks like Seam.