This document provides answers to frequently asked questions about Zope Enterprise Objects (ZEO).

In a nutshell, what is ZEO?

The Zope application server is a transactional object system, where an in-memory cache of objects can be interacted with in many ways. ZEO turns Zope into a distributed transactional object system.

With ZEO, many Zopes are connected to a Zope Storage Server (ZSS). When one Zope changes an object, the changes are sent to the ZSS, which sends a message to the other Zopes. The other Zopes then remove the object from their cache. If the object is needed on a subsequent request, the Zopes fetch the object from the ZSS.

Why the change from commercial status?

First, we realized that scalability was part of the platform and not a vertical application. Since the Zope platform will always be Open Source, it made sense to put scalability into the Open Source part.

Second, we realized that the strength of an Open Source pitch (having control over your critical platform decisions) applies even more to scalability. The classic Open Source benefit of "many eyeballs make all bugs shallow" also applies.

From a business perspective, we also came to the conclusion that we'd make more money in the long run by growing the platform by putting the scalability there. Essentially, having a seamlessly scalable platform story will lead to larger deal sizes for our consulting business.

Will this be going into Zope?

Ultimately yes. ZEO not only adds scalability but it can bring new approaches to collaborative development. We will keep ZEO on a separate development track, then merge it into a future version of Zope.

How is this different from other solutions?

In Zope, all three pieces of a three-tier architecture (presentation, logic, and data) can be managed in one object-based facility. This is very unique, as nearly all other architectures put templates and logic on the filesystem and data in an RDBMS. Note that this increases the need for Zope to handle ZClasses and Python Methods as first class citizens.

Thus, ZEO allows all three tiers to be scaled and distributed in one facility. If you make a change to your logic, the change is distributed automatically to all sites on all networks.

This is the beginning of the road for us to treat all three tiers as managed content.

Simplicity is a second major benefit. ZEO is shockingly lightweight. Other facilities, certainly on Linux, require people to know an enormous amount about system administration.

Doesn't this just move the point of failure somewhere else?

Yes, the Zope Storage Server then becomes a single point of failure. The next stage of ZEO will be to replicate the ZSS piece.

However, since the role of the ZSS is so limited, the chance that it can fail are vastly diminished. Namely, the ZSS doesn't run any Zope applications, it just serves object data. If there is an application that gets hung or crashes, this won't affect the ZSS from functioning. Most of the classic bugs and problems for application servers will be eliminated.

Does ZEO provide everything?

No, ZEO relies on one other piece to function. Namely, ZEO does not provide a facility for routing web requests to the appropriate server. Instead, ZEO relies on external facilities for this, such as Cisco LocalDirector, round robin DNS, round-robin FastCGI, or the dynamic facilities in FastEngine's FastServe.

Beyond scalability, how can ZEO be used?

As alluded to above, ZEO is more than just scalability, reliability, and availability.

For instance, with ZEO you can run different versions of the application server on different machines or ports. You might have a public version that has all the management facilities actually removed from the code to prevent login. Alternatively you could bring up a test version that was running new code, ensure that it works, then roll the changes in process by process.

ZEO will also significantly improve group development. Individual developers can get different process that they shut down and restart without impacting the other members of the team, yet they can still collaborate on the shared three tiers.

When is ZEO not appropriate?

Like Zope, ZEO is modeled after the classic Web pattern of many reads and few writes. Moreso than Zope, ZEO pays a penalty when the ratio of reads to writes starts to get close.