You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Amila Suriarachchi <am...@gmail.com> on 2007/12/24 07:18:45 UTC
[Axis2] Soap Encoding support with ADB
hi,
Recently I have added the soap encoded support to ADB. Now people can use
soap encoding with the Axis2 as well.
To support the soap encoding, there are a set of special classes in the
org.apache.axis2.databinding.types.soapencoding pacakge.
The org.apache.axis2.databinding.types.soapencoding.Array class is used to
support the SOAP-ENC:Array type.
Lets take this schema fragment
<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>
The generated TestSoapElement2 class has a reference to this soap array
class. This Array class
then can be used to add elements and send the array
for an example objects can be added using the addObject method.
(please see the SoapEncodingTest class under adb-codegen module)
Array array = new Array();
_double testDouble;
for (int i = 0; i < 2; i++) {
testDouble = new _double();
testDouble.set_double(23.45);
array.addObject(testDouble);
}
to add soap encoding types, classes under
org.apache.axis2.databinding.types.soapencoding can be used
and to add the Standard Schema types, classes under
org.apache.axis2.databinding.types.xsd can be used. To add any other complex
type those classes can be used.
this array would serialize as follows
<ns1:TestSoapElement2 xmlns:ns1="http://tempuri.org/soapencoding">
<ns1:param1>test param</ns1:param1>
<ns1:param2 xmlns:s2="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENC="
http://schemas.xmlsoap.org/soap/encoding/"
SOAP-ENC:arrayType="s2:ur-type[2]">
<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="SOAP-ENC:double">23.45</item>
<item xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="SOAP-ENC:double">23.45</item>
</ns1:param2>
</ns1:TestSoapElement2>
since there is no special array type declaration it adds xsi:type for all
the items. the array type can be set
as follows using the setArrayTypeQName method.
Array array = new Array();
array.setArrayTypeQName(new QName("
http://schemas.xmlsoap.org/soap/encoding/", "double"));
_double testDouble;
for (int i = 0; i < 2; i++) {
testDouble = new _double();
testDouble.set_double(23.45);
array.addObject(testDouble);
}
this would serialize like this
<ns1:TestSoapElement2 xmlns:ns1="http://tempuri.org/soapencoding">
<ns1:param1>test param</ns1:param1>
<ns1:param2 xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
SOAP-ENC:arrayType="SOAP-ENC:double[2]">
<item>23.45</item>
<item>23.45</item>
</ns1:param2>
</ns1:TestSoapElement2>
Complex types can also be supported in the same way.
Limitations.
href attribute is not supported.
i.e it can not parse xmls like
<greeting id="String-0">Hello</greeting>
<salutation href="#String-0"/>
ADB creates the java object structure using the direct parsing of the input
xml stream without creating any intermediate structure. Therefore it can not
move the pointer to arbitrary locations.
However it is worth to note that the basic profile discourages usage of soap
encoding
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute.
Therefore this feature is for the users who have to deal with the old wsdls
having soap encoding.
Please help us using this feature and reporting any issues so that I can fix
those issue for Axis2 1.4 release.
Thanks,
Amila.
--
Amila Suriarachchi,
WSO2 Inc.
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
On Jan 4, 2008 2:48 AM, R J Scheuerle Jr <sc...@us.ibm.com> wrote:
> Rich Scheuerle
> IBM Web Services
> Apache Axis2 (scheu@apache.org)
> 512-838-5115 (IBM TL 678-5115)
>
> Glen Daniels <gl...@thoughtcraft.com> wrote on 12/28/2007 12:49:21 AM:
>
> > 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
> astop-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.
>
>
> This will only work for graphs which are strictly trees.
> It will not work for graphs which contain loops. (Even worse, it will
> result in
> an infinite loop).
>
> So this highlights an additional concern. Does ADB, in document/literal
> mode, contain code that
> detects loops and gracefully throws an exception ?
>
No. It can handle loops in schema level. but for object structure there can
not be any loops. Any way with ADB multiref serialization is not also
possible.
Amila.
> I know from prior support work that MS does
> trace loops.
>
>
>
>
> >
> > Thanks,
> > --Glen
> >
> > ---------------------------------------------------------------------
> > 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.
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
I went through the soap 1.1 spec and found this as the first serialization
rule.
All values are represented as element content. A multi-reference value MUST
be represented as the content of an independent element. A single-reference
value SHOULD not be (but MAY be)
It only says if we use multirefs those multi referenced values must be top
elements. But single
reference values are also allowed.
So in axis2 we can use the single references as the default serialization.
thanks,
Amila.
On Dec 28, 2007 12:19 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> 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
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
On Jan 3, 2008 10:52 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Anne, all:
>
> Anne Thomas Manes wrote:
> > 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.
>
> +1
>
> > 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>
> >
> > 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:
>
> If this isn't a top-level element (i.e. if this is an element referenced
> inside an outermost complexType) it's certainly ok - but your point is
> well taken. For RPC style you must use the "type" attribute in WSDL 1.1
> <part> definitions, not the "element" attribute.
>
> As for soapenc:Array - it's not out-of-spec to use it directly, and we
> support this in Axis1. It becomes an Object[].
So you basically telling
<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>
use Object[] as the type of the param2 isn't it?
even in this case people people can not use int, double and they have to use
Integer Double etc..
In this case how we going to extend this to support double arrays? What I
thought
to add soapencoding.Array object as a child object and handle this in
serializing logic.
I agree that in the model I have done it is not much user friendly. But we
can extend that
to support any thing and people can do any thing with it. Sometimes this may
be important than getting
a user friendly interface with a limited functionality (Anyway it is my
personal preference).
But if we don't going to think about this I am ok to change this to Object[]
assuming
only one dimensional arrays being used.
Amila.
>
> In general, Amila, SOAP array types want to turn into language arrays,
> not MyCustomArrayClass, just like SOAP doubles want to turn into
> Doubles/doubles (depending on nillable), not MyDoubleClass.
>
> --Glen
>
> ---------------------------------------------------------------------
> 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.
Re: [Axis2] Soap Encoding support with ADB
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Anne, all:
Anne Thomas Manes wrote:
> 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.
+1
> 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>
>
> 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:
If this isn't a top-level element (i.e. if this is an element referenced
inside an outermost complexType) it's certainly ok - but your point is
well taken. For RPC style you must use the "type" attribute in WSDL 1.1
<part> definitions, not the "element" attribute.
As for soapenc:Array - it's not out-of-spec to use it directly, and we
support this in Axis1. It becomes an Object[].
In general, Amila, SOAP array types want to turn into language arrays,
not MyCustomArrayClass, just like SOAP doubles want to turn into
Doubles/doubles (depending on nillable), not MyDoubleClass.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
Here is the summary of this discussion.
ADB soap encoding support is to provide support for wsdls having soap
encoding schema types.
ADB supports only Single reference serialization and hence graphs with loops
can not be supported. But
multireference parsing is supported.
For a general schema with a soap:Array it generates a code with
soapencoding.Array element.
i.e for a schema like this.
<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>
here param2 type would be a soapencoding.Array.
But for this special type of schema pattern
i.e.
<s:element name="TestSoapElement2">
> <s:complexType>
> <s:sequence>
> <s:element name="param1" type="s:string"/>
> <s:element name="param2" type="tns:ArrayOfInt"/>
> </s:sequence>
> </s:complexType>
> </s:element>
<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>
it sets the param2 type as int[] (given type with a:arrayType attribute)
is this ok?
thanks,
Amila.
--
Amila Suriarachchi,
WSO2 Inc.
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
On Jan 4, 2008 1:45 PM, Amila Suriarachchi <am...@gmail.com>
wrote:
>
>
> On Jan 3, 2008 7:59 PM, Anne Thomas Manes <at...@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.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 <am...@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.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
> > > >
> > > > <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.
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
On Jan 3, 2008 7:59 PM, Anne Thomas Manes <at...@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.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'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 <am...@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.
Re: [Axis2] Soap Encoding support with ADB
Posted by Anne Thomas Manes <at...@gmail.com>.
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>
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 <am...@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 <am...@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
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
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 <am...@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.
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
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 <tj...@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.
RE: [Axis2] Soap Encoding support with ADB
Posted by Tom Jordahl <tj...@adobe.com>.
+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.
I would also argue for "full" multiref support, as servers will be
sending this back to Axis2 clients, right?
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. :-)
--
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
Re: [Axis2] Soap Encoding support with ADB
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
Rich Scheuerle
IBM Web Services
Apache Axis2 (scheu@apache.org)
512-838-5115 (IBM TL 678-5115)
Glen Daniels <gl...@thoughtcraft.com> wrote on 12/28/2007 12:49:21 AM:
> 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
astop-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.
This will only work for graphs which are strictly trees.
It will not work for graphs which contain loops. (Even worse, it will
result in
an infinite loop).
So this highlights an additional concern. Does ADB, in document/literal
mode, contain code that
detects loops and gracefully throws an exception ? I know from prior
support work that MS does
trace loops.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
Re: [Axis2] Soap Encoding support with ADB
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
On Dec 26, 2007 7:37 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Amila:
>
> Amila Suriarachchi wrote:
> > To support the soap encoding, there are a set of special classes in the
> > org.apache.axis2.databinding.types.soapencoding pacakge.
>
> Er... sorry, but -1 on this approach. :(
>
> The point of SOAP encoding is to be able to encode *standard language
> types*. If you have to use a whole separate type hierarchy, which
> appears to be what you've done here, in order to access SOAP encoded
> services, I would say it's not even worth doing.
>
> SOAP encoding should be engaged as a result of either a) a configuration
> switch on the service side, if you start from code, or b) reading an
> RPC/ENC WSDL. However, once it is engaged, you as the user shouldn't
> see it in any intrusive way. Separate types are, to say the least,
> intrusive.
>
> > The org.apache.axis2.databinding.types.soapencoding.Array class is used
> > to support the SOAP-ENC:Array type.
>
> I would especially express concern about this. It's an enormous pain in
> the rear to require conversion of all of your arrays in order to use
> them with an encoded service. :(
>
> > Lets take this schema fragment
> > <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>
> >
> > The generated TestSoapElement2 class has a reference to this soap array
> > class. This Array class
> > then can be used to add elements and send the array
>
> Ugh.
>
> > for an example objects can be added using the addObject method.
> > (please see the SoapEncodingTest class under adb-codegen module)
> > Array array = new Array();
> > _double testDouble;
> > for (int i = 0; i < 2; i++) {
> > testDouble = new _double();
> > testDouble.set_double(23.45);
> > array.addObject(testDouble);
> > }
>
> Whereas this should just be:
>
> double [] array = new double[2];
> for (int i = 0; i < 2; i++) {
> array[i] = 23.45;
> }
>
> > to add soap encoding types, classes under
> > org.apache.axis2.databinding.types.soapencoding can be used
> > and to add the Standard Schema types, classes under
> > org.apache.axis2.databinding.types.xsd can be used.
>
> What?? I have to use an Axis2-specific type to encode a float or a
> STRING?? That's a non-starter.
>
> > Limitations.
> > href attribute is not supported.
> > i.e it can not parse xmls like
> > <greeting id="String-0">Hello</greeting>
> > <salutation href="#String-0"/>
>
> In many ways, Amila, SOAP encoding's benefit is really all about the
> ability to maintain referential integrity across a data graph
> transmitted between different implementations. In SOAP 1.2, where you
> can inline the serialization of your objects and then refer back to them
> later, it can *almost* be acceptable not to do hrefs - in many cases you
> 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 ?
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.
thanks,
Amila.
>
>
> So without multiref support, only simple types will be supported for
> SOAP 1.1 encoding. That's not acceptable.
>
> >
> http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute
> > <
> http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute
> >.
> > Therefore this feature is for the users who have to deal with the old
> > wsdls having soap encoding.
>
> IMO we should either support SOAP encoding or not. If we do it, let's
> make it work for the actual SOAPENC services that people are going to be
> using out there.
>
> > Please help us using this feature and reporting any issues so that I can
> > fix those issue for Axis2 1.4 release.
>
> See above. :) Let's please remove this stuff and either do it right (my
> preference) or not do it at all.
>
> I know you put in a lot of work on this Amila, and I apologize for the
> -1, but this really isn't the right way to go.
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> 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.
Re: [Axis2] Soap Encoding support with ADB
Posted by Amila Suriarachchi <am...@gmail.com>.
On Dec 26, 2007 7:37 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Amila:
>
> Amila Suriarachchi wrote:
> > To support the soap encoding, there are a set of special classes in the
> > org.apache.axis2.databinding.types.soapencoding pacakge.
>
> Er... sorry, but -1 on this approach. :(
>
> The point of SOAP encoding is to be able to encode *standard language
> types*.
yes I agree with you this. So this means this is a code first approach
rather than a contract first approach.
isn't it? I learned this after doing the commit. :(
One question then how another client (except axis2) suppose to access this
service?
> If you have to use a whole separate type hierarchy, which
> appears to be what you've done here, in order to access SOAP encoded
> services, I would say it's not even worth doing.
>
> SOAP encoding should be engaged as a result of either a) a configuration
> switch on the service side, if you start from code, or
> b) reading an RPC/ENC WSDL. However, once it is engaged, you as the user
> shouldn't
> see it in any intrusive way. Separate types are, to say the least,
> intrusive.
I guess this is with contract first .
So lets say we have a schema like this
<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>
The schema defines the param2 has a soapenc:array type. in this case at the
client side (i.e when generating the request) how it supposed to know
whether the service accept soapenc:int or an xsd:int?
What I did was let the user to define it using set of two types. I know this
is not web services. In web services whole contract must be expressed using
the wsdl.
>
> > The org.apache.axis2.databinding.types.soapencoding.Array class is used
> > to support the SOAP-ENC:Array type.
>
> I would especially express concern about this. It's an enormous pain in
> the rear to require conversion of all of your arrays in order to use
> them with an encoded service. :(
I think you mean here code first. But I did it thinking as a contract first
approach. In contact first
approach users have to deal with the ADBBean arrays.
>
>
> > Lets take this schema fragment
> > <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>
> >
> > The generated TestSoapElement2 class has a reference to this soap array
> > class. This Array class
> > then can be used to add elements and send the array
>
> Ugh.
>
> > for an example objects can be added using the addObject method.
> > (please see the SoapEncodingTest class under adb-codegen module)
> > Array array = new Array();
> > _double testDouble;
> > for (int i = 0; i < 2; i++) {
> > testDouble = new _double();
> > testDouble.set_double(23.45);
> > array.addObject(testDouble);
> > }
>
> Whereas this should just be:
>
> double [] array = new double[2];
> for (int i = 0; i < 2; i++) {
> array[i] = 23.45;
> }
>
> > to add soap encoding types, classes under
> > org.apache.axis2.databinding.types.soapencoding can be used
> > and to add the Standard Schema types, classes under
> > org.apache.axis2.databinding.types.xsd can be used.
>
> What?? I have to use an Axis2-specific type to encode a float or a
> STRING?? That's a non-starter.
>
> > Limitations.
> > href attribute is not supported.
> > i.e it can not parse xmls like
> > <greeting id="String-0">Hello</greeting>
> > <salutation href="#String-0"/>
>
> In many ways, Amila, SOAP encoding's benefit is really all about the
> ability to maintain referential integrity across a data graph
> transmitted between different implementations. In SOAP 1.2, where you
> can inline the serialization of your objects and then refer back to them
> later, it can *almost* be acceptable not to do hrefs - in many cases you
> 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>
>
> So without multiref support, only simple types will be supported for
> SOAP 1.1 encoding. That's not acceptable.
Agreed. We can solve this as follows with ADB.
first when we receive the message at the message receiver we can build it.
and process it to eliminate the
herfs and put it into a normal OMElement (without hrefs). Then can get the
pull parser from the new omElement.
Since this new parser generate parse events as a normal xml (with out hrefs)
ADB can parse it.
>
>
> >
> http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute
> > <
> http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute
> >.
> > Therefore this feature is for the users who have to deal with the old
> > wsdls having soap encoding.
>
> IMO we should either support SOAP encoding or not. If we do it, let's
> make it work for the actual SOAPENC services that people are going to be
> using out there.
Totally agreed. When we do something we have to do it in an acceptable
level.
>
>
> > Please help us using this feature and reporting any issues so that I can
> > fix those issue for Axis2 1.4 release.
>
> See above. :) Let's please remove this stuff and either do it right (my
> preference) or not do it at all.
I would like to do this.
First we discuss about the soap encoding and try to clearly figure out what
people expect from it.
Then see whether we can improve this to support those features or not. If
not we have to think about a better way.
Lets start this discussion with these questions.
1. Do we need soap encoding support?
I think for this answer is yes, when considering the features list we
have after hackthon and the deepals release plan.
2. Why people use soap encoding? instead of using standard XmlSchema
construct like maxOccurs = unbounded. why basic profile discourages it?
3. is it a contract first or code first approach? This is a vital question
if it is a code first approach then it has nothing to do with ADB.
4. if it is a contract first approach what type of user interface people
would like to use?
e.g.
<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>
for this type of schema what can we have as the type of the param2?
for the moment it is a org.apache.axis2.databinding.types.soapencoding.Array
class. which people can use to access array elements or
populate them.
>
> I know you put in a lot of work on this Amila, and I apologize for the
> -1, but this really isn't the right way to go.
Ok no problem. Lets discuss this and figure out the correct way.
>
>
> Thanks,
> --Glen
>
> ---------------------------------------------------------------------
> 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.
Re: [Axis2] Soap Encoding support with ADB
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila:
Amila Suriarachchi wrote:
> To support the soap encoding, there are a set of special classes in the
> org.apache.axis2.databinding.types.soapencoding pacakge.
Er... sorry, but -1 on this approach. :(
The point of SOAP encoding is to be able to encode *standard language
types*. If you have to use a whole separate type hierarchy, which
appears to be what you've done here, in order to access SOAP encoded
services, I would say it's not even worth doing.
SOAP encoding should be engaged as a result of either a) a configuration
switch on the service side, if you start from code, or b) reading an
RPC/ENC WSDL. However, once it is engaged, you as the user shouldn't
see it in any intrusive way. Separate types are, to say the least,
intrusive.
> The org.apache.axis2.databinding.types.soapencoding.Array class is used
> to support the SOAP-ENC:Array type.
I would especially express concern about this. It's an enormous pain in
the rear to require conversion of all of your arrays in order to use
them with an encoded service. :(
> Lets take this schema fragment
> <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>
>
> The generated TestSoapElement2 class has a reference to this soap array
> class. This Array class
> then can be used to add elements and send the array
Ugh.
> for an example objects can be added using the addObject method.
> (please see the SoapEncodingTest class under adb-codegen module)
> Array array = new Array();
> _double testDouble;
> for (int i = 0; i < 2; i++) {
> testDouble = new _double();
> testDouble.set_double(23.45);
> array.addObject(testDouble);
> }
Whereas this should just be:
double [] array = new double[2];
for (int i = 0; i < 2; i++) {
array[i] = 23.45;
}
> to add soap encoding types, classes under
> org.apache.axis2.databinding.types.soapencoding can be used
> and to add the Standard Schema types, classes under
> org.apache.axis2.databinding.types.xsd can be used.
What?? I have to use an Axis2-specific type to encode a float or a
STRING?? That's a non-starter.
> Limitations.
> href attribute is not supported.
> i.e it can not parse xmls like
> <greeting id="String-0">Hello</greeting>
> <salutation href="#String-0"/>
In many ways, Amila, SOAP encoding's benefit is really all about the
ability to maintain referential integrity across a data graph
transmitted between different implementations. In SOAP 1.2, where you
can inline the serialization of your objects and then refer back to them
later, it can *almost* be acceptable not to do hrefs - in many cases you
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>
So without multiref support, only simple types will be supported for
SOAP 1.1 encoding. That's not acceptable.
> http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute
> <http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#SOAP_encodingStyle_Attribute>.
> Therefore this feature is for the users who have to deal with the old
> wsdls having soap encoding.
IMO we should either support SOAP encoding or not. If we do it, let's
make it work for the actual SOAPENC services that people are going to be
using out there.
> Please help us using this feature and reporting any issues so that I can
> fix those issue for Axis2 1.4 release.
See above. :) Let's please remove this stuff and either do it right (my
preference) or not do it at all.
I know you put in a lot of work on this Amila, and I apologize for the
-1, but this really isn't the right way to go.
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org