Question 16 :
Which of the following is NOT true about deploying EJBs in the WebLogic Server?
C is correct because it is NOT true. A and B are true about deploying EJBs in the WebLogic server. The weblogic/config/examples/applications directory acts as an automatic deployment directory for EJB 2.0 .jar files and EJB .jar deployment directories. When you start WebLogic Server, it automatically deploys any valid EJB 2.0 .jar files or .jar directories that reside in the applications directory. WebLogic Server also checks the contents of applications every ten seconds to determine whether an EJB deployment has changed. If a deployment has changed, it is automatically redeployed using the dynamic deployment feature.
If you change the contents of a compiled EJB .jar file in applications, WebLogic Server automatically attempts to redeploy the .jar using the dynamic deployment feature. Since the automatic redeployment feature uses dynamic deployment, WebLogic Server can only redeploy an EJB's implementation classes. You cannot redeploy an EJB's public interfaces. You create compiled EJB 2.0 .jar files by Compiling your EJB classes and interfaces, packaging the EJB classes and interfaces into a valid .jar file and then Using weblogic.ejbc on the .jar file to generate WebLogic Server container classes. An uncompiled EJB .jar file has the same structure as a compiled file, but you do not have to compile individual class files and interfaces and you do not have to use weblogic.ejbc on the packaged .jar file to generate WebLogic Server container classes. So C is not true.
Question 17 :
Which of the following are valid relationships between JMS objects in the WebLogic Server?
JMS is an enterprise messaging system, which enables applications to communicate with one another through the exchange of messages. WebLogic JMS provides a full implementation of the JMS API.JMS objects are the objects necessary to connect to the JMS, and send and receive messages.
The major components of the WebLogic JMS Server architecture include WebLogic JMS servers implementing the messaging facility, Client applications, JNDI and Backing stores (file or database) for storing persistent data. Two or more JMS servers cannot share the same persistent store. Each JMS server must have its own unique persistent store. Two file-based JMS persistent stores may share the same directory, but their messages will be stored in different files. Multiple consumers may consume from the same queue and multiple producers may send messaged to the same queue. Multiple JMS servers may exist on the same WebLogic server, but a JMS server can be deployed only on server at a time.
Question 18 :
Which of the following is NOT true about the security implementation in the WebLogic Server?
C is correct because it is not true about the security in WebLogic server. A,B and D are true. Servlets, JSPs, EJBs, RMI objects, and Java applications use the Java Authentication and Authorization Service to authenticate WebLogic Server. JAAS is a standard extension to the Java 2 Software Development Kit. The authentication component of JAAS provides the ability to reliably and securely maintain client identity, regardless of whether the code is running as a Java application, a JSP, an EJB, an RMI object or a servlet.
In WebLogic Server, JAAS is layered over the existing Security Service Provider Interface (SPI) allowing the continued use of realm-based authorization. The default security realm in WebLogic Server is the File realm. When WebLogic Server is started, the File realm creates User, Group, and ACL objects from properties defined through the Administration Console in WebLogic Server and stored in the fileRealm.properties file. The File realm is designed for use with 1,000 or fewer users, for more no of users, an alternate security realm should be used. In WebLogic Server, an Administration Server is a WebLogic Server that functions as the central source of all configuration information. An Administration Server may contain configuration information for one WebLogic Server or a cluster of WebLogic servers.
Question 19 :
For EJB applications with bean-managed transaction demarcations, which of the following is used by the client to get a reference to the UserTransaction object for the WebLogic Server domain?
WebLogic Server supports the javax.transaction package and the javax.transaction.xa package, which implement the Java Transaction API (JTA) for Java applications.
javax.transaction.UserTransaction provides an interface to the transaction manager that allows the application developer to manage the scope of a transaction explicitly. The client application uses JNDI to obtain an object reference to the UserTransaction object for the WebLogic Server domain.
The code used by the client is given.
If a bean needs a reference to the UserTransaction object, it obtains it from the EJBContext as given.
Question 20 :
Which of the following are true about the transaction support in the WebLogic server?
WebLogic Server provides a Transaction Service that supports transactions in EJB and RMI applications. WebLogic Server allows transactions to be terminated only by the client that created the transaction. WebLogic Server implements the flat transaction model. Nested transactions are not supported.
WebLogic Server supports multithreaded transactional clients. Clients can make transaction requests concurrently in multiple threads. In WebLogic Server, a client or a server object cannot invoke methods on an object that is infected with (or participating in) another transaction. The method invocation issued by the client or the server will return an exception. Also in WebLogic Server, clients using third-party implementations of the Java Transaction API (for Java applications) are not supported.