OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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


Subject: RE: Ack Message Payload??


i vote we keep the business and the ms ack separate. if not it really
confuses things and is not a normal protocol stack layering architecture...
rik

-----Original Message-----
From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
Sent: Monday, October 30, 2000 10:47 PM
To: dick@8760.com
Cc: Nikola Stojanovic; Ebxml-Poc (E-mail); Ebxml-Transport (E-mail)
Subject: Re: Ack Message Payload??


Dick,

With respect to MS ACKs sent for Reliable Messaging, the end of MS spec
0.21d section 7.11 details the values used... If we agree that an ACK is
also used to convey BP-level information, then I agree we need to talk
about this in Tokyo...

Jim

At 07:41 AM 10/30/2000 -0600, dick@8760.com wrote:
>Nikola,
>
> > <Dick>
> > my response message (identified with "MessageType=Acknowledgement")
> contains
> > the current stock price in the ebXML message payload (like an RPC).
> > </Dick>
> >
> > Is this an attempt to merge MS ACK with "Normal" Payload? Or, is it a
> > Business ACK with a payload?
> >
> > If first, then the same effect could be achieved if the MessageType was
> > "Normal" instead of "Acknowledgement".
> >
> > If second, I don't like it. It ties the meaning of MessageType to the
> > existence of the Payload itself. This overloads the MS, which would need
to
> > deal with different kinds of ACKs. I can see that MS can "Notify"
"Business
> > Layer" about the MS ACK, but I cannot think of any other kind of ACK
> > (whatever it might be) that the MS would need to deal with.
> >
> > Another characteristic of this "Usage" is that both flavors might lead
to a
> > situation when one would need to "ACK an ACK".
> >
> > I really support the view =>
> >
> > <Chris>
> > Let me see if I can make this clearer. A Business ACK is NOT the same as
a
> > MS-level ACK. A Business ACK would NOT use a
MessageType="Acknowledgment"
> > because that is reserved for MS use.
> >
> > A Business ACK is of MessageType="Normal" and has an appropriate
> payload (or
> > not as the case may be,
> > but it is NOT clear at all how an empty payload is supposed to be
> > interpreted by the receiving business service/application!).
> > </Chris>
> >
> > Maybe famous "ServiceInterface/Action" combo can do the trick with
Business
> > ACK and empty payload?
>
>Given the above, a synchronous (RPC-like) interchange would follow
(request)
>MessageType=Normal <----->MessageType=Normal (response) and async
(messaging)
>interchange would follow (request)
>MessageType=Normal<----->MessageType=Acknowledgement (response). This seems
>reasonable, I think we need to play out a couple of scenarios filling-in
the
>ebXML headers for the various type of request/response message exchanges
>to see
>how it plays out. For example:
>
>Does a response (Normal in the RPC-like case) contain a "reflection" of the
>ebXML header values contained in a request message  or does it contain
values
>germane to the acknowledgement (is so, in the RPC case, what values go
>into the
>ServiceInterface, Action, etc.).  The same question applies to the MS ACK
>response message.
>
>Clearly we have a lot more work to do in defining MS behavior in the
various
>scenarios.
>
>Regards,
>
>Dick Brooks
>http://www.8760.com/





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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC