David, thanks a lot for that background information - I am still somewhat new to OfBiz and for me this is great help for understanding.
Personally I wouldn't bet on EARs or anything else very specific, as it is not clear wheter the whole industry - or the Java parts of it at least - will really buy into it. All Java EE servers have their own extensibility mechanism and unless you have one very monolithic application you will have to implement vendor-specific interfaces / declarations / packaging. OSGi looks like it's going to get quite far in terms of defining some lowest common denominator of a standardized module runtime system - but then who knows really? So, that said, there's no disagreement w.r.t. what you decided to do about OfBiz's infrastructure. In most instances (I think) the best approach is to make sure whatever you implement can (in principle - say w/o deep code changes) be integrated as a library, e.g. like you can embed Jetty in your otherwise completely regular Java app. So that the environment specific adaptation (e.g. classpath metadata and service registration in OSGi) can all be put into an adapter. For example, I think there should be nothing wrong with using OfBiz in a Desktop app. From what I can tell from experimenting around OfBiz is not far from there. Thanks, henning Am Sonntag, den 05.07.2009, 15:25 -0600 schrieb David E Jones: > 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 >
