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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: Re: [wsrm] Draft Agenda for Tuesday April 8 WSRM TC meeting Teleconference]


I agree with your analysis.

I was actually bringing up another issue from the one Iwasa was 
discussing.  (efficiency of Acks when messages are flowing in two 
directions between the same endpoints).

Tom Rutt

Doug Bunting wrote:
> Tom,
> 
> I don't believe your suggestion is a clarification of the text Iwasa 
> referenced.  While choices of how much piggybacking support we want to 
> include in our specification remain before us, the original words from 
> the charter were about sending back an acknowledgment immediately 
> (synchronously in the charter's terminology) rather than some time later.
> 
> On the original topic, I agree with Iwasa's original option #2 because 
> it allows support for "unreachable" reliable senders (senders that are 
> not receivers).  Whether or not an RPC or other application response is 
> included in the same immediate response is a somewhat separate point we 
> also need to discuss.
> 
> thanx,
>     doug
> 
> On 08-04-2003 09:02, Tom Rutt wrote:
> 
>> What might be a clarification is that the ack should be able to be 
>> included on a reliable message being sent in the reverse direction to an
>> original request message.
>>
>> Thus, while WSDL would be "one way" messages, one could have them flow 
>> in two directions with a piggyback of acks with messages.
>>
>> Tom Rutt
>> Fujitsu
>>
>> iwasa wrote:
>>
>>> Magdolna,
>>>
>>> Right. Strictly speaking, RPC might not be appropriate terminology.
>>> I meant the synchronous request/response message
>>> exchange pattern, when I said RPC in the former e-mail.
>>>
>>> Iwasa
>>>
>>> -- 
>>>
>>> Hi,
>>>
>>> I'm a bit confused about the terminology used: "synchronous RPC". Do you
>>> mean here synchronous request/response message exchange pattern, 
>>> allowing
>>> much more general message data structure ? In my understanding RPC 
>>> (Remote
>>> Procedure Call) describes a special one.
>>>
>>> br,
>>> Magdolna
>>>
>>> -----Original Message-----
>>> From: ext iwasa [mailto:kiwasa@jp.fujitsu.com]
>>> Sent: April 08,2003 6:38
>>> To: wsrm-TC
>>> Subject: Re: [wsrm] Draft Agenda for Tuesday April 8 WSRM TC meeting
>>> Teleconference]
>>>
>>>
>>> All,
>>>
>>> I would like to raise one discussion item for charter.
>>> Currently, out of scope items include "Synchronous RPC
>>> at the application level", but it would require a clarification.
>>>
>>> This was originally included here to simplify the spec,
>>> since including both RM and RPC sometimes
>>> make the spec confusing.
>>>
>>> However it was not intended to prohibit to use the spec
>>> for synchronous RPC at application level. So it means
>>> we could include how to use the spec for RPC. And the
>>> spec shouldn't prohibit to do so.
>>>
>>> Thus, I would like to propose making a clarification
>>> for the sentence with one of the following options:
>>>
>>> 1.Adding a clarification like:
>>> Synchronous RPC at the application level.
>>> *Note this is included here to simplify the spec,
>>>   since including both RM and RPC sometimes
>>>   make the spec confusing. This doesn't mean the spec
>>>   should not be used for synchronous RPC at application
>>>   level, but the spec must allow to do so. In addition to this,
>>>   the spec may have normative description how the
>>>   spec is used for "Synchronous RPC at the application
>>>   level", if appropriate.
>>>
>>> 2. Removing the sentence to avoid miss-understanding.
>>>
>>> And I would propose #2 option above.
>>> Thanks,
>>>
>>> Iwasa
>>>
>>>
>>>
>>>
>>
>>
> 


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




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