Thanks for writing more about this Henning (and you too Marc in your
reply). This goes back to what has been one of the toughest parts of
OFBiz from day 1: the infrastructure to build it on.
I'll admit I had only been using more "standard" J2EE stuff for only a
couple of years before deciding to diverge from it. The lower level
stuff is mostly fine (though it would be nice if JDBC implementations,
aka drivers, where more consistent), but once you get above things
like JDBC, JTA, Servlets, etc things get pretty messy (and ugly IMO)
in the Java standards world. I guess fortunately they did split out
these lower level standards and build the higher ones on top of them
so that we can at least use them directly when the higher level ones
don't fit the bill.
The OFBiz component stuff was based on the concept of EAR files, but
created because EAR files leave a lot to be desired. If there was a
way to extend EAR files with some sort of plugin they might do the
job, but as-is even app servers (inconsistently) feel the need to
create extensions to it in order to get just the basic job done. The
ofbiz-component.xsd file describes just what we want to configure in
OFBiz for each component, though it is important to note that this
changes over time as we add new things, and in general it's nice to be
able to "plug-in" things since that's the only way to really make
components independent and create generic tools that reduce
dependencies between the components, at least on the configuration
side of things. Of course, the OFBiz component stuff doesn't have a
plugin mechanism either... we just take the easy way out of changing
it when the need arises (usually when something very new is added to
the framework).
Back to multi-tenancy: if there was a good standard (even if not
implemented yet) that we could use for it that would be great, but I'm
not sure that such a thing exists, or at least not in a form that
would be helpful. There certainly are things to facilitate running
multiple instances on a single server, even machine and OS level
virtualization, but those are inefficient and don't scale the way I
think people are talking about (ie thousands of lightly used instances
on a single server or pool of servers acting as one). So, my guess is
that we'll have to do something custom for this.
Anyway, something custom may make the most sense. With the entity
engine we could build something (like Marc, Harmeet, and others at
Emforium have done), and I like the idea of doing it so the user
interaction is like what the big ones do, ie determine your instance
by user, and that should be quite doable with a few variations (like
putting UserLogin and certain other entities in a separate database
(with their own entity-group)).
Some newer features should help with this too, like the "configurable
screen" (aka "portal") stuff, and the proposed security changes to
externalize permissions from implementation artifacts.
-David
On Jul 2, 2009, at 5:28 AM, Henning wrote:
Hi Experts,
I would like to embed OfBiz with a module environment (not OSGi - but
sufficiently similar to think OSGi if that helps) and for multiple
tenants on one VM. The latter is the the stronger requirement for me.
But as far as modularization is concerned, Ofbiz seems to be in good
shape: The individual logical projects (under framework and
applications) that are all packaged up as one Eclipse project can be
broken up into smaller projects that have a beautiful and meaningful
dependency chain and still compile (at least). Executing them is
probably another story.
Now in terms of multi-tenant usage, I would love to be able to run
different "instances" of OfBiz within the same server. So every tenant
would get its own OfBiz configuration (including its own data source
configuration). OfBiz features would actually be something additional,
integrated with another application and OfBiz would not be the leading
infastructure.
I remember having seen some similar discussions on the mailing list
some time ago - they all seemed to go nowhere. To me it seems that
using
OfBiz as the fundamental functional underpinning and toolbox for
anything eCommerce is a very natural path to follow, but it should not
have unbreakable ties to exactly one underlying infrastructure. I
understand that OfBiz has spent some effort into creating its own
module
system (kind of) - that's perfectly fine and seeing OfBiz run
out-of-the-box after 5min. is perfect. However, other places, other
infrastructures.
Anyway, if anybody has a pointer to something that is similar to what
I described above or some success story, it would be great, if you
could
let me know. Of course, if there is good reasons why this cannot work
w/o touching OfBiz in an unknown but huge number of places that would
also be valuable information.
If I end up getting it done myself and if there is interest, I will
be
happy to share my experience.
Thanks,
Henning
