The wonder of the obscure bug

I've just spent a highly entertaining(?) couple of hours trying to debug some Hibernate access code. The basic problem is that I have a primary key on a database with two elements, one called ATTRIBUTE_ID the other called ATTRIBUTE_VALUE, and I was getting exceptions about not being able to set the values or perform the mapping. I change the latter to ATTR_VALUE and everything works.... I've done a quick grep over the source to see if I can see what is doing this... but I can't find it.

But this has brought to mind finding other obscure bugs over the years, mainly I have to say with Java, elements like running JMS, MQSeries and AIX and finding out that it just doesn't work, and the reason was that AIX had a strange shared memory model and IBM had decided to use the same number for the JVM and MQSeries... muppets. And as for experiences using wonderful elements like early releases of various app servers, MQSI in a heterogenous environment (with MQ Pub/Sub).

I'll let the folks at Hibernate off though as its an all around cracking product and it was a minor fix. But it just goes to show...

Some times it isn't actually your fault when the code goes wrong... oh and that most vendors don't appear to have a unit test framework.

How do you define a Service ?

I've been using various tools from different vendors over the past 12 months, all claim that they are for "Service Oriented Architecture" and yet none have an effective way to define what a service is.

Some, like BEA's Weblogic Platform or the unbelivably large install of WBI-SF 2GB for godsake, provide a software container (BeeHive for BEA and WS-IF for IBM) but these are really developer tools rather than architecture tools to define a service. The objective of a service definition should be to define a discreet boundary within a system, this should then be de-composable into further services which can be co-ordinated together. The key is that service comes before process. Most of these tools (especially ones like WBI-Modeller) stress a "Visual COBOL" approach to systems design where the process is more important than the service....

So when vendors say they do SOA, right now every one I've seen means "We do Process Oriented Architecture", it was wrong with COBOL, and its still wrong now.