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



+1

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624



Michael Wang <mwang@tibco.com>

10/17/2002 03:39 PM
Please respond to mwang

To
Dave Elliot <david.elliot@xmlglobal.com>
cc
Christopher B Ferris/Waltham/IBM@IBMUS, Mike Dillon - Drummond Group <mike@drummondgroup.com>, Doug Bunting <db134722@iplanet.com>, ebxml-msg@lists.oasis-open.org, ian.c.jones@bt.com
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: 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>



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


Powered by eList eXpress LLC