Martin Chapman wrote:
well i think ws-n should define boxcar messages
as being delivered atomically, otherwise we have to define our own
dissasembly/reassembly mechanism and I for one don't want to go there!
I agree on "don't go there", especially at this stage of the game. At
this point we probably just note and go on.
I would hope that with both boxcarring and polling we migrate from
home-grown solutions (i.e., pull points and boxcarring in Notify) to
more general solutions. As I understand it, WS-Polling has
notification in mind. Last time I looked at it, it only allowed
messages to be pulled out one at a time, but if it could be composed
with boxcarring ...
Martin.
Martin Chapman wrote:
Boxcarring means that notify messages are bundled in a single soap
message. ws-rx works at the soap level so it doesn’t need to know about
boxcarring of notify messages.
Right. So it looks not to be the tool I'd need if I wanted each
notification to have its own delivery status.
The question is not so much what WS-RX does, but what semantics should we
define. In particular, are we producing and delivering SOAP envelopes
or notifications? Naturally, I lean toward the latter.
FWIW, I'm more and more convinced that there should be some
sort of SOAP-level boxcarring standard that allows multiple SOAP
envelopes to be sent transparently in a single wrapper (most likely
itself a SOAP envelope). This should be able to compose with the other
WS-*, so that it would be possible to acknowledge individual messages
that happened to travel in the same wrapper (or authorize/authenticate
each separately, or re-route them to different places, or whatever).
Martin.
-----Original Message-----
From: David Hull [mailto:dmh@tibco.com]
Sent: Wednesday, January 04, 2006 10:32 PM
To: wsn@lists.oasis-open.org
Subject: [wsn] Boxcarring and reliability
Following the example of the reliability specs, we distinguish
between producing and delivering. If we boxcar a set of
Notifications in a Notify message, are they required to be
delivered atomically? IMHO, boxcarring is a transport-level
optimization and atomicity should be handled separately (it
should be possible to handle a set of messages atomically even
if they happen to be transmitted in different SOAP envelopes).
Ideally, each of the boxcarred messages would have its own
delivery status. E.g., I am able to process the first five of
ten boxcarred messages and acknowledge them, and then my
process crashes or the network goes down. To accomplish this,
though, the reliability layer would have to know about the
boxcarring. This argues for handling boxcarring outside WSN
(WS-Boxcarring, anyone? WS-Polling is already underway ...)
Thoughts?
|