"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896

Hitachi TPBroker� is a robust object-oriented transaction monitor that provides transaction assurance and monitoring for Internet and intranet applications. TPBroker combines the power of Hitachi�s Transaction Manager (TM) and Object Transaction Service (OTS) tightly integrated with Inprise�s VisiBroker� Object Request Broker (ORB). TPBroker is an ideal platform on which to deploy mission-critical distributed corporate applications.

TPBroker enables you to build new systems using existing system resources as building blocks, and simply adding interfaces to the distributed object environment. TPBroker also allows you to develop distributed object-oriented applications using the Common Object Request Broker Architecture (CORBA�) ORB function. This allows the reuse of system components and localization of program modifications that help reduce costs of system development and management. Hitachi TPBroker supports the Internet Inter-ORB Protocol (IIOP) defined in the CORBA specification as the inter-ORB communication protocol.

TPBroker allows the gradual migration of applications towards enterprise-wide computing by preserving co-existence with legacy client and server applications using X/Open�s DTP model. TPBroker supports the TX and XA interfaces. Through the use of X/Open XA interfaces, TPBroker provides connectivity to commercial databases such as Oracle� and Microsoft�s SQL Server�.

All of Hitachi�s middleware offerings are built on top of the TPBroker ORB. Among these offerings is the Hitachi Enterprise Application Manager (HiEM), a distributed application management tool that monitors and controls distributed CORBA applications. The HiEM Server includes the HiEM JServer for  Sun Microsystems� Java� and the Hitachi TPBroker Notification Service. Hitachi has other products in its TPBroker product suite, such as transactional support (OTS) and guaranteed message queuing (TPBroker Asynchronous Message or AM). These products can help the end user or ISV searching for ways to rapidly deploy and maintain their distributed software.

This white paper describes the design and architecture of TPBroker Release 3.1.1 for C++ and Java. The paper also describes how TPBroker can be applied to a variety of domains.

The next section covers the TPBroker for C++ architecture; following that is a section on the TPBroker for Java architecture. The paper concludes with a summary of TPBroker�s superior features.

TPBroker for C++, as shown in Figure 1, consists of the following integrated components:

• VisiBroker TPBroker ORB for C++ V3.2, a fully compliant CORBA 2.1 ORB

• Hitachi�s Distributed Object-Oriented Transaction Manager, fully compliant with OTS 1.1

The TPBroker ORB for C++ is a complete CORBA implementation that goes beyond the standard specification to provide a SMART Smart communication framework, allowing you to easily develop large distributed applications that are robust, scalable, flexible and maintainable. The TPBroker ORB for C++ incorporates a proven communication framework that links thousands of nodes.

Figure 1.  Client Program Acting on an object Object through  an ORB

The ORB provides:

As shown in Figure 4, the OTS has three architecture components that participate in distributed transaction processing:

• The transactional client initiates and terminates a transaction

• The transactional server then joins with the transaction and can terminate it, but does not hold any persistent/recoverable status

• The recoverable server maintains the persistent data (that is, the ACID properties) that the transaction protects

A transaction begins within the transactional client when the transaction originator calls begin() or create(). The OTS then propagates the transaction to the transactional servers and recoverable servers. This propagation forms the transaction tree. The OTS is associated with each client and server and controls the transaction�s propagation and status changes.

The term �transaction tree� relates to the propagation of a given transaction to the server(s) that will handle the actual work, as well as the recoverable server(s) to ensure the transaction is handled correctly in all scenarios. Transactional clients are usually co-located with servers and require the entire OTS, including daemons.

The distributed context management model partitions the global transaction context to subcontexts that contain only the status information of the transaction branch associated with a specific node and maintains the subcontexts in each relevant node. This model is easily scalable because each node added to the system has the responsibility to process user applications and manage transaction contexts. Running the TPBroker runtime client environment on each node allows for library implementations of major OTS functions, which lessens communication overhead.

Because no major DBMS vendor provides an OTS-compliant resource interface today, recoverable servers must be constructed using one of the following:

• X/Open DTP Resource Manager (RM), by means of XA

• Protocol stack that can handle two-phase commit

• ACID properties implemented at the user level

None of these is trivial, so an one option is to omit the recoverable server and directly connect a transactional server to the X/Open Resource Manager. (When connected with an X/Open resource manager, a transactional server acts as a kind of recoverable server.) The OTS is fully compliant with the X/Open DTP model and can connect to Resource Managers.

The OTS consists of seven layers and subsystems, as shown in Figure 5:

• OTS Adapter

• Transaction State Machine

• Persistent Storage subsystem

• Recovery subsystem

• ClientProxy

• Transaction Context Server

• Logging subsystem

OTS Adapter. The OTS Adapter provides OTS objects, OTS APIs, and X/Open TX APIs. The OTS Adapter operates object references of the OTS object, such as narrowing object reference, throwing and catching exceptions, and translating object references into string format. The OTS Adapter requires some simple functions that are not part of the CORBA specification, such as creating object implementations, finding object implementations, and binding them to object references. The OTS Adapter also requires some interfaces that depend on the ORB, such as time-out control of function invocation, binding control, and retrieval of server object information.

Transaction State Machine and Persistent Storage Subsystem. The Transaction State Machine manages the state transitions of all transactions. Most of the transaction status is maintained on shared memory and directly manipulated by OTS libraries; the rest is stored in the Persistent Storage Subsystem. The Transaction State Machine supports both flat and nested transactions.

Recovery Subsystem. The Recovery Subsystem monitors the execution status of the system and activates a recovery process if a failure occurs. It monitors user processes and various OTS daemons. When a process fails, the Recovery Subsystem investigates the outcome of the associated transaction and automatically starts the commit or rollback procedure. The Recovery Subsystem also completes transaction processing after a system failure.

ClientProxy and Transaction Context Server. The ClientProxy and Transaction Context Server layers work togetheras a unit. The ClientProxy layer maintains a ClientProxy object that resides on the client computer. This object contains a copy of the transaction context, the original of which resides on the server in a corresponding Transaction Context Server object. Each Transaction Context Server object is implicitly bound to a unique thread. The ClientProxy delegates transaction control to the Transaction Context Server, which in turn invokes the OTS Adapter. The ClientProxy and Transaction Context Server objects must be in constant communication. The ORB is responsible for notifying the OTS of any communication failure.

Logging Subsystem. The Logging Subsystem is an OTS utility that records system messages. It is fully internationalized.

The OTS component is based on the X/Open�s Transaction Manager (TM) standard. Hitachi�s OTS is a re-implemented component based on Hitachi�s OpenTP1 Transaction Manager, which enables user applications to manage transactional contexts in a distributed environment with high performance and reliability. OTS provides high reliability/stability, robustness and highly improved performance in an open system environment. Figure 5 shows an example of an OpenTP1 system. 

For communication, OTS uses the client/server call and the message queue. Using the transactional client/server call, application programs can execute transactional processes over different nodes in the network involving several database systems. Using the message queue feature, application programs can send messages asynchronously via recoverable disk queues.

Some of the other key OTS features are:

• Two-phase commit control

• Naming service that maps from server�s logical name to network address

• Application scheduling and load balancing

• Application, component, and system recovery

• XA-compliant database access

• Administration tools

• Transactional batch processing

This section covers the unique features of TPBroker for Java�s architecture, and explains its relationship to the TPBroker for C++ architecture.

TPBroker for Java includes:

• TPBroker ORB for Java V3.3 as its ORB

• Java OTS

• Java Applet and Application Support

The ORB is not a separate process. It is a collection of Java objects and network resources integrated within end-user applications, and it allows your client applications to locate and use objects.

In addition to the features provided by the TPBroker ORB for C++, the TPBroker ORB for Java also features:

• Enhanced thread and connection management

• Object request debugger

• Java Ease-of-Use

• Smart stubs

• Gatekeeper (optional feature)

• Secure Sockets Layer (SSL) pack (optional feature)

The Java Ease-of-Use, also called �Caffeine,� set of features includes Web Naming and d the java2iiop and java2idl compilers. Web Naming allows you to associate Uniform Resource Locators (URLs) with objects, allowing an object reference to be obtained and an object to be contacted by specifying a URL.

The enhanced idl2java compiler now includes its own Java-based pre-processor which supports standard pre-processing arguments.

The ORB�s java2iiop compiler allows you to use the Java language to define interfaces, instead of using IDL. You can use java2iiop if you have existing Java code that you wish to adapt to use distributed objects or if you do not wish want to learn use IDL. The java2iiop compiler generates the necessary container classes, client stubs, and server skeletons directly from Java code. The java2idl compiler turns your Java code into IDL, thereby allowing you to generate client stubs in the language of your choice. In addition, because this compiler maps your Java interfaces to IDL, you can re-implement Java objects in another programming language that supports the same IDL.

While still conforming to the security restrictions imposed by Web browsers and firewalls, the optional VisiBroker for Java Gatekeeper software runs on a Web server, and enables client programs to make calls to and receive calls from objects located elsewhere on the same or other network, including communications through existing firewalls. The Gatekeeper handles communication through firewalls, and it can be used as an HTTP daemon, thereby eliminating the requirement for a separate HTTP server during the application development phase. Gatekeeper is required on any machine running a Web server; it�s also required to run Java applets.

In addition, the Gatekeeper provides for the following:

• Bootstrapping

• Location transparency

• Callback enablement

• HTTP tunneling

• HTTP daemon (Web server) functionality during application development

Interoperability with TPBroker ORB for C++

The Hitachi TPBroker for Java transaction management features are based on the OTS specification defined by OMG, providing full support for the OMG OTS interfaces (except the C++ interfaces, which TPBroker for C++ provides). Hitachi TPBroker for C++ and Java Release 3.1.1 provide Java OTS support jointly, allowing developers to write transactional client/server applications in Java. Hitachi TPBroker for Java supports Java programs that run as transactional clients or transactional servers. Figure 6 provides an overview of the Java OTS design. 

In addition to the features provided by the TPBroker for C++ OTS, the TPBroker for Java OTS features:

• Class library for creating transactional Java applications

• Thread-safe support for transactions

• Indirect/direct transaction context management through IDL interface

• Implicit/explicit transaction propagation

• Unrestricted nested-transaction model

• Resource connectivity

Note, however, that the TPBroker Java OTS does not support the following OMG OTS interfaces:

• X/Open Transaction Demarcation (TX) interfaces

• X/Open XA specification on connecting to Resource Managers

This means that in order for your Java applications to be able to access the TX or XA interfaces, you must create C++ applications to serve as intermediaries between the Java applications and those interfaces.

The Java OTS has three architecture components that participate in distributed transaction processing:

• The lightweight Java client (Java applet or Java application) initiates and terminates a transaction, but does not hold transaction context

• The lightweight Java server (Java application) joins with the transaction propagated from Java and/or C++ transactional clients, but does not hold the transaction context

• The Transaction Context Server (TCS) holds the transaction contexts for lightweight transactional clients and servers

When a lightweight Java transactional client initiates a transaction, the client computer does not hold the transaction context. Instead, the Java OTS creates the ClientProxy object, which serves as a local proxy for the actual transaction. The ClientProxy delegates all transaction management to the TCS provided by TPBroker for C++. (Because the TCS is part of TPBroker for C++, it must reside on the same machine as TPBroker for C++.)

When a lightweight Java transactional server receives a transaction request, the server interposes itself in the propagated transaction by creating a ServerProxy object for the transactional object. The ServerProxy and ClientProxy objects have the same role: to serve as local proxies for the actual transaction, whose transaction context is held on the TCS.

Because the ClientProxy and ServerProxy objects communicate with the TCS by means of the IIOP protocol, it is possible for the client, server, and TCS to reside on three separate machines. For performance reasons, you may prefer to place all three on a single machine, but the most common scenario is for the transactional client to reside on the client PC, and for the transactional server and TCS to reside on the server PC.

This section describes how the Java OTS manages a distributed transaction.

TPBroker for C++ must reside on at least one machine in the network. TPBroker for C++ and TPBroker for Java can reside on the same machine provided that each ORB is installed in a separate directory. TPBroker for Java provides full interoperability with TPBroker C++ applications. Your Java applications can propagate transactional operations to C++ applications that use the TPBroker OTS. In turn, C++ applications can propagate transactional operations to your Java applications.

In a typical scenario, a TPBroker Java client application calls a TPBroker C++ server application with a transaction. The TPBroker C++ server application accesses a database using the X/Open XA interface, and the TPBroker for Java client application commits the transaction. (Note that the Java OTS does not support hybrid TPBroker C++/Java applications; specifically, it does not support the TPBroker C++ API in Java programs. However, your Java code can cooperate with TPBroker C++ programs through ORB communication, so that all programs can remain simple.)

Figure 7 shows a simple Java implementation with three distributed applications: two in Java and one in C++. The C++ application is associated with a database. TPBroker for C++ provides TCS and the Completion daemon.

In this example, Java Applet A invokes Java Application B, which in turn invokes C++ Application C. C++ Application C then updates Application C�s database. All operations use indirect context management and implicit propagation.

TPBroker for Java and TPBroker for C++ ensure that all objects involved retain their ACID properties.

The figure shows one shared memory space, but if each of the applications resides on a different machine, shared memory is also separated. It is not necessary for the applications to share the same memory space. 

To provide more detail about this distributed transaction, Java Applet A initiates it. The Java OTS creates a ClientProxy object, which requires the TCS to create a new transaction. The TCS creates a new transaction context in shared memory.

Java Applet A propagates the transaction to Java Application B. The ClientProxy object detects the object invocation, gets the propagation context (PC) from the TCS, and adds it to the transaction request.

Java Application B receives the propagation context (PC) and supplies it to the TCS. The TCS then creates a branch transaction context for Java Application B.

TPBroker for Java supports both Java applets and Java applications.  TPBroker is also interoperable with market-leading Java tools such as JBuilder from Inprise, VisualCafe� from Symantec, VisualAge� from IBM and Visual J++� from Microsoft.

Users can access Java applets with Netscape Navigator/Communicator, which provides Java support by opening the applet�s URL, thereby making full use of the Java language for conducting transactions. Bear in mind that web browsers impose two types of security restrictions on Java applets:

• An applet must connect back only to the host from which it was downloaded

• An applet must accept incoming connections only from the host from which it was downloaded

Currently, TPBroker for Java only supports Netscape Navigator/Communicator when using Java applets.

TPBroker�s distributed architecture is scalable and reliable in production environments, unlike more centralized architectures. Further, this model enables the use of the ORB technology without a configuration burden. Specifically, some of TPBroker�s outstanding features are:

• Communication between objects with different messaging policies and interoperation with existing message-oriented middleware products

• Advanced event coordination 

• Good environment for CORBA applications, especially Java applications in a heterogeneous environment

• Access to many backend databases, especially useful in indirect customer service

• Direct connection architecture needed by customer call centers

• Guaranteed message delivery, ideal for online auctions, brokerages, reservations, and purchasing systems

• Rapid response through multithreading

• High object availability/fault tolerance

As you can see, then, the combination of TPBroker Product Suite V2.1 and TPBroker for Java V3.1.1 provides a robust and reliable architecture, making it an ideal platform on which to deploy mission-critical distributed applications.

Disclaimer

The Business Forum, its Officers, partners, and all other
parties with which it deals, or is associated with, accept
absolutely no responsibility whatsoever, nor any liability,
for what is published on this web site.    Please refer to: