On Dec 26, 2007 7:37 PM, Glen Daniels <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Amila Suriarachchi,
WSO2 Inc.
