Summary

The Zope Enterprise Option (ZEO) brings a distributed object architecture to Zope sites demanding high-performance and scalability.

Features

Scalability. The ZEO architecture allows a site to increase capacity by adding computing resources to handle the load.

High Availability. Since ZEO permits multiple processes in a site, programs that have problems are skipped and can be terminated. Also, the storage of the data is isolated from the application processes, significantly increasing the data integrity of the website.

Distribution. The website can be dynamically distributed to multiple locations in multiple configurations.

Description

Zope is an Open Source application server used for building high-performance, dynamic web sites. The free software contains a high-performance server, powerful object database, and rich framework as its platform.

The Zope Object Database (ZODB) architecture allows the actual object database to be stored in multiple ways. This layer of ZODB is called the Storage. Several Storage options are available as complete or demonstration implementations, including the default filesystem storage, relational database storage, an in-memory storage, a compressed storage, and a Berkeley DB storage.

However, Zope2 only allows one process to write to a particular storage. Other processes can open a read-only, non-updated version of the object data in the storage, but cannot make changes and will not see updates. While it is feasible for developers to provide approaches that mitigate this, Zope now has an offering for sites needing an integrated, powerful option for high-end applications, with minimal administration required.

The Zope Enterprise Option (ZEO) allows multiple processes, machines, and locations to work together as one transactional object system.

ZEO works by introducing a new kind of Storage called a Client Storage (CS). This kind of Storage behaves just like a regular Storage, except its gets and puts its data to a remote Zope Storage Server (ZSS).

Other than the CS, the Zope site is exactly the same. There is an in-memory cache that is standard with Zope. However, the CS also keeps an on-disk cache, making the majority of requests serviceable by local objects. The Zope site can also have regular local Storages as well.

The Zope Storage Server itself manages connections and stores data. Since it isn't a Zope application, it is isolated from incidental application errors. Additionally, the data can be stored, like regular Zope Storages, in local files, relational databases, custom storages, or other kinds of storage.

With the ZEO architecture, sites can introduce multiple Zope application servers on multiple machines in multiple locations, all participating as one consistent object system.

When a Zope site gets a web request and needs an object, it first looks for it in the cache. If the local Zope doesn?t have it, the object is retrieved from the Zope Storage Server. If the object is changed during the request, the change is sent to the ZSS. Because other Zope processes might have the old version of the object in their cache, an invalidation message is sent to all the other Zope processes, which removes the object from each cache.

Like Zope, ZEO is designed for the web model of many reads and few writes. Thus, applications in which the bulk of the web requests will make no changes are good choices for ZEO.

To support distribution to externally controlled Zope sites, the ZSS can restrict connections (1) by address, (2) require a security key, and/or (3) permit read-only access. These features make ZEO a good fit for the classic ?Internet mirror?.

In order to make multiple processes in multiple locations appear to be a single website, some mechanism for routing requests to a Zope process is needed. This routing can be simple, such as round-robin DNS or FastCGI. More importantly, though, many customers desire integration with market leading products such as Cisco LocalDirector.

The pieces of ZEO discussed so far address scalability. For complete reliability, though, the data in the ZSS must be redundant. That is, the single point of failure cannot be simply shifted from the Zope process to the ZSS. The second level of the ZEO architecture eliminates the ZSS as the failure point by mirroring the object data between storage servers and allowing failover of one ZSS process to another. Scaling the Zope Storage Server will be the second phase of the ZEO work.

ZEO also introduces options for the design and deployment of web applications. For instance, each Zope process can run on a different operating system, with some containing different versions of the software. If a site wished to restrict their public sites from the ability to perform management operations, those processes could have the software modified to delete that capability. Also, spreading the object system along multiple lines of storage can present options for how object data are mirrored and distributed.

In summary, the ZEO architecture provides the power, flexibility and intelligence needed for the most demanding web applications.