Hi,
At this time, applications components embedded functional framework and
business oriented (massively B2C) and aren't user friendly.
I possible solution will be have a dedicate application components for
only Consultant or high level user that contains only the functional
framework (with business process cleaned) and for end user an oriented
business components
Exemple :
application /
content
humanres
manufacturing
marketing
order
party
product
workeffort
specialpurpose :
cms
edm
ecommerce
order-b2b
crm-b2b
...
The business components contains (in a beautiful world) only business
service process and simplified screen.
We work with Apache OFBiz on hight parameter ERP with dynamic (by
jquery through screen engine) reusable screen based on portlet and
portal page. Own idea is, the application components give a portlets
list that business components use to configure their portal page.
I'm not a modularity fan. For the technical framework, is great but I'm
much more mixed to use on functional framework. Integration problem will
not resolve easily.
Nicolas
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.
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
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
