Debugging SOA

Last month on my blog, I wrote about how my choice between two bookmark-sharing applications -- Rubric and Scuttle -- tipped in favor of the latter when I couldn’t debug a database-related problem with the former (infoworld.com/2833). Rubric, like most Perl-based software, relies on a bunch of CPAN modules. In this case, the Class::DBI module, an object/relational mapper, was throwing an error. I’m sure the cause was something simple, but when I began to spelunk around inside Class::DBI and its dependent modules, I concluded that I was on a slippery slope.

So I switched to Scuttle. There too I ran into a database-related problem. But because Scuttle’s relationship to the database was less abstract, it was easier to find and fix a problem.

Tony Bowden, the maintainer of Class::DBI, spotted my posting and wrote to tell me that my experience wasn’t unique. Historically, users of CPAN modules were programmers who invested in learning how they worked, and whose applications were tightly bound to modules in ways that made problems relatively easy to diagnose. Nowadays, use of CPAN modules is increasingly likely to be indirect, making wholesale reuse of applications that rely on the modules. From that perspective, Class::DBI is in theory just plumbing that the application developer needn’t even know about. But in practice, when things do fall apart, there’s no obvious way to put them back together.

“The super-programmers of the next few years,” Bowden said, “are going to be those who keep track of all the reusable applications and know how to glue them all together.” We agreed that in this service-oriented environment, debugging and error-handling are going to be major challenges. The same issue came up at InfoWorld’s SOA Executive Forum, in my panel on application development, and it played out in contrasting ways.

At the San Jose, Calif., event, an attendee made a passionate plea for support from tool vendors. His company maintains hundreds of service relationships, he told us, and debugging is becoming a nightmare. Panelists John Shewchuk of Microsoft and Tim Ewald of Mindreef proceeded to have a fascinating discussion about how to instrument SOAP transactions and trace them across service boundaries.

Two weeks later in New York, the same issue provoked a very different audience response. Services should be opaque, people said. It’s crazy to think about debugging a third-party service. We shouldn’t have to know anything about what goes on inside them. If there’s a problem, automatic fail-over should kick in and you should just transparently switch to a working instance.

As usual, everybody’s right. Third-party billing services should be as fungible as disk drives, and like disk drives, nobody should have to depend on a single source for them. Natural selection will tend to weed out those service providers who require their service consumers to wield heavy debugging artillery.

But it’s still the early days of SOA, and multiple sourcing isn’t always an option. Even when there are multiple sources for general-purpose services, there will always be special cases. When a strategic partnership is unique, the service relationship that supports it must likewise be unique.

Like it or not, we’ll always have to look under SOA’s hood from time to time. The good news is that XML is the diagnostician’s best friend.