+1 for the idea for having services at top and then use them whenever required, the only thing comes in my mind (also mentioned by Paul in the thread) what to do with the cross component services. Also once the services moved then how to customize them as per requirements. But we can finalize the things as we move.
We can go slowly and move the items in following sequence to be on safer side (better advise from community most welcome); 1) Entity Auto Services and service interfaces (with dependency check) 2) Other Crud Services 3) Other services in order of component-load In most cases we don't have to worry about the order of services load, but it would be good to follow some practice to work independently for components. The best thing I can see here, once we have everything comes out as Map we can use any UI technology to work with OFBiz and can have our own UI independent on OFBiz other components. So again big +1. I would like to help/work on this effort, LMK. Thanks! Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Mon, Mar 5, 2018 at 10:57 AM, Taher Alkhateeb <[email protected] > wrote: > Hi Paul, Good points and questions. Inline ... > > On Mar 5, 2018 2:36 AM, "Paul Foxworthy" <[email protected]> wrote: > > On 5 March 2018 at 00:45, Taher Alkhateeb <[email protected]> > wrote: > > > > I think If you look at both the "data model" and "services" in OFBiz > > you will notice the following: > > > > - They are highly coupled and everything is connected to everything > > (orders, parties, work efforts, contents, etc ...) > > - Some services and entity models are component-specific and do not > > belong to the generic data models and services. > > > > So what does that mean? It means in order to achieve real flexibility > > and a clean architecture, perhaps we need to separate our data model > > and services from the rest of the components in the system, and we > > already did this with the datamodel component. > > > > So I propose creating a new component, perhaps calling it > > "service-library" that houses all "generic" services that operate on > > the "generic" data model. I propose we implement this new component as > > follows: > > > > - Slowly move services (one at a time) from components to this central > > library, cleaning and refactoring as we move. > > - Migrate any minilang services to another engine while moving > > (groovy, entityauto, etc ...) > > - Keep any services that are component-specific and do not operate on > > the generic data model in the component > > > > What do you think? Do you agree with the general idea? Can we do this > > in a better way? Anyone interested in helping out? > > > > Hi Taher, > > It is the nature of a business process to cross many functional areas. To > fulfil an order, we might need to commission manufacturing involving people > and equipment, order from suppliers, manage inventory, schedule shipments > and create accounting records. > > What proportion of services do you think would turn out to be generic? > > Perhaps most of them. What I mean by generic is that they act on the > datamodel or apply wide scoped logic. > In other words, any service that does not need to exist if you delete a > component would be tightly coupled to that component and should probably > stay there. > > > Any OFBiz implementor can add SECAs which cross component boundaries, when > the original design of a service did not anticipate that. Do we still want > to allow that? If so, the split between "generic" and "component-specific" > is only approximate, and adding SECAs will blur the distinction. > > I think perhaps most SECAs could move too. After all SECAs are just forming > a call graph indirectly. And if you call any service from any component the > SECAs would always apply no? > > > If most services move to be generic, there will be one component with many > tightly-coupled services, and we'll have lost some partitioning and > organisation. So will we have gained anything? > Could we think of services as being partitioned into components only for > the purpose of rough categorisation and human understanding, and for no > technical or communication reason? > > Well, just like in the data model component, we can have directories to > split the services by category. > > > If a component-specific service is modified to be slightly more complex or > general, so it now interacts with generic services or services in other > components, does that mean it should move to be generic? As we extend OFBiz > to be more capable, would there be a drift of services from one component > to generic? > > Hmmm, perhaps as I mentioned earlier, I think only a tiny minority of > services would remain (if any) just like in the data model. For example we > only keep data related to portals and security permissions in components > because they are tightly coupled to the user interface and should not exist > if the component is gone. The rest is all in the data model. A similar > thing could apply to services too. > > > Would a better approach be to reduce the number of entry points between > components, to better manage and understand the critical services that are > called by other components? In other words, is there the possibility of > encapsulation, so many simpler services are only used within one component, > while others are larger in scope? To take that a step further, could your > idea of generic services turn out to be big cross-component business > processes, which *only* call into smaller services within several > components, and contain no business logic of their own? > > > Perhaps before I reply to this point let me try to clarify _why_ am I > proposing what I propose. > Imagine you wanted to create a better accounting component, or imagine you > create a cross-functional component that is a full application and you > called it "OFBiz retail app" that covers functionality across many entities > (orders, GL, party, inventory, etc...). > > Under my proposal, these new components will not depend on any other > components. They will only depend on the data model and service library. So > the pain point of this very complex wiring between components will be > significantly reduced. > > So under this proposal OFBiz will be a more layered architecture where the > lower layers are isolated from higher layers as follow: > > - framework for low level infrastructure > - data model and service library > - applications > - plugins > > I am hoping that perhaps creating the service library would be the first > step towards refactoring the core applications. We would be able if we want > to reconsider the design of how we split apps (party, work effort, content, > etc..). Perhaps in the future we can separate apps by business, not data > model e.g. Service company app, retail company app, ecommerce app, > manufacturing company app, and so on. > > > TIA > > Paul Foxworthy > > -- > Coherent Software Australia Pty Ltd > PO Box 2773 > Cheltenham Vic 3192 > Australia > > Phone: +61 3 9585 6788 > Web: http://www.coherentsoftware.com.au/ > Email: [email protected] >
