Re: section 1, intro, for review

> On Tue, Mar 19, 2002 at 10:12:52PM -0800, David Orchard wrote:
> > Roy,
> > 
> > Further, attempts to put object interfaces onto the web - like 
> > CORBA/DCOM/RMI - failed because they didn't use well-defined 
> > interfaces.
> 
> You mean objects interfaces on the Internet, right?
> 
> No, they had very well defined interfaces.  Exceptionally well.  
> Defined so well that they made an application exceedingly fragile to 
> version drift and differences between ORBs.  Hence, they did not 
> survive multiple organizational boundaries when deployed as 
> application infrastructure.

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.

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

> > too early to market, binary formats, bootstrap problems, no buy-in 
> > across a big enough community or other issues.  I think that this 
> > implies that if CORBA/DCOM/RMI had used HTTP PUT/POST/DELETE/GET in 
> > a RESTful style, they would have had a much better chance of 
> > success.  You said this was the lesson to learn from their failures.
> 
> I think so, yes.  The money placed on CORBA and DCOM, separately, 
> dwarfs that spent on the Web.  But CORBA/DCOM/RMI are all distributed 
> object architectures, so it wouldn't have made any sense for them to 
> be REST-like. 

I agree that application-specific protocols using DCOM/RMI/CORBA are not
rest-like, not should they be.

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

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.

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

DB

Received on Friday, 22 March 2002 15:27:03 UTC