by Markus Plesser and Daniel Lichtenberger 05/01/2008
The daily bread and butter of an architect or developer dealing with web applications usually consists of a great many repetitive tasks. These start with setting up a development environment, choosing and downloading libraries (or let tools like Maven download them), creating basic build scripts, and wiring up all necessary components. After some time a naked skeleton for a web application is ready and waiting for further coding. While these steps are easy and can be efficiently handled by automation tools, other tasks like managing users, choosing a viable form of persistence (file based, JDBC, Hibernate, JPA, etc.), and implementing security for your sensitive data will still require a lot more time and effort.
There are many solutions out there that deal with some of these issues, but in most cases with some drawbacks: e.g., Ruby on Rails -- it is great and works well, but may not have corporate penetration, especially if a Java or .Net platform is already a company standard. We won't delve into the .Net world -- since this is a quite different situation than your typical Java environment -- but having a look at Java and especially Java EE, a web application will in most cases use JSF as its web framework, and the choice for a viable persistence framework will usually be Hibernate or JPA (in some Application Servers implemented using Hibernate). Depending on the use of some scaffolding tools you'll soon have some very basic versions of forms to create, read, edit, and delete data instances.
So far it has been pretty straightforward -- now imagine you also need authorization and authentication -- not only to be able to use (and hence see) data from your application, but even more to restrict access in a finer grained way than the usual "all or nothing" approach. You'll soon end up coding your own custom tailored mini-security framework - maybe based on established open source libraries like OSUser or Acegi coupled with some JAAS code.
Over the years, the authors did the same tasks over and over again. We learned a lot -- in particular about the capabilities and effort to integrate various libraries, as well as their major advantages and drawbacks -- and came up with a list of requirements for a framework:
Built in security, from authentication to fine grained authorization
Datatypes with inherent support for multiple languages
Hierarchical data structures
Support for workflows
Every little bit of the framework should be scriptable
No vendor or technology lock-in
Interoperability with other applications
Figure 1. [fleXive] core components
At its heart [fleXive] is a pure Java EE 5 application, the core is made up of EJB3 beans, sharing common states and configuration using a clustered cache (including out-of-the-box support for JBoss Cache 2.x with pluggable interfaces that could be used for other providers like GigaSpaces or Coherence), while the web layer is based on JSF using Facelets, Richfaces/Ajax4JSF, and the Dojo toolkit. As a persistence alternative to JPA/Hibernate (which can be used as well of course) [fleXive] comes with its own persistence implementation offering some advantages like integrated ACL based security, versioning, support for multilingual data types, inheritance, and reuse. The persistence framework is not intended as an object-to-relational mapper, but rather as generic objects with all instance data accessible using XPath-like statements or traversing object graphs.
All these so called engines (implemented as Enterprise JavaBeans) can be used in your project. [fleXive] supports you by creating application skeletons where you just have to implement your business logic, use some of the pre-made JSF user interface components while giving you the freedom to use which ever Java EE 5 compatible library you wish.
Figure 2. [fleXive] support for writing applications
A big advantage of using [fleXive] is the powerful, and extendable, backend application where you can model your data structures, manage users and security, visually create queries, store search results in so called briefcases, or edit your data instances.
While being designed and written from scratch, [fleXive] uses very mature and approved concepts dating back to 1999. Originally intended as a framework for content management systems it grew to a feature reach multi purpose framework incorporating state of the art open source projects and tools.
Not everything is perfect yet and some features (like import/export and webservice support) are still in the works, but the majority of the framework is very stable and solid and soon ready for production use. Since we at UCS (unique computing solutions gmbh), the company sponsoring [fleXive] and being responsible for development, believe in OpenSource and "give and take," we decided to release the whole framework licensed under the LGPL v2.1 or higher.
A backend application showcasing most of [fleXive]'s features which is built on top of the framework is licensed under the GPL v2 or higher. It helps you to visually manage most aspects of [fleXive] - like defining data structures, building queries, manage users and security, etc.
And while we are currently the only ones maintaining and extending [fleXive] we certainly do hope for some positive feedback, feature requests, and helping hands when it comes to development and documentation from you, the community, to make [fleXive] a valuable choice for upcoming web applications.
We tried not to reinvent the wheel, but to make it easier and faster to develop web applications using up-to-date technology, provide means to extend the framework using plugins, and provide a backend administration application that is ready to use and can easily be adopted to your needs.
Current development snapshots and the "Release Candidate 1" are available for download at http://www.flexive.org/download - the final release following hopefully soon after [fleXive] is feature complete and more or less bug free. For further information please have a look at the roadmap.