Re: Rethinking the structure of the OFBiz Applications Components (4)

[Olivier Heintz <ho...@nereide.biz>]

comments are in-line

Le 14/03/2012 23:04, Tom Burns a écrit :
> 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.
For user interface, it's necessary to be modular and configurable. In 
OFBiz, portlet and portalPage seems to be a good answer (even if it's 
necessary to enhance some mechanisms).
We (the company I work for) have enhance portlet management and migrate 
some OFBiz screens to portlets (~30%) and use it on multiple customer 
projects. These customers all seems to have a good feeling with this 
"new" user interface.
I am currently finishing the functional and code review on portlet 
management enhancement to be able to propose it to OFBiz Community. I 
hope to propose first mail and Jira next week.
When these enhancements will be correct to be integrated in OFBiz. I 
will be able to propose portlets (which are coming from screen migration).

I hope it will be an important step in a user facing interface improvement.

Next step will be to migrate all screens which are necessary to migrate. ;-)
>
>   
> 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<pi...@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.crum@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
>>>>>
>>>>>