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


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 
> 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>

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

Powered by eList eXpress LLC