[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] ACTION for optimization of registration
Green, Alastair J. wrote:
>Greg,
>
>1. "Our priority is to overlay existing tp capabilities": what is this
>but an appeal to historical precedents as our guiding authority? But the
>statement is a) a view, not a decision, and b) technically wrong,
>because you are taking part in an attempt to define an atomic
>transaction protocol which is based on one-way messaging, and this is
>not the pattern of existing tp capabilities.
>
>2. If the Acid capability is "just about the only thing that companies
>need today", then presumably you oppose LRA and BP? If not, then the
>comment has no practical purpose. How do you implement distributed BPEL
>compensable scopes with Acid and XA? It cannot be done: there must be
>the ability to a) write user participants, and b) have selective
>outcomes.
>
>Now, it is true that these two things are not incompatible with a
>protocol that also supports distributed "ACID". We have spent four years
>arguing that the protocol does not constrain or dictate the endpoint
>behaviours or the outcome algorithm, and that a single protocol is
>capable of supporting both types of behaviour.
>
>That is not an opinion, it is a technical fact: you can download our
>product and see it in action.
>
>The anti-generalization shibboleth is the statement that "one size does
>not fit all". It runs through the WS-CAF input documents that your
>company advocated like letters in a stick of rock.
>
I will resist commenting on the Choreology stick of rock.
>It is technically
>false, and it is politically driven.
>
As I said the other day, this discussion has been done before enough
times and the TC has agreed to move on. "technically false" is neither
born out by technical facts nor by commercial/deployment realities. I
hardly see politics in this as much as you seem to do time and time again.
>I don't blame you or anyone else
>for working under commercial-political constraints, but I see no reason
>to ignore the elephant in the room.
>
>
Which elephant would that be? The white one with "one protocol does fit
all" written on it?
>If you wish to change your view, and admit that LRA and BP are redundant
>because they confuse endpoint behaviour and outcome policy-making with
>the characteristics of a distributed coordination protocol, then I will
>be the first to support you in the effort to stop the needless
>variation.
>
>The notion of generic checking is -- as you are acutely aware -- the
>thin end of the wedge of technical logic that points in that direction.
>All of the TXM input protocols are variants of two-phase, and every
>essential part of their functionality can be supported by a single
>protocol. Recognizing this would impel an advance in technical
>capability; your position is one of technical stasis.
>
>If you persist in the view that different protocols are needed to do
>ACID, nested compensable scopes, and protocol bridging, then I repeat:
>where do you stand on LRA and BP? Has this committee voted to drop them,
>and the problem domains that they seek to address?
>
Not that I know of. I assume Greg will reply anyway, but I strongly
suspect that you are reading far too much between the lines and/or
putting words into Greg's mouth.
>Has Oracle decided
>against them?
>
>I leave aside newer problems that you and other Oracle spokesmen have
>asserted are important to your company, such as support for WS-CDL
>coordination.
>
>
>
Mark.
>Alastair
>
>
>-----Original Message-----
>From: Greg Pavlik [mailto:greg.pavlik@oracle.com]
>Sent: 20 July 2005 20:22
>To: Green, Alastair J.
>Cc: Mark Little; ws-caf
>Subject: Re: [ws-caf] ACTION for optimization of registration
>
>I'll try to reply before weeks end to the technical issues.
>
>Just to be clear on preceding comments:
>
>1) I'm not pressing for closure on matters that have barely been
>discussed. I'm asking if we have some consensus points on enlistment
>optimizations so we can advance the discussion. Period.
>
>2) Neither am I appealing to history as authority (you're making these
>discussions seem like a medieval disputation): I'm saying simply that
>our priority for the acid protocol is to overlay existing tp
>capabilities; I'm struggling with how that concern can be positioned as
>a political shibboleth. At the end of the day, its just about the only
>thing that most companies need today.
>
>Greg
>
>Green, Alastair J. wrote:
>
>
>
>>I think "issue-centric" thinking tends to incarnate an intended
>>
>>
>solution
>
>
>>in an issue statement.
>>
>>Pressing for closure on matters that have barely been discussed tends
>>
>>
>to
>
>
>>create a series of point solutions that may well be poorly-thought out.
>>
>>We want to create a one-way message-based coordination protocol. It
>>cannot and will not look like an RPC-based protocol.
>>
>>We want to acknowledge that we are dealing with an asynch application
>>environment. The OTS does not deal with such an environment.
>>Deferred-synch is what it says -- it matches pairs.
>>
>>So the appeal to (a rather limited view of what is) history is
>>misplaced.
>>
>>The avoidance of "generalization" is a political shibboleth in this
>>committee, but it is not a good guide to good technical solutions, when
>>the problems have general features.
>>
>>To answer your questions:
>>
>>1. We can deal with checking separately from enlistment. But the
>>solution originally proposed does not. The thrust of Mark's proposal
>>
>>
>was
>
>
>>to conflate them. My remarks are directed against such a conflation,
>>
>>
>and
>
>
>>in favour of creating an explicit signal for checking.
>>
>>However, once we look at the same problem for the standpoint of
>>optimization, we suddenly realize that the unbundled can handily be
>>bundled: we must communicate the signal: "this is all of them", with a
>>set of "enrols" or a set of "prepareds" in one message.
>>
>>We must distinguish between logical independence and "mass transit".
>>Putting people in a bus doesn't liquidate their identity.
>>
>>So in the end, if we want optimization we must tease apart, and then
>>allow recombination ... looping back to Mark's proposal. This approach:
>>break down the semantics, but be prepared to ship them intelligently
>>
>>
>for
>
>
>>optimization purposes, is the BTP approach, and it works.
>>
>>2. We can and should generalize checking, because it's a general
>>requirement of all multi-phase coordination protocols where there is a
>>cost associated with resource retention in the nodes of the graph.
>>
>>In addition:
>>
>>3. We need to look at the BTP model, not at the OTS model, if we want
>>
>>
>to
>
>
>>do checking right for asynch one-way oriented environments (which are
>>the superset of all others). Check that they've started, not that
>>they've finished; check the ENROLS, not the PREPAREDs. It works for all
>>styles of transaction (short and long-lived) and it is the fastest
>>(earliest possible point of safe commitment) -- two good arguments in
>>favour of this being the generalization chosen.
>>
>>The customer case I mentioned on the call involved a distributed ACID
>>environment using XA resources. The work of the whole system was
>>decoupled (a tree of worker processes through which the workload
>>drained), and the initiator of the transaction wanted to go away as
>>
>>
>soon
>
>
>>as it could (be reused in fact). The moment the total set of operations
>>was up and running, the commit could be issued, and the initiator could
>>move on.
>>
>>This issue is related to the notion of PREPARED equalling ENROL. If, in
>>a loosely-coupled system, participants can say (spontaneously): I'm
>>done, then we can check the dones, not the starteds. That's a really
>>useful optimization, by the way.
>>
>>4. If there is an appetite to create multiplex optimizations, then
>>please can we do the job properly, and come up with a general scheme?
>>The particular scheme will almost certainly have to address almost all
>>the same issues, and the "simplicity" of having a point solution will
>>gain next to nothing in thought or implementation, and will preclude
>>generality and flexibility.
>>
>>Alastair
>>
>>Alastair J. Green
>>CEO and CTO
>>Choreology Ltd
>>68 Lombard Street
>>London EC3V 9LJ
>>www.choreology.com
>>
>>+44 870 739 0050
>>+44 870 739 0051 (fax)
>>+44 795 841 2107 (mobile)
>>
>>
>>-----Original Message-----
>>From: Greg Pavlik [mailto:greg.pavlik@oracle.com]
>>Sent: 20 July 2005 16:30
>>To: Green, Alastair J.
>>Cc: Mark Little; ws-caf
>>Subject: Re: [ws-caf] ACTION for optimization of registration
>>
>>I'm concerned that we're radically overgeneralizing the discussion.
>>
>>1) Alastair, do you agree that we can deal with enlistment independent
>>of checking, ie, without implied graph completion semantics at the CF
>>level? If there's a consensus on that, I'd like us to move forward
>>
>>
>there
>
>
>>so we can close down that issue.
>>
>>2) Independent of 1), is there a general consensus that checking is
>>something that should be tackled independent of a particular protocol
>>semantic?
>>
>>I have some concerns about this latter point. "Acid" systems do in fact
>>
>>
>
>
>
>>tend to conform to a set of historical constraints, eg assumptions
>>embedded in DTP. My main concern with the acid protocol is that it
>>provide a basis for interoperability with existing systems: I do not
>>think anyone will see it as a general mechanism for "web transactions."
>>
>>
>
>
>
>>From that perspective, I don't have a problem with a simplistic
>>checking solution that are consistent with how things have been done in
>>
>>
>
>
>
>>the past *for the acid protocol*, especially if its known to work well
>>with deployed tp technology.
>>
>>Greg
>>
>>Green, Alastair J. wrote:
>>
>>
>>
>>
>>
>>>I don't understand a number of Mark's arguments here.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>(i) a WS-Context context that flows back on the response; none of
>>>>>
>>>>>
>our
>
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>>>specifications actually restrict context flows on "outbound"
>>>>>messages, since we're in a one-way domain, and this is conceptually
>>>>>appealing as it continues to tie together message exchanges within
>>>>>the same activity because the messages are all contextualised. Put
>>>>>
>>>>>
>it
>
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>>>another way: all one-way messages are contextualised and we are
>>>>>simply providing another specific element within the extension
>>>>>capability we already support, to address this. The precedent for
>>>>>this is the OTS and various commercial implementations.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>1. A context that flows back on a response is not an OTS concept.
>>>
>>>
>There
>
>
>>>is no such concept in OTS. This is a BTP concept, called "context
>>>reply". In OTS there is assumed to be application message pairing,
>>>equivalent to return of a function call in X/Open DTP's modelling
>>>mindset. OTS wrongly applies the X/Open synchronous model to the
>>>distributed checking problem.
>>>
>>>2. OTS has a concept of "reply checking". This states that one must
>>>count back the application responses that match each application
>>>request. This is crude and excessive.
>>>
>>>OTS states that checking in a distributed tree is tantamount to
>>>
>>>
>>>
>>>
>>ensuring
>>
>>
>>
>>
>>>that all transactional work of all leaf nodes has been completed.
>>>
>>>In fact:
>>>
>>>a) an application response may be the first or nth of a conversational
>>>stream, and its arrival cannot be construed as equalling completion of
>>>anything other than its role in the application's own protocol;
>>>
>>>b) the danger of unchecked behaviour arises, not from attempting
>>>
>>>
>>>
>>>
>>confirm
>>
>>
>>
>>
>>>processing until all transaction work has been accomplished, but from
>>>attempting confirmation before all participants are enrolled.
>>>
>>>A one-way message-based transaction completion protocol can begin to
>>>pass two-phase requests downtree long before all leaf node work is
>>>completed. The key point is that, while a PREPARE downtree may stall
>>>waiting for a PREPARED (wait for work to complete), we must not send
>>>PREPARE to only some of the required participants. If we do then we
>>>
>>>
>>>
>>>
>>risk
>>
>>
>>
>>
>>>leaving them in a solitary state of preparedness (a state from which
>>>they can never escape short of a brutal backstop timeout on their
>>>attempts to retry obtaining a second-phase instruction). The
>>>
>>>
>terminator
>
>
>>>application should be able to leave transaction completion to occur
>>>without regard to its own lifecycle.
>>>
>>>3. BTP correctly addresses these two problems a) and b). It introduces
>>>
>>>
>>>
>>>
>>a
>>
>>
>>
>>
>>>signal that means: "all enrolments stemming from an application
>>>
>>>
>message
>
>
>>>have been processed". This signal is a BTP message CONTEXT-REPLY. It
>>>
>>>
>>>
>>>
>>can
>>
>>
>>
>>
>>>be sent independently of application responses or as part of an
>>>application response message (as a header element). This signal
>>>logically terminates the stream of 0..n ENROL signals that may arise
>>>
>>>
>as
>
>
>>>a result of a service receiving an inbound CONTEXT message:
>>>
>>>CONTEXT
>>>ENROL/ENROLLED
>>>ENROL/ENROLLED
>>>...
>>>CONTEXT-REPLY
>>>
>>>This sequence could be thought of as the "checking sub protocol".
>>>
>>>(This is a simplification: the reply can be used to communicate
>>>
>>>
>failure
>
>
>>>of required enrolments, and there can be a stream of context replies
>>>
>>>
>to
>
>
>>>indicate to the app that it's in business, but that the protocol level
>>>checking hasn't been completed.)
>>>
>>>4. The point I have been trying to get across in the last week or so
>>>
>>>
>is
>
>
>>>that the need satisfied by CONTEXT-REPLY is separate from the issue of
>>>"boxcarring".
>>>
>>>BTP has all kinds of (useful) network traffic optimizations. It can
>>>concatenate any number of protocol messages together in a wrapper
>>>element holding BTP messages ("bundling"). And it can also "group"
>>>messages to create compound semantics (e.g. CONTEXT-REPLY & ENROL &
>>>PREPARED).
>>>
>>>Mark says:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>(ii) a "boxcar" (a la BTP) of enlistment messages that accompany the
>>>>>
>>>>>
>
>
>
>>>>>one-way "response" message. The precedent for this is BTP.
>>>>>
>>>>>Now it seems to me that (ii) could be dealt with by the underlying
>>>>>SOAP infrastructure - that's always been the argument against
>>>>>
>>>>>
>putting
>
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>>>>boxcarring into the protocol. Whereas (i) is a specific approach for
>>>>>
>>>>>
>
>
>
>>>>>a very specific problem.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>Mark then goes on to explain that his approach i) -- so sedulously
>>>distinguished from BTP -- is in fact to have a bunch of enlistment
>>>messages that accompany a one-way response message called ... a
>>>
>>>
>>>
>>>
>>response
>>
>>
>>
>>
>>>context, which sounds awfully like approach ii).
>>>
>>>Without vectorization we cannot group the context reply ("checked")
>>>
>>>
>>>
>>>
>>with
>>
>>
>>
>>
>>>the enlistments or registrations that must succeed to achieve the
>>>checked state. The checked message has no magical power on its own to
>>>achieve vectorization.
>>>
>>>5. Mark is right to say there are two ways of achieving vectorization:
>>>by relying on the infrastructure, and by doing it yourself. I have to
>>>smile when I read that the SOAP infrastructure will do it for us. I
>>>
>>>
>>>
>>>
>>have
>>
>>
>>
>>
>>>been hearing this for four years. In what decade, and through which
>>>well-known protocol nearing maturity within the WS architecture will
>>>this occur?
>>>
>>>In BTP we did three wise things as a TC on this kind of question --
>>>refused to reference incomplete specs, defined all the facilities we
>>>needed abstractly, and defined a "today's technology" binding that
>>>concretely expressed them -- while defining how a "tomorrow's
>>>technology" binding might be created when the time came. The abstract
>>>EPR/WS-A issue. Are these WS-CAF specs to be capable of implementation
>>>this or next year? If so then I suggest we need to define how
>>>
>>>
>>>
>>>
>>boxcarring
>>
>>
>>
>>
>>>is going to be done, or drop the attempt to support it altogether.
>>>
>>>6. Which brings me back to Mark's proposed text. Boxcarring is
>>>
>>>
>achieved
>
>
>>>by stating that the context will contain enlistments as extension
>>>elements. Mark comments:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>This all presupposes something along the lines of (i) above. [AG:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>having a context reply by using an extended context]
>>>
>>>
>>>
>>>
>>>
>>>
>>>>I'm going to continue to recommend that approach because I think
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>general
>>>
>>>
>>>
>>>
>>>
>>>
>>>>boxcarring as outlined in (ii) [BTP boxcarring in a context reply] is
>>>>
>>>>
>
>
>
>>>>something that the runtime infrastructure will take care of.
>>>>However, that still leaves open the
>>>>issue of what is meant by "context" in the provided text. Is is a) a
>>>>WS-Context as I original indicated, or is it b) the specific
>>>>addParticipant messages, i.e., a very specific form of boxcarring for
>>>>
>>>>
>
>
>
>>>>this very specific problem? As I've already said, I prefer the
>>>>conceptual model of contextualising all of the one-way messages, so
>>>>
>>>>
>a)
>
>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>probably edges out b) for me, but at the moment I can't think of any
>>>>technical reasons for one over the other. I think how the information
>>>>
>>>>
>
>
>
>>>>is conveyed is less important than agreeing to convey that
>>>>
>>>>
>information
>
>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>in the first place.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>I summarize this as:
>>>
>>>Approach i) [Nothing to do with OTS, original Mark proposed text]
>>>
>>>= have a context response and put a number of enlistment elements
>>>
>>>
>>>
>>>
>>within
>>
>>
>>
>>
>>>it.
>>>
>>>Approach ii) [BTP]
>>>
>>>= put a number of enlistment elements within a wrapper, and then
>>>optionally carry that freestanding or grouped with a context reply.
>>>
>>>Approach iii) [Mark musing on an alternative]
>>>
>>>= "have addParticipant (enlistments) messages in a vector".
>>>
>>>On iii) How, where? As free-standing header elements (which implies
>>>
>>>
>>>
>>>
>>they
>>
>>
>>
>>
>>>must run alongside application messages (which is not required)? As
>>>children of an element specifically for bundling WS-CAF protocol
>>>messages -- exactly what <btp:messages/> does in BTP? This would allow
>>>transmission alone or piggybacked as a header element on an app
>>>
>>>
>>>
>>>
>>message.
>>
>>
>>
>>
>>>This leads to a wrapper, and thence straight to approach ii), as in
>>>
>>>
>>>
>>>
>>BTP.
>>
>>
>>
>>
>>>I think it would be brain-bending to use the context itself as such a
>>>wrapper, but someone might come up with that suggestion.
>>>
>>>[Incidentally I cannot see why one would restrain oneself from using
>>>
>>>
>>>
>>>
>>the
>>
>>
>>
>>
>>>technique in i) as a technique for *any* bundle of messages. And I
>>>
>>>
>also
>
>
>>>cannot see why you would hold back from allowing a wrapper to contain
>>>anything CAFish.]
>>>
>>>I simply do not understand what "contextualizing all the one-way
>>>messages" has to do with this. The one-way messages of the application
>>>must *all* be contextualized, even if they have no need? What if the
>>>protocol semantics have nothing to do with app messages and are
>>>out-of-band to the app? The one-way messages of the protocol(s) must
>>>
>>>
>>>
>>>
>>all
>>
>>
>>
>>
>>>be contextualized? What would that mean?
>>>
>>>7. WS-CF and transactions: how do they interrelate in this area?
>>>
>>>Finally, to pull it all together -- WS-CF needs boxcarring to allow
>>>vectorized tree-building or graph-painting. WS-TXM (and it won't just
>>>
>>>
>>>
>>>
>>be
>>
>>
>>
>>
>>>WS-Acid, which raises the need for a general TXM level protocol),
>>>
>>>
>needs
>
>
>>>to have a way of saying "checked, enrolments done".
>>>
>>>They may or may not be combined in a single message, but they are
>>>semantically distinct.
>>>
>>>If they are combined then they need a bucket to travel in together. An
>>>augmented context can be used as the bucket. It needs to have an
>>>extension element for checked that belongs to WS-TXM (and undefined
>>>message in the current spec). It needs to be able to contain multiple
>>>addParticipants for WS-CF.
>>>
>>>But a context is not usually thought of as a body element, and it is
>>>unclear why context is being used just as a bucket, aka a wrapper. And
>>>it is unclear why the checked message should have to travel with an
>>>
>>>
>app
>
>
>>>message, as a header etc. And it is unclear why addParticipants should
>>>have to travel in something called a context to achieve multiple
>>>registrations in one go.
>>>
>>>This points to a WS-CAF bucket for multiple messages, that can be used
>>>as a header element, as a body element, as an extension element of
>>>context if need be etc. This is what BTP does. It works. It addresses
>>>all use-cases.
>>>
>>>8. Checking can also be achieved by counting of identified enrolled
>>>inferiors. This can be dealt with separately, but it should not be
>>>forgotten. It is a WS-TXM-general need, not specific to WS-Acid.
>>>
>>>* * *
>>>
>>>This entire discussion begs the question: why are we trying to
>>>
>>>
>reinvent
>
>
>>>the wheel of BTP in these areas? I venture to suggest that the same
>>>unavoidable question will plague most other discussions as we proceed
>>>with WS-TXM. This is exactly what I meant by "needless variation".
>>>
>>>We would perhaps do ourselves and the wider audience a favour if we
>>>frankly set out to copy BTP as faithfully and as literally as makes
>>>sense given the layering of WS-Context and WS-CF. That way we would
>>>
>>>
>end
>
>
>>>up with a workable and proven solution of equal power, in a short
>>>
>>>
>space
>
>
>>>of time, on this issue, and on many others.
>>>
>>>Alastair
>>>
>>>
>>>
>>>Alastair J. Green
>>>CEO and CTO
>>>Choreology Ltd
>>>68 Lombard Street
>>>London EC3V 9LJ
>>>www.choreology.com
>>>
>>>+44 870 739 0050
>>>+44 870 739 0051 (fax)
>>>+44 795 841 2107 (mobile)
>>>
>>>
>>>-----Original Message-----
>>>From: Greg Pavlik [mailto:greg.pavlik@oracle.com]
>>>Sent: 19 July 2005 18:44
>>>To: Mark Little
>>>Cc: ws-caf
>>>Subject: Re: [ws-caf] ACTION for optimization of registration
>>>
>>>Mark Little wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Conscious of the telecon today, I'd like to keep this rolling.
>>>>
>>>>I think the original issue of optimizing registration calls should be
>>>>
>>>>
>
>
>
>>>>orthogonal to checked transactions. As was discussed at the f2f, this
>>>>
>>>>
>
>
>
>>>>issue is only concerned with reducing the number of cross-domain
>>>>registration calls. With that in mind ...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>yes, I agree. This has been the one problem point in the discussion so
>>>
>>>
>
>
>
>>>far. To clarify my early statement on WS-CF: I'm in favor of
>>>
>>>
>optimizing
>
>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>>registration at that level but not in adding any additional semantic
>>>implications: my view is that CF provides the building blocks for
>>>organizing the participant graph but nothing more.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>Actually I think that we have two different ways of approaching the
>>>>>same problem.
>>>>>
>>>>>
>>>>>
>>>>>Pros and cons both ways.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>We have to make a choice. Fairly obviously, there's an implied (iii)
>>>>in the above, which is "do nothing", i.e., drop the issue. Assuming
>>>>
>>>>
>we
>
>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>don't want to go that route just yet (afterall, we're still in the
>>>>discussion phase), let's return to the original text which I had the
>>>>AI for generating:
>>>>
>>>>"A service that receives a transaction context on an application
>>>>request SHOULD enlist participants with the corresponding activity
>>>>group. The transaction service implementation associated with the
>>>>service MAY decide to use the following protocol to optimize remote
>>>>registration invocations: this optimization MAY occur transparently
>>>>
>>>>
>to
>
>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>the service. Rather than register participants directly, the EPRs of
>>>>the participants (and the protocols they should be enlisted with) are
>>>>
>>>>
>
>
>
>>>>retained by the service-side transaction service component until the
>>>>response to the original invocation is sent; in which case a context
>>>>containing these EPRs and associated data is propagated back with the
>>>>
>>>>
>
>
>
>>>>response.
>>>>
>>>>If a receiver of a response obtains this context it MUST either be
>>>>able to perform the enlistment itself or, if it does not support this
>>>>
>>>>
>
>
>
>>>>optimization, send back a wsacid:CannotOptimizeEnlistment fault code
>>>>message and mark the transaction so that its only outcome is to
>>>>rollback. If enlistment fails then the transaction MUST be rolled
>>>>back; an implementation MAY retry transient registration failures.
>>>>
>>>>If the sender of the response receives an indication that there was a
>>>>
>>>>
>
>
>
>>>>non-recoverable failure (e.g., in delivery of the message or
>>>>registration of the participant EPRs) then it MUST rollback the work
>>>>it has performed in the scope of that transaction. When using this
>>>>optimization, the service MUST still see a wscf:participantAdded
>>>>message in order to be compliant with WS-CF. However, this message
>>>>SHOULD be generated by the service-side transaction component for
>>>>
>>>>
>this
>
>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>optimization to work."
>>>>
>>>>
>>>>Mark.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
--
Mark Little
Chief Architect
Arjuna Technologies Ltd
(www.arjuna.com)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]