ebxml-msg — archive

[System]

David, Please see my comments/responses below. Cheers, Chris David Fischer wrote: > > I believe you, but that's not what is in the spec now. Right now the spec just > says that OnceAndOnlyOnce means the message must be sent using a > reliableMessagingMethod that will result in the application or other process at > the To Party receiving the message once and only once (10.2.1). This does not > sound like it must be done using ebXML RM. This says ANY RM method will do. Yes, that's absolutely correct. However, it should also be noted that it is not a requirement that the *same* RM protocol be used end-to-end. The first hop could be ebXML RM, the second MQSeries. The point is that the reliable semantics (what onceandonlyonce means) MUST be applied end-to-end as far as the ebXML MSH nodes are concerned. This does not mean that an unreliable transport cannot be used (such as SMTP) which might involve multiple nodes, because these are below the level with which the MSH is concerned. We provide the ebXML MSH RM protocol between adjacent nodes to provide for a means of enabling a reliable exchange between the adjacent ebXML MSH nodes over an unreliable transport such as HTTP, SMTP or orange jiuce cans and string. If two adjacent ebXML MSH nodes use MQSeries between them, then there is no need of anything above and beyond this at the ebXML protocol level because the underlying transport is far more robust and reliable than the ebXML RM protocol might ever think of being (and this is reflected in the cost of the product!) Maybe another view of the previous diagram is in order: IM node ================= | (routing app) | | | | | - - - - - - - - - A[eb] <-> | [eb]B B[MQ] | <-> [MQ]C | (MSH) | ================= This node (within the box) is the intermediary. It can be a single piece of software, with an MSH that has two transport "plugins", one for HTTP and one for MQSeries. It can support the ebXML RM protocol for messages sent over HTTP, and can also support exchange (send/receive) of messages via MQSeries. Regardless, the MSH is responsible for ensuring that the "application" gets all messages that the MSH receives with onceandonlyonce semantics. That means no duplicate messages will be delivered to the "application". While we haven't specified an MSI with the layer of software above the MSH, the MSH MUST be sure that the message is actually delivered to the application. This can be achieved in a number of ways, but the intent is clear. It says so in the specification in section 10. The MSH must persist messages and in the event of a failure, it must be capable of processing messages that have not been processed as if there had been no failure. What that means is that an MSH persists messages on disk upon receipt. If ebXML RM is in play, it responds with an Ack as per the spec. It then dispatches the message to the "application" that is designated to process the message. We don't say what that "application" is. Could be a business application, could be middleware that gets the message to the application, we don't and cannot say. The point is that the MSH has a responsibility to ensure that only one instance of a given message is processed by the "application". This *may* mean that some transactional interface is required between the MSH and the "application". We don't and cannot say. That is strictly up to the implementation vendor IMO. One implementation of the IM above might have a simple URI resolver figure out what URI the To/PartyId resolves to and then forward the message (via the MSH that presented the message to the routing application in the first place) to that next destination. Once the MSH send() call has returned, the "routing application" returns control to the MSH thread that passed it the message to be processed which indicates that the message was safely and successfully "delivered" to the application. You could also do it with two-phase commit and a distributed set of components. My point is that we cannot dictate an implementation, we are only chartered with defining a wire protocol and required behaviour around that protocol. > > What would it take to make the spec fit your drawing (which would also eliminate > the issue about unreliable nodes)? At the very least we would have to eliminate > the reliableMessagingMethod attribute. We would also have to specify somewhere > that if ebXML RM is not supported then send back an error (DFN). I think that the spec already says this. Maybe it needs to be clearer, but that is what we meant. > > Is this what we want to do? > > David Fischer > Drummond Group. > >