BEA Logo BEA WebLogic Server Release 1.1

  Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy

   Jolt for WebLogic Server User's Guide:   Previous topic   |   Next topic   |   Contents   |  Index


Introduction to Jolt for WebLogic


With BEA Jolt for WebLogic, you can enable BEA Tuxedo services for the Web, using the BEA WebLogic Server as the front end HTTP and application server.

Jolt is a Java-based client API that manages requests to BEA Tuxedo services via a Jolt Service Listener (JSL) running on the Tuxedo server. The Jolt API is embedded within the WebLogic API, and is accessible from a servlet, JHTML, or any other WebLogic application.

Because Jolt for WebLogic is an extension to the Jolt Java class library, the Jolt Java client class library can be used in HTTP servlets running in the WebLogic Server. Jolt for WebLogic also uses Java HTTP servlets to provide an interface between HTML browser clients and BEA Tuxedo services.

Hereafter, BEA Tuxedo is referred to as Tuxedo, for readability.

This introduction includes the following sections:

Key Features

Key features of the Jolt for WebLogic architecture include:

How Jolt for WebLogic Works

This section describes the major components used for communication in Jolt, and how Jolt for WebLogic works, including:

Relationship Between Jolt for WebLogic and Tuxedo

Using Jolt for WebLogic Server, you can access your underlying Tuxedo system from the Web. This access allows you to write Web-enabled applications that can interact with other systems and databases in your Tuxedo domain.

The system described here is accessed through a standard Web browser. This Web browser is served by the WebLogic Server, which uses a customized Java HTTP servlet to handle the interactive HTTP requests of the browser. (An HTTP servlet is a Java class that handles an HTTP request and delivers an HTTP response.) The custom HTTP servlet uses the Jolt for WebLogic API to talk to a Jolt Server that can be on a remote machine or behind a security firewall.

The Jolt Server lives within the Tuxedo domain and determines which Tuxedo services are accessible to each client. The Jolt Server invokes the requested Tuxedo service and sends any results back to the WebLogic Server. You can then compile the results into a servlet-generated Web page, and send them to the browser. In doing so, you create a highly accessible and user friendly interface to Tuxedo services from anywhere on the Internet or intranet.

Essential Components of the Jolt Architecture

The fundamental object types that maintain the communications connection from the WebLogic Java HTTP servlet to the Jolt Server and from the Jolt Server to Tuxedo, are as follows:

Figure 1-1 shows the architecture for Jolt for WebLogic.

Figure 1-1 Jolt for WebLogic Architecture

WebLogic Server Startup

The WebLogic standards-based, pure-Java application server assembles, deploys, and manages distributed Java applications. It supports distributed component services and enterprise database access, including Enterprise JavaBeans (EJBean), Remote Method Invocation (RMI), distributed JavaBeans, and Java Database Connect (JDBC).

Note: Start the Jolt servers before attempting to create a session pool; otherwise the startup classes will fail, and they will not attempt to commit again.

The WebLogic Server is configured to initialize the session pools at startup through the file. A special startup class, PoolManagerStartUp, is invoked by the WebLogic Server with a number of parameters. This class functions as follows:

Each successive call to this startup class adds another session pool to the same pool manager.

Connecting to a WebLogic Server From a Client Browser

In addition to its other Java services, the WebLogic Server is a fully functional HTTP server that supports Java HTTP servlets. In general, each servlet must be registered with a virtual name in the file.

A servlet may be invoked directly, that is, may actually present HTML to the browser, or may be invoked indirectly from an HTML form when the user submits the form. When the WebLogic Server receives a request containing the registered virtual name of a servlet, it invokes the appropriate servlet's service() method. For more information on HTTP servlets, see "Using WebLogic HTTP Servlets" in the WebLogic Developer's Guide.

The HTTP servlet's service() method (which invokes either the servlet's doPost() or doGet() method, depending on the context) is invoked and passes an HttpServletRequest object containing the HTTP data sent from the browser. In the example packages described in Using the Example Packages, the client's query data is used in a transaction call to Tuxedo, and the response is built into the new HTML page.

How a Servlet Connects to Tuxedo

Using a JNDI lookup, a servlet obtains a reference to the session pool manager that was created and initialized by the WebLogic Server when it started. The session pool manager is always registered in the WLInitialContext JNDI context under the name defined by the SessionPoolManager.POOLMANAGER_NAME final (constant) static variable.

The pool manager is used to retrieve the session pool that was configured in the file. This session pool references the appropriate Jolt Server in a Tuxedo domain. A servlet uses the session pool to invoke a specific Tuxedo service.

Tuxedo services are described and exported (declared accessible) on the Jolt Server in the Jolt Repository. In the Jolt Repository, the service's expected input and output parameter types are declared. A servlet must supply the expected input parameters; Jolt for WebLogic uses specialized ServletSessionPool objects that can accept their input directly from an HttpServletRequest object. The output is returned in a ServletResult object.

What Happens If the Request Fails

The session pool distributes the requests equally among the sessions in the pool. It selects the least busy session to call the Tuxedo service. If the selected session is terminated before the Tuxedo service is called, the session pool redirects the service call to a different session, then establishes a new session to replace the disconnected one. The session pool uses a round-robin algorithm to select and establish a connection to a primary Jolt Server. If no primary Jolt Servers responds, the session pool connects to a failover server.

If no sessions are available from a session pool, or the session pool is suspended, then a SessionPoolException is thrown.

Multiple requests can be grouped into a single transaction. When a transaction fails, a TransactionException is thrown. This exception should be caught by the servlet and handled appropriately. (Usually, the servlet performs a rollback.)

Responding to the Client Browser

Provided the service call was successful, the following events occur:

Disconnecting From the Jolt Server

The WebLogic Server is also configured to shut down the existing session pool connections to Tuxedo through the file.

Use the weblogic.system.shutdownClass property to register the class PoolManagerShutDown so that the Jolt session pool is cleaned up properly when the WebLogic Server shuts down. PoolManagerShutDown accepts the name of the session pool to be closed as shutdownArgs parameters, also configured in the file.

Using the Example Packages

Three example packages are included with Jolt for WebLogic Server. These packages are described in Simple Servlet Example, Servlet with JHTML Example, and Servlet with Enterprise JavaBean Example. They demonstrate how Jolt is used in WebLogic servlets to access BEA Tuxedo services. You can build, run, and inspect these examples to help you decide how to use WebLogic to extend Tuxedo services to the Internet.