Answers of Q2. is ACD and not BCD and that of Q3.is D. Following are the excerpts from ejb2.0 specs:
Regarding Q2.:
We set the following goals for the security management in the EJB architecture:
� Lessen the burden of the application developer (i.e. the Bean Provider) for securing the application
by allowing greater coverage from more qualified EJB roles. The EJB Container provider
provides the implementation of the security infrastructure; the Deployer and System
Administrator define the security policies.
� Allow the security policies to be set by the Application Assembler or Deployer rather than
being hard-coded by the Bean Provider at development time.
� Allow the enterprise bean applications to be portable across multiple EJB Servers that use different
security mechanisms.
Regarding Q3.
If the client receives the java.rmi.RemoteException or the javax.ejb.EJBException
exception from a method invocation, the client, in general, does not know if the enterprise Bean�s
method has been completed or not.
If the client executes in the context of a transaction, the client�s transaction may, or may not, have been
marked for rollback by the communication subsystem or target bean�s Container.
For example, the transaction would be marked for rollback if the underlying transaction service or the
target Bean�s Container doubted the integrity of the data because the business method may have been
partially completed. Partial completion could happen, for example, when the target bean�s method
returned with a RuntimeException exception, or if the remote server crashed in the middle of executing
the business method.
The transaction may not necessarily be marked for rollback. This might occur, for example, when the
communication subsystem on the client-side has not been able to send the request to the server.
When a client executing in a transaction context receives a RemoteException or an EJBException
from an enterprise bean invocation, the client may use either of the following strategies to deal
with the exception:
� Discontinue the transaction. If the client is the transaction originator, it may simply rollback its
transaction. If the client is not the transaction originator, it can mark the transaction for rollback
or perform an action that will cause a rollback. For example, if the client is an enterprise
bean, the enterprise bean may throw a RuntimeException which will cause the Container
to rollback the transaction.
� Continue the transaction. The client may perform additional operations on the same or other
enterprise beans, and eventually attempt to commit the transaction. If the transaction was
marked for rollback at the time the RemoteException or EJBException was thrown to
the client, the commit will fail.
If the client chooses to continue the transaction, the client can first inquire about the transaction status to
avoid fruitless computation on a transaction that has been marked for rollback. A client that is an enterprise
bean with container-managed transaction demarcation can use the EJBContext.getRollbackOnly()
method to
test if the transaction has been marked for rollback; a client that is an
enterprise bean with bean-managed transaction demarcation, and other client types, can use the User-
Transaction.getStatus() method to obtain the status of the transaction.