Pragmatic Dictator

Nick Gall (Gartner) has published a position paper on WS-* and The Web. This statement has drawn quite a lot of attention:

“Unfortunately, Web Services, at least the WS-* style, are “Web” in name only. While WS-* enables tunneling over HTTP (used merely as an XML message transport), in almost every important aspect, WS-* violates (or at best ignores) the architectural principles of the Web as described in the W3C’s Architecture of the World Wide Web, Volume One and in Tim Berners-Lee’s personal design notes.”

Personally I find this statement completely unsurprising as all it really says is that The Web is not the same is WS-*. Perhaps some people are upset because WS-* aka Web Services dares to make use of the word Web. That might even be a reasonable complaint but does it really matter? It seems to me that this part of the paper is a lot more incendiary and far more significant:

“The large set of WS-* specifications is almost entirely focused on recreating traditional middleware capabilities using XML as the syntax for the formal message structure and the formal interface description.”

Which appears to be saying (at least to me) that WS-* is nothing new and thus all the hype about how it’s a great step forward starts to look rather lame. That’s not to say WS-* won’t have it’s uses but it’s no more of a cure-all than The Web or anything else.

[Update: Bill has clarified the posting I link to above, stating that his interest is in the fact that the likes of Gartner are acknowledging that The Web does indeed have an architecture.]

Technorati Tags: architecture, distributed systems, technology

Any time we make a decision to ignore a problem, or attempt to work around it, we make more work for ourselves.

That additional work turns into something akin to the death of a thousand cuts. The problem never goes away and the associated consequences continue to manifest all over the place. And as the problem gets tougher so there are more and nastier consequences to deal with and they are harder to work around. Eventually, something has to give…….

This is really a long hard-learned life lesson which has some convenient applications in software engineering…..

Consider a bug in some code you’re using - if you don’t fix that bug, you end up dotting workarounds all over to cope with the presence of this bug. The same problem occurs with a badly written API, all around your code there will be compensations for it.

I was reminded of this recently when discussing code-lifecycle issues which is a nasty problem, make no mistake. Some members of the discussion wanted to accept the issues as unsolvable and work around them leading to hideously complex architectures and masses of code scattered all over the system. Myself and a couple of others felt it better to tackle the problem head on and came up with a simple solution that’s small and easy to use. Most importantly, the solution relieves us of the burden of tackling all those hideous consequences.

This lesson can also be applied to systems architecture in general. For example, the general policy to place firewalls at the borders of corporate networks which accept nothing unless it’s on port 80 has resulted in a raft issues which exert significant costs on our software and hardware infrastructure.

Technorati Tags: design, philosophy

As I’ve said in a previous posting, I’m not a fan of infrastructure level clustering. It basically comes down to the fact that this kind of approach to resilience and scale is achieved through centralization and strict control of the environment. Whilst such a level of control and centralization might be possible in certain well-defined, small scale circumstances, it gets much more difficult across a network of any size and with any more than a few machines.

There are other problems too like the fact that clustering in this fashion is infrastructure specific not application specific. Basically, the infrastructure will offer you configuration options that fit with what the infrastructure can support/implement generically in an application unaware fashion. You must then fit your application around what the infrastructure will offer which can mean design or performance compromises or maybe maintenance load (hand-holding by system admins etc).

There can be no argument that many adopt this approach and accept the compromises and for a certain class of system, as I’ve said, it’s probably acceptable. However, the typical profile for most systems is that they grow and evolve over time such that those compromises you made are no longer acceptable or viable. They become an albatross around the architects neck. Witness the number of people entrenched in battles to get scaling out of application servers or to add new services etc.

This approach to clustering often goes hand in hand with the denial of the realities of networking. It’s often assumed nothing breaks, there’s always enough bandwidth etc. And everything is coded like it runs in one JVM creating a single difficult to manage monolithic piece of code (something I find ironic given that the people that adopt this approach quite often talk about loose-coupling, service oriented architecture, networked applications etc) which is deliberately naive of it’s under-pinnings.

In an ironic twist, the people that choose to build things this way then throw their hands up in horror and complain when things become difficult to scale, or they haven’t got the level of control they want or they don’t like the way their code has turned out or whatever. What did they expect? They turned all these responsibilities over to some vendor’s software stating “I don’t want to deal with that, you handle it, just tell me what to do” and then in the very next breath said “why on earth did you tell me to do it that way?”

So if I don’t want to suffer this, what might I do? Start looking at building more modular, network aware modules which can be dynamically interlinked at runtime. And find a way to achieve resilience/scale at application level using simple unreliable components. I said in my previous posting:

“I can’t help but feel that there must be a better way……..”

Yep, there is - and I have a prototype to prove it. And, in case you’re wondering, yes the prototype does have persistent state and no it doesn’t require RAID or any other cool hardware, a bunch of blades on a network is all that’s needed. And of course, it uses Jini.

These are currently being standardized but I gather there are implementations available already. If you want to read the specs you can find them here.

Whilst I understand the technical reasons for having these API’s - basically that a “managed environment” can’t support the existing equivalent API’s in the JDK (java.util.Timer and java.util.concurrent.*) there are some other things about this work that I find a little concerning.

Firstly, that part of the justification is about having simpler API’s than what’s in the JDK. What does that say about what’s in the JDK? Which programmers are the intended audience for the JDK API’s versus those in the JSRs which are J2EE oriented. And what does that say about the respective levels of ability of these audiences? Are we really suggesting that J2EE programmers aren’t as smart as those that might use the JDK? That doesn’t sound like a good thing to me for all sorts of reasons.

Secondly, these JSR’s are to all intents and purposes replicating API’s we already have in the standard JDK. Were I to see this kind of duplication in a customer’s architecture I’d be seriously concerned and quoting such things as the DRY principle (which actually goes way beyond the simple issue of not duplicating code). Is it really a good thing for J2EE to be going down a path of duplicating existing standardized functionality bent to it’s own needs? Might there not be something wrong with the model?

I gotta say that these JSR’s have a bit of an odour to them - good or bad I haven’t decided yet……….