Wednesday, 22 October 2008

Can SOA governance technology be distracting?

In a recent post, David Linthicum asks "Can SOA governance technology be distracting?". His answer is yes, and he offers the following sound advice:

First, only purchase SOA governance technology, if it's indeed needed, after you have a complete semantic-, service-, and process-level understanding of the problem domain. Never before.

Amen to that. In my opinion, for all but the most mature and involved environments, the procurement of an SOA governance platform should be well down the list of priorities. I'd add to David's list of things that need to be 'worked out' before you get that cheque book out:

  • What is your vision for governance itself? Do you want to adopt a 'iron fist' or 'hand in glove' approach? Is your registry going to be a mechanism for governing or a side effect of it?
  • Who's going to populate it? Have you got your analysis, design and development processes sufficiently honed that your repository isn't going to turn into a dumping ground of candidate services?
  • Have you actually got any services live yet? Governance is a whole lifecycle thing. Until you've worked out how you're going to deploy and manage services in the production environment and demonstrated that this works, how do you know what capabilities your governance platform needs to offer?
  • Most importantly: What are the use cases for your governance platform? Can you demonstrate that these use cases can't be addressed using your existing tooling (even if that's Microsoft Excel)? Be honest with yourself about when you're likely to implement these use cases. If the answer is further than one year away, then for the time, you might be wise to forget them. There is little point in spending good money on runtime governance or automated deployment technology when in a year's time you'll be able to get more for less.

A lot of projects using SOA governance tools at the moment treat them as glorified databases. If that's where you're at, consider using something less specialised that allows you to evolve your ideas, understanding and schema before you commit to something that will make this innovation harder and more time consuming. When you've spent six to twelve months getting your ducks in a row, so to speak, you'll be in a much better place to make decisions.

I'd really welcome stories from people about how they've implemented governance platforms in the past, whether they're informal (e.g. Wikis, bugtrackers, spreadsheets) or formal (e.g. IBM Websphere Registry and Repository, CentraSite from Software AG): What did you implement? What worked? What didn't? What would you do differently next time?

Sunday, 10 August 2008

Choosing an Open Source 'ESB' technology

I'm currently working to find the best Enterprise Service Bus for a project. Nothing unusual there. Something I've done a few times before. Except this time the requirements are a little more unusual than which kinds of transformation the tool supports.

Functional requirements:

  1. The ESB must fit with Smart421's SOA patterns.
  2. The ESB need not be a one-box solution. We're happy to mix and match tools around the outside. BPEL in particular is not necessarily a mandatory part of the core product.

On the face of it, not too tricky. In practice, maybe a little harder: In our view, the ESB isn't a piece of software in the first place, it's a collection of (continuously changing) standards and policies that govern the interactions that take place across the essentially empty void between two services, so we're looking for something that's compatible with that view, rather than something that wants to sit at the centre of the SOA universe (more on this later, perhaps). Let's look at the non-functionals:

  1. The ESB must be Open Source, be based on an Open Source product, or there must be an Open Source version available.
  2. The ESB must have an established presence in the market - the latest and greatest features aren't enough. We're looking for something that has some industry buy-in.
  3. It must be possible to buy in support for the product from a third party, should we need it.
  4. The ESB must support light weight development. We must be convinced that easy things are easy achieve, and hard things are proportionally (and not disproportionately) harder.
  5. The ESB must offer a non-functional envelope that allows it to support a large scale enterprise application, preferably without restricting us to vertical scaling.

I'm intending to follow a fairly standard product procurement process to help select the technology, so the next step is to set some more formal selection criteria and identify some candidate products to form the ESB core.

At the moment, the obvious candidates for me are:

I'll keep you posted as I progress... Comments/suggestions/vitriol welcome!

Monday, 28 July 2008

Battery Statistics

Simon Wilson recently explained that you can get information on the original and current capacity of your battery using the following command:

ioreg -w0 -l | grep Capacity

This works great on my machine, but just thought I'd mention that for those afraid of the command line, as I've previously mentioned, there's a great little utility called CoconutBattery which provides a GUI interface to all this. Try it, you might like it.

Tuesday, 8 July 2008

The start of a trend?

From MacWorld:

Huge newspaper makes Mac switch move - Mac - Macworld UK:

One of Europe's largest newspaper publishers, Axel Springer AG, has announced plans to migrate its 10,000 employees and 150 newspapers in 30 countries to the Mac

Speaking in a video message that's now available through YouTube, company CEO Mathias Döpfner notes the following four reasons for the shift:

  • 'Most of the company’s layout work was already being done on Macs
  • 'Macs are more user friendly than other computers
  • 'Apple creates the most elegant computers
  • 'Macs are cheaper to buy and easier to maintain than they were in the past.'

Could this be the start of a trend? I'm not expecting an avalanche of such announcements in the near future, but the world is changing. Microsoft seem to be suffering from horrendous PR problems at the moment, with people (regardless of the reality of the situation) starting to view them as dazed and confused. I saw a magazine cover the other day which posed (if I remember correctly) the question: "The end for Microsoft?".

The $64000 question for me is "are Apple really any better than Microsoft?" I think the jury is still out on that one...

Friday, 27 June 2008

Battery Woes & Coconuts


Why is it that all laptop batteries eventually die?

Whenever I charge my MacBook Pro completely, the battery meter stops at 98%, and the battery says it's charged. I'd like to think this just means that I get 2% less charge than I used to, but the reality is far less appealing. When I unplug the juice, my laptop informs me I've got 1:33 to live. I used to get at least 2:30.

I know it's a reality that laptop batteries behave like this, and I'm aware that nothing short of a breakthrough in chemistry is likely to change this, but what I would like to see is some kind of transparency about the state of the battery - an advanced battery meter if you like. Something that shows the theoretical battery capacity, the charge attained last time it was full and it's current level. The meter could also show the number of 'charge' cycles the battery has been through to provide a view of the likely useful life of the battery.

I guess it would look a little like this:


Thankfully, someone's gone to the trouble of doing exactly that. CoconutBattery provides all of the above information at a glance, allowing you to understand exactly the position you're in. Which in my case is that I'm the proud owner of one of the oldest MacBook Pro's on the market (29 months? Has it really been that long?), and its battery is getting a bit weary. Perhaps it's time to buy a new one...

Thursday, 15 May 2008

My other car's a jet powered wing-suit

Dear Santa, please find attached a video of what I'd like for Christmas this year. I know at first glance it might look a little dangerous, but it'd be a hell of ride...

From BBC News: Rocketman flies in the skies.

Thursday, 1 May 2008

Simulation based estimating

I'm sat on a train at the moment, from Norwich to Ipswich. This train will take 39 minutes to reach its destination. It'll then take me 7.5 minutes to walk to the office, 1.3 minutes to make a coffee. I'll be ready to work at 08:17:48. Obviously, I'll stop to take a sip of coffee at 08:17:57, 08:18:20 & 08:18:50, and a large, cup emptying slurp at 08:19:20. Other than that though, it'll be working straight through 'till 17:30:00. I will not get peckish and stop to raid the snack machine. There will be no interruptions. Nobody will, at short notice, book a meeting or pitch up at my desk for an impromptu chat about the current status of Project X or Initiative Y. My fiancé will not send me an SMS asking me to pick up a bottle of wine on the way home, and absolutely no recruitment consultants will call. All my days are like this. I never have a bad day, never fail to get my head around the task at hand first time, never struggle to think where to start. All my tasks are predictable, have well defined goals and require no assistance from anybody who might be having a bad day. Of course, in this environment, I deliver what I said would, when I said I would with 100% certainty, every time.

Of course, I'm dreaming.

The reality is that nothing about the average day of the average employee is in any way precise. My train might take 39 minutes, or it might take 41, or if I'm lucky and there's a northerly wind, it might take 38 minutes and 59 seconds. My walk will be marred by traffic lights, and I (shock) will have bad days. If I were to use the fingers of every occupant of this rush hour train to count the number of times I've been asked by a project manager over the last 10 years "How long will this project take? How much will it cost?", I'd probably have no more than two fingers left to type the remainder of this post.

The trouble is, you see, I don't know.

Don't get me wrong, I can estimate things as well as the next guy - it's just counting widgets at the end of the day, but I know I'll be wrong. Of course, project managers are reasonable people, they say things like "Well, we have to be 100% confident in this estimate, so we'll add 10% contingency to your total, ok?" No. Not OK. The issue here isn't that I under-estimate routinely (although that might well be an issue), it's that adding ten percent will not make any estimate 100% confident, and nor will adding thirty, one hundred or even three hundred percent, regardless of how good an estimator I am.

Anyone who remembers the whale and bowl of petunias from Douglas Adams' Hitch-hikers Guide to the Galaxy will remember that according to Adams, the sudden appearance of flora and fauna in deep space is unlikely, but none the less has a real finite probability. Perhaps somewhat shockingly, this sort of thing is a reasonably well accepted side effect of quantum mechanics; this could happen at any time in any place. You could be just tucking into a medium (sorry, Grandé) cappuccino at your local Starbucks when something, anything, appears. House, car, cat, dog, frog, you name it. Now, just to stop you panicking over your caffeinated beverages, the chances of this happening are infinitesimally small, but it serves to illustrate the point that you never know what might get in the way of your project.

So, finally, to the point of my post. I think it's time estimating grew up a bit, and stopped pretending that it knew all the answers. What's needed is a way of estimating the cost and duration of a project that softens the boundaries a bit, and gives a truer picture not of how long a project will take, but how long it might take. Imagine for a second that a programme manager knew that there was a 66% chance that the project would be in by Christmas, and a 88% chance it'd be in by June. He'd probably be much more likely to give the board a sensible message than if all he had was a vague message from you that it could conceivably be done before the turkey gets cold. Equally, those of us who sometimes work on fixed price contracts would have a much better way of assessing the risk of a given project, allowing us to reliably turn a profit while offering a good deal for the client.

It strikes me that there are two approaches that could be taken to this:

  • Use probability theory to attach a probability distribution to every input parameter in the estimating model, and then carry these through the model and give a final probability distribution at the end. Complex, nasty, not much fun unless you have a PHD in applied statistics.
  • Make the input parameters to the model fuzzy (more on what I mean by this later) and then run the estimating model over and over again, collect all the answers and build a histogram (chart) out of the results.

I've thought long and hard about this over the last few years, and frankly the former option is beyond the capability of my AS-level statistics. Even if it wasn't though, I'd be recommending the latter, and here's why: It's intuitive. What you're doing is running the project over and over again, and seeing how long it takes. Project leaders can be old and wise without being old and wise; they've already done this project 1000 times (albeit in the mind of a machine), so they've got a good idea how long it might take.

Using this approach, you could build absolutely anything into your model; Productive day averages 6 hours, but varies between 2 and 20 hours on occasion? Sorted. 0.04% chance of aliens abducting your senior developer? No problem, at least for the project. The options are endless.

Nicer still, because this approach uses simulation rather than algebra, we don't need to be too anal about how the parameters are set. If it's easier to say "95% of the time it'll take 5 hours, but 5% of the time it'll take a random value between 8 and 10 hours", then that's fine. We don't have to put together some strange combination of probability distributions that models this; we just run with it. Equally, if you have a set of example data to use as a basis (well, this system has N classes, and it took X long), then these values could be used directly, without having to build a complex model from them first. That said, if the guys doing the estimating do understand probability, then they can use a Poisson distribution to determine how many use cases will be delivered by a week next Friday if they so desire.

Equally, because we're actually running the project, we can apply all sorts of interesting things to the model that would be impossible using a purely statistics driven approach. For example, in an agile project, we can simulate the team size and length of sprints against the simulated sizes of the products to determine the optimum length of a sprint for the project. We could simulate the quality of deliverables based on whether code reviews are expected, and use this to estimate the impact on the length of the test cycle. Obviously, this stuff is a bit trickier to achieve than answering the usual how long/how much question, but it's always good to know there's scope to develop things further in the future.

The architecture underlying this kind of estimating machine is pretty trivial. I'd say, with 100% certainty, you could deliver the underlying engine in 27 hours, 5 minutes. Elephants and petunias not withstanding.

Thursday, 27 March 2008

Martian Headsets

A colleague just pointed out a brilliant article from Joel on Software discussing the upcoming release of Microsoft's IE8. If you care about the web, have a position on web standards, consider yourself an activist, pragmatist or martian, then read it. Now.

Friday, 21 March 2008

TimeMachine with AirPort Disk: Finally

Apple yesterday released updates to their AirPort Extreme and TimeCapsule base stations and Time Machine which allows Time Machine to use an AirPort disk for backup (I have an extreme with about 1.5TB hanging off it). Finally. For those of you with a laptop like me, this means you can have a safe and secure Mac without living life in a bird's nest of cables and disks.

I configured it with a new disk yesterday, and it works great - just connect to the drive (by clicking on it in the left bar in Finder), and it appears in the Time Machine window and can be selected as the target for backups. The good news is that it seems very stable and happy - putting the laptop to sleep and waking it up again during a backup seems to have no impact, which is great. The bad news is that I started my first backup more than 24 hours ago, and it's still running. Whoops. Learn from my mistake: do your first full backup with the drive physically connected, otherwise you'll spend the next three weeks watching paint dry.

All in all though, it's great news that those of us that invested in AirPort Extreme base stations are being given the same privileges as those investing in brand new Time Capsules.

Wednesday, 19 March 2008

Oh Joy: High Court rewrites UK software patent rules

From Computing:

High Court rewrites UK software patent rules:

"The High Court has passed a ruling that for the first time allows computer programs to be patented in the UK.

"The decision came about as the court upheld an appeal from Symbian following the rejection of an application the software firm made to the Intellectual Patent Office (IPO).

"Symbian filed for a patent relating to the way computers use a library of functions that can be accessed by programs."

I'm hoping this is a storm in a teacup. IMHO, software patents are a fundamentally flawed concept which I'd hate to be subject to. Patents were designed to protect inventors of physical products, for whom the 'invention' bit was just the start of an enormously expensive journey to success, which could be upset at any time by a competitor with better tooling or more staff. As I understand it, you wouldn't normally go and get a patent until you've created your first production prototype.

This simply doesn't apply in the software world - by the time you've implemented your production prototype, you're 60-80% of the way there: Functional, non-functional and user acceptance testing are the remaining barriers to distribution. You don't need to tool up a multi million pound factory, you don't need to employ 20 staff to work the machines. In the general case, there are no boxes to pack, no labels to print, no lorries or fuel to buy, no returns to process, no replacement goods to ship. What's more, someone with more developers or a more established shop often isn't better placed to produce your product than you, the inventor.

This is what is so beautiful about software. Some of the best software in the world was written by small teams of very smart people, who had a good idea and ran with it before anyone else got a look in. I'm sorry, but if the big boys can't keep up with two guys, one girl and a dog working in their shed, then maybe it's time to consider a divestment.

And Breathe. . .

Friday, 14 March 2008

บ้าน (home)

I crawled into bed at 1am last night, no less than 25 hours after getting up. Paradoxically, I only got up at 7am. Aren't time zones wonderful? I've just got back from a business trip to Bangkok and thought I'd post some lessons learnt. In no particular order:

  • The weather in Bangkok is hot. Wear short-sleeved shirts. Don't wear ties. Wear a suit jacket when you go out in the evening, you'll look like an idiot. And I did.
  • Don't cross roads until you've looked left, right, up, down and have resolved any outstanding issues with your life insurance.
  • When you enter your airport taxi, note that it will take exactly 27 minutes before you realise you are not about to die. It'll take another three minutes before you take your hands away from your eyes long enough to notice that none of the cars weaving between lanes have dents, and decide that they are clearly made of reenforced diamond. Or decide that Thai drivers are considerably more talented than you, I or Jeremy Clarkson. Yes, really.
  • The people in Thailand are friendly, polite, and remarkably tolerant of our lack of aptitude for their language. Say "thank you" using the feminine version of the phrase for three days, just to keep them amused. We did.
  • You've not seen value for money until you've been to Bangkok. Stay in a hotel room as big as your house for £70 per night. Spend 45 minutes watching the meter in a cab slowly reach the £2 mark. Now try doing the same in Farringdon.
  • Towers in Bangkok are tall and numerous. Ours had 38 floors. Take pleasure as the high-speed lifts make your ears pop. Bring sweets. Yawn liberally.
  • The Starbucks franchise covers all corners of the earth. I strongly suspect they have spread to all nearby star systems.
  • Jet lag is a killer. As is the dawning realisation on your exit from Heathrow airport that the English weather is, frankly, rubbish.

More seriously, spending a few days talking to these guys taught us a thing or two about how to communicate with people when you don't speak their language:

  • Don't underestimate the people you're talking to - remember the issue is one of communication, not capability.
  • Explain things in simple, but not patronising terms - using colloquialisms or slang won't help. Remember that some phrases that are in common usage in the UK might well not translate: We spent two days using the word 'business partner' before realising that this had been misunderstood.
  • Use diagrams. "A picture is worth a thousand words" has never been truer.
  • Give it time: You might find you need to explore new ways to explain things in order to hit the right buttons. Talk around the subject a bit, go back to basics, find the hooks in their heads that will allow them to understand.
  • Find time to swap stories and compare cultures. Not only will this build rapport, but it'll help you to understand where your audience is coming from and what drives them.
  • Solicit feedback and encourage questions; you'll get a far better picture of your audience's level of understanding by allowing them to challenge and push back than you will by blindly blithering on at them for days on end.

Saturday, 8 March 2008

So what is service reuse anyway?

Keep climbing and you might just get some reuseJust read an post over at InfoWorld by David Linthicum. The central point of David's post is that reuse shouldn't be considered or advertised as the 'core value' of SOA. I totally agree with that, particularly as often, organisations still insist on setting up SOA projects, rather than changing the mindset and method of working to encourage the adoption of SOA across projects.

To me, half the problem with the reuse argument is that people don't have a clear understanding of what is meant by the term. Often, people consider that reuse is only achieved when a service has more than one consumer within the SOA at a point in time, but (to me) that's missing the point. An SOA is not a static environment; in a well managed organisation, it'll change almost continuously. To me, you're achieving some level of reuse whenever you fundamentally change a business process without having to re-hash all of its services, or you don't have to bother re-testing every combination of parameters to a complex business process because you know already that the services that underly it, which make all the hard decisions about someone's credit worthiness have been tested thoroughly already. You even get re-use whenever you say "Ah, well, we'll apply our standard grade message integrity policy to that service, so we know how to achieve that".

If you take this broader view (let's call it long-term reuse), then long-term reuse and agility become somewhat interchangeable concepts - you get agility through being able to reuse a service across two versions of the same process, by knowing that you've already tested a given service to death, and by not having to make complex technical design decisions each time you create a 'new' service.

So. I agree that the reuse should not be used as an advertising 'headline' for SOA, because in an advert (be it literal or spoken), you don't really have the time or bandwidth to get some of the subtleties of the above across. But in reality, over the medium term, I think we will find that the long-term reuse achieved (assuming for a moment you buy into my definition) is significantly higher than people currently expect.

The last point I'd make is this: If you design your services for immediate reuse, you will likely fail to achieve that re-use. If on the other hand, you design your services for change, and aggressively factor new functionality into them as new consumers require it, I suspect you'll find even 'point in time' reuse increases dramatically over the medium term.

Friday, 7 March 2008

iPhone Killer App: OmniFocus

I've been putting off buying an iPhone for months, as I've already got a mobile contract with Vodafone, and funnily enough, they're not too keen to let me out of it so that I can defect to the competition. However. But. My resolve is failing...

The Omni Group have just announced on their blog that they're intending to release an iPhone version of OmniFocus.

Despite my resistance, there is a 97.4% chance that on the day OmniFocus for iPhone is released, I'll be in the queue in my local O2 shop to pick up an iPhone. My life currently resides mainly within the Mac version of OmniFocus, and my main gripe with it is that taking my laptop out on the road is a real pain. What a joy it would be to be able to leave the thing at home and not forget to breathe in and out.

I'm practically salivating with Getting Things Done goodness, can you tell?

Tuesday, 26 February 2008

On Escalating Communication

Bad day at the office, darling?

Just read a good article from Jeff Atwood over at Coding Horror, On Escalating Communication which discusses the need to communicate not only the right message, but through the right medium. Amen to that.

I had an experience yesterday where I found I was writing an e-mail on a politically sensitive issue which had the potential to blow up in my face (personal situation, I hasten to add - nothing to do with work). Now, there are two approaches people take when writing an e-mail like this. 1) The Grenade: Don't worry too much, toss it over the wall and apologise afterwards. 2) The Gold Brick: Contextualise and rationalise your argument to the point where it is seemingly incontrovertible, but consequently also impenetrable and arrogant, then toss it over the wall and knock the poor recipient out. I'm generally in the latter group.

I went ahead and began to contextualise & rationalise my key message: "I won't pay XXX for YYY, try again." By the time I finished, the e-mail was 7 paragraphs long, explained my full life story, described my rationale for believing that XXX wasn't the right price for YYY, justified it to the 359th degree, turned around and touched its own toes, but didn't really send the right message. Why? It was too inflexible a communication mechanism for the circumstance. There could be any number of reasons why YYY was overpriced, or XXX was too much. Sending the e-mail as it was could potentially have blown the whole situation out of the water, disenfranchising the vendor and leaving me without my YYY.

In the end, I saw sense and 'phoned the vendor and sorted things out. They're still mulling things over, but I'm confident there's a much better chance of getting the right answer than if I'd hit them on the head with a gold brick.

How do you tell when you're trying to use e-mail to do something it shouldn't be used for? I suspect the answer is simple: If you feel you're having to cut corners in your communication, or you feel like you're trying too hard, then you're probably using the wrong medium. Time to upgrade to a phone call or, heaven forbid, a meeting.

Monday, 25 February 2008

Risk Management Faux Pas #374: Pilot sacked after fly-by stunt

Andrew just pointed me to a rather amusing article documenting the impending career failure of an over-excited Cathay Pacific pilot, who decided that performing a fly by in a brand new Boeing 777 at an altitude of - wait for it - 28 feet would be an excellent career move.

Two facts strike me as interesting about this. The pilot was (a) 55, and therefore presumably aware that this kind of behaviour was unlikely to be well received, and (b) flying a plane containing 69 senior Cathay Pacific staff, including their UK chairman. Maybe he thought he'd sneak it under the organisational (or real?) radar...

Sunday, 24 February 2008

IBM WAS: Fast? Yes. Central to SOA? Only in marketing.

IBM recently issued a press release stating that "WebSphere Application Server, a key building block for services oriented architecture (SOA), shattered a popular industry benchmark for scalability and performance by more than 33 percent using technology that costs half the price of the competition".

First of all, Kudos to IBM for continuing to improve the performance of WAS. Anything that drives the performance of key bits of infrastructure has to be a good thing. However, that's not the thing that caught my eye about this article. Instead, my eye was drawn to the statement that WAS is a "key building block for services oriented architecture". Let's consider where IBM was coming from when they wrote this:

  • IBM WebSphere Application Server forms the foundation of IBM WebSphere Process Server, IBM's middle of the road (as opposed to specialised) 'SOA Platform' offering.
  • IBM WebSphere Application Server is the leading (in terms of sales, at least) J2EE platform.

Maybe this is where IBM were coming from. It's true that WPS has significant take up in the market, usually within SOA projects, so I guess you could argue that WAS is the foundation to something which acts as part of the integration infrastructure underlying SOA projects. Alternatively, perhaps they're considering WAS in its own right. It's certainly an excellent platform for building and deploying the business logic which drives the behaviour of service implementations.

But (and in my opinion, it's a big but) the key to SOA is hidden cunningly in the name. It's Service Oriented Architecture not service oriented application-server, service oriented platform or service oriented infrastructure. SOA is about structuring your solutions according to service oriented principles, governing these solutions to ensure that they all contribute to an enterprise-wide ecosystem of services. To me, a key SOA principle is to be globally independent of any one third part product, and understand before you start how you can migrate away from the platform in the future. Therefore, to state that a product is a central component of SOA as a whole is misinformation at best, and could if taken literally be very dangerous for the ongoing health of your company.

I know that sounds melodramatic, but there's method in my madness: If SOA really is The One True Way, then it'll outlive any product (and possibly several of the vendors) currently in the market. If you couple your SOA vision to an individual platform, then you risk creating yourself a huge migration issue, comparable to nothing you've seen previously when the market inevitably moves on to new products in the future.

Thursday, 21 February 2008

Annoying issue with Maven Archetype plug-in

I've just spent an annoying fifteen minutes battling with trying to get Maven to download and use one of the ServiceMix archetypes. After some battling, it transpired that there's a bug in version 2.0-alpha-1 of the Maven archetype plug-in (or at the very least, there's a change in there that upsets the apple cart as far as the current repository goes). The solution seems to be to force Maven to use version 1.0-alpha-7 of the plug-in by either manually running:
mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create ...
... or if you're using ServiceMix like me, editing your smx-arch.bat or file to include a similar change. This does all rather make me think that the Maven guys need to concentrate a little more on governance of change to their plug-ins. Replacing a plug-in that works with a plug-in that doesn't, and making the whole world adopt it by default is not a good way to make friends and influence people.

Wednesday, 20 February 2008

Web Service Threats

I've been doing some work recently that involves enumerating the potential threats faced by SOA implementations. To help Google, here are a few of the resources I've found useful in doing so:
  • ZapThink - XML Threat Management: As you'd expect of ZapThink, a good high-level description of XML threats in general, but no specific terminology for individual threats, and no categorisation of threats.
  • Forum Systems - XML Threats: Forum Systems sell XML/web service security products, so as you'd expect they're hot on illustrating the risks associated with using Web Services to customers. Nothing like a rainstorm to sell umbrellas. This page provides a very high-level summary of the types of attack vectors used by malicious service consumers; a companion white paper, "Anatomy of a Web Service Attack" provides a lot of additional detail explaining these types of attack.
  • ZDNet - Five things you need to know about Web services threats: A useful article by Scott Morrison, Director, Architecture and Security at web service security firm Layer 7. Gets away from talking about specific threats, and talks more about the goals and high-level approaches used by attackers. Well worth a 10 minute read.
Interestingly, there doesn't seem to be a consensus over a taxonomy (categorisation system) for these threats. Possibly the closest we get is in Scott's article, where he suggests that all web service threats can be put in three categories: API, Infrastructure and Transaction attacks. Sadly, Scott doesn't go so far as categorising the threats identified by the other vendors. Hopefully when this picture emerges, it'll represent industry wide consensus. This should allow vendors such as Layer 7, Forum Systems and IBM (with their DataPower range) to communicate with customers in a consistent manner, and allow them to sell their wares based on customer need and product capability, which after all is the key to long term relationships and repeat business.

Wednesday, 6 February 2008

HTML Tip: Coloured bullets using CSS

In a bit of a departure from my normal work, I've been putting together a set of HTML templates and screen designs for a prototype. The company I'm working with has a very strong brand, and the standard text-coloured bullets just weren't quite right. I did a bit of googling for approaches to making this work, but most of them involved wrapping the 'text' part of the bullet in an HTML element:

  <li><span class="text">Bullet text</span></li>

ul {color: red;}
ul .text {color: black;}

I don't particularly like this approach, because it involves adding additional markup to deal with styling, which is bad news. Instead, I came up with the following approach:

  <li>Bullet text</li>

ul {color: red;}
ul li:first-line {color: black;}

This approach works because it asks the browser to render the first line of the bullet in black, and most browsers don't consider the bullet itself part of that first line. Sadly, almost inevitably, this doesn't work on Internet Explorer. Sigh. None the less, if you're looking for a clean way to deal with this that works with most browsers, and you're not too worried about the dwindling numbers of Internet Explorer users, then this approach is worth a look.

Tuesday, 22 January 2008

Runtime SOA Governance

I've recently been asked to define Runtime SOA Governance in the glossary of a project, and having looked high and low, have come to the conclusion that there is no widely accepted definition of the term, which is somewhat surprising given the number of product vendors who mention the term. Despite the risks to my personal safety of doing so, I have come up with my own, which I am only vaguely happy with: Runtime SOA Governance provides a mechanism allowing information about the operation of a running SOA environment to be fed back into an organisation’s SOA governance function. The information gathered may include:
  • How often each service is invoked.
  • Which services each service invokes.
  • Whether services are meeting their service level agreements in terms of availability, reliability and performance.
This information helps to support investment and change decisions by giving the governance function a better understanding of the runtime behaviour of the services. If you have a better definition, do let me know...

Saturday, 12 January 2008

Apprentice Jedi seen in Norwich

A friend (thanks John) just sent me a link to a news story about an 11 year old boy who defended his mother from attack by an unknown assailant with - wait for it - a light sabre. Maybe it's time to upgrade my car to a Millennium Falcon; keeping up with the jones has never been so expensive...