Another Framework Vision

This document is intended to introduce another vision of an application framework for the Apache Open for Business project. It is based on experience developing applications that run on a variety of platforms that include embedded systems, small servers, midrange systems and mainframe systems.

Any discussion of an application framework must start with a definition of what an application framework is. In this document, an application framework is defined as a software framework written in Java that provides the basic structure to write an application.

All applications, regardless of size or complexity, require a fundamental set of capabilities or functions:

1. Configuration.
2. Localization (locale, time zone, currency).
3. Logging.
4. Security (authentication/authorization).
5. Persistence (file system or database).
6. Tasks (services).
   

At a minimum, an application framework should provide those capabilities. The vision proposed in this document is a minimalist one: An application framework should be limited to those six capabilities.

The interesting thing to note about those six items is that they all rely on each other, or are dependent on each other. Items 2 through 6 require item 1 – Configuration. A configuration needs to be persisted – item 5. Access to data (Persistence) might be controlled by Security, and Security-related data might be persisted. Therefore, in this vision all six capabilities comprise a unit. In “OFBiz Speak” they are a single component.

Java code for the application framework is nothing more than some interfaces and abstract classes that provide “glue” to connect existing Java code libraries, while the Java libraries provide the needed capabilities. The “out of the box” version of the application framework would include an agreed-upon set of libraries. Users of the framework would be free to exchange the provided libraries with something else.

An embedded systems developer could build an application based on this framework. This framework could also serve as the basis of Windows services or Unix daemons.

Building On The Framework

In this vision of an application framework, additional capabilities are built upon the framework component – they are not built into it.

Let’s say a Unix daemon developer would prefer to use scripting to develop an application. A separate scripting component could be built on the framework. This is a different approach from the current code – where scripting capability is scattered throughout the project. Such a component could be configured to support any number of scripting languages.

The daemon developer might need to alert someone to a problem – via a Syslog message, eMail, or SMS message. A separate communications component could be built on the framework. The communications component could be configured to support any number of communication methods.

Additional capabilities could be generalized and compartmentalized into components that build on the application framework, and yet none of those capabilities are built into the framework. Components depend on the framework, and some components might depend on other components, but the framework does not depend on any other component. There could even be a separate “component manager” component that exists between components and the framework (maybe based on OSGi). It could provide things like version and dependency control/management.

Web ERP Applications

If we start off with the minimalist framework approach and build it out with separate components that provide additional capabilities, eventually the sum of the parts will equal what is considered “the framework” in the current project – upon which web applications can be built. The difference is, the parts are modular and can be used in various combinations to achieve a goal - without requiring the inclusion of the entire OFBiz project. Ideally, some components could be spun off to separate projects.

Conclusion

This document is intentionally short on details. Its purpose is to present a vision, not an implementation.

A draft high-level design document can be found here.