The WEM platform offers several distinct storage mechanisms for your application data. In this article we will discuss each of these options and what to consider if you intend to use them.
Data organization: The ontology allows you to organize data in a tree structure. Each record(data item) is represented as a node in the tree. These nodes are refered to as concepts. Attributes of the data item will be represented as properties on the node (concept). Besides organizing the data in a tree structure of concepts, it is also possible to create custom relationships between the concepts thereby creating a graph of concepts(data items). Then using an Ontology Query, which is basically a graph query, you can retrieve specific concepts from the ontology.
Data availability: The data is directly present during the time of development, which allows you to include the actual data directly into your application logic.
Modifying data: The data can only be modified during development time. During execution of the application the data is read-only.
Data persistence: The data is persisted during the time of development.
Data accessibility: The data is accessible by all sessions.
Use case: This storage is perfect fit for data that decribes the domain of the application. For example when creating an authentication/authorization system, the different kinds of user roles and privileges can be described using the ontology. This data is static in nature and will be included when modeling the access control logic of the application.
Persistent and Transient Entities
Data organization: In WEM entities are tables, in which an entity instance is a row of the table. For example a list of people can be stored as an entity named “Person” and storing each person on the list as an instance by creating a row in the table. Entities can be nested to create child/parent relationships between the container entity and the nested entity. The amount of nesting is limited for Persistent Entities.
Data availability: During the time of modeling your application you can only define the schema/structure of the entity, creating the entity and adding the fields you will need for storing the actual data. Storing the actual data is only possible during execution of the application. The actual data is therefore not present in the application during development. In short during development only the schema/structure of the data is known. During execution both the schema and actual data is available.
Modifying data: The data can be read and modified during execution.
Data persistence: Transient and Persistent Entities are distinguished by the fact that data stored in transient entities are only available for the duration of the session and also only accessible to that session. Data stored in Persistent Entities will be persisted beyond the duration of a session. Note that when data is added to an Persistent Entity during a session, it will only be persisted when the changes are committed during the session.
Data accessibility: Data stored in a Transient Entity is only accessible to the session who added it. Commited data stored in a Persistent Entities are accessible across all sessions of the application. Note that uncommited data in a Persistent Entity is only accessible to the session that added/modified it.
Using Ontology and Entities side by side
Sometimes the total data of the application can be organized by using the Ontology for the static portion of the data and Entities for the dynamic portion. For example when creating an authentication/authorization system, the type of users, user roles and privileges can be stored in the Ontology as concepts and the actual user instances can stored in an “User” Entity. In Wem it is possible to create references from an Entity instance to concepts stored in the Ontology using concept and conceptset entity fields. It is therefore possible to store the privileges and user roles of a particular user by storing references to these corresponding concepts in the Ontology.