Is it alright now to do away with EJB in ANY application (including "mission-criticals")? Have other open source/commercial tools matured now to a point of being able to do well the advantages that EJB is said to have? I am not inclined to using EJB but my mind is open. I'd like to have your opinions on this, including substitute tools.

I really mean "ANY". Thanks.

Personally, I'm still looking for a framework similar to Spring which allows the development of business services that will work in a POJO environment, but which also supports the ability to generate SLSBs from your business service interfaces. IMHO, that would offer the best of both worlds: simple development along with the ability to utilize EJBs if desired.

This is straightforward to do with Spring: You can write a plain business interface with a POJO implementation, and additionally derive a local SLSB interface from the business interface and an SLSB implementation from the POJO implementation. Alternatively, you can write an SLSB implementation that delegates to an internal instance of the POJO implementation. Beans that access this business object in a Spring context can work with either, as both implement the business interface.

With Spring's EJB access classes (in particular LocalStatelessSessionProxyFactoryBean), it is simple to configure a reference to such an EJB as direct replacement for a local business object: Simple replace the bean definition with the EJB access class; the latter will expose the looked-up EJB instance for bean references. The only requirement is that the EJB implements the business interface.

In the case of remote SLSBs, you need to make your business interface methods throw RemoteException - in all other respects, it's similar to the above. If you're willing to maintain two versions of your business interface, a generic one without RemoteException and one for the remote SLSB, you could set up a simple proxy that implements the generic business interface and delegates to the SLSB interface.

One thing to note is resources and other beans that the POJO/EJB business object depends on: In a Spring context, the POJO would receive these via bean references, which is obviously not possible for the EJB. For a solution, the EJB implementation can look up JNDI resources in setSessionContext and invoke the corresponding setters of its POJO superclass, and potentially load collaborating beans via its own bean factory or the like.

So all things considered, Spring should provide all the infrastructure you need - and I guess it won't get simpler than that, as there are certain mandatory restrictions with EJB that matter in all non-trivial scenarios. If you'd like tool support for generating those SLSB implementation subclasses, that should be straightforward to write in principle: You'll have to address at least the resource lookup issue, though, provided that you have no other beans that you depend on.

Juergen

You can certainly not do away with EJB in ANY application. If your application is internally distributed in its nature, meaning that it needs remoting at the internal component level as opposed to exposing remote services to clients, remote EJBs are still a viable choice. A particular case for remote EJBs is distributed transaction propagation, and load balancing at the component level.

However, 90 percent or more of J2EE web applications out there aren't internally distributed or at least are not deployed that way. If you need to scale such apps, simply set up a farm of web servers, each with its own colocated deployment of the whole app, potentially with HttpSession clustering. For that kind of applications, remote EJBs do not provide any benefit: That's why local EJBs are typically chosen for such scenarios.

It's exactly the use of local EJBs that should be looked at more closely. Essentially, declarative transaction management is the single most important benefit. Instance pooling just makes sense if you keep non-threadsafe instance variables - it's hard to think of a compelling case where that would be necessary (note that a DataSource or a SessionFactory are perfectly threadsafe). And declarative security at the component level simply isn't necessary in colocated apps.

I consider Spring's support for declarative transaction management on plain POJOs a very viable alternative to local SLSBs that are just used for declarative transactions (which assumably more than 90 percent are). It's easier to configure (without additional deployment steps) and particularly easier to test (without an EJB container). And it provides more options, like configurable isolation levels, association of Hibernate Sessions and JDO PersistenceManagers with managed transactions, etc.

As a side note, Spring's generic AOP support allows for security check interceptors and even instance pooling invokers if you really need those. In almost all scenarios, singleton business objects with a transactional proxy are perfectly sufficient. Spring also provides support for exposing existing business objects as remote services (out-of-the-box for Caucho's Hessian and Burlap web service protocols), but without transaction propagation.

So all things considered: I recommend Spring-managed business objects for all local transaction needs, completely replacing local SLSBs. Note that those business objects do not have to be aware of Spring at all, allowing for easy reuse in other environments. But if you need internal distribution at the component level, particularly with remote transaction propagation, I still recommend remote EJBs.

Juergen

XDoclet can be used to produce SLSB out of your POJOs encapsulating business logic.

However, you will have to keep in mind possible EJB issues when
you develop your pojos ( obtaining sessions, transactions, no
messing with files / sockets etc. )

I would love to see an example that uses Spring+Hibernate+EJBs and take advantage of xdoclet.
POJO + xdoclet tags to generate hibernate mapping files and SLSB.
POJO's DAO interface.
Hibernate implementation of the POJO's DAO that uses Spring.

A similar example with the corresponding ant script would be a great resource. Anyone interested in starting it on the wiki?

there are some eyamples of hibernate + ejb with xdoclet.
And I'm working on xdoclet2 templates for hibernate, and xdoclet 2
woulc be better suited to create custom use patterns.

As for me, there are no examples around ( yet ) - tgis is work in progress.

Though you are invited to watch us working on CVS :)
( and contribute... )