Re: NEW ISSUE: Handling arbitrary sets of associated endpoints

Rich Salz wrote:

> After a client or service receives a fault, is it reasonable to expect 
> it won't get any more messages in this MEP?
>
>     /r$
>
I'm not quite sure how best to answer this.

Much of the point here is to get away from MEPs per se and make sure 
that we can support fully asynchronous architectures.  From a MEP point 
of view, the kind of cases I have in mind are probably best seen as a 
series of one-ways:  I send a one-way message, the recipient may in turn 
send further one-way messages to various destinations, these 
destinations may send further messages, and so on.  In that view, there 
is no larger MEP involved than simply sending a one-way message that 
happens to give several destinations for further messages.

To be honest, I mainly included a fault destination to pre-empt a 
solution where [fault endpoint] is overloaded to carry one or the other 
of the further processing destinations.  I could just as well have given 
a case with three "further processing" destinations and no fault, or 
four, or a variable number, or reply, fault and logging destinations, or 
whatever else.  For what it's worth I think even if there were only one 
"further processing" destination, calling it [reply endpoint] would be 
misleading, but I didn't mention such a case as, technically, it's still 
covered by the existing framework.

 From this point of view, I'm not sure it's particularly relevant 
whether a message sent to the fault destination, or to any other 
destination, would end the choreography.  The main question is, can we 
handle "any other interaction pattern"?  This would include both of the 
alternatives.  I could certainly imagine a sender (a.k.a. client) 
finding out about a fault and then proceeding to send further messages.

Why do you ask?

Received on Friday, 11 March 2005 19:24:25 UTC