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" <> on 09/21/2001 07:09:18 PM
To:
Martin W Sachs/Watson/IBM@IBMUS
cc:
<>, "ebXML Msg" <>
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.
