ebxml-msg — archive

RE: FW: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

From: System
To: [email protected]
Date: Mon, 24 Sep 2001 12:05:00 -0000

On the contrary, it is attempting to do the intermediary function within the messaging service that is pushing function down into it that doesn't belong there. That's what an awful lot of the discussion has been about. We don't even have a definition of how two MSHs can work back to back without some function in between them. Regards, Marty "David Fischer" <[email protected]> on 09/21/2001 07:09:18 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: <[email protected]>, "ebXML Msg" <[email protected]> Subject: RE: FW: T2, Proposed solution for ... Re: SyncReply and ReliableMessagingMethod in QualityOfServiceInfo 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.