In general, I think it's a fallback so if you have both RPC/Lit and Doc/Lit operations in the same port, it will work. We try the RPC/Lit things first and then try the doc/lit. Doc/Lit/Bare is kind of the "default" if something else doesn't handle it.
This is definitely something I'd like to see a little more work done on. I'd like to see a "OperationSelectorInterceptor" or similar that can hold a Map<Qname, List<BindingOperationInfo>> that can do a direct lookup for the BOP. That map can be computed up front. The NEXT step beyond that would be to make BindingOperationInfo objects to be InterceptorProviders. Thus, the RPC and DOC/Lit interceptors could be set on a per-operation basis and not "globally for the service on the binding". Once the OperationSelectorInterceptor figures out the operation, add the interceptors designed to handle that operation. That would definitely cleanup the "mixed" cases (rpc/lit mixed with doc/lit bare mixed with doc/lit/wrapped) quite a bit. Would also allow some cool management stuff. (secure individual operations, etc...) Dan On Monday 10 December 2007, Benson Margulies wrote: > RpcInInterceptor falls back to doc/lit/bare when it can't find an > operation. Is this a good thing? it seems to lead to more confusing > diagnosis of bad messages. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
