Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
From: Daniel Kulp <daniel.kulp@iona.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Wrapped operation info
Date: Tue, 19 Sep 2006 13:25:39 -0400
User-Agent: KMail/1.9.4
Cc: Dan Diephouse <dan@envoisolutions.com>
References: <b23ecedc0609150734q52c7eefeo4e9bb6407af3633f@mail.gmail.com>
 <200609151813.12035.daniel.kulp@iona.com>
 <451012C3.7060604@envoisolutions.com>
In-Reply-To: <451012C3.7060604@envoisolutions.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200609191325.40127.daniel.kulp@iona.com>


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!

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194   F:781-902-8001
daniel.kulp@iona.com