MHonArc v2.5.2 -->
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
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