Sander:
Agree - we can't set the bar lower than what ebMS2
provides.
But changing the Ack semantics on intermediaries as you
suggest, is still a more significant change in RM behavior than it appears at
first - introducing a more complex processing of Acks and greater risk of
loosing these.
I have the feel that all this Ack relaying would seriously
hurt robustness.
I wouldn't either go down the road of replicating RM at
ebMS layer - this would also have the serious inconvenience of requiring more
than core V3 from the ultimate receiving MSH.
Instead of 2-tier reliability as previously defined, I
would then look again at how to do end-to-end RM (no RM at
intermediaries).
2 options:
(a)- use WS-Reliability which does not make use of extra
signal messages to care about for routing.
(b)- use WS-ReliableMessaging, and
resolve the routing problem for RM lifecycle messages
(CreateSequence...).
I would then look again at the option of a serious
profiling of the use of WS-RM - e.g. piggybacking "dummy" ebMS headers (with
dummy service/action).
"Flat" End-to-end RM (with only the two endpoints being RM
enabled), still requires the following: the sender must know what are the
messages that share the same RM destination, so that these can be sent over the
same RM sequence. That seems reasonable - e.g. a message partition channel would
be created for each one of these end-to-end paths, and would map to its own RM
sequence. In other words, even if the initial sender does not know
what the ultimate destination URL of its messages are, it must know what are the
header fields that control the routing, so that it can control the RM sequence
creation and usage for messages intended to the same
destination.
Jacques
Jacques,
I think that a 2-tiered solution should be able to realise the QoS
contracts between endpoint as specified in the core spec. If it can not, we will
loose, in my opinion important functionality in the multi-hop situation over the
end-to-end situation. Also in a current multi-hop situation based on ebMS V2.0
we can realise RM end-to-end, so we might even end up with less functionality
than in the current situation.
Providing these levels of QoS however will require special functionality to
be implemented in a MSH component above the RMP. And that functionality will be
(almost) a duplicate of the RMP's one, so one could question the need for an RMP
if RM is already taken care of in the layers above. A reason to still use RM on
each or some legs of the path could be to secure transport over unreliable
legs.
Therefor I thought about using the special RM behavior on the
intermediaries. I know this might not be the way WS-RM spec expects things to
happen. But I assume that the intermediaries are the special cases. So it might
be less important that we require special behavior of them. This way for the
endpoints the first and last intermediaries look to be the other endpoint and
nothing has to be changed to the endpoints.
Regards,
Sander
On Dec 7, 2007, at 5:40 , Durand, Jacques R. wrote:
inline:
My remarks as just made on the call:
* Why use RM on each leg of the route? I don't see any advantage because
a =
missing ebMS ACK will lead to a re-send of the message on the ebMS
level. (=
Assuming a At-Least-Once contract). At the moment I don't see
what the RM o=
n each leg gives us.
<JD> In my opinion, the ebMS synchronization signals cannot be
expected to provide the same level of QoS as protocol-level RM. I would not
for instance expect a synchronization exchange - back and forth - to occur for
each message sent, or at every second, as the overhead of processing these is
quite significant, certainly higher than sequence-based RM signals. I would
not expect either to implement duplicate check at ebMS level (that would put a
significant burden on endpoint MSHs that lets not forget, should ideally not
need implement more than core V3 features), and rely instead on the one in RM
(meaning indeed that with per-segment RM, if a duplicate is generated during
the transfer through an intermediary, we wouldn't detect it). But at least
using segment-level RM provides some RM QoS, that would take care of 50% of
message losses/duplication. The only "end-to-end" feature that 2-tier
reliability (as previously defined) provides, is message loss awareness and
possible remedy. But the more of these losses are taken care of in
protocl-level RM, the better.
There is
no question that 2-tier reliability as defined here is not as good as
"flat" end-to-end RM at protocol level.
* If considering
special reliability behavior on the intermediaries as is t=
he case with
the last one in the 2-tiered solution described by Jacques, co=
uld it be
possible to use WS-RM on each leg with the ACK on the current
leg=
postponed till the the intermediary receives an ACK on the next leg? I
did=
n't have time to look into, just an idea.
<JD> we wish that were possible, but this Ack semantics is not
the one specified in WS-RM. It is very unlikely that RM built-in available
SOAP stacks will allow this...
Regards
Sander
Fieten
On Dec 5, 2007, at 3:16 , Durand, Jacques R. wrote:
So we could call this option (already alluded to by
Ian in a previous
call in November) the 2-tiered reliability, the main
advantage of which
is that it does not require to route anything other
than ebMS messages:
Level 1: WS-RM/R only needs be used between pairs
of MSHs (so each path
segment is "independently reliable"), in other
words the reliability
headers are changing across an intermediary, but
not the ebMS header.
Level 2: additional ebMS signals allow for
end-to-end doublecheck, by
synchronizing the status on both sides. E.g.
sender will periodically
notify a list of "should-have-received"
ebMS IDs to receiver, and a
symmetric synchronization signal sent
by receiver MSH, would notify of
what has NOT been received/delivered. Or
conversely the receiver will
notify a list of "have-received". Remedial
action need not be prescribed
(P-Mode will control) - could range
from just notifying the application
layer on either/both sender or
receiver side, to re-issuing the missing
messages (from the ebMS layer,
in order to avoid creating RM-level
duplicates that could be eliminated
at next RM endpoint).
Some interesting aspects about this
solution:
- the status synchronization is a useful feature in itself as
we seem to
agree (awareness of loss by a receiver MSH allows better
diagnostics on
failed choreographies, etc).
- the ultimate receiving
MSH may not have to support this feature in
order to have end-to-end
reliability: the last intermediary has to.
Indeed, when getting the
"should-have-received" signal, the intermediary
could be required to
respond with only those messageIDs that it has
actually successfully
forwarded, removing the last possibility of
"intermediary loss". E.g. it
could be required to get the RM Ack of
ultimate receiver, before even
sending the "have-received" signal. SO
that mode of reliability does not
require an ultimate MSH to support
more than core V3 features. This is
becoming in the CDC network case,
where MSH hubs serve clusters of
endpoint MSHs. Even if last MSH is not
supporting RM, this enables
"end-to-previous-to-end" reliability !
I am starting to like
it.
So there seems to be two general modes of reliable ebMS
multi-hop:
(1) The "flat reliability" mode, supported end-to-end by
the RM layer.
Here, only the use of WS-Reliability really makes sense, as
the routing
is supposed to be controlled by ebMS header info, even for
establishing
RM sequences.
(2) two-tier reliability, where the RM
mechanism from WS protocol is
only used per segment. Here both
WS-Reliability and WS-ReliableMessaging
can be used between MSH
pairs.
Jacques
Original Message-----
From:
David RR Webber (XML) [mailto:david@drrw.info]
Sent:
Wednesday, November 28, 2007 6:46 AM
To: Durand, Jacques R.
Cc: Pim
van der Eijk; ebxml-msg@lists.oasis-open.org;
Moberg Dale
Subject: RE: [ebxml-msg] Pim on routing
intermediaries,
WS-ReliableMessaging
Jacques,
Yes - I think
the ability to do status checks definately beckons
eventually.
I
like what you suggest - good lightweight logical next step.
During
the BCM work and then ebBP - we identified the need in
extended
collaborations to have a "linking and switching" status
tracking
service.
This is way more than what's needed for message
delivery of course - but
then again - the types of mechanisms could
definately be interchangeable
/ reusable here.
Since right now
each ebBP / ebMS is responsible for its own status
tracking - the obvious
next logic step is to provide centralized status
checking services.
We've explored this model in BCM - the linking and
switching
Appendix B spec' - which uses the Prolog assertion/retraction
predicate
based approach.
At some point we will need to get serious about
enabling that all -
would be a very cool facility - incredibly useful for
all kinds of
applications...
; -)
Cheers, DW
Original Message --------
Subject: RE: [ebxml-msg] Pim on routing
intermediaries,
WS-ReliableMessaging
From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
Date: Wed, November 28, 2007 9:06
am
To: "David RR Webber (XML)" <david@drrw.info>, "Moberg
Dale"
<dmoberg@axway.com>
Cc: "Pim van der Eijk" <pvde@sonnenglanz.net>,
<ebxml-msg@lists.oasis-open.org>
David:
That sounds like re-implementing reliability at
ebMS level - something
I'd prefer to avoid until all other options fail
to deliver :-)...
Besides guaranteed delivery there is also
duplicate detection (based
on sequence numbers or so for the 2 RM specs), so
the redundancy is
starting to build-up.
Now, we may consider a mode of multi-hop
reliability where RM is
per-segment, and in order to catch the cases of
loss during router
forward, a kind of (ebMS) status request where the
initial sender MSH
could notify the ultimate receiver MSH of the list
of message IDs it
is supposed to have received over the last hour or
so, and the
receiver MSH would notify back on what it has not
been able to
deliver. Re-sending by the ebMS layer itself may
or may not be
mandated - could be left to a re-submit at
application level (if no
risk of duplicates). At least that would add
awareness of both sender
and receiver of message loss
(i.e.
non-delivery), something we do not have today
especially with WS-RM.
This awareness by the receiver would in turn allow
the choreography
layer to better diagnose failures.
Jacques
Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Monday, November 19, 2007 6:42
PM
To: Moberg Dale
Cc: Pim van der Eijk; Durand, Jacques R.;
ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Pim on routing
intermediaries,
WS-ReliableMessaging
Dale,
I'm not sold on WS-Reliable messaging - for
starters its merely trying
to mimick what ebMS already has for the past five
years!
Then - who knows what oversights they've made in
the rush to get
something in place. Reading their design and such
does not give me
great confidence. My sense is we are well ahead of
them - and they
should be adopting ebMS reliable messaging (and
actually they are
trying to clone most of it!!!) Of people
using WS the majority could
not careless about reliable delivery - in fact
their whole modus
operandi is built assuming unreliable messaging
and instant traffic
exchanges (query/response).
OK - so where does that leave us?
Why can we not look at some kind of orchestration
agent here? Seems
to me that what is needed is a very simple
component that is tasked
with plugging the gap and acting as an ebMS/SOAP
delivery extension
agent.
All it has to be able to do is manage SOAP-based
exchanges at the
basic transport level. If its built very
dumb and simple - it just
acts as a relay and a pass through - with minimal
logic - mostly just
leveraging SOAP acks and errors
themselves.
The ebMS then interacts with one or more of these
SOAP relay agents -
and will keep trying delivery until it gets an
end-to-end SOAP
acknowledgement relayed back to it.
The agent could be designed to use basic WS - and
in fact then any
SOAP server could be integrated as a delivery
service with the simple
addition of the agent component. This seems
much more like what we
want. Coopting delivery via SOAP
servers.
DW
"The way to be is to do" - Confucius (551-472
B.C.)
Original Message
--------
Subject: [ebxml-msg] Pim on routing
intermediaries,
WS-ReliableMessaging
From: "Moberg Dale" <dmoberg@axway.com>
Date: Mon, November 19, 2007 3:32
pm
To: "Pim van der Eijk" <pvde@sonnenglanz.net>,
"Durand, Jacques
R."
<JDurand@us.fujitsu.com>,
<ebxml-msg@lists.oasis-open.org>
[Pim explained the conflict between
WS-ReliableMessaging and the
advantages in using routing
intermediaries.]
The main options for dealing with the conflict
are
0. Use WS-Addressing anonymous for reply-to and
acks-to, and have
all intermediaries wait before their HTTP reply
is made.
[The above does not scale well, is brittle, and
utilizes lots of
resources.]
1. Use piggybacking (and presumably 1 message
long sequences?).
[Still lacks routing advantages. RMSes have to
target RMDs, and so
have high lifecycle configurability burdens.
Routing intermediary
topology cannot be changed while leaving RMS
configuration
unchanged.
Probably destroys advantages of ebMS routing
intermediary, as Pim
explained.]
2. Locate RMD at routing intermediary, and check
security at
intermediary also.
[ Loss of end to end
reliability.]
Pim has convincingly explained how
WS-ReliableMessaging is not very
intermediary friendly and, along with Jacques,
reflects a step
backwards in trying to accommodate
intermediaries with end-to-end
acknowledgments.
However, the goal of WS-* technology level
convergence seems to
require that we support WS-ReliableMessaging
because it is the WS-I
sanctioned solution.
Is option 2 above an option that could be
embellished to be
satisfactory? What would it take? Add on an
ebBP/RN style
ReceiptAcknowledgment or
ReceiptAcknowledgmentException (if we
wanted to be optimistic with respect to
WS-ReliableMessaging
terminated at intermediary working most of the
time?)
Just some reactions. Good analysis
Pim!
--------------------------------------------------------------------
- To unsubscribe from this mail list, you must
leave the OASIS TC
that generates this mail. You may a link
to this group and all your
TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p
hp
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC
that
generates this mail. You may a link to this group and all your
TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php