W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2000

Re: 2nd try: clarification for "remote procedure" facet

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 8 May 2000 20:31:27 -0400
To: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Cc: Ken MacLeod <ken@bitsko.slc.ut.us>, xml-dist-app@w3.org
Message-ID: <20000508203126.P27982@w3.org>
On Mon, May 08, 2000 at 02:48:48PM -0700, Henrik Frystyk Nielsen wrote:
> > On Sun, Apr 23, 2000 at 09:40:54AM -0500, Ken MacLeod wrote:
> > > Earlier I wrote a possible clarification for the "remote procedure"
> facet,
> > > <http://lists.w3.org/Archives/Public/xml-dist-app/2000Mar/0072.html>
> > >
> > > But I think I've got an even more clear description.  The current
> > > wording is:
> > >
> > >     [Remote procedure] may mean the ability to pass generic
> procedures
> > >     and have the other side have some mechanism for giving a
> > >     best-guess response, or it may mean that there is a way to have
> > >     the other side do something for you, ie. protocol.
> > >
> > > Most of the protocols have some way to "have the other side do
> > > something for you".  The distinction is in whether those things to
> be
> > > done are defined by some application that uses the protocol or
> defined
> > > in the protocol itself.  Another distinction is whether the protocol
> > > explicitly supprts remote procedures or is just a carrier protocol.
> > > "Remote procedure" should only apply to the former.
> 
> I think a distinction has to made between whether a protocol
> 
>     a) can *support* applications with a programming model (like for
>        example a programming model that leans towards RPC) but
>        doesn't itself define one
> 
>     b) *itself* defines a programming model that it exports to the
>        application
> 
> The latter seems much less generic in my mind than the former.

True, but it is also likely that, through strategicly stacking
protocols, we can get good re-use and interoperability out of the
latter.

> Regarding classification of SOAP, SOAP is not a full-fledged protocol -
> it is currently just a protocol framework with the potential for
> becoming feature rich. However, the framework does fall into the a)
> category.

Infusing XML schemas into SOAP pushed SOAP towards a programming model
by reccomending a way to represent atomic and complex data types. The
SOAP-defined error messages amy also imply a some functionality on the
part of a SOAP applications, much like an HTTP-light protocol that
defined request structures and response codes but didn't define any
furthur server functionality.

Not that I object. I think that defined data types and message formats
are a likely win, but I don't know that SOAP is entirely in the 'a' camp.
-- 
-eric

(eric@w3.org)
Received on Monday, 8 May 2000 20:32:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:56 GMT