2004/12/09
Add your comment
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.