(link) [Mark Baker’s Bookmarks]
(link) [Mark Baker’s Bookmarks]
(link) [Mark Baker’s Bookmarks]
Mark and Bill list some of their favourite protocol/distributed-systems papers. Here’s some – not all “papers” – of my favs. I’m sure I’m forgetting some.
- A Note on Distributed Computing. ’nuff said.
- Architectural Styles and the Design of Network-based Software Architectures. Roy Fielding‘s dissertation, obviously.
- Modularity and Efficiency in Protocol Implementation. By Dave Clark. I read this over every couple of years, and get something new out of it each time as I apply its lessons to my recent experiences.
- Foundations for the Study of Software Architecture. Before Roy clarified and improved upon it, this defined the field of software architecture.
- Extending the REpresentational State Transfer Architectural Style for Decentralized Systems. Rohit Khare’s dissertation. Still absorbing it, but it’s already had an influence on my work.
- The Stack of Specifications, by Tim Berners-Lee. How to design and interpret a self-descriptive Internet scale protocol stack. Although that could be the best of the bunch, if you haven’t read all of his Design Issues, you’re missing out on some good stuff.
FWIW, I’m not too keen on Marshall Rose’s RFC 3117. It’s wonderful up to and including section four, but how those sections are used to justify BEEP blows my mind. I think he lost sight of the forest for the trees; that application protocol frameworks (like BEEP, and how SOAP is most commonly used) are a dime a dozen, and that until you’ve defined an application protocol, you’re just spinning your wheels. In other words, BEEP addresses most of the hard problems except the hardest one; coordination.
So apparently “processThis” is now – get this – an imaginary method. 8-)
But I know exactly what Jim’s talking about. I just wouldn’t use the word “imaginary”, because it’s definitely there, aka “in effect”, it’s just implicit; consider that a fault would mean “Sorry, there was a problem processing this”. It’s exactly like streaming video; video data arrives, it gets processed, moving pictures result. What we’re really talking about here (and I just noticed he had some more to say on the subject, in his brand .. new .. weblog! 8-) is the difference between these two types of messages;
Hello there
and
POST some-identifier HTTP/1.0 Content-Type: text/plain [blank line] Hello there
In order to make both messages semantically identical though, some additional work is required. First, the message has to arrive through a channel which has associated with it “processThis” semantics; you can’t just send it along on port 25 (the SMTP port) as is, and expect anybody to understand that you want them to process that data. So you really need a new port, which you have to obtain through IANA. To do that, you’ll need to describe to the IESG what the semantics of that port are, which you do by publishing an RFC which describes what “processThis” semantics are, and states that any data arriving on your special port will have those semantics. You’ll also need to state which spec controls the interpretation of the data, as there’s no (in my example, anyhow) way to indicate that as part of the message, ala the role that Content-Type plays in the HTTP message. Phew! That’s a whole lot of semantics to attach to a single port number!
Which brings me to the advantages of doing all that stuff as part of the message. First, it’s far more extensible. With the former example, if either the semantics of the interaction, or the semantics of the data processing need to change. For example, what if you want to query or store data, rather than just having it processed? You’re SOL.
Practically all large scale systems nowadays make their semantics explicit on-the-wire rather than implicit, in large part for reasons such as those I gave. Even some AV streaming protocols like RTSP do too.
But my intent here isn’t to critique this approach. The extensibility problem is a relatively minor problem compared to the enormous win of using a uniform semantic. What I’m really doing here is trying to describe how REST and Web architecture are an extension on top of this simple but powerful form of interaction. Or in other words, you could build a large scale system with the approach that Jim and Savas advocate, and it would be hugely wonderful thing. But it would still just be a subset of the Web in terms of size and functionality. Let me ask a couple of leading questions that might help drive home that point …
First, how do you address your messages? Just to a remote IP/port? I think you’d agree that you’d need a standard way to address remote data processors, no? And that address would have to be part of the message, otherwise you’re stuck with a single processor per IP/port tuple. So now, you’ve got a means of identifying anything which can reasonably be modelled as something that accepts data. For example, you could have an identifier for me, and if you sent your data to my identifier, perhaps the content would appear on my Blackberry, or arrive on my fax machine or some-such. It would be very much like email.
So now, you have these wonderful standardized identifiers, which you know identify things, many of which have some state associated with them (like myself 8-). Wouldn’t it be useful to have a uniform means of requesting that state be serialized as a response message? That’s the role that GET plays in Web architecture. And the URI is, of course, the standardized identifier.
Can you see why I’m so excited? You (Jim) and Savas are so far ahead of the Web services crowd, that you’re actually describing something that’s as useful as email (I’m not being facetious, that’s really a wonderful thing)! But the Web is just a baby step away.
(link) [del.icio.us/distobj]