I suspect we're focusing on the incorrect layer here. The MSH layer
and the transport layer below it are responsible for responding to the
incoming HTTP request and must (MUST in our specification) do that after
making the message available to the application. If the application
does some application work, including sending a business signal, faster
than the MSH layer responds, it's out of our hands. Even if the "application
work" also involves the MSH (e.g. sending a new ebXML message including
a RefToMessageID referring to the "current" incoming message), enforcement
of the proposed rules seems difficult at best.
We're likely increasing the MSH requirements on the recipient side to
lessen them on the sending side without clear enforcement ability on that
side.
By the way, a big +1 on clear separation of layers in general -- from
the Mike Wang, Chris Ferris split from this thread.
thanx,
doug
"Ahmed, Zahid" wrote:
>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 ???
Decoupling of the transport layer (HTTP/S, JMS, SMTP,
FTP, etc.)
from the ebXML messaging layer is a good idea. Infact,
I believe
it is the intention of the ebXML SOAP messaging exchange
system
to be loosely coupled.
However, the relative ordering of events in the transport
layer and
ebXML messaging layer would need to be factored in any
implementation.
This implies that MSH<-->transport components will
have some interface
to coordinate relative ordering of events. E.g., if MSH
is implemented
on J2EE/EJB component such that the underlying transport
protocol is
JMS, then some form of hand-off, whenever a ebXML message
asynchronously
arrives at that end-point, between the message listener
and the MSH
(which is the message consumer) will occur.
thanks,
Zahid
-----Original Message-----
From: Dave Elliot [mailto:]
Sent: Thursday, October 17, 2002 11:41 AM
To: Christopher B Ferris
Cc: Mike Dillon - Drummond Group; Doug Bunting;
;
Subject: Re: [ebxml-msg] Issue for your review
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>
