Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Jolt   |   Topic List   |   Previous   |   Next   |   Contents   |   Index

   Using BEA Jolt

BEA Jolt connects Java clients to applications that are built using the BEA Tuxedo system. The BEA Tuxedo system provides a set of modular services, each offering specific functionality related to the application as a whole.

The end-to-end view of the BEA Jolt architecture, as well as related BEA Tuxedo components and their interactions, is illustrated in the figure BEA Jolt Architecture.

Using this figure as an example, a simple banking application might have services such as INQUIRY, WITHDRAW, TRANSFER, and DEPOSIT. Typically, service requests are implemented in C or COBOL as a sequence of calls to a program library. Accessing a library from a native program means installing the library for the specific combination of CPU and operating system release on the client machine, a situation that Java was expressly designed to avoid. The Jolt Server implementation acts as a proxy for the Jolt client, invoking the BEA Tuxedo service on behalf of the client. The BEA Jolt Server accepts requests from the Jolt clients and maps those requests into BEA Tuxedo service requests.

Jolt Servers

The following Jolt Server components act in concert to pass Jolt client transaction processing requests to the BEA Tuxedo application.

• Jolt Server Listener (JSL)

  The JSL handles the initial Jolt client connection, and assigns a Jolt client to the Jolt Server Handler.

• Jolt Server Handler (JSH)

  The JSH manages network connectivity, executes service requests on behalf of the client and translates BEA Tuxedo buffer data into the Jolt buffer, as well as Jolt buffer data into the Tuxedo buffer.

• Jolt Repository Server (JREPSVR)

  The JREPSVR retrieves Jolt service definitions from the Jolt Repository and returns the service definitions to the JSH. The JREPSVR also updates or adds Jolt service definitions.

The following figure illustrates the Jolt Server and Jolt Repository components.

Jolt Class Library

The BEA Jolt Class Library is a set of classes that you can use in your Java application or applet to make service requests to the BEA Tuxedo system from a Java-enabled client. You access BEA Tuxedo transaction services by using Jolt class objects.

When developing a Jolt client application, you only need to know about the classes that Jolt provides and the BEA Tuxedo services that are exported by the Jolt Repository. Jolt hides the underlying application details. To use Jolt and the Jolt Class Library, you do not need to understand: the underlying transactional semantics, the language in which the services were coded, buffer manipulation, the location of services, or the names of databases used.

The Jolt API is a Java class library and has the benefits that Java provides: applets are downloaded dynamically and are only resident during runtime. As a result, there is no need for client installation, administration, management, or version control. If services are changed, the client application notes the changes at the next call to the Jolt Repository.

The following figure shows the flow of activity from a Jolt client to and from the BEA Tuxedo system. The call-out numbers correspond to descriptions of the activity in the table Using the Jolt Class Library.

The following table briefly describes the flow of activity involved in using the Jolt Class Library to access BEA Tuxedo services, as shown in the previous figure Using the Jolt Class Library to access BEA Tuxedo Services.

Using the Jolt Class Library

Process	Step	Action
Connection	1	A Java-enabled Web browser uses HTTP protocol to download an HTML page.
...	2	A Jolt applet is downloaded and executed in the Java Virtual Machine on the client.
...	3	The first Java applet task is to open a separate connection to the Jolt Server.
Request	4	The Jolt client now knows the signature of the service (such as name, parameters, types); can build a service request object based on Jolt class definitions; and make a method call.
...	5	The request is sent to the Jolt Server, which translates the Java-based request into a BEA Tuxedo request and forwards the request to the BEA Tuxedo environment.
Reply	6	The BEA Tuxedo system processes the request and returns the information to the Jolt Server, which translates it back to the Java applet.

JoltBeans

BEA Jolt now includes JoltBeans, Java beans components that you use in a Java-enabled integrated development environment (IDE) to construct BEA Jolt clients. Using JoltBeans, and popular JavaBeans-enabled development tools such as Symantec Visual Café, you can graphically create client applications.

BEA JoltBeans provide a JavaBeans-compliant interface to BEA Jolt that enables you to develop a fully functional BEA Jolt client without writing any code. You can drag and drop JoltBeans from the component palette of a development tool and position them on the Java form (or forms) of the Jolt client application you are creating. You can populate the properties of the beans and graphically establish event source-listener relationships between various beans of the application or applet. Typically, the development tool is used to generate the event hook-up code, or you can code the hook-up manually. Client development with JoltBeans is integrated with the BEA Jolt Repository, which provides easy access to available BEA Tuxedo functions.

The Jolt ASP Connectivity for BEA Tuxedo Toolkit is an extension to the Jolt Java class library. The Toolkit allows the Jolt client class library to be used in a Web server, such as the Microsoft Internet Information Server (IIS), to provide an interface between HTML clients or browsers, and BEA Tuxedo services.

The Jolt ASP Connectivity for BEA Tuxedo Toolkit provides an easy-to-use interface for processing and generating dynamic HTML pages. You do not need to learn how to write Common Gateway Interface (CGI) transactional programs to access BEA Tuxedo services.

The Jolt system handles all communication between the Jolt Server and the Jolt client using the BEA Jolt Protocol. The communication process between the Jolt Server and the Jolt client applet or applications functions as follows:

1. BEA Tuxedo service requests and associated parameters are packaged into a message buffer and delivered over the network to the Jolt Server.

2. The Jolt Server unpacks the data from the message and performs necessary data conversions, such as numeric format conversions or character set conversions.

3. The Jolt Server makes the appropriate service request to the application service requested by the Jolt client.

4. Once a service request enters the BEA Tuxedo system, it is executed in exactly the same manner as requests issued by any other BEA Tuxedo client.

5. The results are then returned to the BEA Jolt Server, which packages the results and any error information into a message that is sent to the Jolt client.

6. The Jolt client then maps the contents of the message into the various Jolt client interface objects, completing the request.

The Jolt Repository is a database where BEA Tuxedo services are defined, such as name, number, type, parameter size, and permissions. The repository functions as a central database of definitions for BEA Tuxedo services and permits new and existing BEA Tuxedo services to be made available to Jolt client applications. A BEA Tuxedo application can have many services or service definitions, such as ADD_CUSTOMER, GET_ACCOUNTBALANCE, CHANGE_LOCATION, and GET_STATUS. All or only a few of these definitions can be exported to the Jolt Repository. Within the Jolt Repository, the developer or system administrator uses the Jolt Repository Editor to export these services to the Jolt client application.

All Repository services that are exported to one client are exported to all clients. BEA Tuxedo handles the cases where subsets of services may be needed for one client and not others.

The following figure illustrates how the Jolt Repository brokers BEA Tuxedo services to multiple Jolt client applications. (Four BEA Tuxedo services are shown; however, the WITHDRAW service is not defined in the repository and the TRANSFER service is defined but not exported.)

Jolt Repository Editor

The Jolt Repository Editor is a Java-based GUI administration tool that gives the application administrator access to individual BEA Tuxedo services. You use the Editor to define, test, and export services to Jolt clients.

Note: The Jolt Repository Editor only controls services for Jolt client applications. You cannot use it to make changes to the BEA Tuxedo application.

The Jolt Repository Editor lets you extend and distribute BEA Tuxedo services to Jolt clients without having to modify many lines of code. You can modify parameters for BEA Tuxedo services, logically group BEA Tuxedo services into packages, and remove services from created packages. You can also make the services available to browser-based Jolt applets or Jolt applications by exporting the services.

The Jolt Internet Relay is a component that routes messages from a Jolt client to the Jolt Server. The Jolt Internet Relay consists of the Jolt Relay (JRLY) and the Jolt Relay Adapter (JRAD). JRLY is a stand-alone software component that routes Jolt messages to the Jolt Relay Adapter. Requiring only minimal configuration to work with Jolt clients, the Jolt Relay eliminates the need for the BEA Tuxedo system to run on the same machine as the Web server.

The JRAD is a BEA Tuxedo system server, but does not include any BEA Tuxedo services. It requires command-line arguments to allow it to work with the JSH and the BEA Tuxedo system. JRAD receives client requests from JRLY, and forwards the request to the appropriate JSH. Replies from the JSH are forwarded back to the JRAD, which sends the response back to the JRLY. A single Jolt Internet Relay (JRLY/JRAD pair) handles multiple clients concurrently.