| Oh sure: this is definitely XA specific. I wasn't suggesting we make this mandatory for all interactions, only a suggested way for XA participants (coordinators and 2PC) to use.
Mark.
On 19 Dec 2007, at 21:41, Ram Jeyaraman wrote: No, my concern is that bridging WS-TX to XA is a mapping that is specific to the XA domain. Similarly, one might envisage a mapping, say for example, to LU 6.2. Such specific mappings could be developed on top of the WS-TX protocols. XA does not apply to interoperability? Sorry, but that just doesn't parse for me ;-) On 18 Dec 2007, at 21:03, Ram Jeyaraman wrote:
Since bridging to XA domains is a specific use case and does not broadly apply to general interoperability, do you think this work is better pursued outside the TC, for example a profile? On 12 Dec 2007, at 10:43, Ian Robinson wrote:
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.
Sure. I was definitely not suggesting that this is mandated.
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?
See above: I'd be more than comfortable with this being non-normative and a suggestion. 12/12/2007 02:43 | To | | 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
JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)
|