OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi,

Apologies, I should have been clearer about my suggestions.  I think it would be in scope to propose rewriting WS-CAF, but I do not recommend it, or think it would be a good use of anyone's time.  It would be a way to bring the matter to a vote, that's all.

Mark's suggestion is much more positive, that is, about working to ensure a good mapping for BTP to WS-CF, assuming of course that's what Choreology is interested in.

Eric

-----Original Message-----
From: Mark Little [mailto:Mark.Little@arjuna.com]
Sent: Friday, November 28, 2003 5:17 PM
To: Furniss, Peter; Newcomer, Eric; Haugen Robert; WS-CAF
Cc: business-transaction@lists.oasis-open.org
Subject: RE: [ws-caf] discussion on approaches for web services/
business transaction


I don't think the concept of "one protocol to rule them all and in the 
darkness bind them" (apologies to Tolkien) has yet to be proven. However, as 
we've said a few times, WS-TXM was always intended as a live document for new 
protocols to be added as and when needed. Rather than re-invent the wheel, it 
would seem like another approach (which would be in scope, I assume) would be 
to support BTP within WS-CAF and allow proponents to use that.

Mark.

>===== Original Message From "Newcomer, Eric" <Eric.Newcomer@iona.com> =====
>Peter,
>
>Thanks for this, and yes I think I would have to agree the better place for 
the discussion is the probably the BT email list, assuming that that list is 
intended for debates on broad, abstract topics.
>
>I think there are two ways to proceeed that would put your suggestion in 
scope:
>
>1)  Write a detailed issue, with page numbers, text citations, and proposed 
new text to clearly illustrate the impact of the suggestion on the current 
spec drafts
>2)  Create a new spec draft for consideration as potential input to the 
WS-CAF TC
>
>I do not think we really have any way to deal with such a broad and abstract 
suggestion.  We will need something definite and concrete to vote on.
>
>Eric
>
>-----Original Message-----
>From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
>Sent: Friday, November 28, 2003 12:48 PM
>To: Newcomer, Eric; Haugen Robert; WS-CAF
>Cc: business-transaction@lists.oasis-open.org
>Subject: RE: [ws-caf] discussion on approaches for web services/
>business transaction
>
>
>Eric,
>
>
>> Thanks for this, but as you say, this discussion largely
>> boils down to a matter of opinion.
>
>True. Either way could work. It is a question of which is most
>
>> If there are specific issues here for the WS-CAF specs I have
>> to say I still can't either understand or recognize them.
>
>Yes, I understand your problem as TC Chair. Given the scope stated in
>the charter as fixed, it is difficult to have this discussion in WS-CAF
>TC. Which is why we've suggested the BT TC list (note, that is not the
>BTP TC, though it tends to get called that) as the place to work out the
>discussion.
>
>> I think what we are interested in as a TC are specific
>> suggestions, corrections, amendments etc to the WS-CAF drafts.
>
>Well, the specific suggestion would be collapse all the TXM variants to
>one, which would probably have the message set of ACID, a slightly
>looser state sequence (to allow for optional prepare etc.), and restate
>the semantics of the messages in a way that allows internal choice in
>how those semantics are implemented.
>
>I wonder if you feel that is in scope ?
>
>(It would apply only to the superior/inferior "outcome" exchanges, not
>the control ones, where there might be different protocols)
>
>
>Peter
>
>> Thanks again,
>>
>> Eric
>>
>> -----Original Message-----
>> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
>> Sent: Friday, November 28, 2003 10:40 AM
>> To: Newcomer, Eric; Haugen Robert; WS-CAF
>> Cc: business-transaction@lists.oasis-open.org
>> Subject: RE: [ws-caf] discussion on approaches for web
>> services/ business transaction
>>
>>
>> (cross-posted to the BT tc list - apologies for those of you
>> who are on both BT and WS-CAF, but there are a lot who aren't
>> and I believe the recent thread on ws-caf will be of interest
>> to the BT folks)
>>
>>
>> Eric,
>>
>> I don't see how all the WS-TXM protocols can "bridge" in a
>> single sense of the word while following the meta-model that
>> leads to the requirement for multiple protocols.
>>
>> Of course, today, each environment has its own protocol, at
>> least in the sense of the encodings of the messages. It's
>> legitimate to bridge or translate between those where the
>> semantic of the messages is close enough.  The question is
>> what is "close enough".
>>
>> One can argue, as I understand you do, that the transaction
>> models appropriate to particular groups of interacting
>> entities are so different that each model requires a
>> distinguished protocol.
>>
>> One can argue, as I have been, that the particular
>> transaction model doesn't need to be known to each entity,
>> only the responsibilities each entity enters into and thus
>> you can use a single protocol.
>>
>>
>> But if one believes the semantics associated with a protocol
>> are very precisely defined and reflect the overall model then
>> bridging such protocols would be inappropriate. Conversely,
>> if the semantics of protocols are considered to be limited to
>> the inter-party contract then bridging is merely a matter of
>> using the appropriate syntax for the new environment - in
>> which case you only need one protocol for web-services.
>>
>>
>> I suppose you could mean bridging in one of two contradictory
>> senses that wouldn't violate the assumptions you seem to be
>> building on:
>>
>> 	a) WS-ACID could bridge (in the sense of translate)
>> between OTS, MTS, TIP, WS-AtomicTransaction since they all
>> talk about the same transaction model. That's the same target
>> as TIP had - just a way of shipping their messages in a style
>> that is acceptable to the new (WS) environment, and the
>> ability to get inside the TMs (the latter because one of the
>> TMs must be subordinate/open-top to the other). This would be
>> the same as demonstrated in the ACTranS project we were both
>> on - especially the OTS->TIP-MTS gateway.
>>
>> 	b) "bridging" could mean getting a level of consistency
>> between transactional domains, where one wider business
>> transaction typically involves several transactions in each
>> domain, as each domain ensures it is in an internally
>> consistent state before sending messages in the inter-domain
>> protocol. (which is in fact a very common implementation
>> choice within a business transaction). That's a good answer
>> to a customers question "how do I get consistency between my
>> applications using different TMs" but it's not an answer to
>> the question "how do I bridge a transaction from TM A to TM B".
>>
>> The thing is that bridging sense a) doesn't have anything to
>> do with LRA or BP (unless you can find a model-identical
>> protocol) and sense b) doesn't have anything to do with WS-ACID.
>>
>>
>> I still assert that an approach that says a single model must
>> be understood by all the parties and the protocol must be
>> tied one-to-one to the model will not scale, whereas looking
>> only at the service-user:service expectations allows a single
>> transaction protocol that really can bridge.
>>
>> Peter
>>
>>
>> > -----Original Message-----
>> > From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
>> > Sent: 25 November 2003 21:37
>> > To: Haugen Robert; WS-CAF
>> > Subject: RE: [ws-caf] discussion on approaches for web
>> > services/ business transaction
>> >
>> >
>> > Bob,
>> >
>> > Again, I have to apologize for not agreeing that there's an
>> > issue, or perhaps just not understanding that there's an issue.
>> >
>> > The sub-protocols represent existing environments and
>> > potentially new environments that need to be bridged for the
>> > simple reason that all environments (current and potential)
>> > do not use the same protocol.
>> >
>> > The ACID and LRA tranasaction models in WS-TXM are optional,
>> > as is the BP model.  So the ACID and LRA protocols can be
>> > sub-protocols to the BP model, as can legacy protocols, WS-T,
>> > or BTP.  The ACID, LRA, and BP protocols are not required.
>> > They do not replace anything, and are intended as
>> > complementary protocols instead of replacement protocols.
>> >
>> > I'm sorry, but I still do not see the issue.  This is how
>> > WS-CAF is designed.
>> >
>> > Thanks,
>> >
>> > Eric
>> >
>> > -----Original Message-----
>> > From: Haugen Robert [mailto:Robert.Haugen@choreology.com]
>> > Sent: Tuesday, November 25, 2003 12:38 PM
>> > To: Newcomer, Eric; WS-CAF
>> > Subject: RE: [ws-caf] discussion on approaches for web
>> > services/ business transaction
>> >
>> >
>> > Eric Newcomer wrote:
>> > > the point of WS-CAF is to define a protocol complementary to the
>> > > lower level protocols, not a replacement for them.
>> >
>> > I can understand that assertion re WS-Context and WS-CF
>> > (Coordination), but the issue Peter and I and others have
>> > raised is about WS-TXM.
>> >
>> > When I read WS-TXM, I see a suite of new business transaction
>> > protocols: ACID, LRA and BP, where BP itself decomposes into
>> > a suite of sub-protocols.
>> >
>> > How do I correlate the suite of new protocols in WS-TM with
>> > your statement above?
>> >
>>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]