LLMCMSS.09 - CMS requirements in LLM-Database

This section summarizes all the data structures and access mechanisms used by the LLM-CMS in the LLM-Database.

As the LLF is considered as an external component to the CMS subsystem, it can be considered as if had an "ENVREQ:" in front of it

All CMS subcomponents are clients for the LLM-DB components and store their persistent data there in structures described in the section.

LLMCMSS.09.00 - Document Control

LLMCMSS.09.03 LLM-DB interface required by CMS function

LLMCMSS.09.03.01 General PROPERTIES structure in LLM-DB

As some, if not most of the specific properties and attributes required by most of the components in the LLM-system CMS subsection are not yet known, expandability shall be built into the LLM-DB in order to keep the database structure stable and open for expansion.

1. There shall be a PROPERTIES structure in the LLM-DB with a hierarchical structure to be used for an enhanced version of the Name/Value pattern
2. properties shall be able to be grouped in structures like sections (as known from .ini files) or directories (analogy with file systems)
3. sections also should be properties having names, the value being the sub-structure, producing tree-like organisation
4. Each property entry item shall have a unique ID. Uniqueness shall apply inside one instance of LLM-DB. No uniqueness may be guaranteed when one item is deleted and another different one is created. In this case the unique ID may be re-assigned. Applications should not rely on this uniqueness or, if required, take care of it on the application level. However, the unique ID shall be able to be used when traversing structures. If an entry has been deleted and is requested again by its unique ID, it is permissable to return a NULL value or to throw an exception (on the client API library side).
   Additionally, unique IDs may change when exporting a sub-tree and re-importing it. This ensures the possibiity to import the subtree at another place in the higher hierarchy tree or importing it more than once, for instance in order to implement one type of templates.
5. A property name shall be a reference to a place in a certain property tree, and shall be able to be either of:
   1. absolute path in LLM-DB property tree, sections separated by "/" (preferable in the client library using path-separator variables)
   2. relative path to the "current" context the client is (using a context reference in the client library keeping track of the path context
6. A property value shall be one of:
   1. number - shall be able to hold 64-bit-FLOAT and 64-bit-INTEGER with auto-conversion if necessary
   2. string (unicode) - may be limited in size but no shorter than 1024 characters
   3. Document / Large String (CLOB)
   4. collection ( => strong link ) of more properties
   5. reference ( => weak link ) to one of: - recommended to be used only for certain cases as templates and shared properties
      1. collection in same DB-instance
      2. relative pathname to any type of item value
      3. absolute pathnameto any type of item value
7. properties references shall be usable in all other LLM-DB structure, however, LLM-DB may not need to be aware that some string is a property path
8. There shall be a client library in JAVA providing collection, properties and iterator interfaces to the properties structure
9. Methods in the client library shall keep a context to support buffering and maintaining a "current" place in the property tree
10. There should be methods in the client API to handle absolute and relative paths

LLMCMSS.09.03.02 Classes / Collections of items required and processed  by CMS in LLM-DB

1. Seniors, enhanced by property handle for each entry
2. Users, enhanced by property handle for each entry
3. User rights, roles and permissions managed in property subtree named "auth". Master is account management in CMS components, all other clients must only read with robustness for changed structures between traversal reads.
4. Sessions, enhanced by property handle for each entry if already existing. If not yet existing, implemented as property subtree named "sessions". Sessions shall only be changed by the CMS component session management API, all other clients shall use this subtree as read-only with all the caution required by the fact, that one client may traverse the session tree for viewing purposes and the session management may delete the whole subtree or at least part of it.
5. Equipment Data: local terminals, Server Boxes, PTC devices, enhanced by property handle, if already existing and used by other components. If not yet existing, implemented as property subtree named "devices"
6. System Configuration Data, a property subtree named "sysconfig"
7. General Config-Items / Properties / Attributes in a property subtree named "config"
8. Activity-Information / Notification Data / Event Data in property tree(s)
9. Workflows in property tree(s) managed on a higher structural level inside the workflow processor, located in properties subtree named "workflows"
   
   1. Templates
   2. Instances
   3. Steps
   4. Agents, with relation to users
10. Schedules, Appointments ( vs. ICalendar, ...), attached to users or devices or system general ("sysconfig") as properties subtrees named "calendar"
11. All objects processed by LLM-DB clients shall have globally unique immutable object IDs. These shall NOT be re-used if an object is deleted and a new one is created. This may lead to a new object ID if an object is deleted and created with the same set of attributes, but this is design intent.

LLMCMSS.09.03.03 Methods for unified and secure access to LLM-DB items

1. A unified access method to all objects in the LLM-DB shall exist as specified in LLMCMSS.04.02.14. (See discussion in LLMCMSS.B, Questions 14 and 15)
2. The unified access API shall incorporate the access protection in order to avoid sending unauthorized data across machine boundaries.
3. Access security shall allow for a fine grained system of controlling access to any node and/or subtree of the data model defined by LLMCMSS.04.02.14.
4. Access security shall be able to allow/restrict operations ADD,READ,ENUMERATE,CHANGE,DELETE on any subtree by a system of access control lists (ACL), consisting of access control entries (ACE).
5. Any ACE shall allow any combination of the mentioned operations to one node to the holder of a unique rights-identifier.
6. A rights-identifier shall be able to be held by any user, role and group.
7. Any user, role or group shall be able to hold an arbitrary number of rights identifiers.
8. A rights identifier shall be stored as a NUMBER of min. 64 bit size and shall be able to be unique not only in one LLM-DB instance but globally across all thinkable LLM-DB instances, if necessary by a system of prefixes and classes of rights-identifiers clearly marked as "local" or "private"
9. ACLs shall be able to be attached to any node in the unified LLM-DB tree.
10. When checking access rights for a specific operation to a specific node, in the case of the checked node having no ACL, all the ancesters of the node in the tree shall be checked for an applicable ACL.
11. rights identifiers shall be able to have names, stored in a seperate section of the LLM-DB unified tree and carrying the numerical value of the rights identifier
12. See also the discussion in LLMCMSS.B, Questions 16 thru 19, for implementation hints and concepts