Pragmatic Dictator

The “what is a JavaSpace debate” rages on………….

Fundamentally, I don’t see this as being an exercise in pragmatists vs purists. It’s a difference in engineering philosophy/taste. Personally, I see a JavaSpace as well, errr, a JavaSpace. There are lots of things you can do with it:

• Co-ordination mechanisms
• Systems of co-operating entities for e.g. locking, queues etc
• Compute Servers
• Messaging
• Caching

Note that all of these things can be built on top of JavaSpaces. This leads to two different schools of thought:

1. Make all these different things a part of a JavaSpaces implementation
2. Make all these things layered frameworks that live on top of JavaSpaces

Arguments for the first option are often on the basis of improving performance or “making JavaSpaces more useful”. But JavaSpaces is already useful, acting as good simple underpinnings for all these different things.

And this is why I personally prefer the second option. I’m a minimalist, I like my JavaSpaces nice and simple and I like being able to construct cleanly layered frameworks on top of JavaSpaces. This allows me to have nicely separated responsibilities at each layer leading to (IMHO) better, more understandable, more maintainable design in my systems. I also like to avoid building such layers on top of JavaSpaces if there’s something out there already that can do the job better in a specific scenario.

[ Yep, read that paragraph again and realize that I am both pragmatist and purist. How annoying that I cannot be easily pigeon-holed as one or the other! ]

There’s no accounting for taste but let’s be clear that it has nothing to do with being pragmatic or purist. It seems like Cameron also has a taste for minimalism……

Technorati Tags: design, engineering, philosophy

This is interesting:

“W3C members have issues surrounding enterprise computing. Not just distributed computing, but the typical concerns around transactions, scalability, high availability, and so on. Not only that they’re also dealing with 15, 20, and 25 year old technology that works just fine but is getting more and more difficult to maintain and doesn’t play well with others. Finally, there’s the issue of interconnecting these systems to each other, to partners, and to the Web.”

Once 15+ year old technology is getting difficult to maintain and doesn’t play nice with others, surely it’s time to considering throwing it out? Surely keeping it just forces all the new stuff we do to get bogged down and stifled supporting the old stuff?

I’m just wondering if the logical destination for this will be we can’t make progress any more because we get completely bogged down in our legacy? I certainly appreciate the companies holding on to so much legacy consider it important that the issue is tackled but should the rest of the world which is perhaps more flexible have to care? Should we constantly be bending all the good new stuff we do to cope with all this old crud?

If you buy a car there’s a limit to it’s useful life. You can keep running it after that but maintenance bills get higher and higher to the point where one gives up and just buys a new car because it’s cheaper.

Note also that the owner of this “legacy” car is the one suffering the high maintenance cost, not the manufacturer or the mechanic. Admittedly, the mechanic and the manufacturer must hold onto tools and parts but they can at a point of their choosing drop support. Should it not also be the case that companies holding onto legacy systems suffer similar high maintenance costs? Should these companies be able to displace those costs onto others in the form of horrendous complexity and endless legacy considerations in new products, specs etc?

Clearly there is no right answer for this dilemma but it might be time for us all to sit down and consider the whole cost of holding onto legacy which goes way beyond the simple increasing cost of maintenance.

If nothing else it strikes me as interesting that whilst IT pursues the concept of endless life for systems, nature provides many examples of limited lifespan as a useful tool for progress and sustainability.

Technorati Tags: enterprise, technology

I really like this interview with DHH.

Just listen to what he has to say about mainstream and the compromises that brings. And then think about what’s happening to the Java platform and the prevailing attitudes that drive the likes of J2EE.

And then see if you still wonder why these “upstart technologies” are gaining ground. There’s a lot of good stuff in here around pragmatic thinking, design philosophy and industry behaviours.

Doesn’t matter what your favourite programming languages are, this interview stands watching a number of times.

Oh, and the secret to Rails’ success?  DHH, not Ruby not Web 2.0.

Technorati Tags: Java, design, Rails, technology

I wrote something about parallels between distributed systems and real life which included some stuff on the bird flu’ outbreak here in the UK. Imagine my surprise when I saw this referral!

Made me smile anyways, not quite the readership I was expecting!

This really shouldn’t be difficult, it sounds like a repeat of the kind of issues we had with Applets. Didn’t we learn anything?

Once again, Java was built for this not monolithic, static applications, why is it so hard? Because we’ve not done anything to sort out issues with classloaders and remote code-loading or delivery of classes in .jars in a long, long time.

Sun, stop ignoring the core philosophy of your own software platform, please, it’s excruciating.

Technorati Tags: Java, technology

…..has been worshipped for a long time but there are various barbarian enclaves that are not ready to kneel before him.

Enterprises certainly want the money saving opportunities of utility computing options such as EC2 but there is evidence to suggest that RDBMS’en aren’t cut out for this role.

And recent statements on TSS suggest some people are at least beginning to think that we are mis-using RDBMS’en ignoring it’s lack of suitability to a task because it’s an easy option.

Time to seek a new religion?

Technorati Tags: amazon, distributed systems, enterprise, databases

No doubt many are aware of the fact that bird flu has hit East Anglia and there’s plenty of discussion about future implications so I shan’t be dwelling on that.

From a purely techie standpoint there are some interesting parallels with the way we build and deploy IT systems. Consider that the poultry farm where the outbreak occurred claimed to be keeping all it’s birds in buildings providing “secure biological containment” such that this sort of thing shouldn’t happen and yet it did happen and look at the damage! Does this remind you of the average corporate with all its systems centralized and hidden behind a firewall?

Since the original outbreak there’s been follow on discussion about what would have happened had the birds in question been free-range. These birds would, for a start, have stronger immune systems and not be so closely packed thus potentially limiting the impact. Sounds a little like a distributed system maybe?

What about issues related to the growth of London? Transport is over-stretched because there are too many people trying to get to work morning and evening. We build more roads or attempt to cram more trains into an already congested timetable which temporarily fixes the problem and attracts more people leading to a further transport disaster and so the cycle continues. Similar effects can be seen in locating suitable housing, refuse management and water systems. All of which sounds to me like the regular stresses and strains we suffer attempting to scale our centralized IT systems to cope with load.

One suggestion for addressing the problems involves moving business out of London to locations in Wales or the Midlands or Scotland. Of course, we’d need to improve the transport network making it easier to get to airports from these other locations, perhaps building additional roads to make access easier. The argument being that such a distributed approach might be easier to build, maintain and scale because it encourages more local commuting with fewer people converging on the same place. Sounds a little like the sort of approach used by MySpace or Google?

There are other examples of distributed systems lying around like the internal workings of our own bodies. And yet, in spite of a host of counter examples and failures we still feel compelled to pursue policies of centralization in towns, poultry farms and IT systems. Hmmmmm.

Dunno what it means, dunno who’s right (or indeed if anyone is) but it’s interesting for sure.

Technorati Tags: distributed systems, engineering, technology

Okay, so Patrick has laid down the gauntlet and I’m of a mind to pick it up but there’s a sticking point which is that I must earn a living. I simply can’t dedicate time to work on Jini documentation, books etc for free and it seems no-one else is willing to either. So, inspired by a tongue-in-cheek comment from Cameron and some other conversations, I have a tentative, likely insane proposition for feedback/consideration:

I’m thinking about something I’ll call “micro-consulting”. Normally people pay me by the day or the week to complete some agreed upon set of work products. What if I were to offer my time via the web an hour at a time to write documentation or code tackling some aspect of Jini usage? What if the entity paying for the hour of my time got to dictate or choose the subject I focused on? Perhaps the way to do this is to get together a list of possible projects, after which I would provide a “quote” for the work and then have people place sufficient “bids” against a piece of work to cover my quote. Whichever piece of work met it’s quote first would be the next piece of work I’d pickup.

Just a thought……..

Yep, there is a specification for JavaSpace bulk operations but it’s clear from recent discussions it’s still not well known. It was released in Jini 2.1 and provides:

1. Bulk write
2. Bulk take
3. Bulk read
4. New notify method

Bulk take and write are straightforward, bulk read less so because due to the nature of reads it has to provide a streaming style of interface. And the new notify method allows you to get a copy of the Entry which triggered the event but also provides facilities for Entry’s becoming available/visible again as the result of transaction aborts etc.

The JavaDoc for JavaSpace05 is here.

Technorati Tags: distributed systems, jini, javaSpaces, technology

The first Windows release for some time and the result is a deluge of nausea inducing TV adverts here in the UK. I do use the word “Wow” from time to time but I’m just not going to get that passionate about a release of Windows.

Seems I’m not the only person to be less than enthused…….

Notes on the human aspects of being a techie……….

Jim Gray going missing is a big deal not just because of his work on transactions, databases and the like - he’s a human being that made a significant contribution. Nor was he one-dimensional, hence his reason for being at sea and, if he is to be lost, perhaps this is the way he’d want it?

Good software comes from creativity, energy, pride, obsession, difficult to foster in a constrained environment such as the average enterprise where the “more code now” mantra is chanted un-ceasingly and without consideration for higher concerns such as pausing for thought or building creative, progressive solutions to business problems.

Why are we obsessed with one size fits all? There must be only one platform, there must be one framework, there must be one specification, we must all agree. This is mass adoption, not mass innovation. There should be no one size fits all but that’s where we try to go, destroying any room for individualism.

This stuff is important, there’s more to life than code. We claim to be a creative discipline and yet we hide from our emotion or attempt to control when/where/if emotional discussion happens. This is confining the human spirit, shying away from self knowledge, leading to a grey, featureless (work) life and stifles our creative selves.

Obsessively and mechanically adding features to language or system because they can be found elsewhere ignores the greater philosophical aspects. Languages or systems are styled, they are the way they are because they were framed by a particular line of thinking. Every little piece we add should also follow that line of thinking for otherwise we end up with an incoherent, complex mass.

Technorati Tags: engineering, philosophy, technology

I’ve lost count of the number of developers who rave at me about how things have advanced, “look at Spring or AJAX or ……” they cry.

But is anything really changing? I don’t think there’s any doubt that things are moving along but it’s at snails pace. Why? Because whilst we have a new tool or IDE plugin or container it’s based on the same old programming/architectural model:

1. N-tier
2. Application running in a single JVM
3. No concept of remoteness
4. Little explicit concurrency

i.e. Whilst we change the way we build our applications at code level to some degree, we don’t change our architecture or programming model. We are locked into one way of thinking and subconsciously enforce it on everything we look at. This lock-in causes us significant stress when we attempt to evaluate something with a different programming or architectural model with typical responses being:

1. It’s too complex
2. I can’t understand it
3. It melts my brain

But this is a good sign, this is real learning that stretches you in new directions and makes you a better, more rounded techie. If you don’t thrive on this stuff you can’t be cutting edge and you’re certainly not advancing significantly.

Think different - that’s genuine progress!

Technorati Tags: philosophy, technology

Common practice these days is to have a firewall between corporate’dom and the internet and only open port 80. It’s claimed this is secure but is it and what is this approach costing us? And is the price worth paying?

We tend to argue against open ports at the firewall for two reasons:

1. Denial Of Service Attacks
2. Hacks

Denial Of Service Attacks

The mere act of opening a port leaves one open to such attacks. The difficult bit is having access to sufficient resources with which to attack the target. This drives some to look for more sophisticated attacks that don’t require a “stampeding herd” of machines but there are very few of these people because:

1. You have to be expert
2. You have to have lots of time

In conclusion, denial of service attacks are a part of being on the net and firewalls help very little in this regard. What’s really needed is intrusion detection software and dynamic response/adaption something the firewall doesn’t facilitate.

Hacks

The reason a hack works at all is because it exploits some weakness in some service somewhere. But these weaknesses vary by OS, machine and software version. Blocking everything at the firewall works but really and truthfully we should:

1. Keep our machines up to date
2. Manage this machine by machine because they each have different needs and services

How Secure Are We?

Given the above we can see that boundary firewalls actually provide little effective protection against attack because to provide service, we must open the firewall and as soon as we do it, the hoardes can rush in. Certainly a firewall can stop certain kinds of packet spoofing, remote login etc but we don’t need to close all ports to achieve this goal.

In summary, firewalls are hammers and we are attempting to treat all security issues as nails to beat on.

The Cost of the “No open ports” Strategy

Because port 80 is the only one open, we are seeing everything tunnelled via http. This leads to a whole series of complications:

1. Not everything we would like to use has support for tunnelling over http
2. http is not suitable for all applications, it can be made to work but it’s complex and fragile
3. Given that all traffic looks like http it is difficult to manage/monitor traffic for individual services
4. Multplexing and demultiplexing all this network traffic manifests in our architectures - e.g. configuring our front-line httpd’s to redirect traffic based on URL components

Connection building in certain directions is impossible in most cases which denies us architectural options:

1. Callbacks are not viable - leading us to deploy polling solutions which perform badly and prevent us from building solutions that offer timely updates
2. Protocols other than http cannot be used

The border firewall becomes a point of contention trying to serve conflicting policies for individual services. Changes to the policy are slow owing to the need for agreement from so many parties or, in the worst case, no change happens at all.

We Really Need to Change

Firewalls as they are typically used are the software equivalent of a “Maginot Line” and history is littered with examples of failed border-control policy such that the military at least have learnt that defense in depth is a more appropriate solution. The “Maginot Line philosophy” denies us various software architecture options that would make our systems less complex and more scalable.

Certain elements might argue that all of this should lead us to base our services solely on the web architecture but that denies us certain kinds of desirable abstraction such that we expend lots of effort close to the metal attempting to force our solutions into a single generic approach. This would be somewhat akin to the pain we suffer trying to tunnel everything over http, not good.

Amazon’s EC2 provides some interesting possibilities in that it provides a more flexible firewall policy than straight border control and perhaps the most significant aspect of EC2 is that the firewall configuration can be controlled programmatically thus it would be possible for a service to configure the firewall to suit it’s needs on demand. If nothing else, such an option can speed up deployment removing the need to fiddle with http tunnelling and de-multiplexing or to discuss policy with a centralized admin authority.

In conclusion, we need to look at changing our policy and other approaches such as providing infrastructure that can secure individual services with appropriate policies from machine through to software level. Much of our current software infrastructure has little support for such a strategy and will need to change but surely it will be for the better?

Technorati Tags: architecture, distributed systems, technology

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

Notwork!

I’m currently in Boston, staying in the Hyatt Regency (Cambridge) they claim to have a premium internet access offering via wireless throughout the hotel. Hmmm, well if this is premium I dread to think what the normal service would be like.