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*.
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Amila Suriarachchi,
WSO2 Inc.
