My thinking about Actor is below:
Ron
On 29/10/2015 7:31 PM, David E. Jones wrote:
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.
I am thinking that every application requires Actors.
Party is one kind of actor.
A user is an Actor.
A gayment gateway, an external SaaS application and an e-mail server are
also actors.
Actors have profiles and roles.
Profiles include all kinds of object from photos to birthdays to port
number to URLs.
If the framework offered Actors that supported profiles, this would
eliminate a lot of coding.
I am not just thinking of the framework as the base of OFBIZ ERP but
also as a general framework.
Think of the UML Actor. Actors appear in every Use Case.
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
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
