OASIS ebXML Messaging Services TC

Re: [ebxml-msg] Issue for your review

  • 1.  Re: [ebxml-msg] Issue for your review

    Posted 10-18-2002 20:44
    Hi Mike, Comments below... > Michael Wang wrote: > Consider this processing. > > After the send's transport reports the data as not delivered can > now check its persistent store to check whether a MSH ack came back > during this time. If it did then carry on. If it did not then start > retrying. After exhausting the number of retries and still no MSH > Ack then the message never went out. That processing sounds to me like the Sender EbXML layer is behaving in the same way whether the 2xx came back or not... (since even if the Transport called back to say 'bad dispatch' the EbXML layer still goes looking for an ebXML Ack as it would have in the case of an 'ok dispatch'). This situation where the EbXML Layer behaves independantly of Transport layer success/failure is my point of view ;-) > I feel the issue is not how the sender is handling the returned messages. > Agreed that it is not possible for the sender to enforce when a message > arrives back at the sender. But the point is the responder side needs > to complete its transport level processing before going ahead and > handle MSH level processing. My thoughts here are that the responder is not able to complete transport level processing until it has gone ahead to handle MSH level processing. Whether a 200 w/ Data or a 202/204 w/o data should be sent back by the transport can't be determined until ebXML chores such as inspecting the CPA, contacting the Party, etc. are done. SignalsAndResponse style SyncReply confuses the issue further with regard to when a sync transport connection should be closed (see lines 1805-1808 in CPPA 2.0 final). > > I think only option (2) would be real-world viable. With this option an > > MSH would be effectively be configured to accept an ebXML Ack before it > > received an HTTP 204 for the original send. In essence this goes to my > > original point as to the unenforcability of inter-layer event timing. > > Again, I am not saying we enforce inter-layer event timing. All I am > saying is that complete one layer of work before you go to the next > layer. I guess it depends on perspective. What you suggest: EbXML Layer: Start Send. Transport Layer: Start Dispatch. Transport Layer: Complete Dispatch. EbXML Layer: Complete Send. Seems to me as though the EbXML Layer work is not treated as completed before you go to the next layer (HTTP)... > Quite right that different transport behaves differently. > My feeling is the separation comes at the point of "dispatched". > This means that some server some where has got the message then > the transport level work is done. > > ... > > Note that "dispatched" does not necessary mean delivered. Some > transport means Yes, e.g. HTTP, some means May Be, e.g. SMTP. > > For the spec if it can define what it means by "dispatched" and > give examples in relation to well know transport protocols such as > HTTP, SMTP, JMS, FTP then these can be used as guides for other > protocols. I guess this is where I get concerned, that the ebXML Messaging spec would have to be pulled into discussing particulars of various transport protocols... > Another option is probabaly closer to what you're saying which is > for the spec to say ignore all transport level status by the sender. > I personally don't like this but even then the responder should > complete transport processing before MSH level processing. Here's another real world problem. Suppose the Responder behaves as you suggest and does not send an async EbXML Ack until the transport layer of the inbound message has wrapped up. So in effect you have this sequence: The Responder sends HTTP 202 and then immediately sends the EbXML Ack over a different DeliveryChannel (possibily different transport protocol). Now let us suppose that the EbXML Ack delivery protocol is faster to send and to unmarshall/process than HTTP. This means that the ebXML Ack would arrive up at the Sender's EbXML Layer before the Sender's HTTP transport was able to confirm to its EbXML Layer that the original message was even sent. Which illustrates that even if you were to mandate the transport/ebXML layer sequence that the Responder must follow, the sequence may still occasionally/randomly appear different to the Requester. That's why I don't think it is safe to mandate that kind of thing. Best Regards, Dave Elliot XML Global Technologies