Re: Wrapped operation info

[Dan Diephouse]

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