The terminology is confusing.
When using Document style, the message body on the wire must always contain at most one element. When using "non-wrapped" document style, the databinding maps that body element to a value object. When using "wrapped" style, that body element (which has the same name as the operation) is a wrapper around a set of parameter elements. "Unwrapping" refers to the process in which the databinding system automatically unwraps the body element and maps the parameter elements to individual classes. Support for "wrapped" style (which includes the ability to automatically "unwrap" the body wrapper element) is what Ajith is currently implementing.
Anne
On 6/24/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
Sanjiva Weerawarana wrote:
> On Fri, 2006-06-23 at 22:03 +1200, Dennis Sosnoski wrote:
>
> ...
>
>> One of the points of unwrapping is supposed to be to reduce the number
>> of class generated. Besides, in many cases those unwrapped parts are
>> going to be primitives. How do you plan to handle these?
>>
>
> Reduce the # of classes? Unwrapping *increases* the number of classes ..
> each arg becomes a separate class. I must be missing something.
>
I think that's the crux of where my approach differs from what Ajith is
implementing. You're thinking in terms of a unique class per element
name, which leads to an even worse proliferations of unnecessary classes
than what we've got now. The reason I want to handle the entire call to
the service method within the data binding-specific code is so that I
can work with primitives and classes that have a defined structure
binding (the equivalent of a complexType definition) but may be reused
in different places with different names. That way you're working only
with the actual data classes, without the wrapper classes.
Here's a snippet from the Axis(1) users guide, describing the Axis(1)
handling of wrapped vs. unwrapped:
For a *document* style service, this would map to a method like this:
public void method(PurchaseOrder po)
In other words, the ENTIRE <PurchaseOrder> element would be handed to
your method as a single bean with three fields inside it. On the other
hand, for a *wrapped* style service, it would map to a method like this:
public void purchaseOrder(String item, int quantity, String description)
Note that in the "wrapped" case, the <PurchaseOrder> element is a
"wrapper" (hence the name) which only serves to indicate the correct
operation. The arguments to our method are what we find when we "unwrap"
the outer element and take each of the inner ones as a parameter.
This is what users expect from unwrapped support, not to have to deal
with a whole new layer of classes wrapping the simple bean values.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
