RE: [business-transaction] Regarding issue #89

[Peter Furniss <peter.furniss@choreology.com>]

 

-----Original Message-----
From: Sazi Temel [mailto:sazi.temel@bea.com]
Sent: 25 April 2002 04:08
To: Peter Furniss
Cc: WEBBER,JIM (HP-UnitedKingdom,ex1); business-transaction@lists.oasis-open.org
Subject: RE: [business-transaction] Regarding issue #89

At 02:35 PM 4/24/02 +0100, Peter Furniss wrote:

I think this issue comes in at two levels - a scope/procedure/timing issue,  and a technical/content/detail one. However, they aren't entirely separable.
 
The technical content of what is proposed can be described in the diagram attached. The existing actors are already well defined. All that is proposed is that we define an xml representation of the state of a transaction node, in their five flavours. How that serialisation is invoked, or how the xml format is reincarnated to be active or how the serialised state is passed around or stored or how multiple nodes are presented or transferred are not proposed at this stage.  It could be that those are never defined in a btp spec, but some other specification details with the requesting, transfer and reincarnation of entities whose state can be represented as xml - in which case that document would reference this schema as how to represent btp actors that were involved. Or future btp work might cover this (for a different use case), which might mean there were new roles - but even they would be kind of sideways to the existing ones.
 
In fact, re-reading Sazi's paragraph, it answers its own question: " there is nothing to do other than agreeing on a form that we think that a BTP system will externalize its state". That is precisely what we are talking about.
 

I know. But my sentence continues... "even if so, what is the urgency of this requirement?", Why would we rush into and include it in this version? What is the use case that requires this feature ? TMs have been around for long time and I am sure this or similar ideas discussed before but I do not know any two TMs that coordinate/interoparate/fail-over etc this way. I doubt of its usefulness for interoparating different TMS. If it is for ha reasons, there are many other solutions that does the job. 
 

Yes, to be fair, you questioned your own answer :-)   The point was that by constraining the technical scope, we can then see the procedural/timing issue better - exactly as you say: should this be in 1.0 or deferred

 
I don't think this is as simple as just agreeing on a format of externalizing the state... once we have decided this then the next will be how... how often etc.. which I am afraid will definitely have impact on the spec. Again, I think we should have more time to think on this... 

Yes, such things would have further impact. So we put them out of scope of this issue. No-one is proposing that "the next ..." things should be in 1.0.  

There are some detailed questions about the content of the xml document itself - where implementation or application specific information is included; whether the serialisation declares its position in the tree explicitly (e.g. with a role type element) or if it is implicit in whether superior and inferior relationships exist. But the semantic content is well understood - and has been for a very long time, since it's essentially the same for any 2pc transaction node (at least for presume-abort).
 
Whether we end up with exactly the best xml definition for this isn't certain, but then the same applies to all the rest of the protocol. I think we generally expect that 1.0 won't be the final word. Including a serialisation format now means that stands a chance of getting tested along with everything else.

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX

-----Original Message-----

From: WEBBER,JIM (HP-UnitedKingdom,ex1) [mailto:jim_webber@hp.com]

Sent: 24 April 2002 09:56

To: business-transaction@lists.oasis-open.org

Subject: RE: [business-transaction] Regarding issue #89

Hello TC,

 e) I disagree with the idea that this will not have any impact on protocol as it stands now. How would one externalize the state without involving the BTP actors?  We cannot just say it will not have impact on BTP. Surely some actors/roles will involve in externalizing the state and its consistency, perhaps even the participants will involve... If you can do it without involving the BTP actors and without changing any aspects of the protocol, then it is clear that the externalizing state is out of scope of BTP work - there is nothing to do other than agreeing on a form that we think that a BTP system will externalize its state. Even if so, I do not see its urgency at this version of the spec.  If there is no impact, and no changes needed, perhaps I am also missing something here...

I think Sazi has hit the nail on the head here. If we are to allow externalisable state, the there will be one more role in BTP multiplied by however many actors can play that role. Would this not therefore necessitate considerable changes?

However, I could still happily be convinced of the viability of this with a suitable use-case.

Also, I am not using the "royal we" here since there has been far too much of that on these lists lately ;-)

Jim

Sazi Temel
'                               
bea Systems Inc.        
140 Allen Road  Liberty Corner, NJ 07938
        
sazi.temel@bea.com
sazi.temel@ieee.org
(1) 908 580 3123        
http://www.bea.com