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