Hi Ian,
> I might play around with object publishing in Webware using this... the
> implementation seems fairly simple. Anyway, I'm interested in feedback
> too, which is why I posted here in the first place ;)
I'm neither an Webware nor an XMLRPC expert, but I have some experiences
with SOAP. In my opinion, your design hits some problems which are not
solvable in a general fassion. I'll try my best to explain it (but keep in
mind that I'm not a native speaker, so feel free to ask if something is not
clear):
What you try to build is some kind of statefull XMLRPC protocol. There are
already technics to do this: COM, CORBA, ... but they have their own
problem. XMLRPC and SOAP were build with fast, stateless single calls in
mind to work around the problems of COM and CORBA. The main problem of COM
and CORBA is, that somebody has to manage the object. The liftetime of the
object is usually managed on the server, but then you have a problem if the
connection breaks. Using XMLRPC and SOAP you can not realy hold objects on
the server, so you have to manage the objects on the client. To do this, you
store the state information of the object on the client and send it to the
server each time you call a method. In your example, this is only the id,
but it could be a lot of other state informations. Sending all this
information all the time would produce a lot of useless network overhead. In
general you can not decide, if property x affects a call to method y.
What MS propagates in this context makes very much sense to me: Build
complex bussines logic in a closed LAN, where you can use COM or CORBA and
expose small, stateless functions to the outher world. Of course, I would
prefere to use Python and CORBA and not .NET! ;-)
I hope this was a little bit understandable. If not, please point me to the
unclear parts.
Achim

This doesn't particularly relate to Webware, but I wanted to share the
idea with someone and it applies here...
Anyway, I was reading some article off /. about .NET, and then rereading
some stuff on REST:
http://webservices.devchannel.org/article.pl?sid=03/05/28/0821232http://www.xfront.com/REST-Web-Services.html
And thinking about XMLRPC (I've never actually used SOAP, so articles
like this are all I know so far)... so I'm thinking about objects, and
how they can be represented in a neutral way. Obviously .NET has a lot
to say about this, but let's say we're not going down that path.
Now, you could say that objects were simple structs, maybe somehow
distinguished from XMLRPC <struct>, which usually have a non-object
analog (dictionaries, hash tables, associative arrays, etc). But then
that quickly is revealed to be trivial -- so why not just reuse <struct>
and add attribute access ontop of it. If why not, then why? Anyway,
it's the behavior of these objects that is much more interesting.
Then I thought about the fact that methods can also be considered
messages. Or methods can be considered instance variables, ala Python.
You just need a way of passing back references, maybe like:
<method>
http://whatever.com/path/to/me/dosomething
</method>
The URL is an XMLRPC resource, which can take arguments like any other
resource. It's really just a URL, but if you look at it the right way
maybe it's much more powerful than that.
So, lets say we take struct and extend it. XMLRPC doesn't use
attributes much, but just this once let's do that, and imagine we're
publishing this object:
# published as http://www.parts-depot.com/parts/<id&gt;
class Part:
def __init__(self, id):
# probably get record from some database, etc
self.name = "widget"
self.description = "funny looking widget"
def specification(self):
# fetch from database, return some other complex object
So when we get a part, we get a response like:
<struct type="object">
<member>
<name>id</name>
<value><int>3048</int></value>
<member>
<name>name</name>
<value><string>widget</string></value>
</member>
<member>
<name>description</name>
<value><string>funny looking widget</string></value>
</member>
<member>
<name>specification</name>
<value><method>http://www.parts-depot.com/parts/3048/specification
</method></value>
</member>
</struct>
Hopefully it's easy enough to see how this would be turned into a Python
object. The specification attribute would be an xmlrpclib.ServerProxy
object. "self" is implicit in the URL (/parts/3048), but that might not
be easy to implement with a lot of XMLRPC setups, where the URL points
to a script not an object. Anyway, maybe a notion of self could be
added to <method>. So, say /parts is the XMLRPC handler, and you passed
this before:
<methodCall>
<methodName>getPart</methodName>
<params>
<param><value><int>3048</int></value></param>
</params>
</methodCall>
Then the result for specification might look like:
<method>
<href>http://www.parts-depot.com/parts</href&gt;
<methodName>partSpecification</methodName>
<param><value><int>3048</int></value></param>
</method>
The contents aren't as important, as they would be handled by xmlrpclib
(or the language's equivalent) -- the result is a callable function,
equivalent to a bound method.
In this case, xmlrpclib would add the one <param> to be beginning of the
<params> list, and use the URL and methodName. If the server published
things more nicely via the URL, then some of this information could be
more boring.
So, I'm sure these ideas exist in various RMI schemes, but I like that
this seems to fit XMLRPC pretty well, is language-independent, and
builds on a simple cross-language type system that already is widely
implemented (of course, as long as we add <method> and make this XMLRPC
incompatible, we should add <nil/> for good measure).
I might play around with object publishing in Webware using this... the
implementation seems fairly simple. Anyway, I'm interested in feedback
too, which is why I posted here in the first place ;)
Ian

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details