Java Enterprise and Web Technologies

The Application Assembler is responsible for assembling enterprise beans into application modules and can override transaction attributes defined by the Bean Provider. The Deployer then deploys these assembled modules, while System Administrators manage runtime resources. The Bean Provider only defines default transaction attributes.

EJB architecture defines a distributed component-based architecture for building enterprise business applications. It provides services like transaction management, security, and persistence while allowing developers to focus on business logic. EJB is Java-specific (not language-independent) and predates Web Services, being built on RMI-IIOP, not Web Services architecture.

Container-Managed Transactions (CMT) can be used with both Session and Entity Beans. However, Bean-Managed Transactions (BMT) are strictly prohibited for Entity Beans by the Enterprise JavaBeans specification. Entity Beans must always use CMT. Therefore, the statement is false.

In EJB specifications, the lifecycle states of a Stateless Session Bean are limited to 'Does not exist' and 'Method-ready pool' (or 'Pooled'). Among the choices, 'Does not exist' is the standard lifecycle state. 'Passive' only applies to stateful session beans during passivation.

To invoke an external web service in TIBCO BusinessWorks, you need both the Invoke Partner activity (which makes the actual call) and a Partner Link Configuration (which defines the web service endpoint, WSDL, and binding details). Get Context is for retrieving context variables, and SOAP Request Reply might seem plausible but is not the standard activity for this purpose - Partner Link is the correct mechanism.

For Container-Managed Transactions (CMT), the default transaction attribute is 'Required', meaning the method must always execute within a transaction. If none exists, the container creates one. NotSupported, RequiresNew, and Supports are all valid attributes but must be explicitly specified - they are not defaults.

Stateful session beans support all four callback types: construction (PostConstruct), destruction (PreDestroy), activation (PostActivate), and passivation (PrePassivate). These lifecycle events allow the container to manage bean state when passivating to secondary storage or activating back into memory.

Stateless session beans only support two lifecycle callbacks: PostConstruct (after creation) and PreDestroy (before removal). They don't support activation/passivation because they don't maintain conversational state - instances are pooled and interchangeable.

The lifecycle methods for Stateful Session Beans are: PostConstruct (after creation), PreDestroy (before removal), PostActivate (after passivation), and PrePassivate (before passivation). There is no 'Pre Construction' lifecycle method - construction happens before PreConstruct, not after. PreConstruction would imply something happens before the bean exists, which is impossible.

The key advantage of JSP over Servlet is that it allows embedding Java code directly in HTML, making it easier to maintain the presentation layer. Options B, C, and D are capabilities shared by both JSP and Servlets - they're platform-independent, can create database-driven apps, and both are server-side technologies.

JSP lifecycle methods are jspInit() (called once when JSP is initialized), _jspService() (called for each request, equivalent to service() in servlets), and jspDestroy() (called when JSP is destroyed). Option B lists servlet lifecycle methods. Option C is only one method (doPost is HTTP method handler, not lifecycle).

In the MVC (Model-View-Controller) architecture, JSP serves as the View component - it handles presentation and display. The Model represents data and business logic. The Controller (often a Servlet) handles request processing and coordinates between Model and View.

J2EE supports multiple client types for accessing enterprise applications. Applets are client-side Java programs that run in browsers. Web browsers are the most common J2EE clients using HTTP. Wireless clients include mobile devices and PDAs that access J2EE applications through WAP or similar protocols. Since all three are valid J2EE client types, option D is correct.

The statement is false because while HTTP-based servlets extend HttpServlet, the Servlet API also supports generic servlets that extend javax.servlet.GenericServlet. GenericServlet is protocol-independent and can be used for any protocol, not just HTTP. HttpServlet specifically handles HTTP requests and responses.

The JSP translation to servlet happens only once when the JSP is first requested or when it has been modified. The web container compiles the JSP into a servlet class and caches it. Subsequent requests execute the already-compiled servlet without retranslation. This makes JSP processing efficient after the initial compilation.