[ Site Index] [ Linux Index] [ Feedback ]
The Zope Application Server
Back in 1989, when Tim Berners-Lee was inventing the world wide web at CERN, his overriding goal was to make information stored on different computer architectures universally accessible. CERN had a plethora of different types of computer (ranging from PC's and Macintoshes through a variety of workstations running different flavours of UNIX and exotica like DomainOS, through to mainframes). The original web idea was to pick a simple text file format, and build tools -- web server software -- that would serve these documents up to a client connected to CERN's TCP/IP network.
This idea had certain implications which we're still getting over. One was the idea that what you serve over the web is a file that exists somewhere on your server's filesystem. Another implication arising from the idea of serving files -- and more important in the long run -- was that the data was going to be static.
Static data was the first big stumbling block to go: HTML was extended to encompass form elements (like checkboxes), and clumsly tools such as CGI, the Common Gateway Interface, were added to enable the web servers to talk to external programs that could take form inputs, do something (like a database lookup) and return HTML output for the user.
However, we were left with the file-oriented view of data that lives on a web server. One document need look nothing like another: it took active effort to enforce a common look and feel on a web site. A host of macro processors were written to make it easier to embed common elements in HTML files, but these tended to beg the question -- replacing manual procedures with programming work.
By the late nineties a new class of software was appearing to fill the gap: the web application server (such as Allaire Cold Fusion). The web application server is basically a piece of software that generates HTML (or XML) pages as output. Internally, it uses a richer information format -- typically an HTML-like language with additional tags that provide programming language features, access to databases and external services, and so on. It may be built around a database, and it almost certainly provides sophisticated access control systems to keep track of changes to the system. Web application frameworks make it possible to build a coherent look and feel for a website and integrate dynamic content (things which are generated by programs) with static content (plain ordinary files).
There's a level above the web application framework: the content management system (such as Vignette StoryServer). A CMS isn't just a toolkit for making it easy to integrate dynamic and static content and maintain links in a website: CMS's also provide tools to help organise workflow -- so that an online magazine or a dot-com can standardize the addition of new content to their website. This entails allowing each content producer to create pages and feed them to the publishing system: the system should then automatically ensures that pages get placed correctly, that navigation trees are created and maintained, and that editors and managers can control the process. This becomes critically important if the web site has more than a handful of developers working on it -- for example, a newspaper or wire service.
Although roughly 60% of the world's web servers run on Apache, and Linux is the most popular server platform, there's a relative dearth of web application frameworks and content management systems for Linux. Which makes Zope, the Zope Object Publishing Environment, noteworthy: it's the leading open source web application framework, and also supports a content management system, the Zope CMS.
How it's installed
Zope installation is fairly straightforward: go to Zope.org and download a copy for your platform. A number of binaries are available (including Windows NT, Linux, and Solaris), along with the source code. If you want to install from source, unpack the tgz archive somewhere like /opt/zope:
cd /opt tar xzf /tmp/Zope-2.3.1.tgz mv Zope-2.3.1-src zope cd zope python w_pcgi.py ./startThis builds a standalone Zope server that binds to port 8080 of your local machine; the commands "start" and "stop" in /opt/zope are used to start and stop the server.Note that the script w_pcgi.py will spit out a default administrator username and password (unique to your machine) when it finishes. Make a note of it! If you don't, you won't be able to log in and configure the system.
(All this presupposes that you have Python 1.5.2 installed on your system. If you haven't, you need to install it first! Zope is largely implemented in Python and won't run without it. However, Python is shipped as standard with almost all Linux distributions these days, so you probably need to make a special effort to get this part wrong.) When you've executed the "start" script for the first time, you need to log into the management system. Point your frames-capable web browser (Netscape 4.76 is fine) at http://localhost:8080/manage, and log in using the username and password w_pcgi.py gave you.
If you have problems running "start" (notably if you get an error message about permission denied when creating a file ending in .pid), you may need to check the permissions on the var/ subdirectory of your Zope installation. There are more detailed installation instructions in the doc/INSTALL.txt file in Zope's directory.
Zope basics
Zope has a number of components, but the core of it is the Zope server and Zope object database. Zope server is essentially a web server (and FTP server); the difference between Zope and Apache is that Zope doesn't serve files -- it serves objects. An object is a chunk of data and code stored in the Zope object database: it can have various properties and attached child objects, it emits HTML when you prod it, and it is persistent -- it hangs around in the database until someone or something deletes it.
The general idea is that you load all your web pages, scripts, images, and assorted data into the Zope object database, which is easier to organise and maintain consistency across than a filesystem. (There's also an interface to external relational databases, and you can do stuff functionally equivalent to CGI scripting, but we'll get to those later.) A straight Zope install sets up the Zope HTTP server on TCP port 8080; if you install it on your local machine, you can see what's on the server by pointing your web browser at: http://localhost:8080/ .
You interact with Zope in two ways: by browing "files" on the server (actually, the URLs you can click on are methods that invoke objects in the object database), or via the management interface: you get to it by pointing your web browser at: http://localhost:8080/manage (assuming Zope is on your local workstation). The management interface gives you a two-pane view of the contents of the object database (like the Windows explorer); on the left is a view of the folders open at your current level in the database, and on the right is a tabbed view of whatever you are currently editing. The different tabs give a variety of options for editing or viewing the currently selected object, including its access permissions, associated attributes, and change history -- Zope has built-in version control, with the ability to roll back changes to an object and to identify possible conflicts between revisions made by different users.
Terminology alert: in Zope, a "method" is not the same as a method in most other object oriented programming environments. Zope methods are actually scripts or templates -- chunks of code which are executed to emit HTML code that is served up to the user's web browser, as opposed to objects that are static content (such as images or HTML). So a "DTML method" is a chunk of DTML that is executed by Zope, rather than a "DTML file" which is notionally a chunk of text that gets served up to the client. (This terminology is not particularly helpful, but the term "method" in Zope is probably best thought of as a synonym for "script".)
IMAGE: Zope-init.jpeg
Zope, like a disk filesystem, stores data in folders; however, unlike a filesystem, the stuff that it stores need not consist of files or other folders -- Zope folders can store objects such as SQL queries, Python scripts, or vocabularies (lists of unique words indexed by catalogs -- searchable folders.
In a new Zope installation, the left hand pane will initially show you the folders of your Root folder -- this contains three sub-folders: Control_Panel, Quickstart, and acl_users. The Control_Panel folder contains tools for managing Zope products (chunks of code and data installed on the Zope server), the Quickstart is a basic tutorial, and acl_users is a special folder containing Zope user information. Probably the first thing you should do on running Zope is to set up a new User ID to work with -- the manager ID you were given when Zope was compiled is equivalent to root on Linux, and it is easy to accidentally damage your system using it. Items in Zope's database have owners, and you can assign various permissions to users on a per-user basis (for example, permission to delete or modify objects, change ownership and management attributes, and so on).
Suppose we want to create a very basic website within Zope: our first task (when logged in as the user who's going to maintain the site) is to click on the "Root folder" icon on the left pane. This brings up a view of the contents of the Root Folder. Our new website is going to reside in a new folder: so, on the "Contents" tab in the right-hand pane, we pull down the "Select type to add ..." menu, choose "Folder", and press the "Add" button.
This will bring up a dialog box that asks for a title (which will be seen by the users as the HTML title of the folder) and an Id, which we can use in other Zope objects to refer to the folder by name. (There's also a checkbox to create a default HTML representation -- equivalent to creating a directory with an "index.html" file on a conventional web server's filesystem).
IMAGE: Zope-add-folder.jpeg
Once we've created the new folder, we can enter it (click on it in the left-hand pane) and select "DTML Document" from the "Select type to add ..." pulldown. Again, we're prompted for an object Id and a title. We also have the option of selecting a file from the local filesystem (on your workstation -- remember, Zope is designed for remote administration) and uploading it. If we don't select a file, but hit the "Add and edit" button, we are given a form in which we can edit the document source. Zope gives us a standard default document like this:
-- CODE LISTING --
<dtml-var standard_html_header> <h2><dtml-var title_or_id></h2> <p> This is the <dtml-var id> Document. </p> <dtml-var standard_html_footer>
-- END OF CODE LISTING --
DTML, Document Template Markup Language, is what Zope uses in place of HTML. When you view a Zope object, Zope processes the DTML template and generates HTML which is served up to your browser. DTML is broadly compatible with HTML, except that any tags beginning with <dtml- introduce a DTML construct; for example, <dtml-var some_variable_name> means that the Zope variable called "some_variable_name" is to be inserted into the HTML at this point when the page is served. If you look in the Root folder of your Zope installation you'll see some objects called standard_html_header and standard_html_footer; the new Zope DTML object you are in the process of creating has inherited these other objects.
This brings up one of the most important points about Zope: it is object-oriented. Folders are objects that are instances of a container class; they hold other objects. Objects within a folder inherit things from the enclosing folder, such as its security permissions, ownership attributes, and "Properties" -- simple variables such as strings or integers that the containing object has been tagged with. By ensuring that a folder is owned by one particular user, you ensure that its contents also belong to that user (unless you specifically override the ownership attribute somewhere down the tree).
If you tag a folder with some attributes, or create DTML objects or other objects within it, those entities can be invoked by other objects buried in folders below the staring point. However, the inheritance tree doesn't work in the other direction: items in a folder can't see the properties of an object hidden in a sub-folder.
Like a web server with a filesystem, Zope URLs contain folder names separate by slashes: but if you ask for, say, http://localhost:8080/top_level/my_subdir/fredObject, and there's no fredObject in my_subdir, Zope will backtrack up the hierarchy until it finds a fredObject object it can serve. So if fredObject is defined in both the top_level folder and in my_subdir, Zope will serve the first one it comes to (from my_subdir).
Because of the hierarchic nature of most web sites, this model fits well: you can define some simple header and footer documents in your top level folder, source them into every file in child folders, and maybe override them (adding a navigation toolbar) in folders lower down in the site's tree of files.
From a programmer's point of view, Zope is simply an object-oriented programming environment built out of Python and DTML; objects persist between HTTP requests. In effect Zope treats HTTP requests as method calls and the called Zope objects return their output in the form of HTML which can be sent to the client.
Touring Zope
Zope is a big, gnarly system (albeit consistent and elegant). In addition to its core concept of object-orientation and the two-pane tabbed user interface, there are a lot of things to get to grips with. DTML provides some basic programming constructs, including flow of control operators and iterators (so that you can wrap a SQL query that returns a single row inside an iterator that repeatedly generates lines of HTML while the SQL query continues to return data).
In addition to DTML, there's Python. Python is an extensible object- oriented programming language that has been growing in popularity over the past few years. Python is broadly comparable in power to Perl, but provides a cleaner model for object-oriented programming and more regular syntax: Zope is built around a Python interpreter, and just as DTML objects are used to generate HTML, Zope can execute Python scripts for the same purpose. Python scripts in Zope can be called from DTML documents via the dtml-call tag (which cases a Python script to be triggered). Python scripts can also be called directly, and passed the path (in Zope's namespace) to some object or attribute you want to specify as a parameter. If your HTTP request sends some data, the named parameters in the request are passed to the python script as parameters. For example, if you have a DTML object that contains this HTML form:
<form action="DoSomething"> Name <input type="text" name="name"><br> Age <input type="text" name="age"><br> <input type="submit"> </form>You can process it by simply writing a Python script called "DoSomething" that expects parameters called "name" and "age" in its calling context. For example:
"Process form" return "My name is " + name + " and my age is " + ageThe whole CGI API is absent, and there's no need to mess around unpacking variables: Zope takes care of ensuring that the form parameters are bound to the Python script's calling context and are therefore visible inside the script. As long as the script DoSomething is defined at or above the same level as the DTML object that invokes it, Zope will handle everything else.
Note that Zope's Python interpreter is sandboxed to prevent you doing certain harmful things. You can't use it to get at the contents of private folders, and it will spot (and refuse to execute) many infinite loops; it is also limited by Zope's standard access permissions, so that you can't overwrite data that doesn't belong to you. However, if you explicitly choose to do so it is possible to create and use external methods -- chunks of Python code that run from the parent filesystem within which the Zope server is installed. These aren't sandboxed, and can therefore be used for a variety of low-level tasks.
While you can create your own object types using Python (or Perl -- you can embed Perl scripts in Zope), Zope comes with some pre-canned complex object types. One is the tutorial: go to your test folder, select "Zope Tutorial" from the "Type to add ..." pulldown, and Zope will install a lengthy scripted tutorial for you to work through. This demonstrates a number of the features of Zope as it walks you through creating a website dedicated to tracking Elvis sightings.
IMAGE: zope-tutorial.jpeg
Other complex objects bear examination. There's a virtual host monster object: this is used, in conjunction with Apache, to change the URL paths below a designated folder so that requests for (for example) www.mydemosite.com can be mapped to a subfolder of your Zope server. There's also a cache manager object. This allows you to specify that objects below it will be cached rather than re-executed every time a request for them comes in: the caching can be carried out internally, or externally using a tool such as a Squid proxy server. The ZCatalog object creates a searchable repository and lets you specify mechanisms for searching and presenting the data within it. ZCatalogs can be used for free text searching, for keyword and metadata searching (where the search keys are attributes of the Zope objects in the collection), and for searching the output from SQL query objects.
Perhaps most importantly of all, Zope can act as an object request broker (ORB) for handling apropriately formatted remote object calls over the net. Zope scripts that can be accessed via URLs can be also called via XML-RPC. XML-RPC is a new standard for executing remote procedure calls over HTTP: it's at the core of SOAP (simple object access protocol), the transport layer used by Microsoft's .NET application server environment. XML-RPC lets you marshal objects and pass them to scripts via the web, and handles the responses: because there are XML-RPC libraries for Tcl, Perl, Java, Python and other languages, you can use XML-RPC to make objects hosted on a Zope server accessible to other applications.
Zope database interface
Zope
Applications
Zope is extensible -- it's written in Python, and products (packages of Zope objects) can be installed on a Zope server to add to its set of base classes. A ZClass defines a new clas of Zope object; you can create new ZClasses within Zope, then add methods (chunks of executable code that return HTML) to implement it. Creation of ZClasses is straightforward but involves some thought: you need to determine the permissions required by the new class and available to its users, the properties (named primitive data structures) associated with instances of the class, and the public interface to the class.
In addition to writing your own ZClasses, you can install packages on an existing Zope server. The usual way of doing this is to unpack them in a subdirectory of lib/python/Products, then re-start the server: Zope packages supply pre-canned ZClasses. There're a number of them available via the web: for example Squishdot a clone of the Slashdot community website system is supplied as a ZClass. More packages can be found by way of dev.zope.org (the Zope developer's website), and Zope's download pages.
One of the more interesting of these packages is ZEO, Zope Enterprise Objects. Normally, the ZODB (Z Object Database) can only be accessed by one process at a time. ZEO extends ZODB, allowing it to talk to multiple processes on multiple machines at the same time. ZEO defines a new storage architecture for ZODB that acts as a cache between the Zope server and a remote database: thus, the core Zope database can be replicated by a number of client systems. A current problem with ZEO is that it still relies on a single master Zope Storage Server: while this allows replication for load-balancing purposes, it introduces a single point of failure. Work is in progress on ZEO 2.0, which will have a true distributed database model and allow fail-over from one Zope Storage Server process to another.
Other downloadable Zope packages include multi-user event calendars, LDAP user account management tools, adapters for a number of relational databases including MySQL, Informix and Oracle, Unicode support, basic e-commerce systems, clients for O'Reilly and Associate's Meerkat wire service, extensions to allow embedding MS Word documents in a Zope database (and automatically view them as HTML), maintain Yahoo-style hierarchical directories, and many more. To the extent that it's possible to gauge the health of an open source project by the amount of add-ons written for it, Zope is hot: most of the common web applications are available as easily-installable packages, and there is an active developer community.
Perhaps the biggest package for Zope released recently is the Zope Content Management Framework (from http://cmf.zope.org/). The CMF is a collection of Zope components designed to make it easy to build a community website system, with standardized design, workflow control, and so on. The goal of the Zope CMF is to make it possible to build publishing sites. User accounts can be assigned to members or contributors: the latter get extra privileges for writing articles and managing the news. Members, with more restricted privileges, can post to discussions and customize their view of the site. Additional tools such as ParserHandlers are used to convert postings into formatted content that integrates with the look and feel of the site (which itself is skinnable). The Zope CMF is still fairly new and less well documented than is desirable: however it demonstrates the direction that Digital Creations , who developed Zope, are pushing in. One of the future requirements for such sites is session tracking, so that a portal can keep track of users who are logged in, even anonymously: this is on the cards for a future Zope release. Digital creations are in the business of giving Zope away, and earning money by selling customized add-ons: this suggests that some really large-scale Zope roll-outs are due in the not too distant future.
As a final note: although Zope is open source, commercial support is available from its creators. It's painfully expensive (prices start from US $9995 for one year's support), but comprehensive -- the Gold Support option (a snip at £34,995!) includes staff pre-assigned to the customer's site (and presumably pre-familiarised with it), and the Platinum package (price -- if you need to ask, you can't afford it) appears aimed at corporate customers who need 24x7 hot and cold running engineers. These options aren't for home users or small businesses: they're aimed at large corporations who have bet the business on Zope and need specialist expertise on tap. Digital Creations also provide on-site training -- but again, this isn't exactly priced at the lowest common denominator.
So, to sum it up: is Zope for you?
If all you want to do is to serve up a couple of pages of HTML, the answer is "probably not". Again: if your content doesn't change very often, Zope may be overkill.
On the other hand, if you have to maintain a large corpus of documentation, or run a rapidly-changing commercial website with an overall look and feel and many people contributing changes and content to it, Zope and the CMF will help you manage the whole process, taking a lot of the pain out of the process (pain which is aggravated by the tendency of plain old-fashioned HTML-based websites to fall apart, suffering from broken links and inconsistent style, as they're extended).
Zope really excels at tasks which require the integration of static content (such as HTML pages) with dynamic content (such as database lookups, discussion groups, or CGI scripts). Its approach to writing dynamic scripts is simple, elegant, and takes most of the arcana out of the task: and the choice of Python as a primary language has proven to be inspired. Zope is one of those applications that leave you wondering how you ever managed before it was invented: why not try it today?
[ Site Index] [ Linux Index] [ Feedback ]