Tom Rutt wrote:
comments
inline
Sunil Kunisetty wrote:
Tom Rutt wrote:
The reason to send both is that one is
targeted to the sending RMP the other is targeted to the consumer.
It does not hurt to send both in this case.
I think it hurts. I'm a big proponent of not sending information when
not needed,. I believe in
not sending unnecessary and duplicate information as it will cause
confusion, mutual conflict,
unnecessary bandwidth etc.
Specifically the problems I see in this case are:
i) The duplicate message may either be triggered by the RMP itself or
accidentally by the
application itself. Most likely by the former because of
Guaranteed Delivery. In that case,
RMP itself is the consumer, so sending separate faults doesn't
make much sense.
duplicate invocation is not an rm fault, it gets acked for an rm reply.
I was referring to the SOAP Fault based on the *current* proposal.
But that's not the main
point here. My main point is: Are they any
cases where we need to send both RM and
SOAP Faults?
ii) Just saying "send a SOAP Fault" is very
bad for a spec. as it is not interoperable.
We need to be very specific about the Fault information to be
sent. Is it Client/Sender or
Server/Receiver or what sub-code etc.?
we used to say that it is a client soap fault if it is message formatn
category,
a server soap fault if it is message processing
Perhaps that text went away in Jacques. edits? It should be there
iii) In most cases, the Sending RMP will
formulate a Fault/Exception to the Consumer if
required based on the RM fault itself. A combination of RM Fault
and SOAP Fault
could be problematic in such cases as they could conflict.
Well we do not have a body to send back since we did not delivery the
message, so the
sending rmp does not know what to put in the soap body. Are you
proposing that for response reply
pattern we send empty soap body with rm reply header?
Tom Rutt
Sunil Kunisetty wrote:
Tom Rutt wrote:
whenever the request causes any
rm-fault, it cannot be delivered to the consumer. All RM faults
have this property that for response reply pattern no response payload
is avialable, unless
the sending RMP caches prior responses.
In this case, we will be semding a SOAP Envelope with one Header (that
has the RM Fault) and
with no SOAP Body.
The specific qn. I've is in what cases, we need to send BOTH SOAP Fault
and a RM Fault?
I can't think of any.
Tom Rutt
Sunil Kunisetty wrote:
Tom Rutt wrote:
This section is about rm faults.
Ok. if it is not about DE and generic Faults, what is the chance
that BOTH RM Fault and SOAP Fault
need to be sent. I can't think of any cases myself.
Even if there are few chances, since it is not for all cases, we have
to say "*the underlying protocol
response MUST contain a SOAP Fault (in the SOAP Body)_ if exists one
_ in addition to the
appropriate RM Fault (in the SOAP Header).".
*
The clarification about duplicate
elilmination needs to go in section 4, where duplicate elimination
element is defined.
There we have three options, which are up for debate:
1) allow the receiving rmp to cache the earlier response and send it
with the ack for the duplicate incoke
2) allow the receiving rmo to send nothing in the soap body. Since the
sending RMP was responsible for the second invoke, it can filter out
the second ack with the empty body. It will not deliver it to the
sender. There is a small case where the original response is lost, in
which case the sender does not get the response. This would be
the case with sending a soap fault as well.
3) send a soap fault with tha duplicat ack. This bothers some, since
it is not a fault condition, and the
sending rmp can filter out the second ack and not deliver it.
Tom Rutt
Sunil Kunisetty wrote:
