Re: Binding

Mark Baker wrote on 01/07/2003 04:29:34 PM:

<snip/>
> 
> > _before_ to issuing a GET, and that if the interaction is going to be 
> > successful that implies some prior agreement with the server: in 
> > addition to (i) and (ii) the server will have to be able to respond 
> > appropriately GETs on that URI.
> 
> Well, I disagree for esoteric but important-on-a-large-scale reasons.
> But I don't consider those significant for this example, so ok.

What reasons? I'm curious.

<snip/>
> >
> > 1. How to form a query for a quote URI given the stock identifier 
"IBM".
> 
> It can discover this as part of an interaction, equivalent to a
> machine processable GET form.

It could discover that, yes. But, absent some SW-like solution, we don't 
have the necessary information to know what information is required even 
if
there were a form. As I have said before, with an HTML form, the semantics
and context are sprinkled around the <INPUT/> tags of an HTML form using 
natural language. A human has no problems (usually) in reasoning that a 
field
that has the label "First Name:" is asking them to fill in their given 
name, etc.
Without a priori agreement on the ontology, the tag/label/whatever is just 
a
string of UTF-* characters to a software agent. The tags/labels *mean* 
nothing.
The software agent might be able to leverage the schema (assuming that it 
trusted
a schema that is of foriegn origin) to determine what the schema types of 
the
data elements to be populated might be (A is a string, B is an integer, C 
is a
datetime, etc.) but that isn't enough to go on.

> 
> > 2. How to interpret the services response and extract the quote URI.
> 
> I'd use redirection there, to prevent the client from having to
> understand that there's a separate lookup step.  So from their POV,
> they'd just enter IBM, and they'd get back a quote after doing a
> blind redirect (*good* automata 8-).

I'm sorry, you missed Miles' point altogether. How the information is 
returned
is not the issue. It is *understanding* the information carried in the 
representation
of the resource returned. As with above, without a priori understanding of 
the
*meaning* of the tags, it is simply a bunch of UTF-* characters decorated 
with
pointy brackets to a software agent that has not been prepared to 
understand
the schema of the response (assuming XML). Sure, it can *parse* the XML, 
but it cannot
*understand* what it means... 

> 
> > 3. That issuing a GET on the quote URI will take it one step further 
in
> >    this buy/sell interaction by providing it with a quote.
> 
> That sort of information should be made available in the data.  So
> instead of "<uri>..</uri>", it should be "<quote>..</quote>" or
> similar.

I'm sorry, how did it know what <quote/> means?

> 
> > 4. How to interpret the returned quote, in particular, that
> >    quote/buy/price (resp. quote/sell/price) represents a price to
> >    match against its constraints, and that quote/buy/uri (resp.
> >    quote/sell/uri) represents a corresponding action.
> 
> Yes, it's hardcoded to understand that schema.

Ah hah! The understanding of the schema must be encoded in the software 
agent 
before it encounters an instance, or it must have means of aquiring that
understanding. Would you agree that there are valid use cases where
dynamic acquisition of this understanding is either not an option, or 
would
be contraindicated either due to performance or security concerns?

Is it not reasonable to want to accomodate software agents that have
this understanding "hard coded" in the software that implements the agent?

> 
> > 5. That issuing a POST with an entity of a particular form on the
> >    appropriate URI will further its goals by initiating a trade.
> 
> Because it's been hardcoded to know that based on where the URI was
> discovered in the document.

I see... that understanding thing again...

>
> The nested <buy><uri>..</uri><buy> construct in your example provides
> this information.  More simply, it could be done as;
> 
>   <buy-order-processor>http://...</buy-order-processor>

The schema details are irrelevant. The point is that the agent has 
understanding
of what <buy-order-processor/> *means* and how that relates to its 
processing
and its goals.

> 
<snip/>
> 
> The difference between WSDL based knowledge, and REST based knowledge,
> is that REST's knowledge doesn't impact the binding qualities of the
> interaction.  So a client written to know how to place trades, can do
> so with any service that supports the same schemas.  A Web services
> approach requires that *both* interface and schemas match up.

Nonsense. You must be assuming RPC style here... Again, for the umpteenth
time, you'll get little disagreement on this list that the RPC style
is most assuredly more fragile and less scalable. However, as has also 
been pointed out a bazillion times, there is NOTHING in Web services that 
requires use of the RPC style of interaction. There is no reason 
whatsoever why
you cannot design a Web service such that it used a document-centric and 
RESTful style of interaction. The same applies to HTTP for that matter. 
People have been abusing it since its inception. They either muddle 
through, or 
they get burned and (hopefully) learn from their mistakes. 

Are you suggesting that somehow the RPC style of interaction is part of 
the
Web services architecture? Are you suggesting that REST precludes that
style? 

Think again. 

> 
> The structure of URI space is *completely* irrelevant, because the
> service creates the URIs, and clients use them opaquely without any a
> priori knowledge of what each one is; the a priori knowledge is in the
> code that interprets the schemas and understands what it means for some
> token, such as a URI, to be in a particular place.  The first point #3
> above demonstrates this.

And your point is what? I believe that you have successfully argued Miles'
case for him.

> 
> This discussion has become pretty obscure now, I'd say.  The point seems
> to be buried deeper under successive responses.  I think she's dead,
> Jim.
> 
> MB
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
> 

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624