BEA Weblogic

a. JTA

b. JNDI

c. JMS

d. JTS

e. JMX

Choice B is correct. 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.

UserTransaction ut=(UserTransaction)jndicontext.lookup("javax.transaction.UserTransaction")

If a bean needs a reference to the UserTransaction object, it obtains it from the EJBContext as given.

UserTransaction ut=ejbContext.getUserTransaction()

a. getEJBHome

b. getEJBObject

c. getPrimaryKey

d. getHomeHandle

Choice B is correct. The Handle is a serializable reference to the EJBObject. The EJBObject.getHandle() method returns a Handle object. The Handle allows us to recreate an EJB object remote reference that points to the same type of session bean or the same unique bean that the handle came from.

The Handle interface specifies only one method, getEJBObject(). Calling this method returns the EJB Object from which the handle was created. After getting the object back, we can narrow or cast it to the appropriate remote interface type. The getEJBHome method is defined in the HomeHandle interface and the getPrimaryKey method in the EntityContext interface. The getHomeHandle method is defined in the EJBHome interface.

1:

2:

3:

My Progress Report

4:

5: <% score++; %>

6: <%= "My score is : " + score %>

7:

8:

a. <%! int score = 99; %>

` b. <% int score; %> `

c. <%@ int score = 99; %>

` d. < int score = 99; />

A is the correct choice. The above JSP will work on declaring and initializing the variable score. The syntax for declaring and initializing a variable in JSP is as follows:

<%! variable=variable_value ; %>

Thus A is the correct choice. The <%@ ... %> tag is used to declare directives like include directive. Thus choice C is incorrect. The <% ... %> code is used to insert scriptlets (lines of code in java) like the one at line 5. The code written inside the scriptlet becomes part of the service() method of the generated servlet. Thus 'score' becomes the local variable of the service method. And for this JSP to compile properly, the variable 'score' should have been initialized. If "<% int score; %>" is replaced by "<% int score=99; %>" , the choice B would also be correct. In the present scenario, the choice B will give compilation error saying "Variable score may not have been initialized". Choice D is incorrect as it's not a valid tag.

a. beforeBegin

b. afterBegin

c. beforeCompletion

d. afterCompletion

Choices B, C and D are correct. A stateful session bean using container-managed transactions can implement the javax.ejb.SessionSynchronization interface to provide transaction synchronization notifications. This interface defines only 3 methods - afterBegin(), beforeCompletion() and afterCompletion().

The afterBegin() callback method is called when the bean becomes part of a transaction. It is called before the EJB Object delegates the business method invocation to the bean instance. If the transaction is committed, the bean will be notified through its beforeCompletion() method. If the transaction is rolled back, this method is not invoked. The afterCompletion() method is always invoked whether the transaction ended with a commit or a rollback. A is incorrect because beforeBegin is not a method defined in the SessionSynchronization interface.

Choices:

a. Installer

b. Deployer

c. Bootstrap

d. Packager

Choices A and C are correct. To publish to a WebLogic Server, we can use the ZAC publish wizard. For this, the server must be running, and you will need to know a user and password that has permission to publish. You can also use the ZAC Publish Wizard to create a set of native programs - an installer and a bootstrap - for various operating systems that become part of a published Java application.

The installer program is a native executable that installs your published Java program on the local machine. It doesn't require a Java environment itself, so it can run out-of-the-box in the native OS. The bootstrap is also a native program; the user runs the bootstrap to invoke the published application. The bootstrap takes care of monitoring for updates, downloading and updating the user's application, and other administrative ZAC functions.

You can add a startup script to your UNIX rc scripts to run WebLogic Server at UNIX boot time. Here is an example from an HP-UX 11 system, running under JDK 1.1. You need to supply the URL for your WebLogic Server and your system password. This file, wlstart, is placed in the /sbin/init.d directory and there is a link to it in the /sbin/rc2.d directory:

export SHLIB_PATH=

/home/user1/weblogic/lib/hpux11:/oracle/8.0.4/lib

export CLASSPATH=/home/user1/weblogic/classes:

/home/user1/weblogic/lib/weblogicaux.jar

export ORACLE_HOME=/oracle/8.0.4

export ORACLE_SID=DEMO

export ORACLE_TERM=vt100

export QAT=/home/user1/weblogic

cd $QAT

PATH=/sbin:/usr/sbin:/usr/bin:/opt/java/bin

export PATH

case $1 in

'start')

java -ms64m -mx64m -verbosegc weblogic.Server >

/home/user1/weblogic/server.out 2> #emp;

;;

'stop')

java weblogic.Admin URL shutdown system password

;;

*)

echo "usage: $0 {start|stop}"

;;

esac

You should work with your UNIX system administrator to set up scripts similar to this for your system.

If the existing CORBA object has its remote interfaces defined originally in CORBA IDL, then interoperability is not possible. RMI-IIOP applications can interoperate with other CORBA objects only when their remote interfaces are originally defined as Java RMI interfaces.

For example, to interoperate between an RMI-IIOP client and a C++ object you need to:

1. Define the remote interface of the object in Java as an RMI interface.

2. Run rmic -iiop against the interface to produce the stub for your RMI-IIOP client.

3. Run rmic -idl against the interface to produce IDL compatible with the RMI interface.

4. Run a C++ stub compiler against the IDL file to produce the C++ skeleton for your C++ server object.

a. In case of a MDB, developer needs to create a MessageListener class that utilizes a server-wide session pool.

b. WebLogic Server container provides standard EJB services to MDBs.

c. MDBs benefit from the write-once, deploy-anywhere paradigm of EJBs.

d. MDBs can be associated with multiple Messaging Queues or Topics unlike standard JMS.

Choices B and C are correct. A message-driven bean is a special kind of EJB that acts as a message consumer in the WebLogic JMS messaging system. As with standard JMS message consumers, message-driven beans receive messages from a JMS Queue or Topic, and perform business logic based on the message contents. EJB deployers create listeners to a Queue or Topic at deployment time, and WebLogic Server automatically creates and removes message-driven bean instances as needed to process incoming messages.

Because message-driven beans are implemented as EJBs, they benefit from several key services that are not available to standard JMS consumers. Most importantly, message-driven bean instances are wholly managed by the WebLogic Server EJB container. Using a single message-driven bean class, WebLogic Server creates multiple EJB instances as necessary to process large volumes of messages concurrently. This stands in contrast to a standard JMS messaging system, where the developer must create a MessageListener class that utilizes a server-wide session pool. Thus choice A is incorrect.

WebLogic Server provides standard EJB services to MDBs, such as security services and automatic transaction management. Thus choice B is correct.

Being implemented as EJBs, MDBS benefit from the write-once, deploy-anywhere quality of EJBs. Whereas a JMS MessageListener is tied to specific session pools, Queues, or Topics, message-driven beans can be developed independently of available server resources. Thus Choice C is also correct.

Its not that MDBs are always advantageous as compared to standard JMS consumers. One limitation of MDBs compared to standard JMS listeners is that a given MDB deployment can be associated with only one Queue or Topic. If your application requires a single JMS consumer to service messages from multiple Queues or Topics, you must use a standard JMS consumer, or deploy multiple message-driven bean classes. Thus Choice D is incorrect.

You can use tools such as WebGain, JBuilder, NetBeans and JDB that rely on the Java Platform Debugger Architecture (JPDA) to debug your Java code running in WebLogic Server.

JPDA is integrated in the Java 2 Platform, Standard Edition (J2SE) SDK 1.3 on all platforms and SDK 1.2.2 for Linux. There is a download available from Sun to add JPDA support to the J2SE SDK 1.2.2 on Solaris and Microsoft Window platforms. If you are using J2SE SDK 1.2.2 on these platforms you must first get this download.

To allow a debugger to attach to the virtual machine that WebLogic runs you have to start WebLogic in debug mode. In order to start WebLogic in debug mode using a Sun virtual machine follow these steps (start with step one only if using a Solaris platform):

1. If using a Solaris platform, change the LD_LIBRARY_PATH environment variable to prepend $JAVA_HOME/lib/sparc:

export LD_LIBRARY_PATH=$JAVA_HOME/lib/sparc:$LD_LIBRARY_PATH

2. Add the following parameters to the java command line (before the "weblogic.Server" string) that launches WebLogic server:

-Xdebug

-Xnoagent

-Xrunjdwp:transport=dt_socket

server=y

address=<port_for_debugger_to_connect>

suspend=n

-Djava.compiler=NONE

Note that with the Hotspot Performance engine the -Xnoagent and -Djava.compiler=NONE options are no longer required, but are accepted and ignored for compatibility reasons.

If server=y and no address parameter is supplied, WebLogic Server chooses the transport address and prints it to the standard output stream. So, if a line such as:

Listening for transport dt_socket at address: 46666

prints in your standard output stream when the server starts, the number 46666 is the port number to be supplied to your tool's remote debugger in order to attach it to WebLogic's virutal machine.

If the XML document has a Public ID, then that is its document type. For example, if an XML document contains the following DOCTYPE declaration:

<!DOCTYPE mydoc PUBLIC "My public ID String"

"http://foo.com/url/to/my/dtd">

then its document type is My public ID String.

If the DOCTYPE declaration does not contain a Public ID, but specifies a System ID, then the document type is the System ID. For example, in the following DOCTYPE declaration:

<!DOCTYPE mydoc SYSTEM "http://foo.com/url/to/my/dtd">

the document type is http://foo.com/url/to/my/dtd.

Note: The System ID is of the DTD, not of the XML document itself. It can, however, still be used as a way to identify the XML document.

If the XML document does not specify a DOCTYPE declaration, then the document type can be either the root element name or the namespace URI, if it has one.

The WL-Proxy-Client-Cert header can be spoofed (used) by any client which has direct access to WebLogic Server. WebLogic Server takes the certificate information from that header, trusting that is came from a secure source (the plug-in) and use that information to authenticate the user. In previous releases of WebLogic Server, the default behavior was to always trust that header. Now you need to explicitly define trust of the WL-Proxy-Client-Cert header. A new parameter clientCertProxy allows WebLogic Server to on the implicit trust of the certificate header. If you need an additional level of security, use a connection filter to limit all connections into WebLogic Server (therefore allowing WebLogic Server to only accept connections from the machine on which the plug-in is running).

The clientCertProxy parameter has been added to the HTTPClusterServlet and Web applications.

For the HTTPClusterServlet, add the parameter to the web.xml file as follows:

<context-param>

<param-name>clientCertProxy</param-name>

<param-value>true</param-value>

</context-param>

For Web applications, add the parameter to the web.xml file as follows:

ServletRequestImpl context-param

<context-param>

<param-name>weblogic.http.clientCertProxy</param-name>

<param-value>true</param-value>

</context-param>

You can also use this parameter in a cluster as follows:

<Cluster ClusterAddress="127.0.0.1" Name="MyCluster"

ClientCertProxyHeader="true"/>

If you want to run multiple instances, your servlet will have to implement the SingleThreadModel interface. An instance of a class that implements the SingleThreadModel interface is guaranteed not to be invoked by multiple threads simultaneously. Multiple instances of a SingleThreadModel interface are used to service simultaneous requests, each running in a single thread.

When designing your servlet, consider how you use shared resources outside of the servlet class such as file and database access. Because there are multiple instances of servlets that are identical, and may use exactly the same resources, there are still synchronization and sharing issues that must be resolved, even if you do implement the SingleThreadModel interface.