Monday, April 24, 2006

SOA- meaning less every day

I keep linking to Fowler's "bliki" on Service Oriented Ambiguity because it is one of the best analyses of the subject. And it's kinda funny:

"I've heard people say the nice thing about SOA is that it separates data from process, that it combines data and process, that it uses web standards, that it's independent of web standards, that it's asynchronous, that it's synchronous, that the synchronicity doesn't matter...."

Fowler links to a guy called David Ing. I don't much about Mr. Ing (I don't know much about Fowler either, except that he is a undeniable genius and the guy who got me actually thinking about software.), but he has some sharp thoughts. I clicked on his link from Fowler's blog today and it took me to his latest collection of thoughts type post. It reminds me of Wittgenstein, in the style of sequential ideas.

A sample:
"- WS-* Specs feel 'top-down'. They take abstract concepts that you *may* need at some point and unify them from a few different levels. This unification is beneficial if you use all the concepts, but conversely expensive in terms of complexity if you don't."

I whine about the WS-* specs a lot. I sometimes understand the point of a spec- to define a common operation across systems. They just go too far. And XML Schema doesn't help...where's the RELAX-NG?

Here's my simple "Web Service" spec:
Make it so that every application in your organization returns an html view of an object if you send a GET to:
And make them return the same thing in XML if you send a GET to:

Every place that I have seen where they do that- people actually use the API. Is it a service?

Who cares?


Jason Birch said...

Here's a totally irrelevant comment on your simple spec...

If the company wants its objects indexed by Google, it will avoid using ID as a parameter (except as a session identifier)

Matt M said...

Must get into the index. Must get into the index.

Don't use "&id=" as a parameter in your URLs, as we don't include these pages in our index.

Those pages do work when you're using the enterprise search appliance...

Adam Browning said...

Another way to approach it would be to have urls of the form http://site/resourcetype/id. Since you can map an entire directory to a particular servlet (I assume other web-dev technologies will allow the same thing) and parse the URL, you can keep a dirt-simple interface and keep Google happy.