CORBA 2.3.3 Getting Started Guide (NonStop CORBA 2.3.3+)

Defines the name syntax and parsing interface●
Standardizes bootstrapping to a common name context●
Requires id and kind attribute matching●
Adds support for URL (Uniform Resource Locator) names●
The Naming Service installs automatically when you install NonStop CORBA.
Bootstrap Daemon (BSD)
The Bootstrap Daemon (BSD) is a component of the Interoperable Naming Service. The BSD is needed
for interoperability with other ORBs using the Bootstrap protocol. The BSD protocol provides operations
for resolving an initial object reference and for listing the supported initial reference ids. Interoperable
client ORBs send a request to an initialization agent. The agent replies to the client ORB with the
requested information. The IDL interface provides two operations, a get(), which accepts an ObjectId
and a list(), which accepts no arguments. The IDL interface for the two operations is as follows:
module CORBA{
interface InitialReferences {
Object get(in ObjectID id);
ObjectIdList list();
};
};
For more information on the Bootstrap Daemon, see the NonStop CORBA Administration Guide.
Object Transaction Service (OTS)/Java TransactionService (JTS)
NonStop" Object Transaction Service (OTS) and NonStop" Java Transaction Service (JTS) are
automatically installed with NonStop CORBA. OTS implements the Transaction Service Specification
defined by the Object Management Group. JTS implements the Java Transaction API defined by Sun
Microsystems, Inc. These services support transaction processing between distributed objects.
NSots XID Broker
When transaction context is inherited from one process to another, an imported transaction branch is
created. A transaction branch is represented by a new TMF transaction identifier called the XID. The root
XID and any branch XIDs are not recognized by TMF or SQL as representing the same transaction. This
means that if a process such as an application starts a transaction and makes multiple invocations on
server processes, multiple XIDs can be created resulting in SQL errors or blocking. It is up to the
application designer to avoid this problem. If more than one NSotsTM is configured in a server pool,
multiple requests on the same transaction branch might be routed through more than one NSotsTM. This
situation is beyond the control of the application designer.
To solve this problem, NSOTS and NSJTS include an XID Broker function. The XID Broker brokers