The Zope Application Server Revisited

By: Kevin Reichard
Friday, January 7, 2000 08:31:26 AM EST
URL: http://www.linuxplanet.com/linuxplanet/reviews/1319/1/

Introducing Zope

One of the most noteworthy things about the open-source world is that no good idea is ever wasted; if it doesn't succeed the first time around, it's generally recycled through a few iterations until a wider audience is reached.

Such is the case with Python and Zope. Python has a devoted user base; while this base may not be as large as the user base associated with Java or Perl or Tcl, it's still significant enough to warrant serious consideration in discussions of scripting and programming languages. That's because at its core there are a lot of good ideas within Python about how data should be handled in an object-oriented fashion.

These good ideas are given more exposure and a fuller development in Zope, an open-source application server developed by Digital Creations. Zope is positioned in several different ways by its developers. First, Zope is direct competition to application servers like Cold Fusion and SilverStream, which take user-friendly queries from Web browsers via Java applications, submit them to relational database, format the returned data, and then send the information back to the Web browser. (This, of course, is a gross simplification of what an application server does, but it gives you a general idea, nevertheless.) Secondly, Zope is positioned as an open-source development system against the likes of mod_perl and PHP. Finally, Zope is a content-management system and portal manager, competing against Glyphica, Portera and Vignette.

In this review, we're evaluating Zope as an application server. This isn't to say that the other two areas aren't worthy of consideration, but the application-server market is exceptionally competitive right now, and is one in which Linux solutions are still in short supply despite the presence of Cold Fusion, Bluestone Sapphire/Web and IBM WebSphere.

Installing and Configuring Zope

We downloaded a binary version of Zope 2.1.0 from the Zope Web site and installed it on a Slackware Linux 7.0 server. Zope requires a later version of Python to work (1.5.2 or later), and this distribution included a copy. (Don't be misled by the heavy stress on Python in this explanation of Zope; while the majority of Zope is developed in Python, there are performance-sensitive portions written in C, and by and large you can get a lot of work done in Zope without needing to know a lot about Python.) Zope includes the ZODB object database, Z Classes, WebDAV support, XML-RPC client support, the ZServer Web server and Zcatalog, an indexing tool for creating catalogs.

Zope is available in either binary or source-code form. A program guided us through the installation, and we encountered few problems installing and configuring Zope.

Zope may be open-source software, but it's not distributed under the terms of a GPL or even a Berkeley-style license; it's distributed under the Zope Public License. The terms within the ZPL aren't too onerous--basically, you're asked to give credit to Digital Creations whenever possible--and anyone planning on deploying Zope should have no problem in meeting the license guidelines.

You can use Zope as a total front-to-end solution or integrate it with existing components. For example, Zope comes with its own Web server, but it supports Apache, Netscape, and Microsoft (IIS) Web servers as well. On the back end Zope ships with a native nonrelational database, ZODB, and the assumption is that you'll use ZORB for data storage. If you're not thrilled with the idea of using ZORB as your database format, you can connect Zope to Oracle, Sybase, MySQL, ODBC, Postgres, Solid and Adabas databases.

Although Zope will work with a wide variety of Web servers, the preferred server is the included ZServer, which is a Zope-modified Medusa server toolkit. ZServer allows access via any number of protocols, not just HTTP (for instance, ZServer supports both FTP and WebDAV access), but the command-line ZServer may not be the easiest to launch and monitor for someone who's more used to working with a graphical interface. And while ZServer may be as high-performance a Web server as the Zope documentation claims, there are any number of shortcomings with ZServer that could preclude its use: it doesn't support SSL, it doesn't perform any proxying, and it doesn't support virtual hosts.

If you do use a third-party Web server, you'll need configure Zope to access it via CGI, FastCGI, or PCGI (Persistent CGI), not the most efficient ways of Web-server interaction. We configured Zope to work with an Apache server, and this process was a lot more involved than need be, given the ubiquitous nature of Apache. In the future, we'd like to see better support for Apache in Zope.

One area where Zope excels is user management. Zope is designed to manage authentication and user permissions, and outside protocols like RADIUS are fully supported. Users are treated as objects (in a nonsexist way, of course) and assigned roles, such as content author or manager, that basically function as groups. Roles are assigned permissions, which are operations on objects and correspond to traditional permissions (read, write, execute), with the twist that permissions are specific to objects; different objects can provide different permissions. Once you get past Zope's insistence on using different terms to describe some widely used user-management strategies, you'll see how powerful its user-management tools can be.

Developing Zope Applications

One area where Zope does compare unfavorably with more established application servers is in its lack of advanced development tools. With every other major application server you have an accompanying "studio" product for offline application development. Typically these development tools sport a graphical interface and stand alone as application-development environments. (Allaire's Cold Fusion really began life as a development environment, not as an application server.) Typically these development environments also come with several applications, both to show how applications are developed and also to create new applications.

Seeing a need for a studio environment, Digital Creations and Mozilla (the open-source-development group that's developing future versions of Netscape Navigator) have formed an agreement to develop management tools for Zope. You can read more about the Zope/Mozilla agreement here.

The development environment associated with Zope, a Web-based interface to a Zope server, works surprisingly well, given its limited nature. I used the Web interface to create some simple applications, relying heavily on the documentation to guide me through the process. The one drawback is that Zope doesn't ship with many prebuilt apps. While you can easily grab some from the Zope Web site that were developed and configured by volunteers, they don't substitute for the power of an application-development suite. Anyone not familiar with Python will have a difficult time developing for Zope (as I did, even though I've developed applications on multiple application servers).

And you'll need to code by hand, basically. Zope features DTML, the Document Template Markup Language. (Sadly, there's no way to work with Zope without using DTML. Contrast this with the upcoming release of Cold Fusion 4.5, which adds Java capabilities and decreases the importance of CFML.) The DTML tags are placed directly within your HTML code. These tags are basically used to include variables.

To generate content, you'll need to work with a Zope-supplied Web interface, rather than working with a third-party editor. Quite honestly, it took me a good while to develop an application under Zope, mostly because of my lack of familiarity with both Zope and Python. However, once I spent some time poring over the documentation, and heeding my son's exhortation to "try, try again," I managed to create a small groupware application that stored a rather inconsequential set of data in an SQL database. Basically, the framework for creating applications involves Z Classes, which are objects containing their own methods and properties that can be implemented anywhere within a ZORB hierarchy. To create a Z Class, you can use the Web-based Zope development interface without resorting to a programming language like C++. The lesson: you're not going to be able to jump right in and develop applications using Zope, but once you've developed some, you'll find that the same object-oriented mechanisms and procedures can be used time after time.

Part of the problem with Zope, quite honestly, is that it doesn't play by the rules set forth by the rest of the application-server field. Start hanging around application-server vendors and you'll quickly find that there's a list of mandatory features that represent checklist items when selling into the enterprise. The application-server heavyweights make it quite clear that they're in the business of connecting databases in the enterprise and enabling e-commerce solutions for major players.

But as the open-source world is more (for the lack of a better word) idealistic and bent on presenting things in a unique light, you see Zope repeatedly referred to as an "object publishing system," whatever the heck that means. Structurally, Zope works like most other application servers. The user connects to a Web server via a browser. The server passes requests to an Object Request Broker (ORB) via a publisher. The ORB queries the database, finds the requested data, formats the data in HTML via the Zope-managed templates, and then sends the data to the user.

That, dear readers, is exactly how almost every application server on the market works, give or take a few small twists in the process. However, the devil is certainly in the details, as there's a host of programming languages and object protocols to achieve these goals and ensure that high-level servers can speak to one another even if they come from different servers on different architectures. And it's on the level of details where Zope comes up somewhat short.

Some Zope Drawbacks

For instance: the larger application-server field relies on CORBA or COM; UNIX vendors tend to line up behind CORBA and NT vendors line up behind COM. Though Python supports COM and CORBA, Zope doesn't explicitly support either, so you'll need to come up with your own Python code and include it within Zope in order to enable COM and CORBA support. This is one of the chief difficulties with Zope: you not only need to come up with your own applications, but you must also program your own application server!

In addition, the application-server market has largely settled on Java and Enterprise JavaBeans (EJBs) as tools that can be deployed on any application server, allowing different servers from different vendors to interoperate on a useful level. There's no hint at all within Zope or the Zope documentation that Java/EJB support was ever considered, much less implemented. This is a major problem within Zope; you can argue all day and night that Python is superior to Java, but one simply can't ignore the realities of the marketplace.

Another potential drawback to Zope--which, admittedly, I didn't establish with the use of any sophisticated benchmarking or performance testing --was that performance seemed to be on the slower side. I purposely created the same sort of applications under Zope that I created for a previous review of a beta version of Cold Fusion 4.5 for Linux (which you can read here), using the same back-end SQL database. When putting both application servers through their paces, it seemed as though Cold Fusion for Linux featured snappier performance when working with CFML code and slightly quicker performance when working with Java code. I can't tell whether this is due to DTML being a drag on performance or some component underperforming, nor can I make the argument that you'll see a similar performance drag when deploying Zope on a production-quality system.

One final complaint: as far as application servers go, Zope represents an unsophisticated approach to load balancing and fault tolerance. In Zope itself, there's no load balancing at all; you'll need to purchase it separately as a commercial product from Digital Creations. Fault tolerance and failover ensures that a user session doesn't fail when a server goes down; the session is taken over by another server in the cluster. In the enterprise, load balancing and failover are now nearly mandatory, so until Digital Creations boosts Zope's capabilities in this area, it will be forever doomed to be a departmental server performing a limited number of transactions in non-mission-critical environments.

In Conclusion

Which would be too bad, since Zope deserves a wider audience--just not in this form. Right now Zope is a programmer's environment for managing database transactions using Web technology. If you want something, goes the current Zope thinking, all you need to do is program it in Python. Want COM or CORBA? Just program it in! Need to fully support XML? Just grab an XML tool from the Zope Web site and integrate it yourself.

The trouble is that many of the folks working on a day-to-day basis with application servers aren't programmers and really don't want to learn Python programming in order to get the most, or even just enough, out of their applications servers. They don't want to mess with downloading tools for adding fuller XML capabilities to their application server: they want XML in there in the first place. They want features to hand in a polished application-development and deployment suite.

The biggest advantage to Zope is that it's a tremendous development platform with a ton of potential, but until the creators of Zope harness that power in a way that nonprogrammers can use--as well as integrate essential application-server technologies like CORBA/COM management, load balancing and failover--then Zope is destined to be a niche player, applied more as an open-source tool than as a full-featured application server. And that would be a shame.

Digital Creations Responds

Many thanks for your piece on Zope in LinuxPlanet. It's always nice to see Zope get recognition as a member of the appserver marketplace. You raised many points with your analysis that Digital Creations and the Zope community at large has been pondering for some time. I'd like to discuss some of these below.

First, it's true that getting Zope integrated with Apache is pretty hard. We have thrown a lot of energy over the years towards improving this situation, but in the end, Apache is hard to integrate with. This lament is repeated in the FastCGI, Midgard, and Enhydra communities. We provide a pre-compiled, pre-configured "Zap" (Zope Apache) that helps this situation by demonstrating how it can be done. Since you didn't find this, it indicates that we need to provide more information.

Lesson #1: Create a "Reviewer's Guide" that quickly lists the resources needed.

At the same time, our move to FastCGI and particularly adding cookie-based authentication will ease the burden of plugging into Apache.

Next, you mention that Zope should support RADIUS. There is, in fact, a user-contributed "user folder" that hooks into RADIUS for authentication information. Editor: The review has been edited to reflect this fact.

Lesson #2: Provide links to prominent third-party packages in the Reviewer's Guide.

You say " [o]nce you get past Zope's insistence on using different terms to describe some widely used user-management strategies..." This touches on a theme you discuss that Zope has a jargon challenge. I agree. Writing the Zope O'Reilly book has forced us to confront and begin addressing this. People should be able to leverage concepts they have already mastered when approaching Zope.

Lesson #3: Being different can be good, being unnecessarily different can be fatal.

Concerning the "studio", this has been an area of major, major concern for us. We don't want to lose the "Internet architecture" of a web-based development environment, but we absolutely must improve the productivity of using Zope. Which is why we started the Zope Mozilla initiative. Unfortunately the press release went out the day after your article went up! Editor: Sadly enough, this is true. You can read more about the Zope/Mozilla agreement here.

Our goal is to seriously narrow the productivity gap with traditional studios while retaining an Internet architecture.

Concerning COM, CORBA, and EJB integration, you certainly represent a valid, traditional view of the marketplace. In this regard, though, Zope is similar to Linux, which bucked a trend that had NT taking over the world by now. Certainly the Java bandwagon is pretty loaded, but there is still a lot of non-Java sentiment out there. Chances are that we will provide a strong level of COM/CORBA/EJB integration, but ultimately we view the use of Python as a competitive advantage and a differentiator. We are focusing first on Internet-centric interoperability protocols, such as XML-RPC, SOAP, and WebDAV.

Concerning Zope performance, it currently falls under the "neither fast nor slow" banner. Zope won't saturate a gigabit ethernet, that's for sure! :^) However, Zope provides pretty high performance (10-80 hits/second) that covers a broad swath of Web site requirements and is very competitive with commercial content management systems.

I will take issue with a dichotomy you present on the last page. After convincing the readers that COM/CORBA/EJB is a must, you then assert that "...many of the folks working on a day-to-day basis with application servers aren't programmers and really don't want to learn Python programming..." Seriously, COM and Java are incredibly more complicated than Python. Someone that finds Python too hard to learn will surely not scale the COM or Java learning curve, in my opinion.

--Paul Everett, Digital Creations