[Zope-dev] Using Zope in a client-server system
Tres Seaver
tseaver@palladion.com
Sun, 05 Mar 2000 13:42:07 -0600
Itai Tavor wrote:
>
> Tres Seaver wrote:
> >
> > By default, browsers aren't servers: they don't know from
> > bind()/listen()/accept(), which is what push technology requires (unless
> > you have a long-running, bi-directional connection between browser and
> > server, which HTTP doesn't allow). Polling is the only "native" technique
> > for refresh, and suffers from _horrible_ scalability problems.
> >
> > Options in order of simplicity:
> >
> > 1. Pull instead of push (ick!)
>
> My sentiments exactly.
>
> > 2. As Hung Jung suggests, build the "push model" stuff separately from the
> > browser, using Python or Java to implement HTTP (and perhaps XML-RPC?)
> > Integration with the browser is difficult: clients will have to have
> > some mechanism for registering their mini-server with your server;
> > if you want the broser's display to update when the push event comes
> > in,you may be stuck.
>
> Right. Mixing two GUI's - a browser for most of the interface and a
> separate app for pushed data - would be real ugly. So I either have
> to work inside the browser, as in option 3 below, or code my own GUI.
>
> Registering the mini-servers would not be a problem. This project
> will be running on a small number of workstations, all located in one
> location. It's not designed for public or wide-area use and won't
> even be connected to the internet.
If you control the deployment platform, and the pipe between client and server,
then some of my tradeoffs don't apply, as you note: trusted applets are
reasonable, for instance, and polling is not nearly as terrible a strategy over
a fast network with a small number of clients.
>
> So, the problem with this solution is how to get the pushed data into the GUI.
>
> > 3. Code a lightweight socket server applet in Java, persuade everyone in
> > the world to trust you to run it in their "applet sandbox", and then
> > "register" it with your server.
>
> Again, because of the physical layout of the project, trust won't be
> an issue, which makes this solution rather attractive.
>
> > 4. Write a CORBA callback object in Java, and register it with your
> > server; the server then pushes events to your object (scalability
> > is again an issue, as the server blocks for each client being pushed).
> > Note that adding CORBA into Zope is a non-trivial exercise, for the
> > moment at least; see my
> > "notes":http://www.zope.org/Members/tseaver/CosNaming on the issues.
>
> I read your notes, and I think I'd like to stay away from COBRA - I'd
> use it if I decided to go totally overboard and code both the server
> and client in Java. But with Zope on the server end, XML-RPC seems
> like the best way to communicate.
CORBA is probably overkill, in your case; the reason I introduced it into the
discussion is to lead to #5, which gives you scalable event delivery in a
heterogenous, wide-area environment.
>
> > 5. Write a CORBA event-channel applet (CosEventPushConsumer) in Java, set
> > up a CosEvent/CosNotification channel, subscribe the applet to it, and
> > push events to the channel from your server (decouples your server from
> > event-delivery hassles/blockage, scales MUCH better than direct
> > callbacks).
>
> Scalability is not much of a problem for me. I wouldn't like the
> server to block too much but that shouldn't be much of a problem
> either - with 10 clients on a 100baseT network, and 4 Zope threads on
> a fast server, I can't imagine running into any performance problems.
> But I do want to keep the number of technologies and separate apps
> involved to a minimum, and this seems fairly complicated.
>
> Out of the various options suggested it seems to me that the main
> options to consider are:
>
> - Use a browser for the main GUI, and either compromise the
> requirements to eliminate the need for push or code an applet to
> display push data in the browser.
>
> - Write my own GUI.
>
> The second option raises some new questions:
>
> - Would it still be a good idea to use Zope for the server, or should
> I code the server as well (a full Java solution comes to mind using
> COBRA for two-way communication). How would I handle push in Zope?
> Assuming I code a push client that speaks XML-RPC, how do I get Zope
> to send data outside the context of an http transaction? Actually,
> this same question is relevant for the solution of using a Java
> applet within the browser.
You might look at Loren Stafford's recently-announced ZScheduler product: Loren
is working on a way to have "internally-generated" events fire inside Zope.
>
> - Two good candidates for writing the GUI in are Java and wxPython.
> Using wxPython would have the advantage of keeping everything in
> Python. On the other hand, there's an XML-RPC server for Java, but
> not for Python - I guess I would use HTTP if I use wxPython. Can
> anyone suggest pros/cons for these solutions?
I think I missed something here: Python *does* have an XML-RPC server
implementation (xmlrpclib.py), which is how Zope can do XML-RPC.
>
> I have one other question related to the use of Zope in this project:
> The server has to monitor a serial line and respond to received data
> by pushing messages to the clients. What would be the best way to
> achieve this? An external python process reading the serial line and
> calling ZPublisher.Client to triger a DTML method that will do the
> rest of the work?
Right, but ot necessarily a DTML Method. The ZClient request might, for
example, trigger a method of a Python product instance, which could enqueue the
event for processing by a notification thread, for instance.
> P.S. I know this is getting way off topic for the Zope group. I
> really appreciate all of you contributing your experience.
I don't think this is off-topic at all -- we are pushing the *normal* Zope
envelope a bit, but I think Zope is up to the challenge.
Tres.
--
=========================================================
Tres Seaver tseaver@palladion.com 713-523-6582
Palladion Software http://www.palladion.com