Java Enterprise and Web Technologies

To understand which component executes EJB components, we need to have knowledge about the architecture of Enterprise JavaBeans (EJB) and the roles of different servers in the execution process.

EJB components are server-side components that are used to implement business logic in Java EE applications. They are executed by an EJB container, which is responsible for managing the lifecycle, deployment, and execution of EJB components.

Now let's go through each option and explain why it is right or wrong:

A. a web server: This option is incorrect. A web server is responsible for handling HTTP requests and serving web pages. It does not execute EJB components.

B. an EJB container: This option is correct. An EJB container is specifically designed to execute EJB components. It provides services such as object pooling, concurrency management, security, and transaction management. The EJB container ensures that EJB components are executed in a managed environment.

C. an application server: This option is also correct. An application server is a runtime environment that provides various services to execute enterprise applications. It includes an EJB container as one of its components. The application server manages the execution of EJB components along with other components of the application.

D. a database server: This option is incorrect. A database server is responsible for storing and retrieving data. It does not execute EJB components.

Therefore, the correct answer is:

The Answer is: B. an EJB container

Session Beans (stateful or stateless) are designed to encapsulate business logic and process state for a specific client session. Entity Beans (older EJB tech) represented persistent data. EnterpriseBean is a marker interface. MessageBean would handle messaging.

To answer this question, the user needs to have knowledge of Enterprise JavaBeans (EJB) and how they are used in Java applications.

Now, let's go through each option and explain why it is right or wrong:

A. An EJB handle is used to handle exceptions when accessing EJB objects. This option is incorrect. An EJB handle is not used to handle exceptions. Exceptions in EJBs are typically handled using try-catch blocks or by declaring them in the method signature.

B. An EJB handle is used to store a reference to a specific EJB object. This option is correct. An EJB handle is used to store a reference to a specific EJB object. It allows the client to maintain a reference to an EJB object and use it to invoke methods on that object.

C. An EJB handle is part of the Home interface. This option is incorrect. An EJB handle is not part of the Home interface. The Home interface is used for creating and finding EJB objects, while the handle is used to store a reference to an existing EJB object.

D. An EJB handle is used for local references inside the EJB container. This option is incorrect. An EJB handle is not specific to local references inside the EJB container. It can be used for both local and remote references to EJB objects.

Therefore, the correct answer is:

The Answer is: B

When declaring an EJB local reference, you specify: the local home interface (B), the reference type (ejb-ref-type), and the JNDI binding name (A). You do NOT specify the (remote) home interface (C) because local references are exclusively for local interfaces - mixing local and remote in the same reference is invalid. Local references use LocalHome and Local (or LocalBusiness) interfaces only, not remote Home interfaces.

For stateful session beans, ejbPassivate() serializes the bean to secondary storage (temporarily saving it), and ejbActivate() restores it. However, ejbStore() is the method that explicitly saves the bean's state to persistent storage during passivation or before container shutdown. ejbCreate() (A) is for initialization, not saving state. ejbPassivate() (B) triggers the passivation process but ejbStore() does the actual saving work. ejbSave() (D) doesn't exist in the EJB API.

SessionContext provides transaction management (getUserTransaction, setRollbackOnly), security context (getCallerPrincipal, isCallerInRole), and timer service access. Data source references are obtained through JNDI lookups using resource references in the deployment descriptor, not through SessionContext methods.

For EJB 2.x, local home interfaces are looked up via JNDI and directly cast (option B). Remote home interfaces require PortableRemoteObject.narrow() for proper RMI/IIOP type narrowing (option E). The code is truncated but shows the correct narrow() pattern.

In BMP with 1:1 composition, the Person must cascade delete to Address. This is implemented by having Person.ejbRemove() call Address.remove(). Additionally, Person.ejbLoad() must invoke Address.ejbLoad() to synchronize the dependent Address bean's state when Person is loaded, maintaining referential integrity.

ejbSelect methods are query methods defined in the entity bean class but not exposed in home/remote interfaces. They perform database operations independent of a specific bean instance, often used within home methods (ejbHome) to return entity results or aggregate values.

A message-driven bean requires a message listener port (also called an activation spec or JMS listener) to be configured on the application server. This defines the JMS destination and connection factory the MDB will listen to. Without this configuration, the MDB cannot receive messages.

In EJB 2.x, Container-Managed Persistence (CMP) fields are not declared as variables in the bean class. Instead, they are defined as virtual properties via abstract getter and setter methods. The actual mapping and field definitions are specified in the deployment descriptor's abstract persistence schema.

In CMP entity beans, CMR (Container Managed Relationships) fields are declared as abstract accessor methods (get/set) in the bean class, not as concrete fields. The container generates the actual implementation. The relationship role mappings are defined in ejb-relationship-role elements of the deployment descriptor.

When a session bean demarcates the transaction (using UserTransaction) and calls an entity bean, the entity bean should have transaction attribute 'Required' to ensure it joins the existing transaction context. 'Supports' would allow it to run non-transactionally, which could cause data inconsistency.