[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 Peter, I think the reason for the problem here may also be that it seems possible that you may have misunderstood WS-CAF in the first place. Speaking on behalf of the WS-CAF authors, however, I'd first like to say that we do not think there's a problem with the WS-CAF approach, and while we welcome debate, comment, suggestions, and improvements overall I think it's a bit difficult for the WS-CAF TC to accept suggestions that would effectively change the scope of the TC, such as for example "let's not work on WS-CAF because it's got a problem." Anyway, the point of WS-CAF is to define a protocol complementary to the lower level protocols, not a replacement for them. WS-CAF assumes that current TP infratructure will continue to exist, and that the job of an effective Web services transaction specification is to bridge and map to existing environments rather than propose a single, new, all-emcompassing environment. The aim of WS-CAF is in fact directly opposite what you've apparently misunderstood it to be - it is not a proposal to replace anything. It is a proposal to co-exist with everything, and that seems to me what must be causing the confusion here. Thanks, Eric -----Original Message----- From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] Sent: Tuesday, November 25, 2003 10:32 AM To: Newcomer, Eric; WS-CAF Subject: RE: [ws-caf] discussion on approaches for web services/ business transaction 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/20031 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/20031 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/msg0000 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]