[Fwd: Re: Zope Solution]
Hi! You're right, as Stephan answered to you we used in this project Zope as a pure 'blind' appserver. the protocol we used there is xmlrpc (www.xmlrpc.com) which has bindings for nearly all languages, among these: python,c++,java on client and serverside. xmlrpclib marshalls function calls and basic types (scalars,dicts,lists,datetimes) as xml statements and uses http as transport. Zope has a built-in xmlrpc server. There are also projects for other protocols (SOAP and CORBA) but I think the latter one is in an experimental state. The point I liked so much about xmlrpc was that is very uncomplicated to implement. As I can read from your explanation it should be well possible to implement that with Zope. Please let me know when you need more information, perhaps you can then provide me more details about your project . regards phil Am Don, 2001-12-06 um 13.59 schrieb Geir Arne Evjen:
I posted this message in Zope's miling list. I got a reply that I should contact you.
Did you have a similar problemsituation?
Greeting from, Geir Arne Evjen
I'd heard about this nice product throught a collegue of mine, and I have some questions in which I hope someone can answer me :-)
Me and someothers are working with thermodynamic modelling and alogorithms. One year ago we saw the need of distribution of our code, which means that we made our thermodynamic calculation engine as a separate module, and other modules could use this one (The thermodynamic core could also access other modules again). All communication between the modules are in CORBA. When we want to send data to the modules, id.e. modellparameters we use XML. Later we created a dynamic GUI language for manipulation of the parameters and other stuff, inserting values into the XML tree and calling the different module functions. Its our glue module. (which is more or less does the same as Zope (Correct me if I'm wrong.).
So to my question: This summer we built a GUI client using java which communicated with our gluemodule. This is a solution we want to have. Is it possible in Zope to accomplish this in some way. (Id.e communication without using a web client)
Best regards, Geir Arne Evjen
I had wondered if such a thing would work. I have some logic that I would like to reuse from my Zope application, and I have been playing with accessing this logic via XML-RPC. So far it has worked fairly well, but I am only in the early development stages. Any useful tips to someone just starting out? Jason Philipp Auersperg <phil@bluedynamics.com> writes:
Hi!
You're right, as Stephan answered to you we used in this project Zope as a pure 'blind' appserver.
the protocol we used there is xmlrpc (www.xmlrpc.com) which has bindings for nearly all languages, among these: python,c++,java on client and serverside. xmlrpclib marshalls function calls and basic types (scalars,dicts,lists,datetimes) as xml statements and uses http as transport.
Zope has a built-in xmlrpc server.
There are also projects for other protocols (SOAP and CORBA) but I think the latter one is in an experimental state.
The point I liked so much about xmlrpc was that is very uncomplicated to implement.
As I can read from your explanation it should be well possible to implement that with Zope.
Please let me know when you need more information, perhaps you can then provide me more details about your project .
regards
phil
As a minimal example for xmlrpc you can use that: - in your zope create in the root folder a PythonScript let's call it 'xmltest' - give it one parameter called 'par' - into the body write: return ['your parameter was:',par] -- start python at the commandline:
import xmlrpclib s=xmlrpclib.Server('http://zwork.bluedynamics.com:50280') # or #whatever your zope is s.xmltest('2')
-- it returns an array containing a string and the parameter that you passed. you can try it out with other parameters (dicts,lists....) I can help you if you need more info, but you have to specify your question more precisely. you can check out the xmlrpc howto on zope.org by Amos Latteier with many useful hints (just search for 'xmlrpc' there). also check out www.xmlrpc.com for detailled zope-independent infos good luck phil Am Don, 2001-12-06 um 23.20 schrieb Jason Earl:
I had wondered if such a thing would work. I have some logic that I would like to reuse from my Zope application, and I have been playing with accessing this logic via XML-RPC. So far it has worked fairly well, but I am only in the early development stages.
Any useful tips to someone just starting out?
Jason
Philipp Auersperg <phil@bluedynamics.com> writes:
Hi!
You're right, as Stephan answered to you we used in this project Zope as a pure 'blind' appserver.
the protocol we used there is xmlrpc (www.xmlrpc.com) which has bindings for nearly all languages, among these: python,c++,java on client and serverside. xmlrpclib marshalls function calls and basic types (scalars,dicts,lists,datetimes) as xml statements and uses http as transport.
Zope has a built-in xmlrpc server.
There are also projects for other protocols (SOAP and CORBA) but I think the latter one is in an experimental state.
The point I liked so much about xmlrpc was that is very uncomplicated to implement.
As I can read from your explanation it should be well possible to implement that with Zope.
Please let me know when you need more information, perhaps you can then provide me more details about your project .
regards
phil
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Hmm... I actually know *how* to use XML-RPC, in fact I think that it is incredibly slick. Currently I am using it to enter email messages into a PostgreSQL database. I already had the logic to do this in Zope, and so it seemed a shame to not reuse it. So far this has worked really well, but I was concerned about how well tested this sort of thing is, and how well it scales. Jason Philipp Auersperg <phil@bluedynamics.com> writes:
As a minimal example for xmlrpc you can use that:
- in your zope create in the root folder a PythonScript let's call it 'xmltest'
- give it one parameter called 'par'
- into the body write:
return ['your parameter was:',par]
-- start python at the commandline:
import xmlrpclib s=xmlrpclib.Server('http://zwork.bluedynamics.com:50280') # or #whatever your zope is s.xmltest('2')
--
it returns an array containing a string and the parameter that you passed. you can try it out with other parameters (dicts,lists....)
I can help you if you need more info, but you have to specify your question more precisely.
you can check out the xmlrpc howto on zope.org by Amos Latteier with many useful hints (just search for 'xmlrpc' there).
also check out www.xmlrpc.com for detailled zope-independent infos
good luck phil
ok, there exist some main differences to things like CORBA or DCOM: 0. XMLRPC is more simple, sort of out-of-the-box you dont need very complicated Object Request Brokers for your client. You just need xmlrpclib.py, a small 20 K beast in your PythonPath, - no install of complicated ORB's on the client-side. with python >= 2.0 xmlrpclib is included 1. XMLRPC itself is (only) late-bound - with CORBA and DCOM you define interface by writing .idl definition files and generate stub classes that you use inside your client. DCOM can be also be used late-bound, I dont know about CORBA in that matter. when your call to te server does not match to ot's interface the error occurs an run-time. This feature is not difficult to live with for Python programmers, at least for me 8-) 2. Since XMLRPC is transported by HTTP it is stateless. when you do this: ob=xmlrpclib.Server('.........') ob.doThis() ob.doThat(bla,blorf) res=ob.getSomeResult() in CORBA/DCOM it creates an object reference that is held on the server-side during the whole transaction and released when 'ob' comes out of scope or is intentionally released by the client side. In XMLRPC the object reference is evaluated for every atomic call to the server (see xmlrpclib.py for better understanding). the xmlrpclib.Server(...) just prepares the URL used by xmlrpclib, it is not a real call to the server !! so in XMLRPC you have to design your Server so that transactions have to happen within a single call to the server. If you know that you can deal with it. 3. Performance. well, for every call xmlpclib has to marshal and unmarhal ( thats the most effort ) your method calls as XML chunks. by default xmlrpclib uses xmllib.XMLParser (slow, but buiilt-in). but you can tune xmllib by using sgmlop (speeds up marshalling to 10-15x) xmlrpc fits perfect for remote calls where you have few calls to functions to the server where each function runs long compared to the transport time. Design your interface so, that transactions can be done within single calls to the server !! If you keep these primciles in mind xmlrpclib can make life easy! phil Am Fre, 2001-12-07 um 19.33 schrieb Jason Earl:
Hmm... I actually know *how* to use XML-RPC, in fact I think that it is incredibly slick. Currently I am using it to enter email messages into a PostgreSQL database. I already had the logic to do this in Zope, and so it seemed a shame to not reuse it.
So far this has worked really well, but I was concerned about how well tested this sort of thing is, and how well it scales.
participants (2)
-
Jason Earl -
Philipp Auersperg