RE: [ebxml-msg] Bundling expectations on error conditions

["Pim van der Eijk" <pvde@sonnenglanz.net>]

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:dmoberg@axway.com]
Sent: woensdag 16 september 2009 23:32
To: ebxml-msg@lists.oasis-open.org
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.