Some thoughts inline...
> On 24 Oct 2015, at 07:59, Sharan-F <[email protected]> wrote: > > *What do we want to Achieve?* > We had previously reviewed Adrian’s documentation Initial Framework Vision > Document > <https://cwiki.apache.org/confluence/display/OFBIZ/Another+Framework+Vision> > and Initial Framework Design Document > <https://cwiki.apache.org/confluence/display/OFBIZ/A+New+Application+Framework+Design> > > , and agreed during the meeting that this would be a good starting base for > us. In this proposed subproject we would like to implement a framework that > would initially comprise as follows: > > • Configuration. > • Globalization (locale, time zone, currency). > • Logging. > • Security (authentication/authorization). > • Actor Management (profiles, roles - required for security; Actors - > people, external services) Think of UML Actor. Required to remove dependency > on Party Is this just the user concept, or something bigger? In a framework, IMO, there is no need for the “Party” concept, but the user concept for authc/authz is critical. Some side notes: Apache Shiro may be very useful in OFBiz for authentication and generic authorization, and I’d highly recommend looking at the artifact-aware authorization concept in Moqui for inheritable authz specific to screens, services, entities, etc. It is hugely useful for have this configurable external to the screens, services, etc themselves… much more flexible and simplifies code. > • Persistence (file system or database). This seems a little broad, files are very different in nature from database records (assume relational DB referred to here, like the Entity Engine). A file/resource interface can be backed by a filesystem, content repository, or even database tables that mimic the structure of a filesystem with DB records. For example see the ResourceFacade and ResourceReference in Moqui: http://www.moqui.org/javadoc/org/moqui/context/ResourceFacade.html http://www.moqui.org/javadoc/org/moqui/context/ResourceReference.html Because a relational database is used so much a special interface to it is well worth the effort (like the Entity Engine). There are interfaces for this in Moqui, but no need to reference them here as the generic concept is the same (even if the API and design is very different). One thing I would recommend for the new API is a find object instead of all the find methods on the delegator, ie something like: http://www.moqui.org/javadoc/org/moqui/entity/EntityFind.html It might be interesting to look at a generic interface for NoSQL databases like document, graph, etc DBs. However, the APIs for these are far less consistent than for relational databases so it is very difficult (impossible?) to design a generally useful interface, ends up being the least common denominator of the various underlying DBs. > • Lang package to provide classes that are fundamental to the framework This is an area where OFBiz has a lot of room for improvement, and by improvement I mean getting rid of dozens of utility classes and using existing open source libraries instead. > • Services. > • Runtime management What does Runtime management mean? There are some key things missing for an adequate framework to replace the one in OFBiz, including: - User Interface How will screens and forms be implemented? How are they mapped to web requests? There is a lot of room for improvement in OFBiz here. Having to use a bunch of files and such for a single screen is a pain (controller request and view, screen, form, menu, tree, etc… often have 3-4 files open when working on a single screen). There is also no concept of a screen hierarchy (which is very useful) in OFBiz, just a flat list of supported requests. - Integration (and non-UI web) This might start with using something like Apache Camel, but also needs framework support for handling incoming integration web requests that may tie to entity or service operations, etc. - Caching Even if this is backed by something like Ehcache it may be nice to have a framework interface for using and managing caches. - Transaction Management Transactions are useful for more than just DB operations, but even with just DB stuff it is useful to make it easier to handle things like synchronizations to do stuff on commit or rollback. While sometimes useful in application code it is very useful for other tools (in Moqui this includes data feeds generated based on entity data changes, the write-through per-transaction cache, etc). - Messages and Notifications It is helpful to have a central place to handle messages (error and otherwise) that get passed up through the various levels of the framework, and to determine if something deeper down generated an error without using exceptions (which don’t fit the service model for logic very well, especially not remote services). Notifications are handy for pushing data to users or other applications, eventually through something like web sockets or other interfaces. Another note is the original list is more conceptual than something that should be used to organize an API… for various reasons structuring an API this way would result in some weird structures. I’ll finish with the most important point, IMO, for any framework design: a convenient single interface for the entire framework. This makes lifecycle management and API use so much easier, plus provides a single variable space (context) for all tools that is consistently available. This interface in Moqui is the ExecutionContext (always available in screens, services, scripts, etc as simple “ec”): http://www.moqui.org/javadoc/org/moqui/context/ExecutionContext.html To go along with that for management a primary factory is useful, for Moqui this is the ExecutionContextFactory: http://www.moqui.org/javadoc/org/moqui/context/ExecutionContextFactory.html If you want static initialization you can use the Java ServiceLoader, such as in: https://github.com/moqui/moqui/blob/master/framework/src/api/java/org/moqui/Moqui.java And a META-INF/services file like: https://github.com/moqui/moqui/blob/master/framework/src/main/resources/META-INF/services/org.moqui.context.ExecutionContextFactory -David
