Monthly Archives: February 2004

Messaging alternatives?

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

Reinventing RDF

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 flurry of work by Dave Orchard.

Anybody who’s spent any time following RDF would know that there’s a whole bunch of things 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 interesting.

WS-DataExtensibility anyone?

I also wanted to add, in response to Chris Ferris’ comment 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 my mind.

APIs and documents

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

Towards an RDF Protocol

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 thinking 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 subject; what 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.

Must DELETE yield 4xx?

On the brand-spankin-new REST IRC channel (does anybody have the ability to set up a chump and/or log bot?), 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:
[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.

WS-I tracking

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.


Oh my, WS-Discovery 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 related work on UPnP. 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 Rendezvous or LLMNR 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:

<rdf:RDF xmlns:rdf=””/>

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?