Hi, Sorry for not replying promptly.
I agree the terms are pretty confusing. We can probably simplify them as follows: 1) We need to have two flags for a given operation that has corresponding WSDL: a) dataWrapped: If the payload for the method signature is either already wrapped b) wrapperRequired: If the corresponding WSDL requires to have a wrapper (doc-lit-wrapped or RPC). This flag is only used to set WSDL operation dataWrapped flag Only flag a) will be used for data mediation. Flag b) is only used to control the Java2WSDL generation, 2 When we introspect the Java interface (maybe with JAX-WS annotations), we can set the flag a) is set true only if the @SOAPBinding.parameterStyle == ParameterStyle.BARE b) is set to true if (@SOAPBinding.parameterStyle == ParameterStyle.WRAPPED && @SOAPBinding.style= Style.DOCUMENT) || @SOAPBinding.style= Style.RPC 3) From the data mediation perspective, we'll only consider: 3.1 sourceOperation.dataWrapped && targetOperation.dataWrapped (wrapper --> wrapper) 3.2 sourceOperation.dataWrapped && !targetOperation.dataWrapped (wrapper --> bare) 3.3 !sourceOperation.dataWrapped && targetOperation.dataWrapped (bare --> wrapper) 3.4 !sourceOperation.dataWrapped && !targetOperation.dataWrapped (bare --> bare) Please note the target operation can be a generated WSDL from the java interface, in this case, Flag b of the source operation will be translated into Flag a and Flag b of the target operation. If both source and target operations are Java methods, we'll see: float getQuote(String) --> float getQuote(String) // 3.4 float getQuote(String) --> QuoteResponse getQuote(Quote req) // 3.3 QuoteResponse getQuote(Quote) --> float getQuote(String) // 3.2 QuoteResponse getQuote(Quote) --> QuoteResponse getQuote(Quote req) // 3.1 If the source operation is Java method and the target operation is a corresponding WSDL operation, for example: float getQuote(String) --> doc-lit // 3.4 float getQuote(String) --> doct-lit-wrapped // 3.3 QuoteResponse getQuote(Quote) --> doc-lit // 3.2 QuoteResponse getQuote(Quote) --> doc-lit-wrapped // 3.1 [1] http://fusesource.com/docs/esb/4.3/cxf_jaxws/JAXWSServiceDevJavaFirstAnnotateOptionalSOAPBinding.html Thanks, Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Jan 21, 2011, at 2:57 PM, Scott Kurz wrote: > It's intentional... > > This is the unwrapped type (wrapperStyle=false), but we define a > source-databinding wrapper (non-null) to help us transform to the > wrapped type. > > Though the names aren't the best.. I don't think it's too bad until we > added the 'sourceBare' to the mix. > > I think Raymond added this... correct if I'm wrong... but I think the > reason we need it is that we might have a @SOAPBinding BARE annotation > in Java mapped to a WSDL that would actually qualify for wrapper > style. > > Since our introspection/construction of the Java and WSDL interfaces > happen separately... we can't take the Java into account when > introspecting the WSDL. So we need a flag that says.. though the > WSDL looks like there should be a wrapping/unwrapping along with the > transform... we actually don't want one. > > Simon mentioned in our offline conversation that you'd think in most > cases only the bare/wrapped mapping would even be valid, but you can > imagine a signature like: void myMethod(DataObject obj) where the > same Java could map to either the wrapper element or its single child. > > So we signal that we should go down that third block (child->child > mediation with no wrapper) by choosing to not create a wrapper when we > introspect the Java, and then calculating 'sourceBare' as we do in > I2I. > > I think that's what's going on anyway.. > > I do think if we started from scratch and considered all the > combinations of the wrapped vs. bare Java/WSDL interfaces we could > probably find a clearer way of naming/coding this.. but I'm not sure > it's worth taking it that far.. but reanming the sourceBare check as > we discussed would be nice. > > Scott
