Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 41576 invoked from network); 4 Jan 2008 10:19:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Jan 2008 10:19:11 -0000 Received: (qmail 83921 invoked by uid 500); 4 Jan 2008 10:18:58 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 83886 invoked by uid 500); 4 Jan 2008 10:18:58 -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 83875 invoked by uid 99); 4 Jan 2008 10:18:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jan 2008 02:18:58 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of amilasuriarachchi@gmail.com designates 72.14.202.177 as permitted sender) Received: from [72.14.202.177] (HELO ro-out-1112.google.com) (72.14.202.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Jan 2008 10:18:32 +0000 Received: by ro-out-1112.google.com with SMTP id a14so1314745rof.8 for ; Fri, 04 Jan 2008 02:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=JWNpUizY/E2ft8Si+DR9O+D6ZMjoPcvLgbwBQCOQNAY=; b=ochlsN2qzOVHLTeL4fbO53NjdMT4gilAfV0cdThk7Vnrme1D8PpLfH13zLBf20oWiv271CQ4kkR9r4yTrFdsdeMb/G9Csom9dMVJTUuWSyGNGvXfjN7wi1Iv3/q4LMnLx5w64sjNxX3Rjgqi+tBkiTnu1Zn1p9apwMXP4G8KCQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Pm5gpPoxZCbWgY8O6zS+Gvb6JEeops2yh7R1GwSB8D2QibyWsOSbzaufDSKxefo6e5MslJdQUf/gy5orMKLowFxdbJsQfUJpHlJbA/2fUs9WWphVb1a8nw8dR5fl3hCOgEk202vdMJ1bQqn4fqJBFdt+W3iqE4iKE8apFAfPTYc= Received: by 10.140.187.10 with SMTP id k10mr1325805rvf.86.1199441916421; Fri, 04 Jan 2008 02:18:36 -0800 (PST) Received: by 10.140.173.4 with HTTP; Fri, 4 Jan 2008 02:18:36 -0800 (PST) Message-ID: <60708f4b0801040218s15f513d7x1e5bcf77e8d08873@mail.gmail.com> Date: Fri, 4 Jan 2008 15:48:36 +0530 From: "Amila Suriarachchi" To: axis-dev@ws.apache.org Subject: Re: [Axis2] Soap Encoding support with ADB In-Reply-To: <60708f4b0801040015v5c08d1fcs1d67df294381280f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_20977_5481609.1199441916414" References: <60708f4b0712232218k4b99657ch61df8eaab0912f91@mail.gmail.com> <4772601D.8090102@thoughtcraft.com> <60708f4b0712272226v70dba18bmb897b470e9a3af9@mail.gmail.com> <47749C71.1090307@thoughtcraft.com> <60708f4b0801022123r14c8a58ev5d19093518f48dd0@mail.gmail.com> <60708f4b0801022251j5c7d660ob4983fd7e01bca4d@mail.gmail.com> <60708f4b0801040015v5c08d1fcs1d67df294381280f@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_20977_5481609.1199441916414 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Jan 4, 2008 1:45 PM, Amila Suriarachchi wrote: > > > On Jan 3, 2008 7:59 PM, Anne Thomas Manes wrote: > > > Amila, > > > > SOAP encoding is much more likely to be used in a code-first scenario, > > but you must make sure that it also works in a WSDL-first scenario. > > > > Regarding one of your questions, you would never see an element > > defined as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In the soap encoding schema Array is defined as a complex type. Then why > it is wrong to use it as a type? > > Anyway in the article you given it has mentioned like this. > > The WSDL specification requires that arrays be based on the SOAP 1.1encoding schema. It also requires that arrays use the name > ArrayOfXXX, where XXX is the type of item in the array. > > Does WSDL specification say something like this? For me it is an > customized type they have come up with > to solve the problem we have. They have define some convention to > determine the array type. But I think > we need to come up with some generalized approach to support any schema. > Like I have given above. > I check with the Axis 1.x generated wsdls and microsofts' interop sites wsdls. for axis 1.x and for interop site so it is a general convention every one uses. Therefore I think adding support for this generic convention solves our problem. And we can keep what existing thing to support soap encoding in a generic way. Any thoughts? thanks, Amila. > > > I'll have a look at the wsdls generated by Axis 1.x with soap encoding and > the corresponding java classes generated by the wsdl2java tool. > > > [1] http://schemas.xmlsoap.org/soap/encoding/ > > Amila. > > > > > > > First off, you would define a named complexType rather than an > > element. And second, you never define an element simply as > > soapenc:Array. The ComplexType would look something like this: > > > > > > > > > > > > > > > > > > > > > > > > > wsdl:arrayType="string[]"/> > > > > > > > > > > Or even more likely, you wouldn't define the "TestSoapType2" type -- > > you would simply reference the child types in the WSDL message > > description: > > > > > > > > > > > > > > You might find this article helpful: > > http://www.developer.com/services/article.php/10928_1602051_3 > > > > You also might spend a little time playing with Axis generating some > > RPC/encoded services to get a better sense of how the environment > > works. > > > > Anne > > > > On Jan 3, 2008 1:51 AM, Amila Suriarachchi > > wrote: > > > hi tom, > > > > > > I went through the Axis user guide[1] and as I understood Axis 1.x has > > used > > > soap encoding in the > > > code first approach to support Arrays. I think this is where both you > > and > > > glen has misunderstood. > > > > > > in that case if I have a class like this > > > > > > public class Test { > > > private int[] testArray; > > > public void setTestArray(int[] param){ > > > testArray = param; > > > } > > > > > > public int[] getTestArray(){ > > > return testArray; > > > } > > > > > > } > > > > > > in this case as Axis 1.x has done users must be given the chance to > > deal > > > with the standard types and it is > > > almost useless to ask to deal with a new type. Further as I guess it > > uses > > > org.apache.axis.providers.java.RPCProvider as in Axis2 > > RPCMessageReceiver. > > > BTW one question. Why Axis 1.x use soap encoding for this? why it > > simply > > > generate something > > > like this > > > > > > it is always better to use POX rather than encoding types isn't it? > > > > > > So we won't be able to use the Axis 1.x code for this. > > > > > > But In the contract first approach people always have to deal with the > > > > > generated classes. So I believe in this > > > case I don't think it is a problem. Here the main idea is to access a > > > service already deployed with soap:encoding. > > > > > > So it would only be used at client side. > > > > > > [1] > > > > > http://ws.apache.org/axis/java/user-guide.html#ConsumingWebServicesWithAxis > > > > > > thanks, > > > Amila. > > > > > > > > > > > > On Jan 3, 2008 10:53 AM, Amila Suriarachchi < > > amilasuriarachchi@gmail.com> > > > wrote: > > > > hi tom, > > > > thanks you your reply. if you have already working with axis 1.xcould you > > > please help on answering these > > > > questions? > > > > > > > > > > > > > > > > On Jan 3, 2008 4:06 AM, Tom Jordahl < tjordahl@adobe.com> wrote: > > > > > > > > > +1 on Glen's -1 of using a whole new set of types to support SOAP > > > > > encoding. A String must map to a soapenc:string and a Array[] > > must map > > > > > to a SOAP encoded array. > > > > > > > > > > > > In axis 1.x is it use in code first or contract first (i.e. > > wsdl2java) > > > approach? Here what I am trying to do is to > > > > use it with the wsdl2java tool. i.e with the contract first > > approach. > > > > > > > > So the main question is what is the generated method signature for > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > this type of element. what is the type of param2 in Axis 1.x? Here > > in code > > > generation > > > > time I do not know the type of the array. That is why I set it as a > > new > > > type letting users to define it. > > > > > > > > > > > > > > > > > > > > > > > > > > > I would also argue for "full" multiref support, as servers will be > > > > > sending this back to Axis2 clients, right? > > > > > > > > > > > > I agree. I'll add this feature as I have describe earlier. > > > > > > > > > > > > > > > > > > > > > > > Amila, please feel free to use the Axis 1.x code base as a > > reference for > > > > > how to do any of this. Please also feel free to NOT to duplicate > > the > > > > > Array serialization/deserialization bugs. :-) > > > > > > > > > > > > For the moment in Axis 2 ADB is also in a very stable state. so > > using > > > already existing ADB logic > > > > won't give any serializing de serializing issues. > > > > > > > > Thanks, > > > > Amila. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Tom Jordahl > > > > > Axis 1.x guy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Glen Daniels [mailto:glen@thoughtcraft.com ] > > > > > Sent: Friday, December 28, 2007 1:49 AM > > > > > To: axis-dev@ws.apache.org > > > > > Subject: Re: [Axis2] Soap Encoding support with ADB > > > > > > > > > > Hey Amila: > > > > > > > > > > > won't need them. But for SOAP 1.1, the situation is > > different. > > > > > The > > > > > > encoding spec says you MUST encode all complex object types > > as > > > > > top-level > > > > > > members of the serialization. Therefore ALL conforming SOAP > > 1.1 > > > > > > encoding implementations will be putting out stuff that > > looks like > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the real argument > > > > > > blue > > > > > > > > > > > > > > > > > > > > > > > > is this means it is allowed to have more than one xml element in > > the > > > > > > soap:body ? > > > > > > > > > > Yes. But - I was incorrect about the MUST above! My hands were > > typing > > > > > a little ahead of my brain there. :) Multirefs are not in fact > > > > > *required* by SOAP 1.1 section 5, but some implementations (Axis > > 1.X > > > > > included) will by default serialize all complex objects as > > multirefs > > > > > since it speeds writing (if you don't do it that way you have to > > walk > > > > > the entire data graph to see what objects are referred to multiple > > times > > > > > > > > > > before serializing). > > > > > > > > > > > I have to think about bit. We can resolve the problem with > > parsing as > > > > > I > > > > > > have mentioned earlier but can not think about a way to > > serialize with > > > > > > > > > > > multirefs. > > > > > > > > > > Again, my bad - we're not forced to do so, so it's ok for us not > > to, as > > > > > long as we accept that we're not going to be able to do real > > graphs. If > > > > > > > > > > no one wants this particular functionality, I'm fine with punting > > on it. > > > > > > > > > > Your idea about parsing the XML to remove the hrefs and generate a > > > > > larger "virtual" expanded document on the reading side should work > > fine, > > > > > > > > > > although it will potentially cause repeated data if a multiref is > > used > > > > > many times. Probably not a big deal. I'll respond to the rest of > > your > > > > > other note in another message. > > > > > > > > > > Thanks, > > > > > --Glen > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Amila Suriarachchi, > > > > WSO2 Inc. > > > > > > > > > > > > -- > > > Amila Suriarachchi, > > > WSO2 Inc. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > > For additional commands, e-mail: axis-dev-help@ws.apache.org > > > > > > > -- > Amila Suriarachchi, > WSO2 Inc. -- Amila Suriarachchi, WSO2 Inc. ------=_Part_20977_5481609.1199441916414 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Jan 4, 2008 1:45 PM, Amila Suriarachchi <amilasuriarachchi@gmail.com> wrote:


On Jan 3, 2008 7:59 PM, Anne Thomas Manes <atmanes@gmail.com> wrote:
Amila,

SOAP encoding is much more likely to be used in a code-first scenario,
but you must make sure that it also works in a WSDL-first scenario.

Regarding one of your questions, you would never see an element
defined as follows:

<s:element name="TestSoapElement2">
>         <s:complexType>
>             <s:sequence>
>                 <s:element name="param1" type="s:string"/>
>                 <s:element name="param2" type="soapenc:Array"/>
>             </s:sequence>
>         </s:complexType>
>     </s:element>

In the soap encoding schema Array is defined as a complex type. Then why it is wrong to use it as a type?

Anyway in the article you given it has mentioned like this.

The WSDL specification requires that arrays be based on the SOAP 1.1 encoding schema. It also requires that arrays use the name ArrayOfXXX, where XXX is the type of item in the array.

Does WSDL specification say something like this? For me it is an customized type they have come up with
to solve the problem we have. They have define some convention to determine the array type. But I think
we need to come up with some generalized approach to support any schema. Like I have given above.

I check with the Axis  1.x generated wsdls and  microsofts' interop sites wsdls.
for axis 1.x
<complexType name="ArrayOf_xsd_string">
    <complexContent>
    <restriction base="soapenc:Array">
          <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[]"/>
     </restriction>
    </complexContent>
</complexType>

and for interop site
<xs:complexType name="ArrayOfInt">
    <xs:complexContent mixed="false">
    <xs:restriction base="q1:Array">
   <xs:attribute a:arrayType="xs:int[]" ref="q1:arrayType"/>
  </xs:restriction>
</xs:complexContent>
</xs:complexType>

so it is a general convention every one uses. Therefore I think adding support for this generic convention solves our problem. And we can keep what existing thing to support soap encoding in a generic way.

Any thoughts?

thanks,
Amila.


I'll have a look at the wsdls generated by Axis 1.x with soap encoding and the corresponding java classes generated by the wsdl2java tool.


[1] http://schemas.xmlsoap.org/soap/encoding/

Amila.


First off, you would define a named complexType rather than an
element. And second, you never define an element simply as
soapenc:Array. The ComplexType would look something like this:

 <s:complexType name="TestSoapType2">
    <s:sequence>
         <s:element name="param1" type="soapenc:string"/>
         <s:element name="param2" type="tns:ArrayofString"/>
    </s:sequence>
 </s:complexType>

<complexType name="ArrayOfString">
  <complexContent>
     <restriction base="soapenc:Array">
        <attribute ref="soapenc:arrayType"
           wsdl:arrayType="string[]"/>
     </restriction>
  </complexContent>
</complexType>

Or even more likely, you wouldn't define the "TestSoapType2" type --
you would simply reference the child types in the WSDL message
description:

<w:message name="TestInput">
  <w:part name="param1" type="soapenc:string"/>
  <w:part name="param2" type="tns:ArrayofString"/>
</w:message>

You might find this article helpful:
http://www.developer.com/services/article.php/10928_1602051_3

You also might spend a little time playing with Axis generating some
RPC/encoded services to get a better sense of how the environment
works.

Anne

On Jan 3, 2008 1:51 AM, Amila Suriarachchi <amilasuriarachchi@gmail.com> wrote:
> hi tom,
>
> I went through the Axis user guide[1] and as I understood Axis 1.x has used
> soap encoding in the
> code first approach to support Arrays. I think this is where both you and
> glen has misunderstood.
>
> in that case if I have a class like this
>
> public class Test {
>  private int[] testArray;
> public void setTestArray(int[] param){
>      testArray = param;
> }
>
> public int[] getTestArray(){
>     return testArray;
> }
>
> }
>
> in this case as Axis 1.x has done users must be given the chance to deal
> with the standard types and it is
> almost useless to ask to deal with a new type. Further as I guess it uses
> org.apache.axis.providers.java.RPCProvider as in Axis2 RPCMessageReceiver.
> BTW one question. Why Axis 1.x use soap encoding for this? why it simply
> generate something
> like this
> <element name="testArray" minOccurs="0" maxOccurs="unbounded"/>
> it is always better to use POX rather than encoding types isn't it?
>
> So we won't be able to use the Axis 1.x code for this.
>
> But In the contract first approach people always have to deal with the
> generated classes. So I believe in this
> case I don't think it is a problem. Here the main idea is to access a
> service already deployed with soap:encoding.
>
> So it would only be used at client side.
>
> [1]
> http://ws.apache.org/axis/java/user-guide.html#ConsumingWebServicesWithAxis
>
> thanks,
> Amila.
>
>
>
> On Jan 3, 2008 10:53 AM, Amila Suriarachchi <amilasuriarachchi@gmail.com>
> wrote:
> > hi tom,
> > thanks you your reply. if you have already working with axis 1.x could you
> please help on answering these
> > questions?
> >
> >
> >
> > On Jan 3, 2008 4:06 AM, Tom Jordahl < tjordahl@adobe.com> wrote:
> >
> > > +1 on Glen's -1 of using a whole new set of types to support SOAP
> > > encoding.  A String must map to a soapenc:string and a Array[] must map
> > > to a SOAP encoded array.
> >
> >
> > In axis 1.x is it use in code first or contract first (i.e. wsdl2java)
> approach? Here what I am trying to do is to
> > use it with the wsdl2java tool. i.e with the contract first approach.
> >
> > So the main question is what is the generated method signature for
> >
> > <s:element name="TestSoapElement2">
> > >         <s:complexType>
> > >             <s:sequence>
> > >                 <s:element name="param1" type="s:string"/>
> > >                 <s:element name="param2" type="soapenc:Array"/>
> > >             </s:sequence>
> > >         </s:complexType>
> > >     </s:element>
> >
> > this type of element. what is the type of param2 in Axis 1.x? Here in code
> generation
> > time I do not know the type of the array. That is why I set it as a new
> type letting users to define it.
> >
> >
> >
> > >
> > >
> > > I would also argue for "full" multiref support, as servers will be
> > > sending this back to Axis2 clients, right?
> >
> >
> > I agree. I'll add this feature as I have describe earlier.
> >
> >
> > >
> > >
> > > Amila, please feel free to use the Axis 1.x code base as a reference for
> > > how to do any of this.  Please also feel free to NOT to duplicate the
> > > Array serialization/deserialization bugs. :-)
> >
> >
> > For the moment in Axis 2 ADB is also in a very stable state.  so using
> already existing ADB logic
> > won't give any serializing de serializing issues.
> >
> > Thanks,
> > Amila.
> >
> >
> >
> >
> > >
> > >
> > > --
> > > Tom Jordahl
> > > Axis 1.x guy
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Glen Daniels [mailto: glen@thoughtcraft.com ]
> > > Sent: Friday, December 28, 2007 1:49 AM
> > > To: axis-dev@ws.apache.org
> > > Subject: Re: [Axis2] Soap Encoding support with ADB
> > >
> > > Hey Amila:
> > >
> > > >     won't need them.  But for SOAP 1.1, the situation is different.
> > > The
> > > >     encoding spec says you MUST encode all complex object types as
> > > top-level
> > > >     members of the serialization.  Therefore ALL conforming SOAP 1.1
> > > >     encoding implementations will be putting out stuff that looks like
> > > this:
> > > >
> > > >     <soap:body>
> > > >       <operation>
> > > >         <arg1 href="#obj1"/>
> > > >       </operation>
> > > >       <multiref id="obj1">
> > > >         <name>the real argument</name>
> > > >         <color>blue</color>
> > > >       </multiref>
> > > >     </soap:body>
> > > >
> > > > is this means it is allowed to have more than one xml element in the
> > > > soap:body ?
> > >
> > > Yes.  But - I was incorrect about the MUST above!  My hands were typing
> > > a little ahead of my brain there. :)  Multirefs are not in fact
> > > *required* by SOAP 1.1 section 5, but some implementations (Axis 1.X
> > > included) will by default serialize all complex objects as multirefs
> > > since it speeds writing (if you don't do it that way you have to walk
> > > the entire data graph to see what objects are referred to multiple times
> > >
> > > before serializing).
> > >
> > > > I have to think about bit. We can resolve the problem with parsing as
> > > I
> > > > have mentioned earlier but can not think about a way to serialize with
> > >
> > > > multirefs.
> > >
> > > Again, my bad - we're not forced to do so, so it's ok for us not to, as
> > > long as we accept that we're not going to be able to do real graphs.  If
> > >
> > > no one wants this particular functionality, I'm fine with punting on it.
> > >
> > > Your idea about parsing the XML to remove the hrefs and generate a
> > > larger "virtual" expanded document on the reading side should work fine,
> > >
> > > although it will potentially cause repeated data if a multiref is used
> > > many times.  Probably not a big deal.  I'll respond to the rest of your
> > > other note in another message.
> > >
> > > Thanks,
> > > --Glen
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > >
> > >
> >
> >
> >
> > --
> > Amila Suriarachchi,
> > WSO2 Inc.
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org




--
Amila Suriarachchi,
WSO2 Inc.



--
Amila Suriarachchi,
WSO2 Inc. ------=_Part_20977_5481609.1199441916414--