Hello all,
First, I apologize in advance for the somewhat off-topic post.
A few people, but not many, already know that I've been working on a new
enterprise application framework over the past couple of months. That framework
is not starting to take shape and is called Moqui. You can see the Moqui
project on sourceforge, and eventually I'll get the moqui.org web site setup as
well (but it isn't yet, just a parked domain for now).
I've been waiting to make it more public until I had designs in place for most
of the main ideas, and that is now done. The designs and planning are not yet
complete, but are far enough along (and with an example application) that it is
at least clear what the framework will be like in a fair amount of detail.
How does this relate to the Apache OFBiz Framework? Why am I doing this as a
separate project instead of part of OFBiz?
I guess as Ricky Ricardo used to say, I've "got some 'splainin' to do!" I'll
try to keep it short and simple... but then again you probably know my track
record on that. ;)
Early in the life of OFBiz there were various points in time where we made
dramatic changes to the framework. This was somewhat painful even when the
project was small, and you can still see the results of that in OFBiz today
with some older code that does not take advantage of newer tools. It may be
that part of the problem was that the framework and the applications work
together in a single project and while the dividing line between them was
fairly clear for a long time it has become harder and harder to say what is
really in the framework and what is really in the applications and to keep
things in the framework from depending on the applications. If the framework
had been in a separate project the applications could have been built on a
certain version of the framework, released before updating to a newer version
of the framework, and then refactored or rebuilt to use the newer version of
the framework.
On the other hand, over time as the applications have grown and the number of
organizations using OFBiz have grown, it has become much more difficult to make
major changes in the framework because there is so much code that would have to
be updated and there are so many people using the code that would have problems
because of the updates. In many parts of OFBiz there is backwards compatible
code and I think it is impressive that so much backwards compatibility has been
maintained. This does have the downside of making the framework, and especially
the implementation of the framework, far more complex.
Over the years I've thought about many possible changes to the framework and
kept notes on them. There have been a few times when I focused on framework
improvements, and for a while after OFBiz joined the Apache Software Foundation
I even tried to push a temporary focus on the framework before the size and
scope of the applications increased too much more. A lot of great things have
been added to the framework in recent years in spite of all of the difficulties
and it has been impressive to see the community take up and leverage so many of
these changes.
A few months ago I started thinking about another set of changes and looking at
how they might be implemented inside OFBiz. Eventually I decided that the
changes were too dramatic and it would be much easier to just do them as a
separate project. What I have started is a separate open source project that is
not part of the Apache Software Foundation. It may take quite a while to get
this implemented even to the 1.0 release, and when that happens I hope that
either Apache OFBiz will move to use it or another project like OFBiz will be
built on it. For now I'm not really worried about that and the focus of the
effort is to build a good framework and nothing more. The license of the
framework is the Apache License 2.0.
With the Moqui framework I am also planning to structure the community
differently. There are many great things about a more open community driven
project like OFBiz. For example, it is a great place for innovation and new
ideas and collaboration with others to make those new ideas a reality. For me
personally I plan to stay involved with OFBiz and for the foreseeable future it
is still the main focus of my career. This may seem funny because I have been
hostile in the past with OFBiz to the idea of having more restricted control
over commits to the trunk, and I certainly haven't jumped on the GIT bandwagon
at all. That doesn't mean I don't think it's a good idea in general, I'm just
not sure how it would work for something like OFBiz or for any project in the
ASF.
However, with this new project I am planning on managing it more like Linux and
various other open-source projects are managed. The idea is for everything to
go through a single moderator. Contributions from others may be accepted, but
never directly and only through the moderator. The project may have multiple
moderators each responsible for a different part of the whole, but nothing will
go into the project without centralized review. This sort of model does bring
up other possible issues but for this sort of software the trade-off is well
worth it.
Yesterday I spent some time writing up an overview of the Moqui project and
also a comparison of the Moqui framework to the OFBiz framework. For those
interested I am including both below.
Out of courtesy for the real intent of this mailing list if you have questions
or comments about Moqui please send them to the Moqui Open Discussion Forum
instead of sending them to an OFBiz mailing list. This thread on this mailing
list will hopefully only have a single message so that the list can focus on
what it is meant to.
-David
=============================================================================
The Moqui Framework
=============================================================================
The Moqui Framework is an integrated tool set with everything needed to start
building web-based applications right away. Instead of starting with a set of
tools and figuring out how to use them together and filling in gaps that are
not handled by default Moqui is ready to go right away.
The Moqui Framework includes:
- Database (entity) proxy for data tier
- Define your entities and go, no code to write and no redundancy
- Java API or XML tags for a wide variety of queries and common operations
- Event-Condition-Action rules to do things based on data changes
- Data import and export tools, including for seed and other setup data
- Support for Derby, HSQL, PostgreSQL, MySQL, and Oracle OOTB, and easy to
add support for other databases, usually just through configuration
- Service-based logic tier
- Call services synchronously, async, or scheduled
- Services can be local or remote and implemented in a variety of languages
- Flexible XML service definitions
- Validation of data type, required or not, regexp, and other constraints;
validation runs on server and in client with JavaScript library
- Event-Condition-Action rules to orchestrate high level processes,
externally change or augment behavior of existing services, and much more
- Screen-base user interface tier
- Declarative multi-platform screens, text templates, or any combination
- Generate HTML, XML, PDF (XSL-FO), or drive GWT or Swing screens
- Screen files and included sets of subscreens in directories with the same
structure as the application
- Nested subscreens for multiple levels of tabs or other types of menus
- Data preparation logic declared with screens to make each screen modular
- Outgoing transitions point to input processing logic and conditional
forwarding to other screens or external URLs
- Forms (single, list), trees, panels, and various other common widgets
- Uses Groovy for scripting and Freemarker for templates (can add others)
- JCR 2.0 (JSR-283) based content and artifact management
- Manage incoming and outgoing email
- Implicit internationalization and easy localization
- Comprehensive security with declarative authorization
- Settings in the database, separate from implementation artifacts
- Define run-time inheritable permissions for any artifact in the system
- Both record level and implementation artifact level security
- Protection from XSS and XSRF threats (uses ESAPI and Antisamy)
- Flexible resource access from files, JCR repository, and many others
- Cache management for framework and application resources
- Logging
- Multi-tenant architecture (single application, one database per tenant)
- Common business data structures and seed data
- Enumerations and statuses with transitions
- Units of measure with conversion, including currency
- Geographic boundaries (legal and arbitrary) and points
- Time periods and temporal expressions
- Service/logic and data level integration options
- Data migration and mapping tools (especially for to/from XML, to/from db)
The framework features a well-defined Java API that makes it easy to get at
the features listed above, especially in Groovy code. What's even better is
that the Moqui tools are designed to be used in a declarative way so most of
what you need to do will be possible with XML configuration and little or no
code is required, unless you want to of course.
Moqui uses sourceforge.net for various tools. See the Moqui sourceforge site
here:
http://sourceforge.net/projects/moqui/
To access to the source for Moqui through SVN use this URL:
https://moqui.svn.sourceforge.net/svnroot/moqui/trunk/moqui
=============================================================================
The Moqui Framework versus the the Apache OFBiz Framework
=============================================================================
-- ControlServlet, widgets (screen, form, menu, tree):
These tools are now all combined into the XML Screens.
There are no explicit menus and instead there are subscreens and a menu is
automatically generated from the set of subscreens in a screen.
Instead of using the decoration pattern the XML Screens use subscreens to
compose an hierarchy of screens. The subscreens for a screen can be
configured in three different ways for different purposes including: a
directory structure plus defaults for a normal screen/subscreens hierarchy,
an XML element to include screens from other applications or that aren't in
any application, and a database table that allows add-on component to add
a subscreen to an existing screen somewhere else.
It is not an option to have multiple XML Screens in a single file. Each file
represents a single screen to make it easier to see what an application looks
like just by browsing the directory structure, kind of like it is for webapps
with normal templates and such.
Forms and trees are kept in separate files and are simply in-lined
in a screen. It is possible to refer to forms externally using the
screen's file location and the name of the form.
The widgets don't have any style attributes that will be used for HTML
class attributes. There are id attributes in various places, but the intent
is to use automatic id and class elements based on names and types of
elements in the XML Screens and then keep all of the styling in an external
CSS file.
There aren't any AJAX- and HTML-specific elements and attributes. This
goes back to the original intent of the OFBiz widgets and that is to be purely
declarative and platform independent. Many XML Screens elements will be
implemented using AJAX and DHTML, and options to control those or add to them
will be available.
-- MiniLang simple-methods, screen/form/etc actions
All operations from these various places are combined in one XSD file
and are referred to as XML Actions. These are included in various places
using the "actions" and "condition" elements. With this approach there is no
inconsistency for similarly named and designed operations or conditions.
Moqui XML Actions don't have operations that are not frequently used and some
operations are like a combination of various simple-method operations. There
are operations for a few additional things as well, like producing and
consuming XML.
Some operations that are inconsistent in different places in OFBiz, like
calling a service, have all similar features combined into one far more useful
operation.
There is no performFind service needed in Moqui as the entity-find operation
has an element that takes its place, and can be combined with various other
elements of a find by condition for a great deal of flexibility that is
easily usable.
The actions are available in many more places including ECA rules, screen
transitions (like the OFBiz controller request events), and others.
-- Service definitions and implementations
The OFBiz Service Engine is most like the Service Facade in Moqui. There are
many other facades, and for more info see the API Structure section below.
Service names are split into verb and noun parts, which together make up the
service name (ie like: ${verb}${noun}). Services are called with the combined
name and can separate the verb and noun parts of it using a hash mark ('#').
Service parameters in Moqui are like the service attributes in OFBiz.
Service parameters are split into two groups: "in-parameters" and
"out-parameters" so that parameters with the same name can have different
settings going into or coming out of the service.
Parameters in Moqui have hierarchical sub-types for map and collection types.
Parameters have a fairly complete set of validation tags. Those
validation tags will be used for server-side validation when the service is
called, AND when the service is a target on a screen transition it will be
used to generate client-side validation in JavaScript. This validation
is defined once but run in both places.
As mentioned above XML Actions are available in many places, and one of those
places is inside a service definition. With this a service implementation can
be inline inside the service definition or external depending on preference.
-- Entity engine
The OFBiz Entity Engine is most like the Entity Facade in Moqui. There are
many other facades, and for more info see the API Structure section below.
Entity definitions are more streamlined and don't have the less useful
attributes and elements. Primary key fields are designated with an attribute
on the field element instead of using a separate element. The data type
dictionary in Moqui is more simple and better organized than in OFBiz and
the data types available are declared in the XSD for auto-completion help.
The API for dealing with entity values and for queries and such is much more
simple, streamlined, and in a few small cases has additional functionality.
The methods have far more consistent names than in OFBiz, using
create/update/delete everywhere instead of things like store or remove.
Moqui does not have a concept of multiple delegators so the Entity Proxy
configuration file is much more simple. The datasource elements are also far
more simple because all of the database-specific settings are now in the
database configuration file along with the data type dictionary (combined in
one file instead of a separate file for each database).
-- API structure
The Moqui API is clearly separate into interfaces and implementations of
those interfaces. Applications only need to worry about the interfaces part
of the Java code and not the underlying implementation.
All tools in the Moqui framework are available through the ExecutionContext
object, which is created and attached to a thread for each web request,
remotely called service, etc. It keeps the current context for whatever is
running and has a series of facades for each tool in the framework, including
for sevices, entities, screens, localization, logging, caching, user info
and preferences, and so on. Some of the implementations of these interfaces
will be reusable from one thread to another, and others will be created for
each thread.
The API is designed to take advantage of some of the syntax short cuts in
Groovy such as using the dot syntax to start with the Moqui static object and
get down to whatever part of the API you need.
-- Configuration and code layout
In Moqui the framework is one big happy set of tools that works together.
There is no attempt to separate the tools or make them useful on their own.
That was goal at first with OFBiz, but never really worked out very well and
splitting the framework into components caused more difficulty than it helped
things. So, in Moqui it's all one big framework, and one that can be easily
compiled and deployed and so on. The basic idea is that the framework jar
files (api and implementation) on the classpath plus the locaiton of the
runtime directory are all you need to get started. Components can be loaded
through an API or configuration.
Configuration files are meant to come from a runtime directory and are not
spread around the code. There is a default-conf directory in the framework
so that if a configuration file is left out the framework will have a default
to fallback on that will work in most cases.
While Moqui supports multiple webapps, the normal deployment mode will be as
a single big webapp with screen trees from add on components mounted on a
certain path within the big webapp.
-- Content management
Instead of a set of entities and services for content management that are
part of the project Moqui uses the JCR 2.0 interfaces (and by default the
Apache Jackrabbit implementation) for content management. Anywhere there is
a "location" in the API or XML files it can have a prefix of "content://" to
access something from the JCR. This means that code and templates and such
can go there as well.
-- Security: authorization
Moqui uses a set of entities to define user groups, artifact groups, and
permissions for a group of users on a group of artifacts. These are external
settings and support record level permissions too. With this approach there
is no need make the artifacts responsible for permission checking, and no
code changes are required to change permissions when customizing or
maintaining or supporting an application.
There is a tarpit concept in OFBiz that uses the same model as the
permissions for reduced redundancy and more features.
-- I18n and L10n
Internationalization is implicit everywhere in Moqui using natural text in
the default language for a key instead of an artificial identifier. This
reduces redundancy and effort. The localized labels are in a database table
instead of an XML file to perform better (only lookup and cache labels that
are used) and to support per-tenant localizations in a multi-tenant
environment.
