OTS — OTSPolicy & OTS internal operations

All "OTS enabled" object references have a componet with an OTSPolicy
that contains one of three policy values: REQUIRES, FORBIDS and ADAPTS.

Any object reference without this OTSPolicy is assumed to be a non OTS
1.2 policy.

The behaviour of the caller is then driven by the value of the
NonTxTargetPolicy. Assuming the caller is in a transaction:

If this value is PERMIT the method invocation proceeds without
propagating the transaction information and any exceptions that result
are ignored (since the object cannot participate in the transaction). If
this value is PREVENT the client is notified via an exception.

Note that the value of the NonTxTargetPolicy is strictly under client
control.

Problem:

Under the covers calls to the OTS server to implement the implicit
transaction propagation are presumambly normal CORBA invocations – and
hence go through normal channels (and through the portable interceptor
calls, etc). What OTSPolicy value (if any) does the OTS server export
for its object references?

If there is no OTSPolicy value and the NonTxTargetPolicy is PREVENT
calls with be refused. If there is an OTSPolicy value (presumambly
ADAPTS) and the call to the OTS results in (an expected exception)
then the transaction will be aborted (because exceptions cause the
transaction to be marked rollback-only).

The real problem is that the OTS implicit client side support must be
able to recognize the invocation to the OTS server as somehow
different from regular method invocations.

Solution(s):

We've identified two possible strategies to handle this problem:

1/ Add a new policy value to the OTSPolicy - INTERNAL. On the client
side references with INTERNAL don't have a PropagationContext sent
and the objects do not participate in the transaction. In addition
INTERNAL objects ignore the NonTxTargetPolicy.

2/ Internally in the OTS runtime mark references that are "internal"
with a specific proprietary policy. In the client side interceptor
references with this policy are treated as "internal" as above.

#1 is the easiest to implement since no special action is needed in
the OTS runtime (besides the obvious action when INTERNAL is seen).
However, it requires a change to the spec and change by all vendors.

#2 is the least intrusive from the specification POV. However, it's a
pain to implement. Vendors must ensure that all internal references
have the correct policy overrides installed on all internal
references. This in practice is not as easy as it sounds

I've implemented both approaches and as far as I can tell they both
work.

see above