Open Modeling Architecture
For all details on the script language, see
Script language.
Open Modeling has implemented this architecture in the following way:
The client uses html and javascript to create and manage the user interface.
All information is sent to the client in an XML-stream. The JSP pages are only used
to pass parameters to the java-beans and pass back the resulting xml-stream.
The server uses java beans to access the database and compose the required XML stream.
This setup facilitates a change of a new client presentation based on the same XML stream.
It saparates the development efforts as well by a defined interface between client and server.
Hyperlinks name resolution should be done at run time as the name of the object may change between page retrievals.
Browser support is currently quite broad. The browsers that have been tested are:
Any other browser may support Openmodeling very well, but you will have to test is yourself.
Based on popularity changes changes may occur.
Application servers currently supported are:
- Tomcat
- Wildfly
- Jetty
- Glassfish
- Weblogic
- Websphere
Based on popularity changes changes may occur.
The databases supported by Openmodeling are:
- MariaDB
- MySQL
- SQL Server
- Oracle
- PostgreSQL
- DB2
The connection pooling is achieved with the Poolman poolmanager. The pooling is done for all supported Database Management Systems. Settting up a datasource for
the applications server is not required, the presence of the JDBC jar-files in het WEB-INF/lib directory is sufficient.
Based on popularity changes changes may occur.
One of the design principles was it must work in a standard browser with minimal installation
effort (on the client and server).
The requirmenets were:
browser independent
minimal installation effort
zooming
open standard
Browser support for SVG is broad now and stable.
Java Data Base Connection is the standard for database connection from Java. Most database vendors
have created an implementation of this standard to connect to their own database. Open Modeling
proves the validity of this standard by supporting the major databases. The stability of JDBC is good.
Open Modeling has usergroups an users. A user can have one or more roles so occur in several
usergroups. If this is the case, after logging on a choice is offered for the relevant usergroups
from which a choice should be made. During a session you can change user usergroup by using
the menu option "Change setting"
The username and a timestamp at each database record which user has last created or modified
a record. The complete audit faclitities of the DBMS of your choice are available to you. Your
DBA can inform you about them.
The autorisation is set up according to the barrier-principle: all is permitted unless het
is prohibited by authorisation. To prohibit an action of a user(group) you can create or change
a record in one of the authorisation tables.
These tables have a relationship that acts like an inheritance-mechanism:
In fact this means that if editing is prohibited on the model level for a usergroup, all entities
of this model can't be edited by this usergroup.
On the lowest level selected entities or selected items of an entity can be made non editable.
Exceptions are not implemented: it is not possible to make a model non editable except entity x:
in that case a more detailed authorisation on the lower level should be set up.
Apart from authorisation there is a read-only attribute which prohibits editing from all usergroups.
This attribute is switched on for items that are not editable by their nature (f.i. script items).
Currently the following permissions can be used on every authorisation level:
S=SELECT
I=INSERT
U=UPDATE
D=DELETE
This list can be extended, but every (new) value requires a specific handling in the java-beans.
The category authorisation is limited because an entity can be attached to several categories.
As a consequence inheritance from the categories authorisation will not be consequent.
We have planned to set up the authorisation along the lines of a hierachy and other types
of bulk-authorisations.
An appropriate default authorisation value for every new created entity (for all entitytypes
separately?).