CORBA 2.6.1 Administration Guide

The NonStop CORBA Event Service is implemented based on the OMG CORBA Event Service specification version 1.1. The Event Service
provides asynchronous communication among CORBA objects.
The Event Service allows supplier objects to communicate through an event channel, notifying any number of consumer objects when events
they subscribe to take place.
The Event Service consists of the Event Service executable, which is also deployed as a server pool. Applications interact with this server pool
by using the CORBA-defined object interfaces to the Event Service.
Transaction Service
The NonStop CORBA Transaction Service (OTS) is implemented based on the OMG Transaction Service specification version 1.1. The Object
Transaction Service is an object-oriented, transaction processing system. Using HP’s proven large-scale transactional management and
services infrastructure, application providers can deliver reliable objects that fully support the
ACID properties of a transaction service.
NonStop CORBA 2.6.1 provides two language bindings: OTS (which is used when developing in C++) and JTS (Java Transaction Service). JTS
is the Java API used when developing objects with Java.
This Transaction Service extends the CORBA model by supporting transaction processing between distributed objects, providing for
interoperable transaction processing within existing CORBA systems.
Figure 1.5. Transaction Service Components
Figure 1–9 shows the software components that implement the Transaction Service in NonStop CORBA. The following components are
provided by NonStop CORBA:
OTS and JTS client stubs
NSotsTM process
NSotsXID process
These components are referred to collectively as NSOTS (when used with C++ applications) and NSJTS (when used with Java applications).
The OTS client stub implements the OMG Transaction Service API for C++ programs. The JTS client stub implements the Java Transaction
Service (JTS) API for Java programs. Both stubs have special capabilities beyond those of client stubs generated by the IDL compiler. To use
these stubs, you link them with your applications just as you link the stubs generated from your application's IDL code.
NSotsTM is a process that collaborates with the Transaction Management Facility (TMF) on the NonStop system to manage transactions. TMF
and NSotsTM work together as equals, alternating in superior and subordinate roles as needed. You can configure the NSotsTM process to run
as a TS/MP server pool.
NSotsXID is a singleton process used to broker transaction identifiers (XIDs) when NSotsTM runs as a TS/MP server pool with multiple
processes.
When creating transactional applications using JTS/OTS, concentrate your efforts on the clients and servers that invoke and handle requests
made within the scope of a transaction; the low-level details of the transaction processing are transparently handled for you by the NonStop
CORBA
OTS Transaction Manager (OTSTM).
A Look at Transactions
The word transaction connotes a “unit of work” in which a client can modify one or more objects. At the end of the transaction process, a
decision is made whether to commit or rollback the changes made in effect of the transaction. This is a group decision based on the outcome of
each individual piece of work associated with the transaction.
Committing a transaction means that all of the changes made during the transaction will be made durable. Rolling back, or aborting, a
transaction means that none of the changes made during the transaction will be made durable and the state of the objects involved in the
transaction will remain unchanged from the state they were in before the transaction was started. A rollback may also occur if certain failures are
encountered during the processing of the transaction.
Transaction processing gives you the ability to process multiple changes to the data that an application accesses.
The ACID Properties of a Transaction