Page 10-64 shows the TSIdentification PIDL interface, which must be
provided by the ORB core to the OTS service. Several questions here:
1) TSIdentification is not part of any module on page 10-64,
and the IDL summary in Section 10.6 does not mention it at
all. Which module does it belong to? CORBA? CosTSPortability?
Note that the text for the NotAvailable exception states:
The NotAvailable exception is raised if the ORB
implementation does not support the CosTSPortability module.
This seems to be a hint that TSIdentification is meant to
be part of CosTSPortability. However, that itself raises another
question: an ORB core can raise this exception only if there
actually is a TSIdentification interface that the service
can call. In other words, we seem to have a requirement on
the ORB core here, namely, that all ORBs must provide this
interface, at least to the extent that an OTS implementation
can call it (so that the ORB core can raise the exception).
2) The AlreadyIdentified exception is raised if identify_sender()
or identify_receiver() were previously called "for this addressing
domain".
What is an "addressing domain"? The term is never defined. I assume
what is meant is "address space"? (That would make sense because,
given how the interfaces work, a single process can only deal
with a single OTS implementation at a time.
3) TSIdentification, Sender, and Receiver are PIDL. The C++ mapping
does not specify special mapping rules for these interfaces.
In absence of special rules, the default rules apply. However,
that begs the question: how does the OTS service get hold of
the object reference for TSIdentification, and how does
the OTS create references to Sender and Receiver?
4) The spec says:
"Prior to the first transactional request, the
Transaction Service will identify itself to the ORB
within its domain to establish the transaction callbacks
to be used for transactional requests and replies."
I don't understand how this works. In particular, how does the
thread of control get into the OTS service so that the service
can register itself? At the very least, there would have to
be some sort of call like "initialize_OTS()" that the application
code can call, otherwise, the service doesn't ever get a foot
in the door.
To me, it looks like what would be needed is something on
resolve_initial_references that returns an initialization
object of some kind, so the client can hand the thread of
control to the OTS implementation.
resolve_initial_references does mention OTS, for
"TransactionCurrent". However, if I call ORB_init() immediately
followed by a request for TransactionCurrent, the OTS
implementation won't have had a chance yet to intialize itself.
In turn, that might make it difficult to return a Current object.
The upshot appears to be that there is no way to implement OTS in a way
that wouldn't force the developer to use proprietary calls.