Sun Certified Business Component Developer (SCBCD) Quiz

Q1: It is important to note that the object retrieved from JNDI is directly cast to the correct interface type without being narrowed first. This clearly indicates that we are dealing with the local client view of a session bean. This rules out choice A, as RemoteException must only be declared when dealing with remote client views.

Choice B is incorrect. Even if the exception called were FinderException, the answer would still be incorrect, as only entity bean home interfaces define finder methods.

Choice C is correct. Any application specific exceptions might be thrown from the methods declared in the home interface of a session bean.

Choice D is correct since session bean home interface have to declare at least one create method and the throws clause of create methods must include CreateException.

Choice E is incorrect since RuntimeException is an unchecked exception and it is not mandatory to declare such exceptions in the throws clause of the methods.

Q2.Choice A is correct because non-transient member fields are allowed to refer to null and still be serializable.

Choice B is incorrect, because there is no such interface called javax.transaction.Transaction. The correct interface name is javax.transaction.UserTransaction.

Choice C is correct. Even if the session context object is not serializable, the EJB container must ensure that the SessionContext object will be serialized properly, so that it can be used again when the session bean is activated.

Choice D is incorrect because a JDBC connection is not serializable. The Bean Provider must close all JDBC connections and set their references to null in the ejbPassivate() method.

Choice E is correct since the Java Serialization protocol determines dynamically if an object is serializable or not based on its runtime type and not on its declared type. It is worth noting that an EJB container is not required to use the Java Serialization protocol when passivating beans, it is free to use any techniques it deems appropriate. However, the chosen technique must achieve the same result as the Java Serialization protocol.

Q3. Choices A and B are incorrect. An ejbCreate method is never invoked on a stateless session bean or on a message-driven bean when a client invokes the corresponding create method of the bean's home interface. A client can still invoke a create method and think it is in charge of the bean's lifecycle, but that's not what is happening under the hood. The EJB container is alone responsible for creating new instances of such enterprise beans.

Choices C and D are correct. When a client invokes a create method on an entity bean's home interface or on a stateful session bean's home interface, the corresponding ejbCreate method is invoked on the enterprise bean's instance.

Q4. Primary keys only make sense for entity beans. As a result, the only possible answer is choice C.

Q5. Choices A and D are incorrect because the ejbFind<METHOD>() and ejbSelect<METHOD>() methods are declared to be abstract in an entity bean class. The Bean Provider only needs to declare them but not to implement them. It is the responsibility of the EJB container to provide an implementation for these methods.

Choice B is incorrect since the setRollbackOnly() method is defined in the javax.ejb.EJBContext and javax.transaction.UserTransaction interfaces that must be implemented by the EJB container.

Choices C and E are correct. The Bean Provider must implement the unsetEntityContext() and ejbLoad() methods. Note that the former is invoked when the life cycle of the entity bean instance has been terminated by the EJB container. The latter is called when the container needs to synchronize the state of an entity bean instance with the entity object's persistent state.

Q6. In order to choose the correct answers, let's describe what happens: The method A (in transaction A) invokes the method B. The only way the method B will run in an unspecified transaction context is by specifying the NotSupported transaction attribute. If the transaction attribute of the method B were Supports, then the method B would run in transaction A, and if it were Never, an exception would have been thrown by the EJB container. Hence, Choices A and D can be ruled out.

The method C is invoked by the method B and in order for it to run in transaction B, only the transaction attributes Required or RequiresNew can be specified. This rules out choice F, because an exception would have been thrown by the EJB container since Mandatory requires that a transaction context exists before invoking the method.

When the methods C and B return, the method A invokes the method D. Knowing that the method D runs in the same transaction context as the method A, we can figure out that only the transaction attributes Supports, Required and Mandatory can be used.

When the method D returns, the method A invokes the method E that runs in a new transaction (C). The only way to achieve this is to use the RequiresNew transaction attribute for method E.

Finally, the method E in transaction C invokes the method F that runs in an unspecified transaction context. The only way to suspend the transaction C is to use the NotSupported transaction attribute, as it was the case with method B. If the transaction attribute of method F was Never, an exception would have been thrown by the EJB container, so this choice can be ruled out.

According to what precedes, only choices B and E are correct.

Q7. Choices A, C, and E are incorrect because all these exceptions are standard application exceptions defined by the EJB 2.0 specification.

Choice B is also incorrect, as java.lang.Exception is the superclass of all application exceptions.

Choice D is correct. javax.ejb.NoSuchEntityException is a subclass of the javax.ejb.EJBException, which denotes a system exception.

Q8. Choice C is the correct answer. A Bean Provider may use the in order to specify the shareability of connections obtained from a resource manager connection factory reference. The element can take two possible values, namely, Shareable and Unshareable.

All the other choices are incorrect, as those deployment descriptor elements do not exist.

Q9. Choice A is incorrect because EJBs are allowed to be network clients as long as they do not connect to multicast sockets. However, they cannot be network servers, that is, they cannot listen and accept connections by using an instance of the class java.net.ServerSocket.

Choice B is correct since EJBs are not allowed to use the java.io package in order to access files and directories in the file system. The EJB container is responsible for logging errors in case something bad happens.

Choice C is incorrect because it is not allowed that EJBs create or install their own security manager. This would create potential security hole.

Choice D is correct. EJBs are allowed to retrieve resources (images, texts, properties, etc) that have been bundled within the same enterprise application archive.

Choice E is incorrect, as it is not admissible for EJBs to use any component or sub-component of the java.awt package. Remember that EJBs are server-side components and that it does not make a lot of sense to use graphical components on the server to display information to the user on the client-side.

Choice F is incorrect. EJBs are not allowed to create new threads, or even manage existing ones, as the runtime environment is under the unconditional responsibility of the EJB container.

Q10. Choices A and B are incorrect since there are no such methods in the EJB(Local)Home and EJB(Local)Object interfaces.

Choice C is correct. Invoking the remove() method on an entity bean's home interface and providing the entity bean's primary key in argument results in the ejbRemove method to be invoked and in the removal of the persistent representation of the entity bean.

Choice D is correct. Given that two entity beans, E1 and E2, are in a one-to-one relationship and that the element has been specified for E2, when E1 is removed, so will E2. This is also true for one-to-many relationships, but not for many-to-many relationships.

Q11. Choice A is incorrect since the primary key class must be declared public and not private.

Choice B is incorrect because the primary key class does not need to be declared abstract. The container should be allowed to use the primary class without having to extend it.

Choice C is also incorrect as there is no such requirement. All fields of the primary key class must be declared public, even if this means that the encapsulation of the class is broken. Hence, choice D is correct.

Choice E is also correct. The primary key class is not allowed to declare fields having names that are different from the names of the container-managed fields declared in the <cmp-field> elements in the deployment descriptor.

Q12. Choice A is correct, as the query is well formed and syntactically correct. The query selects all invoices whose amount is bigger than 1000.

Choice B is incorrect because the FROM clause is mandatory in any EJB-QL expression. Moreover, all identification variables must be declared in the FROM clause, and not in the WHERE clause.

Choice C is incorrect, as the SELECT clause must not use the OBJECT operator to qualify path expressions (inv.amount).

Choice D is correct since all keywords of the EJB-QL language as well as all identification variables are case insensitive. This means that one cannot define two identification variables named INV and inv, for instance.

Choice E is incorrect, as the DISTINCT keyword is used to remove all duplicate elements from the result set. In order to qualify an identification variable, one must use the OBJECT keyword.

Q13. Choice A is correct. The code does not compile because the lookup method may throw a javax.naming.NamingException, which is a checked exception. Since the EJB 2.0 specification prohibits the onMessage() method to declare any application exception in its throws clause, a try-catch block must be used. Therefore, choice D is also correct. In addition, the narrow() method may throw a java.lang.ClassCastException (unchecked exception) and the EJB 2.0 specification recommends that well-behaved message-driven beans should not throw any RuntimeException.

Choices B and C are incorrect for the reasons given above.

Choice E is incorrect, as the onMessage() method given in the question statement satisfies the requirements stated in section 15.7.4 of the EJB 2.0 specification.

Q14. Choices A, B and E are incorrect. The responsibilities of the Bean Provider and Application Assembler roles have been interchanged. The opposite is correct, though. Hence, Choices C and D are correct. The Bean Provider is responsible for defining security role references with the <security-role-ref> element. These roles are security roles referenced in the code.

The Application is responsible for building the application and defining the security roles of the enterprise application using the <security-role> element. These security roles are logical, as the Application Assembler has no knowledge of the security environment of the operational environment on which the application will be deployed.

It is the Application Assembler's duty to link every security role reference defined by the Bean Provider to security roles defined by him using the <role-link> element. There is no such element as the <security-link> element. Therefore, Choice E is incorrect.

Q15. Stateless session beans do not keep any conversational state between client invocations. This doesn't mean that a stateless session bean class cannot declare instance variables. However, these instance variables should not be used to store client data. For example, a session bean class usually stores a reference to a SessionContext instance given by the container into an instance variable, but this is not part of the conversational state.

Q16. When a get accessor method for a collection-valued cmr-field that has no related values is invoked, the method must return an empty collection. Since the collection in question must not contain duplicate values, the only possible choice is D.

Choice B would be correct if the cmr-field allowed duplicate values.

All the other choices are incorrect.

Q17. The only correct choice is E. The setSessionContext() method is defined in the javax.ejb.EntityBean interface and takes one argument of the type javax.ejb.EntityContext. This method is invoked only once and very early in the life cycle of entity beans. It gives the entity bean instance an opportunity to get a reference on the context in which it will be running. All other choices are incorrect.

Q18. The difficult thing to do here is to decorticate the information contained in the question statement. First, we know that the bean throws a javax.ejb.EJBException, so we know we are dealing with a local client. Therefore, we can eliminate choices C, D and E right away.

Second, since the transaction attribute of the business method is Mandatory, we know for sure that a client transaction existed (otherwise the container would have thrown javax.ejb.TransactionRequiredLocalException) and that choice F is incorrect.

When a business method that executes in the context of the local caller's transaction throws a javax.ejb.EJBException, the EJB container is required to throw javax.ejb.TransactionRolledbackLocalException as mentioned in Table 15 on page 375 of the EJB 2.0 specification. Therefore, choice B is correct.

Since the javax.ejb.EJBException is not propagated, choice A is incorrect.

Q19. Choices A and D are correct. It is the responsibility of the Bean Provider to define all roles referred to in the code by using the deployment descriptor element called <security-role-ref>. In this case, the isCallerInRolle() method refers to a role, called "admin". Since the Bean Provider does not know which security roles will exist in the target operational environment, he defines so called security role references, which can be seen as logical security roles. Then, the Application Assembler creates the security roles and links the Bean Provider's security role references to them using the <role-link> element. Thus, the <role-link> element must contain the name of a security role (Administrator).

According to what precedes, Choices B and C are incorrect.

Q20. Choice A is incorrect, as creating new session beans is clearly under the responsibility of the (remote or local) home interface.

Choice B is correct. The component interface provides a method called remove() that allows client to remove the associated session bean.

Choice C is correct, as the local and remote component interfaces provide a method called getEJBLocalHome(), respectively getEJBHome(), that returns the local, respectively remote, home interface of the session bean.

Choice D is incorrect because only the remote component interface provides the ability to get a handle for later use.

Choice E is incorrect since session beans do not make their identity available to clients. As a result, when the method getPrimaryKey() is invoked on the local, respectively remote, component interface, an javax.ejb.EJBException, respectively a java.rmi.RemoteException, will be thrown to the client.