The GenUIne Development Approach - Part 2

October 22, 2008

As stated in my last post , the new Magnolia AdminCentral is developed on two different fronts or approaches. The first approach relates to interface design and the second approach, the topic of this article, relates to the technical development of the GenUIne development project.

At the beginning of the GenUIne development, the Magnolia team discussed the various technological options currently available to implement a web-based user interface. Two different technologies have been considered to implement the AdminCentral web application: the “JavaServer Faces (JSF) based approach” and the “web Services based approach”. Before I discuss these in detail I will briefly discuss some important design goals Magnolia intends to meet with the new technology of choice.

Architectural Design Goals and Motivation for the Technological Overhaul

Our main goal for GenUIne is ease-of-development. This is, in my opinion, the most pressing issue with the current implementation of the Magnolia GUI. Whatever technology we choose, it should be easier and more straightforward to implement, extend and maintain the GUI-code.

One important factor to achieve ease-of-development is the separation of concerns. Separation of concerns entails separating the business logic from the model and the view layer. The business logic of Magnolia is primarily content management. More specifically I’m talking about a separation of technologies, for instance using a templating language for AdminCentral dialogs instead of Java code to generate JavaScript or HTML snippets. JavaScript, HTML and CSS code is used in the current Magnolia GUI library. JavaScript, HTML and CSS code is spread over various resources including compiled Java classes. Those classes inherit from other classes which in the end leads to a nearly non-maintainable code and makes changes or improvements take a massive amount of time.

Another major goal is of course to raise Magnolia’s AJAX capabilities to the next level. This is essential in order to implement all of the current requirements with intuitive usability. Magnolia has always had AJAX capabilities built into the “self-made” library of controls. These AJAX features were there before the popularity of AJAX began to be dominant and these features are one important factor for Magnolia’s success. Nevertheless, Magnolia will gain a great deal of functionality, quality, economic advantage and potentially market share by switching to a supported, well-documented and vital third-party library.

An overhaul of the Magnolia AdminCentral GUI could also affect the way users can implement web pages with the Magnolia CMS. In particular, it may be possible to have a simplified programming model for building AJAX-enabled web experiences based on Magnolia. This advantage is primarily a gain in ease-of-use and functionality in templating and is not the primary goal of the pending Magnolia 4.0 release. Technological evolution of Magnolia can also improve our system by making it easier to integrate Magnolia into other systems when the Magnolia GUI is based on standardized web service technologies.

The JavaServer Faces Based Approach

The first technology I evaluated was JSF. JSF is not only a JCP standardized technology but also has a larger set of important, built-in features. Thus it was, in my opinion, “the natural approach” to use JSF for implementing a web based GUI since it resolves many of the problems discussed above.

JSF is a component-oriented framework that allows the declarative composition of interactive web GUIs, which is one of the things I like most about JSF. In addition it clearly separates the application’s model, view and controller in terms of:

• JavaBeans, validators and converters for the model
• Renderers and render kits for the view and
• The so called backing beans for the application logic

In JSF these concepts are applied in a sophisticated, well-defined life-cycle that is executed in order to serve complete page requests or partial page updates (when using AJAX). The figure on the left depicts the JSF rendering scenario. JSF can also be used with different templating technologies such as JSP or Facelets. It also has built-in support for internationalization (I18n) and is in addition extremely flexible and extensible.

While this sounds very positive so far, there are some drawbacks to the JSF option. First of all, developing real components with JSF is (at least with the current spec version 1.2), a complex task. This issue will be fixed in JSF 2.0 . In practice, to implement a new component or to modify an existing one requires the developer to rely on the CDK of the component library’s vendor – if there exists such a CDK at all.

Furthermore, this issue is the same with JSF and AJAX. The JSF spec in its current version doesn’t fully utilize AJAX functionality much (again, this will be fixed with JSF 2.0). The way you use or implement AJAX behavior therefore ultimately depends on the component library implementation of choice. Regarding the built-in AJAX features of such libraries, JSF component libraries do not master AJAX particularly well when compared to pure JavaScript GUI frameworks. For a comparison of JSF component libraries (and some JavaScript libraries see JSFMatrix.net ). JavaScript-only frameworks such as ExtJS have many ready-to-use components with sophisticated editing and extension capabilities (note that the ExtJS column under JSFmatrix.net is incomplete).

For the reasons mentioned above Magnolia decided to evaluate another, more modern approach: the Web services based approach.

The Web Services Based Approach

In general I share the opinion of Michael Marth who states in his recent blog post on modern CMS architectures that state-of-the-art web content management systems should have a 3-layered architecture instead of being monolithic, at maximum 2-layered web applications. In short, in the 3-layered architecture described by Marth the CMS is just one application out of many that sits on top of the newly introduced, so called web infrastructure layer. The web infrastructure layer itself provides services in terms of REST or SOAP based web services to access the JCR. The JCR sits on the bottom and builds the foundation of the stack.

I discovered an equivalent infrastructure which seems to be applicable for Magnolia as well (depicted in the figure on the right). The figure also depicts how one could even design the system to be compatible with both approaches discussed here: the web service and the JSF approach. In the case of Magnolia the web infrastructure layer (I’m also referring to it as the integration layer or service layer) would contain an API that offers the complete functionality of the Magnolia CMS as either SOAP or REST based web services accessible via HTTP.

The resulting architecture implies that the Magnolia AdminCentral application itself is, for instance, a JavaScript based client that can be statically served by any web server. Other options like Adobe Flex/AIR technology based rich clients or even Eclipse RCP based desktop clients are feasible as well. The client application (the frontend) only communicates with the Magnolia web services (the backend) through web service calls. This scenario (depicted in the figure on the left) is quite different than the JSF rendering scenario described above and requires a change in the complete development approach. Once the purely Java based web service API is complete, the development will be much more JavaScript centric than before. Further, the earlier stated goal of a clear separation of concerns would result, although implementation of this would not be a trivial undertaking.

Another benefit of the web service based approach is that the AdminCentral web application could have its own, completely independent development life-cycle separate from the rest of Magnolia. Consequently, new features of AdminCentral and improvements to existing AdminCentral features could be applied much faster and more frequently deployed to the customers.

Finally, beside the fact that AdminCentral gets a completely new look & feel, the web service approach would definitely also be beneficial for Magnolia in terms of extending functionality and more flexibly integrating Magnolia into other systems or system landscapes such as service-oriented architectures (SOA). This could also result in new business opportunities for the Magnolia company itself with companies using SOAs, although the additional benefits of this architecture will apply to companies that are already using the Magnolia enterprise content management system.

The Decision: Choosing the Web Service Based Approach

At this point, Magnolia has decided to go forward with a web service based approach. The advantages discussed above influenced this decision and in addition Magnolia developers and others evaluated several other technical considerations. Some of these technical considerations include server-side requirements and benefits, architectural considerations including decoupling, and several less critical issues including testability, learning curve to fully learn the new system and tool support. For more information refer to the decision table on the Magnolia wiki .

Although Magnolia has made the decision to go forward with the web service approach in general, no decision has been made in regard to the specific technologies to be used. Currently the Magnolia team is in the process of evaluating several different server-side technologies:

• JSR-311 compliant REST implementations (yes, there is a brand new JavaEE JSR for RESTful web services in Java, finalized no two week ago!)
• JAX-WS 2.x implementations for SOAP based web services
• XML-RPC implementations

There are also two different technologies under consideration for the client-side JavaScript libraries. The current candidates being evaluated are:

• JavaScript ExtJS framework and its Java based counterpart ExtGWT
• Sproutcore framework

So, what’s next?

Currently the Magnolia team is still busy with the next official release, Magnolia 3.7. Meanwhile I’m evaluating the different technologies mentioned above. I’ll also take a closer look at the Apache Sling project, which comes up with an interesting REST based approach to manage the underlying JCR. There will be more on that in a later post. And remember, there are some articles from the interface design trail in the pipe.