cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Wrapped operation info
Date Tue, 19 Sep 2006 20:22:31 GMT
I've fixed it in my local SVN. As soon as I get my build working, I'll 
commit...
- Dan

Daniel Kulp wrote:

>I'd consider that a bug and log it JIRA.   That should be unwrappable.
>
>Dan
>
>
>On Tuesday September 19 2006 11:54 am, Dan Diephouse wrote:
>  
>
>>Speaking of unwrapped operations, currently in JAX-WS we end up with one
>>way operations like:
>>
>>    @Oneway
>>    @RequestWrapper(targetNamespace =
>>"http://cxf.apache.org/greeter_control/types", className =
>>"org.apache.cxf.greeter_control.types.GreetMeOneWay", localName =
>>"greetMeOneWay")
>>    @WebMethod(operationName = "greetMeOneWay")
>>    public void greetMeOneWay(
>>        @WebParam(targetNamespace =
>>"http://cxf.apache.org/greeter_control/types", name = "requestType")
>>        java.lang.String requestType
>>    );
>>
>>However, this doesn't show up as isUnwrappedCapable with the current
>>WSDLServiceBuilder because it doesn't have an output message. This
>>causes problems when we create proxies (see the logic thats in
>>EndpointInvocationHandler right now). It seems like the simplest thing
>>to do is support one way unwrapped operations. Or we could have the
>>frontend go back through and modify the service wsdl What do you think?
>>
>>- Dan
>>
>>Daniel Kulp wrote:
>>    
>>
>>>Guillaume,
>>>
>>>      
>>>
>>>>I've raised a JIRA issue about wrapping informations [1].
>>>>The wrapping informations for an operation is an effect of
>>>>the binding, not of the abstract operation.
>>>>All informations from the OperationInfo should be removed
>>>>and put in the BindingOperationInfo.
>>>>        
>>>>
>>>Dan and I had a couple of long discussions about this earlier as well.  
>>>The problem is that unwrapping/wrapping is not an effect for the binding
>>>either. It's technically completely and artifact of the frontend mapping.
>>>  In some cases, the frontend may need/want the data to be unwrapped, but
>>>in other cases, it may not.
>>>
>>>For example, in JAX-WS, we need to support BOTH mappings of:
>>>int add(int a, int b)
>>>and
>>>AddResponse add(AddRequest req)
>>>that would map to the same WSDL.
>>>
>>>Originally, I was only going to have the "strict" OperationInfo in the
>>>ServiceModel that strictly represented the wsdl. (One MessagePartInfo in
>>>the message)    After talking with Dan, we decide to make the "strict"
>>>form the normal one, but allow the frontend to "select" the unwrapped
>>>form, mostly as a convenience.
>>>
>>>      
>>>
>>>>It seems that actually the only information needed is wether
>>>>the bound operation is wrappable or not, which should be
>>>>a simple boolean on the BindingOperationInfo
>>>>
>>>>  boolean isUnwrapped()
>>>>
>>>>The WSDLServiceFactory should be modified accordingly to
>>>>detect wrapped operation when the binding is built and
>>>>set this boolean flag if only one part is bound to the soap body.
>>>>        
>>>>
>>>The PROBLEM with this approach is that the "unwrapped capable" logic would
>>>need to be then embedded into ALL the bindings.    The XML binding would
>>>need it, the CORBA binding (yoko project) would need it, other developer
>>>bindings would need it, etc...
>>>
>>>What we kind of decided on was to, again, for the "default/normal cases",
>>>autodetect if it matched the "normal" rules and flag it as unwrapped
>>>capable, but allow the binding and/or frontends to then also participate
>>>in that. Thus, adding some information to the soap binding to also detect
>>>the header cases is good, but I'd leave the stuff in the
>>>WSDLServiceFactory for the other cases.    Also, a frontend would
>>>probably need to have a say in it. It currently COULD by modifying the
>>>service model after creation from the WSDL.   For now, the JAX-WS layer
>>>can just select one of the two "forms" of the operation stored in the
>>>model that the WSDLServiceBuilder already provided.
>>>
>>>Enjoy!
>>>      
>>>
>
>  
>


-- 
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com


Mime
View raw message