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