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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-tx] Issue 016: WS-C: ReplaceParticipant


Mark,

This is an interesting issue, and dovetails with a couple of questions on the Register/RegisterResponse per se.

The first point is:  we need to make it clear when you have to stop retrying Register. You shouldn't send it if you've received RegisterResponse.

If we make R/RR a standard one-way MEP, which I favour, then we can use the notification/terminal notification nomenclature to state this.

Then we come to your address replacement issue per se.

In BTP we ended up with a message, REDIRECT, which either the Superior (Coordinator) or Inferior (Participant) could send to the other, saying: this is entity Foo, please send my messages to this new address. To do this one needs an identity, so one can say: "I am Foo". If you have a Coordinator identifier and a Participant identifier, then this is easy.

However, I think we already have this (bidirectional) feature in the WS-AT and WS-BA protocols in another form, albeit somewhat tucked away.

In Section 9 on use of WS-A Headers, it is stated that a non-terminal notification has to have a reply-to address. I presume (there is no statement on this, and that needs fixing, for sure) that this field only makes sense if I am trying to redirect subsequent traffic. In other words, I send a standard message but qualify it with the added semantic: "I've moved". If the receivers sees this, I assume they should overwrite the old EPR they have, and continue as normal.

Such an address replacement means that redirection is accomplished as a by-product of recovery-driven replay of messages, or because the load balancer has done a reshuffle -- it doesn't really matter why.

This is neat, because it avoids having to communicate identifiers for redirection (they are still needed for the original register as per other discussions).

Therefore, I believe that this issue could be resolved by supplementing and expanding the  WS-Coord  spec's statements on  MEPs, types of messages etc, with a statement that a non-terminal notification reply-to should supplant the previously held EPR for the next and subsequent messages in the conversation, and we're done.

It is probably obvious, but I see no very good reason why redirection (address replacement) should be limited to the Participant end.

Alastair


Peter Furniss wrote:
This is hereby identified as ws-tx issue 016

Please follow up to this message or otherwise ensure your subject line
starts "Issue 016 - " 
	(after any Re:, [ws-tx] etc)


Issue name -- WS-C: ReplaceParticipant

Owner: Mark Little [mailto:mark.little@jboss.com]

Target document and draft:

Protocol:  Coord

Artifact:  spec / schema

Draft:

Coord spec working draft uploaded 2005-12-02

Link to the document referenced:

http://www.oasis-open.org/committees/download.php/15738/WS-Coordination-
2005-11-22.pdf 


Issue Type

Design

Issue Details

In order to coordinate long running interactions, it is necessary to 
tolerate failures and recovery situations within the scope of an 
activity (long running activity). Once a participant is registered with 
a coordinator,  the current specification implicitly mandates that 
recovery requires it to come back up on the same EPR in order that the 
coordinator can subsequently drive it through whatever protocol is used 
(e.g., 2PC). However, recovery on the same EPR cannot be guaranteed and 
is at best an implementation choice. Failure to recover on the same EPR 
will ultimately lead to more coordinated activities terminating in a 
failure state (e.g., aborting) because participants cannot be reached, 
even if they failed and recovered prior to the start of execution of the

coordinator's protocol.

Proposed Resolution:

That we add a ReplaceParticipant operation that allows a registering 
service to instruct the coordinator service to replace one EPR with 
another EPR. Because EPRs are not currently comparable, a resolution of 
issue 7 or 14 is relevant to this issue.



  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]