Web Things, by Mark Baker

Worth a read
(link) [del.icio.us/distobj]

Presentation at ISCOC, Nov 18 2004
(link) [del.icio.us/distobj]

From the minutes of the last TAG face-to-face;

TBL was positive about looking at RDF/SemanticWeb and said that doing Web Services would be appropriate, but expressed concern about the defacto architecture that that’s coming, e.g. from corporate sources. NM said that those working on Web Services would benefit from the right kind of guidance on how to better leverage the Web Architecture and build scaleable systems

and, as a plan for action;

web services
    get seriously involved in WS addressing. Ask WS choreography to present.

I’m not holding my breath, but it’s better than what’s going on right now.

Last night I was thinking how close SOA is getting to REST, and how gosh-darn frustrating it is to me that its proponents don’t yet see it.

Let’s summarize the state of affairs circa late 2004 …

Document style services. Web services have attempted to escape the RPC style of service, and instead advocate a “document in, document out” model due to its superior loose coupling. Hurrah! That’s a REST style interaction! In particular, a POST operation; representation in, represent out, with simple “process this” semantics. Unfortunately many people don’t appreciate that it’s a uniform semantic (though some do) and still insist on associating service specific semantics with such an interaction. But the good news is that just makes for tightly coupled clients, not services.

Identification. For such a so-called cornerstone specification, it took an awfully long time to arrive, but WS-Addressing is an attempt to have a standard for Web services identifiers. Standardized identifiers? Who knew?! 8-) Of course, REST also requires a single identifying standard which can be used to identify an endpoint from which either a representations can be retrieved(GET), or one can be submitted for processing (POST) (or anything else which can be done to all other identified things). See the similarities?

When compared with the implicit architectural style of Web services circa 2000 then, we see a movement towards adopting the additional REST constraints of resource identification and the uniform interface (albeit, IMO, an overly constrained uniform interface; basically POST semantics only), even if they’re not done in a Web architecture friendly manner.

This is *NOT* a coincidence! Once you set out with document orientation, REST is where you will, for most people, eventually end up (though it’s by no means the end of the journey).

I’ve said it before, and I’ll say it again now; the Web is what Web services are trying to be. There’s just (at least) one enormous sacred cow yet to be slaughtered, IMO, before this can be fully appreciated.

For about the past year or so, Dave Orchard has been using principled design techniques, and in particular Roy Fielding‘s interpretation of software architecture, in his effort to build out and improve the Web services infrastructure. That is indeed worthy of very high praise, as he’s the first Web services proponent to have done it. But unfortunately, it seems he (and he’s not alone in this, of course) is missing one very important aspect of software architecture and large scale architectures in particular; an appreciation that some properties can totally make or break an architectural style.

Dave talks a lot about the pros, cons, tradeoffs, etc.. of particular architectural choices, and that’s all good. More often than not, he’s totally bang-on too. He gets, for example, that not adopting an interface constraint necessarily reduces visibility and simplicity, and has even gone so far, risking ridicule from colleagues, to suggest that a limited form of interface constraint (GET) would be a good thing Yet, at the same time, he fails to recognize the implications of the loss of these properties. Though it’s certainly not the case for all properties, some are so important that they can make or break the suitability of an architectural style for some particular task or environment. In the context of Internet scale systems for example, high degrees of visibility are simply mandatory (unlike LAN scale systems) due to the prevalence of trust boundaries (aka agency). It’s the whole integration complexity thing again; do you want to budget development resources along an O(Nlog(N)) (or worse, O(N^2)), or O(N) curve?

All architectural styles on the Internet, past and present, have large degrees of visibility. Even some non-REST forms of SOA do too, for example MEST. I therefore suggest that all future architectural styles that we’ll see on the Internet will have large degrees of visibility too.

Does your flavour of SOA have it?

Seth Ladd writes;

Stumbled on a great semantic web use case from mod-pubsub […]

Welcome to my world! Not that I have a chance to work with radically decentralized examples like zBay (the eBay without the eBay inspired project) very often (read; not at all, yet), but RDF + mod-pubsub will be my defacto starting point for my next integration project. I haven’t yet had an opportunity to work with them together (except when playing around), but separately they’re each a model of the power of simplicity; Web services done right.

No silly, not in general. I’ve now been running Linux for 10 years. It all started with an Yggdrasil CD I received as a gift when leaving my first job in November 1994, several years of Redhat, then the last few months with Debian. Thanks Linus!

Inspired by Sowa’s Law of Standards, Jon Udell writes;

My guess is that we’ll see a de facto alternative to the W3C’s proposed semantic-web standards — Web Ontology Language and RDF

It could happen, but I don’t think so. I could definitely see a new XML serialization of RDF happening this way though, but RDF itself? It’s already very simple, and has even sacrificed some expressiveness (e.g. quads) in the name of maintaining that simplicity. I think that’s good and healthy, and I can’t imagine any other spec doing what it can and being any simpler, nor can I imagine being able to remove much from RDF and still have it be useful to a lot of people.

I haven’t done enough with OWL to have a strong feeling about it, but it doesn’t seem to add much in the way of (required) complexity AFAICT. For most people, it’s, just another RDF vocabulary.

In the same post he also references some words by Mike O’Dell on the problems with DNS. He comments;

I have no idea whether, or how, “distributed system technology” might finesse the governance issue. But it’s a challenge worth pondering.

Jon might be interested in what the zLabs (“z” for “decentralization”) are up to, in particular the zNS project (not much there yet, but the objective is clear at least).

A succinct little guide to a cool looking tool, granting Resource-ness to SQL data objects
(link) [del.icio.us/distobj]

Tim Bray on xfy
(link) [del.icio.us/distobj]