Web Things, by Mark Baker

A great post from Rich Turner (subscribed!) via Stefan.

It doesn’t surprise me one bit that this backlash is happening. It’s inevitable whenever there’s no definition to back up a buzzword. Since SOA is an architectural style, it needs to be defined in the language of software architecture, something that nobody is doing … well, unless you count this decent first stab by Dave Orchard (which didn’t make it into the WSA document, unfortunately).

If the term “SOA” is going to have any meaning going forward, somebody’s going to have to define it in a rigorous manner, it’s just that simple. Any volunteers?

P.S. and to top it all off, that’s the good news for SOA. 8-)

I cancelled my Friendster account today, in protest of their decision to fire a friend of mine, Joyce Park.

This was apparently, as I understand it, just because she blogged about work related matters, although without revealing anything which wasn’t already publicly available. The mind boggles.

If you’re doing Web stuff, you could do no better than her. Drop her a line (and me too, while you’re at it 8-).

I realized a little while ago that my blog roll was quite one dimensional in the subject matter it aggregated (namely, distributed computing). So, I’ve decided to augment it with some other feeds related to a broader love of mine, design (in general, not just software). For reasons unknown, I seem to be in a headspace recently where I’m noticing design in practically everything. In fact, Adam scooped me on one of them a couple of weeks ago; designing a startup (more on that later, perhaps, as it’s something I have a lot of experience with).

So far I’ve only found two feeds that turned my crank (though without much effort on my part, admittedly); MoCoLoco which presents creative examples of industrial design, and Tesugen by Peter Lindberg, which seems to cover design in general, though with an emphasis on urban design and software architecture.

If anybody knows of any others, I’d be grateful for recommendations.

Uche writes;

But putting the misery of these experiences aside, I’m surprised at how little I’ve had to worry about SOAP. As it became clear to me that Web Services were becoming a menace to much of the goodness wrought by XML, I worried that I would be forced to do a lot of gritting my teeth at work while I accommodated clients’ insistence on WS. This hasn’t turned out to be the case. In several cases where WS “end points” have been suggested, I’ve been surprised at how easily my suggestions of a REST-like alternative are embraced (the fact that I could usually whip up running code in hours helped a lot).

That’s what I’m seeing too, at least once you’re in the door (though for a pretty small sample space of two clients). On the other hand, looking for cool large scale distributed systems work has becoming extremely painful since Web services came onto the scene. Most projects are asking for “SOAP/WSDL/UDDI experience”, which leaves me either having to lie and say “Oh yes, I’ve got lots” (which I won’t do, of course), or else I have to put a pleasant face on WS-Insanity and brave the inevitable lack of interest, as I did in my resume;

He believes that, for the foreseeable future, the bulk of innovation in Internet scale systems will occur via additional architectural constraints applied to the Web; for example the Semantic Web, or the Two Way Web. Unfortunately, these beliefs also indicate to him that Web services have some serious architectural flaws that make their suitability as a large scale integration solution questionable. As a result, he spends considerable amounts of time working within standards setting organizations to ensure that these specifications – including SOAP 1.2 – take maximal advantage of the Web.

He writes;

Simply put, business resources should be “one step back” from HTTP IMHO. When you send non-idempotent messages to a resource (e.g. POST/PUT), you send them to its inward bound, asynch message queue. You do not directly interact with the business resource.

Interesting position on queues, but I think you’ll eventually run into problems doing that … though clearly not major problems, otherwise you’d have discovered them already 8-).

Whenever I want to do the queue thing, I use two resources; the “business resource”, and “the inbound message queue for that business resource” (though of course, as a separate resource, it need not be used only for the business resource). I then subscribe the business resource to the queue, such that messages POSTed to the queue also are forwarded to the business resource. FWIW, I’ve been using mod_pubsub recently to manage the queue resource (as a topic maintained by its router) in some work I’m doing on the side.

The problems I see with the approach Sean describes are a result of it not acknowledging that the queue is a separate resource than the business resource, as this can lead to ambiguities. For example, what can be expected from a GET on the URI; a representation of the state of the business resource, or a representation of the state of the queue?

That structure I described is probably a useful Web idiom to write up… I’ll put it on my todo list. 8-)

P.S. I assume you wanted to say “non-safe” there, since PUT is idempotent.

Savas asks

I am talking about an architecture which only has services and messages, so where are the resources?

Aha! If that ain’t the $10,000 question … So, here’s my smart-ass 2c response;

Show me a message(*) and I’ll show you a representation of the state of some resource.

(*) a ProcessMessage message, aka a document.

In a really awesome essay (sorry for the delay, I was on vacation), Savas ponders, among other things, what it would mean to be a RESTafarian. It seems the one thing holding him back from being a card carrying member of the club though, is that the whole idea of binding application semantics to a protocol seems sorta silly to him. Well, I don’t believe it is, but fortunately, what you believe about that subject matters not to your eligibility for membership. This is because REST, as an architectural style, says nothing about how any particular architecture is implemented. “All” it does is constrain your architectural elements.

So, if your architecture has uniform connector semantics (even if there’s only a single one called “processThis”), and if your architecture has a single data element which identifies resources which act as message endpoints, and it uses fully self-descriptive messages, et cetera …, then your architecture is RESTful, like it or not.

Savas, your card’s in the mail. 8-)

P.S. it hurts to type so don’t expect speedy email or blog replies – a side effect of skewering your hand with a broken wine glass stem.

According to Radovan anyhow 8-)

Everyone programs in something different, so let’s just do protocol-based integration, where we will just agree on the format of the messages we are going to exchange over the wire.

I think this is the thing some ‘REST fundamentalists’ are still missing…

No, I think we get that. Or at least we get that it’s a critical part of the solution. This is why HTTP 1.1 is as well specified as it is (not that it doesn’t have issues, of course). The problem is that the format is only one part of the solution. The other part are the semantics of the messages, something that HTTP also specifies, but SOAP doesn’t … not that it should though, as it can always inherit them from the underlying protocol.

Right from the spec, we have this example of an EPR;

<wsa:EndpointReference xmlns:wsa="..." xmlns:fabrikam="...">

   <wsa:Address>http://www.fabrikam123.example/acct</wsa:Address>
   <wsa:ReferenceProperties>
       <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
   </wsa:ReferenceProperties>
   <wsa:ReferenceParameters>

       <fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart>
   </wsa:ReferenceParameters>
</wsa:EndpointReference>

Somebody please tell me why on earth that isn’t a URI? You know, something like;

http://www.fabrikam123.example/acct/123456789?ShoppingCart=ABCDEFG