Java Enterprise and Web Technologies

EJB (Enterprise JavaBeans) are specifically designed as business components in Java EE architecture. They encapsulate business logic. Servlets handle web requests/responses, JSP handles presentation - neither are business components.

Servlets are server-side programs that run in a web container. They handle client requests, typically HTTP requests, and generate dynamic responses. They do NOT run on the client side.

The jsp:useBean standard action supports four scope values: page, request, session, and application. Page scope is default and lasts only for the current page. Request scope lasts for the duration of the HTTP request. Session scope persists across multiple requests from the same user. Application scope is shared across all users and sessions. Since all four are valid options, 'All' is correct.

In MVC1 architecture, the JSP page acts as the controller, handling both request processing and presentation. The JSP directly receives requests, contains business logic or calls helper beans, and generates the response. This page-centric approach mixes concerns but simplifies development for simple applications. A separate servlet controller is not used in MVC1.

MVC2 uses a servlet as a central controller, making it servlet-centric architecture. A single controller servlet receives all requests, determines the appropriate handler, invokes business logic, and selects the view for rendering. This separation provides better maintainability and testability compared to page-centric approaches.

In MVC2 architecture, a servlet serves as the controller component. The controller servlet receives HTTP requests, delegates business logic processing to appropriate components (often JavaBeans or EJBs), manages session state, and selects the appropriate JSP view for rendering the response. This clear separation of concerns is a key advantage of MVC2.

Entity beans represent persistent data stored in a database and can survive server crashes because their state persists in storage. Stateful session beans maintain conversational state with a specific client only in memory and lose that state if the server crashes. Session beans typically handle business logic and make calls on entity beans for data operations, not the reverse.

EJB 2.0 local client views allow beans in the same JVM to communicate without remote call overhead. Local clients were introduced to improve performance by eliminating RMI/IIOP overhead when client and bean are co-located. Local interfaces are required for beans in the same container, not merely on the same machine.

JAXB (Java Architecture for XML Binding) provides the API described - it binds XML schemas to Java representations, allowing developers to work with XML data as Java objects without detailed XML knowledge. JAXR is for XML registries, JAXP is for parsing, and SAAJ is for SOAP attachments.

All the listed options (A, B, C, D) are actual advantages of Java EE web services programming model. Resource injection, annotations, multi-version SOAP support, and cross-platform interoperability are all benefits. Therefore 'None of the above' (E) is the correct answer.

EJB 3.0 benefits include: (A) Session beans became simple POJOs managed by the container, eliminating home and component interfaces. (C) Callback methods can be defined either in the bean class itself or in a separate listener class using annotations. B is false because stateless beans no longer require home interfaces. D is false because business interfaces became optional with business interface annotations.

EJB 3.0 introduced an interceptor facility for session beans and message-driven beans, allowing cross-cutting concerns to be applied declaratively. It also enhanced the Java Persistence API to support standard SQL queries through JPQL and native SQL. EJB 3.0 did NOT eliminate lifecycle callback methods (they became optional annotations), and it actually reduced the requirement for checked exceptions, not increased it.

Message-Driven Beans (MDBs) are designed to process JMS messages asynchronously, allowing the EJB container to handle message consumption and bean invocation independently of client requests. This asynchronous processing is their defining characteristic. Option C incorrectly states they process messages synchronously. Option A is wrong because MDBs are enterprise beans, not just a way to describe JMS messages. Option D is incorrect because MDBs specifically work with JMS. Option E describes queue behavior which is not their primary purpose.

Message-Driven Beans differ from Entity and Session Beans in two fundamental ways: they don't have home interfaces (only a bean class with annotations), and clients never access them directly through interfaces (remote or local). MDBs are invoked by the container when messages arrive, not by client calls. They also don't have component interfaces like Session/Entity beans. Option A is false because MDBs lack home and component interfaces. Option C is wrong because MDBs are stateless and don't persist state themselves.

For a CRM system with complex relationships and the requirement to keep business objects free of persistence code, Java Persistence API (JPA) is the best choice. JPA handles complex relationships through annotations (OneToMany, ManyToOne, etc.) and keeps persistence logic separate from business objects using the repository pattern or EntityManager. CMP 2.x entity beans are too complex and invasive. BMP requires persistence code in beans. DAO is a pattern, not a complete persistence solution like JPA.