On Monday, February 06, 2012 11:39:24 AM Aki Yoshida wrote: > Hi, > I would like to have an option to be able to invoke oneway calls > synchronously so that the caller will get an HTTP 202 when no error > occurs at the provider side but it will get an HTTP 500 SOAP fault > when some error occurs. There seems to be no option available to > enforce this behavior.
Yea, as it's against spec and likely wouldn't be interopable with other stacks..... One thing that may need to be checked is how the various stacks would deal with a soap:fault on a one-way. If a stack isn't expecting it, not sure what they'd do. > Currently, errors occurring at the provider side for oneway calls lead > to sometimes to an HTTP 500 SOAP fault and sometimes to no error but > simply an HTTP 202 response depending on where exactly the error > occurs. Providing this option to invoke a oneway call synchronously > and returning an HTTP 500 fault to the caller upon some error will > allow the caller to handle various invocation errors more > consistently. > > I would like to achieve this synchronous behavior without forcing the > service definition to be rewritten into a request-response one. In > that way, existing plain oneway services can be invoked in a more > controlled environment. We can look at this as robust oneway (or > robust inOnly). Yep. The WSDL2 spec really did get the extra exchange patterns to be a lot better. > Another benefit of providing this option will be a more efficient > handling of large data. If the call is handled synchronously, the > input data does not need to be sucked in and cached internally before > being needed. > > I tried out adding this option by modifying OneWayProcessorInterceptor > slightly. Basically, when this option is enabled, it invokes the rest > of this oneway call and if there is an error, it switches the > exchange's oneway flag to false and calls the fault observer. The OneWayProcessorInterceptor already has the USE_ORIGINAL_THREAD which I think covers the first part, right? The other part of this would just occur in the handleFault method, right? > Unless someone objects to adding this option this way or has a better > idea of achieving this result, I would like to put this change up in > the code. > > Let me know how you think. No objections from my side. Its a good start for one of the additional WSDL2 exchange patters, not that I really expect us to ever go down the wsdl2 route. :-) Actually, what I'd even suggest is to add an @RobustInOnly annotation that would set the property on the BindingOperationInfo. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
