[Zope] Python object lifecycle?

[Tres Seaver]

Robb Shecter <shecter@darmstadt.gmd.de> wrote:

> 
> Jerry Spicklemire wrote:
> 
> > Not to start a "what IS client server?" discussion (I thought we got past
> > that in the last millenium),
> 
> Yes.
> 
> > but it looks to me like Zope IS the middle
> > layer.
> >
> 
> Hmmm... I don't know about that.  I guess it can be...
> 
> >
> > In terms of layers, the browser "front end" handles presentation (client),
> > the "back-end" (data server, host) is an RDB, or CD tower (of image files),
> > or whatever, then the integration layer "middle" is Zope.
> 
> I disagree.  (OK, I admit that this is somewhat silly, because there's really
> many layers here, and what we call them isn't all that important.)
> 
> A browser is a weird thing.  It's not really a full client on it's own, since
> DHTML / Javascript really sort of died.  Now, a Java applet in a browser -is-
> a front-end to me.  But, using just plain html in the browser means that the
> front end must be split between the client and server.
> 
> So, what you get is this:
> 
> { "Pure-HTML" in browser scenario }
> 
> Name: Front End
> Responsibilities: Reacting to user input, rendering information
> Location: Split between a web browser and an HTML/HTTP server. (CGI, Zope,
> Servlet, etc.)

* DTML, which creates the "presentation" of underlying Python objects,
  handles this role.

> 
> Name: Middle Tier
> Responsibilities: Business Logic.  Ie: user authentication, rule enforcement,
> brokering, trading, bus-like behavior.
> Location: On the same or different computer as the HTML/HTTP server.

* ZClasses and Python products fill the "business logic" role

* The Zope framework handles security (authentication and authorization).

* ZCatalog does some of what I think you mean by brokering and trading.

* ZPublisher is an ORB, so it does some brokering and provides the "bus"
  (again, if I understand you).

> 
> Name: Backend / Datastore

ZODB and ZSQL handle this (along with the various Storage implementations
underlying ZODB).

> .....
> 
> So, the issue here seems to be that Zope absolutely does the Front-End stuff.
> (Plain old content management, style-like HTML rendering, etc.)  But, the real
> questions are does / should / can Zope do the middle tier stuff?
> 
> Usually it's nice middle tier is a long running process.  It can be programmed
> in an OO style, and in a *stateful* manner.

It is generally *essential* in any system big enough to yield ROI for n-tier.

> 
> It looks like Zope's answer here is to write Python classes that get used as
> external methods.  What's not clear to me is how these Python objects live and
  ^^^^^^^^^^^^^^^^^ -- see above:  most will be in Python products or ZClasses.
> die, and when.

* Some objects are "persistent," that is, their lifetime extends beyond the
  boundary of the transaction which creates them.  These are normally stored
  in the ZODB, which handles the incarnation/etherialization of them trans-
  parently, based on demand.  Any object which can be manipulated through the
  managemement interface falls under this heading.

* Other objects are "transient," created to handle a given request;  they die
  when the request terminates.  E.g.:

  - Results objects created from a ZSQL method (the "brains" object)

  - The REQUEST and RESPONSE objects themselves.

In conclusion, I would say that, by your crieria, Zope partakes of all three
layers;  by Jerry's, Zope is the middle tier (I would guess that Jerry would
call ZODB's storage back-end, though).

-- 
=========================================================
Tres Seaver         tseaver@palladion.com    713-523-6582
Palladion Software  http://www.palladion.com