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

> > 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.

I guess that depends on what "strategic" means. In general, I don't
think it would work well with the Web where anybody can use links and
documents in any way they want.

> > 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 serialization part allows some higher-order data models to be
represented on the wire but doesn't say that they are the only ones as
a) the serialization is optional and b) other serializations can be
used. I don't think we have painted ourselves into a corner.

> 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.

Right, but SOAP in fact stops short of saying "request" and "response" -
a SOAP message is still fundamentally a one-way message.

> 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.

At some point you are right - I think the question is to what degree the
programming model is enforced by *how* you use it compared to how you
*can* use it. The reason why we can say that SOAP doesn't really imply a
programming model is because it doesn't do much, really. As soon as we
start designing features to fill in, they will of course dictate certain
patterns.

Henrik

Received on Wednesday, 10 May 2000 17:21:04 UTC