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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf 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


(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]