On Thu, Feb 17, 2011 at 9:20 PM, Yang, Gang CTR US USA <gang.y...@us.army.mil> wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Hi, > > > > I’m continuing implementing WS-security using PolicyHandler framework in > Tuscany 1.6.1. I found that when SOAPFault is generated, the > PolicyHandler.afterInvoke() is skipped. This is true on both the service and > reference side. > > > > This scenario on the service side is the following: beforeInvoke() fails > the security check and throws RuntimeException. This causes Tuscany runtime > to skip calling PolicyHandler.afterInvoke() on the return direction of both > service side and the reference side, which is trying to access the service. > On the wire, Tuscany runtime did generate a SOAPFault body for the response. > This causes several problems: > > > > 1. The service side and the reference side (client) did not have an > opportunity to do WS-security processing for the return direction. > > 2. The audit system also missed some opportunities to audit the > failure. > > > > On a slightly different but related topic, what is the right exception > handling for PolicyHandler? PolicyHandler.before/afterInvoke() signature did > not declare any exception. So I could only throw RuntimeException. That > causes the control to end up in > Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic()’s catch block and > therefore missed the PolicyHandler.afterInvoke(). I think PolicyHandler API > should declare specific exceptions with defined meanings so the users knows > what to do. > > > > Thanks, > > Gang > > Classification: UNCLASSIFIED > Caveats: NONE > >
Hi Gang I agree that is seems sensible if the afterInvoke operation gets a chance to process even in the case of an exception. You can then decide if cleanup is required. When some work was done recently in 2.x around the async programming model the same conclusion was drawn and a specific operation added to perform post processing in the exception case [1]. Re. exception handling. Even in 2.x we don't describe specific exceptions on the Interceptor operations that do the processing. SCA (in 1.x and 2.x) does define a ServiceRuntimeException which extends RuntimeException and we tend to use this in the runtime. This can of course wrap any exception you want it to. Ultimately these exceptions will end back at the implementation provider (on the reference side) or the binding provider (on the service side). Typically these providers propagate the exception so that the caller of a service (either an external client or a component implementation) needs to look inside the exception and decide what to do. These systematic exceptions are not part of the business interface of course. When you say > PolicyHandler API > should declare specific exceptions with defined meanings so the users knows > what to do. Are you talking about the ultimate user of the service here? E.g. some client of a service that might have provided authentication credentials. If it was some "login" business interface then I would expect the business interface to define an InvalidCredentials exception. If it's some other buisness interface where under the covers an authentication policy has been applied (which I think is the case you are talking about) then it can also fail but there is no business exception to report. Hence we would fall back to using something like ServiceRuntimeException. Simon [1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/core-spi/src/main/java/org/apache/tuscany/sca/invocation/InterceptorAsync.java -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
