Re: [ws-tx] Issue 117 - Standard tid request for XA

[Ian Robinson <ian_robinson@uk.ibm.com>]

WS-AT is all about interoperability
between service providers. Today the Activation Service may create an Identifier
using any scheme that can be represented with a wscoor:CoordinationContext/Identifier
and there's certainly no reason why an Activation service implementation
cannot do exactly as described here. But this is more of a "suggested
practice for implementors" than anything related to interoperability.
We have, as far as possible, focussed the content of the normative specifications
on the requirements for interoperability. A non-normative "App Notes"
document might be an appropriate home for this sort of material.

A more normative approach to using specific
schemes for Identifiers in certain types of transaction domain - which
would motivate addressing this in the specification - would raise a number
of questions. For example the proposal describes an "optional supported
capability when the coordinator and participants agree". 
1. How would such a capability be negotiated
- using an application-level igorable policy assertion?
2. What behaviour would be required
if an Identifier used a specific scheme but then deviated from it? For
example, in the scheme you mention, if a participant domain receives a
CoordinationContext/Identifier with a formatId of -2 then would it be required
to return a fault?

Regards,
Ian Robinson

Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>

12/12/2007 02:43

To	"ws-tx@lists.oasis-open.org" <ws-tx@lists.oasis-open.org>
cc
Subject	[ws-tx] Issue 117 - Standard tid request for XA

Issue number 117.
 
From: Mark Little [mailto:mlittle@redhat.com]
Sent: Sunday, December 09, 2007 1:42 AM
To: ws-tx@lists.oasis-open.org
Cc: Ram Jeyaraman
Subject: New issue: standard tid request for XA
 
A common interaction pattern when
using WS-AtomicTransaction is bridging between XA domains. XA has a well
defined format for TIDs and it would be nice (aka helpful for users and
developers) if we also had a standard format for WS-AT TIDs that matched,
when running in these kinds of environment, i.e., not mandated for all
uses of WS-AT, but an optional supported capability when the coordinator
and participants agree.
 
Here is one simple suggestion (from
one of our developers): a transaction id scheme ("trid"), followed
by a path that contains only the formatId and by a query ("?")
that contains the globalTransactionId part of the Xid. 
 
    trid:<formatId>?<globalTransactionId>
 
The <formatId> part is either
-1 (to represent a null transaction id) or the decimal representation of
a non-negative 32-bit integer. 
 
The query part (?<globalTransactionId>)
shall be present if and only if the formatId is not -1. The <globalTransactionId>
is a percent-encoded representation (according to the percent-encoding
conventions in RFC 3986) of the global transaction id part of the Xid.

 
Examples:
 
    "trid:-1" (null
trid)
   
    "trid:6789?http://Fabrikam123.com/SS/1234"
(formatId=6789, globalTransactionId=" http://Fabrikam123.com/SS/1234")
 
    "trid:6789?%00%01%02%03%04%05%06%07%08%09%0A%0B%0C%0D%0E%0F%F0%FF"
(formatId=6789, globalTransactionId=[00 01 02 03 04 05 06 07 08 09 0A 0B
0C 0D 0E 0F F0 FF]) 
 
The use of a query ("?") for
the globalTransactionId part eliminates the need for percent-encoding any
occurrences of the chars "/" or "?" in the global transaction
id. This is good for global transaction ids that are URIs. (This is the
case in the second example above). 
 
Note that there is no branch qualifier
in a trid URI, as branch qualifiers do not need to be propagated across
TMs/appservers. This is the main reason we would prefer an URI scheme like
"trid" (over "xid", which suggests the presence of
a branch qualifier). 
 
This proposal is better for textual
global ids than for binary ones. We could have an alternate scheme that
would make binary global ids shorter, e.g.:
 
    "hextrid:6789?000102030405060708090A0B0C0D0E0FF0FF"

 
Or we could still use the same "trid"
scheme and have a longer path instead of a query:
 
    "trid:6789:000102030405060708090A0B0C0D0E0FF0FF"
 
The occurrence of a ":" instead
of a "?" would indicate that the global id is hex-encoded within
the path. 
 
Mark.
 
----
 
Mark Little
mlittle@redhat.com
 
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd,
Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, 
SI4 1TE, United Kingdom. 
Registered in UK and Wales under Company
Registration No. 3798903 
Directors: Michael Cunningham (USA),
Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

S/MIME Cryptographic Signature