« links for 2007-02-24 | Main | Verisimilitude »

Confederacy

Mike Champion: "those “legacy systems chugging along” work a whole lot better than HTTP for end to end secure, reliable messages, and the IT managers of the world have no interest in moving to the “modern” world of HTTP’s quality of service. There are only a handful of Web companies who have managed to do all this stuff (Amazon, eBay, etc.) that work has required hundreds of millions of dollars to hire extremely bright people who still required several iterations of their architectures to get to the current quality of service levels … and they do *not* interoperate with one another except via 'behind the eyeballs' integration (or read-only operations, of course)."

I hear this from time to time. If the web is fundamentally unsuitable for enterprise work then 'WS' has to be one of the most bone-headed marketing blunders in software history. So perhaps this is the real source of tension - why are these technologies called "Web Services"?

Aside from mine is better is better than yours, I do have a specific practical problem with these technologies being labeled as 'Web'. On every project I've ever worked on that has had enterprise and web dimensions, I've had to waste cycles on how the web tier should be modeled. Enterprise developers instinctively model the web interface as being composed of controllers and service endpoints. These are the same enterprise developers that will bore you tears about how Service Layers are crap (because they skimmed Martin Fowler or Eric Evans) and that we should all be using objects "properly" in the middle tier, often irrespective of whether you needed a object domain model or not. There's now an entire generation of enterprise devs who think WS and SOA are in fact how the Web should, or does work. It'd be farcical if there wasn't real money and real schedules involved. The irony is that you can apply good OO modeling practices as laid down by Ambler, and before him Fowler, and before him Booch, almost as is to web tier design (and then go on to consider the object representations and how aggregations should work). Getting people straight on this becomes more and more important when you realize that the Web is not just the presentation tier anymore; it's becoming a data integration and machine-oriented publishing layer. The presentation layer is being pushed down to the client machine in the form of AJAX, XUL and Flex.


February 24, 2007 02:04 PM

Comments

Mike Champion
(February 24, 2007 03:43 PM #)

I'm not sure what I said that you disagree with. As I see it, the IT folks of the world want to leverage the web's reach, I was just saying that the typical HTTP quality of service is not something they would give up MQ et al. for inside the firewall. The WS stuff's current niche as far as I can tell is to bridge across secure, reliable, blah blah internal systems by using the web as a (gasp) transport layer. In other words, the WS technologies enable (not "provide") more robust quality of service over the Web. That't not to say they should be stupid about the HTTP binding and forego the benefits of GET where appropriate. All parties who build large scale systems have a lot to learn from each other.

FWIW I very strongly agree with "the Web is not just the presentation tier anymore; it's becoming a data integration and machine-oriented publishing layer. The presentation layer is being pushed down to the client machine in the form of AJAX, XUL and Flex." (Althought I'd put WPF/E in that list going forward ...)

Bill de hOra
(February 24, 2007 05:42 PM #)

"I'm not sure what I said that you disagree with."

I don't have to disagree!

"As I see it, the IT folks of the world want to leverage the web's reach"

Operationally, that means punching through firewalls. Sure, I think that's an accepted view of the Web's utility value in some circles. I doubt that's sensible but there you go.

Anyway, the concern I have, is that WS isn't just about QOS or reliability or reach. It's about systems design and WS acts a forcing function for suboptimal systems design *at the point of reach* because of the emphasis on controllers and service endpoints. As an API technique it does not make anything else easier; for example monitoring becomes a nuisance because the things you want to monitor are not addressed. To monitor you have to query, which is a more complicated default that dereferencing the state using a key.

"In other words, the WS technologies enable (not "provide") more robust quality of service over the Web"

I would say the WS stack is seen to be far more ambitious. It's a design paradigm.

People absolutely do think WS is the way to model and think about the design of network applications, and that API techniques will apply well to web sites. That or I've been dreaming on the job for the last half-decade (and then some). I will not be surprised, not one bit, to be at some point to be arguing down some well-intentioned person who thinks the .Net framework guidelines are a suitable basis for a web site's information architecture. However, you don't tend to see REST types as much running around telling middleware types to deploy four method OO APIs at fine grain and that each object should be the moral equivalent of a web server.

"I'd put WPF/E in that list going forward"

Indeed! I expect the next generation of .Net studio tools to continue to focus on the widgets as they should. Much of the resistance to XUL I've seen (as an example) has been down to dealing with raw XML instead of UI components. If you look at the Ajax libraries like GWT and YUI, I think the next step are visual design tools. That would get them to circa 1992 in the desktop world.

Corey
(February 25, 2007 02:31 AM #)

"I do have a specific practical problem with these technologies being labeled as 'Web'"

I guess I never thought of it like that. I've always known that "Web" is thrown around in some odd ways, but never thought through the implications that might come with obscuring terminology.

linked and commented on:
http://www.goldb.org/goldblog/2007/02/25/TheWebAsADataIntegrationAndMachineOrientedPublishingLayer.aspx

Malcolm Tredinnick
(February 25, 2007 03:55 AM #)

The practical issue you raise in the final paragraph is something I've experienced too. Often, it is pitched -- in client meetings I've been in -- as being merely a coin-flip decision between using the web (wider network) interface as just an endpoint for tunneling back to the innards or putting some design work into that level, too, in order to make it ... well.. usable (although that's clearly not their words). Frustrating is a polite way of putting my feelings at that point.

I'm going to express this badly, but I often read the subtext of those debates (from the WS-* side) as "our stuff is very hard to integrate against; best leave that custom part up to us", whereas I would like to make a stab at "your stuff is hard to integrate against; can we ease the pain a little, since we have an extra layer at our disposal here?"

Bill de hOra
(February 26, 2007 12:06 AM #)

"our stuff is very hard to integrate against; best leave that custom part up to us""

And I have no argument with that. It is hard to integrate against; I've spent much time in the last half-decade figuring out how to do exactly that.

I don't think WS-* have done a good job of managing the complexity issues. There's this assumption that because enterprise concerns are complicated, that a) the web can't help, it's clearly too simple, and b) the people that created that complexity are the only people who can fix it, using much the same techniques that lead to the level of complexity in the first place. The first confuses complex results with complex causes. The second; well there's a good quote from Einstein about that kind of reasoning.

Two good examples of bad leakage:

From WS-* - programming language types; insofar as the much of the coal-face issues people end up having with SOAP can be traced to type mismatches between languages.

From Web - implicit defaults in markup; insofar as the much of the coal-face issues people end up having with XML can be traced to misunderstandings around default values (xml:base, xml:lang: xmlns, encoding)

The WS-*/REST debate is largely about determining layers. The question is whether and how that complication should be allowed bleed out (into standards) and whether or how it needs to be encapsulated.

Dan Creswell
(February 26, 2007 03:21 PM #)

Mike Champion said: "As I see it, the IT folks of the world want to leverage the web's reach, I was just saying that the typical HTTP quality of service is not something they would give up MQ et al. for inside the firewall."

Okay, so the IT folks want to leverage the web's reach - should the Web have to adjust to them or should they have to adjust to the Web?

It seems right now like IT expects more the former than the latter. Which is interesting given that likely as not the vast majority of the incumbent Web doesn't need/desire these things and sees no reason to change just because IT wants to come to the party.