First, I agree that we could use a better name for the first flag, for example:
unwrapped or subjectToWrapping
true: the parameters are child elements of the wrapper (doc-lit-wrapper
or RPC wrapper)
false: the parameter is already a wrapper element ((doc-lit-wrapper or
RPC wrapper)) or root element (doc-lit)
Generating the WSDL from a bare style java method is tricky because the bare
method can be from either a doc-lit-wrapper WSDL or doc-lit-plain WSDL.
GetQuoteResponse getQuote(GetQuote quote);
We might to use some logic to test if this is from a doc-lit-wrapper WSDL
operation by looking at the method name and in/out XML elements (JAXB root
elements). Then we could have different flag b settings.
In your 1st example, we end up set the wrapperRequired to be true even it's
bare.
Thans,
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 28, 2011, at 1:53 PM, Scott Kurz wrote:
> Raymond,
>
> Ah..thanks for the clarification...I think I see what you're saying.
>
> I like the fact that you've reduced the number of flags directly
> involved in the transform from three to one.
>
> I think your organization would require some extra knowledge in
> something like Input2Input to track which side in WSDL and which side
> is Java, however.
>
> Let me walk through this to see if I understand:
>
> So if I start from Java with @SOAPBinding.parameterStyle ==
> ParameterStyle.BARE, we'd calculate:
> dataWrapped = true
> wrapperRequired = false
>
> We'd generate a WSDL with dataWrapped=false (copying the
> wrapperRequired = false from Java).
>
> So this would take us down:
>
> 3.2 sourceOperation.dataWrapped && !targetOperation.dataWrapped
> (wrapper --> bare)
>
> which means:
>
> QuoteResponse getQuote(Quote) --> doc-lit // 3.2
>
> The last line signifies that we want to transform "directly", without
> any wrapping, (or unwrapping).
>
> Your examples all flow in the Java->WSDL direction. But note we're
> also going to need to use this same transform:
>
> 3.2 sourceOperation.dataWrapped && !targetOperation.dataWrapped
> (wrapper --> bare)
>
> in the case where we have a Java with @SOAPBinding.parameterStyle ==
> ParameterStyle.WRAPPED (the default of course) , as we go from:
>
> doc-lit-wrapped --> float getQuote(String)
>
> So in the Java->WSDL direction, it would seem like wrapper->bare means
> that you transform without any wrapping or unwrapping, whereas in the
> WSDL->Java direction, it seems like the
> wrapper->bare transform means that you do an unwrapping.
>
> This adds an asymmetry that's not there today...right?
>
> I'm going to stop there and see if you agree, as maybe I still haven't
> understood totally correctly.
>
> I am curious to also understand the cases where there does exist an
> existing WSDL, especially the case I mentioned which I think is a bit
> tricky (where the WSDL exists and would qualify for
> wrapper-style-mapping per JAX-WS but where the Java has the
> ParameterStyle.BARE annotation).
>
> ----
>
> Some other thoughts:
>
> It might take awhile to mentally untangle the fact that a "wrapped"
> Java interface translates into dataWrapped=false. (Then again,
> making sense of the status quo isn't exactly easy).
>
> In saying that the ParameterStyle.BARE Java means "dataWrapped=true",
> you're not so much saying that it's necessarily wrapped... but you're
> saying it doesn't need to be wrapped along with transformation to
> another data format.
>
> I would say that:
> dataWrapped = true
> translates into:
> dataStillNeedsToBeWrapped=false
>
> And having made that connection, agree that it is simpler to deal with
> dataWrapped
> than an equivalent in my terms of:
> ! dataStillNeedsToBeWrapped
>
> -----
> Scott
