ebxml-msg — archive

[System]

David, I don't believe that I am suggesting any change whatsoever. The psuedo-code you cite below is nearly correct. The difference that I see is whether the idempotency check is before the IF you cite or afterwards. If we are going to specify that something along the lines of RetryCount be appended to the MessageId for purposes of performing an idempotency check at an intermediary, then that function needs to be afterwards (part of both 1) and 2) below, each using a different comparison). I think that it needs to be said also that we are not specifying an implementation, but a protocol and specified behaviour. If we were developing an implementation specification, then clearly it would be a very different document. We don't say anything about what software entity actually applies or verifies the digital signature, nor anything about what it might mean. We only specify that if you want to apply one, you do it "this way" so that there can be some chance of interoperability. We don't say whether or not the MSH is actually responsible for the packaging of the messages, we only say how they need to be packaged so as to ensure interoperability. We do impose certain constraints on the RM function, such as the requirement that before the Acknowledgment is sent, the message MUST be persisted and that the receiving software MUST be capable of recovering from a failure such that messages that have not been processed are processed as if there had been no failure. We just don't say anything about *how* this miracle is pulled off by any given implementation. We say nothing about how the "application" interacts with the MSH, nor how an MSH dispatches messages, nor how application software is "bound to" a MSH such that the MSH can dispatch messages to the correct application handler. We provide Service & Action, but we don't necessarily say that dispatching by the MSH is based on Service and Action. The MSH could perform its dispatching of messages based on other content such as CPAId or ConversationId. For that matter, dispatching might be based on nothing other than the fact that the message is an ebXML message (such as might be the case for an intermediary node concerned solely with routing or some other mundane function that is not specific to the business end of the message). As for routing, we don't say how some intermediate node knows or figures out what URL maps to a given PartyId URI or how it knows or determines what transport should be used for the next hop. We are completely silent on the matter as this is clearly not something that needs to be said as far as the protocol and required behaviour is concerned. This is strictly up to an implementer to choose as they see fit. As for the routing application, we (TR&P team) agreed in Tokyo, IIRC, that the actual routing was not a function of the MSH but that there was a "routing" application (which is very different than saying that the application does routing). This decision was an important one as it allowed us to move beyond a sticking point in our discussions when we had to think about intermediary routing as part of the MSH. As I have said before, this doesn't mean that the routing function might not be baked into the same software entity that includes the MSH functionality. It might be just that, but technically, this isn't part of the MSH and to be honest, it also meant that this was not the only possible solution. Cheers, Chris David Fischer wrote: > > We can't put all these functions in the application. We are supposed to support > Transport, Routing and Packaging. > > What you are suggesting is pushing Routing & Packaging into the application?!!! > The application is just supposed to pass parameters and payload(s) to the MSH > where the ebXML-MS headers are built, signed, encrypted and sent. The other end > receives the message, parses the SOAP headers, performs Idempotency (RM), and > then performs an IF: 1) if not the To Party then modify the packaging (Via, > TraceHeaderList) and send to next-hop/end, 2) if the To Party, validate > signatures/encryption and dispatch the payload(s) to the application based upon > Service/Action. Look at figure 6-1. We do Header Parsing & Header Processing. > We do RM. We also do Security Services. What I left out is Error Processing at > each stage of the MSH. > > The IF in the above paragraph was introduced by multi-hop. If no multi-hop then > do 2. Multi-hop does not appear in the figure (and let's NOT put it in). > > What you are suggesting reduces the MSH to just a message send & receive > function. Why bother? You are suggesting a massive change in scope and > functionality from the current specification. > > Regards, > > David Fischer > Drummond Group. > >