rslib-talk — Generic questions, comments, discussions.

Re: [Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Gerhard W. <ger...@gm...>]

Hi,

just to let you know, I uploaded a new rsl.xsd package to pypi.

I did just a quick fix for all xml-schema data types. The user itself  
has to take care about the actual formatting and type constraints. All  
new integer-based types are mapped to python int and all other new  
types are mapped to python strings (or better unicode strings).

This means if you are going to use xsd:time (which is new in this  
release) you have to do the iso-formatting/parsing for this data type  
yourself. Sorry for that, but the whole code should no longer fail  
reading any valid xsd :)

cheers,

Gerhard

Re: [Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Gerhard W. <ger...@gm...>]

Hi,

>
> I can't say I'm a huge fan of dynamically generated classes, but I  
> believe they have their uses.  If you're going to generate the class  
> from another source anyway, I think it makes sense to do it  
> dynamically in a dynamic language.  They key (and sometimes the  
> difficulty) is to generate the classes early enough so they are  
> available when they're needed.

Yes that definitely makes sense :). (and that's why I am trying to  
keep it in mind.)

>
> What I'm thinking is something like generating a class, and  
> attatching it to the wsdl/proxy object.  So, for example, you could  
> do something like:
> foo = proxy.types.Foo()
> foo.bar = 'bar'
> foo.baz = 123
> where, for instance Foo is a complex type containing members bar (a  
> string) and baz (and integer).

Interesting idea to access the dynamic class via the proxy.

I thought more about attaching it to the schema instance. The schema  
look-up in rsl works upwards in the hierarchy. That means, if you are  
looking for a specific schema-type starting from your WSDL instance,  
the lib tries to find it in the WSDL (which is somewhat like a schema  
manager). If it is not there, it goes up the schema manager hierarchy  
and  looks there, and so on... My idea now was to attach type- 
conversion adapters on the various schema instances . So you can  
override a specific xsd-type for your wsdl, without touching the  
adapters in the hierarchy levels above. Or you can attach adapters  
higher in the hierarchy which allows you to share them between  
instances lower in the hierarchy. This allows having different xsd- 
type python-class association for different xsd/wsdl instances.

I added the schema manager hierarchy, because I wanted to keep various  
well-known xml-schemas just once in memory. Additionally this allows  
also to do configurations or tweaks to these schemas just once. (In  
case this is not useful for a specific use case, it is always possible  
using other root-schema managers than the global one.)

For accessing the definition of a dynamic generated class I had  
something like this in mind:

foo = IDynamicClass(wsdl.getType('<fully qualified xsd-type name>'))()

(I am not sure whether an adaption like that would work or not, but I  
am sure somehow it can be done.)

So you retrieve the xsd-class definition, and the IDynamicClass  
adapter returns the class-definition (or a factory) which you can call  
to generate instances of it. (Or maybe some kind of utility method  
which does the adaption for you, based on a schema instance where you  
start to look for a xsd-type definition and a type name. This would  
then resemble named adapters.)
The point I really like on the adaption stuff is, that it can easily  
be added as additional package without requiring me to include class- 
generation code into the main package. (and maybe forces me to  
maintain this code too :) )

Btw. another Idea I am following in the 0.3 branch is, for complex  
types it may well be useful to re-use class/type associations.
e.g.: if you think of a person, with the attributes name and address.  
name is a simple string and address is another complex type.
A person instance would then reuse the python string-class for it's  
name attribute and maybe another custom address class for it's address  
attribute.
If the address xsd-type is re-used in various other xsd-types than  
person, then all the types could re-use this definition. (At least  
this is how it currently works in the 0.3-branch). How the sub- 
elements and attributes of a xml-person element are associated with  
the Person class is completely up to the type-converter registered on  
the schema-instance.

>
> I'm not a SOAP/WSDL expert, but does WSDL separate interface from  
> the endpoint?  In other words, if I have to services that are  
> identical except for URL, is there a way for each service to say  
> "hey, I'm just a service that implements interface ABC?"  If so,  
> then it would make most sense to associate the classes with that.

Once you've parsed the WSDL, you know should know which endpoint  
offers which interface. WSDL defines the interface separately. The an  
interface is bound to a protocol. (e.g. HTTP, SOAP, etc...), And at  
the end a protocol-binding is associated with an endpoint in a 1:1  
relation. While it is legal to associate various protocol-bindings  
with the same endpoint-url (for each such association there is one  
endpoint definition), I have not seen it yet, that a service offers  
different interfaces for the same endpoint-url.
For sure you can also associate one and the same specific binding with  
multiple endpoints. If both endpoint-urls are in the same WSDL, then  
it is no problem to accept them as equal. If the endpoint's come from  
different WSDL's, then it is not always that easy to consider the  
interfaces associated with the endpoints as equal. (Unfortunately name  
space uniqueness is not always given.)

If you associate the dynamic classes with the proxy then you'll have  
an association of a single endpoint url assigned to the proxy, and the  
python-classes are only valid for this url.
If you do it on the schema in the WSDL, it is for all endpoints in the  
WSDL. (I am not sure which one is better, but maybe it makes sense to  
extend the look-up hierarchy described above to allow both.)

>
> Anyway, I know you're busy, and it's not really that important to  
> me.  But, in a perfect world, I'd envision something like that.

No worries about that, there is always time for collecting ideas, it  
just may take a while until they are implemented, and my experience  
tells me, the better the plan the less time you'll spend on  
implementing it.

I hope my I was able to explain my Ideas, it is quite some time ago, I  
thought about this stuff.

>
> Take Care,
>
> Nathan Davis

Re: [Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Nathan D. <dav...@gm...>]

On Wed, Aug 26, 2009 at 12:05 AM, Gerhard Weis <ger...@gm...> wrote:

>
>> I'm curious what your plans are for expanding this in the future -- or,
>> actually, the type system in general.  It would be nice, for example, to be
>> able to work with types defined in the schema as python classes.  I'd like
>> to get your thoughts on the feasibility of dynamically generating python
>> classes from schemas.
>>
>
> If you are really curious on reading a bit of python code you can have a
> look into the source-repository (http://hg.proclos.com/rslib) or
> specifically for the rsl.xsd package: http://hg.proclos.com/rslib/rsl.xsd/ ...
> I did already quite a bit of work on the br-0.3-dev branch. The idea behind
> is, to use parts of the zope component architecture (I think this will be
> just the zope.interface package) to make the whole type-system pluggable.
>
> The main goals of this branch are to allow custom python classes to be
> used, with rsl.xsd. Basically you'll need to register an adapter which does
> a simple transformation from a python object to an  representation which
> rsl.xsd understands (currently simple dictionaries).....
>

Yes, that sounds useful as well.


>
> Regarding dynamically generated python classes:
>
> Personally I am not a fan of dynamically generated classes. However, the
> rsl.xsd 0.3 branch should make it rather easy to add a separate package
> supporting this use case, or generate python code or whatever. For instance
> I could imagine to add an adapter for various xsd:types which generates
> classes on the fly. So I won't ignore dynamic class creation/code creation,
> but I think I won't create such a package by myself. If someone wants to do
> it, I can definitely provide help on how to use rsl.xsd, but my main
> priority is to move the whole rsl-stuff up to the rsl.xsd 0.3 branch. And
> stabilise the whole thing. Another thing which I want to do before I think
> of class/code creation, is to add support for WSDL2 and some additional WS-X
> standards like WS-Addressing and WS-Security etc....
>

I can't say I'm a huge fan of dynamically generated classes, but I believe
they have their uses.  If you're going to generate the class from another
source anyway, I think it makes sense to do it dynamically in a dynamic
language.  They key (and sometimes the difficulty) is to generate the
classes early enough so they are available when they're needed.

What I'm thinking is something like generating a class, and attatching it to
the wsdl/proxy object.  So, for example, you could do something like:

> foo = proxy.types.Foo()
> foo.bar = 'bar'
> foo.baz = 123
>
where, for instance Foo is a complex type containing members bar (a string)
and baz (and integer).

I'm not a SOAP/WSDL expert, but does WSDL separate interface from the
endpoint?  In other words, if I have to services that are identical except
for URL, is there a way for each service to say "hey, I'm just a service
that implements interface ABC?"  If so, then it would make most sense to
associate the classes with that.

Anyway, I know you're busy, and it's not really that important to me.  But,
in a perfect world, I'd envision something like that.

Take Care,

Nathan Davis

Re: [Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Gerhard W. <ger...@gm...>]

Hi Nathan,

I oversaw one of your questions :)

>
> Incidently, would it be possible to monkey-patch this -- for  
> example, if another type was missing or (heaven forbid) someone  
> referenced a non-standard xsd type in their WSDL?

Normally I'd consider a service with such a WSDL as broken,  
unfortunately there are a lot of broken WSDLs out there.

I think the simples thing to do in such a case is to add a similar  
definition for such types directly into the xsd-instance just like you  
did it with xsd:token.
(just choose or implement a suitable alternative for AnySimpleType if  
you need something different.)

The standard xsd-schema should be accessible via the global schema  
manager (see rsl/xsd/manager.py and somewhere should be code how to  
access it, but as a quick fix you can access it directly there.)

from rsl.xsd.manager import GLOBALSCHEMAMANAGER

xsd = GLOBALSCHEMAMANAGER.getSchema('http://www.w3.org/2001/XMLSchema')
xsd.types['.....'] = AnySimpleType(......)


the thing with accessing the GLOBALSCHEMAMANAGER directly will also go  
away in rsl.xsd >= 0.3 (zope's AdapterFactory will make this a lot  
easier)

cheers,

Gerhard

Re: [Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Gerhard W. <ger...@gm...>]

Hi Nathan,


> That did it!  I can't say I called the service successfully, but at  
> least I'm past that error.  Now it's just a matter of figuring out  
> how to form the other parameters to make the server happy --  
> fortunately it provides fairly descriptive error strings.

so far good to hear :)

>
> Would a complete fix also include adding the same line to  
> createCSD99Schema?

Yes, but I have not seen a service which uses the old xml-schema name- 
space for a long time. Basically it is just there to satisfy my tests.

> Thanks.  I'm doing for a client, so that would be very helpful.

You're welcome.

>
> Incidently, would it be possible to monkey-patch this -- for  
> example, if another type was missing or (heaven forbid) someone  
> referenced a non-standard xsd type in their WSDL?

I'll go through the list of xsd-types and will add them. Derived types  
from other name-spaces should be created automatically. It's just the  
the types defined in xml-schema which need to be registered there. I  
know it is not a very clean solution, but as xsd is defined by itself  
I could not think of an easy solution to overcome this issue.

>
> I'm curious what your plans are for expanding this in the future --  
> or, actually, the type system in general.  It would be nice, for  
> example, to be able to work with types defined in the schema as  
> python classes.  I'd like to get your thoughts on the feasibility of  
> dynamically generating python classes from schemas.

If you are really curious on reading a bit of python code you can have  
a look into the source-repository (http://hg.proclos.com/rslib) or  
specifically for the rsl.xsd package: http://hg.proclos.com/rslib/rsl.xsd/ 
  ... I did already quite a bit of work on the br-0.3-dev branch. The  
idea behind is, to use parts of the zope component architecture (I  
think this will be just the zope.interface package) to make the whole  
type-system pluggable.

The main goals of this branch are to allow custom python classes to be  
used, with rsl.xsd. Basically you'll need to register an adapter which  
does a simple transformation from a python object to an   
representation which rsl.xsd understands (currently simple  
dictionaries).....
An additional goal is that custom python classes should be completely  
unaware of such a transformation makeing it easier to include third  
party code. (that's why I am using zope.interface and adaptation).
Furthermore the br-03.dev implementation supports a lot more features  
of xml-schema, like xsd:groups etc. It also does a better job in type  
conversion regarding string formatting for the xml-representation and  
respects various xsd:facets defined in an xml-schema.

Unfortunately I have not had much time lately to work on it, but I  
think it is rather close to be finished for a first release. (At least  
it should provide the same amount of functionality as the 0.2.x  
release series before I make a release).

I also plan to refactor all the other rsl.xxx parts to use  
zope.interface and adaption, which should make it much easier to  
customise various aspect of the library.

Regarding dynamically generated python classes:

Personally I am not a fan of dynamically generated classes. However,  
the rsl.xsd 0.3 branch should make it rather easy to add a separate  
package supporting this use case, or generate python code or whatever.  
For instance I could imagine to add an adapter for various xsd:types  
which generates classes on the fly. So I won't ignore dynamic class  
creation/code creation, but I think I won't create such a package by  
myself. If someone wants to do it, I can definitely provide help on  
how to use rsl.xsd, but my main priority is to move the whole rsl- 
stuff up to the rsl.xsd 0.3 branch. And stabilise the whole thing.  
Another thing which I want to do before I think of class/code  
creation, is to add support for WSDL2 and some additional WS-X  
standards like WS-Addressing and WS-Security etc....

Cheers,

Gerhard

Don't hesitate to ask if you have any further problems or suggestions :)

Re: [Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Nathan D. <dav...@gm...>]

On Tue, Aug 25, 2009 at 10:45 PM, Gerhard Weis <ger...@gm...> wrote:

> Hello,
>

Hi, Gerhard,


>
> thanks for that and great to hear, that the library is also useful for
> others.
>
> I am currently a bit busy, but I will definitely have a closer look at your
> problem later today or tomorrow.
>
> However, as of a quick look I would say I forgot to register the xsd:token
> type.
>
> You can try to fix it in the rsl.xsd package the following way:
>   in rsl/xsd/factories.py int the method: createXSD01Schema add the line:
>      xsd.types["token"] = AnySimpleType("token", xsd)
>
> While I can't guarantee that this will work, I think it should do it.
>

That did it!  I can't say I called the service successfully, but at least
I'm past that error.  Now it's just a matter of figuring out how to form the
other parameters to make the server happy -- fortunately it provides fairly
descriptive error strings.

Would a complete fix also include adding the same line to createCSD99Schema?


>
> As mentioned above, I'll do a new release today or tomorrow after running
> the test-suite with this change.
>

Thanks.  I'm doing for a client, so that would be very helpful.

Incidently, would it be possible to monkey-patch this -- for example, if
another type was missing or (heaven forbid) someone referenced a
non-standard xsd type in their WSDL?


>
> As a note: Type restrictions based on xsd:enumeration are currently ignored
> by rsl.xsd ... You can definitely work with it, but you have to care
> yourself about suppllying correct values to this attribute.
>

I'm curious what your plans are for expanding this in the future -- or,
actually, the type system in general.  It would be nice, for example, to be
able to work with types defined in the schema as python classes.  I'd like
to get your thoughts on the feasibility of dynamically generating python
classes from schemas.

Thank you so much,

Nathan Davis

Re: [Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Gerhard W. <ger...@gm...>]

Hello,

thanks for that and great to hear, that the library is also useful for  
others.

I am currently a bit busy, but I will definitely have a closer look at  
your problem later today or tomorrow.

However, as of a quick look I would say I forgot to register the  
xsd:token type.

You can try to fix it in the rsl.xsd package the following way:
    in rsl/xsd/factories.py int the method: createXSD01Schema add the  
line:
       xsd.types["token"] = AnySimpleType("token", xsd)

While I can't guarantee that this will work, I think it should do it.

As mentioned above, I'll do a new release today or tomorrow after  
running the test-suite with this change.

As a note: Type restrictions based on xsd:enumeration are currently  
ignored by rsl.xsd ... You can definitely work with it, but you have  
to care yourself about suppllying correct values to this attribute.

Regards,

Gerhard

On 26/08/2009, at 12:08 PM, Nathan Davis wrote:

> Hello,
>
> First of all, I want to thank the RSL developer(s) for the work  
> they've done.  I've had problems with other web services libraries,  
> like SOAPpy, which RSL seems to handle just fine.  Keep up the good  
> work!
>
> I'm trying to call the web service described by https://voltage-pp-0000.poc5.vspilot.org/vibesimple/wsdl 
> .  I'm using RSL 0.2.1 with the following code to invoke the  
> ProtectCreditCardNumber function:
>
> import rsl.wsdl.wsdl
>
> wsdl_url = "https://voltage-pp-0000.poc5.vspilot.org/vibesimple/wsdl"
> wsdl = rsl.wsdl.wsdl.loadWSDL(wsdl_url)
> proxy = wsdl.getProxy()
>
> proxy.ProtectCreditCardNumber("123456789", "user", None,  
> "UserPassword", \
> "password")
>  When I run this, however, I get the following exception:
>  KeyError: 'Type token in namespace http://www.w3.org/2001/XMLSchema  
> not found'
> I believe this is because of the 4th parameter.  It's type,  
> AuthMethod, is defined in the WSDL as follows:
> <xsd:simpleType name="AuthMethod">
>   <xsd:restriction base="xsd:token">
>     <xsd:enumeration value="UserPassword"/>
>     <xsd:enumeration value="SharedSecret"/>
>     <xsd:enumeration value="Certificate"/>
>     <xsd:enumeration value="AuthToken_HMAC_SHA1"/>
>   </xsd:restriction>
> </xsd:simpleType>
> Am I doing something wrong, or is this a bug/limitation in RSL?
>
> The exception stacktrace is as follows:
> Traceback (most recent call last):
>   File "protectcc_example.py", line 8, in <module>
>     print proxy.ProtectCreditCardNumber("123456789", "user", None,  
> "UserPassword", "password")
>   File "build/bdist.linux-x86_64/egg/rsl/soap11/proxy.py", line 109,  
> in __call__
>   File "build/bdist.linux-x86_64/egg/rsl/soap11/proxy.py", line 130,  
> in serialize
>   File "build/bdist.linux-x86_64/egg/rsl/soap11/serializer.py", line  
> 125, in serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 67, in serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 129, in serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 199, in _serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 169, in _serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line  
> 156, in _serialize
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line  
> 189, in encode
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line  
> 275, in encode
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line  
> 247, in _getbasecontent
>   File "build/bdist.linux-x86_64/egg/rsl/xsd/schema.py", line 248,  
> in getType
> KeyError: 'Type token in namespace http://www.w3.org/2001/XMLSchema  
> not found'
>
> Thanks,
>
> Nathan Davis
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
> Rslib-talk mailing list
> Rsl...@li...
> https://lists.sourceforge.net/lists/listinfo/rslib-talk

[Rslib-talk] Type token in namespace http://www.w3.org/2001/XMLSchema not found

[Nathan D. <dav...@gm...>]

Hello,

First of all, I want to thank the RSL developer(s) for the work they've
done.  I've had problems with other web services libraries, like SOAPpy,
which RSL seems to handle just fine.  Keep up the good work!

I'm trying to call the web service described by
https://voltage-pp-0000.poc5.vspilot.org/vibesimple/wsdl.  I'm using RSL
0.2.1 with the following code to invoke the ProtectCreditCardNumber
function:


import rsl.wsdl.wsdl

wsdl_url = "https://voltage-pp-0000.poc5.vspilot.org/vibesimple/wsdl"
wsdl = rsl.wsdl.wsdl.loadWSDL(wsdl_url)
proxy = wsdl.getProxy()

proxy.ProtectCreditCardNumber("123456789", "user", None, "UserPassword", \
"password")

 When I run this, however, I get the following exception:

 KeyError: 'Type token in namespace http://www.w3.org/2001/XMLSchema not
found'

I believe this is because of the 4th parameter.  It's type, AuthMethod, is
defined in the WSDL as follows:

<xsd:simpleType name="AuthMethod">
  <xsd:restriction base="xsd:token">
    <xsd:enumeration value="UserPassword"/>
    <xsd:enumeration value="SharedSecret"/>
    <xsd:enumeration value="Certificate"/>
    <xsd:enumeration value="AuthToken_HMAC_SHA1"/>
  </xsd:restriction>
</xsd:simpleType>

Am I doing something wrong, or is this a bug/limitation in RSL?

The exception stacktrace is as follows:

Traceback (most recent call last):
  File "protectcc_example.py", line 8, in <module>
    print proxy.ProtectCreditCardNumber("123456789", "user", None,
"UserPassword", "password")
  File "build/bdist.linux-x86_64/egg/rsl/soap11/proxy.py", line 109, in
__call__
  File "build/bdist.linux-x86_64/egg/rsl/soap11/proxy.py", line 130, in
serialize
  File "build/bdist.linux-x86_64/egg/rsl/soap11/serializer.py", line 125, in
serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 67, in
serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 129, in
serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 199, in
_serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 169, in
_serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/serializer.py", line 156, in
_serialize
  File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line 189, in
encode
  File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line 275, in
encode
  File "build/bdist.linux-x86_64/egg/rsl/xsd/component.py", line 247, in
_getbasecontent
  File "build/bdist.linux-x86_64/egg/rsl/xsd/schema.py", line 248, in
getType
KeyError: 'Type token in namespace http://www.w3.org/2001/XMLSchema not
found'


Thanks,

Nathan Davis

Re: [Rslib-talk] Return question

[Gerhard W. <ger...@gm...>]

Hi,

Sorry for the long time to answer.

I had a closer look into supporting wsdl:arrayType attribute or  
soapenc:arrayType attribute, and came to the decision, that it would  
be quite cumbersome and a fair bit of effort to support them in the  
rsl.xsd and/or rsl.soap11 0.2.x versions.

I'll rather put some more effort into the next version, where this  
will be much easier.

Sorry for that. I hope it was possible for you to make the service  
endpoint WS-I compliant. This will probably solve the problem with  
about any SOAP framework (including rslib :) ).

cheers,

Gerhard

On 21/02/2009, at 7:29 PM, Gerhard Weis wrote:

>
> ......
>
> 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.
>
> ......
>

Re: [Rslib-talk] Return question

[Gerhard W. <ger...@gm...>]

Sorry,

The WS-I BasicProfile is a bit more restrictive with SOAP-ENC:Array  
than I remember.  (and I made a few other errors.)

The WS-I BasicProfile  says:
R2110 In a DESCRIPTION, array declarations MUST NOT extend or restrict  
the soapenc:Array type.
R2111 In a DESCRIPTION, array declarations MUST NOT use wsdl:arrayType  
attribute in the type declaration.
R2112 In a DESCRIPTION, array declaration wrapper elements SHOULD NOT  
be named using the convention ArrayOfXXX.
R2113 A MESSAGE containing serialized arrays MUST NOT include the  
soapenc:arrayType attribute.

The WS-I compliant schema example should read:

<xsd:complexType name="Common.StringSequence">
	<xsd:complexContent>
			<xsd:sequence>
				<element name="item" type="xsd:string" minOccurs="0"  
maxOccurs="unbounded"/>
			</xsd:sequence>
		</xsd:restriction>
	</xsd:complexContent>
</xsd:complexType>

Cheers,

Gerhard

Re: [Rslib-talk] Return question

[Gerhard W. <ger...@gm...>]

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

Re: [Rslib-talk] Basic auth, location, and WSDL questions

[Gerhard W. <ger...@gm...>]

Hello Matt,

Thanks for your comments.

On 09/02/2009, at 6:42 AM, Matt C wrote:

> Thanks for writing the package - it looks very good and it's  
> encouraging to see some life in the Python SOAP world. I've got a  
> few questions (hopefully these will help the documentation effort at  
> some point):
>
> 1) Does anyone have an example of a call with HTTP basic auth? The  
> project I am working on requires it.
>
HTTP basic auth can be handled with standard python urllib2 handlers.  
The package 'rsl' contains a basic auth handler. However you might  
want to customise it to your needs. (see rsl.misc.http). I.e. have a  
look at 'def installopener'. This method installs the default  
urllib2.HTTPBasicAuthHandler. The class 'AskPasswordHandler' in this  
module asks for a password at the command line. So you migth provide  
your own PasswordHandler here.

> 2) Is there a way for me to load a WSDL from disk as opposed to  
> calling it remotely? We plan to have a bunch of WSDLs in a local  
> directory that you can load and point to various remote systems  
> which all support the same methods.
>
The easiest way to load WSDLs from disk is to use the 'file:' url  
scheme instead of e.g. 'http://'.
If you need more control, have a look at loadWSDL in package  
rsl.wsdl.wsdl.

> 3) From what I can see it looks like rsl pulls the end point  
> information from the WSDL. I'd like to be able to set the hostname  
> of a remote service when I instantiate a proxy object (similar to  
> ZSI's ServiceProxy class). I've tried setting the location attribute  
> after building the proxy but this doesn't seem to work.
>
  This is definitely possible, but you need to manipulate the end  
point url in the WSDL-File itself or you can do it on the instantiated  
WSDL. However, there is not enough API available on the WSDL instance,  
so you have to do this manually.

Probably the easisest way is to do the following:

portlist = wsdl._getportlist(namespace=NS_SOAP)
# _getportlist supports also servicename and portname parameters;  
servicename is a fully qualified name.
# for each port in portlist you can update the location attribute
portlist[0].location = 'newurl'

Proxies created after that should have the new location attribute as  
endpoint address.
(If it does not work, please let me know, and I'll digg more into it.)

If you want to change the endpoint address on the proxy you have to do  
it for each single operation.
I guess the whole point 3 needs a some more attention in future  
development. :)

> 4) Are there any plans to generate classes from WSDLs?
>
Nothing concrete for now.
The plan is, to create nice dynamic modules for xml-schema and wsdl.  
After these modules are finished, it should not  be a big deal to  
write some kind of code-generator (dynamic or static.).
The current plan for xml-schema is to provide a pluggable mechanism to  
use custom classes instead of the standard python data type for de/ 
serialisation. This mechanism will likely use plenty of code and ideas  
from the zope component architecture in the background.
Another design goal is, to create a nice component architecture, were  
all components are replaceable/adaptable. This should make it possible  
to 'plug' a class generator into the whole component-architecture if  
needed. (Or even write an additional script which uses the available  
components and generates some code just like wsdl2py).

> Many thanks!
>
> Matt
>

I hope this helps,

If you have any further questions, issues, suggestions, I am happy to  
help out.

cheers

Gerhard

[Rslib-talk] Basic auth, location, and WSDL questions

[Matt C <mca...@gm...>]

Thanks for writing the package - it looks very good and it's encouraging to
see some life in the Python SOAP world. I've got a few questions (hopefully
these will help the documentation effort at some point):

1) Does anyone have an example of a call with HTTP basic auth? The project I
am working on requires it.

2) Is there a way for me to load a WSDL from disk as opposed to calling it
remotely? We plan to have a bunch of WSDLs in a local directory that you can
load and point to various remote systems which all support the same methods.

3) From what I can see it looks like rsl pulls the end point information
from the WSDL. I'd like to be able to set the hostname of a remote service
when I instantiate a proxy object (similar to ZSI's ServiceProxy class).
I've tried setting the location attribute after building the proxy but this
doesn't seem to work.

4) Are there any plans to generate classes from WSDLs?

Many thanks!

Matt