Re: Synchronous Messaging Proposal - Some Thoughts

[Prasad Yendluri <pyendluri@webmethods.com>]

Folks,

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

Prasad,

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 +<:-)