|
|
|
|
| |
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:
Note: Jolt for WebLogic does not provide access to asynchronous Tuxedo event notifications.
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:
A session object represents a physical connection with the Tuxedo system.
A session pool contains one or more sessions. The sessions in the session pool are reused for efficiency. Your WebLogic servlet uses sessions to invoke services in Tuxedo through the methods of a session pool. Session pools are initialized by the WebLogic server at startup and configured by properties in the weblogic.properties file.
Use the session pool manager to get a reference to a session pool and to create, administer, and remove session pools. The session pool manager is created just before the WebLogic server initializes the first session pool, and is registered under a well-known name as a Java Naming and Directory Interface (JNDI) entry, so that your application can obtain a reference to it later through a JNDI lookup.
Figure 1-1 shows the architecture for Jolt for WebLogic.
Figure 1-1 Jolt for WebLogic Architecture
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 weblogic.properties 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 weblogic.properties 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 weblogic.properties 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 weblogic.properties 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 weblogic.properties 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.
A FORM-based HTML front end that submits a string to an HTTP servlet. The servlet in turn sends this string to a Tuxedo service. The returned data is compiled into a dynamically generated HTML file, and sent back to the client browser.
A more sophisticated servlet example that uses JHTML. This example demonstrates how a simple banking application might be implemented.
The Enterprise JavaBean example package contains the classes and other files necessary to set up and run an EJBean stateful session to a Tuxedo Server that is using Jolt.
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|