InfoQ’s Stefan Tilkov talks to Spring Web Services creator Arjen Poutsma about Web services in general

The Spring framework is very popular among Java developers as a more lightweight alternative to “enterprise” frameworks. One of the newest additions is the Spring Web Services subproject, which according to the Web site “is focused on…

Shouldn’t the same idea apply to any black box in principle? I won’t be able to debug your web service and I won’t be able to debug your black box, closed source component…but I might be able to mail you the stack trace so that you can debug it more easily!

That C doesn’t offer a stack trace is more of a problem with C that shouldn’t be allowed to “drag down” a “real” language with it? So, I don’t agree

/Mats

Fair enough, the code in Axis seems to be well thought out, and seems to be helpful for debugging purposes. I’m still not entirely convinced, though .

1. Axis 1.x doesnt send a stack trace over the wire unless you set a flag saying you are a dev system. That wasnt just because end users dont care about stack traces -if you are a developer trying to integrate with someone elses system, quiite often you do. It was mainly for security reasons: I dont want to expose internals unless I have to.

2. I also added the stuff that says the name of the host at fault. Because when you have an 8 way server, you like to know that its server 3 failing al requests, not “one request in 8 is failing”. Again, I think you can strip it if you are paranoid.

3. Did I mention I add http error codes and strings in somewhere too?

I never try and turn soap faults back into native faults; that is silly. the stack trace is just an extra bit of debugging detail, and very nice too.

I can think of 4 web services configs that I’m currently running where I would probably turn on a “convert exception to fault” type feature.
Only 1 of those is using SOAP, but in each case that’s an implementation detail.

The SOAP service is facilitating a .NET client talking to a Java server between two very closely related business units. If something goes wrong and our service triggers an exception then I would prefer the guys on the other end get as much information as possible, as it may be that they caused it (by passing in some combination of data that the service did handle cleanly), or it may be that our database went down and having an SQLException (or some runtime wrapper around it) and that will tell them that it’s our problem and there’s no point them trying to work out if the fault is in the client.

Now, all those things can be dealt with by mapping all the errors explicitly. But that’s a lot of work, for not much gain. Or we can put our own exception catching block at the top of our service and do the SOAP-fault mapping ourself, but that just results in every project duplicating the same code that could have been in Spring-WS.

For our services that have multiple clients with various implementation languages, the exposing of the stack trace isn’t something I’d do. But for simple inter-op between two independant applications it seems to me like the simplest path to exposing the fault.

We’re not expecting exceptions - that’s why they’re exceptions - but if they occur you need some way to report an error. For some use cases a simple “general server error” is appropriate. But in other cases the more information you can push out to the client the faster it will be resolved.

There is probably a user a day on the xfire mailing list who doesn’t seem to comprehend that a stack trace occurred on the server side because they didn’t check their logs. I don’t think we should be reconstructing the exception on the other side, but it probably isn’t that bad to just print it to stdout. It certainly would save me from writing a few emails!

Though I do have mixed feelings about it as people often forget to turn that extra debugging off in production.