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 15:54:43 GMT
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