MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ebxml-msg] an assessment of the reliability of pulled messages
Title: Re: [ebxml-msg] an assessment of the reliability of pulled messages
Jeff:
Your
Scenario #1 (Non-reliable Pull Request)
is not
realistic as you draft it, because you assume an RMP behavior that is quite
"new" w/r to WS-Reliability spec:
namely, that
the RMP will be able to resend the cached pulled message as a sync response of
an entirely new Pull request.
That would
assume that the RMP has some knowledge of the Pull semantics, and
knows somehow that all "Pulls" for this party ID are equivalent, so
that it can do the resending as a response of any of them.
The other
radical alternative for Non-reliable Pull Request that could
be taken (but which has many problems) can be summarized
as:
"Because it
is a Pull signal, we can redo it (MSH level) as many times as we want, when we
fail to get
a pulled
message. So no need to involve any RMP-level reliability."
Problems
are:
- that only
works if the Pull is idempotent, e.g. you need a flag saying "I want to re-pull
the same message as previous pull"
that
complicates things.
- some
caching is assumed on MSH side so that pulled messages are still available for
resending until they are acknowledged somehow. That seems to require a new
persistence mechansim at MSH level that would not be necessary if we rely just
on RMP presistence.
- that needs
be governed by an MSH-level Ack (which we precisely wanted to avoid
lately).
Trying to use
the "next" Pull as an Ack is very tricky: that assumes a complete serialization
of Pull+response pairs, which I think is very restrictive. We should allow for
implementations sending batches of Pull without waiting for the response between
each. That is quite possible when using concurrently several HTTP
connections, and even over a single HTTP connection
(pipelining).
- unless we
try to avoid situations where the same ebMS message can be successfully pulled
twice (whcih seems hard to guarantee) we'll need to do duplicate elimination at
MSH level (based on ebMS ID).
Jacques