Phil Wainewright writes;
There is no alternative to messaging. Your only choice is good messaging or bad messaging.
Mostly, sure. But sometimes, when you’ve got very good messaging
beneath, it becomes possible to see new patterns of communication in the
aggregate. Shared memory, for example.
As I was just writing to someone in private email, if you do REST properly,
you end up with a system which exhibits the properties of both messaging and
shared memory styles, depending upon the configuration of the architecture you’re
examining (obviously), but also depending upon how you look at it; sometimes
I see distributed objects with a uniform interface (the messaging view), and
sometimes I see interconnected pools of data (the shared memory view), and both
are perfectly valid and complementary ways of looking at a single configuration.
Some have referred to this duopoly as
“Bees and Ants”.
Ed Dumbill writes;
I’m wondering how long it will be before everybody’s completely reinvented RDF in the search for what it had all along.
Yup. Any day now, I expect. In fact, I bet BEA is working on
something as we speak given Adam’s comments, plus the recent
Anybody who’s spent any time following RDF would know that there’s a
you could seriously mess up if you didn’t know better. Given that Dave and
Adam have previously demonstrated
some extreme ignorance
regarding RDF, I’m not hopeful that what they produce will be anything very
I also wanted to add, in response to Chris Ferris’
about “partial understanding” (a key benefit of RDF) being unnecessary, that
partial understanding is little more than “MustIgnore”. How DaveO can go
on-and-on (see links above) about the value of MustIgnore, yet not see the
enormous value-add that RDF/XML provides over plain-old XML, totally boggles
Sean spots an
old message of Don’s. Yup.
As yet another contribution to this discussion, here’s some light hearted
Jeff Foxworthy style “humour” (well,
my best go at it anyhow).
You know you might be using APIs, when a firewall is something you’re trying
to hide from, rather than something you’re trying to help.
You know you might be using APIs, when you’re generating stubs and skeletons
rather than reusing age-old network libraries.
You know you might be using APIs, when the words “transport” and “transfer”
are interchangeable in your architecture.
And, the number one … erm, wrong comedian …
You know you might be using APIs, when all your services have different, erm,
has been an unwitting mentor of mine for almost ten years now.
I used to read his and Doug Schmidt‘s
religiously in the mid 90s, and have enjoyed his more recent
work too. I’m sure his
weblog will be just as
I’ve been doing some work with extensible protocol envelopes recently,
with a very strong emphasis on size, processing efficiency, extensibility,
and evolvability. On a lark, since I’ve been
about it for a few years, I thought I’d try to toss in the use of RDF, just to
see how far I could go with it. As it turns out, pretty far.
I’d like to be able to talk more about this now, but can’t; it’ll have to
wait, because I’m being paid to do it by somebody with competitors 8-). But I
can certainly pass along one rather enlightening observation that I made …
Protocols typically work with a predicate(aka header)/value tuple.
If you’ve ever worked with triples though, you quickly realize the problem with
a double; it’s not everything you need to know. In this case, you don’t know the
has a media type, what is of length 342 bytes, what is identified
by this URI? Most protocols, therefore, define their subjects not in the message,
but in the specification. For example,
here are some
possible subjects of an HTTP message.
This is fine when you’re predefining headers in a spec; there’s still a
self-descriptive path from bits-on-the-wire to what-is-the-subject-of-this-header.
But for extension headers, it doesn’t cut it; you’ve got a predicate (the header
name) and an object (the header value), but no subject.
It would help to have RDF available to us when defining protocol extensions.
On the brand-spankin-new REST IRC channel
(does anybody have the ability to set up a
Joe Gregorio asks;
[18-Feb:17:02 jcgregorio] ok, quick question about DELETE, does success mean the URI *has* to then go 404 or 410?
[18-Feb:17:02 jcgregorio] here is the context
[18-Feb:17:02 jcgregorio] I am adding support for the AtomAPI to a wiki
[18-Feb:17:02 jcgregorio] one of the actions is to DELETE a definition
[18-Feb:17:03 jcgregorio] but as far as a wiki is concerned, *all* words exist, they just don't have definitions yet
[18-Feb:17:04 jcgregorio] for example: http://www.intertwingly.net/wiki/pie/ALongWikiWordWhichHasNeverBeenEdited
[18-Feb:17:05 jcgregorio] my implementation now gives a 200 on DELETE, which removes the definition, but doin a GET on the DELETED URI returns a valid Atom Entry with empyt content
Great question. I’d say that it’s up to the server to interpret what DELETE
means (within the bounds of the RFC 2616 definition, of course). The behaviour
you describe for the Wiki there is reasonable, I’d say.
A flurry of systems aching to be engulfed by the Web this week;
I started tracking another Web services metric last night;
the number of WS-I members. I’m not
expecting this to bare any fruit (i.e. show the expected decline) anytime soon, as that will
certainly lag the non-deployment of
Web services on the Internet
by at least a couple of years. But it’ll be interesting to watch when it starts moving.
AFAIK, they don’t have an “affiliate” program yet, which is something the
more mature organizations will use to boost membership for a number of
reasons (including waning interest in the space). That will
certainly impact this metric if and when it happens.
is a Web service spec I might actually use! Horror! 8-)
When I heard what it was, and that it was written by BEA, I was
sure that Yaron Goland would be
involved, after all his
He wasn’t, nor was he even acknowledged. Odd.
But there’s not really too much to say about it (at least until I do
a detailed review). Link local
discovery is a pretty well understood domain, and the authors of this
spec seem to grok it at least as well as I do. The use of SOAP/XML
is unfortunate, I’d say, because of its bloat; you really need to keep
things lean for multicast discovery so as to fit everything in a single
datagram. Some kind of binary-encoded SOAP would be useful here.
I sort of wonder why
weren’t adopted; the former
has a whole lot of support and running code behind it, while the latter
has MS and should be published as an RFC shortly. But I suppose that
nothing’s really close to critical mass in this space, so I can’t blame them
for starting from scratch.
There’s also mention of a “SOAP/UDP” spec, which is “To be published”.
That’ll be interesting to see, especially if there’s a compact (but still
extensible) binary encoding. What’s suggested in the spec, re “UNICAST_UDP_REPEAT”
and “APP_MAX_DELAY”, and comments such as “waiting for timers” suggests
that it might be more a case of trying to reinvent parts of TCP rather than
embracing the message-per-datagram model which seems to work so well. But my
experience there is rather limited, so I’d be happy to be proven wrong.
Chris still isn’t seeing it;
And you either recognize this:
or you don’t. In all cases, you need to read the specs.
Did you notice that in my example document there’s no RDF namespace?
I was trying for an apples-to-apples comparison.
If an XML document is also an RDF/XML document, then an RDF processor can
extract fine grained pieces of information (triples) from that document.
I’ll stop there for the moment, before we go on to why that’s valuable.
Are we in agreement?