[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 117 - Standard tid request for XA
Having a defined way to represent an XA id, so that it can be recognised
if comes back again, would seem to useful, and completely harmless to
other implementations, who will just treat it as an opaque foreign
identifier. It could be a profile, but where is the forum for such,
other than this group ?
I'm not quite so sure about the branch qualifier point. As editor of the
originating CCR specification (ISO 9805), I believe the use of the
branch qualifier has evolved somewhat. Its original use was to identify
the particular link between nodes (effectively TMs - CCR was an
interoperation protocol), ensuring multiple subordinates (participant)
of one superior (coordinator) were kept separate, even if the
subordinates were co-located. In XA, the branch is used (by some
databases at least) in a roughly similar way, but they take advantage of
the atomicity of the transaction to move work between branches, with
only one two-phase. (There was some suggestion in CCR circles that
different branches could get different (non-atomic) results - perhaps
fortunately, not followed up.) Other databases I believe treat the
entire xid as a unit, keeping branches completely separate. I'd suggest
practical experience rather than the original intent should be our guide
however.
While on the subject, I'll mention that the format id = 0, meaning CCR
format is in fact under-defined. CCR, as an OSI standard, defined its
data-types in ASN.1, which is an *abstract" syntax notation. So, in the
absence of a defined mapping, "CCR format" does not define a bit-by-bit
representation. I suspect the assumption of the XA writers was that
Basic Encoding Rules would be used - but there are now alternative rules
defined for ASN.1, and none is mentioned in the XA spec. (and you'd need
Canonical or Distinguished to get a fixed bit-wise value, which I don't
think existed when XA was written). Fortunately of course, no-one uses
the CCR format :-)
Just thought I'd dig up these archeological fragments before they disappear.
Peter
Mark Little wrote:
> 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.
>>
>> *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
>> <mailto: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 ;-)
>>
>> Mark.
>>
>>
>> On 18 Dec 2007, at 21:03, Ram Jeyaraman wrote:
>>
>>
>> Mark,
>>
>> 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?
>>
>> Thanks.
>>
>> *From:* Mark Little [mailto:mark.little@jboss.com]
>> *Sent:* Tuesday, December 18, 2007 8:21 AM
>> *To:* Ian Robinson
>> *Cc:* ws-tx@lists.oasis-open.org <mailto:ws-tx@lists.oasis-open.org>
>> *Subject:* Re: [ws-tx] Issue 117 - Standard tid request for XA
>>
>>
>> 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.
>>
>> Mark.
>>
>>
>>
>>
>>
>> Regards,
>> Ian Robinson
>>
>>
>>
>> *Ram Jeyaraman <Ram.Jeyaraman@microsoft.com
>> <mailto:Ram.Jeyaraman@microsoft.com>>*
>>
>> 12/12/2007 02:43
>>
>>
>> To
>>
>> "ws-tx@lists.oasis-open.org <mailto:ws-tx@lists.oasis-open.org>"
>> <ws-tx@lists.oasis-open.org <mailto: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 <mailto: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
>> <http://fabrikam123.com/SS/1234>" (formatId=6789,
>> globalTransactionId=" http://Fabrikam123.com/SS/1234
>> <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 <mailto: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/
>>
>>
>>
>>
>>
>>
>>
>> ----
>>
>> Mark Little
>> mark.little@jboss.com <mailto:mark.little@jboss.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) and David
>> Owens (Ireland)
>>
>>
>>
>>
>>
>>
>>
>> ----
>>
>> Mark Little
>> mark.little@jboss.com <mailto:mark.little@jboss.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) and David
>> Owens (Ireland)
>>
>>
>>
>>
>>
>
--
Peter Furniss
Software Engineer
Iris Financial Solutions
www.irisfinancialsolutions.com
Dexter House, 2 Royal Mint Court EC3N 4XX
Phone: +44 (0)20 7954 5900
Direct: +44 (0)20 7954 5943
Mobile: +44 (0)7951 536 168
Iris Financial Solutions Limited is a limited company registered in
England and Wales under company number 4854744 and whose registered
address is Dexter House, Royal Mint Court, London, EC3N 4XX.
The information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. If you are not
the intended recipient please delete and do not disclose to another
person or use, copy or forward all or any of it in any form. Any
views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Iris Financial Solutions Ltd.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]