The EJB 2.0 specification will offer Java programmers a new toolkit for asynchronous messaging in an n-tier architecture. Find out how to use message beans to take enterprise messaging beyond the functionality currently available with JMS.

Read the full article.

Too good to start with a new monster!!!!!

Ram

Is it possible to persist these message driven beans(like entity beans) .
(according to EJB2.0 spec we can not, dispute me otherwise)

Well, you could persist data using a MessageDriven bean, but an MDB is not a persistent object in itself because it doesn't have an associated primary key, and its stateless, so there aren't any persistent fields to be mapped to a database.

I actually recommend against putting any real complex logic in an MDB.. I use MDBs as a message gateway to other session beans, which encapsulate business logic and then delegate to entity beans. That way the business logic is reusable for non-messaging clients.

Well,
They are persistent in a sense. The bean it-self is stateless but the message contents (i.e. the state) is persisted in the queue until you consume it and commit. Not quite what you're after though, maybe.

This article was excellent for getting started with
Beans that act as Listeners. but, what about Beans
that produce messages? I assume this is also possible,
but am wondering why it was not mentioned in the article.

Any bean can publish a message even without any special support from the app server. The main issue here is transactions and security. There are other issues also as most JMS transports will probably create a few threads/use the file system etc and basically break some rules as far as J2EE goes.
But, if you'll accept that then even EJB 1.0 servers can happily publish messages.