Question

This is my first try of develop a web service. Authentication is implemented by sending login and password in the context of user request (used this example: http://www.mkyong.com/webservices/jax-ws/application-authentication-with-jax-ws/), and then calling autentication method from each WS method. But in this case what way of user notification about authentication failure is better? Throw an exception(SOAP fault)? Or there is some other better way?

P.S. sorry for my bad English

Answer 1

Artem,

SOAP faults are roughly analogous to program exceptions, so I would return a SOAP fault with

• a distinct Fault Code (i.e. error number) and
• a “vanilla” Fault String, which would be suitable for display to the user; and
• Fault Detail containing “the techinical details”, such as the underlying exception and stack-trace.

This gives you the best of both worlds, simplicity and flexibility. Just say, in the Service implementation you catch an AuthenticationFailureException and build a “SOAP fault response” with

• FaultCode = 5,
• FaultString = “Authentication Failed”, and
• FaultDetail = “AuthenticationFailureException: blah blah\n <stacktrace>”

So at programming time you’ve got everything you need to see EXACTLY what went wrong, and in production the service consumer (i.e. the presentation layer) is responsible for dealing with SOAP faults in order to present the user with an appropriate error message. Exactly what’s displayed to the user should NEVER be, especially in a fault scenario, be determined be the service. That is clearly the responsibility of the presentation layer.

And one refinement… be sure to use a seperate exception-type (and soap-fault-code) for the scenario “the authentication service is currently unavailable”, so that users don’t fruitlessly keep retrying, worrying that they’ve forgotten there password, or been hacked, or whatever.

This is a nice sucinct MSDN article on Using SOAP Faults, which is applicable both Java and .NET web-services.

Cheers. Keith.