Mission
The mission of the Frameworx Project is to develop tools and run-time components for service-oriented J2EE application production that are both (1) open source and freely available and (2) comparable to the most capable proprietary products.
Scope
The Frameworx Project is being seeded with a set of fully implemented components that represent hundreds of person-years of cumulative experience in developing service-oriented application frameworks.
Each of these components independently addresses one or more narrower aspects of the problems development organizations face in efficiently producing applications that are subject to continuously changing requirements. Integrated within a larger service-oriented architecture, this component-set provides a broad and deep approach to the overall problem of J2EE application production.
The Frameworx Project is divided into the following sub-projects:
Louis, a highly evolved, standards-based object:relational mapping framework. Mies, a composition framework for standards-based data modeling, assembly and integration. Imhotep, execution frameworks for XML-defined workflows and work-routing networks. Alvar, a graphical editor framework based on Java Swing. Buckminster, frameworks for building, assembling and deploying component-based systems under configuration management control in large-scale or distributed development organizations.
Each sub-project will have independent technical ownership and follow an independent development path. However, preserving technical compatibility among projects will be a priority, and we will encourage overlapping project membership and architectural coordination.
The Frameworx Project is committed to free & open "Apache-style" licensing for all of its initiated projects.
Architecture
The Frameworx projects listed above have been seeded with components originally developed within a patented service-oriented application architecture. The objective of this architecture is to "package" architectural values that support architectural reuse, extensibility, variability and integratability.
Six-Layer Model
The foundation of this architecture is a six-layer logical model that defines the abstract structure - from database to user interface - of nearly any business-type application. The six-layer model implements those separations of concern that, in our experience, are essential to developing applications with the target architectural values or reuse and variability.
The six layers, and the key separations of concern they implement, are as follows:
Database: separation of the concerns of physical storage and relational persistence from those of an object-oriented information model. The objective is to give the information modeler "freedom of expression", while preserving and leveraging the underlying capabilities of physical data storage mechanisms for operational performance and efficiency. Information model: the object-oriented view of application data. The objective is to support a normalized OO view of all data available for all system use-cases, both from local data sources and external systems. Business data object: a projection of, or facade to, the information model comprising the information appropriate for a given use-case (or set of related use-cases), rather than for all use-cases. The objective is to hide the extent and complexity of the entire information model from application logic, in order to simplify development and minimize the impact of subsequent information model changes. Application control object: transactional semantics added to methods, comprising the overall control logic for given use-cases. The objective is to provide a clear separation between use-case data and use-case control logic, as well as a clear point of transactional demarcation. Interaction object: a protocol transcoding layer that separates generic client service requests (i.e. from a user interface, message queue, Web service) from underlying application logic. The objective is to make application logic completely independent of client implementation, and to provide a consolidated point of access for all internal and external service requests. User interface: a generic user interface. The objective, accomplished by the overall architecture, is to free application logic from all client implementation constraints. Consequently, this layer is essentially empty in the Frameworx architecture.
A fully implemented framework (or set of frameworks and facilities) exists for each of these six layers, assembled from components that we have developed and from widely used open source components.
Common Facilities
Alongside this architectural foundation is an additional set of common facilities (or frameworks), each of which implements a functional pattern commonly required within specified functional domains. Workflow is one of the most broadly applicable of these facilities.
Component Production
An additional set of frameworks and tools addresses the orthogonal concerns associated with application production, such as automating build & deploy processes for component-based systems assembled from multiple sources under version/configuration control.
Sub-Project Packaging
We have segmented this component superset into five separate projects to make explicit the underlying service-orientation of this architecture, and to emphasize their respective values outside the larger architecture. In addition, popular open source components now provide functionality that overlaps with certain of our implementations - particularly those at the Application Control and Interaction layers - and we want to encourage developers to slot these new components in, as appropriate.
An approximate mapping of these projects to the architecture above is as follows:
Louis: Layers 1 (database) and 2 (information model). Mies: Layer 3 (business data object). Imhotep: Horizontal frameworks for workflow & work-routing. Buckminster: Component production. Alvar: A Java/Swing-based visual/graphical editor framework, within which editors for the frameworks & facilities summarized above have been implemented.
|
