Why does javax.ejb.EnterpriseBean extends java.io.Serializable?
# 2003-03-26 14:48:29 -0500 | Java | 9 Comments
So, I was asked wtf javax.ejb.EnterpriseBean
extends java.io.Serializable today.
I have no idea! EnterpriseBean is the super-interface of
EntityBean, MessageDrivenBean and SessionBean, so your bean-implementation classes
are always serializable. Why is that necessary?
Some digging was in order.
I can naively understand why a Stateful SessionBean would be serializable; so that a container could “persist” it during activation/passivation, or move it around the nodes of a cluster. But that is not the modus operandi of EntityBeans… they have CMP or their store/load methods for that.
I couldn’t find any justification why EnterpriseBean is serializable in the EJB2.0 Spec (ejb-2_0-fr2-spec.pdf); it talks about how SessionBean activation/passivation uses serialization, but not a thing on Entity nor MessageDriven beans.
This is not a big issue… but I’m left scratching my head…
Great post - be interested to see if somebody posts the reason why. Other than SUN were lazy. ;-)
It’s my understanding that it’s done this way so that EJBs are clusterable across multiple app servers.
That way you can have two beans which have a 1-to-many relationship and yet still have the bean clusterable.
eg:
class fooBean implements EntityBean {
abstract Collection barBean();
…
}
fooBean contains a Collection of barBean, which is not serializable. The javax.ejb.EnterpriseBean
extends Serializable so that the bean is serializable and thus clusterable.
I think.
Isn’t this due to the fact that also stateless session beans are remote by spec? I mean, how do you send a bean (rmi) if it isn’t serializable? You wouldn’t be able to guarantee the marshalling/unmarshalling of your objects.
I meant to say "how do you send a bean interface if it isn’t serializable"…
Thomas, I agree that bean remote interfaces definitely need to be serializable; it is required because they are Remote; eg so that they can be passed-as-arguments/returned-as-valued to/from remote methods.
But EnterpriseBean is not for the remote interface, its for the bean implementation classes. Instances of those DO NOT get passed around from remote methods; those instances remain "nice and snug" inside the EJB container. That is, EJB impls do not get marshalled during remote calls, just their remote interfaces.
Stateless SB’s implementation instances don’t get marshalled during calls either… but they may get serialized during activation/passivation.
So, once again, I’m left wondering why an Entity EJB is serializable… is the bean implementer required to think about if their class is properly serializable? Will an Entity EJB be passivated before a container "serializes" it… or will an Entity EJB NEVER be serialized by the container…?
Even though you do not normally store the attributes of stateless Session EJBs and
MDBs, you might want the ability to do so, therefore you must have java.io.Serializable in place.
The EJB spec talks a lot about the life-cycle of an EJB. It does not talk about when an EJB is serialized. Therefore you can make no assumptions about when an EJB is serialized and de-serialized. If you need to store attributes then in an MDB or SLSB you would need to do this yourself.
I personally think there is no obvious answer. It probably goes back to early EJB 1.0 days, and now they do not want to remove the interface and break a (mythical) contract.
OJB put me on to this non-answer from a year ago:
http://www.mail-archive.com/ejb-interest@java.sun.com/msg21279.html
The data Storage may be in a different computer and the EJB Enterprise Tier may be in a different computer so during passivation and activation the data need to travell via network to the EIS tier hence the object should be serialized.