comments are in-line
Le 14/03/2012 19:34, Jacopo Cappellato a écrit :
On Mar 14, 2012, at 6:33 PM, Adrian Crum wrote:
Understood.
As a service provider, I regularly comment out unused applications
I would be interested to know what are the applications under the
"applications" folder that you comment out: do you you mean web applications,
not component
and build hot-deploy components to replace OOTB OFBiz components.
we (the company I work for) do the same extensively
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
we do the same; to take the good and also to add custom features not well
suited for the general purpose applications
. I seem to be doing a lot more of it lately
This is the approach we follow since a long time and it has proven to be
effective.
- mostly due to components being added that break every other component.
this is another sad topic :-)
Continuous Integration with functional test is the only solution ;-)
At least with a component approach, that sort of thing can be isolated and
dealt with.
I don't see how the tasks mentioned above are easier with the applications
split into components.
for a business analyst point of view, it's easier to define the
component boundaries and functional tests for one component than for a
full application, so easier to define a Continuous-Integration Job to
check if it's always ok.
For developer it's easier to make correction in a well defined domain,
not too large.
Jacopo
-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).
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
