On Jan 4, 2008 1:45 PM, Amila Suriarachchi <[EMAIL PROTECTED]>
wrote:
>
>
> On Jan 3, 2008 7:59 PM, Anne Thomas Manes <[EMAIL PROTECTED]> 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.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
<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 <[EMAIL PROTECTED]>
> > 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 <
> > [EMAIL PROTECTED]>
> > > 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 < [EMAIL PROTECTED]> 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:[EMAIL PROTECTED] ]
> > > > > 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: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Amila Suriarachchi,
> > > > WSO2 Inc.
> > >
> > >
> > >
> > > --
> > > Amila Suriarachchi,
> > > WSO2 Inc.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
--
Amila Suriarachchi,
WSO2 Inc.
