Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

[Alastair Green <alastair.green@choreology.com>]

Which begs the anterior question: why have two MEPs at all? See that issue.

Not clear what the virtue is. Why are we struggling to maintain 
request-reply MEP for R/RR? It is exactly the same kind of retriable 
exchange as Prepare/Prepared etc.

I think there is an appetite to make WS-A do more than it was designed for.

Alastair

Mark Little wrote:
> Kevin Conner wrote:
>
>
>>> Doug Davis wrote:
>>>
>>  
>>
>>>>> Mark,
>>>>>   If I'm remembering correctly the retries didn't require the 
>>>>> wsa:messageID to be
>>>>> the same each time.  The duplicate detection was done at the tx 
>>>>> protocol level
>>>>> not at the WSA level - meaning the protocol knew how to deal with 
>>>>> multiple
>>>>> Prepare messages - not multiple messages with the same msgID.  
>>>>> Those are
>>>>> two very different things.
>>>>> thanks
>>>>> -Doug
>>>   
>>>
>>>
>>> The MEP in this case is different and the request/response messages 
>>> do not relate to each other at the transport level, solely at the 
>>> protocol level.  The only replay a transport could reasonably do 
>>> (hence using the same MessageID) would be when it had not received a 
>>> delivery acknowledgement from the other endpoint (e.g. HTTP 200 or 
>>> 202 response code).  Any other decision to resend the request is 
>>> taken at a higher level and would constitute a new message.
>>>
>>> The request/response MEP, however, can relate the request to the 
>>> response at the transport level.  The transport would therefore be 
>>> capable of replaying the request until it receives the appropriate 
>>> response.
>>>
>>  
>>
> +1
>
> In the one-way case, retries have to be dealt with at the service 
> level and MAY constitute a new message. In the request-response case, 
> retries SHOULD be dealt with at the transport level.
>
> Mark.
>
>
>
>