Web Services and the fault mechanism

Although some of the developers I met are not aware of its usefulness, the exception and the similar error feedback mechanisms are very useful. I will not go into details of exception usage patterns, but will focus on usage of fault mechanism on web services.

The fault mechanism is really useful, as applications actually need some fault feedback mechanism, and for the web services, this mechanism is more useful, as the interoperability and different systems are in place, where most of the time the consumers of the service is not able to debug or see the log of the server they are trying to interact with, and this is a serious problem especially for big projects which may have several clients who do not have direct control of/contact with the server other than calling the service.

You have to provide good messages and good feedback for the web services constructed, especially if it is a complex one.

For developers using Axis, the fault mechanism is not a simple thing nor it is complete. It is also stated on the documentation that the fault mechanism is to be experienced by the implementor, so some experience I had on this framework made me think about axis twice.

Wsdl first (contract first) development could be different, the way I followed was constructing wsdl from java. For a real feedback mechanism, string may not be adequate, you may need to supply specific information using objects, which means any framework used for web service construction will need to serialize/deserialize the objects contained in the fault tag.

As the documentation suggested and as it is the most logical way, axis converts the exceptions thrown in java code to fault in wsdl. But there are serious problems regarding the namespaces if the package that the exception is a part of and the service operation are different. The only solution is changing the wsdd file by hand, which I have constructed some ant script to change. Most of the time, axis does not complain about the namespace, but trying to consume the service using a non-axis client, the system just fails.

So, if your client is throwing interesting exceptions where your axis client works, it may be good to take a look at the fault namespaces. And also keep in mind that axis fault and exception mechanism is flawed.

Thinking about this and several other issues, at least java first web service development should not be used with axis, cxf and/or jaxb is a better way to go, in my opinion. wsdl first, I cannot say yet, but the reason I chose axis for development was I thought that it was widely used, the bugs had been solved and there were many documentation lying around the net, which I found was not true. Axis documentation is hard to find, and the framework still contains bugs.

I prefer cxf with jaxb/jaxws right now, which is a bit slower (try sxc alongside with jaxb, it is much more faster), but is much more comfortable to work with. I have not yet met any bugs or tricks, so axis may seem like a fast start and you may advance rapidly at first, but if you are dealing with complex scenarios, it may slow you down significantly, the time required to find the namespace and fault issues took 5 times the time required to construct the web services.