Hello,
With respect to:
Signature
over each part, errors for each part sent and (during teleconference it was held
that)
No
further specification
given.
That
is, MSH can deliver non-erroneous parts or deliver
nothing.
The intention of the current draft is that there will be just
a single signature, so this situation would never occur. The wording in 3.5.2
does not explicitly state that, so we should change:
This security header
contains ds:Reference
elements for all payload parts, if payload signing is specified,
and any payload parts brought in via secondary message units will be treated in
the same way as parts that came with the primary message unit.
to
This security header
contains a single ds:Signature element containing
multiple ds:Reference
elements for all payload parts, if payload signing is specified,
and any payload parts brought in via secondary message units will be treated in
the same way as parts that came with the primary message unit.
Reliability processing and regular WS-Security processing
are the same for a bundled message as for an message with just a
single message unit. They succeed or fail atomically. Only if both succeed do we
get to the ebMS module that knows about bundling. There we do have
a question about what to do with multiple ebMS errors (errors in the ebMS
module), e.g. one message unit references via AgreementRef an Agreement
that has expired, and the other units have no problems.
The current version of the spec is based on the following assumption
(3.5.1):
For the Producer and Consumer layers, the semantics of
bundling is equivalent to sending and receiving a sequence of distinct
messages
So in this case the correct units would be
delivered, and errors only generated for the incorrect message unit. They are
not all rejected or all accepted.
Air travel analogy: the current proposal treats an MSH
like an airline that operates multiple aircraft and has many passengers.
Passengers book their flights individually, by destination plus some
QoS (e.g. arrive on date X plus or minus one day, or on date Y in the evening,
only on Star Alliance flight not on One World), and only at the airport do you
know what plane you are on and only after boarding do you know what flight who
else is travelling with you. But at least it is a lot cheaper than hiring
a private jet ... Right now bundling decisions are internal to the MSH
only, though configurable by Pmode, to allow an MSH to apply bundling as an
optimization option.
The proposal does not
support a model where you are travelling as a group, want to make sure that you
are all booked on the same flight and that, if there are problems, either you
all go or all stay, and all arrive or (if one of you is denied entry at
destination) all return home. We could enhance the
proposal with a new Boolean processing mode parameter (for the primary unit)
that indicates whether or not all message units must be ebMS validated before
any of them can be delivered. Or perhaps restricted to ConversationId. Or
should we allow delivery of all correct units before the first incorrect
one? This also probably
means that we need to extend the
Submit operation to allow units to be
submitted explictly as bundles.
Suggestions welcome.
Pim
From: Moberg Dale [mailto:]
Sent: woensdag 16 september 2009 23:32
To:
Subject: [ebxml-msg] Bundling
expectations on error conditions
Bundle delivery under selected error
situations.
Reliability in use only, error during unbundling,
bundle as a whole is not acked.
That is, an error during unbundling
should not count as a
reception.
No
delivery to back end should occur of any
part.
Security
in use, with or without
reliability,
One
signature, all parts fail. Error sent, no parts
delivered.
Signature
over each part, errors for each part sent and (during teleconference it was held
that)
No
further specification
given.
That
is, MSH can deliver non-erroneous parts or deliver
nothing.
However, on this last point, Axway instead
thinks that the MSH behavior should conform to the policy that any error means
no part is delivered to the back end. It is OK to ack the message, however. Just
include the security error and the ack, if using back channel (aka
synchronous).
We also think that it must be
explained that a reliability ack just means Received, and not “Processed”
We want it to be possible that the
bundle is received and an ack is sent for it even when errors are encountered
during some MSH processing.
So unbundling here just means
finding (“parsing”) the parts of the bundle.
We think clear expectations
between/among MSHes with a determinant outcome is better here, even though
it results in probably not trying to bundle on the next attempt to exchange the
data that was not successfully sent. Maybe a WS-Policy value can in the future
be added to override this expectation, but wait until endusers need
it.
