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: Synchronous Messaging Proposal - Some Thoughts

Thanks Dale. That was the reason I brought up that question actually. If a non-refutable acknowledgment of receipt is needed, we must either permit tacking on the ack with the response message or make sure the response message can somehow convey that information.


"Moberg, Dale" wrote:

[Dale Moberg] This is just a small point concerning Prasad's comment below and his response to Dick Brooks
This was from Prasad originally >The synchronous response should accommodate only an acknowledgment message / response message. I don't see value in sending both (e.g. one followed by the >other in the HTTP body). The acknowledgment could come synchronously and a response later asynchronously.

[This was from Dick Brooks] Phase 1 of the TRP delivery matrix includes a use case depicting RPC like behavior (request/response), exemplified using a stock quote service.  I believe it's imperative for ebXML to support synchronous acknowledgements containing a business level response (as in the stock quote case).

<PY> Dick,  we are not in conflict here. My statement is based on the general message exchange model presented in http://lists.ebxml.org/archives/ebxml-transport/200011/msg00018.html, where Acks could be different from responses with a business payload in general.  In RPC like request/response type model, what you called  "synchronous acknowledgements containing a business level response", is same as  the "response message" in my description. I was saying it does not make sense to send the ack (w/o business payload) and the response (with business payload) together (one followed by the other) in the same synchronous response, as the response would constitute the ack here.
[Dale Moberg]  In the Boston f2f joint meeting between BP and TP, an interestingpoint emerged about "signals" that are used to acknowledge. It was pointedout that sometimes the signal style acknowledgements serve to carry non-repudiation of receiptinformation. In such a case, the business response may be able to replace the acknowledgement function but not to perform the non repudiation of receipt function.With the exception of this special case, though, I agree with Prasad and probably Dickthat it may be superfluous to supply an explicit signal style acknowledgement ifyou are actually returning the business level response. (I think that David Burdettand Chris Ferris are working out some of this under the topic of "implicit acknowledgement") 
[Dale Moberg] 

[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