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]


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]