Re: section 1, intro, for review

> I agree that the underlying data rep/type system of DCOM (ndr) and CORBA
> (cdr) didn't have clean extensibility or versioning built in. The data
> rep/type system of web services uses XML and XML Schemas, which have
> fairly well-understood extensibility mechanisms.

They have good syntactic extensibility mechanisms.  Syntax is only half
of the problem.

> > > Their "failure" has nothing to do with complexity,
> > 
> > Complexity was due to object-specific interfaces.
> 
> However, this ignores the fact that the community at large wants to
> build application-specific contracts. In the absence of XML/SOAP/WSDL,
> this means that every developer winds up building his own ad hoc type
> model and we have no chance of building infrastructure to cope with it
> in any sort of general way. SOAP et al give infrastructure more hooks to
> recognize what is going on in the network. Totally ad hoc hacks built
> using HTTP GET and query strings aren't the answer IMO.

I don't believe the "community at large" wants anything even remotely like
application-specific contracts.  What they want is integrated applications.
Absolutely anyone can get an application-specific contract by simply
including a hidden interface version field in a form.  It doesn't matter
if it is ad hoc because it is application-specific.  In order to get
cross-application integration it is necessary to have cross-application
semantics (cross-application syntax is trivial by comparison).

> > REST doesn't use strong typing and focuses on data 
> > streams rather than parameter values.  They are different beasts.  The
> 
> > point is that we lose the properties that makes the Web work when we 
> > introduce strong typing, object-specific interfaces, etc.
> 
> I think the key point you are missing is that the browser/html-based app
> known as "the web" was designed around a "present information to the
> user" model and that the primary design point almost always involved
> rendering ad hoc information to the user. The semantics of the
> information are completely opaque to the software. In general,
> formatting metadata was all that was needed in this application.

That is a fallacy.  Anyone can build a crappy interface on the Web, just
like any system that allows arbitrary gateways.  However, if the application
is built AS a web, then the semantics are standard and the world of software
agents (like MOMspider) have no problem whatsoever.  Those are semantics
that you can actually use to form meaningful integrations between applications
without having to anticipate future interface definitions.

> In the broad range of applications known as web services, the semantics
> of a given URI are baked into every application that uses it. Given that
> many web service consumers are actually software agents running inside
> of server applications, we can't rely on human intervention or
> interpretation of semantics.
> 
> SOAP et al strongly encourage (but do not mandate) strong typing in
> order to (a) better inform any intermediaries, (b) better inform the
> plumbing, and (c) better inform the tools. That stated, the default type
> system used by SOAP (xml schemas) has well understood extensibility
> mechanisms that can be used to lessen the impact of version skew for
> broadly deployed applications.

Syntax.

> > The difference between well-defined object-specific interfaces and 
> > defined uniform interfaces is that the latter scales better with 
> > intermediaries and with unanticipated forms of client.
> 
> The SOAP infrastructure (framing using soap:envelope, extensibility
> using soap:header) are "defined uniform interfaces" that exist primarily
> to facilitate better intermediaries. The SOAP payload, however, tends to
> convey application-specific semantics, which are unavoidable if we are
> to allow developers to continue to innovate in this space.

What space?  All you are saying is that there exists a reason why someone
might want to do RPC using a self-descriptive syntax.  So what?  It still
has nothing whatsoever to do with the Web and should never have been routed
over HTTP.

....Roy

Received on Friday, 22 March 2002 17:17:39 UTC