RE: [ws-caf] discussion on approaches for web services/ business transaction

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Greg,

A good question, but yes I did mean it, though obviously I was being
terse.

The distinction between "inaccessible/undetectable/apparently
firm/visibly tentative" depends on who the "other entity" attempting
access is. In a classic world, the other entity is say another user of
the database - or at least one that is using an equivalent isolation
level. If they are doing dirty reads, our isolation is broken, but, for
our transaction, we model that as being irrelevant - such lower-level
accessors are just deemed to be non-entities.  But in a service world,
we want to concentrate only on what the service itself is offering - the
semantic implications of, say, a tentative hotel reservation are limited
to whether or not I can be sure of a room if I confirm and sure of not
paying if I cancel in time. That reservation is  probably visibly
tentative to the booking staff, perhaps apparently firm to maintenance
(room must be in order by date ..). To another user of the service
(another would-be guest) the question is vague - if there are still
rooms available, they can get in, if not, not (or they might be
waitlisted in the hope that I or someone else cancels).

Although that example is from a loosely-coupled world, I think the same
applies in the more classic cases. A client that is concerned to know
what properties are applied inside a resource manager, beyond assurance
that it will abide by its service agreement (for this client and for
other clients), has sort of gone round the back of the service boundary.
That's going to be because the designer of the client is also the owner
of the resource manager and is using the client to ensure the resource
manager behaves as desired - in fact to configure the services. That's
certainly a rational and practical way of working things in a closed
world, but it confounds the service boundary. In choosing a protocol to
support transactions in a service-oriented world, we want to minimise
the information that must travel over that boundary.



Peter

-----Original Message-----
From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
Sent: 25 November 2003 16:18
To: Furniss, Peter
Cc: Newcomer, Eric; WS-CAF
Subject: Re: [ws-caf] discussion on approaches for web services/
business transaction


I'm somwhat puzzled by this statement, or rather wonder if it's not a 
misstatement altogether:

"Exactly how a service makes
sure that, say, your initial reservation will be honoured or will not
cost you anything (depending on confirm/cancel) is a concern of the
service, but not of the client. "being a concern of the service"
includes whether the tentative (unconfirmed/uncancelled) reservation is
inaccessible/undetectable/apparently firm/visibly tentative to other
entities accessing the same information but that still doesn't affect
this client."

It's not the "how" but the semantic implications of the "how" for the
activity as a whole that is important. If I want to reason about, taking
a familiar example, ACID properties of a transaction as a whole, I
certainly care to know whether or not the result is (pick one)
"inaccessible/undetectable/apparently firm/visibly tentative". My client
may very well be uninterested in using your service if the result is,
say, apparently firm precisely because it is concerned about the broader
semantic implications for the activity itself.

Greg



Furniss, Peter wrote:

>Eric,
>
>My summary was perhaps not clear - you'veanswered a different question
>:-)
>
>The problem as I see it with the WS-CAF approach is that you end up 
>with multiple transaction PROTOCOLS. That is each "transaction model" 
>has a different set of messages that pass between the entities 
>involved. They may share the propagation and registration messages (and

>also share these with the other non-transactional uses of the context 
>management
>aspect) but once it gets to the "shall we/shall we not" completion
stage
>the messages are different.
>
>That means that all the systems involved have got to implement and be 
>aware of the different models involved, although for many cases a 
>particular component (a client-side controller of the transction, or a 
>server-side responsible for some resource (in a wide sense)) may 
>perform in exactly the same way for many models. Exactly how a service 
>makes sure that, say, your initial reservation will be honoured or will

>not cost you anything (depending on confirm/cancel) is a concern of the

>service, but not of the client. "being a concern of the service" 
>includes whether the tentative (unconfirmed/uncancelled) reservation is

>inaccessible/undetectable/apparently firm/visibly tentative to other 
>entities accessing the same information but that still doesn't affect 
>this client. (the case where the client and the service are under 
>common ownership may make this separation moot, but there is still no 
>benefit in using a different set of messages just because the same 
>designer is at each end)
>
>Of course there will be a need for some indication of what variations 
>are expected - time scales most obviously, also atomicity indications 
>etc. But these can be handled as modifiers on a single set of messages,

>rather than requiring a separate set of messages. This has the 
>interoperation benefit that understanding of the modifiers doesn't have

>to be universal - if a component's behaviour is unaffected by a 
>modifier, it doesn't need to understand it.
>
>This is to say nothing about the "WS-CAF idea concerning the value of a

>separate and generic context management system", nor about whether, if 
>that exists, it can be used by the transaction protocol. But the 
>transaction protocol should be only a single customer of that, not a 
>legion.
>
>------------------------------------------
>Peter Furniss
>Chief Scientist, Choreology Ltd
>
>web: http://www.choreology.com
>email:  peter.furniss@choreology.com
>phone:  +44 870 739 0066
>mobile: +44 7951 536168
>
>
>
>-----Original Message-----
>From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
>Sent: 21 November 2003 14:48
>To: Furniss, Peter; WS-CAF
>Subject: RE: [ws-caf] discussion on approaches for web services/
>business transaction
>
>
>Peter,
>
>It would seem the answer is obvious, since WS-CAF takes an approach 
>that allows multiple transaction models, BTP being one of them.  So the

>discussion would naturally need to focus on the best way to map BTP 
>onto WS-CAF.  But you are also correct that this aspect of the WS-CAF 
>work is planned for a bit later into the effort.
>
>Our initial task is to validate the WS-CAF idea concerning the value of

>a separate and generic context management system, apart from 
>transaction protocol.  I (and the other co-authors) believe there's a 
>need to manage context other than transaction context, and that a 
>system can be built up incrementally toward the transaction management
solution.
>
>This would appear the starting point.  I agree with you that other 
>discussions related to whether or not BTP might wish to change its 
>orientation toward multi-protocol compatibility are better handled on 
>the BTP email list.
>
>Thanks & regards,
>
>Eric
>
>-----Original Message-----
>From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
>Sent: Thursday, November 20, 2003 9:47 AM
>To: WS-CAF
>Subject: [ws-caf] discussion on approaches for web services/ business 
>transaction
>
>
>WS-CAFer's - especially those interested in seeking a good general 
>solution to the need for transactional mechanisms in the web services 
>environment - may be interested in the discussion thread on the OASIS 
>business-transaction list with the title "Public Comment" - it began 
>with a message on the business-transaction-comment list
>(http://lists.oasis-open.org/archives/business-transaction-comment/2003
1
>0/msg00001.html - but archive displays
>badly) from Boris Lublinsky, with a detailed response from Mark Little
>and Eric Newcomer
>(http://lists.oasis-open.org/archives/business-transaction-comment/2003
1
>1/msg00000.html) and then the discussion
>tranferred to the main business-transaction list (thread-head is
>http://lists.oasis-open.org/archives/business-transaction/200311/msg000
0
>4.html - some of the later messages are bit mangled (my first one is
>split in two), but you can probably work out what is going on.
>
>I intend to continue the discussion (Mark left the ball in our 
>sub-thread in my court, I think). Since the fundamental question in 
>this area is whether the starting point should be a single transaction 
>protocol or a large number of such, it would seem this is critical to 
>this group. However since ws-caf is based on the latter assumption, and

>in any case the workplan doesn't get round to transactions for a 
>considerable time, the business-transaction list would seem the best 
>place (cross-posting to archiving lists generally being a bad thing). 
>BTP of course does currently take the opposite approach, but the BT 
>group is keen to reach convergence in the business transaction area, 
>and won't count people joining the list as necessarily agreeing.
>
>Peter
>
>------------------------------------------
>Peter Furniss
>Chief Scientist, Choreology Ltd
>
>   Cohesions 1.0 (TM)
>   Business transaction management software for application 
> coordination
>
>web: http://www.choreology.com
>email:  peter.furniss@choreology.com
>phone:  +44 870 739 0066  <-- new, from 4 August 2003
>mobile: +44 7951 536168
>  
>