[Zope-dev] Using Zope in a client-server system

[Tres Seaver]

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