Who this document is for

If you're familiar with, or have ever used, the Java 2 J2EE technologies for creating web sites, this document is meant to introduce you to Zope.

J2EE for web development includes technologies like Enterprise Java Beans, Java Server Pages (JSPs), Java Naming and Directory Interface, et al. Combined they provide a system that looks more like Zope than anything else out there. But don't let that statement mislead you. Nothing is quite like Zope, and it will probably take a little bit of mind bending to get into the Zope frame of mind.

How does J2EE work?

The core of web development with Java is the Enterprise Java Bean. EJBs are Java components that comform to a specific interface so that they are run-time discoverable and manageable by an EJB server. In typical object-oriented fashion, EJBs contain both data and logic, both for peristent, session, and stateless uses.

The EJB can have its container (the server) provide it with persistence, or it can implement it itself. They are discovered most usually with the Java Naming and Directory Interface (JNDI), although there is an SQL-like query language emerging.

EJBs come in Session and Entity types. Session beans are persistent only across a user's session, so when they leave, or the server restarts, the information is lost. Session beans can be stateless, so the bean contains only logic, or they can have state to store data about the user's session. Entity beans are fully persistent, and should survive forever unless otherwise specified. Entity bean persistence can be managed automatically by the container or manually by the bean, and usually involves an external relational database, although the mechanism is not specified.

A system written with EJBs can be accessed by a number of means, including Java RMI and CORBA. Often, they are also made available through HTTP. The contents of EJBs are usually published to the web by Java Servlets or JSPs (which are actually the same thing) which grab the contents of an EJB or more, perhaps do some operations on the data, and write HTML which is then served by a web server. JSP, which is an HTML-embedded scripting language dynamically compiled into a Servlet, can be used as a templating mechanism or, like other HTML-embedded languages, to encode logic.

As you can imagine, the J2EE approach is very flexible and potentially very powerful, but also very programming intensive. While it does more for you than most similar development platforms, it involves a lot of overhead and is unsuited for smaller applications, especially when software and hardware costs are considered.

Similarities

There are several points of similarity between the J2EE approach and the Zope approach which should make the transition from J2EE to Zope easier.

Objects

EJB has beans and Zope has objects, but in spite of being called different things, they're farily similar.

Objects, as we'll call beans and Zope objects, contain data and behaviour that can act on itself, other objects, or the system. They are instances of a known class, and understood to be of the same type with the same interface when created the same way. In Zope the specification of objects is in Products, wheras in EJBs it's in the bean's class. Zope products are Python, and EJB classes are compiled Java bytecode, but it's very much the same concept.

Objects are also able to inherit the capabilities of other objects, and be recognized as having the same interface as their base objects.

Objects are the fundamental units of both systems, and the function and usually data of the entire application is contained in the objects is uses and contains. At a high level, the of J2EE and Zope are similar, but don't take the association too far. We'll see later that there are a number of important differences.

Products

Objects are defined in Zope by Products, which are usually Python code on the filesystem that implements a certain interface so that Zope can understand what they are and to be able to interact with them. Products are easily installed from third parties and immediately give you new capabilities. The actual objects created by Products are in fact Python objects just as you might see them in a regular Python program, except they have extra handles so that Zope can use them.

EJBs are very much the same: Java classes that follow a certain pattern so that they are recognized as EJBs. Adding new classes to your classpath gives you the ability to make and use new beans, and the runtime representation of them is a Java object.

Persistence

EJB containers provide the ability for Entity beans to have transparent persistence, so that the bean can be made as an object and then assumed to live in the server forever, even through restarts. Zope objects, if they inherit a persistent object class, are also given transparent persistence. However, Zope objects are put into an object database that provides a number of automatic relationships between documents that can be exploited by developers. EJBs are simply made to persist.

Neither Zope nor the EJB specification care how the data is stored.

Cross-platform

Both Zope and J2EE make a big deal out of being cross-platform, and for good reason. The ability to be nimble with regard to both hardware and software is important to long-term success, and in the short-term gives a lot of flexibility to chose the platform you know or best fits.

Python and Java, the foundation languages of Zope and J2EE, run (almost) unmodified on a wide variety of platforms. And though Java has more hype about it, Python (and thus Zope) is probably more portable than Java. It runs on all major server platforms, and a number of others besides. There is actually a version of Python that runs on Java and soon there will be a Zope that runs on Java as well.

Zope has some parts written in C for speed, so it's not entirely binary portable across platforms, but most of it is and with open source binary transfer isn't such a big deal.

Differences

There are a number of significant semantic and implementational details that differ between Zope and J2EE. Naturally, of course, since neither pretends to be the other one. A big one is that Zope is Python and J2EE is Java, some of the implications of which we'll get into later.

Object Relationships and Lookup

Beans don't really have any positional relationships. They exist mostly in the void unless you add relationships to them. Think of it as a big bucket of beans: you can't tell anything about it or the beans around it based on where it is in the bucket.

Zope observes (and requires) a set of structured relationships between data. Everything in a Zope application lives in a tree-like object database. You can tell a lot of things based on position: how the object is called, what attributes and behaviours it has, what its parents are, what it can and cannot access, et al.

One of these relationships, and a very powerful one, is acquisition. The elevator story behind acquisition is that objects acquire the properties and behaviour of their parents. Often this means simple data types (those you see in the ZMI Properties tab.) In the case of folderish objects, which have other objects among their properties, subobjects also acquire other objects. This is why you can get away with not having and index_html in every folder and still having one in every folder.

The neat thing about acquitision (and the other relationships Zope provides) is that it is automatic. This makes reuse of services very easy.

Publishing

JSPs and Servlets (since they're basically the same thing) have a very straightforward publishing scheme. They are basically reside on a Java-capable web server and are run and reder themselves as they are requested. It is very much like serving simple HTML pages.

Zope is completely different. You access objects directly thorugh the web via the URL path. Objects are responsible for their own rendering, either through built-in behaviours or acquired ones.

What does this mean? Say you give Zope a URL of http://localhost/folder/doc. Zope tries to find the object doc in the folder folder in the root. It then asks it to publish itself. Say you have a rendering object (perhaps a DTML Method) in the root then you can say http://localhost/folder/doc/render and since render is acquired by all objects in the root (which is everything) it works on the object it is implicitly a property of: doc. This is a very flexible and powerful way of developing.

Of course, objects aren't only available through-the-web, but also through WebDAV, FTP, XML-RPC, and friends.

Object Types

EJBs come in Entity and Session flavors. Zope objects make no such distinction. They are simply Zope objects. Most inherit a persistence class and become permanent additions to the ZODB when created, much like Entity beans. There are also objects meant to track session data, particularly the CoreSessionData object. But there's nothing particularly special about session data objects.

(Another approach to session data is to store it in the HTTP request data, but that does require maintenance of the data on each page.)

The place of stateless Session beans is taken by method objects, which have no data of their own (no Properties tab in the ZMI) but only contain behaviour. Methods must use the data of some other object gotten implicitly by acquisition. An example of this is the DTML Method, which unlike DTML Documents can have no properties and can only work with the data of other documents.

Most Zope objects behave like container-managed Entity beans, but are by no means obligated to use the Zope mechanisms for persistence. Many Products use other means of persistence, such as the filesystem, although this persistence isn't managed by Zope.

If you do want a different type of persistence, you can also mount a different type of storage: the ZODB is an interface, and doesn't care what type of backend you use. Different storages can be mounted at point on the tree, not unlike a Unix filesystem, and be managed transparently by Zope. It's not often needed, though, so if you think you need to do this, think twice.

Object Definitions

I've no idea what I mean by this... I leave it here in the hope I'll remember some time in the future.

Language Properties

A big difference between Zope and EJBs is akin to the difference between Python and Java: the difference between dynamic and static properties. In Java, you can only hold information in slots defined at compile time. This guarnatees that they'll always be there, but also makes it more difficult to add information at runtime. Python, being an interpreted dynamic language, allows you to add fields to a class (and thus properties to a Zope object) dynamically, so if an object needs data, just add it.

Python also allows multiple inheritance, whereas Java does not, and so Zope objects can inherit from any number of other Zope objects, and EJBs only one. This has lead to the heavy use of mixin classes in Zope core/product development, where you inherit a class in order to add functionality. Whether this is a good idea or not is up in the air among object-oriented programmers and other pundits.

Discoverability

Zope provides an easy graphical view of the internal state of the ZODB, and since so much of a Zope application's logic is based on structure (because of acquisition), it can be understood quickly on a high level, and on a low level by looking at the code. J2EE systems don't have any such thing, and understanding the application is a strictly low-level-then-up affair.

This view is also the development environment, and provides a low-impact way for people to feel out the system. Unfortunately the resemblance of the ZODB tree to a filesystem is confusing to many people with more traditional mindsets, so it is important to realize the ZMI view for what it is: a window into Zope, and not a thorugh-the-web file manager.

Scale

J2EE systems are aimed at enterprise computing. This means that there is significant overhead in setting up such systems. They often require external databases and web servers, not to mention a properly configured Java Runtime Environment. It also requires a good bit of raw coding before anything moderately useful begins to take shape. While they scale up nicely, J2EE systems make starting small and scaling up, or just making small scale apps.

Zope also scales up to massive three-tier enterprise apps, but is also quite happy by itself, since it has not only its own object database but its own web server. Zope sites can scale from a desktop install to a massive site almost effortlessly.

Zope can be run sucessfully with a single install, and basically useful sites can be created almost as soon as it is up. There's very little up-front overhead in making Zope sites.

When is J2EE better than Zope?

Obviously if you already have an infrastruture in J2EE, especially with developers and database admins and designers it makes sense to stay with what you know. Likewise, if you have to do serious interaction with existing Java systems, then you should consider sticking with J2EE. It's not a very forward-looking attitude, but then a lot of people would prefer maintaining legacy systems than changing to something that would make life easier.

Also, if you're just moving legacy or relational database data to the web, Java does a pretty good job, since it has a design focus towards being middleware.

The Road to Zope Mastery

The path to J2EE guruness is parallel to the Zope road, at least for a short way. It is essential to realize that what you used to do is probably not the right way to do it in Zope, because Zope operates differently and provides a much richer environment than most competing systems. Take advantage of what Zope gies you for free; in Java you might be reinventing the wheel, but in Zope you'd be reinventing the whole car.

Parting Words

Sometimes Zope trie to make your brain explode, but remember: what doesn't destroy your brain will make you wonder how you ever got along before. Keep at it.

Good luck Zoping.