cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject Re: An option for performing oneway calls synchronously to be able to handle errors consistently
Date Wed, 08 Feb 2012 09:32:18 GMT
forgot to cc on dev@cxf.
doing it now so that i can link the whole thread in a jira ticket.

2012/2/6 Aki Yoshida <elakito@googlemail.com>:
> 2012/2/6 Daniel Kulp <dkulp@apache.org>:
>> On Monday, February 06, 2012 5:50:05 PM Aki Yoshida wrote:
>>> 2012/2/6 Daniel Kulp <dkulp@apache.org>:
>>> > 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.
>
> Right.
>
>>
>> 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.
>> :-)
>>
>
> Yeah. It looks like the spec has been corrected so that is is more
> aligned with reality.
> If we interpret the BP1.0/1.1 paragraph strictly, we might say that we
> are already violating BP 1.0/1.1 for some error cases mentioned
> earlier. However, we could use slightly a loose interpretation of that
> paragraph so that oneway operations cannot return a soap fault to
> actually convey the fault information back to the caller. But a oneway
> call is allowed to return an HTTP 500 to indicate the failure of the
> transmission of the message. And this "transmission" thing could be
> loosely interpreted :-).
>
>>> > 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.
>>
>
> That sounds good.
>
> Thanks.
>
> Regards, aki
>>
>>
>>> Regards, aki
>>>
>>> > --
>>> > Daniel Kulp
>>> > dkulp@apache.org - http://dankulp.com/blog
>>> > Talend Community Coder - http://coders.talend.com
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com

Mime
View raw message