Classification: UNCLASSIFIED Caveats: NONE Hi, Simon,
Thanks for the reply. My responses follow. Thanks, Gang --- Cut --- > 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]. Great. At least 2.x has done something. Is this done only in the Async area? How about the Sync calls. I guess one thing I have come to notice, at least in 1.6.x in my discussions with Simon N., is that the infrastructure concepts have been mainly focused on "calls" which is sort of emphasizing one direction. I can understand that because of what SCA presents to the users - plain application level method invocation without having to worry about how the information is transformed and transported. But internally, we do have to think in terms of communications in a distributed and networked system, which includes a bi-directional request/response pair (Sync or Async). For security, I need to be able to insert logic on both directions whether it's a successful invocation or a fault. As you mentioned below and I agree, fault/exception is just the business layer content here. I'm wondering if anything can be done in 1.6.x among other issues I have brought up. At this point, I'm not sure which of them would be covered in 1.6.x and which would not be. 1.6.x is the one our projects are currently using before we move to 2.0 in the future. I'm not sure how responsibilities are divided among you, but I remember Simon N. had mentioned about being associated more with 1.6.x. > > 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. It makes sense. I think the key issue is to allow interceptors/handlers a chance to process them on the way back, too. The interceptors/handlers may need to coordinate on processing the fault. I my case, the fault that is generated on the inbound (beforeInvoke) needs to be applied with security treatment on the outbound (afterInvoke) before sent back to the client side and the client side inbound (afterInvoke) also needs a chance to process and audit the security content. > > 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. I guess what I was looking for when I tried to program using PolicyHandler API was some sort of checked Exception, say PolicyException, whose treatment by the runtime is well-defined and made known to the PolicyHandler developers like me. The treatment can be that the invocation will stop and the PolicyException or its sub-exceptions thrown by the beforeInvoke will be made available to the return side handlers, afterInvoke for further processing. Of course your description above and the general ServiceRuntimeException is another more general treatment and did help me understand it better. Thanks. > > 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.ja > va > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com Classification: UNCLASSIFIED Caveats: NONE
