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 >>>> >>>>
