Difference between revisions of "Zope Component Architecture"

Revision as of 16:25, 2 February 2012

This page describes the Zope Component Architecture, or ZCA for short.

ZCA: What is it?

The Zope Component Architecture is a Framework that arose out of Zope 3 development, and is now integrated into Zope 2. It is used by various software projects, and doesn't even require Zope to run. You can use it natively with Python. It's part of Zope, but it's not Zope.

Why Should I Use It?

You shouldn't. Well, I mean, don't use it unless you see the value in it, or if you are using a software project that uses it already. Due to the fact that it is a framework, it does impose a paradigm on how you develop Python code and you need to determine if that paradigm works for your particular situation, or if it doesn't.

The Paradigm

In one phrase, the paradigm implemented by the ZCA framework is that of a "component architecture", which in itself may not mean anything to you, but it is easy to understand.

If you are reading this, you have probably developed some Python software. Now imagine if you had to lead a team that is developing a complex Python software application. This type of project presents new challenges that you may not experience as an individual developer.

For one, different members of the team have different skill sets. You also want the team to be able to work in parallel rather than have some members of the team sit idle waiting for parts they depend upon to be completed. Ideally, you would want to split the application into logical parts and then clearly define who is doing what part of the software and what each team is delivering. But when the software is complete, it needs to work together as an integrated unit.

Clearly, you will need to think about the software architecture. But it can also be helpful to have a framework your team can use that helps them to split the application into logical parts, develop these parts in parallel, and then allow these various parts to interact once they are done. This is what a component architecture is typically used for. It supports this style of development.

Interfaces

You decide to split your team into smaller groups, and each group will tackle one part of the software. One group's code will need to interact with another group's code, but many parts depend upon other parts that haven't been written yet. To solve this chicken-and-egg problem, the groups need to define interfaces for how others will be able to utilize their code, even before it is written. These interfaces are the interaction points for one group to utilize software that other groups write.

Now we have added an additional layer of complexity to the software development project -- the effort of defining these interfaces. But we expect the investment to reap major rewards in mere days as this model of development will allow each group to actively develop their part of the application without waiting on another group to complete theirs first. While this could be done without ZCA, essentially all of ZCA is designed to help facilitate this style of development.

Now that you understand this, you will have a better appreciation for why ZCA is designed the way it is. It is trying to provide a framework for building larger projects that cannot be handled by a single developer. It does add some complexity to your project. This is intentional. You should only use ZCA if you expect that the additional complexity will be more than offset by improved productivity, maintainability and software quality that can arise from a component-based architecture. So, is it right for you? There is no one answer to this. The right answer will depend on the complexity of the project, your development team, and other factors.

At least now you know what ZCA is designed for, so you will be able to evaluate it fairly :)

The Parts of ZCA

This section describes the "components" of ZCA itself.

Component Registry

The Component Registry, also called a Site Manager, is a directory of components, and arguably the heart of ZCA. You register components with the component registry, and then others can query the registry for components that they need. There is a global component registry and a local component registry.

Global Component Registry

According to the Zope 3 documentation, "the global registry is unique, created automatically, and populated with all the registrations done in the ZCML files."

Local Component Registry

According to the Zope 3 documentation, "the local registries are persistent and typically live in the ZODB database, in what is called a local site manager. Local registries allow you to override or create component registrations in the object hierarchy, in a contextual manner."

ZCML

Pronounced "Z-camel", ZCML is an XML-based configuration file syntax that is used to register components with the global component registry. It is useful in that it provides a mechanism to add new components using configuration files rather than touching source code. It also provides a mechanism to easily extend ZCA code by overriding existing components with new implementations -- all without touching existing Python source code.

Interfaces

Interfaces are special Python classes that describe functionality implemented by a class or module. They are registered with a component registry, and others can query the registry for components that implement a particular interface. Objects can advertise that they implement a particular interface.

Adapters

Adapters are components that add new Interfaces to existing objects, so they can be used in new ways.

Utilities

A utility is a Python object that you want to add to the component registry. It could be any type of Python object that another part of your application may need. A utility must implement at least one interface. The Zope Documentation has some guidance on when it's appropriate to create a utility.

Multi-Adapters

Multi-adapters are adapters that have the ability to adapt one than more type of object.

Subscription Adapters

Adapters can be registered as subscription adapters, and then all adapters that adapt a particular object can be retrieved by calling the zope.component.subscribers() function. This is useful when doing things like validation, where you want to get back a bunch of adapters that apply to a specific object. Subscription adapters can return a value.

Handlers

Handlers are like subscription adapters, but they do not return a value to the caller. They go off, "handle" something, and then return.

Override

If you register multiple components with the same arguments, the last component registered will replace any previously-registered components. This behavior is used to replace existing components with new ones that may implement new functionality.

Invariants

Invariants are functions that you attach to your interfaces that throw exceptions when certain conditions aren't met. Invariants are invoked by calling the interface's validateInvariants method, passing the object to be validated as an argument.