[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Issue for your review
Dave, 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 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. -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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC