Discussions

EJB design: Why does EnterpriseBean interface extends Serializable

  1. The Bean class of any EJB must implement the EnterprsieBean interface. But does this class is ever serialized? In my opinion this class is not needed to be serialized.

    In case of Stateless Session Bean there is no Serialization. In case of Entity Beans the data is serialized to persistent store directly. Only Stateful session bean can be serialized to maintain user state. But since EnterpriseBean interface is being implemented by all kinds if EJB, they all are Serializable.

    Am I missing something?
  2. If you need to access your EJBs remotely (which is - most of the time) and pass paramters to your EJB methods and return objects, then you need to use serialization so that Java can massage the objects so they can be read correctly on the remote machine. Since the EJBs are usually designed as distributed components, they all have to be Serializable objects.

    Correct me if I am wrong - I think you are inter-mingling Conversation state and Serialization concepts.
  3. Sriram,

    I think the only restriction is on the Parameters and Objects returned by the remote method. Since these are the only things which travel over the network hence they should be Serializable. The Bean class never itself travels over the network.
  4. hello
       if u want to access a EJB component remotely then the object which u want to access remotely should be of remote object type.ie,it shld implement serializable so that all the info the object contains can be passed remotely.
    when u wnat to access an object remotely-it means that u wnat to access its methods,data.so if the calss is not serializable how would you transfer the data betn remote calls!!?
  5. Hi Kamala,

    When we access an EJB component remotely, its the EJB object which travels over the network and Bean class never travels over the network. So the EjbObject should be Serializable and not the Bean class.
  6. if u want to access a EJB component remotely then the object which u want to access remotely should be of remote object type.ie,it shld implement serializable so that all the info the object contains can be passed remotely.
    when u wnat to access an object remotely-it means that u wnat to access its methods,data.so if the calss is not serializable how would you transfer the data betn remote calls!!?


    Bravo! :-)
    So you actually think that your EJB component is transferred between client & server in remote calls? Really? The actual instance + the whole object graph? And all server-side classes along with them (if you have a clue about how serialization works)?

    Buddy, take an RMI tutorial; possibly you’ll get familiar with such concepts as stubs & skeletons (former is generated by app. server and is serializable).

    VS
  7. Hi Valery,

    Of course its the stub which travels over the network and not the EJB Object, but my question is that why the Bean class is Serializable? I dont think its only serialized in case of Stateful session bean.
  8. Hi Valery,

    I think the Bean class is only Serialized in case of Stateful Session bean. In case of Entity beans it will soted in the persistent store and in case of Stateless Session bean serialization is not equired. But by having EnterpriseBean iterface extending Serailizable interface all the bean classes in case of Stateless, Stateful and Entity Bean are all Serializable.
  9. 1. Originally, it was not my question
    2. I know that the only type of beans that should implement java.io.Serializable is SFSB because serialization is part of SFSB passivation.

    I've read today several comments to the following blog post (BTW, are you the same person as blog owner???) and have to agree with assumption that the enforcement to implement java.io.Serializable at javax.ejb.EnterpriseBean level (rather then at least at javax.ejb.SessionBean level while SFSB & SLSB both have the same interface) comes from old EJB 1.0 days when Entity Beans was expected to be stored via serialization. AFAIR, some vendors uses flat files (JRun 3.0), other placed serialized bean into database. There was (almost) no support for O/R mapping so familiar and natural to us nowadays.

    VS
  10. Since we know that one of the ways of achieving Activation/Passivation is via serialization, so it makes sense for Entity as well as Statefull Session Beans to be serializable.

    Probable reason for Stateless - according to J2EE Design Specs, the Session beans were originally designed as "Statefull" only. Sometime later during the design/discussions the Statelessness was found to be useful, and the spec says that "Stateless" is only an exceptional type of Session Bean. This is clearly manifested in 2 ways-

    1. There's only a single SessionBean interface which caters to both statefull and stateless.

    2. Stateless Beans are an afterthought, as they may not be programatically enforced to be stateless... The only place you let the container/system know that they are stateless is via Deployment Descriptors.

    That said, it is a quite useful after thought. Since there's clearly a lot of use for Stateless Session beans that are lightweight and don't have to carry the baggage of state-maintainance.

    Come to think of it, "Stateless-Session" is an Oxymoron, since a "session" by definition should be maintainance of current context/state.