+1
Christopher Ferris
Architect, Emerging e-business Industry Architecture
email:
phone: +1 508 234 3624
Michael Wang <>
10/17/2002 03:39 PM
Please respond to mwang
To
Dave Elliot <>
cc
Christopher B Ferris/Waltham/IBM@IBMUS,
Mike Dillon - Drummond Group <>, Doug Bunting
<>, ,
bcc
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:
> > phone: +1 508 234 3624
> >
> > Mike Dillon - Drummond Group <> 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
> > >
> > > 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>
