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.
From: Mark Little
[mailto:mark.little@jboss.com]
Sent: Wednesday, December 19, 2007 9:16 AM
To: Ram Jeyaraman
Cc: Ian Robinson; ws-tx@lists.oasis-open.org
Subject: Re: [ws-tx] Issue 117 - Standard tid request for XA
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)
|