It’s Dec 31, and time to see how my
past predictions have done.

I predicted that XMethods would list less
than 400 services by today, and lo-and-behold, that’s the case; they list
366.

Am I psychic? Have I hacked XMethods? Nope, I just performed simple
linear extrapolation. Why linear? Because Web services have extraordinarily poor
network effects; their growth has been roughly a function of time, not a function
of the size of the existing population as you’d expect to see in an Internet
scale network (like email, instant messaging, or the Web) which benefits from
Metcalfe’s law.

I also predicted that the TAG would
reject the Web Services Architecture document.
Of course, that document hasn’t progressed very far, and will apparently only be published
as a Note, meaning it will never be reviewed by the TAG.

So here’s a challenge to Web services promoters; make a prediction about the
number of Web services available on the Internet by the end of 2004 and/or 2005.
If they’re so great, then surely, at some point, there’s going to be thousands
of them, right? When will that be? At this rate, they won’t get to 1000 until
2010 … assuming the hype – which is the only thing keeping them even linear, IMO –
lasts that long.

He writes;

Is it a transport protocol or not?

Definitely not a transport protocol. It’s a state transfer protocol.

The difference is this: the HTTP interface is vague and the Linda interface is specific. Linda has precise, simple semantics. The possible range of behaviors exhibited in Linda-based systems benefit from being layered on *top* of those precise, simple semantics.

Hmm, I’m not seeing it. How is get, put, and post any more vague than rd, write, and take?
All have “precise, simple semantics”. IMO, the only really important difference between
them is that the former are operations defined on a more general abstraction than the latter;
the resource for REST, and the tuple space for Linda. If it helps, I
drew that relationship
once upon a time.

Also, regarding Linda, I don’t see how the range of behaviours is a result of layering.
Perhaps this is just a nomenclature problem, but I attribute the wide range of behaviours
to the generality of the Linda interface. For example, if your operation was getStockQuote(),
then you’re only going to be able to use it for stock quotes. If it were getQuote(), then that
would be more general, as you could also use it for insurance quotes too. If it were GET or
rd, well, you could use it for most anything, couldn’t you?

One other point I want to respond to;

Vanessa Williams provides an elaboration of HTTP for a tuple space application protocol. As I understand REST this should therefore provide the application protocol of a tuple space on the architectural style of REST using the HTTP transport/application protocol mix. In this case the advantage of using REST and HTTP is supposed to be found in the hardware and software that would already be in place between the client and the server.

I wouldn’t say that’s what Vanessa did. What I would say she did, is that
she described how one could build an HTTP gateway
(a Facade)
to a tuple space system; identifying each space with a URI, and mapping HTTP
operations to tuple space operations.

Offline, I suggested to Patrick that if we took Linda to the IETF to standardize,
that we’d be placed in the Applications Area
where we’d be tasked with defining “TTP”, the “Tuple Transfer Protocol”. This
application protocol would include operations such as READ, WRITE, TAKE, etc..
Perhaps it might even accomodate extensions so that somebody could, in the future,
define the “TTP-NOTIFY” extension protocol which added the “NOTIFY” operation.
That would also, as with HTTP, most definitely not be a transport protocol …
though I’m sure most SOAP proponents would want to treat it like one. 8-)

This is goodness, though I’m embarassed that it took me so long to
get plugged into; I’m too many degrees of separation away from some
communities that are important to my work. Time to update my weblog
subscriptions.

Here’s what’s been said the past week;

Phil’s done his homework on his “See also” links there; it’s a nice collection
of snippets from the past couple of years, several of them mine. I’d also
recommend a presentation I gave last year to the
Web Services Architecture WG
titled “REST Compared”, where
I present a simple example of a REST vs. Tuple space based solution to the
pervasive problem of turning lights on and off.

I also like what Vanessa did there, and I think that for anybody currently
into tuple spaces hardcore, that following through her outline of one possible
integration of REST & tuple spaces would be very informative about how the Web
relates to their work.

Patrick seems stuck with how to reconcile his position that generic abstractions
are a good thing, but that systems should be built independent of the protocol. Note to
Patrick; this is all well and good for transport protocols, but application
protocols define the abstraction; for them, protocol independence requires
that you disregard that abstraction.

What I like most about this meme is primarily that it implicitly eradicates
the myth that the Web and/or REST is just for humans. Even if you don’t know – or want
to know – about tuple spaces, it should hopefully pique your interest that a bunch
of bright folk in the large scale distributed software composition space – where
there’s no humans in the loop – are looking at REST.

… to the land of blogdom.

telnet proxy.markbaker.ca 80
MONITOR http://www.pacificspirit.com/blog/index.rdf HTTP/1.1
Host: www.pacificspirit.com
Reply-To: http://www.markbaker.ca/private/
Content-Length: 0

aka “subscribed”

It may only be an automata, but I’m gettin’ good lovin’ from
The Classic IQ Test;

Mark, you are a Visionary Philosopher.
This means you are highly intelligent and have a powerful mix of
skills and insight that can be applied in a variety of different ways.

Update; they ask for personal info on page three, but you don’t need
to enter accurate information (i.e. email address) to get your results

The Web Services Description WG
offered up their
latest attempt
at an HTTP binding for WSDL last week. I think it’s about as good as you can hope
something like that to get, without rejecting Web services. But it seems the group
asked itself
some good questions while reviewing it, in particular this one;

Is it good practice to extract part of your content to parameterize your URI? If not, what is the best way?

To which I responded;

Invoke GET on the URI to retrieve a document, and include in that
a declaration of how the URI can be parameterized. This is what forms
are for (well, “GET forms” anyhow); see XForms
or RDF Forms.

If you didn’t recognize it, this is a textbook case of bootstrapping; see a URI,
GET it, etc.. It reminds me of the
Java Beans
component model, which, for all its flaws (namely, that it wasn’t useful for much
more than GUI stuff), had its own wonderful bootstrap mechanism; the zero argument
constructor (sorry, no good URI for it). This permitted anybody who was in
possession of a bean class to instantiate it without a priori information about it.
Some might argue that this was just deferring binding, and they’d be right, but
there’s no “just” about it; deferred (aka late) binding permits more functionality
to be internalized into the system. In the case of beans, this was realized via the
use of a wizard which could be triggered when instantiating beans that needed
parameterizing.

Bootstrapping is your friend.

Dave Bettin comments on my previous
blog entry. He writes;

Mark Baker discusses the causality of redundant message metadata due to the protocol independence nature of Soap. HTTP is not the omnipresent protocol in the services ecosystem; i.e., there are internal business cases where HTTP is not necessary and straight TCP is preferred. I want my metadata to live in the Soap packet; I don’t want leaky metadata abstractions.

I don’t mean to offend Dave with this comment, but that response is
typical of what I hear when I make my claim that protocol independence
is a bug.

So, how to respond? Let me try a few on for size;

  • HTTP was just an example in that entry; the message metadata issue is important to the
    use of all application protocols … but not transport protocols. If you’re
    using a transport protocol, like TCP, then all the message metadata should be in
    the SOAP envelope as TCP doesn’t provide any of its own.
  • So you agree SOAP is broken, as you can’t define a service which returns faults?
  • Comparing HTTP and TCP is like comparing HTML and Ethernet.
  • You can have your metadata in the SOAP packet, but firewalls won’t find it there, as
    they look for it in HTTP, SMTP, and other application protocols. If firewall admins learn
    that metadata important to their duties (i.e. protecting their intranets) is being hidden
    from them, you’ll be shutdown pronto.
  • SOAP, the spec, should be protocol independent, permitting bindings to protocols other
    than HTTP to be created. It’s the use of SOAP which shouldn’t be protocol
    independent.

Perhaps one or more of those will take. 8-)

John Beatty reminded me
that a friend told me a great business (aka non-plumbing) description of the differences
between transport and transfer in the supply chain management space, where they use those
very same terms. Paraphrasing, he said;

Transport refers to the movement of goods between locations.
Transfer refers to the change of ownership of those goods.

Compare that with this REST vs. SOA diagram.

From early on in my work as a member of the
XML Protocol WG to make
SOAP 1.2 usable in a REST
based architecture, I found myself up against the unmoveable force known
as “protocol independence”.

I was reflecting on this experience in the car this morning, and
realized that I could perhaps explain the different viewpoints – of
“protocol independence” and “transport vs. transfer” specifically – in
terms of message metadata.

Message metadata is that data in a message which defines the context
for interpretation of the rest of the data in the message. Application
protocols typically have a handful of pieces of it. For example, HTTP has
the protocol version, request methods, request URIs,
and response codes,
and each one of those changes the meaning of their message fundamentally.

My issue with “protocol independence”, which essentially says that you
should put everything you need to know in the SOAP envelope, is that it requires
me to a) disregard the metadata already provided by application protocols, and
b) requires me to reinvent the same mechanisms higher up! Here’s two examples
of that form of reinvention;

One type of message metadata that hasn’t, to my knowledge, been reinvented,
is the response code metadata. I don’t mean the response codes themselves,
as SOAP does have different standard fault types. I mean a standardized place
in a SOAP envelope which indicates whether the SOAP message is a fault or not.
What’s that you say? The mere presence of a SOAP fault in the body of the
envelope is sufficient information to identify the fault?
Ah, I see. Well
then, you’ve got a message metadata problem. To explain it, consider a Web
service with an operation whose job is to return the last fault that the service
generated. How do you distinguish between the success of that operation and its
failure? Both return faults inside the SOAP envelope! One way would be to define a
wrapper that encapsulates the fault in the not-a-real-fault case, thereby hiding
it. But that wrapper is exactly the kind of message metadata that I’m talking
about!! Another case of reinvention, and again, completely unnecessary when
you’re using an application protocol which already has a place for such metadata.
When you consider that SOAP doesn’t define this wrapper, then you have to conclude
that either a) SOAP is broken, as it prevents me from defining services which
return data that looks like a fault, or b) there’s another way to use SOAP, as an
extension protocol which reuses the message
metadata of the underlying protocol (when it has any, which all application protocols do).

Compare and contrast.

Werner Vogels writes;

A common trend still is that there are no generally accepted definitions of (web) services, and people spent way too much time criticising each others definitions.

Dan Connolly wrote,
this in response to a question regarding the value of dereferenceable URIs;

my answer to “but what if I don’t want to publish representations or descriptions of the thing” is: then you’re not doing what you can to establish consensus around your terms.

My point being that perhaps if there were
more Web services
to which people could look for definitions, conferences like the one Werner’s
attending (not to mention the
Web Services Architecture WG
and indeed most other Web services standardization groups) could be more productive.

Nothing facilitates concensus quite like running code.

Don’t chicken-and-the-egg problems suck?