Re: [Rslib-talk] Return question

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello,

Thanks for this use case. I appreciate all problematic service and bug  
reports :)

This is a common problem with soap-encoding in rslib; especially with  
SOAP-ENC:Array structures.

The first thing is, that rslib does not make any assumptions on the  
return values. This is why you'll get a dictionary with {'return':  
<something>} back. (The name 'return' comes from the message part  
definition in the wsdl). I tested with a couple of other services, and  
many of them use different element names than 'return', so  I decided  
to keep this name in the return value. This makes it also possible to  
cope with even more strange services, which return more than one value.

The other thing with the the content in the return value is, that the  
SOAP-ENC:Array schema defines that '##any' element can be used as  
content in the array. The soap-encoding implementation again makes no  
assumptions here, and hence does not know anything about the content.  
This is why the response is not fully decoded. It only does as far as  
the schema describes the data. In your case the schema says, 'return'  
is an array with '##any' element. This means, that 'return' is then a  
list, and all elements in this list are left as xml-strings.  Each  
element has a single entry in the list. You should be able to parse  
each element with any xml-parser to decode it. (I know, that is a  
quite a bit cumbersome, but a very easy solution without loosing any  
information, that covers almost all possible cases :) ).

The 'wsdl:arrayType' attribute is completely ignored by the soap- 
enconding implementation in rslib, because I have not found a clean  
way to access this information at this point of time. The problem with  
it is, that a type definition with this attribute happens outside the  
schema. Besides that, the usage of 'wsdl:arrayType' is discouraged buy  
the WS-I-Profile, and so I did not bother any more.

The cleanest solution would be, if the service provider could define a  
nicer (WS-I compliant) schema.
e.g.: instead of

<xsd:complexType name="Common.StringSequence">
	<xsd:complexContent>
		<xsd:restriction base='SOAP-ENC:Array'>
			<xsd:attribute ref='SOAP-ENC:arrayType'  
wsdl:arrayType='xsd:string[]'/>
		</xsd:restriction>
	</xsd:complexContent>
</xsd:complexType>

it should say: (note this is the WS-I compliant definition)

<xsd:complexType name="Common.StringSequence">
	<xsd:complexContent>
		<xsd:restriction base='SOAP-ENC:Array'>
			<xsd:sequence>
				<element name="item" type='xsd:string' minOccurs='0'  
maxOccurs='unbound'>
			<xsd:sequence>
			<xsd:attribute ref='SOAP-ENC:arrayType'  
wsdl:arrayType='xsd:string[]'/>
		</xsd:restriction>
	</xsd:complexContent>
</xsd:complexType>

Another solution would be, to include  "  xsi:type='xsd:string'  "   
attributes on each item in the return response, but this is not as  
clean as the first solution before.

However, I'll have a look into the soap-encoding code. I can try to  
add a special implementation for SOAP-ENC:Array which tries a bit  
harder to find some meaningful values, than the pure schema based  
implementation currently does. I just had no use case where this would  
have been necessary, because almost all useful rpc-encoded services on  
the Net are already WS-I compliant.

The problems for the create request are similar, just the other way  
around because it has to deal with xml-serialisation, instead of  
deserialisation. I have a test case for a similar array encoding and  
there it works the following way:

create(pool_names={'any': ['pc2']},
             lb_methods={'any': ['LB_METHOD_ROUND_ROBIN']},
             members={'any': [ {'any': [{'address': '10.20.20.220',  
'port':80}]}]})

(Note the 'any' element to mark the actual array content)

The 'members' parameter is a bit strange because it is defined as an  
array of arrays.

Summary:
The encoding should work as described above, and for the decoding,  
I'll have a look how much effort it is to implement. However, as I can  
not really use the wsdl:arrayType attribute in rslib (becaue of the  
overall design), it will be a rather clumsy solution.

Again I have to say with the next version of rsl.xsd it will be a lot  
easier to add custom de/serialisation mechanisms for specific types  
and/or manipulate the schema after it has been instantiated. Btw.  
progress is going forward, and it works already for very simple cases.  
So it should not take too long.

I hope this helps, and will let you know soon, if the custom SOAP- 
ENC:Array implementation works.
Please let me know, if it is possible to make the service definition  
WS-I compliant, because then it should work anyway.

Gerhard

On 21/02/2009, at 5:04 PM, Matt C wrote:

> I'm using the attached WSDL and getting the following results,  
> calling the get_list() and create() methods defined there. For the  
> get_list() method it looks like the 'return' dict is preventing me  
> from getting a clean response, in this case an object named "test".  
> Any ideas on how I may be able to address this?
>
> C:\tmp>c:\Python25\python.exe test.py
> {'return': ['<item xmlns:m="urn:iControl:LocalLB/Pool" xmlns:E="http://schemas 
> .x
> mlsoap.org/soap/envelope/" xmlns:A="http://schemas.xmlsoap.org/soap/encoding/ 
> " x
> mlns:s="http://www.w3.org/2001/XMLSchema-instance" xmlns:y="http://www.w3.org/20
> 01/XMLSchema" xmlns:iControl="urn:iControl">test</item>\n']}
>
> Also, when running "create" like so (using the same structures I use  
> with ZSI ServiceProxy, maybe a bad assumption):
> In [13]: p.create(pool_names = ['pc2'],  
> lb_methods=['LB_METHOD_ROUND_ROBIN'], members = [{'address':  
> '10.20.20.220', 'port':80}])
> Out[13]: (None, None)
>
> I'm unable to do a successful create:
>
> In [14]: p.get_list()
> Out[14]:
> (None,
>  {'return': ['<item xmlns:m="urn:iControl:LocalLB/Pool" xmlns:E="http://schemas 
> .
> xmlsoap.org/soap/envelope/" xmlns:A="http://schemas.xmlsoap.org/soap/encoding/ 
> "
> xmlns:s="http://www.w3.org/2001/XMLSchema-instance" xmlns:y="http://www.w3.org/2
> 001/XMLSchema" xmlns:iControl="urn:iControl">test</item>\n']})
>
> Any insights would be greatly appreciated.
> -Matt
>
>
> < 
> LocalLB 
> .Pool 
> .wsdl 
> > 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San  
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the  
> Enterprise
> -Strategies to boost innovation and cut costs with open source  
> participation
> -Receive a $600 discount off the registration fee with the source  
> code: SFAD
> http://p.sf.net/sfu/XcvMzF8H_______________________________________________
> Rslib-talk mailing list
> Rsl...@li...
> https://lists.sourceforge.net/lists/listinfo/rslib-talk