Component model, webservices and xmlrpc?
This is a question for those that understand where the component model and webservices are headed with zope. I'm asking since I'm trying to understand the direction zope is headed I just had to let someone access some RDBS data easily. Its already used in zope so I figured the easiest way was xmlrpc to the SQLMethod. Of course it wasn't that simple since sqlmethods return results set classes which are not marshalable via xmlrpc. In the end I had to write a python script wrapper around the sql method to turn it into a dictionary and replace all the Missing objects to blank strings. My question is, in the brave new world of the component model etc would such a scenario this be simpler? and how? I myself can see two ways out: - have a better webservice framework that lets you return objects rather than structures (more like com). I'm not sure if this what SOAP does or not. It seems a big ask since essentially the state would need to be kept on server side and proxy objects would need to connect back to that state for some untermined period of time. Potentially ugly but I can see it being very powerful. - Have the ability to turn abitary classes into mashallable data. In this case the results class could support an results interface. There would be an adapter that knew how to turn objects implementing the results interface into xmlrpc marshallable data. Such adapters would be made for most standard objects? Am I right in saying the zope roadmap will make both of these possible in the not too distant future?
I just had to let someone access some RDBS data easily. Its already used in zope so I figured the easiest way was xmlrpc to the SQLMethod. Of course it wasn't that simple since sqlmethods return results set classes which are not marshalable via xmlrpc. In the end I had to write a python script wrapper around the sql method to turn it into a dictionary and replace all the Missing objects to blank strings.
My question is, in the brave new world of the component model etc would such a scenario this be simpler? and how?
I sure hope so :)
I myself can see two ways out:
- have a better webservice framework that lets you return objects rather than structures (more like com). I'm not sure if this what SOAP does or not. It seems a big ask since essentially the state would need to be kept on server side and proxy objects would need to connect back to that state for some untermined period of time. Potentially ugly but I can see it being very powerful.
SOAP is structure-oriented (there are no object references), but this can still be very powerful if the system is well architected.
- Have the ability to turn abitary classes into mashallable data. In this case the results class could support an results interface. There would be an adapter that knew how to turn objects implementing the results interface into xmlrpc marshallable data. Such adapters would be made for most standard objects?
Am I right in saying the zope roadmap will make both of these possible in the not too distant future?
The component model should be able to accomodate that case. You'd essentially be implementing a custom xml-rpc "presentation" of the object. Your custom implementation would handle the marshalling to the xmlrpc stream. Alternatively, the web services framework should provide a an alternative way to achieve the goal. Using (SOAP) web services, you could implement a web service that probably calls the existing sqlmethod and returns the results. The WS framework will be able to marshal many objects automatically based on an xml schema. That means that you would basically define a WSDL document that includes the schema and the marshalling would be done for you. Note that there is a little hand-waving here - I have some proofs of concept, but not as many hard details to give you as I'd like. Hope this helps though. Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com
participants (2)
-
Brian Lloyd -
Jay, Dylan