Network Computingwww.networkcomputing.com

We tested Jolt, BEA's Web connection into the TUXEDO TP monitor and message-oriented middleware infrastructure. We added TUXEDO awareness to Java programs by making use of Jolt's class definitions and service definition repository. This repository of TUXEDO service definitions (such as service names, inputs and outputs) loads into a Java Virtual Machine (JVM) at run-time. Using Jolt's template builder, we quickly created a Java applet that used the class definitions and repository to b ecome a monitored TUXEDO transaction.

Along with the applet and service definition repository, a proprietary middleware subsystem downloads to the client (likely a browser). Between the desktop and the BEA Jolt server, this subsystem replaces HTTP with BEA's Jolt Transaction Protocol. The result extends connectivity within a Web-based application beyond the limited, document-oriented abilities of HTTP, and it performed as well or better than HTTP in our tests. Replacing HTTP is a step in the right direction for middleware, and BEA's implementation is another distinguishing feature of TUXEDO and Jolt.

A distributed transaction monitor from BEA Systems, TUXEDO (formerly a Novell product) supplied us with message-oriented functions that are implemented in terms of transaction semantics. We took advantage of several features for complex networked applica tions, and it was easily the best of the products we tested.

TUXEDO consists of a transaction manager, queue services functions, a domain feature, DCE integration functions and client components. We were impressed with the transaction manager, which provided naming services--a feature whose design and implementation we liked a lot--dynamic message routing, load-balancing, configuration management, transaction management and security. Queue services are a messaging framework that insulates business logic from the specifics of the network's underlying transport layers. The domain feature lets you segment application components on a large network into administratively autonomous groups. It can even provide firewalls through its enforcement of authenticated access to TUXEDO-monitored applications. These firewalls sit between parts of an organization that should never see one another's work, even though the parts are connected by companywide application components and data objects. TUXEDO's security model is ba sed on Kerberos (a DCE concept) and integrates well with NT Server's access control lists (ACLs) and its domain model. However, we found the naming service doe sn't interoperate with Novell Directory Services (NDS) or Unix-based name services like Network Information Service (NIS+).

We familiarized ourselves with TUXEDO through its Application-to-Transaction Manager Interface (ATMI), a set of 30 application programming interface (API) function calls. The ATMI toolset provides a useful, coherent set of library functions: asynchronous service calls (callback functions), typed buffers, service request forwarding, service request prioritization and dynamic, programmatically controlled data routing. Impressively, TUXEDO supports more programming environments than the other products we tested, including more than 35 third- and fourth-generation language products, Integrated Development Environments (IDEs) and computer-aided software engineering (CASE) tools.

To manage TUXEDO's run-time environment, we experim ented with its drag-and-drop-enabled GUI interface, command-line interface, scripts (macros) and Simple Network Management Protocol (SNMP)-based remote management feature. For use with the SNMP-based network manager, TUXEDO comes with a management information base (MIB).

On an NT system, Tuxedo requires at least Windows 3.51 or later, a 486 or faster processor, 16 MB of RAM and 10 MB of free disk space.