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


[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 interesting
point emerged about "signals" that are used to acknowledge. It was pointed
out that sometimes the signal style acknowledgements serve to carry non-repudiation of receipt
information. 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 Dick
that it may be superfluous to supply an explicit signal style acknowledgement if
you are actually returning the business level response. (I think that David Burdett
and 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