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


Forwarding per Anil's request..

-----Original Message-----
From: Anil K. Vijendran [mailto:Anil.Vijendran@eng.sun.com]
Sent: Friday, December 08, 2000 2:46 PM
To: Prasad Yendluri
Subject: Re: Synchronous Messaging Proposal - Some Thoughts


Pl fwd my followup reply to the list when you get a chance. For some
reason I can't post to the list.

"Anil K. Vijendran" wrote:

> Hi Prasad,
> I was trying to implement sync messaging using ebxml and hence my
> interest in your proposal.
> Prasad Yendluri wrote:
>> General:
>> 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.
> I want to be able to say the following. For every sync request there
> will only be one message -- ack or response -- sent back
> synchronously.
> Why would you want the ability to have a sync ack and an async
> response? The reason I'm interested in sync messaging is for
> request-response type scenarios. I want to send a request, receive a
> response synchronously and then tell myself that I'm done with this
> "thread". Maybe I wouldn't even have the ability to receive a response
> asynchronously and _that is exactly why I requested a sync response in
> the first place_.
>> There are two potential choices for this.  (1) As part of the
>> transport / communication protocol level bindings or  (2) As new
>> elements in the ebXML Header.
> I read both these approaches. I guess either one is fine but I'm
> tempted to have a mild preference to 1. I feel  a/synchronicity is a
> property of the particular transport used, so might as well deal with
> it in a transport-specific binding. I don't like the idea of the ebxml
> header (which is so far transport-neutral) to get polluted with
> transport-specific elements. Specifically what bothers me is that the
> header could be broken for one transport but not for another.
> --
> Peace, Anil +<:-)

Peace, Anil +<:-)

[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