Platform Modulearchitecture
Diesen Artikel in deutsch ansehen...
In the oK-context, a oK-Module is an independant software-component. oK-Modules are services, like Cross Cutting Modules or Service Modules and User Modules.
This article describes the inner architecure of a single-oK-Module. It can be used as architecture template to develop similar structured software-components. Over the time it is possible to create, extend and use a oK-framework library for common oK-functionality.
The following UML component diagram shows the proposal for an oK-Module:
Inhaltsverzeichnis
- 1 1 oK-Module
- 2 2 User Interface (optional)
- 3 3 Module Core
- 4 4 Application Logging Connector
- 5 5 Authentification Connector
- 6 6 Authorization Connector
- 7 7 Job-Scheduling Connector (optional)
- 8 8 Monitoring Connector
- 9 9 Settings
- 10 10 Persistence (optional)
- 11 11 Data Interchange
- 12 12 Communication
1 oK-Module
The oK-Module component consists of different components and parts. Some of them have specific functional requirements and must be implemented especially for the application purpose. But there are also components and parts, that have common functionality and features in the oK-context. Some components and parts are not necessary and can be ommitted. They are optional.
- gray components and parts are optional
- blue components and parts are candidates for a common oK-framework library
2 User Interface (optional)
The User Interface is an optional component for modules, that interact with the user. Usually the Service Modules have no user interface. The User Interfaces are web-applications, that are connected via a REST/JSON communication with the backend.
3 Module Core
The entire application logic is provided by the Module Core. It defines the flow control and manages the interaction of its components and parts to fulfill the functional and technical requirements.
3.1 Business Logic
This part is the heart of the Module Code. It defines the functional requirements.
3.2 Data Model
This is the application specific data model.
It can be inspired by the CIM standard. But be careful. Usually it is not recommend to use the CIM-Model as application own data model. It has to be attentively evaluated, if your performance and software design requirements can be fulfilled. Please also keep in mind that you have a potentially unwanted dependency to CIM.
3.3 Cache (optional)
For performance reasons it is sometimes a good idea to hold often used application data in the memory. The application can use the optional Cache component for this purpose.
3.4 Tracing/Logging
The Tracing/Logging component records technical and functional events, messages and errors that occur while the application is running. It can be used to understand or reproduce malfunctions. It also can be used for archiving purposes and audits. Usually a local-file and/or application console keeps the trace and log records.
To create homogeneous formed log entries and use comparable log levels, it is recommend to implement and use a common oK-logging-component.
4 Application Logging Connector
The Application Logging Connector provides access to the Application Logging Module of the oK-platform.
5 Authentification Connector
The Authentification Module can be used for authentification purposes. This component provides access to this module. It should be implemented module independant, so it can be reused by other oK-Modules.
6 Authorization Connector
The Authorization Connetor is similar to the Authentication Connector and provides access to the common Authorization Module.
7 Job-Scheduling Connector (optional)
Some oK-Modules provides time-dependent processing. With the Job-Scheduling Module it is possible to control the time-dependant processing of different oK-Modules in the right chronological sequence. If the current oK-Modules has any time-dependant processing, the Job-Scheduling Connector enables the access to the common Job-Scheduling Module.
8 Monitoring Connector
Using the Monitoring Module the system operator gets the accurate status information of every distributed oK-Module at one glance. To enable this functionality, it is necessary that every oK-Module provides information about its current state. The Monitoring Connector provides the access to the Monitoring Module.
9 Settings
Normally oK-Modules have a set of configurable values, that are not changed throughout the entire module runtime. For example, they enable the integration of a module in different environments or enable/disable optional module features. The component Settings provides the current configuration. Since the way to access and store settings can be reused, it is recommend to implement or use a common component of the oK-framework library.
10 Persistence (optional)
With the optional Persistence component, the oK-Module can persist its data. Usually a database management system is used for this purpose. But the most suitable storing method depends on the specific needs and requirements of the actual oK-Module.
11 Data Interchange
The Data Interchange component is used to exchange data and information with other oK-Modules or the source systems.
Since the communication with the Module Core is encapsulated in an interface, the Data Interchange component can be replaced easily. So it is possible to minimize the costs, when the communication standard or version will be changed. It is also possible to operate different communication standards or versions concurrently.
11.1 Interchange Data Mapping
The function of this part is to map the Data Model of the Module Core to the Interchange Data Model and vice versa.
11.2 Interchange Data Model
The Interchange Data Model is the representation of the data that should be exchanged with other oK-Modules or the Source Systems. Usually, but not necessarly, this is a CIM-Data Model.
It is an indicator for bad software design, if you use the Data Model as Interchange Data Model. The two models are usually differnt and have to be maintained independently.
11.3 Payload Generator
This part creates the functional information, that should be transfered to the receiving oK-Module or Source System
11.4 Message Generator
The Message Generator prepares the message for transfering. It enriches the payload with meta and routing information that enable the messaging middleware to forward the message and help the receiver to parse the payload.
11.5 Payload Validator
The Payload Validator checks the functional payloads of the incomming messages, if they meet the minimum defined requirements.
11.6 Message Parser
Incomming messages will be analyzed and parsed by the Message Parser. The Message Parser unpacks the payload of the message and transfers it to the Payload Validator.
12 Communication
The reusable Communication component receives or sends the data, that should be exchanged with other oK-Modules. It complies and implements the guidelines that are defined in the Communication Guideline.