Many developers feel EJB is like an extra layer of sugar syrup on a doughnut. In an age where low carb and Atkins diets are the craze, the EJB expert committee has no option but to produce a low carb incarnation of EJB, thus simplifying the development of EJB. The EJB 3.0 expert committee released a sample picture of the lightweight model during JavaOne 2004 when it announced release of the first public draft of the EJB 3.0 specification.

Read Simplifying EJB Development with EJB 3.0

Just to clarify...Although the current EJB 3.0 draft does not specify any XML mappings, the specification will not require the use of annotations.

Bill

Here some EJB3 limitations i have got:

- Objects must come from JNDI to be injected
- No ability to manage finer-grained objects than you might want to put in JNDI
- No ability to manage "singleton" (shared instance)
- No support for complex types such as lists and maps
- No support for configuration properties (Strings, ints etc.)
- No ability to apply custom interception to managed objects
- It's Java 5.0 only
- DI won't work with existing classes because it needs custom annotations

Any disclaimer from you ?

José.

DI won't work with existing classes because it needs custom annotations

I think Bill just mentioned that annotations won't be required.

I have a question. Will EJB 3.0 support the automated persistence of JDK 1.5 Enum Types?

I think Bill just mentioned that annotations won't be required.I have a question. Will EJB 3.0 support the automated persistence of JDK 1.5 Enum Types?

Good question, Corby. I was just reading a blog (http://jroller.com/page/dsmith/20041011) that was just starting to scratch the surface of the enum mapping issues. The spec will include support for mapping enums at the reference data level (which seems like the only sensible way to use them). If you have other thoughts, though, make them known.

-Mike

Here some EJB3 limitations i have got:

- Objects must come from JNDI to be injected- No ability to manage finer-grained objects than you might want to put in JNDI- No ability to manage "singleton" (shared instance) - No support for complex types such as lists and maps- No support for configuration properties (Strings, ints etc.)- No ability to apply custom interception to managed objects- It's Java 5.0 only- DI won't work with existing classes because it needs custom annotations

Any disclaimer from you ?José.

Sure there is support for configuration properties. Its called inheritance and constructors:

public class BaseSessionBean implements SessionRemote

   protected int variable;
   protected String stringVar;

   @Tx(TxType.REQUIRED)
   public void someEjbMethod() {...}

}

@Stateless
public class ConfiguredSessionBean extends BaseSessionBean
   
   public ConfiguredSessionBean()
   {
       variable = 10;
       stringVar = "hello";
    }
}

As for interception...Ask Mike Keith. He has put forward a great proposal in the EJB3 committeee.

As for "singleton" services. There's been some talk about that too and I hope it gets in. Going from the CORBA to J2EE world, I really missed the concept of a stateful service.

Bill

<quote>As for "singleton" services. There's been some talk about that too and I hope it gets in. Going from the CORBA to J2EE world, I really missed the concept of a stateful service.</quote>

Why not use JMX for singletons?

<quote>As for "singleton" services. There's been some talk about that too and I hope it gets in. Going from the CORBA to J2EE world, I really missed the concept of a stateful service.</quote>Why not use JMX for singletons?

That's what we, JBoss, promote for our userbase, but I'm not sure you would be able to use JMX as a service within other application servers. Somebody will have to answer for me on that...

Bill

That's what we, JBoss, promote for our userbase, but I'm not sure you would be able to use JMX as a service within other application servers. Somebody will have to answer for me on that...Bill

Understood. Although, I would suggest that JMX be added to the J2EE topology as a requirement for being spec compliant. This makes more sense to me then creating another standard just for singleton services. JMX seems to fit the bill rather nicely IMO and it is an already established standard.

I wonder why people still want to use EJB 3.0. Look at Spring, it is the best thing that has happened since sliced bread. Declarative transactions, constructor and setter based DI, superior exception handling based on **runtime** exceptions, dynamic proxy based and byte code amendment based AOP, IoC based excellent JDBC framework .... what more would you want!!!!

The whole community should be grateful to Rod and the Spring folks for what they have given us.

Are you referring to EJB3.0 for its Entity Beans or for the Session or Message Bean implementations.
Session beans are useful for distributed systems (as would be Web services), where you don't want to ship the same business function with every application. E.g a calculation engine where for performance reasons, it might be good to have this sort of service running in its own JVM.
Message Driven Beans are simple to program and deploy and provide useful asynchronous queue facilities. You would need to write your own queue listeners without them.

So in general, I think EJB3.0 will still be useful.

Regards

Stateless session beans are useful, however, there are numerous open source products that provide clusterable remoting. You can implement Web services without having a heavy-weight J2EE container. Come on, you don't need EJBs for web services. How do you think Microsoft provided web service support in their software, they don't have EJBs. Spring supports JAX-RPC, similar to the existing support for Hessian, Burlap, and RMI.

Only compelling argument for using EJBs is message driven beans. Anyway, MDBs were far from usable till EJB 2.0 with tight coupling with JMS. However, they have improved it with protocol agnostic reception with JCA 1.5 in EJB 2.1. However, I am yet to see some one using MDBs for a non-JMS transport.

Stateless session beans are useful, however, there are numerous open source products that provide clusterable remoting. You can implement Web services without having a heavy-weight J2EE container.

Since the beginning JBoss has been pluggable in nature. Our microkernel was written for plug-and-play and use-what-you-need from the very beginning.If you just need Tomcat and local EJBs, then you can remove JMS, etc... If you just need Tomcat and Hibernate, we have a nice Hibernate Deployer so that you can package and hot deploy your hibernate components. If you need a clustered cache, drop in the JBoss Cache .SAR archive. If you need web services, drop in the ws4ee archive in the deploy directory. The main difference here between JBoss and these other "lightweight" containers, is that JBoss actually provides a packaging solution that can be hot deployed, classloader scoped, and UI managed.

Our memory footprint and startup times can be made very quick with little configuration. JBoss 4.0 for instance takes 18secs to startup on my laptop with the "bloated" implementation.

Bill

Have you seen Hani's blog on JBoss taking more than two and a half minutes to start up? JBoss

I thought JBoss didn't have scoped classloading with its unified classloader repository, where everything could see everything else. I have been through some of the JBoss codebase. I am sorry to say that compared to Spring I found the code quality to be abysmal.

JBoss had its time. Now it is a thing of the past. I know numerous corporates moving away from heavy-weight bloated EJB architecture and embracing the revolution of light weight containers like Spring and transparent persistent solutions like Hibernate, iBatis and JDO.

Robert, I'm a big Spring and Hibernate advocate as well, but why do you have to be so polarizing? Those "numerous corporations" you mentioned aren't *all* corps, and I can tell you for a fact that the biggest financial shops are still squarely in the EJB camp, approaching lightweight containers very cautiously (well, more cautiously than they did EJBs).

Have you seen Hani's blog on JBoss taking more than two and a half minutes to start up? JBoss

Maybe you shouldn't believe everything you read and instead try it out for yourself. Hani isn't exactly the most trustworthy source...

I thought JBoss didn't have scoped classloading with its unified classloader repository, where everything could see everything else.

JBoss has classloader flexibility. Scoped and non-scoped. This has been around for years...Maybe you should actually read our documentation instead of relying on blogs for your information.

Bill

JBoss + EJB 3.0 = Nice

Really nice, in fact. Play around and you will know. Thanks to JBoss for letting us feel the pulse and make useful comments before it becomes too late.

Spring and the likes will never replace an open standard technology like EJB with strong vendor backing/support.

I have used JBoss for almost as long it has been around. It is quite robust. For plain servlet development I prefer Tomcat, but when it comes to J2EE or EJB dev, my first preference is JBoss (with JBoss plugin in Eclipse). After reading Hani's blog, I am quite certain that I hate WebSphere!

Question to the EJB 3.0 expert group:
Are you giving the "new-life-aproach" (by Ganesh and Rajat) some thought/consideration? Many ppl had a positive opinion about it (obvious from the forum postings) and it definitely deserves some thought.

aXe!

Spring and the likes will never replace an open standard technology like EJB with strong vendor backing/support.

Vendor backing may, may not matter, but the ease of use of EJB 3.0 will really entice away some of the Spring users who like Spring better than EJB 2.1 because of its self-proclaimed simplicity, IMO.

Personally, it was a joy writing the tutorial for JBoss's EJB 3.0 release because it was so freaking easy to write the code and deploy EJB3's. Annotations make things so, so nice. Session beans in particular. I write the session bean as a pojo, tag it as @Stateless, then use IntelliJ's refactor to extract/generate the remote interface, then @Remote tag the extracted interface. Then just jar up the classes and copy the jar to the JBoss deploy directory.

Bill

Bill-

I just got through reading the draft of the spec and I think it's all great.

Thanks for posting to the serverside. I know how these committees can sometimes go - I was a member of the OMG back in the CORBA days. And I know it can be more difficult than people realize to get everyone in the room to agree on the gory details.

Thanks for keeping us up to date.

-Scott

I was a member of the OMG back in the CORBA days. And I know it can be more difficult than people realize to get everyone in the room to agree on the gory details.

More than you know....Linda DiMichel has a real tough job...

Bill

Errm. I didn't say use EJBs for Web Services. I said you could use Web Services for distributed computing as an alternative to EJB.

Errm. I didn't say use EJBs for Web Services. I said you could use Web Services for distributed computing as an alternative to EJB.

Correct me if I'm wrong, but with the current final draft with webservices, it doesn't support security, transaction propagation, asynchronous messaging, etc...

Bill,

   I am sure you are absolutely correct. You seem to be well on top of the specifications. :-)

Chris

Does anyone know where the EG is at wrt an asynch call model for stateless beans?

Last time I heard (around J1 time) they were thinking about it - but werent sure whether it would make it...

-Nick

Are we still going to have the "magic methods" there were many caoumplaints about this a few months ago...?

Cheers

Smythe

Are we still going to have the "magic methods" there were many caoumplaints about this a few months ago...?

To extend that question, which improvements advocated by the "New Life for EJB" proposal [1] may we expect to be incorporated into EJB 3.0?

Cheers, Lars

[1] http://today.java.net/pub/a/today/2004/08/05/ejbnewlife.html

Day in day out I get more and more conviced to abandon Java/Net "SPAM technologies" in favor of the "Just Work" Python.