通常,良好的架构都会有很好的异常处理模式,Web Service也不例外。
例外的是,当你的项目比较庞大的时候,你的业务方法可能很多并且你并不了解他们的内部实现。
作为一个优秀的Web Service架构师,你需要解决Web服务跟这些业务异常的结合问题。
现实是我们都不想关心这些业务类的实现,尽管这些异常从Java类抛出,并且Web服务必须处理这些
异常,起码,你需要让客户端知道:web服务端抛出异常。
以XFire为例, 假设有一个Web服务A和一个调用A的客户端B
A服务端 B客户端
当B->A发起一个Web服务请求,A抛出异常的时候,会直接new XFireFault并扔向XFire客户端。
解耦思路带领下,应该先将异常处理剥离出来。
于是,有
A服务-A异常处理handler B客户端-B异常处理handler
这样,从架构的角度,A/B均无需考虑异常问题。
XFire客户端可以通过addFaultHandler来增加异常处理,XFire服务端则可以通过典型的AOP异常拦截来隔离
业务逻辑和Web服务之间的纽带。
例外的是,当你的项目比较庞大的时候,你的业务方法可能很多并且你并不了解他们的内部实现。
作为一个优秀的Web Service架构师,你需要解决Web服务跟这些业务异常的结合问题。
现实是我们都不想关心这些业务类的实现,尽管这些异常从Java类抛出,并且Web服务必须处理这些
异常,起码,你需要让客户端知道:web服务端抛出异常。
以XFire为例, 假设有一个Web服务A和一个调用A的客户端B
A服务端 B客户端
当B->A发起一个Web服务请求,A抛出异常的时候,会直接new XFireFault并扔向XFire客户端。
解耦思路带领下,应该先将异常处理剥离出来。
于是,有
A服务-A异常处理handler B客户端-B异常处理handler
这样,从架构的角度,A/B均无需考虑异常问题。
XFire客户端可以通过addFaultHandler来增加异常处理,XFire服务端则可以通过典型的AOP异常拦截来隔离
业务逻辑和Web服务之间的纽带。