Java Enterprise and Web Technologies

An Enterprise JavaBean (EJB) component is defined by a set of Java classes and interfaces, such as the bean implementation class, home interface, and component interface. Together, these define the EJB's lifecycle and client interactions, making this option the only complete definition.

EJB components, particularly entity beans, provide standard mechanisms to store and retrieve persistent business data from a database. While EJB supports distributed deployments, the primary service defined in this context is data storage and retrieval, making the other options incorrect.

Enterprise JavaBeans (EJB) specification defines exactly three types of beans. Session beans encapsulate business logic and workflow. Entity beans represent persistent business data (now largely replaced by JPA entities). Message-driven beans handle asynchronous messaging via JMS. 'Object bean' is not a standard EJB type.

Clients interact with session beans to access application business logic. Session beans serve as the client-facing business interface. Entity beans (in EJB 2.x) are for persistence and not directly invoked by clients. Message-driven beans process asynchronous messages and are also not directly invoked by clients.

Session beans are categorized into exactly two types: stateless session beans (no conversational state maintained between calls, can be pooled) and stateful session beans (maintain client-specific state across method invocations). BMP (Bean-Managed Persistence) and CMP (Container-Managed Persistence) are persistence mechanisms for entity beans, not session bean types.

Stateless session beans are used when business operations don't require maintaining client-specific data between method calls. They're more efficient as they can be pooled and shared across clients. Option D correctly describes this scenario. Options A and B suggest scenarios where state might be needed (better for stateful beans). Option C is irrelevant.

Stateful session beans are specifically designed to maintain conversational state with a specific client across multiple method invocations. This makes them ideal for multi-step workflows like shopping carts or wizard-style processes. Option B correctly describes this use case. Option A describes stateless beans. Options C and D are misleading.

Entity beans are designed to represent business objects that need persistent storage - data that survives beyond application sessions. Option A correctly states this purpose. Entity beans map to database tables and handle CRUD operations. Options B, C, and D describe other concerns (communication, review, validation) not related to persistence.

EJB specifications, particularly for stateless session beans, state that these beans do not maintain conversational client state and should not contain custom instance variables. Instead, they are deployed as simple instances managed by the container's pool to execute stateless business methods.

Message-driven beans (MDBs) do not expose remote or local client interfaces. Instead, they act as asynchronous message listeners that the EJB container invokes when messages arrive at their designated queue or topic. Session and entity beans require interfaces for clients to invoke their business methods.

Entity beans in EJB 2.x support two persistence mechanisms: BMP (Bean-Managed Persistence) where the developer writes all database code, and CMP (Container-Managed Persistence) where the container handles persistence automatically. Options C and D correctly identify these. JMS and JAXM (A and B) are messaging technologies unrelated to entity bean persistence.

All servlets must implement the javax.servlet.Servlet interface, either directly or by extending a class like GenericServlet or HttpServlet which already implements it. The Servlet interface defines the lifecycle methods (init, service, destroy) that all servlets must support.

HttpServlet supports both HTTP and HTTPS protocols. The servlet container handles the protocol layer transparently - the same HttpServlet code works regardless of whether the request comes over HTTP or HTTPS.

The false statement is C - Servlets do NOT have GUI interfaces. Servlets are server-side components that generate dynamic content but run without any GUI. In contrast, applets are client-side components that DO have GUI interfaces.