On Monday, February 06, 2012 5:50:05 PM Aki Yoshida wrote: > 2012/2/6 Daniel Kulp <[email protected]>: > > 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. > > I think there is a grey area in the interpretation of the spec. > Logically, in the application's message exchange level, we can all > agree that there is no fault returned to the caller. But there are all > kinds of error situations during the oneway call. Some errors are > already generating an HTTP 500 response
In theory, this would only occur for faults that occur prior to being able to determine which operation is being invoked. Basically, prior to knowing if the incoming message is a one-way or not. Once we know it's a one-way, then the normal one-way rule apply. What's interesting is that this is an area that has even changed in the WSI-BP specs. In 1.1 and earlier: http://www.ws-i.org/Profiles/BasicProfile-1.1.html#One-Way_Operations you can see that for one-way, you CANNOT send a fault response back. But that has changed for 1.2: http://ws-i.org/profiles/BasicProfile-1.2-2010-11-09.html#One-Way_Operations So your changes would violate BP 1.0/1.1, but not 1.2. So I'm OK with it. :-) > > Actually, what I'd even suggest is to add an @RobustInOnly annotation that > > would set the property on the BindingOperationInfo. > > That would be possible. But that means you want to statically > differentiate the service method to be either non-robust and robust, > as if we are going the wsdl2 route? > > I thought it would be beneficial to be able to set this option at the > published endpoint by using some message contextual property. One doesn't preclude the other.... If the OneWayInInterceptor just looks for message.getContextualProperty("....") and basis it's work on that property, it can be set in a number of places including the Endpoint, the bus, the operation, etc... The annotation can just be used to set the property on that specific operation. (and if you allow TYPE for @Target, you could set it on the EndpointImpl or interface to apply to all oneways) Basically, just an easy "java first" way to set the property. > Regards, aki > > > -- > > Daniel Kulp > > [email protected] - http://dankulp.com/blog > > Talend Community Coder - http://coders.talend.com -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
