Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 87387 invoked from network); 24 Jun 2006 23:29:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Jun 2006 23:29:08 -0000 Received: (qmail 41842 invoked by uid 500); 24 Jun 2006 23:29:07 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 41162 invoked by uid 500); 24 Jun 2006 23:29:05 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 41151 invoked by uid 99); 24 Jun 2006 23:29:05 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Jun 2006 16:29:05 -0700 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of atmanes@gmail.com designates 64.233.182.189 as permitted sender) Received: from [64.233.182.189] (HELO nf-out-0910.google.com) (64.233.182.189) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Jun 2006 16:29:04 -0700 Received: by nf-out-0910.google.com with SMTP id x4so704848nfb for ; Sat, 24 Jun 2006 16:28:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=gtfVFzztKmoKgg6YLFVjAtudrIueia1xim5zee0ViiElscc2z5eCmUuwFiLZNLuMgHEYYZw0bEhsBUHMusLfNHb25mlp7CJrUu3KHwDPDH8Sqqa2JcpBGcTh24ubrFcNbwccAwXw00HQaqtzqmqeRudOzUuwCteigzSIX8cRXxs= Received: by 10.49.90.8 with SMTP id s8mr3708344nfl; Sat, 24 Jun 2006 16:28:42 -0700 (PDT) Received: by 10.48.255.4 with HTTP; Sat, 24 Jun 2006 16:28:42 -0700 (PDT) Message-ID: Date: Sat, 24 Jun 2006 19:28:42 -0400 From: "Anne Thomas Manes" To: axis-dev@ws.apache.org Subject: Re: [Axis2] Implementing unwrapped (was Re: [Axis2] Planning for Axis2 next rev - 1.1 (?)) In-Reply-To: <449DA582.3080604@sosnoski.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2574_4152975.1151191722768" References: <19e0530f0606111646i4877f712y429f30cea6fc4139@mail.gmail.com> <448CC29D.7020400@sosnoski.com> <448D2352.1050606@sosnoski.com> <448E82FD.4050603@sosnoski.com> <449BBC5F.6090704@sosnoski.com> <1151159000.19530.15.camel@localhost.localdomain> <449DA582.3080604@sosnoski.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_2574_4152975.1151191722768 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dennis, 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 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 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 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: axis-dev-unsubscribe@ws.apache.org > For additional commands, e-mail: axis-dev-help@ws.apache.org > > ------=_Part_2574_4152975.1151191722768 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dennis,

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 <dms@sosnoski.com> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


------=_Part_2574_4152975.1151191722768--