THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access
Overview
Content Tools
Apps
5 Comments
Jacopo Cappellato
Thank you Sharan for creating this diagram, it is very helpful.
I agree with the overall architecture, in my opinion it is the right way to go.
We may discuss about how to name each layer/component but for now what you did is just fine.
I would like to add that as a second step we could move some business logic (services) that are very specific and bound to the presentation layer from the "kernel" to the relevant application: in this way the kernel will only contain a clean API (services) and a clean data model.
Also, on the architecture side (but this is probably slightly off topic) I think we should really move from one webapp (or more) for each application to just one webapp for all the applications: this unique web app will have just one ControlServlet that will read at startup all the controller.xml files from all the applications. Having a centralized web app will make it easier to deploy ofbiz in external servlet containers/application servlets and will make it easier to simplify our bootstrap classes (e.g. moving from custom Containers to Servlet based containers that are started by the application server e.g. tomcat)
Jacques Le Roux
I have really to think more about it. I'm a bit reluctant to do so, at least for now. First thing which comes to my mind is cloned web-apps. AFAIK we can have only 1 web-app by web.xml file. I just read that Resin has a special setting for that, but it's not standard
Pierre Smits
This diagram conveniently foregoes in both 'Current Application Structure' and 'Future Application Structure' the existence and work done in components as assetmaint, bi/birt, cmssite, ecommerce, hhfacility, ldap, lucene, myportal, pos, projectmgr, scrum, webpos.
Apart from that, several components currently harbour multiple webapps (applications). See following list:
We should investigate whether splitting up any of these components into multiple single focus components/applications would increase awareness of functionality and adoption. For instance, splitting up the product component into one for product and catalog mgt (incl. store, pricing and promorules) and one for warehousing and inventory mgt.
Also, in component Accounting a lot functionality regarding 3rd party payment service providers are integrated. These should be separated from the core accounting data and services model, so that adopters can implement their preferred solution (Authorize.Net, WorldPay, etc).
The same also applies to the functionality regarding 3rd party shipment service providers integrated in the facility app of the product component (DHL, UPS, etc).
Jacopo Cappellato
One small clarification to my proposal to unify the web applications: I am not saying that each component should be limited to declare one "application" only.
However the difference will be that all these "applications" will actually be a set of screens of one big "web application".
If you think about it, this is exactly what we are trying to et out of OFBiz: all backend web applications share the same decorators header/foooter, same login screen, etc... the current architecture is making this more difficult than it should.
With the refactoring I am talking on the ecommerce component will declare its own web app (as it is now) but all the other backend applications (probably with some exceptions) will be part of the same web-app.
Ron Wheeler
If we are looking at restructuring OFBiz, it might be a good idea to separate the services layer from the presentation layer.
This would allow client-side (Javascript, AngularJS, Eclipse, etc) applications to be developed that accessed the OFBiz services through REST or the next generation of service delivery interfaces.
It would also allow the team to be thought of as more specialized groups with expertise in business services, UI design, data modeling, etc.. This would allow us to increase the number of committers and grow the community faster.
It would also likely facilitate the branding and customization since a lot of this (not all) would shift to the UI and to customizing selected parts of the services layer.
Jacopo's idea of a dispatcher that configures itself at run-time sounds good.
It would be nice if it understands the interdependencies between modules.
It could then detect misconfigurations where module A provides services A1, A2 and A3 and depends on services B1 and B2 provided by component B.
Versioning of services and dependencies would be a helpful addition. Module A requires at least version 14.12.1 of B1 and either version 14.12.1 or 13.07.3 of B2.