Overview
Applications need to have a way to manage Actors.
- Actors can be people or organizations that are exposed to the end-user of the application.
- Actors could also be external systems such as mail servers, payment gateways, EDI networks or anything for which the application developer needs to maintain a profile/configuration at run-time or permanaently
Actor Management provides the core of the Party component and removes the current problem wherein the framework depends on the Party Component.
It is also required to implement the Security Framework.
Features:
- Profile management
- CRUD of Actors and Profiles
- Actors can have a profile
- Allows Objects to be associated with a profile - any org.apache.ofbiz.foundation.lang object including images and other files.
- Actos can be assigned mutiple roles
- Search by property name and value or existence.
- Collection operations - sort
- Role management
- CRUD for roles. Could be in Security but Security Roles are a subset of all Roles - Mailer Role, Payment Gateway role would not fit in Security,
- Role assignment
- Search by role
Design Goals
- Single configuration file - located anywhere on the class path.
- Extensible to support Party component
- Thread-safe.
Basic Architecture
- Library: OFBiz
- Java package name: org.apache.ofbiz.foundation.actorManagement
Use cases
Adding an object to a user profile.
Actor Managememt should support adding objects to the profile
- Dates
- Strings
- Files
- Images
- etc.
Objects have names
Objects should be typed. It seems that the Standard Media Types would be a good way to identify Object types.
Adding a payment gateway as an actor
It should be possible to use Actors to describe external systems by adding named configuration entries such as
- URLs,
- credentials,
- parameters
If the application developer wanted to, they could assign the "Payment Gateway" role to the Actor to use to help organize and find configured gateways by looking for actors that have the "Payment Gateway" role.
Interface
ActorFactory get a new actor - possible some simple constructors that allow an actor to be created with a bunch of attached objects of the same type. Create a payment Gateway called "myGateway" with a URL, a username, a password, a display label.
Add a single object to an actor.
Add objects to an Actor - list of pbjects of the same type
Assign roles to an actor - single role, list of named roles.
Collection operations:
Find the actors that have properties matching a parameter
4 Comments
Adrian Crum
Ron, it sounds like you are describing a security principal. Security principal management is handled by the security module. I do not agree that a security principal is a party or that a party is a security principal. They may be related under certain circumstances, but they are not the same thing.
Ron Wheeler
Agreed.
Some Actors might be Security Principles but others are not.
All applications need actors - think of the actor in a UML model. Hard to imagine a Use Case without some Actors that represent things outside the system.
I am suggesting that if we have to move some of Party into the framework, we could provide developers with a general "Actor" object that could be extended to the kinds of things for which Party is used .
It could also be used as the basis for things like Payment Gateways, e-mail servers, etc. that require profiles and are identified with roles (eCommerce Gateway, Mail Service).
I chose the word "Actor" to avoid confusion with "Party" which has an existing meaning within OFBiz and to indicate that Actor has a much wider use than just as a security principal or OFBiz "Party".
I see OFBiz Parties being implemented on top of Actors in the Party Component.
Other applications, would have other higher level objects that would be easier to implement if Actors had a flexible API.
Being able to call a factory and get an Actor that could store a profile and be assigned roles would save a lot of coding.
If the Configuration module could take a configuration type and return fully configured "Actors" that would save a lot of tricky coding for a new application.
I don't know what the Configuration component will do but I would hope that it could be called with a "type" of object - say "Mail Server" or "Payment Gateway" and it would return a set of actors representing all of the configured mail servers or payment gateways with their configururations set up in the profile of each actor. "Bank Accounts", Wire Transfer systems", "EDI gateways", "Payment Processors" " Tax Collectors" are things that can have different properties within the same system and so lend themselves to using the "Profile" to hold the properties. The Configuration component does not care if different payment gateways have different properties - it just loads up the Actors with the specified configuration properties and leaves it up to the payment processing system to sort out how to handle each different type of Gateway.
Even if OFBiz takes years to fully embrace this new framework, I thik that the new framework as you describe it could be a valuable "product" for people looking for an application development framework in a much shorter timeframe.
Adrian Crum
The configuration component consolidates the various configuration files that exist now but are scattered everywhere. It is not an "actor factory."
Third-party libraries or APIs that require security principals can be accommodated by higher level code. The framework cannot know about those things, and trying to accommodate them at this low level will result in obtuse code and an overly complicated API. Keep in mind Bloch's video - an API is:
2. Appropriate for the audience
3. Does one thing, and does it well
4. As small as possible, but no smaller
Ron Wheeler
I have not yet had a chace to look at the configuration component and was expressing some ideas about how to make the simplest API from the developer point of view.
I agree that this level should not try to do anything that is related to business logic but it can make things a lot easier for developers by providing functions that eliminate boilerplate code.
Getting a fully configured actor or set of actors out of the Comfiguration component could save a lot of duplicate code in each application building custom actors from information derived from the Configuration component.
I understood that one of Bloch's suggestions about API design was to avoid making the business level do boilerplate operations such as taking configuration properties and making Actors (custom) from the configuration. Many lines of application code could be eliminated if we hand back a configured Actor.
Even if the Configuration Component can't tell the difference between the function of a mail server and a payment gateway, it can build either Actor from the properties that it finds in the configuration. It just needs to know which type of Actor you want and if you now the name, which one you need.
This has an impact on how the configuration component is fed configurations and that may affect legacy applications but there does need to be a structure in configurations to define opjects and lists of objects with named properties. I am assuming that the configurations are hierarchical in naturesuch as:
I am not sure if this makes the Configuration component much more complex - it only adds two methods to the API.
The methods are pretty simple once the Configuration Component has located the MailServers object.
The Actor is very simple as an API.
It should have a factory to make them- this might have a few convenience methods but the basic function returns an unconfigured actor.
The Actor has property getters and setters where the properties can be a variety of different Object types. This can start with only a small set of types supported and can be extended as required.
Probably want some support for Compare to allow them to participate in collections.