BEA Weblogic

a. Only The Holder Classes

b. Only The Helper and Holder Classes

c. The implementation class(es) written by the user to provide body to the methods defined in the interface class

d. All idltojava generated files (stubs, skeletons, helper, holder and interface classes)

Choice C and D are correct. The Helper class (a final class) provides auxiliary functionality, notably the narrow() method required to cast CORBA object references to their proper types. The Holder class provides operations for out and inout arguments, which CORBA has but which do not map easily to Java's semantics. The server application cannot be compiled successfully until the implementation class(es) has/have been written and compiled. All the other generated files however must be compiled to form '.class' files from the '.java' files. Thus all the implementation classes written by the user and all the "idltojava" generated files must be complied to run the CORBA Server.

Yes. Beginning with WebLogic Server version 6.0, EJBs must be homogeneously deployed across a cluster for the following reasons:

* To keep clustering EJBs simple

* To avoid cross server calls which results in more efficiency. If EJBs are not deployed on all servers, cross server calls are much more likely.

* To ensure that every EJB is available locally

* To ensure that all classes are loaded in an undeployable way

* Every server must have access to each EJB's classes so that it can be bound into the local JNDI tree. If only a subset of the servers deploys the bean, the other servers will have to load the bean's classes in their respective system classpaths which makes it impossible to undeploy the beans.

Using OS authentication in connection pools essentially means that you are using the UserId of the user who started WebLogic Server. OS authentication is available on NT and UNIX, but not on Solaris. This means that database security will rely strictly on the security of WebLogic; that is, if you are allowed to make a client connection to the WebLogic Server and access the pool, then you can get to the database.

You can do this with WebLogic jDriver for Oracle because Oracle uses the process owner to determine who is attempting the connection. In the case of WebLogic JDBC, this is always the user that started the WebLogic Server.

To set up your Oracle instance to use this feature, your DBA needs to follow these basic steps. The full procedure is described in more detail in your Oracle documentation.

1. Add the following line to the INIT[sid].ORA file:

OS_AUTHENT_PREFIX = OPS$

Note that the string "OPS$" is arbitrary and up to the DBA.

2. Log in to the Oracle server as SYSTEM.

3. Create a user named OPS$userid, where userid is some operating system login ID. This user should be granted the standard privileges (for example, CONNECT and RESOURCE).

4. Once the userid is set up, you can connect with WebLogic jDriver for Oracle by specifying "/" as the username property and "" as the password property. Here is an example for testing this connection with the dbping utility:

$ java utils.dbping ORACLE "/" "" myserver

Here is a code example for WebLogic jDriver for Oracle:

Properties props = new Properties();

props.put("user", "/");

props.put("password", "");

props.put("server", "myserver");

Class.forName("weblogic.jdbc.oci.Driver").newInstance();

Connection conn = myDriver.connect("jdbc:weblogic:oracle",

props);

1. Use the Administration Console to set the attribute for your connection pool. The following code is an example of a JDBC connection pool configuration using the WebLogic jDriver for Oracle:

<JDBCConnectionPool

Name="myPool"

Targets="myserver,server1"

DriverName="weblogic.jdbc.oci.Driver"

InitialCapacity="1"

MaxCapacity="10"

CapacityIncrement="2"

Properties="databaseName=myOracleDB"

a. DefaultWebApp/META_INF/classes

b. DefaultWebApp/META_INF/lib

c. DefaultWebApp/WEB_INF/lib

d. DefaultWebApp/WEB_INF/classes

e. DefaultWebApp/classes

Choice D is correct. When packaging a web application create META-INF and WEB-INF subdirectories in the application directory to hold deployment descriptors and compiled Java classes. All servlet classes and helper classes should reside in the WEB-INF/classes subdirectory. The home and remote interface classes for enterprise beans used by the servlets into the WEB-INF/classes subdirectory.

All the HTML files, JSP files, images, and any other files that these Web pages reference should exist in the application directory, maintaining the directory structure for referenced files. The META_INF directory contains the deployment descriptors for the enterprise beans, but not the classes.

Due to the fact that the current configuration and packaging requirements for resource adapters in WebLogic Server require the hand-editing of the weblogic-ra.xml file, any new passwords specified in the security-principal-map entries are done in clear-text.

BEA understands the importance of protecting security passwords. Hence, we provide a Converter Tool that allows for the encryption of all passwords present in the weblogic-ra.xml file. The Converter Tool is shipped in the standard weblogic.jar file. For more information about the Password Converter Tool, see Using the Password Converter Tool in the Configuration section of the Programming the WebLogic J2EE Connector Architecture Guide at ../jconnector/index.html.

a. Close any open resources, like database connections

b. All non-transient, non-serializable fields(except some special types) should be set to null.

c. All transient fields should be set to null

d. Make all database connection reference fields transient

e. All primitive type fields should be set to null

Choices A, B and D are correct. When a bean is about to be passivated, its ejbPassivate() method is invoked, alerting the bean instance that it is about to enter the Passivated state. At this time, the bean instance should close any open resources and set all non transient, non serializable fields to null. This will prevent problems from occurring when the bean is serialized. Transient fields will simply be ignored.Serializable fields will be saved.Open resources such as sockets or JDBC connections must be closed whenever the bean is passivated. In stateful session beans, open resources will not be maintained for the life of the bean instance. When a stateful session bean is passivated, any open resource can cause problems with the activation mechanism.

A bean's conversational state may consist of only primitive values, objects that are serializable, and the following special types-SessionContext, EJBHome, EJBObject, UserTransaction and Context (only when it references the JNDI ENC) . The types in this list (and their subtypes) are handled specially by the passivation mechanism. They don't need to be serializable; they will be maintained through passivation and restored automatically to the bean instance when it is activated

I tried to run two of the applets in the examples directory of the distribution. I installed the WebLogic classes on my local machine (NT server) and on another machine (a Windows 95 client). I am not using any browsers, just trying to run the applets with Appletviewer. The applets work fine when I run Appletviewer from the NT server, but do not work at all from the Windows 95 client.

There are two possible problems: Either the CODEBASE tag is not properly set in the applet HTML file, or the class files are not properly loaded on the HTTP server.

The applet works on the NT server because you installed the WebLogic distribution on your NT server. Even if the applet cannot successfully load the necessary classes from the HTTP server, it does find them in your local CLASSPATH. But when you try to run it from the Windows 95 client, the applet must load the classes over the wire from the HTTP server, and if you haven't installed them correctly, it will fail.

No. Within an unsigned applet, you cannot load native libraries over the wire, access the local file system, or connect to any host except the host from which you loaded the applet. The applet security manager enforces these restrictions on applets as protection against applets being able to do unsavory things to unsuspecting users.

If you are trying to use jDriver for Oracle from an applet, then you are violating the first restriction. Your applet will fail when it attempts to load the native (non-Java layer) library that allows jDriver for Oracle to make calls into the non-Java Oracle client libraries. If you look at the exception that is generated, you will see that your applet fails in java.lang.System.loadLibrary, because the security manager determined that you were attempting to load a local library and halted the applet.

You can, however, use the WebLogic JTS or Pool driver for JDBC connectivity in applets. When you use one of these WebLogic multitier JDBC drivers, you need one copy of WebLogic jDriver for Oracle (or any other two-tier JDBC driver) for the connection between the WebLogic Server and the DBMS.

BEA WebLogic is a J2EE application server and also an HTTP web server by BEA Systems of San Jose, California, for Unix, Linux, Microsoft Windows, and other platforms. WebLogic supports Oracle, DB2, Microsoft SQL Server, and other JDBC-compliant databases. WebLogic Server supports WS-Security and is compliant with J2EE 1.3.

BEA WebLogic Server is part of the BEA WebLogic Platform™. The other parts of WebLogic Platform are:

► Portal, which includes Commerce Server and Personalization Server (which is built on a BEA-produced Rete rules engine),

► WebLogic Integration,

► WebLogic Workshop, an IDE for Java, and

► JRockit, a JVM for Intel CPUs.

WebLogic Server includes .NET interoperability and supports the following native integration capabilities:

► Native enterprise-grade JMS messaging

► J2EE Connector Architecture

► WebLogic/Tuxedo Connector

► COM+ Connectivity

► CORBA connectivity

► IBM WebSphere MQ connectivity

BEA WebLogic Server Process Edition also includes Business Process Management and Data Mapping functionality.

WebLogic supports security policies managed by Security Administrators. The BEA WebLogic Server Security Model includes:

► Separate application business logic from security code

► Complete scope of security coverage for all J2EE and non-J2EE components

Your JDBC code may throw the following exception:

"The coordinator has rolled back the transaction.

No further JDBC access is allowed within this transaction."

The WebLogic JTS JDBC driver throws this exception when the current JDBC connection transaction rolls back prior to or during the JDBC call. This exception indicates that the transaction in which the JDBC connection was participating was rolled back at some point prior to or during the JDBC call.

The rollback may have happened in an earlier EJB invoke that was part of the transaction, or the rollback may have occurred because the transaction timed out. In either case, the transaction will be rolled back, the connection returned to the pool and the database resources released. In order to proceed, the JTS JDBC connection must be closed and reopened in a new transaction.

a. Home

b. Handle

c. HomeHandle

d. EJBHomeHandle

e. HomeObject

Choice C is correct. Once a client has obtained the EJBHome object for an EJB instance, it can create a reference to the home object by calling getHomeHandle(). getHomeHandle() returns a HomeHandle object, which can be used to obtain the home interface to the same EJB instance at a later time.

A client can pass the HomeHandle object as arguments to another client, and the receiving client can use the handle to obtain a reference to the same EJBHome object. Clients can also serialize the HomeHandle and store it in a file for later use. The HomeHandle interface has only one method getEJBHome(), which returns the EJBHome reference.

A.) ejbStore() 1.) INSERT

B.) ejbLoad() 2.) UPDATE

C.) ejbCreate() 3.) SELECT

a. A->1, B->2, C->3

b. A->2, B->1, C->3

c. A->3, B->2, C->1

d. A->1, B->3, C->2

e. A->2, B->3, C->1

f. A->3, B->1, C->2

Choice E is correct. When the create() method on a home interface is invoked, the container delegates the create() method call to the bean instance's matching ejbCreate() method. The ejbCreate() methods are used to initialize the instance state before record is inserted into the database. The ejbCreate() method is analogous to INSERT. The ejbStore() method is invoked just before the container the container is about to write the bean container-managed fields to the database. It is analogous to the UPDATE . The ejbLoad() is invoked just after the container has refreshed the bean container-managed files with its state from the database. It is analogous to the SELECT. Thus choice E is correct and others are not.

The following is some pseudo-code

for a producer class.

class ProducerPool {

static Hashmap pSets = new Hashtable();

static Hashmap inUse = new Hashtable();

QueueSender get(String contextURL,

String connectionFactoryName,

String destinationName) {

String lookup = contextURL+";

"+connectionFactName+";"+destName;

synchronized(pSets) {

producer set = pSets.get(lookup);

if (set != null && set not empty)

qs = set.removeFirst();

}

if (producer == null) {

create ctx

get connect factory

create connection

create session

look up destination

qs = create queue sender

}

synchronized(inUse) {

inUse.put(qs, lookup);

}

return qs;

}

void put(QueueSender qs) {

String lookup;

synchronized(inUse) {

lookup = inUse.remove(p);

}

synchronzied(pSets) {

producer set = pSets.get(lookup);

if (set == null) {

producer set = new producer set

pSets.put(lookup, producer set);

}

producer set.add(qs);

}

}

}

Note: Static classes may be garbage collected if there are no references to them, so make sure the application server has a permanent pointer to them in some manner. One way is to reference it permanently from within a servlet or EJB when they are initialized at startup.

Here is an example of using the producer pool within the onMessage method.

onMessage() {

QueueSender qs = ProducerPool.get(...);

qs.send(...);

ProducerPool.put(qs);

}

You can pre-populate this pool by calling it from

a startup class or a load-on-start servlet class.