Java Enterprise and Web Technologies

MessageDrivenBeans in EJB cannot have local or remote interfaces because they are designed to process asynchronous messages via JMS (Java Message Service). Unlike session or entity beans, MessageDrivenBeans are implemented as message listeners and are not intended for direct client invocation through business interfaces.

The @PrePassivate annotation in EJB indicates a callback method that is invoked before a stateful session bean is passivated (temporarily serialized to secondary storage). Like other lifecycle callback methods such as @PostConstruct and @PreDestroy, it must return void and throw no checked exceptions.

Stateful session beans in EJB undergo all these lifecycle transitions: construction (when created), destruction (when removed), activation (when restored from secondary storage), and passivation (when temporarily serialized). These callbacks allow the bean to manage its state through the complete lifecycle.

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.