Ok, I have a situation where an XML message delivered to a Message Driven Bean. From this message I would like to create an object that encapsulates the data (really does not have much functionality except to repackage the data into an XML message). This object is passed around to some other objects (currently EJBs -- but I am not sure that is right) which will add data to the object until it is ready to generate an encapsulating XML message (basically I am importing data into a system and then generating a message to another application with the data in the new format).

Currently the data encapsulation object is to be an Entity EJB. This seems like overkill to me. Although this object is passed between a few other objects for processing, it never leaves the current application (until it is exported as a XML message using JMS). So why would I need all the infrastructure of the EJB?

I guess in general I am asking: When and why use a EJB over using a POJO?

I realize that the EJB can be interacted with though the server. However, if there is no reason for the object to have an external interface why use the EJB?

Now this is a very interesting question and generally gets you to the problem that is often discussed in professional circles: 2EJB||!2EJB and inspired such an excellent book as Bitter EJB among many online forum bloodbaths.
If your system/application, where this Object is passed around some EJBs is distributed, or it might have to be persisted, then using an EJB might worth the overhead, because you could take advantage of the framework. There are a couple of other factors, that can be of interest here, but without knowing the exact problem and environment, it is quite hard to give an educated guess on wether it is a good idea to use EJBs.
For a bit more information I would recommend the free eBook Wiley: Mastering Enterprise JavaBeans 3.0 4th Edition Jul 2006 available here. Chapter 11 gives a nice list on when to use EJB (and adds 4 more points to the ones I've mentioned and explains them a bit better)

That torrent is damm slow, so here is another one, this is the 3rd edition, but much faster - for me at least.

I believe that the decision whether to use POJO over EJB is one of architecture. EJB is (after all) just a wrapper around a POJO. The question of whether to EJB or not comes down to the architecture you design for your application.

Key questions are, are you constrained by external factors to deploying your application within an J2EE container? Are there other services of that container which you wish to leverage? Has the systems architecture been mandated and you have to use EJBs?

On the subject of JMS and MDBs ..... make sure you do a proof of concept first and ensure that the solution you arrive at performs as you expect. The performance of JMS implementations varies widely and you might find that the application simply wont scale. Also, be aware of the limitations of MDBs, read up on them carefully and take nothing for granted. Most containers have specific attributes which can make them more or less useful.

Flynn, you are painfully right about the performance of JMS implementations!
Looking at the original question it seems to me that the application is based on EJBs, the only question is if a particular object should be implemented as an EJB, however I might be wrong here, so let's wait for some clarification.

There is one MDB... This MDB will receive a message from Websphere MQ that contains a XML document. The MDB then queues this messages up for a XML parser which will construct a wrapper object to hold the data from the XML. Other objects will in turn be called to add the data to various software packages (and picking up the various unique identifiers that each package used for that data). When all the software packages are synchronized the data object's life is over.

So in summary: I am creating a glue between two basically incompatible data management systems. The data comes from some third source, and then goes into the first data management package, picks up some meta-data, and then goes on to the second system.

The truth is, the MDB part is our biggest concern. But at the moment my concern is the data object. I am new to J2EE and I am having a really hard time wrapping my head around how to construct this one little data wrapper. It really just needs to sit pretty an allow the other beans to ask for its data. However there IS a question of persistence. Although the object only has a hopefully short lifespan, due to need to ensure the delivery of the message once it is received by the MDB, the message is persisted until it is processed.

So maybe I should make this an entity bean. Which kinda sucks because I don't really understand all of this... C++ is much more fun for me

You c\an set up an MDB to be part of a container managed transaction so that you can include all your activities within one transaction which encompasses the delivery of the message.

Given that you can enclose everything in a container managed transaction I don't think you've got an issue.

You receive the message with the XML in. Then parse that XML into a POJO. You then enrich that POJO with what ever extra data you need to. Make sure that the POJO is serializable and you can just pass around that object however you want. Once you've happy that everything has happened correctly then you commit the whole transaction.

I'm fairly sure that this is only applicable when you are using a JMS queue as opposed to a topic as message delivery within a topic wouldn't work in the face of a transaction.

What sort of throughput are you expecting from your JMS queue? How many message per hour do you expect?

Ok. Things are moving allong nicely but I am still running into this question 2EJB||!2EJB.

So the MDB is working wonderfully. I put a message in the queue and it receives it. So far so good.

Now the MDB calls an EJP called (more or less) ProcessMessage. This EJB calls ParserBean (also an EJB) which creates an POJO TheMessage which encapsulates the message data. Once the ProcessMessage Bean has a shiny new copy of TheMessage it calls a few more EJB's which add data to TheMessage until it contains all the new data, then another bean called BuildReturnMessage is called to generate a JMS message that is sent out on another queue...

Basically this seems like a waste of the EJB framework. Most of those object have no need for a remote interface. The MDB needs to be a bean. But is seems to me that the rest of the objects are all created from that point and call one another directly. Why would they need to be EJB's?

I guess what my big question is: Why use EJB for object that don't have a remote interface?

BTW: yes I am using a Queues as there are single consumers for the messages.