-
Of all the transactions to lose, let’s hope it’s not this one.
-
It’s JavaOne, but not as we know it.
Comments Off
Archive for January, 2007I’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:
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:
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
Now it’s Java properties. I say once again - the last thing to do is to extend the language. Before that try a new API or have your IDE do it. In the case of Java properties I really don’t see any reason whatsoever for this being in the language as it’s blatantly something that can be done in the IDE plenty well enough. That just leaves a couple of arguments:
Elliotte and others already have the rest of the reasoning nailed so I’m not wasting any more breath.
29
01
2007
 
The Evil That Firewalls DoPosted by: Dan Creswell in Architecture, Distributed Systems, TechnologyCommon 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:
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:
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:
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:
Connection building in certain directions is impossible in most cases which denies us architectural options:
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
27
01
2007
Nick Gall wades into the WS-* debatePosted by: Dan Creswell in Architecture, Enterprise Systems, TechnologyNick 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.
25
01
2007
Solve the Problem or Suffer the ConsequencesPosted by: Dan Creswell in Architecture, TechnologyAny 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
Is a (popular?) saying that essentially means “There’s more than one way to do something”. And the fact that there are many ways to do things makes for a lot of fun, after all variety is the spice of life! But it also brings a burden of having to sort through the options and pick the one most appropriate. This should all be horribly familiar to most of us but I’m going to concentrate on engineers for the rest of this blog. See, engineers do some peculiar things when confronted with this reality:
If you have any of these tendencies take note:
Then take a break, go get a chill pill and mend your ways. Be a little less prescriptive and thrive on that variety. Technorati Tags: philosophy, engineering
|
Entries (RSS)