is impossible for ideas to compete in the marketplace if no forum for
TPBroker for C++ & TPBroker for Java Architecture
Contributed by Hitachi Computer Products (America), Inc.
Introduction and Overview
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
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++ Architecture
TPBroker for C++, as shown in Figure 1, consists of the following integrated components:
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 2 shows an ORB transparently connects a client application, component, or object with its server-side object implementation. The client program object does not need to know whether the server object resides on the same computer or is located on a remote computer somewhere on the network. The client needs only to know the object’s name and to understand the object’s interface. The ORB takes care of the details of locating the object, routing the request, and returning the result.
Figure 1. Client Program Acting on an object Object through an ORB
The TPBroker ORB for C++'s Smart Agent monitors communication between objects and their clients. The Smart Agent keeps track of objects that are available on a network, and locates objects for clients at invocation time. If the object is in your process, it bypasses the ORB and the network altogether. When the object is on a remote node, the ORB’s on-the-wire protocol is selected.
Multiple Smart Agents on a network cooperate to provide load balancing and high availability for client access to server objects. The TPBroker ORB can determine if the connection between your client application and a server object has been lost, due to an error such as a server crash or a network failure. When a failure is detected, an attempt is automatically made to restart the server or to connect your client to another server on a different host.
When your application binds to an object, the TPBroker ORB selects and establishes the most efficient communication mechanism. Depending on the platform and the location of the requested object, the bind may be established through a pointer local reference, shared memory (or other platform-optimized approach), or a TCP/IP socket.
The TPBroker ORB provides native support for single and multi-threaded processing. With the TPBroker ORB’s thread-per-session model, threads are automatically allocated on the server per client connection to service multiple requests, and then are terminated when the connection ends. With the thread pooling model, threads are allocated based on the number of requests for the server object. Very active clients will be serviced by multiple threads, ensuring that requests are quickly executed quickly, while less active clients can share a single thread, and still have their requests immediately serviced immediately.
The TPBroker ORB’s connection management minimizes the number of client connections to the server. All client requests are multiplexed over the same connection, even if they originate from different threads. Released client connections are recycled instead of creating new connections to the same server.
C++ objects can interoperate across platforms using the ORB’s native IIOP implementation, providing easy Web access. This feature ensures that object applications can operate on the Internet, on intranets, and in enterprise computing environments.
The TPBroker ORB for C++ is the most complete ORB implementation currently on the market. It features static and dynamic invocation interfaces, interface and implementation and interface repositories, support for object activation, and a complete set of object administration tools.
The TPBroker ORB for C++ comes with two IDL compilers that make object development easier. The idl2cpp compiler takes IDL files as input and produces the necessary client stubs and server skeletons in C++. The idl2ir compiler takes an IDL file and populates an Interface Repository with its contents.
OTS enables you to build a transaction system that features performance load distribution among multiple servers. OTS is the OMG’s formal specification for object-oriented communication between programs and transaction processing servers. OTS works concurrently with both traditional client/server-based transaction services and with ORB-based services that follow the new CORBA standards. This functionality makes it easier for an organization to migrate from traditional X/Open-compliant client/server systems to next-generation object-oriented CORBA systems.
The OTS can control multiple local database transactions, as well as single database transactions on local or remote servers. Further, the OTS supports recoverable nested transactions, in either a homogeneous or heterogeneous environment, that exhibit Atomicity, Consistency, Isolation, and Durability (ACID) properties, and fully support two-phase commit protocols.
Figure 3 shows the relationship between the various parts of a hypothetical transaction processing system. An application program (AP) can run on the desktop or on the enterprise server. This program communicates with its respective ORBs using the OTS.
TPBroker for C++ has enhanced the OTS features to
The OTS supports both direct and indirect context management. Interface Definition Language (IDL) and DII calls to the OTS support both direct and indirect context transaction management. The OTS also supports both implicit and explicit propagation. The OTS supports propagation to and from other OTS systems by means of the hidden service-specific context, or implicit propagation. Propagation is also supported from other OTS systems without the hidden service-specific context, or explicit propagation.
As shown in Figure 4, the OTS has three architecture components that participate in distributed transaction processing:
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:
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. 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:
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
Hitachi TPBroker for Java uses the TPBroker ORB for Java as
its ORB. The TPBroker ORB for Java connects a client program (which may be a
Java applet or application running on a Java virtual machine or in a
Java-enabled browser) with the objects it wishes to use. As with the C++ ORB,
the client program does not need to know the object’s location. The ORB takes
care of the details of locating the object, routing the request, and returning
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
Object request debugger
Gatekeeper (optional feature)
Secure Sockets Layer (SSL) pack
Hitachi TPBroker for Java uses the TPBroker ORB for Java as its ORB. The TPBroker ORB for Java connects a client program (which may be a Java applet or application running on a Java virtual machine or in a Java-enabled browser) with the objects it wishes to use. As with the C++ ORB, the client program does not need to know the object’s location. The ORB takes care of the details of locating the object, routing the request, and returning the result.
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
Gatekeeper (optional feature)
Secure Sockets Layer (SSL) pack (optional feature)
The ORB provides two thread policies to choose from: thread pooling or thread-per-session. When you select the desired thread policy for your object server, the ORB automatically selects the most efficient way to manage connections between client applications and servers.
Incorporating a Java GUI, this debugger works with both the TPBroker ORB for Java and the TPBroker ORB for C++ to trace an operation invocation (that is, an object request) from a client program through to a server object implementation. It also allows you to set breakpoints.
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.
A stub is a Java object in a client that represents a remote object and its methods. You can customize a stub to intervene in every client invocation on a remote object to introduce “smart” handling of certain situations. This capability is useful for a variety of purposes including caching, load balancing, and logging. The smart stub developer decides what actions a smart stub takes when it is invoked.
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:
Clients and servers that use the ORB’s optional SSL feature are assured of each other’s identities and of the privacy and integrity of their communications. Using Secure Sockets Layer Version 3 protocol to establish secure client/server connections, SSL ensures secure data transmission even over insecure networks such as the Internet. SSL enables clients and servers to authenticate one another’s identity, to encrypt transmitted data, and to ensure that the data is received without corruption or modification. These features allow applications to exchange sensitive information such as credit card numbers without risk.
Java applications created with the TPBroker ORB for Java can communicate with object implementations developed with the TPBroker ORB for C++. Simply use the same IDL you used to develop your Java application as input to the ORB’s IDL compiler, supplied with the TPBroker ORB for C++. You may then use the resulting C++ skeletons to develop the object implementation. Also, object implementations written with the TPBroker ORB for Java will work with clients written with the TPBroker ORB in for C++. In fact, a server written with the TPBroker ORB for Java will work with any CORBA-compliant client; a client written with for Java will work with any CORBA-compliant and/or server.
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:
Note, however, that the TPBroker Java OTS does not support the following OMG OTS interfaces:
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:
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.
The core of the Java OTS is a lightweight client/server library. No daemons or persistent storage are necessary on the machine on which your Java applications run. As part of TPBroker for C++, the Transaction Context Server (TCS) daemons on the server machine manage all transaction contexts delegated from transactional Java applications.
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:
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:
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.
Visit the Authors Web Site
Click Here for The Business Forum Library of White Papers
Search Our Site
Search the ENTIRE Business
Forum site. Search includes the Business