Re: [ebxml-msg] Issue for your review

[Michael Wang <mwang@tibco.com>]

Hi Dave,

Please see comments below.

Dave Elliot wrote:
> 
> Hi Mike/all,
> 
> I have read the discussion and at this point my position still remains
> that the messaging spec will have serious trouble if it tries to dictate
> event sequences that interleave between the ebXML and transport layers.
> Please see below for comments...
> 
> > In the case you did send 2xx and it was lost then the sender
> > side should probabaly have a way of handling this - i.e.
> > continuing on and not error.
> 
> The question still remains as to how exactly the sender side should
> handle this scenerio (the 2xx response being lost).  If the messaging
> spec insists that the ebXML layer synchronize timing with the transport
> layer then you have two options in this scenerio:
> 
> (1) The Sender transport layer reports to its ebXML layer that the data
> was _not_ delivered.  When the subsequent ebXML Ack arrives at this
> Sender MSH it is unrecognized/ignored and the Sender remains unaware
> that the original message was already received by the remote party; or,

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.

I think this is as viable as option 2.

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.

When the responder side obey the rule of completing transport level
processing before MSH level processing and that still results in
messages arrives out of sequence at the sender then it is up to the
sender to deal with it.  In this case, option 1 and 2 are both possible
implementation semantics.

> (2) The Sender transport layer reports to its ebXML layer that the data
> was delivered (even though the transport layer is unsure without a 2xx
> response).  When the ebXML Ack comes in the Sender MSH processes it OK
> and the reliable send is considered complete.
> 
> 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.

> Also note that the 'lost 204' scenerio is only one case where the EbXML
> Send - HTTP Send - HTTP 204 - EbXML Receive sequence breaks down.  Even
> plain process multitasking could result in that sequence being violated.
> 
> > The point of clear separation of layers is a good idea.  In fact,
> > that is exactly the intention of HTTP 2xx response before any MSH
> > activities.  In this case, the HTTP response which is a transport
> > layer message must happen before MSH layer processing and messages
> > start to happen.
> 
> People seem to agree that decoupling the layers is a good idea.  Now the
> issue seems to be 'what is the scope of the decoupling'.  I am seeing
> two broad positions:
> 
> (1) Decoupling means that when the ebXML layer hands-off a message down
> to the transport layer it considers it to be sent.  Any reliability
> applied from that point is purely based on the ebXML layer's Reliable
> Messaging Protocol; or,
> 
> (2) Decoupling means that the ebXML layer hands-off a message down to
> the transport layer and awaits a call-back from the transport layer
> before considering it sent.  The ebXML layer is then using it's own
> Reliable Messaging Protocol in addition to specific reliability
> mechanisms built into the particular transport.
> 
> I think position (2) is troublesome, especially in the face of many
> existing and future transport protocols.  There are many transports that
> cannot call back to the ebXML layer with a definite "Yes or No", but
> rather a "Yes, No or Maybe".  This makes the callback relatively
> useless, and in the presence of the ebXML Reliable Messaing Protocol, it
> is effectively redundant anyway.  Given this, are we comfortable
> defining a 'decoupling' of the ebXML and transport layers that
> neccessitates such a call-back (keeping in mind that this call-back is
> required if you wish to enforce the ordering of an inter-layer sequence
> of events) ???

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.

For example, using SMTP a call into the SMTP server to pass the
data and be able to return from the call means the message is dispatched.
It may not have gone out or delivered to the destination but from
the MSH level the message is "dispatched".  This is similar for JMS -
once you return from the call to the server the message is "dispatched".
For HTTP, dispatched means you get a 2xx back.  This is required
by the HTTP trasport.

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.

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.

Regards,
-mw

> 
> Best Regards,
> 
> Dave Elliot
> XML Global Technologies
> 
> > -mw
> >
> > Dave Elliot wrote:
> > >
> > > Christopher,
> > >
> > > Regarding the 2xx HTTP response (202/Accepted, 204/No Response, etc) in
> > > terms of reliable messaging in a SyncReply NONE scenerio.
> > >
> > > Consider this...if the HTTP 2xx response is lost however the receiving
> > > MSH still sends back the async acknowledgment successfully, should the
> > > sending MSH accept that ebXML acknowledgment?
> > >
> > > I would argue that it should.
> > >
> > > I think it is dangerous to declare sequences of events (1, 2, 3) that
> > > switch between boundaries in the ebXML protocol stack.  My impression is
> > > that the ebXML msging stack has an ebXML layer sitting above a transport
> > > layer (the transport layer could conceivably support HTTP, SMTP, FTP,
> > > MQSeries, carrier pigeons, ...).
> > >
> > > It is certainly fair (required) to enforce event sequences at the ebXML
> > > layer (ebxml request sent before ebxml ack received), or to enforce
> > > event sequences at the transport layer (POST sent before 204 received).
> > > However it would be extremely cumbersome to dictate and enforce event
> > > sequences ACROSS layers (ebxml request sent, HTTP post sent, HTTP 202
> > > received, ebxml ack received...rework for every transport protocol
> > > supported ).
> > >
> > > The decoupling that should exist between the ebXML and transport layers
> > > becomes more apparent when you consider other mixtures of transports.
> > > What if the outbound ebXML messages were transport via FTP batch with
> > > async mshSignal acks coming back via SMTP ?
> > >
> > > I certainly agree with the sequence you list as a recommended order of
> > > processing for a receiving MSH, however can we expect/enforce that
> > > sequence in terms of transport protocol and ebXML message timing ???
> > >
> > > Dave Elliot
> > > XML Global Technologies
> > >
> > > On Thu, 2002-10-17 at 08:36, Christopher B Ferris wrote:
> > > > IMO, if you are doing a one-way asynch message pattern over HTTP, with
> > > > asynch
> > > > ack on a separate channel in the reverse direction, then the HTTP response
> > > > for the
> > > > original POST should be a 202 Accepted. That response should be returned
> > > > WITHOUT
> > > > any processing (MSH or application-level) of the message, which is what
> > > > 202 implies.
> > > >
> > > > So, from the receiving end, it would be:
> > > >
> > > > 1) receive message
> > > > 2) send 202 response
> > > > 3) dispatch message to MSH for processing and eventual dispatch to
> > > > application.
> > > >
> > > > Cheers,
> > > >
> > > > Christopher Ferris
> > > > Architect, Emerging e-business Industry Architecture
> > > > email: chrisfer@us.ibm.com
> > > > phone: +1 508 234 3624
> > > >
> > > > Mike Dillon - Drummond Group <mike@drummondgroup.com> wrote on 10/17/2002
> > > > 11:18:00 AM:
> > > >
> > > > > Hi all,
> > > > >
> > > > >  In the current DrummondGroup ebXML Messaging Interop
> > > > >  we have a issue that would be really helpful to have input
> > > > >  from the committee.  This is somewhat subtle but
> > > > >  but thorny problem that we are having in the current
> > > > >  DGI ebXML Messaging interop.
> > > > >
> > > > >  The problem is on an asynchronous message with
> > > > >  acknowledgment.  Some implementations are returning
> > > > >  the ack before the original http response...
> > > > >  In other words, I post a message to you and I'm
> > > > >  waiting for the http reply, I receive the ack
> > > > >  first, then I receive the http reply. This obviously
> > > > >  has a big effect on the architecture of an MSH solution.
> > > > >
> > > > >  Do you'all have any comment on this ?
> > > > >
> > > > >  Thanks !
> > > > >
> > > > >  mike dillon
> > > > >  mike@drummondgroup.com
> > > > >  817 875 0794
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > To subscribe or unsubscribe from this elist use the subscription
> > > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>