But why? The EJB does not implement EJBObject, the container implements the EJBObject interface. Same with EJBHome, which is also implemented by the container. Remote is the super-interface for EJBHome and EJBRemote. So bottom line that leaves us EntityBean, which was my choice.
You're basically correct on everything but you left out that the methods you want to expose for REMOTE access by a calling application/component must be promoted to your remote interface skelleton (...which itself EXTENDS the EJBObject interface). Your entity bean must then IMPLEMENT the remote interface you defined in addtion to allowing for the standard methods that comprise the EJBObject interface. Without the EJBObject interface your entity bean is no more distributable or remotable (...don't think that's a word) than a standard POJO. It is the EJBObject interface that allows you to establishes the contract for remote control with the calling application through the container.
I still don't understand. The EJB that I provide doesn't implement EJBObject in a Java sense. Meaning I don't write "MyBean implements EJBObject" but I do write "MyBean implements EntityBean". The stub and the skelleton generated by the container implement the EJBObject interface and my bean class only has to make sure it has all the business methods that are also exposed in the remote interface.
posted 15 years ago
I think your getting hung up on their nomenclature. When they refer to an enterprise bean they are not referring to one of the various files involved in defining an enterprise java bean (i.e. the remoter interface, the home interface or the bean implementation clase), they are instead refering to it as a conceptual/complete component. They are asking, "What interface does your EJB (...comprised of all the things I mentioned) need to implement so that an application can invoke it's methods".
The answer is EJBObject.
You are equating enterprise bean with the Bean Implementation Class.
Ok, now, this makes sense if I look at an enterpise bean as the whole thing and not just the e.g. AdvisorBean that I implement. Can I assume that for the real exam too?
posted 15 years ago
I don't think you can ever assume anything. The context of the question is critical. My experience was that the questions were fairly tricky. Careful reading and analysis of each was needed. You really need to know the topics inside and out to extract the most out of the question and avoid second guessing yourself. It was definitely one of the most challenging multiple choice exams I ever took.