[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SP? RE: [business-transaction] RE: [business-transaction-comment] Public Comment
Boris, I understand your concerns about standards. Why not join the WS-CAF effort? Your input would be appreciated. Mark. ---- Mark Little, Chief Architect, Transactions, Arjuna Technologies Ltd. www.arjuna.com ----- Original Message ----- From: "Lublinsky,Boris S." <Boris.Lublinsky@CNA.com> To: "Mark Little" <Mark.Little@arjuna.com>; "Furniss, Peter" <Peter.Furniss@choreology.com>; <business-transaction@lists.oasis-open.org> Cc: "Newcomer, Eric" <Eric.Newcomer@iona.com> Sent: Saturday, November 08, 2003 6:25 PM Subject: SP? RE: [business-transaction] RE: [business-transaction-comment] Public Comment > This conversation is very fascinating, but... > My paycheck, which I am very attached to, does not depend on > implementation of the best transactional protocol, (you guys know much > more about it) but rather on my ability to architect complex systems. > These complex systems require transactional semantics all over the > place, but the absence of the well-defined protocol forces me to: > 1. Adjust service boundaries, when it is possible, to incorporate > transactional requirements into the service implementations. I > effectively need to factor transactional behavior in the service > "shape", which potentially has a negative impact on the overall SOA > proposition. > 2. Over engineer error handling for every service and system as a whole. > I definitely need transactional support, but if I want to have any > chance to succeed, this support has to have a well defined semantic and > set of APIs/messages, supporting this semantics. > Multiplicity of the transactional protocols will cause me to create my > own abstraction layer - effectively a new protocol, and map it onto all > existing ones - a huge task, which I am not equipped to do. Microkernel > approach - good in principle - will lead to all kinds of vendor > extensions/enhancements, which will break interoperability again. > The unfortunate issue is that transactions have to be part of > interoperability stack - any other solution will break the system. > I am crying for help here.... > > -----Original Message----- > From: Mark Little [mailto:Mark.Little@arjuna.com] > Sent: Friday, November 07, 2003 3:54 PM > To: Furniss, Peter; business-transaction@lists.oasis-open.org; Mark > Little > Cc: Lublinsky,Boris S.; Newcomer, Eric > Subject: RE: [business-transaction] RE: [business-transaction-comment] > Public Comment > > > >===== Original Message From "Furniss, Peter" > <Peter.Furniss@choreology.com> > ===== > >The Mark-and-Peter thread - hope everyone did get Mark's reply to me. > > Yes, maybe we should change the title ;-) > > > > >> -----Original Message----- > >> From: Mark Little [mailto:mark.little@arjuna.com] > >> Sent: 07 November 2003 11:05 > >> To: Furniss, Peter; business-transaction@lists.oasis-open.org > >> Cc: Newcomer, Eric; Lublinsky,Boris S. > >> Subject: Re: [business-transaction-comment] Public Comment > >> > >> > >> >> The general approach, of small core and extra features as > >>> needed, is > >> >> appropriate, but the application of the principle to the problem > is > >> >> completely wrong. > >> >> > >> >> What we are all seeking is a protocol (or protocols) - a set of > >> >> messages with defined semantics - for communicating > >>> transactionality > >> >> between fairly loosely-coupled systems using webservices. > Applying > >> >> the micro-kernel paradigm means we should be looking to > >>> abstract the > >> >> variations in the semantics in different use cases to their > >> >> fundamentals, and have a protocol that transmits the fundamentals. > >> >> Don't even think of implementation or engines yet; just define > what > >> >> the messages must mean, assuming no greater knowledge of > >>> the internal > >> >> behaviour of the opposite end than is mandated by the use of the > >> >> protocol. > >>> > >>> Factoring where factoring makes sense is always a good idea. > >>> However, just because two protocols have messages that have > >>> the same name doesn't mean that they can be factored! > >> > >>Same name ? The portfolio approach gives different names to messages > >>that turn out to have effectively the same meaning. We want to > factorise > >>on semantics, then choose the name. > > >But the fact is that they *don't* have the same semantics. Forward > >compensation and backward compensation are different things and have > different > >guarantees. If I use an XAResource then I know that when I tell it to > >rollback, the work will be undone when rollback returns. If I use a > >compensation resource with a compensation transaction (e.g., Sagas) > then the > >guarantees are different and could result in cascade-abort, which could > take > >hours, days, weeks (or never) to complete. From a service composition > >approach, I want to know what those guarantees are when I create my > >application because it'll affect what I can do. Just because somethings > called > >"cancel" and you map it to "rollback" and "compensate" at a higher > level > >doesn't let me see that the side-effects are different. And this isn't > even > >getting into the discussion about isolation, durability etc. which come > into > >play when you look at interoperability between TP implementations. > > Anything, but semantic factoring, will break interoperability and create > a disaster > >> > >> >> We should, in the first instance, further limit the scope > >>> to the true > >> >> inter-party exchanges - what btp calls the outcome protocol, but > >> >> including the propagation and registration mechanisms. The control > >> >> mechanisms, by which an entity creates a transaction and > >>> controls its > >> >> lifecycle, are secondary - they will frequently be more "intimate" > >> >> than the outcome protocol (in-process api v inter-process > messages; > >> >> intra-company transaction server v inter-company b2b > >> >exchanges), and > >> >> the control mechanism is meaningless without a standardised > outcome > >> >> protocol, but not vice versa. > >> >> > >> >> But WS-CAF/TXM, and to a lesser extent, WS-C/Tx apply the > >>> micro-kernel > >> >> approach to the engine that supports the control mechanism (which > >> >> doesn't need to follow a service-oriented > >> >> architecture) > >> > >>> Why do you say this doesn't need to be SOA based? We're > >>> working in a Web services environment for a start. I know > >>> well the argument that BTP isn't just Web services based, but > >>> in the world of Web services transactions that's not an > >>> argument at all. > > > >>I should have emphasized the word "need". How the application > >>software communicates with its immediate ws transaction support > doesn't > >>*have* to be WS - one could use the JTA interface or something based > >>on it, for example. Of course, defining the control interactions in > >>wsdl makes it easier to have a separate hub-style coordination > >>service, but that's not an essential for getting coordination > >>between application services. Whereas the outcome protocol *does* > >>have to be web-services (otherwise it would just be TIP) > > >OK, I understand your original point now. WS-CF/TXM build on Context, > which > >affects the interaction style, though it's not mandated. > > Context absolutely has to be there if we want any chance of transaction > propagation > > > >> >> and forces the inter-party exchanges (which are > >> >> definitely SOA) to be rich and varied. > >> >> > >> >> Given a common outcome protocol, with the fundamental > >> >promise/decision > >> >> (two-phase) pattern, the separate parties do not need to agree > >> >> beforehand which kind of transaction they are involved in this > time. > >> > >> >That's not true. It may be the case with the people you're > >> >talking to, but certainly for the users of the other > >> >specifications that isn't the case. Services want to know > >> >precisely what kind of transaction they are involved in, what > >> >the semantics associated with it are and (at some stage) > >> >whether they can actually be involved in that transaction. > > > >>This really is the crux of the matter - how often do the services > >>in a transaction *really* need to know what is going on elsewhere ? > > Services usually don't, business process, orchestrating service - does. > > >That may be the crux of some problem, but it's not what I meant in the > above > >paragraph! Basically it comes back to the different guarantees that > each > >extended transaction model (and I class ACID transactions as just a > model on > >this sliding spectrum) provides. Each protocol makes different > assumptions > >(rules) about the characteristics services/participants have in terms > of > >atomicity, isolation etc. and those services/participants must obey > those > >rules. > Absolutely. The problem here that services implementations themselves > are, in this case, transactional resources, implementing certain > transactional guarantees. This can lead to another problem, which is - > you can't really impose transactional semantics on the transactional > scope, including services, that does not support this transactional > semantics. This is like force one phase resource to participate in 2PC > > >>How will it affect their internal behaviour ? > > >Well, like I said, if we just take ACID semantics then I'd like > >serializability from my services for a start, which is something not > all > >models require. It wouldn't be good practice for me to glue together my > > >application from some services that did provide serializability and > some that > >didn't. > See above > > >> How would differences > >>in the internal mechanism affect the rest of the transaction ? If we > >>are > >>service-oriented, or even just trying to keep the different elements > of > >>an application appropriately separated, it is only the service > >>behaviour that is of interest. > > >I'm not sure if we are in conflict here, but I'll assume we are ;-) > > >How the service behaves is mandated by the transaction model is > participates > >within. The overall behaviour of the service with respect to the > transaction > >is a combination of the business logic embedded in that service and the > > >participant(s) that interacts with the transaction. > > So basically, implementation is irrelevant, but supported transactional > semantics is very important > > >> Within a service, one needs to decide > >>how *different* transactions affect each other (or how to stop them > >>doing > >>so), but what does it actually need to know about each, except when > >>two bits of the same transaction come into the same service, and what > >>the > >>timescales are. > >> > >>An excellent statement of service-orientation as it applies to these > >>protocols is > >>found in the short statement on WS-AtomicTransaction in the paper > >>"Secure, Reliable, > >> Transacted Web Services: Architecture and Composition" from IBM and > >>Microsoft > >>(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwe > bs > >>rv/html/wsOverView.asp among other places) > >> > >>Section 3.7.2 of that is: > >> > >>WS-AtomicTransaction defines a specific set of protocols that plug > into > >>the WS-Coordination model to implement traditional two-phase atomic > >>transaction > >>protocols. It is important to note that the atomic, two-phase model is > >>only with > >>respect to the services involved. Sites or infrastructure offering > >>services may > >>advertise two-phase commit, but use some other intra-enterprise model > >>like > >>compensation or versioning. This freedom makes a simple two-phase > commit > >>model > >>more useful for long-running Internet computations. > >> > >>which I entirely agree with. Of course, the statement completely > >>sabotages the > >>need to have a separate BA. > > >Well let's just say that there's a difference of opinion within large > >organisations like IBM and MSFT on everything and if you talk to > different > >people you'll get different answers. C'est la vie! > > > > > > >>> A > >>> service that supports Atomic Transaction (taking the > >>> IBM/MSFT/BEA specs to be even handed) is written entirely > >>> differently from one that supports Business Activity. And the > >>> user of that service had better know before hand that it > >>> can't be invoked using Business Activity because it can't > >>> provide the necessary service-side semantics to obey the protocol. > > > >what exactly can't it do ? The reader of the BA spec will think the > >service > >is going to do perform,/compensate-if-told-to - but the work is still > >tentative in some way until compensate|close and, since this is > >a service, it isn't really meaningful to ask if the "partial results > >are accessible". > > This I think is a very important point-back to the issue that service > becomes a transactional resource and has to be implemented as such > > >Hopefully previous answers answer this. If not, let me know. > > > > >> > Each participant is concerend only with establishing (via the > >> > application exchanges) what the content of its promise will > >> be, making > >> > the promise, and applying the decision. > >> > >> But you ignore what it means to make the promise, or even > >> what that promise is. There are occassions where such a > >> promise can be pushed to the back-end and not affected by the > >> type of protocol. But there are many more where it can't. > >> Maybe I'm missing something here (perhaps reading too much > >> between the lines) because I'm sure you can't believe that > >> abstract "promises" and signals are all that's required. > >> > >> > It > >> > generally doesn't need to know what else is going on in the > >> > transaction, and the rest of the transaction doesn't need > >> to know how > >> > it is delivering on its promises. That's service-oriented > >> > transactionality. > >> > >> That is definitely one specific model, and Business > >> Activities/Long Running Actions do epitomise that behaviour > >> precisely because they've been designed with that in mind. > >> However, the Atomic Transaction models (from both specs.) are > >> intended for *interoperability* between existing TP systems. > >> Please remember that Web services are as much about > >> interoperability as they are about the internet. And in which > >> case, the semantic differences between these types of > >> protocol are significant and can't be ignored, especially at > >> setup (bind) time or (importantly) at implementation time. > > > >I'm quite certain you can use BTP to interoperate with other TP > systems. > >In > >fact isn't that what the JOTM implementation effectively does, treating > >BTP as just another transaction protocol. > > >Well the JOTM implementation only implements close-top atoms as far as > I'm > >aware. > > I don't think that it is feasible to mandate that WS transactions are > build on top of existing TPMs. This can cause two many problems in the > general case. I would rather see it as a rare option > > > > BTP lacks the synchronization > >mechanism (which is we've suggested sync should be stirred into the > >convergence pot). What else is special ? We've got an atomic flag > > >The semantics! There is no implied semantic for isolation or cancel or > >durability (as examples) with BTP - and that's fine: that's not a > problem for > >certain types of application (i.e., this isn't a criticism of the > protocol). > >However, because of that very fact an application provider can't > determine > >purely from the fact that a service is BTP-compliant that it's also > going to > >fully support ACID semantics (again, as an example). Despite what the > above > >IBM paper may say, the Atomic Transaction model in WS-T is meant purely > for > >inter-organisational TP-to-TP interactions where the ACID semantics are > > >mandated and must be known a priori. > > >Now, you could do this with BTP with suitable Qualifiers and maybe > publishing > >the service in a special way in UDDI, for example. But the fact is that > it's > >not part of the protocol. You have to go outside the protocol to do > this. > > I hope, for interoperability sake, that semantics is explicitly defined > in the protocol > > > > > > >> > Of course, there are cases where it is appropriate to pass more > >> > information about the transactional behaviour between the > >> parties. But > >> > those are refinements of the basic exchange, and > >> appropriately passed > >> > as qualifiers, policy declarations etc. For example, informing all > >> > receivers of a context that any participant enrolled with > >> it will get > >> > the same decision allows said receivers to share work between > >> > participants, if they so wish, in a way that would be unsound > >> > without that assurance. Announcing time limits and time > >> > scales, allows other parties (if they have the flexibility) > >> > to choose an appropriate internal mechanism for how they will > >> > work in this case - but a service that lacks the > >> > flexibility doesn't have to be told about a completely > >> > different protocol just because some transactions it is > >> > involved in will take longer than others. > >> > >> Qualifiers are a useful extension to protocols but must be > >> used with care and have to be agreed upon by all sides in any > >> "negotiation". So if I have to define Qualifiers that take a > >> base BTP protocol (say) to the level of ACID transactions (no > >> forward compensation, isolation levels, etc.) then all > >> parties are going to have to agree on the precise meaning of > >> those Qualifiers, I'm going to have to make sure that > >> MustUnderstand (or whatever) is set to true so no one can > >> break the protocol, my services are going to have to > >> publicise the fact that they understand these Qualifiers (it > >> could be done dynamically, but in our experience that's not > >> the way people work at the moment), ... > > > >Unless we take as a starting axiom that everyone must know what kind of > >transaction it is, it is difficult to see why *all* the players > >MustUnderstand. > > >That is precisely my starting axiom - remember, interoperability is > pretty > >important! > > Thank you > > > The qualifier stuff is useful to some, but may not > >be to all. Why can't that service do forward compensation if it > delivers > >the right results to me and to everybody else. ? > > >Because forward compensation doesn't give me the same guarantees for > "undo" as > >rollback (timeliness for a start) and neither does it say anything > about > >isolation or durability. BTP defines just the termination protocol, > leaving > >everything else (such as isolation) up to the service or protocol > extensions > >via Qualifiers. However, WS-T/WS-TXM have implied or explicit semantics > for > >more than termination associated with each model. > > > > >> There's a lot of work there to take a basic protocol and > >> narrow it to a more specific protocol. It's all possible and > >> I'm sure you've as much experience in doing it as we have. > >> But what's to be gained from going that route as opposed to > >> making those agreements explicit in the protocol messages and > >> the WSDL to start with? From the experiences and feedback > >> we've had, the latter approach is what people in Web services > >> are after (whether they want Web services for the internet or > >> for interoperability). > > > >Except they won't actually be explicit. > > >Sorry, who won't be explicit about what? > > > The attraction of the portfolio > >approach is indeed that everything is declared up-front - "this > >transaction is being run under the WS-LRA agreement - if you can't > >cope with that, don't join in". However, in practice, if there is, in > >a particular case a genuine need for distributed understanding of the > >internal behaviour of the parties, the general protocol-defined > >agreement > >is probably not going to be enough. > > >What do you call the general protocol? In my definition I'd say that > "2PC as > >unifying approach" is the general protocol and WS-T/WS-TXM define > specific > >protocols. Is that consistent with your meaning? > > Frankly, I have no idea what this means. I would say that 2PC is one of > unifying protocols. Cohesion can be the other one > > > Compare with XA - although XA > >semantics are fairly tightly-defined, you still have to dig into the > >database manual for sophisticated cases, and if you are into tight > >or loose coupling (in the XA sense), you need a further agreement > >(between > >your program and the database configuration, in that case) > > > >So, how big is the portfolio going to get ? Will there be any chance > of > >interoperation if every service has to choose which of the 3, 5, 10, 60 > >transaction protocols it can cope with ? > > >Who knows? At last count there were well over a dozen extended > transaction > >models some for very specific niche cases and many that were > multi-phased > >(more than 2). But we're not saying that every service has to support > every > >protocol. Where did that come from? > > > > > > >There's a further point - it's claimed that WS-TXM supports > >interoperation > >between transaction protocols. From the ws-caf faq on the Arjuna > >website: > > > >WS-TXM's transaction model supports interoperability across multiple > >transaction > >protocols, including BTP, WS-TXM itself, and other proprietary > protocols > >such as WS-Transaction. > > > >(I thought I'd seen a wider list claimed, but I can't find it) > > > >Now it's possible I've misunderstood that, and the "interoperability" > is > >that > >you can use a BTP atom (say) to deliver the promises of WS-TXM LRA > (say) > >- but > >that doesn't seem to be so from context (and would make it a very > >misleading > >statement). That's certainly possible, but no different from saying any > >of the > >protocols (except those wedded to acid and xa) could "interoperate" > >between local > >database transactions using a compensation approach (say). > > > >But if it means what it seems to, that it is possible to use ws-txm as > a > >transaction bridge, > >with one transaction spanning multiple protocols and mechanisms, then I > >think > >you've made my argument. That can only be true if it *doesn't* matter > >what the internal > >mechanisms are and the protocols *are* semantically equivalent. > > >If memory serves, it refers to the BP model which is specifically about > > >interoperability across different models and enterprise domains. The > >assumptions that that model makes are much more in the area of what you > might > >traditionally consider SOA because it's intended for loosely-coupled > >environments. But that doesn't make it BTP. > > > > > > >> > > >> > The WS-CAF/TXM and WS-C/Tx "portfolio" architectural paradigm is > >> > inappropriate for web-service transactions. > >> > >> Based on whose experiences? I hate to keep sounding like a > >> broken record, but as far as Web services are concerned, the > >> paradigms being proposed by IBM, Microsoft, BEA, Oracle, Sun, > >> IONA, Fujitsu and many others (who make up the Web services > >> "heavy-weights") are appropriate. > > > >ok, so I'm heretic :-). > > >I'm saying nothing ;-) > > > Perhaps the industry hasn't thought through for > >transactionality > >the implications of service-orientation. > > >Or perhaps it has. Don't you think that's worth considering? > Based on what is available, it has not > > > (though actually some of this > >goes right back to OSI CCR and TP - where the open systems > >interconnection paradigm > >(identical to the contemporary internet paradigm) was rather similar to > >SOA). And > >as you pointed out, they didn't implement those much either. > > >Let's meet back on this discussion in 2010 and see what happened ;-) > > >Mark. > > Boris > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]