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