RE: [business-transaction] Re: SP? RE: [business-transaction] RE: [business-transaction-comment] Public Comment

["Haugen Robert" <Robert.Haugen@choreology.com>]

But but but, WS-CAF will require him 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..."

Or accept the WS-TXM BP suite of protocols as an abstraction layer,
assuming that would work for him (although BP too is a suite of
sub-protocols) and create his own mapping layer.

And yes all of that stuff can still be handled by one single simple set
of protocol messages.

So why not agree on a standard abstraction layer?


-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com] 
Sent: Monday, November 10, 2003 3:51 AM
To: Lublinsky,Boris S.; Furniss, Peter;
business-transaction@lists.oasis-open.org
Cc: Newcomer, Eric
Subject: [business-transaction] 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
>
>
>


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/business-transaction/member
s/leave_workgroup.php.