Listening to a discussion on Plone, a wonderful CMS built on top of Zope, I was reminded of our attempt to use Zope years ago. We wanted to replace a leave-processing application that was written using Lotus Notes with an application written for a platform that would not have any constraints or issues regarding user licenses.
We found that Zope was sufficiently difficult to get started with, so we finally used CGI scripts in Python, with PostgreSQL as the database. This met our needs. If I were making the decision today, the obvious choice for the platform would have been Django, TurboGears, Pylons or Rails.
However, application servers have not disappeared, and products like Zope, JBoss and Spring continue to attract developers and users. It may be that with better documentation, exposure and smart development environments, application servers are no longer as intimidating as they were when we first looked at them. However, application server developers cannot ignore the impact of the Rails phenomena. The following sentence from a Seam manual has remained in my mind:
This (Seam-gen) is the easy way to get your feet wet with Seam, and gives you some ammunition for the next time you find yourself trapped in an elevator with one of those tedious Ruby guys ranting about how great and wonderful his new toy is for building totally trivial applications that put things in databases.
Seam-gen creates a Seam application with a reasonable set of default parameters, so that developers can focus on the code, and not worry too much about the initial configuration details. A J2EE application typically requires modification of XML files — an integral, but painful part of the J2EE framework.
With the incorporation of annotations in J2EE, writing code for J2EE frameworks, including EJBs, is much simpler. Hence, Seam-gen is very useful; it helps get over the speed bump when getting started.
Another approach is to create frameworks on top of existing application server technologies. These frameworks may be especially useful in organisations that are already committed to an application server technology.
From Zope to Grok
Zope was the first object publishing framework. Zope 2 was very successful, especially because of the Plone application. Incidentally, Canonical’s Launchpad is another well-known example of an application suite using Zope. Zope 3’s core is the Zope Component Architecture (ZCA), which emphasised modularity and scalability. However, the Zope 3 framework was not compatible with Zope 2. The latter’s applications could not run on Zope 3 without significant rewrites. Hence, Zope 3 did not dominate new Zope deployments, and Zope 2 continues to be widely used, since Plone still uses it (Plone did not migrate from Zope 2).
The strategy was revised in Zope 3, in which the framework and the core libraries were separated. The core libraries were named the Zope Toolkit (ZTK). The original Zope 3 was renamed BlueBream. ZCF was backported to Zope 2, making it easier for older applications to use the components framework selectively.
The flexibility and versatility offered by BlueBream implied a longer learning curve. However, with the separation of ZTK from the framework, it became possible for alternate frameworks to be created using the same base.
Grok is a simpler framework, based on ZTK, which is pretty simple to use. (More on the birth of Grok here.) The intention of Grok is to expose ZTK to developers in such a way that it is easier, and more fun, to use.
We will explore Grok in greater detail, and how it compares with Django, in a later article.
Grails — for J2EE shops
Not all components of an application need to have the same characteristics. A substantial part of the application may need to be friendly, but scalability or performance issues are not critical. For example, the administrative part of an application needs to be easy to use, but it is rarely needed. Then, there are parts which may need to scale. It is also possible that we may prematurely optimise an application, at the cost of delaying the release, or make it harder to alter in case the users’ response is indifferent.
It is possible to use the same database as the backend, but use different frameworks for different needs. However, it can be hard to sell the idea of multiple development environments. It can also be hard to sell the idea of a Rails- or Django-like environment to an organisation that’s already using J2EE frameworks.
Grails may be an ideal solution in such environments. It can integrate very well and fairly easily with existing Java applications. Grails is now a project of SpringSource, a part of VMWare. It is built on top of J2EE technologies like Spring and Hibernate. It does not use XML configuration files. It uses the philosophy of “convention over configuration” like Rails. It uses Groovy as the development language. (Groovy, incidentally, is a dynamic programming language for the Java environment. It incorporates
the idiom of languages like Ruby and Python, while closely adhering to the syntax of Java.)
Given that the theme of this month is cloud computing, it is worth looking at Cloud Foundry, a service of SpringSource, which offers hosting of Grails applications in the Amazon cloud.
Grails and (especially) Grok is not as widely known as Rails is. However, in certain scenarios, it may be much easier to use one of them and still get the advantage of a rapid development cycle. Since both are built on established frameworks, the risk of using them is likely to be low to moderate. So, try one!
