+1 2012/3/15 Tom Burns <tramseybu...@yahoo.com>
> Adrian / Jacopo > > While thinking about a refactoring the OFBiz Architecture you > may want to look at http://www.aosabook.org/en/intro.html. The book is all > about Open Source architecture. In particular see the chapter on Eclipse, > the > ultimate open source component framework, Eclipse is the perfect > environment to > implement Adrian's ambitious vision. > > However the most pressing problem in OFBiz, given the > available resources, is not the architecture, rearranging the components > or refactoring > of what in Moque would be the Core / Mantel (i.e. a scripting framework > etc.). > > Rather the problem, as your most recent post to this thread > suggest, is the short comings in the OFBiz Crust. OOB the user facing > applications are difficult to understand, quirky and do not support needed > business > requirements. Just ask yourself would you go into a meeting with Steve > Jobs ghost > with these applications? > > On the OFBiz home page "What is Apache OFBiz" the > focus is clearly ERP. The bullet points advertise OOB application > functionality. The business applications should be easy to use, robust, > and well > documented. This will require more attention to business requirements, > providing a consistent set of defined services, adherence to documented UI > best > practices and well written and better presented user help. > > All of this is possible without doing more additional work > on the Core / Mantel. > > I would be happy to contribute to an effort to improve the > user facing applications if there is support from the committers. > > I see these applications as falling into two categories. Applications > that are common to most businesses and domain specific applications. This > follows the pattern laid out in the two DMR Books. The former, more > general, > category should get the most attention. Those applications include: > Common Business - Requirements common to most businesses > Accounting > Human Resources > Marketing > Work Effort > Reporting > Document Management > E-Commerce > Others to be > identified > I would like to start with Human Resources. Is anyone interested? > > Tom > > > > ________________________________ > From: Pierre Smits <pierre.sm...@gmail.com> > To: dev@ofbiz.apache.org > Sent: Wednesday, March 14, 2012 5:53 PM > Subject: Re: Rethinking the structure of the OFBiz Applications Components > > Hi Adrian, > > Could you list the applications you comment out in your production > implementations? I think that would help creating insight. > > Regards, > > Pierre > > Op 14 maart 2012 18:33 schreef Adrian Crum < > adrian.c...@sandglass-software.com> het volgende: > > > Understood. > > > > As a service provider, I regularly comment out unused applications and > > build hot-deploy components to replace OOTB OFBiz components. I override > > service definitions, redefine entity definitions, etc - all in an effort > to > > take what's good in OFBiz, and replace what's not-so-good. I seem to be > > doing a lot more of it lately - mostly due to components being added that > > break every other component. At least with a component approach, that > sort > > of thing can be isolated and dealt with. > > > > -Adrian > > > > > > On 3/14/2012 5:22 PM, Jacopo Cappellato wrote: > > > >> Thank you Adrian. > >> > >> Just to clarify that I was not talking about the architecture of the > >> framework (topic for another day) but only for the layout of the > >> applications and it is not based on what I think it is best in general > but > >> instead about what I think it is best to represent what we have right > now: > >> what we have right now is *one* big application (made of mostly all the > >> components under the "applications" folder) that is split into chunks > (the > >> components) where each chunk is not built to be used alone. > >> I would be really interested to know from the users of the > "applications" > >> how many of them are removing (or not deploying) the components they do > not > >> need in their business. > >> > >> All in all I am trying to better represent (in a more convenient, > >> cheaper, easier to maintain way) what we already have, not to suggest > how > >> the perfect application built on OFBiz should be. The approach that you > are > >> suggesting on the other hand, that is inspiring, implies a complete > >> refactoring and redesign (also in terms of features) of the > applications. > >> > >> Jacopo > >> > >> On Mar 14, 2012, at 6:09 PM, Adrian Crum wrote: > >> > >> That approach sounds very monolithic, and I tend to avoid monoliths. > >>> > >>> I gave this subject a lot of thought about a year ago when I was > working > >>> on a vision for a new framework (https://cwiki.apache.org/** > >>> confluence/display/OFBADMIN/**Another+Framework+Vision< > https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision > >). > >>> In particular, I was trying to devise a way for us to build a new > >>> architecture for OFBiz out of well-defined and self-contained parts - > with > >>> the ultimate goal of using OSGI to connect them all together. > >>> > >>> That goal led to only one pattern that seemed to work: Hub-and-spoke. > >>> Hubs can be suspended, replaced, and restarted without too much > disruption > >>> because they affect only the spokes connected to them. > >>> > >>> It sounds like what you're proposing is a layered pattern - like a wall > >>> built up of many bricks, but with an all-covering capstone on top. > >>> > >>> I don't have a strong opinion on which approach is best, but I tend to > >>> favor modularity. > >>> > >>> The discussion is worthwhile, and I appreciate you starting it. > >>> > >>> -Adrian > >>> > >>> On 3/14/2012 2:37 PM, Jacopo Cappellato wrote: > >>> > >>>> In the eraly days of the project, the OFBiz applications have been > >>>> designed as independent components to make them more reusable and > because > >>>> they were designed to be a set of reusable and generic artifacts, > each of > >>>> them based on a specific domain of the data model (order, party, > product > >>>> etc...). > >>>> They were not intended to be ready to be used out of the box; they > were > >>>> not intended to implement complete ERP workflows (mostly all complete > real > >>>> World workflows encompass several domains) but rather to provide some > >>>> common artifacts (screens, forms, basic business rules) to facilitate > the > >>>> implementation of custom applications. > >>>> However over the years, they have been implemented to be used as being > >>>> part of the same big suite of ERP applications: i.e. the building > blocks of > >>>> a specific instance of an ERP system. > >>>> Some (parts) of them have become "ready to be used" out of the box > (for > >>>> certain specific business models) by implementing more specific > workflows > >>>> (based on some real World requirements coming from companies): > because of > >>>> the fact that there was not a central design and coordination (which > >>>> industry/business to implement etc...) and because for the same task > >>>> (shipping, receiving etc...) there are thousands of different valid > >>>> worflows we have now several workflows in OFBiz that implement similar > >>>> features but in different alternative ways. > >>>> It is off topic here to say if this is good (the company user can > >>>> choose between a series of choices based on the nature of its > business and > >>>> then customize/clean/complete them) or bad (a lot of duplicated code, > the > >>>> applications seem to deal with everything but they are not really > really > >>>> good for anything): however it is a reality that the applications are > now > >>>> more a suite of ERP application (one application) rather than reusable > >>>> generic artifacts that can be plugged together. > >>>> In fact the OFBiz Applications are now a set of OFBiz components that > >>>> are strictly interdependent at several layers (data model, service, > ui). > >>>> > >>>> In their current status I believe that it would be better to merge > them > >>>> into one big component, the "Apache OFBiz ERP" (or a better name). > >>>> The component will contain: > >>>> * the complete data model for the OFBiz application > >>>> * all the services (Java, Minilang) > >>>> * all data > >>>> * one web application (merged from the existing ones); even if > >>>> initially we could do this in steps and keep them separated as they > are now > >>>> but under the same component > >>>> * one aggregated and consolidated set of ui labels > >>>> > >>>> Even in one component we will have several mechanisms to categorize > our > >>>> artifacts (file names, folders) even if I would suggest to rethink > them > >>>> based on new rules (and only if we need the categorization). > >>>> We could merge a lot of files (data preparation scripts, screen > >>>> definitions, service definitions etc...) to make them more > consistent. We > >>>> would also resolve some of the issues with inter-application links and > >>>> navigation. > >>>> I am pretty sure that we could end up with less code and easier to > >>>> organize and maintain. > >>>> > >>>> It will also be more practical to reuse this component and extend it > >>>> from an external hot deploy component: you will have to extend one > webapp > >>>> and then reuse from the official component what you like. > >>>> > >>>> This is just the rough ideas and there could be some variants to it: > we > >>>> could isolate all the data model and services into one component and > all > >>>> the applications (ui, screens, controllers, data prep scripts and > >>>> templates) into another one. etc. etc. etc... > >>>> > >>>> It is a lot of work but we are a big community and we like to keep us > >>>> busy. > >>>> > >>>> What do you think? > >>>> > >>>> Jacopo > >>>> > >>>> > -- I am hongs
