CORE OF THE PROGRAM
This package contains the fresh object-oriented database management system for Access Road; this package documentation page is recommended as a first reading for all the Access Road developers. This page contains an overview of the design principles, the functions, the design patterns and the architecture of the Access Road software. The second recommended reading is the package documentation page of ARoad0.gWork, where the design of the access path searching is described. This page describes also the general principles this package applies to provide a mature, fast and extensible in-memory database management system.
All the object-oriented database management system for Access Road is into this gBase package, and this is its unique responsibility. In Access Road, the modelling of the access controls of a given software is provided by one or several Access Control Systems (ACS) and its inner components. One ACS is suffisant in most of the cases. The ACS are modelled in this package by the ACSImpl class, which may be subclassed into the ACS addons.
The Access Road user may define the properties of a new ACS through the GUI. If it is a generic, non-addon ACS, it uses directly the ACSFactoryImpl class and its BeanInfo class. An advanced user may creates through the GUI a new ACS from another one, typically by editing some limited properties like the type policies. For the Java developers, it is possible to configure extensively a new ACS, like for the RBAC application in the class gWork.AcsFactory. In all cases, it is recommanded to well understand the class ACSFactoryImpl before the study of the ACS addons. The AcsAddon pattern may provide a complex simulation with a minimal effort, like for Linux Ubuntu and MySQL, when the generic features of this gBase package are not enough. The main principle is to subclass the generic gBase and gWork classes in dedicated packages. It represents the second way to define a new ACS, for the Java developpers only. The last level of coding, of course, is to extend or modify the Java classes of this generic gBase package, and to be then beyond the AcsAddon pattern. The main risk is to impact without control the access paths search into the generic gWork package. This is to reserve to the cases which cannot be managed by the AcsAddon pattern. It is recommanded then to code a new version of Access Road including the new features as generic ones, to allow any AcsAddon to use it in the future.
PRESENTATION OF THE MAIN CLASSES
Before the overview on the design, this section provides a quick look on the main Java classes Access Road handles in the gBase package to simulate a software. An ACS contains a catalog of components, so-called ACSObjects, which are registered into the ACS at their creation. The relation ACS/ACSObject is strong, since the deleting of an ACS deletes all its ACSObjects. The main ACS components, implementing the interface ACSObject, are made with the following classes:
BasicImpl is a subclass of Object which is responsible for modelling the member of a folder (a VirtualFolder or a ViewInBase) in an ACS, and it ensures the handling of Privileges. An ACS does not use pure BasicImpl instances. To let the Privilege capacity to some subclasses, this class does not implement PrivilegeSource and PrivilegeTarget. Nonetheless, it handles fully the privilege rights as source and target, so its subclasses have not to do it. It may be an alias or an alias reference, but not both.
EligiblePartyImpl is a subclass of BasicImpl which is responsible for modelling the simplest rights user for which an ACS grants access or denies access to some targets, by the way of any type of rights. Then, only EligibleParties have effective rights, even if other entities may be the source of access paths to targets, like a VirtualFolder for its members.
GroupIDMemberImpl is a subclass of EligiblePartyImpl which is responsible for modelling the member of a GroupID.
UserIDImpl is a subclass of GroupIDMemberImpl which is responsible for modelling an account in an ACS, as a kind of GroupIDMember that owns some Resources and a primary GroupID. It has Account/Group rights on Resources. It has some current actors, that are programs starting their execution under an UserID.
GroupIDImpl is a subclass of GroupIDMemberImpl which is responsible for modelling a set of GroupIDMembers. It has Account/Group rights on Resources. The relation GroupID/member is weak, since the deleting of the container or the member does not delete the other entity.
ResourceImpl is a subclass of BasicImpl which is responsible for modelling the simplest access target on which an ACS grants an access or denies an access. It is a Target for Account/Group rights, AclEntries and Privileges.
DirectoryImpl is a subclass of ResourceImpl which is responsible for modelling a directory which contains children, as resources and other directories. The relation to the children is strong, since the deleting of the directory produces the deleting of all the direct and indirect children.
ActorImpl is a subclass of ResourceImpl which is also an EligibleParty. It is responsible for modelling an acting entity which may have access to resources, by the way of Account/Group rights, AclEntries, Privileges or Bridges. It may be both a source and a target for the Bridge rights. It may have a current account and a current group, and also secondary groups, and this is true even if the Account/Group rights are not allowed. The Actor may run under an Account/Groups context.
VirtualFolderImpl is a subclass of FolderAbst which is responsible for modelling a folder which contains resources as members. It is a PrivilegeTarget. It may be an alias or an alias reference, but not both. The members may be simple, like Resources or Directories, or it may be EligibleParties as Actors. The relation VirtualFolder/member is weak, since the deleting of the container or the member does not delete the other entity. The ACS sets that the VirtualFolder delivers all its rights to its members, or no right at all. As an alias reference, the VirtualFolder may run under an Account/Groups context. Then, its members may be accessible through the VirtualFolder and a GroupIDMember of this context.
OVERVIEW OF THE DESIGN AND THE TEST STRATEGY
We provide in this section an overview on the Access Road design. Generally speaking, Access Road is based on a solid object-oriented design. The best way to provide great software at the best cost is to concentrate the efforts on clear and structured data, clear and structured patterns, clear and structured documentation, all in layers of different abstraction levels. Like a diamond flashing under the light that goes across it, a great software is transparent to the human understanding because its internal structure is trully coherent. It is just as the diamond atoms are, after the great pressure of the design effort. This requires an iterative structure-driven and abstraction-driven development process. Starting from the true issue, that is to master the code, testing and improving the code is based on a solid ground. SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Robert C. Martin in the early 2000s which stands for five basic principles of object-oriented programming and design. Access Road does apply the SOLID way. This is why the design and the documentation of Access Road represents about 50% of the overall development effort.
Software testing is always mandatory, but the need of testing may be lowered by the best use of structures and abstractions. For instance, if I code a method '2+5', I has to test the result is '7', but if I code 'x+y', I put more abstraction in the code. The first tests may be with a limited set of arguments for x and y. The next iterations will allow to write the code easilly, if I master this 'x+y' abstraction. If I find a bug in the 'x+y' computing for a new couple of argument, it will be the time to debug it. Through this process, abstraction simplifies the understanding of the code, and limits the number of testing cases. This does not mean that hidden bugs are totally avoided, but layered abstraction drives to a natural use of the code where the hidden bugs are rarely met, and more easy to fix. But because we are in the real life, there are also some good conter-exemples. A first conter-exemple is for the type-oriented policy for the ACS. Our choice there is to allow the Access Road user to define extended properties through the GUI, at the creation of an ACS, even if this produces a code rather difficult to validate. With the structure-driven and abstraction-driven development process, it is a good idea to put integrity controls in the code, as method entry controls and consistency controls. Of course, they are based on the semantic of the abstractions. These controls remains generally very stable during the improvement of the software. Last but not least, an abstraction-driven code is smaller, more clear and more dense, simply because there is more smartness in it.
It is not very efficient to test the simplest test cases in programmed tests. The unit testing of a method does not usually check the internal values of the method nor the values of the class properties the method change. This is why the careful reading of the code is the best way to detect the bugs, typically when the developer wants to improve it in an iterative process. Code review is efficient but boring, while improving the code enforces to perform an implicit but careful code review. This is the strength of the agile development. Secondly, with the help of the integrity controls, running tests have to cover the complex cases, and above all, the cases delivered by the higher levels of the layered abstraction. The more efficient way to valid the code is not to apply some unit and integration predefined tests, where the errors by omission are very difficult to see. It is better to monitor the internal data of the implied classes, then to review their values carefully. This approach works even for validating the cases far beyond the current test cases. Well-chosen test cases are fine, but do not hesitate to apply almost random entry data if necessary. This way of testing uses more efficiently the skills of the developer. Again, this is why it is more powerful. As it is not focused on final test results but on the intermediate data, of course this way of work helps the tester to valid the inner logic of the code. The code behavior is more readable.
A first general mean to monitor the internal data for testing requires simply to print them during the execution of the code. 'System.out.println()' calls are required. The Access Road code is full of such calls the code maintainer may easily enable and disable at any moment. The beauty of this testing approach is that no heavy development tool is needed, but a text editor, a Java compiler, and above all, the clear mind of a skilled developer. A second way to monitor the internal data for testing is to read the access paths of a view, because this contain useful descriptions about the paths search logic. With the functionnal-programming style of the access paths search, in the gWork packages, providing a detailled human review of these paths is an efficient way against bugs. Some comparisons between the access paths from two successive versions of Access Road may also be powerful to help the developer to trully understand its new code. We love the continous testing approach through automated tests based on a risk analysis. The previous principles may be seen as an extension of this well-known way. It is easy to convert the 'System.out.println()' calls into calls to a BaseError instance, to collect all the execution points and to use them as criteria of some automated integration tests, or, as Google says, medium-size tests. These criteria complete the classical set of input/output test data.
The Access Road classes are first Plain-Old Java Objects (POJO), because we think that well-structured and 'well-abstracted' POJO is the proven way to have great software. Interfaces and methods are stable, and their generic nature provides high-level operations. Some robust architectural patterns may then appear through the use of these classes in varied contexts, in an iterative process. The convention-over-configuration approach lets avoid needless work. Without the right property, a given feature is not delivered by the generic classes of the Access Road core. Without ACS addon to include a specific class, the core offers a generic class to get a default behavior. This is completed by the specific ACS configurations of the software simulations, like for Linux Ubuntu or MySQL Server, which may be easily copied and edited.
In the code, the naming convention for the classes, the methods and the properties is clear. Its application is very consistent. Each name is chosen to describe precisely the function of the object, like 'Resource' or 'EligibleParty'. In the gBase packages, a class 'XXXImpl' implements an interface 'XXX' in the relevant gBaseInterface package. It is associated to a BeanInfo class named 'XXXImplBeanInfo'. The AcsAddon class names are derived from the generic class names. The instance-level properties have a name ending with '_'. The method-level properties have a name without '_'. The method arguments have a name starting with '_'.
The Access Road structures are driven by data, rather than by algorithm. We stand for the idea of a strong database model from which the software structures and the algorithms grow up, since this is the true nature of a simulation software. This is the responsibility of this gBase package, with the secondary packages gBaseInterface and gBaseBean. The database model is also the best place for most of the data integrity controls. However, there is an exception for the type-oriented policy. It is not enforced by the gBase package, but by the GUI packages, typically in the Gui1.SimplePropertyEditor class and the gDMak.ActionNewResource class. The data-centric approach is also applied to the path search algorithms, the most complex part of the code. The concept of access path is modelled in the CNot.DisplayableLinkImpl class, and the concept of access link between two path nodes is modelled in the CNot.AccessControlLinkImpl class. In this case, the structures in the gWork package to find the paths may be seen as oriented by the semantic geometry of the possible links between the path nodes. Again, the path search algorithms are the result of an iterative structure-driven and abstraction-driven development process. The intermediate-data testing is able to test efficiently large constructors and large methods, contrary to the classical way. The path search algorithms are implemented with a functional programming approach, using large static methods. Very large methods with numerous loops are sometimes mandatory for providing the fastest implementations. These methods are strongly structured, to facilitate their editing.
THE ARCHITECTURAL PATTERNS
Several architectural patterns have emerged during the Access Road development, even if they are not always fully presented as pattern in the code documentation:
The little decision maker pattern in the gDMak package is responsible to manage the basic operations from the events of the menu.
The little internal frame pattern in the Gui1 package is responsible to handle the internal frames in the Access Road desktop.
The gBaseBeanInfo package applies an extended JavaBean pattern called the BeanInfoPattern, to set the handling of gBase objects in the GUI. This pattern covers the display of each property of the base object in the right GUI editor, and the policy to create, edit and delete the property. It is applied mainly by the gBaseBeanInfo and the Gui1 packages.
The embedded class pattern provides a form of multiple class inheritance for the classes in the gBase packages.
The event management pattern for the views is responsible to update a displayed view when a relevant property is changing, from a view node or an intermediate node in any access path of the view. It is described in the documentation of Gui2.GraphicViewBaseListener.
The thread management pattern for the views is responsible to provide a dedicated thread to each displayed view, for processing its own access path searches.
The access path search pattern is the most complex one. It includes mainly the generic gWork package and the AcsAddon gWork packages which contain the search algorithms. There is also the Gui2 package with the GraphicViews, and the CNot package which contains the notification interfaces and classes used for the data flow between the gWork packages and the GUI-oriented packages.
The pattern for the AcsAddons is explicit and well documented, covering the coding for each of the classes and methods which belong to it. It is mainly implemented in the gBase and the gWork packages. This pattern allows to add more easily some Java classes to do specific gBase and gWork functions. It does not allow to extended the CNot, Gui1 and Gui2 packages.
As a framework for simulators, Access Road needs to offer all these architectural patterns. It provides powerful capacities to simulate a new software, and to integrate it into the GUI and into the other simulations. Interface multiple inheritance, Java reflection in Java and dependency injection are used extensively in the patterns. On the other hand, Java annotations and aspects are never used. They have not proved their usefulness yet. The OSGi standard is much more complex than the AcsAddons pattern. It is not used mainly because the loading of a Java module during the Access Road execution is not a need.
ROLE OF THIS gBASE PACKAGE
The gBase package is responsible to model simple and complex software as access control systems (ACS). It provides models for all the ACS objects and for the views that contain a set of objects for which the access paths are defined. In the spirit of the 'thick database' paradigm, this package drives the display of the base object properties in the GUI, through the BeanInfoPattern pattern, and it drives also the access path search in the gWork package, through the access path search pattern.
The gBase classes protect their internal variables from external editing outside the control of given methods. At every property change, they check in the compliance with the integrity constraints coming down from the generic ACS, then they fire a matched property change event to the external listeners. In the gBase package, the integrity constraints are managed in each Java class in a true object-oriented design. It is not in separate tables like in a relational database. By this way, the reliability, the extensibility and the performance of the database may target a very high level.
In the gBase generic package, the class BaseManagerImpl is responsible for the management of the database. BaseManagerImpl handles the storing of all the data in files, with the Java class serialization. This includes mainly the Access Control System data, the ViewInBase and the Information System data. ACS is the main structure, since it simulates a given software, or a part of software, with its structure, its behavior and its access control functions. Each ACS may be independently created, opened, saved and closed. This is also true for the ViewInBases. To open a view, since the view objects are objects from some ACS, these ACS have to be open.
The Information Systems are tree structures to handle the varied relations between the ACS. They are created, opened, saved and closed with the ACS they use. They may contain passive nodes, for example a physical component. An ACS may have a subACS which is managed as a separated set of components and rights. Among the relations from an ACS to another, there is the tied relation forcing an ACS to be open with its ACS parent. A second relation is the visible space of Information System nodes on which an ACS may be connected around it. A third relation is the alternate relation where an ACS or a subACS is replaced in its access decisions by another ACS or subACS. With the combination of ACS, subACS, tied child ACS and alternate ACS/subACS, it is possible to design powerful structures for simulating complex software. With the concept of visible space, it is possible to manage the space of an ACS network where the relations among ACS are not predefined in each ACS, but are discovered by the nodes search algorithm in each ACS.
The classes ACSFactoryImpl and ACSImpl are used respectively for the construction and the handling of Access Control Systems. ACSFactoryImpl is the most complex class of the program. Its responsibility is to allow the setting of more than 100 properties in an ACS to create. This is the first key of the Access Road versatility. ACSFactoryImpl defines a generic ACS to simulate a given software, its structure and its access control functions.
HOW TO CONFIGURE A NEW ACS
Access Road uses four generic tools to provide the level of flexibility the varied software simulations require in the ACS. They are introduced hereinafter:
The first tool is a set of booleans to model the so-called 'ACS structure'. There are 22 main booleans, like one boolean to tell an ACS handles AclEntries or not. Some secondary booleans are also used to complement the first 22 ones. This ACS structure is the first mean to describe the properties of an ACS aiming to simulate a given software.
The second tool is a set of requirements for an ACS, as a list of sentences the user may easily read in the beamer. This list is called the 'ACS rules'. An example is the sentence 'sens meta-rule 1: this-ACS denying rights are superior to this-ACS granting rights'. Most of the booleans in the ACS structure have an equivalent as ACS rule. The rules help the user to understand how the ACS works. There is a common catalog of rules for all the simulations. Of course, the ACS rules are implemented in the Access Road code, like the ACS structure.
The third tool is a type-oriented policy for the ACS, based on a String property 'type' in all the ACSObjects. There are numerous possible constraints. The criterion to apply a constraint is generally the class or the type of the ACS component. For instance, an ACS may handle requirements like 'the types the instances of Directory may have', or 'the Aclentry rights the ACS permits for a Directory having a given type' (see the documentation of ACSCatalog.getM_TypeOrientedPolicy() and ACSCatalog.getM_TypesAndGUIPolicy()).
The fourth tool is the association. It is written by an advanced user in a small programming language, to be executed like a trigger at four types of events: the opening/closing of the ACS, or the creation/deletion of a component in the ACS. Association is a powerful tool to maintain integrity constraints on the ACS, like for instance the Linux constraint 'each account has a dedicated directory having the same name'. These constraints are not 'ACS rules' because they are too specific.
To configure a generic ACS without any coding in Java, an advanded user may use three possible ways, offering varied levels of complexity:
The main capacity of an ACS is defined in its ACS structure. It is its ability to handle or not different types of basic ACS components. Classes in the gBase package allow to model an ACS component, and they all implement the interface ACSObject. Some methods getManageXXX() in ACS set if a given ACS component is managed by this ACS. This includes for instance the management of Resources, GroupIDs and AclEntries, or the varied types of Privileges. Each ACS has its own structure set visible through these management properties the GUI displays. By this way, it is possible to understand in a look the main nature of an ACS. The documentation of these properties is for the gBase.ACSFactoryImpl and gBase.ACSFactoryUtilityImpl classes. The ACS rules are derived from the ACS structure.
It is possible to define a type-oriented policy. For instance, an ACS may handle requirements like the types the instances of Directory may have, otthe rights the ACS handles for Directory only. There are also the constraints on the type of UserID the program, but that are forbidden to the user when he creates a new UserID. Some last examples are the types a group allows for its members, following the group type, or the accounts which cannot be member of more than one group, following the account type. These ACS constraints have their own immutable second-level integrity rules. For instance, the second-level rules define the gBase classes on which the allowed types are check in at the creation of a new ACSObject. For the user, these lists and maps are more difficult to handle than the simple ACS management properties, but they may be forgotten most of the time. They are used by Access Road at each operation on the ACS. The user errors, if not limited by the dialog, are explained by the program. There are so very varied type-oriented constraints. For the GroupID and the GroupID memberships only, there are more than 12 specialized constraints an ACS designer may use. To go further, let's see the method getL_LimitedValuesForSpecializedTypesAndExplorer() in the class gBase.ACSFactoryUtilityImpl, as a first example.
It is possible to define some scripts in a small programming language. They are called associations, and a first example is the operations Access Road has to do after the creation of an object by the user. Another example is for setting the root objects of an ACS in its parent ACS, like the MySQL objects in the Linux on which MySQL runs. The small language has a given syntax the user has to learn when he creates the ACS. This is reserved to advanced users, even if it is much more simple than to code in Java. Most of the users have not to understand these scripts. They produce always updates the user may observe and analyze through the GUI without pain. On the other hand, like any ACS property, the scripts may be ridden through the GUI by the advanced users. The documentation of the small language is for the gBase.AssociateUtilityImpl class, and the method controlAssociations() is a good start.
THE BASIC CLASSES
In the gBase generic package, some basic classes are used by the ACS main components. They are:
NameImpl is responsible for managing the names for all the database objects. Examples of real name are "http://www.accbee.com", "c:\program files\access road", "net/users/john". The separator character depends on the ACS. All the real names are converted in Access Road names implemented by NameImpl. The single separator into the Access Road names is ':: '.
StringRightImpl is a subclass of Object which is responsible for managing a right. A right is defined without connection to the user rights or the access targets. This connection is the role of the right types, like AG rights or ACL rights for instance. There are two types of rights: the canonical metarights, outside any ACS, and the ACS rights. Each ACS right has a metaright as a reference; it is a StringMetaRightimpl, subclass of StringRightImpl. The metaright is used to compare rights from different ACS, and to explain precisely the ACS right semantic. A right has a sens, since it delivers a granting or a denying right.
Account/Group (or AG) rights and Bridge (BDG) rights are directly handled in the ACSObjects. The Account/Group rights are the most complex ones, since they depend on the multiple relations between the UserIDs, the GroupIDs, the Actors and the Resources. Inherited AG rights are also possible through Directory. The Bridge rights are simple executing relations between two Actors from different ACS.
AclEntryImpl is a subclass of Object which is responsible for modelling an access control entry which manages some access granting or some access denying from an EligibleParty to a Resource. The set of StringRights may be changed, but not the source or the target. A conditional AclEntry had some membership conditions to group(s) for delivering its rights to its EligibleParty. The AclEntry, the EligibleParty and the Resource may belong to three different ACSs, or, in the simplest case, to only one ACS. The AclEntry ACS is responsible to deliver or not the rights to the target. An AclEntry is created and managed by its Resource, and it is deleted if the Resource is. An AclEntry is uniquely defined by the set (ACS, Resource, EligibleParty, sens of the right, first condition GroupID). It may deliver no rights, or a list of all-granting or all-denying StringRights. This rights list is often editable by the user. It may deliver the rights only if the EligibleParty is member of one or several given condition GroupIDs. An AclEntry may be inherited from the direct or indirect parent of a Resource, following the inner rules of the ACS. It is not possible to set an AclEntry immutable for the user, contrary of a Privilege.
Privilege is an interface responsible for modelling an entity which manages some immutable access rights or some access restrictions. The set of StringRights cannot be changed after the privilege creation. There are 7 main types of privilege, and two interfaces which are all implemented by the classes PrivileForTypeImpl and PrivilegeForLinksImpl, subclasses of Object. In the interface PrivilegeForType, the ACSObject basic type is the criteria to apply the privilege to a source or a target. The user cannot modify the sources or the targets, since he cannot change the object basic types. These privileges are then fully managed by the program after their creation. In the interface PrivilegeForLinks, the criteria to apply the privilege is the links stored by the privilege, to the source(s) or to the target(s). The user may change the sources and the targets, but not the StringRights. PrivileForTypeImpl is used between couples (ACSObject set, ACSObject set). PrivilegeForLinksImpl is used between (EligibleParty or EligibleParty set, Target or Target set) where the Target is a Resource or an VirtualFolder. For some privilege types, a source or a target may belong to an ACS which is different to the Privilege ACS. In the simplest case, they belong to only one ACS. The ACS of the target(s) are responsible to deliver or not the rights to the target(s). A Privilege is created and managed by its ACS, and it is not deleted if a source or a target is deleted. Only some PrivilegeForLinks may be inherited from the direct or the indirect parent of their single target, following the inner rules of the ACS. A Privilege may be set immutable for the user.
The Directory, Resource and VirtualFolder classes may then manage container-for-target cascading rights to their children, called inherited rights. In Directory, this cover both the AG rights, the AclEntry rights and the Privilege rights. In VirtualFolder, this covers only the Privilege rights. No or one rights inheritance among three is possible in the structure of a given ACS.
A Directory may manage container-for-target cascading rights to its Resource children, both for the Account/Group (AG), AclEntry and Privilege rights. Nonetheless, the generic packages handles only the AG inherited rights. The two other inherited rights should be managed in the AcsAddon packages. In fact, the creation/removing of an inherited Privilege or AclEntry in a child is not handled by the generic gBase package, while their right updatings are handled.
The container-for-target relation is an inner principle in VirtualFolder to deliver rights to its members as targets, and it manages also container-for-target cascading Privilege rights to the VirtualFolder children (not to the members). At the source side, the container-for-source relation is an inner function of GroupID to deliver rights to its members, and in GroupIDMember to deliver rights to its members and running Actors. On the other hand, Directory and VirtualFolder do not deliver source rights to the sources that are their children or members. The container-for-source principle is managed in DirectoryEP (in a future version) to deliver source rights to its children.
In the generic gBase package, there are several embedded classes with a name starting with 'C', like CNodeImpl. Such a class provides a common large function, like privilege handling or node handling. They are used in different ACSObject classes. Each instance creates one single dedicated instance of an embedded class only when it is necessary. This structure provides a form of multiple class inheritance. It avoids for example to replicate the code for node children in DirectoryImpl and VirtualFolderImpl, since both handle a CNodeImpl instance to do the work. Furthermore, it allows to reduce the memory print of an instance when the object does not use the function, since the embedded class instance in the object is then null. This defines the gBase embedded class pattern. This pattern may be useful for a new function used by several classes in an AcsAddon package. The embedded classes in the generic gBase are never directly used by the other packages, but they may be sub-classed by an AcsAddon, just like the other gBase classes.
THE VIEWS
In the gBase generic package, ViewInBaseImpl and its subclasses manage the views. A view is a passive container on which Access Road processes the access paths search to find the paths between all the nodes of the view. There are several types of views:
ViewInBaseImpl is a subclass of FolderAbs, which is also the superclass of VirtualFolderImpl. The relation ViewInBase/member is weak, since the deleting of the container or the member does not delete the other entity.
ViewInBaseImpl has 3 subclasses, EPRViewInBaseImpl, NoThanViewInBaseImpl and SketchViewInBaseImpl. These classes are responsible for modelling a set of BaseObjects for which the GUI may provide an ARoad0.Gui2.GraphicView.
ARoad0.Gui2.GraphicView displays the current rights and links between any couple of view objects, or nodes. There is a 1:1 relation between an open ViewInBase and its GraphicView, if any.
The ViewInBases in the gBase package do not handle the rights and the links, but only the nodes in the view.
EPRViewInBaseImpl is a subclass of ViewInBaseImpl. It has for GraphicView an ARoad0.Gui2.GraphicEPRView. It is the most general view. It stores the nodes and listens some basic property changes to inform its GraphicView. Such a view may be opened without been displayed in a GraphicView.
NoThanViewInBaseImpl is a subclass of EPRViewInBaseImpl. It has for GraphicView an ARoad0.Gui2.GraphicNoThanView. It checks up the compliance with the rights upon 2 optional rules : a maximum right and a minimum right. It stores the nodes and listens some basic property changes to inform its GraphicView. Such a view may be opened without been displayed in a GraphicView.
SketchViewInBaseImpl is also a subclass of EPRViewInBaseImpl. It has for GraphicView an ARoad0.Gui2.GraphicSketchView. It does not listen the property changes of the nodes. Such a view is never opened without a GraphicSketchView, and it is never saved.
The other package classes may listen the property changes in the gBase objects, and the generic gBase package uses only the interfaces of the gBaseInterface package. Most of the classes in the generic gBase package are designed to be sub-classed in the AcsAddon gBase packages. There is a dedicated interface the AcsAddons use to declare the specific property changes the other packages have to listen on their AcsAddon objects (see the documentation of the Gui2 and gWork packages).
THE THREADS MANAGEMENT
The threads management and the event management for the views are described in Gui2.GraphicViewBaseListenerImpl. From the multi-threading point of view, the aim is to provide the best use of the processor capacities for searching the paths. The principles of the thread management are presented there only for the gBase package, as following:
most of the gBase classes implement the ACSObject interface. Their instances may be nodes in a view, and their 'get' methods are invoked in the search of access paths. The search is done in a worker thread, and the GUI may handle several views at the same time. An ACSObject 'get' method may then be acceded in the same instance by more than one thread at the same time, if the node belongs to several open views. Nonetheless, these methods provide copied or immutable values; they are short and not synchronized, to remain fast. The pattern 'value object', from Eric Evans Fowler, is not used there. It is used for instance in the String java class.
ACSImpl is a tricky case, since the frequency of calls from different threads should be far more greater than the same frequency for a single ACSObject. This is why there is very few direct accesses to ACS instances in the access paths algorithms. This is recommended also in the AcsAddons. For the rare ACS methods that are used or should be used by a view worker thread, the method documentation has the comment 'may be called from a view worker thread'. These methods are fast. Furthermore, all the ACS new/remove methods on Resource, EligibleParty, VirtualFolder, AclEntry and Privilege are never called by a view worker thread, and thay are synchronized.
For the rare BaseManagerImpl methods that are used or should be used by an ACS add-on, the documentation contains a comment 'may be called from a view worker thread'. These methods are fast and synchronized.
BaseUtilityImpl is not used by the view core algorithms, and it provides methods for the updating of the gBase object properties. The class UtilityImpl provides some core algorithms to the views. Each view handles an instance of this class, to perform an efficient multi-threading without thread collision. This class is stateless.
THE MANAGEMENT OF THE ACS ADDONS
The principles of the AcsAddon management for the gBase package are presented hereinafter:
The AcsAddon pattern allows a programmer to add more easily to Access Road some Java classes for implementing new gBase and/or new gWork functions. This pattern may be used when the generic packages do not provide the required functions to simulate of a new software.
The first solution to study is always to code the creation of a new type of ACS in gDMak.ActionNewACSyst and gWork.AcsFactory, using the current gBase and gWork packages. Otherwise, a first alternative is to modify directly the code of these generic packages. This is more powerful, but may be much more complex. Furthermore, the compatibility with the future Access Road versions becomes an important issue, and it requires an extended test.
On the other hand, with the AcsAddon pattern, the interfaces of the new classes with the Access Road generic packages are designed to be stable and relatively small. The AcsAddon pattern is based on the subclassing of some generic gBase and gWork classes. Only the new functions are coded, and most of the current Access Road code is reused. For these reasons, the resulting code is much more easy to test and maintain.
The user cannot derive by hand a new set of ACS generic properties from an AcsAddon. Any configuration of the generic properties is handled, controlled and applied in the generic algorithms, at and after the ACS creation. On the other hand, the specific algorithms of an AcsAddon cannot apply any combination of the ACS generic properties, but only the set its AcsFactoryForAcsAddon has build up.
Each AcsAddon has exactly 4 specific Java packages. There is a strict policy for the naming of these packages. Names are derived from the AcsAddon name, like 'ARoad0.AcsAddon.Accbee.Ubuntu.gBase' for the gBase package for the AcsAddon Ubuntu from the editor ACCBEE. The AcsAddon may include a gBase package, with its gBaseBeanInfo and its gBaseInterface packages. It always includes a gWork package, with at least an ARoad0.Pattern.AcsFactoryForAcsAddon implementation to create the ACS. In the simplest case, an AcsAddon contains only one AcsFactoryForAcsAddon and one subclass of any generic gBase or gWork class. But in all cases, the 4 directories for the 4 AcsAddon packages have to be defined. Otherwise, the program detects the issue and it does not start.
Usually, most of the classes in the gBase package of an AcsAddon are subclasses of the generic gBase classes. These classes can be visible to all the program, or they can extend an embedded generic class like CNodeImpl. In this latter case, they are used and known only by the classes of their own package, or a derived package. The AcsAddon gBase classes implement the gBaseInterface interfaces of their AcsAddon, if any. Most of the AcsAddon.gBase classes may be viewed as having a double inheritance: one from a generic gBase class, and one from a set of methods that are duplicated in each class to implements an AcsAddon interface. If the AcsAddon.gBase class simply overrides a method of a generic gBase class, there is no double inheritance. Ubuntu is an example of AcsAddon with a double inheritance for its gBase classes. It may be studied to understand a complex application of the AcsAddon pattern.
In an AcsAddon, the ACS may define new booleans in the ACS structure, and new formal rules in the ACS rules. The formal rules have to belong to a registered catalog of rules which is maintained by the ACCBEE company. The aim is to facilitate the reusing of formal rules. Like the other formal rules, the AcsAddon specific formal rules are displayed in the beamer. It is possible to complement them with informal rules to explain freely the simulation.
The generic packages handle fully the AG inherited rights, and this is not true for the ACL and LPRI inherited rights. For them, the generic gBase package provides some basic methods on Resource and VirtualFolder to set and get the inherited rights. But there is no code to update the ACL and LPRI inherited rights in the children of a node, as it is done for example in the MySQL AcsAddon. On the other hand, the generic gWork package offers a basic processing of the three inherited rights in the access path search. These generic gWork functions may also be extended in an AcsAddon.
In an AcsAddon, to process the AclEntry or PrivilegeForLinks inherited rights, it is mandatory to code how the Directory or VirtualFolder creates and removes the inherited PrivilegeForLinks or AclEntry in its direct children. This may include the choice of the objects that becomes inherited ones, and the definition of an order to select them in each target. The default behavior, in the generic gBase package, is to inherit all the applicable AclEntries or PrivilegeForLinks, and to sum up all the rights. After the creation to code, the right updating of the inherited object is handled by the generic gBase classes. It may also be necessary to code a LinkRightsImpl subclass in the gWork package. Examples are for overriding some of the five 'ThroughNodesTree' methods and the method mergeInheritedAclPriRightsThroughNodesTree which implement the rights inheritance algorithms.
The generic gBase package provides an embedded CAliasImpl class to set and get the hard alias and the soft alias of an ACSObject. There is no generic code to define when a reference object has an alias, nor to allow the user to set an alias through the GUI. The reason is the alias function is truly intrinsic to a given simulation in an ACS, as it is done for example in the MySQL AcsAddon. There are internal aliasing in an ACS, and also external aliasing. It is the responsibility of the ACS associations to set an internal alias for one of the ACS objects. AcsAddons are not required for the internal aliasing, but they may use it. On the other hand, the external Alias relation is always set by a gBase class in an AcsAddon, never by the generic gBase classes. In the two cases, each ACS is responsible to script or to code its proper use of the alias types. A typical application is to script an association for a new ACSObject, for creating the internal alias of the ACSObject. The generic gWork package offers the processing of the two types of alias in the access path search. These generic gWork functions cannot be extended in an AcsAddon.
An AcsAddon must have a 'acsaddon_guide.html' file in the AcsAddon gBase directory, as the first user guide. In this same directory, it may provide an icon for the ACS, at the format JPEG.
A typical application of the AcsAddon pattern is for adding a new search algorithm. For instance, it may be necessary to handle differently the typed privileges. In that case, a LinkRightsImpl subclass is defined to override the four 'PrivilegeForType' methods.
An AcsAddon may be based on another AcsAddon. In that case, it is recommended to not change the ACS generic properties without a thorough validation. It is better to never modify these properties. On the other hand, an AcsAddon may very simply change the displayed name of a generic property. For instance, the generic property 'SoftAlias' is a list of names in the interface ImmutableBasic, to get the soft aliases of an ACSObject. It is used by the MySQL AcsAddon which does not manage the ACS soft aliasing at all. To avoid unusuful coding, this AcsAddon renames 'Soft Alias' as 'Proxy accounts' for the beamer, through the package gBaseBeanInfo. Then, the MySQL AcsAddon handles the generic property for its proper modelling needs.
To summarize, the path search algorithms are based on a full object-oriented structure. The AcsAddon pattern is based on the gBase concepts and methods in the algorithms. It is possible to add simply any additional modelling, any additional processing of an ACSObject, and to modify the generic access path search algorithms by the mean of an AcsAddon gWork package.
FOR FUTURE VERSION: The principles of the tied AcsAddons are presented hereinafter:
The tied AcsAddons are applications of the AcsAddon pattern in the context of the general ACS handling. Without this pattern, it is possible to design an ACS manually or by code, then to copy it to create an ACS image under another ACS. But the copying function has limited capacities to adapt the resulting ACS to its new context.
The tied AcsAddon pattern allows to code a specialized ACS so that it is easy to install it under any parent having some known properties. For instance, the ACS of the AcsAddon 'NetworkGate' may be added as child to an ACS, for handling the IP network of the parent. The tied AcsAddon ACS offer common simulation functions to any new ACS which is its parent. A tied AcsAddon ACS cannot work without its ACS parent.
THE LIMITATIONS OF THE MODEL
In the version 0.7.2, Access Road has some limits. They are presented hereinafter:
The rights simulation is static and do not include the simulation of the authorized changes among the rights by the users of the simulated software. The administrative rights, that is the rights to change the current rights, may exist in the simulation, but the rights transfering to other users is not modelled, nor their impacts on the current rights. These administrative rights are not used to detect the new access paths if an user would grant its proper rights to another user.
In a conditional AclEntry, if the AclEntry source is not a member of one condition group, it is necessary to listen the changes in the membership relations to update the effective rights. Rights change when the source becomes an indirect member of the condition group. This listening along a chain of groups is applied to all the groups for which the source is indirect member. However, the distance of these listened groups to the source, that is the number of intermediate groups, has to be inferior to 5. Otherwise, a new indirect membership is not detected immediately by Access Road, and the relevant views cannot be updated. The indirect membership detection is always correct at the opening of a view, whatever the membership distance source/condition group.
In the NameISTrees, only the 'tied child' relation is currently managed fully. For the access path search in the gWork package, there is no handling of the complex properties like the alternate relation or the ACS visible space.
The DirectoryEP class is not defined, but the ACS structure includes a boolean 'manage right user directory' for further works.
The 2 Privilege implementation classes handle varied types of Privileges, but the usable types in gWork are only the simple PrivilegeForType, the simple PrivilegeForLinks and the one-to-one PrivilegeForLinks.
The copy of an ACS or an ACSObject is not managed, even if some old methods exist.
ACCESS ROAD KNOWN BUGS
When the number of nodes is great, the full view may deliver a wrong drawing of the links, arrows and texts, at false locations, after the adding of the removing of a node.
Ease-of-use: medium. The package is well structured, but the database concepts have to be well understood. There are medium-complexity algorithms to set dynamically the references between the variables, to apply the ACS structure, to define and to apply the ACS policy.
Reliability: medium-high. The main execution paths have been well tested.