What is BEA Weblogic?
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
Which of the following statements are true regarding
MDBs (Message Driven Beans) on version 6.0 of WebLogic
App Server?
a. MDBs support concurrent processing for both Topics
and Queues.
b. MDBs support concurrent processing for only Topics.
c. MDBs support concurrent processing for only Queues.
d. MDBs support concurrent processing neither Topics nor
Queues.
Choice A is correct. MDBs support concurrent processing
for both Topics and Queues. Previously, only concurrent
processing for Queues was supported. To ensure
concurrency, change the weblogic-ejb-jar.xml deployment
descriptor max-beans-in-free-pool setting to >1. If this
element is set to more than one, the container will
spawn as many threads as specified. WebLogic Server
maintains a free pool of EJBs for every stateless
session bean and message driven bean class.
The max-beans-in-free-pool element defines the size of
this pool. By default, max-beans-in-free-pool has no
limit; the maximum number of beans in the free pool is
limited only by the available memory.
Can I use a "native" two-tier driver for a browser
applet?
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.
I'm using a WebLogic multitier driver in an applet as an
interface to a DBMS. If I run the class using the Sun
Appletviewer on my local machine, I have no problems.
But when I try to run the applet in a Netscape browser,
it will not connect.
If Appletviewer works and Netscape does not, it is an
indication that you are violating a Netscape security
restriction. In this case, the violation is that an
applet cannot open a socket to a machine other than the
one from which it loaded the applet. To solve this
problem, you will have to serve your applet code from
the same machine that hosts the DBMS.
In addition, the IP naming format you use in the applet
CODEBASE and the constructor for the T3Client must
match. That is, you can't use dot-notation in one place
and a domain name in the other.
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.
The two primary cluster services provided by WebLogic
Server are?
a. Http Session State Clustering
b. File Service Clustering
c. Time Service Clustering
d. Object Clustering
e. Event Clustering
Choices A and D are correct. A WebLogic Server cluster
is a group of servers that work together to provide a
more scalable and reliable application platform than a
single server. A clustered service is an API or
interface that is available on multiple servers in the
cluster. HTTP session state clustering and object
clustering are the two primary cluster services that
WebLogic Server provides. WebLogic Server also provides
cluster support for JMS destinations and JDBC
connections. WebLogic Server provides clustering support
for servlets and JSPs by replicating the HTTP session
state of clients that access clustered servlets and JSPs.
To benefit from HTTP session state clustering, you must
ensure that the session state is persistent, either by
configure in-memory replication, file system
persistence, or JDBC persistence. If an object is
clustered, instances of the object are deployed on all
WebLogic Servers in the cluster. The client has a choice
about which instance of the object to call. This is
Object Clustering. The APIs and internal services that
cannot be clustered in WebLogic Server version6.0 are
File services, Time services, WebLogic Events,
Workspaces and ZAC.
How do stubs work in a WebLogic Server cluster?
Clients that connect to a WebLogic Server cluster and
look up a clustered object obtain a replica-aware stub
for the object. This stub contains the list of available
server instances that host implementations of the
object. The stub also contains the load balancing logic
for distributing the load among its host servers.
What happens when a failure occurs and the stub cannot
connect to a WebLogic Server instance?
When the failure occurs, the stub removes the failed
server instance from its list. If there are no servers
left in its list, the stub uses DNS again to find a
running server and obtain a current list of running
instances. Also, the stub periodically refreshes its
list of available server instances in the cluster; this
allows the stub to take advantage of new servers as they
are added to the cluster.
Why did my JDBC code throw a rollback SQLException?
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.
Must my bean-managed persistence mechanism use the
WebLogic JTS driver?
Use the TxDataSource for bean-managed persistence.
Why is there no polymorphic-type response from a
create() or find() method?
The EJB Specification prohibits this behavior, and the
weblogic.ejbc compiler checks for this behavior and
prohibits any polymorphic type of response from a
create() or find() method.
The reason the create() and find() methods are not
polymorphic is similar to the reason constructors are
not polymorphic in Java. The derived classes generally
do not know or cannot initialize the base class
properly.
Must EJBs be homogeneously deployed across a cluster?
Why?
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.
Which of the following are recommended practices to be
performed in the ejbPassivate() method of a stateful
session bean?
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
Page Numbers :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
