Java Enterprise and Web Technologies

When building UI controls with JavaScript, all the code runs on the client side in the browser. This means the entire source code is visible to anyone who uses View Source or browser developer tools - there's no way to hide or protect it. This exposes business logic, algorithms, and proprietary implementation details. Options A and C are incorrect - JavaScript development is standard and deployment is simply hosting files. Option D is false.

Web Services enable standardized communication between applications across different platforms and technologies. Option B correctly identifies the core use case: exchanging data between heterogeneous systems. Option D complements this with interoperability - a key goal of web services. Option A is incorrect because web services don't guarantee message delivery (that requires WS-ReliableMessaging). Option C describes a scenario where web services add unnecessary complexity.

JAX-WS (Java API for XML Web Services) is the modern standard that uses JAXB for XML data binding. JAX-RPC is the older, deprecated API. Option A is wrong because both are web service APIs. Option B claims both use JAXB, which is false - JAX-RPC does not. Option D incorrectly states JAX-RPC uses JAXB. Only JAX-WS uses JAXB.

Hibernate's default_entity_mode is set to 'pojo' by default, which means it works with Plain Old Java Objects as the default entity representation mode for mapping.

Hibernate can be configured programmatically using Java code, via a hibernate.properties file, or using hibernate.cfg.xml. All three methods are valid approaches depending on the project requirements.

The tag in hibernate.cfg.xml is used to add HBM XML resources for the current session factory. Each mapping resource points to an XML file containing entity mappings.

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.

web.xml is the standard deployment descriptor for Java web applications. It contains configuration for servlets, filters, welcome files, and other web application settings. While context.xml exists (in Tomcat), web.xml is the universal deployment descriptor.

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.

Context parameters (defined in web.xml) are application-wide and accessible globally via ServletContext to all servlets and filters in the application. Unlike servlet-specific init parameters, context parameters are shared across the entire application.

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.