OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-msg] Issue for your review

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

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

> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC