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.
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). 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. 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. Thanks. Regards, aki
