Bundling concerns, continued.

There are several design principles and conventions at work in our current approach to bundling that don’t quite hang together cleanly -- or so it seems to me. Let me describe some of the major ideas and then discuss some of the tensions in getting them to work together.

Modularity: Each user message should behave in a bundle just as it would by being sent on its own.

MSHDiscretion: A MSH should be free to be statically or dynamically configured to send messages in a bundle or individually.

RootConvention: The P-Mode of the SOAP body user message (href attribute omitted in PartInfo) is primary.

SingleSignature: When a signed message is indicated by the P-Mode of the Root the signature must cover all user messages.

OneSharedReliabilityId (sequence number in WS-RX)

Tensions in Modularity Root Convention, and Single Signature

Suppose one non-root body part has a P-mode with enveloped encryption. The assembly of parts is to proceed as it would for individually sent messages even when in a bundle. But the P-mode of the root is signed only. Should the non-root part be encrypted and then signed? Or should encryption be omitted and the receiving end indicate a Value-Inconsistent error? Or when bundled should each non-root part be processed by ignoring the defined P-mode for this user message?

On the face of it Modularity can easily conflict with RootConvention when SingleSignature is operative. In fact whenever the root P-mode conflicts with a P-mode of a non-root user-message part, then the normal message receiver-side error checks must be disengaged. Likewise I think during sender message assembly, the access to the P-mode associated with the user message’s AgreementRef will need to be overridden. This is a lot of special coding and almost amounts to a new mode of operation.

So I agree with Sander that it might be better to restrict user message bundling to messages with the “same” P-mode, assuming we can explain what that means. I doubt that this constraint will be sufficient to solve all the tensions, however.

Tensions in MSHDiscretion and OneSharedReliabilityId

Here is a case I was struggling with describing today. Supposedly the MSH can “just decide” to bundle messages together. And if the bundle does not work for some reason (errors come back about message parts) it could decide to “back off” and send messages separately. In the case of a signature failure, I think we agree that it might be reasonable to see whether each part could be sent individually. Presumably this makes sense because no part “should” be delivered, given that we have SingleSignature. Sending each part individually would at least be preferable to sending the same bundle again. This is because the message processing failed before the bundle was acked, and so retrying the same bundle with its security defect could go into an endless loop of retries as long as acks might not be sent.

Now suppose for a different bundle that its security checks out, and reliability is processed, and we arrive at the separate message parts. Resending the whole bundle would probably just be acked as a duplicate, so that will not be an option for a transparent recovery. So if we do get error messages, should we trust that the parts for which we did not receive an error message were ok and delivered? What if (some of ) the error messages get lost? Or to be on the safe side should we send all the parts again, individually, adhering to MSHDiscretion and the hope that a more determinate outcome of errors and/or acks comes back? If our received error messages were infallible indicators of exactly what went wrong, then we might try to send each payload with an error and see whether that remedies the error message. Otherwise, we retry all the body parts separately. The problem here is that if some of the parts had been ok and had been delivered optimistically, then retrying individually will get duplicates delivered. And that violates our modularity assumption because when each part has its own reliability id value, duplicates would be eliminated. It could be that we just give up and do nothing about these ebMS level errors, just logging them. But that would violate modularity too, because in that case, we would not know that any of our parts got delivered successfully as we could with an acked, errorless single message sent individually. Being part of the bundle has made our state alignment a bit foggier in the case of some errors at the ebMS header level. Or so it seems to me.

Let me stop with these two issues, and ask for simplifications that would diminish the interactions threatening Modularity. I think that Sander had a good suggestion to disallow P-modes that were “different” but I would like a cleaner way of stating this requirement. I personally would not mind dropping the single signature idea because that definitely makes sending a message in a bundle different from sending it on its own.

(One security header can have many separate signatures within it, although I need to check WSI BSP to see that they have not profiled that away.)

As far as ebMS level errors go, either we should state that nothing is to be done in response to an error by the sender as part of our specified protocol. Or we might state that each part is sent again individually (but I think this is bad because the receiver will have to support a second layer of duplicate detection by ebMS message id). Or we state that a receiver MAY retry a message with an error received when it was sent in a bundle. My preference is now headed toward saying that the specified protocol does not say what to do when an ebMS error is received for one part of a bundled message. Maybe we even say the same thing about the failed-signature error message when received by the sender.

I do not think that going into the dependency graph direction is going to make this situation simpler or better. I think that we should say that when choosing bundling, that is the mode of transmission, and when it fails, each message payload must be resubmitted by operations (but with a do-not-bundle flag set! )

ebxml-msg message